Adding h3ToCenterChild

[zachasme]

I have a use-case where I need to find the center child of a given h3 index at a specified resolution.

I'm simply changing the four resolution bits, but I am wondering if this is worth adding as a helper function to the core library (so I can keep treating the index as an opaque datatype) or if it is too specific a use-case.

I'm willing to make a pull request if you think it would be useful.

[nrabinowitz]

This came up in #255 as well. We have an internal function getDirectChild that should make this implementation a one-liner. The only real cost is increasing the API surface area.

@isaacbrodsky for thoughts. Considerations here:

• Would it be more valuable to expose makeDirectChild (which allows selecting a child 0-6)? My guess is no, because it's too hard for users to determine which child they'd be selecting beyond the center.
• Does adding h3ToCenterChild mean we shouldn't add pentagonsAtRes, because this can be derived efficiently (if not obviously) by the caller?

[zachasme]

As a matter of fact I recently also needed the set of pentagons at a given resolution for a viewer application where I wanted to highlight them.

I think there is some value in increasing the API surface if the use-case is general enough and it helps the consumer avoid manipulating the index representation directly, especially in bindings.

[isaacbrodsky]

• Would it be more valuable to expose makeDirectChild (which allows selecting a child 0-6)? My guess is no, because it's too hard for users to determine which child they'd be selecting beyond the center.

I think h3ToCenterChild is a good function to add. It seems clear and has a couple use cases (@zachasme's and the pentagon one). At the moment I agree that makeDirectChild may not be very useful outside of the library because of the difficulty in choosing the child indexing digit.

• Does adding h3ToCenterChild mean we shouldn't add pentagonsAtRes, because this can be derived efficiently (if not obviously) by the caller?

It's something to consider, but I don't think I'd really push to not add pentagonsAtRes. (That is, I'm OK with adding pentagonsAtRes.) I think our guiding API principles are to be useful, understandable, correct, and stable. Minimalism or the size of the library aren't by themselves goals we're aiming for.

I'm willing to make a pull request if you think it would be useful.

Please do! :)