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)

2461.diff (11.2 KB ) - added by condit 13 years ago.

Download all attachments as: .zip

Change History (18)

comment:1 by warmerdam, 16 years ago

Cc: condit added
Keywords: KML added

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.

comment:2 by condit, 16 years ago

Owner: changed from warmerdam to condit
Status: newassigned

comment:3 by Even Rouault, 16 years ago

Cc: Even Rouault 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 condit, 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 condit, 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 warmerdam, 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 kjordahl, 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 condit, 13 years ago

Cc: warmerdam added

by condit, 13 years ago

Attachment: 2461.diff added

comment:9 by condit, 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 Even Rouault, 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:11 by warmerdam, 13 years ago

I agree with Even's comments.

comment:12 by Jukka Rahkonen, 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 Jukka Rahkonen, 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.

comment:14 by Jukka Rahkonen, 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.

in reply to:  14 comment:15 by Even Rouault, 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 Jukka Rahkonen, 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 Even Rouault, 5 years ago

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.