OK, thanks. Will do.

Step 1: Retagging as disused:* = still in OSM but invisible to end-users. This is to make sure that other mappers will not recreate it if they copy from De Lijn GTFS data.

Step 2: Once De Lijn GTFS data completely removes it, it can be entirely deleted from OSM.

Hello,

What source was used to add those ways inside the airport, please?

We recently had some trouble because a user imported copyrighted airport maps into OSM (changeset/147724524), which goes against established guidelines, not to mention a large number of technical problems (unmatching levels, footways stretching out of the building directly onto the apron, and more).

It looks like your edit is extremely similar.

Looking forward to your reply.
Have a nice day.

Merci pour la réponse. C’est surtout une vérification car dans le passé on a eu des problèmes avec des gens qui importaient plein de données de sites sous copyright, alors on doit toujours un peu surveiller.
Bonne continuation/découverte.

FYI, addr:city and addr:postcode are preferably *not* added to addresses.

Existing boundary relations and postal_code relations already compute them automatically. Flanders and Brussels are among the places of Europe with full automated postal code coverage.
Example here: relation/3479696 ← Everything within this area is automatically recognized as having addr:postcode=3080.

This will also reduce the risk for typos or mistakes and keeps the database light and clean.

Hope this helps.

Bonjour,

C’est quoi, toutes ces boulangeries artisanales qui apparaissent le même jour ? Vous êtes en train d’importer une liste ? Quelle est la source des données, svp ? Ça vient d’un site ?

Aussi, prière de ne pas rajouter des adresses en double. Le bâtiment a déjà une adresse, il ne faut pas l’écrire à nouveau sur la boulangerie, sinon ça fausse les recherches par adresse.

@VDL549
Again, it would be advisable to stop your commenting campaign on dozens of changesets, asking users to justify their actions. You are repeatedly putting the blame on users who are *not* responsible for mistakes on the map, if any.

Also, the way you ask your question is particularly unhelpful. As you can see in the changeset summary, 70 ways and 420 nodes were changed here. Out of courtesy, it would be nice to tell the mapper which of those 490 objects you believe to be incorrect. That will probably get you a quicker answer.

The one you are probably talking about is here: node/3745075517/history

It is wrong to blame @jozin-belgium for the mistake and ask him to justify the choice of the name and to provide you with a reputable source. It is very easy to understand from the history that:
* Version 1 (2015) created the object and named it Cafe De SMis
* Version 2 (2023) renamed it into CaféIn in de Smis
* Version 3 (the changeset you are commenting) only cared to fix the obvious typo by adding a missing space.

It’s very easy to understand that @jozin-belgium is not the one who created the long name you believe to be incorrect.

So, you’ve probably found a mistake on the map. Great! Just fix it, it’s easy. Or if you pretend not to be a mapper, as you once said, you can leave a note to suggest a name change. Discussing trivial points like this serves no purpose. Please reserve changeset comments when people are really doing repeated mistakes or damaging the map—which is definitely not the case here—and next time make sure to address the "blame" to the correct person and not just the last user who updated an area.

Have a nice day.

Your edit has been reverted.
This photo studio was already on the map.
node/4564340237

OK, thanks.

Hello,

The object is already linked to an existing address node (relation/17374176), please do not repeat the address on the grocery store itself.

Also, I wanted to ask: if you know this shop, do you know if their official name only states "Uccle Fort-Jaco" in French or if they have a bilingual name? In Brussels we must always be careful that the map does not discriminate languages; we’ll only do that if the business advertises itself only in one language.

OK, thanks, in that case we’ll stick it to the wall. Done.

Hello,

Some parts of the building have a roof extension which does not match the real outline on the ground. For those cases, I measured a difference of slightly more than 7.5 meters.
Indeed, we are lucky to be allowed to trace directly from government numerical data which has been licenced to use on OSM.

The picture below shows the difference between the official shape (pink) and how it was traced on aerial pictures (red outline).
https://multimob.be/uploads/urbis_err-8554636.png

Have a nice day.

Hello,

I won’t comment about the change in Madrid, which seems to be innocuous, but your edit also erased a boundary area in Poland to retag it as a river. This is a damaging edit and we reverted this.

Hello,

Thanks for this but next time, please inspect the history of an object before adding a mistake that was cleaned in the past. We do not prepend words like "Pharmacie" on pharmacies, especially if it implies forcing the use of one of the languages in Brussels at the expense of the other.

We fixed it.

OK for the NL name, slight difference indeed. But the convention for schools is that the main name uses the primary language of the school. So, Campus Sint-Lukas Brussel in the main name here. We fixed it.

Hello,

Please refrain from commenting on users’ changesets if you don’t understand how OSM works.

Please have a look at the *history* of the object and address your comments to the mapper who introduced that name. Discuss that with that person, and NOT with the last mapper who touched the object; I merely fixed the separator because it raised validation warnings.

relation/17366600 is not a valid multipolygon, please fix it.

Hello,
No addresses on such objects, please.
There is already a relation to link it to the correct address. OSM is a database, we won’t repeat all the elements of the address on every object.
Also, adding name:nl as an identical copy of the name tag shows no added value.
We fixed your edit.

I undeleted the two buildings here:
way/250795793
way/940445540

In doubt, I also undeleted the two small buildings here:
way/250794690
way/860654063
Those two are not easy to spot on 2023 imagery but it looks like they are still there too. If I am mistaken, just remove them.

Bonjour,
Je vois "review_requested=yes" ici.
Globalement, les changements sont OK.
J’ai uniquement coupé le trottoir pour que la partie sur la route soit un objet différent (footway=crossing), way/1264197694
Quelques détails très mineurs de dessin, mais sinon c’est très bon et c’est utile.
Si cette pelouse est un parc/jardin public, peut-être il est utile de l’ajouter aussi.

Bonjour,

Je reviens avec ceci.
UrbIS affiche désormais les numéros des maisons mais il y a aussi 34 en complément de 34A 34B 34C et 34D. Donc 5 numéros au lieu de 4.

Est-ce que UrbIS est correct? Merci.