Opendata plugin uses approximate transformation on shapefile in BNG projection, even if the patch in #20160 has been applied

[Adrian]

The approximate transformation results in a misalignment of nearly 5m in my example. The attached .zip file contains eight files. The shapefile and MapInfo file are both in British National Grid projection EPSG:27700, and contain the same test point at the same coordinates. The osm file contains two reference points, one at the correct position for the test point, and one at the misaligned position.

What steps will reproduce the problem?

1. Build a version of JOSM patched as proposed in #20160.
2. Put a copy of OSTN15_NTv2_OSGBtoETRS.gsb (from #20160) in /usr/local/share/proj, or C:\PROJ\NAD\ under Windows. (This means that the file does not need to be available from the JOSM server.)
3. Open the attached Test point.mif (MapInfo format). This file has no projection defined. When the opendata plugin asks you to choose a projection, select British National Grid EPSG:27700.
4. Open the attached Test point.shp (shapefile).
5. Open the attached Test point.osm

Optionally

6. Set up the custom projection +proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.060,0.1502,0.2470,0.8421,-20.4894 +units=m +bounds=-9,49,2,61 +no_defs. This is the approximation being used by the opendata plugin.
7. Open the .mif file again, using the custom projection.

What is the expected result?

The test point is at the correct position in step 3 and in step 4 (and misaligned in step 7).

What happens instead?

The test point is at the misaligned position in step 4.

Please provide any additional information below. Attach a screenshot if possible.

Although I have reported this as a defect, it it really an RFE.
Being more specific, the approximation relates to the definition of the OSGB36 datum. The approximate definition is +ellps=airy +towgs84=.... The more accurate definition is +ellps=airy +nadgrids=OSTN15_....

Relative:URL: ^/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2020-11-21 14:56:29 +0100 (Sat, 21 Nov 2020)
Revision:17329
Build-Date:2020-11-22 02:30:52
URL:https://josm.openstreetmap.de/svn/trunk

Identification: JOSM/1.5 (17329 en_GB) Mac OS X 10.14.6
OS Build number: Mac OS X 10.14.6 (18G6020)
Memory Usage: 240 MB / 4096 MB (126 MB allocated, but free)
Java version: 15+36, AdoptOpenJDK, OpenJDK 64-Bit Server VM
Look and Feel: com.apple.laf.AquaLookAndFeel
Screen: Display 725375437 1920x1200 (scaling 1.0x1.0)
Maximum Screen Size: 1920x1200
Best cursor sizes: 16x16 -> 16x16, 32x32 -> 32x32

Plugins:
+ ImportImagePlugin (35567)
+ InfoMode (35543)
+ PicLayer (2a9aa7a)
+ apache-commons (35524)
+ cadastre-fr (35645)
+ editgpx (35562)
+ ejml (35458)
+ geotools (35458)
+ http2 (35427)
+ imagery_offset_db (35640)
+ jaxb (35543)
+ jts (35458)
+ log4j (35458)
+ measurement (35640)
+ opendata (35640)
+ photo_geotagging (35640)
+ poly (35640)
+ reverter (35640)
+ turnrestrictions (35640)
+ undelete (35640)
+ utilsplugin2 (35640)
+ waydownloader (35640)

[Adrian]

shapefile, MapInfo file and .osm file

[Adrian]

I have looked into this question a little further and I can see it would not be easy to resolve. I see two problems.

1. The shapefile reader uses geotools. Geotools does not handle grid shift files except for the NAD ones.

2. With a shapefile, the projection is defined in an accompanying .prj file. The .prj file contains a kind of 'well-known text'. You need code which will read the .prj file and either

• work out that it is equivalent to an EPSG projection number, or
• convert it to a proj4 string, or
• convert it to a sequence of mathematical operations.
  
  I believe this processing is currently done by geotools.