Thanks for this. I did some minor changes to values (Mostly writing names or address with capital letters + removed wrong addr:* tags for the office on Rue Blaes/Blaesstraat.)

Hello,
There seems to be something strange with this changeset, especially around Place de l’Église/Kerkplein in Berchem. Also with subsequent changesets (69182557, 69182656, 69195171) touching this area.
I may understand that you might have intended drawing an area around the square, but with road-alike tags and by deleting the existing road.
I will try to fix this because we have routing errors in this area.

There is something strange for the southbound track (way/688510420) when it crosses Avenue de la Réforme/Hervormingslaan : you have drawn the cycle track to join node/5873753308. This node is a give-way sign. Drivers should expect the give-way sign either before or after the cycle track. We need to move the node with the give-way sign.
I don’t remember from my latest survey who has the right of way.
Please tell me if you know this: if a driver comes from Avenue de la Réforme/Hervormingslaan and a cyclist comes on the left side along the cycle track, who has the right of way?
Thanks in advance.

Hello,

North of Brussels North station (near Avenue de la Reine - Koninginnelaan), the railway is on an elevated structure, whereas roads and trams are at "level 0".

In this changeset, you reverted tags such as "covered=yes" for way/371914172 and several other ways nearby, to set "tunnel=yes" instead. It might convey the wrong impression that there is some underground infrastructure here.

I believe that setting the railway as being on a bridge is more correct.

If I am missing something here or if there is a specific reason for this choice, please tell me.

Hello,
I got validation warnings because of gaps in bus routes, here and also along E411.
I have tried to fix all the variants for "Cbis", they look all right now, but perhaps that someone who is more familiar with this area should have a look too.

Hello,
The street was already properly tagged with "oneway:bicycle=no", which is the recommended solution for SUL/BEV streets. Most routing algorithms such as OSRM or GraphHopper use this tag.
Adding the cycleway tag does not add anything for routing. On the contrary, it will spoil other queries. (For instance, counting how many bicycle lanes in Brussels: here there is no lane, just some logos, but the cycleway tag will count this street as one.)
Do you really need the cycleway:* key here? Am I missing anything?
Kind regards.

(In fact I thought it was a test because having node with a tree as part of a highway is quite unusual. :-))
You are right. I surveyed the place today and found out those small palm trees are back. I improved the geometry because they have been moved a bit.

Hello,
Was this a test edit? I don’t recall seeing trees acting as a block across the road.

Good, thanks!

Hello,
It’s good to add all this information to the map.
But wouldn’t it be more appropriate to upload all those edits separately? Or at least provide a more descriptive changeset comment?
Kind regards.

Hello,
Thanks for adding stuff to the map.
What aerial imagery do you use to ensure proper calibration of newly-created objects? Some bicycle stands look as if they are located on the carriageway and not on the sidewalk. Of course, this happens sometimes but I remember cycling in some of those streets recently and that didn’t strike me. Nodes 6360711487 and 6360710679 are examples of possible issues.
What do you think?

Hello,
To be frank, I had hesitated about this one.
Some mappers have been particularly keen about using the "name:language" key when the name tag was not following the standard "fr - nl" order typically used in Brussels.
It is not there to *list* the languages but to know how to parse it properly, for instance Q/A tools can check whether the first part of the name matches the name:nl field.
Using full_name:language as a derivative seemed like a good idea, but you may be right, it probably isn’t that useful. I’ll delete it.

Hello,
Would you please be so kind as to explain what was intended with this edit.
Some buildings look like warehouses (building=warehouse), but here you named the entire multipolygon "Hangar", which also encompasses some ordinary houses (way/227791584).
It looks like the relation should be changed from a multipolygon to a site relation, and some buildings should be tagged individually as building=warehouse, but maybe I’m missing something.
What do you think?

Hello,
I think we might have a geometry issue here.
IMHO, way/24614098 (the road) should not be treated as a tunnel going under the railway infrastructure. This way is an ordinary street and Watermaal railway station is on a bridge at level=1.
If you believe I’m missing something here, please tell me. Otherwise, I plan to change the map in a few days from here.

Okay, I was confused because the "amenity=parking" nodes were at version 1. I realize now that you didn’t move existing nodes but just reuse old tags on new nodes. No problem with that.

I may be in the area in the next days, I’ll try to have a look, because I suspect those roads are in fact connected to the ones at the other side of the building.

Hello,
Isn’t there a confusion between "parking" and "parking entrance" somewhere?

node/861714137 is a bicycle rental station, which you tagged as wheelchair=yes.
I suppose this is a mistake. There is a bus stop next to it, but it was properly tagged as wheelchair=yes.

OK, I get your point. Maybe we’d keep highway=service anyway.

Hello,
I hadn’t noticed this changeset until today.
highway=service looks to me as something very specific (driveways, short road connectors, delivery alleys…). Along Simón Bolívar, the small roads on the side are used to park vehicles, and to connect adjacent office buildings → wouldn’t highway=residential make sense anyway, despite there are "technically" no residents?
Didn’t find conclusive evidence on the wiki.
What do you think?

Hello,

Thanks for keeping an eye on new businesses starting or old ones closing. This is useful.

When a business closes, we strongly suggest to avoid deleting the node about it. It is best to remove the tags about that business, but we should retain the node (it contains other information, like the house number), so that the history of every node will not be lost.
I have fixed this one.