We're storing spot locations as int64 (and maybe more) - should be sth smaller

[timtreis]

No description provided.

[LucaMarconato]

Good point, int32 should be more than enough. Also, according to this scverse/spatialdata#187, int64 are not available in JS, another reason to use int32 (please @ilan-gold confirm this).

[timtreis]

@ilan-gold had strong opinions on this in general - and realistically we can probably get away with sth that covers all use cases? Maybe we could automatically do that within spatialdata-io. Wdyt?

[ilan-gold]

@LucaMarconato unbenkownst to me 64 bit integers were available in JS before scverse/spatialdata#187, but not by very long so a lot of software didn't handle them (yet and still). I can implement a fix for this specifically in vitessce, no problem. but in general, i think this should perhaps be checked a bit? maybe even just warning people? it's double the data for little good reason. For example, you could provide a global setting to allow people to opt-in to writing as 32 bit integers (and then switch it to 32 bit by default after a period of time)

I wouldn't say this is a blocker,but more a suggestion/RFC