Re: POI data model

-1 to a and b.

I agree with the concerns about data coming from alternate sources.
I just want to say that it is hard for us to move too much farther before we start looking closely at existing standards.
For instance, Carl has mentioned before that we should take a close look at CityGML.
If I am not mistaken, they are using option (c) to relate windows to rooms to buildings to areas, etc.

On Oct 28, 2010, at 4:01 PM, Thomas Wrobel wrote:

> -1 to a.
> 
> Possibly both b and c should be possible? Perhaps a bit like how you can
> specify an ID tag in html, it could be an optional way to identify an
> element which could be used elsewhere.
> While I can see the power of a nesting structure, I'm not sure we
> would want to rule out relative linking outside of a nest as well.
> 
> One restriction of only having nesting, is that all the data would
> need to come from the same source. A person couldn't submit data
> relative to a building without being in the same document (whatever
> that is) as the building.
> Working by ID, however, would let a complete independent entity
> specify data relative to anything else.
> 
> 
> On 28 October 2010 20:25, Jens de Smit <jens.desmit@surfnet.nl> wrote:
>> On 28/10/2010 19:32, Thomas Wrobel wrote:
>>> Just putting it "out there"; but if you could specify one anchor
>>> relative to another surely this would kill
>>> a few birds with one stone?
>>> (so you have a base pivot/location for the building, and then other
>>> things relative to that).
>>> 
>>> You could then even (at some point) specify co-ordinates relative to a
>>> marker/image or other reference.
>> 
>> Having relative positioning will be as good as _crucial_ for efficiently
>> defining more complex structures, like descibing superstructures and
>> substructures (such as rooms in a building) and so on.
>> 
>> Now, do we want to do this relative positioning
>> 
>> a. standalone (e.g. every POI carries a lat/lon/alt and an offset)
>> b. by reference (this POI's position is relative to that POIs position)
>> c. through nesting
>> d. some or all of the above
>> 
>> ?
>> 
>> I think a. would yield us too little flexibility and leads to heavy data
>> duplication, but can be the easiest method for simple cases. Option b.
>> could be useful but requires a way to uniquely identify POI's in a set.
>> Option c. will lead to complicated documents (arbitrary depth nesting)
>> but allows a very intuitive way of building up a structure (golly,
>> almost like an HTML document).
>> 
>> So I'd say option d.
>> 
>> Regards,
>> 
>> Jens
>> 
>> 
> 

Alex Hill Ph.D.
Postdoctoral Fellow
Augmented Environments Laboratory
Georgia Institute of Technology
http://www.augmentedenvironments.org/lab