Provide spatial extent field for non-spatial files

[empavia]

There has been a request to enable spatial searching on non-spatial files, such as tabular data. For example, a biophysical table for a location may appear in a spatial search on the Data Hub.

There may be a long-term, and more difficult, solution by allowing spatial searches to show datasets with placenames in the searched bounding box, which will require a lift on the CKAN side.

In the meantime, I see some potential solutions:

1. Add in the extent field (optionally?) to the tabular metadata YAML. This field would be identical to spatial files, but would likely have to be manually edited.
2. Same as point 1, but allow the extent to come from a paired file, such as an AOI shapefile.
3. Do not introduce a new field to the tabular metadata, but add tabular data needing spatial extent to a "data package" containing an AOI with the appropriate extent.

• For example, if we have a biophysical table for Colombia, we would package the table and a shapefile of Colombia, and the duo would come up in spatial search.

Happy to clarify or discuss this further! This will not need to be prioritized until we have more tables on the hub or need to integrate biophysical tables from the Data Hub into the InVEST workbench.

[davemfish]

For example, if we have a biophysical table for Colombia, we would package the table and a shapefile of Colombia, and the duo would come up in spatial search.

This is a compelling option and might represent the need for an individual resource's metadoc (metadata document) to include a reference to a collection that it belongs to. And maybe the collection's metadata should include an extent attribute based on something like the union of all the extents of all the spatial files, or the extent of single user-defined AOI.

[empavia]

This is a compelling option and might represent the need for an individual resource's metadoc (metadata document) to include a reference to a collection that it belongs to.

Yes, I think this could be a great example of that. Our only working example of a "Data package" is the Footprint Impact Tool package, which is separate from the individual layers also hosted on the Hub, that would be great to link together.

And maybe the collection's metadata should include an extent attribute based on something like the union of all the extents of all the spatial files, or the extent of single user-defined AOI.

This is a great idea. I believe the Footprint Impact Tool data package shows up in the spatial search due to it containing spatial files, but it would be great to have a general extent in main zipfile YAML.