New answers tagged

1

I made a test with OSGeo4W version of GDAL gdalinfo --version GDAL 2.0.2, released 2016/01/26 I created a test point in OpenJUMP JML format with one decimal attribute. <?xml version='1.0' encoding='UTF-8'?> <JCSDataFile xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance" > ...


4

There is a configuration switch for this in GDAL 2.1 onwards: http://www.gdal.org/drv_geojson.html It defaults to 16 decimal places. So upgrading to GDAL 2.1 should solve your issue. If not you can try a higher number of decimal for floating point numbers: -lco SIGNIFICANT_FIGURES=17


2

ogr2ogr/ogrinfo are great tools...but also...PostgreSQL provides two built-in tools for exporting (pgsql2shp) and loading (shp2pgsql) shapefiles. They are easy to use and well documented...see the docs and this cheat sheet. Quoting the PostGIS 2.0 docs: An example session using the loader to create an input file and uploading it might look like this: ...


3

YES The -spat switch is completely optional, and the typical use case is probably not to use it. I never use it, because when doing a shapefile import I have never needed only part of the shapefile (or I would rather get it all into PostGIS and then do a spatial selection there). ogr2ogr will run and import all features in the shapefile. Your statement ...


1

I eventually gave up trying to load the large files - it does not seem to be possible with any tool. The other side of the coin was that the features I did manage to load took over 1 hr to do a simple STIntersects query. Solution: I cut up the large shapefiles using ogr2ogr based on county geometries and then uploaded them and associated them with the ...


2

Cygwin might have altered your system PATH variable. You might have to re-install OSGEO4W afterwards. Alternatively, you can use the Gisinternal builds of GDAL, or the shell provided by the QGIS standalone installer. Or install to a different folder.


1

Mapbox's togeojson converter handles this very nicely. It flattens the contents of all layers/folders into sibling features. A bonus: unlike the accepted answer using ogr2ogr to extract each layer/folder, togeojson preserves features in the top-level, and not in any directory. Since it's JavaScript, it can run in your browser at ...


1

You need a Layer attribute in your input into ogr2ogr for it to convert into layers in CAD. I wrote a post about this for a straightforward GML to DXF conversion, using an intermediate step of ShapeFile because or geometry issues with the outputs: http://gisforthought.com/gis-to-cad-using-ogr2ogr-part-2-gml-to-dxf-with-os-mastermap/ But it works just as ...


0

I was able to use the '-nlt linestring' to export a line feature class successfully. The error appears to have been embedded in the sql statement. I was joining two tables and a view. The view was originally written using the 'myview.*'. I changed the SQL so that added each variable individually. This seemed to work. table1.var1, table2.var2, ...


1

Ok, this turned out to be as simple as text search and replace: <Polygon><outerBoundaryIs><LinearRing> to <LineString> and </Polygon></outerBoundaryIs></LinearRing> to </LineString>


0

Try this Oracle environment variable: NLS_LANG=AMERICAN_AMERICA.UTF8


1

I think you may have the ogr2ogr syntax wrong. The last line suggests that ogr2ogr didn't expect that type of argument. I'm using GDAL 2.1.0dev, and this works for me: ogr2ogr --config CARTODB_API_KEY XXXX -f CartoDB CartoDB:wri-02 myfile.shp I think you just need to remove the quotes around the "CartoDB:Development", provided that your account is really ...


2

The shapefile's .prj file does not contain the datum shift parameters from Amersfoort to WGS84, because the ESRI world handles datum shifts differently from the GDAL world. GDAL tries to make a guess about the EPSG code, but sometimes fails. So you have to add explicitely that you have EPSG:28992 data: ogr2ogr -f GeoJSON gem_rd.geojson Gem_2015.shp -t_srs ...


0

I found the solution here (which is to use the correct srs): http://forum.openstreetmap.org/viewtopic.php?pid=163623#p163623 The correct srs (which i saved at rd.srs): +title=Amersfoort/Amersfoort +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs ...


0

I'm not completely sure, but when reading the ogr2ogr documentation, the -clipdst and -clipdstsql seems to relate to destination data object and therefore might not be relevant to this operation. Is there a reason why you chose those variables? I would suggest using the following syntax (untested): ogr2ogr -f GeoJSON ./test-buildings.geojson ...


1

The ogr2gui app seems to read from data\gcs.csv for the Projection drop down dialog. You can edit that file, only including the common SR for the US. When I renamed data/pcs.csv to data\gcs.csv, all the UTM zones where presented in the drop down. Edit: You can either rename the pcs.csv file into gcs.csv for getting a full list of projections or you can ...


2

From the GDAL/OGR PG documentation: Configuration Options There are a variety of Configuration Options which help control the behavior of this driver. ... OGR_TRUNCATE: (GDAL >= 1.11) If set to "YES", the content of the table will be first erased with the SQL TRUNCATE command before inserting the first feature. This is an alternative to ...


2

Looking at the PDF driver documentation, you should be able to set a dataset creation option: -dsco OGR_DISPLAY_FIELD=state_name You can even modify the "sql_statement" label to something else with adding another option: -dsco OGR_DATASOURCE="States" The order of these options are important, where the full working command is: ogr2ogr -dsco ...



Top 50 recent answers are included