Bad GCPs returned from this BSB

[gaopeng]

I have a BSB dataset containing 100+ GCPs. The GCPs generate a very poor fit to a 2nd order polynomial (also fail to generate a valid geotransform in GDALGCPsToGeoTransform). As the result, computed extent in GCS based the GCPs is out of place. The same dataset looks fine in a BSB viewer from maptech.

I placed the test dataset, 530_1.kap at ​ftp://GDAL@ftp.esri.com. Could you take a look? Maybe the GCPs are read wrong or there is another source of georeferencing info in the file.

[warmerdam]

I believe the best approach is actually improving the BSB driver to properly decode the projected coordinate system (often Mercator) and setup the projection and geotransform properly based on that rather than depending on the long/lat control points.

I'll take a whack at this.

[warmerdam]

I have observed that the primary problem with this file is that the GCPs span the international dateline, and that the ones west of the dateline are positive (~179). The mechanisms in GDAL for doing GCP based regressions do not model the wraparound nature of the geographic coordinate systems and this gets treated as a discontinuity and the transform attempts to drag part of the map across the rest.

One potential solution is a heuristic to use values < -180 for GCPs to the west of the dateline. But this might be hard to do properly for large maps (as this one is).

So instead, I will continue to look into deriving the proper mercator coordinate system.

[warmerdam]

I have modified the bsb driver to heuristically group GCPs in either the -180 to 180 or 0 to 360 range depending on which approach minimizes the longitude range.

I have also added logic to reproject the GCPs if PR=Mercator.

There are still issues with the geotransform from gcp computation being too rigerous (requiring 0.25 pixels or less error) with the relatively sloppy BSB gcps.

Changes are in trunk (r16202) and 1.6 branch (r16203).

[gaopeng]

I have tested the fix with my test dataset. The first part of the fix, grouping GCPs, works. The returned GCPs generate a good 2nd order polynomial.

The second part of fix, reprojecting GCPs into PR=Mercator, doesn't work for my setup since I don't have PROJ.4 library installed. One solution can be that GDAL returns the target projection, e.g. as metadata, if it can't project the GCPs. Application can get the GCPs, project them, and then fit its own polynomial.

[warmerdam]

Gao,

I have added logic to publish the KNP/ line from the header as the BSB_KNP metadata item on the dataset. It looks like the following. The "PR=Mercator" is the clue that the GCPs ought to be converted to Mercator. For this particular dataset and other dataline spanning datsets it is important to construct a mercator coordinate system with a central meridian in the vicinity of the dataset.

BSB_KNP=SC=4860700,GD=NAD83,PR=MERCATOR,PP=50.000,PI=300.000,SP=,SK=0.0000000,TA=90.0000000,UN=FATHOMS,SD=MEAN LOWER LOW WATER,DX=486.07,DY=486.07

The change is in trunk (r16207) and 1.6 branch (r16208). I'll look into back porting to the 1.4-esri branch one #2817 is investigated.

[gaopeng]

Frank,

How about a change like the following. The metadata item is set if and only if GCPs can't be reprojected to its underlying SRS. This can also be used to handle other formats, and allows format specific logic to generate the OGR WKT, e.g. MECATOR with the correct central meridian. I tested with this approach. It seems to flow well, except the generated WKT (projection name Mercator_SP2) is not yet supported by PE.

if( poCT != NULL ) {

...

} else

SetMetadataItem( "GCPPROJECTIONX", osUnderlyingSRS, "IMAGE_STRUCTURE" );

[gaopeng]

BSB with underlying projection Lambert conformal conic

[gaopeng]

I found a sample BSB with Lambert conformal conic projection.

[warmerdam]

I have backported the current state of the bsb driver into 1.4-esri branch. LCC work still outstanding.

[gaopeng]

I have tested and confirmed that the fix works in gdal 1.4-esri.

[gaopeng]

I found another case where PR=MERCATOR, but Datum is NAD83, more importantly the unit is in FEET instead of METER. This causes the image being displayed in wrong location.

KNP/SC=20000,GD=NAD83,PR=MERCATOR,PP=28.617,PI=2.000

SP=Texas South Central,4000,SK=0.0000000,TA=90.0000000,UN=FEET SD=MEAN LOWER LOW WATER,DX=2.00,DY=2.00

[gaopeng]

UN=FEET

[warmerdam]

Gao,

I inspected this file and the grid square corners matched up within a pixel or two to what they should be. So I'm not aware of any registration problems with the file.

It is true that the coordinate system and coordinates are presented in Mercator meters rather than feet, but as it is done consistently this should not cause misregistration.

Also, for cartographic purposes NAD83 and WGS84 are essentially the same. But I look into handling the datum more appropriately.

I do notice the map also has coordinates available on it in "texas state grid" coordinates. Were you hoping the image would end up with a geotransform in texas state grid coordinates? This *might* be possible if I incorporate the information in the KNQ line, but I'm by no means confident. Should I look into this?

[gaopeng]

Frank,

I uploaded another image which contains Lat/Long ruler in the image itself. User's complaint is that the coordinate measured from display does not match what the ruler says in the image.

You are right. The UNIT=FEET may not be the cause of that (I thought I found the problem). Could you look at the attached image and see what's the problem?

[gaopeng]

snapshot showing locational shift

[gaopeng]

Frank,

I uploaded a screen shot showing the locational shift problem with 83157_2.kap. The green dot in the display is positioned exactly at Long 162. At the lower right corner, the measured location is 162 degree and 7 seconds. The user indicated that the same dataset displayed correctly in another BSB viewer.

[warmerdam]

I am seeing a similar offset with 83157_2.kap using PROJ.4/OpenEV -- I will investigate further.

[warmerdam]

On careful review I am not convinced that the lat/long grid on this particular map is actually in the WGS84 datum. The REF points in the .KAP file are listed as DN=WGS84, and after conversion to Mercator, and so forth an inspection shows that we are within approximately one second of the right position for the REF (GCP) pixels (well at least the first one). But the nearby map corner is off by around 8 seconds.

I conclude that the map surround is not in the WGS84 datum, which is consistent with the collar notes indicating the data predates 1970.

Is there any reason to believe that the map collar is accurate? Were you seeing similar problems with the Texas data?

[gaopeng]

I have asked the user for more information. Will let you know.

We did, however, confirm that MapTech BSB viewer does not have this shift problem with image 83157_2.kap.

[warmerdam]

We can reopen if there is a confirmation of a problem.