W3C home > Mailing lists > Public > public-sdw-wg@w3.org > June 2015

RE: Best Practice for encoding spatial coverage

From: <Simon.Cox@csiro.au>
Date: Thu, 18 Jun 2015 00:53:49 +0000
To: <andrea.perego@jrc.ec.europa.eu>, <frans.knibbe@geodan.nl>
CC: <public-sdw-wg@w3.org>
Message-ID: <2A7346E8D9F62D4CA8D78387173A054A6022C216@exmbx04-cdc.nexus.csiro.au>
However, note that GeoJSON requires (x,y) order (i.e. lon-lat) in all cases, regardless of CRS definition ... 

-----Original Message-----
From: Andrea Perego [mailto:andrea.perego@jrc.ec.europa.eu] 
Sent: Thursday, 18 June 2015 9:53 AM
To: Frans Knibbe
Cc: SDW WG Public List
Subject: Re: Best Practice for encoding spatial coverage

Hi, Frans.

Looking at what is currently used in the Web and by Web developers:


1. schema.org has a specific property fox bboxes - i.e., schema:box
(http://schema.org/box)

The bbox is encoded as follows:

"A box is the area enclosed by the rectangle formed by two points. The first point is the lower corner, the second point is the upper corner.
A box is expressed as two points separated by a space character."

The axis order used is lat / long, as said in the description of schema:GeoShape (http://schema.org/GeoShape), which also describes the encoding used:

"The geographic shape of a place. A GeoShape can be described using several properties whose values are based on latitude/longitude pairs.
Either whitespace or commas can be used to separate latitude and longitude; whitespace should be used when writing a list of several such points."


2. GeoJSON includes a "member" bbox to be used to "include information on the coordinate range for geometries, features, or feature collections" - see:

http://geojson.org/geojson-spec.html#bounding-boxes

The encoding used is as follows:

"The value of the bbox member must be a 2*n array where n is the number of dimensions represented in the contained geometries, with the lowest values for all axes followed by the highest values."


Maybe we can build upon these examples.

Andrea


On Wed, Jun 17, 2015 at 11:53 AM, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
> 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 (Spatial Coverage). That should point to a 
> dcterms: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.
>
>
> Greetings,
> Frans
>
>
>
> --
> Frans Knibbe
> Geodan
> President Kennedylaan 1
> 1079 MB Amsterdam (NL)
>
> T +31 (0)20 - 5711 347
> E frans.knibbe@geodan.nl
> www.geodan.nl
> disclaimer
>



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

----
The views expressed are purely those of the writer and may not in any circumstances be regarded as stating an official position of the European Commission.
Received on Thursday, 18 June 2015 00:54:49 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:31:17 UTC