Northing/easting shift information at BSB charts

[vadp]

Some commercially available BSB charts have local, non-WGS84, datum assigned to. Hence registration reference points (REF<n>/) at their headers are assigned to that datum. Processing these charts with the current GDAL tools results in chart features shifted north-south and/or east-west against their real position.

It appears that such charts have northing/easting information encoded at their headers to bring their coordinates to WGS84 datum. It's encoded by a line like this:

DTM/<northing>,<easting>

where <northing> and <easting> are longitude and latitude shifts in *seconds* (floating point numbers) to bring that local datum to WGS84.

In essence, these shifts are to be added to REFs coordinates to produce a correct data. This idea was proved by a bash script I wrote for the purpose to create a VRT file with correct coordinates referencing to an original KAP file wich contains BSB data (see attachment).

[vadp]

bsb2vrt.sh -- bash script to produce .vrt file with WGS84 datum

[vadp]

A correction: an example above looks confusing. DTM string semantics is like this:

DTM/<latitude shift>,<longitude shift>

[vadp]

Just in case someone interested in, I've made a temporarily workaround over BSB problems: ​http://forums.internettablettalk.com/showthread.php?t=35789

[warmerdam]

I would be interested in incorporating the offset to WGS84 directly in the GCP processing code in the driver.

[vadp]

Perhaps it would be better to keep original KAP's coordinates and georeferences unaltered as much as possible.

One option might be based on false_easting (x_0) and false_northing (y_0) parameters, but they are more about projection rather than datum. More over, these parameters are used by some projections, Transverse Mercator specifically.

Another option is towgs84 convertion. The parameters #s 4,5,6 there are rotation angles in seconds. One guess produces a rather good looking result (errors are around a few 1/100s of a second):

alpha = - lat_shift*sin(long+long_shift)
beta = lat_shift*cos(long+long_shift)
gamma = long_shift

where lat_shift and long_shift are latitude and longitude shifts from the DTM record, long is a longitude at the middle of the map.

Quick and dirty, but does it makes any sense?

Happy New Year to everyone!

[Even Rouault]

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to ​https://github.com/OSGeo/gdal/issues if it is not already reported there.