Re: [OSM-talk-fr] taille des changeset

[David Faure via Talk-fr]

On samedi 28 novembre 2020 13:12:02 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Ça a l'air bon.

Cool, merci à toi et à Marc pour les retours.

Je viens de procéder à l'import initial, tout s'est bien passé.

Un exemple de changeset :
https://www.openstreetmap.org/changeset/94950838
ou plus exotique :
https://www.openstreetmap.org/changeset/94950984

Je relancerai le script tous les weekends maintenant que tout est automatisé
(mais je vérifie les premiers changesets à la main bien sur).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] taille des changeset

[David Faure via Talk-fr]

On vendredi 27 novembre 2020 12:54:11 CET Marc_marc wrote:
> Bonjour,
> 
> >> 1 537 changets pour 9 730 objets.
> >> Ça fait quand même vraiment beaucoup de changesets.
> > 
> > Vraiment ? Avec StreetComplete j'ai fait 764 changesets
> > pour 2727 objets,
> 
> cela dépend beaucoup de ce que tu fais.
> 
> un contributeur qui modifie un café dans un aéroport à Paris
> et un autre café à l'aéroport de Hong-Kong serrait bien avisé
> de ne pas envoyer ces 2 modifs dans le même changeset couvrant
> la moitié du monde. ce ne sont pas les mêmes contributeur pouvant
> vérifier les 2.
> 
> à l'inverse si tu te balade sur les Champs-Élysées pour renseigner
> toutes les lampadaires, il y a aucun soucis à faire un changeset
> même si au final cela te fait 1000 objets en une fois.
> et faire diviser cela tous les 10 lampadaires ne serrait
> agréable pour personne.
> 
> par comparaison :
> - le projet mondial d'import des stations d'essence (qui n'avaient
> pas abouti) avait conduit à diviser pour avoir au moins un changeset
> par pays.
> - les opérations de masses dument approuvée pour virer le bug
> de wheelchair map avait conduit à un changeset par pays pour
> les pays les plus affectés puis à un changeset par continent
> pour le solde, personne n'avait objecté.

OK, bon, pour essayer que tout le monde soit content je coupe la poire en 
deux. J'ai agrandi très largement l'aire maximale pour les changements
(le concept reste pour au moins éviter de mettre les DOM-TOM dans le même 
changeset que la France métropolitaine).

Maintenant ça me donne 66 changesets 8780 objets (et ça inclut la séparation 
des deux types de changesets, ajout de PH=off, et mettre quand c'est vide).

Je commence avec les PH=off.
https://www.openstreetmap.org/changeset/94938297

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On jeudi 26 novembre 2020 15:23:03 CET Frédéric Rodrigo wrote:
> Le 26/11/2020 à 10:09, Marc_marc a écrit :
> > Le 25.11.20 à 21:39, David Faure via Talk-fr a écrit :
> >> Bonjour à tous,
> >> 
> >> Voici un résumé de l'état des choses concernant cet import
> > 
> > pour ma part un import doit être limpide, donc si je résume
> > la première étape :
> > - ne cibler que ceux qui n'ont pas d'horaire cad ne pas toucher les
> > objets qui ont opening_hours ni opening_hours:covid19 (parce qu'on sait
> > pas si osm a une version corrigée des horaires théoriques ou non)
> > - ne pas mixer 2 sujets dans le même changeset, cad ne profiter de
> > l'ajout d'horaire sur certains pour corriger des PH manquant sur
> > d'autre: c'est telement plus propre un changeset séparé qui
> > dit "ajout de PH manquant dans les horaires existant".
> 
> +1

On pinaille un peu non ?
C'est le même sujet, c'est "utilisation des horaires fournis par datanova".

Soit parce qu'il n'y en avait pas, soit parce la différence est seulement 
PH=off. A l'avenir il pourrait y avoir d'autres raisons qu'on considère 
acceptables...

> >> Ça donne 1537 changesets concernant chacun entre 1 et 96 bureaux de
> >> poste.
> > 
> > pq pas si t'as envie... mais un import avec des changeset n'ayant
> > parfois qu'un bureau, cela limite l'intérêt du changeset.
> > perso un changeset pour la france ou un par région, cela me choque
> > pas, ces bureaux n'avaient de toute façon pas d'horaire.
> > mais peu importe ton choix à ce niveau, ce point est pour moi ok,
> 
> Même avis ici aussi.
> 
> 1 537 changets pour 9 730 objets. Ça fait quand même vraiment beaucoup de
> changesets.

Vraiment ? Avec StreetComplete j'ai fait 764 changesets pour 2727 objets, si 
je comprends bien le "764 Modifications" affiché sur 
https://www.openstreetmap.org/user/Dfaurekde
et le 2727 affiché en haut à gauche dans StreetComplete.

L'idée c'était d'éviter les notifications intempestives, puisqu'apparemment 
certains monitorent une zone bien spécifique et ne veulent pas recevoir de 
notifications intempestives liées à un changement à grande échelle.
D'un autre côté, ça arrive super souvent, non ?
Un exemple au hasard: https://www.openstreetmap.org/changeset/94106441
(merci à toi zorglubu, d'intégrer + de bureaux de postes, ça va m'aider !)

Je peux ajuster la taille de la zone max pour créer moins de changesets.
Mais ... ça change quoi au final ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import d'horaires et :covid19

[David Faure via Talk-fr]

On mercredi 25 novembre 2020 22:27:34 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Bonjour, les messages de Marc et de David sont l'occasion de rappeler à
> propos des horaires que quand on a une source fiable, on n'a pas à se
> poser la question de savoir si on doit ou pas avec un suffixe :covid19.

Ah, en effet.

> Du coup je propose (en dehors du script histoire de ne pas engendrer des
> aller-retours) de supprimer les opening_hours:covid19 si on met à jour
> opening_hours automatiquement.

Ca ne rentre pas tout a fait dans mon approche conservative..
Je ne touche pas aux bureaux avec opening_hours, donc :
- ceux qui ont opening_hours et opening_hours:covid19, j'y touche pas
- ceux qui ont *seulement* opening_hours:covid19 (il y en a 788), oups, il faut 
prendre ça en compte :

* 139 disent "open", bon, on peut laisser ça et importer opening_hours.
* 448 disent "off", ça rentre dans le "désaccord" et du coup je ne devrais pas 
y toucher. Même si je suspecte fortement que ça date du premier confinement et 
que c'est maintenant ouvert, comme indiqué par datanova.
* et 201 ont de vrais horaires, mais différents de ceux de datanova, donc 
pareil, pas touche...

> Ce sont peut-être en partie les bureaux que David trouve avec des
> horaires en conflits OSM <> Datanova.

Ceux qui n'ont rien dans opening_hours sont de nouveaux conflits :-)

Du coup, 649 imports de moins.

Mais bon faut relativiser, y'a jusqu'à 5376 imports potentiels en plus, qui ne 
se font pas parce que la ref:FR:LaPoste est manquante dans OSM.
Donc clairement ce qui aidera le plus après l'import initial, c'est de terminer 
l'intégration de l'import des bureaux de poste (beaucoup de ref manquantes).
http://osmose.openstreetmap.fr/fr/map/#zoom=9=44.147=4.729=7050%2C8020%2C8021%2C8022=1%2C2%2C3=post=

> Auquel cas ça faut le coup de supprimer opening_hours:covid19 si on met
> à jour opening_hours automatiquement.

Avec l'approche conservative de "si y'a, je touche pas", ça veut dire que je ne 
supprime pas opening_hours:covid19
non plus. Sauf si on décide que c'est un cas où on veut donner priorité aux 
données de la poste, mais difficile d'être sûr
de si c'est 100% correct. Je crains toujours le cas d'une ref:FR:LaPoste 
incorrecte (suite à renumérotation par exemple).
Donc je donne priorité à "la fourmi sur place", je ne fournis des données "que" 
pour les 8889 cas où il n'y a pour l'instant aucune info.
C'est déjà pas mal :)

> David, c'est donc ma proposition pour gérer une partie des cas refusés
> pour le moment : on compare avec opening_hours:covid19, si c'est bon on
> supprime opening_hours:covid19 et on met opening_hours à jour.

Malheureusement j'ai 0 cas où datanova == opening_hours:covid19...

Les choses ont changé depuis mars, aucun bureau n'a les mêmes horaires 
maintenant qu'en mars...
Exemple au hasard :
17129A: no opening_hours but covid hours: Mo-Fr 09:00-12:00,14:00-17:00, 
datanova: Mo-Fr 09:00-18:30; Sa 08:30-12:30; PH off

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

Bonjour à tous,

Voici un résumé de l'état des choses concernant cet import, après les 
discussions ici (et aussi en privé avec Jean-Yvon qui m'a donné de nombreux 
bons conseils).

Pour rappel, tout est documenté sur :
https://wiki.openstreetmap.org/wiki/Import/FrenchPostOfficeOpeningHours

J'ai de quoi importer des horaires pour 9730 bureaux de poste identifiés dans 
OSM par leur référence LaPoste. La plupart n'ont pas du tout d'horaires pour 
l'instant, et pour 183 d'entre eux les horaires collent sauf qu'il manque "PH 
off" à la fin, je propose donc de l'ajouter pour que soit exactement égal.

Au lieu de la manip manuelle initialement suggérée (avec JOSM),
j'ai maintenant le code qui va bien pour découper en changesets, chacun étant 
limité à une région de 500m² pour éviter les notifications sur une trop grande 
zone.
Ça donne 1537 changesets concernant chacun entre 1 et 96 bureaux de poste.

Vu les discussions précédentes, je ne touche pas à l'attribut source, 
seulement à opening_hours. Je ne touche pas non plus aux 1057 bureaux qui ont 
un horaire différent dans OSM et datanova. On verra plus tard pour l'idée 
d'ajouter un fixme ou d'utiliser osmose pour montrer ces différences.
On verra aussi plus tard pour intégrer "collection_times". Autant faire 
incrémental.

L'upload de ces changesets est scripté lui aussi, avec osm-bulk-upload.
J'ai testé les scripts sur un bureau de poste prêt d'ici, tout marche.

A ce stade, je me sens donc prêt à uploader tout ça, mais c'est l'occasion de 
faire un dernier point ici pour avoir votre accord d'abord.

Par la suite, ces mêmes scripts mettront à jour les horaires modifiés par 
datanova, si personne n'y a touché dans OSM entre temps. Tout est déjà codé et 
testé pour pouvoir faire ça. Je pense le lancer tous les week-ends, pour bien 
avoir des horaires à jour, y compris quand un bureau décide d'une fermeture 
exceptionnelle pour la semaine suivante.

OK pour tout le monde ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] tag opening_hours vers texte

