#20995 closed enhancement (wontfix)
Why are presets not unified across editors?
Reported by: | roqimas | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Internal preset | Version: | latest |
Keywords: | preset standardization; preset unification; presets | Cc: |
Description (last modified by ) ¶
So, this is less of an issue with JOSM specifically, but something that JOSM IMO should consider.
OSM Wiki notes "Presets have not been standardized across editors"(https://wiki.openstreetmap.org/wiki/Preset). It seems a first attempt at doing this was considered some years ago (https://github.com/osmlab/editor-presets), but nothing ever came of it.
My question is: Why not?
There are a ton of obvious benefits to having unified presets. Data quality of OSM, ease of use for editors, communicability of editing practices, accuracy of rendering by editors would all increase massively if presets (and therefore tagging schemes) were standardized more. The wiki, in integrating that standard preset scheme, could offer even better documentation of those tagging schemes. Changes in tagging could easily propagate across geography and time, past tagging could be understood better as a result of previous unified standards, editing and adding data would be simplified considerably and the barrier of entry for new editors (and editor solutions) would be lowered as well.
Why haven't there been more attempts at integrating the presets JOSM, Potlach, iD and other editing solutions use? We see some convergence; StreetComplete uses iD's presets, Vespucci uses JOSM's. But still, a (IMO highly unnecessary) rift remains, only getting worse with time as more editors, editing solutions and tagging discrepancies emerge.
iD issue: https://github.com/openstreetmap/iD/issues/8537
Vespucci issue: https://github.com/MarcusWolschon/osmeditor4android/issues/1412
Change History (8)
comment:1 by , 4 years ago
comment:2 by , 4 years ago
Description: | modified (diff) |
---|
comment:3 by , 4 years ago
Description: | modified (diff) |
---|
comment:4 by , 4 years ago
Description: | modified (diff) |
---|
comment:5 by , 4 years ago
Milestone: | Longterm |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
One reason is because all the developers know that their own solution is better than that of the others (see the first comment in iD ticket). So instead of any attempt to reuse existing solutions they develop something new. Most even don't really understand the other formats like the JSON<->XML comment in iD ticket shows.
I tried to reach unification several times (with maps, styles and presets) and we adapted our format to overcome the issues voiced in each of these tries. Still the result was no progress. So I gave up - it's not worth the effort.
Beside that, the impact you describe isn't that big. All major editor presets cover the important tagging presets and they are extremely stable. Changes are included following the policy that any news first need to mature before officially supported. For JOSM ways for extensions also exists.
As the editors are different there always would be differences in presentation, layout and so on. Also the scopes of the editors are different, which also makes reusing hard.
Altogether:
- Less benefits than you expect
- Editors would loose a major design influence
- It simply doesn't work for multiple reasons
follow-ups: 7 8 comment:6 by , 4 years ago
Doesn't this present a substantial challenge to interpreting the data, though? If tagging isn't uniform, data quality suffers and renderers, researchers, routers, etc., either can't interpret the data as well or have to spend significant time to understand different tagging schemes for the same thing.
comment:7 by , 4 years ago
Editor software should not populate controversial tags or even create new ones.
Replying to stoecker:
Changes are included following the policy that any news first need to mature before officially supported.
Sorry, but iD does not follow this policy, see #19982.
Replying to anonymous:
Doesn't this present a substantial challenge to interpreting the data, though?
Sure. Would you please ask the iD maintainers why they introduce new tags with low numbers of use which are not approved and controversial. Please, link to their answer. Thanks
comment:8 by , 4 years ago
Replying to anonym:
Doesn't this present a substantial challenge to interpreting the data, though?
A challenge: yes. Substantial: No.
A said the majority of tagging is handled in a similar way. Differences occur for finer details or new methods. Here the non-uniformity has benefits and drawbacks. Essentially it's a bit evolutionary which I consider a good thing.
Related issue on iD side: https://github.com/openstreetmap/iD/issues/8537