Better GeoSPARQL conformity

[patrickbr]

We should be fully conform with the GeoSPARQL standards for types geo:SpatialObject and geo:Feature.

In particular, a geo:Feature must have the following properties: geo:hasGeometry, geo:hasDefaultGeometry, geo:hasCentroid and geo:hasBoundingBox

That is, osm:Nodes, osm:Ways, osm:Relations and osm:Areas should be of type geo:Feature and offer these properties.

As far as I understand it, all of the properties geo:hasGeometry, geo:hasDefaultGeometry, geo:hasCentroid and geo:hasBoundingBox must then point to an object of type geo:SpatialObject. These must implement geo:hasSize, geo:hasMetricSize, geo:hasLength, geo:hasMetricLength, geo:hasPerimeterLength, geo:hasMetricPerimeterLength, geo:hasArea, geo:hasMetricArea, geo:hasVolume and geo:hasMetricVolume.

So far, I don't see any problem with implementing this.

However, AFAIK (@lehmann-4178656ch, @Danysan1, please correct me) , sfIntersects and sfContains should be properties between geo:SpatialObjects. This would mean that we cannot write queries like

SELECT ?osm_id ?hasgeometry WHERE {
  osmrel:1960198 ogc:sfContains ?osm_id .
  ?osm_id geo:hasGeometry/geo:asWKT ?hasgeometry 
}

anymore. They would then look like this:

SELECT ?osm_id ?hasgeometry WHERE {
  osmrel:1960198 geo:hasGeometry ?geoma .
  ?osm_id geo:hasGeometry ?geomb .
  ?geoma ogc:sfContains ?geomb .
  ?geomb geo:hasGeometry/geo:asWKT ?hasgeometry 
}

@hannahbast, @joka921, is that a problem?

See also https://github.com/ad-freiburg/qlever/issues/678#issuecomment-1867066812