mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-11-22 15:21:55 +00:00
183 lines
11 KiB
HTML
183 lines
11 KiB
HTML
<!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: 3 August 2022</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,
|
|
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 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.
|
|
<p>We seem to have lost the expo twitter account credentials.
|
|
<p>We have an expo Facebook account.
|
|
<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>Managing periople'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). See the design document <a href="namesredesign.html">handling people's names properly</a>.
|
|
|
|
<h3>Writing Cave Descriptions</h3>
|
|
<p>In 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>This needs a small but significant re-design.
|
|
|
|
<h3>Consistency Checking between Input Sources</h3>
|
|
<p>We have a manual, offline, poorly-documented script <a
|
|
href="scriptscurrent.html#survex">check-svx.sh</a> which does some checks on survex files' *ref wallet
|
|
references. We have a similar thing <var>check-xml.sh</var> that checks Tunnel file references to survex
|
|
files. We have the beginnings of a parser to do the same for Therion drawings. These are currently
|
|
no better than proof-of-concept and need to be rewritten in troggle.
|
|
<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 Therio files with no documented link to their source data
|
|
in survex files.
|
|
<p>We could do with better reports on survex files which have neved been drawn up ("tunnelled").
|
|
|
|
<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 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.
|
|
|
|
<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="namesredesign.html">handling people's names properly</a>
|
|
<li>New systems for <a href="menudesign.html">website menus</a>
|
|
<li>New <a href="lbredesign.html">logbook coding system</a> - not at all urgent
|
|
<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>
|