Re: POI data model

-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
>
>

Received on Thursday, 28 October 2010 20:01:39 UTC