-
Notifications
You must be signed in to change notification settings - Fork 47
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
Spatial coverage [RSC] #83
Comments
This is already possible using the Core Location Vocabulary that includes a class Geometry. |
Related to #82 |
I also like the use of the locn:geometry property for encoding geometries as literals. See also page 57 in GeoDCAT-AP. |
I don't follow, how can Assuming I've missed something and this can work,
However we have more sophisticated feature/geometry handling elsewhere, like in GeoSPARQL itself which has Geometry & Feature classes. Using GeoSPARQL, a site's location in SOSA:
I can't see any normative links from locn to GeoSPARQL though, only suggestions for use. Perhaps Andrea, a locn editor, can indicate the intention of locn? Otherwise, I'd be more inclined to allow the use of GeoSPARQL directly. |
locn:geometry would be a property of a dcterms:Location, as in the examples: GeoDCAT-AP page 57 or the SDW-BP example 15. Something like:
As @nicholascar suggests, this can indeed also be done directly using geosparql:hasGeometry. GeoSparql provides a normative way of representing geometries expressed as WKT or GML, although it leaves other serializations such as GeoJSON to future work.
|
is "coverage" the same as "the geometry"? The definition of locn:geometry is "Associates any resource with the corresponding geometry." DCAT may have a concept of "the" - i.e. there is a requirement that the geometry is a specific type with a specific characteristics... There is a difference between a geometry defining and indexable extent (normal use of coverage) and for example a 3D model of a city - and certainly most geographical features having area extents. To put this in perspective, some time ago i was looking at modelling the coastline - and there are something like 26 different definitions in Australian law - so there are in fact multiple possible geometries depending on the application domain , but most significantly, if you take a large entity - such as the state of Western Australia (or even one of the indigenous land claims in the state) you get a geometry of many MB from the authoritative dataset, but any most applications would need a generalised form. so, if you re-use a term with a broader semantics for a specific function, at some stage this needs to be declared. The qualified link to the geometry object gives you this AFAICT. You may need to specify that the dcterms:Location has the same meaning as you intend for "coverage" - or perhaps create a subclass of it with this explicit semantics. If the OWL model entails this when the subject of a dct:spatial relationship is a dcat:Dataset, then backwards compatibility is maintained with the use of dcterms:Location |
From the
So, given the domain constrains of |
Sorry to jump in here so late. I should probably provide a bit of context for explaining the reasons behind the design choices of So, the reason why the range of
Coming now to the use of DCAT didn't provide any guidance on this. Moreover, the GeoDCAT-AP WG re-stated the requirement of being able to directly specify the bbox as a literal. So, the choice of The use of Based on the implementation experiences I'm aware of, the use of BTW, this was also one of the issues discussed at length in the LOCADD CG (there's a page summarising the discussion), and then inherited by the SDWWG, but no solution has been provided. |
@rob-metalinkage said:
Well, as In GeoDCAT-AP (as in DCAT), the spatial coverage is specified by using |
@nicholascar said:
@nicholascar , I don't know if I have (at least, partially) answered to your question in my comment above. However, more details on this specific issue are provided in the LOCADD wiki page I mentioned: https://www.w3.org/community/locadd/wiki/Use_case:_Sub-properties_for_locn:geometry |
For geospatial data, spatial coverage should also be complemented by spatial resolution - see discussion at #84 (comment) |
See proposal for |
Back to spatial coverage: unfortunately there are at least three respectable serializations of geometry in common use in different parts of the community:
AFAIK WKT is the only one that also supports association with a Coordinate Reference System Then there are others, like GML, What3Words, ... The Spatial Data on the Web Best Practice is agnostic ... Should we attempt to provide any guidance? |
Compatibility between GeoJSON and JSON-LD 1.0 is problematic. I am not sure about JSON-LD 1.1 (see the discussion in w3c/json-ld-syntax#7). |
providing some guidance would be a boon to interoperability. Being able to specify different SRS for the geolocation is nice for generality, but for interoperability, settling for something simple like an EPSG-4326 bounding box is much better. Using Web UTM is popular, but won't work in polar regions. |
A plug for WKT here: it's much easier for the dataset processing my client agencies do to record WKT strings as RDF literals and then to pull those down and calculate spatial things with them as needed, given that Postgres etc can instantly use them. It woul dbe interesting to know what spatial representations things spatially-enabled triplestores like. Perhaps @pwin can comment since he uses such things. |
Thanks for that link @akuckartz IMO the key problem with the GeoJSON vs JSON-LD issue is that it is based on an incorrect assumption. GeoSPARQL deals with the boundary between semantics and mathematics more honestly, by switching to a micro-format (WKT) when the boundary is crossed. The semantics of the information is managed on the RDF side of the boundary ('it is a geometry!") while the mathematical representation of the geometry is managed on the WKT side of the boundary ("it is a nested, ordered set of numbers"). * A point in space is a unitary concept, but our mathematical systems require several numbers to represent it. The numbers are not independent since they change together if the CRS changes. |
I'm all for WKT, but I would like to re-state a couple of issues mentioned earlier in this thread (see #83 (comment)):
In my experience, these are the main issues people are stumbling upon. |
This issue was discussed by the DCAT subgroup on 6 Mar 2019, and I got an action to make a proposal. I think it is probably better to split the proposal in two, and I would first go for the issue concerning the fact that we lack specific properties for specifying bboxes and centroids. Proposal 1 So, my proposal nr. 1 is to define two corresponding properties in the DCAT namespace:
The range of these two properties may depend on the decision taken about proposal nr. 2 below, so for the moment I leave it undefined. Proposal 2 The proposal nr. 2 is about how to specify the geometry itself. In this case, I would ask for a vote on 3 possible proposals:
Proposals 2.a and 2.b address the issue I mentioned earlier in this discussion of reducing the "distance" in the graph between the dataset and the geometry itself. So, it gives a more flat specification of the spatial coverage compared with GeoSPARQL. Putting this into examples (re-using @nicholascar 's ones):
a:Dataset dct:spatial a:Location .
a:Location a dct:Location ;
locn:geometry "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> Point(-0.001475 51.477811)"^^gsp:wktLiteral .
a:Dataset dct:spatial a:Location .
a:Location a dct:Location ;
dcat:geometry "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> Point(-0.001475 51.477811)"^^gsp:wktLiteral .
a:Dataset dct:spatial a:Location .
a:Location a dct:Location ;
gsp:hasGeometry [
a sf:Point;
gsp:asWKT "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> Point(-0.001475 51.477811)"^^gsp:wktLiteral
] . Looking forward to your votes & feedback. |
Example 2.c seems to have some redundancy: sf:Point and Point(...). Is that necessary? |
@akuckartz said:
This is how the geometry will be represented and encoded in GeoSPARQL. The type of geometry is specified both at the level of class, and in the WKT (or GML) literal. |
I implemented proposals 1 & 2.a for you to review via the following PR #807 Preview here: |
LGTM ! |
Spatial coverage [RSC]
Provide means to specify spatial coverage with geometries.
Related use cases: Modeling spatial coverage [ID29]
The text was updated successfully, but these errors were encountered: