Implement Serialize and Deserialize for WGS84

[meltinglava]

Most people would be able to use a default implementation of these traits. If for some reason they have other output they can just make their own type from from/into implementation.

[feuerste]

You are welcome to open a PR.

[meltinglava]

I did take a look at it. We cant use derive as it will requre N impl serialize. I am happy to implement it, thow sould we use the short or the default names?

[meltinglava]

What we can also do is convert N to f64 and then serialize it. That also makes the deseialization strait forward as it will always return f64

[feuerste]

I'm not 100% clear of the use case you have. Do you want to provide Default implementations for the nav-types data types like WGS84, ECEF, etc. and/or do you want to have Serialize for them? What would be the benefit of either of them?

[meltinglava]

I think what i would like is that we implement Serialize that work in only one way. Since for most purposes I think that would be sufficient. I do not think Serde allows the en user to overwrite keys in any way. And then we implement Deserialize for our implementation for Serialize. If the end user wants to implement these with different types, they can just do what the alternative is now, and create a struct that implements Into<ThatType> for WGS84<N>, and Into<WGS84<N> for ThatType.

My question was more if we want the end json to look like this:

{
    "latitude": 0.0,
    "longitude": 0.0,
    "altitude": 0.0
}

or do we want to use the shorten the words.

[meltinglava]

I think the most new projects are able to adhere to our implementation. Just less hassle.

[feuerste]

@meltinglava Sorry I lost track of this ticket. Your proposed names look good!

[meltinglava]

PR merged. Did not link properly