Re: [OSM-talk-fr] Relation de riviere, Le Rhone

[François Lacombe]

Merci Marc pour la réponse, on est d'accord

Je vais essayer de corriger ca dès que possible

François

Le sam. 20 oct. 2018 à 20:01, marc marc  a
écrit :

> Le 18. 10. 18 à 23:55, François Lacombe a écrit :
> > La 1ere pour sur le filaire river :
> > https://www.openstreetmap.org/way/34907146
>
> c'est globalement correct https://www.openstreetmap.org/relation/1075117
> même s'il y a de nombreux soucis sur la relation dont des zones
> sans rôle mainstream et à l'inverse des zones avec plusieurs mainstream
> au même endroit.
> J'ai corrigé une partie du tracé hier mais pas encore touché
> à la relation pour éviter d'être à plusieurs dessus.
>
> > La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve :
> > https://www.openstreetmap.org/relation/660056
>
> en plus d'être déconseillé par le wiki et inutile
> c'est incorrect :
> - un ensemble de polygone qui se touche ne forment un multipolygone.
> un multipolygone dans osm est un ou plusieurs polygones qui ne se touche
> pas.
> Le rendu osm.org avait même parlé d’arrêté de faire de la devinette
> et de ne plus faire aucun rendu de certains multipolygone erronés
> afin que l'erreur soie visible au lieu d'avoir des problèmes en cascade.
> - Les berges du Rhône ne s'appelle pas le Rhône, il y a confusion.
>
> > Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer
> > la 2nde pour ne laisser que des polygones riverbanks continus sans
> > relation ?
>
> oui
>
> la page sur le wiki fr mériterait aussi d'être rafraîchie/rapprochée
> avec le contenu de la version anglaise.
>
> Et tant qu'à dire, les rôles tributary conflictuels
> sont sur la mauvaise relation
> https://wiki.openstreetmap.org/wiki/Relation:watershed
>
> Cordialement,
> Marc
> ___
> 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] signification multiple crossing=zebra

[marc marc]

En fait le soucis est quand tu fais l'inverse :
tu prend une image sat d'un endroit que tu ne connais pas,
tu édites avec iD, tu vois un zebra au sol,
tu ajoutes un "passage piéton zebra" et iD fait la supposition 
qu'automatiquement c'est un passage sans feu de circulation parce
qu'aux UK, il semblerait que le marquage au sol soie différent
pour les passages avec et sans feu, ce qui n'est pas le cas
ni en France ni en Belgique ni en Suisse
c'est cette supposition là que je propose de corriger.
si tu renseignes passag piéton avec zebra, ca veux juste dire cela.
permettant ainsi à ceux qui le souhaite d'ensuite compléter les
données pour renseigner si le passage piéton a ou non des feux.

Le 26. 10. 18 à 18:59, Gwenaël Jouvin a écrit :
> Bonsoir,
> 
> Lors de mes relevés je m’efforce de placer les passages (au moins ceux qui 
> apparaissent sur mes photos) et surtout, s’il y a des bandes d’éveil de 
> vigilance (tactile_paving=yes|no) et s’ils sont accessibles 
> (wheelchair=yes|limited|no).
> 
> Par contre, je ne vois pas véritablement la pertinence de l’attribut zebra 
> car, s’il a certainement une signification au Royaume-Uni ; c’est différent 
> en France où, par définition, tout passage pour piétons est marqué sur la 
> chaussée, donc ils sont tous « zebra » par défaut.
> 
> Bien sûr, on trouve dans certaines villes des « passages » mieux intégrés 
> dans l’urbanisme, par exemple délimités par des pavés, des clous voire un 
> revêtement ou des pierres colorées.
> Si ce sont bien des passages pour piétons par l’usage, ce n’en sont pas du 
> point de vue de la signalisation routière [1, art. 118].
> Je pense que l’on pourrait ajouter crossing=unmarked pour ces cas clairs par 
> l’usage mais litigieux par la loi.
> 
> Enfin pour finir sur les points litigieux, on voit aussi des passages 
> intégralement peints, en rouge par exemple. C’est illégal [2, II-1], en plus 
> d’être périlleux pour les deux-roues.
> 
> Gwenaël
> 
> 
> [1] IISR 7 : 
> http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_7ePARTIE_VC_20160215_cle217e65.pdf
> [2] Circulaire du 15-05-1996 : 
> https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT00376640
> 
> 
> Le 25/10/2018 à 23:51, marc marc a écrit :
>> 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 

