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

Received on Thursday, 16 June 2011 15:29:32 UTC