Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GeoShape improvements #1548

Open
danbri opened this Issue Mar 6, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@danbri
Copy link
Contributor

danbri commented Mar 6, 2017

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.

@danbri danbri self-assigned this Mar 6, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.