Highways defragmenteren, een analyse

Er zijn in OSM veel wegen die met de eindpunten aan elkaar verbonden zijn die exact de zelfde eigenschappen/relaties hebben. Er zijn verschillende oorzaken voor te vinden. Eén oorzaak is dat wegen opgeknipt worden omdat ze niet in zijn geheel bekeken zijn. Ik weet dat ik dat zelf veel gedaan heb om bv de surface tag toe te voegen. Ik had dan niet de hele weg bekeken en dus knipte ik deze op. Het zou dan kunnen dat ik (of een ander) er later achter kwam dat ook het andere deel de zelfde surface tag had en dat dan toevoegde. Hierbij hebben we lang niet altijd deze 2 delen samengevoegd. Gevolg is dat wegen steeds meer gefragmenteerd worden terwijl dat niet nodig zou zijn. En door al die (m.n. kleine) stukjes weg wordt het mappen er niet makkelijke op omdat je zomaar een stukje kunt vergeten mee te nemen in je edits. Daarnaast vermindert samenvoegen het aantal records in de database waardoor het performancewinst oplevert bij analyses/bewerkingen.

Ik heb een eerste analyse gemaakt van de wegen die obv gelijke eigenschappen samengevoegd zouden kunnen worden. Voor heel NL heb ik de nodes geselecteerd waar de wegen met identieke tags/relaties aansluiten. Dat zijn er best veel. Ze zijn te bekijken op deze kaart. Voor alleen de provincie Utrecht laat ik daarbij ook de highways zien die samengevoegd zouden kunnen worden. (voor heel NL heb ik nu geen ruimte in de qgiscloud opslag)

Ik weet nog niet precies wat we hier mee kunnen of willen maar wellicht hebben jullie daar ideeën over. En mocht je fouten zien dan hou ik me aanbevolen voor feedback. NB de OSM data is van een paar dagen geleden. De kaart wordt dus niet automatisch bijgewerkt. Als je klikt op het punt (osm_highway_samenvoegpunt) dan kun je daarna kiezen voor JOSM om het te laden.

Hoi Peter,

Even een kanttekening.

Het gevaar van zomaar samenvoegen (en dat gebeurt nog al eens) geeft een probleem als er routerelaties over lopen.
Dat doorverbinden maakt de routerelaties stuk.
Vooral startende mappers letten niet op die routerelaties en verbinden zonder er erg in te hebben wegen door.

Kun je dan op jouw kaart zien dat je bepaalde stukken juist niet moet verbinden?

Verder is al eens genoemd dat het inleggen van nieuwe routes ‘ietsje’ lastiger worden.

Op zich is het een goede zaak om die wegen samen te voegen.
Maar er dient dan wel rekening gehouden te worden met de routerelaties waar die wegen deel van uit maken.

Samenvoegen wordt automatisch correct verwerkt in de routerelatie, maar toch kan het fout gaan.
Op het punt waar de wegen samenkomen kan een route afslaan. Dat is dan ook de reden dat de weg in het verleden daar gesplitst is.
Nu weer samenvoegen leidt dan tot een gebroken routerelatie.

Laatst had ik nog zoiets: het eerste deel van een weg maakte 2x deel uit van een relatie. Het tweede deel slechts 1x.
De wegen werden samengevoegd en dus volgde er de volgende dag een melding over een gebroken routerelatie.

Nederland lijkt zo langzamerhand alleen nog te bestaan uit OV-routes, wandelroutes en fietsroutes.
En elke keer dat een route afslaat wordt de doorgaande weg dus gesplitst.
Samenvoegen is dus vaak niet mogelijk.

Aanvulling… Wanneer (her)startende mappers gaan doorverbinden hebben we dat al snel in de gaten. We volgen immers de eerste tien ‘mappingdays’.
Wanneer iemand er meer heeft dan 10 valt het niet op bij de screening, maar alleen omdat knooppuntnet en de ‘Inspector’ foutmeldingen gaan geven. (en die moet je dan toevallig nog zien)
Dan wordt het weer een hele uitzoekerij om zo’n mapper te stoppen.
Zelf zou ik niet willen promoten (hoe goed bedoeld ook) om wegen te gaan samenvoegen, want je kunt gaan wachten op schade.

Je zou dus aan je kaart moeten kunnen zien dat er routes overheen lopen. Die zou je kaart dan moeten negeren en/of niet zichtbaar maken. Geen idee of dat mogelijk is.

Even korte reactie want ik ben aan het fietsen. Ik hou rekening nog met de router relaties. Mocht je merken dat het niet klopt laat het dan weten.

Yep… Veel plezier met je tochtje.

