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

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
>

Received on Thursday, 17 March 2011 07:55:46 UTC