Design Decision: Vector-Based Representation of Feedstocks

[tylerhuntington]

Context

Our tool needs to represent and manage multiple types of biomass feedstocks (e.g., corn stover, grape trimmings, almond shells) across California, with both quantitative and qualitative attributes tied to specific crop field locations. The backend stack is Django + GeoDjango + PostgreSQL/PostGIS.

---

Decision

Based on the rationale below, there is a strong case for storing feedstock data in the tool as vector-based geometries (e.g., polygons representing crop fields or grid cells) in PostGIS, rather than raster-based representations.

---

Rationale

1. Attribute-Rich Data Model

   • Vector geometries in PostGIS can store multiple numeric and categorical attributes directly in the table schema.
   • This allows each feature (crop field or grid cell) to hold many feedstock types, yield estimates, ownership details, and other metadata without requiring complex multi-band raster structures or external lookup tables.
   • Raster cells, by contrast, store a single value per band and require separate bands or datasets for each feedstock type, complicating schema management.

2. First-Class GeoDjango Integration

   • GeoDjango natively supports vector geometries (Point, LineString, Polygon, etc.) via the ORM, enabling clean, maintainable, and performant queries.
   • PostGIS raster fields are not natively supported in GeoDjango, requiring raw SQL and manual handling, which increases development complexity and reduces maintainability.

3. Query and Filter Flexibility

   • Vector data allows direct SQL/ORM filtering on any attribute (e.g., WHERE grape_trimmings_tons > 50 AND region = 'Central Valley').
   • Raster queries require specialized PostGIS raster functions and cannot leverage the ORM for attribute filtering.

4. Data Update and Maintenance

   • Updating vector attributes is straightforward (e.g., updating a single row/column in a table).
   • Updating raster data often requires regenerating and reloading entire tiles or bands, which is more computationally expensive.

5. Interoperability and Analysis

   • Many analytical workflows (e.g., spatial joins, aggregations, buffering) are more mature and efficient with vector geometries in PostGIS.
   • Vector data can be easily exported to common formats (GeoPackage, Shapefile, GeoJSON) for collaboration and integration with other GIS tools.

---

Trade-offs

• Loss of native continuous surface representation: Raster is better suited for continuous spatial phenomena (e.g., elevation, temperature). However, feedstock availability is inherently tied to discrete field boundaries or management zones, making vector a more natural fit.
• Potentially larger storage footprint for very high-resolution data compared to compressed raster formats. This is mitigated by our use case focusing on field-level data rather than sub-meter continuous surfaces.
• Raster-based spatial math (e.g., map algebra) is more cumbersome in vector workflows, but our primary operations are attribute queries and aggregations, not pixel-by-pixel analysis.

---

Conclusion

Given our need to store multiple quantitative and qualitative attributes per location, maintain tight integration with GeoDjango/PostGIS, and support flexible querying and updates, a vector-based representation offers the best balance of maintainability, performance, and analytical capability for biomass feedstock data in California.

---