<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Søren,
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 22 Apr 2020, at 16:04, Søren Holm <<a href="mailto:sgh@sgh.dk" class="">sgh@sgh.dk</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">Hi<br class="">
<br class="">
We are using proj for transformation of some Danish coordinatesystems.<br class="">
<br class="">
Among them are S34 and DKTM.<br class="">
<br class="">
Usually the height is not affected much during transformations. This is <br class="">
however different for S34.<br class="">
<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>Yes, System34 is only a 2D coordinate reference system, so the height is generally not meant to be used.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class=""><br class="">
$ cct -t0 +proj=pipeline +step +init=DK:DKTM1 <br class="">
10 55 0 0<br class="">
263991.7405 1097565.8295 0.0000 0.0000 0<br class="">
<br class="">
<br class="">
$ cct -t0 +proj=pipeline +step +init=DK:S34J <br class="">
10 55 0 0<br class="">
234033.0592 63129.6022 -36.8103 0.0000 0<br class="">
<br class="">
<br class="">
Why is there ~36m subtracted for S34? <br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>The reason is that there is an implicit datum change happening in that transformation, which internally works in three dimensions and then consequently transforms the zero height to another datum. This, however, has no physical meaning and can be regarded
as a mathematical curiosity. With PROJ > 6.0.0 this can actually be avoided by using the <a href="https://proj.org/operations/conversions/push.html" class="">push</a> and <a href="https://proj.org/operations/conversions/pop.html" class="">pop</a> operators:</div>
<div><br class="">
</div>
<div>echo 10 55 | ./bin/cct -z0 -t0 +proj=pipeline +step +proj=push +v_3 +step +init=DK:S34J +step +proj=pop +v_3</div>
<div> 234033.0592 63129.6022 0.0000 0.0000 </div>
<div><br class="">
</div>
<div>The DK init file was created before that was possible. This probably should be updated, although it comes with the risk that someone now relies on the current behaviour. System34 has been submitted to the EPSG but the application is still pending. Once
that find it’s way to the EPSG registry this problem should disappear entirely in PROJ. The time frame is unfortunately unknown at this time.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">Why is there around 0.1mm height difference for most UTM and NTM zones?<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>I haven’t been able to replicate that, so hard to comment on. A guess is that there is some numerical inaccuracy involved. I don’t think there’s anything to worry about, 0.1 mm is very likely less than both the accuracy of the data and the transformation.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="">Is it the intention that the heights should be affected during these
<br class="">
transformations?<br class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>For System34 it’s yes and no. Yes, because that is the way the transformation is currently made but no since it the height isn’t really part of the system. Can’t comment on the other case.</div>
<div><br class="">
</div>
<div>/Kristian</div>
</div>
<br class="">
</div>
</body>
</html>