expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-08 23:04:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Sorting out troggle design docum.

Browse Source
This commit is contained in:
Philip Sargent
2020-06-04 02:12:54 +01:00
parent 91fc44a486
commit 6e3b781a27
15 changed files with 749 additions and 309 deletions
Download Patch File Download Diff File Expand all files Collapse all files

307
handbook/troggle/trognotes.html
View File

@@ -7,13 +7,24 @@
</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 - TO BE RESTRUCTURED</h1>
<h1>Troggle - the beginnings of a manual</h1>
<p>Troggle runs much of the the cave survey data management, presents the data on the website and manages the Expo Handbook.
<h2>NOTES - taken from elsewhere</h2>
<h2>Who needs to know What and When</h2>
<p>This part of the handbook is intended for people maintaining the troggle software. Day to day cave recording and surveying tasks are documented in the expo "survey handbook"
<p>We have several quite different sorts of cavers who interact with troggle:
<ul>
<li>The youthful hard caver, who is trained in underground survey techniques but whose interest is limited to handing over the grubby survey notes when she emerges into daylight. Is keen to know how many km of cave she surveyed each year and to see pretty drawn-up surveys (done by someone else). Walks through walls.
<li>The surface walker who is happy to do route-finding over the plateau, takes lots of photos of cave entrances and cavers enjoying sunshine and may sometimes be able to provide GPS tracks of where he has been. He needs a prospecting guide to find previously identified entrances and be able to find photos of caves in past years. Writes up his explorations in execrable handwriting in the logbook. Looks at walls.
<li>The diligent student who types up the survey notes into survex file format, transcribes sketch notes onto survex centre-lines, and uses Therion to produce beautiful survey graphics of the caves he has digitised - but who is not a computer geek and whose brain oozes out of his ears when Wookey explains what git is. Applies artistic graffiti to walls.
<li>The archivist who takes the survex files, the therion files, the GPS files, the scanned survex centrelines and files them in the right places on the <em> expo laptop</em>, uses the troggle reports to help ensure that these are consistent and are filed correctly. Uses troggle input forms to "create new cave" in the system and adds to the directory structures to match the recently discovered caves. Is learning git. When transcribing bad handwriting in logbook (or struggling with git), climbs walls.
<li><em>Nerdus maximus</em>: talks python in his sleep and can rebase a hairy git branch without error after 7 bottles of Gosser. Painfully averse to writing documentation. Overstressed, over-caffeinated and with a tendency to mutter that it's all obvious. Oblivious to walls.
</ul>
<p>These are some of the "use cases" for which troggle needs to be (re)designed to cope with.
<h3>Rewrite from here on...</h3>
<p>This troggle manual describes these:
<ul>
<li>Annual tasks: preparing for next year, finishing last year (troggle & scripts)
@@ -65,302 +76,14 @@ can do this by filling-in some online forms.
All Survex | Scans | Tunneldata | 107 | 161 | 204 | 258 | 264 | Expo2016 | Expo2017 | Expo2018 | Django admin
</pre>
<h3>Future Developments: Preamble</h3>
<p><em>Assumptions</em> (points to necessarily agree upon)
<ol>
<li>Let's NOT try to design a generic catalogue for storing all kind of data about caves of the whole world, intended for every kind of user (sports, exploration, science). Let's just settle for a generic framework. Let geeks in individual countries or individual communities write their tools operating within this framework.
<li>Let's try make it available for the layman, but still well-playable for the geeks.
<li>Let's rely on already existing, popular technologies. Let's keep it open source and multiplatform. Let's try not to reinvent the wheel.
<li>Let's not assume everyone has an Internet connection while working with their data.
<li>Let's version-control as much as possible.
<li>Let's support i18n - let's use UTF-8 everywhere and cater for data in many languages(entrance names, cave descriptions, location descriptions etc.)
</ol>
<tt><em>Everything here should be updated or replaced - this page just records a lot of unfinished ideas.
Most people will not want to read this at all. This is for speleosoftwarearcheologists only.</em>
</tt>
<p>Two page preliminary design document for <a href="../../documents/caca_arch2.pdf">'caca' (Cave Catalogue) rev.2 2013-07-26</a> by Wookey (copied from http://wookware.org/software/cavearchive/caca_arch2.pdf)
<h2>The data management system conventions bit</h2>
<p>This is likely to change with structural change to the site, with style changes which we expect to implement and with the method by which the info is actually stored and served up.</p>
<p>... and it's not written yet, either :-)</p>
<ul>
<li>Structure</li>
<li>Info for each cave &ndash; automatically generated by <tt>make-indxal4.pl</tt></li>
<li>Contents lists &amp; relative links for multi-article publications like journals. Complicated by expo articles being in a separate hierarchy from journals.</li>
<li>Translations</li>
<li>Other people's work - the noinfo hierarchy.</li>
<li>Style guide for writing cave descriptions: correct use of boldface (<em>once</em> for each passage name, at the primary definition thereof; other uses of the name should be links to this, and certainly should not be bold.) </li>
</ul>
<h3>CUCC wiki on troggle</h3>
<p>CUCC still has an archive list of things that at one time were live tasks:
from <a href="https://camcaving.uk/Documents/Expo/Legacy/Misc/Troggle%20-%20Cambridge%20University%20Caving%20Club.htm">camcaving.uk/Documents/Expo/Legacy/Misc/...</a> and that page is reproduced in the table below (so don't worry if the URL link goes dark when CUCC reorganise their legacy pages).
<p>Troggle is a system under development for keeping track of all expo data in a logical and accessible way, and displaying it on the web. At the moment, it is [no longer] under development at <u>http://troggle.cavingexpedition.com/</u>
<tt>But note that this is Aaron's version of troggle, forked from the version of troggle we use. Aaron uses this for the <a href="https://expeditionwriter.com/new-expedition-to-mount-erebus-antarctica/">Erebus expedition</a>.</tt>
</p>
<p>Note that the information there is incomplete and editing is not yet enabled.
</p>
<table border="1" cellspacing="0">
<tr>
<th><p>Feature</p></th>
<th><p>Old expo website</p></th>
<th><p>Troggle: planned</p></th>
<th><p>Troggle: progress so far</p></th>
</tr>
<tr>
<td><p>Logbook</p></td>
<td><p>Yes; manually formatted each year</p></td>
<td><p>Yes; wiki-style</p></td>
<td><p>Start at the front page, <a rel="nofollow" class="external autonumber" href="http://expo.survex.com/expedition/2007">troggle.cavingexpedition.com/ [1]</a> and click to logbook for year. The logbooks have been parsed back to 1997. </p></td>
</tr>
<tr>
<td><p>Cave index and stats generated from survex file</p></td>
<td><p>Yes</p></td>
<td><p>Yes</p></td>
<td><p>Done; see <a rel="nofollow" class="external autonumber" href="http://expo.survex.com/survexfile/caves/264">troggle.cavingexpedition.com/survey/caves/264 [2]</a> </p></td>
</tr>
<tr>
<td><p>Survey workflow helper</p></td>
<td><p>Yes; minimal. surveys.csv produced an html table of whose surveys were not marked “finished”</p></td>
<td><p>Yes. Makes table of surveys per expo which shows exactly what needs doing. Displays scans. Integrated with survex, scanner software, and tunnel.</p></td>
<td><p>See it at <a rel="nofollow" class="external free" href="http://expo.survex.com/survey_scans/">troggle.cavingexpedition.com/survey</a> . Be sure to try a recent year when we should have data. Survex, scanner, and tunnel integration still needs doing.</p></td>
</tr>
<tr>
<td><p>QM lists generated automatically</p></td>
<td><p>Depends on the cave. Each cave had a different system.</p></td>
<td><p>Yes; unified system.</p></td>
<td><p>Done, but only 204 and 234 Qms have been imported from old system so far. No view yet.</p></td>
</tr>
<tr>
<td><p>Automatic calendar for each year of who will be on expo when</p></td>
<td><p>No, manually produced some years</p></td>
<td><p>Yes</p></td>
<td><p>Done; see <a rel="nofollow" class="external free" href="http://expo.survex.com/expedition/2007">troggle.cavingexpedition.com/calendar/2007</a> (replace 2007 with year in question)</p></td>
</tr>
<tr>
<td><p>Web browser used to enter data</p></td>
<td><p>No</p></td>
<td><p>Yes</p></td>
<td><p>Everything can be edited through admin, at <a rel="nofollow" class="external free" href="http://expo.survex.com/admin/">troggle.cavingexpedition.com/admin</a> . Ask aaron, martin, or julian for the password if you want to have a look / play around with the admin site. Any changes you make will be overwritten. Eventually, data entry will probably be done using custom forms.
</p></td>
</tr>
<tr>
<td><p>Cave and passage descriptions</p></td>
<td><p>Yes, manually html coded.</p></td>
<td><p>Yes, wiki-style.</p></td>
<td><p>Not done yet.<br />
</p></td>
</tr>
<tr>
<td><p>Expo handbook</p></td>
<td><p>Yes, manually html coded.<br />
</p>Maybe. Needs to be discussed further.</td>
<td><p><br />
</p></td>
<td><p>Not done yet.</p></td>
</tr>
<tr>
<td><p>Table of who was on which expo</p></td>
<td><p>Yes</p></td>
<td><p>Yes</p></td>
<td><p>Data has been parsed, this view hasn't been written yet. </p></td>
</tr>
<tr>
<td><p>Signup form, System for keeping contact, medical and next of kin info</p></td>
<td><p>No</p></td>
<td><p>Yes</p></td>
<td><p>Signup form should be ready by 20 Jan.</p></td>
</tr>
<tr>
<td><p>Automated photo upload and gallery</p></td>
<td><p>No; some manual photo galleries put together with lots of effort</p></td>
<td><p>Yes</p></td>
<td><p>Photo upload done, gallery needs writing.</p></td>
</tr>
<tr>
<td><p>Search</p></td>
<td><p>No</p></td>
<td><p>Yes</p></td>
<td><p></p></td>
</tr>
</table>
<h3>List of cave database software</h3>
from <a href="http://wookware.org/software/cavearchive/databasesoftwarelist">wookware.org/software/cavearchive/databasesoftwarelist</a>
<pre>
ckan is something like this - could we use it?
esri online
CUCC (troggle) http://cucc.survex.com/ - this site.
virgina caves database (access+arcgis) (futrell)
each country database
Austria (spelix) ( <a href="https://www.spelix.at/">www.spelix.at/</a>
UK cave registry
mendip cave registry: (access) <a href="http://www.mcra.org.uk/wiki/doku.php">www.mcra.org.uk/wiki/doku.php</a>
White mountains database (gpx + google earth)
Matienzo (?)
Fisher ridge (stephen cladiux)
hong meigui (erin) <a href="http://www.hongmeigui.net/"http://www.hongmeigui.net/</a> (ask erin later)
Wikicaves <a href="http://www.grottocenter.org/">www.grottocenter.org/</a>
multilingual, slippymap, wiki data entry. includes coordinate-free caves.
focus on sport-caving type info (access, basic gear list, overall description, bibliography)
e.g. australians only publish coordinates to nearest 10km
turkey <a href="http://www.tayproject.org">www.tayproject.org</a>.
<a href="http://www.uisic.uis-speleo.org/contacts.html">www.uisic.uis-speleo.org/contacts.html</a> change link. no-one looks for list of databases under 'contacts'
graziano ferrari northern italy list (access + google earth)
</pre>
<h3>Wookey's notes on things to do</h3>
from <a href="http://wookware.org/software/cavearchive/goliczmail">wookware.org/software/cavearchive/goliczmail</a>
<pre>
Generally I'd like to find some people (geeks) that share these technical
ideas: (1) store things in a file system, (2) use XML, (3) do not aim too high
(do not try designing a general system for handling all caving-related data
for the whole world).
If I could find some people that agree with this, then we could try to reach a
compromise on:
(1) how do we store our data in a file system,
(2) how do we use this XML (let's do a common spec, but keep it simple)
(3) how do we aim not too high and not end up dead like CaveXML :)
After we do that, everyone goes away to do their own projects and write their
own code. Or maybe we have some degree of co-operation in actually writing the
code. Normal life. But the idea is that all geeks working on "cave inventory"
and systems making extensive use of cave inventories try to adhere to this
framework as much as possible. So that we can then exchange our tools.
I think things like "which revision system do we use" or "do we use web or
Python" are really secondary. Everyone has their own views, habits,
backgrounds.
My idea is to work on this in a small group (no more than a few persons) - to
get things going fast, even if they are not perfect from the beginning. If it
works, we try to convince others to use it and maybe push it through UIS.
</pre>
<h3>Wookey's other notes on things to do</h3>
from <a href="http://wookware.org/software/cavearchive/troggle2design">wookware.org/software/cavearchive/troggle2design</a>
<pre>
forms
-----
1) members read/write folk.csv and year/members
2) cave read/write cave_data, entrance_data, surveys/pics
3) trips -> logbook , QMs, or surveys (more than one survey or location possible)
4) logbook reads/write year/logbook
5) survey
6) prospecting app
forms show who is logged in.
databases
---------
trips, read from
logbook entry
folder year#index
.svx files
description
QMs
members (cache from form)
caves
caves_data
entrance_data
storage:
expoweb
data/
cave_entrances
caves
descriptions
loser
foo.svx
</pre>
<h3>Yet more of Wookey's notes</h3>
from <a href="http://wookware.org/software/cavearchive/expoweb-design">wookware.org/software/cavearchive/expoweb-design</a>
<pre>
frontpage
---------
quick to load:
Links:
Caves number, name, location
Years
Handbook
Data Entry
Main Index
Slippy map:
Indexes to cave page
Cave page:
Access, description, photos, QMs, Survey
Years:
Logbooks/surveynotes/survexdata/people matrix
Documents
Data Entry:
Logbook entry
Survey data
Survey Notes
Cave description
QMs
Photos
New cave
Backend datafiles:
caves/
cave_entrance
cave_data
directory of info
years/
year/
logbook
pubs/
reports
admin/
lists
who_and_when
travel
jobs
surveyscans/
year/
index
#num
handbook/
(all static info)
Storage:
non-html or > 280K go in 'files' (PDF, PNG, JPEG, DOC, ODF, SVG)
convert small 1024x768 version into website by default. (matching structure?
</pre>
<hr />
</div>
<h3><a id="arch">Archived updates</a></h3>
<p>Since 2008 we have been keeping detailed records of all data management system updates in the version control system.
Before then we manually maintained <a href="../computing/update.html">a list of updates</a> which are now only of historical interest.
<p>A history of the expo website and software was published in Cambridge Underground 1996. A copy of this article <a href="c21bs.html">Taking Expo Bullshit into the 21st Century</a> is archived here.
<p>A history of the expo website and software was published in Cambridge Underground 1996. A copy of this article <a href="../c21bs.html">Taking Expo Bullshit into the 21st Century</a> is archived here.
<hr />
Go on to: <a href="trogarch.html">Troggle architecture</a><br />
Dubiously explore: <a href="archnotes.html">Historic ideas for cave data management</a><br />
Return to: <a href="trogdesign.html">Troggle design notes</a><br />
<hr />
</body>