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

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

From: Jens de Smit <jens.desmit@surfnet.nl>
Date: Mon, 23 Aug 2010 14:45:45 +0200
Message-ID: <4C726D79.7090703@surfnet.nl>
To: Thomas Wrobel <darkflame@gmail.com>
CC: Alex Hill <ahill@gatech.edu>, public-poiwg@w3.org
On 23/08/2010 14:20, 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.

Hi Thomas,

I think it should be up to the developers that use the standard to
select the best approach for their particular use case. If an extra
lookup for each data point is acceptable (for instance because you have
an address database available locally) then it may be easier and more
flexible to use street addresses or site descriptions than coordinates.
If the primary use case is targeted at a high-latency low-bandwidth
mobile device then yes, doing an extra lookup for each point may be too
much (and it would also require the availability of a lookup service
on/for the device). But, I think it should be up to the application
developer to decide what is desirable.

In practical situations I can imagine a two-tiered approach: a data
service providing POI data natively stores and delivers semnatically
relevant point identification (i.e. street addresses or copmany names)
but the result then gets processed by an address translator that
optimizes the result for the specific use case (such as a GPS-capable
mobile device). This way the original data is stored in its most
relevant form while the user gets the optimal experience. For
performance issues, the translation results could of course be cached.


Received on Monday, 23 August 2010 12:46:13 UTC

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