RE: ISSUE-44: How to represent natural relationships, e.g. "near"

We have defined a POI as having a location
We have defined a location as having one or more descriptors
x/y/z
civil address
poly
bounding region
etc

x/y/z’s may or may not exist, or may not have been rendered/geocoded yet from civil addresses.
Civil addressing runs the gamut from very specific (Germany) to less so (rural Brazil).

Let’s not concern ourselves with modeling uncertainty (all geocoding services are providing this information today) so much as ensuring the specification can encompass a description of a location that is not resolved to a precise x/y. These locations are useful, process-able, and navigable.

So a valid POI can be:
                Karl’s Grill
                Backyard of 425 w Randolph, Lincoln Park, Chicago

_______________________________
Karl Seiler
Director Location Technology & Services
NAVTEQ - Chicago
(T)  +312-894-7231
(M) +312-375-5932
www.navteq.com<http://www.navteq.com/>

From: Alex Hill [mailto:ahill@gatech.edu]
Sent: Wednesday, August 03, 2011 10:08 AM
To: Raj Singh
Cc: Thomas Wrobel; Seiler, Karl; roBman@mob-labs.com; public-poiwg@w3.org
Subject: Re: ISSUE-44: How to represent natural relationships, e.g. "near"



I think you're basically correct -- hardware has inherent uncertainty and other methods of determining location don't -- but I don't see that as the main issue. I see two main problems.
1) Hardware uncertainty is easy to know, but a pain to carry around everywhere the data goes. The accuracy of our hardware is so good that users will rarely want or need to see it.

I would caution against assuming that users (and the applications developed for them) will not ask for uncertainty.
What we envision people doing with POI data may seem quaint a few years from now.


2) User uncertainty is hard to know and model. This is an area of broad intellectual interest to anyone working with contributed or crowd-sourced information, but not one I'm ready to take on as part of the POI WG.

So those two points make me feel like we should recognize that this is a battle we are not prepared to fight.

---
Raj
The OGC: Making location count...
http://www.opengeospatial.org/contact



On Jul 29, at 12:48 PM, Thomas Wrobel wrote:


Just as an open question; what exactly are the problems with modelling
uncertainty? (in this context, I mean accuracy of specified numbers
+/- rather then reliability or trustworthiness).

I always thought whatever the source of the POIs there would be a
known uncertainty associated with that which could just be copied in.
(ie. If it came from a phone, then it should know the gps accuracy. If
it came from lazer-measurements done by surveyors, they should know
the tolerance of their equipment).

Of course, casual users wont be putting in uncertainty
themselves...but then, they are likely to be using a visual editor of
some sort that could add it for them.

At least, thats how I pictured it working.
I guess I'm overlooking more complex case's however.

-Thomas

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



On 27 July 2011 14:20, Seiler, Karl <karl.seiler@navteq.com> wrote:
I say fine. If we can represent via links or associations on top of the model, then good. Relative location are natural, real, common and unavoidable to me. Let's extend civil addresses to include such descriptive aids as "2 blocks down from the yellow house."

_______________________________
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 Rob Manson
Sent: Tuesday, July 26, 2011 8:52 PM
To: public-poiwg@w3.org
Subject: Re: ISSUE-44: How to represent natural relationships, e.g. "near"

Sorry to keep ranting...but I really don't understand how a
linguistically ill defined term like "near" can have anything to do with
a simple and elegant definition of a POI.  If people choose to build
linked relationships like this on top of a simple and elegant POI
definition then good luck to them.  They will obviously have to deal
with all of the issues of context and how you derive mean and algorithms
from this.  But it is not an essential part of a simple and elegant POI
definition.

Let's enable a robust linking model that allows us to relate simple and
elegant POI definitions to metadata, other geometries, other digital
content including images, 3d models, audio etc. and relationships to
other POIs including parent, contains, near, similar flavour, ideology,
whatever.  But at the moment this feels like we are slowly trying to
drag everything including the kitchen sink into the data model.


roBman


