No problem - just permission. On Mon, Feb 22, 2021 at 11:14 PM Balambér Hakapesz <[email protected]> wrote:
> 67fffb0 installation does not work on Windows7 > > Balázs. > > On Mon, Feb 22, 2021 at 10:28 PM Balambér Hakapesz < > [email protected]> 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 <[email protected]> >> 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 < >>> [email protected]>: >>> > >>> > >>> >> >>> >> 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 >>> > [email protected] >>> > https://mailman.speleo.sk/listinfo/therion >>> _______________________________________________ >>> Therion mailing list >>> [email protected] >>> https://mailman.speleo.sk/listinfo/therion >>> >>
_______________________________________________ Therion mailing list [email protected] https://mailman.speleo.sk/listinfo/therion
