{"action":"created","issue":{"url":"https://api.github.com/repos/openstreetmap/iD/issues/3618","repository_url":"https://api.github.com/repos/openstreetmap/iD","labels_url":"https://api.github.com/repos/openstreetmap/iD/issues/3618/labels{/name}","comments_url":"https://api.github.com/repos/openstreetmap/iD/issues/3618/comments","events_url":"https://api.github.com/repos/openstreetmap/iD/issues/3618/events","html_url":"https://github.com/openstreetmap/iD/issues/3618","id":191684058,"number":3618,"title":"Also display tags in the left panel which reference known fields, but may not be part of the current preset","user":{"login":"bkil","id":818763,"avatar_url":"https://avatars.githubusercontent.com/u/818763?v=3","gravatar_id":"","url":"https://api.github.com/users/bkil","html_url":"https://github.com/bkil","followers_url":"https://api.github.com/users/bkil/followers","following_url":"https://api.github.com/users/bkil/following{/other_user}","gists_url":"https://api.github.com/users/bkil/gists{/gist_id}","starred_url":"https://api.github.com/users/bkil/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bkil/subscriptions","organizations_url":"https://api.github.com/users/bkil/orgs","repos_url":"https://api.github.com/users/bkil/repos","events_url":"https://api.github.com/users/bkil/events{/privacy}","received_events_url":"https://api.github.com/users/bkil/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":5,"created_at":"2016-11-25T11:41:36Z","updated_at":"2016-11-28T15:42:13Z","closed_at":"2016-11-28T15:42:12Z","body":"Let's take the example of `internet_access`. Although it is not part of `amenity=school`, a mapper could have plausibly indicated that it is physically available by entering it manually. Other mappers using `iD` should see this directly on the left panel, not hidden under the 'all-tags' section.\r\n\r\nA much more important use case would be adding fields for `contact:*`, most prominently `contact:phone` and `contact:website` (pull request ready). If a user sees that a POI already has a website given as `contact:website`, they will not enter a `website` redundantly. At present, because `contact:website` is out of sight, many users add the same information again using the legacy key by mistake.\r\n\r\nA different workaround for the second use case would involve creating special forms to handle all contact keys which have two accepted representation. A single place would be reserved on the sidebar for the user to enter this information. If none of the keys are present, newly entered data would use the new format. If either form is present, that one would be displayed and edited (optionally: when modified, save in new form). If both are present, display both. Although handling this case should be similar to how phone_1, phone_2, etc is handled."},"comment":{"url":"https://api.github.com/repos/openstreetmap/iD/issues/comments/263304601","html_url":"https://github.com/openstreetmap/iD/issues/3618#issuecomment-263304601","issue_url":"https://api.github.com/repos/openstreetmap/iD/issues/3618","id":263304601,"user":{"login":"bhousel","id":38784,"avatar_url":"https://avatars.githubusercontent.com/u/38784?v=3","gravatar_id":"","url":"https://api.github.com/users/bhousel","html_url":"https://github.com/bhousel","followers_url":"https://api.github.com/users/bhousel/followers","following_url":"https://api.github.com/users/bhousel/following{/other_user}","gists_url":"https://api.github.com/users/bhousel/gists{/gist_id}","starred_url":"https://api.github.com/users/bhousel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bhousel/subscriptions","organizations_url":"https://api.github.com/users/bhousel/orgs","repos_url":"https://api.github.com/users/bhousel/repos","events_url":"https://api.github.com/users/bhousel/events{/privacy}","received_events_url":"https://api.github.com/users/bhousel/received_events","type":"User","site_admin":false},"created_at":"2016-11-28T15:42:12Z","updated_at":"2016-11-28T15:42:12Z","body":"> What worries me more is that iD in its present state only slows me down, and something tells me that there could be other experienced contributors with the same feeling as well. The ratio of me editing a form field and adding to the all-tags section is about 1:6.\r\n\r\nSo use JOSM - more efficient editing by experienced contributors is what it's for.  iD is probably not for you.\r\n\r\nI spend kind of a lot of time responding to your issues, and I feel like we're going to keep just talking past each other because we disagree on how tags should work in OSM (you think editor software should follow what the wiki says, and I think we should follow actual tag usage), and we disagree on how complexity of OSM tagging should be presented to people who have never edited a map before (you want to see a field for every tag, and I think we already show too many fields).\r\n\r\n>A second, more troublesome issue is that if we mass migrated all of these\r\nlegacy keys, the values as displayed by popular editors would instantly\r\ndisappear to users. This is unacceptable, so any kind of mass change can\r\nonly come after both popular editors and some major data consumers are\r\nadjusted to support both schemes. This is a good time for iD to step up\r\nwith a solution.\r\n\r\nIf the OSM community ever did want to mass change a tag like this, I'd be totally fine with it.  Somebody (who?) would say \"Hey Bryan we are changing the tag from `phone` to `contact:phone` because good reasons.  This database change will happen on so-and-so-date during whatever-maintainance-window, can you have a new version of iD ready to support the new tag?\" and I'd say \"Sure that's like a 15 minute change, I will have iD `v2.whatever` ready for you to merge in before you bring the database back online.\"   (We did a somewhat-coordinated update like this when osm-carto changed their highway colors last year.)\r\n\r\nWhat _doesn't_ work is having someone change a wiki page and expecting data to magically change itself.  This has been known for a long time. \r\n\r\n> Sometimes I wished iD had a single big multi-line text editor box in which I could simply type all data in key=value form one tag per line and be done with it. I.e., automatically add/update tags when the user navigates away.\r\n\r\nSo fork iD and build this.  I'd be totally happy if somebody made an iD-Advanced.  Or use level0?   \r\n\r\nPlease be nice and understand that iD is not optimized for people who already know what all the tags are.  I'm happy if somebody just opens the editor and adds a few small details."}}
{"actor":{"display_login":"bhousel"}}