note: une riverbank peut aussi être une relation de type multipolygon avec des chemins non fermés. C'est déjà le cas mais il y a bien un fixme indiquant qu'il vaudrait mieux le couper le deux pour la partie maritime avec "tidal"
L'alias "Rivière de Landerneau" pourtant s'emploie aussi dans la partie fluviale sur la commune de Landerneau elle-même, mais pas tellement plus en amont (inutilisé à Landivisiau par exemple, mais aussi à La Roche-Maurice ou à Plouédern). Ca fixe la limite d'usage de ce "alt_name".
Pour le "Dourdun" c'est le plus ancien nom (old_name:fr)=* de tout le fleuve avant la rebretonisation officielle en français sous le nom Elorn. "Dourdun" n'a jamais été employé en breton.

La partie maritime est déjà cartographiée avec son alias.
C'est surtout le reste du riverbank qui est à compléter dans sa partie fluviale
Le linéaire lui est complet aussi dans sa partie maritime, avec son alias et là encore il faut compléter le linéaire en amont dans la partie fluviale
Mais pas besoin de deux relations, une seule suffit pour tout (y compris pour référencer les relations membres pour les affluents avec le rôle "tributary")
Cette relation peut contenir l'alias aussi avec la clé "alt_name=*" (je ne suis pas sûr que "old_name=*" soit approprié car c'est encore en usage)

cici dit tu commentes ici un changeset fait il y a ... 7 ans. Aujourd'hui on a des données plus précises (et surtout l'orthophoto est bcp plus précise pour réaligner un peu mieux). Récemment suite à ton commentaire j'ai revu un peu le cours à Landerneau justement près du pont de Rohan. Je n'ai pas été bcp plus loin car tu sembles vouloirs compléter le reste

Pour moi cette barrière est située sur le pont de Rohan à Landerneau, mais il peut y avoir une barrière antisel un peu plus en aval au Pont de Caernarfon (je doute que ce soit plus bas dans ce pont est la limite des zones de marais salés et d'estran (le reste en amont semble en eau en permanence, donc rempli d'eau douce).

