En plus ctout ce que tu as fait quelques cjours avant c'était le changeset/90539071 où:
- rien du tout n'indique que tu as fait une visite sur le terrain (commetnaire: modifcation de chemins), et on ne voit que le fait que tu as utilisé deux orthophotos, exactement les mêmes que moi ! Tu as donc fait une interprétation différente des deux, et pourtant ce qui reste après c'est bien la BDOrtho et pas du tout Maxar (donc là tu te plantes dans tes explications).
Il n'y a eu aucun changement de tag, au final uniquement quelques détails de géométrie et je ne vois strictement aucune erreur dans la géométrie que j'ai mise sur le dit chemin.

Non je n'ai pas dit ça. Et le seul ton désagréable a été le tien justement, dès la première intervention, avec un ton très impératif et professoral pour me dire de ne pas faire une chose ou faire autrement sans donner de solution applicable, comme si j'avais fait une prétendue erreur (pire volontairement) pour quelque chose dont je ne suis absolument pas responsable puisque c'est ici toi qui n'a pas fait le travail approprié pour mentionner ta "source" (pas une seule note). Il faut bien voir aussi que les commentaires de changeset ne sont jamais visibles à l'édition: les objects sont trop nombreux, et même en les interrogeant un par un on a une série de changeset: ces commetnaires ne sont pas faits pour qualifier un objet individuel.
Alors quand tu me dit de "faire attention", j'ai fait attention justement; tu me demandes de regarder les images récentes mais en même temps tu admets avec un "souvent" (non démontré) que Maxar n'est pas plus pertient qu'une autre et que de toute façon Maxar n'est pas pmieux daté que BDortho, et pire qu'il est mal orthorectifié (déformations) et bien plus mal aligné (j'ajouterais aussi sa résolutuion faible, ses aberrations chromatiques qui ne permet pas bien de discerner des objets différents, ses aberrations de contraste (saturation excessive, qui produisent des artefacts et des effets de moirés avec des objets fantômes qui n'existent même pas et d'autres qui sont complètement effacés par la saturation)..
Donc tu nies les efforts que j'ai fait pour produire le mieuyx possible, et tu affirmes que je n'ai pas comparé les sources, alors que pour modifier quelque chose c'est la pratiquement la seule chose que je fait.
Tu ne donnes pas de manières objectives de faire, ordonner sans solution, et adopter un ton professoral, comme si je ne connaissais pas et n'appliquais pas déjà ces règles, c'est assez désobligeant, comme si forcément ce que tu fais était toujours impeccable et définitif (ce qui n'est pas le cas car toi aussi tu es limité par les sources et tu fais au mieux).
En plus je ne vois pas du tout ce que tu as annulé et aurait constitué une prétendue "erreur" de ma part. Ce qui fait que ton commentaire est non seulement agressif dès le départ, mais en plus totalement improductif donc inutile: tu as perdu du temps et j'ai perdu le mien, aucun progrès possible donc.
Et c'est franchement nier la masse de travail que je fais et que tu gommes sur un seul petit objet; si tu commences comme ça, je vais m'amuser alors à regarder et te signaler toutes les "erreurs" passées alros qu'entre temps les sources ont changé, se sont amélmiorées, se sont diversifiées. Et je vais en trouver beaucoup. On fait chacun de son mieux au moment uniquement avec ce qui est disponibles au moment des modifs: OSM est une carte actuelle, donc évolutive, pas une carte historique.

C'est bien de le mentionner maintenant mais RIEN ne l'indiquait (et même si c'est le cas, ne pas le dater ne permet pas de savoir quoi comparer).
Et comme tu le dis Maxar a de gros décalages (et aussi des déformations, c'est difficile de l'utiliser pour tracer quoi que ce soit avec, au plus ça donne une idée "relative" pour savoir ce qui existe ou pas et une idée générale de la taille ou l'orientation; de plus la résolution est souvent inférieure ce qui ne permet pas des discriminations faciles);
De fait je ne sais pas du tout ce que tu as "réverté" non plus puisque ce n'est pas non plus décrit dans ton commentaire. Bref n'importe qui pourrait affirmer la même chose que toi, ce n'est que ton point de vue personnel et tu pourrais aussi bien indiquer ce que tu veux.
Je ne dis pas que ce que tu fais est faux, mais pas assez qualifié avec un critère objectif vérifiable. Donc en continuant ainsi tu pourras "reprocher" n'importe quoi à n'importe qui qui pourtant a fait un travail honnète sur des sources vérifiables (celles qui sont visibles et pas scelles que tu penses avoir mais ne fournit pas)

Moi je peux comparer en plein d'endroits je trouve l'inverse, mais il n'y a strictement aucun moyen de savoir quand la source a été mise à jour, car la date affichée n'est que la date globale et pas la date de chaque cliché: les orthophoto proposées sont presque toutes des assemblages de photos réalisées sur des périodes différentes, puisqu'aucun plan de vol ne peut couvrir le monde entier. Au mieux ça peut porter sur quelques kilomètres carrés, et la BDOrtho proposée ici est en fait pas directement la BDOrtho mais comprend aussi des mises à jour depuis les plans de vol de Rennes Métropole ici: il y en a bien plus souvent que ceux qu plan national BDOrtho, et Maxar Premium en a encore moins souvent; il peut donc arriver (et il arrive très souvent) que l'un soit donc plus en avance que l'autre localement, ou l'inverse; ce n'est pas disponible sinon on verrait les bordures et la géométrie (orthomodifiée) de chaque cliché, et on aurait une série de dates et pas une couche unique.
De plus tu as commenté une modif bien après que je l'ai faite, et je ne vois pas de différence du tout entre ce que tu as remix/annulé et BDOrtho alors que justement c'est Maxar qui ne colle pas sur ce chemin.
Enfin les sources ortho ne sont pas disponibles en permanence (les serveurs ne répondent pas toujours bien, il y a un fallback de l'un sur l'autre au sein de la config d'imagerie pour éviter d'avoir des tuiles "grises", et en plus cela dépend des niveaux de zoom...

c'est le problème: il n'y a AUCUN moyen fiable de dater les clichés sur les sources d'image: si une route ou un chemin est supprimé, le supprimer d'OSM ne sert à rien, tu imposes un travail inutile aux autres. Il vaut mieux le garder avec un attribut de cycle de vie, et mettre une note datée décrivant la source incorrecte et celle correcte.
Bref ton message est inutile, comme ta suppression totale du chemin et n'aide personne, même pas toi-même si tu te vois obligé de "supprimer" à nouveau, rend-toi compte que tu pouvais faire autrement et t'éviter cette peine.

Deux "contributions" et deux abus !

Merci de ne pas mettre n'importe quoi dans OSM, c en'est pas un terrain de jeu ou de promo d'idées personnelles (surtout quand elles sont insultantes ou illégales) !

Deux "contributions" et deux abus !

Merci de ne pas mettre n'importe quoi dans OSM, c en'est pas un terrain de jeu ou de promo d'idées personnelles (surtout quand elles sont insultantes ou illégales) !

Don't be abused by the name "Rio", it does not necessarily mean it is a "river".
What is seen is ia an areas largely modeled by the sea, even if there are large flow of non-saline water from the multiple river mouths, and lot of sediments deposited below the saline water (the non-saline water flows on the surface, and given its area, it will slow down in speed and its sediments will more easily disperse and fall down into the saline waters). But note that tide of saline waters will agitate the non-saline waters floating on the surface. This is significant enough that even if the tidal saline movements are small this is no longer the normal movement of the non-saline waters, that no longer flow down. For me the coastline stops to the north border of the Reserva de Biosphera Delta Del Parana, around Isla Martin Garcia (with its small airport) and Isla Lucia, and even a bit further to the north, midway between Nueva Palmia and El Faro: Isla Juncal is a martime island, as weel as Isla Juncalito, but not Isla Montequitti which is a fluvial island termianed to the east by the coastline tip.
What we see here is like a fjord, or aber. If we consider this is an aber, then the sea goes even more to the north near Fray Bentos.
There are several criterias, but looking at the deposited sediments is a bad one (because then all rivers of the world would go far too deep into the ocean/sea). In fact the area of deposit is the indication that this is already the sea. as this is caused by the dispersion of dusts inside the floatting non-saline waters on the sirface by the agitation caused by tide.

Anyway postal adresses are not necessarily geographic (see also the recuring debates with "addr:*=*" fields, also not all geographic; and then non-geographic postal addresses better fit in "contact:*=*" fields)

@cquest, you reiterate what I said and summarized "In summary, what applies to printed postal addresses does not apply in OSM"

Ys for Wikipedia, they were wrong, but the debates there were highly biased a few influencers with too much power, insisting only because this convention was used in some specific databases or applications that would otherwise not treat addresses correctly (even if printed postal addreses never contain any hyphen, even after "Saint(e)" where they should be replaced by spaces, and capitalized without accent, a preconisation in fact abandonned for printed addresses using clear fonts with decent sizes and no decorative features, but still recommanded for handwritten addresses or when manually filling paper forms with a pen with irregular letter shapes that could be incorrectly read)

Oh thanks, I effectively meant "ther'es never been any hyphen (not "space") between the leading article and the rest, or between the generic and the specific name".
As well there's never any space (in French), between the elision apostrophe (l', d', s', n') and the following word, but that apostrophe may be replaced by a space on printed postal addresses, not in OSM. This is not true for other languages (e.g. in Italian regional languages) where the space is most often kept after the elision apostrophe, which occurs much more often and more irregularly, ort when the apostrohpe is in fact a placeholder for a glottal or epigolttal consonant or click absent from the Basic Latin alphabet (e.g. in Latinized Semitic, Polynesian or African languages), when the prefered letter exists in Unicode but is rarely used (in some languages, a digraph like "kh" or "qh" or "'gh", or just the letter "q" or "h" may be used to represent that missing letter even if this is not pronounced exactly like the normal Latin letter or the prefered letter is mssing in the usable alphabet of the sender, like the "barred h" prefered in Maltese)

In summary, what applies to printed postal addresses does not apply in OSM. We don't need these transforms for default "name=*"; we may jsut need "short-name=*" if possible abbreviations are not common and basic truncation of long words (without predefined abbreviations) could break the interpretation and could become ambiguous.

in a language read easily by the French poste; this last line with the country name has no use when delivered later in that country so it does not change the total limit of 5 lines for the rest of the printed address.

Note also that you are not required to write the country name on a fina line if this name is a "city-state" whose name is usually alreayd written at end of their local address: "MONACO", "SINGAPORE", "VATICANO"; provided it is written in Latin and capitalized when posting from France (if you ant to write Singapore in Chinese, then repeat it in Latin on an additional line).
Monaco also uses a French postal code. No need to add also the "MC-" prefix to this postal code.
The list lien with the country name should be in a language rea

@trial: I meant this in the street name.
You speak about municipality and the hyphenation of municipality is no longer a requirement for "communes nouvelles" (it remains for communes déléguées).
As I said, in **printed postal addresses** you may (and even should) replace all hyphens and aopstrophes by spaces. This transform does not apply here in OSM as we are not printing addresses on enveloppes and don't abbreviate them like on envelopes.
I've not said that hyphenation is systematic in "Le-Mans" still written "Le Mans" with a space in OSM and on printed addresses where it is also capitalized after the postal code ("LE MANS"), or in "L-Isle-Adam", still written formally "L'Isle-Adam" in OSM, but written "L ISLE ADAM" in printed postal addresses (capitalized and replacing the apostrophe with a pspace only after the postal code).
For other parts of the printed postal addres (street names), the capitalization is not required (just suggested), but the replacement of all punctuation signs (including ".", apostrophe, hyphen) by spaces is preferable (as well abbreviations may be necessary to fit the length limit of these addresses or if there's the need to add precisions (building/room/door/level numbers, that don't fit on the limit of 5 lines);: for this, La Poste indicates abbreviations that should be used. If names are still too long they may be abbreviated further at end (e.g. "Route de la Chapelle-des-Fougeretz" may be printed on enveloppes as "RTE DE LA CHAPELLE DES FTZ" without any dot or hyphen.

Printed postal addresses are special, and FANTOIR contains some additional fields capitalized that exhibit the suggested non-ambiguous and capitalized abbreviations of street names (also without accents or cedilla). We don't want these altered names in OSM (except possibly in "short_name", but this is not needed if all what is abbreviated is the generic, like "RTE" instead of "Route" or "BD" instead of "Boulevard", as these abbreviations are predefined in a wellknown dataset, fully documented.
Other common abbreviations for postal addresses (outside street names or city names) include "BAT" for "Bâtiment", "ESC" for "Escalier", "PTE" for "Porte", "ETG" for "étage", "RDC" for "Rez-de-Chaussée". They are useful to fit more info on limited lines of addresses.

But the last line with the postal code must remain below the limit so the municimality name may be abbreviated in addition to being capitzlized and written without accents/punctuations

(it may be followed by an additional line for the country name when posting from another country, capitalized "FRANCE", as the convention of prefixing the French postal code by "FR-" is not universal in other countries, even if it could avoid an additional line; for example in it not understood when posting from outside Europe, notably countries where the Latin script is not well understood: using "FRANCE" in capital only makes this clear for the local postal services)
As well when writing from France to these countries, we should write their countries in plain text (we an name therse countries in French, this is meant for the French postal service; the rest of the address above can be written using the script used at the target address, in Cyrillic, Chinese, Japanese kanas, Hebrew, Arabic... as this part will be read locally: the part above the country name uses the local conventions of the target country, including for the placement of city names street names and house numbers, postal codes, people name, and so on). Placing the country name at end on a separate line is sufficient (you can name this country in French, or in English, or abbreviated if it's well known like "USA").

Well, the hyphens in French toponyms is not a strict rule. It used to be a rule for communes, but no longer for "communes nouvelles" (the hyphens are kept in their "communes déléguées").
Hyphens and all punctations (including apostrophes) are also replaced by spaces in printed postal addresses on the last line after the postal code.
There's never been a rule stating that street names and locality names (that are not communes) must use hyphens. This is just an old practive that was used in some places.
And there's never been any space between a leading article and the rest, or between the generic name and the specific name. Other hypens in street names come from some municipal databases, and were just a technical trick to help parse and separate articles, generic names and specific names by whitespaces, when they all were stored in a single data field containign a full postal address or a full address line. In those databases for postal addresses, the streetnames could then be automatically abbreviated where needed (but there's no consistant way to use abbreviations across municipalities or inside many databases of addresses, such as contact lists/agendas: these addresses are bet handled as "freeform" so that you can pack other parts when needed to fit the limitations of length for printed postal addresses)

Note that the boundaries for "Kalrsruhe" are very simple, even these two:
way/19802865, relation/181367

And it's definitely NOT more complex thant any typical international boundary which also requires care and lot of work to keep them connected! These bays were not so complicate (in fact their resilution is much coarser than any typical international boundary or any existing coastlines also used for these boundaries and other administrative subdivisions. They did not "pollute", they represented very low amount of data compared to all the rest, and they did not cause major issues in renderers (given that seas have very low density of data compared to everything else on the borders and lands)

This is a very massive deletion, even if all was sourced from international documents. The reason given does not even hold on OSM: things are always "difficult" to edit everywhere, and here this is jsut destruction of work made by many contributors, jsut because ofg a single user abusing his rights to do what he wants, without even consulting anyone and without notice...