- From: Seiler, Karl <karl.seiler@navteq.com>
- Date: Thu, 17 Mar 2011 08:22:29 -0500
- To: "cperey@perey.com" <cperey@perey.com>
- CC: "roBman@mob-labs.com" <roBman@mob-labs.com>, "public-poiwg@w3.org" <public-poiwg@w3.org>, "discussion@arstandards.org" <discussion@arstandards.org>
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.
Received on Thursday, 17 March 2011 13:23:45 UTC