glossary - poutnikl/Brouter-profiles GitHub Wiki

TOP

-A- -B- -C- -D- -E- -F- -G- -H- -I- -J- -K- -L- -M- -N- -O- -P- -Q- -R- -S- -T- -U- -V- -W- -X- -Y- -Z-

A

  • A* / A-star algorithm is an algorithm widely used for route computation.
    • It estimates the total route length using known length of the computed partial route and remaining air-distance to destination.
    • EstimatedTotalRouteCost = PartialRouteCost + HeuristicCoefficient * RemainingAirDistance.
    • HeuristicCoefficient is equal to 1 for original A*, guaranteeing to compute the shortest route if cost/_length >= 1.
    • In routing implementations, real way length is substituted by the "Equivalent length" to express prioritization of ways. Longer the Equivalent length, less likely to be chosen.
    • With increasing "spread" = (Average(Cost/airdistance) - 1 ), the performance of the A* decreases. As it underestimates the remaining cost of route variants. This is affected by route_length/airdistance ration, Costfactor)>0 and ElevationCost.
    • E.g. let suppose the average totalcost/airdistance ratio = 2.0 ( easy to achieve ), Start-destination air distance 400 km. Then at the worst circumstances ( straight flat road with CF=1.0), the route calculation can go up to 200 km in the opposite directions before it is concluded this is not the optimal route. Formally correct, otherwise insane.
    • Brouter uses for the 1st pass a modified version of the algorithm, using a heuristic coefficient Pass1coefficient > 1. It speeds up the first pass, but increases probability the optimal routes is missed.
    • For use of 1pass only routing, my experience says Pass1Coefficient = SafetyCoef * (cost/distance) , with SafetyCoef 0.5-0.7 is still good.
    • My approach is, "optimal routing" and "routing providing the optimal route" are 2 different things. As the former takes into considerations other factors too, like calculation time ( fast enough ) and required resouces ( no crashes nor freezing ).

TOP

B

  • Brouter is a 3rd party standalone Android Application. Its primary purpose was bicycle targetted offline routing service for Map software like OSMAnd, LocusMap and OruxMaps, and generation GPX based traveling route files. But is was revealed BRouter is usable for hiking as well and with some limitations for cars as well. See Setting up the Android App and Brouter KitKat(A4.4+) survival guide.
    The BRouter is natively elevation aware, able to give penalties to slopes. It can even evaluate all OSM ways differently, if on flat, uphill or downhill. E.g. it can promote main roads for downhill fast ride, while penalize it for uphill climbing. Or penalize rough surface difficult to climb up or ride down. This and its powerful scripting makes BRouter a quite unique bicycle router, able to consider near all OSM tagging, related to the travel quality.

  • Brouter-web service is an online brother of Brouter app, being a web frontend for BRouter. It is useful for

    • Online interactive route planning with viapoints and nogo areas
    • GPX track generation for GPX aware navigation/guidance applications.(Typically OSMAnd, LocusMap or OruxMaps )
    • Brouter profile testing - You can test the profiles online by pasting the profile text content to bottom left paste field + pressing UPLOAD button. It then appears as Custom profile, aside of predefined ones. Notice the changelog comments at top and bottom of the profile code. Be aware if you need BRouter web to generate navigation instructions, you have to change turnInstructionMode.

  • BRouter profile is plain text script-like file, defining how the priority of a particular way segment is calculated. See e.g. the standard reference Trekking profile from BRouter/BRouter-web internal profile set.

TOP

C

