Opened 8 years ago

Closed 3 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 Changed 8 years ago by maphew

Summary: Allow fillnodata on vrtAllow fillnodata on vrt: simply add new images for just the filled data

comment:2 Changed 8 years ago by maphew

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.

gdal_fillnodata --use-vrt has-gaps.tif

will result in

has-gaps.tif         #original untouched image
has-gaps_filled.tif  #fills in gap areas, nodata everywhere else

has-gaps.vrt         # virtual mosaic composite
   \--- has-gaps_filled.tif
   \--- has-gaps.tif

Conceivably this would also allow for multiple image inputs. I'm not sure if that makes sense, but it could be explored.

comment:3 Changed 8 years ago by warmerdam

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 Changed 8 years ago by maphew

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 Changed 8 years ago by maphew

sorry, that should be WHERE input.vrt NOT-EQUAL nodata, ERASE filled.tif

comment:6 Changed 8 years ago by maphew

A simulated result of a gdal fillnodata --use-vrt operation: http://min.us/mvkAgXO

comment:7 Changed 4 years ago by Jukka Rahkonen

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 Changed 3 years ago by Jukka Rahkonen

Resolution: fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.