bonjour
lorsqu'un commerce ferme, merci de mettre à jour l'objet OSM correspondant en modifiant les tags pour signaler la fermeture. Ca peut se faire par exemple avec shop=vacant ou le préfixe disused: ou was:
Votre approche qui consiste à supprimer le noeud, qui plus est en le remplaçant par un noeud inutile sans aucun attribut, est plutôt une mauvaise pratique. Merci de lire osm.wiki/FR:Bonnes_pratiques#Garder_l'historique à ce sujet

Hello Mateusz
according to the shop=pet definition in the wiki right know I think it is ok to change from my old pet_supply value to the well known 'pet'. I just proceeded with the change right now.

<3

Bonjour,
à la lecture de votre commentaire de modifications vous supprimez d'OSM des chemins qui existent sur le terrain. Il est important de comprendre qu'OSM n'est pas là pour refléter une législation mais avant tout pour décrire le terrain. Si ces chemins existent bel et bien, le souci n'est pas qu'ils soient répertoriés dans OSM mais que leur existence enfreigne la loi. Les supprimer d'OSM ne changera rien à cela, mais constitue une mauvaise pratique. Un peu de lecture ici : osm.wiki/FR:Bonnes_pratiques#Mappez_ce_qui_se_trouve_sur_le_terrain

merci

monsieur,
merci pour ce commentaire
à l'avenir je tacherai de mieux faire :p

Mes photos de l'endroit montrent une plaque de rue "Avenue Raphaël Jerpan" à partir du node node/520410097 en allant vers l'ouest jusqu'à la mer. Je n'ai rien pour confirmer à l'est, ce qui semble aller dans le sens d'un renommage abusif le long de la Poste au moins.

Bonjour Marc
je ne comprends pas ta question : "le changement de nom Rue Desmarais -> Avenue Raphaël Jerpan est-il du au fait que la rue a changé de nom"

Bonjour Zeriss,
pourquoi avez-vous pour les pharmacies de ce changeset créé un objet pour chacune au lieu de conserver les objets existants et de les mettre à jour ?

merci pour votre réponse
vincent

Je ne sais pas. Si tu regardes l'historique de cet objet tu verras que je me suis contenté de modifier la casse du nom, avec les majuscules ad hoc. Pour l'intitulé lui-même il faudrait demander à l'auteur de la v1 de l'objet, un certain... Shohreh ;)

=> changeset/34846388

Bonsoir Antonin,
le sujet commence à dater dans ma mémoire, je ne voudrais pas te raconter n'importe quoi. Sur le moment, il me semble être allé sur le site de la commune et y avoir vu une évocation de "Clerval", comme c'est encore le cas ce soir sur http://www.clerval.fr/pages/clerval/l-histoire/ par exemple. J'ai pensé à une confusion entre nom du village et nom de la commune, trouvant étonnant que le village même change de nom. Qu'une commune (entité administrative) change de nom est quant à lui courant.
Donc j'ai fait cette modif de bonne foi et avec quelques éléments, maigres j'avoue. Si l'usage local, contrairement à la page que je cite, est de parler du _village_ en tant que "Pays de Clerval", alors il n'y a pas de débat, je me suis trompé et il faut rétablir, ce qui a déjà été fait d'ailleurs.

Merci pour ton signalement,
vincent

Merci pour ton retour.
Je comprends les arguments aussi bien pour micro-mapper que pour avoir une emprise globale. De mon côté je préfère investir sur d'autres infos pratiques, notamment les moyens de contact et les horaires. Tout ça doit pouvoir se combiner, en fonction de l'énergie qu'on veut dépenser sur la thématique Commerces....

Pour le doublon Picard, si tu as l'envie de détailler notamment le parking, alors je comprendrais qu'on garde la version "magasin complet". Sinon en l'état la version "magasin sur le bâtiment" me paraît plus lisible pour tout un chacun. Un argument connexe, mais mineur car il ne s'agit que de rendu : sur osm.org le texte Mc Donalds pour le MacDo voisin ne tombe pas sur le bâtiment, mais sur le fond du parking du fait de ta modélisation. D'un point de vue cartographique c'est assez déroutant (litote) et pour associer correctement le nom au bâtiment à des fins d'affichage, ça demande du pré-process et une heuristique, ce qui est regrettable. La consommation des données s'en trouve complexifiée, un peu abusivement de mon point de vue (de cartographe).

Oui bien vu, c'est typiquement ça. Je ne mets à jour mes données maps.me qu'une fois tous les quelques jours, et j'avoue ne pas vérifier quand j'ajoute un commerce si je ne le vois pas dans maps.me... bingo ici :)
corrigé par changeset/85948649

Bonjour,
j'ai finalement pu regarder.