Format description format for search full format
degrees decimal minutes N 40 26.767, W 79 58.933 N 40°26.767', W 79°58.933'
degrees decimal minutes 40 26.767 N, 79 58.933 W 40° 26.767' N 79° 58.933' W
degrees decimal seconds N 40 26 46 W 79 58 56 N 40° 26' 46?, W 79° 58' 56?
degrees decimal seconds 40 26 46 N 79 58 56 W 40° 26' 46? N, 79° 58' 56? W
degrees decimal N 40.446° W 79.982°
degrees decimal 40.446° N 79.982° W
degrees decimal 12.34, 56.78 [12.456,-78.90]

  • Costfactor(CF) is the BRouter feature defining the way priority or preference to be chosen. It has a numeric value and for an ideal way CF=1.0 . Ways with lower priority have a higher CF and are taken as if they were longer than they are.

    • CF is proportionality constant for EL = CF . L,
      • where L is the physical length of the way segment.
      • EF is the equivalent length of perfect way the BRouter would take as equally good.
    • 15 km of a perfect way with CF=1 is taken as equally long as 5 km of a bad way with CF=3.
    • if CF >= 10000, the way is considered as forbidden, and its passing is not evaluated during route searching. In fact, Brouter pretends such a way does not physically exist. As a side effect, it simplifies the road network and speeds up the routing. It can be e.g.a motorway or an unpaved way, if you have chosen avoiding motorways or unpaved ways for any cost.
    • if CF = 9999, the way is processed as above, but is considered by navigation hint generator. It addresses navigation hint confusion a roundabouts, when BRouter pretended a way does not exist.
    • if CF < 9999, but >> 1.0, the way is allowed for routing, but due very high cost is usually chosen as the last option only.
    • If a route segment is forbidden for bicycle ride, but pedestrians are allowed, the bicycle routing is still allowed, with costfactor at least 5. It takes than 200 m of leading a bicycle as at least 1000 m of bicycle ride.
    • CF is not the only parameter affecting the final Equivalent length of the way, but additional parameters Turncost, InitialCost and ElevationCost are added.
    • Average CF is desired to keep close to 1.0, to allow good enough performance of the A star routing algorithm.

  • Cycleroutes are publicly recommended bicycle routes, marked in tourist maps and by physical way signs. In OSM context, they come in 4 classes. The former two are in context of my profile considered as local cycleroutes ones( by default ), the latter two as long distance cycleroutes.

    • Local cycleroute network ( LCN ), Regional cycleroute network ( RCN )
    • National cycleroute network ( NCN ), International cycleroute network ( ICN )
    • See also Cycleroute-preference on Wiki

  • cycleroute_pref is numeric parameter managing level of cycleroute preferences in Poutnik's profiles.

TOP

