IssueTracker

Argh....with this bug there is absolutely no way to determine if the user has changed changed the panning of the map....I need a way to determine this so that i can allow the user to reset the map to it's original view. Please fix this ASAP.    

I have another example regarding the problematic accuracy of moveCamera/animateCamera.
When you use CameraUpdateFactory.newLatLngBounds(), moveCamera and animateCamera result in different values in map.getProjection().getVisibleRegion().latLngBounds.

LatLngBounds bounds = new LatLngBounds(new LatLng(40.70798493778415, -74.01434069136418), new LatLng(40.72072004852845, -73.99760391411343));
if (animate) {
   map.animateCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0),
} else {
   map.moveCamera(CameraUpdateFactory.newLatLngBounds(bounds, 0));
}

map.getProjection().getVisibleRegion().latLngBounds :
after animateCamera -
LatLngBounds{southwest=lat/lng: (40.70711197865251,-74.01539381593466), northeast=lat/lng: (40.72159253556309,-73.99655096232891)}
after moveCamera -
LatLngBounds{southwest=lat/lng: (40.70798500292429,-74.01539381593466), northeast=lat/lng: (40.72071968970514,-73.99655096232891)}

This is pretty important for my design as im calculating a search radius (Vincenty’s formula) by the bounds of the map. appreciate if you could confirm the accuracy of those 2 APIs.

Another example : http://stackoverflow.com/questions/17909767/googlemap-movecamera-or-animatecamera-according-to-latlngbounds-is-not-accurate/18103614#18103614

any news regarding this issue ?

I can share my thoughts about it.

LatLng is keeping doubles, when these are sent via IPC, they are flattened to floats, because there is no writeDouble: http://developer.android.com/reference/android/os/Parcel.html#writeFloat%28float%29.
When going back, you lose precision and thus errors on 4-5th decimal place.

If I'm correct here, this can be hard (if possible) to fix without breaking compatibility.

If you're right then compatibility doesnt have to be broken in order to pass a more accurate LatLng value in many other parcelable types which are not float. This option can be added and not replace the current one.
I any case this issue is really annoying and i hope someone from google can take a look at it. Thanks.

If I'm right then you are also right. ;)

Double values in LatLng could be sent using writeLong after converting them using Double.doubleToLongBits (http://docs.oracle.com/javase/7/docs/api/java/lang/Double.html#doubleToLongBits%28double%29) and converted back to double in Google Play Services app.

[Comment deleted]

[Comment deleted]

Comparing floating-point values for exact equality is rarely a good idea.  I'd suggest treating two LatLngs as equal if they're within some small distance of each other.

Not sure what comment #5 is getting at.  Parcel#writeDouble exists, and the docs say it's been around since API 1.  (Although the docs have been known to lie...)

As you are comparing objects, not numerals, unless specifically otherwise documented, you should expect the equals() method of any class derived from Object to implement the same equivalence relation as the parent class [1]:
"The equals method for class Object implements the most discriminating possible equivalence relation on objects; that is, for any non-null reference values x and y, this method returns true if and only if x and y refer to the same object (x == y has the value true)."

Also, regarding numerals, as the previous commenter already mentioned, comparing floating point values for exact equality is generally not a good idea, and doing it right is far from trivial [2].

Issue 4786 had a similar report about the onCameraChange() event not returning the exact same coordinates originally passed to CameraUpdateFactory.newLatLng().

As I commented there, we need to convert between real-world coordinates and pixel coordinates to render anything on the screen, so especially when it comes to cameras and views, you should not assume the coordinates you gave to exactly match those used internally.

The developer on the other issue provided two (longitude) coordinates as an example: 51.9820167 (given by developer) and 51.982016909253694 (returned by the API). However, the maximum real-world distance between these points is actually only 2.3 cm (at the equator).

If you need to check coordinates for approximate equality, I'd recommend using an arbitrary epsilon value of your choice (e.g. 5  or 10 cm, or 0.000001 degrees) to determine if two points are close enough to each other to be considered equal. You just need to choose a suitable distance metric and epsilon that works well for for your use case.

As we know the number ranges ([-90.0, 90.0] and [-180.0, 180.0) degrees), as well as the approximate minimum resolution of the map, absolute error margins are likely sufficient for most use cases (either in degrees or distance). That way you can avoid having to bother with the less intuitive relative errors mentioned in the linked article.

That said, I changed this issue to a type Enhancement request, and created an internal feature request for providing an a convenience method for calculating approximate equality.

[1] https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#equals-java.lang.Object-
[2] http://floating-point-gui.de/errors/comparison/ 

Still happening!  I just identified it today when I didn't acknowledge two calendar reminders.  My phone got really hot in my pocket and I had a huge power drain each time.