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
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
