New answers tagged ogr2ogr
GDAL supports two SQL dialects: the default OGR dialect and an alternative SQLite (Spatialite) dialect. Both dialect support selecting geometries by geometry type. Ogrinfo tool is recommended for experiments because by using it the possible troubles with writing the result out can be avoided. If output from ogrinfo is good then the reading side is OK too. ...
If you have GDAL/OGR 1.10 or later, use -dialect SQLITE for the SQLite SQL dialect, which supports ORDER BY POP_MAX DESC LIMIT 30 in SQL statements.
The default OGR SQL engine does not support LIMIT. Try switching to the SQLite dialect, which is done by adding the argument -dialect SQLITE ie. ogr2ogr -f GeoJSON -sql "SELECT * FROM ne_10m_populated_places WHERE ADM0NAME = 'India' ORDER BY POP_MAX DESC LIMIT 1,30" -dialect SQLITE places.tmp.geo.json ne_10m_populated_places.shp
'Limit' is not implemented with OGR2OGR . However, you can add and calculate a field with an integer on your 30 biggest places and filter on your new field. this works : ogr2ogr -f GeoJSON -sql "SELECT * FROM ne_10m_populated_places WHERE ADM0NAME = 'India' ORDER BY POP_MAX" places.tmp.geo.json ne_10m_populated_places.shp with your new field : ogr2ogr ...
Just install GDAL and run it from Bash / terminal. ogr2ogr -f "ESRI Shapefile" mydata.shp PG:"host=myhost user=myloginname dbname=mydbname password=mypassword" "mytable" Or do not even bother with GDAL and just use something like below in terminal. # pgsql2shp -f myfile -p 5555 my_db roads_table
It looks like you're expecting to convert data in Sydney.shp to Sydney2.shp with a different SRS. However that isn't what you're doing. Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update] [-select field_list] [-where restricted_where] [-progress] [-sql <sql statement>] [-dialect dialect] ...
You can use URLs as paths to OGR data sources, so you don't need curl or pipes. ogr2ogr -f KML countries.kml https://raw.githubusercontent.com/nvkelso/natural-earth-vector/master/geojson/ne_50m_admin_0_countries.geojson
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/
You can by using GDAL following this discussion on GDAL-dev mailing list. As stated in the mentioned topic, you need GDAL compiled with Spatialite support. An alternative is already provided on the forum at TopoJSON level by @mbostock
I was having the same (or similar) issue with simply reading from a database. I noticed as well that a non-spatial table was being added to the SDO_GEOM_METADATA table. To resolve it, I removed the table name from the OCI connection string. Since I had the two tables (joining a non-spatial to the spatial for the query) in the SQL, it still worked and I no ...
You do not need any reverse engineering. ogr2ogr is able to read the projection information from prj file for you. Just execute: ogr2ogr -t_srs EPSG:4326 -f geoJSON -lco COORDINATE_PRECISION=7 future.geojson your_shapefile.shp
Off the top of my head, I don't think that you will get a line string or polgon string of x and y values in csv. I believe that you will only receive point values if you pick csv. You will have a column for x and a column for y. The gdal libraries that read shapefiles treat the three files as one animal. These libraries already do all the work of ...
All of the vector formats supported by GDAL/OGR are listed here. With each driver, check out the creation options to control the output. These are passed to ogr2ogr using -dco and -lco flags. Good text-based output drivers include: CSV - be sure to use -lco GEOMETRY=AS_WKT to get the well-known text geometry GeoJSON GML KML LIBKML.
What you are looking for is Geographic Markup Language (GML). It is human readable and should maintain everything. -f gml in gdal / ogr. Do not overlook KML either. Both are human readable vector OGC standards supported in gdal / ogr. You can open both in text editors.
[Edited] If your feature classes are saved as *.shp, you could try: ogr2ogr -f "FileGDB" mygdb.gdb ~/PathTo/MyFeatureClass.shp -lco FEATURE_DATASET=my_features However, since you are exporting from PostGIS another approach could be something like this: ogr2ogr -f "FileGDB" mygdb.gdb PG:"host=my_host user=my_user_name dbname=my_db_name ...
Ok. I finally got the drawing of the lines direction arrows by a little bit of trigonometry in the PostgreSQL(PostGIS) Query that generates the geometries for the ogr2ogr command to export it to the DXF file. The arrow triangle I get is not perfect, it has the tail a little bit moved but it will be enough for my needs. First I get all the points of the ...
Top 50 recent answers are included