Utiliser les présélections iD

Ghost

Voir https://github.com/openstreetmap/id-tagging-schema (+ https://github.com/osmlab/name-suggestion-index/)

Lorsque vous utilisez les presets, vous gagnez:

• vous n'avez pas besoin de maintenir vous-même une liste de caractéristiques et d'icônes.
• noms de fonctionnalités localisés. Il n'est pas nécessaire de maintenir la traduction de ces éléments
• une liste de champs (par exemple, téléphone, site web, si un restaurant propose de la nourriture végétalienne, etc.
• des termes pour les caractéristiques avec lesquels on peut les trouver (par exemple, trouver shop=pet en tapant "chien").

Presque toutes les applications pour smartphones utilisent les préréglages iD d'une manière ou d'une autre (EveryDoor, StreetComplete, GoMap !!, OSM Go, ...).

Dans StreetComplete, j'utilise un sous-ensemble de ces presets, c'est-à-dire uniquement les caractéristiques et non les champs. J'utilise https://github.com/westnordost/osmfeatures pour analyser le preset.json. La recherche de caractéristiques ressemble à ceci :

osmapp le fait aussi. Voir https://github.com/zbycz/osmapp/issues/116

Related: #574

Traduit avec DeepL.com (version gratuite)

1. laem

   Merci pour ce message ! En effet, peut-être qu'il y a des liens à faire. De mon côté, j'avais jugé que la recherche par catégorie de osmapp ou osmand ou organic maps n'était pas au niveau : davantage orientée contributeur OSM que lecteur grand public.

   Un exemple : en cherchant "vêtements" sur osmapp, les suggestions de catégorie sont "magasin de vêtements de seconde main" et "boîte à don". Alors que le grand public s'attendrait plutôt à voir des boutiques de vêtements. D'autre part, cette première catégorie devrait plutôt s'appeler "friperie", or une recherche pour "friperie" donne "magasin de produits d'occasion", ce qui me semble incorrect, friperie faisant référence presque exclusivement aux vêtements, pas aux autres produits.

   D'où l'architecture de catégorie de cartes.app, pour essayer de faire une arborescence qui a du sens pour le grand public. Par contre, dans le contexte de l'i18n, c'est un sujet très pertinent.

   Autre exemple : "bus" donne comme première catégorie "voie de bus". Or, ce n'est pas une chose qu'une personne normale va chercher dans son application de cartes favorite. "métro" donne "Quai de métro" et "rail pour métro" mais pas "arrêt de métro". Je ne donne que des exemples qui marchent pas, mais certains marchent très bien bien sûr, comme "café" ou "bar".

   Par contre, il va falloir que je refasse un tour de StreetComplete pour voir comment tu as géré cela. Le schéma id me semble être une super base de travail mais définitivement très brute et à personnaliser lourdement.

   Thanks again :)

2. laem

   In other terms, I think cartes.app's categories could be seen as a superset of editorialised place categories destined to be used by the general public, but that translates (to and from) OSM key/value tags using the power of Overpass QL (e.g. AND and OR, but also "starts with" and other simple features, and maybe one day more complex features like "bars with a terrace close to a living street", but that's long term).

   One among other similar supersets. I hope we're not redoing something that exists already, but given my previous comment, I don't think it is the case.

3. Ghost

   Definitely not all iD presets are relevant for an end user map app.

   Most (or only) relevant are POIs. StreetComplete filters the results to only show POIs. So, "bicycle path" is never shown when searching for "bicycle", but e.g. " bicycle shop".

   StreetComplete maintains a hardcoded list of POIs, but it may be easier in your case to instead filter by category in iD, I think this information should be available.

   The precision and usefulness of the presets when searching for terms also hinges on how well the translation is made, e.g. which keywords are listed for a preset.

   El 24 de abril de 2025 10:23:36 CEST, Mael @.***> escribió:

   laem left a comment (cartesapp/cartes#922)

   In other terms, I think cartes.app's categories could be seen as a superset of editorialised place categories destined to be used by the general public, but that translates (to and from) OSM key/value tags using the power of Overpass QL (e.g. AND and OR, but also "starts with" and other simple features, and maybe one day more complex features like "bars with a terrace close to a living street", but that's long term).

   One among other similar supersets. I hope we're not redoing something that exists already, but given my previous comment, I don't think it is the case.

   -- Reply to this email directly or view it on GitHub: /documentation/tickets/922#issuecomment-2826773544 You are receiving this because you authored the thread.

   Message ID: @.***>

4. etienneJr

   En bossant sur #2995, je me suis dit qu'on pourrait garder notre fichier de catégories, mais, pour les catégories qui sont définies simplement par une requête key=value, aller directement chercher name, terms et aliases dans les presets ID pour construire notre dictionnaire, plutôt que le définir manuellement. Ca ne va rien apporter pour le français pour lequel on a déjà rempli notre dictionnaire. Mais ça va permettre d'avoir directement sans effort toutes les traductions dans toutes les autres langues.

   While working on #2995, I thought we could keep our categories file, but for categories defined simply by a key=value query, we could retrieve name, terms, and aliases directly from the preset IDs to build our dictionary, rather than defining it manually. This won’t make a difference for French, for which we’ve already populated our dictionary. But it will allow us to effortlessly obtain all translations in all other languages.

   Translated with DeepL.com (free version)

5. etienneJr

   @etienneJr wrote in https://codeberg.org/cartes/web/issues/922#issuecomment-23147026:

   aller directement chercher name, terms et aliases dans les presets ID

   le pb du name de iD c'est qu'il a 1 seule valeur, par exemple Magasin de chaussures, alors que nous notre name brut est <magasin(s) de >chaussures dont on extrait :

   • le nom court chaussures
   • le singulier magasin de chaussures
   • le pluriel magasins de chaussures

   donc on ne peut pas tout baser sur le schéma iD, on doit garder notre version pour gérer ces 3 versions du name.

   Même problème si on veut utiliser iD pour obtenir la traduction dans une autre langue : ça ne donnera que le singulier. C'est déjà pas mal, mais c'est à faire lors de la création initiale de la traduction des catégories, qu'on reprend manuellement ensuite. On ne peut pas générer dynamiquement locale/categories.yaml à partir du schéma iD.