[postgis-users] ST_Transform troubles
Frans Knibbe
frans.knibbe at geodan.nl
Thu Jun 23 12:35:11 PDT 2011
Hello Chris,
Actually, I was wrong in stating that one degree of latitude equals 1852
meters. That should have been a minute (on sixtieth of a degree).
I agree that it is not good to start rounding coordinates or other
intermediate values when performing a transformation. But it does seem
funny not to round the end result to something representative of the
'real' accuracy (assuming that the starting values have the right
precision). Whatever kind of transformation is done, it is impossible to
improve the accuracy of the initial values. Accuracy of coordinates can
only get worse. So it seems to me it is not wrong to round the end result.
Of course I am assuming that the number of significant tells us
something about accuracy. Maybe I should not do that. But there there is
no other way to express the level of accuracy of individual coordinate
values.
Thinking about the subject a bit further I now realise that this is not
really an issue with ST_Transform, it is probably a much more general
issue with all calculations involving geometry (is the radius of a
circle with a circumference of 10 meters
1.5915494309189533576888376337251 or 1.6?). So maybe I'd better withdraw
my second point.
Regards,
Frans
On 2011-06-23 17:29, Chris Hermansen wrote:
> 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
> <mailto: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
> <mailto: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
> <mailto:postgis-users at postgis.refractions.net>
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> <mailto:postgis-users at postgis.refractions.net>
> 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
>
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20110623/2f127f2e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4928 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20110623/2f127f2e/attachment.jpe>
More information about the postgis-users
mailing list