Align getSRID and inCRS

[nicholascar]

GeoSPARQL 1.0 has a function getSRID. This returns an xsd:anyURI with input of a geo:geomLiteral.

GeoSPARQL 1.1 has a new property asCRS with domain geo:Geometry.

Should we unify the terminology here, SRID v. CRS? Are they really synonyms?

Also, can we introduce a consistency check (perhaps non-normative), something like:

ASK
WHERE {
    ?g a geo:Geometry ;
         geo:hasSerialization ?ser ;
         geo:inCRS ?crs .

    FILTER (getSRID(?ser) = ?crs)
}

[dr-shorthair]

Yes, they ought to be aligned. Since SRID was used first, then I guess it will have to be inSRS or even inSRID.

[nicholascar]

Since SRID was used first, then I guess it will have to be inSRS or even inSRID.

Perhaps, unless we view SRID as a lesser / specific version of CRS and convert to CRS (by implementing a synonym function getCRS)

[situx]

I would like to point out that some implementers according to our GeoSPARQL benchmark experience implemented the getSRID function in the wrong assumption that SRID would represent an xsd:integer value as it is the case in other non-semantic database implementations see POSTGIS ST_SRID https://postgis.net/docs/ST_SRID.html So people might intuitively think about an integer and not a URI when reading getSRID. In my subjective experience I would associate CRS more with a URI than SRID, but maybe I am the only one ;)

[nicholascar]

people might intuitively think about an integer and not a URI when reading getSRID

I agree that this would be the common expectation.

Perhaps we can change - a breaking change - to getSRID -> int & getCRS -> IRI. I will propose this for a WG meeting teleconf discussion (in addition to here).

[mathib]

from a non-GIS perspective, I believe CRS is more widely-known as a concept compared to SRID :)

[FransKnibbe]

The "ID" bit in SRID stands for "identifier". But a URI is more than an identifier; it also direct access to data describing the thing. Also, in other spatial standards, IFC for example, the term is CRS. So my preference would be to use CRS where possible and phase out the use of SRID.

[nicholascar]

my preference would be to use CRS where possible and phase out the use of SRID.

Mine too. I will create a PR to maintain SRID in GeoSPARQL 1.1. but indicate that CRS is the preferred terms. We may drop SRID as a property in a future GeoSPARQL 2.0 where we make breaking changes.

[FransKnibbe]

For completeness, we should also consider Spatial Reference System (SRS). It is a term already used in the current GeoSPARQL specification, and its advantage is that it is more inclusive than CRS. After all, it is possible to have a reference system that does not use coordinates. What3words for example.

[FransKnibbe]

One more thing to say on behalf of Spatial Reference System (SRS): it could be understood and defined as to apply to all spatial properties of a Geometry. That way there would be no need to supply units for spatial resolution and properties indicating size (SpatialMeasure at the moment). The units defined in the SRS will always be used. That, in turn, would make certain queries and calculations a lot easier (e.g. gimme data layers that match my map's scale and CRS).

[nicholascar]

I have replaced all mentions of CRS with SRS and renamed the property inCRS to inSRS in by "oncethrough" branch (see PR #102). I've not touched the legacy getSRID

[situx]

Closing since this has been resolved