[Expo-tech] glitch in p2018-ad-01 - is it 1623 or 1626 ?

[Wookey]

On 2020-06-30 13:16 +0100, Philip Sargent (Gmail) wrote:
>    cavern says:
> 
>    …/loser/kataster/1623.svx:7: warning: Station “1623.p2018-ad-01” referred
>    to by *entrance or *export but never used
> 
>     
> 
>    I according to /caves/ it is in 1623:
> 
>    http://expo.survex.com/1623/2018-ad-01
> 
>    and from the GPS in essentials.gpx it is probably in 1623, but overlooking
>    the Wildensee hutte so might be in 1626.

It's 572m inside 1623 according to the dataset I just looked at. Not
even close to being debateable. The border is in the dataset so it's
very easy to tell which side of the line things are. Look in aven.

>    And how do we resolve this without breaking lots of things ?

Resolve the cavern warning?

Well there is no underground data for 2018-ad-01 so there is an no
underground data connected to it. And there are two surface GPS tracks
going there, but the entrance has been positioned in the middle of the
'GPS wander' rather than at any specific point (which seems reasonably
correct) so it's not connected to any actual dataset. Hence the
warning. So nothing is 'wrong' here.

It presumably doesn't also have a REFERENCE modifier which I think
would supress the warning. This relates to the general treatment of
entrance locations, which should correctly be derived from a number of
inputs (surface surveys, bearings, multiple GPS readings, images, and
DEMs and for altitude). Survex could do this (apart from the
image-location - that needs to be extracted in another process), but
currently has rather too simple a data model, resulting in warnings
like this where someone has clearly done the averaging job
manually/externally. We are working on a better process as part of the
'how do we interface with GIS' discussions.

>    But so far as I can see, the GPS position is *only* in essentials.gpx and
>    not in any of the cave or entrance data. Presumably connected by a surface
>    survey to a fixed point but I haven’t deciphered that.

It's clearly been derived from GPS tracks.

A lot of this entrance info needs a good checking over as I'm pretty
sure there is all sorts of nonsense in there. But more usefully we
should work out how to enter the actual data we have such that a
consistent location can be calculated from the available data, rather
than arbitrarily annointing one GPS reading which is currently what
happens a lot.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/