[postgis-users] fuzzy tolerance

Lars Aksel Opsahl Lars.Opsahl at nibio.no
Wed Sep 14 07:43:46 PDT 2016


Hi


One generic problem with adjusting input coordinates is that this mayl not solve the problem with overlapping or invalid polygons, because points in the center of a cell may go to any 4 grid points.


For example if you have two simple feature polygons that are suppose to have no gaps or overlap between them where they touch each other. Since this is simple feature the common part is not one object. If the common line is in the middle of grid cell then you may get overlaps or gaps.


You can say that the probability for this is very low and you may also say that there is bug in the input data when the common borders part don't have the same coordinates, but to compute this common part is not straight forward.


Another problem is also that a polygon that was valid on the client may not be invalid when saved on the server, because the points are moving.


We have used some snapTo in Java (JTS) but only when got a Topology Exceptions from the JTS in Java doing it like below. The polygonSnapRounder was code I got from Martian Davis some years a go. But one problem with this coding is that it makes the code more complicated and you may also cover up for bugs that are real or introduce new bugs.


try {

result = bigPolygon.intersects(areaToRemove);

} catch (com.vividsolutions.jts.geom.TopologyException e2) {

bigPolygon = snapRoundIntersecton(bigPolygon,areaToRemove, snapPM);

}


public static Geometry snapRoundIntersecton(Geometry a, Geometry b, PrecisionModel snapPM) {


Geometry aFix = PolygonSnapRounder.snapRound(a, snapPM);


Geometry bFix = PolygonSnapRounder.snapRound(b, snapPM);


return aFix.intersection(bFix);


}


So my point is that changing input data or to handle Topology exceptions is not an easy task and it's no guarantee for avoiding all problems as far as I can understand. This is one of the reasons that I started to look into Postgis the Topology work by Sandro Santilli.


Lars


________________________________
Fra: postgis-users <postgis-users-bounces at lists.osgeo.org> på vegne av Willy-Bas Loos <willybas at gmail.com>
Sendt: 14. september 2016 12:52
Til: PostGIS Users Discussion
Emne: Re: [postgis-users] fuzzy tolerance

On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <sfkeller at gmail.com<mailto:sfkeller at gmail.com>> wrote:
There is at least SnapToGrid:
# select ST_SnapToGrid((ST_DumpPoints(mypoly.geom)).geom, 0.1) from mypoly;

:Stefan

Hm, i considered that before, but now i can't say why i discarded the thought.
One thing is that the unit for snaptogrid is degrees for WGS84, so for world data that would pose a problem: you're not using a uniform grid to snap to.
But in other coordinate systems, and if the algorithm is fast enough, one could use this in a trigger and always store geometries snapped to a 10cm grid. That would be precise enough for our data.
It is easy to understand what is happening too, so that is an advantage.
BTW i tested and saw that it's not necessary to dump the points, you can snap the whole polygon.

Any words of warning about using a trigger and storing the data on a 10 cm grid like i suggest?

Cheers,


--
Willy-Bas Loos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20160914/1c8c854c/attachment.html>


More information about the postgis-users mailing list