D

  • Downhillcost is the BRouter feature, expressing the penalty for elevation change in form of an additional length-like term in total equivalent length of the way segment. The downhillcutoff is subtracted from the way slope before calculation.

    • Typical value is 60. i.e. 100 m elevation difference is taken as 6 km of equivalent length.
    • Be aware that elevation management parameters are in my bicycle/Hiking profiles calculated, so manual modification may have undesired side effects.

  • Downhillcostfactor ( not to be confused with downhillcost ) is Costfactor, that is used for a way going downhill ( slope > downhillcutoff. Its is by default equal to Costfactor. It may be calculated independently on the Costfactor, either just as a modification of the Costfactor value.

  • Downhillcutoff as the BRouter feature is the percent threshold, under which the ways are considered flat, i.e. not downhill. Typical value is 1.5. Note that all ways with the slope within range Downhillcutoff-Uphillcutoff are considered as flat terrain roads.

  • Downhillcutoffvalue / Downhillcostvalue are custom variables specific for my bicycle profiles. The integer value of the profile variable Hills determines which set of Up/Downhillcutoffvalue / Up/Downhillcostvalue are used. Their meaning is the same as of the Brouter counterparts Up/Downhillcutoff / Up/Downhillcost. The difference is, they are not used by Brouter directly, but by a profile itself as raw values. The final values of BRouter parameters Up/Downhillcutoff/cost are calculated with usage of other parameters like MTB_factor.

TOP

E

  • Elevation Buffer is BRouter feature to filter elevation noise along the route. It may be real, or caused by the artefacts of used SRTM elevation data.

    • From every elevation change is at the first place cut out amount 10*up/downhillcutoff per every km of the way length. What remains, starts to accumulate in the buffer. IF cutoff demand of elevation per length is not saturated from incoming elevation, it is applied on elevation remaining in the buffer as well.
    • E.g. if the way climbs 20 m along 500 m, and uphillcutoff=3.0, then 10*3.0*0.5 = 15 m is taken away and only remaining 5 m accumulates. But if it climbed only 10 m on those 500m, all 10 m would be "swallowed" by cutoff, together with up to 5 m from the buffer, if there were any.
    • When elevation does not fit the buffer of size elevationmaxbuffer, it is converted by up/downhillcost ratio to Elevationcost portion of Equivalentlength. Up/downhillcostfactors are used, if defined, otherwise CostFactor is used.
    • elevationpenaltybuffer is BRouter variable, with default value 5(m) : The variable value is used for 2 purposes:
      • With the buffer content > elevationpenaltybuffer, it starts partially convert the buffered elevation to ElevationCost by Up/downhillcost,
        with elevation taken = MIN (Buffer - elevationpenaltybuffer, WayLength[km] * elevationbufferreduce*10
      • The Up/downhillcost factor takes place instead of costfactor at the percantage of how much is WayLength[km] * elevationbufferreduce*10 is saturated by the buffer content above elevationpenaltybuffer.
    • elevationmaxbuffer - default 10(m) - is the size of the buffer, above which all elevation is converted to Elevationcost by Up/Downhillcost ratio, and - if defined - Up/downhillcostfactor fully replaces Costfactor in way cost calculation.
    • elevationbufferreduce - default 0(slope%)- is rate of conversion of the buffer content above elevationpenaltybuffer to ElevationCost. For a way of length L, the amount of converted elevation is L[km] *elevationbufferreduce[%]*10. The elevation to Elevationcost conversion ratio is given by Up/downhillcost
    • Let examine steady slopes with elevationmaxbuffer=10, elevationpenaltybuffer=5, elevationbufferreduce=0.5, cutoffs=1.5, Up/downhillcosts=60
      • All slopes within 0 .. 1.5% are swallowed by the cutoff
      • For slope 1.75%, there will remain 0.25%. That saturates the elevationbufferreduce 0.5% by 50%. That gives Way cost to be calculated 50% from costfactor and 50% from Up/downhillcostfactor. Additionally, 0.25% gives 2.5 m per 1km, converted to 2.5*60 = 150m of Elevationcost.
      • For slope 2.0%, there will remain 0.5%. That saturates the elevationbufferreduce 0.5% by 100%. That gives Way cost to be calculated fully from Up/downhillcostfactor. Additionally, 0.5% gives 5 m per 1km, converted to 5*60 = 300m of Elevationcost. Up to slope 2.0% the buffer value stays at 5m = elevationpenaltybuffer.
      • For slope 2.5%, there will remain 1.0% after cutoff subtract, and 0.5% after the buffer reduce subtract. The remaining 0.5% accumulates in the buffer by rate 5 m/km. When the buffer is full (elevationmaxbuffer), the elevation transforms to elevationcost by full rate of 1.0%, i.e. 10 m/km, giving elevationcost 10*60=600 m/km.

  • Elevationcost is an additional cost added to the way cost, making a term of the way Equivalent length . It is proportionality constant, converting elevation difference to extra distance. Typical value 60 makes an extra distance 600 m for 10 m of elevation change, it it depends also on other factors. It is calculated as:

    • ElevationCost = WayPhysicalLength * up(down)hillcost * AverageslopeAfterCutoffSubtract/100
    • AverageslopeAfterCutoffSubtract = max(0,abs(elevation_difference)/WayPhysicalLength*100 - up(down)hillcutoff)

  • Equivalent length of a OSM way segment is the length of the ideal way with optimal costfactor=1.0, zero initialcost, zero turncost and zero elevationcost, that would be for the routing algorithm equally good to take. It is calculated as EL = CF . L + IC + total TC + EC, where

TOP

F

TOP

G

  • Guidance(Locus) is used in several closely related meanings:
    • Following the route along OSM ways or in free terrains in point to point way.
    • Visual / voice instructions related to reaching next point. Instructions consider just the context of the routepoint serie, ignoring eventual OSM way network.
    • See also Navigation

TOP

H

  • hills is a numeric parameter of my Brouter bike profiles, used for choosing a predefined set of elevation parameters. Be aware of MTB_factor effects.
assign hills N meaning
0 Standard Trekking profile default with downhillcutoff/cost 1.5/60, uphillcutoff/cost 1.5/0.
1 Trekking-dry profile default. It additionally penalizes steeper uphills over 3% with uphillcutoff/cost 3.0/70
2 Avoids hills, inspired by recumbent/velomobile profiles. Uses low up/downhillcutoff (1.0/0.5) and high costs (80). Useful for long distance heavy loaded trekking.
3 Experimental to get the fastest route. Not finished, considers just elevations, but not surfaces in context of speed impact. Not intended for regular use.
4 Experimental valley mode on a user demand. It prefers flat roads along valleys as long as possible, even at expense of steep climb at escapes from valleys. It combines non standard usage of both elevation cost and up/down hillcostfactors. E.g.: 40 km of flat road and 5 km of 10% climbing is preferred to 20 km of flats and 25 km of 2% climbing. Not intended for regular use.

TOP

I

  • ICN means International Cycleroute Network

  • Ignore_cycleroutes is flag of standard Trekking profile. If set to 1/true, it ignores routes marking, taking them as if not marked. It is used in the standard profile Trekking-ignore-cr. My profiles use alternative implementation as the numeric parameter cycleroute_pref 0.0.

  • Initialclassifier is auxililiary BRouter variablerelated to the InitialCost for a way segment. The Initialcost of the way is applied only if the InitialClassifier value differs from the one of the previous way segment. If the Initialclassifier is not defined, the costfactor is used instead.

  • InitialCost is a BRouter profile feature, defining one time cost of a way or a node in the Equivalent length. It may serve for real well estimated delays, like for ferries, toll points, traffic lights. Or it may served as estimated penalty for a scenario temporary slow down, like dense network of narrow residential roads.

    • If node Initialcost is >= 1000000, the node is considered as forbidden, and the passing through is not evaluated during route searching. It may be e.g. a toll point when you want a toll-free route. TOP

  • iswet is a flag parameter in my bike/foot profile, turned ON in the profiles applicable during wet conditions. It shifts OSM way preferences in favor of paved surfaces, but without attempt to avoid them.

TOP

J

TOP

K

TOP

L

  • LCN means Local Cycleroute Network

  • Local cycleroutes are cycleroutes defined in context of my profiles as local by routelevel parameter, by default LCN and RCN. Their preference is somewhere in the middle of non cycleroute and long distance cycleroute. See Marked-routes

  • Locus/LocusMap is one of 3 BRouter-aware Android GPS map applications.
    The BRouter can be involved in Locus route creation procedures by several ways :

    • 1/ 3rd party offline routing service: The user defines in the Locus naavigation settings BRouter as the navigation routing service, similarly as online services like Mapquest. For defined start, destination and optionally 2 viapoints it calculates a bicycle route, according to assigned BRouter routing profile.
    • 2/ Add new route & measure: this Locus feature allows hybrid automatic/manual approach. The user can define manually the route points in a sparse manner, while BRouter calculates the route and add points between the 2 manually added points. It saves a lot of waypoint manual addition.
    • 3/ Alternative Route Planning with BRouter:
      • Define in Locus ( the best in dedicated BRouter waypoint folder ) special waypoints(favourites) called "from" , "to", optionally "via1" .. "via9". Locus Pro users can use the convenient point creation by Locus Quick points.
      • Launch the BRouter application. Brouter searches the Locus waypoints database for the points with the above names. If it finds them, it takes those points as implicitly defined route.
      • BRouter then generates the GPX file, based on the BRouter profile the user had manually chosen.
      • The user imports GPX to Locus and set Locus to navigate along the route, that already contains turning navigation hints.
    • 4/ The user runs directly Brouter and chooses any waypoints from the Locus waypoint DB to define the route. The rest is as at 3/.
    • 5/ The user uses BRouter-web to define the route interactivel and then generates and downloads generated GPX route file. The rest is like /3 and /4.
  • Long distance cycleroutes are in context of my profiles the routes determined as long distance by routelevel parameter, by default NCN and ICN - see cycleroutes and Marked routes

TOP

M

  • Main road is any way marked in OSM as highway=unclassified or better.

  • Mapping, also OSM mapping, is procedure how to properly record the physical and logical state of real terrain and ways in the OSM (Openstreetmap database.))

  • MTB_factor is numeric parameter shifting priorities of ways according to supposed rider preferences. It gradually evolved in the aggregation of several effects linked to the single parameter.

    • Original intention was shifting preferences toward unpaved tracks/paths - see MTB_factor-and-smallpaved_factor and Trekking-MTB-Profiles---legend.
    • Later was added weakening hesitance toward hills and surface pass ability ( smoothness, MTB scale ).
    • Recently was added weakening hesitance toward fords and decreasing turncosts ( can become negative )
    • See Interactive tweaking tool for the combined effect of MTB_factor + smallpaved_factor + unifactoradjust on the final value of univ_factor_coef, that is used for tweaking of profile behavious toward various road class/quality.

  • MTB:scale is OSM tag describing difficulties of MTB trails in similar 6 level scale as SAC scale.

TOP

N

  • Navigation can be used in several related but distinguished meanings: * a) a routing service, offering generation of a route to follow. It may be : * native to the application * external online service like MapQuest or OSRM * offline like BRouter of Graphhopper * b) An application feature, using a) * c) An application, offering b) * d) Procedure using such a service to create such a route * e} Following such a route, usually with help of icon / voice hints about turns at intersections/junctions.

  • Navigation point is a routepoint provided with navigation hint/instruction like "turn left" or "stay in right lane"". The instruction if often coded and provided with extra verbose comments. Particular implementation can keep navigation points as an extra information within GPX file, like GPX for Locus. Hints may be interpreted by target application as voice a/o icon hint.

  • NCN means National Cycleroute Network

  • Nogo point is a Brouter feature restricting the area allowed to be routed through. Brouter analyzes the waypoint database of the target application. If it finds a waypoint called "nogo[N][ name]", it defines a "nogo" zone of radius N meters ( by default 20m), optionally named for the user convenience. BRouter avoids routing via such nogo zones at any cost. I recommend to create in Locus a dedicated Nogos folder, similarly as a folder for from / to / viaN points for implicit route definition. Brouter-web allows to create one-time nogo points during interactive GPX route creation.

  • NotTooSteep is an exterimental hill mode (hills=6), trying to cutoff too steep hills by a trick with a very high uphillcostfactor

    • slope below TooSteepUphill ( % ) has no penalization
    • hilly penalization is done by uphillcostfactor and downhillcost, not by uphillcost.
    • TooSteepUphillCost can be used optionally, but is rather overrun by the uphillcostfactor.
    • BRouter variable uphillcostfactor is used for uphill slope > TooSteepUphill + TooSteepbufferreduce
      with the transient zone TooSteepUphill .. TooSteepUphill + TooSteepbufferreduce. There is normal costfactor for uphill scope <= TooSteepUphill and uphillcostfactor = TooSteepCostFactor for uphill scope >= TooSteepUphill + TooSteepbufferreduce
    • TooSteepbufferreduce is the width of the uphill scope transient zone
    • Altitude buffer to catch steep SRTM artefacts has to be high enough, otherwise it may suggest an over the hill route instead of a flat route along the river, with very steep SRTM artefacts, like thr route From Obrany to Bilovice at NE border of Brno, Czech Republic, if TooSteepPenaltybuffer = only 10.0 ( BRouter default is 5.0 ) http://brouter.de/brouter-web/#map=14/49.2412/16.6745/standard&lonlats=16.649287,49.227407;16.674995,49.245971
    • Altitude buffer TooSteepMaxbuffer is mainly for downhills for downhills, does not affect uphill penalization with zero uphillcost.

