expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-13 17:37:07 +00:00
Code Issues Packages Projects Releases Wiki Activity

documenting multitudinous little scripts

Browse Source
This commit is contained in:
Philip Sargent
2020-04-26 00:48:38 +01:00
parent a233c4880b
commit 04976f6ed8
7 changed files with 231 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files

91
handbook/troggle/scriptscurrent.html
View File

@@ -40,49 +40,48 @@ p {
<p><a href="">updatephotos</a> (in the :loser: repo) uses the BINS package to generate photo albums. BINS uses the EXIF data (date, location if available) in the uploaded image files to produce a page showing the information available about the picture. All image meta-data are stored in XML files.
<p>BINS is no longer maintained by its author so expo has taken on the responsibility for keeping it running. (Wookey is in the process of packaging it as a proper debian package).
<h4 id="svx2qm">svx2qm.py</a> and QMs</h4>
<p>Philip Withnall's QM extractor (in :loser:/qms/). It generates a list of all the QMs in all the svx files in either text or CSV format. This will produce a text output of all the QMs:
<pre><code>cd loser
find -name '*.svx' | xargs ./svx2qm.py --format csv
</code></pre>
<h4 id="tabqmsqms">tablize-qms.pl</h4>
<p>Takes a CSV file name as the program's argument (e.g. qm.csv as generated by svx2qm.py) and generates an HTML page listing all the QMs.
<p>In :expoweb:/1623/204/ and several other subdirectories of /1623/
<h4 id="find-dead-qms">find-dead-qms.py</h4>
<p>This finds references to completed qms in the cave descriptions.
<p>Also
<a href="#qmreader">qmreader.pl</a> which reads and parses qm.html (why?)
<p>In :expoweb:/1623/204/ - Nial Peters (2011)
<h4>svx2qm.py, tablize-qms.pl, find-dead-qms.py,qmreader.pl</h4>
See the entire page devoted to the various
<a href="scriptsqms.html">QM scripts</a>.
<h4 id="svxtrace">svxtrace.py</h4>
<p>Traces all the svx file dependencies via the *include statements. In :expoweb:/ .
<p>Traces all the svx file dependencies via the *include statements. In :expoweb:/ . The documented workflow today does not appear to need this, but that might be a documentation fault. It might do a key job. <span style="color:red">[to be investigated]</span>
<h4 id="survex">Survex files</a> - reference checking</h4>
<p>Survex files contain a reference to the wallet which contains the original survey notes for that surveyed passage. These sometimes have errors and also get out of date as caves get renamed when they get a kataster number issued. Each online survey wallet also has a reference to the survex file(s) which have been typed up from that data.
<p>Validating the references is checked by scripts check-svx.sh, check-refs.sh, check-refs.awk in the :loser: repository to produce <a href="../../svxvalid.html">svxvalid.html</a> which lists mismatches between the svx files and the survey scan wallets.
<p>This is a horrible proof-of-concept hack that needs replacing with a proper python script instead of an assemblage of awk, bash and sed.
<h4 id="draw">Drawings files</a> - reference checking</h4>
<p>Tunnel files contain references to the wallet which contained the original survey notes for that surveyed and drawn passage.
<p>The results of validation checks are in <a href="../../xmlvalid.html">xmlvalid.html</a> and generated by script check-xml.sh in the :drawings: repository.
<p>(Therion files would too, if people inserted "#Ref" comments. In which case the script would need improving.)
<p>Currently the intermediate data it works from has to be hand-generated so a <span style="color:red">proper parsing script needs to be written</span>.
<h4 id="tabular">caves-tabular.html</h4>
<p> This webpage <a href="../../caves-tabular.html">caves-tabular.html</a> uses a page-specifc JavaScript file TableSort.js which allows the user to resort the table of all the cave data by any of the columns by clicking on it [by Radost]. The exact source (i.e. the report or script) of the data in the table is unknown.
<h4 id="gps">make_essentials.sh GPS</h4>
<p>In :expoweb:/noinfo/
<p>Makes essentials.gpx - see <a href="../essentials.html">GPS on expo</a>.
<h4 id="dplong">create_dplong_table.py</h4>
<p>In :expoweb:/noinfo/
<h4 id="dplong">create_dplong_table.py, <span id="cavestats">cavestats</span>
and smklengths</h4>
<p>"cavestats" is compiled by noinfo/cavestats.build source code and is used by
"create_dplong_table.py".
<p><em>:loser:/docs/smklengths</em> is a brief bash script that runs cavern on all the top-level cave svx files and extracts the total lengths.
<h4 id="surface">make_svx.sh</h4>
<p><span style="color:red">[to be documented]</span>
<h4 id="area">make-areaindices.py</h4>
<p>In :expoweb:/noinfo/
<p>In :expoweb:/noinfo/ - a key part (?) of generating the prospecting guides ? See below.
<p><span style="color:red">[to be documented]</span>
<h4 id="prosp">make-prospectingguide-new.py</h4>
<p>In :expoweb:/noinfo/prospecting_guide_scripts/
<p><span style="color:red">[to be documented]</span>
<p><span style="color:red">[to be documented] - We need a whole webpage on how to construct the various prospecting guides.</span>
<h4 id="latex">seshbook, bierbook & protractors</h4>
<p>How these are used once produced is <a href="../bierbook.html">documented in the the handbook</a>
<p>These are LaTeX files and the instructions for how to process them are in each .tex file. The protractors do not change but the others need a configuration file for all the cavers expected to attend expo.
@@ -94,15 +93,14 @@ Due to the way LaTeX works out table column witdths, these commands may need to
The design of these files is intended to confine all changes year to year to the names.txt and dates.txt files, thanks to LaTeX's capability to read an external file and iterate through line by line performing the same action for each name.
<h4 id="surface">make_svx.sh</h4>
<p><span style="color:red">[to be documented]</span>
<h4 id="cavestats">cavestats</h4>
<p><span style="color:red">[to be documented]</span>
<h4 id="summ">summarizecave.sh</h4>
<p>This runs "cavern" (a commandline tool installed as part of survex) to produce a text (or HTML) report of the key statistics from the master svx file for a cave (the one that includes all the svx files for the individual passages).
<h4 id="gps">make_essentials.sh GPS</h4>
<p>In :expoweb:/noinfo/
<p>Makes essentials.gpx - see <a href="../essentials.html">GPS on expo</a>.
<h3 id="inscripts">Old and possibly obsolete scripts</a></h3>
<h4 id="alljs">make-alljs.py</h4>
<p>Writes out legs and entrances in json format. In :loser:/fixedpts/
<h4 id="glossary">make-glossary.pl</h4>
<p>In :expoweb:/1623/204/ and /1623/161/. It reads a cave-specific glossary.csv and produces the HTML files for caves 161 and 204:
@@ -110,25 +108,34 @@ The design of these files is intended to confine all changes year to year to the
<li><a href="/1623/204/atoz.html">/1623/204/atoz.html</a>
<li><a href="/1623/161/a-z.htm">/1623/161/a-z.htm</a>
</ul>
<p>which are indexes to passage names and locations in the very extensive vcave descriptions for Kaninchenhohle and Steinbruckenhohle.
<p>which are indexes to passage names and locations in the very extensive cave descriptions for Kaninchenhohle and Steinbruckenhohle. We may need this again for Tunnocks/Balkonhohle.
<h4 id="alljs">make-alljs.py</h4>
<p>Writes out legs and entrances in json format. In :loser:/fixedpts/ (along with <em>make-fb-map.pl</em>which does Austrian coordinate transformations).
Also in the :loser:fixedpts/scripts/convert_shx/ folder is a 135-line short script convert_shx.ml written in
<a href="https://en.wikipedia.org/wiki/OCaml">OCaml</a> which constructs input to the
<a href="https://gdal.org/programs/ogr2ogr.html">ogr2ogr</a> GIS feature file format conversion utility.
<p>The documented workflow today does not appear to need this, but that might be a documentation fault. It might do a key job. <span style="color:red">[to be investigated]</span>
<h4 id="indxl4">make-indxal4.pl</h4>
<p>Obsolete.
<p>See history documents which refer to CAVESTATS.CSV
<p><span style="color:red">[to be documented - for historic interest only]</span>
<h4 id="logbk">logbk.pl</h4>
<p>Obsolete.
<p>This function is now done by the troggle input parsers.
<p><span style="color:red">[to be documented - for historic interest only]</span>
<h3 id="inscripts">Old and possibly obsolete scripts</a></h3>
<h4 id="loser1624">Loser-1624 scripts</h4>
<p>
In /scripts/noinfo/scripts/loser-caves1624-raw-data/ there is convert.py and split.sh which operate on
Uebersicht_2011.svx doing coinversions on a dataset generated from dataset generated from CaveRenderer.
Uebersicht_2011.svx doing conversions on a dataset generated from dataset generated from CaveRenderer. The documented workflow today does not appear to need this, but that might be a documentation fault. It might do a key job. <span style="color:red">[to be investigated]</span>
</p>
<h4 id="logbk">logbk.pl</h4>
<p>Obsolete.
<p>This function is now done by the troggle input parsers.
<p>[for historic interest only]
<h4 id="indxl4">make-indxal4.pl</h4>
<p>Obsolete.
<p>See the history document which refers to CAVETAB2.CSV and make-indxal4.pl during the
"script and spreadsheet" phase of the system development from the mid 1990s to the mid 2000s:
<a href="../website-history.html">website history</a>
<hr />
Return to: <a href="otherscripts.html">Other scripts</a><br />