- From: Rob Manson <roBman@mob-labs.com>
- Date: Mon, 25 Apr 2011 12:46:57 +1000
- To: "discussion@arstandards.org" <discussion@arstandards.org>, "public-poiwg@w3.org" <public-poiwg@w3.org>
Hi Thomas,
I think we're saying the same thing 8)
There's a mechanism to get the POI Representations onto the device or
into the app - this can be either pull (Query), push (rss/xmpp/etc.) or
a combination of the two.
Then there's the presentation of the POIs into the UI based on their
availability on the device/app. This may be "pre-cached POIs",
"downloaded POIs only" or "on the fly as they load/become available" or
some more complex calculation (e.g. only once an action has occurred or
within a time window, etc.)
Then there's the events that initiate the UI presentation in the first
place. This is often a combination of the user selecting a state (e.g.
starting an app or opening a Layer, etc.) plus the device gathering
Location data to calculate or filter which POIs to present and where.
Often people summarise this as "we load some POIs and show them to the
user"...but these extra distinctions are important.
The Query model has become the default...but the syndication model you
often evangelise definitely has advantages.
The presentation of the POIs and the data Representations we use to
convey them are really what the POI-WG is focused upon.
And the user/device events, Location data collection and
filter/calculations are really what the different apps create.
I'm definitely not proposing we define a POI Query standard at the
moment...just clarifying the distinction between a POI Query and a POI
Representation and the different meaning a Location has in those 2
different contexts.
Let me know if you don't think we're saying the same thing.
As for the double meaning of uncertainty also being used to define an
area...I agree which is why I raised it. I think overloading like this
always leads to problems.
So the types of area/radius we can meaningfully discuss here are
uncertainty (e.g. potential inaccuracy), size (e.g. 2D or 3D radius) and
search area (e.g. a 2D or 3D search boundary). And these 3 should be
kept distinct.
However there is obviously some fuzziness here too like "does the search
area just return objects with origin points inside the search boundary,
or any object with any part of their geometry inside the search
boundary?" And "how is uncertainty taken into account in this?"
But at least if these 3 elements are kept distinct then a model can
clearly define it's approach to these types of questions.
roBman
On Sun, 2011-04-24 at 12:49 +0200, Thomas Wrobel wrote:
> >"but I really just see that as a caching/distribution layer and the final
> > Representations are still displayed based on a real Query using the
> > users Location at a point in time."
>
> No, I'd have to disagree with that; queries are fundamentally pull,
> xmpp (and others) can be push based.
>
> eg. A new POI could appear in the users field of view instantly, if
> they are subscribed to that source and its just been created.
> No query was sent from the device to get it - the server sent a update
> saying it was there to anybody relevant.
>
> Now I get that you could say the server mearly says a new POI is at a
> location, and the device internally has to ""query"" itself to see if
> its in the field of view. But that's implementation stuff that should
> be left upto the client makers. (ie , they might want to give personal
> filtering options, highlighting of some content etc). Internally a app
> might use sone sort of DB and query, but that internal stufff doesn't
> have any reliance on a standard.
>
> (be it a POI standard, or a POI query standard - which are two separate things)
>
> I don't have any objections to a query standard, mind you. Merely that
> POIs will be used in many cases without any query's.
> imho, POIs should be defined first anyway, else you wont know
> potential query parameters.
>
> >"Here the uncertainty parameter is used to define the
> > radius of a GML sphere...and this to me seems like it's diluting the
> > meaning of this parameter. What do you think?"
>
> Uncertainly should not be used to define an area!
> I'm very concerned about double meanings like this, we need to be as
> specific as possible.
>
> Remember, you could also have something that is a known area but an
> imprecise centerpoint. So uncertainly and radius are very clearly
> separate things to.
>
> I see some usefulness for a client to know the rough size of a POI,
> incidentally; it would help it work out if its visible from a specific
> distance or not. (ie, don't load a coffee shops sign when your 20
> miles away, but that skyscrappers label or 3d augmentations should be
> loaded). This doesn't have to be worked out now or anything, and I am
> coming from an engine-design perspective here.
>
> -Thomas
>
> On 24 April 2011 08:44, Rob Manson <roBman@mob-labs.com> wrote:
> > Hi all,
> >
> > after quite a bit of absorbing and re-thinking of my initial
> > rant...here's a few distinctions that I'd like to raise that relate
> > directly to location based Augmented Reality.
> >
> > 1. Locations
> > 2. Queries
> > 3. Representations
> >
> > Locations
> > It seems like RFC5870[1] geo: URIs are a good solution for
> > embedding locations, in the same way that mailto:, tel: and sms:
> > URI schemes provide a good way for embedding email addresses,
> > phone numbers and SMS capable mobile phone numbers into content.
> > But I think there is a slightly confusing element within the RFC
> > that I'll describe below after the other 2 points.
> >
> > Queries
> > Requests that are sent to a specific server or local application
> > in order to extract a list of Points of Interest relative to a
> > specific Location seems to be the natural interaction that
> > drives location based Augmented Reality.
> > Layar use a getPOI request. Junaio use a pois/search? request.
> > Wikitude uses a similar but unnamed request. The list goes on.
> >
> > Representations
> > The responses to Queries about specific Location return POIs
> > that are Representations of interesting "things" that have or
> > had a relative Location at some point in time.
> >
> >
> > So, what I had attempted to map out in my earlier email was using the
> > geo: URIs as the basis for a query where the geo: part was the Location
> > content and the #fragment constrained the scope. But upon reflection I
> > don't think this does make sense. I think what confused me initially
> > was the uncertainty parameter[2]. In some ways this is very similar to
> > the radius/perimeter parameters used by Layar and Junaio, etc. as the
> > uncertainty parameter defines an area within which the location may be.
> > But it is really quite the opposite. This uncertainty area is defined
> > by how precise (or imprecise) the source of the lat/lon/alt coordinates
> > really is (e.g. the GPS). By contrast the radius/perimeter in a getPOI
> > or search/pois Query defines the area within which you want to search.
> >
> > I know this may be quite obvious...but I think it's worth discussing
> > because the example in section 7.4[3] of RFC5870 starts to blur this
> > line even further. Here the uncertainty parameter is used to define the
> > radius of a GML sphere...and this to me seems like it's diluting the
> > meaning of this parameter. What do you think?
> >
> >
> > I also think these 3 distinctions of Location, Query and Representation
> > relate really well to the "Categorization + Whether a POI must have
> > location" thread[4]. I think a POI representation by definition as a
> > Point "requires" a Location. Vinod, in your recent question about the
> > advertisements...
> >
> > "If we say that POIs always need to have location, *many of the
> > suggestions, advertisements (which don't represent a single
> > geo-tagged item but a list of geo-tagged items) can never be
> > POIs*. So, do we think and agree that such 'virtual entities'
> > representing groups of POIs are not POIs?"
> >
> > ...I think these are just Queries that return Representations that are
> > related to Locations (e.g. POIs). But the Queries are NOT the
> > POIs...just like the Map is NOT the Territory. It can be confusing
> > because the Location is embedded in both the Query and the
> > Representations...but in these 2 different contexts the Locations have
> > quite different meanings.
> >
> > Are there any other related distinctions here we should be calling out?
> >
> > NOTE: Thomas, I know the Query doesn't directly map to the sort of
> > syndicated POI distribution you've discussed using xmpp, rss, etc...but
> > I really just see that as a caching/distribution layer and the final
> > Representations are still displayed based on a real Query using the
> > users Location at a point in time.
> >
> >
> > roBman
> >
> >
> > [1] http://tools.ietf.org/html/rfc5870
> > [2] http://tools.ietf.org/html/rfc5870#section-3.4.3
> > [3] http://tools.ietf.org/html/rfc5870#section-7.4
> > [4] http://lists.w3.org/Archives/Public/public-poiwg/2011Apr/0016.html
> >
> >
> > On Fri, 2011-03-18 at 01:10 +1100, Rob Manson wrote:
> >> Hi Karl,
> >>
> >> yeah it's probably worth explicitly separating out the different
> >> points...I kinda jumped into the deep end there 8)
> >>
> >> First, I thought I'd just raise the geo:URI rfc as I thought it was
> >> relevant...at least for discussion.
> >>
> >> Second, I thought that was useful for having a URI standard that we
> >> could use for the ID primitive.
> >>
> >> Third, I thought there was some ambiguity as the browser is open to
> >> interpret the geo:URI any way it wants...and that we would need all
> >> those other details you listed...or at least a way to scope the
> >> reference down to a specific object/item that then has those other
> >> details attached to it. So I was speculating that we could use the
> >> fragment as a way to handle that.
> >>
> >> Essentially there would be two elements in the full URI - the left side
> >> of the # and the right side.
> >>
> >> geo:...left side...#...right side...
> >>
> >> So the left side would be used as a way to specify the location.
> >> The right side would be the permalink for the POI itself
> >> e.g. the actual id.
> >>
> >> But after thinking about it further maybe I'm blurring a few layers
> >> together and need to be more explicit about the use case. Let me write
> >> up some other notes and post them later.
> >>
> >>
> >> roBman
> >>
> >> On Thu, 2011-03-17 at 08:22 -0500, Seiler, Karl wrote:
> >> > 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, 25 April 2011 02:47:39 UTC