TOP

O

  • OSM = OpenStreetMap is community based vector world map and vector map data management.

TOP

P

  • path_preference is the Trekking-Poutnik template numerical parameter, 0.0 as default, Used 0.0..20.0. It progressively penalizes OSM ways better than unpaved paths.( for MTB-like only ). It means better roads are penalized more. Indirectly defines a type of a road within univ_factor_coef_raw that is taken as neutral by MTB_factor and optimal by smallpaved_factor.

    • It shifts neutral univ_factor_coef=0 to value UnifactorAdjust so
    • if univ_factor_coef>0 then MTB like ways progressively become "MTB factor neutral" and "smallroad factor optimal".
    • if univ_factor_coef<0 then major road like ways become "MTB factor neutral" and "smallroad factor optimal".

  • Pass1coefficient, Pass2coefficient are parameters for the BRouter 2 pass routing, affecting speed, resource demand and optimality of routing.

    • The 1st pass makes rather a quick and dirty shoot to find some route, that may not be the optimal one.
    • The 1st pass Pass1coefficient is the a priori estimation of the average route cost per the unit of airdistance. It is used in formula
      EstimatedRouteCost = StartToNodePartialCost + Pass1coefficient . AirDistanceToDestination where StartToNodePartialCost is partial route evaluation from the start to the examined node. The point with the least EstimatedRouteCost value is taken as the most promising for further evaluation.
    • There is granted to find the optimal route, if the passcoeefficient<=1, but it is slow and memory hungry for longer distances a/o high map density.
    • The values >1 and <1.2-1.3 may be still considered quite safe for longer distances, as the shortest route is statistically typically 1.2-1.3 times longer than the airdistance to the destination.
    • Values >1.2-1.3, if greater than average cost/distance ratio, bring unjustified preference of points closer to destination, as they overestimate the "future cost" of the remaining not yet evaluated route. Too high pass1coefficient is a danger for 1 pass only scenario, OTOH it can be advantage for 2 pass scenario, as finding a route fast is more important than finding the optimal one.
    • The higher the average costfactor is, and more hilly the region is, the higher pass1coeficient you can afford.
    • With sufficiently low pass1coefficient you may afford avoiding the 2nd pass.
    • The 2nd pass is slower, but guarantees finding optimal route. The pat finding algorithm is the Dijkstra, but it employes the A* formula pastcost + remainingdistance for the different, tricky purpose. If the given node is proven not being able to provide better route than the 1st pass result, it is thrown away. It is equivalent to A* algorithm, but is more memory efficient.
    • The values for the Pass2coefficient are used either -1 = disabled or 0 = enabled.
    • Note the Optimal routing and Routing finding the optimal route may not be the same, especially for very long distances ....

  • Poutník is a Czech word for ein Wanderer or a pilgrim/long range (foot) traveller, usually used in religious or outdoor contexts. It is closely related to the famous Russian word "Sputnik" with weaning of the co-travelling mate of the Earth. The terms share the Slavic word root "put", what means a journey or pilgrimage.

  • Priorityclassifier is a BRouter numerical parameter calculated for ways and used for generation of pictogram/voice navigation instructions. Higher values means the more significant(=noticeable) way, AFA it can be predicted from OSM data. To avoid navigation instruction flood, the BRouter author ( Arndt Brenschede ) decided the instructions are provided only if:

    • You are supposed to turn at a crossroad/junction and the other alternatives have the same or higher priority.
    • You are supposed to go straight ahead and some of other alternatives have the higher priority.

  • processUnusedTags (BRouter system variable ) : When BRouter evaluates a route with the given profiles, it ignores by default the OSM tags that are not explicitly evaluated by the profile. It speeds up the routing process and saves the memory. But it has the sideeffect that you do not see these tags in the evaluation table ( the table icon on Browser-web), nor in the CSV export of the evaluation. If you do need these tags e.g. for the OSM data inspection purpose, you can used in the profile global context the code "assign processUnusedTags = true".

  • Profile - also Brouter profile - is a script-like text file, describing the procedure how a particular way or a map feature are evaluated during the searching for the optimal route generation. It is like a computer program computing the preferences for the evaluated way segment.

    • All my profiles are derived from universal templates for hiking / biking / car driving respectively by switching logical flags a/o by changing numerical parameters. These changes tweak the profile behavior. The final profiles are given more or less self-explaining names, with short comments in the profile header comments.

