This project has moved. For the latest updates, please go here.

Location Serialization

Nov 4, 2013 at 5:49 PM
Is there a reason why the Location class is not marked as [Serializable] ?

And is the "internal double Y;" inside Location a test that got committed ?
Nov 4, 2013 at 6:02 PM
Edited Nov 4, 2013 at 6:03 PM
That's just because SerializableAttribute is not available in Silverlight or WinRT. Do you actually need it?

The internal double Y holds the Mercator-transformed latitude value and just avoids unnecessary recalculations.
Nov 4, 2013 at 6:13 PM
Well, that's a pretty good reason. Thank you for answering so promptly.

I made my own class to serialize locations, so I don't need it, but it would have simplified some code.
Nov 5, 2013 at 4:28 PM
Marked Location as serializable in new release 1.7.0.
Marked as answer by ClemensF on 11/13/2013 at 10:53 AM
Nov 5, 2013 at 6:29 PM
Thank you for the change. However, I was wondering why did Location lose the IEquatable interface / Equals override.

That change did break a lot of code on my side (Linq Distinct on locations, and WPF CollectionViewSource grouping, which I use to cluster same location pushpins on the map).

I have workarounds for both (custom IEqualityComparer for Distinct, and using the Converter property of the PropertyGroupDescription to return a Tuple<double, double> instead of a Location), but unless it was causing other problems I am unaware of, I think this is a bad change.
Nov 5, 2013 at 10:07 PM
The IEquatable was a remnant of an earlier version and is no longer needed. I didn't like the implementation anyway, as comparing floating point values is not reliable under all circumstance due to rounding errors.
Jul 4, 2014 at 1:34 AM
Sorry to revive an old discussion, but I've been working with "non-equatable" Locations for a while now, and more than ever I think removing Equals and GetHashCode overrides was a bad change.

In addition to WPF grouping and Linq Distinct needing workarounds, Locations don't behave like I think it would be expected to in HashTables and as dictionary keys, and more importantly, they cause "value changed" triggers in dependency properties.

While all these problems can be worked around, having Equals (and operators ==, != for consistency) and GetHashCode overridden (IEquatable isn't necessary) would solve all these and shouldn't cause any problems to existing code.

As for the rounding errors argument, I can understand that if your input data comes from Viewport to Location transformations, it wouldn't be reliable at all. But when generated directly from doubles (or from deserialization), double type comparison would be reliable. Microsoft does override Equals and GetHashCode in their Point, Size, Vector and Rect types.
Jul 4, 2014 at 1:53 PM
Edited Jul 4, 2014 at 2:53 PM
Ok, I guess I could do that with the next release. I will however not overload the == and != operators for the reasons discussed here: