There has been some testing to improve aeroways for the standard carto.
https://github.com/gravitystorm/openstreetmap-carto/pull/4346
This experiment didn't contain the holding position though.

Lines have direction as well like with a retaining wall, unfortunatly at the time of writing something like this is missing for the holding position tag.

Thanks for keeping in mind the Github, just like you I just try to improve the database we call OpenStreetMap :-)
It would be a bit pointless to replace people their lines with points when lines themselves are allowed or even preferred according to the wiki

-E de Wit

ID errors are indicative, certainly not wrong in all cases.
It's possible that ID errors lag behind, are incomplete or contain a bug.

I'm no aeroway expert by any means, but according to the wiki under 'How to Map' mapping this with a line is allowed or even preferred.

It's probably less time consuming to follow the wiki and suggest this as a validation bug on the ID github without replacing everybody their lines to nodes.

Why remove all the 'aeroway=holding_position' across the world?
As far is I know this is a valid tag with proper documentation.
This is damaging the map.

wiki.openstreetmap.org/wiki/Tag:aeroway=holding%20position

-E de Wit

Alleen de natura2000 contouren zijn niet onderhevig aan interpretatie. Deze zijn vastgesteld en volgen in heel veel gevallen niet de exacte kustlijn. Dat dit er rommelig uit ziet is irrelevant en mappen voor de renderer.
Bij periodieke controle van de natura2000 vlakken was dit ook gewoon weer hersteld naar de vooraf vastgelegde contouren.
Ze liggen om deze reden dan ook op enorm veel plekken los van andere contouren.
Deze zijn allemaal keurig in kaart gebracht door AdVerburg in onder andere deze changeset:
changeset/79078818

Ik heb alleen het natura2000 hersteld naar de door AdVerburg aangebrachte contouren:
https://resultmaps.neis-one.org/osm-change-viz?c=124149235

Bronnen:
https://www.pdok.nl/introductie/-/article/beschermde-gebieden-natura2000-inspire-geharmoniseerd-
https://app.pdok.nl/viewer/

Toestemming gebruik:
osm.wiki/NL:Permissions

Zie reactie:
https://forum.openstreetmap.org/viewtopic.php?pid=868318#p868318

-You removed all my -not- automated details, i'd say removing my work to 'simplify' the map without consulting the prior mapper is very disrespectful.
I agree vandalism is too big of a word, but is suddenly see all my work disappear in name of simplification.

This is not how you treat other mappers.

West aan Zee by the way is a recognized hamlet (buurtschap) within The Netherlands with white signs when you enter.
Within this hamlet there are individual shalets owned by various operators.

Also the 'Duinen Terschelling' is a Natura2000 region with known boundaries. These are now incorrect around West aan Zee as well.

Why remove all details within West aan Zee? This greatly decreases quality and would be considered vandalism.

-E de Wit

Aanvulling:
In de Dragtster courant, 08-08-1878, 'binnen- en buitenlandsch nieuws' wordt zowel het aanvoeren van koolzaad benoemd als de observatie dat het jaar ervoor (1877) er nog water in het meer stond, vandaar start_date=1878

Hoi,

Welkom!
Eggie heeft mij gevraagd even mee te kijken als lokale (Leeuwarden) mapper.
Bij vragen ben je uiteraard welkom om een berichtje te sturen.

Deze weg is niet erg duidelijk aangegeven, maar volgens mij staat hij er goed in zo.

-E de Wit

Top! Dan heb ik bij deze de woningen geïmporteerd uit de BAG in changeset:
changeset/123163016

Removed the empty relation in changeset:
changeset/123162783

And provided feedback in order to improve JOSM:
https://josm.openstreetmap.de/ticket/21825#comment:74

Ik zal niet zo snel andermans werk ongedaan maken :-)

Is men trouwens al begonnen met de bouw van de huizen schuin tegenover de Coop en langs de Trije Keningenwei?

Update: with some reverter plug-in trickery I'm able to remove said relation without damaging my changeset.

I've not done so (yet) because this case might require some further investigation in order to fix JOSM.

I updated to 'josm-tested.jar (version 18463' and have the same result.
This version didn't give me a warning after validation and the empty relation doesn't appear in the relations list.

Hi,

Strange, in JOSM version 18427 the empty relation isn't even in the list with loaded relations (let alone as a validation error).
The relation can be removed here when it appears with 0 members.

I'll get the new JOSM executalbe and see if that fixes it. I'm usually lagging a little bit behind to keep the Dutch BAG plug-in working.

-E de Wit

Houd er rekening mee dat het adres zelf erg vaak nog wel in gebruik is wanneer iemand zijn winkel sluit.
Zoals voor de toekomstige bewoner / winkeleigenaar.

Ik heb de adressen weer teruggezet met changeset:
changeset/123130902

-E de Wit

Heb ik geen problemen mee, effectief hetzelfde resultaat als emergency=yes.
De borden zullen wel weg gehaald worden wanneer men daar serieus met de infrastructuur aan de gang gaat.

Bijna identieke situatie die is opgelost met emergency=yes:
www.openstreetmap.org/way/814298568

hgv=no / bus=no doet volgens mij ook moeilijk, is opgelost met emergency=yes:
www.openstreetmap.org/way/343266385

Wellicht een goed moment om het wat inzichtelijker te krijgen, ook voor
o.a. de VRFR medemappers.
Over de tag emergency=yes valt ook wel het e.e.a. te zeggen, gezien dit voor overkoepelende hulpdiensten is en niet alleen brandweer.
Omdat ze wel de grootste wagens gebruiken loopt emergency=yes wel los, maar emergency=no gaat problemen geven mocht bijv. de ambulance hier in de toekomst ook gebruik van willen maken.

Ik was in de veronderstelling dat het de Boksumerdyk 4 / nieuwbouw
aan de Broukade betrof, vandaar de gelinkte wegen.

Dit moet haast wel de door Jeroenhoek aangegeven beperkingen van breedte en asdruk zijn.

Pragmatisch gezien stel ik voor om emergency=yes op deze weg te zetten om de geldende beperkingen te overschrijven voor hulpdiensten.