TOP

R

  • RCN means Regional Cycleroute Network

  • road_restrictions is a numeric parameter of my car profiles. In contrary to flags avoid_toll, avoid_motorways, avoid_unpaved, its primarily purpose it to limit range of considered ways to increase routing speed.

road_restrictions value Meaning Comment
1 No restriction ( avoid_toll/motorways/unpaved still can take place)
2 Avoids unpavedways Equivalent to avoid_unpaved
3 Minor roads Only mainroads and urban roads, no paved tracks
4 Tertiary roads Only highway=tertiary(link) and better. For values 4-6, only 1 pass is performed.
5 Secondary roads Only highway=Secondary(link) and better.
6 Primary roads Only highway=Primary(link) and better.

  • Roughness is a a parameter of my profile, combining values of MTB scale and Smoothness(as fallback)

  • Route is a collection of start, destination and set of viapoints, prepared during planning a trip over the paper map, later for GPS navigation system.

  • Routing term can be seen in 2 contexts : 1/Generating a route/track 2/ Guiding along such route.
    The routing / or just route generation can be done by one of the 3 ways:

    • By the Android application BRouter itself from Google Play ( just route generation )
    • By Android GPS navigation application OSMAnd, Locus and OruxMaps
      • via routing service API, that call BRouter internally.
      • via navigation along imported BRouter GPX route(track)
    • By BRouter Web Desktop Frontend - useful for profile testing, route planning and GPX exports

  • Routing service is an online or offline(installed on android device) service, generating for given start, destination and optionally viapoints the detailed sequence of routepoints to go through, often with navigation hints for crossroad/junction turning.

