[Fiware-miwi] SceneAPI features: original intent of the EPIC vs . current plans?

[Toni Alatalo]

On 21 Nov 2013, at 10:54, Lasse Öörni <lasse.oorni at ludocraft.com> wrote:
> If there is a good concrete plan to how it should be done instead it's not
> at all too late to change (as any implementation has not began), and if
> it's administratively OK, for example our architecture pictures now
> include the REST scene API described.

I talked today with a guy who is working on the vw / visualization front in the university project with the traffic sensors in the city.

We agreed preliminarily that could use their data and system as a use case for this SceneAPI biz on the fi-ware side — if you and others here find it’s a good idea.

Their data currently updates once per hour, though, so http would work :)

But he had already proposed as a next step a visualisation where traffic is simulated / visualized as actual individual cars. We could have that simulation service as a user of the scene api / sync biz to control the cars so we’d get streaming nature for the data and much harder reqs for the usage (in the spirit of the EPIC).

I still have to confirm with the prof whose leading that project that this all would be ok. We could do it so that the actual implementation of the visualization and even the integration comes from the uni and fi-ware (Ludocraft) only provides the API. I can use some of my university time for this as the integration of the city model and the traffic data is good to get there.

This is not a must and I don’t mean to overcomplicate thing but just figured that a real use case would help to make the *concrete plan* that you called for above. 

The experience with the quick and simple POI & 3DUI integration (completed yesterday) was great, I’ll post about it tomorrow hopefully (the POI guys checked the demo today on ok’d it as this first minimal step). So I hope more integrations and usage of the GEs takes us well forward.

> Lasse Öörni

Cheers,
~Toni