Re: [gdal-dev] Too much precision in WKT
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 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 01 or 99 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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Too much precision in WKT
Frank, I'm all for that approach. The option should be added to ogrinfo as well since it can dump out WKT when incanted properly (I had started to sed/grep/awk its output, then I found that ogr2ogr -f CSV would dump WKT geometry). Many Thanks, Brent Fraser Frank Warmerdam wrote: Brent Fraser wrote: 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? Brent, This question has come up a few times in the context of different text oriented drivers. I'm wondering if we should add an option to ogr2ogr (and a method on OGRGeometry) to reduce coordinate precision to a specified amount. I think I prefer this approach to the alternative of adding creation options or configuration variables to each driver text driver. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Too much precision in WKT
Peter, I want to round the coordinates of the vertices of linestrings represented as WKT, not the projection parameters. My problem is that databases have different field types for strings depending on their expected length (MS Access TEXT vs MEMO for example, and I'm still trying to find info on DBF types). As you've explained below, instead of representing the latitude of a vertex as 53.146791166875367, it would be ok to instead use 53.1467912 and be within a centimeter of the original latitude (as long as the projection parameters remained at their full precision). Best Regards, Brent Fraser Peter J Halls wrote: Brent, why would you want to? Maybe you do not appreciate the implications of so doing? The parameters of which you complain define the ellipsoid, the shape and measurements of the Earth, to be used for that projection. Round them and you effectively change the size and shape of the Earth! Based on the Clarke Ellipsoid, 1m at the equator is approximately 0.0008833141949 of a degree; round that and you lose the positional accuracy - and 1m positional accuracy is, frankly, not great. You can divide that figure by ten if you want to work at .1m positional accuracy. However, most mapping agencies and surveyors will probably use 1cm positional accuracy, or one hundreth: 0.08833141949. There are a number of other spheroids and ellipsoids in use, as the surface of our planet is sufficiently irregular to necessitate different measurements depending upon the location of interest. The map projection equations are sensitive to this numerical precision - they have to be - so reducing the numerical precision of the projection parameters will significantly reduce the precision of the final result. Indeed, it does not take much rounding to have a dramatic result, should you seek to align the results with material projected using the proper parameters. You can test this yourself be experimenting with some spherical trigonometry - the mathematics necessary for working with position on a sphere. You can find the equations for the various projections in J P Snyder's 'Map Projections: a working manual', which is available online from USGS. Try out some of the equations by hand, with the full precision and with your proposed precision for some locations in your area of interest and I'm sure you will then appreciate the need for the precision in these parameters. Best wishes, Peter Brent Fraser wrote: 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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Too much precision in WKT
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 01 or 99 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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Too much precision in WKT
Brent Fraser wrote: 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? Brent, This question has come up a few times in the context of different text oriented drivers. I'm wondering if we should add an option to ogr2ogr (and a method on OGRGeometry) to reduce coordinate precision to a specified amount. I think I prefer this approach to the alternative of adding creation options or configuration variables to each driver text driver. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Too much precision in WKT
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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
