Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
GeoShape improvements #1548
Talking with Ed Parsons (Google + W3C Spatial Web WG cochair) about possible improvements to our base vocabulary, and to the proposed http://pending.webschemas.org/GeospatialGeometry + associated properties (#1375).
We looked at the way in which schema.org indicates exactly what a point or coordinate means. It has been a little vague but in a few places we mention "WGS84", which is a reference datum. He suggests we should instead talk about coordinate (or spatial) reference systems instead, since there can be many of these for the same reference datum. For example, WGS84 is used in both CRS EPSG 4326 and EPSG 4979 (which is a 3D equivalent of EPSG 4326); see also EPSG 32611, which the universal transverse mercator projection for California, which also uses WGS84. https://epsg.io/4326 is a good reference. We ought to find a way to clarify this nuance in our documentation somewhere, without scaring people away.
Also discussed how best to keep things simple, and agreed that the language of "typically..." works better than "default" in logic-based triple languages like schema.org (i.e. RDF-ish representations). This is because we might want to add a property to GeoShape for indicating the CRS (e.g. EPSG 4326 or another), but we would need to anticipate how systems ought to handle things if that explicit triple dropped off (e.g. via queries that neglected it). By saying "typically" we indicate that we don't know for sure; if we said "default" then that is a much stronger claim. In practice various heuristics are likely to be used.
Finally we looked at GeospatialGeometry and the properties drafted against it. The property semantics are somewhat overloaded by design, in that they could apply between a pair of explicit geometries, a pair of places, or a mix of a place and a geometry. While both Place and GeospatialGeometry / GeoShape can to some extent be vague, generally the former is vaguer (though depending on how it is described - e.g. name vs postcoded - and what is being named, e.g. a street vs something like "East London"). We agreed that it made sense to have a single set of spatial relation properties that apply to all these scenarios and that the definition ought to be applicable for each.