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] _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev