Re: [gdal-dev] Recommended OGR Driver For Very Large Vector Data

2018-08-03 Thread Even Rouault
> I still prefer and use that to deliver, over the heavier GPK format. Sizes of GeoPackage and Spatialite DBs should be very similar in most cases. They differ only by the geometry encoding, which in both cases is more or less a header + WKB or a variant of WKB. Spatialite DBs can be significant

Re: [gdal-dev] Recommended OGR Driver For Very Large Vector Data

2018-08-03 Thread Jeff McKenna
My next choice for customers (in cases of a hard file requirement) is always Spatialite (sqlite3 + libspatialite wrapped into a single file). I still prefer and use that to deliver, over the heavier GPK format. (again, everyone has their own preferences, I'm just sharing my 18+ years of MapServ

Re: [gdal-dev] Recommended OGR Driver For Very Large Vector Data

2018-08-03 Thread Patrick Young
Ah right of course! I should have said that we deliver these things to customers, so a file format is needed. We've have had good luck serving simplified versions of these things out of zipped shapefiles from S3 via mapserver so the thought was maybe the same trick would work with the right forma

Re: [gdal-dev] Recommended OGR Driver For Very Large Vector Data

2018-08-03 Thread Jeff McKenna
Hi Patrick, In terms of speed and MapServer, considering you have large vector data and require good indexing, I always use and recommend PostGIS. (of course if you asked this on the MapServer-users list you would get a whole lot of different opinions) But that is my initial recommendation,

[gdal-dev] Recommended OGR Driver For Very Large Vector Data

2018-08-03 Thread Patrick Young
Hi all, I've been trying to figure out a good format to store some very large vector data in. Basically, its a bunch of really dense polygons describing the cutlines that compose a mosaic. We've had reasonable success using zipped shapefiles, but on the larger guys we're exceeding the 2GB file s

Re: [gdal-dev] VRT of VRTs with overviews. They do not seem to be used.

2018-08-03 Thread Even Rouault
Christoph, gdaladdo always start from the full resolution layer (or the preceding overview in case of cascading overview), hence what you observe. And even if it did start from the nearest existing overview level, in your full scenario of a VRT of VRT, with each 'bottom-level' VRT having overvi

Re: [gdal-dev] Fwd: [Projects] OSGeo Annual General Meeting - projects please join and report (August 30 2018)

2018-08-03 Thread Jeff McKenna
Hi Even, I'll be there and don't mind helping. -jeff On 2018-08-02 5:24 PM, Even Rouault wrote: Hi, see below the request from the OSGeo board for a quick (2 minute) project update for GDAL. I won't be in Dar. Is there anyone from the community that will be there and willing to give this upd

[gdal-dev] VRT of VRTs with overviews. They do not seem to be used.

2018-08-03 Thread Christoph Paulik
Hi, I have a use case where I would like to update some parts of my dataset and not have to re-render all the overviews for all the other parts of the globe. My idea was to use 5x5 degree boxes for which I would create overviews of levels e.g. 2, 4, 8, 16. Then I would use a global VRT of these V

[gdal-dev] Recalculate pixel value based on stats

2018-08-03 Thread gis_wild
I want to recalculate pixel values of raster based on raster stats. In terms of gdal, I want to use gdal_calc together with gdal_stats. Is it possible to somehow pass an output of gdal_stats into gdal_calc? In particular, I need to recalculate pixel value based on standard deviation value -- Se

Re: [gdal-dev] Problem with CSV when using both SQLite dialect and -oo GEOM_POSSIBLE_NAMES

2018-08-03 Thread Even Rouault
On jeudi 2 août 2018 22:39:56 CEST Rahkonen Jukka (MML) wrote: > Hi, > > I can reproduce this > https://gis.stackexchange.com/questions/287767/ogrinfo-unable-to-use-sqlite > -dialect-with-oo-geom-possible-names-open-option with GDAL 2.4.0dev but I do > not undesrtand what happens. When doing -oo