Hi! When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good. Balázs Holl. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data. With the "cs" command you define your input data to be in a specific coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs. Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
Hi!
When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good.
Balázs Holl.
[1] Mentes a vírusoktól. www.avg.com [1]
Links: ------ [1] http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections ( http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)), so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion? <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
Hi!
When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good.
Balázs Holl.
[1] Mentes a vírusoktól. www.avg.com [1]
Links: ------ [1]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys). If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates). If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter. I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh. Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)), so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific
coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
Hi!
When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good.
Balázs Holl.
[1] Mentes a vírusoktól. www.avg.com [1] [1]
Links: ------ [1]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2] http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262 kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801 291-262 = 29 m = 44m geoid height - 15m Proj4 error <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)), so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific
coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
Hi!
When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good.
Balázs Holl.
[1] Mentes a vírusoktól. www.avg.com [1] [1]
Links: ------ [1]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
If I were to enter the ellisoid height, the error of Proj4 would still remain on the EOV projection. I could work in a UTM coordinate system, but it would be much simpler if Therion didn’t recalculate anything. (There is no height issue between UTM and WGS84 because there is no conversion) This error is only present in the national projections where Proj4 performs approximate calculations for the advantage of horizontal coordinates and the disadvantage of height. On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-1230142596055352871_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)), so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific
coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
Hi!
When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good.
Balázs Holl.
[1] Mentes a vírusoktól. www.avg.com [1] [1]
Links: ------ [1]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-1230142596055352871_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
What does the survex/aven file give you, is the error there also apparent? What is your full thconfig file for generating the kml and aven .3d? Dies the problem also exists when specifying this: cs EPSG:4326 fix 0 19.009617 47.526453 262 Am 2021-02-19 11:25, schrieb Balambér Hakapesz:
If I were to enter the ellisoid height, the error of Proj4 would still remain on the EOV projection. I could work in a UTM coordinate system, but it would be much simpler if Therion didn’t recalculate anything. (There is no height issue between UTM and WGS84 because there is no conversion) This error is only present in the national projections where Proj4 performs approximate calculations for the advantage of horizontal coordinates and the disadvantage of height.
On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections
(http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)),
so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [1] [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific
coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
Hi!
When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good.
Balázs Holl.
[1] Mentes a vírusoktól. www.avg.com [1] [1] [1]
Links: ------ [1]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[2] Mentes a vírusoktól. www.avg.com [2]
Links: ------ [1] http://www.avg.com [2] http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
# 2021.02.08 created by TopoDroid v 5.0.79 #source "../th/kml.th" source "kml.th" layout topodroid legend on symbol-hide group centerline symbol-show point station debug station-names endlayout export map -layout topodroid -o kml-p.pdf -proj plan export map -layout topodroid -o kml-s.pdf -proj extended # export model -fomat survex -o kmlth.3d export model -output kmlo.3d export model -output kmlo.lox export model -output kmlo.dxf export model -output kmlo.kml # 2021.02.08 created by TopoDroid v 5.0.79 survey kml -title "kml" centerline #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 #ez felel meg az EOV-nek fix 0 647151 242509 262 date 2021.02.08 # declination 5.0000 degrees units length meters units compass clino degrees data normal from to length compass clino extend right 0 1 10.00 180.0 -90.0 1 2 10.00 0.0 0.0 2 3 10.00 90.0 0.0 units left right up down meters data dimensions station left right up down endcenterline endsurvey <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Feb 19, 2021 at 11:49 AM Benedikt Hallinger <beni@hallinger.org> wrote:
What does the survex/aven file give you, is the error there also apparent?
What is your full thconfig file for generating the kml and aven .3d?
Dies the problem also exists when specifying this: cs EPSG:4326 fix 0 19.009617 47.526453 262
Am 2021-02-19 11:25, schrieb Balambér Hakapesz:
If I were to enter the ellisoid height, the error of Proj4 would still remain on the EOV projection. I could work in a UTM coordinate system, but it would be much simpler if Therion didn’t recalculate anything. (There is no height issue between UTM and WGS84 because there is no conversion) This error is only present in the national projections where Proj4 performs approximate calculations for the advantage of horizontal coordinates and the disadvantage of height.
On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections
(http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)),
so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [1] [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific
coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz: > Hi! > > When generating 3D models, Proj4 transforms between different > coordinate systems. > This also transforms the ellipsoidal altitude, but the data always > refer to altitude above sea level and should not be changed. > The finished models do not fit the topography, you have to cheat with > the height to be good. > > Balázs Holl. > > [1] > Mentes a vírusoktól. www.avg.com [1] [1] [1] > > > > Links: > ------ > [1] >
> _______________________________________________ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[2] Mentes a vírusoktól. www.avg.com [2]
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
The error only occurs when using the EOV (EPSG: 23700) coordinate system. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> On Fri, Feb 19, 2021 at 11:59 AM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
# 2021.02.08 created by TopoDroid v 5.0.79
#source "../th/kml.th" source "kml.th"
layout topodroid legend on symbol-hide group centerline symbol-show point station debug station-names endlayout
export map -layout topodroid -o kml-p.pdf -proj plan
export map -layout topodroid -o kml-s.pdf -proj extended
# export model -fomat survex -o kmlth.3d
export model -output kmlo.3d export model -output kmlo.lox export model -output kmlo.dxf export model -output kmlo.kml
# 2021.02.08 created by TopoDroid v 5.0.79
survey kml -title "kml"
centerline #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 #ez felel meg az EOV-nek fix 0 647151 242509 262 date 2021.02.08 # declination 5.0000 degrees units length meters units compass clino degrees data normal from to length compass clino extend right 0 1 10.00 180.0 -90.0 1 2 10.00 0.0 0.0 2 3 10.00 90.0 0.0 units left right up down meters data dimensions station left right up down endcenterline
endsurvey
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-6329123508585773583_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Feb 19, 2021 at 11:49 AM Benedikt Hallinger <beni@hallinger.org> wrote:
What does the survex/aven file give you, is the error there also apparent?
What is your full thconfig file for generating the kml and aven .3d?
Dies the problem also exists when specifying this: cs EPSG:4326 fix 0 19.009617 47.526453 262
Am 2021-02-19 11:25, schrieb Balambér Hakapesz:
If I were to enter the ellisoid height, the error of Proj4 would still remain on the EOV projection. I could work in a UTM coordinate system, but it would be much simpler if Therion didn’t recalculate anything. (There is no height issue between UTM and WGS84 because there is no conversion) This error is only present in the national projections where Proj4 performs approximate calculations for the advantage of horizontal coordinates and the disadvantage of height.
On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections
(http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)),
so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [1] [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
> Hi there, > if you measure the altitude with a barometric device, you do not get > the > altitude above the ellipsoid. You have to account for that at the > input > of your data. > > With the "cs" command you define your input data to be in a specific > > coordinate system, and also your altitude has to be given in that > system. If you just put the barometric altitude there (which you > usually > did calibrate to a map, didn't you?) you have to transform the > altitude > manually if the reference altitude differs. > > Am 2021-02-19 8:44, schrieb Balambér Hakapesz: >> Hi! >> >> When generating 3D models, Proj4 transforms between different >> coordinate systems. >> This also transforms the ellipsoidal altitude, but the data always >> refer to altitude above sea level and should not be changed. >> The finished models do not fit the topography, you have to cheat > with >> the height to be good. >> >> Balázs Holl. >> >> [1] >> Mentes a vírusoktól. www.avg.com [1] [1] [1] >> >> >> >> Links: >> ------ >> [1] >> >
>> _______________________________________________ >> Therion mailing list >> Therion@speleo.sk >> https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[2] Mentes a vírusoktól. www.avg.com [2]
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-6329123508585773583_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
Well then i'm out of ideas, however i do not get weird results here when invoking proj manually: echo "647151 242509 262" | cs2cs EPSG:23700 EPSG:4326 47d31'35.376"N 19d0'34.596"E 262.000 echo "47.526453 19.009617 262" | cs2cs EPSG:4326 EPSG:23700 647151.52 242504.51 262.00 When using EPSG:23700, does the problem also occur in kmlth.3d or just the kml? Am 2021-02-19 12:06, schrieb Balambér Hakapesz:
The error only occurs when using the EOV (EPSG: 23700) coordinate system.
[3] Mentes a vírusoktól. www.avg.com [3]
On Fri, Feb 19, 2021 at 11:59 AM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
# 2021.02.08 created by TopoDroid v 5.0.79
#source "../th/kml.th [2]" source "kml.th [2]"
layout topodroid legend on symbol-hide group centerline symbol-show point station debug station-names endlayout
export map -layout topodroid -o kml-p.pdf -proj plan
export map -layout topodroid -o kml-s.pdf -proj extended
# export model -fomat survex -o kmlth.3d
export model -output kmlo.3d export model -output kmlo.lox export model -output kmlo.dxf export model -output kmlo.kml
# 2021.02.08 created by TopoDroid v 5.0.79
survey kml -title "kml"
centerline #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 #ez felel meg az EOV-nek fix 0 647151 242509 262 date 2021.02.08 # declination 5.0000 degrees units length meters units compass clino degrees data normal from to length compass clino extend right 0 1 10.00 180.0 -90.0 1 2 10.00 0.0 0.0 2 3 10.00 90.0 0.0 units left right up down meters data dimensions station left right up down endcenterline
endsurvey
[3] Mentes a vírusoktól. www.avg.com [3]
On Fri, Feb 19, 2021 at 11:49 AM Benedikt Hallinger <beni@hallinger.org> wrote:
What does the survex/aven file give you, is the error there also apparent?
What is your full thconfig file for generating the kml and aven .3d?
Dies the problem also exists when specifying this: cs EPSG:4326 fix 0 19.009617 47.526453 262
Am 2021-02-19 11:25, schrieb Balambér Hakapesz:
If I were to enter the ellisoid height, the error of Proj4 would still remain on the EOV projection. I could work in a UTM coordinate system, but it would be much simpler if Therion didn’t recalculate anything. (There is no height issue between UTM and WGS84 because there is no conversion) This error is only present in the national projections where Proj4 performs approximate calculations for the advantage of horizontal coordinates and the disadvantage of height.
On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
[2] Mentes a vírusoktól. www.avg.com [1] [2]
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz: > Very rarely can anyone work at ellipsoidal heights. In local > coordinate systems, it only makes sense for upper geodetic > calculations. Only for GPS measurements we get an ellipsoidal > altitude, even there the devices can immediately calculate the > altitude of the EGM96 model with an altitude above sea level (with a > few meters error which is not significant compared to the 15m altitude > error of handheld GPS). > Proj4 calculates the horizontal coordinates well, but there is a > serious error in the height coordinates (for special national > projections >
(http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)),
> so it would be better if not we would count on it but leave the > altitude unchanged. > Could it be an option not to change the height with Therion? > > [2] > Mentes a vírusoktól. www.avg.com [1] [1] [2] > > On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger > <beni@hallinger.org> wrote: > >> Hi there, >> if you measure the altitude with a barometric device, you do not get >> the >> altitude above the ellipsoid. You have to account for that at the >> input >> of your data. >> >> With the "cs" command you define your input data to be in a specific >> >> coordinate system, and also your altitude has to be given in that >> system. If you just put the barometric altitude there (which you >> usually >> did calibrate to a map, didn't you?) you have to transform the >> altitude >> manually if the reference altitude differs. >> >> Am 2021-02-19 8:44, schrieb Balambér Hakapesz: >>> Hi! >>> >>> When generating 3D models, Proj4 transforms between different >>> coordinate systems. >>> This also transforms the ellipsoidal altitude, but the data always >>> refer to altitude above sea level and should not be changed. >>> The finished models do not fit the topography, you have to cheat >> with >>> the height to be good. >>> >>> Balázs Holl. >>> >>> [1] >>> Mentes a vírusoktól. www.avg.com [1] [1] [1] [1] >>> >>> >>> >>> Links: >>> ------ >>> [1] >>> >> >
>>> _______________________________________________ >>> Therion mailing list >>> Therion@speleo.sk >>> https://mailman.speleo.sk/listinfo/therion >> _______________________________________________ >> Therion mailing list >> Therion@speleo.sk >> https://mailman.speleo.sk/listinfo/therion > > > Links: > ------ > [1] http://www.avg.com > [2] >
> _______________________________________________ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[2] Mentes a vírusoktól. www.avg.com [1] [2]
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
[3] Mentes a vírusoktól. www.avg.com [3]
Links: ------ [1] http://www.avg.com [2] http://kml.th [3] http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi, which version of Therion and Proj are you using? I get 19.00961002698361,47.52649340144701,262.00000000000000 in the kml export with the latest Therion and Proj 7.2.1 Best wishes Martin On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)), so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific
coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
Hi!
When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good.
Balázs Holl.
[1] Mentes a vírusoktól. www.avg.com [1] [1]
Links: ------ [1]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
latest Therion 5.5.7 (now install): <LineString><coordinates> 19.00961011626948,47.52649337576408,*291*.08568208824045 19.00961011450532,47.52649337534078,281.08568208855468 19.00962225574169,47.52658294585592,281.08562306819113 19.00975449765885,47.52657472222689,281.08549506128293 </coordinates></LineString> On Fri, Feb 19, 2021 at 8:19 PM Martin Budaj <m.budaj@gmail.com> wrote:
Hi,
which version of Therion and Proj are you using? I get 19.00961002698361,47.52649340144701,262.00000000000000 in the kml export with the latest Therion and Proj 7.2.1
Best wishes Martin
On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz < holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)), so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific
coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz:
Hi!
When generating 3D models, Proj4 transforms between different coordinate systems. This also transforms the ellipsoidal altitude, but the data always refer to altitude above sea level and should not be changed. The finished models do not fit the topography, you have to cheat with the height to be good.
Balázs Holl.
[1] Mentes a vírusoktól. www.avg.com [1] [1]
Links: ------ [1]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
therion 5.5.7+0df52bd+dev (2021-02-18) - using Proj 5.1.0, compiled against 5.1.0 On Fri, Feb 19, 2021 at 8:40 PM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
latest Therion 5.5.7 (now install):
<LineString><coordinates> 19.00961011626948,47.52649337576408,*291*.08568208824045 19.00961011450532,47.52649337534078,281.08568208855468 19.00962225574169,47.52658294585592,281.08562306819113 19.00975449765885,47.52657472222689,281.08549506128293 </coordinates></LineString>
On Fri, Feb 19, 2021 at 8:19 PM Martin Budaj <m.budaj@gmail.com> wrote:
Hi,
which version of Therion and Proj are you using? I get 19.00961002698361,47.52649340144701,262.00000000000000 in the kml export with the latest Therion and Proj 7.2.1
Best wishes Martin
On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz < holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-3468513418640853693_m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf)), so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Hi there, if you measure the altitude with a barometric device, you do not get the altitude above the ellipsoid. You have to account for that at the input of your data.
With the "cs" command you define your input data to be in a specific
coordinate system, and also your altitude has to be given in that system. If you just put the barometric altitude there (which you usually did calibrate to a map, didn't you?) you have to transform the altitude manually if the reference altitude differs.
Am 2021-02-19 8:44, schrieb Balambér Hakapesz: > Hi! > > When generating 3D models, Proj4 transforms between different > coordinate systems. > This also transforms the ellipsoidal altitude, but the data always > refer to altitude above sea level and should not be changed. > The finished models do not fit the topography, you have to cheat with > the height to be good. > > Balázs Holl. > > [1] > Mentes a vírusoktól. www.avg.com [1] [1] > > > > Links: > ------ > [1] >
> _______________________________________________ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-3468513418640853693_m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Hi, Proj 4 and 5 uses a different conversion than Proj 6+ resulting in the height difference. Actually, the behaviour of Therion was inconsistent: when doing internal conversions it transformed only x and y coordinates, but when creating e.g. KML output it transformed all x, y and z coordinates. The latest commit (b6bcc92) unifies this to converting just x and y for all coordinate systems transformations. If there is a real need for a switch between converting and not converting the heights, let us know. Martin On Fri, Feb 19, 2021 at 8:41 PM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
therion 5.5.7+0df52bd+dev (2021-02-18) - using Proj 5.1.0, compiled against 5.1.0
On Fri, Feb 19, 2021 at 8:40 PM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
latest Therion 5.5.7 (now install):
<LineString><coordinates> 19.00961011626948,47.52649337576408,*291*.08568208824045 19.00961011450532,47.52649337534078,281.08568208855468 19.00962225574169,47.52658294585592,281.08562306819113 19.00975449765885,47.52657472222689,281.08549506128293 </coordinates></LineString>
On Fri, Feb 19, 2021 at 8:19 PM Martin Budaj <m.budaj@gmail.com> wrote:
Hi,
which version of Therion and Proj are you using? I get 19.00961002698361,47.52649340144701,262.00000000000000 in the kml export with the latest Therion and Proj 7.2.1
Best wishes Martin
On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz < holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_1264032343771874480_m_-3468513418640853693_m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger <beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz:
Very rarely can anyone work at ellipsoidal heights. In local coordinate systems, it only makes sense for upper geodetic calculations. Only for GPS measurements we get an ellipsoidal altitude, even there the devices can immediately calculate the altitude of the EGM96 model with an altitude above sea level (with a few meters error which is not significant compared to the 15m altitude error of handheld GPS). Proj4 calculates the horizontal coordinates well, but there is a serious error in the height coordinates (for special national projections (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf) ), so it would be better if not we would count on it but leave the altitude unchanged. Could it be an option not to change the height with Therion?
[2] Mentes a vírusoktól. www.avg.com [2]
On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger <beni@hallinger.org> wrote:
> Hi there, > if you measure the altitude with a barometric device, you do not get > the > altitude above the ellipsoid. You have to account for that at the > input > of your data. > > With the "cs" command you define your input data to be in a specific > > coordinate system, and also your altitude has to be given in that > system. If you just put the barometric altitude there (which you > usually > did calibrate to a map, didn't you?) you have to transform the > altitude > manually if the reference altitude differs. > > Am 2021-02-19 8:44, schrieb Balambér Hakapesz: >> Hi! >> >> When generating 3D models, Proj4 transforms between different >> coordinate systems. >> This also transforms the ellipsoidal altitude, but the data always >> refer to altitude above sea level and should not be changed. >> The finished models do not fit the topography, you have to cheat > with >> the height to be good. >> >> Balázs Holl. >> >> [1] >> Mentes a vírusoktól. www.avg.com [1] [1] >> >> >> >> Links: >> ------ >> [1] >> >
>> _______________________________________________ >> Therion mailing list >> Therion@speleo.sk >> https://mailman.speleo.sk/listinfo/therion > _______________________________________________ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion
Links: ------ [1] http://www.avg.com [2]
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_1264032343771874480_m_-3468513418640853693_m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
Yes, it is necessary, we are forced to cheat at the Hungarian EOV coordinates. Thanks. I'm looking forward to the Windows installer. Balázs. On Mon, Feb 22, 2021 at 9:19 PM Martin Budaj <m.budaj@gmail.com> wrote:
Hi,
Proj 4 and 5 uses a different conversion than Proj 6+ resulting in the height difference.
Actually, the behaviour of Therion was inconsistent: when doing internal conversions it transformed only x and y coordinates, but when creating e.g. KML output it transformed all x, y and z coordinates. The latest commit (b6bcc92) unifies this to converting just x and y for all coordinate systems transformations.
If there is a real need for a switch between converting and not converting the heights, let us know.
Martin
On Fri, Feb 19, 2021 at 8:41 PM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
therion 5.5.7+0df52bd+dev (2021-02-18) - using Proj 5.1.0, compiled against 5.1.0
On Fri, Feb 19, 2021 at 8:40 PM Balambér Hakapesz < holl.balazs63@gmail.com> wrote:
latest Therion 5.5.7 (now install):
<LineString><coordinates> 19.00961011626948,47.52649337576408,*291*.08568208824045 19.00961011450532,47.52649337534078,281.08568208855468 19.00962225574169,47.52658294585592,281.08562306819113 19.00975449765885,47.52657472222689,281.08549506128293 </coordinates></LineString>
On Fri, Feb 19, 2021 at 8:19 PM Martin Budaj <m.budaj@gmail.com> wrote:
Hi,
which version of Therion and Proj are you using? I get 19.00961002698361,47.52649340144701,262.00000000000000 in the kml export with the latest Therion and Proj 7.2.1
Best wishes Martin
On Fri, Feb 19, 2021 at 11:25 AM Balambér Hakapesz < holl.balazs63@gmail.com> wrote:
thconfig: #cs long-lat #fix 0 19.009617 47.526453 262 cs EPSG:23700 # Hungarian EOV fix 0 647151 242509 262
kml: <LineString><coordinates> 19.00961011626948,47.52649337576407,291.08568208889801
291-262 = 29 m = 44m geoid height - 15m Proj4 error
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-8081509530659361150_m_1264032343771874480_m_-3468513418640853693_m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Fri, Feb 19, 2021 at 11:06 AM Benedikt Hallinger < beni@hallinger.org> wrote:
Isn't EGM84 the reference ellipsoid currently used by WGS84? What you get with GPS is *not* sea level, but the altitude above that reference geoid (which takes into account gravital anonalys).
If you calibrate your barometric altimeter to the hieght given by a height coordinate of WGS84 (like read from your car's navi at the parking lot, or from a map calibrated to WGS84) then you should get about the same altitude. If you take the cave location from GPS and enter that coordinates into the therion dataset wirh correct "cs" marking, the conversion should yield the correct result. If you take the altitude from a map (or an altimeter calibrated to that map) in another coordinate system, you have to either apply an offset manually, add an instrument correction factor in therion, or supply the correct coordinate system (which then probalby demands conversion of the lat/lon coordinates).
If generating 3D surfce meshes, you also need to supply matching coordinate systems data and/or specify the correct "cs" parameter.
I think your problem comes from mixing coordinate systems in respect to the height model, either at data input or when using the height mesh.
Am 2021-02-19 9:49, schrieb Balambér Hakapesz: > Very rarely can anyone work at ellipsoidal heights. In local > coordinate systems, it only makes sense for upper geodetic > calculations. Only for GPS measurements we get an ellipsoidal > altitude, even there the devices can immediately calculate the > altitude of the EGM96 model with an altitude above sea level (with a > few meters error which is not significant compared to the 15m altitude > error of handheld GPS). > Proj4 calculates the horizontal coordinates well, but there is a > serious error in the height coordinates (for special national > projections > (http://www.agt.bme.hu/gis/workshop4/eloadasok/proj_poszter_3d.pdf) ), > so it would be better if not we would count on it but leave the > altitude unchanged. > Could it be an option not to change the height with Therion? > > [2] > Mentes a vírusoktól. www.avg.com [2] > > On Fri, Feb 19, 2021 at 9:18 AM Benedikt Hallinger > <beni@hallinger.org> wrote: > >> Hi there, >> if you measure the altitude with a barometric device, you do not get >> the >> altitude above the ellipsoid. You have to account for that at the >> input >> of your data. >> >> With the "cs" command you define your input data to be in a specific >> >> coordinate system, and also your altitude has to be given in that >> system. If you just put the barometric altitude there (which you >> usually >> did calibrate to a map, didn't you?) you have to transform the >> altitude >> manually if the reference altitude differs. >> >> Am 2021-02-19 8:44, schrieb Balambér Hakapesz: >>> Hi! >>> >>> When generating 3D models, Proj4 transforms between different >>> coordinate systems. >>> This also transforms the ellipsoidal altitude, but the data always >>> refer to altitude above sea level and should not be changed. >>> The finished models do not fit the topography, you have to cheat >> with >>> the height to be good. >>> >>> Balázs Holl. >>> >>> [1] >>> Mentes a vírusoktól. www.avg.com [1] [1] >>> >>> >>> >>> Links: >>> ------ >>> [1] >>> >> > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail >>> _______________________________________________ >>> Therion mailing list >>> Therion@speleo.sk >>> https://mailman.speleo.sk/listinfo/therion >> _______________________________________________ >> Therion mailing list >> Therion@speleo.sk >> https://mailman.speleo.sk/listinfo/therion > > > Links: > ------ > [1] http://www.avg.com > [2] > http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail > _______________________________________________ > Therion mailing list > Therion@speleo.sk > https://mailman.speleo.sk/listinfo/therion _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> Mentes a vírusoktól. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> <#m_-8081509530659361150_m_1264032343771874480_m_-3468513418640853693_m_2109412960721514408_m_-5536043658431662593_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> _______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
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
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
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
67fffb0 installation does not work on Windows7 Balázs. On Mon, Feb 22, 2021 at 10:28 PM Balambér Hakapesz <holl.balazs63@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@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
No problem - just permission. On Mon, Feb 22, 2021 at 11:14 PM Balambér Hakapesz <holl.balazs63@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@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@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
I’m not sure about your problem, but as I find the most accurate heights are those from DMR5 models for Slovakia and Czechia. But there are differences between DMR3 and DMR5 as you may see on screenshot. Martin
A probléma abban volt, hogy a Therion a Proj5 segítségével akkor is transzformálta a magasságot ha az tenger szint feletti magasság volt, amit nem kell változtatni. Ez most megoldódott. Balázs. On Tue, Feb 23, 2021 at 2:54 PM Martin Sluka via Therion <therion@speleo.sk> wrote:
I’m not sure about your problem, but as I find the most accurate heights are those from DMR5 models for Slovakia and Czechia. But there are differences between DMR3 and DMR5 as you may see on screenshot.
Martin
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
The problem was that Therion used the Proj5 to transform the altitude even if it was above sea level, which did not need to be changed. This is now resolved. Balázs. On Tue, Feb 23, 2021 at 5:05 PM Balambér Hakapesz <holl.balazs63@gmail.com> wrote:
A probléma abban volt, hogy a Therion a Proj5 segítségével akkor is transzformálta a magasságot ha az tenger szint feletti magasság volt, amit nem kell változtatni. Ez most megoldódott. Balázs.
On Tue, Feb 23, 2021 at 2:54 PM Martin Sluka via Therion < therion@speleo.sk> wrote:
I’m not sure about your problem, but as I find the most accurate heights are those from DMR5 models for Slovakia and Czechia. But there are differences between DMR3 and DMR5 as you may see on screenshot.
Martin
_______________________________________________ Therion mailing list Therion@speleo.sk https://mailman.speleo.sk/listinfo/therion
participants (5)
-
Balambér Hakapesz -
Benedikt Hallinger -
Martin Budaj -
Martin Sluka -
Tarquin Wilton-Jones