Dataset requirements to enhance interoperability with other packages

[jbusecke]

During today's meeting, we discussed the vision for glidertools, and one aspect seemed to already crystalize: We do not want to attempt to build a "do it all" package.

Instead, I think glidertools should emphasize modularity and interoperability with other packages.

As pointed out during the discussion and here we probably should come up with a more precise definition of the datasets we would like to have as a base for such a 'plug-and-playable' software ecosystem.

1. I think we all agree that the data model of xarray is and should stay the core data model within the gt community. From this follows that all tools we consider 'compatible' should input/output xarray datasets.
2. But we probably need more requirements in terms of what variables/coordinates/metadata needs to be included, and what would be 'nice-to-have' but not necessary for the core functionality. I am very strongly in favor of using existing conventions if possible. I am not very familiar with the conventions used, but if we e.g. adopt CF conventions internally, there are already community packages like cf-xarray and pint-xarray that could be used here to avoid overlap and save some energy.
3. This also suggests that we will work on moving the platform-specific 'reading/writing to specific data formats to specialized packages, which will then put out a gt-compatible xarray dataset. (To the comment above, these packages would then have to ensure to convert/translate metadata into a common convention). @kerfoot seems already to have a suitable package that could perhaps serve as an example for other glider platforms?

Next steps

• First I would like to get a broader overview if the sentiments I outlined above are in fact a consensus amongst folks here. Please comment below, especially if you think that your workflow would not work with the above constraints or you see other potential problems.
• Does the current code base exclusively work on 1D data (e.g. a timeseries)? Or are there parts that work with profile data only? It would be helpful to enumerate these different group.
• Once we reach a consensus on what we want/wish from an input dataset, we should probably have some automatic way of checking that a dataset is fully compatible.

[jbusecke]

Also it might be very useful to add your packages or ones you would like to work with glidertools into #127