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
