Import brouter website as markdown
This commit is contained in:
Manuel Fuhr
parent
c6bdf1709c
commit
0b9ea9b4c0
10 changed files with 687 additions and 0 deletions
97
docs/features/algorithm.md
Normal file
97
docs/features/algorithm.md
Normal file
|
|
@ -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*.
|
||||
20
docs/features/alternatives.md
Normal file
20
docs/features/alternatives.md
Normal file
|
|
@ -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.
|
||||
27
docs/features/costfunctions.md
Normal file
27
docs/features/costfunctions.md
Normal file
|
|
@ -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.
|
||||
15
docs/features/cycleroutes.md
Normal file
15
docs/features/cycleroutes.md
Normal file
|
|
@ -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).
|
||||
24
docs/features/elevation.md
Normal file
24
docs/features/elevation.md
Normal file
|
|
@ -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.
|
||||
53
docs/features/offline.md
Normal file
53
docs/features/offline.md
Normal file
|
|
@ -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)
|
||||
19
docs/features/vianogo.md
Normal file
19
docs/features/vianogo.md
Normal file
|
|
@ -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.
|
||||
73
docs/index.md
Normal file
73
docs/index.md
Normal file
|
|
@ -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)
|
||||
25
docs/resources.md
Normal file
25
docs/resources.md
Normal file
|
|
@ -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)
|
||||
334
docs/revisions.md
Normal file
334
docs/revisions.md
Normal file
|
|
@ -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
|
||||
Loading…
Reference in a new issue