Re: ISSUE-31 relative points?

Indeed.
For any positioning use its handy really.

"The emergency lifeboats are located x/y/z meters relative to the
centre of this type of ferry ship"

AR is really just a way to display, but this would be just as useful
on 2D maps/plans, or even purely for computational use. (that is,
requesting POIs that meet certain requirements without any specific
desire to display them in context).


On 15 June 2011 23:06, Seiler, Karl <karl.seiler@navteq.com> wrote:
> No. I think the use cases are more general �than AR.
>
> Sent from my iPad
>
> Karl Seiler
> Director, Location Technology and Services
> Navteq
> O: 312-894-7231
> C: 312-375-5932
>
> On Jun 15, 2011, at 1:50 PM, "Raj Singh" <rsingh@opengeospatial.org> wrote:
>
>> And do we agree that this would be part of the AR extension?
>> http://www.w3.org/2010/POI/wiki/Extensions#Augmented_Reality
>>
>> ---
>> Raj
>> The OGC: Making ___location count...
>> http://www.opengeospatial.org/contact
>>
>>
>> On Jun 15, at 1:37 PM, Seiler, Karl wrote:
>>
>>> Very nice, relative offsets either to the current POI or from another POI via its ID/URI
>>>
>>> _______________________________
>>> Karl Seiler
>>> Director Location Technology & Services
>>> NAVTEQ - Chicago
>>> (T) �+312-894-7231
>>> (M) +312-375-5932
>>> www.navteq.com
>>>
>>>
>>> -----Original Message-----
>>> From: Thomas Wrobel [mailto:darkflame@gmail.com]
>>> Sent: Wednesday, June 15, 2011 11:52 AM
>>> To: Seiler, Karl
>>> Cc: Jens de Smit; Alex Hill; Public POI @ W3C
>>> Subject: Re: ISSUE-31 relative points?
>>>
>>>> I still feel relative offsets from a lat/lon anchor point will have value and adds flexibility to the spec.
>>>
>>> +1
>>>
>>> I would add specifically though, the ability to reference an anchor
>>> point of another POI (rather then just itself) adds hugely to the
>>> flexibility.
>>> (we should also bare in mind this should be possible by reference to
>>> the other POI ID - pure markup solutions would prevent something from
>>> one source being positioned relative to something from a different
>>> source. It would also, potentially, lead to hugely bigger packages
>>> then is necessary delivered to clients. If you only want to see object
>>> X �and its positioned next to object A ....do you really need a
>>> package containing everything else positioned relative to A as well?
>>> The client only needs X/As information to display X at the correct
>>> ___location - nothing else)
>>>
>>>>
>>>> _______________________________
>>>> Karl Seiler
>>>> Director Location Technology & Services
>>>> NAVTEQ - Chicago
>>>> (T) �+312-894-7231
>>>> (M) +312-375-5932
>>>> www.navteq.com
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: public-poiwg-request@w3.org [mailto:public-poiwg-request@w3.org] On Behalf Of Jens de Smit
>>>> Sent: Wednesday, June 15, 2011 2:58 AM
>>>> To: Alex Hill
>>>> Cc: Public POI @ W3C
>>>> Subject: Re: ISSUE-31 relative points?
>>>>
>>>> On Fri, Jun 10, 2011 at 6:17 PM, Alex Hill <ahill@gatech.edu> wrote:
>>>>> I think we need to have a discussion about what "relative" positioning
>>>>> means.
>>>>> One example I have seen is in CityGML where building geometry is described
>>>>> in meters relative to an anchor point.
>>>>> However, I'm not sure what such a system for describing polygons, etc. would
>>>>> buy us in the POI spec.
>>>>> I tend to think that we intended relative positioning to facilitate things
>>>>> like the following:
>>>>> <pois>
>>>>> <poi id="frame_of_reference">
>>>>> <___location>
>>>>> <!-- some reference to a moving vehicle a building or any arbitrary frame of
>>>>> reference (not just coords but orientation would be nice) -->
>>>>> </___location>
>>>>> </poi>
>>>>> <poi id="alex">
>>>>> <___location>
>>>>> <!-- some value calculated within that frame of reference (WiFi tracking,
>>>>> etc.) �in something not WGS84 -->
>>>>> <point srsName="urn:ogc:def:crs:EPSG:6.6:4979" srsDimensions="3">
>>>>> <pos>10023.123 1234.123 666.66</pos> <!-- lets say this is mm for now -->
>>>>> </point>
>>>>> </___location>
>>>>> <relation type="relative-to" id="#frame_of_reference"/>
>>>>> </poi>
>>>>> </pois>
>>>>> Is that appropriate, or do we want something where each individual
>>>>> georeference can specify a relative frame of reference?
>>>>> <pois>
>>>>> <poi id="frame_of_reference">
>>>>> <___location>
>>>>> <point relative_to="#frame_of_reference"
>>>>> srsName="urn:ogc:def:crs:EPSG:6.6:4979" srsDimensions="3">
>>>>> <pos>10023.123 1234.123 666.66</pos> <!-- lets say this is mm for now -->
>>>>> </point>
>>>>> <!-- some reference to a moving vehicle a building or any arbitrary frame of
>>>>> reference (not just coords but oriented would be nice) -->
>>>>> </___location>
>>>>> </poi>
>>>>> <poi id="alex">
>>>>> <___location>
>>>>> <point relative_to="#frame_of_reference"
>>>>> srsName="urn:ogc:def:crs:EPSG:6.6:4979">
>>>>> </___location>
>>>>> </poi>
>>>>> </pois>
>>>>> Sorry if this is not "correct", but I'm more concerned about the spirit of
>>>>> this than the syntax.
>>>>> Would this be a valuable addition to the spec?
>>>>
>>>> I really think so, I've always advocated relative positions in the
>>>> spec. I would actually love to see a fully hierarchical model, where
>>>> you can
>>>>
>>>> - place POIs inside other POIs to make the relative relationship implicit
>>>> - have the applicable coordinate reference system cascade down until
>>>> explicitly changed
>>>>
>>>>> Can we think of use cases that would benefit?
>>>>
>>>> Indoor navigation/augmentation, obviously. It would be very
>>>> painstaking and error-prone to map out an entire building in WGS84
>>>> when you want to pinpoint all the coffee machines to centimeter
>>>> accuracy. Accurately pinpointing the front door once and offsetting in
>>>> millimeters from there is relatively (hah) trivial, especially with a
>>>> laser measure.
>>>>
>>>>> I suspect the AR advocates can.
>>>>> What about indoor tracking of POIs?
>>>>> What about vehicle/pedestrian entrances for the mapping crowd?
>>>>> Can we put the relative information in the data model and then let systems
>>>>> back out the actual coordinates for efficiency?
>>>>> Then if you find (don't know how yet) that an update is necessary you can
>>>>> re-calculate.
>>>>> Perhaps what you have above ends up looking like:
>>>>> <___location>
>>>>> <point>
>>>>> <pos>-72.123 34.1234 100.7</pos> <!-- the non-relative position of this
>>>>> point in WGS84 -->
>>>>> </point>
>>>>> <point relative_to="#frame_of_reference"
>>>>> srsName="urn:ogc:def:crs:EPSG:6.6:4979" srsDimensions="3">
>>>>> <pos>10023.123 1234.123 666.66</pos> <!-- lets say this is mm for now -->
>>>>> </point>
>>>>> <!-- some reference to a moving vehicle a building or any arbitrary frame of
>>>>> reference (not just coords but oriented would be nice) -->
>>>>> </___location>
>>>>
>>>> What I'd like to see is that the applications calculate and cache the
>>>> derived coordinates (if they need it, that is. For display purposes,
>>>> locations need to be converted from whatever applicable CRS to display
>>>> coordinates anyway. Why would WGS84 be easier than meters?) If this
>>>> calculation is cumbersome (mobile clients) a POI hosting service might
>>>> do the calculation on the fly and serve it with the response or host a
>>>> separate service that does relative-to-absolute mapping. The further I
>>>> get into this paragraph, the less value I see in converting everything
>>>> to WGS84...
>>>>
>>>> Jens
>>>>
>>>>
>>>>
>>>> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. �If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. �If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
>>>>
>>>
>>>
>>> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. �If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. �If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
>>
>
>
> The information contained in this communication may be CONFIDENTIAL and is intended only for the use of the recipient(s) named above. �If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. �If you have received this communication in error, please notify the sender and delete/destroy the original message and any copy of it from your computer or paper files.
>

Received on Thursday, 16 June 2011 12:24:32 UTC