Opened 15 years ago

Closed 15 years ago

#2940 closed defect (fixed)

NITF projection wrong at high latitudes

Reported by: karney Owned by: Even Rouault
Priority: normal Milestone: 1.7.0
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: nitf polar
Cc:

Description

The documentation for NITF data says that it typically uses a polar projection north of 80N where

x = (90-lat) * sin(lon); y = (90-lat) * -cos(lon)

(not sure I have the phase of lon right...). I have an ONC image 00028053.on9 where the projection is in this form (lat = 80N is circular).

However GDAL thinks there's merely an affine transformation between image space and geographic coordinates. So when I warp the image to WGS84 geographic coordinates lat = 80N is still curved.

Is this a problem with the meta data in my file? Or is GDAL mishandled these images at high latitudes.

00028053.on9 attached

Attachments (4)

00028053.on9 (143.0 KB ) - added by karney 15 years ago.
ONC image from zone 9
0001x053.on9 (143.0 KB ) - added by karney 15 years ago.
A second ONC file
0001x053_geo.tif (735.1 KB ) - added by karney 15 years ago.
Result of gdalwarp on ONC file
00028053_geo.tif (735.1 KB ) - added by karney 15 years ago.
Result of gdalwarp on first ONC file

Download all attachments as: .zip

Change History (13)

by karney, 15 years ago

Attachment: 00028053.on9 added

ONC image from zone 9

comment:1 by Even Rouault, 15 years ago

Component: defaultGDAL_Raster
Keywords: nitf polar added
Milestone: 1.7.0
Resolution: fixed
Status: newclosed

karney,

your analysis is right. GDAL assumed that the image was a "rectangle" (or an affine transform of a rectangle) in lat/long space, whereas in the polar case it is a rectangle in Azimuthal Equidistant projection.

I've fixed that in trunk (r16750) and could check in OpenEV that the georeferencing is correct : the 80° parallel and the meridians each degree drawn on the image matches the coordinates values.

"gdalwarp -t_srs EPSG:4326 00028053.on9 00028053.on9.tif" works, but the result is obviously not very pretty considering the latitudes...

