Access logica voor fietsen

@emvee Ik maak mijn gedachtengang even volledig!
In andere landen zouden fietsknooppuntroutes gewoon over trunks kunnen lopen, conform de default default access-tabel. Wij zijn zelf strenger, maar toch best wel grote landen als VK, Duitsland en Italië volgen de default default. Je zou dan landspecifiek access kunnen controleren, maar dat zie ik niet zo heel snel gebeuren. Daarom zou ik nu (als we er uberhaupt uitkomen) de default default hanteren, anders worden daar correcte routes onterecht afgekeurd.

Dan moet je wel bedenken of het bij ons gevaar oplevert. Bij routeren (navigeren) stuurt de navigatie de fietser, dus dat is een groter risico. Bij controleren van voor fietsers aangelegde routes stuurt de routemaker de fietser, waarbij we mogen aannemen dat er geen (bij ons) niet toegankelijke wegen gebruikt worden. De controle controleert dus de mapping, niet de route. Bij invoer mbv een gpx bijvoorbeeld, gaat het er vooral om welke wegen je kiest om de gpx te vertalen naar een routerelatie. Bij bestaande routes gaat het vooral om wijzigingen te detecteren.
De route kan vervolgens wel in planning gebruikt worden die daarna gevolgd wordt. Als de mapper niet op de lokale defaults let is het risico is dus niet nul, maar er zit dan ook weer een extra controlemoment voor de gebruiker tijdens de planning. Knooppuntroutes worden meestal niet gebruikt om zo snel mogelijk van A naar B te komen, maar juist om thuis een aantrekkelijke route te maken voor een geplande trip, dus je bent juist gespitst op waar die loopt.
Al bij al zou ik dat risico dus als klein bestempelen, zo klein dat het niet rechtvaardigt om wél toegestane routes in andere landen af te keuren.

Misschien kan er een “trunk”-waarschuwing komen die de route niet afkeurt? Ik heb in Italië gefietst en een heleboel wegen mag je officieel fietsen, maar in de praktijk moet je het niet willen! In Analyse zou een opmerking kunnen komen, en in Planner misschien een vinkje “geen trunks” en/of een ! in de resultaten of zo. En/of een kleurtje op de kaart, vergelijkbaar met het verhard/onverhard kleurtje.

Klopt, maar hier gaat het niet om routeren. De knooppuntplanner rijgt door anderen gemaakte en op de weg gemarkeerde routes aan elkaar. De gebruiker volgt de knooppuntmarkering, ook als het afwijkt van de planner. De controle is op de mapping, niet op de route.

Klopt ook, maar in de Knooppuntnet wordt de tagging niet aangepast, alleen geanalyseerd.

Als de knooppuntenplanner afhangt van de routes, dan hangt die af van de routers en dus niet van de tagging en moeten de routers indien deze onvolkomenheden bevatten aangepast worden. Maar: als de knoopuntplanner van de routes afhangt, wat doet dan de highway-accesstagging er überhaupt toe?

Als je de evaluatie uitvoert op de volgorde die ik hier uitleg, dan hoef je dat ook niet te doen. Je moet alleen nog wel de oneway-tags meenemen in die drie onderste functies, en voor elk segment dus beide richtingen evalueren. oneway:vehicle kun je wel negeren, maar als je één functie maakt waarin je access-tag en oneway-tag meegeeft dan los je dat generiek op, en maakt het niet uit.

access_whitelist {
    yes,
    permissive,
    designated,
    dismount
}

access_blacklist {
    no,
    private,
    use_sidepath
}

default_access {
    NL: {
        primary,
        primary_link,
        secondary,
        secondary_link,
        tertiary,
        tertiary_link,
        unclassified,
        residential,
        living_street,
        road,
        track,
        service,
        cycleway,
        path
    },
    // Aanvullen met andere landen die relevant zijn.
    default: {
        trunk,
        trunk_link,
        primary,
        primary_link,
        secondary,
        secondary_link,
        tertiary,
        tertiary_link,
        unclassified,
        residential,
        living_street,
        road,
        service,
        cycleway,
        path
    }
}

