ReimarBauer
commented
7 years ago Original comment by Andreas Hilboll (Bitbucket: andreas-h, GitHub: andreas-h).
Points raised in this issue were my motivation for the MSSChemDataAccess class, because I wanted to have an easy way of adding new forecast datasets without having to touch the MSS code base. I simply wanted to have to think about all the regex stuff once and not have to remember when adding a new data set some months later ;)
For the other end, I started https://mss-chem.readthedocs.io, which is meant to be simply a downloader for chemical weather forecast data and takes care of pre-processing the downloaded files so that they can be used by the MSSChemDataAccess class.
Now, every time I'm implementing support for a new data set, I simply have to write one function which takes care of re-naming, rescaling, and adding the standard_name attribute. However, while doing so, I'm often spending a lot of time inside MSS internals, because the WMS server's error messages are often not very helpful.
So, yes, in my eyes especially a) would be great :-)
Original report by Joern Ungermann (Bitbucket: joernu76, GitHub: joernu76).
Setting up a WMS server using the data access classes is more difficult than necessary.
a) The current classes do not provide sufficient logging to enable identification of problems such as why files are not found, why init_times, but no valid times are identified, etc.
b) A new kind of data access class could be written that "simply" parses all netCDF files, identifies its vertical axis, standard_names, init time, valid times, and uses that to build a cache of where requested information may be accessed.
Point a) could be simply and quickly adressed by providing more logging facilities. Point b) could be adressed by a new, more powerful data access class that would not require the error-prone configuration of the regular expressions in combination with proper naming of the netCDF files. If this is feasible, only a prototype implementation may tell.