If you could check that the fix is correct for other polar images that would be great (it should also fix the south pole case, but I couldn't test it as I had only your sample image to test)

by karney, 15 years ago

Attachment: 0001x053.on9 added

A second ONC file

in reply to:  1 comment:2 by karney, 15 years ago

Resolution: fixed
Status: closedreopened
Version: unspecifiedsvn-trunk

I tested the fix with svn verion 16760. I don't see any change. This is the first time I'm compiled GDAL from source, so possibly I screwed up...

I'm attaching a second neighboring onc file and the results of

~-/gdalwarp -t_srs EPSG:4326 -te 84 79.94 96 80.64 -ts 1500 500 \

0001x053.on9 0001x053_geo.tif

~-/gdalwarp -t_srs EPSG:4326 -te 95 79.94 107 80.64 -ts 1500 500 \

00028053.on9 00028053_geo.tif

The *_geo.tif files clearly show the meridians converging. Can you try the above commands on the on9 files and ascertain whether you get the same results as me (in which case, the bug isn't fixed) or different results (in which case, I'll need to try compiling GDAL again).

by karney, 15 years ago

Attachment: 0001x053_geo.tif added

Result of gdalwarp on ONC file

by karney, 15 years ago

Attachment: 00028053_geo.tif added

Result of gdalwarp on first ONC file

comment:3 by Even Rouault, 15 years ago

Owner: changed from warmerdam to Even Rouault
Status: reopenednew

I don't get the same results as yours, and mine look correct contrary to yours. I suspect that the gdalwarp you're running is still linking towards the libgdal.so installed on your system. You could try uninstalling your system GDAL, or use LD_LIBRARY_PATH to point to the path where you've installed your compiled library. You can check that you're running the correct version with gdalinfo --version. It should return "GDAL 1.7.0dev, released 2008/11/26"

comment:4 by karney, 15 years ago

Owner: changed from Even Rouault to karney
Status: newassigned

Well, I am using 1.7.0dev, released 2008/11/26 (svn version 16762 ); I hid the gdal library in /usr/lib64; ldd reports gdalwarp using the library is the one I just built...

And yet I still get warped results with a circle for lat = 80N.

I'm prepared to put this down to a screw-up on my part and this not a show stopper for me at the moment. So I'm happy to have with ticket closed and I'll check when the fix gets included in a release.

Thanks for your help.

comment:5 by karney, 15 years ago

Owner: changed from karney to Even Rouault
Status: assignednew

Whoops I misunderstood "accept ticket". I did that in error.

comment:6 by Even Rouault, 15 years ago

Hum, that's weird... Have you proj.4 correctly installed ?

Here's the output of "gdalinfo 00028053.on9 -noct -nomd" :

Driver: NITF/National Imagery Transmission Format
Files: 00028053.on9
Size is 1536, 1536
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["unnamed ellipse",
        DATUM["unknown",
            SPHEROID["unnamed",6378137,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Azimuthal_Equidistant"],
    PARAMETER["latitude_of_center",90],
    PARAMETER["longitude_of_center",0],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]
Origin = (1036422.845316683407873,345474.281772228132468)
Pixel Size = (149.945434796973274,-149.945434796974041)
Corner Coordinates:
Upper Left  ( 1036422.845,  345474.282) (108d26'5.82"E, 80d11'9.73"N)
Lower Left  ( 1036422.845,  115158.094) ( 96d20'24.69"E, 80d37'56.50"N)
Upper Right ( 1266739.033,  345474.282) (105d15'18.43"E, 78d12'18.29"N)
Lower Right ( 1266739.033,  115158.094) ( 95d11'39.94"E, 78d34'25.55"N)
Center      ( 1151580.939,  230316.188) (101d18'35.76"E, 79d27'1.10"N)
Band 1 Block=256x256 Type=Byte, ColorInterp=Palette
  NoData Value=216
  Color Table (RGB with 217 entries)

Do you get the same ? Look especially at the "corner coordinates" part.

(Also don't forget to delete the output file of gdalwarp before running it again, as it will try reusing existing files. But I don't think that's your issue.)

in reply to:  6 comment:7 by karney, 15 years ago

Replying to rouault:

Hum, that's weird... Have you proj.4 correctly installed ?

I'm using the stock proj 4 for Linux...

proj-4.5.0-4.fc9.x86_64 proj-devel-4.5.0-4.fc9.x86_64

Do I need to rebuild this from source?

Here's the output of "gdalinfo 00028053.on9 -noct -nomd" :

No I get the old corner points.

Here's how I configure GDAL...

CFLAGS=-O0 CXXFLAGS=-O0 CPPFLAGS=-I/usr/include/libgeotiff ./configure --prefix=/scratch/gdal/test

checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking C_WFLAGS for maximum warnings... -Wall -Wdeclaration-after-statement
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking CXX_WFLAGS for maximum warnings... -Wall
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 32768
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/bin/ld option to reload object files... -r
checking how to recognize dependent libraries... pass_all
checking for ar... ar
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking how to run the C++ preprocessor... g++ -E
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... no
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking for dlopen in -ldl... yes
checking for nanosleep in -lrt... yes
checking for sin in -lm... yes
checking for ANSI C header files... (cached) yes
checking assert.h usability... yes
checking assert.h presence... yes
checking for assert.h... yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking for unistd.h... (cached) yes
checking dbmalloc.h usability... no
checking dbmalloc.h presence... no
checking for dbmalloc.h... no
checking for dlfcn.h... (cached) yes
checking for stdint.h... (cached) yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking values.h usability... yes
checking values.h presence... yes
checking for values.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking direct.h usability... no
checking direct.h presence... no
checking for direct.h... no
checking whether byte ordering is bigendian... no
checking for 64bit integer type... long long
checking for 64bit file io... yes
checking for stat64... yes
checking for fopen64... yes
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 8
checking for unsigned long... yes
checking size of unsigned long... 8
checking for void*... yes
checking size of void*... 8
checking for int8... no
checking for int16... no
checking for int32... no
checking native cpu bit order... msb2lsb
checking for vprintf... yes
checking for _doprnt... no
checking for snprintf... yes
checking for vsnprintf... yes
checking for atoll... yes
checking for strtof... yes
checking for getcwd... yes
checking whether strtof is declared... no
checking for gmtime_r... yes
checking for localtime_r... yes
checking for setlocale... yes
checking to enable debug build... no, CFLAGS="-O0"
checking whether GCC 4.1 atomic builtins are available... yes
checking whether we should hide internal symbols... no
checking for local include/lib path... none
configure: checking whether we should include thread/mutex support......
	 thread safe support disabled.
checking for deflateInit_ in -lz... yes
checking for inflateCopy in -lz... yes
using pre-installed libz
checking for pg_config... no
checking for PostgreSQL... no
checking for G_gisinit_2 in -lgrass5... no
checking for ffopen in -lcfitsio... no
libcfitsio not found - FITS support disabled
checking for Mopen in -lcsf... no
checking csf.h usability... no
checking csf.h presence... no
checking for csf.h... no
using internal csf code.
checking for nc_open in -lnetcdf... no
libnetcdf not found - netCDF support disabled
checking for png_set_IHDR in -lpng... yes
checking png.h usability... yes
checking png.h presence... yes
checking for png.h... yes
using pre-installed libpng.
checking for TIFFGetTagListCount in -ltiff... yes
checking for _TIFFsetDoubleArray in -ltiff... yes
checking for TIFFScanlineSize64 in -ltiff... no
using pre-installed libtiff.
checking for XTIFFClientOpen in -lgeotiff... yes
using pre-installed libgeotiff.
checking for jpeg_read_scanlines in -ljpeg... yes
checking jpeglib.h usability... yes
checking jpeglib.h presence... yes
checking for jpeglib.h... yes
using pre-installed libjpeg.
checking for DGifOpenFileName in -lgif... yes
using pre-installed libgif.
checking for cln_GetLayerCapabilities in -logdi31... no
checking for FMEObjects... no
checking for SDreaddata in -lmfhdf... no
checking for SDreaddata in -lhdf4... no
checking for SDreaddata in -lmfhdf... no
checking for SDreaddata in -lmfhdf... no
checking for H5Fopen in -lhdf5... no
checking for jpc_decode in -ljasper... no
checking for jp2_decode in -ljasper... no
checking for pgx_decode in -ljasper... no
checking for NCScbmOpenFileView in -lNCSEcw... no
checking for NCScbmOpenFileView in -lecwj2... no
checking for Kakadu JPEG2000 support... not requested.
configure: MrSID support disabled.
checking for MSG... not requested
checking for BSB... enabled
checking if Oracle support is enabled... no
checking for GRIB... enabled
checking for OGR ... enabled
checking for MySQL... no
checking for Ingres... no
checking for Xerces C++ Parser... no
checking for Expat XML Parser headers in /usr/include... found
checking for Expat XML Parser libraries... found
checking for Expat XML Parser... yes
checking if Expat XML Parser version is >= 1.95.0... yes
checking for SQLConnect in -lodbc... yes
checking for SQLInstallDriverEx in -lodbcinst... yes
odbc library found, but sql.h missing, ODBC support disabled.
checking if Oracle support is enabled... no
checking Checking for DODS... disabled
checking for curl-config... /usr/bin/curl-config
	 found libcurl version 7.18.2
checking for SQLite3 library >= 3.0.0... yes
checking Checking for DWGdirect... disabled
configure: IBM Informix DataBlade not supported.
configure: checking whether we should include ESRI SDE support...
	 ESRI SDE support not requested.
checking for geos-config... no
checking whether to enable PAM... yes
checking how to link PROJ.4 library... link dynamically.
checking GDAL version information from gdal_version.h: 1.7.0
checking for perl bindings... disabled
checking for php bindings... disabled
checking for ruby bindings... disabled
checking for python bindings... disabled
checking for old-gen python bindings... disabled
configure: creating ./config.status
config.status: creating GDALmake.opt
config.status: WARNING:  GDALmake.opt.in seems to ignore the --datarootdir setting
config.status: creating port/cpl_config.h
config.status: port/cpl_config.h is unchanged
config.status: executing libtool commands

GDAL is now configured for x86_64-unknown-linux-gnu

  Installation directory:    /scratch/gdal/test
  C compiler:                gcc -O0
  C++ compiler:              g++ -O0

  LIBTOOL support:           yes

  LIBZ support:              external
  GRASS support:             no
  CFITSIO support:           no
  PCRaster support:          internal
  NetCDF support:            no
  LIBPNG support:            external
  LIBTIFF support:           external (BigTIFF=no)
  LIBGEOTIFF support:        external
  LIBJPEG support:           external
  LIBGIF support:            external
  OGDI support:              no
  HDF4 support:              no
  HDF5 support:              no
  Kakadu support:            no
  JasPer support:            no
  ECW support:               no
  MrSID support:             no
  MSG support:               no
  GRIB support:              yes
  cURL support (wms/wcs/...):yes
  PostgreSQL support:        no
  MySQL support:             no
  Ingres support:            no
  Xerces-C support:          no
  NAS support:               no
  Expat support:             yes
  ODBC support:              no
  PGeo support:              no
  OCI support:               no
  GEORASTER support:         no
  SDE support:               no
  DODS support:              no
  SQLite support:            yes
  DWGdirect support          no
  INFORMIX DataBlade support:no
  GEOS support:              no


  Old-gen python          no
  SWIG Bindings:          no

  Statically link PROJ.4:    no
  enable OGR building:       yes
  enable pthread support:    no
  hide internal symbols:     no


comment:8 by Even Rouault, 15 years ago

Ok now, I've found the difference between our two setups. I use proj 4.6, and you use proj 4.5. I've tested with proj 4.5 and my fix doesn't work in that case. I'll try to understand the differences.

comment:9 by Even Rouault, 15 years ago

Resolution: fixed
Status: newclosed

I've failed to understand why it works for proj 4.6 and not for previous versions, and found no workaround. So proj 4.6 is a requirement for this fix to work.

Note: See TracTickets for help on using tickets.