Add zone_letter_to_central_latitude

[LuxMiranda]

I'm working on a project involving zone centroids, so I figured I'd implement the sister function to zone_number_to_central_longitude.

Implements the special case of zone X being 4 degrees taller than the other latitude bands.

[Turbo87]

@JackMiranda thanks! can you make sure to write a few tests for this new function too?

[LuxMiranda]

@JackMiranda thanks! can you make sure to write a few tests for this new function too?

Totes my goats my dude

[codecov[bot]]

Codecov Report

Merging #41 into master will increase coverage by 0.29%. The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #41      +/-   ##
==========================================
+ Coverage      95%   95.29%   +0.29%     
==========================================
  Files           3        3              
  Lines         160      170      +10     
==========================================
+ Hits          152      162      +10     
  Misses          8        8

Impacted Files	Coverage Δ
utm/conversion.py	95.18% <100%> (+0.3%)	:arrow_up:
utm/__init__.py	100% <100%> (ø)	:arrow_up:

---

Continue to review full report at Codecov.

Legend - Click here to learn more Δ = absolute <relative> (impact), ø = not affected, ? = missing data Powered by Codecov. Last update d21fbbc...2d1edff. Read the comment docs.

[LuxMiranda]

This new commit does a few things:

• Add tests for both zone_number_to_central_longitude() and zone_letter_to_central_latitude()
• Respectively incorporates number and letter checking into these two functions
• Splits check_valid_zone() into two functions, check_valid_zone_number() and check_valid_zone_letter(), to streamline the above enhancement.

Note: the Travis build only seems to fail as the build system itself fails when trying to fetch older python version archives.

[LuxMiranda]

In this commit, I've gone ahead and tidied up .travis.yml. I toyed around with it in a separate branch; both builds for Python 3.3 and Python 2.6 failed for some dependency reasons even with manual tweaking. Not surprising since they're both past end-of-life and the dependencies have already dropped support for them.

I also added testing for Python 3.7.

[LuxMiranda]

bump

[Turbo87]

both builds for Python 3.3 and Python 2.6 failed for some dependency reasons even with manual tweaking. Not surprising since they're both past end-of-life and the dependencies have already dropped support for them.

unfortunately that means that this is a breaking change and requires a major version bump. apparently maintainers in the python ecosystem seem to not care about semver that much which is why some of our dependencies are breaking, even though they didn't have a major version bump...

would it be possible to restrict the breaking deps to versions that are still compatible with these old Python versions?

in any case, these changes are unrelated to the proposed functionality in this PR, so it would be great if you could move the Travis changes to a dedicated PR.