Bonjour,

Merci pour votre retour et votre patience.

Vous avez parfaitement raison sur les deux points :

1. La semaine est bien équivalente. Notre outil écrit les horaires en fusionnant les créneaux qui se chevauchent sur minuit (`Mo 19:00-08:00` couvre le `Tu 00:00-08:00`, etc.). Le résultat décrit les mêmes heures d'ouverture, simplement formaté différemment.

2. La suppression du `PH` est un bug que nous corrigeons. Notre modèle interne ne manipule pas de notion « jours fériés récurrents » on ne gère que des horaires hebdomadaires + des exceptions datées à date précise. Jusqu'ici, republier les horaires écrasait toute règle `PH` qu'un contributeur aurait saisie. Nous allons **préserver la règle `PH`** quand elle est déjà présente sur le node. Je réintègre moi-même le `Su,PH 0:00-24:00` sur ce node pour restaurer l'information.

Dans la même logique, nous allons aussi préserver les autres règles datées posées par un contributeur (horaires d'été, fermetures annuelles…) dès lors que la date de fin est à venir, et nous allons commencer à émettre nos propres exceptions datées (fermeture de Noël, horaires réduits sur une plage, etc.) au format officiel :
```
YYYY MMM D off
YYYY MMM D-D HH:MM-HH:MM
YYYY MMM D-MMM D off
```
concaténées à la règle hebdomadaire via `;`. Au prochain passage, nos règles et celles saisies manuellement par un contributeur coexisteront proprement (les règles passées étant filtrées naturellement).

Encore merci pour le signalement, c'est exactement le type de retour qui nous permet d'améliorer la qualité de nos contributions.

Bonjour,

Oui effectivement, ce n'est pas un comportement normal nos contributions ne devraient pas réécraser ce type de nettoyage manuel. J'ai déployé un correctif de notre côté pour que le paramètre après le `?` ne soit plus remis en place, et c'est pour cette raison que j'ai relancé le traitement suite à votre modification.

Merci encore pour votre intervention : cela nous a justement permis d'identifier un cas où nos contributions posaient problème et d'ajuster notre processus en conséquence.

Bonne journée,

Bonjour,

Merci pour ce retour, vous mettez le doigt sur un vrai point d'amélioration de notre côté.

Sur le renommage `contact:website` → `website` : c'est bien un choix assumé. Nous suivons la recommandation du wiki OSM qui privilégie la clé `website` plutôt que `contact:website`, donc notre système effectue systématiquement ce remplacement lors de nos contributions.
website=*#Usability

En revanche, vous avez identifié un vrai bug : dans ce cas précis, l'adresse web présente sur OSM était plus pertinente (page dédiée à l'agence) que celle que nous avons poussée (page d'accueil générique, telle que renseignée par le client dans sa fiche). Notre système n'aurait pas dû écraser cette valeur plus précise.

Nous allons faire évoluer notre outil pour :
- détecter ce type de cas (URL existante plus spécifique que celle de notre source),
- ne pas écraser la valeur déjà présente sur OSM,
- et signaler au client qu'une adresse plus précise existe sur OSM, afin qu'il puisse mettre à jour sa fiche s'il le souhaite.

Merci encore pour la vigilance, c'est grâce à ces retours qu'on améliore la qualité de nos contributions.

Bonne soirée,

Bonjour,

Je viens de vérifier : le nom officiel au SIRET est bien « BOULANGERIE PATISSERIE » (exploité par France Boulangerie), et « Soucelles » correspond à la localisation. Mais d'après ce que j'ai compris, ni une description d'activité ni une localisation ne font un bon name=*.

Rien de tout cela n'apparaît sur la devanture. En revanche, le logo officiel fourni par le propriétaire indique « K&F Bouedo », ce qui semble être le vrai nom d'usage.

Je fais la modification en ce sens.

Merci pour la remarque !

Hi,

Sorry for the mistake! You're absolutely right.

I've added a check on my side to detect this won't happen again.

Bonjour @zorglubu,

Je me suis permis de repasser sur ta modification pour remettre en contact les adresses. node/12684892601/history/6

Merci beaucoup pour ces explications détaillées et les liens vers les discussions du forum, c'est très instructif.

Je comprends tout à fait le raisonnement derrière la suppression de ces tags, et les arguments sur la maintenabilité sont pertinents.

Cela dit, de notre côté, notre système de contrôle qualité détecte actuellement l'absence de addr:city et addr:postcode comme une anomalie sur les fiches que nous gérons. Je vais donc remettre ces informations sur les POI concernés afin de rester cohérent avec nos règles actuelles.

Si un consensus clair se dégage au sein de la communauté OSM FR pour ne plus renseigner ces tags sur les POI, j'adapterai notre système en conséquence pour ne plus les considérer comme manquants.

Bonne continuation !

Bonjour,

En analysant le changeset en question, j'ai remarqué que les tags addr:city (Hermanville-sur-Mer) et addr:postcode (14880) ont été supprimés plutôt que conservés ou migrés vers le schéma contact:*.

Avec la nouvelle logique suite aux retours du forum (https://forum.openstreetmap.fr/t/digitaleo-suivi-et-retours/42379/15?u=digitaleo), j'aurais fait quasiment la même modification mais en conservant le city et le code postal.

Y a-t-il une raison particulière à cette suppression ? Est-ce qu'en schéma contact:*, il est d'usage de ne pas renseigner addr:city et addr:postcode ? Si c'est le cas, je dois adapter mon code en conséquence.

Merci d'avance pour l'éclairage !

Je me suis permis de relancer et d'ajouter les informations que Digitaleo avait.

Bonjour @Vinber-Pro, je ne comprends pas la raison de la suppression de l'adresse

Bonjour et merci beaucoup pour vos retours .

Sur le lien entre et : solution_visibilite était un prestataire externe qui avait la charge de publier les données de nos points de vente sur OpenStreetMap pour le compte de Digitaleo. Nous avons depuis développé notre propre solution en interne, et c’est donc désormais le compte qui publie directement les modifications de nos clients sur OSM.

Sur notre système : Notre outil est en phase de rodage. On est pleinement conscients que contribuer à OSM implique de respecter les conventions et pratiques de la communauté, et vos retours sont précieux pour nous améliorer concrètement.

Le champ website contenant des liens Instagram : je vais modifier notre système pour que les liens de réseaux sociaux soient envoyés dans les champs contact:* appropriés (contact:instagram, etc.) et non dans website.

Je vais aussi faire un retour sur le forum mais mon compte a été provisoirement restreint

La page est créée : osm.wiki/Organised_Editing/Activities/Digitaleo

Je regarde si, à partir des informations que nous fournit le client, nous pouvons ajouter cette information.

Bonjour, et merci pour le retour !

Vous avez raison concernant le remplacement des tags contact:* par addr:* notre intention n'était pas de supprimer des informations existantes mais bien de compléter la fiche.

Concernant vos questions, notre page profil détaille notre fonctionnement : @Digitaleo

En résumé : Digitaleo est une plateforme SaaS de gestion de présence en ligne. Lorsqu'un commerçant met à jour ses informations (adresse, horaires, téléphone, moyens de paiement…) sur notre plateforme, les modifications sont publiées vers OSM via l'API. Chaque édition correspond à une action utilisateur réelle ce n'est pas un bot autonome.

Il faut que je crée une page dans osm.wiki/Organised_Editing/Activities pour expliquer également nos activités ?

Bonjour,

Merci beaucoup pour ces retours détaillés !

Je vais appliquer les corrections : mise au format international du numéro de téléphone sur le bon attribut, correction du nom pour qu'il ne contienne que le nom de l'établissement, et séparation correcte du numéro et du nom de rue en deux attributs distincts.

Je prends également note du code de conduite pour les modifications automatisées je vais ajouter des commentaires à mes modifications et clarifier mon activité sur mon profil.