We fixed your edit.

Hello,

"bicycle=mtb" is a deprecated tag. Can you consider a better way to tag this? Probably start with this:mtb:scale=*

Hello,

Thanks for updating tags on a restaurant.

Can you please try to write meaningful changeset titles instead of simply naming the city or country where you edit something.

For anyone reviewing edits in our country, a changeset title that just says "Brussels, Belgium" or "Ghent, Belgium" is useless, provides no real information, and makes your edit sound quite suspicious.

osm.wiki/Good_changeset_comments

Hope this helps. Have a nice day.

Hello and welcome to OSM.

I have observed a few changes you made in the last days, and I also saw that other users started reverting some of your edits. I chose to comment on this changeset because I feel it contains an error, but the text below is a general comment. Here are some suggestions to improve.

1) Since you are a new account, I believe it sounds a little overrated to claim that you are "fixing" things (i.e. presumably all the mistakes made by other people who edited the map before you). It generally takes months or years of practice to understand all the interconnections between objects; too many people easily assume that anything they don’t grasp is a mistake. Instead, you might want to use changeset titles to explain *why* you are changing those tags (e.g. your own findings after visiting those roads, or you are writing a routing engine and found some broken connections…)

2) A useful reading is the table here, which gives the default values which (good) routing engines are expected to follow. This page has been actively maintained for years and Belgian mappers often refer to it in case of doubt.
osm.wiki/OSM_tags_for_routing/Access_restrictions#Belgium

3) It is a good idea to avoid tagging default values. The idea is this: by default a normal road (residential, tertiary…) is open to everyone. If you want to prevent motor vehicles from using it, you can add "motor_vehicle=no" to add a restriction. But to lift this restriction (e.g. after roadworks or in case someone would have added the tag by mistake) it is better to remove the tag entirely. Please do not change "no" into "yes" because if you do that we’ll end up with an access tag that repeats the default values. Although routing engines will continue working fine, doing unnecessarily clutters the tag list and will confuse other mappers.
Same with "oneway=no" on two-way roads, in most cases it is not needed.

4) Setting an access tag set to "yes" is only wanted in two situations: when the default value from the table puts it to no (e.g. sidewalks are for pedestrians only but if there are D9/D10 signs we can add "bicycle=yes") or to counter a "no" on a higher class in the cascaded model (typically, something like "access=no" + "foot=yes").

5) Same with turn restrictions. If a street is one-way or is de facto barred to traffic (e.g. pedestrian road) there is no need to add a turn restriction in OSM to say it. Even if the municipality put a road sign to warn drivers. Routing has already excluded it from the list of streets; such a restriction only creates confusion and makes the database even more complicated to update later.

Happy mapping. Feel free to write back under this comment if needed.

Hello and welcome to OSM.

A description tag on a regular building will hardly be useful. You might want to remove this tag and add a simple floating point inside the building. Here are some useful tags:

office=it
name=<name of the company>
contact:website=<full URL of the main page>

Hello,

About this object in the Netherlands: node/2765340250/history
Doesn’t "access=yes" contradict the explanation you gave in the changeset title?

⚠️ Please never change UrbIS building values like this.
building=pedestal was correct, this is the structure under the statue.
There are two objects here: a pedestal (area) and a statue (node) on top.
In this changeset you retagged the building to change into a statue on its own and broke the building relation to the existing object.
I’ll restore tags.

OK mais svp ne pas créer des doublons d'adresses dans la database, ça nous oblige à tout renettoyer derrière vous.

Adresse sur le bâtiment, c'est suffisant.

Aussi, les numéros de téléphone dans OSM, toujours au format international : +32 81 XX XX XX pas 081 XX XX XX, merci.

OK merci.

Bonjour @Tututuuu et bienvenue sur OSM.

Est-ce un « test » avec des données fausses juste pour tester ou vraiment des données à inclure dans la database, svp ?

Attention : pas de tests sur la DB en production.

Merci de répondre sous ce message car je vais en profiter pour corriger quelques erreurs dans les tags. (p.ex l'info sur le terrain en pente, vous n'utilisez pas le bon champ d'information).

OK, thanks for this and congrats for having started the community discussion to propose this tag.

Hello,

Please observe that we do not repeat addresses on POI in Belgium.

Thanks.

Hello,

key:virtual_tour which you added is currently unknown in the database.

Taginfo contains one single occurrence of "website:virtual_tour", which might possibly be a replacement.

Could you please explain what you tried to achieve with this tag. Do you know any third-party app that extracts this tag? Thanks.

SVP ne pas remplacer le bâtiment par une boulangerie. Next time: mettre un point flottant pour y indiquer la boulangerie à l’intérieur du bâtiment, merci.
Nous corrigeons.

Hello @DCools.

Thanks for updating but please have a look at the list of stops within the relation here, which you edited:
relation/18226734
(Unroll the "Members" section at the end).

Can you please answer this question:
Why did you put "Staden Dorp" at the end of the relation. It is not the terminus, right?

All the bus stops should always be grouped together in the beginning of the list, in the correct order. Sorting must be done manually by users who edit the map, it is not automatic.

Thanks in advance.

The clinic is already on the map, here: node/332542323

Please do not upload new data that duplicates existing data, this damages the quality of the map. We reverted your change.

This is not what I am talking about. I am not questionning your sources, I am just saying that shops should not be mixed with building outlines. If you want to add a business, it is better to add a floating point inside the building and put the shop-related tags to it.
Don’t bother, I will fix it.

I am also reviewing all the changes you put to the production database in the last hours, to fix as much as I can.

Hello,

This is a comment on your changeset. I am writing to you because I see you wanted a review, and also because the changeset contains a mistake.

The Italian restaurant is already mapped as a node, here.
node/5832150834
This is the correct way of mapping objects.

In your changeset, you changed the building as if the building itself was only a restaurant… creating a duplicate because now we have a restaurant inside a restaurant.

Please remove the restaurant tags on the building itself. Leave it for what it is: just a building. Thanks.

Je crois que vous mélangez les bâtiments et les commerces.

One feature, one element, please.

Ce changement n'est pas correct et il fait disparaître le bâtiment de la liste des bâtiments.

landuse=residential + residential=apartments désigne une zone de terrain et non pas un bâtiment.

Ne pas se baser sur les mauvaises traductions françaises de iD pour choisir, svp → il faut regarder les tags de la database.

Nous corrigeons.