Re: Good practice for publishing geometry of a thing as different geometry types?

Lots of overlapping concerns here - but one unified way of looking at this
is to look at the OpenWorld approach - if we assume an object can have
properties we dont know about (yet) then we have a basic model for an object
- object has an identifier and is a member of a set (a registration
viewpoint)
We can then provide an addition view of that object, with a "named
collection of properties" using the Linked Data API semantics - but
basically what we do every time we define a FeatureType. so for "spatial"
features we have
- object isa FeatureType has p1,p2,p3 etc

This view can then be accessed in multiple serialisations (Content-type
negotiation) and potentially also language negotiation.

So in principle one identifier maps to multiple resources. An we accept
that if we work on the web.

but there is no reason to limit the number of views to 1 - and if we accept
the Web architecture that would be an inconsistent thing to do anyway.

So - you can have

FeatureTypes with multiple geometry properties

AND/OR

Multiple FeatureTypes (e.g. simple features) bound to different geometry
models

AND/OR

content negotiation to access different encodings of a feature ( perhaps
CRS choice is analagous to language choice for text?)

but you do probably end up with an architectural requirement to advertise
what views are available... :-)

In summary, I recommend publishing multiple encodings using different
information models, but consistent under an OpenWorld interpretation - i.e.
you should not have different models using the same property predicate with
different values unless it is truly a multi-valued property and these are
separate valid values.  My suspicion is that owl:sameAs ought to apply
across instances using different views (multiple "information resources"
c.f. http-range-14) - as in you can safely mix the assertions about the
object from multiple views. This last point needs some serious thinking,
but I believe the fundamental pattern of supporting multiple views is an
inevitable consequence of the Web architecture and the potential for
multiple clients.

Cheers
Rob Atkinson








On Wed, 11 May 2016 at 00:44 Joshua Lieberman <jlieberman@tumblingwalls.com>
wrote:

