[gdal-dev] Preserve Source Raster Resolution When Merging

[Jamie Adams]

Hi Sam,

If your gdal build has Rasterlite support, you can use that to store
multiple rasters at their native resolution.  For each raster do something
like this, where table is a unique name for each raster.  I used the file
name for table, but it can be anything.

gdal_translate -of Rasterlite raster1.tif RASTERLITE:testdb.sqlite,
table=raster.tif

The problem is on the viewing end.  QGIS prompts you select layers when you
open the sqlite db.  You can select them all, but they come in as
individual rasters. And afaict there isn't a way to enforce layer order.

Cheers,

Jamie

On Wed, Aug 24, 2016 at 2:38 PM, Sam Wilson <sam at surfline.com> wrote:

> Hi,
>
> I’m attempting to merge (or maybe the proper term is mosaic) overlapping
> raster datasets of varying resolutions. I’d like to have the higher
> resolution datasets override the lower resolution datasets where available.
>
> I’ve been able to get close using various methods i.e. gdal_merge.py or by
> constructing a VRT using gdalbuildvrt and providing the input file list.
>
> However, both of those methods don’t seem to be ideal, unless I’m
> mistaken, because I’d prefer to preserve the native resolution of all
> datasets being merged.
>
> For example, when using gdal_merge, you can provide a single pixel size,
> which I think makes the entire merged raster at that resolution. Thus, I
> end up gaining resolution where I don’t want it and losing resolution where
> I do want it. The same goes using the gdalbuildvrt method using the
> -resolution argument.
>
> The end goal is to have a single raster containing all the input rasters
> at their native resolutions.  I’ve done a lot of searching around online
> and it appears that this can be achieved using ArcGIS tools.  However, I’m
> wondering if there are any workarounds to achieve that other than using
> ArcGIS.  For example, is their a modified version of gdal_merge.py that
> keeps the source rasters at their native resolutions when merging?
>
> Thanks for any help!
>
> Cheers,
> Sam
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160825/efc9d48b/attachment.html>