@Bear-in-a-box: What is the sense of writing such a changeset comment here? I don’t see anything wrong with this changeset.

You seem willing to add "animal=horse_walker" to several buildings, as you did later here: way/226239974/history

While this is a good improvement, I still do not understand the point in criticizing this changeset here, which was exclusively focused on refining the outline of landuse areas here. This is not the changeset that created the building, and even if it was, no-one should be blamed for not knowing the inner details of every building.

Hello,

Thanks for reviewing the temporary situation here.

Setting "motor_vehicle=no" is enough. There is no need to add "foot=yes" and "bicycle=yes" explicitely when no tag forbids those means of transport, those tags just create confusion.
Don’t bother to fix this one, but please bear this in mind to improve your further edits.

Have a nice day.

This changeset was 18 months ago, I do not recall the details for every node, but this looks like a mistake.
https://www.mapillary.com/app/?pKey=2110048189479248
I fixed it, thanks.

Hello,

I had to revert your change for one of the crossings.
https://www.mapillary.com/app/?pKey=731655736021627
Please make sure to study the situation carefully. As local mappers, we spend a lot of time tagging crossings, and it is fairly disappointing to see people undoing our work and introducing mistakes. Only the crossing between the footway and the road is regulated with traffic signals; the crossing between the footway and the cycle track is not.
We understand that non-local mappers might be confused if they are not familiar with traffic in Belgium or traffic laws, but I can guarantee this is the real situation.

I restored the previous situation, with an unmarked crossing without traffic signals for node/6982830097

@Eleutherio: There is no intention to be rude, apologies if the reaction made you feel this way.

Every useful contribution is welcome, of course.

Happy mapping.

Hello,

The changeset description does not mention it but, apart from roads and landuse areas, you edited no less than 1,274 trees. Congrats for that big survey, if any.

One tree in the changeset is near Antwerp (node/2053260384), in the north of the country whereas the rest of the changeset is in Genappe, in the south. We would have appreciated to see this as separate changesets.

Have a nice day.

Hello,

Can you please avoid uploading edits spanning over several countries.

Also, it looks like you are repeatedly copying the same title for every of your changesets. As far I can see, your latest 350 changesets have the same description, despite you are editing different stuff each time. There is no need to repeat the name of your employer twice per changeset, we can already see this in your profile description; what we want to know is why/what you edited and what issues you are trying to solve, specifically.

We would be grateful if you could please improve this. Here is a useful page to read.
osm.wiki/Good_changeset_comments

Thanks in advance.

Please do not duplicate addresses, OSM works with address inheritance.
I will fix this.

Hello.
Please verify that objects are not on the map before adding them.
The Egg has been on the map since 2017.
way/524776763
Your change has been reverted.

Hello.

Please use the appropriate text box to provide more details about *what* you are doing.

Do not keep the "Fixed with Osmose" default message for all your changesets, that makes no sense. Edit it when you start mapping, to communicate explicitely what kind of issue you were trying to address.

It is important because Osmose contains a large number of false positive warnings outside France. It is generally felt that new users do not possess the knowledge to know which Osmose warnings are relevant and which ones should be ignored.

For what I see here, you mechanically changed "€" into "EUR" on random POI. This kind of change is okay and goes along with wiki recommendations.

Hello,

opening_hours=24/7 (opening%20hours=24/7?) is a legitimate tag, and most apps can successfully parse it.
uselang=en

If you mechanically change all those values into "Mo-Su 00:00-24:00", despite it is supposed to mean the same thing, it will still get flagged by several QA apps, which will assume that the value is missing during public holidays or that there *is* a closure every day. I wouldn’t recommend this kind of edits.

Please create extra nodes if you want to add a business. Do not steal UrbIS address points to replace them with your own customers, at the expense of proper rendering of useful information for cities. And do not repeat postcodes and city names, this is bad practice. Also, the name is only the name, not a long name including the business type.

Your edit has been redone: Beheat is here.
node/13361748733

Hello.

I am afraid parcel lockers do not have *names*.

You might find the "BBOX LOCKER WILDERSPORTCOMPLE" text string in their dataset or on their website but one should assume that it should be copied to OSM. Should they have a name at all, one would certainly need to dispense with the operator’s name and the object type, and use the full name with correct case, i.e. presumably "Wildersportcomplex".

Thanks in advance.

Hello,

It looks like you redrew some buildings in Cranfield (England), drew a couple of structures in the north-east of Scotland and added a trail in North Korea.

As a consequence, your change is now showing as a huge bounding box spreading from the UK to Asia. And the "added detail" changeset title won’t help anyone. You used the same description to every single of your latest 100 uploads, even though each one of them seems to do something different.

Would you please consider uploading changes in one area before moving on to another area of the map.
osm.wiki/Changeset#Geographical_size_of_changesets
And osm.wiki/Good_changeset_comments

Thanks in advance.

Hello,

I saw you requested a review for this changeset.

The edit looks good. But since you have traced on aerial imagery, I imagine that you aware that you did not draw the real outline of the building but only a probable outline, which will have to be fixed later. It is all right here because the PICC basemap does not show the new buildings yet. It’s a good idea to have the building anyway.

If you experience situations like this, I recommend filling the "fixme" tag on every such building. This field will raise an alert for other mappers; you can simply indicate that the building was traced on aerial imagery.

This would be useful, because we can easily filter all the "fixme" objects in any area, once the new version of PICC is released. That will be much faster than looking at every single building to see which one does not match.

Hope this helps.

Hello,

node/349277440/history "La boite aux lettres rouge de bpost n'existe plus, donc j'ai réutilisé le POI pour un arbre"

That looks smarts but… it is not recommended. Only re-use points when they stay within the same category (it is okay when a hairdresser’s shop closes and becomes a newsagent or even a restaurant, because all of them are businesses, and because they use the same space and will never be all there at the same time). However, since post boxes can not become trees, the best approach here will be to delete the post box entirely and map the tree as a new node.

No need to fix it here anymore, but good to know for future edits. ;-)

Pearle is already on the map, you are adding duplicate data.
node/3267487254
I’ll revert this.

Thanks for this.

If the new bakery replaces the former one on the same spot, the best way to map this is to change the tags on the existing object instead of creating a new one.

Tagging a shop as disused is good practice only when a shop is temporarily vacant.

Fortunately, your changeset description was very clear, and it was easy to fix. :-)

Hello,

The uic_ref tag is already set on the station node here: node/17401552

It looks like you duplicated this unique code to every single of the 21 stop positions here. We feel this is not necessary, since all those stop positions nodes are already bundled with the station node inside the stop_area relation here (relation/6261364).

Repeating a unique reference code to multiple objects isn’t good practice. This not only increases the risk of errors but also complicates data maintenance, making it harder to ensure accuracy. That is why it is better to create relationships between objects. This approach makes the database more efficient, easier to update, and reduces the chances of errors.

Is there really a park named "Lowfield Garden" here?

On aerial imagery I see houses here.

Either you are trying to map a private garden—and in that case it should definitely not be mapped as a public park—or you are testing how to edit… or just trying to prank us.

Would you please explain the situation here.