Topology functions should be tolerance aware

[robe]

In testing functions like ST_NewEdgesSplit, I am reminded that the topology functions don't seem to consider the tolerance that was put in for a topology.

For example I created a topology with tolerance of 0.5 meters.

e.g. if I had an edge like this

ST_GeomFromText('LINESTRING(227575.8 893917.2,227591.9 893900.4)', 26986);

And tried to split at

ST_GeomFromText('POINT(227578.909683258 893913.955113122)', 26986)

I get an error its not on the line yet if I take the distance between the 2 --

SELECT ST_Distance(ST_GeomFromText('POINT(227578.909683258 893913.955113122)', 26986), ST_GeomFromText('LINESTRING(227575.8 893917.2,227591.9 893900.4)', 26986));

I get 0.

Wondering if we should replace our use of ST_Within when comparing a linetring to a point (and ST_Intersects) with ST_DWithin(_tolerance)

Or are there changes in GEOS that will make this work?

[strk]

It'll be a long way to make them all tolerance aware, so it's likely worth setting up a marker like you have for Z index support of postgis function (in the manual).

For each function we'll need to think the actual behavior. For ST_NewEdgesSplit, for instance, I guess we'll want to Snap the point to the edge. Or, in general, always snap what comes later with what's already registered in the topology. Does it sound fine ?

DWithin is surely good to use for the conditional part. I've started adding its use in some topology functions already, altought I havne't yet parametrized the actual distance (not worth unless the tolerance is _fully_ considered, not just on the conditional part)

[robe]

sounds fine to me

[nicklas]

Hallo

I see the great possibility to use ST_Dwithin to handle the tolerance. But I think it is quite a lot slower than ST_Intersects. I am not sure, but the rute force way of calculating that we do when geometries are this close to each other is slower than ST_Intersects.

My point is that it would be interesting if Paul's idea : ​http://postgis.refractions.net/pipermail/postgis-devel/2009-December/007710.html about ordering the vertex points in some sort of tree, would become reality. I have npt thought much about it but suspect there might some questions about if the tree should be stored or recalculated.

Paul, are you planning to implement this? If so, for which version?

It would be very nice to get some speed on distance calculations also with overlapping bounding boxes.

The need of tolerance awareness is a great reason to put effort on that.

/Nicklas

[strk]

Sounds like stuff for 2.1

[strk]

With r9395 I added an internal _ST_MinTolerance taking a topology name and an geometry (an extent). The function will lookup in topology.topology.precision and give that value back, while computing a minimum tolerance if topology.topology.precision is still zero.

The extent passed serves the purpose of computing the minimum tolerance, taking into account the floating point nature of the ordinate values and thus the increasing cell size in the precision grid.

Use of _ST_MinTolerance is currently restricted to ToTopoGeom and the auxiliary TopoGeo_AddPoint, TopoGeo_AddLinestring and TopoGeo_AddPolygon.

It'll help having a function (TopologySummary?) check the consistency between a topology tolerance and the minimum tolerance required to account for changes in the outermost boundary of the current topology extent. Also, it may be useful to allow an "extent" parameter into CreateTopology so that the topology tolerance is computed internally.

[robe]

Milestone renamed