softwareunderground / awesome-open-geoscience Goto Github PK

The descriptions are usually something along the lines of "Python package for..." and "Matlab code that does...".

We could add little icons for programming languages and shift the focus of the utility rather than the dependency. What do you think?

What is the intended extent of https://github.com/softwareunderground/awesome-open-geoscience#data-repositories?

Like, should there go things like

• https://wiki.seg.org/wiki/Open_data
• or Equinor-Volve?

Open-source spatial software development in the R language:

• https://github.com/r-spatial/
• https://www.r-spatial.org/ (website/blog/news)

PR #76 removed the Digital Rocks Portal data repository because their SSL certificate is messed up. We should add it back eventually when the site is back up. Here is the entry:

- [Digital Rocks Portal](https://www.digitalrocksportal.org/) – Powerful data portal for images of varied porous micro-structures

Link times out, needs replaced ?

http://www.ontosoft.org/portal/#list

I stumbled upon Ontosoft recently, which is a compilation of geoscience academic software.

Not all is open-source and I've not used any of them yet, so I decided to just post here in case anyone wants to check them out.

Travis CI keeps failing due to link issues that aren't easy to understand

Need someone to spend some time learning about the script being used for CI and what those error messages mean and then prevent them.

I've been merging using admin rights as it seems there is a CI error of ambiguous meaning or no consequence every time.

LINK TO A RUN EXAMPLE:
https://travis-ci.org/github/softwareunderground/awesome-open-geoscience/builds/774515998

Maybe should abandon current CI methods and go to GitHub Actions that runs a link check every month and then adds issue if there is a fail. Current set-up tends to slow merging of pull requests for little benefit.

It should be possible to build a script that parses the README for all the links then checks those links... could this be implemented on Travis?

Noticed colorcet has a broken link and thought of this

Suggestion to rename the default branch of the repository to main.

Very straightforward to do, just would want approval from a few folks (e.g., @JustinGOSSES, @kwinkunks).

from the results of the link checker run by github actions

✗ [403] https://www.usgs.gov/software/phreeqc-version-3 | Failed: Network error: Forbidden
✗ [403] https://www.usgs.gov/software/modflow-6-usgs-modular-hydrologic-model | Failed: Network error: Forbidden
✗ [404] https://en.wikipedia.org/wiki/Comparison_of_free_geophysics_software | Failed: Network error: Not Found

Suggestion: For packages on PyPI it could be helpful to give visitors the indication of package health from Synk.

e.g. [![segyio](https://snyk.io/advisor/python/segyio/badge.svg)](https://snyk.io/advisor/python/segyio) gives

Any thoughts?

It's currently broken. When the package name debate settles, please fix the link.

Contact Details

[email protected]

Why

I enjoy this list and frequently use it as reference. I’m relatively new to SWUNG and want to get more involved. I also want to learn maintainer skills.

How have you participated

I’m relatively new to swung (about 1yr). I participate in discussions on the slack/Mattermost channels. I frequently use the resources on this repo for my daily work as a geo data scientist @ThinkOnward (formerly Studio X).

I’m a geoscientist by education, with a BS and MS from Kansas State. I worked as a geophysicist at APC/OXY from 2014-2021 in the GoM. I left to pursue an opportunity in data science.

Code of Conduct

• I agree to follow this project's Code of Conduct

The "Simulation and Modelling" category is quite broad at the moment. There is lots of overlap with the "Geophysics" category: e.g. emsig, Fatiando, ResIPy, SimPEG, ... would all fit under "Geophysics". Would it help with discoverability of packages to try to move project names out of "Simulation and Modelling" which might be a bit of a catch-all at the moment?

The GeologicPatterns library does not seem to have a license, we should remove it for now and wait for it to have a proper open license.

Hey there,

this is a nice collection. Maybe our GeoStat-Framework fits in here.
We provide a set of Python packages for geostatistical simulations:

• GSTools: GeoStatTools provides geostatistical tools for various purposes:
  • random field generation
  • conditioned field generation
  • incompressible random vector field generation
  • simple and ordinary kriging
  • variogram estimation and fitting
  • many readily provided and even user-defined covariance models
  • plotting and exporting routines
• ogs5py: A python-API for the OpenGeoSys 5 scientific modeling package. OGS5 is an open-source, finite-element solver for thermo-hydro-mechanical-chemical processes in porous and fractured media.
• welltestpy: A python-package for handling well based field campaigns with a special focus on estimating parameters of aquifer heterogeneity from standard pumping test data.
• AnaFlow: A python-package containing (semi-)analytical solutions for the groundwater flow equation with a focus on effective type curves for heterogeneous aquifers.
• Walks: The Ministry of Random Walks provides methods for:
  • particle tracking
  • Lagrangian transport
  • travel time estimations

All these packages are working nicely together to generate workflows for simulating geostatistical setups.

Cheers,
Sebastian

Thanks for maintaining this amazing list!

Your list is heavy on the solid-earth side of geosciences. Are packages for climate / ocean / atmospheric science in scope? If so, I can make a PR with some suggestions?

FYI, I come from the pangeo project and found this list via @lheagy.

The description in https://github.com/softwareunderground/awesome-open-geoscience/blame/master/awesome.md#L9 is vague to me... I'm curious if there is a checklist of what might make software "awesome" and ready to be added to this list?

I'm asking because I've seen a few projects show up in PRs that maybe aren't as awesome as some of the projects listed here.

Example

Compare GemPy (on the awesome list) and a proposed change like that in #74

GemPy is pretty awesome in my opinion - it has excellent documentation, a new-user-friendly README, lots of tutorials for new users to get up an running, and it's generally accessible (installable via a package manager like pip).

Meanwhile I’m struggling to find these aspects of the project in #74 which proposes adding MB-System. This software has a difficult to read/understand README, no API documentation (or at least after clicking around their website, I did not immediately see it), and no(?) existing examples for new users to get their hands dirty. Although it does appear to be generally accessible (installable using Homebrew)

Add the DOI badge to README and attempt to auto modify a citation file via GitHub actions

https://doi.org/10.5281/zenodo.8354180

Summary of our potential maintainer sustainability problem:

Looking at the contributions graph data: https://github.com/softwareunderground/awesome-open-geoscience/graphs/contributors confirms that I've become the main source of pull request approvals, though @amoodie and @banesullivan have also done some approvals. For a couple reasons, I would like to see more diverse pull request approvals. One is the bus factor. The term bus factor refers to what happens if someone gets hit by a bus tomorrow.

Hypothesized Social Dynamics:

I suspect there's a couple things going on to cause this pattern.

• I can sometimes be quick to jump on easy pull-request approvals as I'm on github for work and non-work reasons most days. This unfortunately takes away opportunities from others to make quick approvals.
• It can be less than obvious whether to approve inclusion on the list for early projects that lack a long record of community engagement as shown by stars, forks, etc. To figure out whether to approve those projects often takes installing them and going through an example or two to make sure they work and do what they say they do.
  • For newbies, they might think doing this work requires someone more experienced?
  • For more experienced folks, they can sometimes be less interested in messing with code they're not going to use?

Maintainer Tasks Before Pull Request Approval:

For clarity, I'll summarize the typical maintainer tasks related to pull requests.

• Go through the checklist as the user fills it out in the pull-request and see if there is anything not-checked there that is critical.
• Go to the README or project page of the project and see if there is pre-existing high levels of engagement as demonstrated by forks, stars, issues, and pull-requests that seem to come from outside the core owners group. If so, probably can go ahead and approve.
• If the project is new and lacks an existing community, it might still be awesome, but this requires more work. At a minimum, the maintainer should (1) make sure the code is installable (2) run a few examples (3) determine if there's a reasonable chance the functionality of the code is elegant and broad enough to be useful to others.

Rough Proposed Solution:

• Move to have at least 3 listed "Current Maintainers" on the README.
• Add a "How to be a Maintainer" markdown file linked to from the CONTRIBUTING.md file that explains the tasks of the maintainers and sets some base expectations in terms of:
  • X days after a pull-request is submitted, there should be some response in the thread.
  • Maintainers can let each other know they're going to be "off" for a month or quarter due to other responsibilities.
  • Any maintainer who responds to more than 75% of the pull requests, should perhaps consider making space for others and how to to about doing that.
  • Plus some suggestions on setting up GitHub notifications such that PRs on the awesome-open-geoscience repository do not get lost in the shuffle.
• Pitch being a listed maintainer as:
  • Ideal for newbie and intermediate coders.
  • A learning opportunity where you get to try out new code.
  • A learning opportunity for what is involved in being a project maintainer, but with relatively low stakes and low complexity.
  • Something people can list on their resume if they'd like.
• Source listed maintainers from:
  • Mention the need in CONTRIBUTING file and README.
  • SoftwareUnderground Slack.
  • Ping previous contributors in last 3 years in an announcement issue.

NOTE: This is a quick proposal. Fee free to offer modifications, additions, or completely different takes.

Please add public data websites:

• NL: https://www.nlog.nl/datacenter/
• US\ND: https://www.dmr.nd.gov/oilgas/
• US\KS: http://www.kgs.ku.edu/PRS
• US\TX: https://www.rrc.texas.gov/resource-center/research/data-sets-available-for-download/
• US Gov: https://catalog.data.gov

Respected sir/madam,
KIndly help me in getting seismic facies identification python project using segy data.

Regards,
Satish

Broken link: http://fuzzylas.appspot.com/ .

Looks like it just went down. Should remove from list.

If anyone ever wants to bring back up, the code looks to be on: https://github.com/agilescientific/fuzzylas

(created 10 years ago as of 2022!)

Most icons are not shown on Firefox (Ubuntu 18.04, Firefox 65). They are shown on Chrome (73).

Firefox

Chrome

Link for Pyrocko should point here: https://git.pyrocko.org/pyrocko/pyrocko rather than here https://github.com/pyrocko/pyrocko

the DuMuX website is down - causing Travis to fail. Perhaps we should link to the repository instead of their website?

https://git.iws.uni-stuttgart.de/dumux-repositories/dumux

This also raises the question on whether links here should point to the code repository (proving it's open-source) or to the documentation/homepage of the listed project

We have the platform category with Open dtect. Qgis would fit in there as well. However, these also fit in seismic and geospatial respectively.

Should we put them in the seismic/geospatial categories? Platform category? Or double them and put them in both?

I'd like to suggest some small set of icons that we could use to indicate what kinds of data files are contained within the various open data collections.

This would require a little bit of graphic design work. Any takers?

Icons might include:

Standard formats:

• stacked seismic (SEGY)
• prestack seismic (SEGY)
• VSP (SEGY)
• petrophysical data (LAS)
• petrophysical data (DLIS)
• Shapefiles (lines, points, and polygons)
• etc.

Non-standard formats (this will be harder to contain)

• horizon files (ASCII, csv, etc)
• Deviation surveys (ASCII, csv)
• Time-depth tables / checkshots (ASCII)
• Well tops markers (ASCII, CSV)

etc.

Perhaps such a feature could be used to incorporate the notion of a standardized summary page for each dataset. Consistently documented and curated. Could even write a script to build such a summary directly from the data set itself – as a first order entrance exam to test the data quality of the dataset.

Would it make sense to include a category if repositories that include code and/or data from papers?

Here's one example. -. https://github.com/UP-RS-ESP/PebbleCounts

I think there should be more out there?

Found a new-ish library called SciKit-GStat, for variogram type calcuations.

https://mmaelicke.github.io/scikit-gstat/index.html

Deserves a review for the Geostats category.

https://github.com/chrisleaman/awesome-coastal

Would it make sense to add a ground penetrating radar (GPR) category? I see no category under which open GPR processing software like GPRPy, RGPR, or readgssi can fit (disclaimer: readgssi is my own software, so whether or not it's awesome is arguably not my place to decide).

I would love to see a place where open GPR software is enumerated and this repository seems perfect for that purpose.

Would it be worthwhile to a sub-category to datasets along the lines of "data in bulk", "bulk download available", or "machine-learning ready"?

A lot of the open datasets out there take a lot human typing to extract large enough datasets to do something with. Wells, especially, have this problem.

Alternatively, should we limit "awesome" datasets to those that don't take a lot of prep or extraction to get working with?