Clarify scope for this project

[shoyer]

From the face of it, MetPy looks very ambitious: "reading, visualizing and performing calculations with weather data" covers a lot of ground. On the other hand, it's scope is currently much more limited.

Some questions that I tried and failed to figure out from the README/docs:

• What are your goals for this project? What is the unmet need?
• Who is your intended audience?
• How do you see MetPy fitting into the broader Python ecosystem?

[dopplershift]

Essentially, the space we're aiming for is GEMPAK (and maybe NCL) -like functionality, in a way that plugs easily into the existing scientific Python ecosystem (numpy, scipy, matplotlib). So, if you take the average GEMPAK script for a weather map, you need to:

• read data
• calculate a derived field
• show on a map/skew-T
  I don't think it's ambitious, just broad. Driving this forward, is, for the most part, the personal itches developers want to scratch. This is why the calculations are (currently) mainly those needed for sounding analysis; or why there are exhaustive NEXRAD level 2 and 3 implementations.

The intended audience is that of GEMPAK: researchers, educators, and any one wanting to script up weather analysis. It doesn't even have to be scripting; I'd be happy to see the calculation routines used to drive a python GUI utility. Conversely, it's the meteorological equivalent of the audience of scipy/scikit-learn/skimage.

One of the benefits I hope to achieve here over GEMPAK is to make it easier to use these routines for any meteorological Python application; this means making it easy to pull out the CAPE calculation and just use that, or re-use the Skew-T with your own data code. I also want to produce a project that is well-documented and well-tested, so that on-going maintenance is easily manageable.

As far as the current scope, it is what it is: version 0.2. PRs welcome. :) Seriously, this project has been the vision of a group of then-graduate students since 2008. It started as a dumping ground for all of our various weather-related hacks. It's only recently (April) that we've had the time to put into working on it, clean things up, and get it to the point where we can reasonably expect to collaborate with others.

[shoyer]

Thanks -- you should add this to the readme!

[dopplershift]

Yeah, that occurred to me, I just need to clean it up a bit. Though I guess even verbatim is better than nothing....

Thanks for the push!

[ktyle]

Yes I also view MetPy as a library of most, ideally all of the diagnostic functions that GEMPAK has had. I know that IDV adapted many of GEMPAK's gridded diagnostic functions for use in its program. These are written in Jython; would it not be too large an undertaking to port these over to Python?

In addition to grids and NEXRAD, the ability to plot point observations (fixed and mobile) on a map (a la GEMPAK's SFMAP and SNMAP) would also be great additions to MetPy.

[dopplershift]

While the IDV functions are written in Python, they're written around the VisAd API and objects, so you'd end up almost completely re-writing them to use numpy arrays. What we have done is surveyed the functions that exist there and can use that as a guide for what's missing; and if there's some question of how to implement a function, we can use those as guides. 95% of what we do in meteorology, though, is not complex enough to worry about those implementation details.

While we spin up, IMO, it will probably be most effective to just implement what people actually notice is missing--the things people actually want to use. Use-case driven development. I'd be happy to get you (or anybody) to open issues for things you need in order for MetPy to be useful to you; a pull request with an implementation (even just a basic start of one) would be even better.

Regarding SFMAP/SNMAP, I agree. See #23 .