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

2016-10-28 Par sujet Florian LAINEZ 
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 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. 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 osm.org


Autre possibilité : dire par où ne doit pas passer la ligne (à la manière
d'OSMAND).

Peut-être qu'un outil web serait plus adapté qu'un outil mobile pour tracer
les chemins ? Je réfléchis à un outil web complémentaire en ce moment.

Le 27 octobre 2016 à 23:54, Philippe Verdy  a écrit :

>
>
> Le 27 octobre 2016 à 23:37,  a écrit :
>
>> Le 27/10/2016 à 02:27, Florian LAINEZ - winner...@free.fr a écrit :
>>
>> 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 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.
>> 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
>> osm.org
>>
>> Autre possibilité : dire par où ne doit pas passer la ligne (à la manière
>> d'OSMAND).
>> Je pense qu'ordonner les arrêts est assez facile pour le non cartographe
>> : c'est en général écrit à l'arrêt.
>>
>> Le 27/10/2016 à 04:48, Philippe Verdy - verd...@wanadoo.fr a écrit :
>>
>> 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)
>>
>> Bien-sûr les données libres ne sont pas à négliger.
>>
>> Actuellement elles sont partiellement signalées sur le wiki.
>>
>
> Juste parce que je j'ai mis à jour cette page pour intégrer le nouveau
> site Open Data de la STAR (qui remplace ceux, partiels, de Rennes Métropole
> et de Keolis). La STAR a communiqué récemment sur cette mise à dispo en
> open-data et sur l'utilisation des fonds de carte OSM dans ses affichages
> publics.
>
> En mentionnant les licences utilisées (ODbL pour presque tout, sauf les
> pictogrammes de numéros de lignes et les plans PDF sous licence CC-BY-ND,
>  et les pictogrammes de services de Keolis; les quelques données vendant du
> GEOFLA n'ont pas d'intérêt pour nous et ce qui est en CC-NY-ND n'est pas
> nécessaire pour nous).
>
> Certes il manque encore les lignes complémentaires (2NN) et scolaires
> (TsNNN) mais ça va venir, dit le site. Mais ces lignes sont codifiées, même
> si on ne les a pas dans le détail avec les arrêts et shapes.
>
>
>
> ___
> 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 (ordre)

2016-10-27 Par sujet Philippe Verdy 
Le 27 octobre 2016 à 23:37,  a écrit :

> Le 27/10/2016 à 02:27, Florian LAINEZ - winner...@free.fr a écrit :
>
> 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 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.
> 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
> osm.org
>
> Autre possibilité : dire par où ne doit pas passer la ligne (à la manière
> d'OSMAND).
> Je pense qu'ordonner les arrêts est assez facile pour le non cartographe :
> c'est en général écrit à l'arrêt.
>
> Le 27/10/2016 à 04:48, Philippe Verdy - verd...@wanadoo.fr a écrit :
>
> 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)
>
> Bien-sûr les données libres ne sont pas à négliger.
>
> Actuellement elles sont partiellement signalées sur le wiki.
>

Juste parce que je j'ai mis à jour cette page pour intégrer le nouveau site
Open Data de la STAR (qui remplace ceux, partiels, de Rennes Métropole et
de Keolis). La STAR a communiqué récemment sur cette mise à dispo en
open-data et sur l'utilisation des fonds de carte OSM dans ses affichages
publics.

En mentionnant les licences utilisées (ODbL pour presque tout, sauf les
pictogrammes de numéros de lignes et les plans PDF sous licence CC-BY-ND,
 et les pictogrammes de services de Keolis; les quelques données vendant du
GEOFLA n'ont pas d'intérêt pour nous et ce qui est en CC-NY-ND n'est pas
nécessaire pour nous).

Certes il manque encore les lignes complémentaires (2NN) et scolaires
(TsNNN) mais ça va venir, dit le site. Mais ces lignes sont codifiées, même
si on ne les a pas dans le détail avec les arrêts et shapes.
___
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 (ordre)

2016-10-27 Par sujet osm . sanspourriel 

Le 27/10/2016 à 02:27, Florian LAINEZ - winner...@free.fr a écrit :

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 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.
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 osm.org 
Autre possibilité : dire par où ne doit pas passer la ligne (à la 
manière d'OSMAND).
Je pense qu'ordonner les arrêts est assez facile pour le non cartographe 
: c'est en général écrit à l'arrêt.


Le 27/10/2016 à 04:48, Philippe Verdy - verd...@wanadoo.fr a écrit :
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)


Bien-sûr les données libres ne sont pas à négliger.

Actuellement elles sont partiellement signalées sur le wiki.

Ça peut être une piste non seulement pour Omose canal OD mais aussi pour 
l'appli.


Deux problèmes :

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


- 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: 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).


