From 0b9ea9b4c0598b5f4e6ce5d376ceb046f1472f6d Mon Sep 17 00:00:00 2001 From: Manuel Fuhr Date: Tue, 30 Nov 2021 19:12:41 +0100 Subject: [PATCH] Import brouter website as markdown --- docs/features/algorithm.md | 97 ++++++++++ docs/features/alternatives.md | 20 ++ docs/features/costfunctions.md | 27 +++ docs/features/cycleroutes.md | 15 ++ docs/features/elevation.md | 24 +++ docs/features/offline.md | 53 ++++++ docs/features/vianogo.md | 19 ++ docs/index.md | 73 +++++++ docs/resources.md | 25 +++ docs/revisions.md | 334 +++++++++++++++++++++++++++++++++ 10 files changed, 687 insertions(+) create mode 100644 docs/features/algorithm.md create mode 100644 docs/features/alternatives.md create mode 100644 docs/features/costfunctions.md create mode 100644 docs/features/cycleroutes.md create mode 100644 docs/features/elevation.md create mode 100644 docs/features/offline.md create mode 100644 docs/features/vianogo.md create mode 100644 docs/index.md create mode 100644 docs/resources.md create mode 100644 docs/revisions.md diff --git a/docs/features/algorithm.md b/docs/features/algorithm.md new file mode 100644 index 0000000..c49d26e --- /dev/null +++ b/docs/features/algorithm.md @@ -0,0 +1,97 @@ +--- +title: "Routing algorithm" +--- + +## Routing algorithm: 2-pass routing with adaptive cost-cutoff + +There's not so much to say about the routing algorithm, because the basic ideas +like [Dijkstra's algorithm](http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm) +or the [A-Star algorithm](http://en.wikipedia.org/wiki/A*_search_algorithm) are +well documented. + +Since Dijkstra uses only the path-cost-function `g(x)`, while A-Star add's the +remaining air-distance to the destination as a *future-cost-function* `h(x)`, +you can consider both algorithms to be equivalent if you introduce a *heuristic +coefficient* `c`: + +``` +cost-function = g(x) + c*h(x) +``` + +It is known that you get a correct result if `c` is in the range 0..1, and if +`g(x)` and `h(x)` satisfy some conditions. + +For `c>1` you do not get a correct result. However, if c is larger than the +average ratio of the path cost-function g(x) and the air-distance, you get a +quick heuristic search which is heading towards the destination with a +processing time that scales linear with distance, not quadratic as for a correct +(`c<1`) search. + +BRouter uses a 2-pass algorithm as a mixed approach with e.g. `c=1.5` for the +first pass and `c=0` for the second pass. The trick here is that the second pass +can use a cost-cutoff from the maximum-cost-estimate that the first pass +delivers to limit the search area, because any path with a remaining +air-distance larger than the difference of the current cost and the maximum cost +estimate can be dropped. And this cost-cutoff is adaptive: if during the second +pass a match is found with the first pass result, the maximum cost estimate is +lowered on-the-fly if this match gives a combined path with a lower cost. + +For recalculations, where you still know the result from the last calculation +for the same destination, the first pass can be skipped, by looking for a match +with the last calculations result. You can expect to find such a match and thus +a maximum cost estimate soon enough, so you get an effective limit on the search +area. If a recalculation does not finish within a given timeout, it's usually +o.k. to publish a merged track from the best match between the new and the old +calculation, because the far-end of a route usually does not change by an +immediate recalculation in case you get off the track. + +The reason that `c=0` (=Dijkstra) is used in the second pass and not `c=1` +(=A-Star) is simply that for `c=0` the open-set is smaller, because many paths +run into the cutoff at an early time and do not have to be managed in the +open-set anymore. And because the size of the open-set has an impact on +performance and memory consumption, c=0 is choosen for the second pass. The +open-set is what's displayed in the graphical app-animation of the brouter-app. + +However, you can change the coefficients of both passes in the routing-profile +via the variables `pass1coefficient` and `pass2coefficient`, as you can see in +the car-test profile. A negative coefficient disables a pass, so you can e.g. +force BRouter to use plain A-Star with: + +``` +assign pass1coefficient=1 +assign pass2coefficient=-1 +``` + +or do some super-fast dirty trick with *non-optimal* results (there are routers +out there doing that!!): + +``` +assign pass1coefficient=2 +assign pass2coefficient=-1 +``` + +Some more words on the conditions that the path-cost-funtion g(x) has to +fullfill. Mathematically it reads that you need *non-negative edge costs*, but +the meaning is that at the time you reach a node you must be sure that no other +path reaching this node at a later time can lead to a better result over all. + +If you have *turn-costs* in your cost function, this is obviously not the case, +because the overall result depends and the angle at which the next edge is +leaving this node.... However, there's a straight forward solution for that +problem by redefining edges and nodes: in BRouter, *nodes* in the Dijkstra-sense +are not OSM-Nodes, but the links between them, and the edges in the Dijkstra +sense are the transitions between the links at the OSM-Nodes. With that +redefinition, *turn-cost* and also *initial-costs* become valid terms in the +path-cost-function. + +However, there's still a problem with the elevation term in the cost-function, +because this includes a low-pass-filter applied on the SRTM-altitudes that +internally is implemented as an *elevation-hysteresis-buffer* that is managed +parallel to the path's cost. So the path's cost is no longer the *true cost* of +a path, because the hysteresis-buffer contains potential costs that maybe +realized later, or maybe not. + +Strictly speaking, neither Dijkstra nor A-Star can handle that. And in BRouter, +there's no real solution. There's a mechanism to delay the node-decision one +step further and so to reduce the probablity of glitches from that dirtyness, +but mainly the solution is *don't care*. diff --git a/docs/features/alternatives.md b/docs/features/alternatives.md new file mode 100644 index 0000000..2b5cc86 --- /dev/null +++ b/docs/features/alternatives.md @@ -0,0 +1,20 @@ +## Alternative route calculations + +Sometimes the routing result is not what you want, and you are looking for some +other way, following the same routing preferences, but not following the way of +the first choice routing result. + +Maybe you don't like the first choice, or you are planning a roundtrip and don't +want to go back the same way. For this purpose, BRouter can calculate +alternatives. + +This feature is well known from handheld-navigation systems, but not found in +online services. This is because these online services need to use +pre-calculations for fast processing and cannot handle individual routing +criteria. BRouter does not do any precalculations for specific routing profiles, +so it can do whatever you ask for. + +When using a second choice route, you may want to recalculate the route using +[via or nogo points](vianogo.md) in order to define the overall routing +according to your preferences but have a route that is first choice except for +these explicit constraints. diff --git a/docs/features/costfunctions.md b/docs/features/costfunctions.md new file mode 100644 index 0000000..9f14c28 --- /dev/null +++ b/docs/features/costfunctions.md @@ -0,0 +1,27 @@ +## Freely configurable routing profile + +A major reason for the limited usefulness of most bike routing software is that +routing preferences are a personal issue. Not even will MTB and racing cyclist +never agree on common routing preferences, also the same people will have +different preferences for day and night, dry and wet weather, etc. The only +solution for that problem is the use of a freely configurable cost function that +can easily be adapted to personal needs. This is far more flexible compared to a +set of static functions with a fixed set of configuration variables. + +To make that point somewhat clearer: there are other routers that are highly +configurable, look at [routino](http://www.routino.org/uk/router.html) for an +example. However, these are one-dimensional parameter sets that do not allow to +handle arbitrary correlation. BRouter's configuration is different. It is more a +scripting language that allows you to program the cost function instead of just +configuring it. E.g. a non-graded track is generally not a good track. But if it +has a surface=asphalt tag, it probably is. On the other hand, a grade5-track +with surface=asphalt is primarily a grade5-track and you should not ignore that. +Such logic is not implementable in one-dimensional parameter sets. + +See some [sample profiles](profiles2) provided for the online router. + +See the trekking-profile [`trekking.brf`](profiles2/trekking.brf) as the +reference-profile with some explanations on the meaning of this script. + +See the [profile_developers_guide.txt](profile_developers_guide.txt) for a +technical reference. diff --git a/docs/features/cycleroutes.md b/docs/features/cycleroutes.md new file mode 100644 index 0000000..01626a9 --- /dev/null +++ b/docs/features/cycleroutes.md @@ -0,0 +1,15 @@ +## Following long distance cycle routes + +The long distance cycle network (see +[www.opencyclemap.org](http://www.opencyclemap.org)) is the first thing to +consider when planning a cycle trip. BRouter can do that, and the `trekking` +profile makes use of it. It does that implicitly by just making them cheap in +the cost-function, so that the routing sometimes *snaps in* to long distance +cycle routes. + +That's a good choice for long distance cycling, because these routes are a *safe +harbor* almost free of bad surprises. However, when really looking for the +*optimal* route between A and B to use it more than once (e.g. your daily +commute) you may want to ignore the long-distance network, to put more focus on +*hard-facts* like distance, hills and surface quality (use the +`trekking-ignore-cr` profile for that purpose). diff --git a/docs/features/elevation.md b/docs/features/elevation.md new file mode 100644 index 0000000..10a9de0 --- /dev/null +++ b/docs/features/elevation.md @@ -0,0 +1,24 @@ +## Elevation algorithm + +Elevation awareness is the most important issue in bike routing if not routing +in a flat country. But in most routing software, elevation is either not handled +at all or in a way that is not really useful. + +Even worse, most tools do not even report on elevation in a useful manner. The +far-too-high *total climbs* usually reported do not only accumulate real, small +height-variations that are averaged-out by the bikers momentum - they accumulate +also noise and grid-interpolation errors from the elevation data source. + +For most regions, BRouter uses elevation data from the [Shuttle Radar Topography +Mission (SRTM)](http://srtm.usgs.gov/), precisely the hole-filled Version 4.1 +Data provided by [srtm.csi.cgiar.org](http://srtm.csi.cgiar.org/), which is the +data that is displayed e.g. in Google Earth and which is used in most +elevation-enabled routing tools. However, the routing algorithm is able to +extract the information on real ascends and descends and ignores the noise. + +For latitudes above 60 degree in northern Europe, BRouter uses Lidar data, that +were [compiled and resampled by Sonny](https://data.opendataportal.at/dataset/dtm-europe) + +On the reporting side, BRouter uses a similar concept to compute the *filtered +ascend*, which is the ascend without the noise and the small hills and which +turned out to be a valid concept to estimate the real elevation penalty. diff --git a/docs/features/offline.md b/docs/features/offline.md new file mode 100644 index 0000000..1152ade --- /dev/null +++ b/docs/features/offline.md @@ -0,0 +1,53 @@ +## Ofline routing on Android phones + +BRouter is first and foremost an offline tool. It runs on any Android phone. The +online version offered here is just for a trial and for convenience. While many +smartphone routing software use online services to do the actual route +calculations, the advantages of the offline approach are evident: + +- It is more reliable, data connection problems and server-side problems are no + issue + +- It works in foreign countries where data connections are either not available + or very expensive + +- It does not raise any data privacy issues + +- You can use a cheap dedicated, second phone for navigation, without having to + put your business smartphone on an untrusted bike mount and run it's battery + low + +The downside is that advanced route calculations are difficult to do on a +smartphone with limited computing and memory resources, which may lead +developers to implement simplifications into the routing algorithm that affect +the quality of the routing results. BRouter always does it's best on the +quality, but has a processing time that scales quadratic with distance, leading +to a limit at about 150km in air-distance, which is enough for a bikers daytrip. + +### Installing the BETA Version of BRouter on an Android smartphone. + +Before trying the Android app, you should have a look one the [online +version](/brouter-web) to see what it's doing. + +What you should also do before trying the BRouter Android app is to install, an +get familiar with, one of the supported map-apps. This is either +[OsmAnd](http://www.osmand.net), which is a full offline navigation solution on +it's own, but especially it's a wonderful offline OSM map tool and is able to +give spoken directions to routes calculated either internally or externally. +Other options are [Locus](http://www.locusmap.eu/) or +[OruxMaps](http://www.oruxmaps.com/index_en.html). + +The BRouter Android app assumes that at least one of OsmAnd, Locus or OruxMaps +is installed - it will not work otherwise. + +If you are o.k. with all that, you can install the BRouter Android app from the +[brouter_1_6_1.zip](../brouter_bin/brouter_1_6_1.zip) installation ZIP-file +including the APK and read the [readme.txt](readme.txt) ( **READ ME !** ) for +details on how to add routing data and navigation profiles to your installation +and how the interfacing between BRouter and the supported map-tools works. + +Navigation profiles and the lookup-data are [here](profiles2) Routing data files +per 5*5-degree square are [here](/brouter/segments4) + +(The Map-Snapshot date is about 2 days before the timestamp of the routing data +files) diff --git a/docs/features/vianogo.md b/docs/features/vianogo.md new file mode 100644 index 0000000..ba2bbac --- /dev/null +++ b/docs/features/vianogo.md @@ -0,0 +1,19 @@ +## Via-Points and NoGo-Areas + +BRouter can process via-points and nogo-areas, and [brouter-web](/brouter-web) +offers on online interface to edit both of them. + +For offline use, nogo-areas can be defined as wayoints using a special naming +convention. Handling of via-points during offline use depends on the mode of +operation, see the README for details. + +NoGo-Areas are forbidden areas. In fact, these are areas, not points, with a +default radius of 20m around the given point. Every way that is touching this +disc of 20m radius is excluded by the routing algorithm. But the radius can also +be specified: a waypoint `nogo` default to 20m radius, but `nogo100` defines a +nogo area with 100m radius. Theres no limit in radius, so you can also exclude a +whole geographic region with a single nogo-area. + +Nogo areas are useful if you encouter an obstacle that is not contained in the +underlying map. But they can also be useful in planning alternative routes by +excluding e.g. a certain bridge or ferry. diff --git a/docs/index.md b/docs/index.md new file mode 100644 index 0000000..6a7de59 --- /dev/null +++ b/docs/index.md @@ -0,0 +1,73 @@ +--- +layout: default +--- + +## BRouter: Let's get serious about bike routing + +There's a lot of routing software on the market, both free and commercial, both +online and offline, both OSM and proprietary maps. However, when it comes to +bike routing, it's hard to find something that's really useful. There's far less +money and engineering power in the field compared to car navigation. + +What do we expect from a bike routing software? It should be able to calculate +more or less the routes that match your experience in the regions you are +familiar with, thus giving you confidence that it yields the same quality in +unknown regions. Scanning the market with that expectation gives little to no +result. + +Here's what makes BRouter unique: + +- It uses [freely configurable routing profiles](features/costfunctions.md) + +- It works [fully offline on any Android phone](features/offline.md) and is + interfaced to some of the most popular Android map tools + +- It uses a sophisticated [routing-algorithm](features/algorithm.md) with + [elevation consideration](features/elevation.md) + +- It offers [alternative route calculations](features/alternatives.md) + +- It supports [via and nogo-points](features/vianogo.md) + +- It can [consider long distance cycle routes](features/cycleroutes.md) + +Routing data is available worldwide with automatic weekly updates + +### BRouter uses OpenStreetMap + +BRouter uses user-generated, collaboratively collected free geodata. Thanks to +OpenStreetMap.org and contributors - please donate your geographic data to +openstreetmap.org! See the [License +description](http://www.openstreetmap.org/copyright) for details. + +### Online versions + +Check [brouter-web](/brouter-web) or [bikerouter.de](https://www.bikerouter.de/) +if you want to use BRouter online. + +### Android app for offline routing + +See [offline routing app](features/offline.md) for how to setup BRouter for +offline routing on an Android smartphone. + +### Revision history + +See the [revision history](revisions.md) for older revisions of the app and the +change-log. + +### Google group for support questions and feedback + +Please use the +[osm-android-bikerouting](http://groups.google.com/group/osm-android-bikerouting) +google group for any questions/feedback. + +### Other bike routing resources: + +* [OpenStreetMap wiki router comparison + matrix](http://wiki.openstreetmap.org/wiki/Routing/online_routers) +* [OpenRouteService.org](http://www.openrouteservice.org) +* [Naviki.org](http://www.naviki.org) +* [yournavigation.org](http://www.yournavigation.org) +* [maps.cloudmade.com](http://maps.cloudmade.com) +* [graphhopper.com](http://graphhopper.com) +* [cycle.travel](http://cycle.travel/map) diff --git a/docs/resources.md b/docs/resources.md new file mode 100644 index 0000000..4193a40 --- /dev/null +++ b/docs/resources.md @@ -0,0 +1,25 @@ +--- +title: Resources +--- + +## International resources + +- Please use the [osm-android-bikerouting](http://groups.google.com/group/osm-android-bikerouting) + google group for any questions/feedback. +- Video: [Energy efficient routing with OSM](https://youtu.be/VMDRr6YPOw0) at + 2018 State-of-the-Map in Milano + +## German resources + +Artikel zu BRouter: + +- im [com-magazin](http://www.com-magazin.de/praxis/android/offline-routing-rad-wandertouren-465807.html) +- bei [gpsradler.de](https://gpsradler.de/praxistest/brouter-web-tourenplaner-test/) +- bei [navigation-professionell.de](https://www.navigation-professionell.de/brouter-web-tourenplanung/) + +Vorträge zu BRouter auf der FOSSGIS Konferenz bei YouTube: + +- 2014: [Höhenbewusstes Routing mit Radardaten](https://www.youtube.com/watch?v=c0TehKCX4Ao) +- 2015: [Neues zu BRouter](https://www.youtube.com/watch?v=Eba4fcYI4h4) [(lokales mp4)](brouter_bin/fossgis_2015_neues_zu_brouter.mp4) +- 2018: [Energieeffizientes PKW Routing mit OpenStreetMap](https://youtu.be/IHV2sL7n0Qo) +- 2020: [Routenplanung mit BRouter und BRouter-Web](https://www.youtube.com/watch?v=l6X2Sm1YDLs) [(lokales mp4)](brouter_bin/fossgis_2020_routenplanung.mp4) diff --git a/docs/revisions.md b/docs/revisions.md new file mode 100644 index 0000000..fbaa817 --- /dev/null +++ b/docs/revisions.md @@ -0,0 +1,334 @@ +## Revision history + +(ZIP-Archives including APK, readme + profiles) + +### [brouter_1_6_1.zip](../brouter_bin/brouter_1_6_1.zip) (current revision, 01.03.2020) + +- download manager: direct jump-in zoom to workaround a problem with + S10+Android10 + +### [brouter_1_6_0.zip](../brouter_bin/brouter_1_6_0.zip) (16.02.2020) + +- fixed Voice-Hint timing bug (locus+osmand) +- BRouter-Web related enhancements +- fixed excessive roundabout times in kinematic model +- lookup+profile extensions +- documentation updates +- pre-processor: Douglas-Peucker transfer-node elimination +- pre-processor: speedup (->daily updates) +- pre-processor: conversion of (lidar-) hgt to bef (->Northern Europe + coverage) +- route server: thread-limit logic update (guarantee 2000ms victim runtime) +- route server: extended parsed profile cache +- route server: more appropriate HTTP status codes +- download manager: rd5 delta updates +- download manager: rd5 delete function +- suspect-manager: multiple challenges + +### [brouter_1_5_5.zip](../brouter_bin/brouter_1_5_5.zip) (22.07.2019) + +- bugfix in lazy crc check +- waypount echo (brouter-web) + +### [brouter_1_5_4.zip](../brouter_bin/brouter_1_5_4.zip) (20.07.2019, hot-fix 16:40 UTC+2) + +- fixed OsmAnd Turn Instruction issue (+hot-fix) +- internal compression in service interface +- repeat timeout -> repeat any service interface routing in brouter-app +- forcing new basedir selection on 1.4.x - 1.5.x update +- more careful memory allocation + +### [brouter_1_5_3.zip](../brouter_bin/brouter_1_5_3.zip) (06.07.2019) + +- fixed car-profiles for correct OsmAnd Turn Instructions +- increased Download Manager Speed Limit 2 Mbit/s -> 4 MBit/s +- adapted download size estimates + +### [brouter_1_5_2.zip](../brouter_bin/brouter_1_5_2.zip) (04.07.2019) + +- Android-Api-28 compatibility (with some loss of function) +- easy install on external SD (but RD5s will be deleted on uninstall) +- both Api-28 and Api-10 APKs in release-zip + +### [brouter_1_5_1.zip](../brouter_bin/brouter_1_5_1.zip) (30.06.2019) + +- Android Target API back to 10 for now (too much problems on Android >= 6) + +### [brouter_1_5_0.zip](../brouter_bin/brouter_1_5_0.zip) (30.06.2019) + +- MIT License +- Android Target API 28 (to conform to Play Store Policy) +- new internal memory management (direct-weaving+escape analysis): lower + memory footprint and defined memory bounds = more reliable operation for + long distances and as embedded library +- performance improvements +- Bicycle+Foot ETA (estimated time of arrival) +- ETA data in GPX for Locus + OsmAnd +- more precice distance calculation +- weighted nogos +- BRouter-Web related additions +- maxspeed:forrward/backward +- no_entry/no_exit TRs + +### [brouter_1_4_11.zip](../brouter_bin/brouter_1_4_11.zip) (02.04.2018, hot-fix 12.4.2018) + +- automatically ignore network islands +- car-fast/eco: breaking speeds from cost model + cost tuning +- **hot-fix 12.4.2018**: fixed bug for only-TRs at start or end + segment + +### [brouter_1_4_10.zip](../brouter_bin/brouter_1_4_10.zip) (07.03.2018) + +- fixed motorcar TR exceptions +- added vr-forum profiles to distribution +- added suspect manager to RouteServer +- polygon nogo pull request (QMapShack) +- nogo encoding pull request (QMapShack) + +### [brouter_1_4_9.zip](../brouter_bin/brouter_1_4_9.zip) (24.09.2017) + +- tweaked distance calculation +- new car profiles, kinematic model based +- basic travel-time/energy support +- modular cost models +- lookup extensions (+conrcete:lanes/plate code-side-hack) +- fix for interface provided nogos +- access to way-context vars from node-context +- fixed same segment search problem +- removed size limit for encoded tags +- (**hot fix, 5pm**: fixed regression bug for TR-bike-exceptions) + +### [brouter_1_4_8.zip](../brouter_bin/brouter_1_4_8.zip) (10.12.2016, hot-fix 7.1.2017) + +- added turn restrictions (default for car, use considerTurnRestrictions=true + for bike) +- fixed elevation interpolation in start/end segments +- fixed error message for very old data files +- removed sanity checks when just reading nogos from waypoint-database +- handling url encoded parameters +- locus codes 13/14 for u-turns left/right +- workaround for app-startup-crash when not able to determine free disk-space + (hot-fix 7.1.2017) + +### [brouter_1_4_7.zip](../brouter_bin/brouter_1_4_7.zip) (19.10.2016) + +- added turncost as start-direction bias (locus only) +- fixed a nullpointer bug in voice-hint-processing +- fixed brouter-web/standalone upload path bug +- added oneway:bicycle=true to oneway logic + +### [brouter_1_4_6.zip](../brouter_bin/brouter_1_4_6.zip) (30.9.2016) + +- improved memory footprint +- tweaked recalculation timeout logic + +### [brouter_1_4_5.zip](../brouter_bin/brouter_1_4_5.zip) (10.9.2016) + +- some more performance improvements +- filtering out unused way tags to increase profile cache efficiency +- cache sizing depending on android memory class +- fixed *ups* bug at very long distances +- fixed a bug when using repeat-timeout shortcut without a cordinate source + +### [brouter_1_4_4.zip](../brouter_bin/brouter_1_4_4.zip) (29.08.2016) + +- performance improvements +- *repeat timeout* shortcut to continue a timed-out service request +- relaxed compatibility rule for lookup-data minor version +- added mtb:scale:uphill + +### [brouter_1_4_3.zip](../brouter_bin/brouter_1_4_3.zip) (06.08.2016) + +- Option for sending profiles via service interface +- more aggresive profile replacement at version upgrade +- fixed a serious rounding bug when reading locus/orux waypoints + +### [brouter_1_4_2.zip](../brouter_bin/brouter_1_4_2.zip) (16.05.2016) + +- turn instructions, elevation on locus waypoints +- turn-instructions, shift to less ambigious angles +- turn-instructions, locus transport mode cleanup + +### [brouter_1_4_1.zip](../brouter_bin/brouter_1_4_1.zip) (09.05.2016 + +- turn instructions, fixed locus roundabaouts +- added xor, lesser, sub operators for profiles + +### [brouter_1_4.zip](../brouter_bin/brouter_1_4.zip) (06.05.2016) + +- turn instructions, first version (locus+osmand) +- extended scan for searching maptool-waypoint database +- blank->underscore replacement in tag-values +- ignoring direct duplicates in waypoint selection + +### [brouter_1_3_2.zip](../brouter_bin/brouter_1_3_2.zip) (01.11.2015) + +- allow big waypoint databases (locus+orux) +- storageconfig-migration for 1.2->1.3.2 update +- dirty reference tracks for better 2nd try performance +- static profile cache re-use +- fix for osmand 2.x directory structure on 4.4+ ext-sd +- fixed some error-handling issues + +### [brouter_1_3_1.zip](../brouter_bin/brouter_1_3_1.zip) (18.10.2015) + +- target island detection +- fixed 2-node loop problem +- minor profile modifications +- changed animation to show track during final pass + +### [brouter_1_3.zip](../brouter_bin/brouter_1_3.zip) (16.10.2015) + +- statistical encoding for data files (->much smaller) +- download manager update function +- filter for routable ways on decoder-level +- -> better memory footprint, no more OOM +- removed carsubset files (not needed anymore) +- waypoint matching on decoder level +- waypoint inside nogo disables nogo +- traffic-load pseudo-tags from traffic simulation + +### [brouter_1_2.zip](../brouter_bin/brouter_1_2.zip) (4.4.2015) + +- profile syntax extensions +- csv-fixes +- safari-patch (brouter-web) +- message list in geojson (brouter-web) +- initial cost classifier +- lookup extensions (minor version 4) +- more error handling + debug tracing + +### [brouter_1_1.zip](../brouter_bin/brouter_1_1.zip) (28.12.2014) + +- performance fixes + +### [brouter_1_0_4.zip](../brouter_bin/brouter_1_0_4.zip) (28.9.2014) + +- lookup extensions +- proposed-handling for cycle relations +- reworked csv listing + +### [brouter_1_0_3.zip](../brouter_bin/brouter_1_0_3.zip) (24.8.2014) + +- support for slope dependent cost-function + +### [brouter_1_0_2.zip](../brouter_bin/brouter_1_0_2.zip) (10.8.2014) + +- fixed NullPointerException during setup +- mime-type patch for downloading from brouter-web + +### [brouter_1_0_1.zip](../brouter_bin/brouter_1_0_1.zip) (26.7.2014) + +- new file format with extended lookup table and 25% size reduction +- special, fast handling for trivial recalculations for timeout-free + recalculations +- fixed the scaling for high-density screens in the download manager +- added more [configuration options](kitkat_survival_readme.txt) to work + around the kitkat (Android 4.4) issues + +### [brouter_0_9_9.zip](../brouter_bin/brouter_0_9_9.zip) (18.4.2014, hot-fix 11.5.2014) + +- new (google-play compatible) signing key, UNINSTALL NECCESSARY! +- added crc checksums to datafiles +- fixed a bug in accessing the last 64k of a datafile +- extended basedir-proposals (**Fixed Android 4.4 issue on 11.5.2014**) +- changed RouteServer to multithreaded/nonblocking operation (for brouter-web) +- added brouter-web start-scripts +- added oneway:bicycle=no -> cycleway=opposite conversion to pre-processor +- added more cache-reuse for better short-route performance + +### [brouter_0_9_8.zip](../brouter_bin/brouter_0_9_8.zip) (12.1.2014) + +- fixed NullPointer for missing service-mode +- fixed remaining issue for short routes with from/to on same way-section +- improved reporting on OutOfMemory +- changed *fastbike* profile to fix an issue with mandatory cycleways +- fixes a bug in elevation reporting if startpoint has VOID elevation + +### [brouter_0_9_7.zip](../brouter_bin/brouter_0_9_7.zip) (31.12.2013) + +- fixed a bug for short routes with from/to on same way-section +- improved waypoint-matching +- improved nogo-handling in service interface (inverse logic, routing mode + stores veto-list) +- added waypoint-selection dialogs when from/to not given +- summary page after service-mode confifuration update +- allowed configuration of BRouter's servicemodes without any supported + maptool installed +- added a redirection-workaround for the tracks-output directory +- removed the beta-expiry + +### [brouter_0_9_6.zip](../brouter_bin/brouter_0_9_6.zip) (27.10.2013) + +- added html-page about [routing-algorithm](features/algorithm.md) +- changed from 3-pass to 2-pass calculation +- added profile-parameters for routing coefficients +- lowered pass1-coefficient for car-test to 1.3 +- fixed a bug in nogo-handling in service interface +- fixed a bug in command-line java version + +### [brouter_0_9_5.zip](../brouter_bin/brouter_0_9_5.zip) (20.10.2013) + +- some performance improvments +- support for car-subset datafiles +- timeout-free partial recalcs in service-mode +- added java-version (executable jar) to distribution zip +- moved service-mode-mapping files to sdcard + +### [brouter_0_9_4.zip](../brouter_bin/brouter_0_9_4.zip) (4.9.2013) + +- additional maptool search at /mnt/sdcard when using a non-standard base + directory +- fixed error handling issues +- major source code refactoring + +### [brouter_0_9_3.zip](../brouter_bin/brouter_0_9_3.zip) (30.6.2013) + +- introduced new service interface as android service +- re-designed service-mode configuration to be more flexible + +### [brouter_0_9_2.zip](../brouter_bin/brouter_0_9_2.zip) (9.6.2013) + +- fixed lifecycle issues of service interface + +### [brouter_0_9_1.zip](../brouter_bin/brouter_0_9_1.zip) (2.6.2013) + +- added an experimental service interface (see readme_service.txt) + +### [brouter_0_9.zip](../brouter_bin/brouter_0_9.zip) (26.5.2013) + +- line-matching + exact positions for waypoints +- minor profile modifications +- changed track-name from mytrack so something more useful + +### [brouter_0_8.zip](../brouter_bin/brouter_0_8.zip) (4.5.2013) + +- changed beta expiry to August 2014 +- Nogo-Points next version: line-matching + radius +- line-matching for waypoints (online version only up to now) +- moped-profile + +### [brouter_0_7.zip](../brouter_bin/brouter_0_7.zip) (7.4.2013) + +- Support for OruxMaps +- Via-Points +- Nogo-Points +- fixed parsing of profiles without trailing newline +- fixed scaling of routing animation +- (No documentation update yet!) + +### [brouter_0_6.zip](../brouter_bin/brouter_0_6.zip) (9.3.2013) + +- Extended data files (more way tags, added node tags) +- Extended profiles (global-, way-, node-context) +- more precise access + oneway rules +- more evelation parameters in profiles +- explicit configuration of base directory +- elevation=void within bridges or tunnels +- fixed gpx version header +- link counter in app animation + +### [brouter_0_5.zip](../brouter_bin/brouter_0_5.zip) (27.1.2013) + +- last revision before data format change - old data files not available + anymore