Bon apparemment ça vient du tagging du bâtiment voisin avec la mauvaise sélection sur un bord; pourtant j'ai du mal à voir pourquoi "amenity=bank" a été sélectionné, sans doute un quirk de l'éditeur avec un retard de prise en compte d'une sélection sur un autre objet dans la zone d'activité commerciale sur la D948 (car il n'y a aucue banque du coté d'Aiffres au sud dans le cadre indiqué, mais il y en a dans la ZAC Terre de Sport et un DAB dans l'Aire du Poitou-Charentes sur l'A10 à la limite Aiffres-Vouillé entre la station Shell et la cafétéria de l'Arche, j'y suis pourtant allé très récemment mais j'ai pas noté.
Les dernières modifs avant ton message concernait une modif automatique par l'éditeur qui modifiait un tag superflu.

Cela ne vient pas de moi... regarde le point c'est quelqu'un d'autre qui a changé le tag d'un arbre en banque!

Et puis je suis allé voir aussi sur place et franchement hormis la petite extension de bâtiment qui a pris de la place sur le parking tout le reste etait bien mieux tracé et c'était plus facile de remettre les modifs locales. Et j'en ai profité aussi pour mettre la note de modif récente qui manquait sur ce bout de bâtiment.

Tout d'abord il l'a dit après coup. Je ne pouvais pas le savoir avant.

Pour lecommerntaire ci-dessus indiquant que ce serait des remorques, c'est possible mais ça ne semble pas être le cas, ça ressemble plus à des toits, on ne voit pas le tracteur et il n'y a aucue indication qu'il y a une position de toit sans mur. De toute façon ce sont des objets tracés en plus et à part, si ça ne plait pas, c'est facile à retirer de façon très localisée.

Je n'ai rien annulé du tout, mais ce n'était pas visible dans les attrributs mis. J'ai fait beaucoup d'autres choses utiles tout autour pour détailler le terrain, de façon précise et très localisée, mais ce qui était avant n'était pas localisé ni assez précis pour indiquer qu'il y avait une petite extension nouvelle sur un seul bâtiment, le résultat était alors incohérent et de tout façon insuffisant avec le reste. On fait ce qu'(on peut, mais pour indiquer quelquechose de nouveau il faut être plus précautionneux, car on ne peut par regarder non plus tous les changesets de l'historique de tous les objets présents pour y chercher un éventuel commentaire, d'autant que la consultation des historiques prend un temps fou et parfois ne peut même pas s'afficher dans iD si on se retrouve à devoir détailler un changeset qui était encore plus volumineux que celui que j'ai fait, et impossible à détailler sur une zone aussi grande sans y passer des heures (et je ne suis pas un robot).

addr:full n'est pas valide non plus (pas sans la commune et le code postal), au mieux un attribut contact (qui n'indique pas une localisation car ça peut être un bureau de poste n'importe où ailleurs par une distribution spéciale, le CS justement permettant l'acheminement à la demande par un service externalisé chez un prestataire, un siège ou une autre agence locale). L'usage des CS peut d'ailleurs varier selon la nature de la demande (facturation, recouvrement, devis, demande de crédit, demande juridique ou fiscale, infos commerciales/publicité, jeu-concours...)

@trial: il n'y a aucune rue mentionnée dans ce changeset, il n'y a que des noeuds isolés

