1) OK, I found out that the definition in the dataset file includes a conversion from altitude to ellipsoid height which explains the difference. 2) This is very possible that I have an old IGNF file from PROJ4. I will check that now. Thanks for the clue, I didn't know there was an update on this file. BQ_BEGIN BQ_END BQ_BEGIN BQ_BEGIN 1.a) NEW SYNTAX: z not correct (grid shift not used) echo 600000.00000000 300097.53400000 0.00000000 | ./bin/cs2cs IGNF:LAMB1 +to IGNF:UTM31RGF93 452845.19 5583309.40 0.00 BQ_END BQ_END Which grid shift file are you refering to ? ntf_r93.gsb ? I assume. But this is a horizontal datum shift. No vertical correction. This horizontal shift is applied, otherwise you'd get "452843.46 5583308.13 0.00" as a result BQ_BEGIN BQ_BEGIN 1.b) OLD SYNTAX: z correct: echo 600000.00000000 300097.53400000 0.00000000 | ./bin/cs2cs +init=IGNF:LAMB1 +to +init=IGNF:UTM31RGF93 452845.19 5583309.40 43.64 BQ_END BQ_END I have no idea how you get this result. You should really try stopping using the (old) IGNF file with newer PROJ. This is mostly in unsupported land. Even when trying, with both PROJ 5.2 and latest PROJ master, and with the IGNF file supplied with PROJ 5.2, I still get the "452845.19 5583309.40 0.00" result. Did you tweak your IGNF file ? The only way I can get something close to what you get is by composing a manual pipeline using the gr3df97a grid with: echo 600000.00000000 300097.53400000 0.00000000 | PROJ_NETWORK=ON PROJ_DEBUG=3 bin/cct +proj=pipeline +step +inv +proj=lcc +lat_1=49.5 +lat_0=49.5 +lon_0=0 +k_0=0.99987734 +x_0=600000 +y_0=200000 +a=6378249.2 +rf=293.466021 +pm=paris +step +proj=cart +ellps=clrk80ign +step +proj=xyzgridshift +grids=fr_ign_gr3df97a.tif +grid_ref=output_crs +ellps=GRS80 +step +inv +proj=cart +ellps=GRS80 +step +proj=utm +zone=31 +ellps=GRS80 452845.1911 5583309.3959 42.9892 inf But it seems a bit dubious to have a Z correction term for NTF <--> RGF93. And newer PROJ when operating with 2D CRS doesn't change the Z value. You may sometimes upgrade your CRS to 3D by adding the --3d switch to cs2cs or projinfo, but if the transformations available are only 2D ones, that won't make miracles. What does Circe does under the hood for that transformation? BQ_BEGIN BQ_BEGIN 2) Example where the old syntax gives a wrong result while the new syntax works: 2.a) OLD SYNTAX from cartographic to geocentric coordinates / result is wrong echo 652760.737 7033791.243 43.642 | PROJ_DEBUG=3 ./bin/cs2cs +init=IGNF:LAMB93 +to +init=IGNF:RGF93 4070355.05 166080.07 4891332.24 BQ_END BQ_END I do get "4070327.25 166078.93 4891298.61". This really smells like your IGNF file isn't the one of PROJ 5.2 BQ_BEGIN BQ_BEGIN 2.b) NEW SYNTAX from cartographic to geocentric coordinates / result is correct echo 652760.737 7033791.243 43.642 | PROJ_DEBUG=3 ./bin/cs2cs IGNF:LAMB93 +to IGNF:RGF93 4070327.25 166078.93 4891298.61 _______________________________________________ PROJ mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.osgeo.org/mailman/listinfo/proj | https://lists.osgeo.org/mailman/listinfo/proj ] BQ_END _______________________________________________ PROJ mailing list [ mailto:[email protected] | [email protected] ] [ https://lists.osgeo.org/mailman/listinfo/proj | https://lists.osgeo.org/mailman/listinfo/proj ] BQ_END -- [ http://www.spatialys.com/ | http://www.spatialys.com ] My software is free, but my time generally not.
_______________________________________________ PROJ mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/proj
