May I ask, what the source for the deletion of this path is? In satellite aerial imagery it seems likely that there is a (somewhat abandoned, but we're in the zone here after all) path here.

Wat vreemd, dat is ergens tijdens het uploadproces misgelopen denk ik. Bedankt voor het opmerken en corrigeren!

Please don't use Bing aerial imagery in the Netherlands. Use the PDOK aerial imagery, this imagery is updated every summer and has a resolution of 25cm per pixel. You re-added outdated things that have been removed by mappers before you, and the things that you added are way off on the positioning.

Please don't use Esri World Imagery in the vicinity of the Netherlands or in the Netherlands itself. In the Netherlands and near the Dutch border there is the "PDOK aerial imagery" source which is updated every summer, with a resolution of 25cm/pixel. This imagery layer is available in the imagery selection list in the iD editor.

Ik repareer het zelf wel even, heb van te voren al het een en ander klaargezet, gebruikt het ook meteen de goede transformatie in tegenstelling tot die vorige versie.
Bedankt voor het goede overleg.

Zou u alstublieft een gesloopt pand dat nog wel in de BAG staat op OSM niet simpelweg willen verwijderen, maar in plaats van te verwijderen de (primaire) tag, building=yes te veranderen naar demolished:building=yes zoals omschreven op de wiki pagina osm.wiki/Key:demolished:building.
Dit voorkomt dat een 'BAGgeraar' als ik perongeluk de panden opnieuw in OSM importeert, omdat wij anders niet zien dat iemand *bewust* deze panden heeft verwijderd.
Wanneer deze demolished:building=yes panden ook uit de BAG en recente luchtfoto's zijn verdwenen komt iemand ze wel een keer tegen om ze definitief op te ruimen.

Alvast bedankt,
Martijn

Die bedoel ik inderdaad.
Wellicht heb je het over het hoofd gezien, maar het hele spulletje hing aan elkaar d.m.v. een type=building relation volgens Simple 3D buildings, zoals omschreven op de wiki.
Verder waren voor backwards compatibility met 'domme' renderers als osm-carto de 'twee' panden (die met de HEMA er in en die met de Kruidvat, onder andere) bovengronds - zoals voorgeschreven door de wiki - getagged als building=yes, in dit geval als multipolygon.
Daarom hadden die twee omtrekken op zichzelf slechts een building:part tag die je in deze changeset hebt verwijderd, ze waren een building=yes d.m.v. de building multipolygon relatie, en elk een building:part in de type=building relation.

Klopt overigens wel dat er wat veranderd is waardoor de BAG update wel nodig was, aan de noordoost kant is de gevel licht aangepast, en verder heb ik indertijd van een verkeerde transformatie gebruik gemaakt voor de BGT vector data die hier is gebruikt.

Om samen te vatten was de situatie voorheen dus als volgt:
er waren twee pandgeometrieën uit de BGT die elk een tag building:part=yes hadden, samen in een multipolygon building=yes zaten, en allebei ook een onderdeel waren van de type=building relatie.

De maximale omtrek van het pand zoals die in de BAG zit had een layer=-1 tag, een location=underground en als primaire tag building:part=yes, onderdeel van de type=building relatie.

In feite was er dus in OSM een 3D pand waarvan twee van elkaar gescheiden delen bovengronds en een deel ondergronds.

In deze changeset heb je het ondergrondse vlak aangegeven als parkeergarage i.p.v. building:part, heb je de twee bovengrondse building:part's omgetagd naar twee zelfstandige building=yes, de building=yes multipolygon relatie verwijderd, en de type=building relatie verwijderd.

Indertijd heb ik het ondergrondse geheel niet aangegeven als parkeergarage omdat ik er niet zeker van ben dat die hele omtrek ook daadwerkelijk parkeergarage is en er niks anders bij zit, maar om dat echt vast te stellen heb je bouwtekeningen nodig of moet je terplekke even het een en ander meten.

Achja, dit soort dingen gebeuren.

Als je geen bezwaar heb zou ik graag mijn oude tagging situatie herstellen, maar dan met de correcte coordinaten-transformatie en de nieuwe mutatie er bij in verwerkt.

Ik ben er niet helemaal over uit of we dat hele ondergrondse vlak als parkeergarage aan moeten merken, volgens een kennis die er lokaal bekend is zit er ook nog een soort kantoortje of opslag bij in, ondergronds. Heb jij enig idee?

Je hebt mijn meesterwerkje dat helemaal netjes volgens Simple 3D buildings was getagged in het centrum van Bemmel overhoop geholpen :(
Die parkeergarage is onderdeel van het pand, nu is het in OSM helemaal geen pand meer, laat staan onderdeel van het pand.

Ter verduidelijking voor de heer/mevrouw Kaart0:
De Data Working Group ('DWG') is het internationale orgaan van Openstreetmap dat door de Openstreetmap Foundation is geautoriseerd om o.a. conflicten als deze te behandelen. De Data Working Group heeft in Openstreetmap veel autoriteit, en wanneer mappers niet de instructies van de DWG opvolgen kunnen zij worden verbannen van Openstreetmap.
Zoals hierboven vermeld door de heer Fredrik Ramm (frederik@remote.org), eigenaar van de accounts woodpeck en woodpeck_repair, wordt elke mapper hier verzocht geen nieuwe edits te maken betreffende deze situatie en per direct te stoppen met deze 'edit-war' tot nader order van de DWG. Dit geldt voor iedereen, zowel voor U als voor elke andere mapper.

Meer informatie over de DWG is te vinden op de Openstreetmap Wiki: osm.wiki/Data_working_group

No problem, now you know :)

Be careful with editing buildings in the Netherlands. Almost all buildings are imported from the BAG, and it is rarely the proper solution to modify them by hand and leave it at that. You managed to find one of the few instances where modification by hand is really justified however, so well done :)

