[PATCH][RFC] Give hints as to what tags are being matched (was remove man_made=communications_tower)

[SherbetS]

Hello.

I am proposing to remove the preset for the tag: man_made=communications_tower.

My reasoning is that there is a extremely high likelihood that there are not any objects in the world that are "a far visible landmark. An indication could be a height greater than 100 meters" that have not been added to the map already.

Preserving this tag in the JOSM presets is just asking for mappers to use it incorrectly, tagging objects that should be man_made=mast + tower:type=communication due to the nature of the english language.

I've spent several hours trying to clean up after mappers using this tag correctly, and I'm tired of having to fight the fast increasing rate at which objects are being tagged with this tag.

see: ​https://taginfo.openstreetmap.org/tags/man_made=communications_tower#chronology

The iD editor has already removed this tag from their presets for this reasoning.

Thanks,
--SherbetS

[skyper]

Could you, please, share some example changesets created with JOSM where the tag was used incorrectly? Thanks. Did you comment on the changesets? Was the internal preset used?

We already named the preset Big Communication Tower and have additional text about the usual height of more than 100m plus links to the other presets. The name and the text is translatable therefore I wonder how the tags can be mixed up.

Why should we remove a well established tag? In addition the presets also offers several secondary tags for more details. This option would be lost. In my eyes this ticket is invalid.

[SherbetS]

Sure. I can link some changesets.

​https://osmcha.org/changesets/127234022/

​https://osmcha.org/changesets/125200147/

​https://osmcha.org/changesets/122885679/

​https://osmcha.org/changesets/122229950/

North America has only one communication tower from what i’ve seen, but hundreds are added by users who don’t know the tagging scheme.

​https://osmcha.org/changesets/108821814/

​https://osmcha.org/changesets/115314437/

​https://osmcha.org/changesets/81234420/

​https://osmcha.org/changesets/72719984/

there are hundreds upon hundreds of changesets I can link all day of mappers using the tag incorrectly. The guidance in JOSM isn’t enough. Editors look for communication infrastructure, and pick the first preset that has communication in the name. Like I said before, the nature of this object means that the likelihood of one not presently being on the map is astronomically unlikely.

having the preset still in JOSM only is resulting in damage to OSM because mappers will continue to mistag objects. I’ve changed over a thousand of these objects to the correct tagging, but they’re still growing rapidly. ​https://taginfo.openstreetmap.org/tags/man_made=communications_tower#chronology

[skyper]

Thanks, I get your point, so we need to add a better guidance.
Looking at the wiki page ​Tag:man_made%3Dcommunications_tower it definitely needs an update and translation in more languages. The sentence "Another indication is, that a man_made=communications_tower has stairs and a lift inside, whereas as man_made=tower, tower:type=communication has to be climbed on the outside." is completely misleading and should be removed. Maybe even a warning box that almost all communications towers are likely to be mapped already and if in doubt man_made=tower is the better choice is useful.

Sorry, I am probably not the best person to judge, why people have that many problems as I am familiar to man_made=communications_tower from my childhood on but I am still against removing this preset.

[Klumbumbus]

I also don't like the idea of removing the preset. IMO the not clear tagging schema of man_made=communications_tower + man_made=tower (+man_made=mast) is the problem. Maybe a proposal to deprecate man_made=communications_tower in favor of man_made=tower + tower_type=... would be the better way to go.

[SherbetS]

I think that man_made=communications_tower still has it's place, since it's a whole local monument thing in Europe from what I can tell. But I don't see why the preset has to be in the base preset set and not like an add-in preset because it's enabling even the most experienced mappers to use the wrong tag to describe regular masts and towers. I agree that the wiki pages do need work though.

There are tens of actual communications towers, but hundreds of thousands of towers and masts in the world.

[skyper]

According to wikipedia these towers are called "telecommunications tower" but that is still ambiguous and I miss a page like the Spanish one, ​https://es.wikipedia.org/wiki/Torre_de_telecomunicaciones_(desambiguaci%C3%B3n).

