Oui elle est faible, voilà comment un modèle v2 approuvé depuis plus d'un
an, pour d'excellentes raisons, n'avance pas: les outils ne suivent
toujours pas (hormi JOSM qui reconnait très bien le nouveau schéma, les
rendus n'en tiennent toujours pas compte, donc n'affichent rien, donc les
utilisateurs ne sont pas poussés non plus à adopter ce schéma).
Il faut bien commencer, quitte à ce que les rendus aient des anomalies (des
arrêts bien tagués mais pour l'instant non affichés): c'est aux rendus donc
de s'adapter, on ne devrait pas taguer juste pour le rendu actuel (qui de
toute façon ne sait pas faire correctement la différence entre arrêts et
plateformes, qui de toute façon ont été confondus et mélangés un peu
partout depuis le début avec "bus_stop".
Si on veut gérer la transition, il faut décider vers lequel de "platform"
ou "stop_position" on doit basculer les "bus_stop" actuels. En majorité les
"bus_stop" ont été mis sur ce qui devrait être des "plateform" en v2 (c'est
à dire à côté des chemins de la relation "route"). Mais si on tague les 2
("platform" + "stop_position" ) en v2
Et si on veut être compatible avec sketchline, les "bus_stop" devraient
être déplacés vers les nouveaux noeuds "stop_position". Le rendu actuel les
affichera au milieu de la chaussée, un nouveau rendu optera pour ne pas les
afficher du tout si on a la combinaison "bus_stop"+"stop_position" sur un
même noeud, et affichera plutôt les "plateform", et les "bus_stop" restants
non associés à un "stop_position". On aura donc le meilleur des deux
mondes, et une transition possible en relative douceur (sachant que cela
prendra beaucoup de temps pour tout basculer en v2, avant de finalement
supprimer le tag "bus_stop" devenu obsolète).
Le 13 décembre 2016 à 20:03, Noémie Lehuby <noemie.leh...@openmailbox.org>
a écrit :
> Bonsoir,
>
> Jean-Yvon, je veux bien tenter d'adapter mon outil pour d'autres régions,
> mais il faut s'assurer avant que les codes qu'on importera sont stables.
> S'ils ne représentent plus rien dans 6 mois, on va le regretter.
> C'est pourquoi en île-de-france ça a du sens : le STIF propose un
> référentiel sur son portail opendata donc on peut penser qu'on aura une
> certaine pérennité de ces codes.
> Quel réseau te ferait plaisir pour Noël ?
>
> C'est amusant ça : la couverture en public_transport = stop_position est
> si faible que j'avais jamais remarqué le problème de rendu avec Skechtline
> que tu cites Philippe.
>
> Noémie
>
> Date: Mon, 12 Dec 2016 21:17:49 +0100
>> From: osm.sanspourr...@spamgourmet.com
>> To: talk-fr@openstreetmap.org
>> Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
>> Message-ID: <45f27b94-1092-e208-08f9-3b2c4b830...@gmx.net>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> Logiquement, on se dit que tu vas nous faire la même chose pour l'open
>> data des lignes hors du STIF : il y a des réseaux de transports en
>> dehors de l'Île-de-France, si, si ;-).
>>
>> Pense qu'une seule personne a profité de l'outil, c'est un peu abuser,
>> non ? :-D
>>
>> Jean-Yvon
>>
>> Le 12/12/2016 à 21:01, Noémie Lehuby - noemie.leh...@openmailbox.org a
>> écrit :
>>
>>> Bonsoir,
>>>
>>> J'ai poussé une mise à jour de l'outil, avec quelques améliorations
>>> mineures : https://ref-lignes-stif.5apps.com/
>>> Je pense que je ne vais pas faire beaucoup d'autres évolutions dans
>>> l'outil, vu que Florian a déjà associé plus des 3/4 des lignes ;)
>>> Belle performance !
>>>
>>
>> -------------- section suivante --------------
>> Une pièce jointe HTML a été nettoyée...
>> URL:
>> <http://lists.openstreetmap.org/pipermail/talk-fr/attachment
>> s/20161212/e1a79ea5/attachment-0001.html>
>>
>> ------------------------------
>>
>
>
> _______________________________________________
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
