Opened 14 years ago
Closed 14 years ago
#341 closed enhancement (fixed)
WKTWriter option to reduce the number of decimals
| Reported by: | atrofast | Owned by: | warmerdam |
|---|---|---|---|
| Priority: | major | Milestone: | 3.3.0 |
| Component: | C API | Version: | main |
| Severity: | Feature Request | Keywords: | |
| Cc: | mloskot, pramsey |
Description
Currently the WKTWriter will often format using more zero's than necessary even though the double value might just be 1.0. It would be great to have an option in the C-API where we could change the actual formatter used and reduce the number of zeros/decimals. I would be happy to take this project on, with the hope that it will be included upstream in GEOS.
Attachments (1)
Change History (7)
comment:1 by , 14 years ago
| Cc: | added |
|---|
comment:2 by , 14 years ago
Tinkering with this I've been thinking about two approaches.
The first would be to just chop off zeroes and round superfluous nines which are there because of floating point inaccuracy reasons. If there are no more decimals left (as in the case of 1.0000000) the end number would be just 1. There are cases when due to the peculiarities of the double type the number might be something like 1.000000000000001 when in fact it is not, then we could chop off the last 1 and go on with trimming the rest of the zeroes.
Another approach I thought of was to let the user specify the precision of the sprintf function in WKTWriter::writeNumber so it'd use the specified precision instead of 16.
Which of these approaches do you feel is the most appropriate (or maybe both should be available)
Thank you for your input.
by , 14 years ago
| Attachment: | trim_round.diff added |
|---|
Adds trim and rounding precision options to WKTWriter and exposes them in the C-API
comment:3 by , 14 years ago
Sounds fine to me. However, what about output precision derived from precision model in the second proposed solution? Precision of output is linked to precision of model being used, isn't it?
comment:4 by , 14 years ago
From what I can tell there are only three precision models: FLOATING (16 decimals), FLOATING_SINGLE (8 decimals) and FIXED (1 I think). Being able to set roundingPrecision gives you a bit more control over how it is displayed. I don't actually touch the underlying numbers, just the strings. The diff I posted overrides the precision model IF you have specified a rounding precision. Does this cause any issue that I might be unaware of?
Thank you for your input!
comment:5 by , 14 years ago
| Cc: | added |
|---|---|
| Owner: | changed from to |
I'm going to do a quick review and apply this as there doesn't seem to be any issues I'm aware of and it would be helpful to get this into trunk sooner rather than later.
comment:6 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
The code seems fine. I have also added some very minimal unit testing of this functionality and committed in trunk (r2993).
It is a good idea. I would suggest to update not only the C API but also the C++.