Preset field inheritance

[quincylvania]

Closes #5710.

The biggest user-facing implication of this change is that, by default, specified presets will retain the generic fields that define them. So the shop field will be present on essentially all shop features. I actually don't mind this behavior. It let's users quickly fix mistagged or accidentally-tagged features (see #5611), and more clearly indicates how the tagging/preset system works. If we do go this route I think it'd be wise to rename fields named Type with more specific labels.

Todo

• Update the documentation

[bhousel]

Hmm, can we resolve these in preset.init() instead of at build time? I imagine that people who are replacing them with a custom set of presets would want to use this feature too..

[quincylvania]

Hmm, can we resolve these in preset.init() instead of at build time? I imagine that people who are replacing them with a custom set of presets would want to use this feature too..

Oh that's a good idea, thanks! Let me know if anything else about this needs work.

[quincylvania]

@bhousel This should be ready to merge. The data changes are fairly large though so it'd be nice to get your thoughts.

[bhousel]

The biggest user-facing implication of this change is that, by default, specified presets will retain the generic fields that define them. So the shop field will be present on essentially all shop features. I actually don't mind this behavior.

Hmm I kind of don't like this part, but mainly because the tags themselves are arbitrary and messy and we can't easily translate them. In the example shown above, showing "Shop Type" of doityourself would be confusing to both non-English and English speakers. I'm imagining that people who don't know any better might try to replace that with "do it yourself", thinking that they are helping.

I see the main purpose of iD's preset system as: hiding the ugliness of OSM tagging from most users.

I really like the idea of preset field inheritance though! It would make a lot of the preset definitions much simpler.

You said in #5710:

An alternative solution would be to allow targeting a specific preset, but I think "parent" inheritance fits most cases.

I wanted to think about this a bit before responding, and I really like this idea of targeting a specific preset a bit better than the {inherit} keyword. The reason is because of how arbitrary OSM tags are. We want to inherit the "building like" fields (address, opening hours) for shop=* but also lots of amenity=*, tourism=*, leisure=*..

I don't see OSM tagging as having a clear inheritance where, e.g. all the amenities get some fields and all the leisure ones get different fields. It's all mixed up.

Would you be ok with - instead of {inherit} - allowing a preset id to appear in there?
The preset ids are automatically generated from the file path and name, so for example, all vending machines could inherit fields from {amenity/vending}.

[quincylvania]

@bhousel Thanks for the feedback!

I definitely see your point about the messy tags, I'll try to come up with a fix. I think eventually we'll need to figure out a way to give translatable labels to the common values of combo fields without limiting them to a predetermined list. As you said, doityourself is confusing but a user could still encounter that option in the shop field before this change.

Would you be ok with - instead of {inherit} - allowing a preset id to appear in there?
The preset ids are automatically generated from the file path and name, so for example, all vending machines could inherit fields from {amenity/vending}

For some reason I thought this would be difficult or confusing but now that you write it out it looks really cool and more obvious. Allowing the same preset to inherit from multiple others would be pretty powerful. I'll look into this more.

[quincylvania]

@bhousel Like you suggested, I changed it so specific presets must be targeted instead of {inherit}. This can work with multiple targets.

I kept it so the parent preset's fields are still used if the field properties are omitted. I think this behavior is helpful for quickly adding new presets and it can easily be overridden.

I'm not sure what the best method is for ignoring the "Type" fields of target presets. I might strip the target's fields that map to the tags defining the source preset, but I'm not sure that's desirable in all cases.

[quincylvania]

I'm not sure what the best method is for ignoring the "Type" fields of target presets. I might strip the target's fields that map to the tags defining the source preset, but I'm not sure that's desirable in all cases.

I ended up doing this. I'd consider changing it back once we can figure out translatable labels for common combo field values. It's not exactly intuitive that some fields are inherited but not all. For now I think it works alright. This PR is ready to merge on my end.

[bhousel]

Looks great! OK to merge 👍