Thank you for your reply.

Multipolygons are indeed invaluable to map complex structures. But there is more… The second sentence in the documentation says:

"They can also be useful to make the distinction between linear objects (e.g. a fence surrounding a property, tagged on the way) and the area inside (tagged on the multipolygon relation) without having to draw overlapping ways."

And that’s exactly the case here: we have a (linear) fence on the left, what has just become a (linear) retaining wall on the right, and an (areal) construction zone in the middle. I can’t think of a more canonical example of the usage mentioned in the documentation. This structure was not a "problem" created by iD, but a deliberate choice, to avoid creating overlapping ways.

By the way: there is a "construction:residential" tag, which means, according to the documentation, that a residential highway is under construction. It is actually the new bus station.

Could you explain why a multipolygon is not appropriate ?

You just added this way. Did you verify on site that it does really exist ? Hint: I did, and I can tell for sure that it has been replaced by a big hole.

Maybe I start to see the light. In my active life, now vanishing in the distant past, I worked with standards from official bodies, like ISO, IEC, CIE, IEEE, IETF. While not devoid of defects, most standards where rather complete and consistent. When a standard includes many options, it is customary to define and publish profiles, sets of options to be used by a class of users.
The standards of OpenStreetMap are developed in a very haphazard way, and are therefore often inconsistent. So it seems that a profile has been defined for mapping railways in Belgium. Since it is not published, one can only discover its existence by committing a sin against it, and being corrected by someone knowing better.
As for the position of the main point, it seems to be variable: in Leuven, for example, it sits in the middle of the station building.
So: I defined the building as train_station, removed the main entry from the stop_area relation, and, as an exercise, created the missing stop_area relation for the station in Céroux-Mousty. I hope that the result is now conformant.

I have nothing special in mind, I just want to tag things as correctly as possible. In those two pages : public_transport=stop_area and osm.wiki/Proposal:Public_Transport, one can find a table of the recommended members of a stop_area relation, and both list the station building. So I have no reason to think that it would be a bad idea.
It is also said that such a relation may include elements pertaining to different modes of public transportation. Since Ottignies also has a platform for busses (not yet mapped, but I am working on it), it could be added to the picture.
And I am trying to keep the pedestrian navigation continuous, despite the frequent changes caused by the works in progress. Next work is to add the services inside the temporary station.

On this page: railway=station
the station building is indeed member of the relation.

Should the building be made member of the relation "Ottignies" grouping the parts of the station ?

Situation vérifiée sur place, description adaptée.

Dans ma lecture de l’attribut, il s’agit de noter si des marquages existent sur la chaussée ; que les voitures aient le droit de circuler ou non est irrelevant. Si une commune met des marquages des deux côtés d’une voie à sens unique sauf vélos, c’est comme ça… J’irai revérifier ce qu’il en est exactement.

Quand l’avenue des Prisonniers de guerre est devenue rue cyclable, cette caractéristique a été étendue sur quelques mètres dans les rues du Pont de pierres et François, qui étaient auparavant des sens uniques sauf vélos. Lors de la modification à ces deux morceaux de rue (Pont de pierrres ET François), les « oneway:bicycle no » ont malencontreusement disparu. Les voici rétablis.

En effet, il est entouré de barrières. Cela pourrait ressembler au début d'une installation de chantier. Ce qui ne serait pas étonnant : https://archeologia.be/actualite2020004.html

Merci pour cette réponse, en français parfait 8-). Je me permets donc de continuer en français.
Il y a malheureusement encore des appareils, systèmes d'exploitation et applications qui ne traitent pas correctement des pans entiers de l'Unicode. C'est un problème aussi vieux que, non pas le monde, mais l'informatique : si l'on avait toujours attendu que le dernier dispositif retardataire soit en mesure de traiter la nouveauté avant l'appliquer, on en serait toujours à se limiter aux 95 caractères de l'USASCII, bloqué dans les années 60.
Je suppose que chez ceux qui disposent d'un dispositif ancien ou de mauvaise qualité, le préjudice est de nature esthétique : caractères remplacés par des points d'interrogation ou par des rectangles. C'est certes vilain, mais pas inutilisable, en attendant que par l'effet des remplacements naturels d'équipements, le problème finisse par se régler (sauf si l'on tient absolument à rester dans le chinois bas de gamme, qui affiche impeccablement les idéogrammes jusqu'au dernier, mais a de gros trous par ailleurs).
Bref, je ne suis pas d'avis de reculer sur la question de la typographie correcte.
Bonne journée (à vélo ?).

