OpenStreetMap Forum

Martin Borsje

Moderator

From: Puth

Registered: 2011-10-22

Posts: 3,187

Re: Access logica voor fietsen

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?

JeroenHoek

Member

Registered: 2014-06-22

Posts: 1,029

Re: Access logica voor fietsen

Het zou dan denk ik handig zijn als die functie (per  OR evaluatie) kapt zodra hij een False tegenkomt. Dan hoe je niet alle mogelijke kombinaties van tags en waarden volledig uit te schrijven.

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.

Peter Elderson

Member

From: Nieuwerkerk aan de IJssel

Registered: 2018-02-08

Posts: 2,201

Re: Access logica voor fietsen

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?

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.

IIVQ

Member

Registered: 2014-11-12

Posts: 909

Re: Access logica voor fietsen

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?

Peter Elderson

Member

From: Nieuwerkerk aan de IJssel

Registered: 2018-02-08

Posts: 2,201

Re: Access logica voor fietsen

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

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

Peter Elderson

Member

From: Nieuwerkerk aan de IJssel

Registered: 2018-02-08

Posts: 2,201

Re: Access logica voor fietsen

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?

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

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

Last edited by Peter Elderson (2021-04-11 10:09:34)

vmarc

Member

Registered: 2015-07-16

Posts: 47

Re: Access logica voor fietsen

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

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

Zeer zeker. Dankjewel!!!

JeroenHoek

Member

Registered: 2014-06-22

Posts: 1,029

Re: Access logica voor fietsen

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

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

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

emvee

Member

From: Rotterdam, The Netherlands

Registered: 2010-07-27

Posts: 268

Re: Access logica voor fietsen

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/error … ?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.

A67-A67

Member

Registered: 2014-04-08

Posts: 783

Re: Access logica voor fietsen

Als je allerlei foutmeldingen van fietsroutes bij grote wegwerkzaamheden wil verkomen, zou ik net als nu de highway=construction toegestaan laten.

Waarschuwingen zijn goed. Je hoeft er niet op te acteren immers. Als een tool een mogelijk probleem detecteert aan de hand van logica dan rapporteert deze dat aan de gebruiker van de tool.

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.

Peter Elderson

Member

From: Nieuwerkerk aan de IJssel

Registered: 2018-02-08

Posts: 2,201

Re: Access logica voor fietsen

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.

?? 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.

A67-A67

Member

Registered: 2014-04-08

Posts: 783

Re: Access logica voor fietsen

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.

dvdhoven

Member

From: Deventer Colmschate

Registered: 2015-03-09

Posts: 2,591

Re: Access logica voor fietsen

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

Last edited by dvdhoven (2021-04-12 07:43:39)

---

Dick van den Hoven

Peter Elderson

Member

From: Nieuwerkerk aan de IJssel

Registered: 2018-02-08

Posts: 2,201

Re: Access logica voor fietsen

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.

Last edited by Peter Elderson (2021-04-14 20:08:36)

emvee

Member

From: Rotterdam, The Netherlands

Registered: 2010-07-27

Posts: 268

Re: Access logica voor fietsen

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.

Peter Elderson

Member

From: Nieuwerkerk aan de IJssel

Registered: 2018-02-08

Posts: 2,201

Re: Access logica voor fietsen

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=<verwachte datum> 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.

Last edited by Peter Elderson (2021-04-14 21:56:45)

Sander H

Member

From: Oostvoorne

Registered: 2013-05-19

Posts: 1,615

Re: Access logica voor fietsen

fixme=<verwachte datum> 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?

Peter Elderson

Member

From: Nieuwerkerk aan de IJssel

Registered: 2018-02-08

Posts: 2,201

Re: Access logica voor fietsen

fixme=<verwachte datum> 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.