Fixed some of it in osm.org/changeset/80443938
The fields in this part of the Netherlands are in general an unmaintained mess, they desperately need maintenance.
This is best done using the BRP (brpgewaspercelen) open data source that is available to us Dutchmen, maintained by the government. In this dataset the farmers themselves draw their fields and add what type of crop (grass, crops etc) they have on that field. This dataset is much more up to date than any aerial imagery.

Most of the fields you edited are in fact not landuse=farmland as used by the Dutch OSM community, but landuse=grass or landuse=meadow.

Please be aware that in the Netherlands the community consensus is to map grass fields for agricultural usage as either landuse=grass or landuse=meadow (historically landuse=grass was used because of the 3dshapes import, now some mappers use landuse=meadow, some others use landuse=grass), and crop fields are tagged as landuse=farmland.

Wat een rare situatie is dit hier zeg..

Ik heb nog eens goed zitten kijken.

De highway=path die hier in OSM zat representeerde het stuk trotoir dat aan de zuidkant van Ringbaan-Zuid ligt, ten *noorden* van de geluidsmuur,
tussen de verbinding van de Oud Zevenaarseweg en de voormalige Wip-Inn (nu tijdelijk Kruitwagen Kledingverhuur).

Ik denk dat er hier een misverstand is tussen ons twee, want het pad waar jij het over lijkt te hebben (een pad dat tussen de geluidsmuur en de huizen ten zuiden zou lopen) is natuurlijk een heel ander pad.
Dit laatste pad heeft naar mijn weten nooit bestaan, en zoals jij vandaag hebt geconcludeert bestaat het nu zeker weten niet.

Als je het pad dat in OSM zat over de luchtfoto legt zie je ook duidelijk dat de originele mapper dit pad over het trotoir heeft getekend, ten *noorden* van de geluidswal. Echter lijkt het me sterk dat het stuk trotoir weg is, en jij beweert blijkbaar ook niet dat dat stuk trotoir weg is.
Dusverre lijkt het pad dat hier in OSM zat dus wél correct.

Nu komen er twee complicaties.

De eerste is dat de verbinding met het parkje van Oud Zevenaar volgens mij helemaal niet bestaat (lokale kennis). Hij is ook totaal niet terug te vinden op de luchtfoto.
Deze verbinding bestaat wel in de BGT, wat dan wel weer vreemd is. Het ziet er dan naar uit dat dit een blunder uit de BGT is. Misschien bestond de verbinding lang geleden wel, maar dan had dat inmiddels toch echt verwijderd moeten zijn uit de BGT. Als ik zeker ben van deze stelling zal ik wel een terugmelding bij ze maken, dan wordt het ook in de BGT gecorrigeerd.

De tweede complicatie is dat het pad dat in OSM zat niet ver genoeg doorliep, in werkelijkheid loopt het trotoir helemaal door tot aan de voormalige Wip-Inn (nu tijdelijk Kruitwagen Kledingverhuur). In OSM liep het pad niet verder dan de verbinding met het parkje. Het pad zou dus weer opnieuw ingetekend moeten worden, maar dan zonder de aansluiting met het parkje, en dan doorlopend tot aan de voormalige Wip-Inn.

Morgen als het weer licht is zal ik even langs lopen, ik ben nu toch wel nieuwsgierig hoe het er terplekke allemaal in detail uit ziet. Helaas kan je met Mapillary niet altijd alles zien.

Wat denk jij?

Met vriendelijke groet,
Martijn

Beste Robbert,
Wat is je bron voor deze changeset, als ik vragen mag? Ik neem aan dat je er bent wezen kijken, want alle beschikbare online bronnen (Mapillary, Luchtfoto's uit zomer 2019, BGT) wijzen er op dat dit pad wel degelijk bestaat, dus als je gelijk hebt dan is dit pas erg recent veranderd :)
Voorheen was er in ieder geval een geluidsmuur én een voetpad. Is de geluidsmuur vervangen of uitgebreid?
Misschien volgende keer even je sources vermelden bij je changeset? In de iD editor (die van de "edit" knop) kan dat vlak voordat je de changeset upload.

Met vriendelijke groet,
Martijn

You changed the geometry of "Landgoed Deelerwoud", which you should never have done. This is a boundary which you can not just move because that way it looks less cluttered on the map. When I created this boundary I even added a note tag to prevent this very thing from happening!
I'm gonna need to revert that now.

Secondly, you merged forest areas which had lanes of no data between them, which is *highly* controversial in the Dutch OSM community, and best not to burn your fingers on that either.

Please be more careful and educated about the place where you're mapping next time.

Well it seems you merely squared the zone, and scorp1035 actually moved the wreck. I reverted both changesets in osm.org/changeset/79019627

Naar mijn mening is de vector data gebruiken weinig anders dan overtrekken, maar dan van hogere kwaliteit.
Natura2000 wordt ook beschikbaar gesteld als WFS (Web Feature Service, vector data protocol uit de familie WMTS, WMS, WCS enz).
https://www.pdok.nl/geo-services/-/article/beschermde-gebieden-natura2000-inspire-geharmoniseerd-
Eigenlijk moet ik (we?) dit eens aankaarten op de forums. Een van de belangrijke dingen is dat je wel dezelfde transformatie van RD naar WGS84 gebruikt als de BAG-import plugin om inconsistenties in onze dataset te voorkomen.

Alle bestuurlijke grenzen in Nederland in OSM lijden van het hetzelfde probleem, ze zijn handmatig overtrokken. In de geo-informatie is dat eigenlijk een doodzonde.

Het zou mooi zijn als we al die officiele data die per definitie maar 1 werkelijke positie heeft vervangen met de officiele, correct getransformeerde vector data. Dat zou de reputatie van OSM ook fors verbeteren.

Ik weet dat het overal zo gebeurd, maar is het niet een beter idee om deze gebieden niet over te trekken maar om de originele vectordata te gebruiken? Het verlies aan nauwkeurigheid is zo zonde en verwarrend.