Re: [AR Standards Discussion] A Uniform Resource Identifier for Geographic Locations ('geo' URI)

Karl -

In terms of civic addresses, we might want to consider the IETF Location
Object. There is a civic and a geodetic encoding (GML). The civic encoding
is already implemented in CISCO routers. The civic encoding has also been
harmonized with the geo data model and addressing model work in NENA. This
work is part of the Next Generation 911 NENA architecture, standards, and
SOP activities.

I can provide URLs if the group is interested.

Regards

Carl
> If I am interpreting this right, we are discussing using a geo URI as the
> unique and persistent ID of the Place's location primitive. But we still
> need the other resolved attribution in the location primitive such as
> civil address, associations to other spatial constructs such as this is
> inside the building, etc.
>
> Also if (when) the business at a Place moves that Places gets a new geo
> URI, buts it's Place ID does not change.
>
> Right?
>
> Sent from my iPad
>
> Karl Seiler
> Director, Location Technology and Services
> Navteq
> O: 312-894-7231
> C: 312-375-5932
>
> On Mar 17, 2011, at 2:58 AM, "Christine Perey" <cperey@perey.com> wrote:
>
>> Hello,
>>
>> By way of this message I am bringing the public-poiwg mailing list
>> (which Rob originally copied--brilliant move IMHO--but which was
>> "truncated" after one or two messages) back into the thread.
>>
>> For those on the public POI WG mailing list who are interested, you have
>> missed a few posts. Some of the posts are preserved in this message.
>>
>> The entire thread which was on the AR discussion mailing list is
>> archived [1]
>>
>> If those on public POI WG mailing list wish to post/contribute to the AR
>> discussion mailing list (this or any other thread) or just to lurk on
>> this list, please subscribe yourself [2]
>>
>> Regards,
>>
>> Christine
>>
>> Spime Wrangler
>>
>> cperey@perey.com
>> mobile +41 79 436 6869
>> VoIP +1 (617) 848-8159
>> Skype Christine_Perey
>>
>> [1] http://arstandards.org/pipermail/discussion/
>> [2] http://arstandards.org/mailman/listinfo/discussion
>>
>> On 3/17/11 4:33 AM, Rob Manson wrote:
>>> Hey Carl,
>>>
>>> absolutely will engage directly with the authors.
>>>
>>> Probably worth having a good AR specific discussion first to see if we
>>> can provide some consolidated feedback though 8)
>>>
>>>
>>> roBman
>>>
>>>
>>> On Wed, 2011-03-16 at 20:14 -0400, creed@opengeospatial.org wrote:
>>>> If there are questions regarding the internet RFC for the geo uri, I
>>>> would
>>>> suggest contacting the authors directly. Their emails are in the
>>>> document.
>>>>
>>>> Regards
>>>>
>>>> Carl
>>>>
>>>>> That's kinda the whole issue I see with geo:URIs.
>>>>>
>>>>> My second point was that the fragment could be the thing that binds
>>>>> it to
>>>>> a server/request if it were a standard URI.
>>>>>
>>>>> G'night Thomas 8)
>>>>>
>>>>>
>>>>> roBman
>>>>>
>>>>>
>>>>> On 17/03/2011, at 10:28 AM, Thomas Wrobel<darkflame@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> This is of the top of my head, as its getting a bit late here and
>>>>>> I'm
>>>>>> doing far too many things at once...
>>>>>>
>>>>>> But what would the fragment actually mean for the client?
>>>>>>
>>>>>> "  geo:-33.874813;151.21840#robman"
>>>>>>
>>>>>> Unlike a url which points to a server which points to a page where
>>>>>> the
>>>>>> fragment refers to a specific state  (or location) within the page -
>>>>>> the geo location points to a point on the earth. There is no
>>>>>> datasource to look for that string within. How does the string
>>>>>> fragment then narrow down that specification of location? What does
>>>>>> the client do when it gets the string "robman"?
>>>>>>
>>>>>> Theres probably something I'm missing here. I can certainly see a
>>>>>> use
>>>>>> for narrowing down the location - but I think it would need to
>>>>>> specify
>>>>>> an image or some other physically identifying property the ar client
>>>>>> could then use to pinpoint what rather then a simple string.
>>>>>>
>>>>>> I'll re-read this all again tomorrow and probably have
>>>>>> more/different
>>>>>> comments ;)
>>>>>>
>>>>>> -Thomas
>>>>>>
>>>>>>
>>>>>> ~~~~~~
>>>>>> Reviews of anything, by anyone;
>>>>>> www.rateoholic.co.uk
>>>>>> Please try out my new site and give feedback :)
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 16 March 2011 23:49, Rob Manson<roBman@mob-labs.com>  wrote:
>>>>>>> Hey Thomas,
>>>>>>>
>>>>>>> yeah those are good points.
>>>>>>>
>>>>>>> After absorbing it for a little while I think orientation could be
>>>>>>> externalised/abstracted (see my thoughts below) so the core geo:URI
>>>>>>> just
>>>>>>> becomes the reference point of origin.
>>>>>>>
>>>>>>> As for the uncertainty...I agree and I don't think that's the only
>>>>>>> ambiguity about it that would be good to resolve.
>>>>>>>
>>>>>>> Perhaps I'm missing the point...so I'd love to hear other people's
>>>>>>> constructive criticism of how I think we could extend it 8)
>>>>>>>
>>>>>>> So, from my reading it seems that this is really dependent upon the
>>>>>>> browser/client having a pre-defined model for handling the local
>>>>>>> presentation of geo:URIs.  This is very ambiguous.  I can see why
>>>>>>> this
>>>>>>> may be the case...but I wonder if there was any thought or
>>>>>>> discussion
>>>>>>> during draft the rfc around an optional broader handling as
>>>>>>> traditional
>>>>>>> urls do - e.g. including an optional hostname or even url
>>>>>>>
>>>>>>> Also, adding/using fragments identifiers[1] like traditional
>>>>>>> urls do to refer to specific objects or parts within that geo:URI
>>>>>>> could
>>>>>>> really extend this in useful ways and maps to the existing HTTP
>>>>>>> model.
>>>>>>>
>>>>>>> e.g.
>>>>>>>
>>>>>>>        geo:-33.874813;151.21840#robman
>>>>>>>        or
>>>>>>>        geo:-33.874813;151.21840#$unique_local_id
>>>>>>>
>>>>>>> I can see how this would be very useful and relevant to the POI-WG
>>>>>>> and
>>>>>>> AR in general.  In fact if the fragment identifier were able to
>>>>>>> include
>>>>>>> a url (possibly an evil tunnelling extension 8)) then this could
>>>>>>> kill
>>>>>>> both the points I've raised with one stone.
>>>>>>>
>>>>>>> e.g.
>>>>>>>
>>>>>>>        geo:-33.874813;151.21840#http://$host/$path<- possibly evil
>>>>>>> 8)
>>>>>>>
>>>>>>>
>>>>>>> This would allow multiple objects/things to share the same location
>>>>>>> point of origin...and then also to support structured queries and
>>>>>>> filters etc.  I'm really just thinking of this in terms of the ID
>>>>>>> primitive [2] and this would work well in existing format like KML
>>>>>>> etc.
>>>>>>> too.
>>>>>>>
>>>>>>>
>>>>>>> roBman
>>>>>>>
>>>>>>> [1] http://en.wikipedia.org/wiki/Fragment_identifier
>>>>>>> [2]
>>>>>>> http://lists.w3.org/Archives/Public/public-poiwg/2011Feb/0037.html
>>>>>>>
>>>>>>> On Wed, 2011-03-16 at 21:40 +0100, Thomas Wrobel wrote:
>>>>>>>> I gave it a very quick read over and it does indeed have much of
>>>>>>>> that's needed (including a default co-ordinate system while being
>>>>>>>> able
>>>>>>>> to specify others, as well as a accuracy spec).
>>>>>>>>
>>>>>>>> However, I think it lacks any orientation specification which we
>>>>>>>> would
>>>>>>>> need. So we could adopt the key/value pairs used here, but would
>>>>>>>> need
>>>>>>>> to add additional ones as well. We could of course use the
>>>>>>>> standard as
>>>>>>>> is, but include the additional data as separate fields - but that
>>>>>>>> would lead to more complex parsing.
>>>>>>>>
>>>>>>>> I'm also not completely sure I like how circle and sphere regions
>>>>>>>> seem
>>>>>>>> to be defined just by a "uncertain point"...seems like data stored
>>>>>>>> in
>>>>>>>> that way could be ambiguously and vulnerable to be interpreted in
>>>>>>>> different ways.
>>>>>>>> [/my 0.0143918euros]
>>>>>>>>
>>>>>>>> I agree however, this should certainly be discussed and added to
>>>>>>>> the
>>>>>>>> existing standards list.
>>>>>>>>
>>>>>>>> -Thomas
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ~~~~~~
>>>>>>>> Reviews of anything, by anyone;
>>>>>>>> www.rateoholic.co.uk
>>>>>>>> Please try out my new site and give feedback :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 16 March 2011 01:40, Rob Manson<roBman@mob-labs.com>  wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I know there has been a lot of mention of WGS-84[1] in the
>>>>>>>>> public-poiwg
>>>>>>>>> discussions but I couldn't seem to find[2][3] any mention of or
>>>>>>>>> reference to rfc5870 - A Uniform Resource Identifier for
>>>>>>>>> Geographic
>>>>>>>>> Locations ('geo' URI)[4].
>>>>>>>>>
>>>>>>>>> This seems like a significant thing to be overlooked and
>>>>>>>>> something it
>>>>>>>>> seems like we should be utilising and benefiting from...if indeed
>>>>>>>>> it
>>>>>>>>> does look like becoming a usable standard (obviously only a
>>>>>>>>> draft/proposed standard at the moment).
>>>>>>>>>
>>>>>>>>> So...what do people think of rfc5870?
>>>>>>>>>
>>>>>>>>> Christine, this is definitely something we should add to the
>>>>>>>>> ARStandards.org "existing standards" page under the "Location
>>>>>>>>> Standards"
>>>>>>>>> section.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> roBman
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>> http://www.w3.org/Search/Mail/Public/search?type-index=public-poiwg&index-type=t&keywords=WGS-84&search=Search
>>>>>>>>> [2]
>>>>>>>>> http://www.w3.org/Search/Mail/Public/search?type-index=public-poiwg&index-type=t&keywords=5870&search=Search
>>>>>>>>> [3]
>>>>>>>>> http://www.w3.org/2010/POI/wiki/index.php?title=Special%3ASearch&search=5870&go=Go
>>>>>>>>> [4] http://tools.ietf.org/html/rfc5870
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Discussion mailing list
>>>>>>>>> Discussion@arstandards.org
>>>>>>>>> http://arstandards.org/mailman/listinfo/discussion
>>>>>>>>>
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Discussion mailing list
>>>>>>> Discussion@arstandards.org
>>>>>>> http://arstandards.org/mailman/listinfo/discussion
>>>>>>>
>>>>> _______________________________________________
>>>>> Discussion mailing list
>>>>> Discussion@arstandards.org
>>>>> http://arstandards.org/mailman/listinfo/discussion
>>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Discussion mailing list
>>> Discussion@arstandards.org
>>> http://arstandards.org/mailman/listinfo/discussion
>>>
>>
>
>
> 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.
> _______________________________________________
> Discussion mailing list
> Discussion@arstandards.org
> http://arstandards.org/mailman/listinfo/discussion
>

Received on Monday, 21 March 2011 16:02:06 UTC