geohashTools NEWSgh_decode accepts and efficiently processes factor input by only decoding each level one time, #17. If you’re likely to have a fair number of duplicate geohashes in your input, consider storing them as a factor for efficiency. In a few representative on 5-20M-size datasets, I saw roughly 5x speed-up from this approach; however, the time to convert from string to factor out-weighed this gain, so it’s best deployed on data where the geohashes are stored as factor anyway.gh_decode errors early on non-ASCII input to prevent out-of-memory access, #19.
Dependency upgrade of r-spatial to PROJ 6 revealed a test failure in geohashTools that has now been corrected, #23. Thanks @rsbivand for his diligence and proactivity in identifying the failure, to @Nowosad for providing helpful Docker images for testing, and @mdsumner for helpful comments.
Input with longitude< -180 (which should be wrapped again around the Earth) was calculated incorrectly, #27.
mockery from Suggests. It may later be restored, but currently it’s not used.gh_neighbors incorrectly returned NA for geohashes whose first component is a boundary but whose higher components do indeed have neighbors, #14.gh_covering works with input from sf. Thanks to @dshkol for the PR.gh_covering failed on input with missing proj4string, #13. Thanks @dshkol for the report.CRAN submission again detected memory issues (accessing memory beyond which was declared for an array), reproduced & fixed for #6; the original fix also led to an uninitialized access error, #12.
CRAN submission also detected a type mismatch error, #11.
gh_covering for generating a covering of an input polygon in geohashes, #4.CRAN submission detected some memory issues in the C++ code which have now hopefully been fixed for #6.
gh_to_spdf failed with duplicate inputs, #8. Duplicates are removed with warning.
gh_neighbors('') failed, #9.