When planning a caving trip there are lots of things to consider; whether the difficulty matches your groups abilities, whether the trip will be safe given the weather, and whether you've got the right equipment to actually do the trip. In the Yorkshire Dales this last one is particularly relevant, as so many of the caves are vertical in nature and require substantial amounts of rope to abseil down into.
This planning complexity tends to limit the trips that people go on, not because there aren't other trips that would be suitable, but because it's difficult to evaluate all these considerations if you haven't been on the same trip before. Guide books are extremely helpful, as they compile all this information (and more) into one easy reference, but some regions have multiple guidebooks, and even so you'd have to manually flick through every listed trip if you wanted to explore all your options.
Enter What can I rig?, a website that takes a list of exactly the rope lengths that you've got, and spits out all of the possible trips that you could do (in the Yorkshire Dales) with those ropes.
To work this out it uses a list of trips and the rope lengths required to undertake them, compiled from a number of websites and guidebooks including:
As it's hosted on Github it's very easy for the community to keep expanding this list as new discoveries are made - I'll try and keep an eye on the CNCC website but pull requests are greatly appreciated!
I've designed the site so that all the processing takes place in the browser using javascript. This means that I don't need any resources to host it (thank you Github Pages), but also that it was very easy to turn it into a Progressive Web App that can be installed on your phone and used offline, which is particularly useful in remote signal-less caving huts.
I've also taken this opportunity to learn a bit more about CI/CD and Github Actions. Now, when changes are committed to the main
branch of the repository, a GitHub action minifies the javascript, CSS, and HTML in the repo and pushes these changes back to the gh-pages
branch, from where another GitHub action builds and deploys the site on Github Pages!
If you're interested in implementing something like this in your own projects you can might find the workflow .yaml
file a useful reference.