- From: Raj Singh <rsingh@opengeospatial.org>
- Date: Thu, 28 Oct 2010 11:46:00 -0400
- To: "public-poiwg@w3.org W3C" <public-poiwg@w3.org>
I changed centroid to anchor and made a new section for listing types of anchors. We can worry about the extensibility mechanism later. Jens, I worry about anchors that only have 2D or 3D grid references within a building. It seems to me much harder to ensure interoperability and "linked data" without a common geographic reference. Maybe every space can at least have a geographic anchor for the enclosing building, then use a local grid reference system (x,y,z) to go from the building's anchor to the individual space. Can you post your suggestions to the wiki? --- Raj The OGC: Making location count... http://www.opengeospatial.org/contact On Oct 28, at 8:46 AM, Jens de Smit wrote: > On 27/10/2010 20:09, Raj Singh wrote: >> I made a page for the data model discussion: >> http://www.w3.org/2010/POI/wiki/Data_Model > > Hello all, > > Thanks Raj for writing this down, this gives us something to start a > discussion from. It seems you based your list primarily on Marco's > "smallest subset if information which can describe a POI" which in turn > was based on Gary's contributions. However, one thing Marco also > mentioned as being important was "extensibility"; I'd like to agree with > that and propose to make a significant change to the data model along > the following lines: > > Replace "centroid" by a more flexible "anchor" (terminology subject to > discussion) property which describes where in the world the POI belongs. > This anchor property should have an attribute/subtype that specifies how > its data should be interpreted. A lat/lon/alt in WGS84 type anchor seems > to be a very obvious anchor type to define, but the following anchor > types come to mind as well: > > - x,y locations on a 2D grid/ x,y,z locations on a 3D grid > Use case: situations where lat/lon/alt are impractical, such as in > buildings where dimensions are usually measured in meters. Much easier > and faster authoring > > - fiducial markers or images > Use case: Augmented Reality experiences obviously, but could also be > applied to virtual worlds > > - buildings > Use case: again, easier authoring than looking up lat/lon coordinates > for everything you want to describe. Also, it conveys a string > connection between the POI and the real-world entity that is being > described. This allows for smarter and nicer user interfaces; for > example see > http://www.perey.com/ARStandards/Nokia_A_Web_Services_Platform.pdf by > Nokia's Petros Belimpasakis et al for some functional AR examples of > tying POIs and buildings together, but the same usability holds for maps > and virtual worlds. > > - dynamic entities > Use case: wouldn't it be neat to describe a car or person as POI? As > computer vision improves, computers can track and recognize more and > more of the world around us. The AR use case is again obvious, but what > if you could dsignate your favourite football player as a POI? Apply > some CSS-like "outer-glow: 3pt yellow;" effect to your POI, link it to > the WebTV stream you're watching and you'll never lose track of him again. > > > So the last example is a bit futuristic and probably won't be part of > the first spec but I hope it conveys why I think having a flexible (and > extensible) "anchor" property would be better than hardcoding a centroid > for each point. All the other properties that have been written down > (except perhaps address) are useful for any of these use cases which is > why I would really like this flexibility in the spec. > > Looking forward to your opinions! > > > Best regards, > > Jens > > Also, this list is not exhaustive and I welcome other suggestions as well. >
Received on Thursday, 28 October 2010 15:46:33 UTC