BRouter-Suspect Scanning: Rule-Set, Limitations, Suspect-Lifecycle, Best-Practices ================================================================================== This is a short writeup on what the BRouter-Suspect-Scanning does and what is the Ruleset that is currently applied. As the suspect-scanning is just done by routing using the car-profile, it is basically the rule-set of the car-profile that takes effect. So there are 2 sections on the rule-set here: - the special logic for the suspect scanning - and the general access logic for brouter car routing A third sections explains the Suspect-Lifecycle. And a final section explains best practices for the corner cases that are not real routing issues, but could be fixed anyhow. Suspect-Scanning-Rules ---------------------- The suspect scanning basically looks for "dead ends" down to highway=tertiary. A dead end can be created by a way that terminates at a node with no routable followup ("dead-end"). Or it can be created by a node that is not routable ("node-block") If the suspect scanning is routing in "inverse mode" (=from destination to start), then it will detect "dead starts" instead of dead ends. Mostly, a dead-end is also a dead start, but when oneways are included, there can be a dead-start which is not a dead end, or vice versa. dead-ends and dead-starts are also recorded if there there actually is a follow-up, but in an unusual angle that does not appear to be an intended routing option ( < -130 degree or > 130 degree ). These suspects are called "sharp-exit" when detected in forward routing and "sharp-entry" when detected in backward routing. There's also the "sharp-link" trigger for cases where the sharp angle in not on a network-node, but on a transfer-node within a way. In addition to dead-ends and dead-starts, there are two more categories of suspects: - "same-priority bad-access branch" ("bad-access") This is the case e.g. when at a node a routable highway=secondary hits a non-routable highway=secondary, but there is a third routable option, so that it's not a dead end For highway=construction, the priority is taken from the "construction=" tagging, so also a touching equal-priority construction triggers "bad-access". Note that "psv" and "hov" access modes are excluded from the analysis. - unknown access tagging: in case the scanner sees an effective access tag that is not known to BRouter at all (e.g. "motor_vehicle=only_red_and_blue_cars_allowed"), a suspect is generated no matter how it is touching the routable network ("unknown-access") An unclassified construction (highway=construction without construction=) also triggers "unkown-access" The suspects manager shows the list of triggers in the suspect-detail page, to give you an idea what could be wrong. There are cases where you just don't see the inconsistency and you cannot find a routing problem. In most of these cases, the reason are invisible "dangling" highway sections that have the dead-end. Or it's a small bi-directional way section that can only be traversed in one direction. Not all nodes that fullfill a suspect condition can be detected, e.g. nodes inside a routing island are not reached. Furthermore suspects ca only be generaded if the routing reaches a node as a "virgin node" that was not yet reached along another path. This is not really a bug, but a feature, because it limits the suspects to those that are really releavnt to routing. One last notice: as the scanning works by random routings, not all suspects are found in every scan. BRouter-Routing-Rules --------------------- The basic principle is to be PESSIMISTIC. So if there's any access-tag that is not known to brouter, it is treated as not allowed. Common cases here that create unintended locks are: - access=yes|yes|no (mixed up from lane-tagging, should be access:lanes) - access=unknown - vehicle=no_trucks - motor_vehicle=conditional:09:00@no (mixed up from conditional tagging) Exception is destination-access. This is currently appleed by the router, bot not in standard suspect scanning. However, there's a special run "strict" that considers destination-access as unroutable and triggers suspects for destination-access on highway=tertiary and up. One exception to being pessimistic is that the implicit "oneway=yes" on highway=motorway (not on highway=motorway_link !) is not (yet) applied by brouter. So some of the suspects originating from this are false-positive formally. But not all routers know the implicit "oneway=yes" on highway=motorway, so making that explicit could by a good idea anyhow. Turn-Restrictions: BRouter processes "normal" TRs (with a "via"-node). It does not process TRs with one or more via-ways. The via-node is expected to be a terminating node of both the from- and the to-way. TR-Exceptions are processed for "bicycle" and "motorcar". Only the "execpt" syntax is considered for restricted TRs, "restiction:" is not (yet) recognized. There's also a special analyis on TRs that checks them for consistency ("bad-tr") Inconsistent TRs could have an angle-contradiction (e.g. "only_left_turn" for a geometry turning right), or one of the "from" or "to" members not terminating on the via-node, or missing or excessive members. Suspect-Lifecycle ----------------- The primary key of suspects is the geo-location of the suspect node. Suspects are born when they are first detected for that geo-location. Then they have the state "NEW". If they are re-detected on the next scan, and there was no action yet, they become "ARCHIVED". After reviewing a suspect, first you have the choice to either mark them as "FALSE POSITIVE". False positive suspects disapear forever, as long as the suspected nodes are not moved. To be able to mark a suspect false-positive, you must have done 4 test-rouings via BRouter-Web within a distance of about 3km of a suspect node. Or you can mark the suspect as "CONFIRMED" to say: yes, there's an issue that shouldn't remain forever in the map. An issue here can be a real error, or e.g. construcion that you expect to be temporary and wan't to review again at a later time. After confirming a suspect to be an issue, you get new choices to either mark it as "FIXED" to say: I either fixed the issue and don't expect it to be re-detected in the next scan. Or I wrote a Note or a changeset comment and I want to review the suspect again after the next scan, because I expect to have new information at that time. Another option for confirmed suspects is to "HIDE" the suspect for a specified time. This is the best choice for constructions where you can find an estimate for the end-date. Just hide the suspect to a time near or after this end date, so you will be re-notified the construction is still in the map after it disappeared in reality. Another reason for hiding an issue is when you have created a note or a changeset-comment, but consider that a minor issue: hust hide it for 4 weeks, and if after that time you got no answer, it's safe to revert the edit.