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 20000 :-) 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 : http://umap.openstreetmap.fr/fr/map/horaires-bureaux-de-poste_522248 > > 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... > > On a déjà ça (Fred confirmera). Effectivement j'ai vu https://wiki.openstreetmap.org/wiki/France/data.gouv.fr/Import_des_points_de_contact_postaux entre temps. > >> 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 forcément certains mettent sur l'objet das le cas d'imports. Mais je ne crée pas l'objet, je change juste son opening_hours. > 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. > > Pas de mention de l'outil d'importation, au cas où quelqu'un veuille > > remonter à comment un mauvais import a eu lieu ? > > Non 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.... > car pour utiliser un robot tu dois créer un compte spécifique. > Par exemple DavidFaure_bot. Ah, c'est vrai que j'avais lu de créer un autre compte et que j'ai oublié de le faire. Mais je vois la réponse de Jérôme, je vous laisse vous mettre d'accord, et j'obéirai :-) > >> 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" ? > > La plupart, tu peux aussi avoir des personnes payées pour (qui doivent > aussi avoir l'accord de la communauté). OK mais ça me laisse confus par rapport à la question de "dans quelle section de Import/Catalogue je dois ajouter mon import". Je vois trois sections qui pourraient coller... Community : oui. One time : oui pour l'instant. Ongoing, fully scripted : oui c'est l'idée. (Enfin 99% scripté, faut quand même passer par JOSM pour uploader, malheureusement...) > >> N. B. : préalable : vérifier avec Osmose par exemple que les bureaux de > >> poste sont bien dans OSM : ce serait dommage de vouloir mettre à jour > >> des horaires de bureaux inconnus. En fait je ne vois pas comment ça peut arriver. Le processus (comme conseillé par Jérôme) c'est une requête overpass pour les bureaux avec une ref, je trouve la ref dans les données datanova, je modifie opening_hours, je pousse via OSM. A aucun moment ceci ne peut amener à "vouloir mettre à jour des horaires de bureaux inconnus". Si un bureau est dans datanova et pas dans OSM, il ne sera jamais regardé puisque l'itération se fait sur les bureaux OSM. Et si un bureau est dans OSM et n'est pas dans datanova, ou bien a des horaires non résolus (comme CERESTE ci-dessus), alors j'y touche pas. Et pour l'instant si un bureau est dans les deux et a des horaires dans OSM, j'y touche pas non plus. Malgré tout ça, j'ai déjà 9179 objets modifiés à envoyés, ça vaut le 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
