[geos-devel] Update to 3.9?

Martin Davis mtnclimb at gmail.com
Wed Nov 25 08:54:49 PST 2020

On Tue, Nov 24, 2020 at 3:44 PM Paul Ramsey <pramsey at cleverelephant.ca>

> - 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

> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20201125/a20fb50b/attachment.html>

More information about the geos-devel mailing list