subject:"\[OSM\-talk\-fr\] intégration des référentiels STIF"

Re: [OSM-talk-fr] intégration des référentiels STIF

2017-02-06 Par sujet Florian LAINEZ

L'évolution de ton outil est juste complétement incroyable Noémie : merci !
Nous avons pas mal de boulot/fun sur la table et j'ai déjà commencé.

Si des motivés ont besoin d'un coup d'aide pour la prise en main, je peux
vous aider ...

Le 5 février 2017 à 16:24, Noémie Lehuby  a
écrit :

> Bonjour,
>
> voici quelques nouvelles du projet d'intégration des ref STIF dans OSM :
> *concernant l'intégration des codes STIF sur les lignes*
> Un petit état des lieux :
> - 381 ref STIF intégrés dans OSM
> - 57 lignes dans OSM sans ref STIF
>
> L'outil est toujours dispo pour réaliser des comparaisons et intégrer les ref 
> : https://ref-lignes-stif.5apps.com/
> C'est très facile, Florian qui a importé 80% de ces ref en une demi-journée 
> pourra en témoignera ;)
> À noter que parmi les lignes restantes, il y en a encore sûrement qui 
> n'existent plus aujourd'hui et qui devraient être supprimées.
>
> Ensuite, j'ai réalisé, avec l'aide Frédéric et de Jocelyn, une analyse Osmose 
> qui permet de renseigner quelques tags manquants sur les lignes OSM en 
> s'aidant des infos opendata :
> http://osmose.openstreetmap.fr/fr/errors/?source=28482=8042=1
> C'est encore modeste, mais ça grossira avec l'avancement de l'intégration des 
> ref sur les lignes, et ça pourra également permettre d'enrichir les relations 
> route.
>
> Par contre, d'après le STIF, on a plus de 1400 lignes en Île-de-France, donc 
> c'est loin d'être fini !
>
> Il y a un effet un gros manque de lignes de transport (relation route_master) 
> dans OSM.
> En revanche, en terme de parcours (relation route), on est plutôt pas mal : 
> on trouve pas mal de relation route où on a, en vrac, le tracé en sens aller, 
> le tracé en sens retour, un tracé spécial des jours de marché, tous les 
> arrêts et même quelques stop_position. En y remettant un peu d'ordre, on peut 
> créer une relation route_master et ses relations route. J'en ai créé ainsi 
> une petite trentaine depuis le début de l'année.
> Personnellement, je cartographie surtout du bus, mais le manque de relation 
> route_master est très général, il en manque sur la plupart des RER et 
> Transilien également.
> Sur ce sujet, je n'ai pas d'idée de génie pour nous aider à avancer :
> On doit pouvoir extraire les relations route non membre d'une relation 
> route_master pour isoler les éléments à créer, mais ça restera du travail 
> long et chiant à faire dans JOSM derrière :(
> *concernant l'intégration des codes STIF sur les arrêts*
> Les proposition d'intégration Osmose de Frédéric sont toujours disponibles.
> Attention tout de même au fait que
>
>
>- un arrêt OSM peut porter plusieurs codes STIF
>- les ref du STIF sont des ref de public_transport = platform et pas
>de public_transport = stop_position.
>
> Là encore, on a des petites lacunes : on a des lignes entières (notamment de 
> tram et de train) cartographiées uniquement avec des stop_position, donc les 
> codes STIF n'y ont pas trop de sens.
>
> J'ai fait un prototype d'outil web qui facilite l'intégration des codes STIF 
> sur les arrêts d'une ligne (une fois que le code STIF de la ligne a été 
> renseigné), mais ce n'est pas encore prêt ...
> La pérennité des codes STIF reste aussi à vérifier : j'ai trouvé des codes 
> STIF intégrés sur les arrêts avec Osmose qu'on ne retrouvait pas dans la 
> dernière version du référentiel du STIF.
> Bref, c'est nettement moins avancé sur ce sujet (et je ne parle même pas des 
> codes STIF des zones d'arrêts :p), mais je ne m'en inquiète pas, ça me parait 
> plus efficace de se concentrer sur les lignes pour le moment.
>
>
> Voilà pour le petit point d'étape.
> Il y a toujours un salon de discussion avec des infos un peu plus fréquentes 
> ouvert ici : https://framateam.org/bato-fr/channels/stif
> Et s'il y a des gens motivés, on peut aussi en discuter de vive voix à une 
> prochaine rencontre mensuelle des contributeurs d'Île-de-France ;)
>
> Noémie
> @nlehuby
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2017-02-05 Par sujet Noémie Lehuby

 

Bonjour,

voici quelques nouvelles du projet d'intégration des ref STIF dans OSM :

CONCERNANT L'INTÉGRATION DES CODES STIF SUR LES LIGNES
Un petit état des lieux :
- 381 ref STIF intégrés dans OSM
- 57 lignes dans OSM sans ref STIF

L'outil est toujours dispo pour réaliser des comparaisons et intégrer
les ref : https://ref-lignes-stif.5apps.com/
C'est très facile, Florian qui a importé 80% de ces ref en une
demi-journée pourra en témoignera ;)
À noter que parmi les lignes restantes, il y en a encore sûrement qui
n'existent plus aujourd'hui et qui devraient être supprimées.

Ensuite, j'ai réalisé, avec l'aide Frédéric et de Jocelyn, une analyse
Osmose qui permet de renseigner quelques tags manquants sur les lignes
OSM en s'aidant des infos opendata : 
http://osmose.openstreetmap.fr/fr/errors/?source=28482=8042=1

C'est encore modeste, mais ça grossira avec l'avancement de
l'intégration des ref sur les lignes, et ça pourra également permettre
d'enrichir les relations route.

Par contre, d'après le STIF, on a plus de 1400 lignes en Île-de-France,
donc c'est loin d'être fini !

Il y a un effet un gros manque de lignes de transport (relation
route_master) dans OSM.
En revanche, en terme de parcours (relation route), on est plutôt pas
mal : on trouve pas mal de relation route où on a, en vrac, le tracé en
sens aller, le tracé en sens retour, un tracé spécial des jours de
marché, tous les arrêts et même quelques stop_position. En y remettant
un peu d'ordre, on peut créer une relation route_master et ses relations
route. J'en ai créé ainsi une petite trentaine depuis le début de
l'année.
Personnellement, je cartographie surtout du bus, mais le manque de
relation route_master est très général, il en manque sur la plupart des
RER et Transilien également.
Sur ce sujet, je n'ai pas d'idée de génie pour nous aider à avancer :
On doit pouvoir extraire les relations route non membre d'une relation
route_master pour isoler les éléments à créer, mais ça restera du
travail long et chiant à faire dans JOSM derrière :(

CONCERNANT L'INTÉGRATION DES CODES STIF SUR LES ARRÊTS
Les proposition d'intégration Osmose de Frédéric sont toujours
disponibles.
Attention tout de même au fait que

* un arrêt OSM peut porter plusieurs codes STIF
* les ref du STIF sont des ref de public_transport = platform et pas
de public_transport = stop_position.

Là encore, on a des petites lacunes : on a des lignes entières
(notamment de tram et de train) cartographiées uniquement avec des
stop_position, donc les codes STIF n'y ont pas trop de sens.

J'ai fait un prototype d'outil web qui facilite l'intégration des codes
STIF sur les arrêts d'une ligne (une fois que le code STIF de la ligne a
été renseigné), mais ce n'est pas encore prêt ...
La pérennité des codes STIF reste aussi à vérifier : j'ai trouvé des
codes STIF intégrés sur les arrêts avec Osmose qu'on ne retrouvait pas
dans la dernière version du référentiel du STIF.
Bref, c'est nettement moins avancé sur ce sujet (et je ne parle même pas
des codes STIF des zones d'arrêts :p), mais je ne m'en inquiète pas, ça
me parait plus efficace de se concentrer sur les lignes pour le moment.

Voilà pour le petit point d'étape.
Il y a toujours un salon de discussion avec des infos un peu plus
fréquentes ouvert ici : https://framateam.org/bato-fr/channels/stif 
Et s'il y a des gens motivés, on peut aussi en discuter de vive voix à
une prochaine rencontre mensuelle des contributeurs d'Île-de-France ;)

Noémie
@nlehuby
 ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2017-01-20 Par sujet Florian LAINEZ

Salut,
Je suis allé voir le STIF ce matin pour leur parler d'OSM, de qualité et
d'ouverture des données.
Ils vont étudier les données OSM de plus près, même s'ils considèrent
clairement OSM comme un référentiel "concurrent" au leur pour l'instant.

Sinon, ils pensent publier le tracé des lignes de bus un de ces 4 (pas de
date annoncée) et ils étudient également différentes solutions de
crowdsourcing.
J'attends une réponse un peu plus formelle concernant leur soutien à mon
initiative Easy Transport.
Pas d'annonce donc, mais un premier contact constructif. Je vous tiens au
courant de la suite ...

Le 31 décembre 2016 à 18:07, Florian LAINEZ  a écrit :

>
> Le 21 décembre 2016 à 22:10, lenny.libre  a écrit :
>
>> Mais là je viens de découvrir bato. C'est tellement vaste... je ne
>> comprends pas tout et je ne vois pas où je pourrais contribuer avec mes
>> petits moyens : je prends une ligne, je la complète si nécessaire, j'aboute
>> les tronçons avec JOSM, je corrige les giratoires (que certains découpent
>> pour leur besoin sans se préoccuper des autres lignes) je complète les
>> arrêts si nécessaire (avec l'aide des openData ou ce que je vois sur place).
>
>
> Contribuer à OSM est la meilleure manière de contribuer à BATO ;)
> Si tu veux aller plus loin et nous aider, nous essayons d'installer une
> première instance de la BDD BATO ... contactes Noémie directement pour
> l'aider.
>
> Les transports scolaires sont-ils compris dans bato ?
>>
> oui
>
> Je ne vois pas comment l'id OSM peut être pérenne
>>
> Il ne l'est pas. L'idée de BATO n'est pas de créer un "identifiant
> "universel"" supplémentaire mais bien de travailler avec l'existant : l'ID
> pérénne d'un arrêt est tout simplement celui définit par le
> transporteur/autorité de transport.
> D'où le travail de correspondance que nous menons actuellement pour
> rajouter le numéro STIF dans la ref des arrêts / lignes de bus en IdF.
> Cette problématique est commune aux différents réseaux.
>
> --
>
> *Florian Lainez*
> @overflorian 
>



-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-31 Par sujet Florian LAINEZ

Le 21 décembre 2016 à 22:10, lenny.libre  a écrit :

> Mais là je viens de découvrir bato. C'est tellement vaste... je ne
> comprends pas tout et je ne vois pas où je pourrais contribuer avec mes
> petits moyens : je prends une ligne, je la complète si nécessaire, j'aboute
> les tronçons avec JOSM, je corrige les giratoires (que certains découpent
> pour leur besoin sans se préoccuper des autres lignes) je complète les
> arrêts si nécessaire (avec l'aide des openData ou ce que je vois sur place).


Contribuer à OSM est la meilleure manière de contribuer à BATO ;)
Si tu veux aller plus loin et nous aider, nous essayons d'installer une
première instance de la BDD BATO ... contactes Noémie directement pour
l'aider.

Les transports scolaires sont-ils compris dans bato ?
>
oui

Je ne vois pas comment l'id OSM peut être pérenne
>
Il ne l'est pas. L'idée de BATO n'est pas de créer un "identifiant
"universel"" supplémentaire mais bien de travailler avec l'existant : l'ID
pérénne d'un arrêt est tout simplement celui définit par le
transporteur/autorité de transport.
D'où le travail de correspondance que nous menons actuellement pour
rajouter le numéro STIF dans la ref des arrêts / lignes de bus en IdF.
Cette problématique est commune aux différents réseaux.

-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-21 Par sujet lenny.libre


h


Le 16/12/2016 à 17:36, Florian LAINEZ a écrit :


Le 16 décembre 2016 à 13:01, lenny.libre > a écrit :


Ne faudrait-il pas quelque part, une récapitulation


Un genre de Base d'Arrêts de Transport Ouverte ? ^^
Contributions bienvenues : https://github.com/BATO-FR/bato_inventaire
je ne pensais pas à quelque chose d'aussi immense ; mais je pensais, 
suite au mail de réponse de Jean-Yvon à Noémie à un tableau 
récapitulatif dans le wiki qui permettrait de choisir l'éventuelle ville 
à traiter après STIF ou à Osmose.


Mais là je viens de découvrir bato. C'est tellement vaste... je ne 
comprends pas tout et je ne vois pas où je pourrais contribuer avec mes 
petits moyens : je prends une ligne, je la complète si nécessaire, 
j'aboute les tronçons avec JOSM, je corrige les giratoires (que certains 
découpent pour leur besoin sans se préoccuper des autres lignes) je 
complète les arrêts si nécessaire (avec l'aide des openData ou ce que je 
vois sur place).


Les transports scolaires sont-ils compris dans bato ?
Dans les slides du Cerema, je trouvé un point qui me parait difficile à 
obtenir :
"IMPORTANT : attribution des identifiants pérennes !(id OSM et id 
Transport)"


Je ne vois pas comment l'id OSM peut être pérenne : prés de chez moi, 
j'ai trouvé deux arrêts, qui en fait n'en était qu'un (un contributeur à 
créé l'arrêt initial, entre temps l'opérateur à changé et un autre 
contributeur à créé un autre arrêt) je suis allé vérifier sur place, 
j'ai mis à jour l'un des deux et j'ai supprimé l'autre : quel était 
celui qui avait un id pérenne ???


cordialement
Léni


*Florian Lainez*

@overflorian 

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-16 Par sujet Florian LAINEZ

Le 16 décembre 2016 à 13:01, lenny.libre  a écrit :

> Ne faudrait-il pas quelque part, une récapitulation


Un genre de Base d'Arrêts de Transport Ouverte ? ^^
Contributions bienvenues : https://github.com/BATO-FR/bato_inventaire

-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-16 Par sujet lenny.libre




Le 13/12/2016 à 20:31, osm.sanspourr...@spamgourmet.com a écrit :


Je parlais en général pour le bien de la communauté, pas pour mon 
réseau local (Lorient a des données sur le portail data.gouv.fr mais 
pas le réseau transport à ma connaissance, Quimperlé n'a pas grand 
chose en disponible : une carte PDF, ce n'est pas ce que l'on fait de 
mieux, comme dit joliment par Christian open mais pas data).


Entièrement d'accord il faut des données libres et stables, je pense 
que pour la STAR (Rennes) c'est le cas.


