[prev in list] [next in list] [prev in thread] [next in thread]
List: postgis-users
Subject: Re: [postgis-users] PostGIS layer spatial tolerance
From: Oxenstierna Andreas <Andreas.Oxenstierna () sweco ! se>
Date: 2009-08-31 11:53:31
Message-ID: 5DCE0C52C73A734D814DDA78B60C4E9603A0E038 () essth024 ! sweco ! se
[Download RAW message or body]
Yes, I am at least partly aware of floating-point positioning problems.
However, from my perspective absolute, calculated and interpolated positions are not \
so important. Data accuracy in the selected CRS is in any case in the magnitude of \
10 metres. We need to preserve similarity for shared coordinates, so the client code \
can rebuild and use the polygon topology correctly. I.e. what we save is what we get \
back for the next editing operation.
A non-redundant geometry model, like ArcInfo Coverage, Oracle topology models, S57 \
hydrographic standard or PostGIS Topology, should of course be better to use but not \
yet in place for our software platform.
Best Regards
________________________________
Andreas Oxenstierna
Telefon direkt 040-16 70 17
Mobil 0734-12 80 17
andreas.oxenstierna@sweco.se
Sweco Position AB
Hans Michelsensgatan 2
Box 286
201 22 Malmö
Telefon 040-16 70 00
www.sweco.se
-----Ursprungligt meddelande-----
Från: postgis-users-bounces@postgis.refractions.net \
[mailto:postgis-users-bounces@postgis.refractions.net] För Chris \
Hermansen
Skickat: den 28 augusti 2009 17:59
Till: PostGIS Users Discussion
Ämne: Re: [postgis-users] PostGIS layer spatial tolerance
Oxenstierna Andreas wrote:
> I come from the ESRI and Oracle world. Both ArcSDE and Oracle Spatial
> have user-defined spatial tolerance for each spatially enabled layer.
> This ensures that coordinates are exact, down to the last decimal (or
> integer for ArcSDE).
> I cannot find in the documentation or in the functionality that
> PostGIS has an awareness of spatial tolerance. What I can find is:
> "All floating point comparisons within the SQL-MM implementation are
> performed to a specified tolerance, currently 1E-8"
> but nothing about actual storage.
>
> For me, the easiest solution would be to use a spatial tolerance.
> Otherwise, we may need to round all coordinates in the application
> code to e.g. 14 valid digits.
Andreas, you state that the ArcSDE fixed point representation ensures that \
coordinates are exact. This is incorrect. What it ensures is that locations are \
represented to a fixed precision; that is all.
By way of example, if you draw a line between points A and B, and then try to \
represent the locations of points along that line, neither ArcSDE fixed point nor \
Shapefile floating point will get those positions exactly. In general, floating \
point will represent those locations more accurately though that depends on the \
coordinate system (more precisely, the X and Y offsets in the coordinate system) and \
on the number of digits in the floating point fraction.
The same is true with points along a curve.
The use of a binary floating point number to represent a real quantity generally \
involves some approximation. For example, you cannot represent 0.1,0.2,0.3 etc \
exactly in binary floating point. You can represent 0.25, 0.5, etc exactly. This is \
because the fractional part in binary floating point is, well, binary, and binary \
fractional numbers cannot generally represent decimal fractional numbers exactly.
Of course, rational numbers like 1/3 and irrational numbers like pi cannot be \
represented exactly either.
This representational error is proportionally small; it's the unit round off error of \
the representation.
So a GIS file format that uses floating point to represent location will inevitably \
be off by its unit round-off error on many locations. This is true of ESRI \
coverages, shape files, and I guess PostGIS.
However the absolute amount of error can be pretty large in a given coordinate \
system; UTM northings in 32 bit binary floating point have a round-off error on the \
order of a metre at my latitude.
Round-off error accumulates through arithmetic operations. One great way to lose a \
lot of representational accuracy is to subtract two nearly equal numbers using a \
fixed number of fractional digits, as does adding two very different sized numbers; \
and therefore as does accumulating inner products (calculating statistical variance, \
polygon areas, eigenvalues, etc). People tend to use 64 bit binary floating point \
these days to try to minimize these problems. Fixed-point number systems are \
generally worse at losing representational accuracy through computation.
Another thing to remember about fixed-point representations like ArcSDE:
numbers come from somewhere, go somewhere, and are compared to other numbers. So \
conversions between external (eg ASCII), internal floating point, and internal fixed \
point, are pretty common. For example, if you do a query "where northing <= \
2345678.9" how do you think the constant is handled? Is it converted precisely into \
an ArcSDE back-end fixed point representation, or is the comparison done in floating \
point by converting the northing value from its back-end fixed point representation \
to floating point?
See http://en.wikipedia.org/wiki/IEEE_754-2008 for more info on floating point.
--
Regards, (please note new mobile number below)
Chris Hermansen mailto:chris.hermansen@timberline.ca
tel+1.604.714.2878 · fax+1.604.733.0631 · mob+1.778.840.4625
Timberline Natural Resource Group · http://www.timberline.ca
401 · 958 West 8th Avenue · Vancouver BC · Canada · V5Z 1E5
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
[Attachment #3 (text/html)]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.6000.16850" name=GENERATOR></HEAD>
<BODY>
<DIV>
<DIV></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><SPAN
class=213014606-31082009><FONT color=#0000ff>Yes, I am at least partly aware of
floating-point positioning problems.</FONT></SPAN></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><SPAN
class=213014606-31082009><FONT color=#0000ff>However, from my perspective
absolute, calculated and interpolated positions are not so important.
<BR>Data accuracy in the selected CRS is in any case in the magnitude of 10
metres.</FONT></SPAN></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><SPAN
class=213014606-31082009><FONT color=#0000ff>We need to preserve similarity for
shared coordinates, so the client code can rebuild and use the polygon topology
correctly.</FONT></SPAN></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><SPAN
class=213014606-31082009><FONT color=#0000ff>I.e. what we save is what we get
back for the next editing operation.</FONT></SPAN></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><SPAN
class=213014606-31082009><FONT color=#0000ff></FONT></SPAN> </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><SPAN
class=213014606-31082009><FONT color=#0000ff>A non-redundant geometry model,
like ArcInfo Coverage, Oracle topology models, S57 hydrographic standard or
</FONT></SPAN><SPAN class=213014606-31082009><FONT color=#0000ff>PostGIS
Topology, should of course be better to use but not yet in place for our
software platform.</FONT></SPAN></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><FONT
color=#0000ff></FONT> </DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><SPAN
class=213014606-31082009><FONT color=#0000ff>Best Regards</FONT></SPAN></DIV>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: Arial" align=left><SPAN
class=213014606-31082009><FONT color=#0000ff></FONT></SPAN> </DIV>
<HR color=#d70005 SIZE=1>
<DIV></DIV>
<DIV style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Verdana"
align=left></DIV>
<DIV style="FONT-SIZE: 10pt; COLOR: #000000; FONT-FAMILY: Verdana" align=left>
<TABLE
style="PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; WIDTH: 600px; \
PADDING-TOP: 0px" cellSpacing=0>
<TBODY style="FONT-SIZE: 7pt; FONT-FAMILY: Verdana">
<TR vAlign=top>
<TD style="WIDTH: 200px">
<DIV style="FONT-SIZE: 8pt"><B>Andreas Oxenstierna</B></DIV>
<DIV style="FONT-SIZE: 7pt"><BR>Telefon direkt 040-16 70 17 <BR>Mobil
0734-12 80 17 <BR>andreas.oxenstierna@sweco.se</DIV></TD>
<TD style="WIDTH: 200px">
<DIV style="FONT-SIZE: 8pt"><B>Sweco Position AB</B><BR></DIV>
<DIV style="FONT-SIZE: 7pt">Hans Michelsensgatan 2<BR>Box 286<BR>201 22
Malmö<BR>Telefon 040-16 70 00<BR>www.sweco.se</DIV></TD>
<TD style="WIDTH: 103px">
<DIV style="FONT-SIZE: 3pt" align=right><BR> <BR></DIV>
<DIV style="FONT-SIZE: 7pt"
align=right><BR><BR></DIV></TD></TR></TBODY></TABLE></DIV>
<DIV style="FONT-SIZE: 7pt; COLOR: #000000; FONT-FAMILY: Verdana"
align=left></DIV></DIV>
<META content="MSHTML 6.00.6000.16850" name=GENERATOR><!-- Converted from text/plain \
format --> <P><FONT size=2><BR><BR>-----Ursprungligt meddelande-----<BR>Från:
postgis-users-bounces@postgis.refractions.net [<A
href="mailto:postgis-users-bounces@postgis.refractions.net">mailto:postgis-users-bounces@postgis.refractions.net</A>] \
För Chris Hermansen<BR>Skickat: den 28 augusti 2009 17:59<BR>Till: PostGIS Users
Discussion<BR>Ämne: Re: [postgis-users] PostGIS layer spatial
tolerance<BR><BR>Oxenstierna Andreas wrote:<BR>> I come from the ESRI and
Oracle world. Both ArcSDE and Oracle Spatial<BR>> have user-defined spatial
tolerance for each spatially enabled layer.<BR>> This ensures that
coordinates are exact, down to the last decimal (or<BR>> integer for
ArcSDE).<BR>> I cannot find in the documentation or in the functionality
that<BR>> PostGIS has an awareness of spatial tolerance. What I can find
is:<BR>> "All floating point comparisons within the SQL-MM implementation
are<BR>> performed to a specified tolerance, currently 1E-8"<BR>> but
nothing about actual storage.<BR>> <BR>> For me, the easiest solution
would be to use a spatial tolerance.<BR>> Otherwise, we may need to round all
coordinates in the application<BR>> code to e.g. 14 valid digits.<BR>Andreas,
you state that the ArcSDE fixed point representation ensures that coordinates
are exact. This is incorrect. What it ensures is that locations are
represented to a fixed precision; that is all.<BR><BR>By way of example, if you
draw a line between points A and B, and then try to represent the locations of
points along that line, neither ArcSDE fixed point nor Shapefile floating point
will get those positions exactly. In general, floating point will
represent those locations more accurately though that depends on the coordinate
system (more precisely, the X and Y offsets in the coordinate system) and on the
number of digits in the floating point fraction.<BR><BR>The same is true with
points along a curve.<BR><BR>The use of a binary floating point number to
represent a real quantity generally involves some approximation. For
example, you cannot represent 0.1,0.2,0.3 etc exactly in binary floating
point. You can represent 0.25, 0.5, etc exactly. This is because the
fractional part in binary floating point is, well, binary, and binary fractional
numbers cannot generally represent decimal fractional numbers exactly.<BR><BR>Of
course, rational numbers like 1/3 and irrational numbers like pi cannot be
represented exactly either.<BR><BR>This representational error is proportionally
small; it's the unit round off error of the representation.<BR><BR>So a GIS file
format that uses floating point to represent location will inevitably be off by
its unit round-off error on many locations. This is true of ESRI
coverages, shape files, and I guess PostGIS.<BR><BR>However the absolute amount
of error can be pretty large in a given coordinate system; UTM northings in 32
bit binary floating point have a round-off error on the order of a metre at my
latitude.<BR><BR>Round-off error accumulates through arithmetic
operations. One great way to lose a lot of representational accuracy is to
subtract two nearly equal numbers using a fixed number of fractional digits, as
does adding two very different sized numbers; and therefore as does accumulating
inner products (calculating statistical variance, polygon areas, eigenvalues,
etc). People tend to use 64 bit binary floating point these days to try to
minimize these problems. Fixed-point number systems are generally worse at
losing representational accuracy through computation.<BR><BR>Another thing to
remember about fixed-point representations like ArcSDE:<BR>numbers come from
somewhere, go somewhere, and are compared to other numbers. So conversions
between external (eg ASCII), internal floating point, and internal fixed point,
are pretty common. For example, if you do a query "where northing <=
2345678.9" how do you think the constant is handled? Is it converted
precisely into an ArcSDE back-end fixed point representation, or is the
comparison done in floating point by converting the northing value from its
back-end fixed point representation to floating point?<BR><BR>See <A
href="http://en.wikipedia.org/wiki/IEEE_754-2008">http://en.wikipedia.org/wiki/IEEE_754-2008</A> \
for more info on floating point.<BR><BR>--<BR>Regards, (please note new
mobile number below)<BR><BR>Chris
Hermansen <A
href="mailto:chris.hermansen@timberline.ca">mailto:chris.hermansen@timberline.ca</A><BR>tel+1.604.714.2878 \
· fax+1.604.733.0631 · mob+1.778.840.4625<BR>Timberline Natural Resource Group ·
<A href="http://www.timberline.ca">http://www.timberline.ca</A><BR>401 · 958
West 8th Avenue · Vancouver BC · Canada · V5Z
1E5<BR><BR>_______________________________________________<BR>postgis-users
mailing list<BR>postgis-users@postgis.refractions.net<BR><A
href="http://postgis.refractions.net/mailman/listinfo/postgis-users">http://postgis.refractions.net/mailman/listinfo/postgis-users</A><BR></FONT></P></BODY></HTML>
_______________________________________________
postgis-users mailing list
postgis-users@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
--===============7579536897634103480==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic