[gdal-dev] Forcing the rounded of coordinates

[Sylvain MAFFREN]

Hello and thanks for the answer.

I juste achieve some tests regarding to my question.

"Actually, it might not be a rounding effect at display time. Paul Ramsey
identified that when inserting data into a Postgis instance, we used the WKT
representation, thus introducing rounding problem effects. You might want to
test latest trunk and see if it improves the situation for you. The relevant
ticket is http://trac.osgeo.org/gdal/ticket/4138

So now, there should be no precision loss when moving data from/to
shapefile/postgresql with ogr2ogr."


I have not seen any loss of decimal accuracy for the transfer of data 
from shapefile to PostgreSQL because I use shp2pgsql which seems to keep 
the good decimal number.

But if I've well understood your scenario, your issue seems to be more when you
pull data from Postgis.

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.

There is no general solution for avoiding precision loss. For sure, not a
ogr2ogr level, because ogr2ogr doesn't change coordinate precision (no text
conversion, just setting variables of type double). If there are rounding
issues, they must be tracked down at the driver level, and for each driver, it
will depend on the actual direction of the data flow (reading vs writing). A
reproducable example of ogr command lines you use with associated data would be
helpfull to understand what's going on in your case.

Now, if you want to change/force coordinate precision, I can imagine that it
*could* be done at ogr2ogr by converting the source geometry object to WKT with
a given precision and then converted back to a destination geometry object. But
the output driver (at least the text based ones) should have a way to know how
many decimals are expected.

I'd note that currently a few text based drivers (bna, geojson recently) have
specific creation options to control the precision in write mode. AFAIR, there's
also ticket in Trac for the same wish for KML.

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 .

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?

Best regards,

--

*Sylvain MAFFREN*
*Géomaticien*

*Tél* : 04 42 90 71 22
*Fax* : 04 42 97 11 56

*CRIGE PACA*
Domaine du Petit Arbois - Avenue Louis Philibert
BP 10019 - 13 545 Aix-en-Provence cedex 4
www.crige-paca.org <http://www.crige-paca.org/>


Le 07/07/2011 12:58, Even Rouault a écrit :
> Selon Sylvain MAFFREN<sylvain.maffren at crige-paca.org>:
>
>> 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.
> Actually, it might not be a rounding effect at display time. Paul Ramsey
> identified that when inserting data into a Postgis instance, we used the WKT
> representation, thus introducing rounding problem effects. You might want to
> test latest trunk and see if it improves the situation for you. The relevant
> ticket is http://trac.osgeo.org/gdal/ticket/4138
>
> So now, there should be no precision loss when moving data from/to
> shapefile/postgresql with ogr2ogr.
>
> But if I've well understood your scenario, your issue seems to be more when you
> pull data from Postgis.
>
>> 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.
> There is no general solution for avoiding precision loss. For sure, not a
> ogr2ogr level, because ogr2ogr doesn't change coordinate precision (no text
> conversion, just setting variables of type double). If there are rounding
> issues, they must be tracked down at the driver level, and for each driver, it
> will depend on the actual direction of the data flow (reading vs writing). A
> reproducable example of ogr command lines you use with associated data would be
> helpfull to understand what's going on in your case.
>
> Now, if you want to change/force coordinate precision, I can imagine that it
> *could* be done at ogr2ogr by converting the source geometry object to WKT with
> a given precision and then converted back to a destination geometry object. But
> the output driver (at least the text based ones) should have a way to know how
> many decimals are expected.
>
> I'd note that currently a few text based drivers (bna, geojson recently) have
> specific creation options to control the precision in write mode. AFAIR, there's
> also ticket in Trac for the same wish for KML.
>
>> 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/20110720/fe6f6acb/attachment-0001.html