Hello,

There are several tagging issues here.
Mistakes are common on the first edits.

Just a few pointers here:
1) amenity=school for a school is okay, but having a school inside another school goes against OSM rules. Perhaps landuse=education for the overall perimeter and amenity=school for each school. Unless everything is one single school, them amenity=school goes to the overall perimeter and there is no school tag on the buildings.

2) phone numbers in international format, please: +32 9 …… not 09/.. stuff

Happy mapping.

Hello,
Okay, good job overall.

I should have mentioned two more details, but I could easily fix them:
* remove addr:* tags on the main buildings
* in Belgium, roles in associatedStreet relations should exclusively be street or house, do not use "address", despite iD will suggest it.

Don’t worry, everything is fine.
Happy mapping.

Hello,

Do not forget to update the highway type too (highway=living_street).

Hello,

Thanks for editing the map for the first time.

I appreciate you describe your changes.

Just one thing here: you added the number of levels on a few houses. I wish to warn you of a mistake: the ground floor should always be counted. If a house has the ground floor + one floor above, then we put "2" into the database. Don’t worry, I’ll fix it.

Hello,

This is a destructive changeset: removing long-standing relations referred in existing systems. It looks like you drew the same bus route from scratch on a new relation in another changeset, starting at version #1.

Preserving the history of OSM objects is a recommended practice (osm.wiki/Keep_the_history).

Could you please undelete those relations and copy your work into those instead?

Looking forward to your reply.
Have a nice day.

OK, I get your point.

Yes, this roadsign appears to be a C11 (with funny colours, the red circle is gone) and we should consider this as sufficient. I found the same sign on recent Mapillary pictures, so that should be okay. I am still concerned about the southbound direction because I don’t see any sign there, and we are keen to map according to the law and not to our personal taste for danger. ;-)

Don’t worry, I’ll put it to my survey list and I’ll try to see in detail, or ask a friend to have a look.

Happy mapping.

Hello again.

It’s very hard to know who really uses ref:UrbIS tags in OSM nowadays and if they are really needed. (And if they are correct, because some data may be outdated.) In doubt, I keep them.

If buildings are to be merged, usually we expand one of them to swallow the other one, then we either add a dual tag with all values on the building—like this ref:Urbis=7135;7136—or alternatively we create two addr:* nodes for each housenumber and each one gets the ref:UrbIS tag of the building it replaces.

Perhaps it’s not easy to reshape buildings with the iD editor. If you tell me which building it is, I can easily do it JOSM.

Hello,

You seem to have inadvertently erased about one third of the building, I restored it. These things happen on first edits, I understand.

Just two things:
1) We should *never* draw buildings on top of aerial imagery, because it is not accurate enough and aerial images are always distorted. We have very accurate numerical imagery for Brussels through UrbIS.
2) Could you please elaborate a bit about the "intégrer cette modification": what change exactly, is that the property limits, renumbering of the house…? It is important because if changes are not properly documented, other mappers will probably restore the former situation.

Reply in any language you feel comfortable with. Thanks in advance.

*were surprised

Hello,

The building is impressive because it very tall, and that’s why it "looks" much larger than it really is on aerial imagery. The current area is around 815 m² and is plausible. We followed offical outline of the new building set in UrbIS. When drawing this shape, I was also puzzled by how small it looked, and we know that sometimes UrbIS is wrong. I understand you were surprise, and I was too.

One thing is certain: undoing this edit and restoring the former shape would be clearly wrong because it was way too big.

I contacted some friends who worked with the architects, to see if we can have a look at construction plans. That would help to see whether UrbIS is correct.

Hello,

This website names it differently in French, i.e. "Fontaine aux fleurs".
https://lemuseedeleauetdelafontaine.be/listing/bruxelles-la-fontaine-aux-fleurs/

We could compare this with the source of information you used for this changeset, and follow the most reliable of the two.

Have a nice day.

Hello,
When you add a name, do not forget to remove "noname=yes" if it was set, because that creates an obvious contradiction.
Good to know this area has a name now.

Hello,

I am reviewing some changes here and came across your edit.

Are you sure about the type of bicycle parking here?
"rack", really?

Those are very uncommon in Brussels, I thought they had installed bicycle stands here ("stands" is for U-shaped structures).

Could you please confirm this is really what you saw here?

Hello,

Here is a hint for roads that go across buildings. ;-)

Do not fiddle with layer=-1 until iD stops complaining. The recommended way is to create nodes where the road and the building intersect, then split the road around those nodes, and tag the part across the building as "tunnel=building_passage".
Like this: way/1051535160

Hope this helps.

Hello,

Thanks for improving the PT network in OSM. Your changeset raises a few questions, though.

1) Wouldn’t it have been better to re-use existing relations (in particular the route_master relation referred on the list of Belgian bus routes on the wiki)? If you create new relations while erasing existing ones, it makes it particularly hard for other mappers to keep track of changes, or for apps that use existing data.

2) I see some people adding [1] and [2] suffixes to route numbers in Wallonia, to identify directions of bus routes. This goes against existing tagging practices everywhere else. Even TEC does not communicate about directions 1 and 2, this is purely internal stuff. If you know about some documentation or who created those guidelines it might be useful. Some mappers have already asked this question, it seems.

Thanks for replying.
Have a nice day.

Hello,

In my comment on your other changesets, what was expected was a discussion, not mechanically changing every bicycle=no tag into bicycle=use_sidepath. Now, we have many more issues to solve because of unmatched ways.

I will investigate and try to fix as much as I can. Just one question because I assume you surveyed this area. I am not aware of any legal restriction against cycling along this road: way/31111802
Are there any legal signs here? Didn’t spot any.

Thanks in advance.

Hello,

Any reason why you set bicycle=no instead of bicycle=use_sidepath here?

Also, before adding restrictions, please always make sure you have checked that all possible combinations remain possible for navigation. In Belgium, cyclists may legally use the road even if there is a signposted cycle path on the side, for instance to make a left turn. We usually only add restrictions after checking that everything still works.

Hello,

Your drawings are visually very beautiful, congrats.

Something about sidewalks. You might be interested to avoid drawing circular ways around blocks + 4 tiny connectors between them and edges near the zebra crossings.
I prefer drawing L-shaped ways (sidewalk along a street, then turning onto the nearest crossing), which makes it considerably easier to maintain the map. Because those small 1-meter ways are a real pain to deal with.

Just a suggestion but it will be appreciated.

Have a nice day.

Hello,

Thanks for this change but just one thing again: when you add address nodes to populate associatedStreet relations, please use "house" and not "address" for the role.
I know the iD editor lets you do that and shows a long list of choices, but this is because iD is a very simple editor that does not check how things are done in every country. In Belgium, we stick to the first two choices.
Thanks.

Don’t bother, I edited it to put the correct value.

(If you spot a mistake the next time: StreetComplete has an undo button in the lower-left corner of the screen. It works as a stack model, i.e. you can undo the last change, and then the change before that, and so one.)