Après autant commencer par les principaux réseaux (Nantes, Lille, 
Lyon, Strasbourg... : que ceux qui veulent un cadeau de Noël écrive à 
la mère Noëlle, heu Noémie.

Merci pour l'offre !
Ne faudrait-il pas quelque part, une récapitulation : comme un tableau - 
ville ou métropole - opérateurs - opendata - données de l'opendata 
vérifiées ou compatibles - osmose - page du wiki ...  ?


Je pense que la faible couverture de public_transport=stop_position 
montre que c'est une lubie de tagueur fou : pas de réalité sur le 
terrain (il faut observer l'arrêt du bus, pour le train suivant la 
longueur pourtant on ne peut en mettre qu'un (quoique ce n'est pas 
précisé dans le wiki 
<https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position>) 
et si la voie n'est pas fixe, on va mettre n arrêts ? Si les 
opérateurs disposent de l'info, la publie et que ça tombe sur une voie 
OSM, OK, sinon on tague pour le schéma (ce qui me semble pire que 
taguer pour le rendu).
On parle de faciliter l'entrée des nouveaux contributeurs. Là ça vaut 
opening_hours : sans outil adapté c'est galère : tu veux entrer un 
arrêt de bus et tu te manges une relation avec des tags qui feront que 
ton arrêt ne se sera pas affiché.


Jean-Yvon


Le 13/12/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/attachments/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


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-16 Par sujet lenny.libre




Le 12/12/2016 à 21:17, osm.sanspourr...@spamgourmet.com a écrit :


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



+1
Léni


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 !




___
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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-14 Par sujet Philippe Verdy

Le 14 décembre 2016 à 11:47, Christian Quest  a
écrit :

> Le 14 décembre 2016 à 10:34, Florian LAINEZ  a écrit :
>
>> Hello,
>>
>> 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
>>>
>>
>> Nous n'avons pas à décider, le modèle V2 a été créé en tant que tel sans
>> rétro-compatibilité, ce qui veut bien dire ce que ça veut dire. Chaque
>> amenity=bus_stop doit être complété ou remplacé à la mano par un platform
>> ou un stop_position.
>>
>>
>>>
>>> Et si on veut être compatible avec sketchline, les "bus_stop" devraient
>>> être déplacés vers les nouveaux noeuds "stop_position".
>>>
>>
>> Je n'ai pas de préférence ni d'avis sur le sujet mais je pense qu'il vaut
>> mieux laisser un seul bus_stop par arrêt effectif.
>> Jusqu'à présent je laisse bus_stop sur la platform par habitude. Mais
>> plus ça va plus je pense que je vais me radicaliser et virer totalement le
>> modèle V1 là où je passe, quitte à impacter le rendu Mapnik.
>>
>>
> Il y a beaucoup de rendus qui verront les arrêts de bus disparaitre.
>
> Il est très complexe d'utiliser les relations public_transport dans les
> rendus*... donc attention à ne pas se tirer une balle dans le pied en
> voulant trop bien faire sur la modélisation des transports publics on
> risque de les rendre invisibles dans la majorité des rendus car trop
> complexes à rendre.
>
> La coexistence ancien/nouveau schéma ne coûte pas grand chose... et évite
> une "fracture sémantique" ;)
>

Exactement ce dont je parlais plus haut.
* Pour cette coexistence dans les rendus carto, les "bus_stop" devraient
être conservés sur les "platform";
* pour la coexistence (sans doublon de noms dans Sketchline), ils devraient
être sur les "stop_position" (les "stop_area" c'est actuellement utilisé
uniquement pour le rendu "Public Transport" sélectionnable dans les couches
proposées sur le site OSM standard, ils peuvent inclure sans problèmes
"platform" et "stop_position", que l'un des deux ait un "bus_stop" ou aucun
des deux).

On a un choix à faire car on ne mettra pas les bus_stop à la fois sur les
stop_position et sur les platform (ce qui serait encore pire pour le rendu
carto et ne résoudrait rien sur Sketchline).
Je penche plutôt au choix de garder les bus_stop pour l'instant sur les
platform et non sur les stop_position (même si cela donne des noms en
doublon dans Sketchline

L'anomalie de Sketchline est déjà signalée de ce côté-là dans la doc du
modèle sur le wiki et signalé d'autre part à l'auteur de cette extension
Overpass Turbo du serveur allemand). Sketchline peut (et de toute façon
doit encore) être corrigé séparément et a un usage pour l'instant bien plus
limité. Et il a encore des améliorations à faire sur d'autres anomalies,
par exemple les lignes formant un circuit en boucle, dont il vire l'arrêt
commun un point de départ et d'arrivée, on a un exemple sur une ligne bus à
Saint-Malo, mais ça pourrait concerner tout autant la ligne de petite
ceinture à Paris et des lignes de circuits à caractère touristique, ou sur
la recherche des correspondances, qui ne fonctionne pas complètement, et la
possibilité d'avoir un diagramme sur plus de deux rangées, pour les lignes
très longues avec de nombreux arrêts, ou encore pour pouvoir y inclure des
pictogrammes de service ou d'accessibilité, ou encore pouvoir annoter les
limites de communes traversées afin de distinguer les arrêts "homonymes"
(comme "Mairie", "Eglise", "Centre", "Gare", "Collège", "Charles de Gaule"
sans avoir à rallonger les noms de chacune des stations avec le nom de la
commune et des parenthèses);

Ou encore pour afficher les limites de zones de tarification comme en
Île-de-France, où ces limites ne sont pas strictement alignées sur les
limites communale (montrer des photos d'exemples réels dans les trains RER
et Transilien peut aider à comprendre; pour les limites de communes on a
déjà les boundaries nécessaires, pour les zones tarifaires c'est à
modéliser avec des tags facilement réemployables tels que
"public_transport:zone=FR:STIF:Z1" et une relation avec le même tag pour
indiquer le nom en clair "name=Zone 1", la relation contenant un polygone
ou plusieurs polygones de types boundary plus des noeuds faisant exception
pour certains arrêts de certaines lignes hors de la zone normale, à moins
que les exceptions soient justement de taguer spécifiquement la zone
 tarifaire sur les arrêts faisant exception, les autres arrêts héritant de
la zone tarifaire délimitée par la relation).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-14 Par sujet Christian Quest

Le 14 décembre 2016 à 10:34, Florian LAINEZ  a écrit :

> Hello,
>
> 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
>>
>
> Nous n'avons pas à décider, le modèle V2 a été créé en tant que tel sans
> rétro-compatibilité, ce qui veut bien dire ce que ça veut dire. Chaque
> amenity=bus_stop doit être complété ou remplacé à la mano par un platform
> ou un stop_position.
>
>
>>
>> Et si on veut être compatible avec sketchline, les "bus_stop" devraient
>> être déplacés vers les nouveaux noeuds "stop_position".
>>
>
> Je n'ai pas de préférence ni d'avis sur le sujet mais je pense qu'il vaut
> mieux laisser un seul bus_stop par arrêt effectif.
> Jusqu'à présent je laisse bus_stop sur la platform par habitude. Mais plus
> ça va plus je pense que je vais me radicaliser et virer totalement le
> modèle V1 là où je passe, quitte à impacter le rendu Mapnik.
>
>
Il y a beaucoup de rendus qui verront les arrêts de bus disparaitre.

Il est très complexe d'utiliser les relations public_transport dans les
rendus*... donc attention à ne pas se tirer une balle dans le pied en
voulant trop bien faire sur la modélisation des transports publics on
risque de les rendre invisibles dans la majorité des rendus car trop
complexes à rendre.

La coexistence ancien/nouveau schéma ne coûte pas grand chose... et évite
une "fracture sémantique" ;)

* j'ai dû bricolé à mort en repassant par des tables qui servent à la mise
à jour des données et pas au rendu pour retrouver le network/operator des
arrêts de bus dans leur relation route pour mettre les logos locaux sur le
rendu FR. Je dois être un des rares à avoir fait ça.
voir: https://github.com/cquest/osmfr-cartocss/blob/master/project.mml#L1937

-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-14 Par sujet Florian LAINEZ

Hello,

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
>

Nous n'avons pas à décider, le modèle V2 a été créé en tant que tel sans
rétro-compatibilité, ce qui veut bien dire ce que ça veut dire. Chaque
amenity=bus_stop doit être complété ou remplacé à la mano par un platform
ou un stop_position.


>
> Et si on veut être compatible avec sketchline, les "bus_stop" devraient
> être déplacés vers les nouveaux noeuds "stop_position".
>

Je n'ai pas de préférence ni d'avis sur le sujet mais je pense qu'il vaut
mieux laisser un seul bus_stop par arrêt effectif.
Jusqu'à présent je laisse bus_stop sur la platform par habitude. Mais plus
ça va plus je pense que je vais me radicaliser et virer totalement le
modèle V1 là où je passe, quitte à impacter le rendu Mapnik.


>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération
>(2504515) 
>et fait partie de :
>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération
>(2504515) 
>
> Faut-il vraiment le second lien (sans rôle) ? Quelle signification ?
> Retrouver la relation maîtresse ?
>
C'est en effet une erreur que j'ai maintenant corrigée, merci.
ça confirme notre besoin d'un outil plus adapté pour faire ce boulot sans
erreur. J'ai un projet qui n'attend qu'à être lancé pour y parvenir ...
#WaitForIt

Le 13 décembre 2016 à 22:38, Philippe Verdy  a écrit :

> effectivement, les membres de relations ne devraient pas se lier l'un à
> l'autre, ce devrait être des parentés strictes dans une hiérarchie, donc
> sans boucle.
>
> Il y a cependant quelques cas où de telles boucles existent entre
> relations (mais pour des rôles différents), notamment pour les "default"
> values applicables à une région.
>
> Pour de tels cas, JOSM a inclus il y a maintenant près de 3 ans un "fix"
> lui évitant de créer une boucle infinie lors de l'énumération récursive des
> membres enfants: il détecte tout cas de retour d'un descendant vers un des
> ancêtres déjà en cours d'énumération et dans ce cas n'ira pas parcourir ce
> lien "descendant" qui en fait revient à un ascendant. Il utilise pour cela
> une simple pile, en empilant l'objet dont on va énumérer les enfants, puis
> en parcourant chacun les enfants (sans rien faire s'ils sont déjà présents
> quelque part dans la pile), puis une fois parcourus tous les enfants en
> dépilant le premier objet parent.
>
> C'est un garde-fou simple à implémenter (la pile est en fait non ordonnée,
> c'est une simple collection indexée par référence d'objet, l'index pouvant
> être très efficace si c'est une simple "hashtable"; de plus il ne sera
> jamais très grand car limité en taille à la longueur maximale de parcours
> hiérarchique d'un ancêtre vers le dernier de ses descendants, qui ne va
> jamais au delà d'un poignée: les parcours d'arbres de relation sont en fait
> beaucoup plus "larges" que "hauts" avec souvent beaucoup de membres dans
> une relation mais peu de niveaux de relations, je n'ai pas vu un seul cas
> où la profondeur atteint ou dépasse 16): si jamais on tombe sur un cas où
> en enfant est présent à la fois dans la liste des membres d'une relation et
> déjà dans la pile, on n'a aucun moyen de retraiter cet objet une deuxième
> fois, tout au plus on peut détecter une éventuelle incohérence de tags et
> journaliser ce cas, mais on ne doit pas traiter cet enfant à nouveau sans
> créer une boucle infinie: il suffit donc juste de savoir, si un objet qui
> peut avoir des descendants est déjà en cours de traitement dans la pile, si
> oui ne rien faire d'autre, sinon on commence à traiter l'objet en
> l'incluant d'abord dans la pile, puis en le retirant une fois le traitement
> de cet enfant terminé.
>
>
>
>
> Le 13 décembre 2016 à 22:17, Éric Gillet  a
> écrit :
>
>> Le 13 décembre 2016 à 21:27,  a écrit :
>>
>>> J'ai peut-être la réponse à la longueur du traitement :
>>>
>>> https://www.openstreetmap.org/relation/6789691 a pour membre :
>>>
>>>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>>>2504515) 
>>>et fait partie de :
>>>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>>>2504515) 
>>>
>>> Faut-il vraiment le second lien (sans rôle) ? Quelle signification ?
>>> Retrouver la relation maîtresse ?
>>>
>>
>> Cela me semble être une erreur, il n'est pas nécessaire de "boucler"
>> comme ça les relations. Les outils, notamment Overpass, savent gérer les
>> liens de parenté entre les

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Philippe Verdy

effectivement, les membres de relations ne devraient pas se lier l'un à
l'autre, ce devrait être des parentés strictes dans une hiérarchie, donc
sans boucle.

Il y a cependant quelques cas où de telles boucles existent entre relations
(mais pour des rôles différents), notamment pour les "default" values
applicables à une région.

Pour de tels cas, JOSM a inclus il y a maintenant près de 3 ans un "fix"
lui évitant de créer une boucle infinie lors de l'énumération récursive des
membres enfants: il détecte tout cas de retour d'un descendant vers un des
ancêtres déjà en cours d'énumération et dans ce cas n'ira pas parcourir ce
lien "descendant" qui en fait revient à un ascendant. Il utilise pour cela
une simple pile, en empilant l'objet dont on va énumérer les enfants, puis
en parcourant chacun les enfants (sans rien faire s'ils sont déjà présents
quelque part dans la pile), puis une fois parcourus tous les enfants en
dépilant le premier objet parent.

C'est un garde-fou simple à implémenter (la pile est en fait non ordonnée,
c'est une simple collection indexée par référence d'objet, l'index pouvant
être très efficace si c'est une simple "hashtable"; de plus il ne sera
jamais très grand car limité en taille à la longueur maximale de parcours
hiérarchique d'un ancêtre vers le dernier de ses descendants, qui ne va
jamais au delà d'un poignée: les parcours d'arbres de relation sont en fait
beaucoup plus "larges" que "hauts" avec souvent beaucoup de membres dans
une relation mais peu de niveaux de relations, je n'ai pas vu un seul cas
où la profondeur atteint ou dépasse 16): si jamais on tombe sur un cas où
en enfant est présent à la fois dans la liste des membres d'une relation et
déjà dans la pile, on n'a aucun moyen de retraiter cet objet une deuxième
fois, tout au plus on peut détecter une éventuelle incohérence de tags et
journaliser ce cas, mais on ne doit pas traiter cet enfant à nouveau sans
créer une boucle infinie: il suffit donc juste de savoir, si un objet qui
peut avoir des descendants est déjà en cours de traitement dans la pile, si
oui ne rien faire d'autre, sinon on commence à traiter l'objet en
l'incluant d'abord dans la pile, puis en le retirant une fois le traitement
de cet enfant terminé.




Le 13 décembre 2016 à 22:17, Éric Gillet  a
écrit :

> Le 13 décembre 2016 à 21:27,  a écrit :
>
>> J'ai peut-être la réponse à la longueur du traitement :
>>
>> https://www.openstreetmap.org/relation/6789691 a pour membre :
>>
>>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>>2504515) 
>>et fait partie de :
>>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>>2504515) 
>>
>> Faut-il vraiment le second lien (sans rôle) ? Quelle signification ?
>> Retrouver la relation maîtresse ?
>>
>
> Cela me semble être une erreur, il n'est pas nécessaire de "boucler" comme
> ça les relations. Les outils, notamment Overpass, savent gérer les liens de
> parenté entre les relations.
>
> ___
> 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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Éric Gillet

Le 13 décembre 2016 à 21:27,  a écrit :

> J'ai peut-être la réponse à la longueur du traitement :
>
> https://www.openstreetmap.org/relation/6789691 a pour membre :
>
>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>2504515) 
>et fait partie de :
>- Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération (
>2504515) 
>
> Faut-il vraiment le second lien (sans rôle) ? Quelle signification ?
> Retrouver la relation maîtresse ?
>

Cela me semble être une erreur, il n'est pas nécessaire de "boucler" comme
ça les relations. Les outils, notamment Overpass, savent gérer les liens de
parenté entre les relations.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet osm . sanspourriel


J'ai peut-être la réponse à la longueur du traitement :

https://www.openstreetmap.org/relation/6789691 a pour membre :

 * Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération
   (2504515) 
   et fait partie de :
 * Relation Noctilien N21 : Châtelet → Chilly-Mazarin – Libération
   (2504515) 

Faut-il vraiment le second lien (sans rôle) ? Quelle signification ? 
Retrouver la relation maîtresse ?



Le 13/12/2016 à 13:31, Florian LAINEZ - winner...@free.fr a écrit :
Bon j'ai créé une route_master pour faire le test 
https://www.openstreetmap.org/relation/6789691
à priori j'ai pas fait de connerie, mais c'est teeellement long de 
faire ça à la mano. Je confirme qu'il nous faut un outil plus adapté 
si on veut créer 600 lignes ...




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Philippe Verdy

gt;> 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>
>> <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>
>> <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/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
>>
>>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Philippe Verdy

gt;
> Le 13/12/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>
> <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/
> attachments/20161212/e1a79ea5/attachment-0001.html>
> <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Philippe Verdy

Au passage, concernant Rennes, ce que propose "d'intégrer" Osmose c'est
quasiment du 100% faux positif !!

Bref Osmose est totalement à revoir concernant Rennes (ses règles sont
totalement fausses) !!!

Le 13 décembre 2016 à 20:31, <osm.sanspourr...@spamgourmet.com> a écrit :

> Je parlais en général pour le bien de la communauté, pas pour mon réseau
> local (Lorient a des données sur le portail data.gouv.fr mais pas le
> réseau transport à ma connaissance, Quimperlé n'a pas grand chose en
> disponible : une carte PDF, ce n'est pas ce que l'on fait de mieux, comme
> dit joliment par Christian open mais pas data).
>
> Entièrement d'accord il faut des données libres et stables, je pense que
> pour la STAR (Rennes) c'est le cas.
> Après autant commencer par les principaux réseaux (Nantes, Lille, Lyon,
> Strasbourg... : que ceux qui veulent un cadeau de Noël écrive à la mère
> Noëlle, heu Noémie.
> Merci pour l'offre !
>
> Je pense que la faible couverture de public_transport=stop_position montre
> que c'est une lubie de tagueur fou : pas de réalité sur le terrain (il faut
> observer l'arrêt du bus, pour le train suivant la longueur pourtant on ne
> peut en mettre qu'un (quoique ce n'est pas précisé dans le wiki
> <https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position>)
> et si la voie n'est pas fixe, on va mettre n arrêts ? Si les opérateurs
> disposent de l'info, la publie et que ça tombe sur une voie OSM, OK, sinon
> on tague pour le schéma (ce qui me semble pire que taguer pour le rendu).
> On parle de faciliter l'entrée des nouveaux contributeurs. Là ça vaut
> opening_hours : sans outil adapté c'est galère : tu veux entrer un arrêt de
> bus et tu te manges une relation avec des tags qui feront que ton arrêt ne
> se sera pas affiché.
>
> Jean-Yvon
>
>
>
> Le 13/12/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>
> <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/
> attachments/20161212/e1a79ea5/attachment-0001.html>
> <http://lists.openstreetmap.org/pipermail/talk-fr/attachments/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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet osm . sanspourriel

Je parlais en général pour le bien de la communauté, pas pour mon réseau 
local (Lorient a des données sur le portail data.gouv.fr mais pas le 
réseau transport à ma connaissance, Quimperlé n'a pas grand chose en 
disponible : une carte PDF, ce n'est pas ce que l'on fait de mieux, 
comme dit joliment par Christian open mais pas data).


Entièrement d'accord il faut des données libres et stables, je pense que 
pour la STAR (Rennes) c'est le cas.


Après autant commencer par les principaux réseaux (Nantes, Lille, Lyon, 
Strasbourg... : que ceux qui veulent un cadeau de Noël écrive à la mère 
Noëlle, heu Noémie.

Merci pour l'offre !

Je pense que la faible couverture de public_transport=stop_position 
montre que c'est une lubie de tagueur fou : pas de réalité sur le 
terrain (il faut observer l'arrêt du bus, pour le train suivant la 
longueur pourtant on ne peut en mettre qu'un (quoique ce n'est pas 
précisé dans le wiki 
<https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position>) 
et si la voie n'est pas fixe, on va mettre n arrêts ? Si les opérateurs 
disposent de l'info, la publie et que ça tombe sur une voie OSM, OK, 
sinon on tague pour le schéma (ce qui me semble pire que taguer pour le 
rendu).
On parle de faciliter l'entrée des nouveaux contributeurs. Là ça vaut 
opening_hours : sans outil adapté c'est galère : tu veux entrer un arrêt 
de bus et tu te manges une relation avec des tags qui feront que ton 
arrêt ne se sera pas affiché.


Jean-Yvon


Le 13/12/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/attachments/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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Philippe Verdy

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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Noémie Lehuby


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/attachments/20161212/e1a79ea5/attachment-0001.html>

--



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Philippe Verdy

J'ai dit "ovales" juste pour simplifier, car évidemment ce sont en fait des
formes créées par un polygone convexe englobant tous les arrêts inclus,
élargis par un petit "buffer" créé autour avec des angles arrondis. Ca
donne des formes qui dépendent de la listance entre les arrêts et de leur
nombre (il peut arriver qu'on ait 4 arrêts sur les 4 rues d'un même
carrefour, formant plus ou moins un grand carré, ça donnera une forme qui
ne sera pas nécessairement "oblongue" non plus. On dit en général "ovale"
pour désigner le tracé de tells formes désignant des ensembles dans des
représentations schématiques simplifiées comme c'est le cas ici.

Etant donné l'absence de rendu actuel des platform et stop_position, et que
seuls les bus_stop sont rendus, il faut je pense garder pour l'instant la
redondance bus_stop + platform pour passer au schéma v2 (donc vérifier que
les bus_stop sont bien tous des "platforms", sinon transformer ces noeuds
uniquement en en stop_position et créer un "platform"+"bus_stop" à côté de
la voie.

Et mettre à jour les relations route pour qu'elles incluent les deux
noeuds: rôle "stop" pour le noeud "stop_position", rôle "platform" pour le
noeud (ou le chemin si on a tracé une zone/un quai, voire un abri) avec
"bus_stop"+"platform".

Au passage sur Rennes je fais l'essai sur la ligne C1. J'avais au départ
supprimé les tags "bus_stop" du schéma v1, mais je vais les remettre en
redondance sur les "platform".

Sachant aussi que l'outil "sketchline" (fourni par l'Overpass Turbo)
affichera alors les deux points comme deux arrêts distincts car il traite
"bus_stop" et "stop_position" comme des arrêts distincts (d'autant plus
qu'il ne seront pas à la même position puisque "bus_stop" se retrouvera sur
la "plateform" à côté de la voie alors que "stop_postion" sera sur le
chemin !) on pourrait aussi décider de faire l'inverse :
* garder "bus_stop" (pour les rendus actuels) uniquement sur le noeud
"stop_position", mais alors on verra l'icône au milieu de la chaussée et on
ne verra plus les icones à l'emplacement des stations sur les trottoirs. On
voit que la décision de garder "bus_stop" (sur l'un ou l'autre), est juste
destinée à "taguer pour le rendu". Ce qui montre bien que "bus_stop" est
mal fichu depuis le début et devra à terme être viré des données !!!

Autre anomalie relevée dans le schéma v2: des membres pour les stations
peuvent être ajoutés aux relations "route", mais aucun rôle n'a été défini.
Ces stations sont typiquement des chemins (pour désigner des bâtiments de
gares par exemple). On peut aussi les inclure comme noeuds simples (plus ou
moins centrés sur la zone d'une "gare" ou d'une "stop_area"). Mais pour
inclure un batiment, pas moyen de le faire avec autre chose qu'un seul
chemin fermé. JOSM râle si on y met une relation (pour des batiments
complexes ayant des enclaves par exemple), par ce que la documentation n'a
pas prévu qu'un bâtiment doive être décrit de façon plus compliquée qu'un
seul chemin fermé. Et la documentation du Wiki indique même (à tord !)
"onRelation=no" et semble vouloir l'interdire (ce qui est carrément stupide
ou irréfléchi!).

Au lieu de mettre une telle restriction, il aurait mieux valu prévoir un
rôle particulier "station" pour décrire des noeuds/chemins/relation
destinés à décrire toute une station/gare (laquelle peut avoir même
plusieurs bâtiments proches mais séparés (par exemple deux gares de chaque
côté d'une ligne, reliées par un souterrain, une passerelle, voire encore
un passage à niveau dans les plus petites gares plus rurales, mais
associées aux mêmes arrêts). Et dans l'immédiat je suis pour qu'on retire
la restriction "onrelation=no" pour les bâtiments d'une station/gare (la
documentation de leurs autres tags sont aussi mal fichus, regardez un peu
le détail!).

Ca mériterait d'être discuté sur la page de discussion associée pour une
vue plus internationale: ce schéma v2, bien qu'approuvé depuis des mois
demande à avancer et à être corrigé de ses problèmes !







Le 13 décembre 2016 à 13:05,  a écrit :

> Le 12/12/2016 à 23:06, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> en revanche les "stop_area" sont reconnus par le rendu "Public Transport"
> qui affiche des ovales autour des arrêts "stop_position"
>
> Avec le schéma V1 on a déjà ça avec les highway
> =bus_stop
> 
> comme ici :
>
> http://www.openstreetmap.org/node/717560945#map=18/48.
> 39228/-4.48753=T
>
> Mais on voit que changer un schéma sans prévoir des règles d'adaptation
> des données et des moteurs (de rendu, de calcul d'itinéraire, etc...) n'est
> pas très raisonnable.
>
> De plus ce concept de zone de correspondance est assez fumeux : quand on
> va du point a au point b qui ne sont pas reliés par la même ligne, on va
> accepter de marcher entre les deux stations les plus proches... sauf si ça
> rallonge de

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Florian LAINEZ

Bon j'ai créé une route_master pour faire le test
https://www.openstreetmap.org/relation/6789691
à priori j'ai pas fait de connerie, mais c'est teeellement long de
faire ça à la mano. Je confirme qu'il nous faut un outil plus adapté si on
veut créer 600 lignes ...

Le 13 décembre 2016 à 13:05,  a écrit :

> Le 12/12/2016 à 23:06, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> en revanche les "stop_area" sont reconnus par le rendu "Public Transport"
> qui affiche des ovales autour des arrêts "stop_position"
>
> Avec le schéma V1 on a déjà ça avec les highway
> =bus_stop
> 
> comme ici :
>
> http://www.openstreetmap.org/node/717560945#map=18/48.
> 39228/-4.48753=T
>
> Mais on voit que changer un schéma sans prévoir des règles d'adaptation
> des données et des moteurs (de rendu, de calcul d'itinéraire, etc...) n'est
> pas très raisonnable.
>
> De plus ce concept de zone de correspondance est assez fumeux : quand on
> va du point a au point b qui ne sont pas reliés par la même ligne, on va
> accepter de marcher entre les deux stations les plus proches... sauf si ça
> rallonge de beaucoup le trajet motorisé.
>
> Typiquement au niveau de calcul d'itinéraires on va facilement passer par
> quelques nœuds de convergence des réseaux qui ne seront pas nécessairement
> très proches. Pour rester sur Brest : typiquement les arrêts autour de la
> place de la Liberté, République pour Rennes, etc... même si les arrêts
> n'ont pas le même nom et sans qu'on veuille je crois mettre toutes les
> stations du coin dans une même stop_area - le rendu serait peut-être des
> zones oblongues (ce ne sont pas des ovales) reliés par des traits conne
> c'est souvent schématisé sur des schémas de transports, faire un gros
> polygone/ovale n'aurait pas de sens (5 fois 2 arrêts Liberté* et 1 fois 2
> Multiplexe
> ). Et
> pourtant les gens changent à "Liberté" ou "République".
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet osm . sanspourriel


Le 12/12/2016 à 23:06, Philippe Verdy - verd...@wanadoo.fr a écrit :
en revanche les "stop_area" sont reconnus par le rendu "Public 
Transport" qui affiche des ovales autour des arrêts "stop_position"


Avec le schéma V1 on a déjà ça avec les highway 
=bus_stop 
 
comme ici :


http://www.openstreetmap.org/node/717560945#map=18/48.39228/-4.48753=T

Mais on voit que changer un schéma sans prévoir des règles d'adaptation 
des données et des moteurs (de rendu, de calcul d'itinéraire, etc...) 
n'est pas très raisonnable.


De plus ce concept de zone de correspondance est assez fumeux : quand on 
va du point a au point b qui ne sont pas reliés par la même ligne, on va 
accepter de marcher entre les deux stations les plus proches... sauf si 
ça rallonge de beaucoup le trajet motorisé.


Typiquement au niveau de calcul d'itinéraires on va facilement passer 
par quelques nœuds de convergence des réseaux qui ne seront pas 
nécessairement très proches. Pour rester sur Brest : typiquement les 
arrêts autour de la place de la Liberté, République pour Rennes, etc... 
même si les arrêts n'ont pas le même nom et sans qu'on veuille je crois 
mettre toutes les stations du coin dans une même stop_area - le rendu 
serait peut-être des zones oblongues (ce ne sont pas des ovales) reliés 
par des traits conne c'est souvent schématisé sur des schémas de 
transports, faire un gros polygone/ovale n'aurait pas de sens (5 fois 2 
arrêts Liberté* et 1 fois 2 Multiplexe 
). Et 
pourtant les gens changent à "Liberté" ou "République".


Jean-Yvon

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-13 Par sujet Florian LAINEZ

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  a écrit :

>
>
> Le 12 décembre 2016 à 21:01, Noémie Lehuby 
> 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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet Philippe Verdy

Le 12 décembre 2016 à 21:01, Noémie Lehuby 
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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet osm . sanspourriel

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 !


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet Noémie Lehuby


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.


Ensuite, pour trouver les lignes opendata qui pourraient correspondre, 
j'utilise le code de la ligne (tag ref), donc s'il est manquant, ça 
marche po.

(Il y a une grosse dizaine de lignes dans ce cas)

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.


étudier les cas en erreurs :
on peut se lister les cas où on arrive pas à trouver d'association (sur 
le wiki ?) pour analyser ça et voir si ce sont des données OSM 
correspondant à des lignes qui n'existent plus, ou des erreurs dans 
l'opendata ou dans OSM.
À noter que j'ai aussi vu plusieurs lignes OSM associées à une même 
ligne Opendata : pas sûre que ça soit normal, ça vaudrait le coup de 
regarder ça plus finement.


passer au référentiel des arrêts :
mais j'ai pas encore d'idée de comment tourner l'outil pour que ça soit 
aussi simple que pour les lignes


isoler les lignes complètement manquantes dans OSM :
pour organiser des cartoparties ;)

documenter ça proprement dans le wiki :
pour pas qu'on se demande dans 6 mois à quoi correspond ce 
ref:FR:STIF:ExternalCode_Line obscur.



Bref, il y a de la matière ;)

Noémie

PS : On peut recycler le Mattermost du projet BATO pour ne pas polluer 
la liste : https://framateam.org/bato-fr/channels/stif



Date: Mon, 12 Dec 2016 15:34:00 +0100
From: Florian LAINEZ <winner...@free.fr>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet Florian LAINEZ

OK j'avais un peu de temps libre donc j'ai terminé les 10 premières pages
aussi ;)
Il ne reste donc que les exceptions et les pages où le chargement a buggé.
Noémie tu nous dis quand tu as fait une MAJ ? Merci

Le 12 décembre 2016 à 15:34, Florian LAINEZ  a écrit :

> Bon en plus du réseau Noctilien j'ai fait les pages 10 à 40 (hors erreurs
> comme reporté ci-avant), histoire de bien commencer la semaine.
> Noémie tu peux peut-être faire une mise à jour aujourd'hui ou demain du
> coup ;)
>
> Quelques problèmes supplémentaires que je n'arrive pas à résoudre
> simplement :
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=325
> 6315_code=31
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=674
> 4194_code=4
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=194
> 2584_code=8
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=165
> 0713_code=1
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=
> 1553375_code=341
>
> Le 12 décembre 2016 à 14:17, Florian LAINEZ  a écrit :
>
>>
>> Le 12 décembre 2016 à 13:56, Noémie Lehuby > > a écrit :
>>
>>> Ton premier exemple est un magnifique exemple de ce qu'il ne faut pas
>>> faire :p
>>
>> je suis ravi ! Je n'ai en effet pas été très bon :/
>> J'ai revert mon edit du coup.
>>
>> Le 12 décembre 2016 à 13:56, Noémie Lehuby > > a écrit :
>>
>> La page d'accueil est mise à jour manuelle à partir d'une extraction
>> Osmosis, je me fixe deux mises à jour par semaine (ça suffira ?)
>>
>> Pas moyen d'automatiser ça chaque nuit ? ;)
>> Sinon ça suffira, yes
>>
>> Du coup pour être certain de ne pas mapper les mêmes lignes que les
>> autres j'ai pris les pages 20 à 30.
>> Après quelques lignes de mappées, je commence à prendre le coup de main.
>>
>> Les seules lignes que je n'ai pas réussi à résoudre sont les suivantes :
>> https://ref-lignes-stif.5apps.com/line.html?osm_relation=589
>> 0965_code=95-20
>> https://ref-lignes-stif.5apps.com/line.html?osm_relation=573
>> 6934_code=Q
>> https://ref-lignes-stif.5apps.com/line.html?osm_relation=572
>> 8884_code=L
>> https://ref-lignes-stif.5apps.com/line.html?osm_relation=363
>> 8709_code=6 (serait-ce la proposition 12/13 ?)
>> Ce sont quelques cas particuliers sur lesquels il vaudrait le coup de se
>> plonger ...
>>
>> En plus de cela, on a souvent une erreur "Il y a eu un souci dans
>> l'affichage des données opendata candidates" mais j'imagine que c'est parce
>> que l'algo n'arrive tout simplement pas à faire de suggestion
>> d'association, n'est-ce-pas ?
>>
>> Je monopolise la conversation mais c'est normal : je trouve que cet outil
>> est juste incroyable ;)
>> J'en oublie même d'aller déjeuner, c'est dire.
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>>
>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>



-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet Florian LAINEZ

Bon en plus du réseau Noctilien j'ai fait les pages 10 à 40 (hors erreurs
comme reporté ci-avant), histoire de bien commencer la semaine.
Noémie tu peux peut-être faire une mise à jour aujourd'hui ou demain du
coup ;)

Quelques problèmes supplémentaires que je n'arrive pas à résoudre
simplement :
https://ref-lignes-stif.5apps.com/line.html?osm_relation=
3256315_code=31
https://ref-lignes-stif.5apps.com/line.html?osm_relation=6744194_code=4
https://ref-lignes-stif.5apps.com/line.html?osm_relation=1942584_code=8
https://ref-lignes-stif.5apps.com/line.html?osm_relation=1650713_code=1
https://ref-lignes-stif.5apps.com/line.html?osm_relation=1553375_code=341

Le 12 décembre 2016 à 14:17, Florian LAINEZ  a écrit :

>
> Le 12 décembre 2016 à 13:56, Noémie Lehuby 
> a écrit :
>
>> Ton premier exemple est un magnifique exemple de ce qu'il ne faut pas
>> faire :p
>
> je suis ravi ! Je n'ai en effet pas été très bon :/
> J'ai revert mon edit du coup.
>
> Le 12 décembre 2016 à 13:56, Noémie Lehuby 
> a écrit :
>
> La page d'accueil est mise à jour manuelle à partir d'une extraction
> Osmosis, je me fixe deux mises à jour par semaine (ça suffira ?)
>
> Pas moyen d'automatiser ça chaque nuit ? ;)
> Sinon ça suffira, yes
>
> Du coup pour être certain de ne pas mapper les mêmes lignes que les autres
> j'ai pris les pages 20 à 30.
> Après quelques lignes de mappées, je commence à prendre le coup de main.
>
> Les seules lignes que je n'ai pas réussi à résoudre sont les suivantes :
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=589
> 0965_code=95-20
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=573
> 6934_code=Q
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=572
> 8884_code=L
> https://ref-lignes-stif.5apps.com/line.html?osm_relation=363
> 8709_code=6 (serait-ce la proposition 12/13 ?)
> Ce sont quelques cas particuliers sur lesquels il vaudrait le coup de se
> plonger ...
>
> En plus de cela, on a souvent une erreur "Il y a eu un souci dans
> l'affichage des données opendata candidates" mais j'imagine que c'est parce
> que l'algo n'arrive tout simplement pas à faire de suggestion
> d'association, n'est-ce-pas ?
>
> Je monopolise la conversation mais c'est normal : je trouve que cet outil
> est juste incroyable ;)
> J'en oublie même d'aller déjeuner, c'est dire.
>
> --
>
> *Florian Lainez*
> @overflorian 
>



-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet Florian LAINEZ

Le 12 décembre 2016 à 13:56, Noémie Lehuby 
a écrit :

> Ton premier exemple est un magnifique exemple de ce qu'il ne faut pas
> faire :p

je suis ravi ! Je n'ai en effet pas été très bon :/
J'ai revert mon edit du coup.

Le 12 décembre 2016 à 13:56, Noémie Lehuby 
a écrit :

La page d'accueil est mise à jour manuelle à partir d'une extraction
Osmosis, je me fixe deux mises à jour par semaine (ça suffira ?)

Pas moyen d'automatiser ça chaque nuit ? ;)
Sinon ça suffira, yes

Du coup pour être certain de ne pas mapper les mêmes lignes que les autres
j'ai pris les pages 20 à 30.
Après quelques lignes de mappées, je commence à prendre le coup de main.

Les seules lignes que je n'ai pas réussi à résoudre sont les suivantes :
https://ref-lignes-stif.5apps.com/line.html?osm_relation=589
0965_code=95-20
https://ref-lignes-stif.5apps.com/line.html?osm_relation=5736934_code=Q
https://ref-lignes-stif.5apps.com/line.html?osm_relation=5728884_code=L
https://ref-lignes-stif.5apps.com/line.html?osm_relation=3638709_code=6
(serait-ce la proposition 12/13 ?)
Ce sont quelques cas particuliers sur lesquels il vaudrait le coup de se
plonger ...

En plus de cela, on a souvent une erreur "Il y a eu un souci dans
l'affichage des données opendata candidates" mais j'imagine que c'est parce
que l'algo n'arrive tout simplement pas à faire de suggestion
d'association, n'est-ce-pas ?

Je monopolise la conversation mais c'est normal : je trouve que cet outil
est juste incroyable ;)
J'en oublie même d'aller déjeuner, c'est dire.

-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet Noémie Lehuby


Hello,

merci pour tes retours Florian ! Je vais voir ce que je peux faire pour 
améliorer l'ergonomie et la compréhension de l'outil.


Ton premier exemple est un magnifique exemple de ce qu'il ne faut pas 
faire :p
tu as associé la ligne OSM 65, du réseau RATP avec la ligne 65 du réseau 
Pays de l'Ourcq...

https://ref-lignes-stif.5apps.com/line.html?osm_relation=954977_code=65

Si les arrêts noirs et bleus se superposent, c'est qu'il y a des chances 
pour que ça soit la même ligne.
Perso, je regarde d'abord si les propriétés de la ligne sont cohérentes 
et si ça semble ok je checke si les arrêts sont cohérents.


Pour le moment, l'outil ajoute juste le code ExternalCode_Line du 
fichier opendata du STIF, car il est lié à l'offre de transport (donc je 
sais que je peux l'utiliser pour afficher les arrêts de la ligne).
Le ref:FR:STIF est celui qui était déjà dans OSM avant que le STIF ne 
mette son référentiel en opendata, celui dont on sait pas bien si c'est 
un code RATP ou un vieux ref STIF plus valide.


La page d'accueil est mise à jour manuelle à partir d'une extraction 
Osmosis, je me fixe deux mises à jour par semaine (ça suffira ?)


Noémie


Date: Mon, 12 Dec 2016 12:53:09 +0100
From: Florian LAINEZ <winner...@free.fr>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<CALZSDK+5nrcMnUm3B9g31zK=md=R_9F10f=qdaD+=mpt57q...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Bon en fait je n'ai pas pu résister et j'ai terminé le réseau 
Noctilien.

C'est surement celui où il y a le moins d'incertitude et donc d'erreur
potentielle.
ça va vraiment super vite quand tu as bien compris comment l'outil
fonctionne.

La liste ne montre pas les nouvelles associations que j'ai créé. à 
quelle

fréquence se met-elle à jour ?
Merci

Le 12 décembre 2016 à 11:42, Florian LAINEZ <winner...@free.fr> a écrit 
:



Noémie, es-tu une machine venue du futur pour révolutionner la
contribution sur les arrêts de transport ??! Ton outil déchire.

J'ai essayé sur une seule ligne pour l'instant pour être certain de
comprendre : https://ref-lignes-stif.5apps.com/line.html?osm_relation=
954977_code=65
Donc ton outil a rajouté ref:FR:STIF:ExternalCode_Line=067067065:65 à 
la

relation https://www.openstreetmap.org/relation/954977
Si ref:FR:STIF=1001000650001 n'avait pas déjà été présent, il l'aurait
rajouté ?

Autre exemple : 
https://ref-lignes-stif.5apps.com/line.html?osm_relation=

5865473_code=119
On voit que les arrêts en noir sont grosso-modo superposés à la ligne 
en
bleue, donc même si les noms ne sont pas les mêmes, tu considères que 
c'est
ok pour intégration ? Quels éléments pourraient nous aider à prendre 
notre

décision ?

Quelques remarques :
-sur les pages "lignes" :
   >on ne sait pas si OSM est à gauche ou à droite. Tu devrais 
rajouter un

titre "OSM" et "Open Data".
   >même remarque pour les attributs de ces lignes : parfois il y a 
juste

écrit "undefined" mais on ne sait pas ce que c'est.
   >ce n'est pas clair si les données OSM sont en bleu ou noir : tu
devrais rajouter une légende à ton plan.
   >lorsque l'on clique sur "voir le détail" sur un popup noir sur la
carte, ça nous renvoie vers une requête Navitia. C'est cool et c'est
sûrement le comportement attendu pour vérifier l'info. Néanmoins on a 
pas
de token donc on tombe sur un message d'erreur. Tu pourrais créer un 
accès

dédiée pour ton appli ?

Trop cool en tout cas ton outil, ça va sûrement nous permettre de 
terminer

l'association des lignes en quelques semaines seulement.

PS : marrant le commentaire du changeset : "created_by OpenBeerMap
javascript editor" > ça sent le fork à plein nez !

Le 11 décembre 2016 à 11:55, Noémie Lehuby 
<noemie.leh...@openmailbox.org>

a écrit :


Bonjour,

j'ai publié une première version d'un outil qui permet déjà de 
commencer

le travail :
https://ref-lignes-stif.5apps.com/

Je continuerai de l'améliorer dans la semaine.
Noémie

Date: Tue, 6 Dec 2016 01:42:47 +0100

From: Jérôme Amagat <jerome.ama...@gmail.com>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<cahuxktlxk8o2nf406quwfbmmpfez4unuy7g-afxtghwscth...@mail.gm
ail.com>
Content-Type: text/plain; charset="utf-8"

Le 5 décembre 2016 à 21:49, Noémie Lehuby 
<noemie.leh...@openmailbox.org>

a
écrit :

Bonsoir,


Pour les objets existants : http://taginfo.openstreetmap.f
r/keys/?key=ref:FR:STIF
à noter que comme le signale Jérôme, il y a aussi quelques 
ref:FR:stif

http://taginfo.openstreetmap.fr/keys/?key=ref:FR:stif

Je ne maîtrise pas bien Osmose : ça marche aussi pour les relations 
sans

composante géographique ?


Pour l'instant, dans osmose, l'ajout de donnée externe c'est l'ajout 
d'un
node ou

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet Florian LAINEZ

Bon en fait je n'ai pas pu résister et j'ai terminé le réseau Noctilien.
C'est surement celui où il y a le moins d'incertitude et donc d'erreur
potentielle.
ça va vraiment super vite quand tu as bien compris comment l'outil
fonctionne.

La liste ne montre pas les nouvelles associations que j'ai créé. à quelle
fréquence se met-elle à jour ?
Merci

Le 12 décembre 2016 à 11:42, Florian LAINEZ <winner...@free.fr> a écrit :

