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

I had to respond just because ... GPS did not overthrow the Airy ellipsoid! It is alive and well in BNG where it should be. There are also organizations (like, I believe, MOLA) that prefer to use LatLng with the Airy ellipsoid. I have a problem with that since it is confusing (there is no *simple

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

/256481988_Development_of_the_Finnish_Height_Conversion_Surface_FIN2005N00#read -Jukka Rahkonen- Lähettäjä: gdal-dev Puolesta Diogo Lähetetty: maanantai 17. lokakuuta 2022 11.59 Vastaanottaja: gdal-dev@lists.osgeo.org Aihe: Re: [gdal-dev] Transformations with same horizontal datum but different geoid outputs the same Z

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] Transformations with same horizontal datum but different geoid outputs the same Z value

On Fri, 14 Oct 2022, Diogo wrote: Hello everyone! I'm merging multiple elevation datasets from different countries and I would like to re-project all into the same coordinates system, 4326+3855 using gdalwarp. I'm using `gdaltransform` to confirm that there is in fact a conversion from the orig

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

Hello everyone! I'm merging multiple elevation datasets from different countries and I would like to re-project all into the same coordinates system, 4326+3855 using gdalwarp. I'm using `gdaltransform` to confirm that there is in fact a conversion from the original projection to the aspected one.