Wellicht kun je meer in detail treden wat ik verkeerd gedaan heb.
Ik neem aan dat je de parkeergarage aan de Markt bedoelt. Daar is volgens mij amper iets veranderd. Paar tags toegevoegd en van het pand erboven veranderd van building:part naar building, maar zie het probleem eigenlijk niet zo 123.

En we mappen niet enkel voor de standaard kaart en hoe mooi er er daar uitziet toch? Er zijn meerdere datagebruikers dan de kaart op osm.org

Het adres op de plek waar het object zich ook daadwerkelijk bevind lijkt mij geen probleem voor de osm.

Gaan we dan alle adressen weggooien? We taggen toch niet voor de renderer?
Iemand mocht er eens naar willen navigeren...

Onzichtbaar refereerde naar het bouwsel dat onder het aquaduct ligt. Het adres kan niet verborgen worden...

Van de week had JOSM nogal wat kuren bij het uploaden. Mogelijk dat daarvoor bij het updaten van de contouren (heb nogal wat gebouwen die af en ingemeten zijn van construction afgehaald) wat losse nodes zijn achtergebleven.
Heb eea opgespoord met Overpass turbo query (deze keek niet naar relaties, dus deze handmatig uitgezonderd) en deze opgeschoond.

fixed

Hi, that plot thing was something we discussed about on the forum 2 years ago and I tried it out on this area.
Now changed to landuse=static_caravan which is what we use for an plot designated by the municipality where one may place a static_caravan (and pay a yearly service fee to the park owner).
These areas are not for tents, caravans, campers or things like that, so definately not a camp_site.

Klopt, JOSM deed nogal vreemd bij de upload en pikte de ingevulde comment/source niet op.

Why did you create a node called "Middelharnis-Sommelsdijk"?

These are 2 separate places that, I don't see any reason for creating a combined node.
Also I don't remember hearing these 2 being called this way together: it's always Middelharnis or Sommelsdijk depending on which part you refer to.

Just happened I was notified again about this, and this changeset was already reverted partially: osm.org/changeset/24789993

Found some discussion with another user explaining that objects that already had a substation tag were excluded, so probably double tagging of the objects affected, but don't know exactly.

De building:parts lijkt ie niet te willen renderen, dus toch maar de :part weggehaald.

Beetje praktisch taggen dus, al zal het constructie technisch wel 1 pand zijn ;)

Hier iets te enthousiast geweest.
Heb een gedeeltelijke restore gedaan en de individuele huizen als building:part teruggezet met als oude referentie ref:bag:old naar de het op oude BAG nummer.
Zie changeset https://overpass-api.de/achavi/?changeset=61634559
Al zie ik dat JOSM ver buiten de selectie voor restore ook nog wat random restores heeft gedaan... vreemd.

I don't think reverting a 4 year old changeset is going to be easy.
Think it was an autofix in JOSM back then and just did the entire country. Don't think I ever looked up the wiki to notice the warning. Maybe not the best decision, but that's what happened...

Zal gefaald zijn omdat de heen en terugweg nu over een eigen aparte way gaan. Was op andere dingen gefocused en was me niet opgevallen dat busroutes lagen.
Bedankt voor het fixen.

Tsja, zou er zelf eerder een type=site van maken, maar dat rendert niet, dus vandaar dat het toch vaak een multi is om de naam op de kaart te krijgen. En als je dan het schoolterrein en het pand de naam wilt geven en dan volgens one feature, one tag het in een relatie stopt krijg je dit soort dingen. En inderdaad geerfd van voorgangers.
Zou nog eens naar de school wiki kunnen kijken hoe dit meestal gedaan wordt. In GB hadden ze een tijdje terug een project om alle scholen netjes te taggen. Daar valt wellicht inspiratie te halen.

Vlug afgehandeld door gemeente:
Bedankt voor uw terugmelding.

In de BAG is het volgende gewijzigd:

Status van pand 1714100000726928 is gewijzigd in: niet gerealiseerd pand. Bij ander pand 1714100000787275 is het bouwjaar 2004 gewijzigd in 1997.

Uw terugmelding is hierbij afgehandeld.

Bij de maandelijkse verwerking van verschillen verwerk ik alle JOSM conflicten, dus deze had naar boven moeten komen.
In ieder geval zouden in BAG geen 2 panden op elkaar moeten liggen.
Heb een terugmelding gedaan om dit issue op te laten lossen, waardoor het in in juni niet verkeerd zou moeten gaan: https://bagviewer.kadaster.nl/lvbag/bag-viewer/index.html#?searchQuery=1714100000726928&resultOffset=0&objectId=1714100000787275&objectId=1714100000726928&geometry.x=15376.41789375&geometry.y=370805.99545625&zoomlevel=7&detailsObjectId=

TU terrein... Pfff dat was een crime om bij te werken. Ben daar wel een tijdje mee bezig geweest, maar sommige panden zijn daar tot op verdieping en raamniveau `gemicromapped`.
Dan vergaat je de lust op een gegeven moment om al die dingen mee uit te lijnen...

Dat is gedaan via de BAG progress website (bij jou bekend). Daar kun je een json van een woonplaats, gemeente en zelfs provincie downloaden van ontbrekende panden/adressen. Daarna via de Remote Control optie rechts daarvan de ontbrekende gebieden inladen en validaties wegwerken. Denk dat ik in Veenendaal ook de verwijderde JSON heb gepakt want erg veel issues en dan kunnen er gaten vallen als shapes ook veranderd zijn. Is inmiddels weer gecorrigeerd. Dank voor de oplettendheid.
Verdere vragen/discussie aub via het BAG forum.