RE: Area of spatial objects

Hi Frans,

Thanks for these suggestions, and good use of Australian coordinates and datum!

I understand the issue of the inseparable CRS as this is something that has bothered me for a while. I’ll look over the IGNF ontology now as you indicate it could be twisted for use to avoid this.

However, I’m not certain about Feature > Geometry > Area. While Area is CRS-dependent, I don’t find it intuitive that area is a type of or within a Geometry. I find it more intuitively an observed property that just happens to be dependent on measurement systems, here CRS. This put it, for me, in the same category as a measured geometry but it doesn’t need to be within a geometry. Having said all that, I do indeed see the logic of what you propose so I think I will have to test out some real data, formulated in both ways, and try and compare representational power or querying results. We do have a lot of data we are working on right now so I’ll do this shortly. Here, for instance, is a water catchment, delivered by a large Linked Data API we are now working on, whose area representations we could improve: http://geofabricld.net/catchment/12502258.


Using your suggested formulation, I would probably represent that catchment’s area like this:

<featureX/geometry2> a geo:Geometry;
  dbpo:area "0.0005254"^^xsd:double; # needs checking
  geom:crs <http://www.opengis.net/def/crs/EPSG/0/????>; # needs checking
.

<featureX/geometry2> a geo:Geometry;
  dbpo:area "0.0005125"^^xsd:double; # needs checking
  geom:crs <http://www.opengis.net/def/crs/EPSG/0/????>; # needs checking
.

I’ll get back to you (this thread) after some tests!

Cheers,

Nick



From: Frans Knibbe <frans.knibbe@geodan.nl>
Sent: Saturday, 17 November 2018 12:11 AM
To: Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au>
Cc: public-sdwig@w3.org; Cox, Simon (L&W, Clayton) <Simon.Cox@csiro.au>
Subject: Re: Area of spatial objects

Hello Nick,

Here is a stab at how the example could be coded:

@prefix geo:   <http://www.opengis.net/ont/geosparql#<http://www.opengis.net/ont/geosparql>>.
@prefix geom:  <http://data.ign.fr/def/geometrie/>.
@prefix dbpo:  <http://dbpedia.org/ontology/>.
@prefix xsd:   <http://www.w3.org/2001/XMLSchema#<http://www.w3.org/2001/XMLSchema>>.
@base <http://www.example.com/>.

<FeatureX> a geo:Feature;
  geo:hasGeometry
    <featureX/geometry1>
    ,<featureX/geometry2>
    ,<featureX/geometry3>;
.

<featureX/geometry1> a geo:Geometry;
  geo:asWKT "Point(149 -35)"^^geo:wktLiteral;
.

<featureX/geometry2> a geo:Geometry;
  dbpo:area "123.45"^^xsd:double;
.

<featureX/geometry3> a geo:Geometry;
  geom:crs <http://www.opengis.net/def/crs/EPSG/0/3577>;
.

I have to admit there are some unsatisfactory elements. One thing is that this touches upon a point that I consider a current weakness in GeoSPARQL: CRS is not a separate property of a geometry, but it is supposed to be part of the literal containing the coordinates. I hope CRS classes and properties can be added to a future version of GeoSPARQL. In the example an ontology made available by the French geographical institute is used. It does have separate modelling for CRS. But I cheated a bit: the range of the geom:crs property is http://data.ign.fr/def/ignf#CRS, which does not allow just any CRS URI. And the CRS URI for Albers that I used in the example does not work yet, but it something that could be arranged with the OGC. An alternative is to code and publish the CRS you would like to use in compliance with the IGNF model (http://data.ign.fr/def/ignf<http://data.ign.fr/def/ignf#CRS>). Then there wouldn't be any semantic friction, and as a bonus the world could then enjoy a definition of the Albers projection in RDF.

Given that QUDT offers a definitions of the quantity (area) and the unit (square metre) as individuals, but does not seem to have a definition of an area property, and neither does GeoSPARQL, I think would opt for the practical solution of using http://dbpedia.org/ontology/area. As others have pointed out, having a separation of quantity and unit would be better, but I don't think using dbpo:area is wrong per se. At least I think it less of a problem than combining CRS and coordinates in one literal :-)

In the example above I did not use blank nodes for the geometries, giving the opportunity to make statements like <featureX/geometry2> owl:sameAs <featureX/geometry3> in the future.

As for specifying dimension: it could be useful information for some, I think. Suppose the spatial thing is essentially a 3D thing, a building for example, then it could be useful to know whether the area was determined using a 3D or a 2D representation.

Anyway, this remains an interesting use case and I think it shows there is still some work left to do in semantics for spatial data on the web.

Greetings,
Frans
Op ma 12 nov. 2018 om 13:52 schreef Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au<mailto:Nicholas.Car@csiro.au>>:
Hi Frans,

Thanks for the follow-up reply. Yes, I could do as you say, perhaps something like this:

<Feature_X> a geo:Feature ;
  geo:hasGeometry [
    # a normal GeoSPARQL Geometry, Point, Polygon etc.
    …
  ],
 [
    geo:dimension 1 ;  # not sure how useful this is
    qudt:numericValue “12345678”^^xsd:decimal ;
    qudt:unit qudt:SquareMeter ;  # more direct than via a CRS
    …
  ]
  …
.


But this still leaves me with no intuitive way to indicate that the geometry here is actually the well-known property “area”. For that I would either need a Geometry subclass or a typing to indicate area. Unless you have other ideas?

Also, you mentioned I might like to try geometries “one with only an area, one with an area and a CRS and one with just coordinates”. How would I indicate, using GeoSPARQL, a Geometry’s CRS without indicating coordinates? Would I use an EMPTY POINT like this geo:asWKT "<http://www.opengis.net/def/crs/EPSG/0/4283> POINT EMPTY”^^geo:wktLiteral or is there a way to indicate a Geometry’s CRS without tying that CRS in to a asWKT or asGML?

Is it possible to indicate an area within the measure dimension of a WKT representation of a geometry leaving all coordinate values empty perhaps?

Thanks,

Nick


From: Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>
Date: Thursday, 8 November 2018 at 7:31 pm
To: Nicholas Car <Nicholas.Car@csiro.au<mailto:Nicholas.Car@csiro.au>>
Cc: "public-sdwig@w3.org<mailto:public-sdwig@w3.org>" <public-sdwig@w3.org<mailto:public-sdwig@w3.org>>
Subject: Re: Area of spatial objects

Hello Nick,

I don't think it would be problem if the coordinates of the geometry are unknown. In that case the property with the coordinates (e.g. geosparql:asWKT) would be absent. Features with a point geometry and an area could be published as a feature having two geometries: one with coordinates and one with an area. The other examples you mentioned could be dealt with the same way. For instance, have a feature with three geometries - one with only an area, one with an area and a CRS and one with just coordinates. There would then be a future option to specify that some of those geometry representations are actually the same thing.

I am not saying this way of publishing your data is better than another, but I do think it is possible. And perhaps this method can be used together with another method, leaving it up to the data consumer how she/he/it wants to query the data.

Regards,
Frans

Op wo 7 nov. 2018 om 13:55 schreef Car, Nicholas (L&W, Dutton Park) <Nicholas.Car@csiro.au<mailto:Nicholas.Car@csiro.au>>:
Hi Frans,

What if I wanted to publish Features’ areas without also publishing geometries? What about features with a point geometry and an area, no polygon. Also, I have data where an area is given and also a polygon but I don’t know for sure if the area was calculated from the polygon. In fact I have data with an area and an Albers area and a geometry and don’t really know what happened to make which.

So, I want to be able to represent area as a spatial property of a feature, independently of any geometry. For this I will try using Observations and Measurements-style mechanics for this.

I think I might use subclassing of a sosa:ObservableProperty (https://www.w3.org/TR/vocab-ssn/#SOSAObservableProperty) to express spatial properties such as area and then relate then to a geo:Feature which would also, by SOSA logic, be a sosa:FeatureOfInterest. I may invent modelling to relate that spatial property to a geometry, but this wouldn’t be required, just nice to have if known.

Cheers,

Nick

From: Frans Knibbe <frans.knibbe@geodan.nl<mailto:frans.knibbe@geodan.nl>>
Sent: Monday, 5 November 2018 6:22 PM
To: public-sdwig@w3.org<mailto:public-sdwig@w3.org>
Subject: Re: Area of spatial objects


Hi Nick,



I wonder: Doesn't the fact that multiple areas for a single spatial thing are published mean that the areas are calculated from different geometric representations of that spatial thing? That would logically make the area a property of a geometry. Besides, the geometry instance could be used to link to the CRS (e.g. Albers), ideally by URI.



CRS data linked to a geometry could also give access to the basic unit of the CRS (e.g. meter) and through that provide information on the units of properties derived from the geometry (like the area), but that would demand a fair amount of reasoning on the part of the data consumer.



Regards,

Frans