Re: Good practice for publishing geometry of a thing as different geometry types?

Best to consider this an alternative "asSVG" serialization, I would think. 

--Josh

Sent from my iPhone

> On May 18, 2016, at 7:43 AM, Little, Chris <chris.little@metoffice.gov.uk> wrote:
> 
> Andrea, Linda, and others,
> 
> At the risk of complicating matters, is it worth testing this approach by considering another existing W3C language for describing polygons? 
> 
> SVG (versions 1, 1.1, 1.2, 2) currently has a well implemented mini-language for paths, which also supports turtle-like graphics, and various short cuts when there are lots of coordinates. There is also a polygon syntax, but this is more restrictive in that curved lines (not 'straight') not allowed.
> 
> Chris
> 
> -----Original Message-----
> From: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu] 
> Sent: Wednesday, May 18, 2016 11:29 AM
> To: Linda van den Brink
> Cc: Rob Atkinson; Joshua Lieberman; Frans Knibbe; SDW WG Public List; Andreas Harth
> Subject: Re: Good practice for publishing geometry of a thing as different geometry types?
> 
> Hi, Linda.
> 
> Please see my comments inline.
> 
>> On 18/05/2016 9:50, Linda van den Brink wrote:
>> Hi all,
>> 
>> Interesting thread this – we should indeed somehow turn this into 
>> content for the BP.
>> 
>> I think the consensus is at least that
>> -          The geometry of a thing is a model of its real world shape.
>> -          Geometries can be expressed in different ways.
>> 
>> And perhaps
>> -          Use a separate geometry for each way you want to express it
>> (although I don’t know if you all agree)
>> 
>> We should describe the different levels of choice, i.e. as Josh described:
>> 
>> Serialization of the geometry, i.e. WKT or GML (or …)
> 
> Just to note again the approach used in GeoDCAT-AP for this:
> 
> https://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/0167.html
> 
> Basically, this is specified by using multiple instances of locn:geometry, with different literals:
> 
> dct:Location locn:geometry
>   "POLYGON((-180 90,180 90,180 -90,-180 -90,-180 90))"^^gsp:wktLiteral ,
>   "<gml:Envelope
> srsName=\"http://www.opengis.net/def/crs/OGC/1.3/CRS84\"><gml:lowerCorner>-180
> -90</gml:lowerCorner><gml:upperCorner>180
> 90</gml:upperCorner></gml:Envelope>"^^gsp:gmlLiteral ,
> 
> "{\"type\":\"Polygon\",\"crs\":{\"type\":\"name\",\"properties\":{\"name\":\"urn:ogc:def:crs:OGC:1.3:CRS84\"}},\"coordinates\":[[[-180,90],[180,90],[180,-90],[-180,-90],[-180,90]]]}"^^ns0:json
> .
> 
> Of course, this doesn't solve the issue of whether these are representations of the same geometry or of different geometries, but the GeoDCAT-AP WG saw this as a practical solution to provide users alternative geometry encodings.
> 
>> CRS (I like Rob’s comparison with language choice)
>> 
>> Realization on different scales/generalization levels
>> 
>> Kind of model (boundary, centroid, …)
>> 
>> And possible approaches for each of these. To which extend can content 
>> negotiation be used?
> 
> There's existing work we can refer to for this, especially in relation to the use of HTTP URIs for geometries. E.g.:
> 
> 
> 1. Ian Davis's work (dating back to 2003):
> 
> http://vocab.org/placetime/2003/05/geopoint-wgs84-20030516
> 
> The service is not maintained, as far as I can see, but a (no longer 
> working) example is:
> 
> http://placetime.com/geopoint/wgs84/X-126.817Y46.183
> 
> 
> 2. Ordnance Survey - e.g.:
> 
> http://data.ordnancesurvey.co.uk/id/geometry/37256-10
> 
> Geometries can be obtained in HTML, RDF/XML, Turtle, JSON. But I'm not 
> sure whether HTTP conneg is supported here. In case, John Goodwin should 
> be able to provide more details.
> 
> 
> 3. The work done in the framework of the GADM project, mentioned by 
> Andreas (cc'ed) in Amersfoort:
> 
> http://gadm.geovocab.org/
> 
> 
> 4. I have a conflict of interests here, but a few years ago I've also 
> set up an experimental API for geometry URIs, able to serve geometries, 
> in arbitrary CRSs, in different encodings / representations via conneg. 
> Discussing with Andreas, the approach seems to be in line with the one 
> used in GADM.
> 
> There's not yet an online demo (but should be available soon). In any 
> case, source code and documentation is on GH:
> 
> https://github.com/andrea-perego/geoiri/wiki
> 
> The supported formats are HTML, RDF (different serialisations), WKT, 
> GML, KML, GeoJSON.
> 
> An example of the RDF/XML output is here:
> 
> https://github.com/andrea-perego/geoiri/blob/master/examples/point(0_0).rdf
> 
> As you will be able to see, the different encodings / representations 
> are modelled by linking them from the geometry with dct:hasFormat, 
> whereas alternative RDF geometry representations are related with 
> owl:sameAs:
> 
> <http://some.site/geoiri/id/geometry/4326/point(0_0)>
>   foaf:primaryTopicOf 
> <http://some.site/geoiri/doc/geometry/4326/point(0_0)> ;
>   rdfs:label "Geometry (WKT): POINT(0 0) - EPSG:4326 (WGS 84)"@en ;
>   owl:sameAs 
> <http://some.site/geoiri/id/geometry/4326/point(0_0)#geosparql> ;
>   owl:sameAs <http://some.site/geoiri/id/geometry/4326/point(0_0)#wgs84> ;
>   owl:sameAs 
> <http://some.site/geoiri/id/geometry/4326/point(0_0)#schema.org> ;
>   owl:sameAs <http://placetime.com/geopoint/wgs84/X0Y0> ;
>   owl:sameAs <http://geohash.org/s0000000000000000000> ;
>   owl:sameAs <geo:0,0;u=0;crs=wgs84> .
> 
> 
> Cheers,
> 
> Andrea
> 
> 
>> 
>> 
>> 
>> Linda
>> 
>> 
>> 
>> *Van:*Rob Atkinson [mailto:rob@metalinkage.com.au]
>> *Verzonden:* vrijdag 13 mei 2016 02:44
>> *Aan:* Joshua Lieberman; Frans Knibbe
>> *CC:* SDW WG Public List
>> *Onderwerp:* Re: Good practice for publishing geometry of a thing as
>> different geometry types?
>> 
>> 
>> 
>> Lots of overlapping concerns here - but one unified way of looking at
>> this is to look at the OpenWorld approach - if we assume an object can
>> have properties we dont know about (yet) then we have a basic model for
>> an object
>> 
>> - object has an identifier and is a member of a set (a registration
>> viewpoint)
>> 
>> We can then provide an addition view of that object, with a "named
>> collection of properties" using the Linked Data API semantics - but
>> basically what we do every time we define a FeatureType. so for
>> "spatial" features we have
>> 
>> - object isa FeatureType has p1,p2,p3 etc
>> 
>> 
>> 
>> This view can then be accessed in multiple serialisations (Content-type
>> negotiation) and potentially also language negotiation.
>> 
>> 
>> 
>> So in principle one identifier maps to multiple resources. An we accept
>> that if we work on the web.
>> 
>> 
>> 
>> but there is no reason to limit the number of views to 1 - and if we
>> accept the Web architecture that would be an inconsistent thing to do
>> anyway.
>> 
>> 
>> 
>> So - you can have
>> 
>> 
>> 
>> FeatureTypes with multiple geometry properties
>> 
>> 
>> 
>> AND/OR
>> 
>> 
>> 
>> Multiple FeatureTypes (e.g. simple features) bound to different geometry
>> models
>> 
>> 
>> 
>> AND/OR
>> 
>> 
>> 
>> content negotiation to access different encodings of a feature ( perhaps
>> CRS choice is analagous to language choice for text?)
>> 
>> 
>> 
>> but you do probably end up with an architectural requirement to
>> advertise what views are available... :-)
>> 
>> 
>> 
>> In summary, I recommend publishing multiple encodings using different
>> information models, but consistent under an OpenWorld interpretation -
>> i.e. you should not have different models using the same property
>> predicate with different values unless it is truly a multi-valued
>> property and these are separate valid values.  My suspicion is that
>> owl:sameAs ought to apply across instances using different views
>> (multiple "information resources" c.f. http-range-14) - as in you can
>> safely mix the assertions about the object from multiple views. This
>> last point needs some serious thinking, but I believe the fundamental
>> pattern of supporting multiple views is an inevitable consequence of the
>> Web architecture and the potential for multiple clients.
>> 
>> 
>> 
>> Cheers
>> 
>> Rob Atkinson
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Wed, 11 May 2016 at 00:44 Joshua Lieberman
>> <jlieberman@tumblingwalls.com <mailto:jlieberman@tumblingwalls.com>> wrote:
>> 
>>    Franz,
>> 
>> 
>> 
>>    There are certainly many shades of difference that can distinguish
>>    how models are constructed and expressed. Serialization may be the
>>    equivalent (in a literal) of the difference between RDF/XML and
>>    Turtle. It’s complicated for CRS since WKT requires any CRS
>>    different from EPSG4326 to be explicitly included in the text
>>    string, although in principle it’s the same geometry. The next step
>>    up is probably realization of a geometry for different scales /
>>    levels of generalization. These are all the same conceptual geometry
>>    but with a different realization in coordinate positions. If we go
>>    to the difference between a feature boundary and a feature centroid,
>>    that’s more clearly a different geometric model of the feature. It’s
>>    less clear that there is a difference in geometry type between a
>>    road centerline and a road marginal line, although it’s clearly a
>>    different property of the feature.
>> 
>> 
>> 
>>    From a practical viewpoint of geometries living independently on the
>>    Web that can be both discovered and linked to features, it makes
>>    sense for these properties (CRS, geometric object type, generality)
>>    to be top level functional geometry properties, and there should be
>>    a set of feature geometry properties (envelope, centroid, boundary,
>>    hull, buffer are in 19107) so that the appropriate property can be
>>    chosen for a given application and people don’t all end up in Kansas
>>    looking for something in the USA because the centroid property is
>>    not identified as such.
>> 
>> 
>> 
>>    Whether alternate serializations should be allowed in one geometry
>>    object is less clear. It is ambiguous in 19107, not allowed in GML,
>>    generally not in Simple Features, and not forbidden in GeoSPARQL. My
>>    sense is that serializations themselves are easily transformable and
>>    multiple coordinate strings are too useful for composite geometries
>>    and other purposes to risk confusion. GeoJSON is an issue here
>>    because it requires one serialization and one CRS to be present
>>    whether or not another one is desirable. There doesn’t seem to be an
>>    prohibition against multiple geometry elements per feature, though,
>>    so it makes sense to put different serializations into different
>>    GeoJSON geometry objects as an extension to support JSON-LD / RDF
>>    (not recognized by the GeoJSON specification, of course).
>> 
>> 
>> 
>>    Josh
>> 
>> 
>> 
>> 
>> 
>>        On May 10, 2016, at 6:09 AM, Frans Knibbe
>>        <frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>> wrote:
>> 
>> 
>> 
>>        Hello Josh, all,
>> 
>> 
>> 
>>        Sorry for misunderstanding what you meant. But it is good to
>>        share thoughts about when and how to split geometry data in
>>        different objects. Probably things like this deserve a place in
>>        the BP document.
>> 
>> 
>> 
>>        You mentioned different serializations. That makes me wonder
>>        what a serialization is. If I change the CRS or the type of a
>>        geometry, I get a new geometry. That more or less follows from
>>        the definition that a geometry is a model of a shape. If I use a
>>        different CRS or different geometry type, I use a different
>>        model. In other words, if the actual sequence of numbers in the
>>        coordinates changes, we have a new geometry. So is that sequence
>>        of numbers the serialization? I could use the same numbers in a
>>        WKT string or in a GML object. Isn't that also serialization?
>>        Probably we need two terms, one for different sequences of
>>        coordinates, and one for packaging the same sequence of
>>        coordinates in different ways. In notice that the GeoSPARQL
>>        standard talks of WKT and GML as different serializations.
>> 
>> 
>> 
>>        To me it would make sense to let the same coordinate sequence in
>>        different data types be part of the same geometry - they are
>>        different expressions of the same model. For example:
>> 
>> 
>> 
>>        ex:geom6789
>> 
>>          a geom:Geometry, geom:Point ;
>> 
>>          geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>> 
>>          geosparql:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>        POINT(131216.968 461378.333)"^^geosparql:wktLiteral ;
>> 
>>          geosparql:asGML "<gml:Point
>>        srsName="EPSG:28992"><gml:coordinates>131216.968,461378.333</gml:coordinates></gml:Point>"^^geosparql:gmlLiteral
>>        .
>> 
>> 
>> 
>>        Regards,
>> 
>>        Frans
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>        2016-05-09 18:05 GMT+02:00 Joshua Lieberman
>>        <jlieberman@tumblingwalls.com
>>        <mailto:jlieberman@tumblingwalls.com>>:
>> 
>>        Yes, of course a geometry is a model. For that matter, a feature
>>        is a model, but one that directly references the “real world".
>>        The question was really whether multiple serializations can be
>>        included in a geometry, e.g. for different scales or CRS’s. It
>>        makes sense to me, but upon investigation, it is just not
>>        something that is practiced, although there is no present axiom
>>        in GeoSPARQL that prevents it. It doesn’t seem to be an explicit
>>        part of either 19107 or GML, and the general semantic is that
>>        multiple positions represent a composite serialization of a
>>        geometry, not alternate ones.
>> 
>> 
>> 
>>        So we should probably stick with each unique combination of role
>>        (centroid, etc. are actually defined terms in 19107), scale,
>>        CRS, interpolation method, etc. as a distinct geometry.
>> 
>> 
>> 
>>        Backlinks from geometry to feature are problematic. If
>>        geometries are to be stored separately, it’s probably to share them.
>> 
>> 
>> 
>>        Josh
>> 
>> 
>> 
>> 
>> 
>>            On May 9, 2016, at 9:50 AM, Bill Roberts <bill@swirrl.com
>>            <mailto:bill@swirrl.com>> wrote:
>> 
>> 
>> 
>>                But I suspect at the heart of your comments is the
>>                question what a geometry really is. There are at least
>>                two possibledefinitions:
>>                A) The geometry of a thing is its real world shape.
>>                B) The geometry of a thing is a model of its real world
>>                shape.
>> 
>> 
>> 
>>            I agree: in practice, (B) is always the case.  No
>>            representation of geometry will be completely accurate, and
>>            different levels of approximation (different models) are
>>            appropriate in different contexts.
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>            On 9 May 2016 at 15:35, Frans Knibbe <frans.knibbe@geodan.nl
>>            <mailto:frans.knibbe@geodan.nl>> wrote:
>> 
>>            Hello Josh,
>> 
>> 
>> 
>>            It could be possible to add more context to the geometries,
>>            to express that they are a footprint or a centroid for
>>            instance. But I think that extra context will not be crucial
>>            for many use cases. Especially since there is no standard
>>            vocabulary for that extra meaning yet  (although the
>>            vocabulary I try to use does have a centroid
>>            property: http://data.ign.fr/def/geometrie#centroid).
>> 
>> 
>> 
>>            But I suspect at the heart of your comments is the question
>>            what a geometry really is. There are at least two possible
>>            definitions:
>> 
>>            A) The geometry of a thing is its real world shape.
>> 
>>            B) The geometry of a thing is a model of its real world shape.
>> 
>> 
>> 
>>            I think I silently use definition B. But if others assume
>>            definition A that could lead to problems. I am ashamed to
>>            have to admit that I don't know the official OGC party line
>>            in this case. But it would be great if an updated GeoSPARQL
>>            standard could have a direct link to a core definition of
>>            geometry.
>> 
>> 
>> 
>>            As for your last example (two coordinate strings that differ
>>            in their CRS) in my line of thinking (adherent of definition
>>            B) that would be modelled as separate geometries. An
>>            extended example:
>> 
>> 
>> 
>>            ex:location1234
>> 
>>               a dcterms:Location ;
>> 
>>               locn:geometry ex:geom1234_1, ex:geom1234_2,
>>            ex:geom1234_3, ex_geom1234_4 ;
>> 
>> 
>> 
>>            ex:geom1234_1
>> 
>>               a geom:Geometry, locn:Geometry, geom:Point ;
>> 
>>               locn:location ex:location123 ;
>> 
>>               geom:crs <http://www
>>            <http://www/>.opengis.net/def/crs/EPSG/0/28992> ;
>> 
>>               geosparql:asWKT "<http://www
>>            <http://www/>.opengis.net/def/crs/EPSG/0/28992>
>>            POINT(...)"^^geosparql:wktLiteral .
>> 
>> 
>> 
>>            ex:geom1234_2
>> 
>>               a geom:Geometry, locn:Geometry, geom:Polygon ;
>> 
>>               locn:location ex:location123 ;
>> 
>>               geom:crs <http://www
>>            <http://www/>.opengis.net/def/crs/EPSG/0/28992> ;
>> 
>>               geosparql:asWKT "<http://www
>>            <http://www/>.opengis.net/def/crs/EPSG/0/28992>
>>            POLYGON(...)"^^geosparql:wktLiteral .
>> 
>> 
>> 
>>            ex:geom1234_3
>> 
>>               a geom:Geometry, locn:Geometry, geom:Point ;
>> 
>>               locn:location ex:location123 ;
>> 
>>               geom:crs <http://www
>>            <http://www/>.opengis.net/def/crs/OGC/1.3/CRS84> ;
>> 
>>               geosparql:asWKT "POINT(...)"^^geosparql:wktLiteral .
>> 
>> 
>> 
>>            ex:geom1234_4
>> 
>>               a geom:Geometry, locn:Geometry, geom:Polygon ;
>> 
>>               locn:location ex:location123 ;
>> 
>>               geom:crs <http://www
>>            <http://www/>.opengis.net/def/crs/OGC/1.3/CRS84> ;
>> 
>>               geosparql:asWKT "POLYGON(...)"^^geosparql:wktLiteral .
>> 
>> 
>> 
>> 
>> 
>>            Note that I also included a backlink from geometry to
>>            location (locn:location).
>> 
>> 
>> 
>>            The question still is: can this be considered a good
>>            practice, given currently available standards/vocabularies?
>> 
>> 
>> 
>>            Regards,
>> 
>>            Frans
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>            2016-05-04 19:10 GMT+02:00 Joshua Lieberman
>>            <jlieberman@tumblingwalls.com
>>            <mailto:jlieberman@tumblingwalls.com>>:
>> 
>>            Do you mean:
>> 
>> 
>> 
>>                ex:location1234
>> 
>>                   a dcterms:Location, ex:feature ;
>> 
>>                   ex:centroid ex:geom1234 ;
>> 
>>                   ex:footprint ex:geom6789 .
>> 
>> 
>> 
>>                ex:geom1234
>> 
>>                   a geom:Geometry, gsp:Point ;
>> 
>>                   geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>> 
>>                   gsp:asWKT
>>                "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>                POINT(...)"^^geosparql:wktLiteral .
>> 
>> 
>> 
>>                ex:geom6789
>> 
>>                   a geom:Geometry, gsp:Polygon ;
>> 
>>                   geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>> 
>>                   gsp:asWKT
>>                "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>                POLYGON(...)"^^geosparql:wktLiteral .
>> 
>> 
>> 
>>            In that case, the range of gsp:asWKT is not a geometry, but
>>            a set of coordinate positions locating the geometry, so
>>            “POLYGON” is the format of the coordinate string, not the
>>            geometry class per se.
>> 
>> 
>> 
>> 
>> 
>>            The coordinate information is more problematic, since one
>>            could easily want to have
>> 
>> 
>> 
>>                ex:geom6789
>> 
>>                   a geom:Geometry, gsp:Polygon ;
>> 
>>                   geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>> 
>>                   gsp:asWKT
>>                "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>                POLYGON(...)"^^geosparql:wktLiteral .
>> 
>>                   gsp:asWKT "POLYGON(...)"^^geosparql:wktLiteral .
>> 
>>                gap:asGML “…”
>> 
>> 
>> 
>>            I consider asWKT to be problematic for this reason, and one
>>            ground for updating the GeoSPARQL standard.
>> 
>> 
>> 
>> 
>> 
>>             Josh
> 
> -- 
> Andrea Perego, Ph.D.
> Scientific / Technical Project Officer
> European Commission DG JRC
> Institute for Environment & Sustainability
> Unit H06 - Digital Earth & Reference Data
> Via E. Fermi, 2749 - TP 262
> 21027 Ispra VA, Italy
> 
> https://ec.europa.eu/jrc/
>

Received on Wednesday, 18 May 2016 12:03:24 UTC