Merci, j'avais lu "Rue *de* Baco".

Merci d'avoir corrigé mes erreurs, je vais vérifier avec Overpass si j'ai fait d'autres erreurs.

Oui, ça m'arrive quelques fois de manquer les champs "contact:*" dans JOSM, mais j'essaye de trouver une meilleure façon de procéder pour limiter les erreurs, notamment les website.

Exact, c'est une erreur de ma part.
Comme il y a pas mal de tags, les contact:* étaient cachés tout en haut dans la liste dans JOSM. Ça explique pourquoi je n'ai modifié à deux reprises, en pensant que la première modification n'était pas passée.
Je vais retirer ces ajouts.
Merci.

Bonjour Cayenne,

J'étais passé devant à pied. Je ne m'y était pas arrêté bien longtemps (puisque je n'ai pas ajouté d'autres informations).
Sans doute qu'il restait un panneau du CCI, et que je n'ai pas vérifié si c'était toujours occupé.
C'est donc une erreur de ma part, et la suppression était donc nécessaire.

Cordialement.

Bonjour Mig0ma,
Concernant le château d'eau (way/119815534) sa position est définie (comme tous les bâtiments) par le cadastre, ce déplacement n'est donc pas valide. J'ai replacé le chateau d'eau pour qu'il soit à nouveau aligné sur le plan du cadastre.
En effet, les images du sol ne sont pas produites à partir des satellites mais des vues aériennes (avions, hélicoptères, drones, etc.) et donc la projection varie suivant l'angle de prise de vue et n'est donc jamais précise au sol.
Je ne peux que conseiller de commencer par des petits groupes de modifications quand on débute sur OpenStreetMap, ça permet de découvrir la complexité de la carte au fur et à mesure.
N'hésitez pas si vous avez de questions ou des remarques.
Cordialement.

Bonjour Cédrick,
Effectivement, les SIRET/SIREN/NAF renseignés disparaissent régulièrement, StreetComplete n'est pas toujours en faute mais c'est vrai que ces informations sont particulièrement compliquées à gérer manuellement (et invérifiables sur place) et régulièrement des anciens codes traînent, mais ça reste plutôt facile à détecter.
Merci d'avoir exposé le problème sur le forum, StreetComplete ne devrait donc plus être en faute dès les prochaines versions !
J'ai repéré ces quelques erreurs sur ce changeset par le "node/10920229115" que tu as modifié de "shop=estate_agent" (version effectivement fautive) en "office=estate_agent" ce qui a effacé tous les autres tags, j'imagine à la sélection par erreur de "lieu différent" dans l'alerte de confirmation.
Ça n'a rien d'irréparable mais sauf à vérifier manuellement dans l'historique des modifications de StreetComplete (avant qu'elles soient envoyées), il n'y a aucune visibilité sur les tags retirés.
StreetComplete est très pratique et efficace pour l'ajout de nouvelles données mais concernant les modifications et suppressions, ça peut devenir assez hasardeux.
Je suis passé d'ailleurs très rapidement à SCEE pour cela (ainsi que pour afficher les images aériennes et créer des calques d'affichage personnalisés), et c'est bien cette version que je trouve excellente !
En tout cas, j'apprécie ces modifications, de plus ça m'a permis de me motiver à faire quelques vérifications sur place (ce que je voulais faire depuis bien un an) !
Maxime.

Bonjour Cédrik,
J'ai fait quelques corrections sur ce changeset après vérification, notamment les commerces qui étaient mal nommés.
En effet, StreetComplete n'affiche pas le champ operator/owner des commerces qui parfois contient le complément du nom du commerce (personne physique, enseigne, etc.)
Je ne peux que recommander d'utiliser SCEE à la place, qui permet d'accéder à l'ensemble des tags pour vérifier les données complètes avant toute modification, et notamment de s'assurer qu'aucune donnée n'est perdue par exemple suite à un changement d'amenity.
Cordialement.

