[gdal-dev] Forcing the rounded of coordinates

[Even Rouault]

Sylvain,

> 
> Indeed, the problem arises when I try to transform data (not just from
> PostGIS) with ogr2ogr. Transformation shapefile to MIF / MID or TAB
> poses the same problems: loss of precision on the coordinates.

Looking very quicly to the MIF driver, I see for example that a point is 
written with :

p->WriteLine("Point %.15g %.15g\n",poPoint->getX(),poPoint->getY());

So that means that up to 15 significant figures are written (including figures 
before the decimal point).

> 
> I made several tests and I do the same conclusion each time: the
> coordinates output are not those expected and decimals are added which
> means that the object has not" really true and good" output coordinates .

You didn't mention if you've tested with the drivers I mentionned to have 
options to control the decimal precision ?

> 
> In addition, I did some tests on the same data with FME and conservation
> of the decimal accuracy is good. It's pretty boring for us because the
> data output with ogr2ogr is "false." And I find no way to get output
> data that have the same number of decimal places that entry (export in
> shapefile, MIF/MID, TAB) ... Maybe a better future OGR2OGR?

It might not look as such, but I believe this is a really challenging topic 
that could have broad implications in OGR core and drivers. It sounds more 
like you'd wish to keep the same precision in the output datasource as the 
input datasource, rather than to control explicitly the output precision, 
right ?

Several points to consider :

* Some datasources use binary representations (shapefile, postgis, 
sqlite/spatialite, tab?, ...) whereas others (mif, kml, gml, geojson, bna...) 
use text representations. But the OGR geometry model only stores a binary 
representation.

* For a text representation, how would we define the desired accuracy : the 
accuracy of each coordinate component found in the input data, the maximum 
accurarcy of any coordinate component for a given geometry, ... ? 
This would mean that somehow, in the OGR geometry model, the precision of the 
values should be set. Or that the text representation should be kept alongside 
with the binary one.

* When transforming from a binary datasource to a text datasource, how do we 
define the accuracy of the source ? Let's consider a number whose one 
representation would be 12.34. Should we write it 12.34, 12.340, 12.3400, or 
... ? The binary representation isn't sufficient to determine the precision for 
its text representation.

And of course, all the above only makes sense when just translating from one 
format to another one ... without reprojection.

IMHO, a quicker&simpler solution (you might qualify it as a workaround ;-)) 
would be to add an option to explicitely set the output precision wished in 
the drivers you are interested in.

Best regards,

Even