On this week's MetPy Monday, we're talking about the Siphon package. Why? As several users have noticed, the getupperair_data function is deprecated as of MetPy 0.6 and will be removed in MetPy 0.8. That functionality has been moved to our remote data access library (siphon) with an improved API. Learn how to use siphon in this week's video!
↧
MetPy Mondays #15 - Upper air data with Siphon
↧
MetPy Mondays #16 - Making a Basic Skew-T
The Skew-T is a fundamental plot for understanding the state of the atmosphere. This week we'll learn how to build a basic Skew-t using MetPy and continue to build on this plot for the next several weeks.
↧
↧
MetPy Mondays #17 - Resampling Wind Barbs
Last week we were able to plot a basic Skew-T, but the wind barbs suffered from over-crowding in some parts of the plot. This week we'll look at a few strategies to deal with this problem including downsampling and nearest-neighbor resampling.
↧
MetPy Mondays #18 - Skew-T Fiducial Lines
Continuing our Skew-T series, this week we'll learn how to add fiducial lines to our Skew-T plot. Theses lines, such as adiabatic paths and mixing ratios, give us a visual reference to aid interpreting the plot and they can be added with just a few lines of code using MetPy!
↧
MetPy Mondays #19 - Skew-T Parcel Path
Now that we've got all of the data plotted in our Skew-T diagram, we might want to know the expected path for a parcel. This week we'll calculate parcel paths and plot them on our Skew-T to round out a publication ready diagram.
↧
↧
MetPy Mondays #20 - Constants
We've all typed constants into our scripts before. It can be error prone and we may not always use the exact same value for the constant. This week we'll show you how to use MetPy's constants library to take the hassle out of your code!
↧
MetPy Mondays #12 - Citing MetPy
When writing research papers, we all cite other papers that we read, datasets that we use, but do you cite the software you use? Just like papers, software can be cited if it was used in your research. Citing MetPy has never been easier! We have a Digital Object Identifier (DOI), prebuilt BibTeX entry, and AMS citation. Using the Crosscite tool you can also generate a citation in just about any format imaginable! You can also tell the software engineers how you use MetPy with our Say Thanks page.
↧
Contributor License Agreement for Unidata Projects
Unidata hosts a variety of Open Source software projects on GitHub. We use the Open Source model because we believe strongly that broad participation in all aspects of Unidata's work is essential to achieving the Unidata community's goals. Developing software that focuses on community needs is one of our main objectives, and participation by community members in all aspects of the development process — from coding to testing, documenting, and commenting — is incredibly valuable.
As community participation in Unidata's Open Source efforts grows, we are facing increasingly complex situations surrounding contributions made to Unidata-hosted projects. As a result, we have decided to begin requiring that community members who wish to contribute code to Unidata projects on GitHub agree to the Unidata Contributor License Agreement (CLA). This agreement is based on a template from the Harmony Agreements project, whose goal is to standardize CLA's within the Open Source community.
What is a Contributor License Agreement?
A Contributor License Agreement (CLA) defines the terms under which intellectual property is contributed to a project. In Unidata's case, the CLA covers software code contributed to Unidata-hosted projects distributed under Open Source licenses. While the Unidata CLA is a legal document, and you should read it carefully before agreeing to it, the two main ideas are:
- You retain the ownership of the copyright to your contribution
- You grant Unidata the right to use your contribution in perpetuity
We feel it is important to use a CLA on Unidata-hosted projects for several reasons. Most important among them is the idea that once a Unidata software product has been released to users, the users can be confident that they have the right to continue using the software. Adding some formality to the software contribution process helps the Unidata community make well-informed choices about the benefits of using Open Source software.
The CLA process Unidata is adopting is becoming more and more common in the Open Source community. We don't think that asking contributors to sign the agreement will present a significant barrier to participation, and we believe that adding this layer of formality will benefit the Unidata community as a whole.
How it Works
When contributing using a Pull Request on GitHub, the following message will present itself, using CLA Assistant, as a comment on the pull request:
Contributors can click on the yellow "CLA not signed yet" badge, which will take them to a copy of the CLA. Contributors are asked to provide a little bit of information about themselves (for legal purposes):
Once the "I Agree" button is clicked, the browser will return to the original pull request page, but now the comment has been updated:
Contributors will only be asked to electronically sign once (unless the CLA is updated), and the agreement applies to all GitHub repositories hosted under the Unidata organization.
For more information about CLAs, see these resources:
- Harmony Agreements
- "Producing OSS" has a section on Contributor Agreements
- A more detailed blog post by Julien Ponge about CLAs
About the Contributor License Agreement
Unidata's CLA comes fromProject Harmony, which is a community-centered group focused on contributor agreements for free and open source software.
The document you are reading now is not a legal analysis of the CLA. If you want one of those, please talk to your lawyer. This is a description of the purpose of the CLA.
Why is a signed CLA required?
The license agreement is a legal document in which you state you are entitled to contribute the code/documentation to Unidata and are willing to have it used in distributions and derivative works. This means that should there be any kind of legal issue in the future as to the origins and ownership of any particular piece of code, we have the necessary forms on file from the contributor(s) saying they were permitted to make this contribution.
The CLA also ensures that once a contribution has been made, contributors cannot try to withdraw permission for its use at a later date. People and companies can therefore use Unidata open source projects, confident that they will not be asked to stop using pieces of the code at a later date.
Lastly, the CLA gives Unidata permission to change the license under which the project, including the various contributions from many developers, is distributed in the future. The CLA states that this license needs to be one that has been approved by the Open Source Initiative, including both copyleft and permissive licenses. This gives Unidata the freedom to adjust licenses in the future if needed (e.g. some clause of the current license is found to be invalid; change to a standard license), so long as the license remains open source.
Am I giving away the copyright to my contributions?
No. This is a pure license agreement, not a copyright assignment. You still maintain the full copyright for your contributions. You are only providing a license to Unidata to distribute your code without further restrictions. This is not the case for all CLA's, but it is the case for the one we are using.
Can I withdraw permission to use my contributions at a later date?
No. This is one of the reasons we require a CLA. No individual contributor can hold such a threat over the entire community of users. Once you make a contribution, you are saying we can use that piece of code forever.
Can I submit patches without having signed the CLA?
No. We will be asking all new contributors and patch submitters to sign before they submit anything.
This CLA explanation is based on Django Contributor License Agreement Frequently Asked Questions (copyright Django Software Foundation. CC-BY) The content has been modified slightly to reflect situations specific to Unidata.
↧
MetPy Mondays #13 - Temperature Units
One of the most common support questions we get regarding MetPy is why temperature calculations fail. As it turns out, temperature units are a bit strange as they have an offset relative to an absolute value and a scaling factor. Learn how to properly handle temperature in your calculations with this week's MetPy Monday!
↧
↧
MetPy Mondays #14 - Adding a logo and timestamp
This week, we'll talk about some handy functions in MetPy that let you decorate your plots with the MetPy or Unidata logos. We'll also add time of creation timestamps to help you keep track of what's what in that pile of PNG files in your manuscript folder!
↧
MetPy Mondays #15 - Upper air data with Siphon
On this week's MetPy Monday, we're talking about the Siphon package. Why? As several users have noticed, the getupperair_data function is deprecated as of MetPy 0.6 and will be removed in MetPy 0.8. That functionality has been moved to our remote data access library (siphon) with an improved API. Learn how to use siphon in this week's video!
↧
MetPy Mondays #16 - Making a Basic Skew-T
The Skew-T is a fundamental plot for understanding the state of the atmosphere. This week we'll learn how to build a basic Skew-t using MetPy and continue to build on this plot for the next several weeks.
↧
MetPy Mondays #17 - Resampling Wind Barbs
Last week we were able to plot a basic Skew-T, but the wind barbs suffered from over-crowding in some parts of the plot. This week we'll look at a few strategies to deal with this problem including downsampling and nearest-neighbor resampling.
↧
↧
MetPy Mondays #18 - Skew-T Fiducial Lines
Continuing our Skew-T series, this week we'll learn how to add fiducial lines to our Skew-T plot. Theses lines, such as adiabatic paths and mixing ratios, give us a visual reference to aid interpreting the plot and they can be added with just a few lines of code using MetPy!
↧
MetPy Mondays #19 - Skew-T Parcel Path
Now that we've got all of the data plotted in our Skew-T diagram, we might want to know the expected path for a parcel. This week we'll calculate parcel paths and plot them on our Skew-T to round out a publication ready diagram.
↧
MetPy Mondays #20 - Constants
We've all typed constants into our scripts before. It can be error prone and we may not always use the exact same value for the constant. This week we'll show you how to use MetPy's constants library to take the hassle out of your code!
↧
MetPy Mondays #21 - LCL, LFC, EL
When looking at sounding data, we often want to calculate various thermodynamically important levels. This week John shows you how to calculate LCL, LFC, and EL along with some of the common mistakes we see. You'll also find tips on exploring how to use functions in Jupyter notebooks.
↧
↧
Metpy Mondays #22 - CAPE/CIN
One of the most requested features in MetPy is CAPE and CIN calculations. These were recently released and this week we're going to show you how to use them! We'll also cover a handy helper function that lets you easily subset over layers in your calculations.
↧
MetPy Mondays # 23 - Contributing to MetPy
MetPy is a community driven and focused project. This week John shows you how you can contribute to MetPy and get involved with the world of open source scientific software development!
↧
MetPy Mondays #24 - WX Symbols and Animation
In this special holiday edition of MetPy Mondays, we are going to build an animated Christmas tree with blinking weather symbol lights to learn about symbols and matplotlib's animation capability.
↧