S2RegionCoverer very high RAM consumption on a specific polygon about s2geometry HOT 6 CLOSED

Either looking at the bounding box or the area would have shown that the loop was inverted / something had gone wrong with polygon construction.

I'm a bit confused how the loop could be inverted, since loop.Normalize() is called.

from s2geometry.

What's the underlying problem you're trying to solve? Usually getting a constant-level covering is only good for quick hacks, and a range of levels should be used.

How much memory do you expect it to take? What's the area of the polygon divided by the average level-13 cell area?

You might also try covering the rect bound of the polygon and seeing if that also runs out of memory.

from s2geometry.

What's the underlying problem you're trying to solve? Usually getting a constant-level covering is only good for quick hacks

this is a very small part of a more complex use case that I tried to isolate for bug report

How much memory do you expect it to take? What's the area of the polygon divided by the average level-13 cell area?

I expect close to nothing :) I actually do this for many other polygons, with comparable or bigger area, and it cost nothing.

The fact that the initial candidates are 6 cells (so I guess the entire planet) is really weird and I think this is the root problem

from s2geometry.

from s2geometry.

My first guess would be that your polygon is inverted so it's effectively trying to cover most of the world with L13 cells.
…
On Mon, Feb 5, 2024 at 8:16 AM troussel @.> wrote: What's the underlying problem you're trying to solve? Usually getting a constant-level covering is only good for quick hacks this is a very small part of a more complex use case that I tried to isolate for bug report How much memory do you expect it to take? What's the area of the polygon divided by the average level-13 cell area? I expect close to nothing :) I actually do this for many other polygons, with comparable or bigger area, and it cost nothing. The fact that the initial candidates are 6 cells (so I guess the entire planet) is really weird and I think this is the root problem — Reply to this email directly, view it on GitHub <#350 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGEMKVV5L4XDXFXQEQGB43YSDZTNAVCNFSM6AAAAABC2IOXZOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMRXGIZTCMRVGM . You are receiving this because you are subscribed to this thread.Message ID: @.>

Thank you it look like this is it. I reversed the coordinates before initializing the loop, and indeed the issue disappear, and the general behavior of my system look sane

I was aware of this orientation issue, but since it works with every other examples I think I don't get the fundamental. By reversing the coordinates list before constructing the loop, I would expect that other cases where my code was working before, would suddenly be an issue because they would now cover the planet. But that's not the case so I feel clueless right now.

Anyway thanks !

from s2geometry.

Either looking at the bounding box or the area would have shown that the loop was inverted / something had gone wrong with polygon construction.

I'm a bit confused how the loop could be inverted, since loop.Normalize() is called.

yes indeed thanks. In the end I changed the intermediate step to construct polygon, so I can use the "smallest" loop based on their bounding box

from s2geometry.