[David Faure via Talk-fr]

On samedi 21 novembre 2020 20:11:27 CET Noémie Lehuby via Talk-fr wrote:
> Bonjour,
> 
> Vous connaissez un service qui serait capable de transformer un tag
> opening_hours en texte intelligible par un humain ?
> 
> Par exemple "Mo-Fr 09:30-12:00,13:30-18:00" deviendrait "du lundi au
> vendredi de 9h30 à 12h puis de 13h30 à 18h"
> 
> Il me semble avoir déjà entendu parler d'un lib qui ferait ça mais je
> n'arrive pas à remettre la main dessus...

Il existe https://github.com/rezemika/humanized_opening_hours

mais c'est plus vraiment maintenu, cf tout dernier message sur
https://zestedesavoir.com/billets/2653/quelques-statistiques-sur-le-champ-opening-hours-dopenstreetmap/?page=1#p227797

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suffixe :covid19

[David Faure via Talk-fr]

On vendredi 20 novembre 2020 15:55:18 CET Éric Gillet wrote:
> Le suffixe :covid19 (opening_hours:covid19, delivery:covid19 etc.) a été
> créé pour le premier confinement, lorsque beaucoup de monde espérait
> qu'il soit de courte durée et enraye la pandémie.
> La covid19 n'a pas disparu après le premier confinement, mais beaucoup
> de commerces "non-essentiels" ont rouvert, ou on retrouvé un
> fonctionnement "classique". D'ici quelques semaines (croisons les
> doigts), on aura la même situation : déconfinement, peut-être
> couvre-feu, mais néanmoins covid19 toujours présente.
> 
> Ce suffixe ne fait malheureusement pas la distinction entre pandémie et
> confinement (et couvre-feu etc.), il est donc difficile de connaître son
> application. De plus, même si l'on dit qu'il ne s'applique que pour le
> confinement, il est difficile de savoir si les horaires (ou autre) sont
> revenues à la version pré-confinement, sont restées telle-quelles ou ont
> été modifiées.
> 
> Ne faudrait-il pas de nouveau utiliser les tags sans suffixe :covid19,
> gérer ces modifications comme des changements classiques ? Que ce soit
> pour les descriptions, horaires, livraisons, service à emporter etc.
> 
> Cela a également l'avantage que ces tags sont affichés et modifiés par
> la plupart des applications, contrairement aux suffixes :covid19. Cela
> engendre des contradictions si les contributeurs ou applications ne
> gèrent pas les deux.

Je suis 100% d'accord.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On lundi 16 novembre 2020 17:44:24 CET Jérôme Amagat wrote:
> Je suis d'accord, aucune solution n'est parfaite. Mais dire, on supprime
> source=* car la source est quelque part dans l'historique de l'objet, je
> n'y vois pas la solution miracle, loin de là.
> 
> Il faut revenir au sujet de cette discussion, on parle de modifier un tag
> sur 1000 objets en France. 

1.

> Est ce qu'au niveau mondial, il a été décidé de
> supprimer le tag source=* ? A ma connaissance non.
>
> Je ne vois pas de problème à parler de la façon d'indiquer la source, mais
> le principal ici, c'est d'aider David pour son import en se limitant à
> l'usage aujourd'hui. 

Merci pour le recentrage de la discussion, je suis tout à fait d'accord :-)

> Et pour moi, ça veut dire, (toujours pour son
> changeset sur les heures d'ouverture), on ne touche pas à source=*, et on
> met la source sur le changeset

Je suis d'accord.

> on peut aussi l'ajouter dans source:opening_hours=* mais pas d'obligation.

J'hésite à le faire. Le danger, c'est que si un contributeur corrige les 
opening_hours dans le cas ( peu probable :) ) où ils seraient incorrects alors 
son éditeur ne modifierait/supprimerait probablement pas l'attribut 
source:opening_hours. Sauf si je me trompe sur le comportement des éditeurs 
actuels. Du coup on aurait une source fausse, alors que si on n'utilise pas 
source:opening_hours alors c'est clair, pour trouver la source (et le 
coupable) faut aller voir le changeset.

> Et si un jour, il est décidé que le tag source=* était superflu, il sera
> facile de le supprimer à ce moment-là.

Tout à fait d'accord.

Sur le problème de l'attribut source=* existant mais pas forcément 100% 
correct, j'y vois un parallèle avec les copyrights dans les fichiers sources 
des programmes opensource. Le copyright indique souvent l'auteur d'origine 
(tout comme l'attribut source: d'OSM) même si d'autres ont fait des modifs par 
la suite. C'est un fait connu, et si on veut savoir qui a fait quoi 
exactement, on regarde les commits git, donc l'équivalent des changesets dans 
OSM.

Par contre ce qui me manque dans mon parallèle avec le développement 
opensource, c'est le "approved" sur les merge requests :)
J'ai du mal à savoir si c'est OK pour que je procède, que ce soit ici ou sur 
imports@ où j'ai finalement décrit mon import (et eu très peu de retour, juste 
un "This all sounds very good.", un +1, et quelques questions auquel ma page 
wiki répondait).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On dimanche 15 novembre 2020 13:38:29 CET Éric Gillet wrote:
> Le 15/11/2020 à 12:25, David Faure via Talk-fr a écrit :
> > Je suis d'accord avec toi sur le fond. Mais clairement la communauté OSM
> > n'est pas (encore) de cet avis là.
> 
> Tous les éditeurs ont migré vers les tags de changeset pour indiquer la
> source, "la communauté" est donc à priori de cet avis.

De l'avis de mettre la source dans le changeset, oui.
De l'avis de supprimer la source de l'objet, non.
 
> Si je comprends bien tu es d'accord avec les problèmes que ça engendre,
> que la solution que je propose est la bonne mais ne va pas l'appliquer.

Je suis d'accord que l'attribut source n'aurait jamais dû être mis sur 
l'objet, c'était une erreur de design dès le départ (vision trop court terme).

Mais même si je suis moi-même convaincu, je ne peux pas appliquer une 
*suppression* de données si plusieurs personnes sont contre -- ce qui est 
clairement le cas.

Je ménage mon risque. Quelqu'un qui trouve que mon script n'aurait pas dû 
supprimer un attribut, aura un bon argument pour effectuer ou demander un 
revert. Alors que quelqu'un qui trouve que mon script aurait dû "en faire 
plus", et bien il peut faire ce plus séparément (ou moi, mais en tous cas, pas 
de revert).

> c'est comme si dans tu avais mis dans ton changeset source=A; B

Ça c'est le point avec lequel je ne suis pas d'accord; mon changeset dit 
source=B pour les attributs qu'il modifie. Et par contre la source A 
originelle est celle qui me fournit l'existence du bureau de poste dans OSM, 
son identifiant ref:FR:LaPoste, donc oui je m'appuie bien sur le source A au 
final. Mais c'est pas ambigü, on voit bien ce qui provient de B quand on 
regarde le changeset.

> Désolé de t'avoir fait perdre du temps, je te souhaite bonne
> continuation pour ton import !

Merci :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On dimanche 15 novembre 2020 11:10:10 CET Éric Gillet wrote:
> > Eric, la modification de wiki nécessaire à ceci (celle à laquelle je
> > pensais en fait) c'est la suppression de "it seems the historic practice
> > of tagging objects or individual attributes has not been officially
> > deprecated yet". Le jour où c'est vraiment déprécié, alors pas de
> > problème pour supprimer, mais clairement ce n'est pas l'avis de tout le
> > monde.
> 
> Pas besoin de déprécier dans ton cas, il n'y a pas d'autres solution que
> de l'enlever pour faire une modification avec une source différente.
> 
> Si tu le laisse, on peut pas savoir à quoi s'applique la source qui est
> sur l'objet et celle qui est dans ton script, à moins de lire son code
> source pour voir ce qu'il vérifie/modifie comme attribut (et faut faire
> pareil pour chacune des version des objets OSM).

Je suis d'accord avec toi sur le fond. Mais clairement la communauté OSM n'est 
pas (encore) de cet avis là.

Quand j'ai modifié les horaires d'ouverture d'un magasin avec l'éditeur ID,
et que j'ai mis source=survey pour le changeset, est-ce que ID a supprimé 
l'attribute source du magasin ? J'en doute.

Quand j'ai renseigné les horaires d'ouverture d'un bureau de Poste avec 
l'application StreetComplete (ce qui m'a donné l'idée de ce projet), est-ce 
que StreetComplete a supprimé l'attribut source du bureau de Poste ?
Non, je confirme que ce n'est pas le cas.
https://www.openstreetmap.org/api/0.6/changeset/92125368/download

Dans ce cadre, il me semble pas raisonnable que mon import soit le premier à 
faire ce genre de choses.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On dimanche 15 novembre 2020 00:57:22 CET Jérôme Amagat wrote:
> En modifiant le tag opening_hours=*, seule la source dans
> source:opening_hours=* peut être modifiée ou supprimée.

Sauf qu'on a dit que je ne modifiais pas le tag opening_hours s'il était déjà 
là, donc je ne touche pas non plus à source:opening_hours...

Bon, je constate un manque évident de consensus sur la suppression de 
l'attribut source, et je dois donc me ranger avec le camp plus conservateur.

Surtout que c'est pas vraiment pour faire le ménage que je suis venu :)

Eric, la modification de wiki nécessaire à ceci (celle à laquelle je pensais 
en fait) c'est la suppression de "it seems the historic practice of tagging 
objects or individual attributes has not been officially deprecated yet".
Le jour où c'est vraiment déprécié, alors pas de problème pour supprimer,
mais clairement ce n'est pas l'avis de tout le monde.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On samedi 14 novembre 2020 21:34:52 CET Éric Gillet wrote:
> Le 14/11/2020 à 21:05, David Faure a écrit :
> > On samedi 14 novembre 2020 20:59:13 CET Éric Gillet wrote:
> > Si quelqu'un change le wiki, je fais :-)⎄
> 
> Je l'ai fait en français et anglais :

OK, merci, j'ai remis la suppression de 'source' dans le script.

Je suis quasiment au bout de la TODO list, je pense que je vais pouvoir faire 
l'import demain, à moins qu'il y ait des objections.

Cf https://wiki.openstreetmap.org/wiki/Import/FrenchPostOfficeOpeningHours
pour tous les détails sur ce qui est fait par le script, etc.

Je peux aussi fournir un "diff" du XML d'openstreetmap si qqn veut jeter un 
oeil, mais bon c'est pas facile à vérifier :-)
http://www.davidfaure.fr/2020/osm_post_offices_xml.diff  [8.5 Mo]

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On samedi 14 novembre 2020 20:59:13 CET Éric Gillet wrote:
> Le 13/11/2020 à 22:09, David Faure via Talk-fr a écrit :
> > On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
> >> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
> >>>> Et il faut garder les anciennes sources (sauf les anciennes versions de
> >>>> ce que tu importes).
> >>>> 
> >>>> Typiquement tu auras des source
> >>>> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
> >>>> 
> >>>> Il ne fallait pas supprimer la source du bâti (par exemple).
> >>> 
> >>> Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais
> >>> il
> >>> ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
> >>> disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
> >>> touche pas.
> >> 
> >> Je penses que la phrase du wiki "so don't go around deleting those
> >> source tags"/"ne vous précipitez pas pour supprimer ces balises sources"
> >> c'est pour éviter que des contributeurs suppriment/modifient en masse
> >> "uniquement" un tag.
> > 
> > Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait
> > implémenter ça.
> > 
> > Mais depuis j'ai vu
> > "Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à
> > supprimer ces marques avant qu'une décision générale du projet décide de
> > le faire."
> > https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_le
> > s_objets_et_les_attributs
> > 
> > Et pareil dans la version anglophone, " As usual don't start deleting
> > those tags unless and until there is a general project decision to do so.
> > "> 
> >> [...]
> >> La source précédente (celle existante sur l'objet) n'est pas perdue,
> >> elle est stockée dans l'historique de l'objet. Tout comme le tag
> >> source=* que tu apposes aux changesets.
> > 
> > Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais pas
> > aller supprimer un attribut si le wiki dit "c'est pas encore vraiment
> > décidé au niveau du projet".
> Si tu ne supprimes par le tag existant il y aura donc 2 sources sur les
> horaires :
> 
> - data.gouv.fr:LaPoste - 04/2012 (par exemple)

Cet attribut est sur l'objet lui même, est plus ou moins déprécié et donc 
j'imagine ignoré ? En tous cas s'il ne l'est pas, j'imagine que tout le monde 
comprend ça comme "la source de la création initiale de l'objet, quelques 
détails ont pu changer depuis".

> - datanova.laposte.fr, 2020-11-15

Cette valeur de l'attribut source est sur le changeset, pas sur l'objet.
Le changeset montre clairement qu'il modifie les horaires.

Si quelqu'un change le wiki, je fais :-)⎄

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Numérotation des semaines (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On samedi 14 novembre 2020 13:08:24 CET Frédéric Rodrigo wrote:
> À vérifier, mais je pense qu'il y a un risque que les horaires affichés
> sur place soit une simplification des horaires Datanova. Et que la
> différence ou les exceptions soient simplement gérés par des affichettes.

Je pense aussi, pour des trucs ponctuels (ponts par exemple).
Pour quelque chose qui va être valide toute l'année (semaines paires/impaires)
ce serait étrange d'avoir un papier scotché toute l'année

> Sur le comptage des semaines, attention il y une différence entre les
> semaines anglaises qui commencent le dimanche (et nous le lundi), quand
> l'année commence un dimanche.

Y'a un standard ISO derrière tout ça (ISO-8601), et c'est plus compliqué que 
la différence démarrage lundi / démarrage dimanche : le standard ISO dit "la 
semaine 1 est celle qui contient le premier jeudi du mois" (ou "celle qui 
contient le 4 janvier", c'est équivalent). Je sais que les américains 
utilisent une règle différente pour la numérotation des semaines...

Par contre ça me met le doute sur ce qui est fait en France...

Si https://calendrierfrance.fr/semaines-2021 est correct, la France ne suit 
pas le standard ISO 8601 ?? (Ce site dit que la semaine du 4 au 10 janvier 
2021 s'appellera la semaine 2, et non pas 1 comme dit le standard ISO).
Je me demande si ce site est correct. 
https://fr.wikipedia.org/wiki/Num%C3%A9rotation_ISO_des_semaines
et https://fr.wikipedia.org/wiki/Semaine ne parlent pas d'une autre 
numérotation utilisée en France.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On samedi 14 novembre 2020 11:16:27 CET Yves P.  wrote:
> Ça donnerait (à vérifier aux changements d'années :
> 
> Mo,Th 08:00-11:30,14:00-16:00;
> Tu08:00-11:30,14:00-17:00;
> Fr08:00-11:30,14:00-18:00;
> Su,PH off;
> 
> week 01-53/2 We 08:00-12:00;
> week 02-53/2 Sa 09:00-12:00

Je vois, merci pour la suggestion.

(et le "Su," peut être supprimé, ça par contre c'est fait)
 
> > je suis vraiment curieux de voir le panneau sur la porte de ce bureau :-)
> 
> Mercredi xxx semaine impaire
> Samedi yyy semaine paire

OK, mais cette description devient incorrecte en 2021...
Ils vont devoir changer le panneau pour échanger "paire" et "impaire", si les 
horaires prévus sont corrects...

> Bon, à voir avec l'auteur de la grammaire : Odd and even weeks over a
> year #351 

Merci.

Mais justement je peux comprendre si la grammaire ne prévoit pas quelque chose 
de quasi impossible à écrire sur un panneau ("Ouvert mercredi 8h-12h une 
semaine sur deux à partir du mercredi 3 janvier 2018").  :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Réimport (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

OK, donc pas 1).

Du coup il reste mon 2) (comparer datanova du dernier import et datanova+OSM 
du jour) ou ta suggestion (comparer OSM du dernier import et datanova+OSM du 
jour).

A mon avis les deux marchent, et ma solution me semble plus simple à 
implémenter (probablement juste parce que j'ai déjà la donnée sous la main,
et qu'il n'y a qu'à comparer deux chaînes de caractères).

Tu as une objection par rapport à ma solution "2)" ?

PS: OK je laisse tomber import@, ça me va :)

Merci pour tous les conseils, je pense que j'y suis presque :)

On vendredi 13 novembre 2020 23:36:14 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Ça tu oublies, oui tu sauve à part.
> 
> Tu peux aussi regarder avec overpass les bureaux qui ont changé depuis
> ton import.
> 
> Car overpass te permet d'inspecter l'historique de la base.
> 
> Par exemple si le dernier à avoir modifié l'objet c'est ton robot, tu
> peux foncer.
> 
> Et sinon tu prends l'image juste après ton dernier import : un export
> CSV par exemple daté avec id, opening_hours et dernier modificateur (si
> tu veux vérifier que c'est bien les données du robot afin de ne pas
> tester tout opening_hours).
> 
> Jean-Yvon
> 
> Le 13/11/2020 à 22:32, David Faure via Talk-fr -
> 
> talk-fr@openstreetmap.org a écrit :
> > 1) quand je sauve un opening_hours (sur un objet qui n'en avait pas,
> > donc),
> > je le duplique dans un tag spécifique (datanova:opening_hours ou un truc
> > comme ça) que je sauve aussi dans l'objet. Au moment du réimport je
> > compare les deux champs, et je ne met à jour (les deux) que s'ils sont
> > encore égaux. Sinon c'est que quelqu'un a fait un changement, alors j'y
> > touche plus (et on passe sur la solution du fixme et de la suggestion,
> > auquel cas ça fait quand même trois champs qui parlent d'horaires
> > d'ouverture, au total...).
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr


-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On vendredi 13 novembre 2020 18:51:32 CET Francois Gouget wrote:
> On Thu, 12 Nov 2020, David Faure via Talk-fr wrote:
> [...]
> 
> > 10115A|GUIDEL BP|Mo-We,Fr 09:00-12:00,14:00-17:00; Th
> > 09:00-12:00,14:30-17:00; Sa 09:00-12:00; Su,PH off
> > 
> > Ah tiens à ce propos, pour les cas où il existe des horaires dans OSM, je
> > vois souvent que la seule différence entre OSM et datanova c'est que je
> > génère "Su,PH off" à la fin alors que dans OSM ça n'y est pas. Je sais
> > que ça revient au même,
>
> Pas tout à fait. Le "Su off" est bien redondant mais pas le "PH off",
> même si tous les français se doutent bien que le bureau de poste sera
> fermé les jours fériés.

Ah, oh. Bonne remarque.

Wow, c'est une erreur super courante. "PH " n'apparaît que pour 47 bureaux de 
poste dans OSM (dont 1 venant de mon import de test).

Je le remet alors, mais si OSM et datanova sont d'accord sauf PH off, je vais 
les considérer égaux quand même. 

> Pour ce qui est des mises à jour au fil de l'eau (après l'import
> initial) ; est-ce que le script serait capable de ne faire une mise à
> jour que si les horaires ont changés dans Datanova ?

Yep. Ça peut se faire sur la base de l'import précédent, cf sous-thread 
"Réimport".

> Cela limiterait les cas d'écrasement des modifications des utilisateurs
> sur place : si un utilisateur corrige un horaire, cette correction ne
> serait écrasée que la prochaine fois qu'il y a un changement dans
> Datanova, auquel cas on peut supposer qu'il serait de toute façon
> nécessaire de faire une vérif / mise à jour.

Ah, mais donc ça écraserait (et perdrait) une donnée manuelle; d'autres ne 
sont pas d'accord avec ça. Et je vois un risque en cas d'erreur d'identifiant 
la poste (même si je n'ai pas d'exemple concret où ça arrive).

Au 2e import, j'aurai :
 * ancienne valeur datanova ("old")
 * nouvelle valeur datanova ("new")
 * valeur stockée dans OSM ("osm")

Si osm==new, on ne fait rien. Et sinon :

Tu suggères 
  if (new != old) { osm = new }
alors qu'il me semble que le consensus est
  if (osm == old) { osm = new }
  else { suggested_hours = new + add fixme }

Ça semble moins risqué.

> Le principal cas de faux positif serait si Datanova contient une fermeture
> exceptionelle pour un jour particulier.

Genre "Jan 16: off" ?
D'une part je ne génère pas ça pour l'instant (si c'est un seul jour je 
l'ignore, si c'est plusieurs jours sans récurrence détectable ça va dans la 
case "non résolu, ne pas importer"). Et d'autre part, au max 3 mois plus tard 
l'import suivant supprimerait ça, donc pas de chance que ça impacte l'année 
suivante.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Réimport (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On vendredi 13 novembre 2020 12:20:37 CET Frédéric Rodrigo wrote:
> Perso, je n'aime pas l'idée d'écraser des choses dans OSM.

A la réflexion, je vais adopter cette pensée "conservatrice" parce qu'il 
existe un risque dont on a peu parlé : un mauvais ref:FR:LaPoste sur un bureau 
de poste dans OSM. Par exemple suite à renommage/renumérotation.

On vendredi 13 novembre 2020 09:58:58 CET Brice wrote:
> Idéalement, si ré-import, application des modifications de Datanova
> uniquement ssi pas de changement dans OSM depuis l'import précédent

Oui, c'est ce que je me dis depuis longtemps.

Je vois deux manières de faire ça :

1) quand je sauve un opening_hours (sur un objet qui n'en avait pas, donc),
je le duplique dans un tag spécifique (datanova:opening_hours ou un truc comme 
ça) que je sauve aussi dans l'objet. Au moment du réimport je compare les deux 
champs, et je ne met à jour (les deux) que s'ils sont encore égaux. Sinon 
c'est que quelqu'un a fait un changement, alors j'y touche plus (et on passe 
sur la solution du fixme et de la suggestion, auquel cas ça fait quand même 
trois champs qui parlent d'horaires d'ouverture, au total...).

2) ou alors je sauve le fichier des horaires parsés dans le git de mon code,
après chaque import, et je m'en sers pour comparer les horaires la fois 
suivante. Avantage, ça pollue moins OSM. Inconvénient, ça fait un peu "base de 
données à part". Mais vu que c'est entièrement pour les besoins du script 
d'import, ça me semble logique de faire comme ça.


Pour info, quelques stats :
==
16699 post offices ready for import, 683 post offices with unresolved rules.

Current status of the OSM data: I have 17371 unique post office IDs in the 
datanova data, while the overpass query outputs only 11593 nodes with a 
ref:FR:LaPoste attribute.

Current outcome: after comparing with OSM, I have 9186 opening_hours 
modifications to send.

The rest is 224 agreements, 962 disagreements, 767 not in datanova, 429 not 
ready (parser failed).
==

La très très grande majorité des horaires (9186 sur 11593) seront donc 
maintenus par l'import régulier. On peut même y inclure les 224 où ça colle 
déjà, en cas de mise à jour.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

[OSM-talk-fr] Suppression de l'attribut source (Re: Import des horaires des bureaux de poste)

[David Faure via Talk-fr]

On vendredi 13 novembre 2020 18:23:11 CET Éric Gillet wrote:
> Le 12/11/2020 à 10:02, David Faure via Talk-fr a écrit :
> >> Et il faut garder les anciennes sources (sauf les anciennes versions de
> >> ce que tu importes).
> >> 
> >> Typiquement tu auras des source
> >> source=LaPoste -03/2019 dus aux ref:FR:LaPoste
> >> 
> >> Il ne fallait pas supprimer la source du bâti (par exemple).
> > 
> > Ah, j'avais mal lu le wiki. Source sur un object c'est historique mais il
> > ne faut pas effacer. Je croyais avoir lu le contraire (et aussi Éric
> > disait qu'il fallait effacer, cf mail de mardi). Pas de problème, j'y
> > touche pas.
> 
> Je penses que la phrase du wiki "so don't go around deleting those
> source tags"/"ne vous précipitez pas pour supprimer ces balises sources"
> c'est pour éviter que des contributeurs suppriment/modifient en masse
> "uniquement" un tag.

Ah, en effet, c'est ce que j'avais lu en premier, et qui m'avait fait 
implémenter ça.

Mais depuis j'ai vu
"Comme celui-ci n'est pas officiellement obsolète, ne commencez pas à supprimer 
ces marques avant qu'une décision générale du projet décide de le faire."
https://wiki.openstreetmap.org/wiki/FR:Key:source#Usage_historique_sur_les_objets_et_les_attributs

Et pareil dans la version anglophone, " As usual don't start deleting those 
tags unless and until there is a general project decision to do so. "

> [...]
> La source précédente (celle existante sur l'objet) n'est pas perdue,
> elle est stockée dans l'historique de l'objet. Tout comme le tag
> source=* que tu apposes aux changesets.

Je suis d'accord avec ton raisonnement. Mais je suis nouveau, je vais pas aller
supprimer un attribut si le wiki dit "c'est pas encore vraiment décidé au 
niveau du projet".

> > Bon ben va falloir se mettre d'accord sur ce point là aussi :-)
> > https://wiki.openstreetmap.org/wiki/Key:created_by peut soit dire JOSM
> > vu que j'uploade le changement avec JOSM (mais bon il n'aura pas fait
> > grand chose dans l'histoire), soit j'y mets le nom de mon script comme
> > dans le premier test que j'ai fait,
> > https://www.openstreetmap.org/changeset/93931921
> > 
> > La page wiki sur created_by ne mentionne pas le cas des imports
> 
> L'important est que l'outil et la personne soient identifiables. La
> méthode me paraît secondaire. Mais ce n'est pas l'avis de tous, et
> certains sont très stricts là-dessus. Le mieux à mon avis c'est de
> mettre en place toutes les méthodes possibles d'identification de
> l'import pour espérer ne pas te faire revert. Il y a d'autres
> suggestions sur le wiki :
> https://wiki.openstreetmap.org/wiki/Import/Guidelines

OK. J'avais lu cette page au début, mais je viens de la relire, et là c'est 
bien clair :
Step 6 : You *must* use a dedicated user account.
C'est fait.

Comme ça c'est ceinture et bretelle, je fais compte spécifique et created_by.

> Personne ici n'a à donner d'ordres ;) La seule chose souhaitable c'est
> de chercher un consensus, mais souvent il n'est jamais atteint sur les
> mailing lists (je suppose dû au format et au public).

Chouette :-)
En plus je viens de lire que je dois aussi parler de l'import sur 
impo...@openstreetmap.org,
histoire d'avoir des avis différents de gens qui se parlent pas directement 
entre eux, MDR :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste / vérification terrain

[David Faure via Talk-fr]

On vendredi 13 novembre 2020 20:15:23 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Pour, on peut lever un drapeau fixme = horaires à vérifier, XXX selon la
> Poste.
> 
> Car ça peut être les horaires XXX, pas la peine de laisser la fourmi se
> taper le texte s'il suffit de le vérifier.
> 
> Ou :
> 
> fixme = horaires à vérifier, voir si suggested:opening_hours contient la
> bonne valeur.
> 
> suggested:opening_hours=XXX

Ah, pourquoi pas, ça me plaît.
En plus comme ça Osmose peut facilement afficher la suggestion, sans avoir 
besoin de dupliquer le code complexe de parsing des données datanova.

J'imagine que s'il y a déjà un fixme, je concatène avec un ";" entre les deux.

Cf ci-joint la liste des fixme existants sur des bureaux de poste, par 
curiosité.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





























































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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On mercredi 11 novembre 2020 22:21:50 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Je vois qu'Yves avait compris ce que tu veux dire. Ce que je ne
> comprends pas c'est ce que tu dis initialement : on se fiche des heures
> de collectes par rapports aux horaires d'ouverture de la Poste ou de
> l'agence postale.

Et bien je ne savais pas encore que collection_times pourrait modéliser cette 
donnée,
et il se trouve qu'elle est fournie par datanova, mais elle ne fait pas partie 
du problème
que je cherchais initialement à résoudre : les horaires d'ouverture.
Quoi qu'il en soit c'est noté dans la TODO sur le wiki, pour améliorer les 
choses
après l'import initial.

> Oui avançons déjà sur opening_hours. 

Exactement :-)

> > Au pire il faudra que je fasse "2020 week 2-53/2 Sa [...]" et "2021 week
> > 1-53/2 Sa [...]" en dupliquant la donnée, si y'a pas mieux...
> 
> Oui mais ça n'arrive que pour quelques bureaux et seulement au dernier
> trimestre.

Seulement 46 bureaux, en effet. Mais quand on code, c'est autant de boulot pour 
2 que pour 2 :-)
Enfin bon c'est fait entre temps.
Le cas extrême ça donne ça... je suis vraiment curieux de voir le panneau sur 
la porte de ce bureau :-)

88064A|BEC DE MORTAGNE AP|Mo,Th 08:00-11:30,14:00-16:00; Tu 
08:00-11:30,14:00-17:00; week 01-53/2 We 08:00-12:00; week 02-53/2 We off; 2020 
week 02-53/2 We 08:00-12:00; 2020 week 01-53/2 We off; Fr 
08:00-11:30,14:00-18:00; week 01-53/2 Sa off; week 02-53/2 Sa 09:00-12:00; 2020 
week 02-53/2 Sa off; 2020 week 01-53/2 Sa 09:00-12:00; Su,PH off

> Même si le rythme quinzomadaire arrive ailleurs aussi (par exemple
> poubelles jaunes dans mon agglo). Donc semaine paire certaines années,
> impaires d'autres, ça n'a pas l'air d'avoir été défini dans opening_hours.

Yep, je crois que c'est le consensus.

> > Oui si j'arrive à tout automatiser, l'import pourrait se faire
> > régulièrement. Les données sont pour les 3 prochains mois, mais je ne
> > sais pas si ça garantit ces horaires. C'est peu probable (grêves, arrêts
> > maladie, ...).
> 
> Je pense que les grèves, tu n'auras pas (les grévistes n'ont pas à
> prévenir à l'avance). Les arrêts maladie ? Ça n'a apparaitrait que si le
> bureau n'est tenu que par une personne. Et dans ce cas je crains que
> l'info reste coincée aux niveau des RH. Alors des plages horaires
> réduites pour les bureaux de taille moyenne ? Je ne sais.

Yep. Je me demande juste ce qui amène certains bureaux à avoir des horaires 
aussi tordus,
(si bien sûr les données sont fiables). Par exemple:

WARNING: CERESTE BP: Th has multiple outcomes:
│09:00-12:30 on 2020-11-26 2020-12-17 2021-01-07 2021-01-28
│09:00-12:30,14:00-16:00 on 2020-11-12 2020-11-19 2020-12-03 2020-12-10 
2020-12-24 2020-12-31 2021-01-14 2021-01-21 2021-02-04

Pourquoi donc ce bureau a-t-il prévu de fermer quelques jeudi après-midi mais 
pas les autres ?
Je ne vois pas de logique qui soit modélisable pour opening_hours.
Hmm  c'est peut-être toutes les 3 semaines, en fait, pour celui-là 
J'ai 1197 autres warnings de ce type à analyser, lol.

Je crois que dans certains cas c'est des ponts (autour des jours fériés).
Mais c'est pas toujours la veille d'un jour férié, ça peut être le lendemain etc
donc c'est du cas par cas. Pour l'instant j'importe pas ces cas là, pour cela
il faudra que j'ajoute des exceptions pour des jours donnés. Mais avant d'en 
arriver
là il vaut mieux essayer de détecter un max de récurrences (sinon l'exemple 
ci-dessus
dirait "exceptions Nov 26, Dec 17, Jan 07, Jan 28" au lieu de "w1-53/3" pour 
toutes les 3 semaines).
D'un autre côté, ça revient au même si l'import a lieu tous les mois :-)

> >> Un truc sympa serait d'avoir une carte, par exemple un fond OSM et une
> >> info bulle sur les bureaux avec les horaires actuels, les horaires
> >> déduits et les horaires bruts dont tu pars. Par exemple en important tes
> >> données dans une umap.
> > 
> > Euh. Ça c'est du chinois pour moi (je saurais pas faire), et j'ai du mal à
> > voir l'intérêt. Si c'est pour débugguer, un simple "grep" sur le fichier
> > de
> > départ et le fichier de sortie permet de regarder ça. Si c'est pour
> > l'utilisateur final, le but c'est de voir ça dans OsmAnd et autres :)
> 
> C'est bien pour déboguer mais pour que la communauté vérifie.

Oui OK, ça sert avant le premier import, ou *si* on décide de ne pas
écraser les données existantes, alors c'est le moyen de voir les deux données
(OSM et datanova) et de comparer en allant sur le terrain (ou en détectant
que les deux écritures sont équivalentes).

Sinon il n'y a rien à comparer, une fois l'import fait ;)

> umap.openstreetmap.fr
> Tu importes le fichier que tu as généré (csv, geojson, osm,...). 

Ah, cool, déjà ça confirme que ça touche les DOM-TOM en effet.

> "Gabarit du contenu de la popup".

Wow c'est super lent quand on tape dans ce champ...
[Firefox tourne à 100% CPU pendant très longtemps à chaque appui de touche]

OK c'est prêt :

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On mercredi 11 novembre 2020 21:48:36 CET osm.sanspourr...@spamgourmet.com 
wrote:
> Il est possible que ce fichier soit de grande qualité comme de
> piètre qualité.

OK, on va voir :-)

> Je te propose de jouer pour ref:FR:LaPoste
> 
> 10115A. Pas d'horaires actuellement, là encore il y a eu les horaires
> covid mais je dois avoir une photo des horaires d'avant - et les connais
> à peu près. C'était du style demi-tordu sans doute à cause d'un temps
> partiel modifié.

10115A|GUIDEL BP|Mo-We,Fr 09:00-12:00,14:00-17:00; Th 09:00-12:00,14:30-17:00; 
Sa 09:00-12:00; Su,PH off

Ah tiens à ce propos, pour les cas où il existe des horaires dans OSM, je vois 
souvent
que la seule différence entre OSM et datanova c'est que je génère "Su,PH off" à 
la fin
alors que dans OSM ça n'y est pas. Je sais que ça revient au même, mais est-ce 
qu'il y
a une bonne pratique par rapport à ça ? Je peux le supprimer de ma génération
pour que ça colle plus aux données existantes, si c'est considéré plus lisible.
Ou le laisser si c'est considéré plus explicite.

Je viens de rajouter un coup de https://github.com/rezemika/oh_sanitizer sur 
les deux données
mais la différence reste, apparement oh_sanitizer n'y touche pas.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On mercredi 11 novembre 2020 18:32:53 CET Brice wrote:
> Le 11/11/2020 à 15:57, David Faure via Talk-fr a écrit :
> > Dis moi où tu habites et j'aurai des infos super précises sur les horaires
> > d'ouverture de ton bureau de Poste :)
> 
> OK pour un mini-mini échantillonnage, je vérifierai :
> https://www.openstreetmap.org/node/326243219
> https://www.openstreetmap.org/node/6140793094
> https://www.openstreetmap.org/node/249560489
> mais horaires très simples, on est pas vraiment dans le rural;-)

Voilà ce que sort mon script, sur la base des données datanova :

