W3C home > Mailing lists > Public > public-poiwg@w3.org > August 2010

Re: [uk-government-data-developers] Couple of Ordnance Survey things

From: Henning Schulzrinne <hgs@cs.columbia.edu>
Date: Mon, 23 Aug 2010 10:39:19 -0400
Cc: Alex Hill <ahill@gatech.edu>, public-poiwg@w3.org
Message-Id: <13751ECF-E752-483E-A144-369E44DEEF07@cs.columbia.edu>
To: Thomas Wrobel <darkflame@gmail.com>
There's lots of existing experience in that field; we've had long discussions on this in the IETF GEOPRIV group. In some cases (indoors being a typical one), civic locations (aka street addresses) are more directly useable, more likely to be provided by the location infrastructure and more informative. Civic addresses also include "landmark" names, such as "Rockefeller Center".

Fortunately, that group has also done a lot of the spade work on civic locations, so as long as we don't try to re-invent the wheel here, this isn't too hard.

Again, I'd like to remind people that AR is not the only application for POIs. I'm worried about excessive tuning for one application. I think the processing chain is fairly simple:

- you get civic and/or geo location information (along with time)
- you find relevant POI information in some searchable repository
- the POI contains relevant pointers to more detailed, application-specific data or the descriptive data itself, depending on the usual trade-offs of indirection vs. wasting bits on things that the receiver doesn't care about or already has.

There already is a protocol that does the mapping (LoST), if you're looking for that, now being deployed by an emergency calling agency near you...

Searching by image similarity seems like a rather different problem, although the image database may well contain pointers to POIs. But that's likely a many-to-one mapping, e.g., there are thousands of images of the Rockefeller Center in the (say, Flickr or Picasa) image database, and there's no point in creating a record that contains them all.

Henning

On Aug 23, 2010, at 8:20 AM, Thomas Wrobel wrote:

> "Does one want to associate their content with -85.0,34.0 or at the
> Klaus Computing building?"
> 
> I think most(all?) people agree that co-ordinates alone shouldn't be
> the only way to tie the real world to data.
> However, you have to think in terms of how it will physically work,
> and not just the easiest way for the content creators to assign
> things.
> 
> For example; How will a device know what/where the "Klaus Computing
> building" is ?
> Surely by tieing it to that String, it would require an additional
> look up, from a government database, or another source every time a
> client needs to know. This could cause a lot of wasted bandwidth no?
> Surely its better for any "fixed" locations to be specified at
> creation time, not looked up at viewing time? You make one call to
> find out co-ordinates when your assigning content. But for every
> client looking at it, they dont need to look at the database because
> to those devices its just raw co-ordinates.
> Defining a region (like the shape of the building itself) is a good
> idea, and something being discussed too. (Although I suspect a center
> pivot point would need to be done anyway though, even in that
> scenario).Also  might be worth looking at;
> https://research.cc.gatech.edu/polaris/content/infrastructure-service
> too, which prepossess a survive for delivering infer-structure models.
> 
> For things that can't be done at all with co-ordinates (like your car
> example), we have to think of what other data to use so the device can
> get a fix on if its in view, and where it is.  My view is this pretty
> much has to be an image. Some sort of image recognition of the car,
> that can then be associated with data. It could also be a RFID, or
> another identifying technology....but that would require a physical
> change to the car, so it seems less practical.
> 
> So overall we certainly shouldn't just limit ourselves to
> co-ordinates, but we do have to consider how things will work, and try
> to avoid too many remote-calls when possible.
> 
> [/two cents]
> 
> -Thomas Wrobel
> 
Received on Monday, 23 August 2010 14:39:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:25 UTC