Skip to content

Update goes-restitch.py to adhere to Mission Standard Naming Conventions#9

Open
mzuranski wants to merge 1 commit intoUnidata:mainfrom
mzuranski:master
Open

Update goes-restitch.py to adhere to Mission Standard Naming Conventions#9
mzuranski wants to merge 1 commit intoUnidata:mainfrom
mzuranski:master

Conversation

@mzuranski
Copy link
Copy Markdown
Contributor

See here for more details on the ABI File Naming Conventions: http://cimss.ssec.wisc.edu/goes/ABI_File_Naming_Conventions.pdf

@CLAassistant
Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.


Mike Zuranski seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
You have signed the CLA already but the status is still pending? Let us recheck it.

@mzuranski
Copy link
Copy Markdown
Contributor Author

I don't think I realized this PR was still pending until now, not sure how that happened.

Then I see above: "please add the email address used for this commit to your account." That could be a problem @dopplershift, any way you could help me out here?

@dopplershift
Copy link
Copy Markdown
Member

Sorry for the delay. We can certainly take care of the CLA issue here.

I think the reason this lingered is because I'm not particularly thrilled with this change. While I understand the conformance to the naming from the rest of distribution of the GOES-R series of products, I also find that naming scheme to be outright user-hostile. So little of the data we deal with in meteorology use the julian day, so moving away from YYYYMMDD seems like a step backwards from a usability standpoint, not to mention the fact that the standard naming has 3 separate times that are not immediately clear or intuitive what the difference is.

I think if this naming became an option, rather than the default, I'd be more in favor. That said, I'm certainly open to hear what the benefits are for conforming to the standard.

@mzuranski
Copy link
Copy Markdown
Contributor Author

I do not disagree with your stance, I think I was mostly in favor of adhering to conventions at the time, but you're not wrong about the "choices" made in that standard.

I'll ruminate on what the best actions here might be and will come back with more later. Thanks!

@mzuranski
Copy link
Copy Markdown
Contributor Author

One thought I have right away is to add a cli arg to opt in for the standard naming convention, all the code already exists between branches so that might not be a very complex undertaking. 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants