expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-11-25 08:41:54 +00:00
Code Issues Packages Projects Releases Wiki Activity

altitude, link to rtk - online edit of handbook/survey/ententry.html

Browse Source
This commit is contained in:
Expo on server 2024-06-30 16:43:40 +01:00
parent a5011d7c65
commit 65a1a5d00e
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
handbook/survey/ententry.html
View File

@ -88,9 +88,9 @@ This page outlines step 7 of the survey production process. Each step is documen
*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 <a href="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, and even the new Galileo system won't promise anything better than &plusmn; 0.4m in 2030. (If you take the altitude from a track while moving the altitude can easily be 15m wrong.)
<p>The altitude is not nearly as vital as the lat/long numbers. GPS altitudes are still pretty bad, we are waiting for cheaper <a href="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, and it is still not good.
<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 (<a href="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 <a href="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.]
<h2>List of New Entrance/Entrance_data fields</h2>