- From: Little, Chris <chris.little@metoffice.gov.uk>
- Date: Fri, 20 May 2016 11:57:09 +0000
- To: Frans Knibbe <frans.knibbe@geodan.nl>
- CC: Andrea Perego <andrea.perego@jrc.ec.europa.eu>, Linda van den Brink <l.vandenbrink@geonovum.nl>, Rob Atkinson <rob@metalinkage.com.au>, "Joshua Lieberman" <jlieberman@tumblingwalls.com>, SDW WG Public List <public-sdw-wg@w3.org>, Andreas Harth <harth@kit.edu>
- Message-ID: <3DAD8A5A545D7644A066C4F2E82072883E1FFBA8@EXXCMPD1DAG4.cmpd1.metoffice.gov.uk>
Hi Frans,
I had a discussion within the SVG WG last year, and in particular with Satoru Takagi, about CRSs in SVG. The official line is if an SVG author creates user coordinates, for example: ( (-180,+180), (-90,+90) ), SVG knows nothing about the geo-referencing , and should not. There is a metadata tag where some information could be embedded.
I envisage at some time in the future, browsers may read the metadata and do something appropriate. At present, the JavaScript will have to do that. The encouraging thing is that the push in SVG2 is complete backwards compatibility with SVG1,1,2,1,2, Tiny, and focussing on interactions with the context (HTML5, CSS, etc) so it should be relatively straight forward to establish meaningful rectilinear coordinates in a single viewport at the ‘top’ of the SVG. Hence back to JavaScript rather than the SVG browser code.
And of course with those user coordinates, there is the issue of precision and accuracy (cf response from the geoJSON standards people)
In the longer term, I think all browsers will become geo aware and accurate enough, but currently there is no enthusiasm from the browser developers that I have talked to.
And of course SVG does points – usually manifested as Markers. Generally points are properties of other things.
I am back at work next Tuesday. Do you want some snippets of SVG?
Chris
From: Frans Knibbe [mailto:frans.knibbe@geodan.nl]
Sent: Wednesday, May 18, 2016 3:19 PM
To: Little, Chris
Cc: Andrea Perego; Linda van den Brink; Rob Atkinson; Joshua Lieberman; SDW WG Public List; Andreas Harth
Subject: Re: Good practice for publishing geometry of a thing as different geometry types?
Hello Chris,
Best practices for spatial data on the web should not be limited to geography, so testing with SVG seems a good idea. If we can demonstrate it works, it would be a triumph for levelling barriers between geographic and non-geographic spatial data on the web.
I do wonder about CRS specification in SVG. A geometric shape expressed as SVG can include a CRS definition, in that respect it is not different from GML or GeoSPARQL WKT. But a CRS specification in GML or GeoSPARQL WKT can be made to align with a separate CRS specification in a geometry object, as in the example from a previous message:
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 .
In this example the CRS specification is repeated in the coordinate serializations (let's call them that), which is not very elegant, but does not cause a conflict.
If an SVG serialization was added to this example, how could the SVG coordinate system be aligned with the CRS specification? I don't think SVG can link to CRS URIs. My guess is that the SVG object should not have any specification of its viewport or CRS. That seems to be supported by the SVG standard, see https://www.w3.org/TR/SVG/coords.html#ViewportSpace: ".. containing document might include attributes, properties and/or other parameters (explicit or implicit) which specify or provide hints about the dimensions of the viewport for the SVG content". Considering a geometry specification in RDF, like the turtle example in above, hopefully the geometry instance (ex:geom6789 in the example) can be regarded as the document containing the SVG specification. By means of its geom:crs property it provides "hints about the dimensions of the viewport for the SVG content".
Something funny just happened: I tried to extend the turtle example with SVG but then I found out SVG does not do points. Oh well...
Regards,
Frans
2016-05-18 13:43 GMT+02:00 Little, Chris <chris.little@metoffice.gov.uk<mailto:chris.little@metoffice.gov.uk>>:
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<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\<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<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> <mailto: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> <mailto: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>
> <mailto: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>
> <mailto: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>
> <mailto: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<http://opengis.net/def/crs/EPSG/0/28992>> ;
>
> geosparql:asWKT "<http://www
> <http://www/>.opengis.net/def/crs/EPSG/0/28992<http://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<http://opengis.net/def/crs/EPSG/0/28992>> ;
>
> geosparql:asWKT "<http://www
> <http://www/>.opengis.net/def/crs/EPSG/0/28992<http://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<http://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<http://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>
> <mailto: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 Friday, 20 May 2016 11:57:43 UTC