Thanks for starting this topic and attempting to center it around constructive feedback. It’s so easy but ultimately unnecessary to divide the OSM community into rival camps based on preferred workflows. I hope it’s clear by now that, even though iD and JOSM are optimized for a certain level of expertise, one isn’t necessarily a “good” or “bad” mapper for using one or another. Editors are just tools; try them all out and use the one that suits your tastes and that you can become the most effective with.
Personally, after over 15 years of mapping, I’ve still found iD or Rapid adequate for virtually all of my needs, but that’s partly because of what I like to map and how: I’m a generalist who often spends an afternoon roaming around a neighborhood, mapping such an assortment of features that I’d never be able to keep the raw tags straight in my head. On the other hand, a mapper who specializes in mapping something inherently complex in OSM, such as route relations, might find it better to learn a very specific workflow in JOSM and hope it never changes.
Lately, as I’ve been working on large-scale boundary edits in OpenHistoricalMap, I’ve resorted to increasingly elaborate workarounds in iD and ultimately had to migrate to JOSM almost full-time. As a software developer, I certainly am capable of learning how to use JOSM, but this doesn’t keep me from feeling like a fish out of water.
Some of the iD limitations you cited aren’t inherent to a Web application, but they aren’t arbitrary limitations either. For example, it probably would be feasible for an iD “expert mode” to support manipulating a selected feature at any zoom level, if not for the fact that iD automatically loads a full copy of everything in the viewport. If it could support sparse downloads (e.g., based on Overpass API queries or just element IDs on demand), then suddenly there isn’t as much of an issue with editing while zoomed out.
Of course, there are plenty of other considerations besides performance. You can imagine what would happen if iD were to make it easy to delete all the members of an international boundary relation at once. Novices and experts can both benefit from a degree of safety. Maybe my stubborn use of iD keeps me from getting in over my head with large mechanical edits or imports of datasets I didn’t fully understand, or accidentally offsetting an entire city by a quarter mile, as I once witnessed at a mapathon. (I did have to bust out JOSM in order to revert that!)
JOSM’s trust-the-user approach bombards you with alerts. These are often very good warnings to heed, but other times it’s just noise. The alert about dragging nodes too far can get annoying, but it has also saved me from accidentally moving the whole boundary instead of just a node – one of the knock-on consequences of binding right-click-drag to panning the map.
To respond to one of these alerts, you have to know what you’re doing, but that requires learning from mistakes, since our documentation is imperfect and incomplete. As much as we like to rag on iD for scrambling relations, I just as often see JOSM users – including paid professional mappers – break multiple relations at once by splitting a way after a sparse Overpass download. If someone has scolded you for this mistake before, you’ll know to download the surrounding area before splitting and heed the validator warning about modifying an incomplete relation. And if you don’t, some would consider it your fault for misusing the editor. Paradoxically, an editor that tries to be safer cannot escape the finger-pointing.
Design philosophy aside, neither editor is perfect. Both have feature areas that are undeveloped, to put it kindly. I probably could come up with a more specific list of paper cuts, as well as a list of things I really like about JOSM (selection history!), but I think the differing approaches to safety largely account for the different “vibes” I get using both editors. Anyways, as far as I’m concerned, literally no editor can ever beat Potlatch 1: its visual undelete mode was based on OSM API functionality that has since been removed.
