No, the issue is the difference between the altitudes of the mean sea level (geoid) and the ellipsoidal coordinates.

Balázs.

On Mon, Feb 22, 2021 at 10:22 PM Benedikt Hallinger <beni@hallinger.org> wrote:

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.
If you want an altitude offset, i would expect that we must manually convert.

As an example: i tag my data to be wsg89, which defines altitude pegged to a certain reference.
Assume alt is 0.
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).
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.
But that’s not the fault of wgs89 mir the target cs, the reason was that my initial calibration was never in wgs89!

What do i get wrong in this thought process?


> Am 22.02.2021 um 21:37 schrieb Tarquin Wilton-Jones via Therion <therion@speleo.sk>:
>
> 
>>
>> If there is a real need for a switch between converting and not
>> converting the heights, let us know.
>
> At least here in the UK, a lot of rough and ready surveys seem to use
> Garmin handheld GPS units like the 66sr. These use barometric altitude,
> which you calibrate to a local benchmark. That means you get local
> mapping heights that do not need to be converted, while the GPS
> coordinates would need to be converted.
>
> Anyone relying on this approach (which already is rather poor from an
> accuracy perspective) would indeed need you to perform conversion on x
> and y but not z, while anyone using a proper GPS unit which outputs
> ellipsoid heights would need you to convert x, y, and z. I therefore see
> a need for it to be controllable.
>
> Personally, I use real GPS ellipsoid heights, which I manually convert
> using continental drift calculations and the higher quality
> OSTN15+OSGM15 transformation (since these then remain correct in spite
> of continental drift). I do not rely on proj for that, and have built my
> own tool instead, since proj does not have access to the data required
> for it.
>
> Tarquin
> _______________________________________________
> Therion mailing list
> Therion@speleo.sk
> https://mailman.speleo.sk/listinfo/therion
_______________________________________________
Therion mailing list
Therion@speleo.sk
https://mailman.speleo.sk/listinfo/therion