<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>Actually it seems to me that thinking about several tags at a time seems to be a fairly new concept ;-)</p>
<p>Joke aside, describing a complex reality may require something more than the simplest possible data model.</p>
<p>The thing got me baffled from the start is that there's so many things regarding naming that can't be done in with OSM and any of its most popular renderers. That have existed in regular maps since forever. To me it's like starting to use a new word processor just to discover that the character 'q' is in available, because the designers didn't put it in as it's not really used as much as the other characters :-). I just "WHAT? You must be kidding!". The omitting of obvious features (what I thought was obvious at least) and the lack of interest to find solutions for them just felt unreal.</p>
<p>But now after being on this list for a while I'm doubting myself, maybe this isn't as obvious after all. I know mostly Swedish and to some extent Norwegian maps, maybe all these features are non-existent in all other countries, but I doubt it. What is somewhat special is that we have quite a lot of rural areas, but that exists in other countries too. I would guess that there are many native American names still alive and well in the US nature, just like we have lots of Sami names in nature Sweden/Norway/Finland. I think it's more about that most OSMers are interested in urban areas, street routing and stuff like that, and outdoor maps haven't really been much of a thing other than for simple illustrative purposes.<br /><br />I don't consider it a great achievement in design to simply just strip away all features of maps that require a (slightly) more complex data model. What we in OSM seem to have done is simply to adapt the end uses after our data model, not adapt data model after what typical end uses require. It's like if we considers these names in nature to be poorly designed (no defined borders! booo!) and should therefore be disregarded. But this is our culture. Those names exist and any serious map maker takes these names seriously and find a way to represent them. Actually I even find it disrespectful to the people of the local land current and past to ignore the names. Locals will still know them, but visitors will only know them from maps, and if they aren't there, they won't exist to them.</p>
<p>But I hear what you are saying, and many other say. It boils down to that OSM is not a map, it's a database with geo information, and it will only cover those features that fit the data model that is already set (in stone perhaps?). If a map feature needs something more, well, then we don't do those maps, or someone else could add some extra database and make their own renderer that can. Well, I guess that's fair enough.</p>
<p>I'm today leaning towards stopping to contribute to OSM as the type of mapping I'm most interested in is what OSM on the whole is clearly least interested in, and not really interested in improving in either. But I'll think about it the coming weeks. As Tomas pointed out you can work with OSM without ever caring what people in this list think or do. It basically means that you need to implement a renderer on your own though and make own data on the side and that's a huge task, and I'm not sure I'm *that* interested in mapping.</p>
<p>/Anders</p>
<p id="reply-intro">On 2020-12-21 20:26, stevea wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div id="replybody1">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On Dec 21, 2020, at 10:53 AM, Anders Torger <<a href="mailto:anders@torger.se" rel="noreferrer">anders@torger.se</a>> wrote:<br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Cluttering could be a problem, but is an easy thing to solve with filters. As I edit i national parks now I have this huge national park polygon covering all work, which renders as a flat although half-transparent color in JOSM. It's easy to remove with a filter though, but actually I'm not disturbed by it enough to care to do it. If we actually define this as a feature we could have a filter setup for these in our tools.</blockquote>
<div> </div>
Anders, think about what you are saying: defining fuzzy areas (work to do, work to achieve consensus...) virtually requires a tool filter for reducing or eliminating them from how many — even most — mappers view them? That smacks (hard) of "OSM: do something quite different from what you do (for me and my purposes) and then filter out the results (as noise) from your views of the data." Do you see how this entire approach can be seen as offensive by OSM? I don't want to stifle real questions about whether we want fuzzy areas, as it's a valid discussion. But positing it like this is 100% a non-starter.<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">The question becomes more complex as there are several types of these areas. Regions in cities like this I haven't thought about before, I didn't know that it existed. It has quite different impact than a plateau in the mountains.</blockquote>
<div> </div>
Yes, it does become more complex. You haven't thought about these? Thinking about these (and others like them, yet also unlike them) is required. There are no shortcuts to that.<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">I think it would be unfortunate if a few bad examples of fuzzy area use or (simple) limitations in our tools block all use or further development of them, as they are important for certain type of maps in certain areas.</blockquote>
<div> </div>
Repeating myself: "there is good design, there is bad design." Which do you think OSM prefers?
<div><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">I guess cities can do well without region mapping or just use points which there is a quite rich definition for already (neighboorhood etc),</blockquote>
<div> </div>
Yes, the specifics of how to map "smaller conurbations" (within larger conurbations) is documented in our place=* wiki. There is no need to guess at how to use nodes (or closed ways) to do this. (Not "points").</div>
<div><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">but making an outdoor/rural map without naming nature and without proper support for zooming out (ie having some approximate size of the named features), greatly cripples the capabilities of maps rendered for those areas.</blockquote>
<div> </div>
There you go again: you seem to persist with this basic understanding that OSM's <em>rendered</em> map data are "what OSM is." No. OSM is data. Accurate, ground-verifiable (there are some specific exceptions, like boundaries), peer-reviewable, properly tagged (because consensus establishes the tagging scheme) data. Stop tagging for the renderer! (And / or build your own).<br /><br />
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">Do you think there is a valid use for fuzzy areas in outdoor/rural areas, or would you rather see them not being used there either?</blockquote>
</div>
<div>I see potential value in the concept (a good place to start, as I have said). I don't see anything nearly enough for me to conclude (let alone even begin to consider, yet) that "fuzzy areas" should be "in" OSM. In some separate, OSM-friendly (possibly to be mingled with OSM data) repository which can be cleverly blended? Maybe. I would need much more proposal-oriented specific propositions with which to evaluate that before I could proceed. Should you wish to continue in this direction, please develop one (or several) such proposals (starting with familiarity with our culture, process and tools, then progressing through questions and dialog) and this community will consider it / them. Jump up and down that "we are crippled because we don't do what you think we should do" (and don't currently, because it isn't what we do, it is what you THINK we SHOULD do), no. This community should not consider repeated complaints that we do not do what one Contributor thinks we should do as valid methodology to quite radically alter our data model. Such an approach is doomed to failure, and should be. Constructive propositions to different ways of doing things? Proposed as the community has evolved to discuss, develop and accept them? Sure, we do that here. Absorbing repeated complaints that we shouldn't continue with a working process and listen to one, persistent complainer? Nope. That's not how this project works.</div>
<div> </div>
<div>Anders, honestly, I'm trying to help you.</div>
<div> </div>
<div>SteveA</div>
</div>
</div>
<br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br />Tagging mailing list<br /><a href="mailto:Tagging@openstreetmap.org">Tagging@openstreetmap.org</a><br /><a href="https://lists.openstreetmap.org/listinfo/tagging" target="_blank" rel="noopener noreferrer">https://lists.openstreetmap.org/listinfo/tagging</a></div>
</blockquote>
<p><br /></p>
</body></html>