[postgis-users] ST_Transform troubles

[Chris Hermansen]

Frans,

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.

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.

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.

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.

On Thu, Jun 23, 2011 at 7:56 AM, Frans Knibbe <frans.knibbe at geodan.nl>wrote:

> Hi Mike,
>
> Thanks for your response.
>
> 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 http://www.epsg-registry.org/, 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).
>
> 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!
>
> 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.
>
> Regards,
> Frans
>
>
> On 2011-06-23 16:05, Mike Toews wrote:
>
>> On 24 June 2011 01:19, Frans Knibbe<frans.knibbe at geodan.nl>  wrote:
>>
>>> POINT(6.86264236062518 53.3160795502069)
>>> There are two things wrong with this result:
>>> 1) The coordinates are in the wrong order (EPSG:4326 uses latitude,
>>> longitude).
>>>
>> They are in the correct order. Standards say "X, Y" which are "long,
>> lat". This convention is commonly confused, as "lat, long" is very
>> common.
>>
>>  2) There are too much significant numbers in the result (the implied
>>> accuracy was increased by ST_Transform).
>>>
>> It's "precision" (not "accuracy") that was increased. This is
>> generally a good thing, and is required to represent global positions
>> within fractions of a millimeter. The "significant digits" method of
>> determining precision does not work here as the actual re-projection
>> calculations are not simple.
>>
>>  I would have expected a result like
>>> POINT(53.31608 6.86264)
>>>
>> You can format geometry any way you like, e.g. for reporting as
>> "53.31608N 6.86264E". But if you are passing data for applications,
>> keep to standard WKT and high precision if you can. The distance
>> between the high-precision and 5-decimal precision is about 16.5 cm,
>> which can be significant to many users.
>>
>> -Mike
>> ______________________________**_________________
>> postgis-users mailing list
>> postgis-users at postgis.**refractions.net<postgis-users at postgis.refractions.net>
>> http://postgis.refractions.**net/mailman/listinfo/postgis-**users<http://postgis.refractions.net/mailman/listinfo/postgis-users>
>>
>
>
> ______________________________**_________________
> postgis-users mailing list
> postgis-users at postgis.**refractions.net<postgis-users at postgis.refractions.net>
> http://postgis.refractions.**net/mailman/listinfo/postgis-**users<http://postgis.refractions.net/mailman/listinfo/postgis-users>
>



-- 
Chris Hermansen
*Vice President*

TECO Natural Resource Group Limited
301 · 958 West 8th Avenue
Vancouver BC CANADA · V5Z 1E5
Tel +1.604.714.2878 · Cel +1.778.840.4625
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20110623/500cdab6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: teco_sig.jpg
Type: image/jpeg
Size: 4928 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20110623/500cdab6/attachment.jpg>