<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Petro,</p>
<p>I've queued <a class="moz-txt-link-freetext" href="https://github.com/OSGeo/gdal/pull/4908">https://github.com/OSGeo/gdal/pull/4908</a> 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""<br>
</p>
<p>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.)</p>
<p>(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)<br>
</p>
<p>Even<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Le 27/11/2021 à 19:13, Pedro Venâncio a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAMCJChu3R6kCGM4Er=cqoDdwwegt0=RPuORhfaEUAk4u7FRHdw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi all,<br>
<br>
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.<br>
<br>
For instance, this shapefile: <a
href="https://si.icnf.pt/shp/rnap" moz-do-not-send="true">https://si.icnf.pt/shp/rnap</a><br>
<br>
Checking ogrinfo in different versions:<br>
<br>
ogrinfo --version<br>
GDAL 2.4.0, released 2018/12/14 (Used by QGIS 2.18.28)<br>
<br>
ogrinfo -al rnap.shp<br>
INFO: Open of `rnap.shp'<br>
using driver `ESRI Shapefile' successful.<br>
<br>
Layer name: rnap<br>
Metadata:<br>
DBF_DATE_LAST_UPDATE=1921-11-27<br>
Geometry: Polygon<br>
Feature Count: 48<br>
Extent: (-123561.201500, -300415.400000) - (162054.118700,
268136.980100)<br>
Layer SRS WKT:<br>
PROJCS["ETRS89 / Portugal TM06",<br>
GEOGCS["ETRS89",<br>
DATUM["European Terrestrial Reference System 1989",<br>
SPHEROID["GRS 1980",6378137.0,298.257222101,<br>
AUTHORITY["EPSG","7019"]],<br>
TOWGS84[0.0,0.0,0.0,0.0,0.0,0.0,0.0],<br>
AUTHORITY["EPSG","6258"]],<br>
PRIMEM["Greenwich",0.0,<br>
AUTHORITY["EPSG","8901"]],<br>
UNIT["degree",0.017453292519943295],<br>
AXIS["Geodetic longitude",EAST],<br>
AXIS["Geodetic latitude",NORTH],<br>
AUTHORITY["EPSG","4258"]],<br>
PROJECTION["Transverse_Mercator",<br>
AUTHORITY["EPSG","9807"]],<br>
PARAMETER["central_meridian",-8.133108333333334],<br>
PARAMETER["latitude_of_origin",39.66825833333334],<br>
PARAMETER["scale_factor",1.0],<br>
PARAMETER["false_easting",0.0],<br>
PARAMETER["false_northing",0.0],<br>
UNIT["m",1.0],<br>
AXIS["Easting",EAST],<br>
AXIS["Northing",NORTH],<br>
AUTHORITY["EPSG","3763"]]<br>
nome_ap: String (254.0)<br>
classifica: String (254.0)<br>
publica1: String (254.0)<br>
publica2: String (254.0)<br>
jurisdicao: String (254.0)<br>
area_ha: Real (33.15)<br>
sigla: String (254.0)<br>
<br>
<br>
<br>
ogrinfo --version<br>
GDAL 3.4.0, released 2021/11/04 (Used by QGIS 3.22)<br>
<br>
ogrinfo -al rnap.shp<br>
INFO: Open of `rnap.shp'<br>
using driver `ESRI Shapefile' successful.<br>
<br>
Layer name: rnap<br>
Metadata:<br>
DBF_DATE_LAST_UPDATE=1920-08-17<br>
Geometry: Polygon<br>
Feature Count: 48<br>
Extent: (-123561.201500, -300415.400000) - (162054.118700,
268136.980100)<br>
Layer SRS WKT:<br>
BOUNDCRS[<br>
SOURCECRS[<br>
PROJCRS["ETRS89 / Portugal TM06",<br>
BASEGEOGCRS["ETRS89",<br>
ENSEMBLE["European Terrestrial Reference System
1989 ensemble",<br>
MEMBER["European Terrestrial Reference Frame
1989"],<br>
MEMBER["European Terrestrial Reference Frame
1990"],<br>
MEMBER["European Terrestrial Reference Frame
1991"],<br>
MEMBER["European Terrestrial Reference Frame
1992"],<br>
MEMBER["European Terrestrial Reference Frame
1993"],<br>
MEMBER["European Terrestrial Reference Frame
1994"],<br>
MEMBER["European Terrestrial Reference Frame
1996"],<br>
MEMBER["European Terrestrial Reference Frame
1997"],<br>
MEMBER["European Terrestrial Reference Frame
2000"],<br>
MEMBER["European Terrestrial Reference Frame
2005"],<br>
MEMBER["European Terrestrial Reference Frame
2014"],<br>
ELLIPSOID["GRS 1980",6378137,298.257222101,<br>
LENGTHUNIT["metre",1]],<br>
ENSEMBLEACCURACY[0.1]],<br>
PRIMEM["Greenwich",0,<br>
ANGLEUNIT["degree",0.0174532925199433]],<br>
ID["EPSG",4258]],<br>
CONVERSION["Portugual TM06",<br>
METHOD["Transverse Mercator",<br>
ID["EPSG",9807]],<br>
PARAMETER["Latitude of natural
origin",39.6682583333333,<br>
ANGLEUNIT["degree",0.0174532925199433],<br>
ID["EPSG",8801]],<br>
PARAMETER["Longitude of natural
origin",-8.13310833333333,<br>
ANGLEUNIT["degree",0.0174532925199433],<br>
ID["EPSG",8802]],<br>
PARAMETER["Scale factor at natural origin",1,<br>
SCALEUNIT["unity",1],<br>
ID["EPSG",8805]],<br>
PARAMETER["False easting",0,<br>
LENGTHUNIT["metre",1],<br>
ID["EPSG",8806]],<br>
PARAMETER["False northing",0,<br>
LENGTHUNIT["metre",1],<br>
ID["EPSG",8807]]],<br>
CS[Cartesian,2],<br>
AXIS["easting (X)",east,<br>
ORDER[1],<br>
LENGTHUNIT["metre",1]],<br>
AXIS["northing (Y)",north,<br>
ORDER[2],<br>
LENGTHUNIT["metre",1]],<br>
USAGE[<br>
SCOPE["Topographic mapping (medium scale)."],<br>
AREA["Portugal - mainland - onshore."],<br>
BBOX[36.95,-9.56,42.16,-6.19]],<br>
ID["EPSG",3763]]],<br>
TARGETCRS[<br>
GEOGCRS["WGS 84",<br>
DATUM["World Geodetic System 1984",<br>
ELLIPSOID["WGS 84",6378137,298.257223563,<br>
LENGTHUNIT["metre",1]]],<br>
PRIMEM["Greenwich",0,<br>
ANGLEUNIT["degree",0.0174532925199433]],<br>
CS[ellipsoidal,2],<br>
AXIS["latitude",north,<br>
ORDER[1],<br>
ANGLEUNIT["degree",0.0174532925199433]],<br>
AXIS["longitude",east,<br>
ORDER[2],<br>
ANGLEUNIT["degree",0.0174532925199433]],<br>
ID["EPSG",4326]]],<br>
ABRIDGEDTRANSFORMATION["ETRS89 to WGS 84 (1)",<br>
VERSION["EPSG-eur"],<br>
METHOD["Geocentric translations (geog2D domain)",<br>
ID["EPSG",9603]],<br>
PARAMETER["X-axis translation",0,<br>
ID["EPSG",8605]],<br>
PARAMETER["Y-axis translation",0,<br>
ID["EPSG",8606]],<br>
PARAMETER["Z-axis translation",0,<br>
ID["EPSG",8607]],<br>
USAGE[<br>
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."],<br>
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."],<br>
BBOX[32.88,-16.1,84.73,40.18]],<br>
ID["EPSG",1149],<br>
REMARK["ETRS89 and WGS 84 are realizations of ITRS
coincident to within 1 metre. This transformation has an
accuracy equal to the coincidence figure."]]]<br>
Data axis to CRS axis mapping: 1,2<br>
nome_ap: String (254.0)<br>
classifica: String (254.0)<br>
publica1: String (254.0)<br>
publica2: String (254.0)<br>
jurisdicao: String (254.0)<br>
area_ha: Real (33.15)<br>
sigla: String (254.0)<br>
<br>
The differences between rnap.prj (left) and <a
href="https://epsg.io/3763" moz-do-not-send="true">https://epsg.io/3763</a>
(right) are few:<br>
<br>
<a
href="https://cld.pt/dl/download/5d9b5324-b28a-4654-a8f7-365c7cc39c10/rnap_prj.png"
moz-do-not-send="true">https://cld.pt/dl/download/5d9b5324-b28a-4654-a8f7-365c7cc39c10/rnap_prj.png</a><br>
<br>
The GeoServer version that is generating this layer is old.<br>
<br>
So, could this be a bug?<br>
<br>
Thanks!<br>
<br>
Best regards,<br>
Pedro</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
QGIS-Developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>