[QGIS-Developer] QGIS does not recognize CRS of specific layers generated by GeoServer
Even Rouault
even.rouault at spatialys.com
Sat Nov 27 11:41:01 PST 2021
I meant "Pedro", sorry for the typo.
Le 27/11/2021 à 20:38, Even Rouault a écrit :
>
> Petro,
>
> I've queued https://github.com/OSGeo/gdal/pull/4908 which will "fix"
> that particular case (more precisely anything based on ETRS89). I'm
> not super satisfied with this, and I believe there's no miracle
> solution for all potential use cases. What GDAL returns in both 2.4.0
> and 3.4.0 is actually pretty much the same object, despite the
> different representation (WKT1 vs WKT2). The root cause of the issue
> is with the TOWGS84[] node. Those nodes are not part of CRS
> definitions. They date back to the time where the GDAL & PROJ stack
> wasn't capable of more powerful transformation, and so a particular
> datum transformation to WGS 84 was picked up, and encoded in the CRS
> definition. When reading such definitions nowadays, we have a dilemna:
> did the user really meant to use the particular transformation that
> was in TOWGS84[], or was it just there because that was the default
> one. We ere on the side of caution (most of time, there are a few
> exceptions there and there in GDAL), and keep the transformation
> information, which makes that this CRS is formally not the official
> definition, and thus considered as ""custom""
>
> However, for ETRS89, I believe we can safely remove it, since as far
> as I know, there's no better transformation between ETRS89 (which is
> known modeled as a "datum ensemble" by EPSG, meaning any of the 11
> ETRF realizations) and WGS 84 (itself a datum ensemble) than the
> TOWGS84[0.0,0.0,0.0,0.0,0.0,0.0,0.0], and it is unlikely there will be
> an alternative one in the future, given the dynamic nature of the WGS
> 84 datum (maybe I'm speaking too fast. When ETRS89 and WGS 84
> coordinates will have drifted too far away in the future, maybe there
> will some non-null transformation added in the database, so that users
> who want to transform to a 'past' or 'future' coordinate epoch of WGS
> 84 can do that in a not too bad way.)
>
> (I should not that this .prj file isn't really compliant with the Esri
> dialect of WKT, which is supposed to be used for shapefiles, since
> normally it shouldn't contain TOWGS84 or AUHTORITY code)
>
> Even
>
>
> Le 27/11/2021 à 19:13, Pedro Venâncio a écrit :
>> Hi all,
>>
>> I'm seeing that QGIS 3.16 / 3.22 does not recognize the CRS of
>> specific layers generated by GeoServer, but the old QGIS 2.18.28
>> recognize.
>>
>> For instance, this shapefile: https://si.icnf.pt/shp/rnap
>> <https://si.icnf.pt/shp/rnap>
>>
>> Checking ogrinfo in different versions:
>>
>> ogrinfo --version
>> GDAL 2.4.0, released 2018/12/14 (Used by QGIS 2.18.28)
>>
>> ogrinfo -al rnap.shp
>> INFO: Open of `rnap.shp'
>> using driver `ESRI Shapefile' successful.
>>
>> Layer name: rnap
>> Metadata:
>> DBF_DATE_LAST_UPDATE=1921-11-27
>> Geometry: Polygon
>> Feature Count: 48
>> Extent: (-123561.201500, -300415.400000) - (162054.118700, 268136.980100)
>> Layer SRS WKT:
>> PROJCS["ETRS89 / Portugal TM06",
>> GEOGCS["ETRS89",
>> DATUM["European Terrestrial Reference System 1989",
>> SPHEROID["GRS 1980",6378137.0,298.257222101,
>> AUTHORITY["EPSG","7019"]],
>> TOWGS84[0.0,0.0,0.0,0.0,0.0,0.0,0.0],
>> AUTHORITY["EPSG","6258"]],
>> PRIMEM["Greenwich",0.0,
>> AUTHORITY["EPSG","8901"]],
>> UNIT["degree",0.017453292519943295],
>> AXIS["Geodetic longitude",EAST],
>> AXIS["Geodetic latitude",NORTH],
>> AUTHORITY["EPSG","4258"]],
>> PROJECTION["Transverse_Mercator",
>> AUTHORITY["EPSG","9807"]],
>> PARAMETER["central_meridian",-8.133108333333334],
>> PARAMETER["latitude_of_origin",39.66825833333334],
>> PARAMETER["scale_factor",1.0],
>> PARAMETER["false_easting",0.0],
>> PARAMETER["false_northing",0.0],
>> UNIT["m",1.0],
>> AXIS["Easting",EAST],
>> AXIS["Northing",NORTH],
>> AUTHORITY["EPSG","3763"]]
>> nome_ap: String (254.0)
>> classifica: String (254.0)
>> publica1: String (254.0)
>> publica2: String (254.0)
>> jurisdicao: String (254.0)
>> area_ha: Real (33.15)
>> sigla: String (254.0)
>>
>>
>>
>> ogrinfo --version
>> GDAL 3.4.0, released 2021/11/04 (Used by QGIS 3.22)
>>
>> ogrinfo -al rnap.shp
>> INFO: Open of `rnap.shp'
>> using driver `ESRI Shapefile' successful.
>>
>> Layer name: rnap
>> Metadata:
>> DBF_DATE_LAST_UPDATE=1920-08-17
>> Geometry: Polygon
>> Feature Count: 48
>> Extent: (-123561.201500, -300415.400000) - (162054.118700, 268136.980100)
>> Layer SRS WKT:
>> BOUNDCRS[
>> SOURCECRS[
>> PROJCRS["ETRS89 / Portugal TM06",
>> BASEGEOGCRS["ETRS89",
>> ENSEMBLE["European Terrestrial Reference System 1989
>> ensemble",
>> MEMBER["European Terrestrial Reference Frame 1989"],
>> MEMBER["European Terrestrial Reference Frame 1990"],
>> MEMBER["European Terrestrial Reference Frame 1991"],
>> MEMBER["European Terrestrial Reference Frame 1992"],
>> MEMBER["European Terrestrial Reference Frame 1993"],
>> MEMBER["European Terrestrial Reference Frame 1994"],
>> MEMBER["European Terrestrial Reference Frame 1996"],
>> MEMBER["European Terrestrial Reference Frame 1997"],
>> MEMBER["European Terrestrial Reference Frame 2000"],
>> MEMBER["European Terrestrial Reference Frame 2005"],
>> MEMBER["European Terrestrial Reference Frame 2014"],
>> ELLIPSOID["GRS 1980",6378137,298.257222101,
>> LENGTHUNIT["metre",1]],
>> ENSEMBLEACCURACY[0.1]],
>> PRIMEM["Greenwich",0,
>> ANGLEUNIT["degree",0.0174532925199433]],
>> ID["EPSG",4258]],
>> CONVERSION["Portugual TM06",
>> METHOD["Transverse Mercator",
>> ID["EPSG",9807]],
>> PARAMETER["Latitude of natural origin",39.6682583333333,
>> ANGLEUNIT["degree",0.0174532925199433],
>> ID["EPSG",8801]],
>> PARAMETER["Longitude of natural
>> origin",-8.13310833333333,
>> ANGLEUNIT["degree",0.0174532925199433],
>> ID["EPSG",8802]],
>> PARAMETER["Scale factor at natural origin",1,
>> SCALEUNIT["unity",1],
>> ID["EPSG",8805]],
>> PARAMETER["False easting",0,
>> LENGTHUNIT["metre",1],
>> ID["EPSG",8806]],
>> PARAMETER["False northing",0,
>> LENGTHUNIT["metre",1],
>> ID["EPSG",8807]]],
>> CS[Cartesian,2],
>> AXIS["easting (X)",east,
>> ORDER[1],
>> LENGTHUNIT["metre",1]],
>> AXIS["northing (Y)",north,
>> ORDER[2],
>> LENGTHUNIT["metre",1]],
>> USAGE[
>> SCOPE["Topographic mapping (medium scale)."],
>> AREA["Portugal - mainland - onshore."],
>> BBOX[36.95,-9.56,42.16,-6.19]],
>> ID["EPSG",3763]]],
>> TARGETCRS[
>> GEOGCRS["WGS 84",
>> DATUM["World Geodetic System 1984",
>> ELLIPSOID["WGS 84",6378137,298.257223563,
>> LENGTHUNIT["metre",1]]],
>> PRIMEM["Greenwich",0,
>> ANGLEUNIT["degree",0.0174532925199433]],
>> CS[ellipsoidal,2],
>> AXIS["latitude",north,
>> ORDER[1],
>> ANGLEUNIT["degree",0.0174532925199433]],
>> AXIS["longitude",east,
>> ORDER[2],
>> ANGLEUNIT["degree",0.0174532925199433]],
>> ID["EPSG",4326]]],
>> ABRIDGEDTRANSFORMATION["ETRS89 to WGS 84 (1)",
>> VERSION["EPSG-eur"],
>> METHOD["Geocentric translations (geog2D domain)",
>> ID["EPSG",9603]],
>> PARAMETER["X-axis translation",0,
>> ID["EPSG",8605]],
>> PARAMETER["Y-axis translation",0,
>> ID["EPSG",8606]],
>> PARAMETER["Z-axis translation",0,
>> ID["EPSG",8607]],
>> USAGE[
>> SCOPE["(null/copy) Approximation for medium and low
>> accuracy applications assuming equality between plate-fixed static
>> and earth-fixed dynamic CRSs, ignoring static/dynamic CRS differences."],
>> AREA["Europe - onshore and offshore: Albania; Andorra;
>> Austria; Belgium; Bosnia and Herzegovina; Bulgaria; Croatia; Cyprus;
>> Czechia; Denmark; Estonia; Faroe Islands; Finland; France; Germany;
>> Gibraltar; Greece; Hungary; Ireland; Italy; Kosovo; Latvia;
>> Liechtenstein; Lithuania; Luxembourg; Malta; Moldova; Monaco;
>> Montenegro; Netherlands; North Macedonia; Norway including Svalbard
>> and Jan Mayen; Poland; Portugal; Romania; San Marino; Serbia;
>> Slovakia; Slovenia; Spain; Sweden; Switzerland; United Kingdom (UK)
>> including Channel Islands and Isle of Man; Vatican City State."],
>> BBOX[32.88,-16.1,84.73,40.18]],
>> ID["EPSG",1149],
>> REMARK["ETRS89 and WGS 84 are realizations of ITRS coincident
>> to within 1 metre. This transformation has an accuracy equal to the
>> coincidence figure."]]]
>> Data axis to CRS axis mapping: 1,2
>> nome_ap: String (254.0)
>> classifica: String (254.0)
>> publica1: String (254.0)
>> publica2: String (254.0)
>> jurisdicao: String (254.0)
>> area_ha: Real (33.15)
>> sigla: String (254.0)
>>
>> The differences between rnap.prj (left) and https://epsg.io/3763
>> <https://epsg.io/3763> (right) are few:
>>
>> https://cld.pt/dl/download/5d9b5324-b28a-4654-a8f7-365c7cc39c10/rnap_prj.png
>> <https://cld.pt/dl/download/5d9b5324-b28a-4654-a8f7-365c7cc39c10/rnap_prj.png>
>>
>> The GeoServer version that is generating this layer is old.
>>
>> So, could this be a bug?
>>
>> Thanks!
>>
>> Best regards,
>> Pedro
>>
>> _______________________________________________
>> QGIS-Developer mailing list
>> QGIS-Developer at lists.osgeo.org
>> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
--
http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20211127/d924f1c5/attachment-0001.html>
More information about the QGIS-Developer
mailing list