Hi!

I've merged bramp's speed optimization to encodeHash() and I've replaced hashLengthToCoverBoundingBox(). The latter is now 100 times faster (and creates fewer objects). What I did is just to mimc encodeHash algorithm until the point the results would differ counting the number of bits. I then return that number / 5 (rounding down).

All tests pass and I've also created a small program comparing the results between the old hashLengthToCoverBoundingBox and the new, using random values. No differences after 400,000 samples.

Thanks!

I'm not sure whether this is an intentional design decision, but I expected that I could get back my original geohash String when I encode the decoded base32 long. This is useful for systems that wish to store a geohash as a long and later recover it as a String.

The issue is pretty simple. Base32.encodeBase32(Base32.decodeBase32("0000")) returns "0". The encodeBase32 function needs to prepend the result with zeros to the desired length. Then the correct geohash String can be recovered.

We cannot use GeoHash.coverBoundingBox method with a bounding box around antimeridian (180/-180) because it does not allow bottomRightLon to be lower than topLeftLon (Google Maps behavior) or it does not handle correctly longitude outside [-180, 180] range (Leaflet behavior).

This pull request addresses this use case and also fixes issues in #25 and #34.

Now the GeoHash.coverBoundingBoxLongs method allow more longitudes values in input. For instance, these values are accepted (see unit tests):

• topLeftLon = 156 and bottomRightLon = -118
• topLeftLon = -204 and bottomRightLon = -121
• topLeftLon = -703 and bottomRightLon = 624

Hi !

We're using the GeoHash.hashContains with 2 to 4-char geohashes and are seeing that the static method heightDegrees comes up as a Hot spot during our CPU sampling with VisualVM. I noticed this method is synchronized so I was wondering if it may be a good idea to pre-calculate all MAX_HASH_LENGTH (12) values in a static way so you can remove the synchronization ?

Is this something you may consider changing ?

Thanks Regards

As requested by @abrin.

David, As I use it a bit, it might be nice to expose both "length" and “max” to the encode functions. Right now, one has to make the choice between either having a number of hashes or a max length of a hash. But, if you’re selecting a larger region it likely becomes important to have access to both.

thanks,

adam

Hi, I've been having some issues with generating Geo Hashes of points and then of bounding boxes that I would expect to share a prefix. E.g. this fairly arbitrary point in New Mexico ( 35.37322998046875, -108.7591552734375) should be contained in a rough bounding box of the United States (13.923403897723347, -126.91406249999999 x 55.37911044801047, -74.1796875 ). Am I doing something wrong?

thanks

Unit test below:

package org.digitalantiquity.skope;

import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertTrue;

import org.apache.log4j.Logger;
import org.digitalantiquity.skope.service.LuceneIndexingService;
import org.junit.Test;

import com.github.davidmoten.geo.Coverage;
import com.github.davidmoten.geo.GeoHash;
import com.github.davidmoten.geo.LatLong;

public class ShapefileParserTest {

    private final Logger logger = Logger.getLogger(getClass());


    @Test
    public void testHash() {
        double x1 = -126.91406249999999;
        double y1 = 13.923403897723347;
        double x2 = -74.1796875;
        double y2 = 55.37911044801047;

        logger.debug(String.format("start (%s,%s) x(%s,%s)", x1, y1, x2, y2));
        String point = "9w69jps00000";
        LatLong latLong = GeoHash.decodeHash(point);
        logger.debug(latLong);
        String hash2 = GeoHash.encodeHash(35.37322998046875, -108.7591552734375);
        assertEquals(hash2, point);
        logger.debug(hash2);
        Coverage coverage = GeoHash.coverBoundingBox(x1,y1,x2,y2,4);
        boolean seen = false;
        logger.debug(coverage);
        for (String hash : coverage.getHashes()) {
            if (hash.equals(point) || point.startsWith(hash)) {
                logger.debug(hash + " -> " + GeoHash.decodeHash(hash));
                seen = true;
            }
        }
        assertTrue("should have seen hash",seen);
    }
}

