J'avoue avoir un peu abusé de l'outil à mon seul profit ^^ très bons points pour la suite Noémie. Il va falloir choisir les priorités ... celles que je propose :
on a plus d'un millier de lignes côté opendata, et péniblement 400 côté OSM > ... donc il en manque. > Il y en a pas mal qui sont déjà présentes dans OSM mais pas cartographiées > rigoureusement selon le schéma (des fois il manque le tag route_master, des > fois on a l'aller et le retour de la ligne dans la même relation, etc) > Là, je n'ai pas d'outil ni pour détecter ni pour aller plus vite dans la > remise au carré des relations, mais je pense qu'il y a pas mal de boulot. Si on s'organise pour faire ça pas à pas, il y a moyen de s'en sortir. Le tasking manager https://github.com/hotosm/osm-tasking-manager2 ne serait-il pas le bon outil pour y parvenir ? > utiliser l'association déjà réalisée pour compléter OSM : > pour le moment, c'est assez minimaliste, mais on doit pouvoir trouver les > tags network / operator / from / to en se basant sur les données opendata > qui matchent. > penses-tu pouvoir faire évoluer ton outil pour intégrer ça ? Le 12 décembre 2016 à 23:06, Philippe Verdy <verd...@wanadoo.fr> a écrit : > > > Le 12 décembre 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 ! >> >> Quelques pistes pour aller plus loin: >> préparer le deuxième service : >> on a plus d'un millier de lignes côté opendata, et péniblement 400 côté >> OSM ... donc il en manque. >> Il y en a pas mal qui sont déjà présentes dans OSM mais pas >> cartographiées rigoureusement selon le schéma (des fois il manque le tag >> route_master, des fois on a l'aller et le retour de la ligne dans la même >> relation, etc) >> Là, je n'ai pas d'outil ni pour détecter ni pour aller plus vite dans la >> remise au carré des relations, mais je pense qu'il y a pas mal de boulot. >> > > Ce n'est pas spécifuqye au réseau d'Île-de-France. Le schéma v2 commence > tout juste à sortir des cartons (il a été oublié pendant plus d'un an), et > on constate maintenant qu'il y a encore des anomalies de rendu. > > Par exemple, en "v1", les arrêts étaient taguées avec "highway=bus_stop" > pour mentionner en fait les plateformes (à côté des chemins d'itinéraires, > donc avec des difficultés pour chercher les correspondances à la même > plateforme, surtout quand il y a des carrefours et des lignes qui se > croisent autour). Mais seuls ces "highway=bus_stop" sont rendus pour > l'instant sur OSM Mapnik. Les "platform" de la "v2" ne sont pas affichés du > tout. > > Si on combine "highway=bus_stop" (v1) et "public_transport=platform" sur > le même noeud (ce qui serait logique), on a bien ce rendu. Mais alors il > manque un noeud "public_tranport=stop_position"+"bus=yes" sur le chemin. > Si on ajoute ce noeud (qui n'est pas non plus affiché dans OSM Mapnik, à > moins qu'il porte aussi "railway=stop/halt" pour le ferroviaire/métro), on > se retrouve alors avec deux noeuds et l'outil "Sketchline" de l'Overpass > API Turbo va les afficher tous les deux comme deux arrêts successifs > (homonymes). Si on ne garde que le schéma v2 (suppression de l'ancien > "bus_stop", conservation de "public_transport=platform", là on n'a qu'un > seul arrêt (Sketchline prend en compte à la fois "bus_stop" et "platform" > qui devraient correspondre, mais ignore "stop_position"; il ne sait pas > prendre les 3 et faire une union, ce qui ne facilite pas les transitions de > schéma). > > La solution propre pour passer à la v2 est bien de supprimer tous les > "highway=bus_stop"; mais Mapnik OSM ne sait pour l'instant pas afficher > autre chose ! Il ne reconnait encore que le schéma v1, ne tient jamais > compte des "stop_area" (en revanche les "stop_area" sont reconnus par le > rendu "Public Transport" qui affiche des ovales autour des arrêts > "stop_position" mais pas autour des "plateform" qui sont des objets > séparés: ces ovales signalent le trajet éventuellement à faire à pied pour > passer d'un point d'arrêt de véhicule à l'autre, sans tenir compte des > plateformes d'attente qui sont souvent plus grandes, notamment pour les > gares). > > Ca fait donc des mois que le schéma v2 est décrit, mais si on ne commence > pas à le prendre en compte pour les données, il semble qu'aun rendu ne > s'adaptera pour reconnaitre ce schéma. et chacun traite à sa façon les > objets à tagués à prendre en compte ou ignorer: il manque des règles > claires de transition (et de priorité entre tags). > > Osmose non plus ne semble pas savoir quoi décider. JOSM reconnait > parfaitement les deux schémas v1 et v2 (et il les vérifie, à condition de > mentionner explicitement la version 2 du schéma, sinon il utilise les > anciennes règles de la v1. On a donc des débuts de prise enc compte mais > pas de façon générale. > > De plus il reste quelques anomalies dans le schéma v1 (par exemple dans > les relations "route", on a des membres décrits pour les batiments, mais > uniquement s'ils sont tagués comme un seul polygone fermé, et pas comme > multipolygone pour des formes plus complexes (ou contenant des enclaves > intérieures): cet oublie des "relations multipolygone" (pourtant > correctement tagués avec "railway=station" est signalé par JOSM comme une > erreur, uniquement parce que le rôle vide défini pour ça ne mentionne que > la possiblité de batiments réduits à un noeud ou un seul polygone fermé: il > aurait plutôt fallu définir des rôles pour les "station"). > > > > _______________________________________________ > Talk-fr mailing list > Talk-fr@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-fr > > -- *Florian Lainez* @overflorian <http://twitter.com/overflorian>
_______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
