Make some fields readonly when matching a suggestion preset

[bhousel]

Name suggestion index presets each have a canonical brand name and some other brand tags.

We really don't want the user to edit with the name or brand:*. They should be able to delete these keys by pressing the 🗑 button, and we can still let them do whatever they want in the raw tag editor.

When we match a preset like this:

• make the name field and ➕ button readonly
• make sure the 🗑 button deletes all the keys that go along with the suggestion preset, not just the name key.
• add a tooltip so the user knows why it's disabled

[1ec5]

If a single location of a chain has a unique name, such as a Shell location named “Blue Ash Shell”, it should be possible to make the name more specific without blowing away the preset’s other tags, such as amenity=fuel and brand:wikidata. I don’t think we should discourage mappers from making these tags more specific, even at the cost of a little (legitimate) inconsistency in the database.

[bhousel]

A thing that I'm really struggling with in iD these days is: balancing the wishes of experienced mappers to do whatever they want, while preventing inexperienced mappers from messing things up 😆

What I'm really worried about is situations where that Shell station has changed to an Exxon station, and a new mapper just changes the name without changing the brand tags that go along with it. So I think locking down the name field in this situation is the better thing to do.

I really feel like features with a wikidata or brand:wikidata are special and need to be protected a bit more than the usual stuff in OpenStreetMap. And experienced users can still edit the name in the raw tag editor if they want to.

Let's it this way for a while, and if it turns out to be a terrible idea, we can change it later?

[matthewdarwin]

Sounds like we need an "expert mode".

[1ec5]

I’ve seen plenty of times when a brand-new mapper puts in a specific name for a gas station, car dealership, or supermarket in their neighborhood. The concept of a named branch location isn’t purely the domain of power-mapper POI nerds like us. 😉

It goes beyond just the name: for example, the Popeye’s fast food chain would sensibly be assigned cuisine=fried_chicken by the name suggestion index, but a significant number of locations also serve seafood. It would be frustrating to have to start from scratch when the intention is only to add detail, not remove any.

I agree that we need to avoid the situation where brand:wikidata gets out of sync with name. The concern I raised is one of usability, while the problem you’re pointing out is one of data consistency. What this situation highlights is that technically these names are really brands. There would be no problem at all with locking down the Brand field from #4999 so that it matches brand:wikidata. In the glorious future, there won’t be any downsides to putting these brand names in brand like there are today (gravitystorm/openstreetmap-carto#1874) and we can add that field to all the presets.

In the meantime, the expert mode is the raw tag editor. I was worried it was also going to get locked down, but if this change would be limited to the main fields, then at least there’s a workaround for a determined enough mapper. By the way, it would be awesome if brand:wikidata could somehow be presented as part of the Name field, pretty-printed as I described in #5500 (comment).

[bhousel]

It goes beyond just the name: for example, the Popeye’s fast food chain would sensibly be assigned cuisine=fried_chicken by the name suggestion index, but a significant number of locations also serve seafood

Oh yeah - I'm not thinking of restricting any other display field than brand/name (and multilingual names) right now.

What this situation highlights is that technically these names are really brands.

Yes - this. The user can (even today in the current iD) pick brand names in the name field. We don't show the brand field, and we probably wouldn't be able to explain to most users why it's a thing.

There would be no problem at all with locking down the Brand field from #4999 so that it matches brand:wikidata.

Thanks for the reminder - I will need to change this preset also.

In the meantime, the expert mode is the raw tag editor. I was worried it was also going to get locked down, but if this change would be limited to the main fields, then at least there’s a workaround for a determined enough mapper.

yep 👍

By the way, it would be awesome if brand:wikidata could somehow be presented as part of the Name field,

I agree, I want to make the wikidata more visible/useful, but I can't get that done in the next few days for the next iD release.

[1ec5]

we probably wouldn't be able to explain to most users why it's a thing

As an aside, maybe we would distinguish the fields as “Store Name” (name) and “Chain Name” (brand). But yeah, that’s tricky and would need to wait for gravitystorm/openstreetmap-carto#1874 anyways. (“Brand Name” could be misinterpreted to mean the marque that a third-party shop=car_repair specializes in, which I think would be incorrect.)

[bhousel]

I've been thinking about this more, and at least for some kinds of brands, the name can deviate from the brand.

e.g. I see car dealerships near me named things like "Planet Honda", "Rt 22 Honda", "Paul Miller Honda of West Caldwell".

I wonder if we should forget this readonly name idea for certain presets? or make the rule something like:

• if name is the only field shown, make it readonly
• if name and brand are both shown, make name editable, and brand readonly.

I dunno, that is kind of complicated, and I hate adding too much magic.

[1ec5]

If Brand is shown, maybe it should remain writable but editing it should automatically delete or update brand:wikidata. This is similar to how wikidata behaves when the Wikipedia field is edited. It might require adding autocompletion suggestions to the Brand field based on name-suggestion-index. I’m not sure that it would work with the Name field, though.

[bhousel]

I think I’d like a kind of thing where we put a lock 🔒 next to the locked fields with tooltip that explains why and that the user can click to unlock 🔓 the field. Maybe something for a future version.

[bhousel]

if name and brand are both shown, make name editable, and brand readonly.

I did this..