Ik moet mij weer eens verontschuldigen. Een aantal mensen hebben mij gezegd dat het omzetten van note->ref een mass edit is. Ik wilde daar niet echt aan, omdat ik het handmatig doe, en anderen doen het ook, maar ik kom daarop terug. Zij hebben gelijk: als ik in JOSM als een zotte bot dit zit te editen en ik upload het in één keer, dan is dat een mechanical edit. En die mag ik officieel niet doen zonder dat vooraf goed te dokumenteren!
Omdat ik ervan overtuigd ben dat het uiteindelijk toch gaat gebeuren (in België en Duitsland zijn ze ook al aan het omzetten) ga ik liever niet reverten wat ik al gedaan heb. Maar ik heb het nu wel gedokumenteerd en wel hier: https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Peter_Elderson
Graag nodig ik jullie uit om hier konstruktief kommentaar op te geven. Tips over hoe het handiger en veiliger kan zijn altijd welkom!
(*Ik hou deze diskussie in Nederland, omdat ik alleen in Nederland hiermee aan de slag ga en omdat het buiten Nederland nauwelijks in deze omvang speelt. Dat is ook konform de richtlijnen voor dit soort omzetoperaties. *)
Ik heb zelf ook het Wandelnetwerk Twente omgetagd en volgde een soortgelijke procedure, maar wel met enige verschillen.
Wat me in jouw procedure opvalt is de omtagging van note naar note_1 op nodes. Dit leidt tot onnodig omtaggen en het daarbij creëren van een niet gedocumenteerde tag (note_1). Ik vermoed dat je dit doet omdat je de boel exporteert naar een .osm bestand en daar alle ‘note’ naar ‘ref’ omzet. Dus niet alleen voor de relaties maar ook voor alle nodes. Ikzelf selecteerde simpelweg in JOSM alle om te taggen relaties (gebruik de search mogelijkheid) en dan in JOSM de note naar ref veranderen (uiteraard na eerst de nodige checks uit te voeren). Je verandert daarmee enkel de relaties en niets anders.
Ook snap ik niet dat je alles naar route=foot hebt omgetagd. De meeste routes (in ieder geval in mijn omgeving zijn route=hiking i.v.m. het unpaved zijn).
Ik zou het mechanisch aanpakken per route-relatie. Je zou er een kunnen kiezen en die bij voldoende steun uit kunnen voeren ter controle. Daarna kunnen alle wandel- en fietsroutes omgezet worden lijkt me.
Het is denk ik niet zo nuttig om af te wachten totdat elk stukje route een keer door iemand aangepast is, dat kan decennia duren. Ik heb onlangs een aantal wandelknooppuntroutes rondom Leeuwarden ingevoerd (en zelfs een aantal routes aangepast weten te krijgen bij de beheerder vanwege een aankomende spoorbaanoverwegsluiting), maar ik heb daar note gebruikt, omdat de bestaande routedelen dit ook al deden. Ik ben er juist vanuit gegaan dat de omzetting note→ref mechanisch zou gebeuren, zodat alles gelijk blijft binnen een routerelatie.
Dat is inderdaad wel vreemd. Ben je bang om ‘echte’, niet route-notes kwijt te raken? Je zou een regex kunnen loslaten op de note-tags ter controle. Als een note-tag niet aan deze voldoet, dan moet er even naar gekeken worden:
[0-9]+-[0-9]+
Ik zou het dan ook met een scriptje doen buiten JOSM bij stap 5. Die controleert dan of een note-tag voldoet aan de knooppuntroutestandaard, en zet hem om naar ref, en geeft je een seintje als je er even naar moet kijken.
Ik zou zelf één scriptje maken die waarschuwingen geeft over rare note-tags, en één die ze omzet naar ref. Zo kun je de eerste herhalen tot je alle vreemde notes er uit hebt gevist.
Parkeertag note_1
Als het binnen JOSM kan blijven hoef ik inderdaad niet moeilijk te doen door de notes van nodes tijdelijk om te taggen en daarna weer terug. Uiteraard komt die tijdelijke tag nooit in OSM want ik zet hem daarna weer terug. Moet ik beschrijven, tenzij het niet meer nodig is, zie verder.
Omtaggen binnen JOSM?
Maar hoe verander je in JOSM voor de selectie in één keer alle note=xx-yy naar ref=xx-yy ? Dus alleen de key veranderen, met behoud van de waarde? Ik zag niet hoe dat kan, waarschijnlijk ken ik een leuke optie niet.
foot / hiking
Ik denk dat foot = paved en hiking = unpaved niet conform wiki is. Die is wel een beetje vaag, maar er staat zeker geen hard onderscheid in. Volgens mij is dat ook niet algemeen gebruikelijk in Nederland. De renderings die ik ken gooien foot en hiking allemaal op 1 hoop (soms ook walking) en kijken voor een paved/unpaved rendering naar de eigenschappen van de wegen. Ik had me niet gerealiseerd dat dit soms op routeniveau toegepast wordt voor onderscheid paved / unpaved.
Ik hanteer zelf: langeafstandswandelingen en streekpaden hiking, en knooppuntenetwerken foot. Maar ik zal daar dan verder niet aankomen, nu ik dit weet.
Misschien wel interessant om daar een algemene afspraak over te maken?
Ik ben geen programmeur, helaas… Gewoon een domme gebruiker, die opties in programma’s nodig heeft.
Als jij zegt scriptje, dan weet ik niet wat ik moet doen!
Die regexp snap ik wel, en ik kan ook nog pseudocode verzinnen, maar dan zit ik.
Ik heb ik voor de knooppunten route=foot gebruikt.
Dat lijkt mij ook logisch omdat het ook bv. route=bicycle is en niet route=cycling.
De wiki maakt een verschil tussen route=foot en route=hiking:
A foot route is generally a shorter, easier route. A hiking route is generally longer and/or more strenuous.
In het Duits is het onderscheid tussen spazieren en wandern.
In het Nederlands ken ik dit onderscheid niet zo zozeer.
Misschien dat je bij LAW/streekpaden route=hiking moet gebruiken en bij de knooppunten/lokale rondjes route=foot.
Persoonlijk zie ik niet in wat het nut is om dit verschil te maken als je ook network=lwn, rwn, nwn hebt.
Tja, ik ben niet zo handig dat ik heel Nederland in 1 keer veilig automatisch zou kunnen en durven omzetten. Daarom doe ik het liever netwerk voor netwerk. Dat is veel werk, maar het is afzienbaar. Ik wil daarbinnen wel graag de repeterende handelingen geautomatiseerd hebben.
Heb je Python3 beschikbaar of kun je die installeren? Je kan deze installeren vanuit de Microsoft Store.
Ik maak een scriptje dat je kan vertellen of er notes zijn die niet overeenkomen met wat we verwachten, en die note omzet naar ref in de relaties. Je hebt dan een OSM-bestand wat je kan controleren en weer in JOSM kan laden.
Als testdata pak ik de wandelknooppuntenroutes van Wandelnetwerk Fryslân.
Dat is gemakkelijk:
Bij selecteren staat er in de tags lijst dan note = <2 verschillende>
Daarop dubbelklikken en alleen de key aanpassen en de waarden ongemoeid laten
Dan OK en is enkel de key aangepast en zijn alle waarden nog hoe ze waren met de oude key
Oef, het is dat ik in de oudheid nog met dos gewerkt heb, dat ik nu nog een heel klein beetje iets in een “dos-box” (tegenwoordig heet dat “opdrachtprompt”) kan. Mapje aangemaakt om dit werkje in te doen; daar het .py bestand ingezet en er de .osm uit JOSM heen geschreven als route_in.osm. Het .py bestand bleek met hyphens ipv underscores te zijn, geen probleem verder. Het werkt!
De truuk is dus om de mogelijke problemen op te lossen vóórdat je de .osm maakt en de check runt! Anders blijf je bezig…
Verder, na openen van het aangepaste bestand in josm staan niet alle relaties als “gewijzigd” aangemerkt, dus de truuk om alles te selecteren en iets te doen wat verder geen kwaad kan, blijft nodig.
De check geeft je per relatie met problemen de id in de vorm van id:1234, die kun je letterlijk in JOSM’s zoekveld stoppen (met ‘id:’ erbij), dan heb je de relatie gelijk te pakken. Zie je veel meldingen bij andere routerelaties in de check?
Zal ik dat even toevoegen aan het script? Laat het script het domme bulkwerk doen zodat je je kan focussen op de inhoud.
Dat is zo eenvoudig dat ik er niet opgekomen was! Bedankt!
Dan is de workflow nog eenvoudiger, want er hoeft niets buiten josm om geëdit te worden. Het script van Jeroen is wel heel mooi om te checken of eerst alle problemen uit de weg geruimd zijn, maar het omtaggen zelf is dan handiger om het binnen JOSM te doen.
PS wat is het toch handig om een beetje te kunnen programmeren!
