- From: Frans Knibbe <frans.knibbe@geodan.nl>
- Date: Mon, 22 Jun 2015 12:55:15 +0200
- 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>
- Message-ID: <CAFVDz43gbZNRmP_BA2C3Q1V69Fdj_kO-Zfrh4HEMUggMhq5Z=A@mail.gmail.com>
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 <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#BoundingBoxCentroid> . Regards, 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 <http://www.geodan.nl/disclaimer>
Received on Monday, 22 June 2015 10:55:47 UTC