Just starting this thread to gauge interest in the idea of an “Imagery asset” type. In my experience integrating a few different kinds of imagery with farmOS I’ve seen how a higher level concept of “imagery” could be useful in the farmOS data model itself.
I’m not convinced an “imagery asset” is the right approach, though, so I want to see what others think, make sure my head is on correctly
I first mentioned the concept of an imagery asset here:
And later learned about the Cloud Optimized Geotiff, and mentioned it here:
I don’t want to make this issue entirely about COGs, but because they should be able to be hosted on a farmOS server itself, I think they are an important consideration here. It’s exciting because they potentially lower the barrier to integrating custom imagery. I did some initial testing with this and was able to load a COG geotiff that was hosted from my local 1.x development server into the Cog-Explorer (shared back in this farmOS chat)
The Cog-Explorer (source) is neat because it’s using Openlayers (like farmOS-map!) + geotiff.js. Somewhere I found this high-res demo from an AWS source which is pretty neat as well. Integrating farmOS-map with geotiff.js is the remaining question mark, but it should be possible, and potentially much easier soon with this PR that is nearing completion (and even has a nice COG build demo!): Rendering raster tiles with WebGL by tschaub · Pull Request #12008 · openlayers/openlayers · GitHub
So back to the “imagery asset” idea…
Some benefits of implementing as an asset type:
- Has a
filefield that could potentially be used to reference & save imagery data
- Might be convenient for locally-hosted COG imagery
- Because this is an asset type, it is fieldable (could add
- Could have an “imagery_type” field to categorize imagery
- Can be archived (if imagery becomes “outdated” or etc)
- Location can be assigned via intrinsic geometry or movement logs
- Can be referenced by logs (eg: a drone flight activity log, on a timestamp, assigned to a user, that “creates” some imagery assets)
And some negatives:
- Doesn’t have a concept of “remote imagery URLs” (or parameters, settings, access tokens, etc) unless specific fields are added. But these fields would be added to all imagery assets.
- Maybe this remote stream wrapper could work? (https://www.drupal.org/project/remote_stream_wrapper)
- Limited support for “imagery type” - all types will have the same fields.
- Imagery as an “asset” makes sense to me (flying a drone commercially cost $$, the image is an “asset” for the farm), but maybe this is confusing or overkill in other use cases?
Another option may be to use the Drupal core media module. This provides a
media content entity with
media_type bundles. Each media type specifies a source plugin that handles some of the “domain knowledge” like validating the file extension and providing metadata. I haven’t used this module myself but believe it is often used on Drupal sites.
Some benefits of
- Better support for “imagery type” - each type is its own bundle, can have different fields, and customize form/view modes
- Better handling of “remote” media (perhaps leverage this module: https://www.drupal.org/project/media_remote)
- Could potentially use the Drupal media library (I think?) to browse imagery
- Doesn’t have many of the features an asset gets by default (unless an asset references the media entity)
- Assets and logs come with file reference fields (for
mediareference fields (but a
mediareference could be added)
- Adds a dependency on the core
After thinking more about
media entities, I’m leaning towards providing an Imagery asset with a
media reference field that is limited to
media_types that are considered “imagery types” (identified via third party settings?). This would give the benefits of both an asset and the media type bundles to support different imagery types.
Does this make sense? Would it work with your (dream?) workflow of adding/using special imagery in farmOS?