<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Arial">Hello and thanks for the answer.<br>
<br>
I juste achieve some tests regarding to my question.<br>
<br>
</font></font>
<pre wrap="">"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 <a class="moz-txt-link-freetext" href="http://trac.osgeo.org/gdal/ticket/4138">http://trac.osgeo.org/gdal/ticket/4138</a>
So now, there should be no precision loss when moving data from/to
shapefile/postgresql with ogr2ogr."</pre>
<font size="-1"><font face="Arial"><br>
</font></font><small><span id="result_box" class="" lang="en"><span
title="Cliquer ici pour voir d'autres traductions" class="hps">I
have</span> <span title="Cliquer ici pour voir d'autres
traductions" class="hps">not seen any</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">loss
of decimal accuracy</span> <span title="Cliquer ici pour voir
d'autres traductions" class="hps">for the transfer of</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">data
from</span> <span title="Cliquer ici pour voir d'autres
traductions" class="hps">shapefile</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">to
PostgreSQL</span> <span title="Cliquer ici pour voir d'autres
traductions" class="hps">because I use</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps"></span></span></small><small><span
id="result_box" class="" lang="en"><span title="Cliquer ici pour
voir d'autres traductions" class="hps">shp2pgsql</span> which
</span></small><small><span id="result_box" class="" lang="en"><span
title="Cliquer ici pour voir d'autres traductions" class="hps">seems</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">to keep the</span> <span title="Cliquer ici pour
voir d'autres traductions" class="hps">good decimal number</span><span
class="" title="Cliquer ici pour voir d'autres traductions">.</span></span></small><br>
<br>
<pre wrap="">But if I've well understood your scenario, your issue seems to be more when you
pull data from Postgis.</pre>
<small><span id="result_box" class="" lang="en"><span title="Cliquer
ici pour voir d'autres traductions" class="hps">Indeed,</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">the problem arises</span> <span title="Cliquer
ici pour voir d'autres traductions" class="hps">when I try to</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">transform data</span> <span title="Cliquer ici
pour voir d'autres traductions" class="hps">(not just</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">from</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">PostGIS</span><span title="Cliquer ici pour voir
d'autres traductions">) with</span> <span title="Cliquer ici
pour voir d'autres traductions" class="hps">ogr2ogr</span><span
class="" title="Cliquer ici pour voir d'autres traductions">.</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">Transformation</span> <span title="Cliquer ici
pour voir d'autres traductions" class="hps">shapefile</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">to</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">MIF</span> <span title="Cliquer ici pour voir
d'autres traductions" class="hps">/ MID</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps"></span></span></small><small><span
id="result_box" class="" lang="en"><span title="Cliquer ici pour
voir d'autres traductions" class="hps">or</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps"></span></span></small><small><span
id="result_box" class="" lang="en"><span title="Cliquer ici pour
voir d'autres traductions" class="hps">TAB</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">poses
the same problems</span><span title="Cliquer ici pour voir
d'autres traductions">:</span> <span title="Cliquer ici pour
voir d'autres traductions" class="hps">loss of precision</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">on the coordinates</span></span></small>.<br>
<br>
<pre wrap="">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.</pre>
<small><span id="result_box" class="" lang="en"><span title="Cliquer
ici pour voir d'autres traductions" class="hps">I made several</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">tests</span> <span title="Cliquer ici pour voir
d'autres traductions" class="hps">and I do</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">the
same conclusion</span> <span title="Cliquer ici pour voir
d'autres traductions" class="hps">each time:</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">the
coordinates</span> <span title="Cliquer ici pour voir
d'autres traductions" class="hps">output</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">are
not those</span> <span title="Cliquer ici pour voir d'autres
traductions" class="hps">expected</span> <span title="Cliquer
ici pour voir d'autres traductions" class="hps">and decimals</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">are added</span> <span title="Cliquer ici pour
voir d'autres traductions" class="hps">which means that</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">the object has not</span>" <span title="Cliquer
ici pour voir d'autres traductions" class="hps">really</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">true</span> <span title="Cliquer ici pour voir
d'autres traductions" class="hps">and good</span>" <span
title="Cliquer ici pour voir d'autres traductions" class="hps">output
coordinates</span> <span title="Cliquer ici pour voir
d'autres traductions" class="hps">.</span><br>
<br>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">In addition</span><span title="Cliquer ici pour
voir d'autres traductions">, I did some</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">tests</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">on the same data</span> <span title="Cliquer ici
pour voir d'autres traductions" class="hps">with</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">FME</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">and conservation of</span> <span title="Cliquer
ici pour voir d'autres traductions" class="hps">the decimal
accuracy </span><span title="Cliquer ici pour voir d'autres
traductions" class="hps">is good.</span> <span title="Cliquer
ici pour voir d'autres traductions" class="hps">It's</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">pretty
boring</span> <span title="Cliquer ici pour voir d'autres
traductions" class="hps">for us because</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">the
data</span> <span title="Cliquer ici pour voir d'autres
traductions" class="hps">output with ogr2ogr is</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">"false</span><span
title="Cliquer ici pour voir d'autres traductions">."</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">And</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">I find no</span> <span title="Cliquer ici pour
voir d'autres traductions" class="hps">way to</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">get</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">output data</span> <span title="Cliquer ici pour
voir d'autres traductions" class="hps">that have the same</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">number of decimal places</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">that</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">entry</span> (export in shapefile, MIF/MID, TAB) <span
title="Cliquer ici pour voir d'autres traductions" class="hps">...
Maybe</span> <span title="Cliquer ici pour voir d'autres
traductions" class="hps">a</span> <span title="Cliquer ici
pour voir d'autres traductions" class="hps">better</span> <span
title="Cliquer ici pour voir d'autres traductions" class="hps">future</span>
<span title="Cliquer ici pour voir d'autres traductions"
class="hps">OGR2OGR</span><span class="" title="Cliquer ici
pour voir d'autres traductions">?</span></span></small><br>
<font size="-1"><font face="Arial"><br>
Best regards,<br>
<br>
--<br>
</font></font>
<div class="moz-signature">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<meta name="ProgId" content="Word.Document">
<meta name="Generator" content="Microsoft Word 11">
<meta name="Originator" content="Microsoft Word 11">
<link rel="File-List"
href="signature_crige_sm_fichiers/filelist.xml">
<title>-------------------------------------</title>
<!--[if gte mso 9]><xml>
<o:DocumentProperties>
<o:Author>Sylvain Maffren</o:Author>
<o:LastAuthor>Sylvain Maffren</o:LastAuthor>
<o:Revision>4</o:Revision>
<o:TotalTime>5</o:TotalTime>
<o:Created>2011-04-18T07:04:00Z</o:Created>
<o:LastSaved>2011-04-19T14:20:00Z</o:LastSaved>
<o:Pages>1</o:Pages>
<o:Words>47</o:Words>
<o:Characters>259</o:Characters>
<o:Company>CRIGE PACA</o:Company>
<o:Lines>2</o:Lines>
<o:Paragraphs>1</o:Paragraphs>
<o:CharactersWithSpaces>305</o:CharactersWithSpaces>
<o:Version>11.9999</o:Version>
</o:DocumentProperties>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:WordDocument>
<w:Zoom>120</w:Zoom>
<w:SpellingState>Clean</w:SpellingState>
<w:GrammarState>Clean</w:GrammarState>
<w:HyphenationZone>21</w:HyphenationZone>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
</w:Compatibility>
<w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
</w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" LatentStyleCount="156">
</w:LatentStyles>
</xml><![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;
text-underline:single;}
p
{mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:"Times New Roman";}
span.SpellE
{mso-style-name:"";
mso-spl-e:yes;}
@page Section1
{size:595.3pt 841.9pt;
margin:70.85pt 70.85pt 70.85pt 70.85pt;
mso-header-margin:35.4pt;
mso-footer-margin:35.4pt;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</style><!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Tableau Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:10.0pt;
font-family:"Times New Roman";
mso-ansi-language:#0400;
mso-fareast-language:#0400;
mso-bidi-language:#0400;}
</style>
<![endif]-->
<div class="Section1">
<p style="margin: 0cm 0cm 0.0001pt;"><b><span style="font-size:
10pt; font-family: Tahoma; color: black;">Sylvain MAFFREN</span></b><span
style="color: black;"><br>
</span><span class="SpellE"><b><span style="font-size: 7.5pt;
font-family: Tahoma; color: black;">Géomaticien</span></b></span><span
style="font-size: 7.5pt; font-family: Tahoma; color: black;"><br>
<br>
<b>Tél</b> : 04 42 90 71 22<br>
<b>Fax</b> : 04 42 97 11 56 </span><span style="color:
black;"><br>
<br>
</span><b><span style="font-size: 7.5pt; font-family: Tahoma;
color: black;">CRIGE
PACA</span></b><span style="font-size: 7.5pt; font-family:
Tahoma; color: black;"><br>
Domaine du Petit Arbois - Avenue Louis Philibert<br>
BP 10019 - 13 545 Aix-en-Provence cedex 4</span><span
style="font-size: 7.5pt; font-family: Tahoma; color: navy;"><br>
<a href="http://www.crige-paca.org/"
title="http://www.crige-paca.org/
blocked::http://www.crige-paca.org/">www.crige-paca.org</a></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<br>
Le 07/07/2011 12:58, Even Rouault a écrit :
<blockquote cite="mid:1310036332.4e15916ca2a7c@webmail.free.fr"
type="cite">
<pre wrap="">Selon Sylvain MAFFREN <a class="moz-txt-link-rfc2396E" href="mailto:sylvain.maffren@crige-paca.org"><sylvain.maffren@crige-paca.org></a>:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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 <a class="moz-txt-link-freetext" href="http://trac.osgeo.org/gdal/ticket/4138">http://trac.osgeo.org/gdal/ticket/4138</a>
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.
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">
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...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> 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
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</body>
</html>