Closed willcohen closed 6 years ago
probably want to have native java version as well, as the current implementation seems to be a wrappen around the C lib.
Yeah I'd be happy to add this as long as the deps aren't too crazy. I'd love to see it added as a new namespace and if the implementation can be relatively parallel to the existing geohash one that would be nice.
I did not find a native java implementation from a brief web search.
I think their published JAR has the compiled binary packaged into it as a resource, so users shouldn't, AFAIK, need the native deps for the underlying library. I suppose it could make for a large JAR if it has all those binaries loaded into it, but maybe it's not too bad.
Seems like they have pretty good OS Compatibility.
The dependency is about ~700 KB with the native libraries embedded. For comparison, JTS is ~800 KB, spatial4j is ~200 KB, proj4 is ~1.7 MB (the projection databases themselves are the bulk of that).
@mprins, is the concern with the C wrapper that it excludes an OS/architecture you're hoping to use, or just generally trying to keep the implementations pure java?
Android on x68, any arch on OpenBSD are my main concern. If the dependency is optional it won't be a problem
A work-in-progress PR is at #22. Still needs tests, but these are the most immediately interesting functions I see so far. It allows for converting points to H3 cells and vice versa, finding bordering rings of cells, getting a JTS object of a cell's hexagonal boundary, getting all cells to polyfill a Shapelike at a given resolution, and functions to compact and uncompact lists of cells.
There's some more advanced functionality involving directional edges, contiguous shapes, and so on, but I'm not sure if that all needs to get added immediately.
Things to note:
GeoCoord
, which is a small coordinate/point analog. The H3 cells themselves exclusively exist as long or integer indices, which then get passed into the various library functions. While this library will be able to do things like pass shapelikes into functions, this means that there's no exact geohash equivalent to get added to Shapelike.GeoCoord
exists in geo.spatial
now, nothing calling the native functions exists outside of the new geo.h3
namespace -- this should mean that anyone who doesn't want to use the native libraries can just ignore this namespace and go about their business.Closing with #22's merge.
Do you have interest in including support for h3 (java here) as a hexagonal alternative alongside geohashes? Hex grids are one of the spatial operations where I’m currently dropping down to postgis, and the hierarchical structure of these is pretty neat. If so, happy to take a stab at initial support — there’s a lot of functions in there with parallels to some of this library’s geohash functions, but might be good to start with adding it to shapelike, getting points in and out, and taking it from there.