Hello,

Thanks for sharing information. I am writing this comment to you because I am afraid there are some serious issues here.

Please observe that the opening_hours tag should be machine-readable and follows a very strict syntax. Also, OSM is used in the entire world and there is little chance apps can read a string like "vendredi 06:30–22:30 samedi 07:30–21:00 dimanche 07:30–21:00 lundi 06:30–22:30 mardi 06:30–22:30 mercredi 06:30–22:30 jeudi 06:30–22:30" which you wrote in French.
The correct syntax is: "Mo-Fr 06:30-22:30; Sa-Su 07:30-21:00".

Same for "operator=Inconnu" → If you do not know some information, leave it blank.

Hello and welcome to OSM.

We will try to fix your edit and also the various other edits you committed today, because it looks like you added the same information multiple times, like this shoe shop, which appears now twice on the same location.

OpenStreetMap is a geographical database of the world, and like any proper database, most information is only written once.

L’adresse 497 Brusselsesteenweg est déjà sur le bâtiment et les codes postaux et noms des villes sont calculés automatiquement.

Ne PAS dupliquer les adresses sur les points qui servent à désigner les magasins, entreprises, etc. svp, car ça crée de la corruption des données.

Hello,

You retagged the cafe as a pharmacy, but I think there is an issue here because the pharmacy is the shop on the corner, and it is already on the map.
node/1039101045

I think the former cafe is on the part that has been walled, so it should be probably tagged as vacant, unless you saw something different.

What do you think?

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.