> Franz,
>
> There are certainly many shades of difference that can distinguish how
> models are constructed and expressed. Serialization may be the equivalent
> (in a literal) of the difference between RDF/XML and Turtle. It’s
> complicated for CRS since WKT requires any CRS different from EPSG4326 to
> be explicitly included in the text string, although in principle it’s the
> same geometry. The next step up is probably realization of a geometry for
> different scales / levels of generalization. These are all the same
> conceptual geometry but with a different realization in coordinate
> positions. If we go to the difference between a feature boundary and a
> feature centroid, that’s more clearly a different geometric model of the
> feature. It’s less clear that there is a difference in geometry type
> between a road centerline and a road marginal line, although it’s clearly a
> different property of the feature.
>
> From a practical viewpoint of geometries living independently on the Web
> that can be both discovered and linked to features, it makes sense for
> these properties (CRS, geometric object type, generality) to be top level
> functional geometry properties, and there should be a set of feature
> geometry properties (envelope, centroid, boundary, hull, buffer are in
> 19107) so that the appropriate property can be chosen for a given
> application and people don’t all end up in Kansas looking for something in
> the USA because the centroid property is not identified as such.
>
> Whether alternate serializations should be allowed in one geometry object
> is less clear. It is ambiguous in 19107, not allowed in GML, generally not
> in Simple Features, and not forbidden in GeoSPARQL. My sense is that
> serializations themselves are easily transformable and multiple coordinate
> strings are too useful for composite geometries and other purposes to risk
> confusion. GeoJSON is an issue here because it requires one serialization
> and one CRS to be present whether or not another one is desirable. There
> doesn’t seem to be an prohibition against multiple geometry elements per
> feature, though, so it makes sense to put different serializations into
> different GeoJSON geometry objects as an extension to support JSON-LD / RDF
> (not recognized by the GeoJSON specification, of course).
>
> Josh
>
>
> On May 10, 2016, at 6:09 AM, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>
> Hello Josh, all,
>
> Sorry for misunderstanding what you meant. But it is good to share
> thoughts about when and how to split geometry data in different objects.
> Probably things like this deserve a place in the BP document.
>
> You mentioned different serializations. That makes me wonder what a
> serialization is. If I change the CRS or the type of a geometry, I get a
> new geometry. That more or less follows from the definition that a geometry
> is a model of a shape. If I use a different CRS or different geometry type,
> I use a different model. In other words, if the actual sequence of numbers
> in the coordinates changes, we have a new geometry. So is that sequence of
> numbers the serialization? I could use the same numbers in a WKT string or
> in a GML object. Isn't that also serialization? Probably we need two terms,
> one for different sequences of coordinates, and one for packaging the same
> sequence of coordinates in different ways. In notice that the GeoSPARQL
> standard talks of WKT and GML as different serializations.
>
> To me it would make sense to let the same coordinate sequence in different
> data types be part of the same geometry - they are different expressions of
> the same model. For example:
>
> ex:geom6789
>   a geom:Geometry, geom:Point ;
>   geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>   geosparql:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
> POINT(131216.968 461378.333)"^^geosparql:wktLiteral ;
>   geosparql:asGML "<gml:Point
> srsName="EPSG:28992"><gml:coordinates>131216.968,461378.333</gml:coordinates></gml:Point>"^^geosparql:gmlLiteral
> .
>
> Regards,
> Frans
>
>
>
>
> 2016-05-09 18:05 GMT+02:00 Joshua Lieberman <jlieberman@tumblingwalls.com>
> :
>
>> Yes, of course a geometry is a model. For that matter, a feature is a
>> model, but one that directly references the “real world". The question was
>> really whether multiple serializations can be included in a geometry, e.g.
>> for different scales or CRS’s. It makes sense to me, but upon
>> investigation, it is just not something that is practiced, although there
>> is no present axiom in GeoSPARQL that prevents it. It doesn’t seem to be an
>> explicit part of either 19107 or GML, and the general semantic is that
>> multiple positions represent a composite serialization of a geometry, not
>> alternate ones.
>>
>> So we should probably stick with each unique combination of role
>> (centroid, etc. are actually defined terms in 19107), scale, CRS,
>> interpolation method, etc. as a distinct geometry.
>>
>> Backlinks from geometry to feature are problematic. If geometries are to
>> be stored separately, it’s probably to share them.
>>
>> Josh
>>
>>
>> On May 9, 2016, at 9:50 AM, Bill Roberts <bill@swirrl.com> wrote:
>>
>> But I suspect at the heart of your comments is the question what a
>>> geometry really is. There are at least two possibledefinitions:
>>> A) The geometry of a thing is its real world shape.
>>> B) The geometry of a thing is a model of its real world shape.
>>
>>
>> I agree: in practice, (B) is always the case.  No representation of
>> geometry will be completely accurate, and different levels of approximation
>> (different models) are appropriate in different contexts.
>>
>>
>>
>> On 9 May 2016 at 15:35, Frans Knibbe <frans.knibbe@geodan.nl> wrote:
>>
>>> Hello Josh,
>>>
>>> It could be possible to add more context to the geometries, to express
>>> that they are a footprint or a centroid for instance. But I think that
>>> extra context will not be crucial for many use cases. Especially since
>>> there is no standard vocabulary for that extra meaning yet  (although the
>>> vocabulary I try to use does have a centroid property: http://data.ign
>>> .fr/def/geometrie#centroid).
>>>
>>> But I suspect at the heart of your comments is the question what a
>>> geometry really is. There are at least two possible definitions:
>>> A) The geometry of a thing is its real world shape.
>>> B) The geometry of a thing is a model of its real world shape.
>>>
>>> I think I silently use definition B. But if others assume definition A
>>> that could lead to problems. I am ashamed to have to admit that I don't
>>> know the official OGC party line in this case. But it would be great if
>>> an updated GeoSPARQL standard could have a direct link to a core
>>> definition of geometry.
>>>
>>> As for your last example (two coordinate strings that differ in their
>>> CRS) in my line of thinking (adherent of definition B) that would be
>>> modelled as separate geometries. An extended example:
>>>
>>> ex:location1234
>>>    a dcterms:Location ;
>>>    locn:geometry ex:geom1234_1, ex:geom1234_2, ex:geom1234_3,
>>> ex_geom1234_4 ;
>>>
>>> ex:geom1234_1
>>>    a geom:Geometry, locn:Geometry, geom:Point ;
>>>    locn:location ex:location123 ;
>>>    geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>>>    geosparql:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>> POINT(...)"^^geosparql:wktLiteral .
>>>
>>> ex:geom1234_2
>>>    a geom:Geometry, locn:Geometry, geom:Polygon ;
>>>    locn:location ex:location123 ;
>>>    geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>>>    geosparql:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>> POLYGON(...)"^^geosparql:wktLiteral .
>>>
>>> ex:geom1234_3
>>>    a geom:Geometry, locn:Geometry, geom:Point ;
>>>    locn:location ex:location123 ;
>>>    geom:crs <http://www.opengis.net/def/crs/OGC/1.3/CRS84> ;
>>>    geosparql:asWKT "POINT(...)"^^geosparql:wktLiteral .
>>>
>>> ex:geom1234_4
>>>    a geom:Geometry, locn:Geometry, geom:Polygon ;
>>>    locn:location ex:location123 ;
>>>    geom:crs <http://www.opengis.net/def/crs/OGC/1.3/CRS84> ;
>>>    geosparql:asWKT "POLYGON(...)"^^geosparql:wktLiteral .
>>>
>>>
>>> Note that I also included a backlink from geometry to location (locn
>>> :location).
>>>
>>> The question still is: can this be considered a good practice, given
>>> currently available standards/vocabularies?
>>>
>>> Regards,
>>> Frans
>>>
>>>
>>>
>>>
>>>
>>>
>>> 2016-05-04 19:10 GMT+02:00 Joshua Lieberman <
>>> jlieberman@tumblingwalls.com>:
>>>
>>>> Do you mean:
>>>>
>>>>
>>>> ex:location1234
>>>>    a dcterms:Location, ex:feature ;
>>>>    ex:centroid ex:geom1234 ;
>>>>    ex:footprint ex:geom6789 .
>>>>
>>>> ex:geom1234
>>>>    a geom:Geometry, gsp:Point ;
>>>>    geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>>>>    gsp:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>>> POINT(...)"^^geosparql:wktLiteral .
>>>>
>>>> ex:geom6789
>>>>    a geom:Geometry, gsp:Polygon ;
>>>>    geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>>>>    gsp:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>>> POLYGON(...)"^^geosparql:wktLiteral .
>>>>
>>>>
>>>> In that case, the range of gsp:asWKT is not a geometry, but a set of
>>>> coordinate positions locating the geometry, so “POLYGON” is the format of
>>>> the coordinate string, not the geometry class per se.
>>>>
>>>>
>>>> The coordinate information is more problematic, since one could easily
>>>> want to have
>>>>
>>>> ex:geom6789
>>>>    a geom:Geometry, gsp:Polygon ;
>>>>    geom:crs <http://www.opengis.net/def/crs/EPSG/0/28992> ;
>>>>    gsp:asWKT "<http://www.opengis.net/def/crs/EPSG/0/28992>
>>>> POLYGON(...)"^^geosparql:wktLiteral .
>>>>
>>>>    gsp:asWKT "POLYGON(...)"^^geosparql:wktLiteral .
>>>>
>>>>     gap:asGML “…”
>>>>
>>>> I consider asWKT to be problematic for this reason, and one ground for
>>>> updating the GeoSPARQL standard.
>>>>
>>>>
>>>>  Josh
>>>>
>>>>
>>>
>>
>>
>
>