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