TOP

S

  • SAC scale is OSM map tag describing mountain trail difficulties according to alpine standards.

  • smallpaved_factor is numeric parameter decreasing priorities of ways far from being small paved road.

    • See Interactive tweaking tool for the combined effect of MTB_factor + smallpaved_factor + unifactoradjust on the final value of univ_factor_coef, that is used for tweaking of profile behavious toward various road class/quality.

  • Smoothness is the OSM tag to evaluate physical usability for vehicles. combined with MTB:scale, it is used to evaluate driving conditions.

  • SRTM stands for "Shuttle Radar Topography Mission" and was a space program of a radar survey of the Earth surface elevation by radar reflection. Originally it had resolution 90 m, later improved to 30m. Brouter uses the data for elevation evaluation using bilinear interpolation, currently AFAIK the original 90 m resolution.

    • Be aware that SRTM elevation data may be a subject of various artefacts, showing elevation jumps where there are none. It happens if the scanned terrain 90x90 or 30x30 m squares have very variable elevation. In such cases it happens avg elevation differs from real elevation of the way and/or each to other for neighbor squares.
    • Particularly, typical such scenarios are narrow valley, tunnels, bridges, ways in wood, rivers, "urban canyons" with tall buildings.
    • You can view it at this illustrative route segment from the Moravian Karst ( South Moravia, Czech Republic ). In the link to BRouter web you can see an elevation profile on the left. There is like a 20 m elevation drop between 3.5 and 4.0 km, like as 4% downhill slope. But in reality there is a steady mild climbing, it just leaves the very narrow brook wood valley and continues in the open terrain near the villege.

