[Feature Contribution]: Geocode support in the API

[vaughanknight]

What happened?

While cloud datacenters lean towards having named locations (not having to remember geocodes) when looking at client side carbon aware decisions, the use case for geocoordinates is very strong.

This feature would be to add geocode support to any of the API's where named locations are supported (and geocodes are not).

This is likely a large change, and will need considerable impact analysis to ensure we do it cleanly.

Code of Conduct

• I agree to follow this project's Code of Conduct

Feature Commitment

• I commit to contributing this feature as a PR and working with the GSF to merge this feature into the Carbon Aware SDK.

[Willmish]

Mentioned in #115

[bderusha]

This feature unlocks many use-cases around end user device carbon awareness. EG home computer: time-shifted file downloads, uploads; smart home devices: managing power consumption for car chargers, appliances, etc.

Design Recommendations

• Ability to configure multiple LocationSources and have them applied in a specific order.
• Keep location input type as single string value (even for lat,long geospacial coordinates) and let the location source resolve the string into something well-formed.
• Caching needs to be considered here. Whether it's documenting a recommended approach for operators to put in front of the SDK or baking it into the solution. But simply using a geocoordinate as the key will have many cache misses, it would be great to have a solution that handles that a bit smarter.

[bderusha]

Another comment on this:

Having multiple LocationSources is a significant change that should have an approved ADR before it is implemented.

[Willmish]

Update from #355 : Lot of possible implications from the carbon perspective (might allow for not a good use of the CA SDK). Not on track for v1.1, looking to implement in v1.2.