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<[email protected]>:
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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