Re: [OSM-talk-fr] Correction des voies de chemin de fer gare d'Austerlitz

[François Lacombe]

Salut Florian,

Tu m'accompagnes pour aller voir ca de visu ? :=)


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 


Le ven. 26 oct. 2018 à 18:57, Florian LAINEZ  a écrit :

> Hello,
> En faisant une mise-à-jour dans la gare Austerlitz j'ai remarqué qu'il
> manquait des voies au niveau -1 le long des quais du RER C.
> J'ai rajouté ça ici :
> https://www.openstreetmap.org/way/638180762
> https://www.openstreetmap.org/way/638180763
> Je ne sais pas ce que ces voies deviennent au nord et au sud du quai ni
> les détails à rajouter sur ces segments donc pour l'instant je les ai
> raccordé au réseau ferré avec un fixme.
> Peut-être que cela intéresse les spécialistes des réseaux, qui sait ? ;)
>
> Une fois sur la gare dans JOSM, utilisez les filtres de niveaux qui
> apparaissent en haut à gauche pour bien visualiser ce que j'ai fait.
>
> PS : J'ai fait ça aussi dans la gare souterraine de Musée d'Orsay et je
> vais continuer comme ça pour les autres gares parisiennes ...
>
> --
>
> *Florian Lainez*
> @overflorian 
> ___
> 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] signification multiple crossing=zebra

[Gwenaël Jouvin]

Bonsoir,

Lors de mes relevés je m’efforce de placer les passages (au moins ceux qui 
apparaissent sur mes photos) et surtout, s’il y a des bandes d’éveil de 
vigilance (tactile_paving=yes|no) et s’ils sont accessibles 
(wheelchair=yes|limited|no).

Par contre, je ne vois pas véritablement la pertinence de l’attribut zebra car, 
s’il a certainement une signification au Royaume-Uni ; c’est différent en 
France où, par définition, tout passage pour piétons est marqué sur la 
chaussée, donc ils sont tous « zebra » par défaut.

Bien sûr, on trouve dans certaines villes des « passages » mieux intégrés dans 
l’urbanisme, par exemple délimités par des pavés, des clous voire un revêtement 
ou des pierres colorées.
Si ce sont bien des passages pour piétons par l’usage, ce n’en sont pas du 
point de vue de la signalisation routière [1, art. 118].
Je pense que l’on pourrait ajouter crossing=unmarked pour ces cas clairs par 
l’usage mais litigieux par la loi.

Enfin pour finir sur les points litigieux, on voit aussi des passages 
intégralement peints, en rouge par exemple. C’est illégal [2, II-1], en plus 
d’être périlleux pour les deux-roues.

Gwenaël


[1] IISR 7 : 
http://www.equipementsdelaroute.equipement.gouv.fr/IMG/pdf/IISR_7ePARTIE_VC_20160215_cle217e65.pdf
[2] Circulaire du 15-05-1996 : 
https://www.legifrance.gouv.fr/jo_pdf.do?id=JORFTEXT00376640


Le 25/10/2018 à 23:51, marc marc a écrit :
> 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
> 

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

[OSM-talk-fr] Correction des voies de chemin de fer gare d'Austerlitz

[Florian LAINEZ]

Hello,
En faisant une mise-à-jour dans la gare Austerlitz j'ai remarqué qu'il
manquait des voies au niveau -1 le long des quais du RER C.
J'ai rajouté ça ici :
https://www.openstreetmap.org/way/638180762
https://www.openstreetmap.org/way/638180763
Je ne sais pas ce que ces voies deviennent au nord et au sud du quai ni les
détails à rajouter sur ces segments donc pour l'instant je les ai raccordé
au réseau ferré avec un fixme.
Peut-être que cela intéresse les spécialistes des réseaux, qui sait ? ;)

Une fois sur la gare dans JOSM, utilisez les filtres de niveaux qui
apparaissent en haut à gauche pour bien visualiser ce que j'ai fait.

PS : J'ai fait ça aussi dans la gare souterraine de Musée d'Orsay et je
vais continuer comme ça pour les autres gares parisiennes ...

-- 

*Florian Lainez*
@overflorian 
___
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

[Philippe Verdy]

D'ailleurs à mon avis je supprimerais complètement le "off" de l'attribut
"opening_hours=*" (il complique tout inutilement)

A la place je mettrais un autre attribut "closing_hours=*" (avec la même
syntaxe, mais là aussi sans "off" ni "on") et qui n'a de sens que s'il est
associé à un attribut "opening_hours=*" (à interpréter en premier, le
"closing_hours=*" n'apportant que des exceptions).

Dans ce cas plus d’ambiguïté du tout, plus besoin de virgule (encore moins
le "|" inutile), le point-virgule suffit à tout, chacune des deux listes
étant écrite dans un ordre quelconque.


Le ven. 26 oct. 2018 à 14:31, Philippe Verdy  a écrit :

> Note: si tous les éléments sont "on" (il n'y a aucun "off") utiliser la
> virgule ou le point-virgule ne donnera aucune différence puisque l'ordre
> n'est alors pas significatif. C'est pour ça que le point-virgule est aussi
> autorisé, mais il est à éviter totalement s'il y a même un seul élément
> "off" (qu'on doit placer à la fin, donc toujours après une virgule).
>
>
> Le ven. 26 oct. 2018 à 14:28, Philippe Verdy  a
> écrit :
>
>>
>>
>> Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  a écrit :
>>
>>> 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: ';' | ',' | '||'
>>>
>>
>> Pas tout à fait :
>> * le point-virgule dans un attribut indique une liste non-ordonnée (dont
>> les éléments peuvent être librement permutés sans changement
>> d'interprétation) : c'est valable normalement pour tout attribut OSM.
>> * alors que la virgule impose un ordre de priorité.
>>
>> De fait les éléments séparés par point-virgules doivent être indépendants
>> (ne pas se recouvrir, ou bien être équivalents sémantiquement)
>>
>> Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la
>> liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du
>> second (qui indique des horaires différents pour certaines dates).
>>
>> Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple,
>> où la virgule dans un liste vient ajouter des éléments (ajouter des plages
>> horaires, ou en retirer avec "off")  à la liste en modifiant les précédents.
>>
>> La syntaxe utilisée ci-dessus est en fait ambiguë puisque la partie
>> séparée par des virgules (une fois le point-virgule converti en virgule)
>> contient les éléments suivants, qui doivent être lus dans l'ordre, chaque
>> élément modifiant le calendrier:
>> - au départ (liste vide), par défaut tout est fermé, tous les jours
>> quelque soit l'heure
>> - "08:00-17:45" : ajoute l'ouverture tous les jours à cette plage horaire
>> (cela remplace la fermeture
>> - "PH" : n'indique aucune plage horaire, donc veut dire que cela ajoute
>> l'ouverture toute la journée (24/24) des jours fériés
>> - "Sa" : n'indique aucune plage horaire, donc veut dire  que cela ajoute
>> l'ouverture toute la journée (24/24) de tous les samedis (fériés ou pas)
>> - "Su 08:00-09:00 off" : exclue de tout ce qui précède l'ouverture de 8h
>> à 9h si c'est un dimanche (donc le dimanche reste ouvert 23h sur 24 si
>> c'est férié, sinon ouvert seulement de 9h à 17h45)
>> - "Mar 01-Mar Su[-1] 17:45-19:00 : ajoute l'ouverte à cette plage horaire
>> tous les jours de entre le 1er du mois de mars et le dernier dimanche de
>> mars (n'a pas d'effet sur les dimanches fériée de mars, mais les autres
>> dimanches non fériés de mars ont une ouverture allongée)
>> - etc. (autres plages horaires ajoutées pour d'autres dates)
>>
>> Cette liste ne peut pas être librement permutée (notamment entre les
>> éléments contenant des "off" et ceux qui sont "on" par défaut), mais peut
>> être permutée entre deux éléments "on" s'il n'y a aucun élément "off" entre
>> les deux.
>>
>> Et c'est le cas ici car tous les éléments sont "on" (par défaut), SAUF le
>> 4e (Su 08:00-09:00) qui est "off".
>>
>> Hors je ne pense pas que ce soit ce que tu voulais (pas convaincu que tu
>> voulais mettre des jours fériés avec une ouverture 24/24 (ou 23/24 le
>> dimanche). Si tu retire le 4e élément (Su 08:00-09:00 off), tous les autres
>> éléments sont librement permutables puisqu'ils sont tous "on" par défa

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

[Philippe Verdy]

Note: si tous les éléments sont "on" (il n'y a aucun "off") utiliser la
virgule ou le point-virgule ne donnera aucune différence puisque l'ordre
n'est alors pas significatif. C'est pour ça que le point-virgule est aussi
autorisé, mais il est à éviter totalement s'il y a même un seul élément
"off" (qu'on doit placer à la fin, donc toujours après une virgule).


Le ven. 26 oct. 2018 à 14:28, Philippe Verdy  a écrit :

>
>
> Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  a écrit :
>
>> 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: ';' | ',' | '||'
>>
>
> Pas tout à fait :
> * le point-virgule dans un attribut indique une liste non-ordonnée (dont
> les éléments peuvent être librement permutés sans changement
> d'interprétation) : c'est valable normalement pour tout attribut OSM.
> * alors que la virgule impose un ordre de priorité.
>
> De fait les éléments séparés par point-virgules doivent être indépendants
> (ne pas se recouvrir, ou bien être équivalents sémantiquement)
>
> Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la
> liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du
> second (qui indique des horaires différents pour certaines dates).
>
> Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple,
> où la virgule dans un liste vient ajouter des éléments (ajouter des plages
> horaires, ou en retirer avec "off")  à la liste en modifiant les précédents.
>
> La syntaxe utilisée ci-dessus est en fait ambiguë puisque la partie
> séparée par des virgules (une fois le point-virgule converti en virgule)
> contient les éléments suivants, qui doivent être lus dans l'ordre, chaque
> élément modifiant le calendrier:
> - au départ (liste vide), par défaut tout est fermé, tous les jours
> quelque soit l'heure
> - "08:00-17:45" : ajoute l'ouverture tous les jours à cette plage horaire
> (cela remplace la fermeture
> - "PH" : n'indique aucune plage horaire, donc veut dire que cela ajoute
> l'ouverture toute la journée (24/24) des jours fériés
> - "Sa" : n'indique aucune plage horaire, donc veut dire  que cela ajoute
> l'ouverture toute la journée (24/24) de tous les samedis (fériés ou pas)
> - "Su 08:00-09:00 off" : exclue de tout ce qui précède l'ouverture de 8h à
> 9h si c'est un dimanche (donc le dimanche reste ouvert 23h sur 24 si c'est
> férié, sinon ouvert seulement de 9h à 17h45)
> - "Mar 01-Mar Su[-1] 17:45-19:00 : ajoute l'ouverte à cette plage horaire
> tous les jours de entre le 1er du mois de mars et le dernier dimanche de
> mars (n'a pas d'effet sur les dimanches fériée de mars, mais les autres
> dimanches non fériés de mars ont une ouverture allongée)
> - etc. (autres plages horaires ajoutées pour d'autres dates)
>
> Cette liste ne peut pas être librement permutée (notamment entre les
> éléments contenant des "off" et ceux qui sont "on" par défaut), mais peut
> être permutée entre deux éléments "on" s'il n'y a aucun élément "off" entre
> les deux.
>
> Et c'est le cas ici car tous les éléments sont "on" (par défaut), SAUF le
> 4e (Su 08:00-09:00) qui est "off".
>
> Hors je ne pense pas que ce soit ce que tu voulais (pas convaincu que tu
> voulais mettre des jours fériés avec une ouverture 24/24 (ou 23/24 le
> dimanche). Si tu retire le 4e élément (Su 08:00-09:00 off), tous les autres
> éléments sont librement permutables puisqu'ils sont tous "on" par défaut :
> ils forment une combinaison (en "ou") de tous les horaires indiquer, ne
> peuvent pas se contredire entre eux mais peuvent se recouvrir mutuellement.
>
> Si tu utilises le ";" les éléments doivent être mutuellement exclusifs
> entre les dates concernées, mais c'est encore sujet à ambiguïté (le
> point-virgule ne devrait dont pas être utilisé du tout, la virgule en
> revanche garantie et impose l'ordre d'interprétation).
>
> En général il est plus simple de concevoir les opening_hours en listant
> d'abord au début tous les éléments "on" (par défaut) dans un ordre
> quelconque pour ajouter des horaires d'ouverture, et seulement ensuite en
> listant tous les éléments "off" aux aussi dans un ordre quelconque pour
> retirer certain

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

[Philippe Verdy]

Le jeu. 25 oct. 2018 à 16:45, Francois Gouget  a écrit :

> 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: ';' | ',' | '||'
>

Pas tout à fait :
* le point-virgule dans un attribut indique une liste non-ordonnée (dont
les éléments peuvent être librement permutés sans changement
d'interprétation) : c'est valable normalement pour tout attribut OSM.
* alors que la virgule impose un ordre de priorité.

De fait les éléments séparés par point-virgules doivent être indépendants
(ne pas se recouvrir, ou bien être équivalents sémantiquement)

Ce qui n'est pas le cas dans l'exemple ici car le premier élément de la
liste séparée par point-virgule "08:00-17:45" couvre une bonne partie du
second (qui indique des horaires différents pour certaines dates).

Il ne devrait donc pas y avoir de point-virgule du tout dans ton exemple,
où la virgule dans un liste vient ajouter des éléments (ajouter des plages
horaires, ou en retirer avec "off")  à la liste en modifiant les précédents.

La syntaxe utilisée ci-dessus est en fait ambiguë puisque la partie séparée
par des virgules (une fois le point-virgule converti en virgule) contient
les éléments suivants, qui doivent être lus dans l'ordre, chaque élément
modifiant le calendrier:
- au départ (liste vide), par défaut tout est fermé, tous les jours quelque
soit l'heure
- "08:00-17:45" : ajoute l'ouverture tous les jours à cette plage horaire
(cela remplace la fermeture
- "PH" : n'indique aucune plage horaire, donc veut dire que cela ajoute
l'ouverture toute la journée (24/24) des jours fériés
- "Sa" : n'indique aucune plage horaire, donc veut dire  que cela ajoute
l'ouverture toute la journée (24/24) de tous les samedis (fériés ou pas)
- "Su 08:00-09:00 off" : exclue de tout ce qui précède l'ouverture de 8h à
9h si c'est un dimanche (donc le dimanche reste ouvert 23h sur 24 si c'est
férié, sinon ouvert seulement de 9h à 17h45)
- "Mar 01-Mar Su[-1] 17:45-19:00 : ajoute l'ouverte à cette plage horaire
tous les jours de entre le 1er du mois de mars et le dernier dimanche de
mars (n'a pas d'effet sur les dimanches fériée de mars, mais les autres
dimanches non fériés de mars ont une ouverture allongée)
- etc. (autres plages horaires ajoutées pour d'autres dates)

Cette liste ne peut pas être librement permutée (notamment entre les
éléments contenant des "off" et ceux qui sont "on" par défaut), mais peut
être permutée entre deux éléments "on" s'il n'y a aucun élément "off" entre
les deux.

Et c'est le cas ici car tous les éléments sont "on" (par défaut), SAUF le
4e (Su 08:00-09:00) qui est "off".

Hors je ne pense pas que ce soit ce que tu voulais (pas convaincu que tu
voulais mettre des jours fériés avec une ouverture 24/24 (ou 23/24 le
dimanche). Si tu retire le 4e élément (Su 08:00-09:00 off), tous les autres
éléments sont librement permutables puisqu'ils sont tous "on" par défaut :
ils forment une combinaison (en "ou") de tous les horaires indiquer, ne
peuvent pas se contredire entre eux mais peuvent se recouvrir mutuellement.

Si tu utilises le ";" les éléments doivent être mutuellement exclusifs
entre les dates concernées, mais c'est encore sujet à ambiguïté (le
point-virgule ne devrait dont pas être utilisé du tout, la virgule en
revanche garantie et impose l'ordre d'interprétation).

En général il est plus simple de concevoir les opening_hours en listant
d'abord au début tous les éléments "on" (par défaut) dans un ordre
quelconque pour ajouter des horaires d'ouverture, et seulement ensuite en
listant tous les éléments "off" aux aussi dans un ordre quelconque pour
retirer certains horaires ajoutés par la première liste (donc mentionner
des exceptions à la première liste) : il n'y a alors aucun risque
d'ambiguité.

L'ennui de la syntaxe actuelle est qu'elle oblige à répéter explicitement
la propriété "off" pour chacun des éléments "off" de la seconde liste; il
aurait juste suffit d'imposer l'ordre "liste de tous les horaires
d'ouverture", puis un mot clé "off" suivi de la liste des exceptions où des
horaires sont fermés). On aurait eu une syntaxe allégé (plus d'obligation
de répéter "off", plus facile à interpréter, et jamais ambiguë

Mais 

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

[Nicolas Bétheuil]

J'ai été poser la question

https://ask.openrouteservice.org/t/roadworks-and-how-to-handle-it/45
https://groups.google.com/forum/#!topic/osm-android-bikerouting/bsRYArj8fCM
https://groups.google.com/forum/#!topic/opentripplanner-users/ryjK46IoOY8

pour commencer

Le ven. 26 oct. 2018 à 08:28, Phyks  a écrit :

> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr