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
