- From: Jens de Smit <jens.desmit@surfnet.nl>
- Date: Mon, 23 Aug 2010 14:45:45 +0200
- 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. Regards, Jens
Received on Monday, 23 August 2010 12:46:13 UTC