> Noémie, es-tu une machine venue du futur pour révolutionner la
> contribution sur les arrêts de transport ??! Ton outil déchire.
>
> J'ai essayé sur une seule ligne pour l'instant pour être certain de
> comprendre : https://ref-lignes-stif.5apps.com/line.html?osm_relation=
> 954977_code=65
> Donc ton outil a rajouté ref:FR:STIF:ExternalCode_Line=067067065:65 à la
> relation https://www.openstreetmap.org/relation/954977
> Si ref:FR:STIF=1001000650001 n'avait pas déjà été présent, il l'aurait
> rajouté ?
>
> Autre exemple : https://ref-lignes-stif.5apps.com/line.html?osm_relation=
> 5865473_code=119
> On voit que les arrêts en noir sont grosso-modo superposés à la ligne en
> bleue, donc même si les noms ne sont pas les mêmes, tu considères que c'est
> ok pour intégration ? Quels éléments pourraient nous aider à prendre notre
> décision ?
>
> Quelques remarques :
> -sur les pages "lignes" :
>>on ne sait pas si OSM est à gauche ou à droite. Tu devrais rajouter un
> titre "OSM" et "Open Data".
>>même remarque pour les attributs de ces lignes : parfois il y a juste
> écrit "undefined" mais on ne sait pas ce que c'est.
>>ce n'est pas clair si les données OSM sont en bleu ou noir : tu
> devrais rajouter une légende à ton plan.
>>lorsque l'on clique sur "voir le détail" sur un popup noir sur la
> carte, ça nous renvoie vers une requête Navitia. C'est cool et c'est
> sûrement le comportement attendu pour vérifier l'info. Néanmoins on a pas
> de token donc on tombe sur un message d'erreur. Tu pourrais créer un accès
> dédiée pour ton appli ?
>
> Trop cool en tout cas ton outil, ça va sûrement nous permettre de terminer
> l'association des lignes en quelques semaines seulement.
>
> PS : marrant le commentaire du changeset : "created_by OpenBeerMap
> javascript editor" > ça sent le fork à plein nez !
>
> Le 11 décembre 2016 à 11:55, Noémie Lehuby <noemie.leh...@openmailbox.org>
> a écrit :
>
>> Bonjour,
>>
>> j'ai publié une première version d'un outil qui permet déjà de commencer
>> le travail :
>> https://ref-lignes-stif.5apps.com/
>>
>> Je continuerai de l'améliorer dans la semaine.
>> Noémie
>>
>> Date: Tue, 6 Dec 2016 01:42:47 +0100
>>> From: Jérôme Amagat <jerome.ama...@gmail.com>
>>> To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
>>> Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
>>> Message-ID:
>>> <cahuxktlxk8o2nf406quwfbmmpfez4unuy7g-afxtghwscth...@mail.gm
>>> ail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Le 5 décembre 2016 à 21:49, Noémie Lehuby <noemie.leh...@openmailbox.org>
>>> a
>>> écrit :
>>>
>>> Bonsoir,
>>>>
>>>> Pour les objets existants : http://taginfo.openstreetmap.f
>>>> r/keys/?key=ref:FR:STIF
>>>> à noter que comme le signale Jérôme, il y a aussi quelques ref:FR:stif
>>>> http://taginfo.openstreetmap.fr/keys/?key=ref:FR:stif
>>>>
>>>> Je ne maîtrise pas bien Osmose : ça marche aussi pour les relations sans
>>>> composante géographique ?
>>>>
>>>>
>>> Pour l'instant, dans osmose, l'ajout de donnée externe c'est l'ajout d'un
>>> node ou l'ajout de tag sur un objet déjà existant. Donc dans notre cas,
>>> ça
>>> marche bien pour ajouter les arrêts de bus.
>>>
>>>
>>> Parce que les lignes de transport, l'objet OSM qui correspond le plus, ça
>>>> sera la relation route_master (dont les éléments sont exclusivement
>>>> d'autres relations) et qui ne se représente pas bien sur une carte.
>>>>
>>>>
>>> Dans osm, oui c'est une relation route_master qui représente la  ligne de
>>> bus mais il faut y placer des relation type=route et route=bus comme
>>> indiqué là : https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus
>>> On en crée une pour le trajet du bus à l’allée une autre pour le retour
>>> (voir encore plein d'autres si la ligne de bus a des variantes) et après
>>> on
>>> met c'est différentes relations dans

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-12 Par sujet Florian LAINEZ

Noémie, es-tu une machine venue du futur pour révolutionner la contribution
sur les arrêts de transport ??! Ton outil déchire.

J'ai essayé sur une seule ligne pour l'instant pour être certain de
comprendre :
https://ref-lignes-stif.5apps.com/line.html?osm_relation=954977_code=65
Donc ton outil a rajouté ref:FR:STIF:ExternalCode_Line=067067065:65 à la
relation https://www.openstreetmap.org/relation/954977
Si ref:FR:STIF=1001000650001 n'avait pas déjà été présent, il l'aurait
rajouté ?

Autre exemple :
https://ref-lignes-stif.5apps.com/line.html?osm_relation=5865473_code=119
On voit que les arrêts en noir sont grosso-modo superposés à la ligne en
bleue, donc même si les noms ne sont pas les mêmes, tu considères que c'est
ok pour intégration ? Quels éléments pourraient nous aider à prendre notre
décision ?

Quelques remarques :
-sur les pages "lignes" :
   >on ne sait pas si OSM est à gauche ou à droite. Tu devrais rajouter un
titre "OSM" et "Open Data".
   >même remarque pour les attributs de ces lignes : parfois il y a juste
écrit "undefined" mais on ne sait pas ce que c'est.
   >ce n'est pas clair si les données OSM sont en bleu ou noir : tu devrais
rajouter une légende à ton plan.
   >lorsque l'on clique sur "voir le détail" sur un popup noir sur la
carte, ça nous renvoie vers une requête Navitia. C'est cool et c'est
sûrement le comportement attendu pour vérifier l'info. Néanmoins on a pas
de token donc on tombe sur un message d'erreur. Tu pourrais créer un accès
dédiée pour ton appli ?

Trop cool en tout cas ton outil, ça va sûrement nous permettre de terminer
l'association des lignes en quelques semaines seulement.

PS : marrant le commentaire du changeset : "created_by OpenBeerMap
javascript editor" > ça sent le fork à plein nez !

Le 11 décembre 2016 à 11:55, Noémie Lehuby <noemie.leh...@openmailbox.org>
a écrit :

> Bonjour,
>
> j'ai publié une première version d'un outil qui permet déjà de commencer
> le travail :
> https://ref-lignes-stif.5apps.com/
>
> Je continuerai de l'améliorer dans la semaine.
> Noémie
>
> Date: Tue, 6 Dec 2016 01:42:47 +0100
>> From: Jérôme Amagat <jerome.ama...@gmail.com>
>> To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
>> Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
>> Message-ID:
>> <cahuxktlxk8o2nf406quwfbmmpfez4unuy7g-afxtghwscth...@mail.gm
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Le 5 décembre 2016 à 21:49, Noémie Lehuby <noemie.leh...@openmailbox.org>
>> a
>> écrit :
>>
>> Bonsoir,
>>>
>>> Pour les objets existants : http://taginfo.openstreetmap.f
>>> r/keys/?key=ref:FR:STIF
>>> à noter que comme le signale Jérôme, il y a aussi quelques ref:FR:stif
>>> http://taginfo.openstreetmap.fr/keys/?key=ref:FR:stif
>>>
>>> Je ne maîtrise pas bien Osmose : ça marche aussi pour les relations sans
>>> composante géographique ?
>>>
>>>
>> Pour l'instant, dans osmose, l'ajout de donnée externe c'est l'ajout d'un
>> node ou l'ajout de tag sur un objet déjà existant. Donc dans notre cas, ça
>> marche bien pour ajouter les arrêts de bus.
>>
>>
>> Parce que les lignes de transport, l'objet OSM qui correspond le plus, ça
>>> sera la relation route_master (dont les éléments sont exclusivement
>>> d'autres relations) et qui ne se représente pas bien sur une carte.
>>>
>>>
>> Dans osm, oui c'est une relation route_master qui représente la  ligne de
>> bus mais il faut y placer des relation type=route et route=bus comme
>> indiqué là : https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus
>> On en crée une pour le trajet du bus à l’allée une autre pour le retour
>> (voir encore plein d'autres si la ligne de bus a des variantes) et après
>> on
>> met c'est différentes relations dans une relation route_master qui
>> représente toute la ligne de bus.
>> Comme il faut mettre dans c'est relation les bon morceaux de route
>> qu'empruntent les bus je pense pas qu'osmose ou un autre outil puissent le
>> faire à notre place.
>>
>>
>>> Et je préférerais qu'on commence par les lignes avant d'attaquer les
>>> point
>>> d'arrêts et zones d'arrêts (un peu comme avec les adresses, où on
>>> commence
>>> par faire matcher les communes, puis les rues). Ça permettra d'être plus
>>> fin et d'éviter d'attribuer la référence de l'arrêt qui est en fait de
>>> l'autre côté de la rue, voire de créer des arrêts parce qu'on en a deux
>>> dans les données du STIF alors qu'il n'y a bien qu'un unique arrêt sur le
>>> terra

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-11 Par sujet Noémie Lehuby


Bonjour,

j'ai publié une première version d'un outil qui permet déjà de commencer 
le travail :

https://ref-lignes-stif.5apps.com/

Je continuerai de l'améliorer dans la semaine.
Noémie


Date: Tue, 6 Dec 2016 01:42:47 +0100
From: Jérôme Amagat <jerome.ama...@gmail.com>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<cahuxktlxk8o2nf406quwfbmmpfez4unuy7g-afxtghwscth...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Le 5 décembre 2016 à 21:49, Noémie Lehuby 
<noemie.leh...@openmailbox.org> a

écrit :


Bonsoir,

Pour les objets existants : http://taginfo.openstreetmap.f
r/keys/?key=ref:FR:STIF
à noter que comme le signale Jérôme, il y a aussi quelques ref:FR:stif
http://taginfo.openstreetmap.fr/keys/?key=ref:FR:stif

Je ne maîtrise pas bien Osmose : ça marche aussi pour les relations 
sans

composante géographique ?



Pour l'instant, dans osmose, l'ajout de donnée externe c'est l'ajout 
d'un
node ou l'ajout de tag sur un objet déjà existant. Donc dans notre cas, 
ça

marche bien pour ajouter les arrêts de bus.


Parce que les lignes de transport, l'objet OSM qui correspond le plus, 
ça

sera la relation route_master (dont les éléments sont exclusivement
d'autres relations) et qui ne se représente pas bien sur une carte.



Dans osm, oui c'est une relation route_master qui représente la  ligne 
de

bus mais il faut y placer des relation type=route et route=bus comme
indiqué là : https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus
On en crée une pour le trajet du bus à l’allée une autre pour le retour
(voir encore plein d'autres si la ligne de bus a des variantes) et 
après on

met c'est différentes relations dans une relation route_master qui
représente toute la ligne de bus.
Comme il faut mettre dans c'est relation les bon morceaux de route
qu'empruntent les bus je pense pas qu'osmose ou un autre outil puissent 
le

faire à notre place.



Et je préférerais qu'on commence par les lignes avant d'attaquer les 
point
d'arrêts et zones d'arrêts (un peu comme avec les adresses, où on 
commence
par faire matcher les communes, puis les rues). Ça permettra d'être 
plus

fin et d'éviter d'attribuer la référence de l'arrêt qui est en fait de
l'autre côté de la rue, voire de créer des arrêts parce qu'on en a 
deux
dans les données du STIF alors qu'il n'y a bien qu'un unique arrêt sur 
le

terrain.



Il y en a 2, un pour chaque coté de la route?
Osmose permet de placer un point exactement où le stif le place lui. et
comme il les place sur ce que j'ai vu bien 1 de chaque coté de la route 
il

n'y a pas de problème?
Comme dans les relations il faut mettre les arrêts, si il existent déjà 
je

pense que c'est plus simple.

Si je dis des bêtises n’hésitez pas à rectifier j'ai déjà toucher se 
genre
de relation quand elles existaient déjà mais j'en ai pas vraiment 
créer.




nlehuby

Date: Mon, 5 Dec 2016 20:48:17 +0100

From: Jérôme Amagat <jerome.ama...@gmail.com>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<CAHUxktL+txPNO5nXZPK8QuV9B0QMupK=AqUdPvYwu9TFnHF_4A@mail.
gmail.com>
Content-Type: text/plain; charset="utf-8"


J'ai regardé un peu les données.
Déjà pour les arrêts les "Zones d'Embarquement d'Île-de-France (ZDE)" 
(les

public_transport=platform dans osm) les coordonnées semble de bonne
qualité. (pour les noms par contre c'est pas homogène certains sont 
tout

en
majuscule d'autres non, avec bien sur des problèmes avec les accents 
non

présents sur les majuscules)
C'est un bon candidat pour osmose je pense. (les tags ajoutés 
seraient

public_transport=platform name=* et pour les arrêt de bus :
highway=bus_stop bus=yes il y a aussi les arrêts de tram et métro)
Pour les autres données : Zone de Lieu (ZDL) Lieu d’arrêt (LDA)
possibilité
de créer une relation public_transport = stop_area qui regroupe des
platforms mais je sais pas pour lequel des 2 et c'est plus compliqué 
pour

osmose.

Par contre les ref: il y en a beaucoup dans les fichiers. je dirais 
qu'il
faut utiliser ref:FR:STIF et c'est suivant les autres tags que l'on 
sait

quel ref c'est.
par contre pour les arrêts, il y a un ID_REFA avec les "Zones
d'Embarquement" et dans le fichier "Arrêts par lignes de transport en
commun en Ile-de-France" il y a un stop_id (qui peut être par exemple
"StopPoint:81:255"). c'est une partie des valeurs déjà présentent 
dans

osm.
Dans osm il y a des ref:FR:STIF (http://overpass-turbo.eu/s/kty) et 
des

ref:FR:stif (http://overpass-turbo.eu/s/ktA)

Le 5 décembre 2016 à 08:49, Florian LAINEZ <winner...@free.fr> a 
écrit :


Salut Noémie,
L'identifiant ref:FR:STIF me parait également le plus pérenne et 
donc il
devrait être préféré systématiquement. Ceci dit, il n'y a aucun 
problème

à
ajouter le code te

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-09 Par sujet Frédéric Rodrigo


Le 09/12/2016 à 09:07, Florian LAINEZ a écrit :

hey,

Le 8 décembre 2016 à 20:49, Noémie Lehuby 
> 
a écrit :


Rah ... du coup, j'ai commencé un outil web pour visualiser les
lignes dans les deux systèmes et faciliter la mise en
correspondance :p
J'essaye d'en publier une première version ce week-end.


Absolument génial !

Le 8 décembre 2016 à 23:08, Frédéric Rodrigo > a écrit :


Pour ce qui est du GTFS je ne vois pas en quoi ça peut aider.


Si j'ai bien compris la démonstration de Noémie, les données dans le 
GTFS sont bien plus exploitables que celles en Open Data. Tu penses 
que la qualité n'est toujours pas suffisante pour faire du bon boulot ?


Je pense sur tout que ça être très variable :
- sur la position
- su la précision spatiale
- sur les la présence de ref stable (via jointure ou non)

En l'état avec Osmose on peut déjà faire les stops via les l’analyseur 
de rapprochement OpenData (simple fichier CSV dans un ZIP).


Pour les autres ça restera à faire et surtout à déterminer ce qu'il 
faudrait essayer de faire.


Frédéric.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-09 Par sujet Florian LAINEZ

hey,

Le 8 décembre 2016 à 20:49, Noémie Lehuby  a
écrit :

> Rah ... du coup, j'ai commencé un outil web pour visualiser les lignes
> dans les deux systèmes et faciliter la mise en correspondance :p
> J'essaye d'en publier une première version ce week-end.
>

Absolument génial !

Le 8 décembre 2016 à 23:08, Frédéric Rodrigo  a
écrit :

> Pour ce qui est du GTFS je ne vois pas en quoi ça peut aider.
>

Si j'ai bien compris la démonstration de Noémie, les données dans le GTFS
sont bien plus exploitables que celles en Open Data. Tu penses que la
qualité n'est toujours pas suffisante pour faire du bon boulot ?


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-08 Par sujet Frédéric Rodrigo

C'est à cause de cette indécidabilité que j'avais arrêté d'essayer de 
valider et de dédupliquer les arrêts de bus avec Osmose.


D'ailleurs Florian j'avais pour cette raison évoqué avec la toi l'idée 
de faire de BATO une base des stop area plutôt que des stops.


Pour ce qui est du GTFS je ne vois pas en quoi ça peut aider.


Le 07/12/2016 à 20:48, Florian LAINEZ a écrit :

Très intéressante démonstration Noémie.
Du coup peut-être en effet devrions-nous attendre de pouvoir exploiter 
le GTFS avant de se lancer dans l'intégration des données STIF ...

Fred tu penses que ça pourrait passer sur la liste au père-noël ? ;)

Le 7 décembre 2016 à 11:15, Noémie Lehuby 
<noemie.leh...@openmailbox.org <mailto:noemie.leh...@openmailbox.org>> 
a écrit :


Bref, vous voulez pas qu'on commence par les lignes / relations
route_master, et qu'ensuite on voit comment on peut redescendre
sur les relations route, puis les relations stop_area et les
noeuds  public_transport = platform?

pourquoi pas mais on fait comment ? Il me semble qu'il nous manque 
pour l'instant un outil pour faire le boulot efficacement, /n'est-il 
pas/ ?





Le 07/12/2016 à 11:15, Noémie Lehuby a écrit :

Bonjour,

Je ne suis pas favorable à l'utilisation d'Osmose pour intégrer les 
codes des points d'arrêts, du moins pour le moment. Je pense que ça 
risque d'induire des erreurs chiantes à redresser par la suite.
Déjà parce qu'on ne va pas forcément avoir une relation 1 1 entre les 
deux référentiels.

Voir par exemple ce cas :
https://framapic.org/xhAIOVchGrbR/GusjVGKbAd0L.png
(bleu STIF, rose OSM)
les données OSM sont conformes au terrain : il y a en effet uniquement 
deux arrêts de bus
les données du STIF ont une qualité honorable, mais présentent un 
couple d'arrêt pour chaque transporteur qui s'arrête à cet endroit


Et à part pour les cas simples (par exemple un arrêt bien isolé), je 
ne vois pas trop comment on peut déterminer quel est l'arrêt qui 
matche côté STIF sans s'aider des lignes qui y passent.
Une intégration en s'appuyant sur la base des données transport 
globales (GTFS par exemple) est en effet à mon avis beaucoup plus 
pertinente.
Par exemple sur ce cas-là, ça me semble loin d'être évident de voir 
quel arrêt OSM correspond à quel(s) arrêt(s) STIF.

https://framapic.org/k9Pz6OezPUAu/WKoTWeaYyLSm.png
(vert STIF, rose OSM)


Bref, vous voulez pas qu'on commence par les lignes / relations 
route_master, et qu'ensuite on voit comment on peut redescendre sur 
les relations route, puis les relations stop_area et les noeuds  
public_transport = platform?


Noémie


Date: Wed, 7 Dec 2016 02:05:13 +0100
From: Jérôme Amagat <jerome.ama...@gmail.com>
To: Discussions sur OSM en français <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<cahuxktjnsian5go6iomysnqra-cskg9ucufnva2rrfbszrj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier 
sauf 1

c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
fichier pour passer du
ZDEr_ID_REF_A au stop_id


Le 6 décembre 2016 à 22:20, Florian LAINEZ <winner...@free.fr> a écrit :


Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de
passer à une autre échelle.
Fred tu comptes l'implémenter du coup ?
Comment comptes-tu gérer l'évolution des données sources dans le 
temps ?

Autant avec un jeu de données statiques tu peux valider/ignorer un POI,
autant si les données évoluent il faut être certain de disposer d'un
identifiant pérenne.

Fred en attendant peut-être vaut-il déjà intégrer les données 
statiques du

STIF comme première étape.
Merci



Le 6 décembre 2016 à 20:44, Frédéric Rodrigo <fred.rodr...@gmail.com> a
écrit :


Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :



Le 6 décembre 2016 à 13:45, Christian Quest <cqu...@openstreetmap.fr
<mailto:cqu...@openstreetmap.fr>> a écrit :

J'ai regardé dans mon quartier desservi par la RATP... c'est
"correct" à 50m près.

J'en ai à peu près le même souvenir. J'ai checké une belle quantité
d'arrêts autour de gares Transilien cet été, j'en ai trouvé 
certains sur

les quais de gares ... d'autres très bien placés.

Le STIF agrégeant des données provenant d'une multitude de
sociétés de transport, la qualité géométrique n'est sûrement pas
homogène

exactement.

Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre 
ref:FR:STIF,

merci

Au passage je vous signale cette issues sur osmose-backend:


https://github.com/osm-fr/osmose-backend/issues/163

qui propose de faire la même chose à un niveau industriel.




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-08 Par sujet Noémie Lehuby


Bonsoir,

Rah ... du coup, j'ai commencé un outil web pour visualiser les lignes 
dans les deux systèmes et faciliter la mise en correspondance :p

J'essaye d'en publier une première version ce week-end.

C'est justement parce que les relations route_master ne portent pas de 
géométrie que ta requête Overpass (avec une bbox) ne ressort rien 
Jérôme.
Je ne suis pas assez balèze en overpass pour te filer une requête qui 
marche. Mais j'ai fait une extraction osmosis vite fait (sur des données 
de juillet que j'avais en local, dsl c'est un peu vieux) et j'ai 354 
relations route_master. (Du coup, t'as raison, il en manque un sacret 
paquet par rapport à ce que nous dit le STIF)
Je commencerais bien par trouver les références STIF de celles qu'on a 
déjà.
L'idée de créer les lignes manquantes à partir des infos du STIF me 
semble aussi en effet mauvaise, surtout si on n'est pas capables pour le 
moment de les créer avec des membres.
Mais le fait de faire correspondre nos lignes avec celles du STIF nous 
permettra déjà d'évaluer la complétude pour pourquoi pas cibler les 
coins où il faut vraiment faire des cartoparties / les coins où il faut 
faire un peu de ménage et d'uniformisation sur les données existantes ;)


Noémie


Date: Wed, 7 Dec 2016 20:48:30 +0100
From: Florian LAINEZ <winner...@free.fr>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<calzsdkjegack_hqh+by0sojnpqkhd-3xx-pdmtmkznqvwf-...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Très intéressante démonstration Noémie.
Du coup peut-être en effet devrions-nous attendre de pouvoir exploiter 
le

GTFS avant de se lancer dans l'intégration des données STIF ...
Fred tu penses que ça pourrait passer sur la liste au père-noël ? ;)

Le 7 décembre 2016 à 11:15, Noémie Lehuby 
<noemie.leh...@openmailbox.org> a

écrit :


Bref, vous voulez pas qu'on commence par les lignes / relations
route_master, et qu'ensuite on voit comment on peut redescendre sur 
les

relations route, puis les relations stop_area et les noeuds
public_transport = platform?


pourquoi pas mais on fait comment ? Il me semble qu'il nous manque pour
l'instant un outil pour faire le boulot efficacement, *n'est-il pas* ?

--

*Florian Lainez*
@overflorian <http://twitter.com/overflorian>
-- section suivante --
Une pièce jointe HTML a été nettoyée...
URL:
<http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161207/e54f7f34/attachment-0001.html>

--

Message: 2
Date: Thu, 8 Dec 2016 02:13:35 +0100
From: Jérôme Amagat <jerome.ama...@gmail.com>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<CAHUxktKgO5tR8YE4aEvzJOiBqiu9ddM+tGMd4fYduf=LvPa=r...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Le 7 décembre 2016 à 20:48, Florian LAINEZ <winner...@free.fr> a écrit 
:



Très intéressante démonstration Noémie.
Du coup peut-être en effet devrions-nous attendre de pouvoir exploiter 
le

GTFS avant de se lancer dans l'intégration des données STIF ...
Fred tu penses que ça pourrait passer sur la liste au père-noël ? ;)

Le 7 décembre 2016 à 11:15, Noémie Lehuby 
<noemie.leh...@openmailbox.org>

a écrit :


Bref, vous voulez pas qu'on commence par les lignes / relations
route_master, et qu'ensuite on voit comment on peut redescendre sur 
les

relations route, puis les relations stop_area et les noeuds
public_transport = platform?


pourquoi pas mais on fait comment ? Il me semble qu'il nous manque 
pour

l'instant un outil pour faire le boulot efficacement, *n'est-il pas* ?

Dans osm on peut pas créer des relations sans rien mettre dedans 
(enfin ça
doit être possible mais la relation est tout de suite perdu) il faut 
une

géométrie à lui accrocher. Seul les node ont des coordonnées si une
relation n'est pas lié de près ou de loin à un node elle est nulle 
part.

Les relations route master sont reliés qu'a d'autres relations les
relations route qui elles sont relié aux arrêts et aux routes entre les
arrêts.
ces route entre les arrêts je vois pas comment ça pourrait être fait
autrement qu'"à la main par des gens"
les arrêts, on a des données avec des coordonnées pas trop mal c'est 
pour

intégré ce genre de données qu'osmose est utile.
après si on a les arrêts avec les bonnes "ref" dans osm, un "outil" 
peut
créer les relation (route ou route master) ou vérifier quels sont 
justes

avec les donnée GTFS ou d'autres données.
Mais dans l'autre sens je vois pas comment.

Par contre, ce qui est possible et utile c'est se mettre d'accord sur 
les

tags à mettre dans les relations d’après les données qu'on a (quel ref,
quel name ...) pour avoir des données dans osm homogènes. pareil sur la
façon de créer les relatio

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-07 Par sujet Jérôme Amagat

Le 7 décembre 2016 à 20:48, Florian LAINEZ  a écrit :

> Très intéressante démonstration Noémie.
> Du coup peut-être en effet devrions-nous attendre de pouvoir exploiter le
> GTFS avant de se lancer dans l'intégration des données STIF ...
> Fred tu penses que ça pourrait passer sur la liste au père-noël ? ;)
>
> Le 7 décembre 2016 à 11:15, Noémie Lehuby 
> a écrit :
>
>> Bref, vous voulez pas qu'on commence par les lignes / relations
>> route_master, et qu'ensuite on voit comment on peut redescendre sur les
>> relations route, puis les relations stop_area et les noeuds
>> public_transport = platform?
>
> pourquoi pas mais on fait comment ? Il me semble qu'il nous manque pour
> l'instant un outil pour faire le boulot efficacement, *n'est-il pas* ?
>
> Dans osm on peut pas créer des relations sans rien mettre dedans (enfin ça
doit être possible mais la relation est tout de suite perdu) il faut une
géométrie à lui accrocher. Seul les node ont des coordonnées si une
relation n'est pas lié de près ou de loin à un node elle est nulle part.
Les relations route master sont reliés qu'a d'autres relations les
relations route qui elles sont relié aux arrêts et aux routes entre les
arrêts.
ces route entre les arrêts je vois pas comment ça pourrait être fait
autrement qu'"à la main par des gens"
les arrêts, on a des données avec des coordonnées pas trop mal c'est pour
intégré ce genre de données qu'osmose est utile.
après si on a les arrêts avec les bonnes "ref" dans osm, un "outil" peut
créer les relation (route ou route master) ou vérifier quels sont justes
avec les donnée GTFS ou d'autres données.
Mais dans l'autre sens je vois pas comment.

