Hi list & apologies for cross-posting.
In short, I am trying to handle ntf files (NITF) as easy as possible -- working with some WorldView 01/02 and QuickBird imagery. 1) The question is: how do you correctly import in GRASS-GIS QuickBird & WorldView imagery from N(I)TF containers? 2) A second, of less importance, question, is: how important are the warnings like: "Warning 1: Unable to save auxilary information in /vsisubfile/3884_471349721,10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf.aux.xml." ? My working solution (seems to be), is to gdal-warp the SUBDATASET that contains the raster spectral bands _and_ by using the -rpc switch (mentioned in some past post in GDAL-dev's ML [19]). Otherwise, the resulting warped image is heavily skewed and not ready for analysis. E.g.: --%<--- gdalwarp -rpc NITF_IM:0:10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf 10APR13WV020600013APR10075059- P1BS-500060446050_05_P003_NorthUp.tif --->%-- This post is, also, sort of a BUMP related to my previous latest message in the GDAL-dev-ML's thread entitled "Can't read NITF images" :-! I think that N(I)TF files, no matter whatsoever the status of the related drivers are, as well as the "feelings" towards favouring it or not, deserves some more examples, a page in GRASS-Wiki perhaps, etc. Now, the long story is that, I 've been through the list (grass-user, gdal-dev), manuals (grass importing related stuff & gdal's driver's documentation), well known and easy to find pages in GRASS-Wiki, GDAL tutorials, etc. I haven't found any concrete examples on working with NITF images and GFOSS. [**See various links in the end] I would appreciate any hints (while I am actively searching How To do this best) to save time in the quest to find an optimal solution which can be scripted to handle various images from the same source. Unfortunately, there is no access in GeoTiffs (so far/yet)! Set aside the internal compression "obstacle" (JPEG2000) which one can overcome using the OpenJPEG driver (or, necessarily some proprietary (?) bound solution [0, 1, 2, 3]), NITF files that contain multiple SUBDATASETS may look like: # code ################################################### gdalinfo -nomd -norat -noct -nofl 10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf Driver: NITF/National Imagery Transmission Format Files: 10APR13WV020600013APR10075059-P1BS-500060446050_05_P003.ntf Size is 35840, 27648 Coordinate System is `' GCP Projection = GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9108"]], AUTHORITY["EPSG","4326"]] GCP[ 0]: Id=UpperLeft, Info= (0.5,0.5) -> (43.8088888888889,-23.3544444444444,0) GCP[ 1]: Id=UpperRight, Info= (35839.5,0.5) -> (43.6219444444444,-23.3344444444444,0) GCP[ 2]: Id=LowerRight, Info= (35839.5,27647.5) -> (43.6225,-23.1958333333333,0) GCP[ 3]: Id=LowerLeft, Info= (0.5,27647.5) -> (43.8083333333333,-23.2152777777778,0) Subdatasets: SUBDATASET_1_NAME=NITF_IM:0:10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf SUBDATASET_1_DESC=Image 1 of 10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf SUBDATASET_2_NAME=NITF_IM:1:10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf SUBDATASET_2_DESC=Image 2 of 10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0,27648.0) Upper Right (35840.0, 0.0) Lower Right (35840.0,27648.0) Center (17920.0,13824.0) Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Gray Overviews: 17920x13824, 8960x6912, 4480x3456, 2240x1728, 1120x864 Overviews: arbitrary ################################################### The 1st SUBDATASET is reported as: # code ################################################### gdalinfo -sd 1 -nomd -norat -noct -nofl 10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf [ -- cut -- some Warnings -- ] Driver: NITF/National Imagery Transmission Format Files: 10APR13WV020600013APR10075059-P1BS-500060446050_05_P003.ntf Size is 35840, 27648 Coordinate System is `' GCP Projection = GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9108"]], AUTHORITY["EPSG","4326"]] GCP[ 0]: Id=UpperLeft, Info= (0.5,0.5) -> (43.8088888888889,-23.3544444444444,0) GCP[ 1]: Id=UpperRight, Info= (35839.5,0.5) -> (43.6219444444444,-23.3344444444444,0) GCP[ 2]: Id=LowerRight, Info= (35839.5,27647.5) -> (43.6225,-23.1958333333333,0) GCP[ 3]: Id=LowerLeft, Info= (0.5,27647.5) -> (43.8083333333333,-23.2152777777778,0) Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0,27648.0) Upper Right (35840.0, 0.0) Lower Right (35840.0,27648.0) Center (17920.0,13824.0) Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Gray Overviews: 17920x13824, 8960x6912, 4480x3456, 2240x1728, 1120x864 Overviews: arbitrary [ -- cut -- some Warnings -- ] ################################################### The 2nd SUBDATASET is reported as: # code ################################################### gdalinfo -sd 2 -nomd -norat -noct -nofl 10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf [ -- cut -- some Warnings -- ] Driver: NITF/National Imagery Transmission Format Files: 10APR13WV020600013APR10075059-P1BS-500060446050_05_P003.ntf Size is 97, 78 Coordinate System is: GEOGCS["WGS 84", DATUM["WGS_1984", SPHEROID["WGS 84",6378137,298.257223563, AUTHORITY["EPSG","7030"]], TOWGS84[0,0,0,0,0,0,0], AUTHORITY["EPSG","6326"]], PRIMEM["Greenwich",0, AUTHORITY["EPSG","8901"]], UNIT["degree",0.0174532925199433, AUTHORITY["EPSG","9108"]], AUTHORITY["EPSG","4326"]] GeoTransform = 43.8096587433111, -0.001954571759259283, -1.803751803795437e-06 -23.35525135093495, 0.0002068865740741814, 0.001823593073593144 Corner Coordinates: Upper Left ( 43.8096587, -23.3552514) ( 43d48'34.77"E, 23d21'18.90"S) Lower Left ( 43.8095181, -23.2130111) ( 43d48'34.26"E, 23d12'46.84"S) Upper Right ( 43.6200653, -23.3351834) ( 43d37'12.24"E, 23d20' 6.66"S) Lower Right ( 43.6199246, -23.1929431) ( 43d37'11.73"E, 23d11'34.60"S) Center ( 43.7147917, -23.2740972) ( 43d42'53.25"E, 23d16'26.75"S) Band 1 Block=97x1 Type=Byte, ColorInterp=Undefined ################################################### Likewise, reporting on a Multi-Spectral NTF container, the 2nd SUBDATASET is the Spatial Reference System information. Unfortunately, though expected, r.in.gdal complains about the missing projection info for the 1st SUBDATASET. # code ################################################### r.in.gdal in=NITF_IM:0:10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf out=m_sd_1 ERROR: Projection of dataset does not appear to match current location. Location PROJ_INFO is: name: Lat/Lon proj: ll datum: wgs84 ellps: wgs84 no_defs: defined Import dataset PROJ_INFO is: cellhd.proj = 0 (unreferenced/unknown) You can use the -o flag to r.in.gdal to override this check and use the location definition for the dataset. Consider generating a new location from the input dataset using the 'location' parameter. [ -- cut -- some Warnings -- ] ################################################### Adding the "-o" flag, gets to the next error: # code ################################################### r.in.gdal in=NITF_IM:0:10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf out=m_sd_1 -o WARNING: Over-riding projection check ERROR: Illegal latitude for North [ -- cut -- some Warnings -- ] ################################################### Adding the "-l" switch, takes too much time "waiting" in 0% for the import process. Now, the GCP's are given in the 2nd SUBDATASET(s). Is there any way to avoid usnig "r.region" and make the long story short, just by using some gdal-* magic? Using gdalwarp to go NorthUp: #################################################### code # gdalwarp -of NITF -co "ICORDS=G" NITF_IM:0:10APR13WV020600013APR10075059- P1BS-500060446050_05_P003.ntf 10APR13WV020600013APR10075059- P1BS-500060446050_05_P003_NorthUp.ntf ################################################### allows for imoprting the image via r.in.gdal. However, this image is obviously and heavily skewed/shifted. Using r.region doesn't make any sense... since the image boundaries coincide! #################################################### code # gdalinfo -nomd -noct -norat -nofl -nogcp 10APR13WV020600013APR10075059- M1BS-500060446050_05_P003_NorthUp.tif Corner Coordinates: Upper Left ( 43.6218649, -23.1956837) ( 43d37'18.71"E, 23d11'44.46"S) Lower Left ( 43.6218649, -23.3543246) ( 43d37'18.71"E, 23d21'15.57"S) Upper Right ( 43.8088360, -23.1956837) ( 43d48'31.81"E, 23d11'44.46"S) Lower Right ( 43.8088360, -23.3543246) ( 43d48'31.81"E, 23d21'15.57"S) ################################################### and minor differences when gdal-warping in to a NITF file #################################################### code # Corner Coordinates: Upper Left ( 43.6219339, -23.1955450) ( 43d37'18.96"E, 23d11'43.96"S) Lower Left ( 43.6219339, -23.3544550) ( 43d37'18.96"E, 23d21'16.04"S) Upper Right ( 43.8088994, -23.1955450) ( 43d48'32.04"E, 23d11'43.96"S) Lower Right ( 43.8088994, -23.3544550) ( 43d48'32.04"E, 23d21'16.04"S) ################################################### After importing, one band reports #################################################### code # r.info -g M1BS_from_TIF.1 north=-23.1956836847222 south=-23.3543246272222 east=43.8088360363889 west=43.6218648544444 ################################################### The corner coordinates are practically identical. Hence, it doesn't look like boundary (re-)definition/correction is required for these rasters. So, how do you go about your NITF images? The only "nice-working" attempt so far, is when I extacted a specific fragment out of the Multi-Spectral container, for example, using the "-te" switch while warping, i.e. (using values, of course, in place of West, South, North and East): gdalwarp -s_srs 'epsg:4326' -te West South North East 03APR13WV010500013APR03073141-P1BS-500060446050_03_P003.ntf test.tif These small fragments coincide perfectly with some vectorised area of intere st. And, finally, and fortunately, adding the "-rpc" magic, seems to do the trick. Importing an rpc-warped image in GRASS, looks, after some cross-checks, nice :-) Any other solutions? Thanks, Nikos --- [0] <http://www.jpeg.org/faq.phtml?action=show_answer&question_id=q3f042a68b1081> [1] <http://trac.osgeo.org/gdal/wiki/ECW> [2] <http://trac.osgeo.org/gdal/wiki/JasPer> [3] <http://trac.osgeo.org/gdal/wiki/JP2KAK> [4] <http://trac.osgeo.org/gdal/wiki/MrSID> NITF and GDAL [5] <http://www.gdal.org/frmt_nitf.html> [6] <http://www.gdal.org/frmt_nitf_advanced.html> NITF Related posts (even a bit) [7] <http://lists.maptools.org/pipermail/fwtools/2008-March/001193.html>, 2008, refers also to license stuff. [8] <http://osgeo-org.1560.x6.nabble.com/gdal-dev-Can-t-read-NITF-image-td5064590.html> [9] <http://lists.osgeo.org/pipermail/gdal-dev/2012-April/032431.html> [10] <http://web.archiveorange.com/archive/v/H2CPnHaFxXHV9S1zxqmE> [11] <http://lists.osgeo.org/pipermail/grass-user/2000-May/003502.html>, very old! [12] <http://lists.osgeo.org/pipermail/grass-user/2006-March/033353.html>, old [13] <http://lists.osgeo.org/pipermail/grass-user/2006-March/033300.html>, old [14] <http://osgeo-org.1560.x6.nabble.com/gdal-dev-NITF-with-MultiDataSet-td5050649.html>, "Try building a vrt with the NITF datasets." [15] <http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg02376.html>, refers to "-co". [16] <http://marc.info/?l=gdal-dev&m=121323053222339&w=2> [17] <http://osdir.com/ml/gdal-development-gis-osgeo/2009-01/msg00044.html>, about compression/compressed output. Advanced coding discussions [18] <http://osgeo-org.1560.x6.nabble.com/NITF-image-metadata-domain-field-in-GDAL-SUBDATASETS-td3762940.html> [19] <http://osgeo-org.1560.x6.nabble.com/gdal-dev-How-to-use-RPC-Metadata-from-NITF-Files-in-a-MapServer-TileIndex-td4981951.html>, "The images also have rpc metadata and using the -rpc option in gdalwarp reprojects them quite well." _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev