<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>