mirror of
https://expo.survex.com/repositories/expoweb/.git/
synced 2024-11-25 16:52:00 +00:00
What troggle does badly
This commit is contained in:
Philip Sargent
parent
a6b24483cf
commit
8e23de70f5
@ -7,9 +7,151 @@
|
||||
</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>Troggle Design Decisions</h1>
|
||||
<h1>What Troggle Does Badly - Design Decisions</h1>
|
||||
<p>Practical use of troggle quickly shows up serious shortcomings:
|
||||
|
||||
<p>Specific, immediate problems:
|
||||
<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: 11 March 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>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>Online Wallet Management</h3>
|
||||
<p>The results are not too bad, but some poor caver has to edit a JSON file in each online wallet on the
|
||||
<em>expo laptop</em>. It should be a straightforward job to move the code in
|
||||
<a href="scriptscurrent.html#wallets"><var>wallets.py</var></a> into
|
||||
troggle, create troggle reports to duplicate the 3 different types of pages produced by the script, and add
|
||||
an online form to create the equivalent to the JSON file.
|
||||
|
||||
<p>The current script does only a single year at a time. When incorporated into troggle, we will be able to
|
||||
do all outstanding years worth of work.
|
||||
<p>We have all the wallets data for 1999 but it needs to be restructured into the modern file structure
|
||||
before we can run the script on 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>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>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="menudesign.html">website menus</a>
|
||||
<li><s>Short-term note on "logon" <a href="trogregistr.html">django-registration</a></s>
|
||||
|
||||
@ -18,7 +18,7 @@
|
||||
<a href="trogmanual.html">Troggle - Maintenance</a> - list of maintenance tasks<br>
|
||||
<a href="trogarch.html">Troggle - Architecture</a> - diagrams, files, structure<br>
|
||||
<a href="datamodel.html">Troggle - Data Model</a> - syntax-coloured list of classes, instance variables and foreign keys<br>
|
||||
<a href="trogdesign.html">Troggle - Design Decisions for the Future</a> - open issues being worked on:<br>
|
||||
<a href="trogdesign.html">Troggle - What it does Badly</a> - Design Decisions for the Future<br>
|
||||
<ul>
|
||||
<li><a href="trogregistr.html">Troggle Login and user registration</a> - proposal to remove registration<br>
|
||||
<li><a href="menudesign.html">Troggle Menu Design</a> - options for replacing the menuing system<br><br>
|
||||
|
||||
Loading…
Reference in New Issue
Block a user