-
Notifications
You must be signed in to change notification settings - Fork 32
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add uk_os_OSGM15_GB.tif geoid file for ODN height, UK #25
Conversation
You could solve most of them by running the grid_tools/vertoffset_grid_to_gtiff.py script of this repo as a post-processing step on your warped TIFF file. For the first point regarding PixelIsPoint, adding -mo AREA_OR_POINT=Point to gdalwarp should fix it
|
Thank you! I'll try to follow your remarks. |
@rouault, I have some questions to you and hope you will not mind helping me
So, I have added all necessary metadata and tried to change pixel size by setting
and then
I have no enough experience and knowledge to estimate if new transformation is more correct, so, I'm very appreciate your help! Pleas, take a look at the new results of tests:
If it's acceptable I will update PR and copyright_and_licenses.csv file. Thank you! |
the length in metres of one degree of longitude at the equator of the GRS80 ellipsoid = pi * 6378137 / 180
Should rather be res_long=res_lat*math.cos(min_latitude_of_grid_expressed_in_radian)
you could possibly compute the mean square root error on a few sample points and compare |
7251c35
to
c17674c
Compare
Hi, again!
RMSE for the very first geoid were: So, i choose variant with middle latitude. New
Also I added comment with adding metadata to the script. |
For RMSE calculation I used test
|
What's the size (in pixels) and resolution of the input grid ? |
Pixel size in meters: 1000x1000
There are used
Moreover, Absolute errors:
|
ah, not for me. It reports EPSG:4937. There's a related fix in GDAL 3.1: OSGeo/gdal@3090465
OK, so we have a consistent number of samples in the resampled product with 1266. But I obviously got the maths wrong for the longitude resolution: it should be res_lat / cos(lat) . We should aim to go closer to the original number of samples in the longitude direction: I'd say greater than 700 but not significantly larger than 1000 or so. |
Source data is `OSTN15_OSGM15_DataFile.txt` file obtained from OrdnanceSurvey developer pack (see README)
a33299b
to
c496d7e
Compare
Recalculated:
Now I understand the logic! Check it out
I changed |
Looking at EPSG:7711 metadata (ETRS89 to ODN height (2)), it mentions an accuracy of 8 mm. So here our RMSE is one order of magnitude below it (7.6e-4 m), and our max error is 2mm. @kbevers any opinion if given the above using a grid referenced to geographic coordinates compared to the original one referenced to projected coordinates is a reasonable compromise ? |
@and-marsh Could you add a note in the README about the slight added error due to the reprojection (with mensions of the RMSE and max error) ? with that, I guess we should be good to go |
c496d7e
to
1df555f
Compare
1df555f
to
77fa91c
Compare
@rouault I have added some notes to the README. Can I ask you regenerate index file, since for now I don't have GDAL with Python bindings? Thanks a lot! |
Database: register geoid file for UK added in OSGeo/PROJ-data#25
Index regenerated |
Referring to the “Transformations_and_OSGM15_UserGuide.pdf“ contained in the developers pack, page 10, Table and note 6. I believe the developer pack provides “Geoid height”. Note 6 further explains that: ETRS height - OSGM15 Geoid height = orthometric height above mean sea level. So to obtain the vertical shift from ETRS89 (GRS80) to orthometric, the Geoid height must be multiplied by minus 1. The grid currently has positive instead of negative shifts. |
yes, that's correct. Geoid models as used in PROJ (and in most other formats) must be the value of the geoid undulation, that is the ellipsoidal height for a orthometric altitude of 0.
|
Oh, it’s a OSGM15 Geoid height model relative to ETRS89/GRS80 ellipsoid, not a vertical shift from ETRS89/GRS80 to OSGB36/ODN. Thanks for helping the penny drop. Not all vertical shifts are Geoid models, so would be helpful to know this one is. |
Hi,
I decided to add lacked geoid file for
EPSG(5701)ODN height
, UKI have read OSGeo/PROJ#1315 and OSGeo/PROJ#2173 issues and tried to build
uk_os_OSGM15_GB.tif
geoid file from source fileOSTN15_OSGM15_DataFile.txt
obtained from Ordnance Survey developer pack.I attached shell script to generate output file. There I used custom projected CRS
ETRS89 / British National Grid
since the points of the source grid are configured in this system in accordane to theOSGM15_Notice_of_release_for_developers.pdf
attached to the developer packSo, I also conducted tests on data obtained from the developer pack for transformation
EPSG:4258
->EPSG:27700+5701
:Results of tests - difference of coordinates of points obtained after transformation and provided by the developer pack, all values in meters:
Height of some points weren't transformed since these points are outside
ODN height
area of use - UK - Great Britain mainland onshore. Accuracy of height transformation is up to 1.5 mm.Related PR: OSGeo/PROJ#2250