Rename sites -> location

[peterdudfield]

• Rename site to location
• https://github.com/openclimatefix/pv-site-datamodel
• Relationships between location group.
• Location: a point of region
• Add subtype for point or region on location table?
• A renewable forecast or renewable metered data set will usually have a property of Location.
• Locations can have a parent-child location, which we can define either from the electricity grid topology, or we could use the - geographical location to do this (we did this for the sites roll-up already), or some other set parent-child relationship.
• SQL tables
  -- [Location] -> [Region]
  -- [Location] -> [Site]
• Can have child-parent relationships too
• Question going forward: what is the data we need as indexed/query-able columns, and what is “just” metadata, i.e. can be JSON field(s) like location.metadata, which will have a specific data type/structure based on the location.type (Point or Region).

[peterdudfield]

It could be something like

---
title: SQLAlchemy Location relationships
---
classDiagram

   class LocationSQL{
        + location_uuid
        + client_site_id
        + client_site_name 
        + country 
        + location_type:
        + latitude
        + longitude
         + ml_id 
     }

    class SiteSQL{
        + site_uuid : UUID ≪ PK ≫
        + orientation : Float
        + tilt : Float
        + capacity_kw : Float
        + inverter_capacity_kw : Float
        + module_capacity_kw : Float
    }

    class RegionSQL{
        + region_uuid : UUID ≪ PK ≫
        + name : str
        + region_type: str
        + meta_data : json
        + capacity_kw : Float
    }
    
    
        LocationSQL "1" -- "N" SiteSQL : contains
        LocationSQL "1" -- "N" RegionSQL : contains
        LocationSQL "N" -- "N" LocationSQL : relationships

Loading

[peterdudfield]

Examples could be

Many sites

graph TD;
      L1(Location1 - site ) ;
    L2(Location2 - site ) ;
    L3(Location3 - site) ;

Loading

Many regions, like GSPs

graph TD;
      L1(Location1 - region);
    L2(Location1 - region);
    L3(Location1 - region);

Loading

Many sites in one region

graph TD;
      L1(Location1 - site) 
    L2(Location2 - site);
    L3(Location3- site) ;
   L4(Location4 region);
   L1 --> L4
 L2 --> L4
 L3 --> L4

Loading

Many sites, many region,

graph TD;
      L1(Location1 - site) 
    L2(Location2 - site);
    L3(Location3- site) ;
   L4(Location4 - site) 
    L5(Location5 - site);
    L6(Location6 - site) ;
   R1(Location7 - region);
   R2(Location8 -  region);
   L1 --> R1
 L2 --> R1
 L3 --> R1
   L4--> R2
 L5 --> R2
 L6 --> R2

Loading

Many sites, many region, regions in region. In the UK, the first layer of regions could be GSPs, and the grand regions could be DNOs or Wind constraints regions

graph TD;
      L1(Location1 - site) 
    L2(Location2 - site);
    L3(Location3- site) ;
   L4(Location4 - site) 
    L5(Location5 - site);
   L7(Location7 - site) 
    L8(Location8 - site);
   R1(Location7 - region);
   R2(Location8 -  region);
   R3(Location9 -  region);
 RR1(Location10 -  region);
 RR2(Location11 -  region);
   L1 --> R1
 L2 --> R1
 L3 --> R1
   L4--> R2
 L5 --> R2
 L7--> R3
 L8 --> R3
R1 --> RR1
R2--> RR1
R3 --> RR2

Loading

[Averagenormaljoe]

May I work on this?

[peterdudfield]

I think we are still discussion this, o perhaps hold fire

[peterdudfield]

One slightly tricky thing is with data migration and current users. A few different methods we could do to handle this

1. One way to do this is

• write down all the current user --> site connections,
• do the migrations,
• Would need to update API and Dashboard
• then re add the user --> location connections. Would need to update API and Dashboard at the same time.

• Add a location and region table, and keep current user --> site connections.
• Make new user --> locations connections.
• Update Dashboard, update Api.
• Remove user --> site connections (and remove N-N join tables)

• rename sites to location
• add site (new) and region tables
• copy data to site and regions tables
• update functions to use site and region parameters
• remove old site properties from location

[braddf]

It could be something like

---
title: SQLAlchemy New Location relationships
---
classDiagram

   class LocationSQL{
        + location_uuid
        + client_site_id
        + client_site_name 
        + country 
        + location_type:
        + latitude
        + longitude
        + ml_id 
        + metadata
     }
    
    

        LocationSQL "N" -- "N" LocationSQL : groups

Loading

metadata:
type: "site"
        + site_uuid : UUID ≪ PK ≫
        + orientation : Float
        + tilt : Float
        + capacity_kw : Float
        + inverter_capacity_kw : Float
        + module_capacity_kw : Float

type: "region"
        + region_uuid : UUID ≪ PK ≫
        + name : str
        + region_type: str
        + meta_data : json
        + capacity_kw : Float

[peterdudfield]

Current

so current table of sites has the following fields

• site_uuid
• client_site_id
• client_site_name
• country
• region
• dno
• gsp
• asset_type
• orientation
• tilt
• latitude
• longitude
• capacity_kw
• inverter_capacity_kw
• module_capacity_kw
• ml_id
• active
  (other foreigns for joining that I wont mentioned)

New

The new table (rename site to location)

same fields

• location_uuid (migrated from site_uuid)
• client_site_id
• client_site_name
• country
• asset_type
• latitude
• longitude
• capacity_kw
• ml_id
• active

new fields

• location_type
• metadata
• n:n mapping to reference back to locations

legacy fields (which can be removed in a further migration)

• region
• dno
• gsp
• orientation
• tilt
• inverter_capacity_kw
• module_capacity_kw

Check

@brad and @devsjc you happy with this, before coding starts (obviously still do PR e.t.c)

• @devsjc
• @braddf