Hello.
Nice that you want to add buildings but… can you please avoid tracing buildings on aerial imagery.
We do not do this in Belgium. Every time someone does this, it takes ages to repair and slows down the effort to add missing buildings even more.
In this area of Belgium (Flanders), the reference for building outlines is "Digitaal Vlaanderen GRB", which shows the real outline without the distorsion.
Thanks.

osm.wiki/WikiProject_Belgium/Building_and_address_import

Don't bother, we fixed it.

(User ici_Be has not been seen for almost 6 years, the account is inactive.)

In case you do not know: We usually do not repeat information inside the database when this information can be obtained in a straightforward manner.

Example for De Panne.
The OSM object for this town contains a wikidata tag, pointing to this page: https://www.wikidata.org/wiki/Q674954
Wikidata is the central repository for a lot of information, so it does not have to be replicated into OSM.
The "official_website" property of Wikidata already stores the URL of the website.

Hello.

Can you please group uploads geographically (i.e. several towns in the same area) instead of alphabetically.

Uploading Dalhem and Damme together creates a giant bounding box spanning over the entire country. Please do not do that.

Thanks in advance.

Hello.

Just curious: did you really visit Norway, the Azores, New Guinea, Japan (changeset/162115214), Arizona (changeset/162115214) and Paraguay (changeset/162123641) on a single day?

An inspection of your latest changes suggests you are actively changing tags on brands, which is fairly unusual when using StreetComplete (not to mention the misleading source=survey tag and the giant bounding boxes).

Have a nice day.

## Reverted
You added housenumber 1 here, but this number was already on the map. As a consequence, we suddenly ended up with two adjacent buildings with the same address.
We fixed your edit.

## Reverted
This is an Oliobox, for cooking oil. The glass-recycling container is a separate object.
Please read your screen correctly when using StreetComplete: a few years ago we obtained that the operator is shown for the quest, precisely to prevent users from corrupting the database by inserting answers for the wrong container.

Bonjour, est-il vraiment possible que les signes d'informations pour « Palais Royal » sont uniquement en français ? Ici, c'est une ville bilingue et les noms sont toujours doubles.

Hello,

Thanks for this "Update".

Please observe that we prefer not to repeat addresses on POI in Belgium. The address is automatically inherited from the container building or from the nearest address point.

Moreover, Brussels is a bilingual area and addresses are written in both official languages.

We fixed your edit.

Hello,

About relation/18646088

Is "Aire de jeu" an official name? Looks like a description, which is useless as long as "leisure=playground" is set.

I don’t think a site relation is useful. Drawing a polygon with leisure=playground is enough. If there are playground=* objects or paths inside it, they will be automatically understood as being part of this. This is the basic principle of inheritance, because OSM is a geographical database. Site relations are mostly necessary to join distant items. Any reason for wanting a relation here?

Thanks.

That is probably not easy with the online editor.

The most straightforward way would be as such: Instead of uploading each area separately, continue editing the neighbour, then another neighbour and so one. Only upload once at the end. This will generate one single changeset instead of a bunch of small ones.

If you select the areas wisely (i.e. all the areas of the same province), the resulting bounding box will not be too large.

Have a nice day.

OK, thanks.

If you continue adding this tag, make sure to follow the import guidelines, and also try to group changesets to avoid cluttering the history reports with dozens of identical titles.

Oh yes, Wandrer, again…

Thanks at least for trying to fix. I’ll try to repair this area in the next days because there are still some strange issues (e.g. way/1356146574 will never be used).

Happy mapping.

Hello,

I am afraid this changeset introduces arbitrary restrictions. Under Belgian law, cyclists are not required to use cycle tracks or lanes if they change directions.

Here is a concrete situation: way/23598324
A cyclist coming from the north may want to stay on the carriageway to enter the roundabout and make a left turn towards Is. Meyskensstraat.

By setting "bicycle=use_sidepath", you instruct navigation engines to no longer use that road. Those engines will no longer offer this possibility and will force longer detours.

This is the reason why we always examine the routing graph instead of blindly applying this tag on any road with a cycle track nearby.

Could you please enlighten us about why you felt it was important to use this tag? Did someone request to do it? Is there something special here explicitely forbidding cyclists to enter the roundabout?

Thanks in advance.

Hello,

Your latest 100 edits have the same changeset title and no source. Can you please source your edits when uploading? (And please consider grouping your edits per area.)

About this change here: I cannot find official data with "21004E" as the official code for this part.

The closest I could find was this open data feed, where all sub-municipalities keep the same code as the parent municipality, i.e. 21004.

https://opendata.bruxelles.be/explore/dataset/codes-ins-nis-postaux-belgique/table/?disjunctive.postal_code&disjunctive.refnis_code&disjunctive.gemeentenaam&disjunctive.nom_commune&disjunctive.code_ins_region&disjunctive.region_fr&disjunctive.region_nl&disjunctive.region_en&sort=refnis_code

Also, is the "ref:INS" tag documented somewhere, in particular how it should apply to objects with different admin_level? Could you please explain why you are adding this tag to objects in the database?

Looking forward to your reply. Thanks.

Hello,

I think this is a rather unusual way to fix the problem. It looks like this street way/1072029253 was drawn in the wrong direction. Maybe there is a "no right turn" somewhere, but simply to alert drivers not to turn into a one-way road against the flow of traffic. These situations are common and we don’t use turn relations.

I see you are mapping for Mapbox, so you probably are mapping after reading reports from users. Did they say anything special about that street?

I tried to inspect the "streetlevel imagery;streetside;mapillary;kartaview " which you claim to use as the source for this changeset/161971123 and found this on Mapillary, which confirms the street has been mapped in the wrong direction.
https://www.mapillary.com/app/?pKey=1035061384868260

Unless you have more recent information, I suggest we reverse Doggeweg and remove the turn relation.

Bonjour et bienvenue sur OSM.

OK pour ajouter Big Appple, mais nous avons corrigé votre édition. Il ne faut pas écrire directement sur les bâtiments mais créer un point simple (sans adresse, c'est automatique).

Corrigé ici : node/12544021478

Bonjour Tommy3009,

Bus 6: Jemappes → Mons relation/11611411

Vous avez mis "Flénu Rue de Valenciennes (3001826868) as platform" comme dernier arrêt de la ligne, qui devient le terminus.

Pas correct.

Toujours veiller à insérer les arrêts dans l'ordre du parcours, sinon vous produisez des données fausses.

Merci de corriger stp.

Dear Tommy3009, I think you are damaging the map here.

This node is used by both TEC and De Lijn.
node/10180708012

You changed network and operator, which had both TEC and De Lijn tags into just TEC… whereas the stop is still attached to De Lijn relations.

Why did you do that?

Thanks in advance for your reply.

Hello,

Your two changes from today have been reverted. This is because, when you tried to undo your first change, you removed an entire address from the map. This is not acceptable.

We restored the normal situation.