Désolé pour le retard, ce message m'a échappé je le découvre par hasard dans les tréfonds des "spams" (très nombreux depuis le confinement).
En fait la deuxième relation n'existe pas/plus.
Il y a une relation pour le cours linéaire (ioncomplet en amont), et une autre pour le lit (surtout la partie maritime avec un petit bout fluvial séparé en plus, donc incomplet là aussi)
Je pense que pour le linéaire une seule relation suffirait, mais deux pour le lit (riverbank) étant donné la nature différente du régime des eaux et la salinité. Ceci dit je n'ai rien contre deux relations linéaires en coupant au dernier barrage ou la barrière anti-sel à Landerneau, qui bascule et se soulève pour empêcher les eaux salée plus lourdes de remonter plus eau en marée montante, sans empêcher l'eau douce plus légère de passer par dessus par débordement. Le principe de ces barrière anti sel est très simple, c'est la force de l'eau en marée montante qui les fait se lever toutes seules (mais il faut qu'elles soient entretenues pour éviter qu'elles coincent, sinon il faut les actionner automatiquement avec un moteur en marée montante; c'est très courant sur les embouchures de rivières pour éviter la salinisation des sols en amont ou la contaminations des nappes par le sel)

Also I did not "revert" anything as you think.

Oh I see :" zaizone" is a username.
Anwyay nothing is deleted. The achavi shows the admin_level 10 area (an admisnistratrive area which is a quarter, within the municipal arrondissement)
The borders you see are admin boundaries; the water basins in the harbourd are independant and use their own separate relations.

what's the "zaizone", an inventged term...
I've not removed any basin anyway, they are all there.

et au passage donc modifier des objets partagés sur des milliers de kilomètres et dans des tas de relations. Donc des conflits d'édition en pagaille et bien plus nombreux que nécessaire dans ces relations.
Et puis "trop long"?. Non désolé c'est 4 phrases, même si ici c'est dans une colonne serrée.

"Tu n'utilises pas cette méthode". C'est pourtant ce que tu as fait en redessinant tout et effacçnt tout ce qui était là avant, et a

Pourrais-tu éviter de redessiner de nouveaux traits en supprimant les autres, cela génère beaucoup trop de conflits d'édition et ça supprime tous les historiques avec les nouveaux traits avec de nouveaux ids et des tonnes de relations modifiées (beaucoup plus que nécessaire, surtout ici sur des lignes de côtes).
Pas besoin de redessiner, il suffit de "pousser" les points existants en partant des plus proches), en supprimer s'il y en a trop, en ajouter s'il en faut d'autres, et faire les ajustement locaux nécessaires.
C'est très difficile à suivre, dis-toi bien que tu n'est pas seul à travailler sur les côtes, ùême si ça te semble local, l'mpact touche au moins toute une région entière et même très au delà concernant le golfe de Gascogne.
Ensuite on passe de heures à gérer correctement les conflits d'édition et savoir quoi garder, et même en faisant attention, on n'est plus à l'abri d'une erreur dans cette résolution si pour la moindre modif locale qu'on faisait on se retrouve avec des milliers d'objets en conflits comme tu le fais en faisant des retracés complets. En poussant les points, tu limites énormement le nombre de conflits à résoudre (ça ne les empêche pas mais au moins c'est plus facile et beaucoup moins long et pénible). Merci

il n'y avait PAS de nouveau pont dans ce qui était là, et je me suis appuyé pour la géométrie sur l'imagerie la plus récente (pas l'ancienne) dans la zone qui n'est déjà plus en travaux.
Il y a peut-être un nouveau pont supplémentaire (côte ouest peut-être pour la rue André Bardon) mais il n'était PAS encore tracé; en attendant il y a toujours la passerelle parallèle mais séparée du pont de l'Avenue Florian. Si la passerelle n'est plus là elle doit faire partie du BUS et sans doute plus de la rue Bardon plus à l'ouest sur son propre nouveau pont.
La topologie de toute façon ne fonctionnait pas.

note that a signaled bug in JOSM (fixed but still not available for download) causes severe difficulties to use the validator and update modifications or edit conflicts (because it attempts to recurse down to all subrelations and dwnloads too much data). Edit conflicts are hard to solve for now, and require specific subselection for cleaning up the situation. And lot of errors are now detected in the OSM data for unchecked conditions (many people ignore the edit conflicts and do not resolve them, or there are partly submitted changesets living orphaned nodes/ways or broken relations). I'm fixing this slowly because it requires much time to process the data.

The same is true for other smaller objects than "seas", such as natural=water with water=gulf, water=bay... (and not all are "places" with a name but may justexist for other taggings needs, such as access restrictions, dangers, specific protections, areas of scientific or industrial interest, other regulations such as coastal and maritime navigation, pollution, resurgences of non saline waters under sea, flora like herbal fields, aquaculture, historic reasons, specific geological features of the sea bed below these waters...)
We just don't tag and delimit oceans for now (too large and only delimited by coastlines plus place nodes arbitrarily placed), but coastal seas and part of seas are waters: if a relation is creatd for them it should have this water tag as the root needed for other water=* tags.

Which rendering problems ? This allows additional consistantcy checks (the same that occurs on lakes, rivers and estuaries).
I notices for example that these relations forgot many islands detected by their coastlines; but in no case this caused islands to be "flooded" by waters).
Thiks is really natural=water like the rest, not really "places".
The rendering problems are unproven, not seen at all, other wise there would be problems as well for estuaries or lakes. The coastal marshes, rocks, sandbanks, mangroves, bridges over sea, buildings on sea, tidal areas are still rendered with no problem at all (I've checked that in many places, existing renderers for various styles and not just OSM Carto, are not impacted at all and don't need any fix)

De plus je ne vois pas du tout ce que peut faire OsmAnd de ce noeud; même OsmAnd peut chercher un polygone, que ce soit une mer, un lac, une ville, un pays. S'il trouve un label, il ne saura pas afficher la surface entière sur la carte, et zoomera sur une zone bien trop petite (zoom level 18 ou 19, le plus haut supporté par le rendu) où on ne voit rien d'identifiable et où même le libellé n'apparaitra pas forcément là s'il y a d'autres objets voisins! Une mer entière n'est pas un lieu-dit ni une adresse.
Enfin je n'ai vu nulle part le wiki recommander ce label pour des objets aussi grands (le label sert pour des zones bien plus petites plus vaguement définies comme des petites baies (anses devant une plage) ou estuaires; sur des zones étendues comprement de nombreuses sous-zones et des iles, le label est très pauvre et sa position indiquée n'a aucune signification.
Une chose est sure, on ne peut pas avec un noeud place=* et un polygone place=* de même type indiqué (en valeur de place=*) et de mêmes noms. Les noeuds sont juste des substituts temporaires tant qu'on n'a pas tracé les polygones, mais leur position est totalement subjective et ne permet pas de situer les autres objets à proximité ou dans les mers concernées.

Et puis comme tu le vois, même sans aucun label ni noeud il y a bien un rendu du label, et aucun problème non plus pour trouver dans Nominatim.

Note:ici les lignes sont précises car il y a des lignes territoriales, contiguës, et ZEE, et aussi le besoin de référencer les iles et baies incluses. Ce n'est pas possible de le faire avec un seul noeud placé arbitrairement, car il n'y a pas l'info du tout (on ne peut pas le déduire). Le (multi)polygone est toujours meuilleur que le point pour les surfaces aquatiques, le point n'ayant d'intéret que tant qu'on n'a pas complétement tracé les limites et les iles et baies ou sous-mer incluses.

Je ne voit pas l'utilité du noeud qui n'est rue rarement présent et seulement quand les polygones n'ont pas été définis
C'est la même chose pour les mers, les baies, les détroits, les lacs, le noeud si on le laisse fait doublon dans le rendu (affiché en tout petit comme un lieu-dit car il n'y a aucune extension définie, à un certain niveau on voit alors les deux: le gros label du polygone, et le mini label placé arbitrairement.
En tout cas si un noeud existe il ne peut être qu'un label mais ne PAS avoir d'attribut place=*; hors on le sait, les labels ne sont pas rendus, ils ont peu d'utilité même pour les recherches; l'un ou l'autre suffit mais pas les deux, et si on a un polygone définissant l'extension maximale d'une zone, le noeud n'est pas nécessaire.
Quand à celui qui a supprimé (à tord) le polygone de la mer Moire, il s'est carrément trompé: on ne peut pas contruire le polygone avec les coastlines puisqu'un des segments au moins n'est pas une coastline mais une ligne maritime de coupure (certes placée un peut arbitrairement mais on ne peut pas savoir où et pas compter du tout non plus sur les noms des lignes de côtes (surtout la Mer Noire où c'est multilingue, et où il y a aussi d'autres mers adjascentes!

this is fixed

most probably accidental selection, because this is not the local name at that position and not the directions
name:right on a node has no meaning