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

On 18/05/2016 14:02, Joshua Lieberman wrote:
> Best to consider this an alternative "asSVG" serialization, I would think.

+1.

BTW, if I remember well Andreas's API is returning geometries also in SVG.

Andrea


>
> --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/
>>
>
>

-- 
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 13:40:21 UTC