<div dir="ltr">67fffb0 installation does not work on Windows7<br><div><br></div><div>Balázs.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 22, 2021 at 10:28 PM Balambér Hakapesz <<a href="mailto:holl.balazs63@gmail.com">holl.balazs63@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">No, the issue is the difference between the altitudes of the mean sea level (geoid) and the ellipsoidal coordinates.<br><div><br></div><div>Balázs.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 22, 2021 at 10:22 PM Benedikt Hallinger <<a href="mailto:beni@hallinger.org" target="_blank">beni@hallinger.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">As far as i understood, when you tag your data to be in a certain coordinate system that should include all three data points when the coordinate system defines them.<br>
If you want an altitude offset, i would expect that we must manually convert.<br>
<br>
As an example: i tag my data to be wsg89, which defines altitude pegged to a certain reference.<br>
Assume alt is 0.<br>
When i now switch coordinate systems to something really (artifically) weird, like the origin pegged to the peak of mt. Everest, i would expect all three coordinates to be correctly transformed (making especially altitude very negative).<br>
If i now want to say that a point is at the same level as everests peak, i would have to apply a manual transformation step.<br>
But that’s not the fault of wgs89 mir the target cs, the reason was that my initial calibration was never in wgs89!<br>
<br>
What do i get wrong in this thought process?<br>
<br>
<br>
> Am 22.02.2021 um 21:37 schrieb Tarquin Wilton-Jones via Therion <<a href="mailto:therion@speleo.sk" target="_blank">therion@speleo.sk</a>>:<br>
> <br>
> <br>
>> <br>
>> If there is a real need for a switch between converting and not<br>
>> converting the heights, let us know.<br>
> <br>
> At least here in the UK, a lot of rough and ready surveys seem to use<br>
> Garmin handheld GPS units like the 66sr. These use barometric altitude,<br>
> which you calibrate to a local benchmark. That means you get local<br>
> mapping heights that do not need to be converted, while the GPS<br>
> coordinates would need to be converted.<br>
> <br>
> Anyone relying on this approach (which already is rather poor from an<br>
> accuracy perspective) would indeed need you to perform conversion on x<br>
> and y but not z, while anyone using a proper GPS unit which outputs<br>
> ellipsoid heights would need you to convert x, y, and z. I therefore see<br>
> a need for it to be controllable.<br>
> <br>
> Personally, I use real GPS ellipsoid heights, which I manually convert<br>
> using continental drift calculations and the higher quality<br>
> OSTN15+OSGM15 transformation (since these then remain correct in spite<br>
> of continental drift). I do not rely on proj for that, and have built my<br>
> own tool instead, since proj does not have access to the data required<br>
> for it.<br>
> <br>
> Tarquin<br>
> _______________________________________________<br>
> Therion mailing list<br>
> <a href="mailto:Therion@speleo.sk" target="_blank">Therion@speleo.sk</a><br>
> <a href="https://mailman.speleo.sk/listinfo/therion" rel="noreferrer" target="_blank">https://mailman.speleo.sk/listinfo/therion</a><br>
_______________________________________________<br>
Therion mailing list<br>
<a href="mailto:Therion@speleo.sk" target="_blank">Therion@speleo.sk</a><br>
<a href="https://mailman.speleo.sk/listinfo/therion" rel="noreferrer" target="_blank">https://mailman.speleo.sk/listinfo/therion</a><br>
</blockquote></div>
</blockquote></div>