Hello,

I saw you requested a review here.

Your change is good. Thanks for spotting the mistake, by the way. Indeed, this is a rare situation with both sides on different municipalities and with a different name; it turns out that the first mapper who drew the street a few years ago hadn’t noticed this detail. It is correct now.

There are also 5 buildings along Av. de Roodebeeklaan (280 to 288), which I added to the relevant associatedStreet relation, to have a complete relation.

Have a nice day.

Hello,

Welcome to OSM. This edit you made today was brought to my attention.

From what I see, there are multiple containers in this street, run by different operators. They are mapped as separate objects on OSM.

StreetComplete asked here about the one run by "Bruxelles-Propreté - Net Brussel", which is an underground container for glass (white and coloured).

You answered that this glass-container now accepts cooking oil. I suspect that you mistook it for the orange Oliobox around.

You also seem to have clicked on several other items in the list, which added extra tags to this glass-container, but it’s probably not something they gladly take.

recycling:beverage_cartons=yes
recycling:cans=yes
recycling:plastic_bottles=yes

If there is another container for that (in addition to the pair of glass containers and the Oliobox), please let me know, so that I can add it separately.

Thanks in advance.

Very cool to add Mastodon handles.

But please do not repeat the address on the object. We do not do this (anymore) in Belgium, to avoid data corruption when the same address gets repeated on multiple places.

We removed the address tags you added.

Thanks.

Hello,

I see you requested a review.

There was already a restaurant in this building, which had been remapped as vacant when it closed.

Next time, please make sure to observe the situation carefully before editing. In that case, one should re-use the existing node and put the tags about the new restaurants there instead of creating a new node beside. This helps keeping a clean database, so that we can track the history of a business over the years.

Also, the opening hours on OSM must follow a syntax to be machine-readable. We do not type free text there because apps won’t be able to parse them.

Don’t worry, we fixed everything, no further edit is expected here.
node/8814651902

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.