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

On Mon, 17 Oct 2022, Greg Troxel wrote: Andrew C Aitchison writes: I do know that 4326 uses a geoid which is less accurate *over Great Britain* than the one the Great Britain Ordnance Survey have been using for a century or two (OSGB36 Datum 1936, Airy Spheriod 1830!). I suspect that other na

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

Andrew C Aitchison writes: > On Mon, 17 Oct 2022, Diogo wrote: > >> Hi Andrew. Thanks for taking the time to read my email and reply it. >> I'm aware of Copernicus land and other datasets like SMRT3 and ASTER >> however I need the best possible elevation resolution available. To do so, >> I'm ge

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

On Mon, 17 Oct 2022, Diogo wrote: Hi Andrew. Thanks for taking the time to read my email and reply it. I'm aware of Copernicus land and other datasets like SMRT3 and ASTER however I need the best possible elevation resolution available. To do so, I'm getting the elevation dataset directly from c

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

Diogo, There are far more CRS definitions in the PROJ database, mostly coming from the EPSG dataset, than there are known transformations from/to those CRS to other ones Genoa 1942 height (Italy) $echo "14.995 37.755 3357" | PROJ_NETWORK=ON gdaltransform --debug on -s_srs"EPSG:4326+3855"

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

Italy? I am not aware of any Geoid grid file for Italy in PROJ-Data: https://cdn.proj.org/ EPSG:5214 is the vertical coordinate reference system, not a geoid model. https://epsg.org/crs_5214/Genoa-1942-height.html .___ ._ ..._ .. . ._. .___ .. __ . _. . __.. ... ._ .__ Entre dos pensamiento

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

Hi, Maybe there is no transformation for converting heights from N2000 into WGS84 heights registered into the EPSG database. I found only two N2000 related transformations EPSG:9573 and EPSG:9574 and they seem convert to EVRF2019 height. Proj can convert between our national height systems N200

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

Hi Andrew. Thanks for taking the time to read my email and reply it. I'm aware of Copernicus land and other datasets like SMRT3 and ASTER however I need the best possible elevation resolution available. To do so, I'm getting the elevation dataset directly from countries geographic institutes and co

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

Hi! I needed the docs are correct but as this is the second time it confuses people maybe the wording should be revised? https://github.com/OSGeo/gdal/pull/5969 Any ideas? On Mon, 17 Oct 2022, 11:49 Nicolas Godet, wrote: > Indeed, this is right. > My bad.. > -- > *D

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

Indeed, this is right. My bad.. De : Andrew C Aitchison Envoyé : lundi 17 octobre 2022 10:25 À : Nicolas Godet Cc : gdal-dev@lists.osgeo.org Objet : Re: [gdal-dev] [Doc] gdal_calc.py extent option On Mon, 17 Oct 2022, Nicolas Godet wrote: > Dear Devs, > > In do

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

On Mon, 17 Oct 2022, Nicolas Godet wrote: Dear Devs, In documentation, extent param description seems a bit odd to me. union - the extent (bounds) of the output will be the minimal rectangle that contains all the input extents. inte

[gdal-dev] [Doc] gdal_calc.py extent option

Dear Devs, In documentation, extent param description seems a bit odd to me. union - the extent (bounds) of the output will be the minimal rectangle that contains all the input extents. intersect - the extent (bounds) of the output wi