Re: Geolocation and POI

"The "point" can and will very frequently, be an object (thing or a
person)  moving in space/without geoposition or orientation
associated."

Just thinking a bit out load here, but generically what we are trying
to do is this;

(object/location) << (linking method) >> (data being linked too)

For all possible objects or locations in the world. Does that, in very
lose terms, cover everything?

-

For things with a fixed location, it probably makes the most sense to
use earth-relative positioning. GPS based or similar, and that
information becomes the "physical hyperlink" between the
object/location and the virtual data. The (linking method) is nothing
more then some key/value pairs in this instance.

For things that arn't fixed, or could appear in multiple places at
once, I think image based positioning is the most realistic, although
RFID could be used in some situations.
So your then left with the need for "linking method" to itself be an
image, or a encoded description of image data, which could then be
checked against the field of view for matches.

Thus, to me it seems the task of the W3C is to work out the best
"linking methods" for both static and dynamic objects. So a few forms
of these physical hyperlinks could be developed to suit different
situations.

GPS based links are probably a fairly trivial task compared to Image
based ones to sort out, so I think it would be advantages to pin them
down earlier then the rest. Perhaps they deserve a separate
(relatively faster/more achievable) track to the other discussions?

One warning with image/dynamic object linking methods   is that we
have to be careful no one company gets a monopoly over the system.
Both Google's Goggles API they are working on and , Qualcomm  are
image<>data database's, and if we arn't careful could become
monopoly's in the AR field simply because people have to use their
system in order to see what there friends have "glued" to objects.
There needs to be an open standard for linking images in the field of
view to virtual data, and that probably needs a client<>server
protocol to deliver the image and compare it (and that probably has to
be server side).  Alternatively a hash of an image could be used, I
guess too.

[/random thoughts]



On 10 July 2010 01:39, Christine Perey <cperey@perey.com> wrote:
> Hi Gene,
>
> Good expansion. This is material which should go into a meeting, I think.
>
> This part:
>
> from Gene Becker, July 9, 2010:
>
> If the goal is to produce location standards that are more broadly useful
> and responsive to the particular needs of AR, then it should probably be a
> separate WG with an AR-specific charter beyond "POI". I guess that
> discussion should also look to existing W3C 3D efforts; Web3D folks are
> becoming active in AR, so there could be some converged interests here as
> well.
>
> There is also the issue of data representation in AR; I'd like to think that
> a mechanism involving something analogous to user-agents and MIME types
> could help us get to client-aware adaptation and data extensibility.
>
> ======
>
> I believe it was explained to me that a benefit of an AR WG is that it can
> (and, in my opinion should) go beyond POI,  but for "starters" for the first
> charter, the focus should be on what can be achieved.
>
> Then, once the first objective is well underway, the WG can refocus its
> charter on problems the group is equipped to address or feels there is an
> urgent need for standardization.
>
> Any other thoughts?
>
> --
> Christine
>
> Spime Wrangler
>
> cperey@perey.com
> mobile +41 79 436 68 69
> VoIP (from US) +1 (617) 848-8159
> Skype (from anywhere) Christine_Perey
>
> On 7/9/2010 8:18 PM, Gene Becker wrote:
>>
>> If the goal is to produce location standards that are more broadly
>> useful and responsive to the particular needs of AR, then it should
>> probably be a separate WG with an AR-specific charter beyond "POI". I
>> guess that discussion should also look to existing W3C 3D efforts; Web3D
>> folks are becoming active in AR, so there could be some converged
>> interests here as well.
>>
>> Of course, as Christine points out, there are many more "triggers" for
>> AR, beyond just location. I'm not sure if these are ripe for
>> standardization, thoughts on this?
>>
>> There is also the issue of data representation in AR; I'd like to think
>> that a mechanism involving something analogous to user-agents and MIME
>> types could help us get to client-aware adaptation and data extensibility.
>
>

Received on Saturday, 10 July 2010 12:56:52 UTC