[OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

2018-10-25 Par sujet Phyks 
Merci ! J'avais pensé à verser les signalements de cyclassist dans OED
(et utiliser OED plutôt qu'une base différente pour cyclassist), mais je
n'étais pas sûr que ça ait parfaitement sa place dans OED. J'avais eu un
peu de mal à trouver de la doc / des points de contact aussi :/

Mais c'est quelque chose qui pourrait changer facilement, il y a de quoi
faire un dump des signalements de Cycl'Assist facilement.


Concernant les travaux, pour l'instant je récupère des points libres
mais je voudrais reprendre ça pour les associer à des objets OSM. La
plupart des sources fournissent une aire touchée par les travaux et il
suffit alors de chercher les intersections avec les objets OSM. C'est
sur ma liste de trucs à faire.


Concernant les modes de transport affectés (ou les fermetures partielles
/ totales etc), c'est très souvent donné dans un champ texte libre, avec
toutes les variations possibles du coup… rien de normalisé et de facile
à réutiliser j'ai l'impression :/


Pour réutiliser ça dans un calculateur d'itinéraires, je sais que
certains proposent d'éviter des zones (OpenRouteService proposé par JB,
brouter aussi). Du coup, pas besoin d'associer ça précisément à un objet
OSM. Le seul problème que je vois avec les zones à éviter c'est que ces
zones de travaux ne sont pas forcément "à éviter" mais plutôt "à
pénaliser", du moins tant que l'information précise des éléments
(trottoirs, chaussée, fermeture partielle ou totale) n'est pas bien
connu. Des travaux sur un trottoir impliquent probablement des
complications pour les automobilistes, mais il n'y a aucune raison a
priori d'éviter totalement la zone.

-- 
Phyks

Le 25/10/2018 à 10:45, Nicolas Bétheuil a écrit :
> Classe ! Félicitations !
> J'adore la richesse d'OSM ! Ou de verser cyclassist dans OED ? L'api d'OED
> est publique.
> Dire si ça concerne que les vélos où aussi les voitures, les piétons,
> mobilité réduite ?
> Après pour que ce soit exploitable dans OSM par un calculateur
> d'itinéraire, il faut rattacher ça à des objets OSM pour les tagguer ?
> 
> Le jeu. 25 oct. 2018 à 09:33, Phyks  a écrit :
> 
>> Salut,
>>
>>> Vu que chaque ville à sa propre base / api ça me paraît compliqué que les
>>> calculateurs d'itinéraire le prenne en compte nottament avec les
>> arguments
>>> déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import dans OSM
>>> mais que des contributeurs revalident ces données, modifier OSM me parait
>>> aussi compliqué en automatique : ce n'est pas qu'ajouter un POI, faire
>> une
>>> conflation ... les différents chantiers ont différents impact donc à
>>> tagguer différemment.
>>
>> J'ai
>> https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
>> en stock avec toutes les opendata sur les travaux que j'ai trouvées en
>> France pour l'instant (et qui les uniformise un minimum).
>>
>> Ça devrait être possible de reprendre un script du genre et de
>> l'injecter dans OED, non ?
>>
>> --
>> Phyks
>>
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 



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

[OSM-talk-fr] signification multiple crossing=zebra

2018-10-25 Par sujet marc marc 
Bonjour,

j'aurais du vous proposer une édition de masse sur ce sujet.
c'était en préparation depuis longtemps depuis que le problème avait été 
identifié lors d'une discussion cartomobilité qui discute entre autre 
des problèmes de comment osm peux aider pour renseigner l'accessibilité 
multiple.
mais voila, ces oir josm a poussé un patch qui complique encore la 
chose. je vais donc vous exposer le problème en français, traduction
de celui que je viens de poster sur tagging (la ml mondiale anglaise 
pour les problèmes de tag).

Bonjour. Bonjour,

J'ai un gros problème avec crossing=zebra.
il empêche de remplir d'autre valeur pour le croisement comme 
crossing=traffic_signals (passage piéton avec un feu de circulation) 
crossing=uncontrolled (passage piéton sans feu)
le wiki[1] dit que crossing=zebra est un raccourci pour 
crossing=uncontrolled + crossing_ref=zebra au Royaume-Uni
mais beaucoup de zébra tant au Royaume-Uni, qu'en France et ailleur
ont des zébra avec feu qui doivent donc être renseign avec 
crossing=traffic_signals
donc à la fin, crossing=zebra n'a pas de sens... peut-être
que le contributeur précédent voulait dire crossing=uncontrolled + 
crossing_ref=zebra
mais peut-être qu'il veut dire seulement crossing_ref=zebra et qu'il n'a 
aucune idée de la présence de feu ou pas (ajout depuis l'imagerie sat 
par exemple).
J'ai corrigé il y a quelques semaines beaucoup de crossing=zebra 
crossing_1=signals_traffic_signals
ou crossing=zebra;traffic_signals qui montrent que c'est un problème.

un ticket a été fermé dans iD[2] il y a quelque temps parce que "son dev 
n'aime pas crossing_ref" (c'est en fait un nom très laid pour le tag)
en ce moment josm[3] change le preset pour supprimer cossing_ref=zebra
en faveur du croissing=zébra

Je fais partie d'un groupe de cartographes travaillant sur 
l'accessibilité yant l'intention d'ouvrir une discussion pour y 
remédier, mais l'actualité des commit nous a précédés.

donc ma requête est : comment éviter à nouveau une balise multi sens ?

Peut/doit-on séparer le type de croisement du marquage au sol ?
en résumé : changer les crossing=zebra au profit d'une autre balise ?
si oui crossing_Ref est-il si laid que dans le même temps un autre tag 
en a besoin à utiliser pour le marquage au sol ?
(ajout hors traduction : perso je suis partisant d'étape limité séparée
et donc initialement j'aurais changer crossing=zebra en 
crossing_ref=zebra et reporté le choix d'un meilleur non pour le 
marquage dans un autre sujet)

évitons l'argument "il y a trop de cas à régler",
cela ne m'effraie pas de proposer une édition de masse une fois qu'un 
schéma cohérent a été établi.
mais le fait d'avoir la moité des outils qui remplissent une valeur avec 
une autre signification que l'autre ou que la signification historique 
est un gros problème pour l'utilisation. des données.

[1] https://wiki.openstreetmap.org/wiki/Key:crossing
[2] https://github.com/openstreetmap/iD/issues/4788
[3] https://josm.openstreetmap.de/ticket/16793
https://taginfo.openstreetmap.fr/search?q=%3Dzebra

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

Re: [OSM-talk-fr] vérification de quelques tags,

2018-10-25 Par sujet deuzeffe 

On 10/25/18 1:08 PM, JB wrote:

Les thématiques qui me parlent : Le 24/10/2018 à 18:30, ades a écrit :
waterway:riverbanks on suit le wiki français : pas de riverbank si 
largeur moins de 12m?
Va vraiment falloir que quelqu'un aille modifier ce wiki, 


Just do it?
--
deuzeffe

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

Re: [OSM-talk-fr] opening_hours contre les parcs parisiens

2018-10-25 Par sujet Francois Gouget 
On Thu, 25 Oct 2018, Megan Parat wrote:
[...]
> En utilisant les particularités des séparateurs de règles, et un ordre
> particulier, j'ai cette expression d'opening_hours qui comporte 161
> caractères :
> 
> 08:00-17:45; PH,Sa,Su 08:00-09:00 off, Mar 01-Mar Su[-1] 17:45-19:00,
> Oct 01-Oct Su[-1] 17:45-19:30, Mar Su[-1]-Apr 30,Sep 17:45-20:30, May
> 01-Aug 31 17:45-21:30
> 
> Je crois qu'elle est valide.

Joli !
Après consultation de la "spécification complète" (dont je ne trouve le 
lien que dans la version anglaise du wiki), je crois aussi qu'elle est 
valide.

Là où la page opening_hours laisse penser que la virgule ne peut être 
utilisée que dans les listes (d'années, de mois ou d'heures), la 
spécification complète indique qu'on peut l'utiliser partout où on peut 
utiliser le point-virgule :

|  opening_hours = 
|  :  {   }
|  any_rule_separator: ';' | ',' | '||'

Il même prévu explicitement qu'on puisse l'utiliser ainsi :

|  An additional rule is treated exactly the same as a normal rule, 
|  except that an additional rule does not overwrite the day for which 
|  it applies (unlike the  which starts always 
|  with a new, empty day, deleting any previous rules applying for the 
|  given day). Note that an additional rule does not use any data from 
|  previous or from following rules. If time wraps over midnight are 
|  involved then you will probably also need to use additional rules to 
|  not overwrite the part which wraps into the next day. It can also be 
|  used to specify different comments for one day. Read more (including 
|  some examples) in this issue on github.
|
|  Because of the peskiness that the  is the 
|  same token as the token to separate lists (e.g.  { , 
|   }) the , (comma) is only interpreted as 
|   if it follows after one of those symbols:
|
|   12:00-14:00, We 16:00-18:00
|   12:00-14:00 unknown, We 16:00-18:00
|   12:00-14:00 "call us", We 16:00-18:00


Je note aussi l'utilisation de "Mar Su[-1]-Apr 30". J'avais essayé "Mar 
Su[-1]-Apr" qui ne marche pas. Si on spécifie un jour de début ou de fin 
il faut aussi spécifier un jour de l'autre coté même si on pourrait 
penser que le mois est suffisant et que le jour est implicitement 
évident.

-- 
Francois Gouget   http://fgouget.free.fr/
A particle is an irreducible representation of the Poincaré Group - Eugene 
Wigner___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] vérification de quelques tags,

2018-10-25 Par sujet JB 

Les thématiques qui me parlent : Le 24/10/2018 à 18:30, ades a écrit :

waterway:riverbanks on suit le wiki français : pas de riverbank si largeur 
moins de 12m?
Va vraiment falloir que quelqu'un aille modifier ce wiki, la question 
revient régulièrement. 12m, ça date de l'époque où on ne pouvait pas 
faire mieux faute d'outils et d'imagerie adaptée. Je ne dis pas que 50cm 
serait la bonne limite, mais on peut faire bien mieux que 12m actuellement.

landuse:forest vs natural:wood dans une zone complètement anthropisée c’est 
landuse:forest ?
Bof, tu fais un peu comme tu veux, les puristes n'arrivent pas à se 
mettre d'accord sur une définition et les autres s'en fichent un peu.


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

