Unidata
Function for parsing WPC coded surface bulletins
In response to issue #1153, the PR introduces a new function in the IO module for parsing WPC coded surface bulletins. Provided a path to a file, or a file-like object, the function returns a geopandas GeoDataFrame containing the data from the bulletin. Each row of the dataframe represents a pressure center or frontal boundary. The main use of this function is to provide support for the ability to plot surface analyses with MetPy.
Additionally, this PR includes a small change to open_as_needed() in _tools.py. In order to get some WPC surface bulletins, I was using urllib.request.urlopen("https://www.wpc.ncep.noaa.gov/basicwx/coded_srp.txt"), which returns an HTTPRequest object. open_as_needed() was throwing an error when trying to use seek(0) on that HTTPRequest object. Maybe there is a better solution than adding a try/except, so any additional feedback on that would be great.
Checklist
- [X] Contributes to #1153
- [ ] Tests added
- [X] Fully documented
How do I add a new text file to our staticdata folder and use get_test_data() to access it from a test function?
I've tried adding my file to staticdata on my local repo, but when trying to use get_test_data(), it looks for the file on the Unidata repo (https://github.com/Unidata/MetPy/raw/main/staticdata/WPC_sfc_fronts_20210628_1800.txt)
Above issue resolved by recreating the data registry with python -c "import pooch; pooch.make_registry('staticdata', 'src/metpy/static-data-manifest.txt')" after putting the new data file in the staticdata folder.
@23ccozad I've taken what you started and pushed it across the finish line, leveraging what's in #2420. Can you mark this as no longer a draft? I'm unable to do so.
Ok, rebased on #2420 so that we can sensibly plot. One idea I had was to make an example of a simple low pressure system plot using this stuff as a simpler example using the path effects.
EDIT: Simple example done separately in #2997
Hrmm...also one other issue: We're currently optionally depending on Shapely, which is no burden since it comes in with the optional dependency on Cartopy. This would be harder to keep optional here.
@dcamron any thoughts on what to do with Shapely (e.g. depending on it or jumping through hoops)?
Hmmm... Would it be more difficult than the cartopy machinery you've already put in place? Not to totally rebuild WPC parsing to be able to work without Shapely, but to just have it fail on run instead of import without it.
I think realistically it would affect very few people negatively to fully depend on Shapely. It does feel a little conceptually gross if we've already done similar work to help out those very few people, and Shapely does feel ever so slightly heavier to jam into all of metpy.io than say Pandas.
We could import Shapely inside the wpc parsing function since it's only used there. That seems pretty limited. We'd need to add some machinery to require shapely for the tests, which isn't scary. I'd say that's the way to go.