encoding consistency on different python versions [WIP]

[perrygeo]

This PR adds two tests, one of which will fail on every build. Which one fails depends on the python version.

TODO: make these consistent across python versions and remove the test with the "bad" result

@frederickjansen I could use your help in identifying the causes of this bug.

[sgillies]

The Python 3 rounding strategy is different from that of Python 2. And different from Javascript's. For example:

• Javascript: Math.round(2.5); # 3.0
• Python 2: round(2.5) # 3.0
• Python 3: round(2.5) # 2.

The last two commits to the polyline project involve details of rounding. If Javascript rounding is the standard for this algorithm, than the implementation here will need to be a little different for Python 3.

[frederickjansen]

@perrygeo Great catch, thanks!

@sgillies It actually looks like the Python 2 behavior is the correct one. I tried the failing test (but then with the coordinates reversed, latitude has to be between 90 and -90) on Google's Interactive Polyline Utility and get ss`{E~kbkTeAQw@J, same as with this implementation in Python 2. Mapbox's polyline tool returns ss`{E~kbkTeAQw@H, which matches Python 3 but appears to be wrong.

polyline.encode([[36.05322, -112.084004], [36.053573, -112.083914], [36.053845, -112.083965]])

I'll fix the issue (hopefully later today) and release v1.3.1.

[frederickjansen]

Fixed the issue, rounding behavior is weird... This gives me a chance to write some better documentation, so I'll do that soon and then release a new version.

@sgillies I misread your post, you said exactly that the implementation for Python 3 was incorrect. Interestingly enough, this algorithm uses Python 2's way of rounding, not Javascript's. In Python 2, round(-0.5) == -1. In Javascript, Math.round(-0.5) == -0. So the Mapbox implementation has to change as well.