TOP

T

  • Target application is a narrow sense a BRouter aware Android navigation application, currently LocusMap, OSMAnd and Oruxmaps. In wider sense it can be any application able to import and process BRouter route exported in GPX format.

  • Template ( or profile template) is technically the BRouter profile as well, and can be directly used e.g. for experimenting with its settings in the BRouter-web. But its primary use is as a base line for the profile generation. It is usually identical to the default profile for given transportation mode. Other profiles are created by modification its logical flags/switches or numerical parameters.

    • The idea behind the 1 template + many profile is this :
      • "No size fits all" - a single profile always finds a part of its users unsatisfied.
      • Many of them would like to tweak its behavior for them, or for some scenarios.
      • There is implemented tweaking system and several of expected tweaking was given an selfexplaining name of the profile.
      • Much more tweaking combinations is possible, but this is left to advanced users, who know what they want and what they are doing.

  • Trackpoint is a point of a track, an oriented sequence of points marking the passed way as a recorded log.

  • Travel_mode is an experimental numerical parameter under development, serving as an alternative way to tweak of existing tuneable parameters of my Trekking-Poutnik template. All the changes are presented as a single integer number, that is analyzed and parameters are then modified accordingly. It is implemented to override eventual direct parameter settings.

  • Turncost is the Brouter profile feature, addressing slowing down at way curves. Turncost value is the equivalent length for the penalty for the right angle curve(including junctions/crossroads). the value is typically tens(bike) to hundreds of meters(fast roads). The penalty takes into account the curve angle.

    • the turncost penalty is calculated as Turncost(angle) =Turncost * ( 1- cos(angle)), so it goes from 0 for angle=0deg to 2*turncost for angle=180deg.
    • The turncost for the whole way is the sum of turncosts of its curves.
    • Note that Turncost(90) =Turncost is valid only for really rectangular scenario, like rectangular crossroads. Gradually bending curves are usually mapped in OSM as a sequence of several broken roads segments. BRouter evaluates such a gradual 90 degree curve as a sequence of e.g. 4 curves per 22.5 degrees.
    • Interesting effect has negative Turncost value. It decreases the cost of a winding way, compared to the straight but otherwise the same quality way. It may be interesting for motorbikes or bikers, preferring to avoid boring straight ways. Be aware it may have very funny result in city routing cases, especially if too strong. __It was recently realized negative turncosts may cause at very winding a/o short way segments the error: re-tracking a track, probably due violation of minimal way cost. If it occurs, either disable negative values by "assign turncost max 0 <turncost expression)>", either try to used less agressive values. See raised Brouter issue 77 __

  • turnInstructionMode is the BRouter parameter affecting generation of navigation screen/voice instructions.
    assign turnInstructionMode = 1 # 0=none, 1=auto-choose, 2=locus-style, 3=osmand-style

    • 0 generates no instructions(hints)
    • 1 generates instructions ONLY with Android application, with the format of application with last updated favourites. It generates NO hints with BRouter-web. If you use only LocusMap or only OSMAnd, you can with advantage use exclusively the explicit application mode 2 or 3, as Brouter-web will be aware of your application.
    • 2 generates explicitly hints for LocusMap application in both Brouter and BRouter-web
    • 3 generates explicitly hints for OSMAnd application in both Brouter and BRouter-web

