<p>New in 2021 are fields for the latitude and logitude (WGS84 - the same as your GPS displays). <b>Unless</b> someone has already created the *fix point for the cave, these should be entered in the form. IF the *fix <em>has</em> been done, then <em>leave the WGS84 fields blank</em>.
<p>We always write degrees with decimals for fractions of a degree, e.g. 42.357 (not 42 degrees 21 minutes 25 seconds, or 42 degrees 21.42 minutes).
<p>These WGS84 fields exist for newly-discovered cave entrances for which we currently have no location information except for a GPS reading by the original discoverer. These discoveries have a habit of getting completely lost: so enter it so that someone can find it again to properly survey it. In due course the cave will be linked in to the survex survey system using *fix statements. If this *fix work has been done, then that is authoritative and <em> you do not need</em> to enter location information on this form.
<h3id="fix">More details about *fix statements</h3>
<p>When a nerd creates a *fix statement, in the right place, the nerd will manually delete the WGS84 values on the Entrance.
<p>
The survex location uses a *fix statement and it looks like this:
<p>If you are doing this for the first time, it might be a good idea to put it in the same survex file temporarily. A nerd will move it to the right place later.
<divstyle="margin-left: 3em; margin-right: 4em"><em>The 'right place' is in the <var>fixedpts</var> part of the <var>:loser:</var> repository, but is very different depending on whether the cave is in the 1623 or the 1626 area - for historic reasons
</em>
<p>For the 1623 area it is easy. Each year has a different file. For 2019 there is a file <var>gps/gps19.svx</var> which contians all the *fix statements for new locations that year.
<p>For the 1626 area it has got horribly complicated and you should talk to Wookey and Becka. Most likely it will have to go into <var>fixedpts/1626-no-schoenberg-hs-not-tied-to-caves.svx</var></div>
<p>And in your main survex file you will need to make the connection between the survey points in the cave and the external location. This would be something like this (not real data), where survey station "1" is the tag at the entrance of the cave, and outside the begin/end section it is called "2023-js-02.1"
<code>
*equate p2023-js-02 2023-js-02.1<br/>
<br/>
*begin 2023-js-01<br/>
*export 1<br/>
...<br/>
*data normal from to length bearing gradient ignoreall<br/>
1 2 4.46 099.3 -54<br/>
...<br/>
*end 2023-js-01<br/>
</code>
<p>There is a lot more to say about how to record the best GPS data, and how to link GPS with survey points, e.g. see <ahref="gps.htm">Getting a GPS fix</a>
<p>The altitude is not nearly as vital as the lat/long numbers. GPS altitudes are still pretty bad, we are waiting for cheaper <ahref="https://en.wikipedia.org/wiki/Real-time_kinematic_positioning">RTK</a> systems for survey-quality altitudes. (If you take the altitude from a track while moving the altitude can easily be 15m wrong.)
<p>In practice, for us on the plateau, we get repeat measurements of the same spot by different teams in different years to be accurate to only about 3m. This is fine for finding entrances, and for checking whether two different teams have found the same cave, but it is not adequate for loop-closure. That requires particular care with averaging the reading over 2 minutes, and use of a location with good view of the sky, away from vertical rock, and surface survey using instruments to get from the GPS point to the actual cave entrances. To get a decent <em>altitude</em> measurement requires averaging over 10 minutes, on 2 or 3 separate days, and it is still not good enough - much better to use lat/lon and a topographic laser map (<ahref="https://en.wikipedia.org/wiki/Real-time_kinematic_positioning">RTK</a> will change this).
<p>In previous decades the location of an entrance was the <em>output</em> of a whole lot of surveying and position fixing (e.g. see <ahref="lasers.htm">laser points</a>). Today, an initial location of an entrance is available by GPS at the <em>beginning</em> of the process. So we have these fields to record the data. [We don't yet have the code to automatically add the *fix statements into the <var>fixedpts</var> data, or to the <var>essentials.gpx</var> download to be used for prospecting though.]