Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make QGIS Server able to detect EPSG code #461

Open
lucernae opened this issue Jul 31, 2018 · 2 comments
Open

Make QGIS Server able to detect EPSG code #461

lucernae opened this issue Jul 31, 2018 · 2 comments

Comments

@lucernae
Copy link
Collaborator

The test layer is here: https://github.com/GeoNode/gisdata/blob/master/gisdata/both/good/sangis.org/Airport/Air_Runways.shp

I fixed some issues with GDAL version regarding this PR: #442
Now with GDAL 2, GeoNode are able to recognize most of empty EPSG projection, but not all.

In the above test layer, if we open it in QGIS, it is able to render it correctly. However it doesn't have the EPSG code. QGIS just assign a user projection (no epsg code, but correct projection).

The actual projection is EPSG:2230.
When I tried using GDAL to detect the EPSG, it failed and returned EPSG:4269, maybe the closest one but different Datum.

In GeoServer, because they also used GDAL, it is also using EPSG:4629. However, GeoNode send another request to GeoServer API to try to detect the EPSG code, and it returned the correct EPSG:2230.

My question is, is there any way for QGIS (API wise or implemented via otf-project), to detect the EPSG of the layer (not from GDAL), so we can have the correct EPSG code. This EPSG code is needed to transform layer boundary from that code to 4326 so leaflet can render in the correct bounds. WMS rendering by QGIS actually doesn't have any problem. It correctly renders the given area of EPSG:4326, even though the actual layer uses user projection.

Is there any suggestion for this @timlinux @gubuntu ?

@gubuntu
Copy link

gubuntu commented Jul 31, 2018

@lucernae

  • GDAL maintains its own copy of the EPSG database plus CRS definitions from other authorities
  • QGIS does too
  • GeoServer does too
  • so does PostGIS

QGIS and GeoServer will both guess 4326 if a layer has no EPSG code but has geometry that appears to be geographic.

For an EPSG (or other authority) code to be used across all those tools, its definition needs to exist in each tool's own database.

If an uploaded dataset has a valid CRS but no EPSG code, we can tell the use to try again with a CRS that has a valid EPSG code OR we can ask the user what the EPSG code is and set that as a layer property in the QGIS project via otf-project.

If you want to support a custom CRS via a fake authority code you can do so in Geoserver and PostGIS by adding them to those tools' CRS libraries. However, custom CRSs in QGIS get random and inconsistent codes so you cannot rely on that with QGIS server.

So

is there any way for QGIS (API wise or implemented via otf-project), to detect the EPSG of the layer (not from GDAL), so we can have the correct EPSG code

QGIS might guess it a bit better than GDAL but if it's not there, it's not there. Also remember proj4 projection strings do not encode an authority code. Also, WKT and proj4 projection strings can be written in several ways to mean the same thing so GDAL and QGIS have to do some clever matching. So I would just leave it to GDAL as is.

This EPSG code is needed to transform layer boundary from that code to 4326 so leaflet can render in the correct bounds.

Not really. It just has to be a valid CRS.

The problem is not QGIS, it is GeoNode insisting on referencing a CRS via a standard code, which is not always available.

Maybe if GeoNode stored a projection string rather than a code it would handle a few more cases.

@gubuntu
Copy link

gubuntu commented Jul 31, 2018

But @lucernae this is not a blocker for WB GeoSAFE, please proceed with the existing fixes to #435 and park this in the backlog, I don't think it should suck up any more time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants