[geos-devel] [GEOS] #959: Reversed result in GEOSClipByRect

[GEOS]

#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).