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.kni...@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.kni...@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@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
postgis-users@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@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
|
