[postgis-users] Wrong result in spatial analysis methods likeintersects due to limited coordinate precision

[Martin Davis]

> JTS seems to have solved the problem, if I got the discussion right.

Nope - JTS has exactly the same behaviour as you're seeing in PostGIS (deliberately, since PostGIS uses GEOS, which is a port of JTS).

There's no immediate plans to enhance JTS to support a tolerance value for predicates, but it's an interesting idea and perhaps one that should be implemented.

I'm just not sure that using a tolerance value is a panacea for bad data.  For instance, what happens if you have data which has very small "zingers" (spikes folded back on the main polygon)?  These would test fine using a tolerance value, but would obviously not be correctly aligned.  This seems to be a complex problem which isn't going to be fixed simply by allowing a tolerance in predicates.

Martin Davis, Senior Technical Architect
Vivid Solutions Inc.      www.vividsolutions.com
Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046


> -----Original Message-----
> From: postgis-users-bounces at postgis.refractions.net 
> [mailto:postgis-users-bounces at postgis.refractions.net] On 
> Behalf Of Sommer Gerhard
> Sent: May 22, 2006 10:06 AM
> To: postgis-users at postgis.refractions.net
> Subject: [postgis-users] Wrong result in spatial analysis 
> methods likeintersects due to limited coordinate precision
> 
> 
> Hi,
> 
> I am using PostGIS 1.1.2 with PostgreSQL 8.1 and I have 
> detected the following inconsistency, which can be 
> reconstructed with the following SQL statements:
> 
> select 
> astext(line_interpolate_point(geomfromtext('LINESTRING(200 
> 340000.00, 600 340100.00)'), 0.7345678965533442)); --Result 
> -> "POINT(493.827158621338 340073.456789655)" select 
> distance(geomfromtext('LINESTRING(200 340000.00, 600 
> 340100.00)'), geomfromtext('POINT(493.827158621338 
> 340073.456789655)')); --Result -> 0.000000000296534992623179 
> select intersects(geomfromtext('LINESTRING(200 340000.00, 600 
> 340100.00)'), geomfromtext('POINT(493.827158621338 
> 340073.456789655)')); --Result -> f
> 
> The last statemant shows that the point, which I have before 
> interpolated on the line, is not on the line according to the 
> "intersects" operation. The reason for this is clear. It is 
> because the precision of any stored ccordinate values ist 
> restricted by the number of bytes available for storage (in 
> double precision this is approximately 15 digits). The 
> problem is also described in 
> http://www.vividsolutions.com/jts/discussion.htm#dimensionalCo
llapse and JTS seems to have solved the problem, if I got the discussion right.

In my opinion the intersects operation and the other spatial anlysis methods should and could always return the correct result. This could be done by defining a fuzzy tolerance (either explicitly as a parameter of the operations or implicitly depending on the precision of data storage). Then, if the point in the above example was within this tolerance, the function would return "true", as it should in this case. In the above example the tolerance could be i.e. 0.000000001.

It would be great, if this could be considered as an enhancement to PostGIS in a future version.

The reason, why this is a problem at our organization is, that when editing polygons, the edges of the polygon are snapped to another polygon. Later we need to test, which polygons are "not disjoint" to the other polygon. But this query often delivers the wrong results, as the snapped points are partly outside and partly inside the other polygon, which results in an intersection, that would not be there, if we had unlimited precision available or if the limited precision would be considered in the PostGIS function.

Best Regards
--
Gerhard Sommer
Magistrat Wien (MA 14-ADV), Rathausstraße 1, 1082 Wien, Austria
E-Mail: som at adv.magwien.gv.at
Tel: +43 (1) 4000 91326
Fax: +43 (1) 4000 99 91326
 
_______________________________________________
postgis-users mailing list postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users