Move presets / data into a separate repository

[gmaclennan]

It is hard to track code changes between all the changes and issues around presets.

Keeping the data folder as a separate repository would also make it easier for those of us using iD with custom presets, and in general keep the issues cleaner for each.

[jgpacker]

I believe it is possible to create a separate repository and add it as a git submodule to this one, while preserving those files's history (using some of gits history-rewriting commands). Though I'm not sure how we could migrate the related Github issues to the new presets repository.

It should also be verified if the presets are cleanly separated in different directories, because otherwise we would need to refactor current code to accomodate this change (and that could be a deal-breaker unless it was a really trivial change).

[bhousel]

It should also be verified if the presets are cleanly separated in different directories

Yes the presets are cleanly isolated under data/presets. It would be very easy to just remove all the preset files and build script into another repository, and that's basically what I'm proposing here: osmlab/editor-presets#2

[bhousel]

Bumping the priority of this issue. As soon as reasonably possible, I will:

• move OSM presets to separate repository
• create a separate similar repository for HOT presets

HOT really needs their own presets because:

• HOT uses a far more limited preset subset than OSM does
• HOT is more tag-focused, so we shouldn't try to hide, simplify, or localize, unfortunately named OSM tags (like unclassified and track)
• Any little changes we make on the OSM side shouldn't invalidate all of the HOT training materials

This also helps me out because now quibbles about proper tagging can be moved elsewhere.

[gmaclennan]

I created a separate module for building presets, which expects data in the same structure as data/presets: https://github.com/digidem/id-presets-builder

We use this for building custom presets for different deployments. Hopefully this can be useful for others working with custom presets and also be used when OSM presets move to a separate repository.

Differences from the iD build.js

Most of the code is pulled from build.js with the following differences:

• Everything is async, which speeds things up a bit.
• Additional schema checks for defaults.json and category files - it may be useful to pull this into build.js.
• Additional checks that any categories or presets in defaults.json actually exist.
• Builds a single presets.json with properties presets, categories, fields, defaults, rather than creating separate files presets.json, categories.json and fields.json.
• Does not include names-suggestions (PR welcome - needs a way to choose between OSM suggestions and a custom file).
• Does not build taginfo data since that is specific to iD Editor.

@kriscarle @jimmyrocks @mojodna

[gmaclennan]

I realize I stuck a MIT license on this by default, happy to license it as whatever, as needed.

[bhousel]

I've changed my thinking on this.. read more here

tl;dr:

Usability and speed of development are very important to me, and these are things that would suffer if I split the presets off into a separate project.

Let's leave the presets in iD for now, but make it easier for users to replace them with #5049