Hello,
Was there a problem with corridors inside the building? Why did you remove them? Did anyone ask you to do that?

Hello,

Changing the amenity type is okay but please do not add address tags on places.

We work hard to clean up the address system and avoid duplication inside the database. OSM is a geographical database, a lot of information like this is automatically obtained by querying related objects.

Happy mapping.

Wise choice, indeed.
As you see, my changeset was only there to clean up a problem with the addresses, I merely re-used the tags from the previous user. I will change them now.

What I see in taginfo is that amenity=culture_center has only 87 occurrences in the world, almost exclusively in North-America, whereas the tag I provided to you has 2,208 occurrences.

The convention is not my personal choice, it’s part of the general OSM guidelines. The names of tags and their values should follow British English spelling conventions (for example, "colour" instead of "color," "favour" instead of "favor"). This ensures consistency throughout the map's data and avoids duplication that might arise if different contributors use American or other English variations.

Hello,

I don’t want to be overly critical but please use established tags instead of inventing your own. Also, most apps will disregard tags written in American English, which will render you mapping efforts useless.

The normal tags for such a place are those:

amenity=community_centre + community_centre=cultural_centre

We originally did not merge them because they are referred differently in the park inventory.

Anyway, if you want to create a MP, please remove the "park"-related tags on members, otherwise we end up with database corruption and double tagging.

Hello,

Nice add but if you create a footway, "highway=footway" is enough to have the information.

No need to add "foot=yes" or "motor_vehicle=no", those tags are used for cases when the rules are non-standard. A footway is always open by default to pedestrians and closed to cars, so we don’t have to repeat this all the time. Time saver. ;-)

Hello,

You incorrectly added a tag to an entrance to change the entrance itself into a courthouse.

We fixed this by separating them clearly: one node is the door and one is the courthouse itself, and they can be linked, of course.

Woluwe Shopping is already on the map, with "shop=mall".
relation/12420918

Please do not repeat the tag a second time—you did that by editing one of the buildings; dual tagging corrupts the database.

Your edit has been reverted.

Why did you erase an active bus stop?
node/416868838/history

Hello, Lemmery,

Despite your changeset title claims that you edited roads in Kazakhstan, you also made several edits around New York (redrawing a sidewalk, redrawing a house entirely, moving landuse areas…).

It is strongly advised to upload such changes separately; this will also make it easier for you to provide more accurate descriptions of your changes upon uploading.
osm.wiki/Changeset#Geographical_size_of_changesets

Happy mapping.

Votre modification comporte un grand nombre d’erreurs et a été nettoyée.

Votre modification comporte un grand nombre d’erreurs et a été nettoyée.

Hello,
Thanks for the survey.
Next time, please do not add compound values with an invalid format: "836-838" is not correct for OSM. In general, addresses are better as floating nodes, especially like here with several numbers within the same building. I will fix it.

Yes, Netherlands has a different convention about this, we know.

Hello Comino,

I spotted your latest changes and I wish to kindly warn you there might be some misunderstanding about OSM works.

You probably believe you are helping others by repeating addresses on some places, but this is not helpful. On the contrary, it might be destructive, especially when data creates a mismatch.

OSM is a geographical database and addresses are automatically computed by inheritance or proximity. In many cases, we even added relations to explicitely link a place to its address and/or entrance door. Here is an example for Dolle Mol.
relation/16276596
As for post codes and city names, we do not fill them in Belgium, because they are automatically obtained, respectively from postal_code boundary relations and from administtrative boundary relations.

Don’t spend more time duplicating available information. In case you want to continue using the simple online editor (iD), you may safely ignore the text boxes they show for addresses.

I will repair the data here. Have a nice day.

Hello,

If a path is private, the recommended way is to add "access=private" to it.

Despite routing engines will behave in the same way, "access=no" is a slightly different thing (we use it for places that are *really* restricted, such as military areas and more).

More importantly: to bar access to a path or road, just use "access=private" and do not bother with the other categories of users. I see you use the online editor. In that case, it will be the first dropdown list: Allowed access > All: private.

It is not necessary to fill the values for bicycles, pedestrians, cars, horses… to say the same thing. When we set "access=private" it goes for everyone at once. The other check boxes are only there for special cases, e.g. "forbidden to all but cyclists may pass through".

Hope this helps. I will fix this one. Happy mapping!

Hello,

I see you wanted a review. Here it is.

What I see here is that you added "access=private" on an existing path. This will effectively prevent routing engines from operating here. Your changeset description is very clear too, so we can very quickly see that you did "the right thing", because the changes in the map correctly reflect what you said you wanted to do.

So, this is a good changeset. Well done! 👍️

Hello,

We do not repeat post codes and city names on addresses in Belgium.

The entire country is covered by postal_code boundary relations, e.g. every point within this area is automatically recognised as having post code 1750.
relation/3942878

The zone system is less error-prone than encouraging every mapper to fill all the fields in the iD editor and ending up with lots of faulty data.

If you don’t mind, I will erase the unnecessary tags on the address of this building.

Hello jbieber,

It looks like you are now adding POI on top of existing POI. This makes map really ugly and messy and can create confusion. Double tagging is pointless, and if you a different POI than the one that already exists, it will require some investigation, which takes valuable time for other mappers.

Here is an example: you added a gift shop named "London souvenirs" (node/12309459372) inside a building which was already tagged as being a gift shop named "London Souvenirs" (way/955830226)

Same situation for the other shops you have been adding in this changeset + the other ones from the last hours. Are you using a broken app that does not warn you about such obvious situations? Can you please consider checking the existing data and updating it instead of creating new data on top?

Again, we’d also appreciate that you could write proper changeset titles when you add data to the production database.
osm.wiki/Good_changeset_comments

Thanks in advance. Happy mapping to you!