[Gdal-dev] Re: [GDAL] #913: NITF driver fails for some CADRG tiles

[Even Rouault]

Sophia,

apparently your file is not north up (you have upper latitude < lower 
latitude). I don't know if it is usual in NITF, but apparently (just reading 
a few comments) it's somehow taken into account in nitfdataset.cpp. GDAL 
itself shouldn't have problems with dealing with non square bounding box as 
long as there's an affine transform (rotation, scaling and translation) 
between the bounding box and a rectangle.

Now, on the difference of coordinates between what you see in CIVA and what 
reports gdalinfo, I think it's because in GDAL, we first read the IGEOLO 
fields, but if there is a RPF CoverageSectionSubheader, we read it (the 
content is binary doubles) and take it into account as it's supposed to have 
more precise bounds than IGEOLO. However, in your case, the differences for 
the longitudes are quite large (the latitudes are the same however) ...

Do you have an idea of what is the right bounding box ?

If possible, attaching the file would make investigation easier. You may send 
it privately to myself and/or F. Warmerdam.

Best regards

On Monday 10 September 2007 21:23:37 you wrote:
> Even,
>
> Thanks for the patch, but unfortunately it does not solve the problem
> with incorrect coordinates.  I see in the patch that gdal looks at the
> IGEOLO data to get the corner coordinates.  I looked at the file in a
> NITF validator tool called CIVA
> (http://www.gwg.nga.mil/ntb/baseline/software/jitctest.html) to check
> the value of the IGEOLO fields.
>
> Here's what CIVA returns:
>
>
>
> ISH [1] ->*ULIGEOLO*
> 15 bytes @0x353 bytes
>
>
>
> *Contents *
>
>
>
> "741119N1613354W"
>
>
>
> *Pass *
>
>
>
> *Status *
>
>
>
> *Message *
>
> Character Set
>
>
>
> OK
>
>
>
> "The field is compliant with the specification for Basic Character
> Set-Alphanumeric."
>
> 1
>
>
>
> OK
>
>
>
> "This field did match one of the format specifications."
>
> 2
>
>
>
> OK
>
>
>
> "There were no values or ranges to check."
>
> ISH [1] ->*URIGEOLO*
> 15 bytes @0x362 bytes
>
>
>
> *Contents *
>
>
>
> "741119N1613354E"
>
>
>
> *Pass *
>
>
>
> *Status *
>
>
>
> *Message *
>
> Character Set
>
>
>
> OK
>
>
>
> "The field is compliant with the specification for Basic Character
> Set-Alphanumeric."
>
> 1
>
>
>
> OK
>
>
>
> "This field did match one of the format specifications."
>
> 2
>
>
>
> OK
>
>
>
> "There were no values or ranges to check."
>
> ISH [1] ->*LRIGEOLO*
> 15 bytes @0x371 bytes
>
>
>
> *Contents *
>
>
>
> "825544N1350000E"
>
>
>
> *Pass *
>
>
>
> *Status *
>
>
>
> *Message *
>
> Character Set
>
>
>
> OK
>
>
>
> "The field is compliant with the specification for Basic Character
> Set-Alphanumeric."
>
> 1
>
>
>
> OK
>
>
>
> "This field did match one of the format specifications."
>
> 2
>
>
>
> OK
>
>
>
> "There were no values or ranges to check."
>
> ISH [1] ->*LLIGEOLO*
> 15 bytes @0x380 bytes
>
>
>
> *Contents *
>
>
>
> "825544N1350000W"
>
>
>
> *Pass *
>
>
>
> *Status *
>
>
>
> *Message *
>
> Character Set
>
>
>
> OK
>
>
>
> "The field is compliant with the specification for Basic Character
> Set-Alphanumeric."
>
> 1
>
>
>
> OK
>
>
>
> "This field did match one of the format specifications."
>
> 2
>
>
>
> OK
>
>
>
> "There were no values or ranges to check."
>
>
>
>  Here's what gdal returns:
>
>
> Corner Coordinates:
>
> Upper Left  (-148.2825256,  74.1886117)
>
> Lower Left  (-148.2825256,  82.9289322)
>
> Upper Right ( 148.2825256,  74.1886117)
>
> Lower Right ( 148.2825256,  82.9289322)
>
> Center      (   0.0000000,  78.5587719)
>
>
> The bounding box from the IGEOLO are not square, also the longitude is
> reported by gdal is the average of the longitudes in the IGEOLO fields.
> Is a non-square BBOX a problem for gdal?
>
>
> Regards,
>
>
> sophia
>
> Even Rouault wrote:
> > Sophia,
> >
> > thanks for testing the fix for bug #913.
> > What's annoying is that I've just tested your file and it works fine with
> > the svn version of GDAL trunk (as well as a version of GDAL 1.4.2 that
> > I've patched). Just out of curiosity, I've removed the fix for bug #913
> > and another CADRG bug I've fixed, and your file is still working fine...
> > Even more, it is still working fine with the official GDAL 1.4.2 release.
> > Are you really sure you're linking with the good GDAL library ?
> > I can't see other explanations for the moment.
> >
> > Your first message said that the bbox displayed was not correct. I get
> > the following results with GDAL svn trunk :
> >
> > Corner Coordinates:
> > Upper Left  ( 160.3951807,  59.5397891) (160d23'42.65"E, 59d32'23.24"N)
> > Lower Left  ( 160.3951807,  59.0220518) (160d23'42.65"E, 59d 1'19.39"N)
> > Upper Right ( 161.4361446,  59.5397891) (161d26'10.12"E, 59d32'23.24"N)
> > Lower Right ( 161.4361446,  59.0220518) (161d26'10.12"E, 59d 1'19.39"N)
> > Center      ( 160.9156627,  59.2809204) (160d54'56.39"E, 59d16'51.31"N)
> >
> > Best regards
> >
> > On Monday 27 August 2007 19:52:21 you wrote:
> >> Even,
> >>
> >> I rebuilt gdal with the patch but I get an error with the attached
> >> file.  Here is the error I get:
> >>
> >> ERROR 3: Unable to read 6144 byte block from -16705196.
> >> ERROR 1: IReadBlock failed at X offset 1, Y offset 3
> >>
> >>
> >> I've attached the file, it is a tile from a CADRG cd.
> >>
> >> Thanks,
> >>
> >> sophia
> >>
> >> Even Rouault wrote:
> >>> Sophia,
> >>>
> >>> I don't know what your exact problem was, but bug #913 has just been
> >>> fixed in GDAL trunk subversion repository and will be available in GDAL
> >>> 1.5.
> >>>
> >>> See http://trac.osgeo.org/gdal/ticket/913.
> >>>
> >>> Could you check if it also solves your problem ? Thank you.
> >>>
> >>> Best regards,