[OSM-talk-fr] Changement de nom réseau / opérateurs suite changement de type de regroupement de communes

Dim 7 Aou 18:55:01 UTC 2016

Les ref:Qnnnn ne servent à rien: on a une clé standard pour ça:
wikidata=Qnnn
Mais cela revient à supposer que Wikidata est une référence alors que
Wikidata a lui-même besoin de référence (et n'est pas forcément plus à jour
qu'OSM et demande une mise à jour séparée, par des outils séparés, un
compte utilisateur séparé, une adminsitration de site séparée.

Notez que Wikdiata n'est pas non plus exempt d'erreurs. Bref au lie ude
faire du contrôle qualité sur une base de données, on se retrouve à la
faire sur une autre base de données (où la persistence des Qnnnn n'est pas
non plus garantie du tout: à tout moment un Qnnn peut aussi être supprimé
par la création d'un objte homonyme puis une fusion qui préservera une des
deux références mais pas toujours celle qu'on croyait (ceci dit, Wikidata
préfère ne pas supprimer un Qnnnn pour créer plutôt une redirection, mais
rediriger un élément Wikidata sur un autre n'est franchement pas facile à
faire et demande des droits très pariticuliers, et c'est encore
passablement compliqué par le nombre d'opérations et de pages spéciales à
utiliser).

Je veux bien qu'on utilise Wikidata pour collecter d'autres données sur les
réseaux de transport mais dans OSM ces réseaux ont une vocation
géographique certaine et une logique en terme de routage/calcule
d'itinériaires. On est dans le coeur d'OSM plus que dans Wikidata qui
s'intéresse à des tas d'autres choses non géographiques (élections,
politiques, liste des élus, histoire, économie, personnalités, divers
éléments économiques et culturels plsu ou moins locaux,
jumelages/partenariats, évènements d'actualité, entreprises et marques...).

Pour OSM on a besoin de repreésenter le monde dans son état actuel et le
plus à jour possible. Je pense qu'OSM devrait plutôt être la référence
externe dans Wikidata de tout ce qui est géographique (mais OSM n'est pas
la seule source possible non plus évidemment) en tant "qu'agrégateur" de
sources géographiques.

Et puis ce n'est pas très grave si une clé ref=* mentionne une valeur
abrégée qui ne correspond plus au nom actuel de l'entitité: on ne
représente pas réellement dans OSM cette entité elle-même, c'est une valeur
*codée*. Le but est seulement d'avoir un identifiant unique raisonnable et
identifiable de ce réseau quand il a une structure homogène ou intégrée (et
peu importe alors les spécificités locales de ce réseau qui comprend
presque toujours des éléments partagés avec d'autres réseaux de transports
publics ou privés sur certaines lignes coexploitées ou partiellement
subventionnées sur une partie de leur parcours ou pour certains horaires
seulement). Ces réseaux sont pourtant existant en martière de
planification, ils peuvent changer un peu chaque année, selon les budgets
des collectivités et selon les appels d'offre et fins de marchés publics en
cas de nouvel appel à la concurrence, en utilisant divers moeysn
disponibles, privés ou publics, commerciaux ou associatifs sous contrat.

Dans ce but il faut juste que les valeurs de clés soient réellement
uniques, ne génèrent pas de conflits inattendus, facilement orthographiés
pour pouvoir les rendre homogènes.

Personnellement le moyen d'y parvenir (avec le moins d'efforts pour la
maintenance et les recherches nécessaires), c'est d'utiliser les relations
d'OSM (sachant que certains lignes ou tronçons de lignes peuvent faire
partie de plusieurs réseaux simultanément, comme par exemple la ligne RER A
du Francilien/SNCF et de la RATP, ou nombre de lignes de bus
"départementales" dont les sections urbaines font aussi très souvent partie
des réseaux de transports communautaires, les bus ayant alors une double
numérotation, voire trois numéros si on ajoute le numéro de ligne de
l'exploitant comme à la SNCF qui donne des numéros uniques non pas ligne
par ligne mais horaire par horaire quand les parcours et arrêts peuvent
changer selon l'heure).

Le 7 août 2016 à 13:31, <osm.sanspourriel at spamgourmet.com> a écrit :

>
>
> Le 07/08/2016 à 10:42, lenny.libre - lenny.libre at orange.fr a écrit :
>
> Le 06/08/2016 à 14:33, osm.sanspourriel at spamgourmet.com a écrit :
>
> Sur https://www.wikidata.org/wiki/Q1117116 les noms hormis en français et
> occitan sont toujours basés sur la CUB.
>
> si on avait les ref:Q1117116 on n'aurait pas à les changer mais il faut
> adapter les outils. Car un tel code est sujet à typo et côté ergonomie
> homme-machine on a vu mieux.
>
> Je n'avais pas compris grand-chose dans la précédente discussion ...
> est-ce un tag a ajouter (lequel) ou une modification de josm, ID, ... ou
> doit-il encore faire l'objet de discutions au niveau des listes
> internationales ?
>
> L'idée c'est de remplacer les ref:FR:CUB par exemple par des ref:Q1117116
> L'avantage c'est qu'à périmètre constant (ce qui est le cas de la CUB
> devenue BM ou de ERDF devenu Enedis), on n'a rien à changer.
> L'inconvénient c'est que c'est inutilisable en brut comme présenté ici :
> - pas de contrôle (un ref:FR:CUN au lieu de ref:FR:CUB, ça se voit plus
> facilement qu'un ref:Q1171116 au lieu d'un ref:Q1117116)
> il faut donc que les outils principaux (JOSM, ID, Potlatch) proposent déjà
> une interface qui intègre cela (si la personne tape CUB on lui propose
> ref:Q1117116 - affiché Bordeaux Métropole avec un indicateur Wikidata, idem
> si on trouve un ref:Q1117116 on doit afficher Bordeaux Métropole avec un
> indicateur Wikidata).
>
> Je ne sais si quelqu'un a lancé la discussion sur une liste internationale.
>
> Je n'ai jamais fait de remplacement systématique, mais, j'ai préparé (ce
> que je pensais possible de faire) et j'aimerais qu'on me dise si c'est ok:
>
> Moi non plus mais ça me semble correct.
>
> - il trouve une liste d'avertissements longue comme "un jour sans pain"
> (89) je suis pas prêt de tous les vérifier
>
> Comme tu modifies il te propose de corriger des erreurs précédentes.
> Stricto sensu tu pourrais passer outre et corriger plus tard. Car si tu
> attends 3 semaines il y a des risques que d'autres modifient ces objets et
> que tu te retrouves avec un conflit d'édition : d'accord avec Frédéric.
>
> Je n'ai pas trouvé dans les datas de BM des infos sur les couleurs en hex
> Je suis donc parti des couleurs représentées sur le site TBM que j'ai
> mises à gauche et à droite celles que j'ai trouvées approchantes. N'y
> a-t-il pas dans le wiki une page Bordeaux comme celle de Toulouse (
> http://wiki.openstreetmap.org/wiki/Toulouse/Transports_en_commun) ?
> bleu             #008BCF
>
> #008DD0
>
> orange         #ED862F
>
> #F58220
>
> vert              #7B9C41
>
> #7B9C41
>
> bleu foncé   #292059
>
> #292059
> Je suis parti de la page initiale et ai utilisé le greffon ColorPicker.
> Bien plus pratique (et plus sûr)
>
> Jean-Yvon
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment.htm>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/png
Taille: 1155 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment.png>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/png
Taille: 1553 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment-0001.png>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/png
Taille: 1512 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment-0002.png>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/png
Taille: 86 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment-0003.png>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/png
Taille: 1309 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment-0004.png>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/png
Taille: 84 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment-0005.png>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/png
Taille: 88 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment-0006.png>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: non disponible
Type: image/png
Taille: 87 octets
Desc: non disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20160807/18cfa07c/attachment-0007.png>