Re: Best Practice for encoding spatial coverage

Hi, Frans.

> [snip]
>
> The expression 'schema:box "50 4 52 6"' could be replaced (or accompanied)
> by 'georss:box "50 4 52 6"', but I assume the schema.org vocabulary is more
> widely used than the GeoRSS vocabulary, and more likely to be already
> included in the set of referenced vocabularies. On the other hand,
> schema.org also allows  'schema:box "50,4 52,6"', i.e. commas between
> latitude and longitude, while GeoRSS only allows whitespace. Having multiple
> possibilities for the format of the text literal is less web developer
> friendly, I think.

I don't see a dev issue here (e.g., the string can be normalised by
replacing commas with spaces). More important would be to state
clearly the syntax and semantics of this encoding.

Actually, a probably more "friendly" way to explain how to use it
would be to map numbers to cardinal directions - i.e., N E S W. Users
would be able to understand those numbers and remember their order
(clockwise) more easily.

> What do you think? Do we already have something that we can recommend as a
> best practice?

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

----
[1]http://lists.w3.org/Archives/Public/public-sdw-wg/2015Jun/0177.html
[2]http://lists.w3.org/Archives/Public/public-locadd/2014May/0036.html

Received on Friday, 19 June 2015 13:10:11 UTC