RE: ISSUE-31 relative points?

What I am hearing from the micro-location teams is they are adding resolution to lat/lon/alt to cover micro. Not sure that makes sense for all the use cases we tend to discuss. 

_______________________________
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: Thursday, June 16, 2011 10:29 AM
To: Seiler, Karl
Cc: Raj Singh; Jens de Smit; Alex Hill; Public POI @ W3C
Subject: Re: ISSUE-31 relative points?

This is, I admit, purely a guess - but I suspect when you get down to
that level there isn't an industry standard.
Architecture wise its probably something like;

"The building is (here - gps), the door is (here - mm relative to the
gps), the door is a standard of type (door type) and the handle
location on a door of that type is (mm relative to a point on the
door?)"

Not sure we have anything that would go straight from planetary to
sub-mm without a relative point inbetween to measure against. (not
that thats a reason by itself why their shouldn't be sub-mm lat/long
possible, but I think its likely in most case's they would switch to a
smaller unit).

Again, just a guess. I worked at an architects firm very
briefly.....when I was a student....for two weeks.....so I don't think
my knowledge here counts for too much ;)


~~~~~~
Reviews of anything, by anyone;
www.rateoholic.co.uk
Please try out my new site and give feedback :)



On 16 June 2011 15:57, Seiler, Karl <karl.seiler@navteq.com> wrote:
> For me the driver is what is to be the industry standard method for the specification of micro-point locations? The life-boat, the in-building office door, the door handle, my keys....
>
> The smallest of small "where" of things and places.
>
> _______________________________
> 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: Thursday, June 16, 2011 7:24 AM
> To: Seiler, Karl
> Cc: Raj Singh; Jens de Smit; Alex Hill; Public POI @ W3C
> Subject: 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.
>>
>
>
> 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 15:33:42 UTC