Lekker fietsweer, we zijn net weer terug.
Prima actie van je, respect hoe je steeds weer van dit soort mooie dingen doet. Van mij zou een automatische edit rustig mogen (na een grondige bug-fix).
Over een “bug” gesproken. Daar waar een weg splitst bij b.v. een kruising krijg je ook een opmerking. Deze b.v.: https://qgiscloud.com/PeeWee32/OSM_defrag_highway_QGC/?l=osm_highway_samenvoegpunt%2Cosm_wegen_samenvoegen_utr2%2COpenStreetMap&t=OSM_defrag_highway_QGC&e=766939%2C6937299%2C767955%2C6937807
Tertiary (2) in het midden. M.i. hoeven deze niet samengevoegd te worden.

@eggie, goed nieuws:

In iD is tegenwoordig de doorverbindknop niet bruikbaar (grijs) als je twee delen probeert samen te voegen waarbij het enige verschil een route relatie is. Een weg die onderdeel is van een relatie is ook niet zomaar te verwijderen, je moet eerst de relatie er af halen voordat dat kan. iD is toch wel beter en robuuste aan het worden.

Toffe tool PeeWee32. Ik ga alvast handmatig aan de slag ermee in mijn regio. Eens kijken wat er op mijn pad komt.

Goeie toevoeging. Ik hou er nu wel rekening mee dat beide wegen wel (of niet) deel uit maken van de zelfde route relaties(s) . Waar ik geen rekening mee hou is dat de rol in de relatie de zelfde is of dat een weg meer dan 1x deel uitmaakt van de relatie (en de verbonden weg slechts 1x) . Daar moet ik nog eens induiken en proberen e.e.a. te verfijnen. Ook de richting van de weg i.r.t. de oneway tags moet ik nog eens nader onderzoeken. Kan zijn dat dit false positives oplevert.

Ik denk wel dat een ervaren mapper (met voldoende tijd :wink: ) alvast e.e.a. zou kunnen samenvoegen. Dat kan nog meer feedback opleveren. Ik heb voorlopig nog ff wat huiswerk ;).

Bedankt. Je voorbeeld geeft m.i. mooi aan dat het nogal lastig wordt om e.e.a. geautomatiseerd samen te voegen. Als je de relatie volgt zijn de 2 wegen niet op één volgend. Dan gaat het dus fout. Weer wat huiswerk voor me :wink:

Dick of ligfietser heeft al eens aangegeven dat men bij het maken van routerelaties graag ziet dat vooraf al kruisingen geknipt zijn, veel beter werkt voor het maken van deze relaties.

Dat verkeersborden gelden tot de volgende kruising, zodat je niet voorbij een kruising, de volgende en meerdere kruisingen het access verkeerd zet.

Wanneer je per ongelijk een weg versleept dat wegvak verkeerd ligt. En dat een ander van de andere kant weer goed gaat leggen en tot de conclusie komt dat is wel heel erg lang.

Ik heb dan geen moeite om op kruisingen te knippen.

Een mechanical edit is af te raden.

Zo werd mechanical edit afgeraden bij traffic_sign fietsborden.

Goed punt. Ik heb nu de samenvoegpunten groen gemaakt als er geen relaties overheen lopen en rood als dat wel het geval is.
kaart

Klopt, is iets minder werk als je een route-relatie maakt, anders moet je op dat moment zelf een knip uitvoeren. Maar of dat nu een reden is om op voorhand bij alle kruisingen een knip uit te voeren betwijfel ik.

Top Peter… die kleuren…
Ja …en iD wordt steeds beter… Toch gaat het met die routes nog steeds op eoa manier fout.

Hier een voorbeeld waar een mapper een in onbruik geraakt pad heeft verwijderd. Dat moest geknipt worden. iD knipte daardoor ook (zonder waarschuwing?) de weg die van noord naar zuid loopt. Resultaat… De volgorde der routedelen in de war.

https://overpass-api.de/achavi/?changeset=124576354

Niet meer, dat is oud zeer.
Er is een zeer succesvolle ingreep in de code van JOSM gedaan, waardoor het knippen van wegen voor een route fluit of cent is geworden.
Vroeger moest je na een knip alle - al bestaande - routes controleren omdat de volgorde van de segmenten na een knip, vaak verkeerd stond.
Nu niet meer.
En verder was mijn punt in deze, dat bij de AND import al deze wegen al geknipt waren en een aantal mappers dat allemaal zaten door te verbinden, terwijl dat eigenlijk niet nodig was. Dus het is niet op voorhand een knip uitvoeren, maar gewoon een bestaan de knip handhaven.

Maar goed dat is allemaal niet nodig meer.

En meer doorverbinden is alleen maar plezierig, scheelt weer segmenten in de route.

Laatst zag ik wegen in Fryslân, waar de weg bij elke afslaande serviceroad was doorgeknipt. Dat lijkt mij een beetje te veel van het goede.

Ik zou graag de verhouding tussen kruispunten (splitsingen) en de andere stukken willen zien (tussenstuk). Geknipt bij een service road zoals hierboven vermeld dan weer niet, lastig.

Leuk inzicht!

Bij een splitsing, om een verkeerseiland heen, links en rechts, oneway=yes, Niet verbinden.

Mooi werk!

Een paar dingen vallen mij op:

  • In bijvoorbeeld de Loethoelilaan in Amstelveen zie ik dat deze weg zich even splitst met een middenberm in een dubbel eenrichtingsverkeersweg. Je krijgt dan bij qc_id 161251 2 dezelfde wegen. Dit zijn echter de heen- en terugrichting van dezelfde eenrichtingsweg.
    Hoewel datagericht dit prima één (rondlopende, want even verderop ook dezelfde tags) weg zou kunnen zijn is het dat uit semantisch oogpunt natuurlijk niet. Je krijgt dan (tagging voor de renderer) een naam die zich “om het bochtje” kan renderen en bij routers die minder knooppuntten bevoordelen zou je zelfs een route kunnen krijgen waar hier keren (wat vaak niet mag of praktisch niet mogelijk is maar nog niet in een turn relation gevangen is) de eerste optie is.

  • Het betreft erg veel footways. Daar zit vaak geen naam aan en als je daar willekeurig paren gaat verbinden krijg je wellicht hele rare “slangen” van footways aan elkaar. Dat is qua data niet per se fout maar wel een beetje raar.

In het verlengde daarvan voelen bij dit soort straten die op zichzelf terugbuigen de knippen ook niet per se verkeerd:

(De twee waarbij de straat 90° een andere richting op gaat.)

Je kan misschien veel van zulke knippen er uit filteren door te kijken naar de hoek die de segmenten daar bij die node maken. Bij scherpere hoeken is een knip niet heel raar (geld voor veel voetpaden ook).

Heb flink wat highways aangepakt en gebruik gemaakt van de tool. Mooie meerwaarde. Hoop dat deze voorlopig online blijft en af en toe wordt bijgewerkt!

  • Vooralsnog niet geschikt voor mechanical edits gezien de “vele” uitzonderingen
  • Vooralsnog niet geschikt voor beginners en alleen in JOSM wat mij betreft de veiligste optie. Eventueel de groene bolletjes voor beginners.
  • Bij kruispunten en bij rotondes extra aandacht benodigd, hier krijg je vaak gesplitste ways, maar in mijn ziens zeker niet connecten met elkaar! Oneway problemen en wat nog niet meer.
  • Dit geldt ook voor Middenbermen met een vluchtheuvel er tussen in. In theorie kan de helft geconnect worden, maar praktisch, vanuit visueel oogpunt is het niet.
  • Bij rotonde cycleways kan ook e.e.a uiteraard aan elkaar worden gezet, maar is dit wenselijk. Ik denk van niet. Functie van de rotonde voor fietsers verdwijnt dan (tbv afslag begeleiding)
  • De tool werkt uitstekend in woonwijken met oude imports van vroeger en weinig overige edits in de loop der tijd. De meest kleine stukjes highway haalt hij eruit! Geweldig, dit geeft een mooi rustig kaartbeeld (taggen voor de render :wink: ). Maar vooral laad-snelheid (met OsmAnd gecheckt!)
  • Cycleways en footways ZONDER naam, tja hoe lang wil je spaghetti sliert maken. Voor je het weet hebben we één voetpad van Groningen naar limburg via Zeeland lopen. Boeren verstand gebruiken in deze.
  • De kleurtjes groen&rood werken fijn, zo kun je redelijk snel alle groene bolletjes afwerken zonder eerst routes dubbel te checken.
  • Doordat je met deze tool wat meer in detail gaat kijken heb ik al diverse straatnamen gecorrigeerd en highway types correcties toegepast die nog niet waren opgevallen. Dubbel winst!
  • Soms kunnen de wegen wel gecombineerd worden maar is het gewoon niet logisch vanuit menselijk oogpunt, bijvoorbeeld bij highways die om pleintjes lopen. Of straten in de vorm van vierkanten met diverse aftakkingen. Daar zul je toch een keuze moeten maken hoe jij het graag ziet, en kan niet alles aan elkaar geplakt worden.
  • Zou er gefilterd kunnen worden op type highways ? Of wat grover van opzet om [Footway, Cycleway] aan/uit te kunnen zetten