[Fiware-miwi] Hands-on: POI Data Provider GE

[Toni Alatalo]

On 20 Feb 2014, at 20:32, Stefan Lemme <stefan.lemme at dfki.de> wrote:
> Wouldn't it be better to reference a remote xml3d element directly by URI instead of string-encode dom elements?

I’m not involved with the POI work but from a 3D-UI perspective I wonder whether both ways have merits.

I imagine embedding some simple for example icon type graphics or why not even simple meshes might be handy in the same JSON. It is then simply a part of the POI data .. POIs can have long textual descriptions embedded, the text for those is I imagine typically not gotten from a separate sources. Seems sensible to allow including also 3D vis data the same way, no? On the other hand I imagine images are always references? — then again those tend to be big, except exactly simple icons and so. A simple 3D thing can be tiny, not much different from a long text desc.

Hm, and with XML3D it can be anything basically, no? For example: <mesh src=“http://someserver/my.xml3d”/>. Or perhaps more interestingly:
	<group transform=cartesian(POI.position)>
		<hoveringtext text=POI.name font=category2font[POI.category] />
		<billboard src=POI.image />
	</group>
or:
	<primitive-box/>

That is: the xml3d elements can be a self-contained declaration of the 3d for the POI, using only the POI data. 
Yet perhaps such visualisation template / logic doesn’t belong to the POI data. This old POI - 3D-UI demo / test online, has that kind of POI 3D visualisation, with just simple bubble plates for name texts: http://playsign.tklapp.com:8000/POIThreeJS/POI.html (best with chrome, the mouse handling there has a quirk on firefox). So here the 3d for the POI is just the visualisation style (the city buildings are in the 3d scene, not from POI data there). I think we don’t want such vis logic in the POI data but in the whatever views the apps have. I mean the red bubbles, that sort of things you’d get with the <billboard> etc. So yes I also figure the idea in the POI data is to ref to external 3d vis data which often further uses a mesh, textures, shaders etc.

But it may be the case for the practicality of just embedding e.g. simple mesh geom still holds - I’m too tired to think through now really.

Anyhow I’d also think that URIs there are necessary. That is in fact how we were planning the use of the 3d city models in a city AR setting, in the prev Tue meet: we'll make POIs for the buildings which then ref to the Oulu3D buildings which are on the Web otherwise already. Definitely good that the POI & AR biz doesn’t need to touch the 3d data in such (hopefully normal) case that they can just happily use the normal city service web version’s data. We probably need to deal with LoD levels there etc anyhow also for the VW use so is probably a good idea to use the same system also for the mobile devices for the single-house (a POI) use case we discussed then.

poor disclaimer: i’m not sure if i understood your point correctly as haven’t read the specs and all - just commenting as it is then the 3D-UI's job to deal with that data .. make it show, either from the given string or uri.

Anyway that’s probably trivial for the guys to go either way in the spec and easy enough to deal with in the codes etc so I’m sure there are no problems with this. But seems like a good catch, thanks from our part as well!

~Toni

P.S. Was fun to test the looks of reX ECs as XML3D there again. Because those two example xml elements, ‘hoveringtext’ and ‘billboard’ are not standard xml3d elements, not in those specs. But they are existing realXtend components so with the reX EC <-> xml3d mapping we have that’s about how they look. http://doc.meshmoon.com/doxygen/component_base.html is the list of current in native Tundra is someone’s curious to check those or others out.


> Which ontology is used for the category of a POI? How to handle POIs referring to multiple categories? And what about tags? (All with regard to multi-lingual content)
> What entities are referred by UUIDs through source.id and last_update.responsible?
> I would really appreciate to get some more informations about the open questions.
> Best regards,
> Stefan
> 
> -- 
> ********************************************************
> Stefan Lemme
> 
> DFKI GmbH
> Agenten und Simulierte Realität
> Campus, Geb. D 3 4, Raum 0.75
> 66123 Saarbrücken
> 
> Tel.: +49 (0) 681 / 85775 – 5391
> Fax: +49 (0) 681 / 85775 – 2235
> http://www.dfki.de/web
> ********************************************************
> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
> Trippstadter Straße 122
> D-67663 Kaiserslautern, Germany
> 
> Geschaeftsführung:
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
> Dr. Walter Olthoff
> Vorsitzender des Aufsichtsrats:
> Prof. Dr. h.c. Hans A. Aukes
> Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
> USt-Id.Nr.: DE 148646973
> Steuernummer:  19/673/0060/
> ********************************************************
> 
> 
> 
> 
> 
> ********************************************************
> Stefan Lemme
> 
> DFKI GmbH 
> Agents and Simulated Reality 
> Campus, Build. D 3 4, room 0.75
> D-66123 Saarbruecken 
> Germany
> 
> Phone: +49 (0) 681 / 85775 – 5391
> Fax:      +49 (0) 681 / 85775 – 2235 
> http://www.dfki.de/web 
> ******************************************************** 
> German Research Center for Artificial Intelligence 
> Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH 
> Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany 
> 
> Management Board: 
> Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Chairman) 
> Dr. Walter Olthoff 
> 
> Chairman of the Supervisory Board: 
> Prof. Dr. h.c. Hans A. Aukes 
> 
> Amtsgericht Kaiserslautern, HRB 2313 
> ********************************************************
> _______________________________________________
> Fiware-miwi mailing list
> Fiware-miwi at lists.fi-ware.eu
> https://lists.fi-ware.eu/listinfo/fiware-miwi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/fiware-miwi/attachments/20140221/66ac8173/attachment.html>