[Tagging] Fuzzy areas again: should we have them or not?

[Anders Torger]

Actually it seems to me that thinking about several tags at a time seems 
to be a fairly new concept ;-)

Joke aside, describing a complex reality may require something more than 
the simplest possible data model.

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.

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.

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.

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.

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.

/Anders

On 2020-12-21 20:26, stevea wrote:

> On Dec 21, 2020, at 10:53 AM, Anders Torger <anders at torger.se> 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
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201221/d4102221/attachment-0001.htm>