[Tagging] Mapping of mountain ranges (Was: The showstoppers for mapping Scandinavian nature.)

[Kevin Kenny]

On Mon, Dec 28, 2020 at 9:45 AM Joseph Eisenberg <joseph.eisenberg at gmail.com>
wrote:

> The problem with a relation like this which tries to represent an area for
> a part of a mountain range (the "Mürzsteg Alps") is not centimeter
> precision, but that it cannot be mapped accurately to even the nearest
> kilometer.
>
> Look at this area:
> https://www.openstreetmap.org/relation/2247685#map=14/47.5438/15.3067&layers=C
>
> The currently defined area of the mountain range follows the river in the
> southwest, but then suddenly crosses the valley in a nearly straight line
> to the primary highway, and then follows this through a village, crossing a
> ridge and a stream on the way.
>
> There is no physical object that can be followed along that straight-line
> way.
>
> This leads to silly situations where half of a village in a valley is
> considered part of this mountain range, while the rest of the village on
> the other side of the main street is in a different "mountain range":
> https://www.openstreetmap.org/relation/2247474
>
> Boundaries like this are not verifiable because they cannot be confirmed
> to be correct, except by appealing to a semi-official authority, "the
> definition made by the local alpine club" (
> https://de.wikipedia.org/wiki/de:Alpenvereinseinteilung%20der%20Ostalpen?uselang=de#/media/Datei:AVE_Ostalpen.png) - which
> in this case has defined an area which is convenient for their uses, but
> does not represent a physical reality.
>

Given that this impossibility is something that many people want, I'm not
quite willing to abandon the discussion of 'how to do it' entirely. 'Why
not to do it' has failed to convince many, as evidenced by the fact that
this keeps coming up. Surely many users want to have features such as
mountain ranges appear on a map (not necessarily OSM-Carto - just *a* map
based on our database!), and I think we owe them a better answer than "No!"
"Let's investigate how we might accomplish this without sacrificing our
other requirements of data consistency and verifiability," is a much more
palatable reply. That investigation might reveal that it's a very difficult
problem (it is, indeed!) but it can then lay the groundwork for further
discussion without everyone talking past one another.

For the specific topic of mountain ranges, I think there are verifiable
approaches that might work, if we don't insist on mapping them as areas.
I'm perfectly fine with giving up on areas that are completely undefinable,
rather than simply indefinite for a portion of their margins. 'The Alps'
are not an area with a well-defined topology for which things like
containment and intersection queries make sense.  (I'm not entirely willing
to give up on bays, seas, straits, peninsulae, isthmi, or indefinite admin
boundaries. For those, topology often does matter and the indefinite
portions are usually short and consist of a fuzzy boundary between two
otherwise well defined regions. But that's not my main point here!)

Many mountain ranges form divides between major river basins.  When this is
the case, the divide can be mapped reasonably accurately as a linear
feature. There may be some ambiguity in high-elevation wetlands that drain
both ways - but it we are totally intolerant of even the slightest
ambiguity, we're not mapping the real world.  This, of course, does not
solve the problem for the Alps, because they drain in so many different
directions (Rhine, Rhone, Danube, Po, Var, Adige, Piave, ...?) that the
divide lines would be a maze.  Even the mapping of the ridge line can be
problematic. This thread reminded me to query the mapper who imported
https://www.openstreetmap.org/changeset/90304729 - simply because it may be
following the hydrography, but it's definitely not following the local
name! (I offer the Shawangunk Ridge State Forest and the Shawangunk Ridge
Trail - both of which are signed in the field - as evidence of the local
name.)

For a linear mountain range, the ridge line might be Good Enough. For a
more complex ones, a renderer might have enough to go on by adding a group
relation for the major ridges.  (I'm not talking about the main renderer
here - this problem is far beyond its current capabilities. But from time
to time, I experiment with renderings.)
https://en.wikipedia.org/wiki/European_watershed#/media/File:Europ%C3%A4ische_Wasserscheiden.png
suggests that label placement on a generalized version of the divide lines
from the Cévennes or Vosges in the west to the Carpathians in the east
would come pretty close to my (uninformed?) view of where one might label
'ALPS' on a small-scale map.

Returning to https://www.openstreetmap.org/changeset/90304729 suggests that
identification of the Catskills on a map might produce more of a challenge.
Only a few of the higher summits are west of the divide line. But if a
group relation were also to encompass the dividing line of the Mohawk River
basin, and possibly the high ridges on either side of the Pepacton
reservoir, that combination would give a pretty good indication of the area
of interest. I think an appropriate label placement technique could be
developed.

Yes, it's a hard problem. I'm asking, "what is the minimal infrastructure
that we could provide to even start the research on attacking it?" and
trying to break it down even farther to specific types of features (since
it could be that there is no good single solution for all indefinite
features.)  For the specific case of mountain ranges, "map the major
ridges, and provide the name of the range by grouping the ridges (or
isolated peaks) into a relation" looks like one of the better
possibilities.

Sure, that particular limited grouping and naming is 'unverifiable' - the
names of natural features often are!  To the best of my knowledge, the only
place that Balsam Cap  https://www.openstreetmap.org/node/357546546 has its
name indicated in the field is that it is written in felt-tip pen on the
cover of the climbers' log book at the summit. Van Wyck Mountain
https://www.openstreetmap.org/node/357594389 does not have even that much.
But those are the names. The locals know them, and many maps of the region
call them out.

If even relations grouping the ridge lines to guide a data consumer to
produce an estimate of the area of interest are to be sacrificed on the
altar of verifiability, then I think we need to have further discussion
about how to permit OSM to have stable relationships with foreign
databases. I don't know enough to judge whether, for instance, adding
Wikidata identifiers to the ridge segments could allow the relationships to
be mapped in Wikidata, or in another database keyed to it.  Except for
Wikidata ID's, the presence of foreign keys has been regarded by at least a
significant and vocal minority of OSM'ers as unacceptable practice (again,
because they're not verifiable in the field). But that has the effect of
cutting OSM off from the rest of the network ecology - there is no stable
handle by which a non-OSM database can assert, "I consider *this* object in
my database to be related with *that* object in OSM."  We make ourselves
into an island.

Truly, I'm not trying to open a gateway to a yawning pit of chaos and
madness!  I think the question if "is there something minimal we could do
that would allow these things to be done by an external system?" deserves
an answer.  Otherwise, the argument starts to sound like "you can't have
your features on our map, and if  you want them on your own, you can't tie
it to our data!" which is not exactly friendly.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201228/f253b513/attachment-0001.htm>