Hi,
In the case of buildings with a complex history, this allows users to pinpoint the last modification made to the building. There's a note below explaining this: "1895 Mascara depot (TRT); 1968 expansion and conversion into warehouses; 2023 demolition of a northern section."

Hi,

All mm ways should be in m as of now.

I've shifted most of them from min/max to start/end when the road is shifting from one width to another such as this one way/1426169241

However there are ways which do not switch from one width to another but rather have a varying widht, and in those cases min/max is appropriate. Should I ask for a wiki page to be created ?

Shift from wikimaginot url to ref:wikimaginot is done ;-)

Thanks, I'll add it !

ref:wikimaginot seems the most appropriate, isn't it ?

How can I ask for the ref:wikimaginot to provide a link with the tag id in a similar way as other ref:tags do ?

Par contre, si les entrées sont dissociées (l'une 72, l'autre 74...), tu peux mettre un point avec entrance=main ou yes et l'adresse sur ce point.
osm.wiki/FR:Adresses#B%C3%A2timents_avec_plusieurs_num%C3%A9ros_d'adresses

Salut,
Concernant le 74-78 rue du Général de Gaulle à Dampremy, ce n'est pas une bonne pratique de diviser arbitrairement une maison en 4 pour avoir des numéros dissociés, tu peux très bien laisser en addr:house 74;74A;76;78 ça ne pose pas de soucis.
Amicalement

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 railway=abandoned

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 ?
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 relation/19284329 , this one uses the same lines as the previous one, with the addition of a simple line without "source:geometry" 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.