[geos-devel] Update to 3.9?

[Joris Van den Bossche]

Hi all,

On the CI of PyGEOS we have a build testing against GEOS master, and
somewhere in the last 4 days, a lot of the STRtree tests started failing
(see eg https://github.com/pygeos/pygeos/runs/1465460418#step:9:86).
Looking at the commits of the last days, this might be related to the
SimpleSTRtree work?

A small (python) example of a tree consisting of a single point, which no
longer is returned when querying the tree with a big polygon that certainly
contains the point:

Using released version of GEOS:

>>> import pygeos
>>> pygeos.geos_version
(3, 8, 1)
>>> point = pygeos.Geometry("POINT (2 3)")
>>> tree = pygeos.STRtree([point])
>>> tree.query(pygeos.box(0, 0, 10, 10))
array([0])

This is correctly returning the index of the single point. But when running
with the latest GEOS master, the query doesn't find any point of the tree:

>>> import pygeos
>>> pygeos.geos_version
(3, 9, 0)
>>> point = pygeos.Geometry("POINT (2 3)")
>>> tree = pygeos.STRtree([point])
>>> tree.query(pygeos.box(0, 0, 10, 10))
array([], dtype=int64)

Are there changes expected in how the STRtree C API functions or required
changes in user code? Or maybe we are using it in some incorrect/unexpected
way? (code is at https://github.com/pygeos/pygeos/blob/master/src/strtree.c)

Best,
Joris


On Wed, 25 Nov 2020 at 00:44, Paul Ramsey <pramsey at cleverelephant.ca> wrote:

> Hey all, just truing up what's underway and nearly there...
>
> - Am I right that Z coordinates are nearly done? What's the status there?
>
> I've been trying to address some performance issues, with some success and
> some ... other things.
>
> 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.
>
> While I have implemented the nearestNeighbor() functionality on the
> SimpleSTRtree, I haven't hooked it up to anything yet. It could go into the
> IndexedFacetDistance, if anyone is super enthusiastic about it. From there
> it would affect searching in PreparedGeometry of various sorts.
>
> I also tried using a similar trick with the MonotoneChainBuilder that sits
> inside the MCIndexNoder, replacing individual heap allocations with slabs
> by putting objects onto a std::deque, and incidentally stripping out some
> book-keeping. While that seems to pick up about 3-5% speedwise,
> unfortunately something about my implementation is incorrect (and in a
> wonderfully subtle way) as it fails testing on some platforms (not mine).
> https://github.com/pramsey/geos/tree/monotone-chain-builder
>
> I've put that work to the side for now.
>
> 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.
>
> I think we're close, looking forward to release :)
>
> P
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/geos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20201128/f3984cac/attachment.html>