Par contre, ce qui est possible et utile c'est se mettre d'accord sur les
tags à mettre dans les relations d’après les données qu'on a (quel ref,
quel name ...) pour avoir des données dans osm homogènes. pareil sur la
façon de créer les relations stop_area. Mais les créer sans rien mettre
dedans à part des tags c'est pas possible ?

Autre chose qui peut être fait avant d’intégré les arrêts ( c'est une chose
qui pourrait compliquer aussi le travail d'un "outil créant les relations"
) c'est voir comment modifié , rajouté quel tag sur les relations
représentant les lignes de bus qui en existe déjà.
Des type=route_master il n'y en a pas beaucoup !? (ou alors je cherche pas
comme il faut) : http://overpass-turbo.eu/s/kvI
des type=route route=bus il y en as beaucoup :
http://overpass-turbo.eu/s/kvJ



> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-07 Par sujet Florian LAINEZ

Très intéressante démonstration Noémie.
Du coup peut-être en effet devrions-nous attendre de pouvoir exploiter le
GTFS avant de se lancer dans l'intégration des données STIF ...
Fred tu penses que ça pourrait passer sur la liste au père-noël ? ;)

Le 7 décembre 2016 à 11:15, Noémie Lehuby  a
écrit :

> Bref, vous voulez pas qu'on commence par les lignes / relations
> route_master, et qu'ensuite on voit comment on peut redescendre sur les
> relations route, puis les relations stop_area et les noeuds
> public_transport = platform?

pourquoi pas mais on fait comment ? Il me semble qu'il nous manque pour
l'instant un outil pour faire le boulot efficacement, *n'est-il pas* ?

-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-07 Par sujet Noémie Lehuby


Bonjour,

Je ne suis pas favorable à l'utilisation d'Osmose pour intégrer les 
codes des points d'arrêts, du moins pour le moment. Je pense que ça 
risque d'induire des erreurs chiantes à redresser par la suite.
Déjà parce qu'on ne va pas forcément avoir une relation 1 1 entre les 
deux référentiels.

Voir par exemple ce cas :
https://framapic.org/xhAIOVchGrbR/GusjVGKbAd0L.png
(bleu STIF, rose OSM)
les données OSM sont conformes au terrain : il y a en effet uniquement 
deux arrêts de bus
les données du STIF ont une qualité honorable, mais présentent un couple 
d'arrêt pour chaque transporteur qui s'arrête à cet endroit


Et à part pour les cas simples (par exemple un arrêt bien isolé), je ne 
vois pas trop comment on peut déterminer quel est l'arrêt qui matche 
côté STIF sans s'aider des lignes qui y passent.
Une intégration en s'appuyant sur la base des données transport globales 
(GTFS par exemple) est en effet à mon avis beaucoup plus pertinente.
Par exemple sur ce cas-là, ça me semble loin d'être évident de voir quel 
arrêt OSM correspond à quel(s) arrêt(s) STIF.

https://framapic.org/k9Pz6OezPUAu/WKoTWeaYyLSm.png
(vert STIF, rose OSM)


Bref, vous voulez pas qu'on commence par les lignes / relations 
route_master, et qu'ensuite on voit comment on peut redescendre sur les 
relations route, puis les relations stop_area et les noeuds  
public_transport = platform?


Noémie


Date: Wed, 7 Dec 2016 02:05:13 +0100
From: Jérôme Amagat <jerome.ama...@gmail.com>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<cahuxktjnsian5go6iomysnqra-cskg9ucufnva2rrfbszrj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier 
sauf 1

c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
fichier pour passer du
ZDEr_ID_REF_A au stop_id


Le 6 décembre 2016 à 22:20, Florian LAINEZ <winner...@free.fr> a écrit 
:



Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de
passer à une autre échelle.
Fred tu comptes l'implémenter du coup ?
Comment comptes-tu gérer l'évolution des données sources dans le temps 
?
Autant avec un jeu de données statiques tu peux valider/ignorer un 
POI,

autant si les données évoluent il faut être certain de disposer d'un
identifiant pérenne.

Fred en attendant peut-être vaut-il déjà intégrer les données 
statiques du

STIF comme première étape.
Merci



Le 6 décembre 2016 à 20:44, Frédéric Rodrigo <fred.rodr...@gmail.com> 
a

écrit :


Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :



Le 6 décembre 2016 à 13:45, Christian Quest <cqu...@openstreetmap.fr
<mailto:cqu...@openstreetmap.fr>> a écrit :

J'ai regardé dans mon quartier desservi par la RATP... c'est
"correct" à 50m près.

J'en ai à peu près le même souvenir. J'ai checké une belle quantité
d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains 
sur

les quais de gares ... d'autres très bien placés.

Le STIF agrégeant des données provenant d'une multitude de
sociétés de transport, la qualité géométrique n'est sûrement pas
homogène

exactement.

Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre 
ref:FR:STIF,

merci

Au passage je vous signale cette issues sur osmose-backend:


https://github.com/osm-fr/osmose-backend/issues/163

qui propose de faire la même chose à un niveau industriel.




___
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



-- section suivante --
Une pièce jointe HTML a été nettoyée...
URL:
<http://lists.openstreetmap.org/pipermail/talk-fr/attachments/20161207/8488f152/attachment-0001.html>

--

Message: 2
Date: Wed, 7 Dec 2016 07:26:20 +0100
From: Christian Quest <cqu...@openstreetmap.fr>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<caaxy6dopdwmxathijqrdfhuoyf+o2eoddasgu2nvjacygb_...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Il faut SI POSSIBLE se baser sur l'id qu'on peut voir sur le terrain... 
et

des id "STIF" j'en ai déjà vu sur des réseaux non RATP.

Le 7 décembre 2016 à 02:05, Jérôme Amagat <jerome.ama...@gmail.com> a 
écrit

:

pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier 
sauf 1

c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
fichier pour passer du
ZDEr_ID_REF_A au stop_id


Le 6 décembre 2016 à 22:20, Florian LAINEZ

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Christian Quest

Il faut SI POSSIBLE se baser sur l'id qu'on peut voir sur le terrain... et
des id "STIF" j'en ai déjà vu sur des réseaux non RATP.

Le 7 décembre 2016 à 02:05, Jérôme Amagat  a écrit
:

> pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier sauf 1
> c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
> fichier pour passer du
> ZDEr_ID_REF_A au stop_id
>
>
> Le 6 décembre 2016 à 22:20, Florian LAINEZ  a écrit :
>
>> Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de
>> passer à une autre échelle.
>> Fred tu comptes l'implémenter du coup ?
>> Comment comptes-tu gérer l'évolution des données sources dans le temps ?
>> Autant avec un jeu de données statiques tu peux valider/ignorer un POI,
>> autant si les données évoluent il faut être certain de disposer d'un
>> identifiant pérenne.
>>
>> Fred en attendant peut-être vaut-il déjà intégrer les données statiques
>> du STIF comme première étape.
>> Merci
>>
>>
>>
>> Le 6 décembre 2016 à 20:44, Frédéric Rodrigo  a
>> écrit :
>>
>>> Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :
>>>

 Le 6 décembre 2016 à 13:45, Christian Quest > a écrit :

 J'ai regardé dans mon quartier desservi par la RATP... c'est
 "correct" à 50m près.

 J'en ai à peu près le même souvenir. J'ai checké une belle quantité
 d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains sur
 les quais de gares ... d'autres très bien placés.

 Le STIF agrégeant des données provenant d'une multitude de
 sociétés de transport, la qualité géométrique n'est sûrement pas
 homogène

 exactement.

 Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre
 ref:FR:STIF, merci

 Au passage je vous signale cette issues sur osmose-backend:
>>>
>>> https://github.com/osm-fr/osmose-backend/issues/163
>>>
>>> qui propose de faire la même chose à un niveau industriel.
>>>
>>>
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>>
>> --
>>
>> *Florian Lainez*
>> @overflorian 
>>
>> ___
>> 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
>
>


-- 
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Jérôme Amagat

pour le STIF dans le GTFS le "ref" des arrêts dans tous les fichier sauf 1
c'est un stop_id différent du ZDEr_ID_REF_A mais il y a quand même un
fichier pour passer du
ZDEr_ID_REF_A au stop_id


Le 6 décembre 2016 à 22:20, Florian LAINEZ  a écrit :

> Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de
> passer à une autre échelle.
> Fred tu comptes l'implémenter du coup ?
> Comment comptes-tu gérer l'évolution des données sources dans le temps ?
> Autant avec un jeu de données statiques tu peux valider/ignorer un POI,
> autant si les données évoluent il faut être certain de disposer d'un
> identifiant pérenne.
>
> Fred en attendant peut-être vaut-il déjà intégrer les données statiques du
> STIF comme première étape.
> Merci
>
>
>
> Le 6 décembre 2016 à 20:44, Frédéric Rodrigo  a
> écrit :
>
>> Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :
>>
>>>
>>> Le 6 décembre 2016 à 13:45, Christian Quest >> > a écrit :
>>>
>>> J'ai regardé dans mon quartier desservi par la RATP... c'est
>>> "correct" à 50m près.
>>>
>>> J'en ai à peu près le même souvenir. J'ai checké une belle quantité
>>> d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains sur
>>> les quais de gares ... d'autres très bien placés.
>>>
>>> Le STIF agrégeant des données provenant d'une multitude de
>>> sociétés de transport, la qualité géométrique n'est sûrement pas
>>> homogène
>>>
>>> exactement.
>>>
>>> Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre ref:FR:STIF,
>>> merci
>>>
>>> Au passage je vous signale cette issues sur osmose-backend:
>>
>> https://github.com/osm-fr/osmose-backend/issues/163
>>
>> qui propose de faire la même chose à un niveau industriel.
>>
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Florian LAINEZ

Si OSMOSE se met à manger du GTFS c'est certain que ça permettrai de passer
à une autre échelle.
Fred tu comptes l'implémenter du coup ?
Comment comptes-tu gérer l'évolution des données sources dans le temps ?
Autant avec un jeu de données statiques tu peux valider/ignorer un POI,
autant si les données évoluent il faut être certain de disposer d'un
identifiant pérenne.

Fred en attendant peut-être vaut-il déjà intégrer les données statiques du
STIF comme première étape.
Merci



Le 6 décembre 2016 à 20:44, Frédéric Rodrigo  a
écrit :

> Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :
>
>>
>> Le 6 décembre 2016 à 13:45, Christian Quest > > a écrit :
>>
>> J'ai regardé dans mon quartier desservi par la RATP... c'est
>> "correct" à 50m près.
>>
>> J'en ai à peu près le même souvenir. J'ai checké une belle quantité
>> d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains sur
>> les quais de gares ... d'autres très bien placés.
>>
>> Le STIF agrégeant des données provenant d'une multitude de
>> sociétés de transport, la qualité géométrique n'est sûrement pas
>> homogène
>>
>> exactement.
>>
>> Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre ref:FR:STIF,
>> merci
>>
>> Au passage je vous signale cette issues sur osmose-backend:
>
> https://github.com/osm-fr/osmose-backend/issues/163
>
> qui propose de faire la même chose à un niveau industriel.
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Frédéric Rodrigo


Le 06/12/2016 à 19:13, Florian LAINEZ a écrit :


Le 6 décembre 2016 à 13:45, Christian Quest > a écrit :


J'ai regardé dans mon quartier desservi par la RATP... c'est
"correct" à 50m près.

J'en ai à peu près le même souvenir. J'ai checké une belle quantité 
d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains 
sur les quais de gares ... d'autres très bien placés.


Le STIF agrégeant des données provenant d'une multitude de
sociétés de transport, la qualité géométrique n'est sûrement pas
homogène

exactement.

Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre 
ref:FR:STIF, merci



Au passage je vous signale cette issues sur osmose-backend:

https://github.com/osm-fr/osmose-backend/issues/163

qui propose de faire la même chose à un niveau industriel.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Florian LAINEZ

Le 6 décembre 2016 à 13:45, Christian Quest  a
écrit :

> J'ai regardé dans mon quartier desservi par la RATP... c'est "correct" à
> 50m près.

J'en ai à peu près le même souvenir. J'ai checké une belle quantité
d'arrêts autour de gares Transilien cet été, j'en ai trouvé certains sur
les quais de gares ... d'autres très bien placés.

Le STIF agrégeant des données provenant d'une multitude de sociétés de
> transport, la qualité géométrique n'est sûrement pas homogène
>
exactement.

Fred tu peux considérer le champs ZDEr_ID_REF_A comme notre ref:FR:STIF,
merci


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Christian Quest


Le 06/12/2016 à 12:25, Frédéric Rodrigo a écrit :

Le 06/12/2016 à 10:05, Florian LAINEZ a écrit :


Le 6 décembre 2016 à 01:42, Jérôme Amagat > a écrit :


Pour l'instant, dans osmose, l'ajout de donnée externe c'est
l'ajout d'un node ou l'ajout de tag sur un objet déjà existant.
Donc dans notre cas, ça marche bien pour ajouter les arrêts de bus.


en effet. Noémie, si tu veux t'attaquer aux lignes avant tout, il va 
nous falloir un outil adapté ... tu nous code ça vite fait bien fait 
? ;)


Fred tu penses que tu pourrais nous intégrer ce jeu de données 
https://opendata.stif.info/explore/dataset/referentiel-arret-tc-idf/ 
dans Osmose stp ? On pourra déjà commencer à bosser sur les arrêts 
comme ça.

Merci d'avance

C'est faisable.

À note que j'avais déjà ajouté les arrêts de bus RATP que puis retiré, 
parce que la qualité était trop mauvaise. Dans les données SITF à mon 
avis il doit y a voir du bon et du moins bon. Vous avez déjà une idée 
de la qualité (-> distance de conflation pour Osmose) ?




J'ai regardé dans mon quartier desservi par la RATP... c'est "correct" à 
50m près.


Le STIF agrégeant des données provenant d'une multitude de sociétés de 
transport, la qualité géométrique n'est sûrement pas homogène. Il faut 
donc regarder à d'autres endroits, hors petite couronne.


--
Christian Quest - OpenStreetMap France


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Frédéric Rodrigo


Le 06/12/2016 à 10:05, Florian LAINEZ a écrit :


Le 6 décembre 2016 à 01:42, Jérôme Amagat > a écrit :


Pour l'instant, dans osmose, l'ajout de donnée externe c'est
l'ajout d'un node ou l'ajout de tag sur un objet déjà existant.
Donc dans notre cas, ça marche bien pour ajouter les arrêts de bus.


en effet. Noémie, si tu veux t'attaquer aux lignes avant tout, il va 
nous falloir un outil adapté ... tu nous code ça vite fait bien fait ? ;)


Fred tu penses que tu pourrais nous intégrer ce jeu de données 
https://opendata.stif.info/explore/dataset/referentiel-arret-tc-idf/ 
dans Osmose stp ? On pourra déjà commencer à bosser sur les arrêts 
comme ça.

Merci d'avance

C'est faisable.

À note que j'avais déjà ajouté les arrêts de bus RATP que puis retiré, 
parce que la qualité était trop mauvaise. Dans les données SITF à mon 
avis il doit y a voir du bon et du moins bon. Vous avez déjà une idée de 
la qualité (-> distance de conflation pour Osmose) ?


Le champ ZDEr_ID_REF_A on la mappe vers quel tag ?

Frédéric.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-06 Par sujet Florian LAINEZ

Le 6 décembre 2016 à 01:42, Jérôme Amagat  a écrit
:

> Pour l'instant, dans osmose, l'ajout de donnée externe c'est l'ajout d'un
> node ou l'ajout de tag sur un objet déjà existant. Donc dans notre cas, ça
> marche bien pour ajouter les arrêts de bus.


en effet. Noémie, si tu veux t'attaquer aux lignes avant tout, il va nous
falloir un outil adapté ... tu nous code ça vite fait bien fait ? ;)

Fred tu penses que tu pourrais nous intégrer ce jeu de données
https://opendata.stif.info/explore/dataset/referentiel-arret-tc-idf/ dans
Osmose stp ? On pourra déjà commencer à bosser sur les arrêts comme ça.
Merci d'avance

-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-05 Par sujet Jérôme Amagat

Le 5 décembre 2016 à 21:49, Noémie Lehuby <noemie.leh...@openmailbox.org> a
écrit :

> Bonsoir,
>
> Pour les objets existants : http://taginfo.openstreetmap.f
> r/keys/?key=ref:FR:STIF
> à noter que comme le signale Jérôme, il y a aussi quelques ref:FR:stif
> http://taginfo.openstreetmap.fr/keys/?key=ref:FR:stif
>
> Je ne maîtrise pas bien Osmose : ça marche aussi pour les relations sans
> composante géographique ?
>

Pour l'instant, dans osmose, l'ajout de donnée externe c'est l'ajout d'un
node ou l'ajout de tag sur un objet déjà existant. Donc dans notre cas, ça
marche bien pour ajouter les arrêts de bus.


> Parce que les lignes de transport, l'objet OSM qui correspond le plus, ça
> sera la relation route_master (dont les éléments sont exclusivement
> d'autres relations) et qui ne se représente pas bien sur une carte.
>

Dans osm, oui c'est une relation route_master qui représente la  ligne de
bus mais il faut y placer des relation type=route et route=bus comme
indiqué là : https://wiki.openstreetmap.org/wiki/Tag:route%3Dbus
On en crée une pour le trajet du bus à l’allée une autre pour le retour
(voir encore plein d'autres si la ligne de bus a des variantes) et après on
met c'est différentes relations dans une relation route_master qui
représente toute la ligne de bus.
Comme il faut mettre dans c'est relation les bon morceaux de route
qu'empruntent les bus je pense pas qu'osmose ou un autre outil puissent le
faire à notre place.

>
> Et je préférerais qu'on commence par les lignes avant d'attaquer les point
> d'arrêts et zones d'arrêts (un peu comme avec les adresses, où on commence
> par faire matcher les communes, puis les rues). Ça permettra d'être plus
> fin et d'éviter d'attribuer la référence de l'arrêt qui est en fait de
> l'autre côté de la rue, voire de créer des arrêts parce qu'on en a deux
> dans les données du STIF alors qu'il n'y a bien qu'un unique arrêt sur le
> terrain.
>

Il y en a 2, un pour chaque coté de la route?
Osmose permet de placer un point exactement où le stif le place lui. et
comme il les place sur ce que j'ai vu bien 1 de chaque coté de la route il
n'y a pas de problème?
Comme dans les relations il faut mettre les arrêts, si il existent déjà je
pense que c'est plus simple.

Si je dis des bêtises n’hésitez pas à rectifier j'ai déjà toucher se genre
de relation quand elles existaient déjà mais j'en ai pas vraiment créer.


> nlehuby
>
> Date: Mon, 5 Dec 2016 20:48:17 +0100
>> From: Jérôme Amagat <jerome.ama...@gmail.com>
>> To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
>> Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
>> Message-ID:
>> <CAHUxktL+txPNO5nXZPK8QuV9B0QMupK=AqUdPvYwu9TFnHF_4A@mail.
>> gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>>
>> J'ai regardé un peu les données.
>> Déjà pour les arrêts les "Zones d'Embarquement d'Île-de-France (ZDE)" (les
>> public_transport=platform dans osm) les coordonnées semble de bonne
>> qualité. (pour les noms par contre c'est pas homogène certains sont tout
>> en
>> majuscule d'autres non, avec bien sur des problèmes avec les accents non
>> présents sur les majuscules)
>> C'est un bon candidat pour osmose je pense. (les tags ajoutés seraient
>> public_transport=platform name=* et pour les arrêt de bus :
>> highway=bus_stop bus=yes il y a aussi les arrêts de tram et métro)
>> Pour les autres données : Zone de Lieu (ZDL) Lieu d’arrêt (LDA)
>> possibilité
>> de créer une relation public_transport = stop_area qui regroupe des
>> platforms mais je sais pas pour lequel des 2 et c'est plus compliqué pour
>> osmose.
>>
>> Par contre les ref: il y en a beaucoup dans les fichiers. je dirais qu'il
>> faut utiliser ref:FR:STIF et c'est suivant les autres tags que l'on sait
>> quel ref c'est.
>> par contre pour les arrêts, il y a un ID_REFA avec les "Zones
>> d'Embarquement" et dans le fichier "Arrêts par lignes de transport en
>> commun en Ile-de-France" il y a un stop_id (qui peut être par exemple
>> "StopPoint:81:255"). c'est une partie des valeurs déjà présentent dans
>> osm.
>> Dans osm il y a des ref:FR:STIF (http://overpass-turbo.eu/s/kty) et des
>> ref:FR:stif (http://overpass-turbo.eu/s/ktA)
>>
>> Le 5 décembre 2016 à 08:49, Florian LAINEZ <winner...@free.fr> a écrit :
>>
>> Salut Noémie,
>>> L'identifiant ref:FR:STIF me parait également le plus pérenne et donc il
>>> devrait être préféré systématiquement. Ceci dit, il n'y a aucun problème
>>> à
>>> ajouter le code technique si cela peut t'être utile.
>>>
>>> Il ne me semble pas choquant d'uti

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-05 Par sujet Noémie Lehuby


Bonsoir,

Pour les objets existants : 
http://taginfo.openstreetmap.fr/keys/?key=ref:FR:STIF
à noter que comme le signale Jérôme, il y a aussi quelques ref:FR:stif 
http://taginfo.openstreetmap.fr/keys/?key=ref:FR:stif


Je ne maîtrise pas bien Osmose : ça marche aussi pour les relations sans 
composante géographique ?
Parce que les lignes de transport, l'objet OSM qui correspond le plus, 
ça sera la relation route_master (dont les éléments sont exclusivement 
d'autres relations) et qui ne se représente pas bien sur une carte.


Et je préférerais qu'on commence par les lignes avant d'attaquer les 
point d'arrêts et zones d'arrêts (un peu comme avec les adresses, où on 
commence par faire matcher les communes, puis les rues). Ça permettra 
d'être plus fin et d'éviter d'attribuer la référence de l'arrêt qui est 
en fait de l'autre côté de la rue, voire de créer des arrêts parce qu'on 
en a deux dans les données du STIF alors qu'il n'y a bien qu'un unique 
arrêt sur le terrain.


nlehuby


Date: Mon, 5 Dec 2016 20:48:17 +0100
From: Jérôme Amagat <jerome.ama...@gmail.com>
To: Discussions sur OSM en français  <talk-fr@openstreetmap.org>
Subject: Re: [OSM-talk-fr] intégration des référentiels STIF
Message-ID:
<CAHUxktL+txPNO5nXZPK8QuV9B0QMupK=aqudpvywu9tfnhf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

J'ai regardé un peu les données.
Déjà pour les arrêts les "Zones d'Embarquement d'Île-de-France (ZDE)" 
(les

public_transport=platform dans osm) les coordonnées semble de bonne
qualité. (pour les noms par contre c'est pas homogène certains sont 
tout en
majuscule d'autres non, avec bien sur des problèmes avec les accents 
non

présents sur les majuscules)
C'est un bon candidat pour osmose je pense. (les tags ajoutés seraient
public_transport=platform name=* et pour les arrêt de bus :
highway=bus_stop bus=yes il y a aussi les arrêts de tram et métro)
Pour les autres données : Zone de Lieu (ZDL) Lieu d’arrêt (LDA) 
possibilité

de créer une relation public_transport = stop_area qui regroupe des
platforms mais je sais pas pour lequel des 2 et c'est plus compliqué 
pour

osmose.

Par contre les ref: il y en a beaucoup dans les fichiers. je dirais 
qu'il
faut utiliser ref:FR:STIF et c'est suivant les autres tags que l'on 
sait

quel ref c'est.
par contre pour les arrêts, il y a un ID_REFA avec les "Zones
d'Embarquement" et dans le fichier "Arrêts par lignes de transport en
commun en Ile-de-France" il y a un stop_id (qui peut être par exemple
"StopPoint:81:255"). c'est une partie des valeurs déjà présentent dans 
osm.

Dans osm il y a des ref:FR:STIF (http://overpass-turbo.eu/s/kty) et des
ref:FR:stif (http://overpass-turbo.eu/s/ktA)

Le 5 décembre 2016 à 08:49, Florian LAINEZ <winner...@free.fr> a écrit 
:



Salut Noémie,
L'identifiant ref:FR:STIF me parait également le plus pérenne et donc 
il
devrait être préféré systématiquement. Ceci dit, il n'y a aucun 
problème à

ajouter le code technique si cela peut t'être utile.

Il ne me semble pas choquant d'utiliser ref:FR:STIF pour identifier 
les

lignes et les zones d'arrêt même si cela ne correspond pas au même
identifiant coté STIF. Le simple fait que cela s'applique à une ligne
suffit à expliciter le type d'objet concerné.

Tu dis qu'il y a déjà des objets avec ref:FR:STIF, je ne les ai pas
trouvé, tu peux nous envoyer la requête Overpass utilisée stp ? Si 
d'autres
références sont indiquées, il va falloir que l'on trouve ce à quoi 
cela

correspond.
Au doigt mouillé, je dirait que ce sont des identifiants de la RATP ou
d'un autre transporteur qui ont été mal tagués.

Est-ce que tu as intégré les données du STIF dans OSMOSE pour qu'on 
puisse

"dégommer du rouge" avec toi ? ;)

Le 4 décembre 2016 à 20:09, <osm.sanspourr...@spamgourmet.com> a écrit 
:


Le 04/12/2016 à 18:41, Noémie Lehuby - noemie.leh...@openmailbox.org 
a

écrit :

Je pensais partir simplement sur ref:FR:STIF pour indiquer les
identifiants. Mais :
* Il y a des déjà des objets avec ce tag dans la base. Je n'ai pas 
trouvé
à quoi correspondent ces références actuelles. Ça ressemble un peu à 
la

colonne ExternalCode_ID du référentiel STIF, mais pas tout à fait...
Quelqu'un sait ce que c'est et si ça a toujours une réalité ?
* Est-ce que c'est choquant d'utiliser ce tag à la fois pour les
références des lignes, des points d'arrêts et des zones d'arrêts ? 
Sinon,

on peut affiner la clef avec ref:FR:STIF:ID_Line et
ref:FR:STIF:ZDEr_ID_REF_A.

Qu'en pensez-vous ?

nlehuby

Tu peux peut-être contacter des créateurs de ces références pour ne 
avoir
le cœur net. Si l'intersection est vide, tu peux te contenter d'une 
clé,

sinon ça va être compliqué.
Ce que tu dis sur le wiki me semble correct.
Garder les 2 références permet sans doute de suivre plus facilement 
les

évolutions.

Jean-Yvon

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
htt

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-05 Par sujet Jérôme Amagat

J'ai regardé un peu les données.
Déjà pour les arrêts les "Zones d'Embarquement d'Île-de-France (ZDE)" (les
public_transport=platform dans osm) les coordonnées semble de bonne
qualité. (pour les noms par contre c'est pas homogène certains sont tout en
majuscule d'autres non, avec bien sur des problèmes avec les accents non
présents sur les majuscules)
C'est un bon candidat pour osmose je pense. (les tags ajoutés seraient
public_transport=platform name=* et pour les arrêt de bus :
highway=bus_stop bus=yes il y a aussi les arrêts de tram et métro)
Pour les autres données : Zone de Lieu (ZDL) Lieu d’arrêt (LDA) possibilité
de créer une relation public_transport = stop_area qui regroupe des
platforms mais je sais pas pour lequel des 2 et c'est plus compliqué pour
osmose.

Par contre les ref: il y en a beaucoup dans les fichiers. je dirais qu'il
faut utiliser ref:FR:STIF et c'est suivant les autres tags que l'on sait
quel ref c'est.
par contre pour les arrêts, il y a un ID_REFA avec les "Zones
d'Embarquement" et dans le fichier "Arrêts par lignes de transport en
commun en Ile-de-France" il y a un stop_id (qui peut être par exemple
"StopPoint:81:255"). c'est une partie des valeurs déjà présentent dans osm.
Dans osm il y a des ref:FR:STIF (http://overpass-turbo.eu/s/kty) et des
ref:FR:stif (http://overpass-turbo.eu/s/ktA)

Le 5 décembre 2016 à 08:49, Florian LAINEZ  a écrit :

> Salut Noémie,
> L'identifiant ref:FR:STIF me parait également le plus pérenne et donc il
> devrait être préféré systématiquement. Ceci dit, il n'y a aucun problème à
> ajouter le code technique si cela peut t'être utile.
>
> Il ne me semble pas choquant d'utiliser ref:FR:STIF pour identifier les
> lignes et les zones d'arrêt même si cela ne correspond pas au même
> identifiant coté STIF. Le simple fait que cela s'applique à une ligne
> suffit à expliciter le type d'objet concerné.
>
> Tu dis qu'il y a déjà des objets avec ref:FR:STIF, je ne les ai pas
> trouvé, tu peux nous envoyer la requête Overpass utilisée stp ? Si d'autres
> références sont indiquées, il va falloir que l'on trouve ce à quoi cela
> correspond.
> Au doigt mouillé, je dirait que ce sont des identifiants de la RATP ou
> d'un autre transporteur qui ont été mal tagués.
>
> Est-ce que tu as intégré les données du STIF dans OSMOSE pour qu'on puisse
> "dégommer du rouge" avec toi ? ;)
>
> Le 4 décembre 2016 à 20:09,  a écrit :
>
>> Le 04/12/2016 à 18:41, Noémie Lehuby - noemie.leh...@openmailbox.org a
>> écrit :
>>
>> Je pensais partir simplement sur ref:FR:STIF pour indiquer les
>> identifiants. Mais :
>> * Il y a des déjà des objets avec ce tag dans la base. Je n'ai pas trouvé
>> à quoi correspondent ces références actuelles. Ça ressemble un peu à la
>> colonne ExternalCode_ID du référentiel STIF, mais pas tout à fait...
>> Quelqu'un sait ce que c'est et si ça a toujours une réalité ?
>> * Est-ce que c'est choquant d'utiliser ce tag à la fois pour les
>> références des lignes, des points d'arrêts et des zones d'arrêts ? Sinon,
>> on peut affiner la clef avec ref:FR:STIF:ID_Line et
>> ref:FR:STIF:ZDEr_ID_REF_A.
>>
>> Qu'en pensez-vous ?
>>
>> nlehuby
>>
>> Tu peux peut-être contacter des créateurs de ces références pour ne avoir
>> le cœur net. Si l'intersection est vide, tu peux te contenter d'une clé,
>> sinon ça va être compliqué.
>> Ce que tu dis sur le wiki me semble correct.
>> Garder les 2 références permet sans doute de suivre plus facilement les
>> évolutions.
>>
>> Jean-Yvon
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
>
> *Florian Lainez*
> @overflorian 
>
> ___
> 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

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-04 Par sujet Florian LAINEZ

Salut Noémie,
L'identifiant ref:FR:STIF me parait également le plus pérenne et donc il
devrait être préféré systématiquement. Ceci dit, il n'y a aucun problème à
ajouter le code technique si cela peut t'être utile.

Il ne me semble pas choquant d'utiliser ref:FR:STIF pour identifier les
lignes et les zones d'arrêt même si cela ne correspond pas au même
identifiant coté STIF. Le simple fait que cela s'applique à une ligne
suffit à expliciter le type d'objet concerné.

Tu dis qu'il y a déjà des objets avec ref:FR:STIF, je ne les ai pas trouvé,
tu peux nous envoyer la requête Overpass utilisée stp ? Si d'autres
références sont indiquées, il va falloir que l'on trouve ce à quoi cela
correspond.
Au doigt mouillé, je dirait que ce sont des identifiants de la RATP ou d'un
autre transporteur qui ont été mal tagués.

Est-ce que tu as intégré les données du STIF dans OSMOSE pour qu'on puisse
"dégommer du rouge" avec toi ? ;)

Le 4 décembre 2016 à 20:09,  a écrit :

> Le 04/12/2016 à 18:41, Noémie Lehuby - noemie.leh...@openmailbox.org a
> écrit :
>
> Je pensais partir simplement sur ref:FR:STIF pour indiquer les
> identifiants. Mais :
> * Il y a des déjà des objets avec ce tag dans la base. Je n'ai pas trouvé
> à quoi correspondent ces références actuelles. Ça ressemble un peu à la
> colonne ExternalCode_ID du référentiel STIF, mais pas tout à fait...
> Quelqu'un sait ce que c'est et si ça a toujours une réalité ?
> * Est-ce que c'est choquant d'utiliser ce tag à la fois pour les
> références des lignes, des points d'arrêts et des zones d'arrêts ? Sinon,
> on peut affiner la clef avec ref:FR:STIF:ID_Line et
> ref:FR:STIF:ZDEr_ID_REF_A.
>
> Qu'en pensez-vous ?
>
> nlehuby
>
> Tu peux peut-être contacter des créateurs de ces références pour ne avoir
> le cœur net. Si l'intersection est vide, tu peux te contenter d'une clé,
> sinon ça va être compliqué.
> Ce que tu dis sur le wiki me semble correct.
> Garder les 2 références permet sans doute de suivre plus facilement les
> évolutions.
>
> Jean-Yvon
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

*Florian Lainez*
@overflorian 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] intégration des référentiels STIF

2016-12-04 Par sujet osm . sanspourriel

Le 04/12/2016 à 18:41, Noémie Lehuby - noemie.leh...@openmailbox.org a 
écrit :


Je pensais partir simplement sur ref:FR:STIF pour indiquer les 
identifiants. Mais :
* Il y a des déjà des objets avec ce tag dans la base. Je n'ai pas 
trouvé à quoi correspondent ces références actuelles. Ça ressemble un 
peu à la colonne ExternalCode_ID du référentiel STIF, mais pas tout à 
fait... Quelqu'un sait ce que c'est et si ça a toujours une réalité ?
* Est-ce que c'est choquant d'utiliser ce tag à la fois pour les 
références des lignes, des points d'arrêts et des zones d'arrêts ? 
Sinon, on peut affiner la clef avec ref:FR:STIF:ID_Line et 
ref:FR:STIF:ZDEr_ID_REF_A.


Qu'en pensez-vous ?

nlehuby
Tu peux peut-être contacter des créateurs de ces références pour ne 
avoir le cœur net. Si l'intersection est vide, tu peux te contenter 
d'une clé, sinon ça va être compliqué.

Ce que tu dis sur le wiki me semble correct.
Garder les 2 références permet sans doute de suivre plus facilement les 
évolutions.


Jean-Yvon
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] intégration des référentiels STIF

2016-12-04 Par sujet Noémie Lehuby


Bonjour,

Le STIF fournit sur son portail opendata des référentiels stables sur 
les lignes et les arrêts de toute la région Île-de-France.
J'aimerais bien attaquer l'intégration de ces références, sur les lignes 
pour commencer.


Une page de discussion a été initiée sur le wiki sur le sujet, avec tous 
les liens vers les doc et les fichiers opendata qui vont bien : 
https://wiki.openstreetmap.org/wiki/Talk:WikiProject_France/Transports_en_%C3%8Ele-de-France


Je pensais partir simplement sur ref:FR:STIF pour indiquer les 
identifiants. Mais :
* Il y a des déjà des objets avec ce tag dans la base. Je n'ai pas 
trouvé à quoi correspondent ces références actuelles. Ça ressemble un 
peu à la colonne ExternalCode_ID du référentiel STIF, mais pas tout à 
fait... Quelqu'un sait ce que c'est et si ça a toujours une réalité ?
* Est-ce que c'est choquant d'utiliser ce tag à la fois pour les 
références des lignes, des points d'arrêts et des zones d'arrêts ? 
Sinon, on peut affiner la clef avec ref:FR:STIF:ID_Line et 
ref:FR:STIF:ZDEr_ID_REF_A.


Qu'en pensez-vous ?

nlehuby

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

55 matches

Mail list logo