Sites and Projects
Erde separates where environmental data lives from what work it belongs to. A Site is the spatial scope — a physical place under management. A Project is the work scope — an engagement or effort. These two axes are independent: one Project can span many Sites, and one Site can carry many Projects. A Program groups Projects, and Sites connect to it only through those Projects.
Two scopes, one record set
Every domain record in Erde answers to one or both of these scopes. Field artifacts such as Wells are scoped to a Site (they describe a place). Work products such as Samples and Lab Reports are scoped to a Project (they belong to an engagement). A Sample is always Site-scoped: when it is anchored to a Location, the Site comes from that Location; when it has no Location, you assign it to a Site already linked to the Project. A Lab Report is Project-scoped only. Monitoring records — Water Levels, Well Purges, Field Parameter sessions, and Logger streams — are dual-scoped: each is anchored to a Location on a Site and belongs to a Project, so it carries both a Site scope and a Project scope at once.
Keeping the axes separate matters because a Location outlives any single Project. A monitoring well drilled for one investigation is reused by the next; it stays anchored to its Site while Projects come and go. Erde models this by making the Site the durable home of physical features and the Project the durable home of work.
The two are linked by a join — a Site is assigned to a Project rather than owned by it:
Figure: A Program links to Projects; a Project links to Sites. There is no direct Program-to-Site edge — Sites relate to a Program only through its Projects.
Site versus Project
The two scopes describe different things, hold different fields, and are managed independently.
| Aspect | Site | Project |
|---|---|---|
| Scope axis | Spatial — where the data is | Work — what effort the data serves |
| Marker interface | ISiteScoped | IProjectScoped |
| Identifier | Code (unique across Sites), Name | Code (unique across Projects), Name |
| Default status | Active | Planned |
| Geometry | Carries its own representative Coordinate (WGS84 / EPSG:4326) and a Boundary in any coordinate system | None |
| Holds | Locations, Wells, Boreholes, Test Pits, Sediment Cores | Samples, Lab Reports, Chains of Custody |
| Lock | Lock/Unlock freeze edits to Site-scoped data | Lock/Unlock freeze edits to Project-scoped data |
| Lifespan | Durable — Locations outlive Projects | Per-engagement |
Both Site and Project also carry a Status, optional StartDate and EndDate, and a Description. A Project additionally carries an optional ClientProjectNumber and a pinned Data Management Plan.
The Holds row above lists what each scope is the primary home for. As noted above, Samples are always Site-scoped, and the monitoring records below sit on both sides: Water Levels, Well Purges, Field Parameter sessions, and Logger streams are each Location-anchored to a Site and also assigned to a Project, so each carries both a SiteExternalId and a ProjectExternalId. They appear under both scopes, not one.
How Programs connect them
A Program is a higher-level grouping of related Projects — for example, a multi-year monitoring program made up of annual investigation Projects. A Program holds a Code, a Name, a Status (default Planned), optional dates, an optional Description, and a list of member Projects.
Each membership is recorded once: a given Project appears at most once in a given Program. A Program has no Site field of its own. Its Sites are whatever Sites the member Projects are assigned to. To see "every Site touched by this Program," follow Program → Projects → Sites.
How it fits together
The Site-to-Project relationship is many-to-many. Assigning a Site to a Project does not move or copy the Site's data — it grants the Project access to that Site's spatial context. A Site dropped from one Project keeps all its Locations and records, because those belong to the Site, not the Project.
This separation is the foundation of access scoping. Erde grants access along the same two axes: a user can be scoped to specific Sites, to specific Projects, or both. Because physical features hang off Sites and work products hang off Projects, scoping a user to a Project gives them the work without exposing every Site, and scoping to a Site gives them the place without exposing every engagement. See Users, roles, and permissions for the full model.
Related
- The Erde data model — the full record hierarchy from Site and Project down to Lab Result.
- Aggregates, locking, and auditing — how Site and Project locks freeze scoped data.
- Users, roles, and permissions — how the two scopes drive who can see and edit what.
- Sites & Locations — working with Sites and the features beneath them.