Hello,
Thanks for this but for a short-distance move, it is better to *move* the existing node instead of destroying one and recreating a new one beside. This will preserve the history of objects, which is good practice in OSM.
I will fix this one.

This changeset only cared to realign the polygon. This is routine maintenance work, as people using the online iD editor are often unaware of this when drawing. No information was lost: 5 nodes were touched, with a move of respectively 3, 7, 25, 28, and 28 cm.
OSM mappers are fully aware that UrbIS geometries are sometimes wrong or outdated, and that is why these cases can be documented on the object themselves, if necessary. That would prevent misunderstandings like here.

There is a 36-meter long elevated part stretching across the entire intersection. This is a fairly common case, and we map traffic_calming=table on the way itself rather than on a random node. This is what the changeset is about.
Here is a Mapillary pictures that shows the infrastructure.
https://www.mapillary.com/app/?pKey=823085459041912

Yes, it’s better to create separate associatedStreet relations for each postcode/city combination. I’ve just added the missing relation to fix the issue (btw, most streets were in the wrong relation before this changeset).

OK, thanks. I found it on Mapillary pictures we took a few months ago, it’s fixed now.

OK, merci.

@VLD549: Had you inspected the history of the object prior to writing your comment, you might have noticed that the Dutch spelling in two words was introduced in version #11 of the object several years ago, and by another mapper, here: changeset/50993775

What I see here is that luschi only applied a minor fix about the "*" sign at the end but this is unrelated to the choice of writing it in one or two words.

Hello,

Pardon my curiosity but where is this ticket machine supposed to be?

You added "indoor=yes" + "level=0". The location where you put it does not match any known location outside. Should that machine be inside the metro station (indoor=yes), it would not be at level 0.

Can you please give a few more details, so that we can fix the tags and/or relocate the node?

Hello and welcome to OSM.

I have had a look at your latest contributions. It looks like you are adding parking entrances in Prague.
This is a welcomed enhancement but there is a technical problem here.

The purpose of relations in OSM is to group multiple objects together.
But 1-member relations are invalid: relation/17804037

To be fair, site relations are an advanced skill in OSM but if you want to make it right, here is the recommended way:
* Create one node with amenity=parking_entrance (that is what you already do).
* Create one node with amenity=parking (it will be rendered as a blue P on most maps). Tags with the name, price, opening hours, etc. go to this object.
* Use the site relation to join them.

I hope this helps.

Hello,

I regret to inform you that we undid your contribution here.

We do *not* add postcodes and city names on addresses in Belgium. In the past years, we endeavoured to draw all the postcode areas accurately, so that this information could easily be calculated (this is called "reverse geocoding"). Some countries still use the old system where information is repeated on all possible objects but we try to avoid this here.

Better luck next time. ;-)

Hello,

One-way for *everyone* or are there M2 signs to allow bicycles against traffic?

I am asking because your change set the street as one-way for everyone, this is very uncommon in Brussels.

Hello,

Speed tables should better not be tagged as nodes on the road. Do this only to mark a small speed table on the intersection point itself.

For a long speed table spanning across the entire intersection, it is better to split the road on the two limits of the elevated part, and then add the "traffic_calming=speed_table" tag on the road itself. That makes it easier for route navigation and also allows to calculate statistics about infrastructure more correctly (one speed table here, not two).

Hope this helps.

Next time, please make it two separate changesets.
osm.wiki/Changeset#Geographical_size_of_changesets

Hello,

Please make sure to write proper titles for the changes you upload to the database.

OSM is based on peer review and when a relatively new user merely titles "Update" on various changes, it raises a legitimate level of suspicion.

An interesting reading before doing more changesets.
osm.wiki/Good_changeset_comments

Thanks for your cooperation.

Hello,

Please do not retrace building outlines on (distorted) aerial imagery.

Only UrbisAdm for buildings in Brussels, thanks.

Please make sure to add the stops on the correct position in the route relation. Adding a bulk of stops at the end breaks the relation.

Yes, this is an old comment from one year ago.
Don’t worry, I had applied a fix, i.e. make sure that the fuel station and the store are two separate objects in OSM.

There are many apps like StreetComplete that will ask mappers who are passing by if they can add or update the opening hours, so you don’t have to worry anymore about this one. But thanks for the reply anyway. ;-)

Hello,

Normally, the parking entrance on this side was expected to be closed for good, and they installed a full line of bollards near the entrance to bar the access. The last picture we have, taken earlier this year, shows them.
https://www.mapillary.com/app/?pKey=397529935976786

Do I understand that (at least part of) the line of bollards has been removed and that motor vehicles can now enter the site from here? You saw that with your own eyes, didn’t you?

Thanks in advance.

You are welcome, thanks.

This place was added one month ago (node/11895344619), we removed the one you added today, which was a duplicate.
To avoid this problem, please make sure to always have a fresh copy of the dataset before editing.

In OsmAnd~, you can use Maps & Resources > Updates > Live updates > Belgium > Update now, which will update your local copy of the map data. :-)