Hi Adrian, many thanks for the extensive and worked example answers... more below...
On Thu, 25 Jun 2026 at 13:10, Adrian via Talk-GB <[email protected]> wrote: > I am replying to some of the questions asked by Graham Whaley. For less > expert readers, I have tried to explain some of the technical terms, at the > end of this message. > 'less expert' - oh, how I laughed... believe me, expert at this I am definitely not... > There are a couple of slips in what Chris Andrew wrote. The difference > between ODN and EGM96 is less than a metre. And (in the UK) EGM96 is above > the ellipsoid. > > For ele tags, I would specify four: > ele > ele:EGM96 > ele:ODN > ele:WGS84 > The ele tag would contain the EGM96 value. This is my way of complying > with the recommendation that the the ele tag should be referred to EGM96, > while making it crystal clear what is going on. I am assuming that > man_made=survey_point would not generally be rendered in maps, so that the > presence of decimals in ele values would not be a problem. If someone > produced a specialist map showing survey points, they could choose how to > deal with the decimals, e.g. they could round the values if the decimals > are cluttering the map. > > This is an example of my tagging of a peak: > https://www.openstreetmap.org/node/518577471 Tags - storing the different EGM96/ODN/WGS85 in separate tags, sure thing. That's easy. I'm still not totally sold on EGM96 in plain 'ele'. As you say, afaict nobody yet renders the survey_points (which I find odd for trigpoints, coming from a more hiking than highway background ;-) ). If I look at the OSM survey_point data I have I see 1338 nodes with 'ele' set. ~15 of them are in feet!, but the rest I'm pretty sure are all going to be ODN. I've tried to search the survey_point data I have, and I see four references to ODN, all of them for non-pillar benchmark cutmarks. No mentions of EGM96. And in the UK, would all the peaks currently be in ODN? Let's take for instance Ben Nevis - it is rendered on OSM and shows 1345m - which is its 'official' height I think... I think it would be darned confusing to show it as anything else, and it only has plain 'ele' associated with it right now (no ele:local for instance). But hey, if community consensus is that we are going to put EGM96 into trigpoint 'ele' (and make that clear by having the other 'ele:*' tags present), then that's what I'll do... I don't have a major problem with it as long as there is consensus or at least a decision, and nobody shoots the messenger :-). But I think this will still need broader discussion somehow. (oh, and I note the peak you pointed to is in France ... where I know they did their own large trigpoint import but google failed to translate their page for me and I don't know what reference they used for their ele tags - but if I pick a random node from the import, it only has a single 'ele' tag:) https://www.openstreetmap.org/node/670163029 > > The ele:ODN value could be as given by the Ordnance Survey, with however > many decimals there were. I prefer ele:ODN to ele:local because it is > clearer what the reference is. I would retain all the decimal places in the > calculations, but then round the other ele values to the nearest centimetre > (2 decimal places) because the third decimal place (millimetres) would not > be meaningful. I say this, because of this quote "The National Geoid Model > OSGM15 is a grid of geoid-ellipsoid separation values... The nominal > accuracy of the geoid model is 8 mm rms (root mean square) in mainland > UK..." which comes from here > https://docs.os.uk/more-than-maps/a-guide-to-coordinate-systems-in-great-britain/from-one-coordinate-system-to-another-geodetic-transformations/national-geoid-model-osgm15-etrs89-orthometric-height > (very long URL). > sure, 2 decimal places doesn't sound unreasonable for converted ele values - but for ODN I'll probably stick to the values as provided in the trigpoint database. > Now, the conversion to latitude, longitude and EGM96 height. As examples, > I have chosen two triangulation pillars more or less at random, one, well > to the south and one, well to the north. > Box Hill trig point https://www.openstreetmap.org/node/4267733568 > Strathy Point trig point https://www.openstreetmap.org/node/612893275 > British National Grid (BNG) eastings and northings from OS: > Box Hill 517971.06 151163.16 > Strathy Point 282007.756 968512.562 > Box Hill height is 171.968 in trig archive and 171.9682 in benchmark > archive. > Strathy Point height is 90.293 in trig archive and 90.294 in benchmark > archive. > Right - nice, I've extracted those two and will run them through my R conversion code... > > I did a manual conversion giving these results (these really need to be > displayed with a monospaced font as in the mailing list web pages): > Ht of EGM96 Ht above Offset from > ODN HAE geoid EGM96 geoid Latitude Longitude OSM object > Box Hill 171.968 217.439 45.809 171.630 51.2474475 -0.3111227 0.82m > Strathy Point 90.293 143.410 53.686 89.724 58.5885068 -4.0314345 13.00m > You can see that the difference between ele:ODN and ele:EGM96 is 30-60cm. > The height of the geoid is within the range given by Chris Andrew. You can > use these results to check your calculations. You will sometimes see a > difference of 1 in the 7th decimal place of latitude and longitude. I > suggest you replicate my manual conversions (to give confidence in the > process) and then do a couple more trig points in the same way, to give a > more comprehensive check on your calculations. How I did it... > (err, did you mean 30-60metres there, not cm?) I tried rendering that table in a txt file, but I'm not sure I got it right. I do have a query though... just this morning I got some R/sf(GDAL/PROJ) code running to do the 3D height conversions. Now, here is where I a bit confused - if the EGM96 geoid is *above*, so the 'base 0 level' is moved 'up', then the heights of our peaks... will 'look lower' and come down, no? So, if we take Box Hill with 171.968/ODN, and a 45.8m difference between ODN and EGM96 - my EGM96 data currently comes out as 126.155 (171.968 - 45.813), and not 217.439 (171.968 + 45.525)? I'm very happy to be told it is my misunderstanding and my code is not working - just want to check, as right now I'm confused... > I downloaded the Ordnance Survey Grid InQuestII application from > https://www.ordnancesurvey.co.uk/geodesy-positioning/coordinate-transformations/grid-inquest2-software > . You need to set suitable numbers of decimal places for the input and > output boxes, in the options. Then I did a conversion from OSGB36/BNG to > ETRS89 geodetic. This gave me the latitude, the longitude and the height > above the ellipsoid (HAE, the ele:WGS84 value). Then I obtained the height > of the EGM96 geoid (above the ellipsoid) from > https://geographiclib.sourceforge.io/cgi-bin/GeoidEval . Then the height > relative to the EGM96 geoid is a simple subtraction. Then the last stage is > optional... In JOSM, I created a node at the position of the trig point. I > drew a way from there to the OSM object. With the way selected, the status > bar gives its length, i.e. the offset. (If you only see one decimal place, > you need to change statusbar.decimal-format to 0.00 in the expert > preferences and restart.) > > Right, I have inquestII here. Thanks for the geoid link. My code is in R, using the 'sf' library that sits atop GDAL and PROJ. I'm doing a 3 step conversion from: EPSG:7405 : OSGB36 + ODN ->EPSG:4937 : ETRS89 -> EPSG:9707 : WGS84 + EGM96 height Here is the (trimmed) output for my Box Hill result for reference: > osz_sf_7405[2,]$geometry Projected CRS: OSGB36 / British National Grid + ODN height POINT Z (517971.06 151163.16 171.968) > osz_sf_4937[2,]$geometry Geodetic CRS: ETRS89 POINT Z (-0.3111317188 51.24743604 171.968) > osz_sf_9707[2,]$geometry Geodetic CRS: WGS 84 + EGM96 height POINT Z (-0.3111317188 51.24743604 126.1553988) You can see that I have guided you to ETRS89 coordinates. This is because, > in Great Britain, we are recommending that users align aerial imagery to > the OSMUK Cadastral Parcels before tracing features. The Cadastral Parcels > are based on Ordnance Survey data which is aligned to ETRS89. ETRS89 can be > regarded as WGS84 epoch 1989.0, in other words, the WGS84 coordinates as > they were at the beginning of 1989. WGS84 coordinates in Europe move at > 25mm per year relative to the land because of the motion of the Eurasian > tectonic plate. So the difference between epochs 1989.0 and 2026.0 is a > little over 90cm. In contrast, the Cadastral Parcels do not move relative > to the land. They remain at the property boundaries. They track the > tectonic plate - ETRS89 is a plate-fixed datum. > ack - I've come to have a much better understanding of world-referenced and plate-referenced data in this last week :-) But - can I use ETRS89 co-ordinates in OSC XML change files? That is how I currently generate the 'new nodes' dataset, and I'm sure not going to be doing all 4400 by hand in JOSM ;-) I thought core OSM was WGS84, and that is what goes in the OSC files? I'm happy to change the output format if there is a better way to generate a plate-relative co-ordinate and have that injected into OSM... Many thanks for the input Adrian - it helps, and at least it feels I'm on the right path. Graham > > Finally, an explanation of some technical terms. > > The geoid is the shape of the earth - of a level surface at sea level. It > is uneven because of variations in density from place to place within the > earth. It is usually expressed in terms of the height relative to the > ellipsoid. > > "The ellipsoid" is the GRS80 ellipsoid, used by WGS84 and ETRS89. An > ellipsoid is a geometrical figure, a "squashed sphere". Because it is a > geometrical figure, we can work with it, using equations. The ellipsoid > provides a rough approximation to the shape of the earth. A GNSS receiver > measures the height above the ellipsoid - HAE is the raw data. GNSS stands > for Global Navigation Satellite System. Many GNSS receivers contain a geoid > model so that they can do an approximate conversion to height above sea > level. > > A geoid model - such as EGM96 - provides a much closer approximation to > the shape of the earth. It is essentially a set of numbers which describe > the details of the shape. EGM stands for Earth Gravitational Model. > > ODN is the Ordnance Datum Newlyn. It is the Ordnance Survey's geoid model, > covering Great Britain. It is the zero altitude reference level ("sea > level") for all heights given by the Ordnance Survey. > > _______________________________________________ > Talk-GB mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-gb >
_______________________________________________ Talk-GB mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-gb
