Opened 13 years ago
Closed 8 years ago
#4062 closed enhancement (fixed)
Allow fillnodata on vrt: simply add new images for just the filled data
Reported by: | maphew | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Utilities | Version: | unspecified |
Severity: | normal | Keywords: | fillnodata |
Cc: |
Description
Please consider extending gdal_fillnodata.py so that it can operate on VRT images. I think this could be accomplished by the simple expedient of adding new file(s) to the table to hold the fill data, leaving the sources untouched.
Change History (8)
comment:1 by , 13 years ago
Summary: | Allow fillnodata on vrt → Allow fillnodata on vrt: simply add new images for just the filled data |
---|
comment:2 by , 13 years ago
comment:3 by , 13 years ago
I see two main options here.
One is to extend the VRT driver to create some sort of backing raster file which would get added to the virtual raster as the lowest level raster and would be used to write to areas for which there is no other file. Do we even support writing to VRTs? We didn't used to.
The other is to have gdal_fillnodata.py support writing the results to something other than the source file. But examination of gdal_fillnodata.py shows it already has a dstfile option to write to a new file so this seems unnecessary.
Overall I'm not convinced there is a compelling need here that couldn't be worked around other ways.
comment:4 by , 13 years ago
As far as I know vrt is still read only, at least running fillnodata on one yields ERROR 1: Writing through VRTSourcedRasterBand is not supported.
.
The problem with using the dstfile option, as it works now, is unnecessary duplication. For example in the use case which spawned this request my input rasters which I want to "heal" total 15gb, compressed. I'd be surprised if the fill areas total more than 1 or 200mb as the gaps are quite small, 2-3 pixels along adjoining sheets.
Why create a need for ~31gb of storage when the same could be accomplished in 16gb? I would think using a vrt would also be much faster, though that's just speculation.
I suppose we could run fillnodata on the vrt with an output file and then do something like where input.vrt == nodata, erase filled.tif
, or is that even possible with the gdal utilities?
comment:5 by , 13 years ago
sorry, that should be WHERE input.vrt NOT-EQUAL nodata, ERASE filled.tif
comment:6 by , 13 years ago
A simulated result of a gdal fillnodata --use-vrt operation: http://min.us/mvkAgXO
comment:7 by , 9 years ago
I must say that I do not totally understand this ticket especially because the annex file has disappeared from min.us. However, I have a feeling that the desired result can be achieved nowadays by using gdalbuildvrt utility http://www.gdal.org/gdalbuildvrt.html by playing with the -addalpha, -hidenodata and -vrtnodata parameters.
comment:8 by , 8 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Idea of using physical nodata files and include them in the VRT feels so hackish that I would rather close the ticket. I also still have a feeling that the case can be handled with -addalpha, -hidenodata, and -vrtnodata. Therefore closing as Fixed.
A more generic and versatile aproach might be to add a
--read-only
or--use-vrt
switch, which would have the effect of always putting the fill data in a separate image and leave the originals untouched. This would allow it to be used on all image formats.will result in
Conceivably this would also allow for multiple image inputs. I'm not sure if that makes sense, but it could be explored.