Le 23 août 2017 à 22:28, <osm.sanspourr...@spamgourmet.com> a écrit :
> Résumé à la vdct : KISS > > Le 23/08/2017 à 20:59, Noémie Lehuby - noemie.leh...@zaclys.net a écrit : > > Le 22/08/2017 à 22:52, Philippe Verdy a écrit : > > L'ennui c'et que toutes les applications qui ont commencé à utiliser > network=* ont supposé que le nom indiqué derrière était unique, ce qu'il > n'est pas. En fait ils voulaient que ce soit bien un identifiant. > > On parle de quelles applications ? > Moi j'en connais pas bcp qui utilisent le tag network des relations route > ou route_master (voire même : pas bcp qui utilisent les relations route ou > route_master). > > Noémie, tu m'enlèves le pain de la bouche. > Car j'allais poser la question. > Je ne connais personnellement que Overpass API qui a l'interface > sketchline pour produire des lignes de transport. > https://wiki.openstreetmap.org/wiki/Overpass_API/Public_transport_examples > > Fonctionnalité si bien cachée que je ne trouvais pas le point d'entrée > <http://overpass-api.de/public_transport.html> de l'application (en fait > il ne fallait pas partir du wiki mais de la page principale, je corrige le > wiki). > Je découvre aujourd'hui après le style allemand et italien le style > français appelé paris : > http://overpass-api.de/api/sketch-line?ref=a&network=FR:STAR&style=paris > Pas mal ! > Et pour les lignes identiques, j'ai fini par avoir une idée qui me semble > être simple (et donc bonne). Suspense... > > Personnellement, quand je fais des extractions de données transports, je > ne m'attends pas à ce que le nom soit unique. > S'il y a deux réseaux STAR ou Arc-En-Ciel ou SITUS, ben je veux avoir deux > occurrences dans mes données. C'est la réalité du terrain, ça me semble > normal de retrouver cela dans OSM. > > En fait quelqu'un disait que les noms de villes étaient aussi multiples et > que ça ne nous dérangeait pas. > Dans l'API précédente il nous propose en cas de réseaux de même nom la clé > operator. > Si je prends la CTRL > <https://fr.wikipedia.org/wiki/Compagnie_de_transport_de_la_r%C3%A9gion_lorientaise> > (Lorient) pas moins de 5 opérateurs pour les bus ou cars (Philippe me dira > qu'ils sont sans toutes tous délégataires d'un seul, possible mais si un > contributeur vois des car Kerjan assurer le transport scolaire il mettra > operator Kerjan, pas Keolis Lorient). Subtilités : > - 5 lignes maritimes gérées par Keolis Maritime Lorient > - une ligne maritime sans doute cogérée avec TBK entre les Bas-Pouldus > c'est à dire les port de Guidel-Plages et du Pouldu. > Donc l'API proposée qui demande un tag operator après un network tu > oublies. > > Le nom public c'est simple (CTRL, TBK, c'est écrit sur les véhicules et > sur les arrêts). > Et... le lieu c'est simple pour OSM. > Or on est sur Overpass qui comprend facilement des bbox et des zones > géographiques. > "network=fr_ctrl in Bretagne" avec l'assistant overpass-turbo donne bien > le réseau CTRL. > Si demain l'API supporte bbox et/ou geocodeArea, ça permet de mettre le > nom commercial dans network, et d'avoir une API plus facile à utiliser pour > monsieur tout le monde : l'unicité du nom comme pour la ville vient de la > précision de la localisation (Brest, Bretagne ou Brest, Belarus comme > Arc-en-ciel, Haute-Garonne). > network=fr_ctrl in "Lorient Agglomération" > <http://overpass-turbo.eu/s/rcO> marche aussi. > > On peut ajouter un tampon optionnel (around, ça existe déjà) pour traiter > des transports hors zone de compétence stricte (ci-dessus, Le Pouldu est > dans le Finistère et non dans Lorient Aqglomération). > > Parce que les noms sont en entrée libre, je suggère d'avoir un > network:wikidata afin de faire plus facilement du contrôle qualité. Et si > on ne veut pas ajouter un Wikidata, on peut toujours au lieu d'avoir un > Qxxx mettre un Oxxx (identifiant unique OSM, à mettre quelque part par > exemple sur le wiki page transports public). > > Ce qui répond aux besoins exprimés par Philippe (unicité) et aussi bien > qu'aujourd'hui (où nulle part on n'a la liste des identifiants utilisés). > Le jour ou il y a un wikidata, il suffit de remplacer les > network:wikidata=Oxxx par network:wikidata=Qyyy. > > Quant à la lenteur supposée par Philippe, elle suppose que l'on est > bourrin et qu'on travaille sans cache. > Non la lenteur vient du fait qu'Overpass n'est pas destiné à ça (et n'est pas conçu pour supporter l'usage dans une application), c'est juste un outil de travail à destination des controbuteurs de données ou temporairement pour les développeurs qui vont justement tenter de se créer un dataset et de le consolider, ce qui n'est pas simple du tout. > De plus la solution proposée n'exclut pas la relation network. > J'ai dit exactement le symétrique. mais en précisant tout de même qu'il y avait une forte redondance alors dans les tags, et que cela posera toujours des complexités de maintenance et de doublons un peu partout. La visibilité des relations est assurée même pour les utilisateurs basiques de iD: la relation mère apparait de la même façon qu'un tag unique, et en un clic sur le lien affiché ils sont le détail de façon lisible. en revanche avec un tag network:id=Oxxxx totalement illisible, on n'aura QUE des erreurs un peu partout et pas de navigation aussi simple. Le network:wikidata=Qnnn peut aussi afficher un lien pour afficher des détails sur la page web de Wikidata (ou dans l'UI d'un client qui comprend le protocole de requête de Wikidata), à condition que Wikidata parle le même langage qu'OSM et utilise les mêmes critères de classification: rien ne le dit. Et Wikidata risque fort de données des tas d'infos qui seraient rejetées dans OSM ou de noyer encore plus l'utilisateur sous des flots croissants de propriétés et de liens (en fait Wikidata a lui même de moins en moins de contributeurs, il est devenu incompréhensible pour la plupart des gens, c'est devenu un outil destiné à concevoir des modèles de requêtes pour mettre en forme certaines données dans Wikipédia, et de plus en plus fortement lié à Wikipédia et ses critères d'adminissibilité, et prenant assez mal en compte d'autres projets comme le Wiktionnaire ou même Commons uniquement pour ses catégories; Wikidata est de plus en plus rempli de données qui ne concerne que Wikipédia et souvent que la version anglophone; rien que l'inclusaion dans Wikidata des "pages d'homonymie" de Wikipedia a créé un max de "spaghettis" avec de "classes" intermédiaires presque impossibles à nommer, et des tas de "critères" avec des listes de règles illisibles, incomplètes, souvent incoéhbrentes entre elles et ayant de très nombreuses exceptions: Wikidata ne sait en effet pas gérer autre chose que des affirmations fortement binaires, mais il veut y mettre toutes la connaissance du monde selon Wikipedia, où le monde ne se classe pas tout entier dans un système de choix binaires même multidimensionnels :essayez d'y classer la politique, la religion, la philosophie et même les choses bien réelles comme le vivant et en plus de vouloir y mettre une archive de toutes les anciennes modélisations du monde !) Pour tenter de régler ça, il y a bien eu dans Wikidata l'introduction des "qualificateurs", mais là encore les qualificateurs à utiliser suivent une logique de classification binaire (on a reporté le problème de classes à celui de nouvelles "métaclasses" et on s'éloigne de plus en plus de la connaissance comprise par le plus grand nombre). ela a fait de Wikidata un projet de plus en plus réservé à quelques spécialistes (qui n'ont pas non plus les mêmes avis pourtant très tranchés). Wikidata a donc de gros problèmes qui lui sont propres et ce ne sera pas facile de coexister quand nous aussi on a nos propres problèmes de cohérence (et q'on voudrait reporter nos problèmes vers Wikidata en leur laissant le soin de tenter de les régler alors qu'ils ont encore moins de monde que nous et sont encore plus débordés !) Et seuls quelques experts essaieront d'utiliser Overpass, et de construire une requête qu'ils devront maintenir et qui ne trouvera en fait pas tout. On a une solution immédiatement utilisable, simple même à expliquer (ce n'est pas plus compliqué d'expliquer l'ajout dans iD d'une relation mère sélectionnée d'un clic dans une liste simple et lisible que de tenter de leur expliquer ce qu'est un tag et comment lui donner une valeur que l'éditeur ne permet même pas de valider ou d'interpréter !) cet outil permet une collaboration avec beaucoup de monde, préserve l'ouverture des données (pas besoin de savoir où il peut exister une base annexe et si cette base est ouverte ou pas !), et dont le coût en espace est même négligeable (inférieur même aux multiples tags proposés), et ne posant aucun problème d'interprétations ou d'ambiguité, et désignant clairement ce qu'on peut qualifier d'objet cartographique (mais à la "géométrie" générale très compliquée car comprenant plus que de simple points, traits ou surfaces mais avec des propriétés spécifiques entre ces derniers éléments). Franchement: où est le problème avec ces relations microscopiques? Alors que le gros du boulot est sur le maintien des routes, les listes d'arrêts, la géométrie des plateformes, les estimations de parcours, le calcul tarifaire, l'accessibilité à différents niveaux. Pourquoi se compliquer avec un tag ambigu dès le départ, et même avec des requêtes géométriques qui sont, je le répète, très inefficaces sur les zones étendues couvertes par ces réseaux, qui en plus s'entrecroisent un peu partout (donc la "localisation" géographique restera très imprécise et floue, pouvant aller jusqu'au pays tout entier dont la bounding box débordera sur les voisins qui pourront eux aussi avoir des réseaux homonymes même si leurs lignes respectives ne s'entrecroisent pas du tout) ! Si à la place des bounding box on a besoin de la géométrie des pays alors ça devient encore plus lourd et plus inefficace. Et en tout cas totalement inutilisable depuis les éditeurs de base (exit le travail sur le site OSM avec iD): on a créé un OSM lui aussi réservé à quelques spécialistes, et le jour où ils ne sont plus là plus personne ne peut reprendre la suite et la base sera bourrée d'anomalies, tellement que ces donnes ne serviront à rien ou seront massivement obsolètes. OSM se cantonnera juste à ce qui est visible et tout le monde ne voudra plus faire que taguer pour le rendu avec des règles portant sur des objets très réduits, peu de propriétés, et des données seulement comprises par un humain. On fait alors la même chose que ce qui est arrivé chez Wikimedia pour le Wiktionnaire, qui pourtant traite d'une connaissance essentielle à chacun dans le monde: sa langue et la compréhension des autres. Le Wiktionnaire en fait ne répond plus à ce qui était voulu, ce sont les dictionnaires commerciaux et surtout les moteurs de recherche qui ont pris toute la place. Et si vous ne me croyez pas, regardez combien à a de routes obsolètes et en doublons dans les quelques grandes villes où on a commencé à les mettre: depuis le début dans OSM il a manqué la structure pour gérer le travail non seulement de création initiale. Mais aussi pour faciliter la maintenance régulière car ces réseaux sont très évolutifs (plus vite que l'infrastructure des routes et immeubles qui durent une ou plusieurs décennies, ou même les commerces et activités, ou les éléments naturels du sol et des surfaces en eau qui eux restent à peu près en état pendant des siècles tant qu'ils ne sont pas occupés ou retournent vite à leur état quand l'activité cesse).
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
