[gdal-dev] Forcing the rounded of coordinates

[Sylvain MAFFREN]

Hello and thank you for that answer.

I think if it was a rounding effect that appears at display time when 
ogrinfo outputs the WKT representation, I should have the same results 
on several data but this is notthe case.

Indeed,by querying topology between the source layer and output layer 
(checking to see if the two layers overlap perfectly), I didn't have any 
results. That's means that the coordinates of output have been changed 
by ogr2ogr and that's why I think it's not a rounding effect.

It is there a chance that changes be made to add a parameter in ogr2ogr 
in order to force the rounded coordinates with a number of decimal 
defined by user in future versions of gdal / ogr? We would be willing to 
fund this improvement if necessary.

Thank you in advance for your feedback.

Le 22/06/2011 09:56, Even Rouault a écrit :

This might be just a rounding effect that appears at display time when ogrinfo
outputs the WKT representation, but not affect the output data itself. Likely
993366.00000000058 and 993366 are 2 decimal representations for the same
binary representation. There's no generation option to control the coordinate
precision of the output in ogr2ogr. A few drivers/formats that are text-based
have a layer/dataset creation option to control it, but this is driver/format
dependant. You might want (or not!) to hack into the ugly logic of
OGRFormatDouble() in ogr/ogrutils.cpp that is the main responsible for what
you observe...


> >  Hi !
> >  
> >  I apologize in advance for my english which I not very fluent. I have
> >  some questions about the tool ogr2ogr (and also about gdalwarp and
> >  gdal_translate) and the rounding of coordinates.
> >  
> >  
> >  Let me explain:
> >  
> >  Some databases (particularly IGN -- France databases) have coordinates
> >  rounded to the meter (BD CARTO for example) or the decimeter (BD TOPO
> >  for example).
> >  
> >  I will explain my comment with for bases the coordinates of a point of
> >  BD CARTO to support my comments :
> >  
> >  In an original *.shp in Lambert93 - France, a point has the following
> >  coordinates (provided by ogrinfo):
> >  
> >  X = 993366 m Y = 6304044 m
> >  
> >  We import this in PostGIS with shp2pgsql, and the point has always these
> >  coordinates:
> >  
> >  X = 993366 m Y = 6304044 m
> >  
> >  It's good !
> >  
> >  If we try to export this PostGIS layer through ogr2ogr (in *.shp, *.tab
> >  or *.mif), a ogrinfo gives us the same point of the layer resulting,
> >  with the following coordinates:
> >  
> >  X = and Y = 993366.00000000058 6304043.9999999898)
> >  
> >  This means that ogr2ogr (identical tests performed on a raster layer
> >  bounding box with reprojection (gdalwarp) or without (gdal_translate))
> >  changes the number of decimal coordinates of origin, which can be
> >  annoying in some cases (when we need to recover a given output with the
> >  same number of decimal than in entry.
> >  
> >  I tried to find a setting to force ogr2ogr (or gdal and related
> >  functions) to round the coordinates to a given number of decimal (as can
> >  be done with CS2CS) and I have not found any answer.
> >  
> >  Is it possible to set the number of decimal places in output (and
> >  ideally keep the same as input) ? And if so, how?
> >  
> >  Thank you in advance to all who have good ideas and / or directions to
> >  follow.
> >  
> >  
> >  Sylvain Maffren
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110707/d1f6f279/attachment-0001.html