[PROJ] Is proj line associate to EPSG:31467 behaving properly?
Thomas Knudsen
knudsen.thomas at gmail.com
Wed Dec 1 03:54:16 PST 2021
EPSG:4326 is geographical coordinates in (some unspecified realization of)
the World Geodetic System 1984 (WGS84). EPSG:31467 is GK zone 3 coordinates
on the "Deutsche Hauptdreiecksnetz" (DHDN).
As these are two different systems, you need a datum shift, which you get
from your proj_create_crs_to_crs call (try "projinfo -s epsg:4326 -t
epsg:31467" to see what actually goes on behind the scenes).
By swapping your output system to a plain PROJ projection definition, you
probably bypass the datum shift, and take the EPSG:4326 coordinates, which
are defined on the GRS80-ellipsoid with a semimajor axis of 6378137 m, and
drop them directly onto the somewhat smaller Bessel ellipsoid (semimajor
axis = 6377397.155 m), which makes your GK coordinates nonsensical.
But since both EPSG:4326 and EPSG:31467 are 2D systems, you should probably
not worry too much about your height coordinate being nonsensical, but
rather that your coordinates in general are.
The proj_create_crs_to_crs call should give you the right operation. Since
you apparently use the PROJ APi in your own code, why not simply add the 40
cm directly to your output coordinates?
But considering the indtermination of EPSG:4326 (multiple realizations
differing by up to 2 m), it's hard to see the idea of adding 40 cm: Your
overall accuracy is much worse than that.
Probably, your client knows what they actually mean by EPSG:4326, and you
will be able to construct a sufficient transformation somehow - but you
need to be careful and have a good set of control points for checking.
Den ons. 1. dec. 2021 kl. 09.54 skrev Kilian Demeulemeester <
kilian.demeulemeester at yellowscan-lidar.com>:
> Hi!
>
> Our client is willing to generate his data in EPSG:31467 but he wants to
> translate +40cm on the y axis.
>
> So I figured out that I would use the corresponding PROJ.4 "+proj=tmerc
> +lat_0=0 +lon_0=9 +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +units=m +no_defs
> +type=crs" code and modify the y_0=0 with a y_0=0.4
>
> 1. Data are originally expressed in EPSG:4326
>
> 2. Using the EPSG code: via proj API, I transform the data via
> proj_create_crs_to_crs(..., "EPSG:4326", "EPSG:31497")
>
> 3. Now, if I replace the "EPSG:31467" with "+proj=tmerc +lat_0=0 +lon_0=9
> +k=1 +x_0=3500000 +y_0=0 +ellps=bessel +units=m +no_defs +type=crs", (the
> corresponding proj line), the data are z-offsetted by approx 1000m
>
> I know that for some CRS, the PROJ.4 is not enough to generate the correct
> coordinates. Is that the case for this transformation?
>
> Ultimately, is there a something (+proj=pipeline ?) that I could use that
> would transform my data from EPSG:4326 to EPSG:31497 with a translation of
> +40cm on the y axis?
>
> Thank you all!
>
> Kilian
>
>
> *Kilian Demeulemeester*
> Software Project Lead - R&D
>
> [image: logo_Yellowscan] <https://yellowscan-lidar.com>
>
> 525 Avenue Saint Sauveur du Pin
> 34980 Saint-Clément-De-Rivière - France
> Tel: +33 (0)4 11 93 14 06
> yellowscan-lidar.com
>
> <https://www.yellowscan-lidar.com/events/category/demo-days/?utm_source=email_signature&utm_medium=email&utm_campaign=demodays_banner>
> _______________________________________________
> PROJ mailing list
> PROJ at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/proj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20211201/c9296333/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x-disclaimer-534644925-0.png
Type: image/png
Size: 1125 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20211201/c9296333/attachment.png>
More information about the PROJ
mailing list