Frans,<br><br>You think of your input coordinates as accurate to the nearest meter.  Well perhaps :-)  But anyway, the output of the transformation is as accurate as possible a representation of your input coordinates in the new coordinate system.  That is, the transformation contains multiplication, division, perhaps iteration,
 and an underlying representation (IEEE floating point double precision)
 that causes round-off errors in floating point calculations. <br><br>It is your assumption, not correct actually, that the output representation contains false precision.  Think of your own example - if one degree of latitude is 1852 meters (to the nearest meter, on average around the spheroid), then to twenty digits of precision 1 meter is 0.00053995680345572354 degrees.  There is no "false precision" here; that is just what one gets dividing 1 by 1852 and keeping the first 20 digits of the answer.<br>
<br>If you start to throw away digits of your transformed numbers, then do calculations, then transform back, you will get a less accurate answer than if you keep it all (cumulative round-off error).  That's the point of precisely representing your numbers - minimize that computational error.<br>
<br>As to serializing, I guess it depends on how you serialize, but if it's some kind of character representation of the underlying binary floating point, you're not going to save much - you might use hexadecimal characters to represent 8 bytes for each number and generally there won't be a bunch of trailing zeros in those character representations, so you're not going to be able to shorten them up much on average.<br>
<br><div class="gmail_quote">On Thu, Jun 23, 2011 at 7:56 AM, Frans Knibbe <span dir="ltr"><<a href="mailto:frans.knibbe@geodan.nl">frans.knibbe@geodan.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Mike,<br>
<br>
Thanks for your response.<br>
<br>
About the order of coordinates: I see that PostGIS uses EPSG as the authority that defines coordinate reference systems. If you look up the definition of EPSG:4326 (for example at <a href="http://www.epsg-registry.org/" target="_blank">http://www.epsg-registry.org/</a>, use 'retrieve by code'), you can see that it explicitly says that the axes are latitude, longitude. So it seems the standard that is used in PostGIS specifies (latitude, longitude), not (longitude, latitude).<br>

<br>
About accuracy/precision: The original coordinates in my example were (253328, 593188). Those values are in meters. So the measurement is accurate on the level of a meter. Now look at the number 6.86264236062518 (longitude). The unit of measurement in this case is degrees. One degree of latitude is 1852 meters. The number 6.86264236062518 implies that it has an accuracy of about 0.00000000000001 degree, which is 0.00000000001852 meter. So suddenly, after transforming, the coordinates seem to have been measured at a submicroscopic level!<br>

<br>
I agree that a high precision is a good thing, but only if it is combined with a high accuracy. The precision in this case is clearly far too large. Another point that can be made here is that the large number of insignificant digits in this case cause bloating of data, which is a nuisance if these data are serialised.<br>

<br>
Regards,<br><font color="#888888">
Frans</font><div><div></div><div class="h5"><br>
<br>
On 2011-06-23 16:05, Mike Toews wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 24 June 2011 01:19, Frans Knibbe<<a href="mailto:frans.knibbe@geodan.nl" target="_blank">frans.knibbe@geodan.nl</a>>  wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
POINT(6.86264236062518 53.3160795502069)<br>
There are two things wrong with this result:<br>
1) The coordinates are in the wrong order (EPSG:4326 uses latitude,<br>
longitude).<br>
</blockquote>
They are in the correct order. Standards say "X, Y" which are "long,<br>
lat". This convention is commonly confused, as "lat, long" is very<br>
common.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) There are too much significant numbers in the result (the implied<br>
accuracy was increased by ST_Transform).<br>
</blockquote>
It's "precision" (not "accuracy") that was increased. This is<br>
generally a good thing, and is required to represent global positions<br>
within fractions of a millimeter. The "significant digits" method of<br>
determining precision does not work here as the actual re-projection<br>
calculations are not simple.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I would have expected a result like<br>
POINT(53.31608 6.86264)<br>
</blockquote>
You can format geometry any way you like, e.g. for reporting as<br>
"53.31608N 6.86264E". But if you are passing data for applications,<br>
keep to standard WKT and high precision if you can. The distance<br>
between the high-precision and 5-decimal precision is about 16.5 cm,<br>
which can be significant to many users.<br>
<br>
-Mike<br>
______________________________<u></u>_________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.<u></u>refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.<u></u>net/mailman/listinfo/postgis-<u></u>users</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@postgis.refractions.net" target="_blank">postgis-users@postgis.<u></u>refractions.net</a><br>
<a href="http://postgis.refractions.net/mailman/listinfo/postgis-users" target="_blank">http://postgis.refractions.<u></u>net/mailman/listinfo/postgis-<u></u>users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><font face="SANS" size="3"><span style="border-collapse:collapse;color:rgb(32, 32, 32);font-family:'Droid Sans', arial, sans-serif;font-size:13px"><font style="font-family:arial,helvetica,sans-serif" face="SANS" size="3">Chris Hermansen</font><br style="font-family:arial,helvetica,sans-serif">
<i style="font-family:arial,helvetica,sans-serif"><font size="2">Vice President</font></i><br style="font-family:arial,helvetica,sans-serif"><img style="font-family:arial,helvetica,sans-serif" src="cid:part1.07020105.06030603@tecogroup.ca" align="bottom" border="0"><br style="font-family:arial,helvetica,sans-serif">
<font style="font-family:arial,helvetica,sans-serif" face="SANS" size="2">TECO Natural Resource Group Limited</font><br style="font-family:arial,helvetica,sans-serif"><font style="font-family:arial,helvetica,sans-serif" face="SANS" size="2">301 · 958 West 8th Avenue</font><br style="font-family:arial,helvetica,sans-serif">
<font style="font-family:arial,helvetica,sans-serif" face="SANS" size="2">Vancouver BC CANADA · V5Z 1E5</font><br style="font-family:arial,helvetica,sans-serif"><font face="SANS" size="2"><span style="font-family:arial,helvetica,sans-serif">Tel +1.604.714.2878 · Cel +1.778.840.46</span>25</font></span></font><br>