Re: [gdal-dev] SQL script for creating a test GeoPackage

Il 23/04/2015 20:24, Pepijn Van Eeckhoudt ha scritto: > Jukka, > > What I have is in the tool I wrote > ;) Not easy to copy/paste the SQL > though. Hi all, what a nice idea. Would you be so kind as to let the QGIS-dev list know when you have a tool ready? I

Re: [gdal-dev] SQL script for creating a test GeoPackage

Jukka, What I have is in the tool I wrote ;) Not easy to copy/paste the SQL though. Table definitions, required data and validation logic are in gpkg_db.c .

Re: [gdal-dev] SQL script for creating a test GeoPackage

Le jeudi 23 avril 2015 18:54:14, Jukka Rahkonen a écrit : > Hi, > > Inspired by this Spatialite forum thread > https://groups.google.com/d/msg/spatialite-users/rBKeuXLpQv8/THStsQdQXI0J I > started to write a SQL script that creates a GeoPackage database with all > the metadata tables, triggers etc

[gdal-dev] SQL script for creating a test GeoPackage

Hi, Inspired by this Spatialite forum thread https://groups.google.com/d/msg/spatialite-users/rBKeuXLpQv8/THStsQdQXI0J I started to write a SQL script that creates a GeoPackage database with all the metadata tables, triggers etc. and also data tables for every possible geometry type, each with one

Re: [gdal-dev] Processing huge DEM dataset

On Thu, Apr 23, 2015 at 02:36:35PM +0200, Even Rouault wrote: > Most gdaldem algorithms (except color-relief) need to compute some form of > gradient (a 3x3 window around the pixel being computed), so you have edge > effects. By default, they put a nodata value on the edges. > If you specify -com

[gdal-dev] Easier testing of drivers using HTTP APIs

Hi, This will be of interest mainly for GDAL driver developers of drivers using HTTP APIs. Writing autotests for such drivers isn't always easy, or reliable, since you have to connect to a server that may be temporarily unavailable (or definitely after some time), or there might be issues wit

Re: [gdal-dev] Processing huge DEM dataset

...or rasdaman, www.rasdaman.org. It allows to establish a single seamless map on which you can run algorithms in a high-level language. The system takes care of borders etc. Prefab VM is available on request (production not yet automated). my 2 cents, Peter On 04/23/15 15:03, Rémi Cura wrote: >

Re: [gdal-dev] Processing huge DEM dataset

Hey, gdal may not be the right tool for this. You may use Orfeo Tool Box (https://www.orfeo-toolbox.org/), which has been designed to process huge images with limited cpu and memory. Cheers, Rémi-C 2015-04-23 14:36 GMT+02:00 Even Rouault : > Le jeudi 23 avril 2015 14:22:30, Paul Ramsey a écrit

Re: [gdal-dev] Processing huge DEM dataset

Le jeudi 23 avril 2015 14:22:30, Paul Ramsey a écrit : > I have in the past, with other tool sets, not GDAL, approached this by > building out padded tiles as the first step. So for each tile, merge it > with it’s neighbors, then clip out the middle so you get a somewhat larger > tile. Give it a ni

Re: [gdal-dev] Processing huge DEM dataset

I have in the past, with other tool sets, not GDAL, approached this by building out padded tiles as the first step. So for each tile, merge it with it’s neighbors, then clip out the middle so you get a somewhat larger tile. Give it a nice thick buffer. Now all your tiles overlap. Process them a

[gdal-dev] Unable to read data correctly in gdal python

Hello, The gdalinfo.exe correctly shows the subdataset of a HDF4 file with dimension [180x8x32x9]. But the same subdataset read from gdal in python is only [180x8x32]. I was using the gdal binary from Christoph Gohlke in windows, and according to him, the GDAL binaries are built with HDF-4.2.1

[gdal-dev] Processing huge DEM dataset

I have SRTM's DEM 1x1 degree 30m resolution tiles for the whole Europe and I'm trying to generate several raster images based on that (elevation coloring, slopeshade and hillshade), but I'm not sure about the right approach to do it for that amount of data. The simplest approach is to