Paul,<br>
<br>
I cannot much much regarding the first question. Since the data is
large you have to find out the reason for segfault yourselves. Try
running it with gdb as "gdb --args python gdal_fillnodata.py ..." and
examine the call stack after the segfault with the command "bt" in the
gdb console.<br>
<br>
For the second question, you could create a vrt file mentioning 32767
as the source's NODATA and -32767 as vrt's NoDataValue. The vrt driver translates the pixels with value 32767 to -32767. Refer to
<a href="http://www.gdal.org/gdalbuildvrt.html">http://www.gdal.org/gdalbuildvrt.html</a> and/or
<a href="http://www.gdal.org/gdal_vrttut.html">http://www.gdal.org/gdal_vrttut.html</a> for more details. This method is not good if you have more than a few nodata values.<br><br><br><div class="gmail_quote">On Wed, Apr 7, 2010 at 1:24 AM, Paul Delamater <span dir="ltr"><<a href="mailto:pauldelamater@gmail.com">pauldelamater@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">A couple of questions...<br><br>1. I'm getting a Segmentation Fault when using gdal_fillnodata.py on an .img file that I created in GDAL. I'm running GDAL 1.7.1 on Ubuntu 9.10 (64bit). The file is big (1.2Gb).<br>
<br>Here's my command:<br>$ gdal_fillnodata.py -md 1 zone10_albers.img -nomask zone10_test.img -of HFA<br><br>I get to about 50% done in the progress bar, then Segmenation Fault. However, the process outputs 4 files:: zone10_test.img, 3172751088_0fill_filtmask_work.tif, 3172751088_0fill_val_work.tif, 3172751088_0fill_y_work.tif. Unfortunately, the .img output doesn't have any info in it.<br>
<br>$ gdalinfo zone10_test.img<br>Driver: HFA/Erdas Imagine Images (.img)<br>Files: zone10_test.img<br>Size is 16000, 40667<br>Coordinate System is `'<br>Corner Coordinates:<br>Upper Left ( 0.0, 0.0)<br>Lower Left ( 0.0,40667.0)<br>
Upper Right (16000.0, 0.0)<br>Lower Right (16000.0,40667.0)<br>Center ( 8000.0,20333.5)<br>Band 1 Block=64x64 Type=Int16, ColorInterp=Undefined<br> Description = Layer_1<br> Metadata:<br> LAYER_TYPE=athematic<br>
<br>Any ideas on what could be causing this? My other gdal.py commands work without problem. Because I was curious, I had a terminal window running 'top' to see what kind of system resources the process was using and I didn't see anything that would lead me to believe it was a memory problem.<br>
<br>2. Is there any method available to set multiple values to NoData? I have about 6000 USGS DEMs and some (randomly) have a few pixels on their edge with values of 32767 and -32767 (NoData pixels are supposed to be -32766). Can I give multiple values when using the nodata flag in gdalmerge or gdalwarp?<br>
<br>Thanks much, -Paul Delamater<br><br>
<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>Best regards,<br>Chaitanya kumar CH.<br>
/tʃaɪθənjə/ /kʊmɑr/ <br>+91-9848167848<br>17.2416N 80.1426E<br>