How to handle CRS URIs in geo:wktLiterals

[pietercolpaert]

Current implementation

Current implementation parses the URI and strips off the last numbers to pass these as an EPSG to the Proj4JS library.

Why this is incorrect

https://opengeospatial.github.io/ogc-geosparql/geosparql11/spec.html#_rdfs_datatype_geowktliteral

The geosparql spec does not have these URI semantics anywhere specified. An SRS thus may have a totally different URI than something trailing with an EPSG code. However, it is a functional hack that works in cases where e.g., opengis URIs are being used which do follow this pattern.

How to do it properly: up for discussion

The OpenGIS URIs return a GML definition in XML (example: http://www.opengis.net/def/crs/EPSG/9.9.1/31370). I’m not sure whether we can count on all URI servers to always give a GML description, but let’s assume we can:

This XML cannot be fed into proj4js as far as I know: we’d have to parse this GML and generate a WKT description of the projection which can then be fed into proj4js. I’m not sure whether this exists as an JavaScript library already?

I checked NPM and I don’t immediately find a library that would be able to parse these XML files. Tooling like https://www.npmjs.com/package/epsg-to-proj use the EPSG code and look them up at epsg.io, which I don’t find a great solution.

Even when it does, we’d have to use a server-side HTTP proxy before we can fetch it into wktmap: the opengis.net server does not allow CORS. We have a proxy running at https://proxy.linkeddatafragments.org/ (just concatenate a URL) that may be used as a default.

[pieterprovoost]

Apologies for the corner cutting. I have made some changes to throw an error when anything other than an OpenGIS EPSG URI is provided, and I'll look into options for handling others.

[pietercolpaert]

Ha, no worries! Cutting that corner makes a lot of sense as the solution I describe is certainly not straightforward to implement. I also wonder whether expecting a GML from that URI is something we can count on, or whether we should actually test what we get back from the URI.

[derhuerst]

Note: I don't fully understand the context of this Issue, but I'll reply to a specific aspect.

[…] Tooling like https://www.npmjs.com/package/epsg-to-proj use the EPSG code and look them up at epsg.io, which I don’t find a great solution.

I created the epsg-index npm package a while ago as an alternative.

But it definitely doesn't solve the actual problem in a clean way.

[pietercolpaert]

I indeed thing that we shouldn’t load all SRSs in memory or ship it with a codebase, but start from the URL of a GML description of the projection, which is how the Geosparql standard does it. I also see that as the most evolvable way.

[pieterprovoost]

Maybe I can look into setting up an API that wraps gdalsrsinfo (which accepts URIs), but it would be good to know what kind of URIs exist in the wild. So far I'm mostly seeing http://www.opengis.net/def/crs/OGC/1.3/CRS84 and http://www.opengis.net/def/crs/EPSG/{version}/{epsg}.

[pietercolpaert]

This is blocked by the fact that we don’t have a GML → Proj4JS SRS configuration converter, right?

[pietercolpaert]

We should have something like this, but then in Javascript: https://github.com/maptiler/epsg.io/blob/master/gml_parser.py - and convert the result of it to a proj4js string, which apparently in epsg.io is done using gdal bindings for python. Looks like, for now, we should just live with our current solution. Shall I just close this issue for now?

[pieterprovoost]

I'm happy to keep this open, would be good to have a solution at some point.