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