<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>without a pipeline given this might be true, but using the -ct
option, the docs clearly say "It must take into account
the axis order of the source and target CRS.". so the axisswap was
the missing part in my string and now it works.</p>
<p>thanks for your help =)<br>
</p>
<div class="moz-cite-prefix">Am 09.02.2021 um 18:56 schrieb Markus
Metz:<br>
</div>
<blockquote type="cite"
cite="mid:CAG+h=FHBxU+7Xtsph-R9nN9OuuKm2yasXT8hveqYRETYspVwpg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr"><br>
<br>
On Tue, Feb 9, 2021 at 9:15 AM Karsten Tebling <<a
href="mailto:tebling@masuch.de" moz-do-not-send="true">tebling@masuch.de</a>>
wrote:<br>
><br>
> the projinfo-command was exactly what i needed but didn't
know it exists! the ogr2ogr -ct command works now, thank you
very much!<br>
<div><br>
</div>
<div>Interesting, because I am sure my previous suggestion to
include the axis swap step was wrong.<br>
</div>
<div><br>
</div>
<div>ogr2ogr should handle the axis order on its own correctly
if you just provide</div>
<div>ogr2ogr -s_srs "EPSG:31468" -t_srs "EPSG:25833" <br>
</div>
<div>without a custom pipeline given with the -ct option</div>
<div><br>
</div>
<div>Markus M<br>
</div>
<div><br>
</div>
<div>></div>
> could this example be added to the official examples on <a
href="https://gdal.org/programs/ogr2ogr.html#ogr2ogr"
moz-do-not-send="true">https://gdal.org/programs/ogr2ogr.html#ogr2ogr</a>
? i think the -ct option is very useful and an example for it
would be good. i could also try to edit it on my own and send a
pull request if that helps<br>
><br>
> i just like to use the console if i can, QGIS has it's
advantages but if i have the option to use gdal directly or via
a wrapper like QGIS, i like to use gdal directly. this also
saves me from the pain when the wrapper does implement something
wrong or uses it's own functions instead of gdal, which in
addition could change every new version and need to be checked.
using gdal directly is much more reliable for me.<br>
><br>
> Am 08.02.2021 um 22:18 schrieb Markus Metz:<br>
><br>
><br>
><br>
> On Mon, Feb 8, 2021 at 10:23 AM Karsten Tebling <<a
href="mailto:tebling@masuch.de" moz-do-not-send="true">tebling@masuch.de</a>>
wrote:<br>
> ><br>
> > gdalinfo for NTv2LSBB_LSA.gsb gave the following
information:<br>
> ><br>
> > Size is 256, 264<br>
> > Coordinate System is: EPSG 4326<br>
> > Origin: 10.5, 53.1<br>
> > SYSTEM_F: S4283<br>
> > SYSTEM_T: ETRS89<br>
> > Upper Left 10.5, 53.1<br>
> > Lower Left 10.5, 50.9<br>
> > Upper Right 13.3, 53.1<br>
> > Lower Right 13.3, 50.9<br>
> ><br>
> > ogrinfo for punkte_31468.dxf gave the following
information:<br>
> ><br>
> > Geometry: Unknown (any)<br>
> > Feature Count: 36<br>
> > Extent: (4523806.5, 5758974.7) - (4524134.7,
5759234.0)<br>
> > Layer SRS WKT: (unknown)<br>
> ><br>
> > according to QGIS punkte_31468.dxf should be at 11.6
52.1 which is inside the extent of the NTv2LSBB_LSA.gsb. after
checking the documentation for the NTv2LSBB_LSA.gsb i noticed i
couldn't use it for transformations from 31468 to 25833, that's
why i tried it with BETA2007.gsb instead, but it didn't work
either - it gave the same errors.<br>
> ><br>
> > gdalinfo for BETA2007.gsb gave the following
information:<br>
> ><br>
> > Size is 62, 84<br>
> > Coordinate System is: EPSG 4326<br>
> > Origin: 5.4, 55.4<br>
> > SYSTEM_F: DHDN90<br>
> > SYSTEM_T: ETRS89<br>
> > Upper Left 5.4, 55.4<br>
> > Lower Left 5.4, 47.0<br>
> > Upper Right 15.8, 55.4<br>
> > Lower Right 15.6, 47.0<br>
> ><br>
> > my adjusted code for BETA2007.gsb looks like:<br>
> ><br>
> > ogr2ogr -s_srs "EPSG:31468" -t_srs "EPSG:25833" -dim
XYZ -ct "+proj=pipeline +step +inv +proj=tmerc +lat_0=0
+lon_0=12 +k=1 +x_0=4500000 +y_0=0 +ellps=bessel +step
+proj=hgridshift +grids=BETA2007.gsb +step +proj=utm +zone=33
+ellps=GRS80" -f DXF punkte_25833.dxf punkte_31468.dxf<br>
> ><br>
> > the points i used to test this were digitized around
Magdeburg, Saxony-Anhalt in EPSG:31468. according to aerial data
and openstreetmap, the position and coordinate system are
correct when i check it in QGIS and switch to different
coordinate systems.<br>
><br>
> Wit PROJ 7.2.1 and<br>
> projinfo -o PROJ -s "EPSG:31468" -t "EPSG:25833"<br>
> I get<br>
> Operation No. 1:<br>
><br>
> unknown id, Inverse of 3-degree Gauss-Kruger zone 4 + DHDN
to ETRS89 (8) + UTM zone 33N, 0.9 m, Germany - onshore - states
of Baden-Wurtemberg, Bayern, Berlin, Brandenburg, Bremen,
Hamburg, Hessen, Mecklenburg-Vorpommern, Niedersachsen,
Nordrhein-Westfalen, Rheinland-Pfalz, Saarland, Sachsen,
Sachsen-Anhalt, Schleswig-Holstein, Thuringen.<br>
><br>
> PROJ string:<br>
> +proj=pipeline<br>
> +step +proj=axisswap +order=2,1<br>
> +step +inv +proj=tmerc +lat_0=0 +lon_0=12 +k=1
+x_0=4500000 +y_0=0<br>
> +ellps=bessel<br>
> +step +proj=hgridshift +grids=de_adv_BETA2007.tif<br>
> +step +proj=utm +zone=33 +ellps=GRS80<br>
><br>
> -------------------------------------<br>
> Operation No. 2:<br>
><br>
> unknown id, Inverse of 3-degree Gauss-Kruger zone 4 + DHDN
to ETRS89 (2) + UTM zone 33N, 3 m, Germany - states of former
West Germany onshore - Baden-Wurtemberg, Bayern, Bremen,
Hamburg, Hessen, Niedersachsen, Nordrhein-Westfalen,
Rheinland-Pfalz, Saarland, Schleswig-Holstein.<br>
><br>
> PROJ string:<br>
> +proj=pipeline<br>
> +step +proj=axisswap +order=2,1<br>
> +step +inv +proj=tmerc +lat_0=0 +lon_0=12 +k=1
+x_0=4500000 +y_0=0<br>
> +ellps=bessel<br>
> +step +proj=push +v_3<br>
> +step +proj=cart +ellps=bessel<br>
> +step +proj=helmert +x=598.1 +y=73.7 +z=418.2 +rx=0.202
+ry=0.045 +rz=-2.455<br>
> +s=6.7 +convention=position_vector<br>
> +step +inv +proj=cart +ellps=GRS80<br>
> +step +proj=pop +v_3<br>
> +step +proj=utm +zone=33 +ellps=GRS80<br>
><br>
><br>
> It seems your custom definitions of the coordinate
operation are missing the axis swap step "+step +proj=axisswap
+order=2,1".<br>
> According to "projinfo -o WKT2:2019 "EPSG:31468", northing
is the first axis in EPSG:31468, thus the need for the axis
swap.<br>
><br>
> If you trust the QGIS coordinate operation, then why do you
provide a custom coordinate operation to ogr2ogr with the -ct
option?<br>
><br>
> ><br>
> > Am 06.02.2021 um 22:24 schrieb Markus Metz:<br>
> ><br>
> ><br>
> ><br>
> > On Fri, Feb 5, 2021 at 3:40 PM Karsten Tebling <<a
href="mailto:tebling@masuch.de" moz-do-not-send="true">tebling@masuch.de</a>>
wrote:<br>
> > ><br>
> > > Hello,<br>
> > ><br>
> > > i'm struggling with how to use the -ct option in
ogr2ogr and could need<br>
> > > some help.<br>
> > ><br>
> > > i copied a NTv2.gsb to osgeo4w64/share/proj and
edited the proj.db by<br>
> > > inserting a new row in the
grid_transformation-table. using this<br>
> > > transformation in qgis works. however when i try
to use it in ogr2ogr<br>
> > > with the same data i always get "failed to
reproject feature (geometry<br>
> > > probably out of source or destination srs). no
known way to write<br>
> > > feature with geometry 'none'". here is my code:<br>
> > ><br>
> > > ogr2ogr -s_srs "EPSG:31468" -t_srs "EPSG:25833"
-dim XYZ -ct<br>
> > > "+proj=pipeline +step +inv +proj=tmerc +lat_0=0
+lon_0=12 +k=1<br>
> > > +x_0=4500000 +y_0=0 +ellps=bessel +step
+proj=hgridshift<br>
> > > +grids=NTv2LSBB_LSA.gsb +step +proj=utm +zone=33
+ellps=GRS80" -f DXF<br>
> > > punkte_25833.dxf punkte_31468.dxf<br>
> > ><br>
> ><br>
> > Is the grid NTv2LSBB_LSA.gsb used for hgridshift
really covering the full extent of punkte_31468.dxf ?<br>
> > You can check with "gdalinfo NTv2LSBB_LSA.gsb" and
"ogrinfo -so punkte_31468.dxf".<br>
> ><br>
> > Markus M<br>
> ><br>
> > > i'm using the latest qgis-ltr and osgeo4w shell<br>
> > ><br>
> > > greetings<br>
> > > _______________________________________________<br>
> > > gdal-dev mailing list<br>
> > > <a href="mailto:gdal-dev@lists.osgeo.org"
moz-do-not-send="true">gdal-dev@lists.osgeo.org</a><br>
> > > <a
href="https://lists.osgeo.org/mailman/listinfo/gdal-dev"
moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a></div>
</blockquote>
</body>
</html>