Hi, I have another patch =)

By internally representing hashes as longs I could make coverBoundingBox() faster. In my laptop I could speeed that function from 5.8 µs to 2.6 µs (123 % faster). (In an Android app times are significantly higher, of course)

The long representation I use for geohashes is directly tied to the algorithm and it's incompatible with the representation used in Base32.

This representation is: Starting from the most significant bits I use each 5-bit group as each geohash character and I use the remaining 4 least significant bits to encode the hash length. That allows for hashes upto 12 characters (because 12 * 5 + 4 = 64). I think this representation is also well suited to dababases, as the ordering is the same as the string values.

I had to add a CoverageLongs class, but it's not public (it could be at some point, I think).

Thanks!

I might be using this incorrectly, but when I do

double topLeftLat = 90d
double topLeftLon = -179d
double bottomRightLat = -90d
double bottomRightLon = 180d
Coverage c = GeoHash.coverBoundingBox(topLeftLat, topLeftLon, bottomRightLat, bottomRightLon, 1);

I would have expected c.getHashes() to contain the 32 single-character Geohashes (i.e., 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, b, c, d, e, f, g, h, j, k, m, n, p, q, r, s, t, u, v, w, x, y, z).

Instead, it contains only 0, 2, 8, b.

At lat/lon 0,0 the output of geohash should be s00000000000 to match geohash.org and PostGIS ST_GeoHash function.

=> select ST_GeoHash(ST_SetSRID(ST_MakePoint(0,0),4326),12);
  st_geohash  
 s00000000000

Similar issue was fixed in PostGIS to match geohash.org: Reference: http://trac.osgeo.org/postgis/ticket/2201

Also: Add asserts for hashes around boundary/pole conditions.

Bumps spotbugs-maven-plugin from 4.6.0.0 to 4.7.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps spotbugs-maven-plugin from 4.2.3 to 4.6.0.0.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

First of all, I'd like to say that it's really a pleasure to use this library.

I am having a use case for which I need to identify "border cells" below a certain distance, e.g. all cells with resolution of about 2.4x2.4 m^2 (geohash lenght = 9) on the border between cells "b" and "c".

What I would require in this case is, being able to extract all cells of geohash length n+1 (e.g. lenght 2 starting from cells of length 1) by direction, so to have the rightmost column of sub-cells in "b" of geohash length, say, 9, and the leftmost column of subcells of "c" of the same geohash length.

Looks like there is a dependency reference on java.awt in the library. Although this isn't an Android library, it might be handy to clean up this kind of reference.

Package not included in Android ../../../../../.gradle/caches/modules-2/files-2.1/org.apache.commons/commons-math3/3.2/ec2544ab27e110d2d431bdad7d538ed509b21e62/commons-math3-3.2.jar: Invalid package reference in library; not included in Android: java.awt.geom. Referenced from org.apache.commons.math3.geometry.euclidean.threed.PolyhedronsSet.RotationTransform. ../../../../../.gradle/caches/modules-2/files-2.1/com.github.davidmoten/grumpy-core/0.2.2/48b4cff02a62a3a9ea876dd2486225aefd225706/grumpy-core-0.2.2.jar: Invalid package reference in library; not included in Android: java.awt. Referenced from com.github.davidmoten.grumpy.core.Position.

Hi, and great job.

I use geohashes for land polygons and I want geohashes that can be merged, to merge them to a bigger one. Is there a way?

like the Georaptor does (https://github.com/ashwin711/georaptor )

..for hash "u".

result = {ArrayList@3156} size = 8 0 = "g" 1 = "v" 2 = "b" 3 = "s" 4 = "z" 5 = "e" 6 = "c" 7 = "t"

g u v e s t seem to be OK. I could imagine, that u meets b, c and f over the pole. But what about "z"?

Regards

It will be great to have a BoundingBox object with: area; southwest.latitude; southwest.longitude; northeast.latitude; northeast.longitude etc etc, keep the good work