TOP

U

  • Uphill(cost|cutoff), Uphillcostfactor, Uphill(cost|cutoff)value - see respective Downhill variants

  • UnifactorAdjust redefines the the position of the neutral point of Univ_factor_coef, that is not affected by changes of MTB_factor nor Smallpaved_factor * See Interactive tweaking tool for the combined effect of MTB_factor + smallpaved_factor + unifactoradjust on the final value of univ_factor_coef, that is used for tweaking of profile behavious toward various road class/quality.

TOP

V

  • Viapoint (cz:Prujezdní bod) is a point of a route, that a user wishes to visit or go through. Originally all routepoints but start/destination points were viapoints. But for the case route is generated by the Routing service, only the initial intermediate points provided by the user are considered as viapoints.

TOP

W

  • Way/OSM way is a general term of any oriented line-shape structure, consisting of OSM nodes. The most important class of OSM ways are highways ( OSM tag highway= ), from highway=motorways to highway=path.

  • Waypoint is a general term for any point of a track or a route. Points of routes are called routepoints, of a track - trackpoints.

  • Wrong mapping to fix routing, wrong routing to fix mapping - this should be avoided. OSM Mapping should reflect the physical a/o logical verifyable state of OSM ways. There is needed somewhat weakened approach to subjective paramaters like Smoothness, MTB scale, SAC scale, Trail visibility or others. Routing should be based on what is in the OSM based map, not what is in the terrain. If there is map versus reality disagreement, it is the map that should be fixed, not the routing. Currently, the BRouter RD5 files are usually updates every 7-10 days. Until the update, use via-points or perhaps even better - specifically for BRouter - use nogo points.

TOP

X

TOP

Y

TOP

Z

TOP

⚠️ **GitHub.com Fallback** ⚠️