describe the "aliases" property in the readme

[tyrasd]

See #3. This feature is currently not described in the project Readme.

[tyrasd]

Reopening, since the current description on the readme is still unsatisfactory.

Some resources with background for this:

• Presets: Separate terms into synonyms and keywords openstreetmap/iD#6139
• Add preset aliases property [WIP, Feedback required] openstreetmap/iD#6412
• Separate synonyms from search terms #3

[westnordost]

The most conservative approach would be to use aliases only for proper synonyms (here: land access road and track road). Whether it makes sense to also include names which describe a strict subset of features represented by the preset can be discussed IMO (here for example: forest track, agricultural road, etc.). I would abstain from including terms as aliases which can cover features not represented by the preset (here: dirt road, unmaintained road).

This sounds reasonable. Both "Feldweg" and "Waldweg" should be an alias for "Feld-/Waldweg" as all "Feldweg"s and all "Waldweg"s are "Feld-/Waldweg"s (duh!). Trying to find an alias that 100% reflects "Feld-/Waldweg" and is not just a subset of it kind of defeats the possible usefulness of alias a bit, because there are not really any.

Though, it should be a strict subset of features represented by the preset that are not represented by a sub-preset. E.g. "wheelbender" can be an alias for amenity=bicycle_parking but only if there is not a preset explicitly for amenity=bicycle_parking + bicycle_parking=wall_loops. If there is, "wheelbender" must be an alias for that preset instead.

However, the caveat to allow subsets is that if a sub-preset is created for a preset (like e.g. for bicycle parkings), some of the previously added aliases of the parent preset must be removed too (also from translations) which means it is more work.

In the end, above all, the meaning and usefulness of alias and thus its exact definition will probably only dawn the translators on transifex if they know where and how it displays. Hence, the alias as matched should ideally appear in the search result list, e.g. as a sub-title of the matched preset (see #6139).

[tyrasd]

[…] not represented by a sub-preset
if a sub-preset is created for a preset […] some of the previously added aliases of the parent preset must be removed too

Good point. A thing we could implement here (in addition to showing the alias in the list of search results, which is a great idea, btw) is to add an automated check which produces a warning when there exist any duplicate names or aliases between a preset and their sub-presets.

[Hufkratzer]

(in addition to showing the alias in the list of search results, which is a great idea, btw)

This is a long list of aliases in some cases (example), especially if you merge the aliases from diffrerent dialects. Maybe you better only show them if one clicks on the i, together with the description from the data item.

[tyrasd]

Sorry, I was a bit imprecise. I meant to only show the (single) alias which matches the user's search input (and only if the preset name doesn't match the search input). Very similar to how it is shown in the mock-up on openstreetmap/iD#6139 (comment)

[tyrasd]

[…] also include names which describe a strict subset of features represented by the preset

I'm tending towards only accept "real synonyms" as aliases. Apart from the already mentioned additional maintenance work of checking for potential duplicates in future sub-presets, there also exists the following additional issue if we allowed "subset names" which I find to be quite critical: When a search for a "subset name" matches a preset and the UI displays the sub-name alongside the preset's primary name, it can potentially give the impression to the mapper that the selected preset already fully describes the sub-preset they were thinking about.

For example, assume we included "Oil Refinery" as an alias to the "Factory" preset. When a user searches for "oil factory", and iD would show the "Factory" preset (potentially displaying both names in the search result, for example like this: Factory - Oil Refinery), this could leave the impression that the selected preset already properly describes the OSM feature as a oil refinery, while it would only have got the tags for the generic factory preset.

It would be very hard to convey in the user interface that some aliases are actual synonyms and others are special cases of what a preset can be used for. And that for the latter one should described the feature in more detail using the preset's fields or additional tags.

I would say is that in many cases where one would be tempted to add a "subset name" to a preset as an alias, it is rather an indicator towards that a sub-preset is missing. For the cases where adding a sub-presets is impossible (e.g. because there are no tags to describe the sub-feature accurately), I think it is sufficient to continue to include these names as simple search terms.

[westnordost]

Hmm, the oil refinery / gold mine example seems to be a bit far fetched. You mean as alias for landuse=industrial or what exactly? A better example here would be "factory grounds" as an alias for "industrial landuse". Not all industrial landuse are factory grounds, but the other way round. If strict subsets are not allowed, "factory grounds" would not be OK for an alias.

If no (strict) subset is allowed, e.g. the following wouldn't be possible as alias (looking a bit through German translation):

• Feldweg for highway=track (because tag tag is used for more than just Feldweg)
• Kindergarten for amenity=kindergarten (because the tag is used for Kindertagesstätte = all Kindergarten (2y-6y)+ all Kinderkrippe (0y-2y) AFAIK) - even though this is the primary name right now

I would say is that in many cases where one would be tempted to add a "subset name" to a preset as an alias, it is rather an indicator towards that a sub-preset is missing.

Not necessarily. You know, it is possible to get ever more detailed about the (slightest nuances) in kind of places. Probably no synonym/alias is 100% a synonym, you'll always find that each word carries a slightly different nuance. That doesn't mean that this nuance must always be recorded and that it doesn't fit into the same box (=the same tag).

[westnordost]

But in any case, no work is lost and it is not an irreversible decision if you define aliases in a more strict sense because terms not strictly aliases will just remain in terms.