RE: WG Objectives - A Personal Take

I like the anchor idea since in my experience the description of where something is varies greatly from region to region. 

For example:
- UK and Germany addresses are very specific and accurate
- US address is an a reasonable interpolation, usually augmented by an entrance x/y for large sites (malls, airport, hospitals, etc.)
- newly mapped countries usually x/y is the only reliable data
- offsets from landmarks is commonly the best descriptor, sometimes is official, and poorly supported by systems (200m from the big blue store)
- intersections are common (exit 121 off N I95)

Location hashed IDs is good for machines, but hard on people, and their persistence suffers from the issues of the restaurant that moves to the other side of town (same ID, new location) and the location that was interpolated from an address, that the owner nudges along the street to get it in front of the door (same place, now more accurate anchor).

Centroid aids in display, but not in getting there. The larger (and usually the more important) the place the more value there is in having both a center point for display and a "routing point" for navigation. It is the difference in getting you to the block of land on which the hospital resides versus getting you the door of the emergency room.

I strongly recommend we ensure we can identify the location of the store or office INSIDE the larger building. All the mapping stakeholders are working on capturing the "inside" data and it needs a shared representation.

For tying heads-up building-to-POI linkage the chain of links is usually as follows:
- 360 street image
- aligned to building footprints / with extrusions
- associated to a 2D building footprint carto feature
- associated to POIs in that area, streets, building

To make it work buildings need polygonal feature anchors and places need point anchors associated to the buildings. Representing these simple associations is a key topic for standardization.


_______________________________
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: Thursday, October 28, 2010 7:47 AM
To: public-poiwg@w3.org
Subject: Re: WG Objectives - A Personal Take

On 27/10/2010 20:09, Raj Singh wrote:
> I made a page for the data model discussion:
> http://www.w3.org/2010/POI/wiki/Data_Model


Hello all,

Thanks Raj for writing this down, this gives us something to start a
discussion from. It seems you based your list primarily on Marco's
"smallest subset if information which can describe a POI" which in turn
was based on Gary's contributions. However, one thing Marco also
mentioned as being important was "extensibility"; I'd like to agree with
that and propose to make a significant change to the data model along
the following lines:

Replace "centroid" by a more flexible "anchor" (terminology subject to
discussion) property which describes where in the world the POI belongs.
This anchor property should have an attribute/subtype that specifies how
its data should be interpreted. A lat/lon/alt in WGS84 type anchor seems
to be a very obvious anchor type to define, but the following anchor
types come to mind as well:

- x,y locations on a 2D grid/ x,y,z locations on a 3D grid
Use case: situations where lat/lon/alt are impractical, such as in
buildings where dimensions are usually measured in meters. Much easier
and faster authoring

- fiducial markers or images
Use case: Augmented Reality experiences obviously, but could also be
applied to virtual worlds

- buildings
Use case: again, easier authoring than looking up lat/lon coordinates
for everything you want to describe. Also, it conveys a string
connection between the POI and the real-world entity that is being
described. This allows for smarter and nicer user interfaces; for
example see
http://www.perey.com/ARStandards/Nokia_A_Web_Services_Platform.pdf by
Nokia's Petros Belimpasakis et al for some functional AR examples of
tying POIs and buildings together, but the same usability holds for maps
and virtual worlds.

- dynamic entities
Use case: wouldn't it be neat to describe a car or person as POI? As
computer vision improves, computers can track and recognize more and
more of the world around us. The AR use case is again obvious, but what
if you could dsignate your favourite football player as a POI? Apply
some CSS-like "outer-glow: 3pt yellow;" effect to your POI, link it to
the WebTV stream you're watching and you'll never lose track of him again.


So the last example is a bit futuristic and probably won't be part of
the first spec but I hope it conveys why I think having a flexible (and
extensible) "anchor" property would be better than hardcoding a centroid
for each point. All the other properties that have been written down
(except perhaps address) are useful for any of these use cases which is
why I would really like this flexibility in the spec.

Looking forward to your opinions!


Best regards,

Jens

Also, this list is not exhaustive and I welcome other suggestions as well.



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, 28 October 2010 13:28:05 UTC