#959: Reversed result in GEOSClipByRect
-------------------------+---------------------------
Reporter: Algunenano | Owner: geos-devel@…
Type: defect | Status: closed
Priority: major | Milestone: 3.5.2
Component: Default | Version: 3.5.0
Severity: Significant | Resolution: invalid
Keywords: |
-------------------------+---------------------------
Comment (by mdavis):
Replying to [comment:7 Algunenano]:
> It doesn't make much sense to port that clipping algorithm without the
whole paraphernalia (quick validation with int coordinates).
Ok, so any replacement/improvement to GEOS-based MVT clipping has to
produce valid integer geoms.
> I found and even harder issue around mvts today [1] where making a
polygon valid changed some of its coordinates to floats (against the mvt
spec), then snapping them to ints turned it invalid (against the mvt
spec), and so on.
>
Not totally surprising. MakeValid operates at full precision, and can
introduce new vertices. And because it is using full precision, the
output will not necessarily be valid when snapped to lower precision.
The JTS (and probably GEOS) operations can actually specify a precision
model, which might solve this problem. It would have to be exposed by
MakeValid, however. And MakeValid is doing a LOT of complex processing,
so not sure that's even feasible. Also, for the kind of invalidity
produced by brute-force clipping to a rectangle (as in quick_clip),
MakeValid is probably overkill. It might be possible to just node the
clipped linework (using int precision), and then polygonize. I will try
and experiment with this. If that works, it would provide a fairly simple
GEOS-based rectangle clipper for MVT use.
--
Ticket URL: <https://trac.osgeo.org/geos/ticket/959#comment:8>
GEOS <http://trac.osgeo.org/geos>
GEOS (Geometry Engine - Open Source) is a C++ port of the Java Topology Suite
(JTS).
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
