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

[stevea]

On Dec 28, 2020, at 9:07 AM, Kevin Kenny <kevin.b.kenny at gmail.com> wrote:
a lot!  I love his usual very knowledgable analysis, so thank you, Kevin.  Including
> 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.

I've mapped my local range as a linear feature, which is simply a way whose nodes are ridge peaks in a geographic direction (it could be the opposite geographic direction, that is, the way could be reversed with no change in the meaning that "this is a mountain_range" and NW->SE instead of SE->NW).  Indeed, I consider this "Good Enough," and while I've had a complaint or two about it, I also see others who nod their approval (with, for example, decorations to the data of a Wikipedia or Wikidata tag).  I've also heard from another OSM collaborator who would rather that his "experimental" mountain range not be included in "international contexts" (like this list), so I won't say more than that, and this:  it is a relation of nodes that define "peaks which are included in the range."  Both approaches seem valid, but there are naysayers about any particular data structure that represent a mountain_range (distinct from a ridge) in OSM.

> 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.

I am similarly optimistic.  Both the "proper inclusion" aspect (it seems a relation is the only way to go) and the naming aspect, though the latter continues to challenge my thinking regarding implementation.

> 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.

I "second the motion" that I think this is fine approach to start with and further develop.  Again, putting it into a relation seems like the easy part (grouping and tagging still to be determined), but the naming aspect and how that renders, I'm almost fully at a loss to even pontificate how that might be done ("properly").

> 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.

While "what the locals know to be true" is certainly a traction point likely sufficient to establish OSM verifiability, at least in the USA we have federal (and state?) agencies specifically concerned with geographic naming (in our Department of Interior, one is "United States Board on Geographic Names").  Both, indeed ALL sources (historical documents, newspaper articles from hoary old microfiche that use a particular name for a particular feature...) should be utilized to establish and verify names.  The more "scholarly," authoritative and complete, the better we make OSM (and it's true, better bolster our street credentials as a respectable map with respectable data — not that we're not, but the sky's the limit).

> 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.

Kevin touches on a seldom-talked about very important topic:  where and when OSM's data potentially conflict with either reality itself (because of "fuzzy" or an ill-defined, possibly incompletely defined feature) or other data pool (Wiki*...).  We need to explore issues around these topics, they do seem to be coming up again and again.

> 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.

Not to mention "how to 'capture' and 'name'" natural features like mountain ranges and more.

SteveA