Wow, thank you very much Even! I think this solution is just fine! Thanks again!
Best regards, Pedro A sábado, 27/11/2021, 19:38, Even Rouault <[email protected]> escreveu: > 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 > > 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 (right) > are few: > > > 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 [email protected] > 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 > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
