Salut,
La page wikipedia peut-être supprimée, fusionnée ou n'avoir jamais existée cela ne justifie pas de supprimer le tag wikidata.
Amicalement

Toujours rue de l'Énergie, là où la zone ballastée double en largeur c'est là où se situait l'évitement.

C'est exact, entre Destrée et la route de Châtelet il reste le site propre, rue de l'Énergie il reste tout l'accotement ballasté et sur les sections en site propre l'emprise est encore visible.

La page wiki ne semble pas indiquer qu'il y a eu une prise de décision dans ce sens osm.wiki/Tag:railway%3Dabandoned

Salut,
La discussion sur la suppression des railway=abandonned a donc abouti à une prise de décision communautaire je suppose ?

Salut,
L'aubette du parc Crombez va devenir un kiosque à journaux ?

Si pas c'est une erreur alors car il s'agit de l'ancienne aubette des trams vicinaux.
Amicalement

Ok top, merci de ta réponse rapide :D

Salut,
Le chemin qui déborde au nord est-ce une erreur ?
osm.org/way/1047837908

Je ne vois rien sur les cartes et il n'était pas relié aux chemins existants

In the case where a multipolygon is composed of lines with no tags except "source:geometry," let's say we replace this multipolygon with a simple polygon. What do we do with these two lines? If they can remain in the database and provide a source for other contributors, then I don't see any problem with switching to simple polygons.

My main concern is the sources, as long as the sources are present on the objects; I don't care whether we use polygons or multipolygons. Sources in diff comments (when there are any) are nice, but apart from the fact that you have to search the object's history each time, it doesn't allow you to work with cross-referenced or complementary sources!

(POV) However, if I had to argue in favor of multipolygons, in the long term, what would be the storage space saved by having a widespread use of relations listing shared linestrings instead of polygons listing nodes (boundaries work on this principle and it works). If I take the case of the Athénée Royal de Rochefort, it is 4 linestrings listed instead of 24 points. And knowing that by using sources like the PICC, the GRB or recent aerials, we can easily multiply the number of geometry points by 10, I let you imagine the potential savings.

Hi,
This one, for example, uses aerials and PICC osm.org/relation/19284329 , this one uses the same lines as the previous one, with the addition of a simple line without "source:geometry" osm.org/relation/19284222

Yes, I see the problem with the school multipolygon. I need to finish a street in Saint-Nicolas (Liège) and then I'm going to map the road between Rochefort, Han-sur-Lesse, and Wellin based on aerials and PICC, in addition to adding 2-3 walls, hence this multipolygon in preparation for the import. Something I didn't mention in the comments, which is a mistake!

Tried the F thing on both id and JOSM and it didn't work. Can you tell me more about this?

However, this doesn't solve my problem; I don't see a way to create a simple polygon object designed with lines using different "source:geometry" values except by using a multi.

As for added complexity, I've given my reason for using this type of relationship in a very specific and rare case, and as soon as we get beyond that, I can agree with you. The multipolygon is a basic and common object that every beginner knows, and if not, it takes 10 seconds to understand how it works. As for modifying a multipolygon, whether in JOSM or id, I don't really see the problem, except for the reluctance to not do as usual which isn't complexity.

Hi,
I agree with this idea for polygons that use continuous lines without tags.

However, their use is necessary when using different sources for geometry (e.g., one line without the "source:geometry" tag, the other using PICC/GRB). This is to avoid mixing geometry sources and, as a bonus, it avoids having to duplicate entire lines, which saves us time.

I don't see any more changes to revert, however given the warning message at the top of the "Approximations" section, it would be interesting for you to have a discussion with the person who added this message.

Hi,
I'll fix this later this day, I'll come back to you when it's done.

Done

Hi,
For the start_date, I posted an answer on the Key:start_date wiki page, I also started a discussion here https://community.openstreetmap.org/t/111085

Good morning,
Where did the source:geometry as with 1164690139 go? Disappeared.

What were the problems?
Were the buildings displayed correctly? Yes.
Were landuses displayed correctly? Yes.
Did it have source:geometry tags to allow other users to check out the work? Yes.

"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."
osm.wiki/Relation:multipolygon

Hi,
The start_date corresponds to the date when the feature/road exists as it is, here the start date of the N7 with its current route. As for the date of construction, it probably dates back to the 18th century under the Austrian era.

We can draw a parallel with the Saint-Louis-de-Gonzague church in Monceau-sur-Sambre, the construction dates would be 1838-10-08 for the main part of the building (building:part), 1914 for the bell tower ( building:part) and something like "from 1838-10-08" or "1838-10-08 onward" for the complete building (building=yes) but the start_date for the latter would be 2000 as the church is deconsecrated and that corresponds to the date when the feature exists as it is today, i.e. a simple building with the tag building=yes.

As for the roundabouts, you are right, I am finishing compiling the routes of the N7 made from aerial and PICC/GRB imageries for another project and I am going to improve some of the the roads while also correcting those dates. It will be done within a few days.

Salut,
Ce chemin n'a pas de nom donné, j'ai suivi l'usage fait pour les anciens sites propres ferroviaires convertis en chemins ou RAVELs.

Hi,
Corrected to start_date=1972.

Thanks for the info on the 2019 merger, I'm correcting that right away, Antwerp and RBC/BHG have not been changed.

Oudsbergen - was unchanged.
Kruisem - corrected.
Aalter - corrected.
Pelt - was unchanged, admin_center changed from Neerpelt to Pelt.
Deinze - corrected.
Puurs-Sint-Amands - fixed, admin_centre changed from Puurs to Puurs-Sint-Amands.
Lievegem - fixed, admin_centre changed from Zomergem to Lievegem.