<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">On Dec 21, 2020, at 10:53 AM, Anders Torger <<a href="mailto:anders@torger.se" class="">anders@torger.se</a>> wrote:<br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><div class=""><br class=""></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 class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><div class=""><br class=""></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 class=""><br class=""><blockquote type="cite" class="">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 class=""><br class=""></div>Repeating myself: "there is good design, there is bad design." Which do you think OSM prefers?<div class=""><br class=""><blockquote type="cite" class="">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 class=""><br class=""></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 class=""><br class=""><blockquote type="cite" class="">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.<br class=""></blockquote><div class=""><br class=""></div>There you go again: you seem to persist with this basic understanding that OSM's <i class="">rendered</i> 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 class=""><br class=""><blockquote type="cite" class="">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?<br class=""></blockquote><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Anders, honestly, I'm trying to help you.</div><div class=""><br class=""></div><div class="">SteveA</div></body></html>