Hier in het Bentwoud bij Zoetermeer / Benthuizen: https://www.openstreetmap.org/?mlat=52.06501&mlon=4.55664#map=18/52.06501/4.55664
lijken twee watervlakken te overlappen. De ene heeft als bron BGT data (way nr. 642937429) en de ander komt uit Prorail Aerial Imagery (2015), way nr. 465778600 en deze laatste is lid van een relatie. Rondom het tracee van de HSL heb ik ooit meer van soortgelijke watervlakken gezien die soms over andere structuren zijn ingetekend (bulk import zonder afdoende na-controle?) - ben er maar van afgebleven…
Nou lijkt het niet zo moeilijk om een van de twee weg te gooien, maar ik vraag me af welke edit / bron in dit soort gevallen de voorkeur zou moeten krijgen. Als ik afga op de eenvoud van de edit-handeling, dan zou ik het ‘bgt’-watervlak verwijderen en niet dat van Prorail omdat dat lid is van een relatie en verwijderen dan misschien weer veel meer extra werk oplevert?
Lastig. Normaal zou ik de BGT ook bewaren, maar in dit geval, met de relatie, i.d.d. de Prorail laten staan en misschien op basis van BGT de kaart aanpassen.
Het Prorail-vlak is eerder gemapt dan het BGT-vlak, dus BGT-vlak verwijderen en Prorail-vlak eventueel aanpassen aan de BGT. Dit had de mapper van het BGT-vlak ook moeten doen, in plaats van het vlak dubbel in te tekenen.
Hoi, dit was een foutje van mij in een groot landuse/naturals-project om het grote Bentwoud eindelijk qua vlakken eindelijk op orde te krijgen. Liep daar eerder, net als andere mappers, op stuk vanwege de gebruikelijk misère als je oude grove import wil verbeteren/ actualiseren Zie ook https://forum.openstreetmap.org/viewtopic.php?id=57879
Alleen werkt de multipolygoon-per-polder-aanpak voor water in het Bentwoud niet goed omdat de betreffende polder (een samengestelde droogmakerij van polders die eerder tot water zijn uitgeveend vanwege onze honger naar brandstof) zo groot is, dat het om zo te mappen niet goed meer te overzien is.
De cut-out plugin van Kiaatix gaf nieuwe moed om dit gebied alsnog aan te pakken, maar dan met handmatig overzetten van steeds kleine beetjes uit de BGT voor zover die er nog niet in zaten.
En daar heb ik een foutje gemaakt door in dit geval de ProRailwatergang niet te verwijderen. BGT is hier -zoals meestal- beter. Heb geloof ik 1 ProRail watergang laten staan die even goed is als BGT. Twee watervlakken over elkaar hoort natuurlijk niet, heb dat nu gecorrigeerd.
Ze lagen zo dicht op elkaar dat ik het bij uitzoomen niet heb opgemerkt, en toen ik zelf de genoemde multipolygoon aanmaakte, heb ik blijkbaar op het ProRail-vlak geklikt en niet op het BGT-vlak.
In algemene zin: als het vlak dat geen lid is van de relatie beter is qua geometrie, dan is het in JOSM een koud kunstje om die toe te voegen aan de relatie (natuurlijk samen met verwijdering van het slechtere vlak)
Dubbel tekenen was natuurlijk fout, maar bestaande vlakken allemaal aanpassen is leuk als het er een of twee zijn, maar niet bij meer en complexere vlakken, dan wordt dat onwerkbaar. Replace geometry kan soms nog uitkomst bieden, maar niet in dit soort gevallen: dan ga je source:prorail-tags hangen aan een geometrie uit de BGT. En dat werkt vaak ook al niet omdat het aantal vlakken dat is gebruikt voor een feature niet altijd gelijk is.
Nadeel van vervangen is zich minder zicht op geschiedenis, maar anders dan bij bijvoorbeeld highways zijn het bij landuse en naturals niet zozeer de tags die een ontwikkeling vertellen (en kunnen helpen bij herstel na ongelukkige edits), maar de geometrie die steeds verandert. Bovendien is de geschiedenis van verwijderde vlakken nog steeds te vinden in de changeset waarin je tegelijk ook het nieuwe vlak toevoegt, is een keertje klikken extra.
Er is nog steeds wel wat werk te doen, maar de grote lijnen van landuse zijn na flink wat uurtjes werk wel opgeschoten ten opzichte van de onderstaande voor-situatie:
De uitleg van multimodaal vind ik prima. Zelf hergebruik ik heel veel oude vlakken en nodes van oude imports omdat ik zo gek ben om handmatig heel nauwkeurig gras en water uit te lijnen.
Juist bij dit soort vlakken is het inderdaad goed te verdedigen om af te wijken van de richtlijn om te behouden wat er al is. Dit geldt zeker als de vorm van een oude import nog intact is. De eventuele handmatige intekening/wijziging van iemand zou je niet zomaar willen weggooien, maar als die er enorm slordig uitziet dan lijkt me dat ook weer geen bezwaar.
De tag operator=owner op sloten heb ik wel mijn vraagtekens bij.
Uit veel veld- en leggerstudie blijkt dat enorm te helpen bij het kunnen generaliseren van watervlakken. Zo zie je bijvoorbeeld dat waterkaarten over verloop van tijd veel onduidelijker zijn geworden omdat er door bulk-import van topografische data allemaal sloten bij zijn gekomen die landschappelijk wel zijn (daar sowieso prima om p de kaart te zetten), maar waar je als watersporter helemaal niets mee kan en waardoor je het zicht op de grote lijnen (en mogelijk wel -met een beetje moeite- bevaarbare delen) verliest.
Dank voor de toelichting. Ik had kunnen weten dat je het in het importvoorstel had vermeld.
Het profijt van zo’n onderscheide tag kan ik me goed indenken. De ene sloot is de andere niet en de breedte op de kaart zegt niets over diepte of bevaarbaarheid en bedoeling en onderhoud daartoe. Een ‘oormerk’ is dan een welkome oplossing.
De tag-combinatie blijf ik wat wonderlijk vinden… pragmatisch is het wel.
Ik ben benieuwd of het door andere mappers overgenomen gaat worden. Operator=farmer op een landuse=meadow kan dan ook. Ik ga er niet aan beginnen.
