[Gdal-dev] Merging Dems

Ray Gardener rayg at daylongraphics.com
Tue Jun 20 18:26:37 EDT 2006


That's actually a common problem in sampling algorithms. LucasFilm, 
e.g., supports overpadded images in OpenEXR to let digital filters use 
their kernels without having to subtract kernel pixels outside the image 
(letting them run faster; less conditional logic, less branch 
misprediction stalls). If GDAL's sampler isn't taking edges into account 
properly, an option would be to prepad the DEM with repeated edge pixels 
and then crop it afterwards.

That won't solve void pixels inside the DEM (holes), and if those are a 
problem, the sampler process has to be adjusted.

Ray


Chris Pennock wrote:
> Hi all,
> 
> Merging dems seems like a common task, but I
> cannot find a way to do it well using gdal. Is there a
> best practice I should be aware of?
> 
> I realize that there will always be gaps between dems,
> which must be fixed afterward (thanks Craig and Ben),
> but what is the best way to merge the dems together,
> with "clean" NODATA edges, so that the gaps can
> be filled?
> 
> The problem I run into is that warping with "-rcs" for
> cubic spline resampling, which looks best, leaves the
> edges of the dem "rounded off". E.g. if the data
> should be:
> 
> 1000, 1000, 1000, NODATA, NODATA
> 
> I get instead:
> 
> 1000, 1000, -400, -5000, NODATA
> 
> And so I don't have clean cut offs from data to
> NODATA, which makes gap filling challenging.
> 
> 
> 
> Any help would be much appreciated.
> 
> Thanks,
> Chris
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/gdal-dev
> 
> 



More information about the Gdal-dev mailing list