Imagery asset - any interest?

Development
1

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 :stuck_out_tongue:

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!): https://github.com/openlayers/openlayers/pull/12008

So back to the “imagery asset” idea…

Some benefits of implementing as an asset type:

  • Has a file field 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 imagery_type, imagery_date field, etc)
  • 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.
  • 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 media entities:

  • 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

Negatives:

  • 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 file and image files), not media reference fields (but a media reference could be added)
  • Adds a dependency on the core media module

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?

2 Likes
2

Cool idea! I think the idea of an “imagery asset” makes sense!

(Setting aside my Farmier-specific filesize/traffic concerns/hesitation in the thread with @walt… :wink: Mapping issue: Area classification - #5 by mstenta)

I haven’t used the Media module myself. My gut is that it would be unnecessary complexity, but worth exploring perhaps!

2 Likes
3

It would be great to have an “imagery asset”. The following would be a use case that I would imagine.

  • Farmer takes several pictures in the field during the year to document the overall status of the crop or field.
  • These pictures are takes at different or at the same location.
  • Since they are not directly related to something specific they are not related to any other asset → now they would be related to the imagery asset
  • over time (months/ years) this builds up a database of pictures that can be archived or better layered for every year or time period
  • a few years later a weed spot emerges → the farmer can now go back in time via layers and check if it was there before or if it spread…; also for orchards is could show the progress of growth

Could this be done with the imagery asset or is there a better way to do it?

3 Likes
4

Good question @Lars. “Pictures in the field” sounds like you’re describing pictures taken by a phone/camera by hand? I think this could be accomplished by attaching photos to observation logs right now. The logs could be assigned to location(s) and be used to look at changes over time. Perhaps a future UI could make it easier to review all photos that have happened in a certain location.

I didn’t fully explain this above (oops!) but my thought is that these imagery assets would be viewed as a base layer in a farmOS-map instance. It would also be possible to “promote” certain imagery assets to be added as base layers to all maps used in farmOS. So the imagery asset would really only be for imagery that has been mapped to a coordinate system, typically things like drone and satellite imagery.

Maybe “map imagery” or “map layers” would be a better term?

2 Likes
5

Thanks for that clarification, @paul121 : i’m with @Lars on the need for some better affordance in the UI for this sort of image-based/ observations-over-time capture & review capability, but i guess that’s a different conversation. /w

Regarding your last sentence (italics mine): Is it intended to address cases of sharing maps across different farms/ farmOS instances with some shared hosting provision? Or is it in case of different maps related to same farm/ farmOS instance? In my case, the only basemap i know about is the one that shows up in my dashboard by default, providing geographic context to the Areas i have defined -so i’m a bit confused by your use of the plural: mapS.

Again re last sentence (italics mine): Would that terminology be relevant to the end-user? Or is the term only relevant to Developer role? As a non-dev user of farmOS, but a bit more savvy in realm. of GIS, i would observe that “layers” can be either bitmap or vector, while “imagery” refers to bitmaps specifically, so… Dunno if this distinction is quite obvious to the “naive” user, but seems to me important for the Developer to be aware.

2 Likes
6

No - an imagery asset would only be available on a single farmOS instance. To share imagery with multiple farmOS servers it would be better to host it externally (AWS S3, etc).

By “maps” I’m referring to the maps that are rendered on different pages in farmOS, eg: dashboard, asset list, asset view/edit, log view/edit, etc. You’ll notice that these all have subtle differences. It could be possible to select which (or all) maps to render an imagery asset on. For example, only render on the dashboard, or only render in log maps (if imagery is only used to identify fences for animal movement logs).

Good observation… maybe “map layers” is too general. I think “map imagery” better captures the goal here. And is less technical than something like “bitmap layers”

3 Likes
7

OK, i see what you mean. I was confused, because in my instance, the basemap is always the same, only the focus will change to a different range of co-ordinates, depending on what’s been selected for viewing… But i can see how this “Imagery Asset” class would enable delivery of whatever “map imagery” is most appropriate as a basemap for the context in focus.

For example: the default basemap imagery is fine for most of our purposes in the system -except when it comes to our Market Garden operation, which has 2 important new elements (a summer shade tunnel, AND an annex to our greenhouse that has doubled its size) not shown on the default satellite imagery, it is so old! If i could replace it with more current GeoTIFF map imagery, as proposed in another thread, that would be great -and this sounds like a good way to enable it.

Yes -“map imagery” is a simple and unambiguous term that is friendly to both Users and Devs, seems to me.

2 Likes
8

@Lars I agree with @paul121 that Observation logs are the best place to store the kind of photographic records you’re talking about. These logs can reference any assets they pertain to, so you can quickly find them again in the future, and if you use a standard naming scheme or Log Category on them then you can filter out unrelated logs.

That’s the “raw” way to do it right now - but it could be really fun to explore some kind of higher-level dedicated “Observation Management” module on top! Maybe with some kind of dashboard that helps you define and track different “threads” of observation that you are interested in, linking them all together in the background for you. (Perhaps a dedicated forum topic?) :slight_smile:

@walt @paul121 I agree “Map Imagery” seems to be the best label for what you were describing - to make it clear that it’s for maps, not more general imagery/photos/observations.

9

Hi folks: just want to provide my perspective here. @paul121 have been working on the arable 2.x integration and we’ve decided the NDVI data (very common for aerial imagery) should be a data stream. It seems to me this standard should be consistent for other forms of NDVI/reflectance data in the data model. You could classify everything on the farm as an “asset” if the only requirement is that it cost money. Instead, I’d propose that imagery be an “aerial imagery” or “remote sensing” data stream as these are industry standard names.

In terms of data management, running a local instance of geoserver was very laborious in my experience. I ended up having to add imagery URLs to add imagery layers to farmOS-map, and I had to make sure the geoserver was operational. For satellite imagery providers, an API options such as this: Overview | Leaf could be a nice way to offload the bulk of the data management for very little cost.

High resolution aerial imagery from drones and manned-aircraft is an entirely different beast…perhaps something that would be managed better by a service provider. I think at the end of the day, you want to avoid a situation where the user ends up managing imagery instead of managing the farm. Just my two cents.

2 Likes
10

Cleaning up some old issues in the drupal.org/project/farm issue queue, and came across this one, which has some related thoughts: Add function to add areas to uploaded images [#2931048] | Drupal.org

11

Another similar idea might be “Document” assets: Document center [#2965987] | Drupal.org

12

This would be pretty cool, could be implemented in various ways, but I do kite and multispectral photography so adding map overlays would be awesome

2 Likes