On Mon, 2011-07-25 at 14:39 -0600, Carl Reed wrote:
Perhaps another approach - and one that does not require complex additions
to the spec - other than some measure of accuracy/uncertainty.

Back when I architected GIS software systems, we had a proximity function
that let users ask simple questions such as find me all of the Starbucks
within one mile of my house (or one kilometer for most of the world). Our
software supported simple distance (circle by center point search) as well
as network distance. The user could also ask questions such as find me all
houses in a city that are not within a specified distance of a fire hydrant.
These are all PoIs :-) In all cases, we had to consider accuracy of the data
to fine-tune the answer. These operations were incredibly fast - even in the
old non-massive data center days. In this way, one avoids dealing with the
"near" concept!  Also, there is no "near" specified in the 9 spatial query
types as defined in SQL-MM, OGC Simple Features and other international
standards.

Cheers

Carl

----- Original Message -----
From: "Raj Singh" <rsingh@opengeospatial.org>
To: "Thomas Wrobel" <darkflame@gmail.com>
Cc: "Seiler, Karl" <karl.seiler@navteq.com>; "Carl Reed"
<creed@opengeospatial.org>; "Points of Interest Working Group WG"
<member-poiwg@w3.org>
Sent: Monday, July 25, 2011 4:51 AM
Subject: Re: ISSUE-44: How to represent natural relationships, e.g. "near"


Changing the subject. Issue 44 is about near.
I agree there are lot's of problems with the near relationship. It can't be
consistent across users. And if you try to get more specific, you're really
modeling uncertainty, which is so hard to do (outside of scientific
communities who are used to doing that) I doubt anyone would bother.

Near is certainly a last resort, least-common-denominator relationship.
Whether it's useful to have at all is the question. I'd say it's not a
relationship we should *recommend* specifying except when the location is
undetermined.

---
Raj
The OGC: Making location count...
http://www.opengeospatial.org/contact



On Jul 24, at 2:54 PM, Thomas Wrobel wrote:

On 23 July 2011 15:46, Raj Singh <rsingh@opengeospatial.org> wrote:
I think he key point is that "near" relationships would rarely be
translated into coordinates. I see a few use cases:
1) database query convenience--select all near POIs instead of computing
distances

But who decides whats "near" and how to get correlation between the
people entering the data (who might think 15m-ish is "near") and the
database designers (who might think 200m-ish is "near"). With a lot of
data coming from different sources, and the search engine maybe being
a 3rd party I'm not sure how a "near" definition would work.

Then, of course, theres the end users idea of what "near" mean which
might be different again.

2) POIs with undetermined locations could be tagged as near a known POI.
this could be very convenient in a place like India where a monument
would have a known location, but shopping stalls would only be marked as
near. (that reminds me--some people/cultures don't want to be exactly
geo-positioned)

Certainly in either case we need to deal with "fuzzy" or imprecise
co-ordinates, but isn't this better dealt with by a known margin of
error specified?
So something like "within 50m+/- of this location"...that seems a lot
more useful to me.

3) historical POIs: the historical record sometimes only has information
that something was near something else. Once again the location would be
undetermined, maybe for decades, until more evidence was gathered.

I understand the problem here...when the only source data you have
itself just specifys near.
Even here though, Id guess different cultures and sources have
different ideas about nearby and based on context estimates have to be
made.
Not sure you can get a 1-size-fits-all "near" spec, or if you did, you
could never compare it to other POIs from different sources without
having the source and its ideas of "near" (or our best guess)
specified somewhere.



---
Raj


On Jul 23, 2011, at 6:01 AM, Thomas Wrobel <darkflame@gmail.com> wrote:

The second example seems pretty good.

Iḿ not keen on ¨next too¨ style definitions, as while they are easier
to enter, they expected a lot of work to be done by the end clients or
servers doing on the fly conversions to usable co-ordinates.
I think, thus, while those sorts of definitions might be used to
create POI in some cases, whatever software is being used to make or
place the POIs should convert it to more fixed/precise definition to
be used by the official standard.
The other point is its easier to work out ¨nearby¨ from proper
co-ordinates (relative or not) then it is to work out co-ordinates
from ¨nearby¨.
Even converting a fixed street address to co-ordinates means someone
has to pay for a server database of references and clients need to
query it. This could quickly multiply for ¨show me things near¨ style
querys.

