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

Received on Friday, 29 July 2011 17:00:50 UTC