Opened 16 years ago
Closed 5 years ago
#2461 closed enhancement (wontfix)
KML Driver - vertex coordinate precision option
Reported by: | chash | Owned by: | condit |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | OGR_SF | Version: | unspecified |
Severity: | normal | Keywords: | KML |
Cc: | condit, Even Rouault, warmerdam |
Description
When exporting polygons to KML ASCII (using ogr2ogr), polygon vertices can end up printing with around 15 decimal places. This causes massive bloat in the KMLs. Could the precision be a creation option in the KML driver, or simply lowered?
Attachments (1)
Change History (18)
comment:1 by , 16 years ago
Cc: | added |
---|---|
Keywords: | KML added |
comment:2 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:3 by , 16 years ago
Cc: | added |
---|
This could also be interesting for GPX and many other text formats. So it would be cool if we could find an harmonized name for the creation option. Even if the user doesn't pass explicit precision, we also probably want to detect rounding errors, for example '12.0000000001' or '11.9999999999', like it is done in OGRPrintDouble.
comment:4 by , 16 years ago
The KML driver is calling OGRMakeWktCoordinate in ogrutils.cpp:88. I was thinking of simply adding a precision argument to this function. I don't think that the GPX driver is using this, though...
comment:5 by , 16 years ago
Is the interest here in having the precision as a specific option (ie -dsco precision=3) or just reducing the precision to 1/1000th or something?
comment:6 by , 16 years ago
I do not thing just producing values with crappy precision is appropriate. We should attempt to preserve the original precision by default, and potentially offer an option to reduce the precision.
comment:7 by , 13 years ago
I know this is an old issue, but it seems to still exist (unless I am missing an option). Has there been any progress on this?
I don't think anyone is talking about "crappy resolution" by default. My KML conversions are using 16 digits after the decimal point. For output in degrees, this corresponds to a precision on the order of 10-11 meters, which is smaller than the radius of a hydrogen atom. Perhaps a default resolution on the order of millimeters may be good enough for general use, and take half as many digits.
Of course it doesn't matter in many cases if excess precision is used, but I am coming up against a million-character per line input limit for large polygons in KML.
comment:8 by , 13 years ago
Cc: | added |
---|
by , 13 years ago
comment:9 by , 13 years ago
kjordahl- I think that the new libkml driver is preferred - but I see that this could be an annoyance with the original driver. I think Frank has the best solution of attempting to preserve the precision from the source data. In the meantime I attached a patch adding a "Precision" creation option. You can use it like: -dsco Precision=3 (for 3 decimal places of precision).
Frank- I didn't commit the change since it touches ogrutils.cpp and I wanted to make sure that change was ok with you (see attached diff).
comment:10 by , 13 years ago
I think that the changes in ogrutils.cpp are fine, except I would change the test to be if ( nPrecision >= 0 ) instead of if ( nPrecision > 0 ) in case someone wants only the integer part (doesn't make much sense for KML in Lat/Long, but could make sense for other projected SRS since OGRMakeWktCoordinate() is also used for exporting WKT and GML).
But the change of the prototype of OGR_G_ExportToKML() should be avoided since that function is part of the C API and we are committed to maintain it stable (you would get a compiling error in swig bindings by the way). Perhaps a OGR_G_ExportToKMLEx would be more appropriate with a char papszOptions argument (similarly to OGR_G_ExportToGMLEx()) so that we can add easily new options later. Or if we don't anticipate new options just add a nPrecision argument.
comment:12 by , 9 years ago
One GDAL driver does have a desired option: ArcInfo GRID. Actually it has two:
When writing floating-point values, the driver uses the "%.20g" format pattern as a default. You can consult a reference manual for printf to have an idea of the exact behaviour of this ;-). You can alternatively specify the number of decimal places with the DECIMAL_PRECISION creation option. For example, DECIMAL_PRECISION=3 will output numbers with 3 decimal places(using %lf format). Starting with GDAL 1.11, another option is SIGNIFICANT_DIGITS=3, which will output 3 significant digits (using %g format).
It would be cool to have such option not only in KML but also in drivers like GPX, GML, and GeoJSON. There may be more.
comment:13 by , 9 years ago
GeoJSON seems to have this option already http://www.gdal.org/drv_geojson.html
COORDINATE_PRECISION = int_number : (OGR >= 1.9.0) Maximum number of figures after decimal separator to write in coordinates. Default to 15. "Smart" truncation will occur to remove trailing zeros.
follow-up: 15 comment:14 by , 9 years ago
Having been busy with resolving topology errors on some polygon coverages and I would say that "producing values with crappy precision" does happen in real life but just in an opposite way. It looks that many processed datasets I have received have thousands of overlaps and gaps at a nanometer scale and I believe that they are rounding errors coming from 32-bit accuracy. The first step to clean these coverages it to reduce coordinate precision to for example 6 decimal places.
Instead of implementing different coordinate precision methods for each driver, wouldn't it be better to have one common OGR method?
Dropping decimals is not safe for topology if common boundaries do not use same vertices and this should be mentioned in documentation.
comment:15 by , 9 years ago
Instead of implementing different coordinate precision methods for each driver, wouldn't it be better to have one common OGR method?
Well, it is the driver responsibility to generate their output. There's no technical way of doing coordinate precision reduction in a universal way. However there's the OGRFormatDouble() function that can be used by drivers to generate a string from a double value and limit the number of decimals
Dropping decimals is not safe for topology if common boundaries do not use same vertices and this should be mentioned in documentation.
Hum, if in the starting data, vertices of objects that have common points or boundaries are identical, after truncation to the same number of decimals, they will still be identical.
comment:16 by , 9 years ago
It is true that truncation itself should not effect the topology but by my experience on real world datasets it is not uncommon that shared boundaries do not share all the vertices. Some nodes may be over the other boundary but unnoded so that the line underneath does not have a node at that place. When the precision of such unnoded vertex is reduced it may move a bit and as a result there will an overlap or a gap. An illustrated example about a not identical but same kind of case is at http://gis.stackexchange.com/questions/143695/create-common-vertexes-between-shared-polygon-boundaries-in-postgis/143719#143719
With a very new Spatialite version it should be possible to use SQLite SQL dialect and ST_SnapToGrid https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html for reducing the precision. I think it is rather close to an universal way for reducing coordinate precision. However, the Spatialite of gisinternals builds do not have ST_SnapToGrid and I haven't been able to test it with GDAL. However, I have used it couple of times with spatialite-gui with good results.
comment:17 by , 5 years ago
Milestone: | → closed_because_of_github_migration |
---|---|
Resolution: | → wontfix |
Status: | assigned → closed |
This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.
Making precision of vertex encoding a creation parameter seem plausible to me, but we have never bothered to do this for any other formats before. I'll add Chris to the cc: list and perhaps he will be interested in doing it.