W3C home > Mailing lists > Public > public-poiwg@w3.org > October 2010

Re: POI data model

From: Thomas Wrobel <darkflame@gmail.com>
Date: Thu, 28 Oct 2010 22:01:06 +0200
Message-ID: <AANLkTinUF_A34WY_4Bj4q5wOZb4aQO-vMK_U4+kLeh4O@mail.gmail.com>
To: Jens de Smit <jens.desmit@surfnet.nl>
Cc: "public-poiwg@w3.org" <public-poiwg@w3.org>
-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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:26 UTC