Par exemple Jonzac et Saint-Jean-d'Angély ont chacune une zone commerciale, un centre hospitalier, un collège et un lycée. Ça ne me semble pas non plus entrer dans la définition "disposant de peu d'équipements et dont les habitants se rendent dans les villes voisines pour accéder à ceux-ci.". Ça me semble même un critère objectif pour définir s'il s'agit d'un "village" ou "town".
De plus, il est certain que la quelque vingtaines de communes proches (< 15 km) utilisent principalement ces infrastructures (l'inscription en collège doit même se faire par défaut pour les élèves vivant à proximité), ce qui rentre dans la définition d'OpenStreetMap "Les villes disposent normalement d'une bonne gamme de magasins et d'équipements utilisés par les habitants des villages voisins.".

Si la situation n'a pas changé depuis l'été dernier (ma dernière visite) et que mes souvenirs sont bons, l'accès en voiture est réglementé (badge sans doute délivré seulement aux résidents). L'accès par bus, vélo et piéton n'est pas affecté.
Ça nécessiterait une vérification sur place.

Effectivement, ces modifications semble se rapprocher des définitions de l'INSEE (village, bourg, ville, etc.) en se basant juste sur le nombre d'habitant, plutôt que les définitions de OpenStreetMap.
Si c'est bien le cas (puisque aucune source n'est spécifiée), l'INSEE utilise des "unités urbaines" (divisions par regroupement des habitations) pour définir le type de chaque commune, pas uniquement le nombre d'habitants, ce qui peut donc donner différents types pour un même nombre d'habitants.

Bonjour Kerhun,
Suite à ce changeset, le bâtiment way/1102826139 n'était plus fermé (le premier segment passe par dessus le dernier segment), et donc le node de la boulangerie était en double (j'en ai profité pour l'extraire du way dans un node séparé).
Je l'ai corrigé mais je ne sais pas comment ça a pu arriver, et il faut donc vérifier si les changements récents n'ont pas ce même problème.
Cordialement.

Super pour ta modification !
Dans le cas de Léonidas, il y a aussi l'email des boutiques qui est affiché sur les pages, ça peut être intéressant de les importer dans AllThePlaces.

Par contre, ça serait bien plus facile de vérifier les données si les changeset étaient plus petit (genre 20 modifications max) et regroupés sur une même zone.
Par exemple, partir de la première modification, et rassembler toutes les autres dans un périmètre de 20km.
Ça permettrait aussi de pouvoir revert bien plus facilement en cas d'erreur.

Je n'ai pas fait attention que les horaires étaient plus anciens.
Peut-être ajouter un "fixme" contenant les nouveaux horaires (enfin, ceux de AllThePlaces) ?

D'accord, au temps pour moi, je pensais qu'ils étaient remplacés en même temps que website et phone.
Oui donc mes remarques sur les horaires des autres commerces sont aussi à ignorer alors.

La boutique "node/1939356268" n'a pas les bons horaires, sans doute parce que le magasin est fermé entre 12h et 14h30, ce qui n'est sans doute pas géré par le crawler.

Beaucoup de magasins ont des horaires qui ne sont pas bons (ex.: "node/63983438", "node/66912225", "node/68775022")
Ça correspond surtout au dimanche, souvent ouvert, qui n'est pas récupéré, mais aussi parfois aux autres jours.

Les horaires ne correspondent souvent pas (ex.: "node/62565856" et "node/67156965").
Ça semble surtout concerner le dimanche qui est mal récupéré (ouvert quand fermé, ou mauvais horaires).
Vu la quantité de Carrefour, et le fait que les Carrefour Contact ont souvent des horaires différents le week-end, il faudrait revert le temps que le problème soit corrigé sur AllThePlaces.

Les horaires ne sont pas cohérents, certains contiennent les après-midis (qui sont toujours sur rendez-vous), d'autres juste le matin (sans rendez-vous).
Il faudrait que tous les horaires contiennent le matin et l'après-midi, idéalement séparément avec "|| sur RDV" pour l'après-midi.