Experiment: override tree type presets

[bhousel]

This week I've been working with @tordans on adding some improved icons for various tree types, see:

rapideditor/temaki#87
openstreetmap/id-tagging-schema#1035

I think it would be fun for Rapid to support these, especially as we are starting to see open tree datasets like the Esri Community Trees appear as Esri datasets that Rapid users can access..

There are some basic tree presets in the id-tagging-schema repo, but we could override these presets to support for a wider variety of tree types, including palms and cacti.

Our PresetSystem is supposed to support merging in custom presets that override the defaults, but we have never actually tested this! So I think this thing with the trees could be a good way to see whether the code works and test out the idea of custom presets for some kinds of data.

[tordans]

TBH I am very concerned whenever I read the term "override". I think we need to work hard to not increase the fragmentation of tooling. If not for anything else, than to keep the complexity of the whole system manageable. I would very much prefer if we bundled our energy to get great presets in the central tagging-schema repo and use them in all the consumer apps (which are many, nowadays, especially the mobile editors).

[bhousel]

I would very much prefer if we bundled our energy to get great presets in the central tagging-schema repo and use them in all the consumer apps

Supporting custom presets in editors is feature that has been around for a while in iD and JOSM, and a regular request for dedicated mapping teams. We have the code to do it in iD and Rapid, but I don't think anyone (aside from the name-suggestion-index presets) has ever really tried it out.

I don't see an experiment replacing 4 tree presets with ones with nicer icons as competing with the official presets in the tagging-schema repo or increasing fragmentation of tooling.

[tordans]

We have the code to do it in iD and Rapid, but I don't think anyone (aside from the name-suggestion-index presets) has ever really tried it out.

I agree, that is interesting to explore. And I am also pretty sure it is not used apart from the very basic HOT (and MapComplete?) UseCase to use preset=<presetnames> in the URL.

I played around with it a few times but without much luck getting it working (which might be me knowing too litte JS at that time … or maybe those features where never used much and not really working – I never found out).

One part that was broken was the URL api with presets=file.json but I now see you removed that in 2020. And then I tried using the API that is called on Rapid.* (this or that) to build a prototype of what is now the id-tagging-schema-preview but did not get very far with it either.

Having great preset-configurations is on my list of things that would make iD/Rapid configurable enough to be used as a single purpose editor (as in "specialized for one mapping topic, like parking lanes).