Hi Chris, *many* thanks for the response - most useful! See below... On Tue, 23 Jun 2026 at 00:15, Chris Andrew <[email protected]> wrote:
> --- > > Graeme's question first: what's the actual difference between ODN and > EGM96 across Great Britain? > > The EGM96 geoid sits roughly 43m to 57m above ODN across mainland GB > (broadly increasing from south to north), so the two are not > interchangeable in the ele tag without conversion. For a trig pillar on a > lowland site in southern England the difference might be around +44m; for > something in the Scottish Highlands it could be +56m or more. It's large > enough to matter. > > Thanks for that info Chris. 'AI' (not that I asked it...) was telling me anywhere between 15m and 50m difference - I wanted (and will do) the calcs to at least check the differences before pursuing the topic further.. > --- > > On Graham's PROJ/GDAL question: > > You'll need two OS-supplied grid files alongside the standard EGM96 grid: > > - OSTN15_NTv2_OSGBtoETRS.gsb (horizontal shift, OSGB36 to ETRS89) > - OSGM15_GB.gtx (vertical, ODN to ETRS89 ellipsoidal height) > - egm96_15.gtx (vertical, EGM96 geoid undulation) > > The first two are available from the OS/CDVP download page: > > https://www.google.com/url?q=https://www.ordnancesurvey.co.uk/business-government/tools-support/os-net/for-developers&source=gmail&ust=1782256072499000&sa=E > > egm96_15.gtx is included in the PROJ datum grid package (proj-data), or > available separately from: > > https://www.google.com/url?q=https://cdn.proj.org/&source=gmail&ust=1782256072499000&sa=E > > Once you have those in place, the PROJ pipeline from EPSG:7405 (OSGB36 + > ODN) to WGS84 + EGM96 is: > > echo "<easting> <northing> <ODN_height>" | \ > cs2cs EPSG:7405 \ > +proj=pipeline \ > +step +inv +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 \ > +x_0=400000 +y_0=-100000 +ellps=airy \ > +step +hgridshift +grids=OSTN15_NTv2_OSGBtoETRS.gsb \ > +step +vgridshift +grids=OSGM15_GB.gtx +multiplier=1 \ > +step +inv +vgridshift +grids=egm96_15.gtx +multiplier=1 \ > +step +proj=longlat +datum=WGS84 > > Oh, that's great, thanks! I don't think I would have ever worked that out on my own! Now knowing to go via ETRS89, I'll see if I can coax sf to do that with its normal API, and if not I believe it allows me to code up pipelines and hand them to it, so should be all good... On Q1 (what goes in ele): > > I think your instinct is right. In practice, the vast majority of existing > OSM nodes for peaks and trig points in the UK are tagged with ODN values, > because that is what OS data and the trig point community have always > published. The wiki's EGM96 guidance reflects a global standard that does > not match UK practice. > > This import seems like a good opportunity to be explicit about which datum > is in use. One approach would be to use ele:local for the ODN value and ele > for the EGM96-converted value where you can derive it. If the conversion > proves impractical at scale, tagging ODN into ele with a clear data source > note is arguably better than leaving the field empty or converting > imprecisely. > > It might also be worth proposing a ref:datum tag (e.g. ref:datum=ODN) to > make the vertical datum machine-readable, though I am not aware of that > being established OSM practice -- it could be worth raising on the wiki or > the tagging list if others think it useful. > Right. I don't think we can ever leave 'ele' empty. I'll carry on with the code to get all potentially useful data and add 'ele:local' to the plans and docs whilst we see where the dust settles. --- > > On Q2 (three decimal place precision): > > I would say go ahead and retain the precision. Trig pillars are geodetic > control points -- their heights are known to millimetre accuracy by design. > Three decimal places in ele:local is appropriate and informative, and is > quite different from estimating a mountain summit to the nearest metre. The > integer-only convention in existing OSM data reflects the imprecision of > those source data, not a deliberate policy. > > ack. Pretty much my thoughts were 'why would you throw info away', and indeed, its a trigpoint - its whole point in life is to try and be accurate... --- > > Hope that helps move things forward -- the slippy map preview looks great. > thanks! Probably the first HTML and JS I've ever written (really not in my ballpark...). I'm finding the map very useful to view the state of data and assess the outcomes. Last night whilst staring I noticed a FB duplication error - simple missing checks in the code... will be working on that now. And thanks for the github items (which I half missed, along with this email, due to a combo of spam filters and githubs default notifications... all good now)... I'll respond to those back on github. Graham
_______________________________________________ Talk-GB mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-gb
