Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[Vincent Bergeot]

Le 20/10/2016 à 11:26, Florian LAINEZ a écrit :


dans le bus je me sers d'un thème quasi identique à celui là
:https://www.cartes.xyz/t/04e491-Arrets_de_bus__Florian#


@vincent tu m'as bien compris, c'est exactement ce que j'aimerai faire 
avec un interface pour les débutants. Il manque aussi à ton outil la 
gestion des lignes : il est difficile de voir quels arrêts sont sur la 
même ligne, or ça me parait être clef pour la simplicité de contribution.

yep, je crois comprendre.
Cela devient plus une question de "rendu" que de données si je comprends 
bien. Imaginer les couleurs correspondantes aux lignes et les arrêts 
associés.
Effectivement, en mettant le rendu transport sur le thème précédent, 
c'est déjà un peu plus clair.


Dans ta "présentation tu parles "Edit bus stops details: name, 
direction, bus line". Bus_line et direction sont tagués sur le bus_stop 
? Je ne trouve rien sur le wiki, j'ai raté des choses je pense !


Et pour les relations, à voir avec la requête overpass qui le fait !

PS : je suis conscient que cela ne correspond pas à certaines de tes 
attentes (off-line, interface plus simple, android, ...) mais cela me 
permet aussi d'avancer sur un thème arrêt de bus pour que ta mère puisse 
s'en servir une fois qu'elle aura commencé avec ton idée d'application :)


--
Vincent Bergeot

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

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[lenny.libre]

Le 20/10/2016 à 18:15, Thomas a écrit :

Bonjour,

L'import Grand Toulouse comporte les attributs 'ref' et 'operator' qui
permettraient de constituer le tuple unique le plus opportun pour une
identification unique globale. Ce sont des attributs qu'il me semble
essentiel de conserver en cas de fusion ou suppression.

Bonsoir

Pour ma part, j'ai fait quelques modifications de lignes après les 
changements Tisséo intervenus le 29 août.


Je n'ai pas remarqué ces doublons ; la source est "Grand Toulouse" mais 
ne me semble pas être le résultat d'un import, Les emplacements sont 
assez corrects (vérifié avec l'orthophotoplan ToulouseMetropole 2015, ou 
sur place) ou alors je n'ai pas bien regardé.


J'ai téléchargé les arrêts de bus que j'ai trouvé sur le site de 
Toulouse Métropole 
(https://data.toulouse-metropole.fr/explore/dataset/arrets-de-bus0/map/?location=16,43.59271,1.41894&basemap=jawg.streets) 
et j'ai constaté qu'il y a un seul point pour tous les arrêts ayant le 
même nom avec un champ "conc_arret=" qui est la concaténation des n° de 
chaque arrêt (par exemple le point [code_expl=6192449487677451 
code_log=18 *conc_arret=179 180 182 183 184 185 188 189*conc_ligne=14 34 
46 64 65 67 conc_mode=bus id=705.0 *nom_arret=Arènes*nom_expl=tisseo] 
dans osm (http://osm.org/go/xVNVXVlXr) on trouve plusieurs nodes avec ce 
nom). Les n° présents dans ce "conc_arret" sont les ref indiqués dans 
osm comme on peut le voir à l'arrêt physique (certains rares nodes 
contiennent également une concaténation des ref 
http://www.openstreetmap.org/node/3793076559).


L'attribut commun entre DGI et Grand Toulouse, c'est (au delà de la
catégorisation bus_stop/bus=yes) c'est le nom. Mais étant donné que les
arrêts en face à face sur une voie à double sens de circulation portent
le même nom cela pose un problème pour envisager automatiser un recalage
sur cette couche de la DGI.
le nom n'est pas l'attribut commun (voir plus haut) c'est bien le n°  + 
Tisséo (pour les arrêts communs avec ceux du Conseil Départemental, il y 
a un autre n° propre à CD31)
D'autant plus que certains arrêts ont changé de nom (par exemple sur la 
ligne 21 "Colomiers Relais Bus" renommé "Salle Gascogne", "Passerelle" 
renommé "Val d'Aran")


Je viens de regarder sur des communes alentour, je constate
effectivement la présence de doublons DGI/Grand Toulouse ailleurs, avec
des décalages parfois importants de positions.

Du coup, le mieux serait-il de supprimer les noeuds DGI qui constituent
des doublons, après avoir vérifié in-situ la bonne position ou non des
noeuds Grand Toulouse lorsque les écarts entre les 2 couches sont
significatifs (cas facile à détecter avec une moulinette) ?

Thomas


On 20/10/2016 15:48, Francescu GAROBY wrote:

Bonjour Thomas,
Est-ce que les arrêts de bus importés par la DGI et/ou Grand Toulouse
ont un identifiant unique ?
Si oui, une possibilité pourrait être de fusionner les 2 points d'un
même arrêt, en conservant ce(s) identifiant(s), de façon à ce qu'un
réimport, qui devrait se baser là-dessus pour différencier les arrêts
présents/manquants, ne soit pas perturbé et retrouve ses petits.
Et perso, j'éviterais de laisser le doublon de chaque arrêt : ça
n'apporte rien et, pire, ça embrouille les cartographieurs (qui
pourraient associer le mauvais arrêt dans la relation d'une ligne) comme
les usagers d'OSM...


Francescu

Le 20 octobre 2016 à 15:40, Thomas mailto:thomas+...@mignien.fr>> a écrit :

 Bonjour,

 je profite de la thématique des arrêts de bus pour vous exposer une
 problématique et solliciter vos bons conseils.

 Je constate que dans mon coin il y a des incohérences sur la position
 d'arrêts de bus, notamment des déplacements liés à des réaménagements de
 l'espace urbain.

 Par exemple, je vais avoir l'arrêt de bus en double, à des positions
 différentes. Ces doublons s'expliquent par des campagnes d'import Open
 Data :

 2009 DGI : Positionnement OK, mais avec peu d'informations sur la ligne
 2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement KO,
 mais avec des attributs intéressants. Je note par ailleurs que
 l'emplacement de cet arrêt est également faux sur le site commercial de
 Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
 métropole.

 Mes questions :
 - Comment gérer au mieux ces problématiques de données importées par le
 passé ?
 - Dois-je fusionner les attributs pour conserver un maximum d'infos et
 supprimer le nœud mal placé ?
 - Dois-je conserver les deux nœuds, et uniquement corriger la position
 erronée ?


Il me semble que les doublons que tu as détectés devraient être 
fusionnés (A voir peut-être avec osmose) vu qu'il n'y a qu'un arrêt sur 
le terrain (ces doublons sont des anomalies).



 L'idée ici est de faire au mieux pour ne pas perturber ou être perturbé
 lors d'une prochaine campagne d'import Open Data avec des données plus
 ou moins correctes.
Vu ce 

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[osm . sanspourriel]

Merci aussi à toi pour ton retour.

Le 20/10/2016 à 11:26, Florian LAINEZ - winner...@free.fr a écrit :


@Jean-Yvon tous les détails dont tu parles sont passionnants, je passe 
moi-même beaucoup de temps à m'y plonger dedans. Mais l'outil que je 
souhaite est vraiment fait pour les noobs. OSMAND n'est pas utilisable 
par ma mère car trop compliqué.

D'accord sur la complexité de l'utilisation d'OSMAND.
Mais la question est : faut-il repartir à zéro ou rendre l'interface 
d'OSMAND utilisable par ta mère ?
Je n'ai pas la réponse, idéalement je choisirais la seconde proposition, 
j'ai vu que OSMAND proposait des feuilles de style (bon une que l'on 
peut adapter) pour afficher les descriptions des objets (on dit ce que 
l'on veut voir et dans quel ordre).
Si on pouvait faire des feuilles de styles de la carte qui servent de 
base aux feuilles de styles des descriptions / entrées / modifications 
des POI (voir simplement avoir des correspondances par nom : tu choisis 
le style transports publics pour la carte et il utilise la feuille de 
style transports publics pour les éditions de POI).
Ça me fait aussi penser au mapping.xml d’imposm3 :  on peut peut-être 
partir des attributs conseillés pour une thème dans un wiki pour trouver 
les données à présenter et l'ordre de présentation (sans oublier les 
données génériques style position et nom).

Peut-être à ranger par catégorie.

Sur l'utilisation de la caméra : suggérer de photographier l'arrêt de 
bus  (il y a souvent la fiche horaire avec au moins les principaux 
arrêts). Avec un GPX en plus ça permet de valider au moins les 
principaux arrêts.
Tu veux intégrer de l'OCR (reconnaissance optique de caractères) pour 
avoir les noms des arrêts ? ;-).
Sinon ça peut-être utile aux contributeurs en fauteuil, voir proposé 
dans Osmose comme aide à la décision.


Autre possibilité : quand on arrive à un arrêt connu possibilité de le 
valider (source=survey:2016). Là ce qui est gênant c'est qu'on veut 
attester de la non-modification. Faire une modif pour cela...


Je pense qu'il faut aussi montrer à l'utilisateur que son travail est 
utile en montrant un avant et un après.


Le 19 octobre 2016 à 23:19, Pierre-Yves Berrard 
mailto:pierre.yves.berr...@gmail.com>> 
a écrit :


Le 19 octobre 2016 à 23:12, Philippe Verdy mailto:verd...@wanadoo.fr>> a écrit :

Merci pour ces précisions.

Et en résumé : STAR est une marque associée à un réseau mais cette 
marque n'apparaît nulle part dans OSM.

fr_star, une fois que tu sais, ok.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[Thomas Gratier]

Salut,

Pas mis à jour depuis longtemps mais cette application avait la vocation de
mapper les arrêts de transport
http://makinacorpus.github.io/osm-transport-editor/#/ avec code
http://makinacorpus.github.io/osm-transport-editor/

Cordialement


Thomas Gratier

Le 20 octobre 2016 à 18:15, Thomas  a écrit :

> Bonjour,
>
> L'import Grand Toulouse comporte les attributs 'ref' et 'operator' qui
> permettraient de constituer le tuple unique le plus opportun pour une
> identification unique globale. Ce sont des attributs qu'il me semble
> essentiel de conserver en cas de fusion ou suppression.
>
> L'attribut commun entre DGI et Grand Toulouse, c'est (au delà de la
> catégorisation bus_stop/bus=yes) c'est le nom. Mais étant donné que les
> arrêts en face à face sur une voie à double sens de circulation portent
> le même nom cela pose un problème pour envisager automatiser un recalage
> sur cette couche de la DGI.
>
> Je viens de regarder sur des communes alentour, je constate
> effectivement la présence de doublons DGI/Grand Toulouse ailleurs, avec
> des décalages parfois importants de positions.
>
> Du coup, le mieux serait-il de supprimer les noeuds DGI qui constituent
> des doublons, après avoir vérifié in-situ la bonne position ou non des
> noeuds Grand Toulouse lorsque les écarts entre les 2 couches sont
> significatifs (cas facile à détecter avec une moulinette) ?
>
> Thomas
>
>
> On 20/10/2016 15:48, Francescu GAROBY wrote:
> > Bonjour Thomas,
> > Est-ce que les arrêts de bus importés par la DGI et/ou Grand Toulouse
> > ont un identifiant unique ?
> > Si oui, une possibilité pourrait être de fusionner les 2 points d'un
> > même arrêt, en conservant ce(s) identifiant(s), de façon à ce qu'un
> > réimport, qui devrait se baser là-dessus pour différencier les arrêts
> > présents/manquants, ne soit pas perturbé et retrouve ses petits.
> > Et perso, j'éviterais de laisser le doublon de chaque arrêt : ça
> > n'apporte rien et, pire, ça embrouille les cartographieurs (qui
> > pourraient associer le mauvais arrêt dans la relation d'une ligne) comme
> > les usagers d'OSM...
> >
> >
> > Francescu
> >
> > Le 20 octobre 2016 à 15:40, Thomas  > > a écrit :
> >
> > Bonjour,
> >
> > je profite de la thématique des arrêts de bus pour vous exposer une
> > problématique et solliciter vos bons conseils.
> >
> > Je constate que dans mon coin il y a des incohérences sur la position
> > d'arrêts de bus, notamment des déplacements liés à des
> réaménagements de
> > l'espace urbain.
> >
> > Par exemple, je vais avoir l'arrêt de bus en double, à des positions
> > différentes. Ces doublons s'expliquent par des campagnes d'import
> Open
> > Data :
> >
> > 2009 DGI : Positionnement OK, mais avec peu d'informations sur la
> ligne
> > 2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement
> KO,
> > mais avec des attributs intéressants. Je note par ailleurs que
> > l'emplacement de cet arrêt est également faux sur le site commercial
> de
> > Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
> > métropole.
> >
> > Mes questions :
> > - Comment gérer au mieux ces problématiques de données importées par
> le
> > passé ?
> > - Dois-je fusionner les attributs pour conserver un maximum d'infos
> et
> > supprimer le nœud mal placé ?
> > - Dois-je conserver les deux nœuds, et uniquement corriger la
> position
> > erronée ?
> >
> > L'idée ici est de faire au mieux pour ne pas perturber ou être
> perturbé
> > lors d'une prochaine campagne d'import Open Data avec des données
> plus
> > ou moins correctes.
> >
> > Salutations,
> >
> >
> > On 19/10/2016 20:00, Philippe Verdy wrote:
> > > Dans les villes qui publient des données Open Data sur leurs
> > réseaux de
> > > transport, je pense qu'on n'a pas besoin de cette appli tierce mais
> > > qu'il vaut mieux s'appuyer sur des solutions de synchronisation et
> > > comparaison.
> > >
> > > On a divers outils, y compris
> > > - via les données OSM elles-mêmes (relations de type "network"
> > pour les
> > > réseaux publics, dont les lignes membres sont des relations
> > > "route_master" contenant les relations "route" pour chaque sens ou
> > variante)
> > > - les ref:* pour le réseau ou pour l'opérateur
> > > - les outils d'intégration comme Osmose (qui pourrait aussi
> vérifier
> > > l'intégrité et la continuité des lignes)
> > > Ces relations "network" peuvent "facilement" être vérifiées de
> façon
> > > systématique avec un formalisme permettant certains automatismes.
> > >
> > > Pour le reste il peut manquer des infos non encore en open data:
> > ce qui
> > > est en général moins bien géré c'est le schéma v2 des transports
> qui
> > > intègre la notion de "plateforme" pour les interconnexions de
> > lignes et
> > > intermodales, permettan

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[Thomas]

Bonjour,

L'import Grand Toulouse comporte les attributs 'ref' et 'operator' qui
permettraient de constituer le tuple unique le plus opportun pour une
identification unique globale. Ce sont des attributs qu'il me semble
essentiel de conserver en cas de fusion ou suppression.

L'attribut commun entre DGI et Grand Toulouse, c'est (au delà de la
catégorisation bus_stop/bus=yes) c'est le nom. Mais étant donné que les
arrêts en face à face sur une voie à double sens de circulation portent
le même nom cela pose un problème pour envisager automatiser un recalage
sur cette couche de la DGI.

Je viens de regarder sur des communes alentour, je constate
effectivement la présence de doublons DGI/Grand Toulouse ailleurs, avec
des décalages parfois importants de positions.

Du coup, le mieux serait-il de supprimer les noeuds DGI qui constituent
des doublons, après avoir vérifié in-situ la bonne position ou non des
noeuds Grand Toulouse lorsque les écarts entre les 2 couches sont
significatifs (cas facile à détecter avec une moulinette) ?

Thomas


On 20/10/2016 15:48, Francescu GAROBY wrote:
> Bonjour Thomas,
> Est-ce que les arrêts de bus importés par la DGI et/ou Grand Toulouse
> ont un identifiant unique ?
> Si oui, une possibilité pourrait être de fusionner les 2 points d'un
> même arrêt, en conservant ce(s) identifiant(s), de façon à ce qu'un
> réimport, qui devrait se baser là-dessus pour différencier les arrêts
> présents/manquants, ne soit pas perturbé et retrouve ses petits.
> Et perso, j'éviterais de laisser le doublon de chaque arrêt : ça
> n'apporte rien et, pire, ça embrouille les cartographieurs (qui
> pourraient associer le mauvais arrêt dans la relation d'une ligne) comme
> les usagers d'OSM...
> 
> 
> Francescu
> 
> Le 20 octobre 2016 à 15:40, Thomas  > a écrit :
> 
> Bonjour,
> 
> je profite de la thématique des arrêts de bus pour vous exposer une
> problématique et solliciter vos bons conseils.
> 
> Je constate que dans mon coin il y a des incohérences sur la position
> d'arrêts de bus, notamment des déplacements liés à des réaménagements de
> l'espace urbain.
> 
> Par exemple, je vais avoir l'arrêt de bus en double, à des positions
> différentes. Ces doublons s'expliquent par des campagnes d'import Open
> Data :
> 
> 2009 DGI : Positionnement OK, mais avec peu d'informations sur la ligne
> 2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement KO,
> mais avec des attributs intéressants. Je note par ailleurs que
> l'emplacement de cet arrêt est également faux sur le site commercial de
> Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
> métropole.
> 
> Mes questions :
> - Comment gérer au mieux ces problématiques de données importées par le
> passé ?
> - Dois-je fusionner les attributs pour conserver un maximum d'infos et
> supprimer le nœud mal placé ?
> - Dois-je conserver les deux nœuds, et uniquement corriger la position
> erronée ?
> 
> L'idée ici est de faire au mieux pour ne pas perturber ou être perturbé
> lors d'une prochaine campagne d'import Open Data avec des données plus
> ou moins correctes.
> 
> Salutations,
> 
> 
> On 19/10/2016 20:00, Philippe Verdy wrote:
> > Dans les villes qui publient des données Open Data sur leurs
> réseaux de
> > transport, je pense qu'on n'a pas besoin de cette appli tierce mais
> > qu'il vaut mieux s'appuyer sur des solutions de synchronisation et
> > comparaison.
> >
> > On a divers outils, y compris
> > - via les données OSM elles-mêmes (relations de type "network"
> pour les
> > réseaux publics, dont les lignes membres sont des relations
> > "route_master" contenant les relations "route" pour chaque sens ou
> variante)
> > - les ref:* pour le réseau ou pour l'opérateur
> > - les outils d'intégration comme Osmose (qui pourrait aussi vérifier
> > l'intégrité et la continuité des lignes)
> > Ces relations "network" peuvent "facilement" être vérifiées de façon
> > systématique avec un formalisme permettant certains automatismes.
> >
> > Pour le reste il peut manquer des infos non encore en open data:
> ce qui
> > est en général moins bien géré c'est le schéma v2 des transports qui
> > intègre la notion de "plateforme" pour les interconnexions de
> lignes et
> > intermodales, permettant de regrouper des arrêts et faire les
> > correspondances, même entre réseaux différents (par exemple entre un
> > réseau urbain, un réseau départemental, les lignes nationales
> bus/train,
> > les stations de taxis, les stations d'auto-partage, les vélos à la
> > demande ("Vélib" et similaires), les interconnexions vers des chemins
> > touristiques...
> >
> > Actuellement les objets "platform" d'OSM sont surtout construits
> pour un
> > unique réseau, mais si on regarde le déta

[OSM-talk-fr] Mapathon MM à Saint denis Jeudi 28/10

[Violaine Doutreleau]

Bonjour à tous,

On organise le prochain mapathon Missing Maps avec l'université Paris 
VIII et le Master de Géographie et le Master de Géomatique à 
l'université Paris VIII le *jeudi 27/10 de 18h30 à 21h!*


+d'infos et inscriptions ici : 
https://www.eventbrite.fr/e/billets-missing-maps-saint-denis-28602298244


A bientôt, je l'espère,
V
--

CartONG




Humanitarian mapping and information management
Website: cartong.org  | Twitter: @assocCartONG 
 | Address: Chambéry, France | Lon: 
05°55'24'' | Lat: 45°30'20''


Violaine Doutreleau

Email:v_doutrel...@cartong.org 
Phone: +33 (0)4 79 26 28 82
Mobile: +33 (0)6 95 02 42 44
Skype: doutreleau.violaine  




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

Re: [OSM-talk-fr] massif du mont-blanc

[Florian LAINEZ]

Merci David pour ces précisions.
Pour l'instant je n'ai pas vraiment d'idée plus précise sur le sujet.

Le 20 octobre 2016 à 12:04, David Marchal  a écrit :

> Bonjour.
>
> En fait, il n'y a pas encore de modélisation standardisée des massifs
> montagneux ; j'avais posé la question je ne sais plus où, et les diverses
> réponses montraient plusieurs problèmes parmi lesquels :
> * la divergence des définitions de ces  massifs, qui ne sont en fait bien
> définis géographiquement que dans les Alpes ; ailleurs, il n'y a pas de
> définition universelle des massifs ;
> * la délimitation précise des massifs (fond de vallée ? haut des montagnes
> limitrophes ?)
> * sans doute autre chose.
>
> Mais vous pouvez proposer vos idées sur le sujet, si vous le souhaitez.
>
> Cordialement.
> 
> De : Florian LAINEZ [winner...@free.fr]
> Envoyé : mercredi 19 octobre 2016 15:59
> À : Discussions sur OSM en français
> Objet : [OSM-talk-fr]  massif du mont-blanc
>
> hello,
> je n'arrive pas à trouver la relation qui décrit le massif du mont blanc,
> c'est à dire la délimitation du tour de tout le massif montagneux. J'avais
> dans l'idée de lui adjoindre le tag wikipedia.
> Je suis nul ou il n'existe pas encore ? Je n'ai pas trouvé de tag sur le
> wiki pour décrire de massif montagneux donc pas possible de faire de
> requête overpass.
> Help !
>
> --
>
> Florian Lainez
>
> [http://twitter.com/favicon.ico]@overflorian twitter.com/overflorian>
>
> ___
> 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] Appli mobile pour mapper les arrêts de bus

[Francescu GAROBY]

Bonjour Thomas,
Est-ce que les arrêts de bus importés par la DGI et/ou Grand Toulouse ont
un identifiant unique ?
Si oui, une possibilité pourrait être de fusionner les 2 points d'un même
arrêt, en conservant ce(s) identifiant(s), de façon à ce qu'un réimport,
qui devrait se baser là-dessus pour différencier les arrêts
présents/manquants, ne soit pas perturbé et retrouve ses petits.
Et perso, j'éviterais de laisser le doublon de chaque arrêt : ça n'apporte
rien et, pire, ça embrouille les cartographieurs (qui pourraient associer
le mauvais arrêt dans la relation d'une ligne) comme les usagers d'OSM...


Francescu

Le 20 octobre 2016 à 15:40, Thomas  a écrit :

> Bonjour,
>
> je profite de la thématique des arrêts de bus pour vous exposer une
> problématique et solliciter vos bons conseils.
>
> Je constate que dans mon coin il y a des incohérences sur la position
> d'arrêts de bus, notamment des déplacements liés à des réaménagements de
> l'espace urbain.
>
> Par exemple, je vais avoir l'arrêt de bus en double, à des positions
> différentes. Ces doublons s'expliquent par des campagnes d'import Open
> Data :
>
> 2009 DGI : Positionnement OK, mais avec peu d'informations sur la ligne
> 2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement KO,
> mais avec des attributs intéressants. Je note par ailleurs que
> l'emplacement de cet arrêt est également faux sur le site commercial de
> Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
> métropole.
>
> Mes questions :
> - Comment gérer au mieux ces problématiques de données importées par le
> passé ?
> - Dois-je fusionner les attributs pour conserver un maximum d'infos et
> supprimer le nœud mal placé ?
> - Dois-je conserver les deux nœuds, et uniquement corriger la position
> erronée ?
>
> L'idée ici est de faire au mieux pour ne pas perturber ou être perturbé
> lors d'une prochaine campagne d'import Open Data avec des données plus
> ou moins correctes.
>
> Salutations,
>
>
> On 19/10/2016 20:00, Philippe Verdy wrote:
> > Dans les villes qui publient des données Open Data sur leurs réseaux de
> > transport, je pense qu'on n'a pas besoin de cette appli tierce mais
> > qu'il vaut mieux s'appuyer sur des solutions de synchronisation et
> > comparaison.
> >
> > On a divers outils, y compris
> > - via les données OSM elles-mêmes (relations de type "network" pour les
> > réseaux publics, dont les lignes membres sont des relations
> > "route_master" contenant les relations "route" pour chaque sens ou
> variante)
> > - les ref:* pour le réseau ou pour l'opérateur
> > - les outils d'intégration comme Osmose (qui pourrait aussi vérifier
> > l'intégrité et la continuité des lignes)
> > Ces relations "network" peuvent "facilement" être vérifiées de façon
> > systématique avec un formalisme permettant certains automatismes.
> >
> > Pour le reste il peut manquer des infos non encore en open data: ce qui
> > est en général moins bien géré c'est le schéma v2 des transports qui
> > intègre la notion de "plateforme" pour les interconnexions de lignes et
> > intermodales, permettant de regrouper des arrêts et faire les
> > correspondances, même entre réseaux différents (par exemple entre un
> > réseau urbain, un réseau départemental, les lignes nationales bus/train,
> > les stations de taxis, les stations d'auto-partage, les vélos à la
> > demande ("Vélib" et similaires), les interconnexions vers des chemins
> > touristiques...
> >
> > Actuellement les objets "platform" d'OSM sont surtout construits pour un
> > unique réseau, mais si on regarde le détail ce qui nous manque c'est
> > surtout les connexion intermodales, qui permettant de choisir ou
> > optimiser les moyens de transport ou trouver des alternatives. Sans
> > cela, les outils de recherche font des approximations pas toujours très
> > claires et oublient des tas de possibilités (parce qu'en général on ne
> > tague pas la plupart des trajets piétonniers courts et qu'il y a des
> > obstacles imprévus ou des problèmes de sécurité pour faire certains
> > trajets d'interconnexion).
> >
> >
> >
> > Le 19 octobre 2016 à 18:36, lenny.libre  > > a écrit :
> >
> > Mon anglais étant niveau maternelle je n'ai pas trop essayé de lire
> > la présentation ...
> >
> > je trouve le principe intéressant, je me pose quelques
> interrogations :
> >
> > - possibilité de photographier (pour avoir éventuellement le nom de
> > l’arrêt et la liste des lignes qui s’arrêtent à cet arrêt)
> >
> > - plusieurs lignes par arrêt et plusieurs réseaux opérateurs ?
> >
> > - est-il possible de faire les deux points
> > "public_transport=stop_position" et "public_transport=platform"
> >
> > - l'utiliser sans connexion internet, juste le gps
> >
> > bonne idée, cordialement
> >
> > léni
> >
> >
> >
> > Le 19/10/2016 à 14:57, Florian LAINEZ a écrit :
> >> Hello,
> >> Il y a quelques temps qu'une idée me trotte en tête : j'aimerai
> >> cré

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[Thomas]

Bonjour,

je profite de la thématique des arrêts de bus pour vous exposer une
problématique et solliciter vos bons conseils.

Je constate que dans mon coin il y a des incohérences sur la position
d'arrêts de bus, notamment des déplacements liés à des réaménagements de
l'espace urbain.

Par exemple, je vais avoir l'arrêt de bus en double, à des positions
différentes. Ces doublons s'expliquent par des campagnes d'import Open
Data :

2009 DGI : Positionnement OK, mais avec peu d'informations sur la ligne
2012 Grand Toulouse (maintenant Toulouse Metropole), Positionnement KO,
mais avec des attributs intéressants. Je note par ailleurs que
l'emplacement de cet arrêt est également faux sur le site commercial de
Tisséo, la SMTC qui gère le réseau, qui a dû alimenter la base de la
métropole.

Mes questions :
- Comment gérer au mieux ces problématiques de données importées par le
passé ?
- Dois-je fusionner les attributs pour conserver un maximum d'infos et
supprimer le nœud mal placé ?
- Dois-je conserver les deux nœuds, et uniquement corriger la position
erronée ?

L'idée ici est de faire au mieux pour ne pas perturber ou être perturbé
lors d'une prochaine campagne d'import Open Data avec des données plus
ou moins correctes.

Salutations,


On 19/10/2016 20:00, Philippe Verdy wrote:
> Dans les villes qui publient des données Open Data sur leurs réseaux de
> transport, je pense qu'on n'a pas besoin de cette appli tierce mais
> qu'il vaut mieux s'appuyer sur des solutions de synchronisation et
> comparaison.
> 
> On a divers outils, y compris
> - via les données OSM elles-mêmes (relations de type "network" pour les
> réseaux publics, dont les lignes membres sont des relations
> "route_master" contenant les relations "route" pour chaque sens ou variante)
> - les ref:* pour le réseau ou pour l'opérateur
> - les outils d'intégration comme Osmose (qui pourrait aussi vérifier
> l'intégrité et la continuité des lignes)
> Ces relations "network" peuvent "facilement" être vérifiées de façon
> systématique avec un formalisme permettant certains automatismes.
> 
> Pour le reste il peut manquer des infos non encore en open data: ce qui
> est en général moins bien géré c'est le schéma v2 des transports qui
> intègre la notion de "plateforme" pour les interconnexions de lignes et
> intermodales, permettant de regrouper des arrêts et faire les
> correspondances, même entre réseaux différents (par exemple entre un
> réseau urbain, un réseau départemental, les lignes nationales bus/train,
> les stations de taxis, les stations d'auto-partage, les vélos à la
> demande ("Vélib" et similaires), les interconnexions vers des chemins
> touristiques...
> 
> Actuellement les objets "platform" d'OSM sont surtout construits pour un
> unique réseau, mais si on regarde le détail ce qui nous manque c'est
> surtout les connexion intermodales, qui permettant de choisir ou
> optimiser les moyens de transport ou trouver des alternatives. Sans
> cela, les outils de recherche font des approximations pas toujours très
> claires et oublient des tas de possibilités (parce qu'en général on ne
> tague pas la plupart des trajets piétonniers courts et qu'il y a des
> obstacles imprévus ou des problèmes de sécurité pour faire certains
> trajets d'interconnexion).
> 
> 
> 
> Le 19 octobre 2016 à 18:36, lenny.libre  > a écrit :
> 
> Mon anglais étant niveau maternelle je n'ai pas trop essayé de lire
> la présentation ...
> 
> je trouve le principe intéressant, je me pose quelques interrogations :
> 
> - possibilité de photographier (pour avoir éventuellement le nom de
> l’arrêt et la liste des lignes qui s’arrêtent à cet arrêt)
> 
> - plusieurs lignes par arrêt et plusieurs réseaux opérateurs ?
> 
> - est-il possible de faire les deux points
> "public_transport=stop_position" et "public_transport=platform"
> 
> - l'utiliser sans connexion internet, juste le gps
> 
> bonne idée, cordialement
> 
> léni
> 
> 
> 
> Le 19/10/2016 à 14:57, Florian LAINEZ a écrit :
>> Hello,
>> Il y a quelques temps qu'une idée me trotte en tête : j'aimerai
>> créer une appli mobile pour éditer facilement les arrêts et les
>> relations de bus.
>> J'ai mis ce que j'avais en tête par écrit ici :
>> http://slides.com/overflorian/busstopcollector
>> 
>> Vous en pensez quoi ?
>>
>> -- 
>>
>> *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/

Re: [OSM-talk-fr] massif du mont-blanc

[David Marchal]

Bonjour.

En fait, il n'y a pas encore de modélisation standardisée des massifs 
montagneux ; j'avais posé la question je ne sais plus où, et les diverses 
réponses montraient plusieurs problèmes parmi lesquels :
* la divergence des définitions de ces  massifs, qui ne sont en fait bien 
définis géographiquement que dans les Alpes ; ailleurs, il n'y a pas de 
définition universelle des massifs ;
* la délimitation précise des massifs (fond de vallée ? haut des montagnes 
limitrophes ?)
* sans doute autre chose.

Mais vous pouvez proposer vos idées sur le sujet, si vous le souhaitez.

Cordialement.

De : Florian LAINEZ [winner...@free.fr]
Envoyé : mercredi 19 octobre 2016 15:59
À : Discussions sur OSM en français
Objet : [OSM-talk-fr]  massif du mont-blanc

hello,
je n'arrive pas à trouver la relation qui décrit le massif du mont blanc, c'est 
à dire la délimitation du tour de tout le massif montagneux. J'avais dans 
l'idée de lui adjoindre le tag wikipedia.
Je suis nul ou il n'existe pas encore ? Je n'ai pas trouvé de tag sur le wiki 
pour décrire de massif montagneux donc pas possible de faire de requête 
overpass.
Help !

--

Florian Lainez

[http://twitter.com/favicon.ico]@overflorian

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

Re: [OSM-talk-fr] Appli mobile pour mapper les arrêts de bus

[Florian LAINEZ]

Merci à tous pour vos retour et désolé d'avoir eu l'impolitesse de faire ma
proposition en anglais.

Par contre, si je vois bien la facilité qu'il peut y avoir à renseigner un
> arrêt, son équipement (banc, abribus, affichage, ...) ainsi que les lignes
> qui y passent, j'ai du mal à voir comment rendre facile l'édition d'un
> trajet de bus
>
@Francescu pour l'instant je ne sais pas moi non plus mais ça fait partie
des fonctionnalités à faire après la v1

Une autre possibilité de contribution que pourrait permettre cette
> application, ce serait l'enregistrement du tracé
>
Bonne idée ! Je note.

dans le bus je me sers d'un thème quasi identique à celui là :
> https://www.cartes.xyz/t/04e491-Arrets_de_bus__Florian#

@vincent tu m'as bien compris, c'est exactement ce que j'aimerai faire avec
un interface pour les débutants. Il manque aussi à ton outil la gestion des
lignes : il est difficile de voir quels arrêts sont sur la même ligne, or
ça me parait être clef pour la simplicité de contribution.

@léni je note tes propositions (certaines ont en effet déjà été détaillées
dans ma présentation)

@Jean-Yvon tous les détails dont tu parles sont passionnants, je passe
moi-même beaucoup de temps à m'y plonger dedans. Mais l'outil que je
souhaite est vraiment fait pour les noobs. OSMAND n'est pas utilisable par
ma mère car trop compliqué.

Je vais passer un peu de temps à formaliser ma proposition dans le jours à
venir, vos retours sont les bienvenus


Le 19 octobre 2016 à 23:19, Pierre-Yves Berrard <
pierre.yves.berr...@gmail.com> a écrit :

> Le 19 octobre 2016 à 23:12, Philippe Verdy  a écrit :
>
>> [...] (les passagers pourront alors embarquer ces jours-là avec leurs
>> titre de transport STAR, il pourront même acheter les titre dans les bus au
>> prix standard STAR, et sinon acheter les titres complémentaires pour aller
>> au delà, sans avoir besoin de descendre du car, à moins que ce jour-là la
>> métropole accepte d'affrêter la ligne existante du transporteur tiers sur
>> toute sa longueur, au prix justement de l'ajout d'arrêts supplémentaires
>> par rapport au trajet habituel du transporteur; ce transporteur tiers
>> pourra aussi augmenter la fréquence avec des bus supplémentaires pour ses
>> besoins propres en cas de trop forte affluence).[...]
>>
>
> Merci pour ces précisions.
>
>
> ___
> 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] Re: Intégration des monuments historiques dans Osm

[Florian LAINEZ]

Le 17 octobre 2016 à 21:17, Romain MEHUT  a écrit :

> Si si on peut mettre deux valeurs séparées par un point virgule et ceci ne
> concerne pas que le tag ref.
>

C'est bien ce que j'ai fait au final, merci pour vos conseils.

C'est assez prenant comme jeu, je me suis mis aux chapelles de
Haute-Savoie, y a du boulot ...

@Jean tu devrais parler de ton projet aux wikimediens, je suis sûr qu'ils
seraient intéressés. Tu peux commencer par faire une annonce sur le bistrot
https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Le_Bistro c'est une bonne
porte d'entrée.


-- 

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