- From: Peter Baumann <p.baumann@jacobs-university.de>
- Date: Wed, 17 Jun 2015 17:17:37 +0200
- To: Frans Knibbe <frans.knibbe@geodan.nl>
- CC: Simon Cox <Simon.Cox@csiro.au>, SDW WG Public List <public-sdw-wg@w3.org>
- Message-ID: <55818F91.4090803@jacobs-university.de>
Hi Frans, yes, in your points I see no contradiction to what I said before. And I agree, this is an IMHO weird combination of DC and GML. If your only toy was Lego then you tend to see everything as a pluggable brick. Sorry. ;-) -Peter On 06/17/15 17:10, Frans Knibbe wrote: > Hello Peter, > > Too much freedom or room for interpretation is undesirable. In this case, a > web developer has a web page with a map element that needs to be told the > extent of the map that should be drawn. The same web developer requests the > metadata of a geographical data set. The question is: how can the web > developer get the numbers he/she needs (a definition of a bounding box) from > the metadata? This needs to be done in a predictable (standardised) way, and > should involve as little processing as possible. > > By the way, following the information on the web about alignment of INSPIRE > metadata with DCAT, I came across this example of dataset metadata > <http://rdf-translator.appspot.com/convert/xml/turtle/https://ies-svn.jrc.ec.europa.eu/attachments/download/723/md-series-inspire+dcat-ap-core.rdf> > that includes a stament on spatial extent: > > dcterms:spatial [ a dcterms:Location ; > locn:geometry "<gml:Envelope > srsName=\"http://www.opengis.net/def/EPSG/0/4326\ > <http://www.opengis.net/def/EPSG/0/4326%5C>"><gml:lowerCorner>-10.58 > 34.56</gml:lowerCorner><gml:upperCorner>34.59 > 70.09</gml:upperCorner></gml:Envelope>"^^<http://www.opengis.net/rdf#GMLLiteral> > ] ; > > In this example, a dcterms:Location is described as a GML fragment. While this > conforms with current W3C and OGC standards, from the point of view of the web > developer this not optimal. First, somehow the GML code needs to be recognised > as GML code and secondly the GML code needs to be parsed in order to obtain > the required numbers. > > Greetings, > Frans > > > > > 2015-06-17 13:14 GMT+02:00 Peter Baumann <p.baumann@jacobs-university.de > <mailto:p.baumann@jacobs-university.de>>: > > Hi Frans, > > again, this XML is just an _example_ showing the ingredients. Nobody says > it must be XML! See my mail below: use RDF, JSON, or any other format to > represent CRS + coordinates. > > Dublin Core - BTW, it's XML ;-) ) works on another level of metadata, here > an example from Wikipedia (http://www.w3.org/wiki/DublinCore): > > <meta name="DC.Coverage.spatial" scheme="TGN" content="name=San Francisco > (San Francisco county, California, United States)" /> <meta > name="DC.Coverage.spatial" scheme="DCMIPOINT" content="name=San Francisco, > CA, U.S.A.; east=237.5833; north=37.7667" /> > > Hence, Dublin Core uses a _description_ rather than an exact _location_. > AFAICS the requirement under discussion focuses solely on the issue of > representing space (and likely time) exactly (that is: through > coordinates). Inexact representation, as done here, is another > requirement. On the side, note the missing CRS. In "European" coordinates, > this might end up in the Pacific ocean ;-) > > BTW, citing said Wikipedia page: "TGN Be careful, since most of the > documentation for georeferencing with DC is too vague on the precise > format, and most of the examples are incorrect". > > And, again: "coverages" is not identical to "XML". Any representation is > fine. :) > > cheers, > Peter > > > > > > On 06/17/15 12:58, Frans Knibbe wrote: >> Yes, there is an existing practice in the realm of current OGC standards. >> But does this automatically mean there is a best practice for spatial >> data on the web? In this example, the web developer would have to parse >> XML and understand GML. That would not have the average web developer >> jumping for joy. Considering that we want to advocate best practices that >> are as simple as possible, and easy to adopt for developers that know >> little of geospatial data, I think we could try to think of something >> more webby. >> >> Also it does not feel right to me to ignore an applicable Dublin Core >> metadata element (dcterms:spatial) when it is there to use. >> >> Of course, if a recommended best practice also closely matches existing >> geospatial standards that would be all the better. >> >> Greetings, >> Frans >> >> 2015-06-17 12:41 GMT+02:00 Peter Baumann <p.baumann@jacobs-university.de >> <mailto:p.baumann@jacobs-university.de>>: >> >> indeed, confirming this (Frans, you already had a feeling in that >> direction): the envelope defines a bounding box whose coordinates are >> expressed in the CRS also referenced in the envelope. Here is a >> simple OGC coverage example (in XML, but easy to translate into RDF, >> JSON, etc), just FYI: >> >> <gml:Envelope srsName=" http://www.opengis.net/def/EPSG/0/4326“ >> <http://www.opengis.net/def/EPSG/0/4326%E2%80%9C> >> axisLabels="Lat Long" uomLabels="deg deg" srsDimension=“2"> >> <gml:lowerCorner>1 2</gml:lowerCorner> >> <gml:upperCorner>3 4</gml:upperCorner> >> </gml:Envelope> >> >> -Peter >> >> >> On 06/17/15 12:09, Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au> wrote: >>> Frans - >>> You really don't have to make this up afresh. >>> ISO 19107 defines a property 'envelope' for any geometry, with a >>> value of type GM_Envelope, which has a lower and upper corner, whose >>> values are points. >>> ISO 19123 defines a property 'domain extent' for any coverage, with >>> a value of type EX_Extent, which is a bit more complex (defined in >>> ISO 19115). >>> There is no standard property for the corresponding thing for a >>> generic feature, but 'bounding box' is a common name. >>> >>> Simon >>> >>> Caveat lector - Sent from a tablet using TouchDown* >>> >>> * >>> -------------------------------------------------------------------------------- >>> *From:* Frans Knibbe >>> *Sent:* Wednesday, 17 June 2015 9:53:42 AM >>> *To:* SDW WG Public List >>> *Subject:* Best Practice for encoding spatial coverage >>> >>> Hello all, >>> >>> Is it OK to try to venture in to the domain of best practices >>> already? I wonder if we can try our hands at the following issue: >>> >>> I have just had a talk with a web developer on the best way of >>> making the extent of a spatial data set known, in a Linked Data >>> context. It is useful to know the spatial extent of a data set >>> because that way a map can be zoomed in on the right patch of Earth. >>> >>> I think an obvious predicate for making the extent known is >>> dcterms:spatial >>> <http://dublincore.org/documents/dcmi-terms/#terms-spatial> (Spatial >>> Coverage). That should point to a dcterms:Location >>> <http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms#terms-Location>, >>> which can have a geometry. So an option would be to encode the >>> extent as a WKT polygon, according to GeoSPARQL semantics. But that >>> would not be the most webdeveloper-friendly way of making the extent >>> known. The usual way of setting a map extent involves knowing the >>> minimum and maximum values for X and Y. So a question is: what would >>> be the best way to publish the minimum and maximum X and Y? There >>> are usable vocabularies for publishing point coordinates, so one >>> could think of recommending to publish two points (lower left corner >>> and upper right corner). Perhaps there are standard vocabularies >>> available that define the concepts of 'minimum' and 'maximum' and >>> 'x' and 'y'? >>> >>> I should note that this issue relates to the Spatial metadata >>> requirement >>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#SpatialMetadata>. >>> >>> >>> Greetings, >>> Frans >>> >>> >>> >>> -- >>> Frans Knibbe >>> Geodan >>> President Kennedylaan 1 >>> 1079 MB Amsterdam (NL) >>> >>> T +31 (0)20 - 5711 347 <tel:%2B31%20%280%2920%20-%205711%20347> >>> E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl> >>> www.geodan.nl <http://www.geodan.nl> >>> disclaimer <http://www.geodan.nl/disclaimer> >>> >> >> -- >> Dr. Peter Baumann >> - Professor of Computer Science, Jacobs University Bremen >> www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann> >> mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de> >> tel: +49-421-200-3178 <tel:%2B49-421-200-3178>, fax: +49-421-200-493178 <tel:%2B49-421-200-493178> >> - Executive Director, rasdaman GmbH Bremen (HRB 26793) >> www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com> >> tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 <tel:%2B49-173-5837882> >> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) >> >> >> >> >> >> -- >> Frans Knibbe >> Geodan >> President Kennedylaan 1 >> 1079 MB Amsterdam (NL) >> >> T +31 (0)20 - 5711 347 <tel:%2B31%20%280%2920%20-%205711%20347> >> E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl> >> www.geodan.nl <http://www.geodan.nl> >> disclaimer <http://www.geodan.nl/disclaimer> >> > > -- > Dr. Peter Baumann > - Professor of Computer Science, Jacobs University Bremen > www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann> > mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de> > tel: +49-421-200-3178 <tel:%2B49-421-200-3178>, fax: +49-421-200-493178 <tel:%2B49-421-200-493178> > - Executive Director, rasdaman GmbH Bremen (HRB 26793) > www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com> > tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 <tel:%2B49-173-5837882> > "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083) > > > > > > -- > Frans Knibbe > Geodan > President Kennedylaan 1 > 1079 MB Amsterdam (NL) > > T +31 (0)20 - 5711 347 > E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl> > www.geodan.nl <http://www.geodan.nl> > disclaimer <http://www.geodan.nl/disclaimer> > -- Dr. Peter Baumann - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
Received on Wednesday, 17 June 2015 15:18:21 UTC