Modify

Opened 2 months ago

Last modified 9 days ago

#20160 new enhancement

[patch] [rfe] British National Grid projection EPSG:27700

Reported by: ar2988-os@… Owned by: team
Priority: normal Milestone: 21.01
Component: Core Version: latest
Keywords: template_report projection OSGB_1936 OSGB36 Cc:

Description

This proposal is in two parts. First, to add the British National Grid projection EPSG:27700 to the list of default projections. Second, to upgrade the definition of EPSG:27700 from the approximate version currently used by JOSM. The approximation produces misalignments of up to 5m depending on the location. The approximation is the one used by proj4 at the time when the projection handling was added to JOSM. The definition used by proj was upgraded in proj6. It implements the official definition held in the EPSG registry.

The upgrade actually applies to the OSGB36 datum, used by EPSG:27700. This change affects 105 projections which use the OSGB36 datum, numbers 4277, 7405, 27700 and 102799-102900. It involves a grid shift file OSTN15_NTv2_OSGBtoETRS.gsb. The file came from https://www.ordnancesurvey.co.uk/business-government/tools-support/os-net/for-developers The file is also available here https://download.osgeo.org/proj/proj-datumgrid-europe-1.2.zip

A patch is attached. You will see that it includes an ugly workaround. I have updated the projection test files and the updates are in the patch. I have only updated the 105 projections affected. I used proj-4.9.3 - with a modification to the OSGB36 datum equivalent to the modification in the patch - when updating the test files. I have run ProjectionRefTest and ProjectionRegressionTest and they passed on my machine.

[junitlauncher] Test run finished after 59302 ms
[junitlauncher] [         1 tests successful      ]

[junitlauncher] Test run finished after 59390 ms
[junitlauncher] [         1 tests successful      ]

If you accept this rfe, and if you wish to credit me, my name is Adrian.

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: 234 MB / 4096 MB (111 MB allocated, but free)
Java version: 15+36, AdoptOpenJDK, OpenJDK 64-Bit Server VM
Look and Feel: com.apple.laf.AquaLookAndFeel
Screen: Display 458669421 1920x1080 (scaling 1.0x1.0)
Maximum Screen Size: 1920x1080
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)

Attachments (2)

20160.patch (157.0 KB) - added by ar2988-os@… 2 months ago.
OSTN15_NTv2_OSGBtoETRS.gsb (14.5 MB) - added by ar2988-os@… 2 months ago.
Grid shift file

Change History (15)

Changed 2 months ago by ar2988-os@…

Attachment: 20160.patch added

Changed 2 months ago by ar2988-os@…

Attachment: OSTN15_NTv2_OSGBtoETRS.gsb added

Grid shift file

comment:1 Changed 2 months ago by stoecker

Why that change to NTV2Proj4DirGridShiftFileSource.java?

BTW: Actually I'm not happy that we stick to proj4 style files. Migration to the better proj6 concept would be fine. Question is how?

comment:2 in reply to:  1 Changed 2 months ago by ar2988-os@…

Replying to stoecker:

Why that change to NTV2Proj4DirGridShiftFileSource.java?

It allows JOSM to look for grid shift files in a local folder on MacOS, like it does in Windows and Linux/Unix. I installed proj from source on MacOS and by default it puts its grid shift files in /usr/local/share/proj

comment:3 in reply to:  1 ; Changed 2 months ago by simon04

Milestone: 20.12

BTW: Actually I'm not happy that we stick to proj4 style files. Migration to the better proj6 concept would be fine. Question is how?

#18733?

comment:4 in reply to:  3 ; Changed 2 months ago by stoecker

Replying to simon04:

BTW: Actually I'm not happy that we stick to proj4 style files. Migration to the better proj6 concept would be fine. Question is how?

#18733?

No. The grids are only one part.

The transformations itself in newer proj are handled totally different (and better). But sadly this means the transformation dataset isn't compatible. You don't find such an easy textual description for new proj.

comment:5 Changed 4 weeks ago by simon04

Milestone: 20.1221.01

comment:6 in reply to:  4 ; Changed 3 weeks ago by Don-vip

Replying to stoecker:

The transformations itself in newer proj are handled totally different (and better).

What's the difference? Do you have an example?

comment:7 Changed 3 weeks ago by Don-vip

Why so many changes in the projection data files? I expected to find only changes for the three listed projections.

comment:8 in reply to:  7 Changed 3 weeks ago by ar2988-os@…

Replying to Don-vip:

Why so many changes in the projection data files? I expected to find only changes for the three listed projections.

I am proposing a change to the OSGB36 datum. This datum is used by 105 projections and I have updated the corresponding tests.

comment:9 in reply to:  6 ; Changed 3 weeks ago by stoecker

Replying to Don-vip:

Replying to stoecker:

The transformations itself in newer proj are handled totally different (and better).

What's the difference? Do you have an example?

https://github.com/OSGeo/PROJ/releases/tag/5.0.0

comment:10 in reply to:  9 ; Changed 12 days ago by Don-vip

Replying to stoecker:

What's the difference? Do you have an example?

https://github.com/OSGeo/PROJ/releases/tag/5.0.0

OK so if I understand correctly, the algorithms have been improved and the previous text file is now a SQLite3 database file named proj.db.

Probably the simplest solution would be to make JOSM download the JDBC driver (7 Mb) and SQLite file (9 Mb) at runtime?

I don't know what the algorithms update mean for us.

comment:11 in reply to:  10 Changed 12 days ago by stoecker

Replying to Don-vip:

Replying to stoecker:

What's the difference? Do you have an example?

https://github.com/OSGeo/PROJ/releases/tag/5.0.0

OK so if I understand correctly, the algorithms have been improved and the previous text file is now a SQLite3 database file named proj.db.

Probably the simplest solution would be to make JOSM download the JDBC driver (7 Mb) and SQLite file (9 Mb) at runtime?

I don't know what the algorithms update mean for us.

I have no idea. But maybe the existence of the sqlite file means that it's easier than I thought :-)

comment:12 Changed 10 days ago by Don-vip

One other option would be simply to write a conversion tool that converts the sqlite file to proj.4 format?

comment:13 in reply to:  12 Changed 9 days ago by stoecker

Replying to Don-vip:

One other option would be simply to write a conversion tool that converts the sqlite file to proj.4 format?

If possible I'd think that's the easiest solution.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set.
to The owner will be changed from team to the specified user.
The owner will change to ar2988-os@yahoo.co.uk
as duplicate The resolution will be set to duplicate.The specified ticket will be cross-referenced with this ticket
The owner will be changed from team to anonymous.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.