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