New answers tagged ogr2ogr
As you discovered by trial and error, there were few nagging issues you needed to fix, the last of which was resolved using ogr2ogr's -nlt GEOMETRY* argument. * Note the recommendation in @LeeHachadoorian's comment that -nlt PROMOTE_TO_MULTI be used as a default solution, rather than nlt GEOMETRY, as the former promotes best practice in addition to ...
This is quite a nasty problem and hard to resolve without experience on different ways to store geodata into SQLite database. The problem is not in the output format but in the input format. The natural_earth_vector.sqlite database is written as FDO. Read more info from the "Regular" SQLite databases" section in the GDAL SQLite driver manual page ...
So the answer seems to be; it's not possible. ogr2ogr does not pick up on xlinks in GML files. My solution was to use Safe FME to load the data instead.
You're looking for the symmetrical difference tool. In my experience it works very similarly to st_disjoint, only it does it in a "masking" style so the underlying shape can be cut out just so. I struggled with this tool for a while, getting empty outputs, before I discovered a workable solution. Both of my layers were in geographic (EPSG:4326) format ...
use --with-static-proj when compiling gdal libraries.
I found a solution to my problem: Running a batch that temporarily sets the PATH variable to the GDAL-package and afterwards running a second batch that sets the rest of the variables needed by ogr2ogr and runs the ogr2ogr commands you need. The first batch looks like this: rem In this case the gdal package is located in C: setx PATH "C:\gdal;%PATH%" ...
Turns out it was an error due to the number of requests I was making to the API. I implemented exponential backoff in my script, and am no longer experiencing the error.
I would take OGR (ogr2ogr) and set the layer creation option COLUMN_TYPES: -lco COLUMN_TYPES field1=INTEGER,field1=FLOAT8. That's another layer creation option as Mike T suggested above. In general, I would consider switching to GeoPackage since Shapefiles are deprecated and have deficiencies like field names limited to 10 chars.
The number width/precision is specified in the DBF file, as support by GDAL/OGR with get/set width/precision (i.e. see API). Looking at the documentation for the PostgreSQL / PostGIS driver, there is a PRECISION layer creation option: This may be "YES" to force new fields created on this layer to try and represent the width and precision information, if ...
For the second point you can use the Information_schema and select the needed columns. "SELECT column_name, data_type FROM information_schema.columns" and use this information in a loop with an ALTER TABLE statement together with SET DATA TYPE to change the types. This of course needs to be inside a loop for all tables which you also get from ...
Top 50 recent answers are included