[Expo-tech] Survey kataster numbers linking to cave names etc

[Wookey]

On 2020-06-12 00:57 +0100, Rebecca Lawson wrote:
> Quick follow up on the meeting on Wed: I'm not sure why it's necessary to
> include the entrance station name in the .xml files in expofiles/entrance_data
> 
> (eg http://expo.survex.com/1623/204/204.html "p204a" and "p204b")
> 
> Isn't this info already in the survex file ("*entrance p204a")?

> Surely Nat only needs a look-up to get him between the kataster (or unofficial)
> number and the cave name, he doesn't need the entrance survey station name as
> well.

Well, all those points exist in the dataset, but I don't think every
cave has a 'p' point defined. Nor do I expect the names to be
consistent enough that a straight lookup from the kataster or official
name will always work. There will be differences in case,
dash/underscore and probably some other randomness. You might get a
point for both the kataster number _and_ the unofficial number and
they might not be the same. Possibly we could go through and fix up
those things but fundamentally this is relying on conventions.

There might have to be code to look for a 't' if there is no 'p' and so on.

An actual entry in the _entrance_data_ file explicitly says 'this is
the point for this entrance' which makes it very easy for a computer
to deal with and allows for any weirdness, craziness and renumbering
that might occur.

> In principle I don't like the idea of typing by hand the same info in multiple
> places. It's a waste of people's time and it's error prone.

This is a good principle, but we are talking about two different
datasets here (loser survex data and the website cave database), and
this would be the explicit link between them.

> The entrance
> station info seems to me to belong in the survex file and we shouldn't also
> include it in the cave/entrance info in expofiles (it's missing for many caves
> already). Or am I missing something?

No, it's a reasonable point. Strictly we are defining a point, and
then recording a reference to it in a different dataset, but that does
look quite a lot like 'writing the same thing down twice' in practice.

I can't offhand think of a good reason why the *entrance point should
be different from the <entrance_station> for one entrance, so if we
made the loser dataset sufficiently regular just looking for
p<kataseternum> or p<unofficalnum> should work in priciple. I just
worry about odd cases (e.g. what if you find both and they are not the
same location?), and just failing to find one.

It can also be non-trivial work to fix the survex dataset to have
entrance points correctly named and processed (I know a load are wrong
at the moment and have not done the relevant loin-girding to sort it
out yet), whilst it's trivial to write down 'a station' in the cave file
and have that location appear on the webpage. So it may sometimes be
expedient to use the <entrance_station> feature.

Perhaps a good way to do it is to only use that field to deal with
special cases where the simple search for p<kataseternum> or
p<unofficalnum> fails. That way we mostly don't fill
it in 99% of the time but it's there to allow for special cases.

I think it's up to Nat if he is up for writing a relatively smart
script to fish out the right p<whatever> points from
<kataster_area>.3d file dumps and fall back to the entrance_data/*
files, or just want to write a really stupid one that reads
<entrance_station> and looks it up. I guess you always end up using
all 3 files anyway <cave_data>/<area>-<num> for the name and the
entrance slugs, <area>.3d for the locations and
<entrance_data>/<area>-<num> for the entrance names (via the slugs),
so it may not make much difference to the complexity which way it is
done.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.wookware.org/pipermail/expo-tech/attachments/20200612/4c716c61/attachment.sig>