-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable precision #25
Comments
We would like to see this as an option too, within bounds. Overall using less precision makes sense to us for some of the data we are considering using this for. Coupled with this, would it make sense to aggregate vertices together that after rounding are no longer different at this level of precision? |
@brendan-ward probably not — we don't want to complicate schema with different-precision vertices and the use case with drastically different-precision data in the same protobuf is minimal. Or are you seeing a benefit in that? |
@mourner Let me try differently, I might have been confused by something you proposed above:
|
@brendan-ward yes, that's correct. I was addressing your "aggregate vertices together" comment. |
@mourner I meant that if the coordinates were unique at their original precision are no longer different when converted to this precision, we could gain efficiency by dropping the duplicate coordinates, e.g.,
But perhaps that's not likely enough to happen in practice that it is worth dealing with. |
@brendan-ward yeah, we can dedupe in encoding easily. |
Closing in favor of #27 |
1e6
rounding is hardcoded in geobuf, but some datasets don't loose much with lower precision like1e4
. Perhaps we could make this configurable and also encoded as a property in the format to give more room for geometry compression.Should get more relevant with delta encoding #23, because lower-precision data will have much lower deltas with configurable precision.
The text was updated successfully, but these errors were encountered: