Changes between Version 1 and Version 2 of SomeSplitting

Timestamp:

Mar 7, 2013, 3:26:30 PM (11 years ago)

Author:

darkblueb

Comment:

—

SomeSplitting

@@ -13 +13 @@
 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
+