[postgis-users] PostGIS layer spatial tolerance

[Chris Hermansen]

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 at 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