brycehemme
commented
2 years ago My personal take is that we need a standard for agricultural spatial layers that defines a base layer construct and strongly typed layer implementations (i.e. Soil Vector Maps, Management Zones, Historical Productivity Maps, etc). This might not be ADAPT directly but ADAPT may reference another standard for agriculture layers. I'd be happy to discuss this further.
knelson-farmbeltnorth
Reference Layers appear to be a generic means of storing geospatial information that is otherwise loosely associated to the rest of the ADAPT model. I am not aware that this facility has been used in any ADAPT implementation.
Does this concept belong in the model, or is it simply an incomplete design? Other reviewers have also called it out as something that doesn't seem to fit, at least where it is placed at the root of the model. One could argue that having such an open-ended data store runs contrary to our purposes of a well-defined standard, or simply that it leaves the impression that ADAPT is trying to be too many things at once.
E.g., one of the defined types is "Variety Locator" (which is generally a collection of polygons defining distinct seed varieties planted on a single field for comparison against yield data). Without any definition from the model, how can we interpret the data consistently? I might expect a layer with a single attribute for CropVarietyProduct.Id.ReferenceId and only as many multipolygons as different products on the field, but there is no guarantee every implementer would do it that same way. If VarietyLocator data is really something we want to track within ADAPT, why not have a VarietyBoundaries attribute on CropZone, and define a VarietyBoundary as a MultiPolygon extended with a ProductId. In this way there would be consistent implementation.
Similarly, Management Zone could be modeled in its own right. An Elevation Map is arguably the same concept as a Management Zone for ADAPT's purposes.
Obstacles are redundant to FieldBoundary.InteriorBoundaryAttributes.
As a US-Centric concept, CommonLandUnit should be modeled as a FieldBoundary with an appropriate Context Item to identify it as such.
Of the remaining types, Profit Maps and Soil Type Maps would generally reference detailed data not otherwise modeled in ADAPT, and using ADAPT to store BackgroundImagery seems a stretch.
@strhea Can you fill in any history here? Was the inclusion of this section a compromise for the initial release?