On Tue, Nov 24, 2020 at 3:44 PM Paul Ramsey <pram...@cleverelephant.ca> wrote:
> > - Am I right that Z coordinates are nearly done? What's the status there? > I'm going to say that the JTS Z work is functionally complete. It interpolates Z values where possible, and populates missing Z values from an ElevationModel patterned after the one currently in GEOS. I think GEOS does interpolation along a line as well, but that seems questionable to me, so have not implemented that. So the final step is to finish porting the JTS code to GEOS, and then try out the code in PostGIS. No idea how that will match up to the Z unit tests in PostGIS - but I'm not sure they are based on any actual requirements anyway? > > The success is the SimpleSTRtree, which is just the current STRtree but > without the inheritance structure and with the nodes stored all next to > each other in contiguous memory for more locality. For at least one use > case I've seen 20% speed-ups on overlays, using the SimpleSTRtree in place > of the STRtree inside the MCIndexNoder. I have not seen any slow-downs. I > have pushed the SimpleSTRtree into master. > > Nice work. > > All the performance talk is mostly because JTS still runs a lot faster > than GEOS for some bulk processing. My current test is a big union of > watershed boundaries, about 6MB of data, which takes about 20s under GEOS > and about 25% of that under JTS. It's a big gap, and in theory the two > code bases are pretty aligned right now. Same overlayNG engine, etc. So I > figure there has to be a big implementation ball of performance hiding > under the covers somewhere. No luck thus far. > That's quite a difference. Maybe the JVM JIT really is magic?
_______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
