<html><head><meta name="qrichtext" content="1" /></head><body style="font-size:9pt;font-family:Sans Serif">
<p>Brent,</p>
<p></p>
<p>no, there's currently no way to limit the precision.</p>
<p></p>
<p>By looking at your example, it seems that the extra figures are significant (but perhaps not for your use case). You'd get 000001 or 999999 at the end of the numbers if they were not significant So there's no way OGR can guess that you don't want them.</p>
<p></p>
<p>The WKT formatting for a point is done by OGRMakeWktCoordinate() in ogr/ogrutils.cpp and it always outputs 15 digits after the comma. This is the place where to hack if you want to change that default behaviour. The easiest way to add this would be adding a configuration option. The other - and cleaner - possibility is to propagate a precision parameter into the whole sequence of calls of ExportToWkt(). In any case, care should be taken that the output buffer passed by calling functions is sufficiently large. Currently all callers are supposed to pass a sufficiently large buffer, but if precision is made parametrable, this would be a bit more complicated : that wouldn't be a bad thing by the way to revisit that, as currently the code that allocates the buffer has plenty of magic - and different - constants all over and different tests to check if it must be resized...</p>
<p></p>
<p>But specifying the formatting is not as trivial as one could think at first. For a floating point, you have several possibilities that are reflected by the possibilities offered by printf with floating numbers :</p>
<p>- fixed point notiation (%f) where you can control the maximum number of figures after the comma, but not before</p>
<p>- exponential notation (%e) where you can control the number of significant figures.</p>
<p>- fixed point or exponential (%g), whichever is more appropriate for its magnitude</p>
<p></p>
<p>I'm not sure how the user could specify the format he wants. Passing the printf formatting string is a bit dangerous, as very bad things could happen if he got wrong...</p>
<p></p>
<p>I found that Frank had written a paragraph somehow a bit related to that issue, but it was more about OGC WKT Coordinate System. See "Numerical Precision in WKT" http://home.gdal.org/projects/opengis/wktproblems.html</p>
<p></p>
<p>I also found the following discussion : http://lists.ingres.com/pipermail/gis-users/2009-January/000145.html</p>
<p></p>
<p>Best regards,</p>
<p></p>
<p>Even</p>
<p></p>
<p>P.S : I had a doubt if the OGC WKT spec allowed exponential notation, but apparently yes (OGC 06-103r3 page 53-54, OpenGIS® Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecturen v1.2).</p>
<p></p>
<p></p>
<p>Le Tuesday 02 June 2009 19:50:40 Brent Fraser, vous avez écrit :</p>
<p>> I've been experimenting with v1.6.0 ogr2ogr:</p>
<p>></p>
<p>> ogr2ogr -f csv test_dir test_in.shp -nln test_out -lco GEOMETRY=AS_WKT</p>
<p>></p>
<p>> The precision of the coordinates in the WKT seems to be overkill, eg:</p>
<p>></p>
<p>> "LINESTRING (-115.11433812265155 53.146791166875367,-115.12192424362472</p>
<p>> 53.147304268559473,</p>
<p>></p>
<p>> Is there any way to limit the precision?</p>
<p>></p>
<p>> Thanks!</p>
<p>> Brent Fraser</p>
<p>> _______________________________________________</p>
<p>> gdal-dev mailing list</p>
<p>> gdal-dev@lists.osgeo.org</p>
<p>> http://lists.osgeo.org/mailman/listinfo/gdal-dev</p>
<p></p>
<p></p>
<p></p>
</body></html>