SolarArbiter / solarforecastarbiter-api

HTTP API and database schema for the Solar Forecast Arbiter
https://api.solarforecastarbiter.org
MIT License
10 stars 6 forks source link

how to handle climate regions #253

Closed wholmgren closed 4 years ago

wholmgren commented 5 years ago

I think we're going to need a standardized way to handle climate regions. While perhaps not required, it might be worthwhile for us to keep mind that the code could be more useful in the long run if it can handle more general regions such as utility/ISO/interconnect boundaries.

Here's one idea:

  1. Create database table that tracks known regions. Columns might be name, kind, specification. kind takes values like climate or iso. specification could be more specific, like wkt, or it could let the entry describe itself. Perhaps we'd also want to add some kind of way to control access permissions for arbitrary regions.

  2. Create an API function that takes latitude, longitude and returns all table rows that include the point.

  3. Create an API function that takes a region name and returns all datamodel.Site objects that are included in it.

  4. Add a regions attribute to datamodel.Site.

I'm thinking of the API functions as things that would recompute the result on demand. But we might want to create additional tables to compute all known associations. That could be tricky to do well with permissions.

Eventually this information needs to be communicated and searchable in the dashboard. I think the API functions described above meet the requirements for most use cases.

alorenzo175 commented 4 years ago

I like the ideas. We'll need lots of benchmarking and prototyping to do it right. We might also adjust site objects so that coordinates are richer can capture an entire area instead of only points.