Generalize iD

[quincylvania]

Currently, iD is designed for mapping OpenStreetMap data exclusively. This severely limits the downstream use cases of the project.

We should make iD a general-purpose GeoJSON editor with an extensive plugin interface. Developers could then customize every part of iD without even needing to fork it. The OpenStreetMap plugin would be the flagship plugin and could live in a separate repo. That way, things like presets and tag deprecations could be hashed out separately from the iD core.

From the perspective of a user editing on osm.org, this change would make no difference.

Some of the components that require generalizing:

• User authentication
• Data sources
• Geometry primitives
• Presets
• Map styling
• Validation rules

[bhousel]

The OpenStreetMap plugin would be the flagship plugin and could live in a separate repo.

Actually I'd prefer for everything substantial to move out of this repo into a new one, and this repo under the openstreetmap organization could just be where the plugin lives.

[manfredbrandl]

How would translations in Transifex become organized with this change?

[quincylvania]

@manfredbrandl Most likely the core iD strings and the OpenStreetMap-specific strings would be separated out. The iD strings would remain on transifex while the OSM strings could become a separate transifex project or use another translation platform like the wikibase.

[matkoniecz]

Would this generic editor use name of OSM editor or is there a plan to create a new name?

[BjornRasmussen]

It would just be "iD", right?

[quincylvania]

Would this generic editor use name of OSM editor or is there a plan to create a new name?

@matkoniecz I haven't thought much about the names. I think the core would be "iD" and then plugin could be "iD for OpenStreetMap" or something.

[gmaclennan]

This would be really useful for us. We currently maintain a fork for integration with our offline map editor, Mapeo. Generalizing iD and splitting into separate modules would make customization much easier to maintain. The key would be well-designed APIs for each module which remain as stable as possible. We would love to help out, although we have no one on our team at the moment who is very familiar with the iD codebase.

[westnordost]

I really like the idea of splitting up the core application from presets and other the metadata into separate repositories. Looking forward to it. Just to add my 5 cents, here are the advantages I see:

• The presets in particular could be more easily reused by other OpenStreetMap-based projects, more easily forked to add support for specialized presets or remove controversial ones. Thus, it's a step towards unifying the tagging presets in the OpenStreetMap-ecosystem and opens up the possibility to include more data that may not be useful for OpenStreetMap-editors but for other use-cases.*
• The crowd-sourced translation of presets could be made easier when it is separate from the core app because the possibility arises to move away from Transifex to another or maybe even a custom-made solution. (In Transifex, the context is often missing as the strings for each preset are not grouped together and no context is supplied)
• The Git History is cleaner, for all of these repositories.

---

* for example:

• In an end-user map-app like Maps.Me or Osmand, denominate map features (without names) correctly
• "Ok Google, take me to the closest recycling container with openstreetmap"
• Show all computer stores in my vicinity on the map

[bhousel]

I really like the idea of splitting up the core application from presets and other the metadata into separate repositories.

Yes, we will still do this as part of modularization. The presets that we bundle now are too big and it would be better to have smaller preset packs for users to add on depending on whatever their needs are.

(As an aside, I think the suggestion to build a "custom made solution" to replace what we get from Transifex would be a mistake. There is a ton of work that has been done to translate all of the presets, and it would be great to try to retain that.)

For completeness, here are the criticisms we got the last time we offered to split out the iD presets in 2015.
osmlab/editor-presets#1
osmlab/editor-presets#2
#2656 (closed in 2018 w my reasons why)

My take on this is that other downstream projects are either already consuming the presets directly from iD (so having them in the iD repository isn't really a blocker) or are not interested in them anyway (JOSM). It helps us to have them more tightly coupled with iD so we can change things about them sometimes (stuff like #6124 is a good example).

[1ec5]

Would there be any demand for a separate NPM package for the presets that is still developed in the iD repository, monorepo-style?