I have commented on some CSs but still wait for some answers.

We could add another sentence to the preset but I still fear that won't help much as people seem to do not read carefully enough and to do not look at the other linked presets.

[Palolo]

This is an interesting discussion, I mostly work remotely in Africa and so cannot always see the details needed. I do know that while in the developed world almost all of these towers have been added to OSM, but in other places there are very prominent landmarks/towers/masts that have yet to be added. I find this tagging to be rather silly and outdated since aside from waterway= and natural= the remaining 99% of OSM feature were created by humans (women also make things). Maybe a more appropriate choice would be tower=communication, tower_type=mast, etc. I know this seems like a big effort, but just because a small group of people in Manchester or Amsterdam made some decisions many years ago, it doesn't mean that we have to continue doing the wrong thing.
It's fine to remove the preset, but that doesn't solve the problem of poor language.

[skyper]

I have updated the external preset Mast and tower. Would a similar naming and individual presets per type solve the problem?

[Woazboat]

People tagging a feature incorrectly isn't a good reason to remove a preset, it's a reason to improve the wording and description of the preset (if that's indeed the reason for the mistagging in the first place). A majority of objects (or even all of them) already being tagged is also no reason to remove a preset.

[Woazboat]

Replying to Palolo:

I find this tagging to be rather silly and outdated since aside from waterway= and natural= the remaining 99% of OSM feature were created by humans (women also make things).
I know this seems like a big effort, but just because a small group of people in Manchester or Amsterdam made some decisions many years ago, it doesn't mean that we have to continue doing the wrong thing.
It's fine to remove the preset, but that doesn't solve the problem of poor language.

I assume you mean the use of man_made? Yes, the wording is unfortunate and a different term would be better. Changing it is not as easy as simply changing all man_made tags in the OSM database. That would be the trivial part. You'd have to change all software and data processing tools that use the affected tags as well as all documentation and that is pretty much impossible. "A big effort" is a bit of an understatement.
(I assume you are aware that the man in man_made does not and was never intended to refer to just male humans but to humanity in general as in 'mankind'. Use of the term has fallen out of favor in exchange for more overtly neutral terms. Avoiding it for new uses... good idea. Forcefully changing it with enormous effort and breaking lots of things along the way... maybe not.)

The JOSM issue tracker for a completely unrelated topic isn't the right place to discuss this however.

[stoecker]

The JOSM issue tracker for a completely unrelated topic isn't the right place to discuss this however.

And in case you're not fluent in English please note that man in man_made comes from man (as in human, mankind, ...) and is translated to e.g. German as "Mensch" and not from man (as in the male human) translated to German as "Mann".

So it's not "poor language", but rather "poor understanding" of the language.

[Palolo]

Replying to stoecker:

The JOSM issue tracker for a completely unrelated topic isn't the right place to discuss this however.

And in case you're not fluent in English please note that man in man_made comes from man (as in human, mankind, ...) and is translated to e.g. German as "Mensch" and not from man (as in the male human) translated to German as "Mann".

So it's not "poor language", but rather "poor understanding" of the language.

I have a fairly good understanding of the English language for many decades, but there is always much to learn. I live in the United States and we long ago started abandoning poor language usage like this. My point would even be true if the tag was people_made. It is really too bad that the "Open" part of OSM is not universal and doesn't apply to the system. stoecker If you would like to fix the incorrect tags in east Africa please feel free to do so. There are vast populations of this planet that have not map whatsoever. I very much appreciate all the work that people have done to build and maintain JOSM, it is of tremendous value.

[Hufkratzer]

Replying to SherbetS:

The guidance in JOSM isn’t enough. Editors look for communication infrastructure, and pick the first preset that has communication in the name.

I assume this is the main problem.

If in JOSM I search for "communication" I currently get this list:

If JOSM could look up how often these tags/tag combinations are used (e.g. in taginfo) and would sort the list by these numbers in descending order, the list would look like this:

Numbers	Tag/Tag combination	Display in search dialog
178.357	man_made=tower + tower:type=communication	Man Made/Towers/Tower + Type communication
156.708	man_made=mast + tower:type=communication	Man Made/Towers/Mast + Type communication
33.634	office=telecommunication	Offices/Telecommunication
3.868	man_made=communications_tower	Man Made/Towers/Big Communication Tower

If the user picks the first one from this list, it is more likely than at present that this choice is not wrong.

This method probably does not always work, but maybe it can be improved somehow.

[Hufkratzer]

shows search result

[stoecker]

The order is based on the presets file. Simply reordering the file manually would reach your goal.

[Woazboat]

Notably the other preset options don't even have communication in the displayed title. That's probably the main issue

[anonymous]

Replying to stoecker:

The order is based on the presets file. Simply reordering the file manually would reach your goal.

The current order in defaultpresets.xml is

1. Mast line 6144 ff
2. Tower line 6168 ff
3. Big Communication Tower line 6202 ff

But (AFAIK) the presets that have the search string in their own name are always listed before the presets that have it only in some combo box or multiselect list with parameter

values_searchable="true"

Check/uncheck the checkbox Search in tags to see the two different groups.

[skyper]

@all:
Please, try the external preset Mast and tower. It should solve most of the mentioned problems and an adaption would be quite easy.

Regarding finding the correct tags the OSM wiki pages would benefit from some rework and updates as I found same strange changes going back til 2018. Probably better photos of the range of each tag and better description of the differences (also from the engineering perspective) would help.

[skyper]

Ok, all useful answers on CSs would appreciate finding Communication tower and Communication mast in preset's name. I could come up with a patch which adds own presets per tower:type similar to my external preset if this will be accepted.

[SherbetS]

Yes. the main issue with this preset is that it has communications in it's name, which does a lot to guide users away from the correct tagging. I don't see any harm in just removing this preset from the ones that come with JOSM, and instead including it in a preset pack that the user can enable to work with these objects instead of continuing to have users continuing to get confused over the tagging scheme.

aplogies for the late response, I don't care to give this website my email address.

[Hufkratzer]

Replying to SherbetS:

The iD editor has already removed this tag from their presets for this reasoning.

Where is this discussion?

There is a related open issue for iD presets:
​https://github.com/openstreetmap/id-tagging-schema/issues/92

[anonymous]

Where is this discussion?

I don't think there was a discussion, but I figure someone at iD team would probably present similar reasoning to this issue.

[SherbetS]

How do I get this removed?

All of us know these features are already mapped. I hate having to waste my time fighting this.

​https://taginfo.openstreetmap.org/tags/man_made%3Dcommunications_tower#chronology

—SherbetS

[taylor.smock]

Show tag matches

[taylor.smock]

Replying to SherbetS:

How do I get this removed?

Short answer: you probably don't. The preset also provides rendering support for the already mapped communication towers.

Anyway, it would probably be a better idea to start showing the tag matches, like so:

[taylor.smock]

Indicate what tags from a preset are causing the preset to be found when using the Search presets window

[taylor.smock]

I don't know if showing the matching tags will help reduce the introduction of new man_made=tower, but I think it might help at least.

[Hufkratzer]

As explained in comment:13, it would also be helpful if the more commonly used presets Mast and Tower were listed before the Big Communication Tower preset.

I thought that the presets that contain the search string would always be listed before the others (comment:16). But today I came across a case where this is not true:

I don't understand why this is happening here and not in other cases; but maybe someone who understands it can explain how this can be used to move the Mast and Tower presets up in the search results.

[Hufkratzer]

shows search result for "polideportivo" in Spanish presets

[taylor.smock]

The sort order of that list depends upon several factors.

Here are the weightings:

• Last used (CLASSIFICATION_IN_FAVORITES): 300
• Name match (CLASSIFICATION_NAME_MATCH): 300
• Group match (CLASSIFICATION_GROUP_MATCH): 200
• Tags match (CLASSIFICATION_TAGS_MATCH): 100

For name, group, and tag matches, each word in the search term is compared. If it starts with the search term, 2 is added to the classification (so Polideportivo would be CLASSIFICATION_NAME_MATCH + 2 for a total of 302).

I don't know what is going on with Natacion, but I'd guess you have previously tagged something with it and it has a tag with polideportivo since it that search term occurs neither in the name (Natacion) nor the group (Deportes/Deporte). So it probably has a weighting of CLASSIFICATION_IN_FAVORITES + CLASSIFICATION_TAGS_MATCH + <some much smaller number> for something 400+.

[Hufkratzer]

Probably right. I tried it on another computer an got

[Hufkratzer]

another attempt with Spanish presets

[Hufkratzer]

I wonder why there are so many of these man_made=communications_tower mapped in Germany (see ​taginfo map) although it was translated "Großer Kommunikationsturm" and I wouldn't call such a tower like that, rather I would search for "Funkturm" (compare ​DE:Tag:man_made=tower), and the search for "Funkturm" only finds the man_made=tower and man_made=mast presets.

[GerdP]

@Taylor: This issue poped up again here ​https://community.openstreetmap.org/t/tag-funkturm-funkmast/108599
I wanted to try the patch but it doesn't apply cleanly. Please can you link an updated version?

[taylor.smock]

Update to current JOSM source

[GerdP]

--language=de

[GerdP]

--language=en

[GerdP]

Thanks. I first thought it doesn't work at all, but then I noticed that I had the checkbox for "Search in tags" disabled.
One problem remains:
Why do I see different results for German and English language?

Is the search only performed on the translated tags?

[taylor.smock]

It looks like it is a partial search on translated tags.

It looks like the two missing ones are Man Made/Towers/{Mast|Tower}. This is probably from cms.getDisplayValues() (L313). If we change it to cms.getValues(), I think it will work, but we probably want to do both.

[GerdP]

Yes, an additional line with

   list.addAll(cms.getValues());

seems to improve the results. Sort order is still different.
Is it intended that nothing is selected and the Select button is enabled? It seems to select the topmost entry.

[taylor.smock]

From comment:26 (so I don't have to look at how order is calculated again):

• Community center (en): CLASSIFICATION_NAME_MATCH + CLASSIFICATION_TAGS_MATCH
• Community center (de): CLASSIFICATION_TAGS_MATCH

Is it intended that nothing is selected and the Select button is enabled? It seems to select the topmost entry.

I think this is the current behavior. And something that I kind of expect, although maybe we should be selecting the topmost entry or otherwise indicating that it is what will be selected when the user hits Select.

[GerdP]

It would probably be bad to disable the button until something is selected. With the typical background colour blue for selected item the text is much harder to read. Probably the current behaviour is a good compromise.

Another possible problem:
When I search for "bridge" while a highway is selected I would expect to find presets for highway and railway and maybe others where bridge=yes could be applied, but I don't.

[taylor.smock]

Handle check groups

[GerdP]

OK, that works, but now the order really matters. With a highway=track selected I would want to find the preset Highays/Ways/Track much higher.

I rarely use presets, so maybe I am not the best candidate to suggest improvements.
I've normally disabled the preference properties.presets.visible, but for comparison I've enabled it. The selection of presets there is also confusing. When I have a way with two tags highway=track and bridge=yes the preset "Man made/Bridges/Bridge" is shown in addition to the "Highays/Ways/Track". Why?

[skyper]

"Man made/Bridges/Bridge" is shown as bridge=yes is present and while the "Highways/Ways/Track" only has a checkbox the "Man made/Bridges/Bridge" allows to add other values plus lot more tags for bridges.

[GerdP]

But a (unclosed) highway=track cannot also be a man_made=bridge. I may want to add a closed way with man_made=bride but it is very unlikely that I want to change the highway=* object to a man_made=bridge object.

[skyper]

The preset for man_made=bridge is "Man made/Bridges/Bridge outline".

[GerdP]

A OK, didn't try what happens when I select the preset. Probably just a thing one has to learn to be able to work with presets.