Le lundi 02 mai 2016 15:43:42, Daniele Romagnoli a écrit : > Cool! > Do you think this capability will be backported to 1.11 series too?
Possibly if you file a ticket about that. > > Thanks for your assistance. > Cheers, > Daniele > > On Mon, May 2, 2016 at 3:42 PM, Even Rouault <[email protected]> > > wrote: > > Le lundi 02 mai 2016 15:37:58, Daniele Romagnoli a écrit : > > > On Mon, May 2, 2016 at 3:27 PM, Even Rouault > > > <[email protected] > > > > > > wrote: > > > > Le lundi 02 mai 2016 15:16:30, Daniele Romagnoli a écrit : > > > > > Hi Even, > > > > > The produced GeoTIFF doesn't contain any nodata metadata/flag/TAG. > > > > > It simply has "NaN" pixels. QuantumGIS report those pixels as "nan" > > > > and > > > > > > > OpenEV report them as 1.#QNAN so I think they are properly > > > > "recognized" > > > > > > as > > > > > > > > > NaN. > > > > > > > > > > I'm wondering if the GDAL utilities explicitly look for some > > > > > > > > metadata/flag > > > > > > > > > (as the "nodata value" in your previous ascii based sample) to do > > > > > noData checks or if it's also able to recognize a NaN "binary" > > > > > value inside the pixels. > > > > > > > > Yes, the NaN value must be explicitly set as the nodata property of > > > > the geotiff > > > > file so that gdalbuildvrt can recognize it as the nodata value > > > > (similarly > > > > > > to > > > > other nodata value) > > > > > > > > You can do this with gdal_translate -a_nodata nan (or gdal_edit.py > > > > -a_nodata > > > > nan) > > > > > > Ok. Thanks. > > > I was trying to add it with "gdalbuildvrt -srcnodata nan" to avoid an > > > intermediate step between my geotiff and the VRT but I was getting: > > > ERROR 5: Invalid -srcnodata value > > > > > > Therefore, I had to edit the VRT by replacing the > > > <ComplexSource><NODATA>-9999</NODATA></ComplexSource> with "nan" > > > instead > > > > of > > > > > "-9999". > > > Do you know if there is any chance to let the -srcnodata parameter > > > > accept a > > > > > String like "nan"? > > > > Yes, this is available in the fresh new 2.1.0: > > * gdalbuildvrt: accept nan as value for -srcnodata and -vrtnodata > > > > > Cheers, > > > Daniele > > > > > > > > What do you think about it? > > > > > Cheers, > > > > > Daniele > > > > > > > > > > On Mon, May 2, 2016 at 2:52 PM, Daniele Romagnoli < > > > > > > > > > > [email protected]> wrote: > > > > > > Hi Even. > > > > > > Thanks for the feedback. > > > > > > > > > > > > Sorry... I'm using GDAL 1.11.3. > > > > > > I'm going to double check to make sure I didn't make any mistake. > > > > > > I'll let you know. > > > > > > > > > > > > Cheers, > > > > > > Daniele > > > > > > > > > > > > > > > > > > > > > > > > On Mon, May 2, 2016 at 2:49 PM, Even Rouault < > > > > > > > > [email protected]> > > > > > > > > > > wrote: > > > > > >> Le lundi 02 mai 2016 14:37:39, Daniele Romagnoli a écrit : > > > > > >> > Hi List, > > > > > >> > > > > > > >> > I have a reprojectiion tool which creates GeoTIFFs with NoData > > > > > >> > = > > > > > > > > NaN. > > > > > > > > > >> > I'm creating couple of GeoTIFFs with partially overlapping > > > > > >> > areas > > > > > > > > where > > > > > > > > > >> > GeoTIFF1 has NaNs in a region and GeoTIFF2 has proper values > > > > > >> > in the same overlapping region and viceversa (GeoTIFF2 has > > > > > >> > some NaN area while > > > > > >> > > > > > >> GeoTIFF1 > > > > > >> > > > > > >> > has valid pixels for same area). > > > > > >> > I have built a VRT on top of them and then translated into a > > > > > >> > single GeoTIFF. However, the result has NaN in those regions. > > > > > >> > I was hoping that the area containing NaNs would have been > > > > ignored > > > > > > > >> instead, > > > > > >> > > > > > >> > in favor of proper values from the other file. > > > > > >> > Is there any flag, properties or suggestions to make it > > > > > >> > working? > > > > > >> > > > > > > >> > If I configure the reprojection tool to write NoData = -9999 > > > > > >> > and > > > > > > > > then > > > > > > > > > >> use > > > > > >> > > > > > >> > gdalbuildvrt -srcnodata -9999, things are working fine. > > > > > >> > So I'm just wondering if the same can be achieved dealing with > > > > NaN > > > > > > > >> instead > > > > > >> > > > > > >> > of custom values. > > > > > >> > > > > > >> Daniele, > > > > > >> > > > > > >> You didn't mention which GDAL version you use. It is possible > > > > > >> that support for > > > > > >> NaN as a nodata value in gdalbuildvrt & the VRT driver was fixed > > > > at > > > > > > some > > > > > > > > > >> point. > > > > > >> From a quick test with trunk, it works (works with 1.11 branch > > > > > >> as well): > > > > > >> > > > > > >> $ cat in1.asc > > > > > >> ncols 3 > > > > > >> nrows 3 > > > > > >> xllcorner 440720.000000000000 > > > > > >> yllcorner 3750120.000000000000 > > > > > >> cellsize 60.000000000000 > > > > > >> NODATA_value nan > > > > > >> > > > > > >> 1.0 1.0 1.0 > > > > > >> 1.0 nan 1.0 > > > > > >> 1.0 1.0 1.0 > > > > > >> > > > > > >> $ cat in2.asc > > > > > >> ncols 3 > > > > > >> nrows 3 > > > > > >> xllcorner 440720.000000000000 > > > > > >> yllcorner 3750120.000000000000 > > > > > >> cellsize 60.000000000000 > > > > > >> NODATA_value nan > > > > > >> > > > > > >> nan nan nan > > > > > >> nan 2.0 nan > > > > > >> nan nan nan > > > > > >> > > > > > >> $ gdalbuildvrt nan.vrt in1.asc in2.asc > > > > > >> > > > > > >> $ gdal_translate nan.vrt /vsistdout/ -of aaigrid > > > > > >> ncols 3 > > > > > >> nrows 3 > > > > > >> xllcorner 440720.000000000000 > > > > > >> yllcorner 3750120.000000000000 > > > > > >> cellsize 60.000000000000 > > > > > >> NODATA_value nan > > > > > >> > > > > > >> 1 1 1 > > > > > >> 1 2 1 > > > > > >> 1 1 1 > > > > > >> > > > > > >> Even > > > > > >> > > > > > >> -- > > > > > >> Spatialys - Geospatial professional services > > > > > >> http://www.spatialys.com > > > > > > > > > > > > -- > > > > > > == > > > > > > GeoServer Professional Services from the experts! Visit > > > > > > http://goo.gl/it488V for more information. > > > > > > == > > > > > > > > > > > > Ing. Daniele Romagnoli > > > > > > Senior Software Engineer > > > > > > > > > > > > GeoSolutions S.A.S. > > > > > > Via di Montramito 3/A > > > > > > 55054 Massarosa (LU) > > > > > > Italy > > > > > > phone: +39 0584 962313 > > > > > > fax: +39 0584 1660272 > > > > > > > > > > > > http://www.geo-solutions.it > > > > > > http://twitter.com/geosolutions_it > > > > > > > > > > > > ------------------------------------------------------- > > > > > > > > > > > > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* > > > > > > > > > > > > Le informazioni contenute in questo messaggio di posta > > > > > > elettronica e/o nel/i file/s allegato/i sono da considerarsi > > > > > > strettamente riservate. Il loro utilizzo è consentito > > > > > > esclusivamente al destinatario del > > > > > > > > messaggio, > > > > > > > > > > per le finalità indicate nel messaggio stesso. Qualora riceviate > > > > > > questo messaggio senza esserne il destinatario, Vi preghiamo > > > > > > cortesemente di darcene notizia via e-mail e di procedere alla > > > > > > distruzione del > > > > > > > > messaggio > > > > > > > > > > stesso, cancellandolo dal Vostro sistema. Conservare il messaggio > > > > > > > > stesso, > > > > > > > > > > divulgarlo anche in parte, distribuirlo ad altri soggetti, > > > > copiarlo, > > > > > > > > od utilizzarlo per finalità diverse, costituisce comportamento > > > > > > contrario > > > > > > > > ai > > > > > > > > > > principi dettati dal D.Lgs. 196/2003. > > > > > > > > > > > > > > > > > > > > > > > > The information in this message and/or attachments, is intended > > > > > > solely for the attention and use of the named addressee(s) and > > > > > > may be confidential or proprietary in nature or covered by the > > > > > > provisions of privacy act (Legislative Decree June, 30 2003, > > > > > > no.196 - Italy's New > > > > > > > > Data > > > > > > > > > > Protection Code).Any use not in accord with its purpose, any > > > > > > > > disclosure, > > > > > > > > > > reproduction, copying, distribution, or either dissemination, > > > > either > > > > > > > > whole or partial, is strictly forbidden except previous formal > > > > > > approval of the named > > > > > > addressee(s). If you are not the intended recipient, please > > > > > > contact immediately the sender by telephone, fax or e-mail and > > > > > > delete the information in this message that has been received in > > > > > > error. The sender does not give any warranty or accept liability > > > > > > as the content, accuracy or completeness of sent messages and > > > > > > accepts no responsibility for changes made after they were sent > > > > > > or for other risks which arise as a result of e-mail > > > > > > transmission, viruses, etc. > > > > > > > > -- > > > > Spatialys - Geospatial professional services > > > > http://www.spatialys.com > > > > -- > > Spatialys - Geospatial professional services > > http://www.spatialys.com -- Spatialys - Geospatial professional services http://www.spatialys.com _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
