> > > > > About the union question, probably no good news there, unless your data > has some very unlikely characteristics. The GEOS Cascaded Union approach > is remarkably efficient at unioning sets of overlapping polygons - which it > sounds like you have. The other alternative hack is to run buffer(0), but > it is unlikely to be faster. > > Ok, thanks for the confirmation. Is there any benefit in "batching" > sets of geometries to cascaded union (e.g. unioning 100 geometries in > sets of 10, and then doing a final union of the result)? Or best to > throw EVERYTHING at GEOS and let it sort it out? >
Best to let GEOS handle it. It uses a spatial index to choose sets of polygons to union. It's unlikely you could do this better (unless there is some characteristic of the data you can take advantage of) > > > IF the data was a true polygonal coverage (i.e. strictly > non-overlapping) then there is a faster approach in GEOSCoverageUniion. > [1]. But if you are trying to find gaps then it's likely your data is not > a true coverage. > > Interesting. I have one application which would definitely benefit > from this. GEOS 3.8 looks to be a very exciting release..! One thing I > couldn't determine from the coverage PR and the docs of the new > operation is what happens when the data **isn't** a non-overlapping > coverage. Is the result total garbage in this case or is an exception > raised? Are holes/non-contiguous parts allowed? > > It looks like GEOSCoverageUnion is able to detect non-fully-noded inputs [1] and overlaps [2], and throws an exception in this case. I would think holes and non-contiguous parts are fine as input. [1] https://github.com/libgeos/geos/pull/158/files#diff-7cd9f5f9244e77677b80591da3d99207R94 [2] https://github.com/libgeos/geos/pull/158/files#diff-7cd9f5f9244e77677b80591da3d99207R123
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel