- From: Gene Becker <gbecker8888@gmail.com>
- Date: Mon, 23 Aug 2010 08:07:55 -0700
- Cc: "public-poiwg@w3.org" <public-poiwg@w3.org>
urposes as suggested a couple weeks back, will likely cause confusion. $0.02. -gene On Aug 23, 2010, at 7:54 AM, Christine Perey <cperey@perey.com> wrote: > +1 to not reinventing. > > OK: AR is not the only application for POIs > > OK: POI is not the only area in need of standards for a successful AR ecosystem. > > OK: AR is not the only application for visual search. > > FWIW, I don't believe that anyone is proposing that visual search be standardized in the context of any organization. But the way in which visual search engines receive images and return results could use open protocols. > > > -- > 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 8/23/2010 4:39 PM, Henning Schulzrinne wrote: >> 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 Tuesday, 24 August 2010 07:48:45 UTC