Opened 13 years ago

Closed 10 years ago

#2809 closed defect (worksforme)

Bad GCPs returned from this BSB

Reported by: gaopeng Owned by: warmerdam
Priority: normal Milestone:
Component: GDAL_Raster Version: 1.6.0
Severity: normal Keywords: BSB
Cc:

Description (last modified by warmerdam)

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.

Attachments (4)

australia4c.kap (11.6 KB) - added by gaopeng 13 years ago.
BSB with underlying projection Lambert conformal conic
11317_2.KAP (670.1 KB) - added by gaopeng 13 years ago.
UN=FEET
83157_2.KAP (303.1 KB) - added by gaopeng 13 years ago.
bsb162.JPG (43.2 KB) - added by gaopeng 13 years ago.
snapshot showing locational shift

Download all attachments as: .zip

Change History (21)

comment:1 Changed 13 years ago by warmerdam

Keywords: BSB added
Owner: changed from Warmerdam to warmerdam
Status: newassigned

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.

comment:2 Changed 13 years ago by warmerdam

Description: modified (diff)

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.

comment:3 Changed 13 years ago by warmerdam

Resolution: fixed
Status: assignedclosed

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

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by warmerdam

Resolution: fixed
Status: closedreopened

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.

comment:6 Changed 13 years ago by 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" );

Changed 13 years ago by gaopeng

Attachment: australia4c.kap added

BSB with underlying projection Lambert conformal conic

comment:7 Changed 13 years ago by gaopeng

I found a sample BSB with Lambert conformal conic projection.

comment:8 Changed 13 years ago by warmerdam

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

comment:9 Changed 13 years ago by gaopeng

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

comment:10 Changed 13 years ago by 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

Changed 13 years ago by gaopeng

Attachment: 11317_2.KAP added

UN=FEET

comment:11 Changed 13 years ago by 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?

Changed 13 years ago by gaopeng

Attachment: 83157_2.KAP added

comment:12 Changed 13 years ago by 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?

Changed 13 years ago by gaopeng

Attachment: bsb162.JPG added

snapshot showing locational shift

comment:13 Changed 13 years ago by 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.

comment:14 Changed 13 years ago by warmerdam

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

comment:15 Changed 13 years ago by 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?

comment:16 Changed 13 years ago by 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.

comment:17 Changed 10 years ago by warmerdam

Milestone: 1.6.4
Resolution: worksforme
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.