Hello,

I am trying to review your changeset.
I am afraid to announce you there are several issues here. I understand you are doing your first edits, it’s never easy to start.

Those guidelines may help.
(I write in English because it is easier for me but you can reply in any language.)

1) By default, places like gardens or swimming pools are public. People use OSM-based apps to look for the nearest place where they can have a walk or swim. Be sure to add "access=private" tag on them if those are private places, that way they will not be advertised to passers-by.

2) Houses: very important: all the buildings in Brussels are already on the map. Please never try to redraw them. Here is the reason: the building shape we show on OSM is the real outline of the building. In the online editor you can find this in the UrbisAdm layer on the Background menu. Please never redraw buildings by tracing on aerial imagery. Those are taken during yearly cartography flights and buildings are never shown top-down properly on those pictures. I had to undo all your edits along Avenue Coloniale/Kolonialelaan and Rue de l'Abreuvoir/Hondenwetstraat because buildings were away from their real locations.
If there are new buildings, of if you are not sure, you can always create a note on the map.

3) It’s always a good idea to make smaller edits. If you add a couple of gardens and a zebra crossing on a street, stop there and upload that, and then start drawing on another place. This makes reviewing much easier.

That being said, I really appreciate that you write good changeset comments to describe your changes, this is fine.

Have a nice day.

Hello,

Though "path" is the usual word, shouldn’t it be tagged as highway=footway instead?
way/1117123839

This is because the default access tags for a highway=path and a highway=footway are not the same in OSM and it creates incomplete routing situations if your "path" is only connected to footways.

Hello,

way/1116846952/history (version #4)
You added role=outer + type=multipolygon on a way.

I think there is a mistake here. This is not how the OSM data model works. Those tags are to be used on relations, not ways/areas.

Hello,
I see from your edits you are using the iD online editor.
For some unknown reason, this editor chose to name UrbIS latest imagery differently, indeed they name it "CIRB/CIBG most recent aerial imagery", but it resolves to https://geoservices-urbis.irisnet.be/geoserver/ows, as other layers named UrbIS-Ortho*
That’s usually a safe choice, though sometimes you may want to recalibrate it before editing (hopefully much less often than AIV imagery, though).
Have a nice day.

Hello,

building=garage is to be used _exclusively_ for building structures.
way/1116514475

If there is some space to park a car in front of your house, it should not be drawn as a building. This is fake data and should be erased.

I am trying to investigate your other edits, fixing footpaths and other errors (you seem to have been moving lots of objects by mistake, we’ll have to clean this up now).

There were a few mistakes here.
Fixed by changeset/129277423.

Please no silly name such as "Jardin" on objects. Names are only if something has an official name (a street, a shop…). A name is not a description. Tags are enough to identify the type of object and display it correctly on the map.

way/1116505769

name=Prairie à chevaux

This is a description, not a real name. Please remove the name.

Hello,

I know those are presumably test edits and I hope you will revert or fix them.

For instance, name="Chemin gravier" is incorrect data. Use description:fr if you want to describe it in plain words, but please do not fill the name tag unless a path has an official name.

Hello,

With "gps" I suppose you mean the routing algorithm of an embarked device.

highway=motorway and motorway_link already defaults to no in Belgium (and probably in every European country). Have you considered reporting the problem upstream? It might be better than adding tags in OSM to circumvent software bugs.

Thanks for this.

But please remember this: by default, a highway=pedestrian disallows cycling. We need to add bicycle=yes on the streets if cycling is allowed. (Don’t worry, I fixed it.)

Hello,

Why did you move this node and attached it to a road? Is this a test edit?

Though I am not a specialist of railway landmarks, a quick online search seemed to indicate the "CPI" was correctly located along line 26 (https://www.flickr.com/photos/80559116@N06/50606418647/)

Hello,

Would you please be so kind and use proper changeset comments to describe what you are doing?
"changed", "added"… provide no real information.

It looks like you have been changing the highway type of some roads.
I am a bit puzzled about this one: way/381113307/history → you changed a highway=pedestrian into highway=unclassified, but the street still has a—probably useless—huge list of access tags, making it impossible to route properly (whatever the highway type, only pedestrians will be allowed to use it, according to the current tags in the database; judging by the changeset comment here, restricting access to pedestrians was deliberate changeset/35420351). This is an example of why it is important to document changesets properly.

This is also a problem here: way/1115576090
It looks like pedestrian routing was broken. Good point for using a proper footway connector but now you’ve broken cycleway routing (in both directions) and invalidated cycle relations. Was this intended?

Hello,

Incomplete/bad tags here:
way/1115795924

Is this a hairdressers shop?
Use shop=hairdresser instead of building=commercial, then. And the name should not start in lower case.

Happy mapping.

Hello,

Warning: it looks like you are sometimes misaligning objects.

This edit is located in the Brussels-Capital Region. Please use UrbIS imagery for Brussels, not AIV Flanders, which has a lower resolution and is not entirely orthophoto-calibrated in our area.

Hello,

Thanks for this but there might be a few issues:

1) Can you please ensure your changeset titles reflect what you are *really* doing on the map. This change has much more to do than bicycle parkings.

2) Do you really think that way/1114965791 qualifies as landuse=forest? This tag is certainly not to be used in the middle of a highly-urbanised one like here.
There is just a tree with some green around it: https://www.mapillary.com/app/?pKey=1022115642021219
I think landuse=village_green will make a little more sense.

