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#>.
@prefix geom:  <http://data.ign.fr/def/geometrie/>.
@prefix dbpo:  <http://dbpedia.org/ontology/>.
@prefix xsd:   <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>:

> 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>
> *Date: *Thursday, 8 November 2018 at 7:31 pm
> *To: *Nicholas Car <Nicholas.Car@csiro.au>
> *Cc: *"public-sdwig@w3.org" <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>:
>
> 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>
> *Sent:* Monday, 5 November 2018 6:22 PM
> *To:* 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
>
>
>
>