<p>We have no procedure for this. And also no proper procedures (or even agreed single final location) for rigging topos either. We have a bucket folder for final drawn-up surveys on expofiles.
<h3>Use with Common Social Media</h3>
<p>The 2019 expo was documented on two different blogs and the content has still not got copied into
our own expo logbooks. One of these is UK caving, and for one post the caver used an ephemeral
location for the illutrating photographs - which were very good. We have these archived on expofiles
somewhere. [We now have a documented, but convoluted, procedure for managing this, see <ahref="/handbook/computing/log-blog-parsing.html">log-blog-parsing</a>.]
<p>We have an incresing number of "pending" caves where we have some data about them, but nobody has written even the beginnings of a cave description file. See the pending list from the most recent import in <ahref="/dataissues">caves</a>.
<p>[Much better now that an external script has been incorporated into troggle and a form has been created for editing wallet data in July 2022. See <ahref="/wallets/year/2019">2019 Wallets</a>]
<p>We have all the wallets data for 1999 but it needs to be restructured into the modern file structure
before we troggle can make sense of it. (We have scanned survey logbooks for 1989-1998 and a wallet structure
could be restrospectively created with a bit of data archeology. If we did that, we could then apply the same
data consistency tools. This is only likely to be worthwhile if we need to seriously return to 1623/161).
<p>We have proof of concept for <ahref="/api/expeditions_json">one</a> of these: a simple list of
expeditions. There are 61 different types of reports produced by troggle, some of which have complex
internal structure which would need several API URLs. Nobody has attempted to produce any kind of alternative
special-purpose front-end yet.
<h3>Onboarding new People to Help</h3>
<p>This is discussed on <ahref="https://app.element.io/#/room/!wTGfwrwfiRMsZvzGZW:matrix.org">Element</a>
and there are extensive previous discussions on <ahref="https://app.slack.com/client/TQF95LK8T/CSCD0HW3S/thread/CQUM4L3HD-1579458900.001800">Slack</a>.
<h3>Expofiles archiving</h3>
The <ahref="/expofiles">expofiles</a> folders are 40 GB of folders with no documnted archiving or backup procedures.
Informally, several expo nerds have complete copies, but some better means of managing it are overdue.
<h3>Fossil Software that needs Replacing</h3>
<p>There are a lot of things where the troggle software mostly works, but is clunky or confusing, and where
the maintenance is difficult because several different epochs of software techniques are munged together.
So this makes future enhancement slower and more difficult as historic special cases need to be re-done.
This is technical debt.
<p>We import <b>cavers' names</b> in three separate places: the folk list, the names of the surveyors in
survex files, and the names of expoers in the logbooks. These are inconsistently validated.
<p>We have half a dozen different <b>logbook HTML dialects</b> for different eras of expo logbooks. These should be
converted into one, simpler form. Then we can reduce the size of the logbooks parsers substantially.
<p>We have the HTML folder structure for complex caves in the same <b>URL namespace as the cave descriptions</b>
generated by troggle. This is a fossil from when the cave descriptions were actual HTML files (generated
offline) and needed to be local so that they would have simple access to the linked photographs and passage
description pages. This prevents us using "EditThisPage" on those complex descriptions, which thus adds
another level of pain on doing this task which is already much more difficult than it needs to be.
<h2id="change">New Things Troggle will need to Manage</h2>
<h3>Users with Only a Phone, No Computer</h3>
<p>The possible alternative front-ends using the (in development) API would help.
As would a complete alternative phone-centric design of the CSS and <ahref="menudesign.html">menuing system</a>.
<h3>GPS altitudes</h3>
<p>GPS is currently great for route-finding and locating entrances, but it is much less useful in those
parts where there are steep cliffs as the height accuracy is dreadful. When GPS fixes the altitude
accuracy, it will open a new range of uses.
<h3>3D Cave surveying</h3>
<p>There are some wonderful demos of fly-through surveys which use visual flow, phone ultrasonic range
detection and/or lidar. These will be big files and unsuited to being stored in a git repository - as we
currently do for Tunnel and Therion Drawings.
<h3>Geographic Software (GIS) and Terrain Model Integration</h3>
<p>One-off attempts have been made at this for the past 15 years at least, e.g. the 3D view of the whole
SMK ridge on <ahref="/guidebook/areas.htm">the Areas page</a>.
<p>Historic QGIS work is archived at <ahref="/expofiles/qgis_resources">expofiles/qgis_resources</a>
expofiles\qgis_resources
<p>CaveView does a wondeful job of animating 3D survex centre-lines, and when this is restored to use it will
make a difference.
<p>Julian has a high-quality lidar of the whole plateau area but it has not been as useful as we hoped.
<h3>Good Internet Access across the Plateau</h3>
<p>Troggle is now sufficently portable that we can run the entire system on a laptop: it doesn't need
internet access. We could design clever caching so that just an ordinary web browser could take effective a
complete copy, but if universal internet access is coming anyway, any such work would be wasted.
