= Discussion of Methods and API for Splitting an Oversize Polygon =

* GEOS performs poorly as a POLYGON increases in number of vertices, even in the simple cases. 

* It is often desirable to "split" a POLYGON with a high number of vertices into some number of smaller POLYGONs. 

* From a user's perspective, some GIS processes result in very large POLYGON, for example 10,000 or 100,000 or more, vertices.  There is a case to be made that PostGIS users would benefit from standard calls to take a single POLYGON as an input,  and output some GEOMETRYCOLLECTION of POLYGON that are "equivalent", disregarding the problems inherent with the numeric precision model used.

* For the sake of discussion. let us assume we are operating on a POLYGON with a single outer ring, that is formally valid.

---

Rough transcript of IRC on 07Mar13:

strk: splitting / gridding ... which one you mentioned was about keeping existing vertices ?
I don't think it's defined, but I just hit another case in which I'd want it to be possibly defined.
rationale is that "split on vertex" introduces NO spatial drift/change.
while "split segment" almost _always_ introduces a spatial difference
pramsey: don't you think we need a general class of "on-vertex" splitting function ?
closestpoint, substring, split, ... what else ?
all functions that "break" any line into smaller components
need a way to be invoked to specify: "no segment splitting please"

pramsey: that seems like a very narrow-bore approach to a particular prob. when the general prob is, we don't have a precision model. so I don't feel super comfortable with a complex semantic of "split, but only in this very particular way"  particularly when the semantic can fall apart and look dumb so easily (hand it a very long segment)

dbb:  ''tries to grok context here''

strk:  well, I've heard people saying: "every vertex has a cost"  they wouldn't be happy with splitting on segments. cost of some operations is per-vertex, not per-length ..  _most_ operations

dbb:  isnt there a case to be made to take a very high number of vertices POLY, and simply provide a call to break it into some number of polys with max N vertices ?  Arc* definitely does this with a simple dialog box, and its a common user problem I think

strk:  that too. can still be done using segment-splitting as the number of added points would likely not affect the overall reduction (I've been using that) BUT, segment-splitting would introduce spatial drift so that putting the "tiles" back together they wouldn't necessarily match