Hello! It was the wrong tag, and I fixed it right away. Thanks for flagging it!

Hello! This is a very old edit from nine years ago. I haven’t used that tag since, and I believe this is an isolated case anyway. I checked with Overpass Turbo and couldn’t find any other instances where I used this tag. I’ll correct it.

Understood

The "still a large number of these tags" turned out to be just 23 buildings with the wrong "has_parts" tag. Next time, please don't make it sound so dramatic. At this rate, you might as well change these by yourself, next time.

I would really appreciate a clearer message (not something vague): in which area do you say such unrefined edits still exist? I have put in significant effort over the past 16 days to remedy the situation, plus additional effort in the last 24 hours.

We could implement new notifications (in JOSM and the iD editor) to warn OSM users about these incorrect tags, so they don't perpetuate the error. For other companies using OSM data, it's simply a matter of excluding certain attributes when they import query results. Otherwise, and to close this discussion: I'll be more careful when processing footprints going forward. I've already managed to remove all the ways that had the "has_parts=false" tag.

All right, I agree with this

I'm starting to notice a pattern: several users who are now very passionate about QA, not just you. I can sense the impact of some third parties.

I understand the argument about international lane-tagging standards, and I'll try to adapt where the carriageway + shoulder actually allow for 2 lanes (one in each direction). But, I'll say it again, it seems absolutely absurd to me for a road that's barely 3 meters wide, gate to gate, to be tagged with lane:forward=1 and lane:backward=1. There simply isn't the physical space for vehicles to travel in both directions on certain stretches. It's reasonable to expect that some of these roads will eventually become one-way, or at best get priority/yield rules, as the local population's rate of motorization increases.
I'll keep having an open and civil dialogue with any OpenStreetMap user, as long as their observations actually make sense.

I agree with the idea of not uploading edits to OpenStreetMap until they're in their final form.

That said, I also find your argument as not valid. It should be the responsibility of third parties to refine the data when they make local copies from OpenStreetMap. Errors can be picked up at any point.

Anyone can make mistakes, and this is the core principle open source was built on: allowing room for mistakes and for peer review, so we can actually learn from each other. The fact that you call it "useless data" tells me you're not really aligned with the principles this platform was founded on. I've been editing OpenStreetMap since 2016. Just 2 years ago, I found a whole cluster of footprints near Marcea, Vâlcea, with no tags whatsoever. None. They sat like that for over a year without a single OSM user raising an alarm because they showed up as errors in their QA tools. Now that OpenStreetMap is getting more attention from third parties and big tech (TomTom, Waze, Apple etc), suddenly everyone's up in arms. Third parties get paid for the stress that, let's say, users like me supposedly cause them by uploading non-conforming edits. I can sense that same kind of stress in your attitude, but let me remind you that I and some other users do all of this voluntarily, purely out of a desire to help our local community. We are not data engineers and we do not pretend to be. Regards.

Hi! I'd recommend taking a look at my more recent activity before jumping to conclusions. Those footprints were all manually edited, almost none of them are still the same as in the initial imported version. The "has_parts" tag is just a placeholder that doesn't render on OpenStreetMap, and the final version of each footprint will be tagged as "building=yes".

The amount of work involved is very high, so I still have hundreds of footprints left to refinem, but that doesn't mean I'm going to leave them as they are.

All right, thanks for your suggestions! I will implement them!

Hi there! This was intentional. I've left them as they are for now, and I'll gradually come back to convert the footprints into buildings. I'm just trying to avoid unnecessary comments from some local users who aren't particularly fond of auto-generated footprints.

Hi there! These are refined Overture building footprints. I thought keeping these tags would be useful for future edits or modifications, but I'm happy to remove them if needed. The ID is obsolete, since I'm modifying the building footprints anyway as part of the refinement process.

Your comments seem to be purely critical, with no consideration for perspectives other than your own. There are routing software systems that factor in the number of lanes when prioritising between possible routes. Tagging a narrow 3-metre road with 2 lanes would be treated the same as a genuine 2-lane, two-way road wider than 4 meters which is clearly misleading. As for the other comments, I was simply following the editing patterns established by more experienced contributors. You are welcome to update the data as you see fit, but please do not reprimand me for edits made two years ago. These are voluntary, unpaid contributions, and I have no intention of spending more time defending my work.

Hello! I appreciate the detailed explanation, but I will respectfully disagree in this specific case.

The roads I tagged as lanes=1 are physically single-lane roads, meaning the carriageway is so narrow that only one vehicle can pass at a time, and opposing traffic must yield or use outside area of the carriageway. This is not a tagging error and it reflects the physical reality on the ground.
You correctly note in your own message that for roads "so narrow that only one direction of traffic can flow at a time", that is precisely the situation I observed and documented.
It is also worth noting that the perception of road width can vary significantly depending on the mode of transport. A road that feels comfortably passable on a bicycle may in practice not allow two motor vehicles - or a car and a truck - to pass each other simultaneously. Many rural tertiary roads in Romania are considerably narrower than what the same classification implies in Western Europe, and tagging them as lanes=2 by default would misrepresent their actual usability for general traffic.
I agree that lanes=1 should never be applied simply because lane markings are absent on an otherwise standard two-lane road and I have not done that. Where the road physically accommodates two passing vehicles simultaneously, I have not changed lanes=2.
I'm happy to discuss specific changesets if you believe a particular road was mistagged. However, a blanket correction of all my lanes=1 tags in the region would itself introduce errors for the genuinely narrow roads. And I will also try to specify the roughly narrow of the carriageway. I did not find any evidence of strictly marking a tertiary road with lane=2 in the OpenStreetMap Wiki documentation

Salutare! Apreciez că te-ai apucat să realiniezi drumurile și să mai adaugi clădiri/anexe de clădiri în zona Hângu, NT - dar te rog nu mai șterge clădirile vechi, deja adăugate. Poți lua legătura cu mine și mă ocup eu să le realiniez/să lucrez la detalii. Mulțumesc!

Greeting! Could you please provide a source for your information?

Salutare! Nu m-aș grăbi să adăugăm această rută nici măcar cu tag-ul „proposed” pentru că sunt șanse mai mari să nu se facă această porțiune din proiect. A se vedea un document oficial în care apar unele concluzii preliminarii ale studiului de pre-fezabilitate - https://www.cdep.ro/interpel/2024/r13280A.pdf

Pentru Tigveni-Râmnicu Vâlcea pare că se poate găsi justificare economică

Salutare! Da, îmi cer scuze, cred că am selectat din dropdown tag-ul greșit

Buona osservazione, grazie per la vigilanza