Guidance needed for creating/using spatialRaster & spatialVector entities in EML

[gremau]

We’re de-emphasizing the use of spatialRaster and spatialVector in the new EML BP v4 document. Some people are understandably skeptical of that change in guidance (notably @srearl and @clnsmth ), but it seems clear that few people use these entities in EML because there are not community-supported methods to create them, or well-known downstream uses for them once created. I suggest we create a document that 1) describes HOW to create these spatial data entities in EML, and 2) defines what the use cases are. Once that happens I don’t mind recommending the use of these entity types in either the EML BP or the Special Cases documents.

[srearl]

I think this is likely true for the average user. A value of these datatypes and the corresponding rich metadata is to the increasing importance of machine readability and use. Maybe this is a longer arc than the scope of this document but I suggest that rather than codifying the current approach of "this is too hard so we should not bother" the true best practice is to embrace these datatypes and build tooling and workflows around them so that their construction is more accessible to the community. Consider also that the geospatial landscape is evolving rapidly. As ESRI loses its grip on the non-commercial space, practitioners are embracing other formats (e.g., GeoJSON) and tools (e.g., sf, Geopandas) for their geospatial needs. These approaches are (likely) better served than by, for example, a zipped shapefile encoded as a otherEntity and, conversely, these approaches may be part of the toolsuite to construct these EML spatial datatypes. Further, we should consider also that geospatial products and workflows are moving increasingly to the cloud (e.g., GCP, SageMaker). As such, a role for EML/EDI may not be so much to house geospatial resources but to describe and point to them, for which these geospatial datatypes are (likely) better suited.