In the Google Maps API v2 for Android, LatLng normalizes longitude values to the range -180 degrees inclusive to +180 degrees exclusive. Consequently, attempting to represent the entire world as a LatLngBounds produces a longitude range of -180 to -180, which has zero width and contains no points:

// southwest, northeast
final LatLngBounds world = new LatLngBounds(
    new LatLng(-90, -180),
    new LatLng(90, 180));
assertTrue(world.contains(new LatLng(0, 0))); // test fails

So obviously, normalizing longitude to [-180, 180) has a cost in terms of how LatLngBounds works. We can only speculate as to why the API designers might have made this decision. But what are the potential benefits of normalizing longitude this way? Are there any common operations that are simplified?

1 Answer 1


+180 and -180 are the same meridian on the Earth, so they are essentially the same value when defining extents. And as you demonstrated, defining extents with the same value will produce zero width extents.

This is why one of the +-180 values must be exclusive and one must be inclusive.

edit: Technically, there isn't a reason why they couldn't have +180 and -180 both be valid, but when creating an API, less is more. It's better to restrict input up front, rather than having to deal with multiple cases for the same value in your code.

This is somewhat similar to using One's Complement to store signed integer values. Having to test for two different representations of zero is a pain, so this is one of the reasons why Two's Complement is much more popular.

  • After re-reading your question, I might have missed the point you were trying to get at. Please leave a comment or edit your question if so.
    – Mintx
    Jan 3, 2017 at 23:33
  • Perhaps unintentionally, you hit on exactly what I'm getting at. As you said, it's necessary for extents to be inclusive/exclusive. But I don't understand what advantage there might be in prohibiting a latitude value of +180 in single point coordinates, except maybe to slightly simplify testing for equality. That leads me to wonder if there's some advantage I don't see. Jan 4, 2017 at 2:13
  • Possibly to clean up the 'edge' when unprojecting data back to lat-lon. Some projections do not cleanly unproject, so you might start with a line with all x/easting values at -180, but end up with one at -180.xxxx, -179.9999xxxx, +179.99999xxxx, +180.0000xxx, etc.
    – mkennedy
    Jan 4, 2017 at 19:39
  • I implemented my own equivalents to LatLng and LatLngBounds and ended up normalizing 180 to -180 just as Google did. I realized that allowing 180 was insufficient for the purpose that I originally envisioned (allowing a bounds that spans 360 degrees longitude) so I had to find another solution for that. Incidentally, I discovered that Google's LatLng does not normalize -0.0 to 0.0 and treats them as unequal. It also accepts Double.NaN... Jan 6, 2017 at 18:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.