Re: WG Objectives - A Personal Take

On 28/10/2010 15:10, Thomas Wrobel wrote:
> +1 to "anchor" term. It seems to fit very well to me.

Why thank you :) I did try to pick something sensible, glad it resonates
with you.

> I do say though I'm not  sure linking to a building(name?) would be
> better then just linking to its co-ordinates; buildings don't move, so
> if its location is looked up at run-time, surely thats adding
> unnecessary overhead on the client end?
> There could, however, be some sort of system for swapping building
> names for co-ordinates; an "infrastructural looked-up" style
> system/api. Possibly used as a optional "snap too" function for
> clients submitting data. ("Did you mean to post on [building name]?
> Yes - post on buildings anchor, No - post at my exact co-ordinates
> specified"). This would be used when submitting data, but not every
> time a client needs to read the data.
> (imagine a client wants to see things within a certain range, if it
> can just look down a list of co-ordinates, thats much quicker/less
> bandwidth then converting a list of names first to a list of
> co-ordinates and thne checking).

The added value of linking to an object (such as a building) instead of
coordinates is that, when displaying info in a client, the client has
the knowledge to connect the POI's information to the building even when
only a certain part of the building is in the viewport. Especially when
viewing large buildings up close (whether on a map, in a virtual world
or in AR), a single geographic point to describe the building might be
invisible if you are looking at the other side of the building. Still,
this is a technologically advanced use case which requires clients to
somehow recognize buildings. This is probably easier in applications
like Google Earth, where a lot of this information is already present,
than in a mobile AR browser.

As a compromise we could have multiple anchor properties for a single
POI, i.e. allow multiple anchors to be defined, optionally with an order
of precedence. User agents can then use the easy, quick lat/lon for
early rendering and subsequently start querying for building info to
refine the representation. Also, you could probably cache building
lookups for a pretty long time (they don't move much as you said). With
the current state of storage (and it's still getting better) even mobile
handsets should be able to this.

If you're worried about bandwidth (as a service provider for mobiles for
example) you can always choose to either not store the additional
building info or filter it our using a swift pass-through proxy that
does some post-processing based on a user-agent header (talking HTTP to
the WFP guy here, I know ;)

> Expansion potential to link to dynamic objects is a must though.
> Partly this could be just another form of image anchor (markers being
> a sub-set of that), but you could also at some point have RFID
> anchors. I love the tv highlighting use-case, but I can only see it
> working as advanced image recognition or the player carrying a "becon"
> of some form.

Who says they won't start carrying beacons? If you consider assocation
football (aka soccer), advocates of electronic refereeing assistance
have proposed player tracking systems to detect off side situations for
ages. A radio wave echo in the shinguard, couple of transmitters around
the field, a little triangulation and presto: player tracking! (I have a
second workable approach based on image recognition but I won't
elaborate any further here :)

My point is that it took me 20 seconds to come up with a use case.
Together we could make 50 more in a day. I'd say we need this flexible
anchoring scheme :)

Regards,

Jens

Received on Thursday, 28 October 2010 13:34:44 UTC