Relations route=bus et valeurs proposés par l'éditeur iD

Bonjour à tous,

Dans mon combat pour maintenir quelques réseaux de bus je rencontre souvent des modifications réalisées avec iD.
Sur ce changeset Changeset: 141427977 | OpenStreetMap la réponse est bien étayée et propose de débattre de la mise à jour du wiki Key:network - OpenStreetMap Wiki . C’est pourquoi j’ouvre ce sujet.

Marc
PS : si quelqu’un peut indiquer où modifier le github d’Id qui propose STAR au lieu de FR:STAR …

Les valeurs proposées viennent probablement du Name Suggestion Index, dont on a parlé récemment ici: network=VélO² à Lyon

J’ai posté une petite explication comment changer les valeurs NSI sur Github. Il faut chercher sur NSI dans la catégorie « Transit ».

Dans ce cas il s’agit sans doute du fichier bus.json puisqu’il s’agit de relation de bus.

Je peux modifier la valeur si vous le souhaitez.
Mais est-ce vraiment "exact de qualifier le réseau STAR de Rennes comme « FR:STAR ». Avec l’attribut wikidata, on peut désormais référencer 2 réseaux ayant le même nom.
Je ne me permettrai pas de trancher sur cette problématique et je préfère les « locaux » exprimer leur avis sur cette question

L’attribut wikidata peut ne pas être unique sur un réseau. À Rennes, sur le réseau STAR, on a un attribut wikidata par ligne de métro.
J’ai l’impression qu’osmose ne contrôle pas cet attribut (présence et identique entre relations route et route_master).

Pour NSI, pour éviter une guerre d’édition, est-il possible de juste désactiver les suggestions ?

Plutôt que l’attribut wikidata, je pense qu’il serait préférable comme sur certains réseaux d’utiliser network:wikidata.

Oui, tu as un idenifiant wikidata pour le métro a (Q24641190), un pour le métro b (Q24641690) et un pour le réseau STAR (Q3480422).
Pour les lignes de métro, tu n’as donc pas de conflit avec l’usage de network:wikidata et wikidata

C’est déjà le cas sur NSI :

      "displayName": "STAR",
      "id": "star-add5eb",
      "locationSet": {"include": ["fx"]},
      "matchNames": ["fr:star"],
      "tags": {
        "network": "STAR",
        "network:wikidata": "Q3480422",
        "route": "bus"
      }

Comme il y a aussi un réseau STAR à Roanne : Service des transports de l'agglomération roannaise — Wikipédia
FR:STAR, ne suffit pas. Il faudrait du FR:35:STAR ou FR:Bretagne:STAR

ou on accepte que le network= soit bien le nom du réseau comme la plupart des autres réseaux de transport en commun et ne soit pas obligatoirement unique. (d’ailleurs les identifiants uniques c’est plutôt des tags ref= ou ref:*=)

Et le réseau de Roanne a bénéficié de l’attribut network:wikidata du réseau de Rennes cf Relation: ‪Ligne 2 : Mably - Tuileries -> ZAC Perreux‬ (‪13046711‬) | OpenStreetMap

Effectivement, rien n’indique que l’attribut network doit être un identifiant dans le schéma PTv2 et rien n’est prévu pour le nom du réseau (dans un attribut name:network ?). Les deux sont utiles et l’absence de relation chapeau type associatedStreet oblige à jongler pour retrouver les relations route et route_master d’un réseau.

Pour l’histoire des 2 réseaux STAR en France Métropolitaine, je pense avoir trouvé le moyen pour que iD propose la complétude uniquement sur Rennes Métropole et non plus sur Roanne. Cela permettra de ne plus proposer cette complétude.
Qu’en pensez-vous ?

    "displayName": "STAR",
      "id": "star-add5eb",
      "locationSet": { include: [[-1.7114, 48.1082, 30]] },
      "matchNames": ["fr:star"],
      "tags": {
        "network": "STAR",
        "network:wikidata": "Q3480422",
        "route": "bus"
      }

Au niveau du include, voici ce que cela donnerait comme périmètre => Location Conflation

oui, c’est sans doute le plus simple, plutôt que de chercher une astuce sur le network (qui est de toute façon bien précisé par le network:wikidata).
Est-ce que le network STAR de Roanne est aussi présent dans le NSI? ça peut être l’occasion de l’ajouter avec le même principe de réduction du zonage

Il n’y a pas Roanne dans NSI mais je peux en profiter pour l’ajouter. J’ai trouvé son wikidata.
Edit : Tout a été ajouté sur NSI, le code a été accepté par les administrateurs. Je vérifie dans une semaine si tout est OK

1 Like

Je ne comprends pas tout au NSI:

    {
      "displayName": "STAR (Rennes)",
      "id": "star-7ed087",
      "locationSet": {
        "include": [[-1.7114, 48.1082, 30]]
      },
      "tags": {
        "network": "STAR",
        "network:wikidata": "Q3480422",
        "route": "bus"
      }
    },
    {
      "displayName": "STAR (Roanne)",
      "id": "star-81dad7",
      "locationSet": {
        "include": [[3.9742, 46.0851, 30]]
      },
      "tags": {
        "network": "STAR",
        "network:wikidata": "Q3488202",
        "route": "bus"
      }
    },

    {
      "displayName": "FR:STAR",
      "id": "frstar-a45453",
      "locationSet": {"include": ["001"]},
      "tags": {
        "network": "FR:STAR",
        "route": "bus"
      }
    },

mais le STAR (Rennes) avec « network »: « STAR » va me permettre de continuer à utiliser l’overpass et level0 plus un petit coup d’osmose

Peux-tu me dire ce que tu ne comprends pas sur NSI. Ce que j’ai fait dans les code NSI :

  • Afficher uniquement le réseau STAR de Rennes au niveau de la métropole de Rennes (centroide + 30km de rayon)
  • Afficher uniquement le réseau STAR de Roanne utilisant le même principe qu’à Rennes

Il se trouve que le code NSI a été packagé hier dans la foulée et j’ai réalisé différents tests sur iD et ca fonctionne bien dans les 2 régions.
Je ferai un travail de nettoyage lundi du mauvais wikidata sur Roanne et également outre-atlantique.

Remarque : A la place d’utiliser les coordonnées avec un rayon, j’aurai pu me calquer sur les régions françaises, bon à savoir pour les réseaux régionaux/départementaux