function highway_access_for_bicycle_by_default(country, highway_value) {
    if default_access.has_key(country):
        return default_access[country].contains(highway_value)
    else
        return default_access['default'].contains(highway_value)
}

function eval_access_at_level(access_value, oneway_value, direction) {
    if access_value in access_blacklist return False
    if oneway_value == yes && direction == Backward return False
    if oneway_value == -1 && direction == Forward return False
    if access_value in access_whitelist return True
    return None
}

function eval_access_direction(country, direction, tags) {
    Boolean has_access = highway_access_for_bicycle_by_default(country, tags['highway'])

    Boolean access_access = eval_access_at_level(tags['access'], tags['oneway'], direction)
    if access_access != None has_access = access_access

    Boolean access_vehicle = eval_access_at_level(tags['vehicle'], tags['oneway:vehicle'], direction)
    if access_vehicle != None has_access = access_vehicle

    Boolean access_bicycle = eval_access_at_level(tags['bicycle'], tags['oneway:bicycle'], direction)
    if access_bicycle != None has_access = access_bicycle
}

// Voorbeeldaanroep voor één OSM way:
Boolean access_forward = eval_access_direction(NL, Forward, tags)
Boolean access_backward = eval_access_direction(NL, Backward, tags)

Deze pseudocode is wat er in routers ook grofweg gedaan wordt.

De routes worden niet gegenereerd, maar ontworpen/uitgetekend door mensen en vervolgens op de weg gemarkeerd. Wij voeren dat dan weer zo goed mogelijk in in OSM als knooppuntennetwerk.

Knooppuntnet Analyse voert een groot aantal checks uit op de invoer, om te kijken of de netwerk- en routeintegriteit klopt en blijft kloppen. Toegankelijkheid/Doorgankelijkheid (soort weg, eenrichting, access) is een van de kriteria. Als je ergens echt niet mag komen is het waarschijnlijk een fout in de invoer, of de eigenschappen van de weg zijn veranderd en de registratie klopt niet meer: dan moet dus de OSM-representatie van het netwerk worden aangepast.
De check is nu vrij grof, de meeste gevallen worden gedekt, en naar aanleiding van een bepaalde situatie ligt de vraag voor of dat beter kan. Hij laat highway=, highway:virtual=, route=ferry toe, tenzij er bicycle=no op staat, en verder alle ways waar bicycle=yes op staat.

Nu er een algemene OSM-knooppuntplanner is, melden gebruikers soms dingen. In dit geval, dat een knooppuntroute volgens Knooppuntnet bestaat, maar geen rekening houdt met dat de weg inmiddels “highway=construction” en “access=no” is - een vrij vaak voorkomende situatie. Daaruit was dus de issue: kan Knooppuntnet rekening houden met dit soort situaties, door zo’n route in Analyse een rooie vlag te geven, en in Planner onplanbaar te maken.

En als je dan toch bezig bent, is de logische vraag: kunnen we dat zo algemeen mogelijk maken zodat ook andere doorgankelijkheidsbeperkingen gedetecteerd worden. Bijvoorbeeld wegsoort en -fase (impliciete access), expliciete access tags, oneway.

Ik heb toevallig dit meegemaakt in het wandelroute-netwerk Amstelland, waar de wandelroute (volgens route én in het veld) over een busbaan gaat die expliciet verboden is voor voetgangers. Ik krijg daar in knooppuntnet (terecht) een foutmelding op, en heb dat opgelost door daar melding van te maken via meldpuntroutes. Die stuurden mij van de week dat ze het opgelost hebben, ik zal er binnenkort eens gaan kijken en dan aanpassen op OSM.
Ik weet dat je niet mag mappen voor de renderer, maar mag je wel de ground veranderen voor de renderer?