Peut-être peut-on pré-remplir la liste des arrêts et l'ordre.

Par exemple si on reprend la ligne C1 de la Star on voit que c'est 
l'itinéraire qui n'est pas à jour.


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.


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


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.


Ou est-ce encore trop le b... en OD ?

Si on arrive à le faire, plusieurs applis peuvent en profiter.
Y a-t-il des pratiquants pour savoir si chaque réseau est trop 
spécifique pour espérer y arriver ?


Jean-Yvon
___
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 (ordre)

2016-10-26 Par sujet Florian LAINEZ 
@Philippe l'ensemble de ton email est HS : nous parlons d'une appli mobile,
pas de JOSM.

@Jean-Yvon je pense que nous sommes tous d'accord pour dire qu'il est
important d'ordonner. Néanmoins ma question portait plutôt sur l'appli
dédiée aux débutants que je souhaite développer : doit-on intégrer un tel
niveau de complexité pour des personnes qui ne maitrisent pas la carto ?
à la limite je suis prêt à considérer la possibilité d'ordonner les arrêts
(glisser-déposer via une liste) si vous arrivez à me convaincre de son
absolue nécessité. Pour l'instant, j'en doute.
Par contre l'ordonnancement des chemins me parait bien trop complexe à
gérer sur mobile.

> Possibilité de sélectionner un arrêt sur la carte pour l'ajouter ? Idem
> pour un chemin ?
>
Oui, il doit être simple d'ajouter un arrêt existant ou de créer un nouvel
arrêt en le reliant à une relation existante.

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 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.
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
osm.org

merci encore pour vos idées, on progresse dans la réflexion ...

Le 27 octobre 2016 à 01:03, Philippe Verdy  a écrit :

