<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-fareast-language:NL;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="NL" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">I don’t understand why you are using EPSG:4326 (WGS84) when a 2 metre offset is not acceptable for you. EPSG:4326 is a general code for a collection (datum ensemble) of more precise
defined datums (WGS84 realisations) with their own codes. The differences within the datums of the ensemble prevent a transformation to EPSG:4326 that is more precise than 2 metres. So if you what a higher accuracy, you will have to use a CRS based on another
datum, e.g. EPSG:9000 (ITRF2014).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US">Regards, Jochem
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> PROJ <proj-bounces@lists.osgeo.org>
<b>On Behalf Of </b>XCTrails<br>
<b>Sent:</b> donderdag 15 april 2021 16:26<br>
<b>To:</b> Even Rouault <even.rouault@spatialys.com><br>
<b>Cc:</b> PROJ <proj@lists.osgeo.org><br>
<b>Subject:</b> Re: [PROJ] Transforming from epsg:4326 to epsg:31468 produces a 2 meter offset<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Ok, I clearly need to research this more judging from your answers so far.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Maybe as background from where the problem originates:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm getting shapes in EPSG:31468 which will subsequently be imported/mapped to OpenstreetMap. Eventually, there will be updates to the EPSG:31468 shapes and I'm in the process of writing a script which should detect shape changes/deletions/additions.
In order to be able to geometrically compare the 2 datasets, my current workaround is to perform the transformation from EPSG:31468 to EPSG:4326 manually in QGIS, the diff then runs on 2 4326 geojson files and produces reasonable polygon matches with an intersection
over union approach. Ideally, I'd like to get rid of the manual transformation step in QGIS (along the way understanding the underlying issue).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">So, if I understand this correctly: creating a pyproj transformation using one of the mentioned PROJ strings/pipelines should yield better results? Within the limits of WGS84 - which might by in the same range as my initially observed offset.<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">Am Do., 15. Apr. 2021 um 15:19 Uhr schrieb Even Rouault <<a href="mailto:even.rouault@spatialys.com" target="_blank">even.rouault@spatialys.com</a>>:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p>projinfo is often the answer to such questions. Datum transformations *are* generally needed. What is generally no longer required in PROJ 6 era is to use the explict +nadgrids / +towgs84 terms. PROJ will find which ones are needed, but the user may still
have to arbitrate because there's not always a single possibility.<o:p></o:p></p>
<p>So the most precise transformation uses the BETA2007 grid, or you have 2 potential Helmert-based transformations depending on the location<o:p></o:p></p>
<p style="margin-bottom:12.0pt">$ projinfo -s EPSG:4326 -t EPSG:31468 --spatial-test intersects -o PROJ<br>
Candidate operations found: 3<br>
-------------------------------------<br>
Operation No. 1:<br>
<br>
unknown id, Inverse of DHDN to WGS 84 (4) + 3-degree Gauss-Kruger zone 4, 1 m, Germany - onshore - states of Baden-Wurtemberg, Bayern, Berlin, Brandenburg, Bremen, Hamburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz,
Saarland, Sachsen, Sachsen-Anhalt, Schleswig-Holstein, Thuringen.<br>
<br>
PROJ string:<br>
+proj=pipeline<br>
+step +proj=axisswap +order=2,1<br>
+step +proj=unitconvert +xy_in=deg +xy_out=rad<br>
+step +inv +proj=hgridshift +grids=de_adv_BETA2007.tif<br>
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel<br>
+step +proj=axisswap +order=2,1<br>
<br>
-------------------------------------<br>
Operation No. 2:<br>
<br>
unknown id, Inverse of DHDN to WGS 84 (2) + 3-degree Gauss-Kruger zone 4, 3 m, Germany - states of former West Germany onshore - Baden-Wurtemberg, Bayern, Bremen, Hamburg, Hessen, Niedersachsen, Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Schleswig-Holstein.<br>
<br>
PROJ string:<br>
+proj=pipeline<br>
+step +proj=axisswap +order=2,1<br>
+step +proj=unitconvert +xy_in=deg +xy_out=rad<br>
+step +proj=push +v_3<br>
+step +proj=cart +ellps=WGS84<br>
+step +inv +proj=helmert +x=598.1 +y=73.7 +z=418.2 +rx=0.202 +ry=0.045<br>
+rz=-2.455 +s=6.7 +convention=position_vector<br>
+step +inv +proj=cart +ellps=bessel<br>
+step +proj=pop +v_3<br>
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel<br>
+step +proj=axisswap +order=2,1<br>
<br>
-------------------------------------<br>
Operation No. 3:<br>
<br>
unknown id, Inverse of DHDN to WGS 84 (3) + 3-degree Gauss-Kruger zone 4, 2 m, Germany - states of former East Germany - Berlin, Brandenburg; Mecklenburg-Vorpommern; Sachsen; Sachsen-Anhalt; Thuringen.<br>
<br>
PROJ string:<br>
+proj=pipeline<br>
+step +proj=axisswap +order=2,1<br>
+step +proj=unitconvert +xy_in=deg +xy_out=rad<br>
+step +proj=push +v_3<br>
+step +proj=cart +ellps=WGS84<br>
+step +inv +proj=helmert +x=612.4 +y=77 +z=440.2 +rx=-0.054 +ry=0.057<br>
+rz=-2.797 +s=2.55 +convention=position_vector<br>
+step +inv +proj=cart +ellps=bessel<br>
+step +proj=pop +v_3<br>
+step +proj=tmerc +lat_0=0 +lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel<br>
+step +proj=axisswap +order=2,1<o:p></o:p></p>
<div>
<p class="MsoNormal">Le 15/04/2021 à 14:51, Alan Snow a écrit :<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Original question: <a href="https://github.com/pyproj4/pyproj/discussions/814" target="_blank">
https://github.com/pyproj4/pyproj/discussions/814</a> <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">What he is asking is if TOWGS84 parameters are needed for datum transformations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks <span style="font-family:"Segoe UI Emoji",sans-serif">
👍</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Thu, Apr 15, 2021, 2:32 AM XCTrails <<a href="mailto:info@xctrails.org" target="_blank">info@xctrails.org</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Hi,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I have input polygon in epsg:31468 which I need to transform to epsg:4326
<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">My current code boils down to this:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">project = pyproj.Transformer.from_crs("EPSG:31468","EPSG:4326", always_xy=True)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">poly = transform(project.transform, poly)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The problem however is that the resulting polygons have a 1-2 meter offset according to visual inspection in QGIS. On reddit, someone suggested that I might also need a datum transformation, on the pyproj4 issue tracker someone said, that
datum transformations are no longer needed in PROJ 6+ and that I should ask for clarification here. So here I am ;-)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Can anyone shed any light on why I get these offsets and what I can do to fix this?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">There's no offset if I manually reproject this in QGIS and compare it with the original.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Armin<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>PROJ mailing list<o:p></o:p></pre>
<pre><a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><o:p></o:p></pre>
<pre><a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><o:p></o:p></pre>
</blockquote>
<pre>-- <o:p></o:p></pre>
<pre><a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a><o:p></o:p></pre>
<pre>My software is free, but my time generally not.<o:p></o:p></pre>
</div>
<p class="MsoNormal">_______________________________________________<br>
PROJ mailing list<br>
<a href="mailto:PROJ@lists.osgeo.org" target="_blank">PROJ@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/proj" target="_blank">https://lists.osgeo.org/mailman/listinfo/proj</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<br>
<br>
<font size="2">Disclaimer:<br>
De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.<br>
Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster<br>
is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u<br>
dit direct te melden aan de verzender en het bericht te vernietigen.<br>
Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.<br>
<br>
Disclaimer:<br>
The content of this message is meant to be received by the addressee only.<br>
Use of the content of this message by anyone other than the addressee without the consent<br>
of the Kadaster is unlawful. If you have received this message, but are not the addressee,<br>
please contact the sender immediately and destroy the message.<br>
No rights can be derived from the content of this message.<br>
</font>
</body>
</html>