Grab a copy of the ogr2ogr Python port, which is distributed with the GDAL source code download or can be found here: http://svn.osgeo.org/gdal/trunk/gdal/swig/python/samples/ogr2ogr.py
Once you import that into your code, you can use it like this:
#note: main is expecting sys.argv, where the first argument is the script name
On Windows, for the current and sub-directories under the current, try this command:
for /R %f in (*.shp) do ogr2ogr -f "MapInfo File" "%~dpnf.tab" "%f"
To briefly explain the trickery of what is going on here, %~dpnf.tab uses the variable %f, with which it adds the driver letter, path name (i.e., folder or directory), and extracts the file name (without ...
You have to force the SHP geometry type (because the geometry type of GeoJSON Geometry Collection is not supported in SHPs) and use the -skipfailures option:
ogr2ogr -nlt POINT -skipfailures points.shp geojsonfile.json OGRGeoJSON
ogr2ogr -nlt LINESTRING -skipfailures linestrings.shp geojsonfile.json OGRGeoJSON
ogr2ogr -nlt POLYGON -skipfailures polygons....
You miss a minus sign before where and the select is not necessary, so it should be:
ogr2ogr -where ID="1" outfile.shp infile.shp
or if you have to do more complex query on your input data:
ogr2ogr -sql "SELECT * FROM infile WHERE ID='1'" outfile.shp infile.shp
If ID is a field of Integer type, substitute ID='1' with ID=1.
-f "ESRI Shapefile" is ...
Using Homebrew you should:
brew install gdal --with-postgresql
or with older versions of gdal:
brew install gdal --with-postgres
if you have already installed gdal with brew before but without postgresql support, just
brew uninstall gdal
Try adding appropriate host and port arguments.
And BTW, when I import a large GDB file, I also add these flags:
-overwrite (erases any mess you may have already inserted) and
-progress (displays a dot or number for every 10,000 or 10% records added):
--config PG_USE_COPY YES (greatly improves speed)
So the command (which should be a one-liner but i ...
Figured it out by reading the OGR SQL documentation at http://www.gdal.org/ogr/ogr_sql.html
This works, using one command and one output file per geometry type:
$ ogr2ogr -where "OGR_GEOMETRY='Point'" -f "ESRI Shapefile" transit_points.shp transit.kml
$ ogr2ogr -where "OGR_GEOMETRY='LineString'" -f "ESRI Shapefile" transit_linestrings.shp transit.kml
you can use ST_GeomFromKML as this page.
or you can use ogr2ogr as following to process entire KML files;
ogr2ogr -f "PostgreSQL" PG:"host=yourhost user=youruser dbname=...
Assuming you want to reproject a shapefile, one way within QGIS is to load the file, right-click on the layer, select Save As…, and then the following window appears:
If you click browse beside CRS you can choose a new projection to save your file in.
To reproject all shapfiles in the one folder, something like this could work:
ogrinfo -so -al yourshapefile.shp
This will give you geometry type, number of features/shapes, bounding box corners, projection information, and the name of each attribute file as well as the datatype stored in those attributes.
For GDAL there are datastores which contain layers. Some datastores, like the database ones or GML, can hold several layers but some others like shapefiles can only contain one layer.
You can test with for example GeoPackage driver what happens if you do not use the -nln switch with a datastore that can contain many layers.
ogr2ogr -f gpkg merged.gpkg a....
OGR has its own idiom for stdin, /vsistdin/. Use that as ogr2ogr's first argument (the dst_datasource_name) and you can pipe curl's output to it:
curl "https://raw.githubusercontent.com/nvkelso/natural-earth-vector/master/geojson/ne_50m_admin_0_countries.geojson" | ogr2ogr -f "KML" countries.kml /vsistdin/
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 ...
Use the -nlt option. In this case you want:
There is also PROMOTE_TO_MULTI (GDAL 1.10 and later), which chooses either MULTILINESTRING or MULTIPOLYGON depending on the input layer. The use case for this is "doing a mass conversion of shapefiles that [mix] different types of geometries".
With small scripting it would be doable. With something like following you should be able to add column to a shapefile in all shapefiles in a folder, and merge them to merged.shp file
for %f in (*.shp) do (
ogrinfo %f -sql "ALTER TABLE %f ADD COLUMN filename character(15)"
ogrinfo %f -sql "UPDATE TABLE %f filename = '%f'"
ogr2ogr -update -append ...
There is, yes, using a combination of row_to_json, array_to_json, array_agg and ST_AsGeoJSON. I realize, on rereading your question, that you asked for ogr2ogr approach, but seeing as your source is Postgis, I thought you might appreciate a pure Postgres/Postgis approach. I have used this approach with Google Maps, so it works well if you need to create ...
SpatialLite has no way of converting multi-geometries to single-parts itself. There are some 'CastTo' functions but they are for special cases (where your multigeometry contains a single geometry - it won't fan-out). I have seen a reference to a function in the SpatialLite GUI but never found it (perhaps you need to compile from the latest source code. I'...
To answer my own question on how to combine both the .dbx (properties) and the .shp (geometries) into a single JSON file:
The problem I did not see is that all file names must be lower case to enable ogr2ogr to do the conversion. That should not be neccessary if your file system is case-insensitive but mine is. With this requirements fulfilled ogr2ogr is ...
You are looking for the -progress switch
ogr2ogr -progress ...
You can see the other options by doing ogr2ogr --help
Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update]
[-select field_list] [-where restricted_where]
[-progress] [-sql <sql statement>] [-dialect dialect]
According to the ogr2ogr csv documentation and also this answer, you need to specify which fields contain the geometry in a VRT file:
In https://gis.stackexchange.com/questions/158457/gdal2tiles-how-to-make-filenames-of-tiles-to-represent-xyz-coordinates, somebody mentions doing:
sudo ln -s /usr/lib/libproj.so.0 /usr/lib/libproj.so
Which absolutely fixed the same error (ERROR 6: Unable to load PROJ.4 library (libproj.so)) for me.
On the x86_64 architecture you may need to use this ...
For unix bash:
for FILE in *.mif # cycles through all files in directory (case-sensitive!)
echo "converting file: $FILE..."
FILENEW=`echo $FILE | sed "s/.mif/_new.shp/"` # replaces old filename
-f "ESRI Shapefile" \
If you're working in a *nix-based OS (ie Linux or OS X), there are ...
Using GDAL >= 1.10.0 and its OGR Virtual Format, we can write a VRT file named, for example, merge.vrt (see Example: Union layer (GDAL >= 1.10.0)):
So this python script will take a json input file as detailed above and write properly formatted geojson to the output file.
run the script in terminal by doing python scriptname.py input_file.json output_file.json
#! usr/bin/env python
from sys import argv
from os.path import exists
import simplejson as json
script, in_file, out_file = argv
data = ...
As 102100 and 3857 are mathematically identical, I think you can safely ignore the errors and just continue with overriding the source srs using the -s_srs flag.
You can try adding the definition for 102100 in your $GDAL_DATA$ but it's not really recommended. If you really want to do it though, here's the method and the accompanying warning from Frank ...