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

[stevea]

On Dec 29, 2020, at 9:58 AM, Martin Søndergaard <sondergaard246 at gmail.com> wrote:
> There are some interesting ideas in these threads including Brians proof of concept. But I want to just quickly extend the implications of this discussion to other similar natural features, e.g. bays, straits, valleys etc.

I'll repeat that I, too, am finding much that is interesting in these threads.  The discourse yields wide knowledge and fresh approaches to difficult issues.

> If it was decided that mountain ranges should be determined by relations of peaks or ridges, then it should be clear that such a definition can't be extended to many (or any) of the other similar "unverifiable" features; bays clearly don't have an analogous feature to peaks.

I think it's safe to say the list and its participants remain in an "exploratory mode" about these topics.  An important corollary is that how one natural feature (set) determines its "where," its definitions and its data structure implementation more-likely-than-not isn't going to be the same for another, even those which share "natural."  I re-state what Martin says, and it may be obvious, but mountain ranges, and how we might define and tag them, isn't going to work for bays, valleys, wetlands, etc.  What we're doing is noting these differences, although I think it is useful to say explicitly that these share a quality of "amorphousness," where "sharp boundary" does not exist.  The concept of "fuzzy" helps, but I'm not sure it is quite what is needed, though it appears "helpful" in its present articulation (even as it seems only poorly able — with some work and maybe luck — for data consumers to determine "I'm inside" vs. "I'm outside").

> I can imagine a world where each of these features have their own complex way of being defined resulting in a mess of different workflows. "How do I add a mountain range again? Oh yeah, I make this relation of ridges". "But what about valleys? I can't quite remember; was it something like...", "But what about straits?", and on and on it goes.

Yes, again, a mountain range isn't a bay isn't a boggy swamp.  If we think of an attribute ("amorphous") that is applicable to a great many things (where a neighborhood begins and ends without strictly-defined boundaries, how inclusive of minor peaks and foothills is a mountain range...) we can partition OSM data into what most of them already are:  those NOT included in the concept of "amorphous" and a broad category of data which ARE included in it.

> Disregarding possible disadvantages for a moment, the advantage of simply representing these features as an approximate simplified polygonal area is that the "workflow" becomes the exact same for all of these features.

I agree — as does a noticeable segment of OSM who have done this — that "drawing an approximate simplified polygon" is not only similar for widely disparate amorphous data, but that doing so is only a first draft of implementation.  As necessity is the mother of invention, this technique evolved to quench the thirst of mappers looking to capture "bays, straits, valleys..." in OSM, yet it has drawbacks.  I'm guessing that even as mappers enter these data, they feel a sense of "good enough, though at the same time, not good enough."  Can a database, made of the cold reality of 1s and 0s, capture the semantic of "amorphous?"  With a fuzzy tag?  With something better?  Is it even possible?

So:  most data in OSM are not amorphous, but a wide number of categories of data (especially, though not exclusively, natural=*) are amorphous.  OSM does have the practice of drawing polygons of approximation and the concept and tag of fuzzy=* sometimes applied to better characterize this, but these are controversial and ill-defined (formally, as in wiki). There is https://wiki.osm.org/wiki/Proposed_features/Fuzzy but it is from 2009, has Status "abandoned" and its scant Discussion page dribbled off to nothingness over five years ago.

I realize this post is little more than a restatement, a high-altitude flyover of what has largely already been said.  But there really are two classes of data both in OSM and what we want to better enter into OSM:  the "sharply-defined" (the great majority of our data) and the "amorphous" (in the minority, made up of many differing sub-classes).  Maybe simply saying that out loud helps, I hope so.

SteveA