Re: [gdal-dev] [EXT] Re: [Doc] gdal_calc.py extent option

2022-10-18 Thread Laurențiu Nicola via gdal-dev
Hi Matt, The definitions are correct. For the union you want a rectangle (or polygon) that's larger than the input, indeed. But you want the smallest of those rectangles, because there's an infinity of them. The larger ones would cover an arbitrary area of the plane (or the globe, if you want).

Re: [gdal-dev] [EXT] Re: [Doc] gdal_calc.py extent option

2022-10-18 Thread Matt . Wilkie
To my mind the outputs of Union should be the largest extent area and Intersect is the smallest extent area. However any explanation in words alone will always have some ambiguity. It can't be avoided. Union and Intersect via Wiki.GIS.com (I do find the intersect diagram less clear in this exam

Re: [gdal-dev] Problem with coordinate transformation

2022-10-18 Thread Philippe Lelong
Hi, thanks again for the explanation I uploaded the tif file I was trying to render here: https://www.virtual-winds.org/maitai/gebco.tif The thing that worries me is that it is the first case since we upgraded to 3.4.1 a quite a while ago, and I am wondering how it can work for all other tif

Re: [gdal-dev] Problem with coordinate transformation

2022-10-18 Thread Laurențiu Nicola via gdal-dev
Hi, According to the migration guide, this is only relevant for OSRImportFromEPSG, SetWellKnownGeogCS and SetFromUserInput. But then again, you were using the equivalent of OSRImportFromWkt. I never noticed any issues when using spatial references loaded from existing rasters, but you might wa

Re: [gdal-dev] Problem with coordinate transformation

2022-10-18 Thread Philippe Lelong
Thanks very much, I would never have figured that out myself. Just to make it clear I should add this flag on all OGRSpatialReference or only when it is loaded with importFromWkt ? --Philippe From: gdal-dev on behalf of Laurențiu Nicola via gdal-dev Sent:

Re: [gdal-dev] Problem with coordinate transformation

2022-10-18 Thread Laurențiu Nicola via gdal-dev
Hi Philippe, The new behaviour is correct. See https://gdal.org/development/rfc/rfc73_proj6_wkt2_srsbarn.html#axis-order-issues for the axis order issue, a change made in GDAL 3.0. You can find a solution in https://github.com/OSGeo/gdal/blob/v3.5.0/MIGRATION_GUIDE.TXT#L67 (calling SetAxisMapp

[gdal-dev] Problem with coordinate transformation

2022-10-18 Thread Philippe Lelong
Hi, I have an app build against GDAL 3.4.1 and PROJ6, and the same app build against GDAL 2.1.3 and PROJ4. They are not giving the same result when using OGRCoordinateTransformation. If I do const char *their = "GEOGCS[\"WGS 84\",DATUM[\"WGS_1984\",SPHEROID[\"WGS 84\",6378137,298.25722

[gdal-dev] Fwd: Transformations with same horizontal datum but different geoid outputs the same Z value

2022-10-18 Thread Diogo
Hi there! Thanks, everyone for your help and recommendations provided. Even, I wasn't aware of that, as many other things I see. I thought that It could be translated directly > Genoa 1942 height (Italy) > > $ echo "14.995 37.755 3357" | PROJ_NETWORK=ON gdaltransform --debug on -s_srs > "EPSG: