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

Re: Best Practice for encoding spatial coverage

From: Frans Knibbe <frans.knibbe@geodan.nl>
Date: Mon, 22 Jun 2015 12:55:15 +0200
Message-ID: <CAFVDz43gbZNRmP_BA2C3Q1V69Fdj_kO-Zfrh4HEMUggMhq5Z=A@mail.gmail.com>
To: Andrea Perego <andrea.perego@jrc.ec.europa.eu>
Cc: "Mcgibbney, Lewis J (398M)" <Lewis.J.Mcgibbney@jpl.nasa.gov>, SDW WG Public List <public-sdw-wg@w3.org>
2015-06-19 15:09 GMT+02:00 Andrea Perego <andrea.perego@jrc.ec.europa.eu>:

> [snip]
> About a recommended property for bboxes, I don't have a "safe"
> proposal - e.g., see Raphaƫl's comment on schema:box [1].
> About the encoding, the schema.org format might be considered
> specifically for bboxes. But as far as geometries in general are
> concerned, my preference goes to WKT, since it matches most of the
> "Web" requirements - as Simon already highlighted during the LOCADD's
> conversation on "space and time" [2].
> In particular:
> - it is able to express any geometry
> - it is the most compact human-readable encoding currently available
> - its syntax is simple and the semantics clear (enough)
> - it is case and "space" insensitive - i.e., all the following
> variants are valid: " point(0 0)" "PoinT ( 0  0)", " POINT(0  0 )  "
> - it is widely supported by Web tools and platforms
> Andrea

Yes, there is something to be said for WKT. I described the need for web
developers to be able to extract the numbers for map configuration as
easily as possible. But another major usage for spatial extent metadata is
discovery of datasets based on spatial filters. For example: get all
datasets that overlap with a certain rectangle (which could be the extent
of a map) from a dataset catalog (dataset index). For that scenario, one
needs support of spatial operators (e.g. st_overlaps) and I assume that
such support is easier to achieve with encodings that are part of the
current set of OGC standards, or in other words, encodings that are firmly
rooted in existing spatial semantic frameworks.

The web developer who just wants the numbers should go into a bit more
trouble though. To be safe, he/she needs to know how to parse WKT. But
chances are that a javascript library that can do this will be already
included in the project because the same library will be used to work with
the map.

Perhaps it is somehow possible to have a box as a special kind of geometry
in WKT? A box is simpler shape than a polygon so it is easier to support
and easier to work with. Luckily we have this idea covered (in a sense) by
the Bounding box and centroid requirement


Frans Knibbe
President Kennedylaan 1
1079 MB Amsterdam (NL)

T +31 (0)20 - 5711 347
E frans.knibbe@geodan.nl
disclaimer <http://www.geodan.nl/disclaimer>
Received on Monday, 22 June 2015 10:55:47 UTC

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