Naming of street level imagery tags

[tordans]

This is extracted from #1344.

The question I have is, if we want to group the street level imagery tags by prefixing their labels with a common term.

Currently, the labels are

• Mapillary Image ID

• Panoramax Image ID

Only users that know the service or look into the info-i will know what those tags are used for.

Proposal: Something like this:

• Street level imagery: Mapillary

• Street level imagery: Panoramax

---

Any thoughts on this?

[mnalis]

Ah, so just a label change?

Makes sense to me, although I'd probably leave the "ID" part in to make it clear at glance what expected value is; i.e.

• Street level imagery: Mapillary ID
• Street level imagery: Panoramax ID

[1ec5]

Only users that know the service or look into the info-i will know what those tags are used for.

This is true of quite a few fields, such as “Wikimedia Commons Page” and “GNIS Feature ID”. Do we need to optimize the field names to keep the user from clicking the ℹ️ button? It seems like an obvious thing for them to click if they don’t know what the field is for.

If we do need to qualify the service name somehow, can this disambiguator be a suffix instead of a prefix, such as “[Provider] Street-Level Image ID” or “[Provider] ID (Street-Level Image)”?

As a prefix, it risks crowding out the most important information, depending on the sidebar width and language. (The sidebar can get even narrower than in these screenshots.)

The question I have is, if we want to group the street level imagery tags by prefixing their labels with a common term.

I assume these keys will normally be added automatically rather than manually; a user wouldn’t likely go through the “Add fields” dropdown seeking to add each one of the street-level imagery ID fields. On the other hand, if they’re looking for just one in particular, suffixes shouldn’t be a problem, since the combo box matches the input against any part of the field’s name, not just the beginning:

[tordans]

Very good point @1ec5 – given those issues I don't thing this approach will work.

One advantage of the prefix would be that the fields are grouped in the fields UI in iD (right?).
Maybe we can use some Shorthand to group them?

• 📸 Mapillary Image ID
• 📸 Panoramax Image ID
• 📸 Wikimedia Image

(mapillary, panoramax, wikimedia_commons)

That would be the first time we use images in this context, though…

[1ec5]

The 📸 emoji would force the fields to appear adjacent to each other, since iD currently sorts the fields alphabetically by name. We would need to make the prefix untranslatable.

Honestly I find it hard to care one way or another about these fields, since I don’t see myself editing them by hand. There are more prominent groups of related fields, such as the ones cross-referencing #2050, or the name variant fields added in openstreetmap/iD#215. If grouping is desirable, we could instead add a special case to the existing sorting code:

https://github.com/openstreetmap/iD/blob/51ee85f6f53dc1c903cb14b846699ac1ff14fcc2/modules/ui/sections/preset_fields.js#L88-L90

By the way, “Wikimedia Image” would be misleading because the wikimedia_commons=* key can accept the name of a non-image file such as a video, or a category or gallery, or even a GeoJSON file. I just brought up Commons as an example of another external site that the user might not be familiar with.

[tordans]

Agreed. Lets resolve this as part of #2050 and/or #1202

I will close this here since I don't see a quick win here and what we have works well enough for now.