API design for non-map plots

[JamesVarndell]

The earthkit-plots API is designed to leverage domain-specific knowledge to reduce boilerplate code and make earth science visualisation more accessible. For map-based plots, this has led to features like:

• Metadata-aware templating for titles and styles
• Unit-aware levels for contouring
• Named domains to simplify plot extent selection
• Quickplot to automate as much setup as possible based on data metadata

These features work well because most map-based plots are derived from data formats rich in metadata (e.g., netCDF, GRIB).

However, earthkit-plots also needs to support non-map visualisations—such as line charts, bar charts, quantile plots, tephigrams, and other 2D plots. The challenge is ensuring that our API for these plots is effective and intuitive.

Discussion Points

1. How can we add value for users with our non-map plots API?

   • What are the biggest pain points in existing workflows that we can address?
   • Are there opportunities to simplify common tasks through automation or smart defaults?

2. What are the most common data sources for non-map plots?

   • Are there additional sources (e.g. Pandas dataframes) that we need to improve support for?

3. Which existing features of earthkit-plots can benefit non-map plots?

   • Can unit conversion, metadata-aware styling, or templating be extended beyond maps?
   • Are there specific adaptations needed for these features to work with 2D plots?

4. Is the current Styles API suitable for non-map plots?

   • Do we need a different or extended approach to styling for these plots?

5. How can we make it easy to create common climate and meteorological plots?

   • Should we introduce high-level classes or functions for specific plot types (e.g., meteograms, hydrographs)?
   • What is the most user-friendly API design for these specialised visualisations?