Re: POI Core strawman: Geo-reference section

Here's a little more structured feedback based on my earlier comments on
Locations/Points/Centers and Geometries in general[1]

It seems like the Geo-reference section[2] would be more cleanly related
to the existing models of this type of structure e.g. as Raj has
referred to with the W3C Geospatial Vocab & GeoRSS.

As I see it...at the heart of it all is the centroid[3]/extent[4]
separation where the centroid/point is the origin Location for the POI.
On top of that can be mapped or projected zero or more extents or
models.

So the centroid or point seems to map pretty clearly to the existing
Location models (e.g. gml:Point, geo: etc).

Then the extents seem to map clearly to the existing data models for
"other types" of geometries that are relatively common.  Here are the
KML and geojson terms just to list two.

        KML[5]
        - Point
        - LineString
        - LinearRing
        - Polygon
        - MultiGeometry
        - gx:MultiTrack
        - Model
        - gx:Track
        
        geojson[6]
        - Point
        - LineString
        - Polygon
        - MultiPoint
        - MultiLineString
        - MultiPolygon
        - GeometryCollection

The existing Geo-reference types like Route, Navigation-Point and Center
seem un-resolved.  

To me a Route is more like a LineString (or Path/Track).  

A Navigation-Point seems like a relationship between two (or more)
mutually consenting Points.  

And a Center seems like a Point, if that's accepted as the heart of the
POI data model (see Thomas' comment about plinks, etc.[7]).

Point also seems like a much stronger term than Center or Centroid as
both of those suggest a relationship to one specific model or extent.
Yet a Point suggests it can have any number of models or extents related
to it without it needing to change.

I'm not quite sure what or how Undetermined would be used?

And Relative also seems like a relationship between two (or more)
mutually consenting points.  At the moment it seems un-resolved as to
how the "another location" is defined and how you would deal with the
movement of that "another location".  If it's just a relationship
between Points then this is simply a reference and all the rest is
pretty straightforward.

Map also seems a little out of place.  I can see why a Map vendor would
like this...but surely it's just the job of the client application or
POI consumer to map a POI using a specific representation
solution...which may or may not involve maps.

With the Relationship primitive...are these just goals?  What happens if
the actual extents/models for the two POIs don't agree with the defined
Relationship.  e.g. it's set to contained-within but when the models are
projected this isn't the case.


roBman

[1] http://lists.w3.org/Archives/Public/public-poiwg/2011May/0003.html 
[2] http://www.w3.org/2010/POI/documents/Core/POI%20Core%20Draft.html#geo-reference
[3] http://en.wikipedia.org/wiki/Centroid 
[4] http://dictionary.reference.com/browse/extent 
[5] http://code.google.com/apis/kml/documentation/kmlreference.html#geometry
[6] http://wiki.geojson.org/GeoJSON_draft_version_6#Geometries 
[7] http://lists.w3.org/Archives/Public/public-poiwg/2011May/0005.html

Received on Thursday, 5 May 2011 00:02:25 UTC