On Dec 21, 2020, at 10:53 AM, Anders Torger <[email protected]> wrote:
> 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.
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.
> 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.
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.
> 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.
Repeating myself: "there is good design, there is bad design." Which do you
think OSM prefers?
> I guess cities can do well without region mapping or just use points which
> there is a quite rich definition for already (neighboorhood etc),
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").
> 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.
There you go again: you seem to persist with this basic understanding that
OSM's rendered 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).
> 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?
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.
Anders, honestly, I'm trying to help you.
SteveA
_______________________________________________
Tagging mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/tagging