Contrairement à ce que tu dis, le magasin Picard n'a pas été ajouté par tes soins en 2019. Je l'ai ajouté en 2014, il a été édité au fil du temps, puis supprimé/remplacé par tes soins en 2019. Tu es passé d'un schéma de tags largement répandu qui consiste à tagguer un bâtiment (building)=* avec le shop=* du magasin qui l'occupe à un schéma où le shop n'est associé à aucun élément physique, ni building ni landuse. C'est très très discutable. Quand je dis "largement répandu" : Taginfo mentionne 945000 shops sur des ways, et par ailleurs 870000 combinaisons shop & building, dont on peut logiquement penser que l'écrasante majorité concerne des ways et non des nodes, vu que 99% des tags building sont associés à des ways.

En l'espèce le parking reste traversable par des piétons y compris quand le magasin est fermé, donc faire de l'emprise globale celle du magasin, en y associant des horaires d'ouverture fermeture, est aussi largement discutable. Incidemment, si j'ai rétabli les infos sur le polygone du bâtiment, ça n'est pas par réaction à ton schéma, c'est tout simplement parce que je ne l'ai pas vu, alors que j'avais le nez dessus. Ca pose aussi des questions sur le bien fondé de ton schéma en l'état actuel des outils d'édition.

En résumé : ta conversion de schéma n'ajoute à mon sens pas de valeur sur cet exemple. Il y a bien un doublon à l'instant, mais je trouverais profitable qu'on garde une schématisation plus conventionnelle et intuitive pour le cartographe lambda que celle que tu as apportée.

Dispo bien sur pour en discuter et arriver à un consensus.
merci, et désolé pour le message un peu long,
vincent

Oops merci. Je regarde ça dès que j'ai un JOSM sous la main

Ah oui bien vu. Merci pour ta vigilance, ok bien sûr

Bonjour,
attention à ne pas remplacer les populations issues de l'INSEE 2020 par des populations plus anciennes prises sur les node place ou dans l'historique des relations. Dans ce changeset tu as remis de vieux chiffres que j'avais actualisés hier :)

merci
vincent

Bonjour louisblot,
des remarques ont été faites dans de précédents changesets (changeset/78847481 et changeset/78858190), sans prise en compte. Je viens d'annuler les 4 changesets changeset/78978509, changeset/78978537, changeset/78978556 et changeset/78978570 pour leurs similitudes avec les précédents.
Merci de cesser définitivement ce type de contribution. Et changer d'intitulé de compte entre temps ne change rien à la traçabilité.

vincent

Merci pour ces corrections rapides :)

Je vois en passant que tu importes de gros volumes d'adresses d'un seul coup comme par exemple ici : changeset/78259779
Ta source semble être le Cadastre. D'expérience, les adresses du Cadastre, tout en étant un matériau de grande valeur, sont loin d'être parfaites, en précision, en actualité et en complétude. Ca me paraît difficile en important autant d'adresses en si peu de temps de vérifier leur exactitude et corriger ce qui peut l'être. Je t'invite autant que possible à travailler par plus petits lots de données. La raison d'être de l'outil dont je te parlais ce matin est justement de proposer une granularité fine (la voie) pour l'intégration des données, pour mieux "digérer" les données source.
Enfin comme le sujet des adresses est souvent discuté sur la liste française, n'hésite pas à venir participer aux discussions :
https://lists.openstreetmap.org/listinfo/talk-fr

merci et bonne journée,
vincent

Bonjour chabe01
C'est une bonne chose d'ajouter quand tu en as l'occasion le tag ref:FR:FANTOIR sur les relations de voies. Il y a cependant un souci dans le contenu du tag, car tu insères entre les 2e et 3e chiffres le 'code direction' de Fantoir, souvent égal à 0. On a pris dans OSM la convention de renseigner le code Fantoir sur 10 caractères, en omettant ce code direction. La convention fait qu'on s'attend à trouver sur les 5 premières positions du code le code INSEE de la commune. Avec le code direction ajouté, la convention est cassée, et par exemple sur le Val de Marne tous tes ajouts commencent par 94001, ce qui pourrait laisser penser que les voies appartiennent toutes à Ablon-sur-Seine (INSEE 94001)
Est-ce que tu peux éviter d'ajouter ce code à l'avenir ? Je t'invite à lire la page osm.wiki/FR:Key:ref:FR:FANTOIR du wiki pour confirmation.
Par ailleurs, il existe un outil qui peut t'aider pour l'ajout des adresses, à cette page :
http://dev.cadastre.openstreetmap.fr/fantoir/ dont le fonctionnement est décrit ici : osm.wiki/Contribuer_%C3%A0_la_BANO#Interface_de_contr.C3.B4le_et_de_saisie_Fantoir.2FOSM

Bonne journée et à ta disposition pour continuer la discussion,
vincent

Bonjour,
pour une mise en service future d'une portion en sens unique, il est préférable de ne pas l'indiquer en avance sans plus de précisions car rien ne dit que les données ne reflètent pas le terrain.
Soit vous attendez le jour J pour faire la modification (le 2/9), soit vous ajoutez un tag comme opening_date=* pour indiquer que ça n'est pas encore effectif. La première solution reste la plus simple.

merci
vincent