[gdal-dev] Too much precision in WKT

[Brent Fraser]

Even,

  I'll likely do the hack for now.  I need to write an easy-to-use app that spits out the first and last point coordinates of the linestrings as well as the linestrings in WKT for eventual loading into a database, so I might as well hard code the precision for now.

 Personally, I think something like an option of:

  -WKT_cp <digits to represent the fractional part>
eg:
  -WKT_cp 7   would result in 53.1467912

to specify the WKT coordinate precision would be good enough for a long term solution.  Easy to implement, easy to document, and easy to check the user input. And would likely handle most of the practical precision needs.

Best Regards,
Brent Fraser

Even Rouault wrote:
> Brent,
> 
> no, there's currently no way to limit the precision.
> 
> 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.
> 
> 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...
> 
> 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 :
> 
> - fixed point notiation (%f) where you can control the maximum number of 
> figures after the comma, but not before
> 
> - exponential notation (%e) where you can control the number of 
> significant figures.
> 
> - fixed point or exponential (%g), whichever is more appropriate for its 
> magnitude
> 
> 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...
> 
> 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
> 
> I also found the following discussion : 
> http://lists.ingres.com/pipermail/gis-users/2009-January/000145.html
> 
> Best regards,
> 
> Even
> 
> 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).
> 
> Le Tuesday 02 June 2009 19:50:40 Brent Fraser, vous avez écrit :
> 
>>  I've been experimenting with v1.6.0 ogr2ogr:
> 
>>
> 
>>  ogr2ogr -f csv test_dir test_in.shp -nln test_out -lco GEOMETRY=AS_WKT
> 
>>
> 
>>  The precision of the coordinates in the WKT seems to be overkill, eg:
> 
>>
> 
>>  "LINESTRING (-115.11433812265155 53.146791166875367,-115.12192424362472
> 
>>  53.147304268559473,
> 
>>
> 
>>  Is there any way to limit the precision?
> 
>>
> 
>>  Thanks!
> 
>>  Brent Fraser
> 
>>  _______________________________________________
> 
>>  gdal-dev mailing list
> 
>>  gdal-dev at lists.osgeo.org
> 
>>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>