<!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <title>Handbook Troggle Design</title> <link rel="stylesheet" type="text/css" href="/css/main2.css" /> </head> <body> <style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style> <h2 id="tophead">CUCC Expedition Handbook</h2> <h1>What Troggle Does Badly - Design Decisions</h1> <p>Practical use of troggle quickly shows up serious shortcomings: <ul> <li><h4><a href="#fail">Things Troggle Doesn't Do</a></h4> <li><h4><a href="#badly">Things Troggle Does Badly</a></h4> <li><h4><a href="#change">New Things Troggle will need to Manage</a></h4> <li><h4><a href="#specific">Specific, Immediate problems</a></h4> </ul> <p><em>Updated: 5 September 2023</em> <h2 id="fail">Things Troggle Doesn't Do</h2> <p>Mostly these are not just a problem just with troggle, but things where expo procedures have never been properly created or applied, or where there was a procedure but it fell out of use because it wasn't easy enough to persist with. <h3>Finding and identifying entrances</h3> <p>This is abolutely crap. We have a manual, undocumented, probably incomplete offline set of scripts which produced a GPX file in 2019 and again in 2023 (Mark Shinwell), which we have no easy way of delivering to a mobile device. The troggle pages for the cave and entrance descriptions do not have any location information on them, as it is generated quite separately from the survex files and fixed-points. And it is all in Austrian grid coordinates not WGS84 too. <p>We have no procedure whatsoever to capture photos of cave entrances and to get them associated witht he entrance data in troggle. <p>Our former prospecting guide has died of terminal obsolescence. <p>It should be perfectly possible to convert the entrance data as listed in the second table on <a href="/eastings">the troggle 'ents' page</a> into WGS84 and display it in the entrance description pages. <p>We really want a prospecting map showing entrances which are clickable, so that the entrance description pops up. <p>Our procedures for 'tag', 'exact tag', and 'other tag' are undocumented and need to be redone. <h3>Using Question Marks in active exploration</h3> <p>See <a href="scriptsqms.html">the current ugly situation</a>. <h3>Proper archive/restore of Tunnel and Therion files</h3> <p>Strangely, we have no process at all to allow anyone to download the archived Tunnel or Therion XML files and also download the referenced source scan files at the same time so that the references within the XML files actually work. <p>The XML files contain cross-reference links to the scan files <em>on the computer the tunnelling/therioning was done</em> which is different for every machine as we have no recommended standard setup. <h3>Supporting Final Survey Preparation</h3> <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. 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 now have a documented, but convoluted, procedure for managing this, see <a href="/handbook/computing/log-blog-parsing.html">log-blog-parsing</a>.] <p>We seem to have lost the expo twitter account credentials. <p>We have an expo Facebook account (deprecated as many Expo users hate FB) <p>We used to use Slack and (in 2022) use Trello for expo organisation. We have moved from Slack to Element, which we can archive ourseleves, and maybe we can use Kanboard (ditto) next year instead of Trello. <h2 id="badly">Things Troggle Does Badly</h2> <h3>Writing Cave Descriptions</h3> <p>Since 2022 we have a working online form to create or edit the cave and entrance descriptions. But the URL namespace of the form is different from where the cave description will be actually published, so getting the A HREF tags and IMG SRC tags correct for the referenced passage text and photos, and also to relevant bits of logbook, is unnecessarily convoluted. <p>Martin added image-adding to the HTML editor which helps a lot. <p>We have an increasing 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 <a href="/dataissues">caves</a>. <h3>Consistency Checking between Input Sources</h3> <p>The input parser 'drawings' does some very-limited checks on Tunnel file references to survex files. Problems are reported in <a href="/dataissues">DataIssues</a> and links to wallets in <a href="/dwgfiles/">expo.survex.com/dwgfiles/</a>. We have the beginnings of a parser to do the same for Therion drawings. These are currently no better than proof-of-concept. <p>We could do with reports that identify survex files with no equivalent logbook entry (which would show up all the ARGE surveys, but we could filter those out). <p>We could do with finding drawn-up Tunnel and Therion files with no documented link to their source data in survex files. <p>We have an imperfect report <a href="/therionissues">therionissues</a> on references within in Therion files <p>We could do with better reports on survex files which have neved been drawn up ("tunnelled"). <strike><h3>Managing people's names</h3> <p>As of 2022, there are 15 people troggle can't cope with at all because their name is not structured as "Forename Surname": where it is only two words and each begins with a capital letter (with no other punctuation, capital letters or other names or initials).</strike> See the design document <a href="namesredesign.html">handling people's names properly</a>. <h3>Online Wallet Management</h3> <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 <a href="/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). <h3>API for Different Front Ends</h3> <p>We have proof of concept for <a href="/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 <a href="https://app.element.io/#/room/!wTGfwrwfiRMsZvzGZW:matrix.org">Element</a> and there are extensive previous discussions on <a href="https://app.slack.com/client/TQF95LK8T/CSCD0HW3S/thread/CQUM4L3HD-1579458900.001800">Slack</a>. <h3>Expofiles archiving</h3> The <a href="/expofiles">expofiles</a> folders are 40 GB of folders with no documented 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. <strike> <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. </strike> We now (March 2023) have just one logbook format in use, and the last old logbook has been converted (Sept.2023). <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. <h2 id="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 <a href="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 <a href="/guidebook/areas.htm">the Areas page</a>. <p>Historic QGIS work is archived at <a href="/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. <h2 id="specific">Specific, Immediate problems</h2> <ul> <li>New systems for <a href="menudesign.html">website menus</a> <li><strike>New systems for <a href="namesredesign.html">handling people's names properly</a></strike> <li><s>New <a href="lbredesign.html">logbook coding system</a> </s> <li><s>Short-term note on "logon" <a href="trogregistr.html">django-registration</a></s> </ul> <p>Open architectural issues being worked on: <ul> <li>Critiqued proposal on <a href="trogsimpler.html">future architecture</a> <li>A possible <a href="trog2030.html">5 year plan</a> to 2030 <li>Speculations on <a href="trogspeculate.html">future architectures</a> </ul> <hr /> Go on to: <a href="trogarch.html">Troggle architecture</a><br /> Return to: <a href="trogintro.html">Troggle intro</a><br /> Troggle index: <a href="trogindex.html">Index of all troggle documents</a><br /> <hr /></body> </html>