@vmarc, lees je mee? Kan je hier iets mee?

Tuurlijk. De ontwerpers van wandelnetwerken doen niet anders: intekenen, renderen, uitrollen.

Ze zullen er wel een onderbordje ophangen: Uitgezonderd OSM-ers.

Zeer zeker. Dankjewel!!!

Het is trouwens nog complexer dan dit, want ik doe daar de eenrichtingscode nog niet goed.

Voor draaiende code, zie analyser_osmosis_relation_route_access.py.

Merk op dat trunk voor de fiets als probleem wordt gezien Wel heeft Osmose een simpele manier om een issue te markeren als “false positive” wat knooppuntnet niet heeft zover ik weet.

Deze code draait ook al een tijd, zie voor de output:

http://osmose.openstreetmap.fr/en/errors/?item=3240

Zoek op Land/Provincie en op de link aan het eind van de regel onder het aantal gevonden problemen.
Het totaal aantal problemen (wereldwijd) is iets van 61000, zie http://osmose.openstreetmap.fr/en/errors/graph.png?item=3240
Ik ben benieuw of zodra code aan knooppuntnet wordt toegevoegd de stijgende lijn wordt omgebogen.

Nog een punt ter info: brouter, in het default trekking profiel, zal je over elke weg/pad sturen als dat onderdeel is van een fietsroute.

Dan is er dus een tag of een optie in Knooppuntnet nodig om aan te geven dat het een knooppuntenroute is die tijdelijk tijdens de werkzaamheden niet toegankelijk is en dus een onoplosbare fout in de analyse zal geven.

Er zijn nu op enkele plekken knooppuntenroutes omgezet naar lcn op dergelijke locaties, een work-around die eigenlijk fout is. Als highway=construction fouten oplevert, zal het verleidelijk zijn om veel meer routes zo te taggen om niet oplosbare fouten toch op te lossen. Dat lijkt me zeer onwenselijk omdat het in principe foutieve tagging is en het daardoor het kaartbeeld op bijvoorbeeld Waymarkedtrails verpest.

?? Dat is toch precies wat highway=construction doet ?? Bedoel je dat Analyse hem dan niet als fout moet tellen? Maar hij kan er ook niet over gaan plannen, de route is niet bruikbaar, volgens de tags van de wegen.

Je kan natuurlijk altijd een note op de relatie zetten.
Voor sommige checks werkt een fixme ongeveer zo denk ik?

Ik heb wel eens gedacht dat het handig zou zijn om bij de “feiten” te kunnen aangeven dat het een bekend probleem is. Dan zou er in de foutenlijstjes een groen sterretje of zo bij kunnen staan, misschien ook apart tellen. Maar dat is dan weer lastig gesynchroniseerd te houden met OSM denk ik.

Het probleem is dat je op Knooppuntnet niet wil dat de oplosbare fouten niet meer vindbaar zijn tussen onoplosbare fouten.

Stel dat er 52 knooppuntenroutes in Nederland over een highway=construction lopen en daardoor tijdelijk niet toegankelijk zijn. Dan staan er 52 routes bij ‘Route niet toegankelijk’ die niet op te lossen zijn en pas zullen verdwijnen als de wegwerkzaamheden voorbij zijn. Als er dan ook 2 routes over de weg lopen in plaats van het fietspad, dan zijn die twee oplosbare fouten nauwelijks vindbaar in de lijst met in totaal 54 ontoegankelijke routes.

In de huidige situatie wordt een fietsroute over highway=construction niet als een probleem gezien, waardoor slechts die twee foutieve routes in de lijst met ontoegankelijke routes staan en de fouten dus snel opgelost kunnen worden.

