I have submitted a ticket to the JOSM developers. The ticket contains a fully worked-out patch to upgrade the EPSG:27700 projection from the Helmert transformation to the look-up table transformation.
I'm afraid this is another somewhat long and technical message. But it does contain an explanation of why the Land Registry wms is actually sort-of correct. With my modified version of JOSM, .mif files are now transformed using the look-up table. This is with the hack I described before, where no projection is defined in the file, and you choose EPSG:27700 when the opendata plugin asks you. But .shp files which declare British National Grid are still transformed with the Helmert transformation. This must be down to the opendata plugin, because JOSM itself, as modified, does not know about the Helmert transformation any more. (I have put in a ticket for that, too, but without a patch.) I now understand better, the information in the EPSG registry. If you go to the page for projection 27700, and open the panel for the OSGB36 datum, it is not entirely clear, as I described before. But if you look at the page for the OSGB36 datum (transformation 7953), it spells out that this transformation uses the OSTN15 look-up table. However, transformation 7953 isn't referenced anywhere in the page for projection 27700. The more I look at this projection stuff, the worse it gets. The Land Registry only covers England and Wales. The Scottish counterpart is Registers of Scotland. I've also had a look at their opendata. The URL is a bit hard to find so I give it here https://ros.locationcentre.co.uk/inspire/ They too have a wms, which is here http://ros.datafeed.locationcentre.co.uk/geoserver/wms They offer .shp files in British National Grid and ETRS. I've already mentioned the issues raised by .shp files. Rob was hoping to compare the BNG and ETRS files, but that's not possible because Registers of Scotland have made a mistake in preparing the ETRS files. The BNG and ETRS files are identical. In other words, the ETRS file contains BNG coordinates in metres. I am a bit surprised that I might be the first to spot this and report it. (With shapefiles, the projection is defined in an accompanying .prj file. The .prj file uses a version of 'well-known text' which does not contain EPSG numbers. This will be part of the explanation for the issue with the opendata plugin. If the .prj file is missing, the only option with the opendata plugin is EPSG:4326 (WGS84), so removing the .prj file does not provide a workaround.) The Registers of Scotland wms is misaligned, just like the Land Registry one. Rob's examples align with the two wms. *But* I always launch JOSM from the command line. And I spotted an info message on the command line saying 'reprojecting from EPSG:27700'. So, a further discovery. Some background - We are familiar with online maps from various sources. Most of them use tms protocol with Web Mercator projection (EPSG:3857). Wms is different. The server offers the client a list of projections which it can deliver, and the client chooses which one to have. Suppose JOSM is set to EPSG:3857. The Land Registry wms does not offer EPSG:3857 so JOSM chooses the first projection which it understands, from the server's list - EPSG:27700. Then JOSM reprojects it, so the wms is misaligned because *JOSM* is using Helmert. And the Land Registry was right all along! The Registers of Scotland wms does offer EPSG:3857, so that is what JOSM chooses. And the wms is misaligned because the *wms server* is using Helmert. The wms also offers EPSG:27700. So if you set JOSM to EPSG:27700; and delete and re-add the wms layer so it is redownloaded in EPSG:27700; then the wms is misaligned because *JOSM* is using Helmert. [I mean delete the layer, not delete the entry in the imagery list.] With my modified version of JOSM, both wms are correctly aligned (provided, in the case of Registers of Scotland, that you set JOSM to EPSG:27700 before adding the wms layer). The alignment of Rob's examples does not change with my modified version of JOSM, so Rob's examples no longer align with the two wms. I should add that the other projections offered by the two wms servers, in as far as I have been able to test them, are all misaligned. In other words, both servers are using Helmert. I tested with JOSM and QGIS. I've had another look at proj6 and proj7 and they do in fact use the look-up table for EPSG:27700. One piece I found online suggests they fall back to the Helmert transformation if the look-up table file is not available. This explains how come QGIS is using the look-up table transformation for EPSG:27700. I've looked further into the issue of simplification of polygons (dropping of nodes). GDAL and ogr2ogr behave the same as QGIS. ogr2ogr has a simplify option but that only increases the amount of simplification: it won't reduce it below the preset minimum. QGIS uses GDAL, so it looks like the simplification is hard-wired into the output side of GDAL. The opendata plugin simplifies shapefiles in a similar way when they are opened in JOSM. _______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
