Generalize Annotators

[jbednar]

The EarthSim project is explicitly designed to be a sandbox where we work out initial solutions to problems in earth-related simulation, first in a very specific form in example notebooks (in examples/topics), then with somewhat generalized code pulled out into a python module (in earthsim) and documented in the user guide. Wherever possible, code should then eventually migrate out of earthsim and into a more general purpose library, as long as the code can be expressed in a way that is no longer specific to the particular earth-simulation use case where it originated.

The GeoAnnotators classes in earthsim/annotators.py are currently in the middle of such a trajectory, as they can be used as-is for a variety of different purposes but are fundamentally limited in that they require a map to be present and that each such class has a certain fixed number of drawing tools and associated streams, each with hard-coded configuration parameters tied to them at the annotator class level.

From a brief survey of the code involved, it looks to me like it might be possible to generalize this approach so that it supports any number of associated tools with matching data streams, provided as a list, rather than having a fixed supported set of such tools. Each tool/stream would be configured individually, not at the Annotator class level, and the Annotator would iterate through them, link them up as appropriate, and so on. I have not tested this approach, and there are likely to be some tricky issues involved, but it seems like something along these lines could eventually move into HoloViews (if not geo-specific) or at least GeoViews (if the coordinate-system support needs to be handled within these classes) (or maybe one in each project).

Making such a change would not only minimize the code needed to be maintained in EarthSim, but would also likely reduce the amount of user code needed in their own applications, because right now users are likely to have to copy the Annotator classes and edit them for their own use, and a general approach might avoid the need for such minor variations.

[kcpevey]

I REALLY like this idea and it would help me out a ton! Right now I'm doing exactly what you mention - copying the Annotator classes and modifying them. I'm trying to keep all ducks in a row, but I'm having issues. A more generalized approach would definitely be helpful.

[jbednar]

Great; thanks for the motivation! It will be really helpful for us to see what you come up with so that we can generalize this approach in the right way to cover whatever it is you ended up needing to do.

[kcpevey]

I'm still struggling with adapting the annotators - specifically with dynamic tables. I think separating out the table generation from the basic annotator would be helpful to me. @jbednar - any updates on generalization?

[philippjfr]

I'm still struggling with adapting the annotators - specifically with dynamic tables. I think separating out the table generation from the basic annotator would be helpful to me

That's definitely the trickiest part, I'm still brainstorming about ideas that would allow the datasource to be shared between the polygons and the table, like it is for the points. Then all of this complexity just disappears.

[kcpevey]

@philippjfr Is this still blocked?