Als ik die AND-wegen in JOSM haal, zie ik soms een lange geschiedenis ná AND. Welke bewerkingen zorgen ervoor dat de overpass-turbo query hem niet meer vindt voor user:AND (en welke niet?)
De overpass haalt nodes op die onderdeel zijn van een way highway, met als laatste bewerker, user AND.
Als de AND node verschoven is, dan heeft iemand die node bewerkt. En komt hij niet meer voor bij een opvraag.
Ways kunnen na die tijd vele extra tags krijgen. En dat is ook gebeurd.
Er zijn geen ways met way._(user:"AND"); als laatst bewerkt.
De scheven wegen website is een goede andere vergelijking.
Daar kom je ongeveer tot dezelfde conclusie, nu bekeken vanuit de AND user.
Het ging mij er om, waar men nog nooit na die import de node heeft bewerkt. Op een weg is dat veelal het verschuiven van de node.
Aha. Dus de node blijft terugkomen, tot hij verschoven is. Dat zou inhouden dat je van zo’n ouderweg alle nodes moet aanraken om hem weg te krijgen uit de klus. Want het gaat uiteindelijk om de weg, niet de nodes.
Dat wegen in Nederland scheef liggen heeft voor een groot deel te maken met de AND import.
De klus zou zijn om te controleren of the node midden op de weg ligt, zo nodig aanpassen, verschuiven. Ligt het goed, dan kan je er af blijven.
Clusters van nodes, AND, geeft een indicatie waar men eerst zou kunnen kijken.
Het verschil met PeeWee 32 vergelijk methode is, waarbij uitgegaan wordt dat een deel buiten het BGT wegvlak ligt en dus als scheef wordt aangemerkt.
Terwijl er ook stukken zijn die wel binnen het BGT vlak liggen, maar niet midden op de rijbaan zijn ingetekend. Dus scheef binnen het vlak liggen, een aanwijzing is dan kijk eens naar waar die AND clusters liggen.
Zelf heb ik ook woonwijken recht gelegd, daar zijn nog steeds AND nodes, die lagen dus goed.
Doel is dan niet om al die AND nodes notificaties weg te krijgen.
Voorheen hadden wij de .gpx track, later kregen we BING luchtfoto, ergens daar is de AND import geweest. Voor die tijd was dat een verbetering. Nu met de scherpere PDOK luchtfoto en de PDOK laag BGT omtrekgericht kunnen we een kwaliteitsslag maken. Veel tekenwerk.
Nee, maar als ze blijven verschijnen dan wordt de query na korte tijd niet meer zo handig als sturend gegeven. Liefst heb je bij opknapklussen dat de treffers na het werk uit de selectie verdwijnen. Als alles weg is is het dan klaar.
Bij slecht uitgelijnde wegen heb je al gauw dat je over de hele lengte nodes verschuift, toevoegt en verwijdert, dus er zullen er niet veel overblijven die AND als laatste user hebben.
Ik las dit gisteren en bedacht me dat ik de BGT data moest verversen. Toen liep er hier e.e.a. mis en was kaart helemaal niet meer te gebruiken. Inmiddels doet ie het weer. Omdat ik me de laatste tijd veel met BGT heb bezig gehouden realiseer ik me dat ik ook voor deze kaart nog e.e.a. kan verbeteren. Ik hou nl. geen rekening met het type BGT wegdeel waar de OSM highway mee overlapt. Dus als een OSM residential volledig overlapt met BGT wegdelen waarvan 80% BGT “voetpad” (bv naastgelegen stoep) en 20% “rijbaan lokale weg” dan wordt ie nu niet gesignaleert. Dat staat op mijn todo lijst.
Er is wat dat betreft nog heel veel werk te doen.
We (inclusief mezelf) zijn vaak bezig met de grootste futiliteiten, maar waar het echt om gaat (de wegen) liggen er in veel plaatsen nog bij als bij de eerste import.
Het lijkt vaak erop dat mensen vooral gefocust zijn op zo snel mogelijk dingen in te tekenen die nieuw zijn, of nog niet op de kaart staan, terwijl de basis al jaren schreeuwt op verbetering (uitlijning mbv BGT).
Absoluut waar en schrijpend, maar ik vind de mix leuk. Stomme dingetjes, belangrijke dingen, veldwerk en databronnen, eigen dorp micromappen en themawerk in groter gebied, rotondes doen en lange wandelroutes, nieuw mappen naar eigen goesting en Maproulette missies, af en toe wat notes oplossen, af en toe een QA-tool gebruiken.
Ik heb in mijn woonplaats (gemeente Zuidplas) de nodes gecheckt die als laatste door AND waren aangeraakt. De meeste konden wel een correctie gebruiken, vaak ook de hele weg, en vaak ook de hele directe omgeving.
Alleen maar geĂŻsoleerde nodes verschuiven om de historie van de node te updaten is MI heel erg veel moeite voor weinig winst. Je kan dat wel gebruiken als vrij willekeurige ingang om het betreffende gebied een opknapbeurt te geven.
Vergelijkbaar met Maproulette missies zoals “Oud water”, die ook vooral een aanleiding zijn om naar allerlei plekken te kijken die anders nooit aan de orde komen.
Als een serie nodes van een weg nog AND zijn, dan wordt het absoluut de moeite. Als ik zo’n weg naloop dan blijft er zelden een node op zijn plaats.
Een cluster AND-nodes houdt meestal in dat er een wijk, natuurgebied of park al heel lang een facelift nodig heeft.
Al met al, MI vooral een aardige aanleiding om (delen van) je eigen woonplaats een beurt te geven. Als we weer een cyclus provincie van de maand gaan doen, is dit ook wel een kandidaat, maar dan zou ik het beperken tot verbindingswegen die een hele rij AND-nodes hebben.
Ik werk wel eens aansluitend, daar heb ik eerder een bericht over geschreven.
Voor AND kan je ook je eigen naam invullen.
En zo kon ik zien waar ik de dag ervoor ben opgehouden en welke kruisingen ik nog moest.
Als je wijk voor wijk na loopt. Op elke kruising is wel wat te doen. Verbetering van intekening.
Dat is vooral geschikt voor een eigen persoonlijk project. Als je iets zo wil opzetten dat willekeurig wie daar zin in heeft, een stuk kan doen, is het handig om een dynamische kaart te hebben met de werkvoorraad, waar datgene wat gedaan is gewoon van verdwijnt.
Tegenwoordig gebruik ik ook veel de todo-plugin van JOSM. Als je een goede Overpass-turbo query hebt, kan je die loslaten op een gebied (een bbox of een geocode-area) en dan exporteren naar JOSM; daar in de todo-list gooien en een voor een afwerken en afvinken. Porties van ca 100 af te werken objecten zijn goed te doen, is mijn ervaring.
Maar in zo’n overpass query kan je niet met een externe databron vergelijken. Voor de AND nodes gaat het dus wel, dat is puur OSM, maar voor bv een knooppuntennetwerk uit de routedatabank niet.
