search

ideditor / schema-builder

🏗🏷 Create tagging schemas for iD
ISC License
13 stars 16 forks source link

describe the "aliases" property in the readme #28

Closed tyrasd closed 2 years ago

tyrasd commented 2 years ago

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

tyrasd commented 2 years ago

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

Some resources with background for this:

westnordost commented 2 years ago

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 commented 2 years ago

[…] 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 commented 2 years ago

(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 commented 2 years ago

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 https://github.com/openstreetmap/iD/issues/6139#issuecomment-481284610

tyrasd commented 2 years ago

[…] 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 commented 2 years ago

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):

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 commented 2 years ago

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.