Good morning!, Ah, *many thanks* Adrian for working out why my sf/proj is giving wonky results. I do have the tif files (via a combination of the OS site and off the proj servers - it was non-trivial to find some of them...). I have tried getting them into the proj path, but I'm in a docker container so it takes a tiny bit more fiddling - I'll have another go at doing that better today. What is frustrating is that sf/proj didn't fault out and complain... so, I'll go through the whole height translation process with a finer toothed comb. thanks. I did try the direct one-step conversion in my code, but that seemed to silently drop the Z conversion, which Chris says is a known sf issue :-( I'll get the tif files in place and compare the one-step and two-step and do some cs2cs outside the docker container. I'll probably keep the 2-step in though as processing time/resource is not really an issue and it leaves around the intermediate data as a handy source/reference.
Ah, yes, if I can show to myself that ETRS89 is close to WGS84, and we understand that it was a match at a certain epoch, then I'll probably be happy sticking ETRS89 co-ords into the OSC outputs. On a side note, notionally in the Trigpoint data we do have the dates the measurements were taken (although its not exactly clearly documented), so in theory maybe we can do an epoch drift calculation... but, overall I think we probably don't need to and things are simpler without it. Graham On Fri, 26 Jun 2026 at 09:38, Adrian via Talk-GB <[email protected]> wrote: > Re the ele tags, I didn't mean to suggest that there was a community > recommendation to use the four tags I listed. I have not discussed this > with anyone else, nor have I had any feedback. It is simply my idea of the > best way to deal with an awkward situation, and a way which is unlikely to > give rise to objections. > > Yes, I think it is likely that most of the ele values in the UK are on > Ordnance Datum. But as the difference between ODN and EGM96 is less than a > metre (it is, indeed, I'll come back to that), it's not obvious which datum > is being used. Especially if ele is in whole metres. Peaks such as Ben > Nevis are an interesting case because the height associated with the > triangulation pillar probably isn't the height of the summit. This is for > two reasons. First, the pillar may not be quite at the summit. Second, the > height given, is for the flush bracket set into the side of the pillar. > This is usually about 30cm above ground level. > > In France they did an import of both trigpoints and benchmarks. Their ele > tags are on the local datum, IGN69. IGN is the Institut Géographique > National, the French counterpart to the Ordnance Survey. Their ele tags > have decimals. I don't think the imported survey points were intended to be > rendered on maps. I think they did the import because it gave a convenient > way to access the data. > > Now let me walk through the height calculation for Box Hill. The height is > 171.968m above Ordnance Datum. Grid InQuestII says the height above the > ellipsoid is 217.439m. So we can deduce that Ordnance Datum is 45.471m > above the ellipsoid at this location (217.439 - 171.968). The EGM96 geoid > is 45.809m above the ellipsoid. So Box Hill flush bracket is 171.630m above > the geoid (217.439 - 45.809). And the difference between ODN and EGM96 at > this location is 0.338m (45.809 - 45.471, also 171.968 - 171.630). In > France, the difference between the local datum and EGM96 is also less than > a metre. > > After a great deal of trial and error, I believe I have discovered why > your code is not giving the expected results. I believe there is nothing > wrong with the code. But I believe two of the data files referred to by > Chris, are missing. Firstly OSTN15_NTv2_OSGBtoETRS.gsb which you can get > from the NTv2 item on the page > https://www.ordnancesurvey.co.uk/geodesy-positioning/coordinate-transformations/resources > . Second, I could not find OSGM15_GB.gtx but https://cdn.proj.org/ had > uk_os_OSGM15_GB.tif and that worked for me. The files need to go in the > folder where proj looks for data files, probably /usr/local/share/proj/, > otherwise, almost certainly a path ending .../share/proj/. > > I have discovered that you can omit the intermediate step in the > coordinate conversion: > Mac:~ ar$ cs2cs -f "%.7f" EPSG:7405 EPSG:9707 <<EOF > > 517971.06 151163.16 171.968 > > EOF > 51.2474475 -0.3111227 171.6279101 > Mac:~ ar$ > You will have cs2cs because it is part of proj. > > There is general acceptance among the UK community that we are using > ETRS89 coordinates as the least-worst option (when it's supposed to be > WGS84). We can sort-of justify it by noting that ETRS89 is equivalent to > WGS84 epoch 1989.0. The "rules" don't specify an epoch. Indeed, attempting > to specify an epoch would open an enormous can of worms, and few people > want to go there. I don't think you need to change your workflow. The > "right" numbers should just come through into your OSC files. There is > nothing to stop you slipping ETRS data into the OSC files, given that the > UK community accepts it. I note that France is also on ETRS89, for similar > reasons to the UK. They are aligning their data, to data coming from the > IGN. The USA has a more difficult problem because their local datum is not > equivalent to WGS84 at any epoch. > > _______________________________________________ > 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
