In an ideal world our 'sites' table would be named 'points' and if we had sites they would represent an area/region of study where several sensors were deployed as points.
However, we do have a concept of a point named with the term 'site'. Correcting this mistake is prohibitively expensive.
Instead we now introduce the concept of a region. A region is an area of study, usually small, where a group of related sensors are deployed as 'sites'. A region as introduced here is consistent with the ecological definition of a site.
We also desperately wanted to avoid changing the hierarchy in the app - especially with all the complexities involved with sites<->projects. So this means it is optional for a site to belong to a region.
This idea was previously named site_groups because really all this region concept is a logical grouping of sites.
Changes
Adding a new table, model, and nested/shallow API only endpoints
Adds regions …
Closes #383
In an ideal world our 'sites' table would be named 'points' and if we had sites they would represent an area/region of study where several sensors were deployed as points.
However, we do have a concept of a point named with the term 'site'. Correcting this mistake is prohibitively expensive.
Instead we now introduce the concept of a region. A region is an area of study, usually small, where a group of related sensors are deployed as 'sites'. A region as introduced here is consistent with the ecological definition of a site.
We also desperately wanted to avoid changing the hierarchy in the app - especially with all the complexities involved with sites<->projects. So this means it is optional for a site to belong to a region.
This idea was previously named site_groups because really all this region concept is a logical grouping of sites.
Changes
Adding a new table, model, and nested/shallow API only endpoints
Problems
Visual Changes
N/A
Final Checklist