Hello,

I think there is a problem with this edit.

Using a mobile app is not a good idea because you probably miss all the details here. Another mapper and myself had cared to map all the containers as accurately as possible in the last months, with their own reference number. There is usually a line of 4 containers next to each other, each with a number and a dedicated type of material.

It looks like you changed the values and put multiple values on containers.

For instance, this one, labelled 5008, is for plastic bottles. Your edit changed this to make it like a container that also accepts food waste, green waste and more.
node/7744853515/history
(Probably a confusion with another container.)

Did they really reorganise all the containers in this area so that each box now accepts virtually any garbage?

Can I suggest you go to the settings of your StreetComplete app. There is a list of quests. You can tick off the one about recycling containers, so that it won’t bother you again with those.

Thanks.

It does not come from a tool. It’s just humans with their own eyes. But basically any validating software that is aware of language separators (e.g. Osmose) is expected to complain here and I doubt they will make an exception for bus routes.

Merci pour la vérification.
Le tag est "oneway:bicycle=no"… et je vois que vous avez déjà tout corrigé, donc c'est parfait à présent.

Sense unique pour tous les utilisateurs ou y a-t-il des exceptions (cyclistes, speed pedelecs…) ? Est-ce qu'il y a des panneaux additionnels (M2 ou autre) ?

OK, nice try.

A suggestion here: please avoid doing such work with the iD editor, because edits in iD cause major corruption to route relations. I’ve just had to fix the cycle relation, where the ways on the bridge were added at the bottom of the list and without any direction role. You can always ask for help or open a note to request complicated tasks.

Also, can you please check the following invalid turn relation: relation/19375922 The "via" node is missing.

Hello,

"Bus 123: Gare du Midi - Zuidstation → Waterloo Berlaymont" is parsed as a multilingual text string because of the " - " separator in it… and it is clearly invalid.

Dealing with names in multilingual areas has been a long and complicated discussion. From what I see, current usage is to stick to using "Bruxelles-Midi" inside the "name" tag of all TEC routes, and "Brussel Zuid" for De Lijn. Only "to" and "from" names are set to match the platform name.

The fix in the "from" tag is correct, changeset/164953866 was faulty.

Hello,

Thanks for adding a missing shop here.

There is a problem with the way you are adding data to the map.

First, the phone numbers in OSM must always follow the international format, +32 470 XX XX XX, and not 0470…

Also, the container building already has a correct address:
way/680698527
Therefore you should not duplicate the address on the bakery itself. If youdo this, that corrupts the addressing system and force us to hunt for address duplicates.

I did not react on your first edits but since you are repeatedly making the same mistakes I felt I had to tell you, so that you can do better contributions.

Happy mapping.

Hello,

Adding or fixing one-way streets is okay.

However, on recent Mapillary pictures, I see that there are exemptions for cyclists and moped-A drivers, like here:
https://www.mapillary.com/app/?pKey=740469918215724

Yet, you mapped this street is being strictly one-way for *everyone*:
way/126494291

Your edit will now block cycle routing.

Have all those M3-signs been removed in your area or is it just a mistake? Perhaps you forgot to set the additional tags. I prefer asking before we fix this.

Please reply below this message. Thanks in advance.

Hello,

Thanks for "adding details".

Here are two comments about your latest changes on OSM.

1. Do not add addresses to defibrillators, this creates unwanted data duplication within the database. Defibrillators are devices, they are not buildings on their own.

2. You pushed 14 different changesets with an identical title: "Details aangevuld". Your fellow mappers would be grateful to you if you could please start writing proper descriptions whenever you change something.
osm.wiki/Good_changeset_comments

Have a nice day.

Your edit unfortunately damaged some building outlines.

Please do not trace buildings from (distorted) aerial imagery.

In Belgium, buildings should follow numerical imagery provided by governments. For Wallonia, the available layer is SPW(allonie) PICC numerical imagery. Please use only this one.

Happy mapping!

Hello,

Thanks for adding missing houses.

However, I want to inform you that we never trace building structures from aerial imagery in Belgium.

Governments provide detailed numerical imagery showing the correct outline of every building in the country. We often get new users who want to "help" and retrace existing buildings to match… aerial imagery. Those images show a distorted view of the world and are not suitable for buildings.

I wanted to let you know this, so that we don’t have this mistake again.

We fixed your various edits of today.

Hello, rmammouth.

On this picture, the surface of the road is definitely made of setts and not of asphalt.
https://www.mapillary.com/app/?pKey=200296993116589

Why did you change it?

Did they recently rearrange the road here?

Thanks for the information.
I had planned to relocate the venue in September but let’s do it now, then.

Just one thing, please never add fake addresses to places, that just corrupts the addressing system. If the point is located in Anderlecht, it should never get an address as if it was elsewhere in the city. The correct way to map is to move the point to its new location (without typing any address).

Don’t worry, everything has been fixed here.

Hello,

This is a small house and there is already an active restaurant here: node/2403723652

Are there 2 restaurants in this building? I suspect the one you tried to add today replaces the existing one.

Can you please confirm what you saw here?

Hello,

It would have been advisable to move existing objects rather than your "destroy old + create new" technique (e.g. Andorra, Comores, Angola…), which also left invalid 1-member relations. Keeping the history of POI is a good practice in OSM.

I will try to repair the mistakes here.

Thanks for drawing new cycle tracks—which we will assume have been built very recently.

Please try to spend some time learning how to edit OSM properly before engaging in massive redrawings of infrastructure. I am afraid you are doing it incorrectly: you attached a cycle track to a boundary way instead of a road, and your new cycle track ends on a sidewalk with no accessible connectors, therefore it creates a broken routing grid.

I would be happy to talk it with you and help you improve this.

Hello,

Thanks and welcome to OSM.

We have two questions about this:

1. You claim that the one-way street was introduced in 2022. On this picture taken in July 2024, there is no indication about one-way signs here:
https://www.mapillary.com/app/?pKey=1006722197572097

2. You added a restriction for ALL modes of transport. This is very rare. The usual rule in Brussels is that when a street becomes one-way for motor vehicles, there are white signs allowing cyclists to use it in both directions (M2) or sometimes speed pedelecs too (M11).
Can you please tell us if such white signs are present here?
OSM is used to navigate ALL modes of transports, not just cars, so this is important.

Thanks in advance for your reply under this message.

I reverted the changeset here: changeset/168579807

All the relations elsewhere in the world were restored to their previous state.

@Flap Slimy Outward: your work to create road relations in your area was preserved too, in most cases through new relations.

The comment by @limes11 is correct.

To create new objects in OSM, you should give them *negative* numbers and the API will create them for you. On the contrary, if you use *positive* numbers, you will ask the API to re-use an existing object having that number. That created the mess here, because your upload requested to edit several relations that were already in use and move them to Colorado.

⚠️ It looks like this changeset re-used several existing relations all over the world to transform them into relations for roads in Colorado.

Take this one, which was a multipolygon in London (UK) up to version #5: relation/332/history

Or this one was a river in Iraq up to version #11: relation/147/history

source=Google Maps, really?

Please do not use Gmaps as a source for your OpenStreetMap edits, this is not allowed.