note: entre décimétrique et décamétrique il y a un facteur 100 en longueur, mais en terme de surface réelle ou nombre de noeuds concernés c'est un facteur 10000 qui permet alors de précisément localiser tout le reste (Corine ne tenait pas compte du tout du bâti et des éléments réels d'infrastructure qui justement permettent le calage fin des routes, voies, clôtures, accès et tout l'équipement et les services autour. Je m'attache particulièrement aux petites routes, et aux contours précis des zones urbaines. pour qu'ensuite on puisse s'occuper de leur contenu, et c'est là qu'on voit vraiment ce qu'il reste à faire en détails fins. Je n'oublie aucune ligne électrique visible même et surtout mineure, mais je n'invente pas les tags qualificatifs ou les connexions souterraines qui nécessitent d'autres données. Et j'évite autant que possible les superpositions de polygones de même nature et superpositions de traits par des partages de noeuds non nécessaires (ce qui n'est plus génant sur des polygones assez petits et facile à charger entièrement et vérifier sans trou facilement cassé sans prévenir dans JOSM). Je n'oublie pas la signalisation visible, les passages piétons, feux, priorités et cédez-le-passage au moins en zone rédidentielle et sur les routes secondaires, visibles aussi par le marquage au sol. Et aucune route ou chemin ne sort de sa bande et respecte au plus près l'axe central marqué. Pour les routes et lignes électriques la précision que je laisse est mieux que décimétrique, les angles de courbure ne dépassent jamais les 15-20 degrés (doit 5 angles pour un virage à 90 degrés et quelques noeuds d'approche convenablement distribués si possibles sur des points bien visibles). Il y a toujours une marge d'appréciation personnelle, j'en conviens sur certains attributs, mais c'est le cas de tout le monde et en aucun cas je ne "tague pour le rendu". Et quand je me balade dans le coin et vois des différences avec la carto, je prends une photo sur mon portable ou une note pour une modif à faire chez moi un peu plus tard. Si j'ai le temps en cas d'ambiguïté, je profite de la sortie suivante. ou j'ajoute une note "fixme". mais je n'organisse pas un "survey" complet et systématique, surtout dans des zones inaccessibles au public ou à la circulation ou présentant un risque (donc aucune sortie en campagne de nuit le long d'une petite route)

Dcon en fin de compte je ne vois pas ce que tu me reprocherais ici, et qui s'applique plutôt à ce que tu n'as pas fait toi-même. Je sais, on ne peut pas tout faire en une fois, mais la méthode du "grignotage" est plus fructueuse et plus stable pour les modifs à long terme où elles seront plus locales et plus facilement contrôlables. Il faut dégommer les vieux polygones Corine comme ça, ils polluent la carte et compliquent la maintenance puisqu'il ne s'appuient sur rien de concret et visible à l'échelle décimétrique où on doit travailler maintenant (alors que Corine était 100 fois moins précise, décamétrique, parfois pire).

Bote bien ici également les statistiques rapportées dans les métadonnées sur le nombre de problèmes résolus. Il n'y en a pas du tout dans ton ancien changeset. Donc contrairement à toi, j'ai tenu compte de nombreuses de demandes modifs signalées par le validateur d'iD, alors que tu n'en as pas tenu compte dans JOSM ou tu n'as pas utilisé son validateur.

Bref si tu vois une de mes modifs un peu plus "étendue", c'est la plupart du temps parce que j'ai commencéà à redécouper un vieux polygone Corine géant (que je ne prend pas le temps de corriger ou refermer complèetment, sachant qu'il va être entièrement retracé et découpé plus finement: c'est ce que tu vois dans les changesets suivants; mais à chaque fois je suis la notification rouge affichée dans iD invitant à sauvegarder au plus vite et ne pas continuer trop longtemps: je termine complètemetn des détails fins et le reste du vieux polygnoe est marqué avec un "fixme=incomplet" comme il se doit, pour ne pas l'oublier dans les demandes de corrections et travaux à continuer ou terminer (ce que le validateur ne manque pas de signaler pour tous les modificateurs suivants et pas que moi)

Et note que ton changeset précédent 134655762 est beaucoup plus étendu que celui-ci et encore moins précis, avec des modifs encore moins locales qu'ici, portant sur au moins 4 fois plus de relations, 2 fois plus plus de chemins, et 2 fois plus de noeuds!

Note que même si je ne vais pas trop souvent, cette zone est accessible de chez moi même à pied en une trentaine de minutes. J'ai beau regarder je ne vois pas ce qui cloche dans ce changeset qui a réduit la taille des zones et les a mieux délimitées. Et en passant à côté, je ne vois rien d'anormal. Tu parles de quoi? du cheminement dans le parking? D'un bâtiment modifié (apparemment pas de façon significative sauf si on prend le détail d'une image aérienne et si on se fie aussi à ce qui est tracé dans le cadastre, souvent sommairement et avec des tas de vieilleries et disproportions, voire des aorientations complètement fausses du bâti)? Concernant les voies non privées elles sont totalement en accord avec le terrain (sans tenir compte des travaux ou incidents temporaires qui peuent survenir n'importe où et ne sont dans aucun source: si on tient compte de tels incidents dans un tracé il doit être daté, marqué comme estimatif et à revoir plus tard). Mais sans date ou juste avec la mention du nom d'une ou plusieurs sources (pas toujours synchronisées entre elles), on n'a aucun moyen de décider autre que ce fier à ce qu'on voit réellement. Il y a des attributs pour les travaux commencés et dont le résultat est estimé avec une moins grande précision, et je les utilise quand j'en trouve (dans ce cas je ne rentre pas profondément dans les détails internes de ces zones). Donc je ne vois pas trop ce que tu voudrais "reverter", alors que j'ai rendu justement les modifications ultérieures plus aisées avec des objets plus petits et plus locaux (ce que tu voulais justement en demandant à ce que je fasse des modifs plus locales, mais comment le faire quand il faut redécouper des polygones trop grands et trop approximatifs utilisant des traits de découpe arbitraires qui ne correspondent à rien, et qn'il faut éliminer justement des anciens imports Corine?). ces redécoupages fins permettent justement de progresser (mais comme jsutement je ne peux pas aller trop loin dans les modifs, il peut rester des fragments de veux gros polygones en cours de réassemblage et que je "grignote" par petit bout et de façon cohérente pour ne pas laisser trop de "gruyère": ce qui manque encore dans les changesets suivants est très facilement repérable, mais impossible de les faire entièrement sans avoir un changeset énorme.

Note que ce changeset est assez dépouillé, et pas si gros que ça. Je travaille pouer justerment découper des objets trop gros (notamment les immenses zones agricoles tracées à la va-vite, et améliorer la précision "presque" au niveau des parcelles (en fait uniquement les limites visibles, sans tenir compte des remembrements invisibles), et seulemetn avant de valider je fait un passage rapide des erreurs relevées par l'éditeur pour les attributs manquants ou obsolètes dans la zone (parfois ça peut déborder en apparence, si ça touche par exemple une ligne électrique bien plus longue que la parcelle, mais où j'ai pu réaligner un poteau ou en ajouter un manquant); 84 chemins dans ce changeset (en comptant les redécoupages faits) c'est très peu, avec une seule relation modifiée pour un parking.

@ivanbranco je vois la raison: il y avait un doublon de noeud sur le même nom mais avec des valeurs différentes de place=*; en les fusionnant en un seul (ce sont bien des lieux aujourd'hui habités sur une partie d'un ancien lieu-dit dont il reste encore quelques champs non construits et encore exploités pour l'agriculture, les parties habités sont des parcelles plus petites. Devenus habités, ces ancienb lieux-dits (locality) ont aussi donné leur nom aux petites routes communales d'accès. On trouve les panonceuax blancs indicateurs de ces lieux-dits habités (neighbourhod en zone classée "urbaine", sinon "isolated_dwelling" pour une habitation isolée ou une ferme (famryard), voire "hamlet" s'il y a des propriétés différentes ou plusieurs adresses associées à des locataires distincts ou plusieurs autres usages hors habitation comme des locaux techniques à caractère agricole ou de stockage)

@ivanbranco I do not see ain the OSM database any duplicate places or duplicate names on the two nodes you signal, which are also correctly placed. You're probably using another *non-OSM** database which may place them within a small distance. So I do not see what you mean there.
I have local knowledge of this area (whre I was walking again this afternoon)

@romeodelta: il y a une claire distinction entre les rangées d'arbres qui ne sont pas des haies. Ces rangés d'arbes peuvent en plus avoir une cloture ou des barrières en travers de chamins, ou simplement pousser sur un talus surélevé en bordure de route, et qui constituent aussi une barrière (avec aussi un fossé ou ruisseau mineur qui n'est peut-être pas représenté, cas courant le long des petites routes rurales de ce coin, où les rives sont très peu larges et où on ne se croise pas facilement en véhicule si l'accottement ne suffit pas, il faut que l'un recule pour trouver un créneau stable comme une entrée de champ.
Les arbes parfois poussent au dessus des haies naturelles, masi c'est rare, ce sont plutôt des ronces, les clotures en barbelé ou bois mort sont souvent non entretenues, mais le talus est bien là, les arbres et champs ne sont pour la plupart pas au niveau des routes qui sont un peu plus basses et bordées de fossés drainants; ces petites routes ont souvent des accotements plein d'ornières, et boueux en hiver, avec aussi des nids de poule, même les chemins communaux ou intercommunaux, sauf près des habitations.

This is not a "collection" of unrelated items but the way it is really and exactly composed.
Why are you editing throughout Europe, without any contact with anyone in France or comments in French?
Technically, the municapalities that are part of each postal area are also part of the address (the name of the zone is that of its central post office, but is no longer needed on postal addresses in France: the last addresss line just gives the postal code, and the municipality, which may be a local submunicipality at level 9 instead of level 8 in some cases of municipalities that are "softly merged" in associations with a single council, but still separate territories represented in that council)
It also happens that in some of the most populated cities, there may be several postal areas with distinct codes: they exist because there are multiple central post offices. A central post office can then be composed of full municipalities, or submunicipalites with known boundaries (the same as administrative ones at level 8 or 9).
So these subareas are effectively relevant in France postal addresses. Do not mix that with your assumption as you've seen them in Germany, where you live.

Because the given value is country specific, bound to its law and has NO equivalent in any othjer country, even if the other country names these types the same way (they don't work the same way, and not necessarily at the same level.
There are many other examples existing already. "admin_type" values are NOT worldwide unifiable, unlike "admin_level" that are OSM-specific and have NO meaning by themselves in any country (admin level is purely an invention in OSM for OSM, which frequently mixes different statuses at the same level, even within the same country, you can find examples just nearby, within Burkina Faso, with the local statuses of its departments as "communes" with different statuses but all at the same "admin_level"; the same occurs in many countries, and in fact in most of them: the hierarchival model of "admin_level" is a OSM simplification for another reality. See other examples in US, Britain, France, Spain, Russia; Germany...: that's where "admin_level" is insufficient and we need country-specific statuses; in same cases there are competing status in areas claimed by several countries or administered jointly; administrative status are complex and have lot of exceptions to the simplified model of hierarchical levels). Adding the country suffix explicitly prohibits unifiying statuses defined only by the relevant country, sometimes even outside of its defined border, so that you can't even use a geometric request to locate all those entities (the same would apply to the country-specific tag set in relations, like it would apply to their member ways.
You'll also find "border_type" used as well but not necessarily for administrative areas (however border_type" is more weakly defined because of this and I've not seen any area in OSM where it as used consistantly; but they persist for legacy reasons as they are used by some applications; but they are much harder to fix without understanding their actual usage in third party apps; however a few usages have been documented in the wiki even if I don't know precisely if they are maintained the same way between those created these documentations and those that added them or attempted to maintain them in OSM data); you can find however a few old interesting talks in the mailing list archives; but for the purpose administrative boundaries, I think that "border_type" is deprecated since long, "admin_type" replaced them, preferably with a relevant country code suffix to avoid artefacts along international borders and to efficently facilitate their use in data queries). Using tsuch suffic is very common for country-specific tags (such as classification of schools, other public services or utilities, or maintenance of external references: there are many tags using a country code suffix appropriately to avoid collisions between concurrent interpretations)

and what they are used for: they indicate explictly that the way is used by "some" relations (without saying how may or where) so it indicates that we should look at these relations containing the way to interpret it. It also explicitly indicates that this way should not be removed (or joined) only because it is part of a river way, because it would break the other relations not defining the river itself.
Theoretically we could even drop all attributes from these ways, but experience shows that ways are not always loaded with all relations using them, and not marrking these ways causes relations to be frequently broken by removed/splitted ways or joining that did not have the same attributes. There are a few other purely linear attributes that are also local to each way (e.g. speed limits, width, or attributes marking what is along these ways, i.e. describing the borders of the river or highways, such as lanes, kerbs, retaining walls, fences... and that are not described in the relations themselves because they don't apply to all ways that are members of the relation). So there are tags as well on ways, but for different purposes. We have to play also with compatiblity of renderers or to database queries (it's mor difficult to query the database on objects as it requires querying whar are other objects referencing the described object). A few extra tags on ways do not hurt: they are descriptive, their interpretation still depends on what is effectiely described in the relations using them. But it let "others" be awre of what kind of objects these ways are part of.