14181A|PARIS BELLEVILLE BP|Mo-Fr 09:00-19:00; Sa 09:00-13:00; Su,PH off
14266A|PARIS SAMBRE ET MEUSE|Mo-Fr 09:00-20:00; Sa 09:00-13:00; Su,PH off
14298A|PARIS PERNETY PLAISANCE|Mo-Fr 08:30-19:30; Sa 09:00-13:00; Su,PH off

Apparemment c'est donc stable sur les 3 prochains mois, pas de cas particulier.
Ce qui est intéressant c'est que OSM n'a pas les mêmes horaires :

Paris Belleville : Mo-Fr 10:00-16:00
(marqué comme opening_hours:covid19, je ne vois pas de tag opening_hours tout 
court)

Paris Sambre et Meuse : Mo-Fr 09:00-20:00; Sa 09:00-13:00 --> sur celui là on 
est d'accord.

Paris Pernety / Plaisance : Mo-Fr 08:00-20:00; Sa 09:00-13:00  --> différent

Tu as moyen de vérifier les horaires réels ?

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On mercredi 11 novembre 2020 13:31:02 CET Brice wrote:
> > ensuite pour les autre questions :
> (...)
> 
> > - tes données ont beaucoup plus de chance d'être à jour que celles
> > présentes dans osm donc moi je dirais qu'il faut remplacer l'existant
> > qui peut être là depuis des années.
> 
> Pas trop d'accord, il serait dommage de partir d'un à priori qu'un
> organisme central connaisse parfaitement les horaires de toutes ses
> implantations, quand se comptent en milliers : pas sûr du tout.
> Je suis pour ne compléter que les bureaux de poste avec horaires non
> encore renseignés et laisser tels quels les horaires existants pour
> qu'ils soient corrigés, si nécessaire, au fur et à mesure.

Merci pour ton retour, c'est utile qu'on en discute.
Est-ce que tu as regardé les données datanova ?
Je pense qu'elles sont bien plus précises que tu ne le penses, et pour info 
elles sont mises à jour *tous les jours* automatiquement.

Les données datanova nous disent par exemple que le bureau de Poste de 
DENEUILLE LES MINES sera ouvert le mardi de 09:00 à 12:00 
aux dates suivantes :
  2020-11-03 2020-11-10 2020-11-17 2020-11-24
et de 08:15 à 12:15 aux dates suivantes :
  2020-10-27 2020-12-01 2020-12-08 2020-12-15 2020-12-22 2020-12-29 2021-01-05 
2021-01-12 2021-01-19 2021-01-26
... ce qui veut dire qu'il y a un changement temporaire en Novembre.
Quelle est la probabilité que quelqu'un aille noter ce changement temporaire 
dans OSM manuellement ? Et surtout, quelle est la probabilité que cette donnée 
soit fausse, et que les horaires affichés sur la porte soient plus corrects ?

Dans le même style, datanova contient les changements horaires qui auront lieu 
à partir du premier janvier 2021, toujours avec une précision jour par jour.
J'ai aussi détecté bureaux qui sont ouverts un samedi sur deux, ou qui sont 
fermés le dernier samedi de chaque mois. Et d'autres avec des cas encore plus 
tordus de fermetures exceptionnelles ou d'alternance entre deux horaires sans 
récurrence détectable. Tout ça pour dire que c'est super précis.

En cas de désaccord entre le opening_hours existant dans OSM et la donnée 
datanova.laposte.fr, qu'est-ce qui est le plus probable ? Que datanova se 
trompe ou que la donnée OSM ne soit pas à jour ? Au vu de la précision des 
données publiées, je dirais que c'est le second cas, à coup sûr.

Dis moi où tu habites et j'aurai des infos super précises sur les horaires 
d'ouverture de ton bureau de Poste :)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On lundi 9 novembre 2020 19:10:26 CET Jérôme Amagat wrote:
> Ce qu'il est possible de faire, il y a surement d'autre façon de faire,
> mais je n'ai essayé que ça :
> - obtenir les bureaux de poste avec l'overpass api via une requête de ce
> type : https://overpass-turbo.eu/s/ZUw (pour josm il faut du xml et out
> meta)
> -  faire un script qui va lire le xml, détecter les tags ref:FR:LaPoste=*
> et ajouter les opening_hours=* au bon élément, il faut pour que josm sache
> que l'élément a été modifié et qu'il faut envoyer l'élément au serveur,
> ajouter un action='modify' au bon endroit pour chaque élément modifié.
> - une fois modifié, ouvrir avec josm ce fichier enregistré en .osm
> - envoyer les modification

Merci beaucoup pour ces instructions.

Je viens de les utiliser pour soumettre mon premier changeset avec JOSM :
https://www.openstreetmap.org/changeset/93931921
Est-ce que tout semble correct ?
En particulier la suppression de la source de l'objet (déprécié), l'ajout des 
horaires bien sûr, le created_by et la "source" du changeset, et le 
commentaire avec le lien wiki.

Si ça semble bon je vais pouvoir industrialiser :-)

PS: J'ai utilisé https://github.com/mvexel/overpass-api-python-wrapper
et 5 lignes de python pour faire la requête overpass en ligne de commande, 
c'est plus pratique.
Mes scripts sont maintenant en ligne sur 
https://github.com/dfaure/DataNovaImportScripts

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On lundi 9 novembre 2020 21:32:40 CET Frédéric Rodrigo wrote:
> Si le générateur des horaires d'ouvertures est codé en python 

Je connais bien mieux perl que python donc pour l'instant c'est en perl.
Si quelqu'un veut m'aider à convertir en python... :)

> ça serait bien aussi de l'ajouter à Osmose

Pour refaire l'import en temps réel et voir si ça colle ? Ou bien je pige pas 
l'idée ?

C'est peut-être surtout l'autre sens qui serait utile, valider que les 
horaires sont syntaxiquement corrects ? Mais bon ça je compte le faire avant 
import de toutes façons.

> https://github.com/osm-fr/osmose-backend/blob/master/analysers/analyser_merg
> e_poste_FR.py
> http://osmose.openstreetmap.fr/fr/map/#zoom=9=45.215=0.104=705
> 0%2C8020%2C8021%2C8022=1%2C2%2C3==

Wow, merci pour ce lien. Ça m'explique pourquoi j'ai 17371 identifiants 
différents de bureaux de poste dans les données datanova, alors que la requête 
overpass de Jérôme ne me sort que 11503 bureaux avec un attribut 
ref:FR:LaPoste.
osmose montre que de nombreux bureaux n'ont pas cet attribut, et certains ont 
une valeur qui n'existe plus chez laposte (renumérotation ? fermeture ... ?).

Et ben c'est pas simple tout ça :-)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

On lundi 9 novembre 2020 19:42:59 CET Yves P. wrote:
> > Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier,
> > Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
> > ne vont pas dans opening_hours, donc je les considère hors périmètre.
> > C'est déjà assez compliqué comme ça :-)
> 
> On pourrait suffixer collection_times ;)
> 
> On trouve cet exemple dans le wiki :
> collection_times = Mo-Fr 09:00-12:00,17:00; Sa 14:00
> collection_times:local = Mo-Fr 23:00; Su 23:00
>
> Ça donnerait donc quelque chose comme :
> collection_times:parcel = Su-Fr 23:00

OK, noté dans la TODO list :)
C'est OK d'inventer des suffixes non standardisés/documentés comme ça ?
Ou bien c'est une suggestion "à faire standardiser d'abord" ?

> collection_times:chronopost = Su-Fr 18:00
> Parcel est générique et doit se retrouver dans tous les pays.
> chronopost est une marque. Existe-t-il un terme générique anglais pour ce
> type de paquets ?

Ça ne me rappelle rien.

Dans les autres pays les paquets sont livrés, contrairement aux chronoposts, 
bien souvent :-) :-)

> >>> Detect cases like "every other Saturday", which seems to happen.
> 
> Je ne comprend pas cette expression. DeepL me dit "un samedi sur deux".

Oui.

> C'est bien ça ? Ça ne serait pas plutôt premier et 3e samedi du mois ?
> Ou samedi des semaines paires (ou impaires) ?

Non.

> Le langage d'opening_hours permet cela :
> Su[1,3]   # 1er et 3e samedi du mois
> week 01-53/2  # semaines impaires
> week 02-53/2  # semaines paires

Comme je disais, ça fait pas du "1 sur 2" au changement d'année, alors que 
c'est vraiment ça que je vois dans certains bureaux de poste...

D'autres font du Sa[-1], j'ai pas fini de tomber sur des cas tordus :-)

> Il faut peut-être l'ajuster d'une année sur l'autre ?

Oui je vais devoir faire ça du coup...

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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

Re: [OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

Bonjour et merci pour toutes ces réponses !

On dimanche 8 novembre 2020 16:43:36 CET osm.sanspourr...@spamgourmet.com 
wrote:
>  > (ignore everything after 11:45, that's the max time for sending 
> > letters, parcels, etc.)
> Pourquoi ? Si la poste est ouverte, ça peut être utile pour poster un
> colis même s'il part le lendemain, rencontrer un conseiller. 

Disons que ces informations (les colonnes Heure_limite_dépôt_Courrier, 
Heure_limite_dépôt_Chrono, et Heure_limite_dépôt_Colis)
ne vont pas dans opening_hours, donc je les considère hors périmètre.
C'est déjà assez compliqué comme ça :-)

> Ne pas confondre avec collection_times
> https://wiki.openstreetmap.org/wiki/FR:Key:collection_times

Oui, c'est pas ça non plus, je suis d'accord.

>  > Detect cases like "every other Saturday", which seems to happen.
> 
> Adrien et Cie, on a un moyen de modéliser ça proprement dans OSM ?

J'ai trouvé "week 2-53/2" mais ça ne fonctionne pas forcément au changement 
d’année… Fin 2020, la semaine 53 est suivie de la semaine 1, donc deux 
semaines impaires se suivent.
Et justement la Poste de La Boisse (aucune idée de là où ça se trouve)
est ouverte le samedi matin les jours suivants: 2020-12-12, 2020-12-26, 
2021-01-09, 2021-01-23, donc semaines 50, 52, 1, 3.

Au pire il faudra que je fasse "2020 week 2-53/2 Sa [...]" et "2021 week 
1-53/2 Sa [...]" en dupliquant la donnée, si y'a pas mieux...

>  > Decide whether to add specific single-date exceptions to the OSM
> > opening hours or to just ignore them. Do we want this level of detail?
> 
> Il y a deux types d'exceptions : les jours fériés et les jours vraiment
> exceptionnels.

Les jours fériés je gère déjà [tant que le bureau fait la même chose tous les 
jours fériés...].

> Rien contre indiquer les jours vraiment exceptionnels mais il faut alors
> être sûr que la mise à jour soit régulière. Avoir mettons une journée
> dans le passé pourrait faire conclure à des horaires non actuels.

Oui si j'arrive à tout automatiser, l'import pourrait se faire régulièrement.
Les données sont pour les 3 prochains mois, mais je ne sais pas si ça garantit 
ces horaires. C'est peu probable (grêves, arrêts maladie, ...). Du coup d'une 
semaine sur l'autre, les horaires prévisionnels pour "dans 2 semaines" 
pourraient changer. Donc en toute théorie il faudrait importer tous les jours, 
LOL. Mais bon déjà si c'est une fois par mois ça me semble pas mal.

> Un truc sympa serait d'avoir une carte, par exemple un fond OSM et une
> info bulle sur les bureaux avec les horaires actuels, les horaires
> déduits et les horaires bruts dont tu pars. Par exemple en important tes
> données dans une umap.

Euh. Ça c'est du chinois pour moi (je saurais pas faire), et j'ai du mal à 
voir l'intérêt. Si c'est pour débugguer, un simple "grep" sur le fichier de 
départ et le fichier de sortie permet de regarder ça. Si c'est pour 
l'utilisateur final, le but c'est de voir ça dans OsmAnd et autres :)

>  > and new post offices
> 
> Et surtout ceux qui disparaissent (c'est plus fréquent).

Hmm, je veux mettre à jour les horaires, pas supprimer des bureaux de poste,
ça semble dangereux et hors périmètre :-)
Je pense que la création et la suppression seraient plutôt à faire à partir 
d'une autre source de données, la liste des bureaux de poste
https://datanova.laposte.fr/explore/dataset/laposte_poincont2/
Mais ça je laisse volontiers à quelqu'un d'autre...

> Horaires : oui on a le droit d'ajouter/modifier des horaires, on met en
> général un source=La Poste, 2020-11-08 (histoire de savoir d'où ça vient
> et de quand ça date).

Dans le changeset, j'imagine. OK.
Pas de mention de l'outil d'importation, au cas où quelqu'un veuille remonter 
à comment un mauvais import a eu lieu ?

> Mais dans un premier temps détecter les différences c'est déjà un bon
> point pour savoir ce qu'il y a à vérifier.

Je ne suis pas sûr de ce que tu veux dire par là.
Si l'outil détecte une différence entre OSM et datanova, j'imagine que 
datanova est plus fiable, mais c'est pas en comparant 08:00 et 09:00 qu'on 
saura qui a raison. Il faut aller voir les horaires sur la porte, mais la 
France c'est grand et on est confinés :-)

Mais oui pour commencer c'est plus sûr de ne rien écraser.

> Pages éventuellement à compléter par la suite :
> https://wiki.openstreetmap.org/wiki/Import/Catalogue

Ah oui, j'ai vu cette page, mais je ne comprends pas bien la différence entre 
ses sections. Les imports ne sont-ils pas tous "communautaires" ?

> https://wiki.openstreetmap.org/wiki/Contributors#France

Merci pour l'info, c'est noté aussi.

> Pour les imports, on va sans doute te conseiller de faire tes tests avec
> JOSM

OK.

> mais pour la mise à jour régulière il y aura sûrement d'autres
> propositions.

Oui, le wiki dit que ça fait pas les grandes quantités de données...
Peut-être osmsync ferait l'affaire ?

> N. B. : préalable : vérifier avec Osmose par exemple que les bureaux de
> poste sont bien dans OSM : ce serait dommage de vouloir 

[OSM-talk-fr] Import des horaires des bureaux de poste

[David Faure via Talk-fr]

Bonjour à tous,

J'ai le projet d'importer les horaires des bureaux de poste de toute la France, 
depuis les données disponibles sur datanova.laposte.fr.

La page Import/Guidelines indique que je dois en discuter avec la communauté 
alors me voici :-)

Je viens de créer la page 
https://wiki.openstreetmap.org/wiki/Import/FrenchPostOfficeOpeningHours
avec l'état actuel de ce projet.

Vous y trouverez aussi quelques questions, comme celle de garder les valeurs 
actuelles ou de les remplacer, et la stratégie de remise à jour après le 
premier import. Votre avis sera le bienvenu.

Est-ce que vous avez un conseil sur la solution technique à utiliser pour cet 
import ?
Mon script génère les valeurs au format OSM pour l'attribut opening_hours, la 
prochaine étape est d'interfacer avec OSM,
et je vois sur https://wiki.openstreetmap.org/wiki/Import/Software qu'il existe 
beaucoup de solutions...


PS: pour plus de contexte sur moi et l'origine de cette idée, cf.
https://wiki.openstreetmap.org/wiki/User:Dfaure

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5




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