<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">Le 20/10/2016 à 18:15, Thomas a écrit :<br>
</div>
<blockquote
cite="mid:6ab05aff-f527-d635-f546-21c6ff0c1a7a@mignien.fr"
type="cite">
<pre wrap="">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.</pre>
</blockquote>
Bonsoir
<p>Pour ma part, j'ai fait quelques modifications de lignes après
les changements Tisséo intervenus le 29 août.</p>
<p>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é.</p>
J'ai téléchargé les arrêts de bus que j'ai trouvé sur le site de
Toulouse Métropole
(<a class="moz-txt-link-freetext" href="https://data.toulouse-metropole.fr/explore/dataset/arrets-de-bus0/map/?location=16,43.59271,1.41894&basemap=jawg.streets">https://data.toulouse-metropole.fr/explore/dataset/arrets-de-bus0/map/?location=16,43.59271,1.41894&basemap=jawg.streets</a>)
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 [<tt>code_expl=6192449487677451
code_log=18 </tt><tt><b>conc_arret=179 180 182 183 184 185 188
189</b></tt><tt> conc_ligne=14 34 46 64 65 67 conc_mode=bus
id=705.0 </tt><tt><b>nom_arret=Arènes</b></tt><tt> </tt><tt>nom_expl=tisseo</tt>]
dans osm (<a class="moz-txt-link-freetext" href="http://osm.org/go/xVNVXVlXr">http://osm.org/go/xVNVXVlXr</a>) 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
<a class="moz-txt-link-freetext" href="http://www.openstreetmap.org/node/3793076559">http://www.openstreetmap.org/node/3793076559</a>). <br>
<blockquote
cite="mid:6ab05aff-f527-d635-f546-21c6ff0c1a7a@mignien.fr"
type="cite">
<pre wrap="">
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.</pre>
</blockquote>
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)<br>
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")<br>
<blockquote
cite="mid:6ab05aff-f527-d635-f546-21c6ff0c1a7a@mignien.fr"
type="cite">
<pre wrap="">
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:
</pre>
<blockquote type="cite">
<pre wrap="">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 class="moz-txt-link-abbreviated" href="mailto:thomas+osm@mignien.fr">thomas+osm@mignien.fr</a>
<a class="moz-txt-link-rfc2396E" href="mailto:thomas+osm@mignien.fr"><mailto:thomas+osm@mignien.fr></a>> 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 ?</pre>
</blockquote>
</blockquote>
<br>
<p>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).
</p>
<blockquote
cite="mid:6ab05aff-f527-d635-f546-21c6ff0c1a7a@mignien.fr"
type="cite">
<blockquote type="cite">
<pre wrap="">
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.</pre>
</blockquote>
</blockquote>
Vu ce que j'ai compris en consultant ces données, il me semble que
ce serait difficile de faire de l'import, vu qu'un point de
l'OpenData correspond à plusieurs nodes
"public_transport=platform", il me semble qu'un outil du genre
d'osmose pourrait détecter des anomalies ou des manques.<br>
<br>
cordialement<br>
léni<br>
</body>
</html>