<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">Am 13.08.2020 um 19:06 schrieb Colin
Smale:<br>
</div>
<blockquote type="cite"
cite="mid:517ed6c9f019606c606053f3235153e8@xs4all.nl">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>On 2020-08-13 18:35, <a class="moz-txt-link-abbreviated" href="mailto:Werner.Haag@leitstelle.tirol">Werner.Haag@leitstelle.tirol</a> wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0">
<div>Hi,</div>
<div> </div>
<div>in my opinion (i think dktue is right there) it should be
easy for a user to distinguish or extract (overpass query) the
upper, mid and lower stations.</div>
<div>That´s not possible at the moment in OSM. Elevation (ele
tag) may be useful, but does not indicate whether a station is
the lower or upper one.</div>
<div>On the other hand, a tagging with upper_station or
lower_station is clear and self-explanatory.</div>
<div> </div>
</blockquote>
<div>It would also be a denormalisation of the data. In SQL terms
you would use a subquery like "WHERE ele = MIN(SELECT ele FROM
stations WHERE...)" although I suspect the usual use case will
be looking for the whole line, so a simple "ORDER BY ele" would
give you all you need to know - bottom station is first row, top
station is last row, rows 2..n-1 are mid stations. This would
avoid any possibility of conflicting information, e.g. multiple
stations tagged as top, or the station with the lowest elevation
being tagged as top station.</div>
<div> </div>
<div>All this is based on the assumption that the definition of
the top station is the one with the highest altitude.... If any
other factors are in play that could mean that this definition
does not always hold true, then I am keen to hear.... It's best
to check assumptions, even (especially?) if they do appear
obvious.</div>
<div> </div>
</blockquote>
I agree that this is denormalization, but: We still do this in OSM
with addresses and zipcodes for example and this is a good thing to
do: Because it allows to find potential errors in the data in an
automated way. I think it's very hard to find a wrong ele-Tag but it
would be easy to hint in a quality assurance tool that ele-Tag and
station-Tag do conflict.<br>
</body>
</html>