Consider using google.type.* instead of our custom types

[llucax]

I notices some of the types we are defined, are also present in google.type.* and was wondering if it would make sense to use a probably more widely known messages instead of a custom ones.

• frequenz.api.common.v1.market.Price: google.type.Money
• frequenz.api.common.v1.Location: google.type.LatLng
• Rename types.TimeIntervalFilter to Interval #364

In any case, I would just copy them, as we did with google.type.Decimal (frequenz.api.common.v1.types.Decimal).

FYI @frequenz-floss/api-electricity-trading-team @tiyash-basu-frequenz @thomas-nicolai-frequenz

[florian-wagner-frequenz]

So I am in favor of using less home brew-types, so I looked at the examples:

Price vs. Money
There seem to be two significant differences:

• Money stores the Unit as string (albeit indexed to an ISO standard) instead of an enum (as we use internally). If we start doing inter-currency things, then we probably will want that ISO string anyways to talk to currency exchanges etc.
• Money stores the value as two integers instead of a string, ensuring more correctness on the wire
  Lastly the name is just more fitting. In a naive view, the Price should contain an amount of money, not be the prime representation of one.

Location vs. LatLng
While we could think about having the Latitude and Longitude values wrapped in the google type, I think having the country code is sensible for multiple reasons:

• Presumably we know which country this location belongs to, and especially if we have customers that are sitting close to a border, I'd rather such information come from a database maintained by us rather than every actor querying independently.
• Funnily enough just lat and long are not sufficient to identify a point, as there are different reference ellipsoids. Granted, we still can't derive the ellipsoid from the country code, but it helps with educated guessing and also helps where different ellipsoids would yield different countries for the same lat and lng values.

Note however that I have no deep GIS credentials, I just happened to sit in a room with the map people at some point.

TimeIntervalFilter vs. Interval
Same contents, but I like the Google name more. We might specify time intervals that aren't filters e.g. when issuing a dispatch request. Are those currently using a different type?

Anyway, lots of words for my 2 cents

[llucax]

Yeah I forgot about the country code, maybe we can have Location { string country_code; LatLng lat_lng }, but not sure.

[llucax]

TimeIntervalFilter vs. Interval
Same contents, but I like the Google name more. We might specify time intervals that aren't filters e.g. when issuing a dispatch request.
Yeah, I think our name is way too specific, it prevent us from using it in other contexts (in a non-confusing way)

[florian-wagner-frequenz]

Yeah I forgot about the country code, maybe we can have Location { string country_code; LatLng lat_lng }, but not sure.

That would be nice, that said it might make working with locations a bit more painful (although we can smooth out that corner in the clients/sdk I guess).

Either way we should maybe document/agree what Ellipsoid we are referring to with LatLng. It seems WGS84 is the standardized version, although legal maps will probably use whatever the local country uses. Either way, we should be clear about what we refer to here.

[llucax]

• Rename types.TimeIntervalFilter to Interval #364