Maybe you are dutch speaking ? Anyway, the only typographically correct abbreviation for « numéro », in french, is « nᵒ ». See for example https://en.wikipedia.org/wiki/Numero_sign. "nr" seems german, except that the correct german form is "Nr".

Bonjour,
Puis-je vous demander pourquoi vous remplacez des abréviations françaises (nᵒ) par des abréviations (nr) qui n’ont pas de légitimité typographique ?
Voir : https://fr.wikipedia.org/wiki/Numéro

Bonjour,
Nous avons travaillé quasi simultanément sur les mêmes objets. Il semblerait que le cache de GoMap s'en est trouvé un peu confus, de sorte que je me suis retrouvé à un moment avec des nœuds parasites, en particulier aux frontières des zones d'utilisation du sol. Mais je pense avoir pu y remettre bon ordre.
Bon, si on voulait être entièrement dans la ligne du parti, il faudrait sans doute couper les zones résidentielles en multiples morceaux afin de ne pas y inclure les routes. Si le confinement se poursuit encore longtemps, on finira peut-être par le faire pour s'occuper 8-).
À la prochaine...

Ce chemin est invisible, tant sur les vues aériennes que sur le terrain. Il semble qu'il a été ajouté sur base de l'Atlas de 1841, sans vérification de son existence actuelle.
Puis-je attirer votre attention sur ceci, extrait de la page osm.wiki/FR:Bonnes_pratiques :
« Ne cartographiez pas des évènements historiques ou des éléments qui n'existent plus
Ceci est la conséquence de l'obligation de vérifiabilité. Ne cartographiez pas d'évènements historiques. De même, ne cartographiez pas d'objets qui ne sont plus visibles sur le terrain, car ces éléments ne peuvent pas être vérifiés. »
Il conviendrait donc sans doute de supprimer ce chemin.

Thank you for your fast and courteous answer.
I happened to see those changes because I was about to perform some corrections after a walk in the region. It is my personal policy, in line with OSM recommendations, to only correct things I have personally seen (most of the time anyway 8-)). So my action in OSM is of the slow and steady style.
About the capitalizations and other defects: sure, there are quite lot, but I am working on them, like described above. In particular, in this very zone, a recent mapper has started to add all the 'Chemins' and 'Sentiers' present in the Atlas, without considering the situatioin in the field (aka 'Armchair mapping'). And he usually does add them without capitalization, too... So now, each time I go for a walk there, I have to look carefully at all those pathes to see if they exist or not, the bad capitalization/spelling beeing a strong hint.
Thank you for restoring the previous versions, good or less good. I have some work to do at other places where I have been walking recently, so don't feel too hard pressed.

May I ask you the reason why, with this single (automated ?) changeset, you did deface about 400 names ? The way there were encoded (Chemin nᵒ 9, Sentier nᵒ 47, ...) was consistent with their appearance in the "Atlas des voiries vicinales", which is the source of all those names. It is also how they appear on most name signs installed by the local authorities (pictures available). And this is normal, since it is the correct French typography. In comparison, for a native French speaker, the "new" way looks rough and uneducated. So, please revert this changeset and restore the typographically correct names.

Hi,
May I ask you why you are deleting pathes that DO EXIST in the field ?
If those pathes can be proved to be private, there are appropriate "access" tags to document their status.
If those pathes are not highly practicable, there are appropriate ways to document the fact.

Une nouvelle visite sur site a bien apporté la confirmation que, sur le panneau d'information planté à côté du bâtiment, figure toujours le nom "La porte de la ferme". Le principe de vérifiabilité impose donc d'encoder ce nom dans OSM.
Comme il ne peut y avoir deux portes de la Ferme, la porte de Nivelles (https://fr.wikipedia.org/wiki/Porte_de_Nivelles_(Villers-la-Ville)) doit également retrouver son nom.