| 68 | | strk: there's both triangulation and topology in postgis, not a single function, you'd have to write that one, on your needs. I think plpgsql could do, it really depends on your need for speed ST_SplitByGrid() ST_SplitToMaxN() SplitToMaxN has multiple solutions, so harder to generalize. |
| | 68 | strk: there's both triangulation and topology in postgis, not a single function, you'd have to write that one, on your needs. I think plpgsql could do, it really depends on your need for speed ST_SplitByGrid() ST_SplitToMaxN() SplitToMaxN has multiple solutions, so harder to generalize. SplitToMaxN could be implemented with a sweep line, for example. a vertical line that moves from leftmost vertex toward right direction, as soon as it seen enough points it cuts. we have ST_Split already, to split a polygon by a line. sweep would be performed by taking all vertices, ordering by X and positioning the line to the Nth point... |
| | 69 | |
| | 70 | nhv: understood but if one was to use a quadtree splitting cells where needed to satisfy maxN constraint ... is best of both worlds no ? but you are very likely to end up with long skinny objects which would be avoided in a quadtree solution |
| | 71 | |
| | 72 | dbb: I dont think people care about blazing performance for this one.. I think it is the utility that is first |
| | 73 | |
| | 74 | strk: the characteristic would be that of max "size", not max "extent" |
| | 75 | |
| | 76 | nhv: irregular tiles are ok I just like to avoid long skinny things when possible, they often have numerical issues |
