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

[15] <<a href="http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg02376.html" target="_blank">http://www.mail-archive.com/gdal-dev@lists.osgeo.org/msg02376.html</a>>,<br>
refers to "-co".<br>
[16] <<a href="http://marc.info/?l=gdal-dev&m=121323053222339&w=2" target="_blank">http://marc.info/?l=gdal-dev&m=121323053222339&w=2</a>><br>
[17] <<a href="http://osdir.com/ml/gdal-development-gis-osgeo/2009-01/msg00044.html" target="_blank">http://osdir.com/ml/gdal-development-gis-osgeo/2009-01/msg00044.html</a>>,<br>
about compression/compressed output.<br>
<br>
<br>
Advanced coding discussions<br>
<br>
[18] <<a href="http://osgeo-org.1560.x6.nabble.com/NITF-image-metadata-domain-field-in-GDAL-SUBDATASETS-td3762940.html" target="_blank">http://osgeo-org.1560.x6.nabble.com/NITF-image-metadata-domain-field-in-GDAL-SUBDATASETS-td3762940.html</a>><br>

[19] <<a href="http://osgeo-org.1560.x6.nabble.com/gdal-dev-How-to-use-RPC-Metadata-from-NITF-Files-in-a-MapServer-TileIndex-td4981951.html" target="_blank">http://osgeo-org.1560.x6.nabble.com/gdal-dev-How-to-use-RPC-Metadata-from-NITF-Files-in-a-MapServer-TileIndex-td4981951.html</a>>, "The images also<br>

have rpc metadata and using the -rpc option in gdalwarp reprojects them quite<br>
well."<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up   | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com" target="_blank">warmerdam@pobox.com</a><br>
light and sound - activate the windows | <a href="http://pobox.com/~warmerdam" target="_blank">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush    | Geospatial Software Developer<br>
</div></div>