Centicule support

[GoogleCodeExporter]

What steps will reproduce the problem?
1. The geohash is too damned far today!
2. I don't feel like burning anymore fossil fuels.
3. Biking to the closest centihash seems more reasonable sometimes.

What is the expected output?  What happened instead?
I'd like to see another page for centicules similar to what you already did for 
the globalhash. You could overlay the map with the requisite 10x10 grid lines 
(optional) instead of drawing 100 crowded flags. Then when the user clicks on a 
centicule <insert helpful color flash feedback here>, you could display The 
Algorithm applied to a tenth of a graticule and place the flag icon there.

What version of Geohash Droid are you using?  On what phone?
0.7.15 on Nexus One

What version of Android is running on that phone, if you know?
2.3.7

Please provide any additional information below.
If it's good enough for JBQ, it should be good enough for anyone!

Original issue reported on code.google.com by pacob...@gmail.com on 13 Apr 2012 at 6:51

[Lee-Carre]

Being in the Channel Islands (graticule 49,-2) means that most hashpoints are on open water. Only occasionally will one be on land.

Centicules would remedy this.

[sporksmith]

I also would like this a lot, for same reasons as OP.

Would you amendable to a PR adding this support?

[CaptainSpam]

Sure, I'd be amenable to a PR for it. The main thing that's been stopping me all this time (apart from various life stuff) is that I don't really know what the workflow, so to speak, for a centicule expedition is. Are centicules decided on as a sort of last-minute thing, or are they normally just planned out the same as a graticule or globalhash is?

Whatever the case, I'll check out a PR, sure. I might tweak it for UI purposes, of course, but I'll give it a look when I get the chance.

[sporksmith]

Thanks for the feedback!

I'm not sure what you mean re last-minute vs planned-out...?

For me, my ideal workflow is something like:

• Open the app sometime after relevant DJ opening
• Check to see if the "regular" geohashpoint is reachable with my intended mode of transportation and time constraints
• If not, check my centicule hash point (and maybe neighboring centicule hash points)

Maybe it'd make sense to put this into the "graticule" menu, which is also how we currently view the globalhash? e.g. the coordinates fields could accept decimals, and there could be a new button/checkbox next to the globalhash box to see centihashes.

Generally when viewing centihashes I'd expect the UI to work mostly the same as for regular hash points, though with no wiki support.

Whatever the case, I'll check out a PR, sure. I might tweak it for UI purposes, of course, but I'll give it a look when I get the chance.

I'm an experienced developer but not an experienced app developer, so I don't have a great idea of how much work this would end up being or how realistic it is for me to hack it up, but good to know that at least you don't hate the idea before bothering to dig further :). And definitely open to further discussion about what the UX ought to look like.

[sporksmith]

Btw here's the wiki page re centicules including sample code: https://geohashing.site/geohashing/Centicule

[CaptainSpam]

Hmm... well, a workflow like that makes sense. I can picture that going in the current graticule picker screen, yeah, though my first instinct would be to convert the globalhash checkbox into a dropdown with options for graticule, centicule, and globalhash. I'm thinking that would be easier to enforce adding a decimal if the user wants a centicule that way, rather than trying to work out what to do with weird input cases like "37 -122.3".

Besides that, if I'm understanding the centicule parser correctly (the link to a visualizer in that wiki page appears to be 404'd), it uses the same hash input as normal graticules and geohashing, correct? And the resulting fractional portions are just placed after an additional decimal place? For instance, using the hash from the original comic, which resolves to 0.857713 and 0.544543, applied to centicules of 37.5N 122.3W would result in a point of 37.5857713N 122.3544543W (as opposed to the graticule point of 37.877713N 122.544543W), right?

If so, this likely wouldn't be too much of a problem, though it would require a bit of tweaking to some of the data classes, which I originally designed strictly around graticules. I'm not immediately at a point where I can go back over my code in detail to work out what would need to be changed, but on first glance Info, Graticule, and HashBuilder would need changing, as well as potentially anything that uses those. The actual stock fetching wouldn't need changing, and neither would the actual hash calculation, but I think HashBuilder has utility methods that work out latitude/longitude given a Graticule. I'm pretty sure Graticule can be expanded upon to add centicule data (i.e. a boolean flag and a couple more ints), it'd just be making sure everything is refactored correctly.

That'd be the basics, at least. Once I've got some time, I can look more into it.

[sporksmith]

my first instinct would be to convert the globalhash checkbox into a dropdown with options for graticule, centicule, and globalhash.

:+1:

I'm thinking that would be easier to enforce adding a decimal if the user wants a centicule that way, rather than trying to work out what to do with weird input cases like "37 -122.3".

:+1:

it uses the same hash input as normal graticules and geohashing, correct? And the resulting fractional portions are just placed after an additional decimal place?

Yup, that's my understanding.

If so, this likely wouldn't be too much of a problem, ...

Cool! Thanks again! I might try poking at it some weekend but I'd be very happy if you beat me to it :smile:

[CaptainSpam]

It might be a bit slow on my end, as I tend to give myself too much to do in general (and then don't wind up doing most of it...), but I've dived back into my code a bit to come up with a plan.

The main issue I'm seeing is that the Graticule class was designed very much around it being strictly based on whole graticules, and there's a few points in code where that assumption is being used in math (picking the surrounding graticules for the map, figuring out what graticule has the closest point, etc). The biggest offenders here are the getLatitude() and getLongitude() methods, both of which are assumed to return ints. Thankfully, those aren't used much; the better-suited getLatitudeString()/getLongitudeString() are a more general-case solution, and neither technically require isSouth()/isWest() to resolve the Prime Meridian/equator problem.

So I'd say the first step is to generalize Graticule into an abstract base class (or interface). I kinda want to call it Somethingicule, as I don't have a better name for it. Eventually, Centicule will extend/implement Somethingicule.

A part of that will be to change it so that anything that involves math on a Graticule happens in Graticule itself. createOffsetFrom() is probably one of the keys there; I think I just need to make it not be static and make it clearer that the inputs are the number of objects of that sort offset, not necessarily degrees (as Centicule would be tenths-of-a-degree). Plus I think there's a few places where I'd need to update serialization and make sure the new code understands to convert old serializations. The versioning part should be easy, as all old serializations are guaranteed to be Graticules.

Once Graticule is generalized properly, Centicule would follow logically, and then the UI parts can get going. It's just that the generalization part and the refactoring might take a bit. It likely won't be hard, per se, just tedious. I'll see what I can do.

(side note: The code currently assumes a null Graticule means a globalhash, so that won't need another object)

[CaptainSpam]

All righty... the centicule branch is up. So far, I've just implemented the initial Somethingicule (d215967b16da46e4bf0b52b342e3d9209a44f039), made Graticule implement it, and updated StockWorker and KnownLocation to accommodate (5082ff3ff66616519bfb47279696784b413a5c50), plus finally, FINALLY added more tests (17871dc8908e14e214f1bc4e1cd4f5d27ec1aded). It's a start!