[gdal-dev] geojson to shp and vice versa

Dear all, I have a headache inducing problem. Whenever I try to convert a GeoJSON feature collection which contains multiple different geometry shapes (i.e. polygon, linestring and point) I get this type of error: "ERROR 1: Attempt to write non-polygon (LINESTRING) geometry to POLYGON type shape

Re: [gdal-dev] ERROR: Too many connections: max 64

Or is it better to do the processing on shapefiles? Le gach dea ghui, *Shane Carey* *GIS and Data Solutions Consultant* On Thu, Nov 28, 2019 at 8:40 PM Shane Carey wrote: > After processing, is there a way to release the wal and shm files? I'm on > qgis3.4. > Thanks Even > Le gach dea ghui, > *

Re: [gdal-dev] ERROR: Too many connections: max 64

After processing, is there a way to release the wal and shm files? I'm on qgis3.4. Thanks Even Le gach dea ghui, *Shane Carey* *GIS and Data Solutions Consultant* On Thu, Nov 28, 2019 at 8:37 PM Even Rouault wrote: > On jeudi 28 novembre 2019 20:19:10 CET Shane Carey wrote: > > Hi, > > > > I'm

Re: [gdal-dev] ERROR: Too many connections: max 64

On jeudi 28 novembre 2019 20:19:10 CET Shane Carey wrote: > Hi, > > I'm doing some processing with Pyqgis and after processing, the file > remains locked and eventually I get: > ERROR: Too many connections: max 64 All I can say is that this error messages comes from Spatialite that can only hand

Re: [gdal-dev] GDAL 3 + PROJ 6 performance issue in CENTOS

Again Even you are my hero, ``` $ sqlite3 --version 3.7.17 2013-05-20 00:56:22 118a3b35693b134d56ebd780123b7fd6f1497668 ``` Will try to update and see how it goes, Thanks a lot > Le 28 nov. 2019 à 15:34, Even Rouault a écrit : > >> The full discovery can be seen in >> https://github.com/Remo

Re: [gdal-dev] GDAL 3 + PROJ 6 performance issue in CENTOS

> The full discovery can be seen in > https://github.com/RemotePixel/amazonlinux/issues/10 > and > https://github.com/RemotePixel/amazonlinux/issues/16 > . > The dockerfile can be found h

[gdal-dev] GDAL 3 + PROJ 6 performance issue in CENTOS

Dear community, I hope some of you might be of help here. For weeks I’ve been trying to build CENTOS docker image (for AWS Lambda) for GDAL 3 + PROJ 6 but I stumbled into a strange behavior making my processes a couple time slower than with gdal 2. I’m using those images for dynamic tiling (war

[gdal-dev] ERROR: Too many connections: max 64

Hi, I'm doing some processing with Pyqgis and after processing, the file remains locked and eventually I get: ERROR: Too many connections: max 64 How do I handle this? Thanks Le gach dea ghui, *Shane Carey* *GIS and Data Solutions Consultant* ___ gdal-

Re: [gdal-dev] ogr2ogr (I)LIKE not caseINsensitive

Hi Even, I'll upgrade to get rid of the error. Thanks again. Jan On Thu, Nov 28, 2019 at 5:49 PM Even Rouault wrote: > On jeudi 28 novembre 2019 17:40:34 CET Jan Heckman wrote: > > That's > > ogr2ogr plangebieden.shp -t_srs EPSG:28992 -dim 2 -spat 45000 405000 > 14 > > 485000 WFS:"http://af

Re: [gdal-dev] ogr2ogr (I)LIKE not caseINsensitive

On jeudi 28 novembre 2019 17:40:34 CET Jan Heckman wrote: > That's > ogr2ogr plangebieden.shp -t_srs EPSG:28992 -dim 2 -spat 45000 405000 14 > 485000 WFS:"http://afnemers.ruimtelijkeplannen.nl/afnemers2012/services"; > Bestemmingsplangebied -lco ENCODING=UTF-8 -where > "BeleidsmatigVerantwoorde

Re: [gdal-dev] ogr2ogr (I)LIKE not caseINsensitive

That's ogr2ogr plangebieden.shp -t_srs EPSG:28992 -dim 2 -spat 45000 405000 14 485000 WFS:"http://afnemers.ruimtelijkeplannen.nl/afnemers2012/services"; Bestemmingsplangebied -lco ENCODING=UTF-8 -where "BeleidsmatigVerantwoordelijkeOverheid LIKE '_eme%' AND planstatus NOT LIKE 'voor%' AND plans

Re: [gdal-dev] ogr2ogr (I)LIKE not caseINsensitive

On jeudi 28 novembre 2019 16:42:19 CET Jan Heckman wrote: > Hi Even, all, > Thanks for the fast and helpful response! > So, if I need this shortly, I should compile a slightly modified version? > I can't see myself giving a true solution to the backward compatibility > issue ;) > My problem here is

Re: [gdal-dev] ogr2ogr (I)LIKE not caseINsensitive

Hi Even, all, Thanks for the fast and helpful response! So, if I need this shortly, I should compile a slightly modified version? I can't see myself giving a true solution to the backward compatibility issue ;) My problem here is not large. The main advantage of caseinsensitive is a compact and acc

Re: [gdal-dev] ogr2ogr (I)LIKE not caseINsensitive

On jeudi 28 novembre 2019 16:09:28 CET Jan Heckman wrote: > Hi everybody, > According to docs , LIKE and > ILIKE should be caseinsensitive. > However, they are not. > ogr2ogr plangebieden.shp -t_srs EPSG:28992 -dim 2 -spat 45000 405000 14 > 485000 WFS

[gdal-dev] ogr2ogr (I)LIKE not caseINsensitive

Hi everybody, According to docs , LIKE and ILIKE should be caseinsensitive. However, they are not. ogr2ogr plangebieden.shp -t_srs EPSG:28992 -dim 2 -spat 45000 405000 14 485000 WFS:"http://afnemers.ruimtelijkeplannen.nl/afnemers2012/services"; Bestem