[Therion] 3D model height

[Balambér Hakapesz]

No problem - just permission.

On Mon, Feb 22, 2021 at 11:14 PM Balambér Hakapesz <holl.balazs63 at gmail.com>
wrote:

> 67fffb0 installation does not work on Windows7
>
> Balázs.
>
> On Mon, Feb 22, 2021 at 10:28 PM Balambér Hakapesz <
> holl.balazs63 at gmail.com> wrote:
>
>> 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 at 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 at 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 at speleo.sk
>>> > https://mailman.speleo.sk/listinfo/therion
>>> _______________________________________________
>>> Therion mailing list
>>> Therion at speleo.sk
>>> https://mailman.speleo.sk/listinfo/therion
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.speleo.sk/pipermail/therion/attachments/20210222/298aadcf/attachment.htm>