Virtuoso does not recognize GeoSPARQL CRS

[alejandrofcarrera]

The current version of Virtuoso does not allow load RDF data with GeoSPARQL plus CRS.

The official document of this link says that geo:hasGeometry property is linked to an object with a property geo:asWKT and a datatype geo:wktLiteral.

At the beginning of this last datatype, there is an optional URI like this http://www.opengis.net/def/crs/.... If it is no exist, the user might assume that CRS will be WGS84 by default (Virtuoso does this), but you can use it for another CRS like EPSG:23030 http://www.opengis.net/def/crs/EPSG/0/23030.

This is important for know CRS may be used with ST_Transform for example.

@prefix geosparql: <http://www.opengis.net/ont/geosparql#> .

Valid:

<http://example.org/1/geometry>
        geosparql:crs "<http://www.opengis.net/def/crs/OGC/1.3/CRS84>" ;
        geosparql:asWKT "POLYGON ((-3.70 40.42, ...))"^^geosparql:wktLiteral .

Invalid:

<http://example.org/1/geometry>
        geosparql:crs "<http://www.opengis.net/def/crs/EPSG/0/23030>" ;
        geosparql:asWKT "POLYGON ((439930.8579 4475096.6375, ...))"^^geosparql:wktLiteral .

Invalid:

<http://example.org/1/geometry>
        geosparql:crs "<http://www.opengis.net/def/crs/OGC/1.3/CRS84>" ;
        geosparql:asWKT "<http://www.opengis.net/def/crs/OGC/1.3/CRS84> POLYGON ((-3.70 40.42, ...))"^^geosparql:wktLiteral .

Invalid:

<http://example.org/1/geometry>
        geosparql:crs "<http://www.opengis.net/def/crs/EPSG/0/23030>" ;
        geosparql:asWKT "<http://www.opengis.net/def/crs/EPSG/0/23030> POLYGON ((439930.8579 4475096.6375, ...))"^^geosparql:wktLiteral .

Issues relationated: #295 #274 #195.

System:
Linux precise64 3.2.0-23-generic #36-Ubuntu SMP x86_64 x86_64 x86_64 GNU/Linux
Virtuoso 7.20.3214 (stable & develop branch)

[HughWilliams]

We are scheduling to look into this ...

[p1d1d1]

This was ok in Virtuoso 6. Tested on debian

[VladimirAlexiev]

geosparql:crs is not mentioned in the GeoSPARQL standard, nor the ontology. What's the purpose of using a non-standard property, and where is it described?

[rtroncy]

Correct, crs is not a property defined by GeoSPARQL. You may want to use instead the property <http://data.ign.fr/def/geometrie#crs> which does exactly this.

[VladimirAlexiev]

GeoSPARQL mandates the CRS should be embedded as URL in the WKT (and I guess similarly for GML). What is the purpose of also putting it out as a separate property?

[p1d1d1]

CRS is part of the asWKT (and GML) representation.

"<http://www.opengis.net/def/crs/EPSG/0/4326> Point(33.95 -83.38)"^^<http://www.opengis.net/ont/geosparql#wktLiteral>

The CRS URI is optional and if missing, then CRS84 is assumed. Meaning if you have something else than CRS84, then you have to declare the URI of your CRS.
This is my understanging of [1] chapter 8.5

[1] https://portal.opengeospatial.org/files/?artifact_id=47664

[rtroncy]

GeoSPARQL mandates the CRS should be embedded as URL in the WKT (and I guess similarly for GML). What is the purpose of also putting it out as a separate property?

The added value of having the crs value in a separate property is to simply avoid to parse a string to locate the CRS URI! As some people prefer to encode the geometry in structured properties rather than a complex literal to parse

[IvanMikhailov]

Virtuoso supports EWKT , i.e. "SRID=nnnn; FEATURETYPE(details)" syntax, the support of IRI prefix is coming soon, the support of details of an arbitrary custom CS as a prefix is delayed because it has some scalability issues (now Virtuoso assigns 16-bit IDs to coordinate systems, that's more than enough for all well-known SRIDs around the world but the use of arbitrary CS-es with rounding errors etc. may easily run out of this limit).

However there will be a restriction on IRIs as prefixes. Well-known IRIs like "http://www.opengis.net/def/crs/EPSG/x/yyyyy" or "http://www.opengis.net/def/crs/OGC/x.x/yyyyy" will be ok out of the box. Any other IRIs must be explicitly declared before use, in a separate transaction, and application must take care on replicating this declaration to every server that is subscriber of its data with this IRI.

[VladimirAlexiev]

@rtroncy But GeoSPARQL is a standard that repositories (are supposed to) follow. If you also find value in putting the CRS in a separate property then fine, but you need to do this in addition to conforming to the standard (i.e. redundantly). http://data.ign.fr/def/geometrie#crs is just as non-standard as a made-up prop geo:crs. RDF's freedom to add properties doesn't mean freedom not to follow standards.

You can't interpret a WKT without knowing the CRS (eg EPSG has inverted lat/lon axes), so from that point of view having the CRS as integral part of the literal is a good design. I'm not sure what is the value of separating just the CRS if you keep the rest as opaque literal (why not also split out POINT features into wgs:long, wgs:lat fields?)

@IvanMikhailov

Any other CRS IRIs must be explicitly declared before use, in a separate transaction...

I didn't even know there is such freedom. Sounds like a great extension.

the use of arbitrary CS-es with rounding errors etc

AllegroGraph has a similar thing in its n-dimensional indexing: you predeclare the granularity of time and space axes in a datatype, and the index is built conforming only to those granularities. (It doesn't follow any standard, and the indexing didn't seem particularly smart: striping along X axis.)

But is it good design to hard-code the granularity into the CRS? The meaning of a WKT literal doesn't change as you change the granularity: that is merely an auxiliary instruction to the indexer.

[rtroncy]

@VladimirAlexiev Standards are evolving. This new property does not come from out of the blue, but from IGN, the French National Geographic Institute which is also one of the main contributors to standards. It was heavily discussed by the W3C/OGC joint group on Spatial on the Web, and having this explicit property is recognized as a good practice in standards, read here

[VladimirAlexiev]

@rtroncy At that reference I see discussion of the importance of CRS, but not a recommendation to put it in a separate prop, can you quote?

GeoSPARQL hasn't evolved since 2012-04-27, and still the state of adoption by data providers is lacking (see linked issues). Complying to ONE standard by the wide user communities is hard, complying to several is harder...

A cursory examination of http://data.ign.fr/def/geometrie shows that it fully expands geo data, down to individual points and their x,y,z (and m) coordinates. From this point of view, making ign:crs a separate property is obligatory. But wouldn't this produce too many triples? Are there significant amounts of data using this ontology? I can't get a response from http://data.ign.fr/endpoint.html, in particular for

SELECT (count(*) as ?c) WHERE {
?s ?p ?o .
}

[alejandrofcarrera]

Sorry for the big delay, but GitHub didn't notified me about the changes on this thread and the conversation went out of context. When the issue was created, we didn't find a good ontology that fitted with our purposes or data so we created our own property and adding it to the current geosparql ontology. For sure, the perfect implementation is using the current one: http://data.ign.fr/def/geometrie#crs

The issue is:

• The second example, even we wanted to add a new property like we did, the upload crashed (only when the CRS was different), so weird because the property didn't exist.
• Following examples because we added the CRS on the literal like the consortium suggests, but it crashed too. This must be the implementation that must be working out of box.

We were using another approaches or databases to avoid the problems with geo transformations on Virtuoso (related with WKT). So, now anyone can use the CRS on the literal of the WKT or no one tested it ? With that, this issue can be closed.

[TallTed]

@alejandrofcarrera - Have you tested with a current version of Virtuoso (or at least a version built from code later than Sep 20, 2018), which does have GeoSPARQL support? Enterprise Edition 8.2+ and Open Source Edition 7.2.6-rc1+ should both load your geodata, as discussed here.