-
Notifications
You must be signed in to change notification settings - Fork 18
Glossary
-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-star algorithm is an algorithm widely used for route computation. It scores point in the road network topology by sum of partial route length and and air distance to destination. Note that the length is taken in BRouter context as Equivalent length. Brouter uses for the 1st pass a modified version of the algorithm, using a heuristic coefficient as the air distance multiplier.
-
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.
- Coordinate format - Nominatim : reported valid formats for coordinate search on Brouter-web. Note the ASCII code way for ° is ALT 0176.
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 Effective length of the way, but additional parameters Turncost, InitialCost and ElevationCost are added.
- CF is proportionality constant for EL = CF . L,
-
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.
- Its default value 0.2 in Trekking-Dry means just the mild preference.
- The value 0.0 is used for -ICR profiles ( ignore cycleroutes ).
- The value 0.6 is used for -FCR profiles ( follow cycleroutes ).
- the effect is non-linear, see Marked-routes
- See also Cycleroute-preference for incoming chnages in development version of Trekking-Poutnik template.
-
Downhillcost is the BRouter feature, expressing the penalty for elevation change in form of an additional length-like term in total cost calculation. I call it elevation equivalent length. 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, being an intermediate values for final calculation of Up/Downhillcutoff/cost. As these values are not fixed, but depend on other parameters like MTB_factor.
-
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.
- With the buffer content > elevationpenaltybuffer, it starts partially convert the buffered elevation to ElevationCost by Up/downhillcost,
- 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 way cost, equal to calculated Equivalent length (with cost, calculated from the elevation slope. Typical value is extra 600 m for 10 m of elevation, but depends on used parameters. 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
- EL = Equivalent length
- CF = CostFactor
- L = Physical length
- IC = InitialCost
- TC = TurnCost
- EC = ElevationCost
-
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
- 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. |
1 | Trekking-dry profile default. It additionally penalizes steep uphills over 3% with uphillcutoff/cost 3.0/70 |
2 | Avoid hills, inspired by recumbent/velomobile profiles. Uses low up/downhillcutoff (1.0/0.5) and high costs (80) |
3 | Experimental to get the fastest route |
4 | Experimental valley mode to prefer as long as possible flat roads, even at expense of steep hills. |
-
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.
-
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
-
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 )
-
MTB:scale is OSM tag describing difficulties of MTB trails in similar 6 level scale as SAC scale.
-
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.
- See also guidance
-
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.
- OSM = OpenStreetMap is community based vector world map and vector map data management.
-
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. It is used in both religious and outdoor contexts.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
- The idea behind the 1 template + many profile is this :
-
Trackpoint is a point of a track, an oriented sequence of points marking the passed way as a recorded log.
-
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.
-
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
- 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
-
Uphillcost - see Downhillcost
-
Uphillcostfactor - see Downhillcostfactor.
-
Uphillcutoff - see Downhillcutoff.
-
**Uphillcutoffvalue / Uphillcostvalue ** - See Downhillcutoffvalue / Downhillcostvalue
- Viapoint (cz:Průjezdní 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.
-
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[(#s), 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.