Tag Info

New answers tagged

1

You may still have 10dp numbers reported, but count the number of nodes in the modified file, and it should be far fewer that the original. The tolerance unit is whatever the unit of your map data uses. 0.000001° would keep destination paths no more than 0.000001° (a metre 10 cm or so) from their original location. It would be far too small if your data ...


1

perhaps a couple of resources on this - here's another stack question that may be a duplicate. or portions of this page might be helpful - in any case, it appears to be a two step process - first create the .dbf from the csv then create the spatial information from a vrt file (small xml-like file with basic information about your data and output ...


0

That is one way to do it. How much time / effort do you want to put into it? With a GDAL distribution, you have the code for ogr2ogr. you could peruse that code and figure out how it does the above command, and then add your processing to that C/C++ utility, thus generating your own. you could replicate that processing in C# by calling the .NET bindings and ...


0

Two other things you can try. First, does your shapefile have any attributes that you can drop before converting to kml? Second, you can try to open the kml in Google Earth and save it as a kmz. This should drastically reduce the size of the file, but I'm not sure if it will solve your original problem since the kmz will still have the same amount ...


2

This is a case sensitivity/quoting issue. "PointsForGpxExport" and PointsForGpxExport are not the same table name. PostgreSQL, per the SQL standard, case-folds unquoted identifiers. (It case-folds to lowercase, where the standard says uppercase, though). So when you write PointsForGpxExport, PostgreSQL treats that as the same as pointsforgpxexport. Since ...


0

The first step in reducing the file size of a featureclass is to simplify it. This documentation explains the simplify process in ArcGIS. Basically, the more vertices your features have, the more information they are storing, and therefore the larger the file size of the feature. When you convert a shapefile to KML you are converting all of these vertices. ...


1

Recently, i also encounter problems with Chinese character read in dbf file ! Here is the convert tool for shapefile to geojson via web browser without server-side code and supporting non-english encoding, just need to upload the zip file and set the encoding (Shift_JIS) for the correctly display Japanese text. http://gipong.github.io/shp2geojson.js/ It ...


1

Using the version 1.2 of H2GIS (java spatial database) here: http://search.maven.org/remotecontent?filepath=org/orbisgis/h2-dist/1.2.0/h2-dist-1.2.0-bin.zip You can load the file into the database using the right encoding. H2GIS is able to find the right encoding in the dbf header, however under windows the encoding name is not supported. Unzip the file. ...


1

If you only need to do the job once and there is no need to go to scripting then one simple way is to convert the data with OpenJUMP. Activate the charactes set selection from menu Customize - Options Open your dataset as Shift-JIS Save data back with Save as... and select UTF-8 charset


1

ogr2ogr man page says that this should work ogr2ogr --config SHAPE_ENCODING Shift_JIS japan_ver72_utf8.shp -lco ENCODING=UTF-8 Have you already tried it ? (Probably needs linux version of ogr2ogr)


0

As the data owner cannot change the field types, I have used ogr2ogr and a -sql select statement to exclude the field that is causing problems. As the field, LENGTH, is derived data, then it shows up in QGIS anyway so I was ok to omit it. My new code is as follows; ogr2ogr.exe -f PostgreSQL PG:"dbname=postgis host=localhost user=username ...


1

You probably want to write a script, but starting point could be to take a list of the layers with ogrinfo: ogrinfo kml_samples.kml INFO: Open of `kml_samples.kml' using driver `LIBKML' successful. 1: Placemarks 2: Styles and Markup 3: Highlighted Icon 4: Ground Overlays 5: Screen Overlays 6: Paths 7: Polygons 8: Google Campus 9: Extruded Polygon 10: ...


3

A python solution is fairly simple using ogr.GetDriverByName(in_format).Open(in_file). import sys from osgeo import ogr def main(in_file, in_format, out_file, out_format): in_ds = ogr.GetDriverByName(in_format).Open(in_file) out_ds = ogr.GetDriverByName(out_format).CopyDataSource(in_ds, out_file) if __name__ == '__main__': main(*sys.argv[1:]) ...


1

If the output parameter is a directory instead of a file name, ogr2ogr will automatically convert all geometry types into separate shapefiles: ogr2ogr out_dir d:\incoming\nhn_09AA001_1_0.gml Unfortunately for the OP this doesn't work for KML, but it does for some of the other multiple geometry type formats like ArcInfo Coverages and GML. Posting here ...


0

What I had found was the line features that failed were zig-zagged between two different features in my clip feature. When I merged all my clip features together I no longer get the error and it clips as expected. Not sure why having multiple features in my clip feature would cause this, but merging them together resolved the problem.



Top 50 recent answers are included