-
Notifications
You must be signed in to change notification settings - Fork 20
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
Allow parsing arbitrarily long geohashes. #42
Comments
Do you know whether it involves a change to the decode_bbox logic or just to its length check? |
I think that just removing the length check would cause problems, since the first 4 characters would get ignored (in the instance above of a 16 length hash) rather than the last 4, which is undesirable. Checking if the string is longer than 12 characters and then truncating it if it's too long should work for this purpose, but I do wonder if it might have some undesirable consequences in situations where the hash being too long is in fact an error that the user wants to catch. |
I no longer work at the company that used this, but maybe @ceejbot would have an opininion. My personal take: add a different function for parsing bounded ones, allow arbitrary by default (unless the geohash spec says otherwise, I don’t recall). |
This would make backwards compatibility nicer. I know precision wise it is pointless but we have some 16-length geohashes lying around and limiting to 12 is going to make migrating more difficult.
The text was updated successfully, but these errors were encountered: