<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="transparent" text="#000000">
    <p>Le 27/10/2016 à 02:27, Florian LAINEZ - <a class="moz-txt-link-abbreviated" href="mailto:winnerflo@free.fr">winnerflo@free.fr</a> a
      écrit :<br>
    </p>
    <blockquote
cite="mid:CALZSDKLzz3Sje8ASDQy5kAJU-D5nYHj=VebXHKnJmzWg=SuUag@mail.gmail.com"
      type="cite">Je ne souhaite par contre pas faire apparaitre les
      segments de route en tant qu'objets individuels. Il me semble plus
      intuitif de permettre de modifier le chemin en drag&drop un
      point du segment qui recalculerait un itinéraire en conséquence.
      Par la suite c'est l'appli qui gérerait elle-même les segments à
      ajouter/supprimer de la relation.<br>
      Pour vous donner une idée de ce comportement, il suffit de
      déplacer un point de départ ou d'arrivée lors d'un calcul
      d'itinéraire avec OSRM sur <a moz-do-not-send="true"
        href="http://osm.org">osm.org</a><br>
    </blockquote>
    Autre possibilité : dire par où ne doit pas passer la ligne (à la
    manière d'OSMAND).<br>
    Je pense qu'ordonner les arrêts est assez facile pour le non
    cartographe : c'est en général écrit à l'arrêt.<br>
    <br>
    <div class="moz-cite-prefix">Le 27/10/2016 à 04:48, Philippe Verdy -
      <a class="moz-txt-link-abbreviated" href="mailto:verdy_p@wanadoo.fr">verdy_p@wanadoo.fr</a> a écrit :<br>
    </div>
    <blockquote
cite="mid:CAGa7JC14tfwZCC+6aauWOXV-etLq7o6cdp6FoC4yOZb2CQGGQg@mail.gmail.com"
      type="cite">
      <div dir="ltr">Les trajets des bus sont aussi dans l'opendata de
        la STAR (sous forme de shape atteaché à un des attributs des
        lignes, un shape par direction)<br>
      </div>
    </blockquote>
    <p>Bien-sûr les données libres ne sont pas à négliger.</p>
    <p>Actuellement elles sont partiellement signalées sur le wiki.</p>
    <p>Ça peut être une piste non seulement pour Omose canal OD mais
      aussi pour l'appli.</p>
    <p>Deux problèmes :</p>
    <p>- les formats à chaque fois différents (bon entre shp et geojson
      on doit couvrir pas mal de possibilités) mais les correspondances
      attributs sont différentes.<br>
    </p>
    <p>- les convergences et divergences. Le nom donné par le réseau a
      été proposé comme nom alternatif (en cas de divergence).
      localisation, nom doivent permettre de mettre une référence
      (ref:<nom du réseau> par exemple ref:fr_star et non juste
      ref:network comme proposait Marc à cause des arrêts et lignes
      partagées et donc les sources multiples - il parlait de name mais
      c'est sensiblement pareil) afin de faciliter le suivi (dont les
      arrêts partagés).<br>
    </p>
    <p>Peut-être peut-on pré-remplir la liste des arrêts et l'ordre.</p>
    <p>Par exemple si on reprend la ligne C1 de la Star on voit que
      c'est l'itinéraire qui n'est pas à jour.</p>
    <p>Mais j'en reviens à un de mes TOC : mettre le modèle dans la
      base. Car les règles que l'on met c'est bien mais typiquement les
      règles de Jérôme pourraient être portées par le réseau Star, au
      moins le lien vers les données.</p>
    <p>un ref:fr_star doit permettre de remonter au réseau et sur le
      réseau on doit avoir l'adresse web, l'adresse des données libres
      (le cas échéant) et idéalement les règles de transformation.
      Peut-être qu'un lien sur un wiki c'est plus simple car moins
      formalisé.</p>
    <p>Un petit XML/JSON pour expliquer la correspondance, des
      paramètres comme la distance pour considérer qu'un arrêt OD et un
      arrrêt OSM peuvent les mêmes, ça doit régler déjà pas mal de cas.</p>
    <p>Ou est-ce encore trop le b... en OD ?<br>
    </p>
    Si on arrive à le faire, plusieurs applis peuvent en profiter.<br>
    Y a-t-il des pratiquants pour savoir si chaque réseau est trop
    spécifique pour espérer y arriver ?<br>
    <br>
    Jean-Yvon<br>
  </body>
</html>