Hope this helps.
Have a nice day.

Hello,

Sorry but we had to undo your latest changes.

Let me explain:
The house and the music venue are not the same thing. The house is just a house with a housenumber. The music venue should have its own node, with name=BBB Studio and be tagged as amenity=music_venue.

OpenStreetMap is primarily a database. The "map" is just a layer that renders *some* information from the database. There are plenty of different layers (6 different layers on osm.org and dozens of other renderings elsewhere or on mobile apps), some will show this point and some won’t.

I suppose you are primarily interested to have the name visible on the map. But putting the name on the building itself is not correct. (This is called "mapping for the renderer, i.e. putting incorrect information in the database to achieve some results on the map.)

The devs of the main map layer—the most popular one, visible on osm.org, I guess that’s the one you had in mind—are dealing with several new tags that could be rendered in the future. I will try to warn them about the idea of adding an icon for all the places with amenity=music_venue.

Hello,

When a shop closes down, do not delete it. Just remove the name and type and tag it as vacant.

That way, we can follow the history of points over the years, what will not be possible if you destroy it and someone creates a different point in the future.

(Sorry, I sent the previous message too fast, here is a better version.)

I see you are using the iD editor.
When you are editing the map, there are buttons on the right side of the screen. One of the buttons in the middle is the "Backgrounds" button: click on this one and scroll down to "AIV Flanders GRB". Then you can see the correct basemap. Normally, you can trust this data; but just like all government data it is sometimes outdated.
Don’t worry too much about this street, I had planned to spend some time reviewing the line of houses here, reshape them and check the numbers, hopefully in a few days.

I see you are using the iD editor.
When you are editing the map, there are buttons on the right side on the screen. One of the buttons in the middle if the "Backgrounds" button: click on this one and scroll down to "AIV Flanders GRB". Then you can see the correct basemap. Normally, you can trust this data.

Hello,

In the previous changeset, I had explicitely described the situation about this shop:
node/7107743044/history

As you know, it will only open in a month. We feel it’s a bad idea to fake it on the map and pretend the shop is really there. Most users will be misled, expecting to find a Kruidvat here and find closed doors until Dec. 13.

That is the reason why I explicitely tagged it with a lifecycle prefix (proposed:shop instead of shop) and a start_date; I had set a timer to be sure to update the tags a few days before the opening.

Your change seems to contradict that entirely. Only clients able to properly parse the opening hours string might notice there is no shop at the moment. And now we have several tags contradicting each other (you added shop=chemist but didn’t remove proposed:shop=chemist).

If you don’t mind, I think it will be better for everyone if we could wait until December. Don’t worry, regardless of the situation, your shop is still in the database. And we have an active community of mappers here, ensuring everything is up to date.

What do you think?