FR: gh_neighbors(hashes, n_neighbors)

[MichaelChirico]

It might be nice to allow gh_neighbors to more flexibly return not just the neighbors, but the neighbors' neighbors (up to distinctness, i.e. for n_neighbors = k there should be (k+2)^2 - 1 geohashes returned), e.g.

# would return the same information as does currently gh_neighbours('dqcjqc')
gh_neighbours('dqcjqc', n_neighbors = 1)
# would return 24 geohashes
gh_neighbours('dqcjqc', n_neighbors = 2)

The 24 GH returned would be: 1 . NW-NW - dqcjq7

2. NW-N - dqcjqe
3. N-N - dqcjqg
4. N-NE - dqcjr5
5. NE-NE - dqcjr7
6. NE-E - dqcjr6
7. E-E - dqcjr3
8. SE-E - dqcjr2
9. SE-SE - dqcjpr
10. SE-S - dqcjpp
11. S-S - dqcjnz
12. SW-S - dqcjnx
13. SW-SW - dqcjnr
14. SW-W - dqcjq2
15. W-W - dqcjq3
16. NW-W - dqcjq6
17. NW - dqcjqd
18. N - dqcjqf
19. NE - dqcjr4
20. E - dqcjr1
21. SE - dqcjr0
22. S - dqcjqb
23. SW - dqcjq8
24. W - dqcjq9

A few potential issues:

• these "names" are not well defined, e.g., NW-W is the same as W-NW
• the current API (which returns one column for each of the neighbors) may get a bit unwieldy as the number of columns grows quadratically (not sure there's a simple way around this....)

[Ironholds]

Yeah, those'd be my concerns too

[MichaelChirico]

I'm just noticing the gh_neighbour internal function... with that, the names of the neighbors are well-defined, i.e. geohash:::gh_neighbour('dqcjqc', c(1, -2)) gives dqcjq6 unambiguously.

Corollary:

• This could be used to define the columns when n_neighbors > 1 (NW-W would be NWW in echo of the input to gh_neighbour
• Alternatively, we could just export gh_neighbour, and let people stitch together the n_neighbors argument by hand in a way which fits their current use case.