Opened 14 years ago

Closed 5 years ago

#3172 closed defect (wontfix)

Northing/easting shift information at BSB charts

Reported by: vadp Owned by: warmerdam
Priority: normal Milestone: closed_because_of_github_migration
Component: GDAL_Raster Version: unspecified
Severity: normal Keywords: BSB datum


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:


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).

Attachments (1) (880 bytes ) - added by vadp 14 years ago. -- bash script to produce .vrt file with WGS84 datum

Download all attachments as: .zip

Change History (7)

by vadp, 14 years ago

Attachment: added -- bash script to produce .vrt file with WGS84 datum

comment:1 by vadp, 14 years ago

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

DTM/<latitude shift>,<longitude shift>

comment:2 by warmerdam, 14 years ago

Component: defaultGDAL_Raster
Owner: changed from Frank Warmerdam to warmerdam

comment:3 by vadp, 14 years ago

Just in case someone interested in, I've made a temporarily workaround over BSB problems:

comment:4 by warmerdam, 14 years ago

Status: newassigned

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

comment:5 by vadp, 14 years ago

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!

comment:6 by Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: assignedclosed

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 if it is not already reported there.

Note: See TracTickets for help on using tickets.