Re: [gdal-dev] Creating Cloud Optimized GeoTIFFs

2018-12-17 Thread Even Rouault
> I have run some initial tests on an untiled/uncompressed image basically > skipping step 1 and going straight to adding overviews and translating to > reorder, compress, and tile. The resulting image passes the COG validator > test, meaning it is a "valid" COG, though the overview offset values a

Re: [gdal-dev] Creating Cloud Optimized GeoTIFFs

2018-12-17 Thread anash
Hi Even, I have seen pretty much everywhere that COG's are created in 3 steps: 1. compress and tile the image $ gdal_translate -co TILED=YES -co COMPRESS=DEFLATE in.tif tmp.tif 2. add overviews $ gdaladdo -r average 2 4 8 16 tmp.tif 3. reorder overviews $ gdal_translate -co TILED=YES -co COM

Re: [gdal-dev] Piping ogr2ogr (SHP format) /vsistdout/ to unix command

2018-12-17 Thread Even Rouault
On lundi 17 décembre 2018 16:00:30 CET umbertofilippo wrote: > I hope my poor knowledge of informatics terminology won't prevent me to > explain properly, but I try to make my best. > I am trying to use ogr2ogr to convert the GML response from a WFS GetFeature > request to a zipped Shapefile. > Is

[gdal-dev] Zonal Grid Statistics

2018-12-17 Thread Nicolas Cadieux
Hi, I am currently using the SAGA Zonal Grid Statistics found here: http://www.saga-gis.org/saga_tool_doc/7.0.0/statistics_grid_5.html (both Zonal and Continuous Data are Rasters with the same extent and pixel posting). It works well but SAGA load both grids into memory.  Since my grids are t

[gdal-dev] Piping ogr2ogr (SHP format) /vsistdout/ to unix command

2018-12-17 Thread umbertofilippo
I hope my poor knowledge of informatics terminology won't prevent me to explain properly, but I try to make my best. I am trying to use ogr2ogr to convert the GML response from a WFS GetFeature request to a zipped Shapefile. I am able to convert the GML to Shapefile, but what I'd like to do now is

Re: [gdal-dev] Support for reading IFC files?

2018-12-17 Thread Even Rouault
Magnus, I believe that could be an interesting evolution. How that would be done exactly (e.g. leveraging IfcOpenShell) remains to be defined. And also find an available developer + appropriate funding to make that happen. Even > Hi > Over at > http://osgeo-org.1560.x6.nabble.com/QGIS-Develope

Re: [gdal-dev] gdalwarp cutline shift between raster and vector in GDAL 2.3.2

2018-12-17 Thread Pedro Venâncio
Hi Even, What version of PROJ does your GDAL 2.3.2 build use ? PROJ 5 ? > And your GDAL 2.2.2 build: PROJ 4 ? > GDAL 2.3.2 uses PROJ 5.2.0. GDAL 2.2.3 uses PROJ.4 version 493 GDAL 2.2.2 uses PROJ.4 version 480 > If so, that might explain things. The ESRI:102164 translated as a proj > string >

Re: [gdal-dev] gdalwarp cutline shift between raster and vector in GDAL 2.3.2

2018-12-17 Thread Even Rouault
On lundi 17 décembre 2018 14:25:02 CET Pedro Venâncio wrote: > Hi Andre, > > Given the magnitude of the shift, I suspected that could be due to the lack > of +towgs84 parameters of ESRI 102164. What version of PROJ does your GDAL 2.3.2 build use ? PROJ 5 ? And your GDAL 2.2.2 build: PROJ 4 ? If

Re: [gdal-dev] gdalwarp cutline shift between raster and vector in GDAL 2.3.2

2018-12-17 Thread Pedro Venâncio
Hi Andre, Given the magnitude of the shift, I suspected that could be due to the lack of +towgs84 parameters of ESRI 102164. But I does not understand why it worked correctly in GDAL 2.2.2. Now I see that C:\>gdalinfo --version GDAL 2.3.2, released 2018/09/21 C:\>gdalsrsinfo EPSG:102164 PROJ.4

Re: [gdal-dev] gdalwarp cutline shift between raster and vector in GDAL 2.3.2

2018-12-17 Thread Andre Joost
Hi Pedro, if you compare gdalsrsinfo epsg:20790 and gdalsrsinfo EPSG:102164 from ESRI, you see that ESRI omits the datum shift between Lisbon Hayford and WGS84. So you should use -s_srs EPSG:20790 to get the warping correctly. HTH, Andre Joost Am 17.12.18 um 11:09 schrieb Pedro Venâncio: H

[gdal-dev] gdalwarp cutline shift between raster and vector in GDAL 2.3.2

2018-12-17 Thread Pedro Venâncio
Hi, I'm getting an error when clipping a raster by a mask layer, in GDAL 2.3.2. This beaviour does not happen in GDAL 2.2.2. To be more specific, in a Windows machine with GDAL 2.3.2, the clip is done, but the image is clipped about 200 meters away from the correct bounding box of the vector lay