[GRASS-user] [gdal-dev] Working with NTF files

[Nikos Alexandris]

Nikos Alexandris:

> > 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?


Frank Warmerdam wrote:

> Your working solution with gdalwarp seems reasonable.  Is there a problem
> with it?

No (except that I left this option as the "final attempt" of many tests -- 
working with some >1GB images here, so it took me hours... :D).  Your 
confirmation, though, is highly useful!


> Perhaps you were hoping to do the RPC based warp within GRASS?

Yes, I was hopping to say something like:

--%<---
r.in.gdal in=NITF.ntf out=NITF sds=1 band=1,2,3,4 transform=rpc[,tps] 
[resampling=n,b,c,cs,l,a,m]
--->%--

:D -- I know, I am asking for too much.  I have read the following post
already: <http://fwarmerdam.blogspot.gr/2009/12/death-by-complexity.html>.

Also, there is already a (kind of related) grass-ticket:
<http://trac.osgeo.org/grass/ticket/798>.

 
> > 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." ?

> This is not important.  I presume you are getting this with JPEG2000
> compressed image streams in NITF?

Correct


> If you file a bug I might be able to clear this up but there are layers of
> complexity that make it challening.

I will (take the time later to) file a ticket.  I was hopping, anyhow, in case 
such warnings are not a real big deal, to have a way to supress them.  That 
would ease off, me thinks at least, scripting.  Some option like the "-q" one 
-- though, in this case it doesn't silence these Warnings.


> > 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.

> I'm afraid I'm one of those who neglected that thread.  I thought I saw Even
> answer is so I was happy to keep out of it.

> I can't speak to how the files should be described in GRASS.  Generally
> I'd hope that the value of using GDAL is that GRASS wouldn't need to
> talk too much about specific formats.

It certainly is so (in general).


> On the GDAL side we often have special info in trac wiki pages under the
> BuildHints page, but in this case the issues are more usage rather than
> building so there is no obvious place for user contributions.  The format
> pages for NITF do have quite a bit of info.  It is (I think) the only driver
> with an "advanced" page.  However, there are many kinds of NITF
> files and thus usage patterns that are an issue so it isn't clear how to
> handle that in the user docs.

I am (slowly) getting to see that there is a "bigger" picture.


> I've skimmed the rest of your post, but I don't have any particular
> advice or anything to add.  I do think it is reasonable to correct
> such images into a nicer form with gdalwarp before running r.in.gdal.

Your reply as a whole is very useful for me.

Thank you Frank, Nikos
--

[rest deleted]