s2 cannot handle more than 2^31 - 1 vertices in polyline/polygon

[MBkkt]

https://github.com/google/s2geometry/blob/master/src/s2/encoded_s2point_vector.h#L131

Access by int, uint32 size_, by size encoded and decoded as size_t

So in general s2 cannot handle more than 2^31 - 1 vertices in polyline/polygon :(

It looks pretty easy to fix and also looks like current encoding/decoding can handle this.

Do you plan to fix this?

[smcallis]

I'm sure that we could, but no one's asked before, so you plan to have more than 4B vertices? That's ~96GB of vertices in a single polygon.

[MBkkt]

I agree it's not very realistic, but at the same time it is just strange.

Also I think it is possible in more simplified case:

For an example if you have just a lot of points, and you just want to serialize/deserialize it.

Best way which I see now is using: s2coding::EncodeS2PointVector and EncodedS2PointVector

In both cases it's impossible to use something more larger.

Also it's smaller count of bytes, it's maximum without compression 2^31 * 2^3 * 3 = 48GB

[smcallis]

Makes sense, I can get it fixed but I'll do it internally for the next release since it doesn't sound urgently needed.

[MBkkt]

Nice, thanks!

[jmr]

There are a lot of int/int32s. How extensively are you going to change them?

Do we ever have enough array indexes stored so that changing the type is going to blow up the memory use and halve the cache efficiency?

I see some typedefs in S2Builder: https://github.com/google/s2geometry/blob/efb4eb8d0cbe8ddcf68a8600ab217129a2d94283/src/s2/s2builder.h#L737

[MBkkt]

I agree it a lot of places, I just noticed difference between serialization and runtime and decide to ask, do you plan to fix runtime or not

[smcallis]

TBD, I'll have to poke around and see how big of a lift it would be, it might not be worth the trouble.