Ik ben het voor 200% met je eens.
Dat is al voortdurend mijn vrees, sinds dit topic gestart werd.
Nu al is de foutlijst niet goed werkbaar meer en met extra controles en nog meer niet oplosbare fouten, kunnen we knooppuntnet.nl gelijk wel in de bittenbak gooien.
Nu al moet ik onthouden dat bij rcn NL er 6 fouten zijn voor Overbodige segmenten en 4 sorteerfouten, die voor eeuwig in de foutlijst blijven staan. Bij het rwn is het nog erger.

Op known bug zetten, gebeurt nu al, in feite is de melding route met fixme=incomplete zoiets

Als een route op de weg wel bestaat maar niet toegankelijk is, dan is het toch goed dat dat een melding oplevert en dat die route dan in de planner dan niet gebruikt kan worden?

Ik ben het er wel mee eens dat als er een verklaarbare fout is die nu niet opgelost kan worden, dat het fijn zou zijn om dat in Knooppuntnet te kunnen onderscheiden. Zeker als die route dan in 3 verschillende checks allemaal als fout genoemd wordt. Bij wandelen is het inderdaad erger, omdat het daar nou eenmaal om veel meer routes gaat en het mede daardoor ook minder strak onderhouden wordt.

Ik kijk daarom meestal naar een kleiner gebied via de adminlevel-hiërarchie, dan heb je niet zo’n last van veel onoplosbare “feiten”. Maar het zou fijn zijn om ook groter te kunnen kijken, en het aantal oplosbare feiten systematisch op 0 te kunnen houden.

Enhancement issue inschieten bij Knooppuntnet, voor een volgende release?

Als we het heel konkreet kunnen maken is het misschien niet heel moeilijk, en het is wel belangrijk voor de onderhoudbaarheid.

Ik zou voorstander zijn om de nieuwe checks tegelijk met de functionaliteit om een probleem zo te markeren dat niet (verschillende) mensen er steeds opnieuw en opnieuw naar kijken. Je weet nooit hoe lang de implementatie van z’n feature duurt en het risico bestaat dat zonder mensen het gaan laten liggen omdat er te veel false-positives in zitten.

De check geeft een echt probleem aan, dus het is niet valspositief, lijkt mij. Anders moet de check verbeterd worden. Alleen zou je sommige feiten niet de hele tijd terug willen zien omdat je er toch niks aan kan doen. Als de route over wegen gaat waar geen access is, denk ik dat er wel degelijk een verhelpbaar probleem is.

Als de toegang versperd is wegens construction, dan zou je dat liever niet de hele tijd in de “werklijst” zien staan. Maar je wil het wel kúnnen zien, want het moet af en toe wel degelijk opnieuw bekeken worden net als die fixme’s.
Vaak staat er wel iets in de note, maar daar kan je volgens mij niks op bouwen, want vrije tekst. Bij fixme’s kan je nog wel een codewoord afspreken, maar construction is denk ik niet fixme. Of toch?

fixme= is dat wat? Dan zou hij tot die datum onderdrukt kunnen worden in de lijstjes, maar als je hem aanklikt zie je wel wat er aan de hand is. En dan in de planner niet planbaar maken, want immers onderbroken.

Hebben we al https://wiki.openstreetmap.org/wiki/Key:opening_date voor, toch?

Hmm…ja… Ja, voor construction op een way, als je echt een redelijke openingsdatum hebt. Dit kan door elke mapper gezet worden en is een (min of meer verifieerbare) eigenschap van het object.

Hier gaat het meer om een willekeurig op dit moment onoplosbaar probleem in een knooppuntroute waarbij je denkt, over 3 maanden of volgend seizoen ga ik nog 's kijken en tot die tijd hoef ik het niet te zien. Dit kan natuurlijk ook door elke mapper gezet worden, maar het is in de praktijk toch beperkt tot een groepje knooppuntadepten. Het is geen eigenschap van het object maar een mappersnotitie.

Denk ik. Ik vind mijn idee zo gek nog niet, en fixme wordt al door Knooppuntnet bekeken.