> Je déconseille très fortement le "glisser-déposer" dans l'éditeur de
> relations de JOSM !!! Trop souvent fois au lieu de déposer les objets, JOSM
> les SUPPRIME instantanément de la relation (sans même poser la question) si
> on a le malheur de déposer sur les pixels séparant deux lignes (et ce n'est
> pas rare du tout !).
>
> C'est un vieux bogue non corrigé (d'ailleurs il arrive parfois que pendant
> un clic on glisse légèrement la souris de quelques pixels et JOSM croit
> qu'on veut faire un glisser-déposer, et se plante de la même façon !). Si
> on ne voit plus les membres qu'on avait sélectionné, il va falloir aller
> les rechercher à nouveau sur la carte). D'ailleurs JOSM n'aide pas non plus
> quand on valide la relation validée, car il n'indique pas le nombre de
> membres ajoutés ou supprimés dans son historique, il se contente juste de
> dire que la relation a été modifiée.
>
> Pour éviter des erreurs de manipulation quand on manipule des relations
> avec beaucoup d'éléments et pouvoir réparer, je commence par sélectionner
> tous les éléments pour les mettre tels quels dans une autre nouvelle
> relation (dans une autre fenêtre), sans me soucier des rôles et des tags,
> et je laisse cette fenêtre d'éditeur ouverte sans la valider. Ensuite je
> peux modifier la relation. Ceci fait, je vérifie qu'il ne manque aucun
> membre dans la relation en allant les re-sélectionner depuis la fenêtre
> voisine temporaire qui est encore ouverte: ces membres doivent tous
> apparaître surlignés en jaune dans la relation que je modifiait, sinon
> c'est qu'ils ont disparu, mais c'est facile de les remettre. Quand c'est
> terminé, je valide la relation, et j'annule la fenêtre temporaire qui me
> sert juste de "presse-papier".
>
> Cette méthode de "presse-papier" en revanche ne permet pas de détecter les
> membres qui devraient rester en "doublon" dans la relation (les chemins
> parcourus deux fois dans la ligne fait un détour... et parfois aussi
> certains arrêts desservis deux fois sachant que le bus a son indicateur qui
> affiche sur quelle partie de la ligne il est en indiquant soit un arrêt
> dans le détour soit celui du terminus) : il faut vérifier manuellement le
> nombre de doublons surlignés "en rose" dans les deux fenêtres. On aura le
> problème tant qu'on n'aura pas de "route segments"
>
> Pour ordonner les membres dans l'éditeur SANS glisser-déposer:
>  - sélectionner les membres au clavier (flèches et touche SHIFT pour un
> intervalle, ou CTRL pour ajouter/retirer un membre de la sélection) ou la
> souris,
> - puis utiliser les icônes monter/descendre de la barre latérale.
>
> Ensuite peu importe si on a groupé les ways en tête de la relation ou à la
> fin. Personnellement je préfère grouper les ways à la fin pour que les
> premiers membres visibles soient les noms des premiers arrêts (les chemins
> n'ont pas de nom évident), et ensuite grouper ensemble le "stop" nécessaire
> pour la v2 (l'icône: devrait être un gros point rouge) avec sa "plateform"
> (bus_stop de la v1, l'icone est celle d'un bus pour "bus", ou celle d'un
> poteau d'arrêt pour les platform v2). On peut vérifier visuellement qu'on
> ne s'est pas trompé de rôle.
>
> Au minimum la relation devrait avoir deux "stop" (donc deux icones "points
> rouges" ou "bus") ;  sur les lignes non circulaires, le premier "stop"
> devrait avoir son rôle suffixé "_entry_only", et le dernier un rôle suffixé
> "_exit_only". Dans un premier temps on n'est pas obligé d'avoir tous

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

2016-10-26 Par sujet Philippe Verdy 
Je déconseille très fortement le "glisser-déposer" dans l'éditeur de
relations de JOSM !!! Trop souvent fois au lieu de déposer les objets, JOSM
les SUPPRIME instantanément de la relation (sans même poser la question) si
on a le malheur de déposer sur les pixels séparant deux lignes (et ce n'est
pas rare du tout !).

C'est un vieux bogue non corrigé (d'ailleurs il arrive parfois que pendant
un clic on glisse légèrement la souris de quelques pixels et JOSM croit
qu'on veut faire un glisser-déposer, et se plante de la même façon !). Si
on ne voit plus les membres qu'on avait sélectionné, il va falloir aller
les rechercher à nouveau sur la carte). D'ailleurs JOSM n'aide pas non plus
quand on valide la relation validée, car il n'indique pas le nombre de
membres ajoutés ou supprimés dans son historique, il se contente juste de
dire que la relation a été modifiée.

Pour éviter des erreurs de manipulation quand on manipule des relations
avec beaucoup d'éléments et pouvoir réparer, je commence par sélectionner
tous les éléments pour les mettre tels quels dans une autre nouvelle
relation (dans une autre fenêtre), sans me soucier des rôles et des tags,
et je laisse cette fenêtre d'éditeur ouverte sans la valider. Ensuite je
peux modifier la relation. Ceci fait, je vérifie qu'il ne manque aucun
membre dans la relation en allant les re-sélectionner depuis la fenêtre
voisine temporaire qui est encore ouverte: ces membres doivent tous
apparaître surlignés en jaune dans la relation que je modifiait, sinon
c'est qu'ils ont disparu, mais c'est facile de les remettre. Quand c'est
terminé, je valide la relation, et j'annule la fenêtre temporaire qui me
sert juste de "presse-papier".

Cette méthode de "presse-papier" en revanche ne permet pas de détecter les
membres qui devraient rester en "doublon" dans la relation (les chemins
parcourus deux fois dans la ligne fait un détour... et parfois aussi
certains arrêts desservis deux fois sachant que le bus a son indicateur qui
affiche sur quelle partie de la ligne il est en indiquant soit un arrêt
dans le détour soit celui du terminus) : il faut vérifier manuellement le
nombre de doublons surlignés "en rose" dans les deux fenêtres. On aura le
problème tant qu'on n'aura pas de "route segments"

Pour ordonner les membres dans l'éditeur SANS glisser-déposer:
 - sélectionner les membres au clavier (flèches et touche SHIFT pour un
intervalle, ou CTRL pour ajouter/retirer un membre de la sélection) ou la
souris,
- puis utiliser les icônes monter/descendre de la barre latérale.

Ensuite peu importe si on a groupé les ways en tête de la relation ou à la
fin. Personnellement je préfère grouper les ways à la fin pour que les
premiers membres visibles soient les noms des premiers arrêts (les chemins
n'ont pas de nom évident), et ensuite grouper ensemble le "stop" nécessaire
pour la v2 (l'icône: devrait être un gros point rouge) avec sa "plateform"
(bus_stop de la v1, l'icone est celle d'un bus pour "bus", ou celle d'un
poteau d'arrêt pour les platform v2). On peut vérifier visuellement qu'on
ne s'est pas trompé de rôle.

Au minimum la relation devrait avoir deux "stop" (donc deux icones "points
rouges" ou "bus") ;  sur les lignes non circulaires, le premier "stop"
devrait avoir son rôle suffixé "_entry_only", et le dernier un rôle suffixé
"_exit_only". Dans un premier temps on n'est pas obligé d'avoir tous les
arrêts ("stop"), tant qu'on a toutes les stations ("platform"  ou
"bus_stop"). Cependant l'outil "sketch_line" ne cherche encore que les
"platform" ou "bus-stop" et semble ne pas prendre en compte encore les
"stop": les deux terminus devraient donc avoir les deux types d'objet
("stop" et "platform"~"bus_stop").



Le 27 octobre 2016 à 00:08,  a écrit :

> Aussi d'accord pour ordonner : même si dans certains cas ce n'est pas
> strictement nécessaire, c'est dans tous les cas beaucoup plus simple. Même
> tout simplement pour les vérifications manuelles.
>
> Si les arrêts sont numérotés dans l'ordre de la relation et les chemins
> sinon numérotés au moins avec un dégradé, on doit voir si c'est correct ou
> pas.
>
> Un glisser/déposer dans la liste des arrêts pour réordonnancer ?
>
> Idem pour les chemins ?
>
> Possibilité de sélectionner un arrêt sur la carte pour l'ajouter ? Idem
> pour un chemin ?
>
> Oui, pour la V2 ;-)
>
> Je pense que si à partir d'un arrêt de bus (sans doute via les relations
> définissant les lignes) on arrivait à remonter au niveau du Réseau et si
> avec le réseau et le nom de la ligne on avait une url nous donnant le
> trajet, on aurait déjà une aide à la vérification (comme ici je suis allé
> voir la star pour trouver, mais si je n'avais été dans la coin je ne
> saurais pas aller sur star.fr à partir d'un arrêt de bus desservi par la
> Star.
>
> N. B. : c'est vrai que des réseaux sont moins complets que celui de la
> Star qui pourtant est incorrect.
>
> Jean-Yvon
>
___
Talk-fr mailing

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

2016-10-26 Par sujet osm . sanspourriel 
Aussi d'accord pour ordonner : même si dans certains cas ce n'est pas 
strictement nécessaire, c'est dans tous les cas beaucoup plus simple. 
Même tout simplement pour les vérifications manuelles.


Si les arrêts sont numérotés dans l'ordre de la relation et les chemins 
sinon numérotés au moins avec un dégradé, on doit voir si c'est correct 
ou pas.


Un glisser/déposer dans la liste des arrêts pour réordonnancer ?

Idem pour les chemins ?

Possibilité de sélectionner un arrêt sur la carte pour l'ajouter ? Idem 
pour un chemin ?


Oui, pour la V2 ;-)

Je pense que si à partir d'un arrêt de bus (sans doute via les relations 
définissant les lignes) on arrivait à remonter au niveau du Réseau et si 
avec le réseau et le nom de la ligne on avait une url nous donnant le 
trajet, on aurait déjà une aide à la vérification (comme ici je suis 
allé voir la star pour trouver, mais si je n'avais été dans la coin je 
ne saurais pas aller sur star.fr à partir d'un arrêt de bus desservi par 
la Star.


N. B. : c'est vrai que des réseaux sont moins complets que celui de la 
Star qui pourtant est incorrect.


Jean-Yvon



Le 26/10/2016 à 23:41, Philippe Verdy - verd...@wanadoo.fr a écrit :
Dans le message qur tu cites on parle de "quelqu'un qui expérimente". 
Certes je suis en train de travailler dessus, mais c'est déjà le 
désordre et je n'expérimente pas, puisque c'est une schéma v2 
approuvé. Il manque des tas de détails et des erreurs il y en avait 
déjà avant dans les centaines de routes pas toutes au point (et il en 
manque encore pas mal).
C'est ce tri à faire qui représente pas mal de travail (pas qu'à 
Rennes d'ailleurs même si le réseau est "modèle" dans OSM, car pour 
les réseaux parisiens c'est encore pire!)


C'est un gros chantier qui ne peut pas se faire en une fois, rien que 
pour arriver au stade de la v2 (poser tous les "stop" manquants), 
sachant qu'il y aura une v3 pour les problèmes qui subsistent sur 
l'ordre des parcours, et le sens réel: à défaut en attendant, il FAUT 
ordonner, sinon on ne s'en sort pas.




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