[Talk-GB] boundary & admin_level tags on ways.

[Colin Smale]

> On 11/07/2022 17:19 Dave F <davefoxfac63 at btinternet.com> wrote:
> 
>  
> On 11/07/2022 08:38, Colin Smale wrote:
> >> On 11/07/2022 04:14 Dave F <davefoxfac63 at btinternet.com> wrote:
> >>
> >>   
> >> On 10/07/2022 21:22, Colin Smale wrote:
> >>> For what it's worth I would like to leave these tags (at least boundary=*) on the ways.
> >>>
> >>> I know it's a rather selfish reason, but when working in Potlatch (as I and many others still do) it shows the boundary way in a distinctive style, so it stands out a bit and is easier to follow.
> >> This is one of the (minor) reasons why I would like them removed. I find
> >> the Potlatch rendering obscures the /real/ purpose of the way.
> > I don't understand your point... I suggest making boundary ways distinctive (in the editor) and you say it would obscure the /real/ purpose of the way? What is the /real/ purpose you are referring to here?
> 
> When they're attached to roads, waterways, paths etc.

You mean when a way is (e.g.) both highway=something AND boundary=something. In my opinion this scenario should not occur (in the UK at least) as the boundary and the road/waterway should be separate ways in OSM as described in https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative under "Gluing".

> 
> >
> >>> In any case, I would argue that these tags could be considered redundant or superfluous, but not erroneous (assuming they are not erroneous of course). In other words, their presence is not worth the effort to go round deleting them without any other reason to update that way.
> >> It can be performed in one changeset.
> >> I'm still struggling to understand why some contributors have an
> >> aversion to amending tags. Redundancy is a prime reason for editing.
> >> There's nothing wrong with a spring clean of superfluousness.
> > Would you advocate a mass edit crusade to rid the map of "superfluous tags"? Good luck with that. I assume your philosophy would apply equally to all redundant tags, and not just boundary=* on ways.
> 
> 
> Again, Colin, your argument is illogical. That there are many erroneous 
> tags isn't a valid reason to not amend them. One tag at a time, seems a 
> sensible process.

I didn't say that. I fully agree with you here - OSM's data quality (I mean here internal and external consistency) is very poor, and needs a good clean-up. What usually happens is that people who try to approach it in the "official" way get shot down and people who "just do it anyway" sometimes get reverted. All because OSM is allergic to any statement that could be considered as tending to define what's right and what's wrong and thereby limiting the creative freedom of mappers, whose opinion is valued far more than that of the data consumers. Such a system is intrinsically unstable as it favours people who want to diverge rather than normalise. Sooner or later OSMs data will become bogged down and essentially unusable because it will be an impossible task to make sense of the spaghetti. HOWEVER I would like to make the following point: If a mapper has an hour to spare, to my mind it would be more valuable to spend that time on adding missing information rather than removing redundant (but not incorrect) tags. And if the elders of the community have an hour to spare, they might think of how to handle the subject of data quality, starting with a definition, then a way of measuring it, and then a strategy to improve it. Then we would have a frame of reference to judge whether a proposed action would improve the quality, or detract from it. But as there is nothing more ephemeral than consensus in OSM, it will probably never happen.

> > 
> >> And before anybody replies with the illogical 'non updated data
> >> encourages people to update' nonsense again - Sorry It just don't buy it.
> >>
> >>
> >>>    A bit like the widespread use of oneway=no or access=yes - possibly pointless, but not actually WRONG.
> >>>
> >>> I don't see how could they lead to confusion and erroneous edits though.
> >> If the boundaries change & only the way is amended it leads to errors.
> >> Contributors see the tag on the way could assume there wouldn't be an
> >> extras on any of the relations.
> > Could you illustrate this with an example?
> 
> I'm unsure it has occurred yet. I want to ensure it can't. Prevention is 
> better than cure. Maintaining a simpler database is a good thing.

Absolutely, couldn't agree more. But this is a UI problem (and not a data problem) - editors etc. should protect against illogical and/or incorrect actions. Many examples of what some people regard as "bad tagging" have their origins in editor presets and QA tools making "helpful suggestions".

> > Boundary ways should not normally be shared with non-boundary functions.
> 
> With this I concur, which is why I kept my re-import of Cotswold AONB as 
> separate entities.

If everybody did this, your point about Potlatch's rendering of hybrid ways would be moot.