[/2 cents]

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



On 22 July 2011 15:01, Seiler, Karl <karl.seiler@navteq.com> wrote:
From a navigation perspective we see POI locations that now run a gamut
from:
That restaurant is in this hamlet
The taxi stand is near the intersection of Hollywood and Vine
The shop is at this interpolated location based on an address
The main entrance to the park is at this x/y/z
...to, right hand side door to the door optometrist if at this high
fidelity x/y/z

For other purposes such as representations we see POI locations that
now run a gamut from:
The center of Illinois is x/y
The theater district is bounded by this geo-fence
The center point of the building this POI is in is at x/y
The building footprint of the airport is this polygon
The building wireframe extrusion is ...
The 3d model for the building is...

_______________________________
Karl Seiler
Director Location Technology & Services
NAVTEQ - Chicago
(T)  +312-894-7231
(M) +312-375-5932
www.navteq.com


-----Original Message-----
From: Carl Reed [mailto:creed@opengeospatial.org]
Sent: Thursday, July 21, 2011 9:46 PM
To: Thomas Wrobel; Seiler, Karl
Cc: Points of Interest Working Group WG
Subject: Re: ISSUE-43: Do we want polygons to have complex topology
with holes, etc

Thomas -

If we do decide to define polygon as part of the PoI spec, I might
suggest
using the polygon elements as defined in the ISO/OGC 19107 Spatial
Schema
standard. 19107 provides the abstract model for geometry as used in
many
other standards such as OGC Simple Features, GeoJSON, GeoRSS, and GML.

Regards

Carl

----- Original Message -----
From: "Thomas Wrobel" <darkflame@gmail.com>
To: "Seiler, Karl" <karl.seiler@navteq.com>
Cc: "Points of Interest Working Group WG" <member-poiwg@w3.org>
Sent: Thursday, July 21, 2011 1:04 PM
Subject: Re: ISSUE-43: Do we want polygons to have complex topology
with
holes, etc


As long as the points are specified relative to a achor/¨main¨ point I
dont think having holes or islands is any extra effort.
I believe most vector specifications simply use
clockwise/anticlockwise point placement to specify inside/outside
regions.

I think region-definition is most useful for naming/precise searches.
(¨what POIs are within the park?¨). However, this might be best to
leave for later as you quickly get into the issue of (¨why not specify
a 3d volume? - am I inside that building or not?¨).
I dont think theres any logical sense to have 2d areas and not 3d. So
maybe for the first draft we should stick to the core ¨point¨ of the
POI.

Remember, of course, specifying an area of a POI is completely
different to attaching a 3d model to a POI. (or a 2d polygon for that
mater). One is a question of define a region, he other is merely an
association of data with that region.

-Thomas

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



On 21 July 2011 19:44, Seiler, Karl <karl.seiler@navteq.com> wrote:
What is the purpose of a polygon for a POI?
It can let someone know when they are there ("inside the park").
It can enable display of a footprint other than a pushpin.

I feel the value of representation for islands is rendering.

_______________________________
Karl Seiler
Director Location Technology & Services
NAVTEQ - Chicago
(T) +312-894-7231
(M) +312-375-5932
www.navteq.com


-----Original Message-----
From: member-poiwg-request@w3.org [mailto:member-poiwg-request@w3.org]
On
Behalf Of Points of Interest Working Group Issue Tracker
Sent: Thursday, July 21, 2011 9:26 AM
To: member-poiwg@w3.org
Subject: ISSUE-43: Do we want polygons to have complex topology with
holes, etc


ISSUE-43: Do we want polygons to have complex topology with holes, etc

http://www.w3.org/2010/POI/track/issues/43


Raised by:
On product:







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.




Alex Hill Ph.D.
Postdoctoral Fellow
Augmented Environments Laboratory
Georgia Institute of Technology
http://www.augmentedenvironments.org/lab




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.