Hello Andrew,
Your changeset comment here is just "updated". It'd be better if you could use comments that explain in more detail what you're actually edited.
Best Regards,
Andy

Привет,
Вы добавили node/9126630246 сюда, но он выглядит как точная копия way/67029280.
С уважением,
Энди

Hello,
You've added node/9126630246 here, but that looks like an exact duplicate of way/67029280 .
Best Regards,
Andy

Hello,
You've added node/9107771244 here, but is it perhaps the same thing as way/906621443/history ?
Best Regards,
Andy

Bonjour,
Je ne sais pas ce que signifie "corrections pb ID" mais je pense que cela aurait pu casser relation/7640939 en n'en faisant plus un multipolygone. J'ai ajouté un lien sur changeset/111918710 pour le corriger.
Meilleures salutations,
Andy

Hello,
I'm not sure what "corrections pb ID" means but I think that this might have broken relation/7640939 by making it no longer a multipolygon. I've added a link back in at changeset/111918710 to fix it.
Best Regards,
Andy

It may be that at this point the AONB should be defined in terms of the stream or the admin boundary, in which case the "other" bit is wrong and this link isn't needed.

Bits and pieces around York, from survey 31/8/2021, tr8110b

Hmm - maybe I was misremembering what I'd seen at https://en.wikipedia.org/wiki/.eh (note - that's for the ccTLD .eh, _not_ the ISO3166-1:alpha2 code EH).
We'll see what people say at https://en.wikipedia.org/wiki/Talk:ISO_3166-2#Is_EH_code_referring_to_currently_existing_entity%3F_Or_only_to_defunct_country%3F . I'm guessing that the answer will be effectively the same. See also https://www.europarl.europa.eu/doceo/document/E-8-2017-007241_EN.html for another source that takes it as read that "EH" applies to the whole of relation/2559126 , not just relation/5441968 .

If the quality of this data is so poor that the shape, size and even the number of buildings is wrong, then it needs to be removed.
It's much easier to add correct data to OSM if you don't have to remove poor-quality data first.
OSM data is always a process of iteration - but this isn't a first iterative step - it's dumping 1000s of poor-quality objects in OSM that don't correspond to actual buildings.

Thanks - adding "not:" does help to clarify here.
Obviously at some point in the future the situation may change.

re the alleged source of Bing - it doesn't look like it to me. See changeset/111064067 .

> but I NEVER called you such word!

To be clear, what actually happened was I said:

> An attempt to communiciate with the user creating the errors at [1]changeset/110820868 was met with no answer about the source at all, and no promise of a date when the errors would be fixed.

and you replied "False," at the start of a longer answer that still provided no answer about the source at all, and no promise of a date when the errors would be fixed.

To reiterate what I have said elsewhere - we are trying to help you. Please do not assuming that if someone says you have made a mistake that it is a personal attack on you.
If someone asks you a question, do not argue or say incorrectly "I have already answered that" - answer the question.

(s/the/them in first sentence and s/cmmunity/community later - apologies)

To be clear - You questions do not reflect what I an asking the to do.
I am asking them to follow a _process_ as documented at osm.wiki/Import/Guidelines . Do that, and they will need to ask questions of the rest of the OSM cmmunity and we will help.

مهما كان مصدر way/981991478 ، فهو ليس Bing (وهو ما تقترحه علامة المصدر لمجموعة التغييرات هذه). يحتوي Bing على 5 مبانٍ متجاورة ذات شكل مختلف ؛ هذه التغييرات فقط way/981991478 و way/981991481.
سنحتاج إلى معرفة مصدر البيانات للتأكد من أن الترخيص الذي تم توفيرها بموجبه كان متوافقًا مع OSM.

Whatever the source of way/981991478 is it is not Bing (which is what the source tag of this changeset suggests). Bing has 5 adjoined buildings of a different shape; this changeset just way/981991478 and way/981991481 .
We would need to know the source of the data to ensure that the licence under which it was made available was compatible with OSM.

(to reiterate what I've written on the other changeset)
Please, read osm.wiki/Import/Guidelines and discuss what you plan to do before doing any more work. "drawing in an empty layer and uploading" is exactly the wrong way to add data to OSM.
We are trying to help you, but having you continually arguing (and calling me a liar on Ticket#2021092510000174) really does not help us to help you.
As you follow osm.wiki/Import/Guidelines you will see that it says in step 2 "Discuss your plan. Email the OSM community to notify them of your plans, including a link to your wiki page. You can do this with an email to (at a minimum) imports@openstreetmap.org, talk-(your country)@openstreetmap.org, and the OSM group specific to the area directly impacted by the import". Follow the guidelines, including all the steps that you have to perform on the way, and the OSM community globally will help you to achieve your goal.

Most of those questions that you have written above bear no resemblance to any that I have asked you.

What I asked you to do was quite simple - follow osm.wiki/Import/Guidelines . It appears that whoever is doing this work has stopped before line 1 of "prerequisites" as they have clearly failed to "Gain familiarity with the basics of OpenStreetMap, including editing, such as adding details of your neighbourhood."

If they follow that they'll discuss the source used with the wider OSM community, and discuss the source associated with whatever imagery or other sources that they are using.

Given the errors in the re-imported data, we'll likely need to remove this again so please, before any more adding to OSM, ensure that whoever is doing this work follows the procedure properly next time.

For completeness, just running the JOSM validator across a tiny area of this data results in significant errors - way/983064112/history overlaps way/983064115 , for example. In the previous import there were more - way/983046620/history apparently has a road running through it.