Open MBkkt opened 1 year ago
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.
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
Makes sense, I can get it fixed but I'll do it internally for the next release since it doesn't sound urgently needed.
Nice, thanks!
There are a lot of int
/int32
s. 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 typedef
s in S2Builder
: https://github.com/google/s2geometry/blob/efb4eb8d0cbe8ddcf68a8600ab217129a2d94283/src/s2/s2builder.h#L737
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
TBD, I'll have to poke around and see how big of a lift it would be, it might not be worth the trouble.
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?