Switch to sint32 for coords

[mourner]

Since we use 1e6 encoding, it might make sense to switch coords from int64 to int32 for better geometry compression.

int32 range is -2147,483,648 through 2147,483,647, which is plenty of headroom for the usual -180..180 plus a handful of repeating worlds. We probably should not care about other CRS because it's going to be ditched out of the GeoJSON spec.

[mourner]

Actually, if we use delta encoding, we need sint32 instead of int32 to use zigzag encoding: https://developers.google.com/protocol-buffers/docs/encoding

[brendan-ward]

From my testing, using sint64 only had an effect on resultant file size using protocol-buffers not the current implementation on ProtobufJS (it appeared to be silently ignored there). Not sure about the effect of sint32, I didn't test that.

I'm in favor of this change.

[mourner]

@brendan-ward interesting! one more reason to switch to protocol-buffers. The size different will be huge once we do #23.

[kkaefer]

@mourner there's no difference in the on-wire represenation between sint32 and sint64. The only difference is for implementations, e.g. Google's Protobuf implementation provides a int64 when decoding (and requires one when encoding). For JavaScript implementations, there should be no difference since all numbers are stored as doubles anyway (or as int32 if they're small integers, depending on the JS implementation).

[mourner]

@kkaefer yeah, I originally meant int64 to int32, and there would be difference for negative numbers, but then learned about zig-zag encoding of sint. We can do either sint32 or sint64.

[mourner]

Closing in favor of #27