[Geoserver-users] NITF files incorrectly georeferenced

Hi,

I have never done anything with NITF and I am happy about your progress. I would try to resolve the ERROR 6 by reading the message, and http://www.gdal.org/frmt_nitf.html, and then perhaps

gdalwarp –of NITF –s_srs EPSG:4326 –t_srs EPSG:4326 –co ICORDS=G myOriginalFile.ntf myNewFile.ntf

-Jukka Rahkonen-

Smart, Gary wrote:

Using gdalwarp, the corners are indeed populated (thanks guys) – even when converting from a NTF directly to another NTF.

Converting to geotifs using gdalwarp also rectifies the image of course. When mosaicked into geoserver, the alignment to the underlying map is not precise, but I kind of expected this since IGEOLO precision in the NITF standard is pretty poor. The warping applied to the files by gdalwarp appears to be the same as that applied by the mosaic plugin on the raw geotif inputs I used before i.e. it would appear acceptable to pass non rectified imagery to the imageMosaic plugin and it presumably gdalwarps it for you.

A couple of interesting points worth noting that I’ve spotted en-route:

  1. With 16bit imagery, applying the transparency colours to zero in the layer preferences for a mosaic, turns the whole image transparent. I’m guessing that someone somewhere is assuming all inputs to the mosaic are 8bit?

  2. gdalwarp –of NITF –s_srs EPSG:4326 –t_srs EPSG:4326 myOriginalFile.ntf myNewFile.ntf fails to embed the georeferencing into the IGEOLO, giving the following errors:

ERROR 6: NITF file should have been created with creation option ‘ICORDS=G’ (or ‘ICORDS=D’).

ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.

and dumps an aux.xml file instead – presumably not used by Geoserver which crashes immediately on publishing such mosaicked NITF layers with:

java.lang.RuntimeException: Error occurred while building the resources for the configuration page which is ultimately ‘caused by’ No Transformation available from System”EngineeringCRS[Wildcard 2D Cartesian plane in metric unit] to GeographicCRS[WGS84(DD)]

…which is fair enough I suppose!

Brilliant! By telling GDAL to use ICORDS=G, the mosaic plugin correctly loads the NITFs directly. I still have to convert the NITF files to 8bit first (otherwise the mosaic can’t deal with the transparent colour selections), but apart from that – bingo!

···

From: Rahkonen Jukka (MML) [mailto:jukka.rahkonen@…6847…]
Sent: 21 October 2015 15:56
To: Smart, Gary Export License Required - US UTAS
Cc: geoserver-users@lists.sourceforge.net
Subject: [External] Re: [Geoserver-users] NITF files incorrectly georeferenced

Hi,

I have never done anything with NITF and I am happy about your progress. I would try to resolve the ERROR 6 by reading the message, and http://www.gdal.org/frmt_nitf.html, and then perhaps

gdalwarp –of NITF –s_srs EPSG:4326 –t_srs EPSG:4326 –co ICORDS=G myOriginalFile.ntf myNewFile.ntf

-Jukka Rahkonen-

Smart, Gary wrote:

Using gdalwarp, the corners are indeed populated (thanks guys) – even when converting from a NTF directly to another NTF.

Converting to geotifs using gdalwarp also rectifies the image of course. When mosaicked into geoserver, the alignment to the underlying map is not precise, but I kind of expected this since IGEOLO precision in the NITF standard is pretty poor. The warping applied to the files by gdalwarp appears to be the same as that applied by the mosaic plugin on the raw geotif inputs I used before i.e. it would appear acceptable to pass non rectified imagery to the imageMosaic plugin and it presumably gdalwarps it for you.

A couple of interesting points worth noting that I’ve spotted en-route:

  1. With 16bit imagery, applying the transparency colours to zero in the layer preferences for a mosaic, turns the whole image transparent. I’m guessing that someone somewhere is assuming all inputs to the mosaic are 8bit?

  2. gdalwarp –of NITF –s_srs EPSG:4326 –t_srs EPSG:4326 myOriginalFile.ntf myNewFile.ntf fails to embed the georeferencing into the IGEOLO, giving the following errors:

ERROR 6: NITF file should have been created with creation option ‘ICORDS=G’ (or ‘ICORDS=D’).

ERROR 6: Apparently no space reserved for IGEOLO info in NITF file.

and dumps an aux.xml file instead – presumably not used by Geoserver which crashes immediately on publishing such mosaicked NITF layers with:

java.lang.RuntimeException: Error occurred while building the resources for the configuration page which is ultimately ‘caused by’ No Transformation available from System”EngineeringCRS[Wildcard 2D Cartesian plane in metric unit] to GeographicCRS[WGS84(DD)]

…which is fair enough I suppose!