iD/Controversial Decisions

From OpenStreetMap Wiki
< ID
Jump to navigation Jump to search

Edit icon (the Noun Project 30184).svg

This is an opinion article.
This page contains the advice or opinions of one or more OpenStreetMap contributors. This page is not documentation, nor is it one of OpenStreetMap's policies or good practices, and it has not been thoroughly vetted by the community. Some articles represent widespread norms; others only represent minority viewpoints.

Some decisions by the iD maintainers – mainly regarding tagging – appear controversial or lack support by the community. These cases are documented on this page.

This page is not a place to discuss what is controversial and what not. If you are not sure or if you doubt that any of these entries is controversial, discuss it on the Tagging mailing list or any appropriate, frequently used place. It is controversial if many people disagree with the decision of the maintainers of iD and can provide valid arguments against the maintainers' decision.

The software dispute resolution panel has been created to handle such controversial decisions, but has never being used so far.

Present in the Latest Release of iD

Asking users about performing tag transformations that don't know about tags (and should not know about tags according to iD maintainers)

See iD issue #7047, iD developers claim that subset of tagging info displayed by iD interface and iD map rendering is sufficient to judge a validator edit.

Deprecating (and automatically replacing) tags without discussion and in some cases clearly wrongly

See https://github.com/openstreetmap/iD/blob/6141132cb7360f484dd845cfbf6999d8011c3e82/data/deprecated.json

In particular (as in clearly wrong)

further there are a couple of replacements that potentially cause a loss of information.

Tram crossings

iD introduced railway=tram_crossing and railway=tram_level_crossing as an alternative to established tags railway=crossing and railway=level_crossing

Those tags are not supported by other editors. JOSM does not render them and, on the contrary, rejects those new tags which bring no added value and potentially create issues in places where trains and trams/light-rail share the same tracks. See JOSM issue 19982.

https://github.com/openstreetmap/iD/pull/9306 proposes to change iD to not automatically add these tags anymore.

Most would have been added through automatic fix of validator warnings. As of 2024-09-12, there are still 17k + 15k = 32k railway=level_crossing , and 14k + 13k = 27k railway=crossing on railway=tram or railway=light_rail , with the consideration that some pre-existing ones have been retagged.

4th format for vehicle services "introduced"

An undiscussed change to the ID editor lead to a confusing bunch of tags.It's unclear what the prefix service:vehicle=* should be good for (to distinguish it from what ?)

Default loading of icons from Facebook

iD loads icons hosted by Facebook as part of its chain store autocompletion, causing privacy concerns.

It is possible to disable that in settings.

To mitigate this, since version 2.20.3, the privacy settings are shown when iD is loaded for the fist time. See issue #8831.

Shrubbery preset

The iD maintainers thus far have yet to accept a preset for natural=shrubbery despite a two-year-old ticket and continued sustained growth in usage of that tag.

Resolved in Latest Release of iD

Adding highway=footway to public_transport=platform

This issue is resolved since version 2.15.2.

This was part of iD since version 2.15.0, added in iD issue 6042.

Quincy Morgan provided the following explanation for their change:

The overall motivation behind these and similar recent changes is to replace implicit tagging with explicit tagging. Implicit tags make it harder for consumers to handle OSM data with certainty. A feature with highway=footway + access=customers + bicycle=dismount is much less ambiguous than public_transport=platform alone

iD's validation rules asked to add highway=footway to all platforms (public_transport=platform and railway=platform). People against the change argued that

On 22 May 2019 Nakaner asked to remove this validation rule and pointed out the issues mentioned above. Both on GitHub and on the tagging mailing list, almost nobody objected and multiple users agreed with him. On 23 May 2019 Bryan Housel closed and locked the discussion on GitHub saying he agreed with Quincy. This comment was the subject of a Code of Conduct complaint.

Adding barrier=kerb to nodes with kerb=*

Many nodes with kerb=* tags are highway=crossing nodes. Which means tags apply to both a pedestrian crossing and a road. By adding a barrier=* tag, iD (> 2.15.0) introduces a barrier to the road, which breaks routing in some applications. This feature was removed in version 2.15.2. See also the GitHub ticket about the complaint.

Biased in favour of Facebook, Reddit, Slack when suggesting how to engage with community

After uploading, users are shown a selection of channels from the "community index" where they can engage with the community. The ID editor contains code that, if different channels are defined for the same area, will prioritize the proprietary channels Facebook, Reddit, and Slack over the open channels Mailinglists, Forum, and IRC. A pull request to rectify this situation was closed.

