expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-01-18 08:52:37 +00:00
Code Issues Packages Projects Releases Wiki Activity

QM docm update

Browse Source
This commit is contained in:
Philip Sargent 2022-07-05 22:49:16 +03:00
parent b80f6d2e64
commit 3f9bf27a04
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
handbook/troggle/scriptsqms.html
View File

@ -33,7 +33,7 @@ tl;dr - use <em>svx2qm.py</em>. Look at the output at:<br>
<p>You will be familiar with <a href="../survey/qmentry.html">documenting newly found QMs</a> in the survex file when you type it in. But
QMs are only useful if they can be easily scanned by people planning the next pushing trip. That's what we are discussing here.
<p>There are four (roughly) ways we have used to manage QMs:
<p>There are half a dozen ways we have used to manage QMs:
<ol>
<li><strong>Hand-edited lists of QMS</strong> - only exist for 1623-161 <a href="/1623/161/qmtodo.htm">Kaninchenh&ouml;hle</a>
<li><strong>Perl script</strong> - Historically QMs were not in the survex file but typed up in a separate list <var>qms.csv</var> for
@ -49,18 +49,18 @@ chase QMs. It was a troggle-generated document at <a href="/prospecting_guide/">
It has been retired because the mapping software packages it used were terminally outdated.
</ol>
<p>The plan is to write new parsers to extract the QM information from the survex files and to
integrate these QMs into the same reports as those parsed from the CSV files.
<p>QMs all use <a href="../survey/qm.html">the same QM description conventions</a>.
<h4 id="qms.py">troggle/parsers/qms.py</a></h4>
<p>Troggle currently reports QMs for only three historic caves and also imports all the QMs inside survex files.
Thus a recent cave such as 1623-264 (Balkh&ouml;hle)will only show QMs imported from the survex files:
Thus a recent cave such as 1623-264 (Balkh&ouml;hle) will only show QMs imported from the survex files:
<ul>
<li>/cave/qms/&lt;caveslug&gt; e.g. <a href="/cave/qms/1623-264/">/cave/qms/1623-264/</a> works (slow page)
<li>/cave/&lt;caveslug&gt;-&lt;year&gt;&lt;qm_id&gt; e.g. <a href="/cave/qms/1623-264/2019-2B">/cave/qms/1623-264/2019-2B</a> broken (multiple hits)
<li>/cave/&lt;caveslug&gt;-&lt;year&gt;&lt;qm_id&gt; e.g. <a href="/cave/qms/1623-264/2019-lipstickdipstick2B">/cave/qms/1623-264/2019-lipstickdipstick2B</a> broken, no data shown
</ul>
<p>The bug in the individual QMs is probably in the importing process.
<p>There is an open issue in that although we use the name of the 'block' in the survex file to disambiguate QMs in the same cave and from
the same year, it is still possible for blocks to be named non-uniquely. This would crash the system as two QMs would have the same URL.
<p>The parser <em>troggle/parsers/qms.py</em> currently imports the <var>qm.csv</var> files used by
the 2004 perl script tablize-qms.pl (see below) into troggle using a mixture of csv and html parsers:
<code><pre>parseCaveQMs(cave='stein',inputFile=r"1623/204/qm.csv")