Re: [OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

2018-10-25 Par sujet JB 
Je ne sais plus quels moteurs de routage permettent d'éviter des zones 
prédéfinies comme OpenRouteService 
(https://wiki.openstreetmap.org/wiki/OpenRouteService/Help#Avoid_Areas), 
mais ça me semble être typiquement la base de données de zones à éviter 
qu'ils pourraient utiliser.

JBx

Le 25/10/2018 à 10:45, Nicolas Bétheuil a écrit :

Classe ! Félicitations !
J'adore la richesse d'OSM ! Ou de verser cyclassist dans OED ? L'api 
d'OED est publique.
Dire si ça concerne que les vélos où aussi les voitures, les piétons, 
mobilité réduite ?
Après pour que ce soit exploitable dans OSM par un calculateur 
d'itinéraire, il faut rattacher ça à des objets OSM pour les tagguer ?


Le jeu. 25 oct. 2018 à 09:33, Phyks > a écrit :


Salut,

> Vu que chaque ville à sa propre base / api ça me paraît
compliqué que les
> calculateurs d'itinéraire le prenne en compte nottament avec les
arguments
> déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import
dans OSM
> mais que des contributeurs revalident ces données, modifier OSM
me parait
> aussi compliqué en automatique : ce n'est pas qu'ajouter un POI,
faire une
> conflation ... les différents chantiers ont différents impact donc à
> tagguer différemment.

J'ai
https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
en stock avec toutes les opendata sur les travaux que j'ai trouvées en
France pour l'instant (et qui les uniformise un minimum).

Ça devrait être possible de reprendre un script du genre et de
l'injecter dans OED, non ?

-- 
Phyks




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



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


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

Re: [OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

2018-10-25 Par sujet Nicolas Bétheuil 
Classe ! Félicitations !
J'adore la richesse d'OSM ! Ou de verser cyclassist dans OED ? L'api d'OED
est publique.
Dire si ça concerne que les vélos où aussi les voitures, les piétons,
mobilité réduite ?
Après pour que ce soit exploitable dans OSM par un calculateur
d'itinéraire, il faut rattacher ça à des objets OSM pour les tagguer ?

Le jeu. 25 oct. 2018 à 09:33, Phyks  a écrit :

> Salut,
>
> > Vu que chaque ville à sa propre base / api ça me paraît compliqué que les
> > calculateurs d'itinéraire le prenne en compte nottament avec les
> arguments
> > déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import dans OSM
> > mais que des contributeurs revalident ces données, modifier OSM me parait
> > aussi compliqué en automatique : ce n'est pas qu'ajouter un POI, faire
> une
> > conflation ... les différents chantiers ont différents impact donc à
> > tagguer différemment.
>
> J'ai
> https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
> en stock avec toutes les opendata sur les travaux que j'ai trouvées en
> France pour l'instant (et qui les uniformise un minimum).
>
> Ça devrait être possible de reprendre un script du genre et de
> l'injecter dans OED, non ?
>
> --
> Phyks
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

2018-10-25 Par sujet Christian Quest 
OpenEventDatabase n'est pas franco-français, la base (et son API) sont
ouvertes à toutes données, exactement comme OSM. Il y a des données hors de
France (comme les tremblements de terre).

Ok, le contenu actuel est quasiment uniquement franco-français, car je suis
quasiment le seul à publier des données dedans, mais bon, OSM c'était aussi
britano-anglais au tout départ ;)

Des données sur les travaux il en existe à différents endroits et les
agréger sur une plateforme commune (OEDB) permet aux N utilisateurs de
données de ne pas de prendre la tête avec les M sources. C'est la même
chose avec OSM... on harmonise les données au sein d'une même base/API et
avec un format et une structure unifié.

Tout comme OSM, l'enjeu est d'arriver à ce que les producteurs de données,
les publie directement dans cette base commune via l'API... mais on voit a
quel point c'est délicat pour OSM malgré sa notoriété !
L'avantage avec les événements, c'est qu'ils sont moins interdépendants que
les données OSM. On peut publier un événement sans trop se préoccuper de
l'existant.

Pour injecter des événements dans OEDB, j'ai publié quelques scripts
(python) sur https://github.com/openeventdatabase/datasources

Un exemple avec les infos traffic de Versailles:
https://github.com/openeventdatabase/datasources/blob/master/fr.versailles/versailles.py


Le jeu. 25 oct. 2018 à 09:35, Phyks  a écrit :

> Salut,
>
> > Vu que chaque ville à sa propre base / api ça me paraît compliqué que les
> > calculateurs d'itinéraire le prenne en compte nottament avec les
> arguments
> > déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import dans OSM
> > mais que des contributeurs revalident ces données, modifier OSM me parait
> > aussi compliqué en automatique : ce n'est pas qu'ajouter un POI, faire
> une
> > conflation ... les différents chantiers ont différents impact donc à
> > tagguer différemment.
>
> J'ai
> https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
> en stock avec toutes les opendata sur les travaux que j'ai trouvées en
> France pour l'instant (et qui les uniformise un minimum).
>
> Ça devrait être possible de reprendre un script du genre et de
> l'injecter dans OED, non ?
>
> --
> Phyks
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

[OSM-talk-fr] Calcul d'itinéraire prenant en compte les travaux

2018-10-25 Par sujet Phyks 
Salut,

> Vu que chaque ville à sa propre base / api ça me paraît compliqué que les
> calculateurs d'itinéraire le prenne en compte nottament avec les arguments
> déjà évoqués. Vu aussi que l'idée est de ne pas faire d'import dans OSM
> mais que des contributeurs revalident ces données, modifier OSM me parait
> aussi compliqué en automatique : ce n'est pas qu'ajouter un POI, faire une
> conflation ... les différents chantiers ont différents impact donc à
> tagguer différemment.

J'ai
https://framagit.org/phyks/cyclassist/blob/master/scripts/opendata/works.py
en stock avec toutes les opendata sur les travaux que j'ai trouvées en
France pour l'instant (et qui les uniformise un minimum).

Ça devrait être possible de reprendre un script du genre et de
l'injecter dans OED, non ?

-- 
Phyks



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