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

handbook coordinate systems

Browse Source
This commit is contained in:
Philip Sargent 2023-11-05 21:58:22 +02:00
parent 4e1d6a37e9
commit aada307172
2 changed files with 39 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
handbook/survey/coord.htm
View File

@ -6,7 +6,6 @@
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head>
<body>
<h2 id="tophead">CUCC Expo Surveying Handbook</h2>
<h1>Coordinate Systems</h1>
<p>
@ -195,7 +194,8 @@ GPS.
<p>
I personally get along very well with Proj4, which is open source and free and
all that. It should also be packaged with all major Linux distributions and
all that. [We use survex for all our cordinate conversions these days - which uses proj4 internally - 2023].
<p>Proj4 should also be packaged with all major Linux distributions and
installed on the expo computer. Unfortunately the current versions do not deal
very well with vertical datums (i.e. geoids), but we can ignore the geoids
anyway. To invoke it, you have to type in something like
@ -260,8 +260,9 @@ about a metre or so.
<p>
[These are Olaf's view in 2012. This is no longer what we use! Today we use WGS84
latitude and logitude just as it appears on your phone or GPS. (Note added May 2021)]</p>
For all practical purposes I'd say, set your GPS receiver to UTM coordinates,
WGS84 ellipsoid, WGS84 datum. It will
For all practical purposes [in 2012] I'd say, set your GPS receiver to UTM coordinates,
WGS84 ellipsoid, WGS84 datum. [No: today in the 2020s set your phone to lat/long WGS84, digital degreees.] <p>It will
usually spit out rather unspecific "heights above sea level", which are within
about 25cm of the heights in our data set. To convert the horizontal
coordinates from UTM zone 33 to our data set coordinates, use:
@ -289,8 +290,6 @@ latitude-longitude, UTM and data set coordinates:
<p><i>Olaf K&auml;hler, September 2012</i></p>
<hr />
<p>Return to <a href="coord2.html">GPS and coordinate systems</a>.
</body>
<p>Return to <a href="coord2.html">GPS and coordinate systems</a>.</body>
</html>

37
handbook/survey/coord2.html
View File

@ -15,17 +15,46 @@
<h3 id="summary">Summary - for 2023</h3>
<p>Surveying in Austria does <em>not</em> just use the latitude and longitude you may be familiar with from Google maps, your phone etc.
<p>All our caves and locations in our survex files use the <a href="https://hoehle.org/downloads/SD_10_Handbuch.pdf">Austrian Caving national grid system</a>, numbers which look like this:
<p>All our caves and locations in our survex files process data in the UTM33N coordinate system, numbers which look like this:
<table class="trad">
<tr><th> Northing</th><th> Easting</th><th> Altitude</th><th>
Description</th></tr>
<tr><td>411563.49 </td><td>5282622.35</td><td> 1867.95m </td><td>
p204a at the Stone Bridge</td></tr>
</table>
<p>These grid references are what we use to locate the entrances and to tie in the survey of a new cave in with the rest of the 180+ km of cave and surface surveys.
<p>Note that there are 6 digits starting 41... and 7 digits starting 52... This is not a mistake.
<p>These might be called "dataset coordinates" in expo-speak, but note that some people historically used this to mean the coordinate system in common use on an expo many years ago, which would not be the same.
<p><em>Note that there are 6 digits starting 41... and 7 digits starting 52... This is not a mistake.</em>
<p>However, when you prospecting and discover a new cave, you possibly only have the WGS84 latitude and logitude from your phone, e.g. <var>47.690933 N 13.821467 E</var> (degrees and decimals of degrees, set your phone to produce this: none of that degrees/minutes/seconds stuff, but if that's all that you have, we can work with that).
<p>So when you are recording the position of a completely new entrance, before you do any surveying, it will be the WGS84 lat/long that you will be writing down on the survey notes, and which will get scanned into the wallet back at base, and which you will enter into the <a href="/handbook/survey/caveentry.html">New Cave and Entrance forms</a> on troggle (step 6 of the dave data processing guide) in the lat/long. data entry fields.
<h3>"Dataset" coordinates</h3>
<p>We do all our serious geolocation within survex, using .svx survex files and using the conversion capabilities built into survex.
<p>While cave entrance locations are <em>input</em> using a bewildering variety of different coordinate systems, the processing and output is now all standardised on using UTM33, i.e.
<code>
*cs out UTM33N
</code> as survex puts it.
<h4>Historical use of GK</h4>
<p>Actually, the vast majority of our historic data input has been using the GK coordinate system because that is what the Austrian cavers use (though some people thought it was BMN, so beware of mistakes in the writeups and documentation).
<p>The Austrian <em>Caving</em> national grid system <a href="https://hoehle.org/downloads/SD_10_Handbuch.pdf">SD_10_Handbuch</a> uses the Gauss-Kr&uuml;ger-Koordinatensystem(GK) (page 39 of the SD_10_Handbuch). This is 5 digits x, 5 digits y, and usually with a couple of digits after the decimal point for each.
<p>So if you are looking at the <var>*fix</var> data in files in the <var>:loser:</var> repository, you will see this:
<pre><code>*cs out UTM33N
*cs custom "+proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=0 +y_0=-5200000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232"
*fix p2000-bl-12 34554.2 86249.7 1898
</code></pre>
<p>Where the input coordinate system is specified using what is called a "proj4" string which defines a custom coordinate system, and that is the srong which defines GK.
<h4>Historical use of BMN (M31)</h4>
<p>In 2013 there were about 30 potential cave entrances located using a GPS device set to record data in the BMN (area M31) coordinate system.
<p>This looks very similar to GK but has different offsets in +x_0 and +y_0 :
<pre><code>*cs out UTM33N
*cs custom "+proj=tmerc +lat_0=0 +lon_0=13d20 +k=1 +x_0=+450000 +y_0=-5000000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232"
*fix p2013-bl-01 486492 284508 1859
</code></pre>
<p>A quick check is that both the x and y coordinate have 6 digits before the decimal point.
<p>This is described very clearly in <a href="https://de.wikipedia.org/wiki/%C3%96sterreichisches_Bundesmeldenetz">wikipedia.de: &Ouml;sterreichische Bundesmeldenetz (BMN)</a>.
<h3>Coordinate systems</h3>
<p>[The text from this point onwards is from before we had mobile phones, but it is correct.]
@ -90,7 +119,7 @@ recognisably different formats, UTM 33 coordinates look like dataset
coordinates but are offset by a couple of kilometres. Having your GPS set to
the wrong datum produces even more subtle errors - the difference between BMN
grid + WGS84 datum and BMN grid + Austrian datum is an offset of around 500m to
the south and 50m in altitude.)</p>
the south and 47m in altitude.)</p>
<p>A good way of testing that your GPS is correctly set up is to set it WGS84
Lat/Long and enter a waypoint for a point whose coordinates are known &ndash;
@ -99,7 +128,7 @@ change the settings again to use the user grid. It will now convert this point
into the new grid; if you check its coordinates, it should come out as
something close to 486697E, 5283699N, which are the BMN coordinates for 204a.
For use in the dataset we tend to subtract the 450km offset in the easting and
ignore the first two digits of the northing, giving 36697E 83699N.</p>
ignore the first two digits of the northing, giving 36697E 83699N [which means this is actually GK ].</p>
<p>Write down the figure that the GPS gives for each waypoint <i>at the
time</i> (just in case some failure loses the data from the GPS memory &ndash;