SOLVED: The OSM Community Index is an editable github repository so anyone can propose a change. As of 27 Aug 2019 there is an order property so channels can be ordered how the community wants.

Changing crossing=zebra to crossing=marked

crossing=zebra was originally documented as UK-only shortcut tag in the wiki. iD pushed the global use of this tag through the preset mechanism, see here for a summary: [2] Recently the authors of iD decided that crossing=zebra should be deprecated (no public discussion about this has taken place, the tag has 533.000 uses as of July 2, 2019), and offers to automatically replace it with crossing=marked, which is an undocumented tag (currently 269.000 uses as of July 2, 2019, likely due to the automatic conversions, because taghistory shows nearly 6000 uses in mid 2018).

The tagging of crossing=marked is based on the proposal Proposed_features/Unambiguous_crossings.

It should also be noted that a "zebra crossing" may have legal implications in a jurisdiction, that may not be the same than any other kind of crossing markings (this is completely unclear because of the lack of definition and discussion of crossing=marked).

Issue 6962 proposes to add also crossing_ref=zebra to eliminate data loss.

This issue was solved in iD 2.17 "due to ambiguity issues raised by mappers...since the meanings of these tags vary across the OpenStreetMap database".

Imagery Index license violation

In March 2020, Bryan forked the Editor Layer Index (ELI) into a new iD-specific imagery-index under ISC license, incompatible with CC BY-SA 3.0. Both ELI maintainers and JOSM maintainers consider this is a license violation of the data shared between ELI and JOSM Imagery sources. In addition Bryan is "OK with that the ISC license would prevent some kind of automatic sync with JOSM's wiki". After protests it was promised that copyright violation will be fixed, by switching to an appropriate license. On 20th March 2020, Quincy reverted the switch in iD "as per direction of the OSMF board" (comment was later edited to "due to strong push-back from some influential members of the community").

But promised license change that would stop copyright violation was not done so far as of June 2020[1], with reminder posted on June 2020 - as it turned out delay was caused by completely understandable reasons and issue was fixed immediately.

Calling a highway=track an "unmaintained track road"

Maintained asphalt forestry road. Correctly tagged as highway=track + surface=asphalt + tracktype=grade1. Was incorrectly described by iD as "Unmaintained Track Road"

The preset name for highway=track is "unmaintained track road", while the tag has no documented implications about maintenance but is about access to the land. Name applies in in the US English localization. It is also used as a base for all translations though some substituted this term by more accurate. There are multiple tickets on GitHub about this decision:

  • GitHub ticket #2615 where Bryan mentions that he changed the description of the tag on the OSM wiki (the wiki edit was reverted later)
  • comments to commit 6b2a692 (discussion locked, Bryan Housel showing unwillingness to accept other opinions)
  • GitHub ticket #3038 (closed, locked)
  • GitHub ticket #6954 suggested to not use "unmaintained track road" for (at least) tracktype=grade1. It was closed by Quincy Morgan as, "The paved issue was discussed at length (#2615, #2982, #3038, #4092, #5128). Let's please not rehash it". The ticket was locked a few hours later.

There is an interesting analysis by Roland Olbricht of that case posted on one of mailing list.

Situation was changed with https://github.com/openstreetmap/id-tagging-schema/pull/288

nonsquare=yes for buildings and highlighting unsquared buildings as errors

On 7 May 2019 Quincy Morgan opened a ticket on GitHub suggesting that "iD should offer a fix like "Tag as accurate" that will add a tag like unsquare=yes to indicate a building is known to be truly irregular". Michael Reichert and Paul Norman objected on the GitHub ticket; Michael Reichert brought the issue to the attention of the community on the Talk mailing list. Both on the mailing list and the GitHub ticket, various users pointed out why such a tag should not be used, that editor developers should not just invent tags as they like and where such a valiation rule could cause problems.

Note: Quincy replaced unsquare=yes by nonsquare=yes during the discussion.

Links for further reading/archived discussions:

iD 2.15.2 and later do not offer to add nonsquare=yes as a autofix option of the validation rule but still use the tag to suppress the validation warning.

Not showing specifics of automatic tag transformations by default

Unless you click on an info-button, the automatic transformations, are confirmed „blindly“ (not knowing what they will do) and will just happen in the background. These are functions for experienced mappers who know the meaning of tags and should be required to have a look what will be automatically changed. Right now you can blindly confirm these without actually knowing what they are about. There is a UI conflict between making conscious pro decisions and a simple “trust us and click ok”-style UI.

Deprecations

References