Merge pull request #431 from zod/docs
Update documentation and transform to markdown
This commit is contained in:
afischerdev
GitHub
commit
1765ec4523
39 changed files with 1887 additions and 989 deletions
10
README.md
10
README.md
|
|
@ -15,7 +15,7 @@ You can install the BRouter app on your Android device from
|
||||||
Store](https://play.google.com/store/apps/details?id=btools.routingapp). You
|
Store](https://play.google.com/store/apps/details?id=btools.routingapp). You
|
||||||
can also [build BRouter](#build-and-install) yourself. You can find detailed
|
can also [build BRouter](#build-and-install) yourself. You can find detailed
|
||||||
documentation of the BRouter Android app in
|
documentation of the BRouter Android app in
|
||||||
[`misc/readmes/readme.txt`](misc/readmes/readme.txt).
|
[`docs/users/android_quickstart.md`](docs/users/android_quickstart.md).
|
||||||
|
|
||||||
<a href="https://f-droid.org/packages/btools.routingapp" target="_blank">
|
<a href="https://f-droid.org/packages/btools.routingapp" target="_blank">
|
||||||
<img src="https://f-droid.org/badge/get-it-on.png" alt="Get it on F-Droid" height="90"/></a>
|
<img src="https://f-droid.org/badge/get-it-on.png" alt="Get it on F-Droid" height="90"/></a>
|
||||||
|
|
@ -39,7 +39,7 @@ Alternatively, you can also use BRouter as the offline routing engine for
|
||||||
[OSMAnd](https://osmand.net/) on your Android device.
|
[OSMAnd](https://osmand.net/) on your Android device.
|
||||||
|
|
||||||
A full documentation on how to set this up is available at
|
A full documentation on how to set this up is available at
|
||||||
[`misc/readmes/osmand/README.md`](misc/readmes/osmand/README.md).
|
[`docs/users/osmand.md`](docs/users/osmand.md).
|
||||||
|
|
||||||
|
|
||||||
## BRouter on Windows/Linux/Mac OS
|
## BRouter on Windows/Linux/Mac OS
|
||||||
|
|
@ -106,7 +106,7 @@ You can also generate the segments files you need directly from a planet dump
|
||||||
of OpenStreetMap data (or a [GeoFabrik extract](https://download.geofabrik.de/)).
|
of OpenStreetMap data (or a [GeoFabrik extract](https://download.geofabrik.de/)).
|
||||||
|
|
||||||
More documentation of this is available in the
|
More documentation of this is available in the
|
||||||
[`misc/readmes/mapcreation.md`](misc/readmes/mapcreation.md) file.
|
[`docs/developers/build_segments.md`](docs/developers/build_segments.md) file.
|
||||||
|
|
||||||
|
|
||||||
### (Optional) Generate profile variants
|
### (Optional) Generate profile variants
|
||||||
|
|
@ -120,7 +120,7 @@ to help you quickly generate variants based on the default profiles, to create
|
||||||
a default set of profiles covering most of the basic use cases.
|
a default set of profiles covering most of the basic use cases.
|
||||||
|
|
||||||
Have a look at the
|
Have a look at the
|
||||||
[`misc/readmes/profile_developers_guide.txt`](misc/readmes/profile_developers_guide.txt)
|
[`docs/developers/profile_developers_guide.md`](docs/developers/profile_developers_guide.md)
|
||||||
for an in-depth guide on profiles edition and customization.
|
for an in-depth guide on profiles edition and customization.
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -140,7 +140,7 @@ file.
|
||||||
|
|
||||||
## Documentation
|
## Documentation
|
||||||
|
|
||||||
More documentation is available in the [`misc/readmes`](misc/readmes) folder.
|
More documentation is available in the [`docs`](docs) folder.
|
||||||
|
|
||||||
|
|
||||||
## Related Projects
|
## Related Projects
|
||||||
|
|
|
||||||
|
|
@ -89,7 +89,11 @@ android {
|
||||||
}
|
}
|
||||||
|
|
||||||
applicationVariants.all {
|
applicationVariants.all {
|
||||||
variant -> tasks["merge${variant.name.capitalize()}Assets"].dependsOn(generateProfilesZip)
|
variant ->
|
||||||
|
{
|
||||||
|
tasks["merge${variant.name.capitalize()}Assets"].dependsOn(generateProfilesZip)
|
||||||
|
tasks["merge${variant.name.capitalize()}Assets"].dependsOn(generateReadmesZip)
|
||||||
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
||||||
|
|
@ -122,10 +126,22 @@ task generateProfilesZip(type: Zip) {
|
||||||
dependsOn generateProfiles
|
dependsOn generateProfiles
|
||||||
}
|
}
|
||||||
archiveFileName = "profiles2.zip"
|
archiveFileName = "profiles2.zip"
|
||||||
from "../misc/profiles2"
|
from("../misc/profiles2") {
|
||||||
exclude "all.brf"
|
exclude "all.brf"
|
||||||
exclude "car-traffic_analysis.brf"
|
exclude "car-traffic_analysis.brf"
|
||||||
exclude "car-vario.brf"
|
exclude "car-vario.brf"
|
||||||
exclude "softaccess.brf"
|
exclude "softaccess.brf"
|
||||||
destinationDirectory = layout.buildDirectory.dir('assets')
|
}
|
||||||
|
destinationDirectory = layout.buildDirectory.dir("assets")
|
||||||
|
}
|
||||||
|
|
||||||
|
task generateReadmesZip(type: Zip) {
|
||||||
|
archiveFileName = "readmes.zip"
|
||||||
|
from("../docs") {
|
||||||
|
include("users/android_quickstart.md")
|
||||||
|
include("users/android_advanced.md")
|
||||||
|
include("developers/profile_developers_guide.md")
|
||||||
|
include("developers/build_segments.md")
|
||||||
|
}
|
||||||
|
destinationDirectory = layout.buildDirectory.dir("assets")
|
||||||
}
|
}
|
||||||
|
|
|
||||||
Binary file not shown.
6
docs/.gitignore
vendored
Normal file
6
docs/.gitignore
vendored
Normal file
|
|
@ -0,0 +1,6 @@
|
||||||
|
_site
|
||||||
|
.bundle
|
||||||
|
.sass-cache
|
||||||
|
.jekyll-cache
|
||||||
|
.jekyll-metadata
|
||||||
|
vendor
|
||||||
25
docs/404.html
Normal file
25
docs/404.html
Normal file
|
|
@ -0,0 +1,25 @@
|
||||||
|
---
|
||||||
|
permalink: /404.html
|
||||||
|
layout: default
|
||||||
|
---
|
||||||
|
|
||||||
|
<style type="text/css" media="screen">
|
||||||
|
.container {
|
||||||
|
margin: 10px auto;
|
||||||
|
max-width: 600px;
|
||||||
|
text-align: center;
|
||||||
|
}
|
||||||
|
h1 {
|
||||||
|
margin: 30px 0;
|
||||||
|
font-size: 4em;
|
||||||
|
line-height: 1;
|
||||||
|
letter-spacing: -1px;
|
||||||
|
}
|
||||||
|
</style>
|
||||||
|
|
||||||
|
<div class="container">
|
||||||
|
<h1>404</h1>
|
||||||
|
|
||||||
|
<p><strong>Page not found :(</strong></p>
|
||||||
|
<p>The requested page could not be found.</p>
|
||||||
|
</div>
|
||||||
29
docs/Gemfile
Normal file
29
docs/Gemfile
Normal file
|
|
@ -0,0 +1,29 @@
|
||||||
|
source "https://rubygems.org"
|
||||||
|
# Hello! This is where you manage which Jekyll version is used to run.
|
||||||
|
# When you want to use a different version, change it below, save the
|
||||||
|
# file and run `bundle install`. Run Jekyll with `bundle exec`, like so:
|
||||||
|
#
|
||||||
|
# bundle exec jekyll serve
|
||||||
|
#
|
||||||
|
# This will help ensure the proper Jekyll version is running.
|
||||||
|
# Happy Jekylling!
|
||||||
|
|
||||||
|
# Use the github-pages bundle by default
|
||||||
|
# gem "jekyll", "~> 4.2.1"
|
||||||
|
gem "github-pages", group: :jekyll_plugins
|
||||||
|
|
||||||
|
# If you have any plugins, put them here!
|
||||||
|
group :jekyll_plugins do
|
||||||
|
# gem "jekyll-feed", "~> 0.12"
|
||||||
|
end
|
||||||
|
|
||||||
|
# Windows and JRuby does not include zoneinfo files, so bundle the tzinfo-data gem
|
||||||
|
# and associated library.
|
||||||
|
platforms :mingw, :x64_mingw, :mswin, :jruby do
|
||||||
|
gem "tzinfo", "~> 1.2"
|
||||||
|
gem "tzinfo-data"
|
||||||
|
end
|
||||||
|
|
||||||
|
# Performance-booster for watching directories on Windows
|
||||||
|
gem "wdm", "~> 0.1.1", :platforms => [:mingw, :x64_mingw, :mswin]
|
||||||
|
|
||||||
280
docs/Gemfile.lock
Normal file
280
docs/Gemfile.lock
Normal file
|
|
@ -0,0 +1,280 @@
|
||||||
|
GEM
|
||||||
|
remote: https://rubygems.org/
|
||||||
|
specs:
|
||||||
|
activesupport (6.0.4.1)
|
||||||
|
concurrent-ruby (~> 1.0, >= 1.0.2)
|
||||||
|
i18n (>= 0.7, < 2)
|
||||||
|
minitest (~> 5.1)
|
||||||
|
tzinfo (~> 1.1)
|
||||||
|
zeitwerk (~> 2.2, >= 2.2.2)
|
||||||
|
addressable (2.8.0)
|
||||||
|
public_suffix (>= 2.0.2, < 5.0)
|
||||||
|
coffee-script (2.4.1)
|
||||||
|
coffee-script-source
|
||||||
|
execjs
|
||||||
|
coffee-script-source (1.11.1)
|
||||||
|
colorator (1.1.0)
|
||||||
|
commonmarker (0.17.13)
|
||||||
|
ruby-enum (~> 0.5)
|
||||||
|
concurrent-ruby (1.1.9)
|
||||||
|
dnsruby (1.61.7)
|
||||||
|
simpleidn (~> 0.1)
|
||||||
|
em-websocket (0.5.3)
|
||||||
|
eventmachine (>= 0.12.9)
|
||||||
|
http_parser.rb (~> 0)
|
||||||
|
ethon (0.15.0)
|
||||||
|
ffi (>= 1.15.0)
|
||||||
|
eventmachine (1.2.7)
|
||||||
|
execjs (2.8.1)
|
||||||
|
faraday (1.8.0)
|
||||||
|
faraday-em_http (~> 1.0)
|
||||||
|
faraday-em_synchrony (~> 1.0)
|
||||||
|
faraday-excon (~> 1.1)
|
||||||
|
faraday-httpclient (~> 1.0.1)
|
||||||
|
faraday-net_http (~> 1.0)
|
||||||
|
faraday-net_http_persistent (~> 1.1)
|
||||||
|
faraday-patron (~> 1.0)
|
||||||
|
faraday-rack (~> 1.0)
|
||||||
|
multipart-post (>= 1.2, < 3)
|
||||||
|
ruby2_keywords (>= 0.0.4)
|
||||||
|
faraday-em_http (1.0.0)
|
||||||
|
faraday-em_synchrony (1.0.0)
|
||||||
|
faraday-excon (1.1.0)
|
||||||
|
faraday-httpclient (1.0.1)
|
||||||
|
faraday-net_http (1.0.1)
|
||||||
|
faraday-net_http_persistent (1.2.0)
|
||||||
|
faraday-patron (1.0.0)
|
||||||
|
faraday-rack (1.0.0)
|
||||||
|
ffi (1.15.4)
|
||||||
|
forwardable-extended (2.6.0)
|
||||||
|
gemoji (3.0.1)
|
||||||
|
github-pages (222)
|
||||||
|
github-pages-health-check (= 1.17.9)
|
||||||
|
jekyll (= 3.9.0)
|
||||||
|
jekyll-avatar (= 0.7.0)
|
||||||
|
jekyll-coffeescript (= 1.1.1)
|
||||||
|
jekyll-commonmark-ghpages (= 0.1.6)
|
||||||
|
jekyll-default-layout (= 0.1.4)
|
||||||
|
jekyll-feed (= 0.15.1)
|
||||||
|
jekyll-gist (= 1.5.0)
|
||||||
|
jekyll-github-metadata (= 2.13.0)
|
||||||
|
jekyll-mentions (= 1.6.0)
|
||||||
|
jekyll-optional-front-matter (= 0.3.2)
|
||||||
|
jekyll-paginate (= 1.1.0)
|
||||||
|
jekyll-readme-index (= 0.3.0)
|
||||||
|
jekyll-redirect-from (= 0.16.0)
|
||||||
|
jekyll-relative-links (= 0.6.1)
|
||||||
|
jekyll-remote-theme (= 0.4.3)
|
||||||
|
jekyll-sass-converter (= 1.5.2)
|
||||||
|
jekyll-seo-tag (= 2.7.1)
|
||||||
|
jekyll-sitemap (= 1.4.0)
|
||||||
|
jekyll-swiss (= 1.0.0)
|
||||||
|
jekyll-theme-architect (= 0.2.0)
|
||||||
|
jekyll-theme-cayman (= 0.2.0)
|
||||||
|
jekyll-theme-dinky (= 0.2.0)
|
||||||
|
jekyll-theme-hacker (= 0.2.0)
|
||||||
|
jekyll-theme-leap-day (= 0.2.0)
|
||||||
|
jekyll-theme-merlot (= 0.2.0)
|
||||||
|
jekyll-theme-midnight (= 0.2.0)
|
||||||
|
jekyll-theme-minimal (= 0.2.0)
|
||||||
|
jekyll-theme-modernist (= 0.2.0)
|
||||||
|
jekyll-theme-primer (= 0.6.0)
|
||||||
|
jekyll-theme-slate (= 0.2.0)
|
||||||
|
jekyll-theme-tactile (= 0.2.0)
|
||||||
|
jekyll-theme-time-machine (= 0.2.0)
|
||||||
|
jekyll-titles-from-headings (= 0.5.3)
|
||||||
|
jemoji (= 0.12.0)
|
||||||
|
kramdown (= 2.3.1)
|
||||||
|
kramdown-parser-gfm (= 1.1.0)
|
||||||
|
liquid (= 4.0.3)
|
||||||
|
mercenary (~> 0.3)
|
||||||
|
minima (= 2.5.1)
|
||||||
|
nokogiri (>= 1.12.5, < 2.0)
|
||||||
|
rouge (= 3.26.0)
|
||||||
|
terminal-table (~> 1.4)
|
||||||
|
github-pages-health-check (1.17.9)
|
||||||
|
addressable (~> 2.3)
|
||||||
|
dnsruby (~> 1.60)
|
||||||
|
octokit (~> 4.0)
|
||||||
|
public_suffix (>= 3.0, < 5.0)
|
||||||
|
typhoeus (~> 1.3)
|
||||||
|
html-pipeline (2.14.0)
|
||||||
|
activesupport (>= 2)
|
||||||
|
nokogiri (>= 1.4)
|
||||||
|
http_parser.rb (0.8.0)
|
||||||
|
i18n (0.9.5)
|
||||||
|
concurrent-ruby (~> 1.0)
|
||||||
|
jekyll (3.9.0)
|
||||||
|
addressable (~> 2.4)
|
||||||
|
colorator (~> 1.0)
|
||||||
|
em-websocket (~> 0.5)
|
||||||
|
i18n (~> 0.7)
|
||||||
|
jekyll-sass-converter (~> 1.0)
|
||||||
|
jekyll-watch (~> 2.0)
|
||||||
|
kramdown (>= 1.17, < 3)
|
||||||
|
liquid (~> 4.0)
|
||||||
|
mercenary (~> 0.3.3)
|
||||||
|
pathutil (~> 0.9)
|
||||||
|
rouge (>= 1.7, < 4)
|
||||||
|
safe_yaml (~> 1.0)
|
||||||
|
jekyll-avatar (0.7.0)
|
||||||
|
jekyll (>= 3.0, < 5.0)
|
||||||
|
jekyll-coffeescript (1.1.1)
|
||||||
|
coffee-script (~> 2.2)
|
||||||
|
coffee-script-source (~> 1.11.1)
|
||||||
|
jekyll-commonmark (1.3.1)
|
||||||
|
commonmarker (~> 0.14)
|
||||||
|
jekyll (>= 3.7, < 5.0)
|
||||||
|
jekyll-commonmark-ghpages (0.1.6)
|
||||||
|
commonmarker (~> 0.17.6)
|
||||||
|
jekyll-commonmark (~> 1.2)
|
||||||
|
rouge (>= 2.0, < 4.0)
|
||||||
|
jekyll-default-layout (0.1.4)
|
||||||
|
jekyll (~> 3.0)
|
||||||
|
jekyll-feed (0.15.1)
|
||||||
|
jekyll (>= 3.7, < 5.0)
|
||||||
|
jekyll-gist (1.5.0)
|
||||||
|
octokit (~> 4.2)
|
||||||
|
jekyll-github-metadata (2.13.0)
|
||||||
|
jekyll (>= 3.4, < 5.0)
|
||||||
|
octokit (~> 4.0, != 4.4.0)
|
||||||
|
jekyll-mentions (1.6.0)
|
||||||
|
html-pipeline (~> 2.3)
|
||||||
|
jekyll (>= 3.7, < 5.0)
|
||||||
|
jekyll-optional-front-matter (0.3.2)
|
||||||
|
jekyll (>= 3.0, < 5.0)
|
||||||
|
jekyll-paginate (1.1.0)
|
||||||
|
jekyll-readme-index (0.3.0)
|
||||||
|
jekyll (>= 3.0, < 5.0)
|
||||||
|
jekyll-redirect-from (0.16.0)
|
||||||
|
jekyll (>= 3.3, < 5.0)
|
||||||
|
jekyll-relative-links (0.6.1)
|
||||||
|
jekyll (>= 3.3, < 5.0)
|
||||||
|
jekyll-remote-theme (0.4.3)
|
||||||
|
addressable (~> 2.0)
|
||||||
|
jekyll (>= 3.5, < 5.0)
|
||||||
|
jekyll-sass-converter (>= 1.0, <= 3.0.0, != 2.0.0)
|
||||||
|
rubyzip (>= 1.3.0, < 3.0)
|
||||||
|
jekyll-sass-converter (1.5.2)
|
||||||
|
sass (~> 3.4)
|
||||||
|
jekyll-seo-tag (2.7.1)
|
||||||
|
jekyll (>= 3.8, < 5.0)
|
||||||
|
jekyll-sitemap (1.4.0)
|
||||||
|
jekyll (>= 3.7, < 5.0)
|
||||||
|
jekyll-swiss (1.0.0)
|
||||||
|
jekyll-theme-architect (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-cayman (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-dinky (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-hacker (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-leap-day (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-merlot (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-midnight (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-minimal (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-modernist (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-primer (0.6.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-github-metadata (~> 2.9)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-slate (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-tactile (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-theme-time-machine (0.2.0)
|
||||||
|
jekyll (> 3.5, < 5.0)
|
||||||
|
jekyll-seo-tag (~> 2.0)
|
||||||
|
jekyll-titles-from-headings (0.5.3)
|
||||||
|
jekyll (>= 3.3, < 5.0)
|
||||||
|
jekyll-watch (2.2.1)
|
||||||
|
listen (~> 3.0)
|
||||||
|
jemoji (0.12.0)
|
||||||
|
gemoji (~> 3.0)
|
||||||
|
html-pipeline (~> 2.2)
|
||||||
|
jekyll (>= 3.0, < 5.0)
|
||||||
|
kramdown (2.3.1)
|
||||||
|
rexml
|
||||||
|
kramdown-parser-gfm (1.1.0)
|
||||||
|
kramdown (~> 2.0)
|
||||||
|
liquid (4.0.3)
|
||||||
|
listen (3.7.0)
|
||||||
|
rb-fsevent (~> 0.10, >= 0.10.3)
|
||||||
|
rb-inotify (~> 0.9, >= 0.9.10)
|
||||||
|
mercenary (0.3.6)
|
||||||
|
minima (2.5.1)
|
||||||
|
jekyll (>= 3.5, < 5.0)
|
||||||
|
jekyll-feed (~> 0.9)
|
||||||
|
jekyll-seo-tag (~> 2.1)
|
||||||
|
minitest (5.14.4)
|
||||||
|
multipart-post (2.1.1)
|
||||||
|
nokogiri (1.12.5-x86_64-linux)
|
||||||
|
racc (~> 1.4)
|
||||||
|
octokit (4.21.0)
|
||||||
|
faraday (>= 0.9)
|
||||||
|
sawyer (~> 0.8.0, >= 0.5.3)
|
||||||
|
pathutil (0.16.2)
|
||||||
|
forwardable-extended (~> 2.6)
|
||||||
|
public_suffix (4.0.6)
|
||||||
|
racc (1.6.0)
|
||||||
|
rb-fsevent (0.11.0)
|
||||||
|
rb-inotify (0.10.1)
|
||||||
|
ffi (~> 1.0)
|
||||||
|
rexml (3.2.5)
|
||||||
|
rouge (3.26.0)
|
||||||
|
ruby-enum (0.9.0)
|
||||||
|
i18n
|
||||||
|
ruby2_keywords (0.0.5)
|
||||||
|
rubyzip (2.3.2)
|
||||||
|
safe_yaml (1.0.5)
|
||||||
|
sass (3.7.4)
|
||||||
|
sass-listen (~> 4.0.0)
|
||||||
|
sass-listen (4.0.0)
|
||||||
|
rb-fsevent (~> 0.9, >= 0.9.4)
|
||||||
|
rb-inotify (~> 0.9, >= 0.9.7)
|
||||||
|
sawyer (0.8.2)
|
||||||
|
addressable (>= 2.3.5)
|
||||||
|
faraday (> 0.8, < 2.0)
|
||||||
|
simpleidn (0.2.1)
|
||||||
|
unf (~> 0.1.4)
|
||||||
|
terminal-table (1.8.0)
|
||||||
|
unicode-display_width (~> 1.1, >= 1.1.1)
|
||||||
|
thread_safe (0.3.6)
|
||||||
|
typhoeus (1.4.0)
|
||||||
|
ethon (>= 0.9.0)
|
||||||
|
tzinfo (1.2.9)
|
||||||
|
thread_safe (~> 0.1)
|
||||||
|
unf (0.1.4)
|
||||||
|
unf_ext
|
||||||
|
unf_ext (0.0.8)
|
||||||
|
unicode-display_width (1.8.0)
|
||||||
|
zeitwerk (2.5.1)
|
||||||
|
|
||||||
|
PLATFORMS
|
||||||
|
x86_64-linux
|
||||||
|
|
||||||
|
DEPENDENCIES
|
||||||
|
github-pages
|
||||||
|
tzinfo (~> 1.2)
|
||||||
|
tzinfo-data
|
||||||
|
wdm (~> 0.1.1)
|
||||||
|
|
||||||
|
BUNDLED WITH
|
||||||
|
2.2.32
|
||||||
65
docs/_config.yml
Normal file
65
docs/_config.yml
Normal file
|
|
@ -0,0 +1,65 @@
|
||||||
|
# Welcome to Jekyll!
|
||||||
|
#
|
||||||
|
# This config file is meant for settings that affect your whole blog, values
|
||||||
|
# which you are expected to set up once and rarely edit after that. If you find
|
||||||
|
# yourself editing this file very often, consider using Jekyll's data files
|
||||||
|
# feature for the data you need to update frequently.
|
||||||
|
#
|
||||||
|
# For technical reasons, this file is *NOT* reloaded automatically when you use
|
||||||
|
# 'bundle exec jekyll serve'. If you change this file, please restart the server process.
|
||||||
|
#
|
||||||
|
# If you need help with YAML syntax, here are some quick references for you:
|
||||||
|
# https://learn-the-web.algonquindesign.ca/topics/markdown-yaml-cheat-sheet/#yaml
|
||||||
|
# https://learnxinyminutes.com/docs/yaml/
|
||||||
|
#
|
||||||
|
# Site settings
|
||||||
|
# These are used to personalize your new site. If you look in the HTML files,
|
||||||
|
# you will see them accessed via {{ site.title }}, {{ site.email }}, and so on.
|
||||||
|
# You can create any custom variable you would like, and they will be accessible
|
||||||
|
# in the templates via {{ site.myvariable }}.
|
||||||
|
|
||||||
|
title: BRouter
|
||||||
|
description: >- # this means to ignore newlines until "baseurl:"
|
||||||
|
BRouter is a configurable OSM offline router with elevation awareness, Java +
|
||||||
|
Android. Designed to be multi-modal with a particular emphasis on bicycle and
|
||||||
|
energy-based car routing.
|
||||||
|
baseurl: "/brouter" # the subpath of your site, e.g. /blog
|
||||||
|
# url: "" # the base hostname & protocol for your site, e.g. http://example.com
|
||||||
|
|
||||||
|
# Build settings
|
||||||
|
remote_theme: pmarsceill/just-the-docs
|
||||||
|
color_scheme: brouter
|
||||||
|
|
||||||
|
# Footer "Edit this page on GitHub" link text
|
||||||
|
gh_edit_link: true
|
||||||
|
gh_edit_link_text: "Edit this page on GitHub."
|
||||||
|
gh_edit_repository: "https://github.com/zod/brouter"
|
||||||
|
gh_edit_branch: docs
|
||||||
|
gh_edit_source: docs
|
||||||
|
gh_edit_view_mode: tree
|
||||||
|
|
||||||
|
aux_links:
|
||||||
|
"GitHub":
|
||||||
|
- "//github.com/abrensch/brouter"
|
||||||
|
"Discussion Foum":
|
||||||
|
- "https://groups.google.com/group/osm-android-bikerouting"
|
||||||
|
|
||||||
|
# Exclude from processing.
|
||||||
|
# The following items will not be processed, by default.
|
||||||
|
# Any item listed under the `exclude:` key here will be automatically added to
|
||||||
|
# the internal "default list".
|
||||||
|
#
|
||||||
|
# Excluded items can be processed by explicitly listing the directories or
|
||||||
|
# their entries' file path in the `include:` list.
|
||||||
|
#
|
||||||
|
# exclude:
|
||||||
|
# - .sass-cache/
|
||||||
|
# - .jekyll-cache/
|
||||||
|
# - gemfiles/
|
||||||
|
# - Gemfile
|
||||||
|
# - Gemfile.lock
|
||||||
|
# - node_modules/
|
||||||
|
# - vendor/bundle/
|
||||||
|
# - vendor/cache/
|
||||||
|
# - vendor/gems/
|
||||||
|
# - vendor/ruby/
|
||||||
1
docs/_sass/color_schemes/brouter.scss
Normal file
1
docs/_sass/color_schemes/brouter.scss
Normal file
|
|
@ -0,0 +1 @@
|
||||||
|
$link-color: $blue-000;
|
||||||
98
docs/developers/algorithm.md
Normal file
98
docs/developers/algorithm.md
Normal file
|
|
@ -0,0 +1,98 @@
|
||||||
|
---
|
||||||
|
title: "Routing algorithm"
|
||||||
|
parent: Developers
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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*.
|
||||||
10
docs/developers/android_service.md
Normal file
10
docs/developers/android_service.md
Normal file
|
|
@ -0,0 +1,10 @@
|
||||||
|
---
|
||||||
|
parent: Developers
|
||||||
|
---
|
||||||
|
|
||||||
|
# Android Service
|
||||||
|
|
||||||
|
BRouter exposes an [Android
|
||||||
|
Service](https://developer.android.com/guide/components/services) which can be
|
||||||
|
used by other applications to calculate routes. See `IBRouterService.aidl` for
|
||||||
|
the interface definition.
|
||||||
|
|
@ -1,10 +1,16 @@
|
||||||
Build your own BRouter segments files
|
---
|
||||||
=====================================
|
parent: Developers
|
||||||
|
title: Build segment files
|
||||||
|
---
|
||||||
|
|
||||||
|
Build your own segments files
|
||||||
|
=============================
|
||||||
|
|
||||||
BRouter uses its own data format (`.rd5` files), split in tiles of 5 x 5
|
BRouter uses its own data format (`.rd5` files), split in tiles of 5 x 5
|
||||||
in latitude and longitude. You can download the official segment files (weekly
|
in latitude and longitude. You can download the official segment files (weekly
|
||||||
built) from [brouter.de](http://brouter.de/brouter/segments4/) but you can
|
built) from [brouter.de](http://brouter.de/brouter/segments4/) but you can
|
||||||
also build them yourself from an OSM dump.
|
also build them yourself from an OSM dump (e.g. planet or [GeoFabrik
|
||||||
|
extract](https://download.geofabrik.de/))
|
||||||
|
|
||||||
|
|
||||||
## Build the pbfparser
|
## Build the pbfparser
|
||||||
16
docs/developers/http_server.md
Normal file
16
docs/developers/http_server.md
Normal file
|
|
@ -0,0 +1,16 @@
|
||||||
|
---
|
||||||
|
parent: Developers
|
||||||
|
title: HTTP server
|
||||||
|
---
|
||||||
|
|
||||||
|
# Run the BRouter HTTP server
|
||||||
|
|
||||||
|
Helpers scripts are provided in `misc/scripts/standalone` to quickly spawn a
|
||||||
|
BRouter HTTP server for various platforms.
|
||||||
|
|
||||||
|
* Linux/Mac OS: `./misc/scripts/standalone/server.sh`
|
||||||
|
* Windows (using Bash): `./misc/scripts/standalone/server.sh`
|
||||||
|
* Windows (using CMD): `misc\scripts\standalone\server.cmd`
|
||||||
|
|
||||||
|
The API endpoints exposed by this HTTP server are documented in the
|
||||||
|
`ServerHandler.java`
|
||||||
24
docs/developers/index.md
Normal file
24
docs/developers/index.md
Normal file
|
|
@ -0,0 +1,24 @@
|
||||||
|
---
|
||||||
|
title: Developers
|
||||||
|
has_children: true
|
||||||
|
nav_order: 4
|
||||||
|
---
|
||||||
|
|
||||||
|
# Developer Information
|
||||||
|
|
||||||
|
## Profile Development
|
||||||
|
|
||||||
|
BRouter offers [freely configurable routing profiles](../features/costfunctions.md).
|
||||||
|
To extend existing profiles or develop
|
||||||
|
you own profile see [Profile Developers Guide](profile_developers_guide.md) for
|
||||||
|
a technical reference.
|
||||||
|
|
||||||
|
### (Optional) Generate profile variants
|
||||||
|
|
||||||
|
This repository holds examples of BRouter profiles for many different
|
||||||
|
transportation modes. Most of these can be easily customized by setting
|
||||||
|
variables in the first `global` context of the profiles files.
|
||||||
|
|
||||||
|
An helper script is available in `misc/scripts/generate_profile_variants.sh`
|
||||||
|
to help you quickly generate variants based on the default profiles, to create
|
||||||
|
a default set of profiles covering most of the basic use cases.
|
||||||
408
docs/developers/profile_developers_guide.md
Normal file
408
docs/developers/profile_developers_guide.md
Normal file
|
|
@ -0,0 +1,408 @@
|
||||||
|
---
|
||||||
|
parent: Developers
|
||||||
|
---
|
||||||
|
|
||||||
|
Profile developers guide
|
||||||
|
========================
|
||||||
|
{: .no_toc}
|
||||||
|
|
||||||
|
Technical reference for BRouter profile scripts
|
||||||
|
|
||||||
|
1. TOC
|
||||||
|
{:toc}
|
||||||
|
|
||||||
|
The tag-value lookup table
|
||||||
|
--------------------------
|
||||||
|
|
||||||
|
Within the routing data files (rd5), tag information is encoded in a binary
|
||||||
|
bitstream for the way tags and the node tags each.
|
||||||
|
|
||||||
|
To encode and decode to/from this bitstream, a lookup table is used that
|
||||||
|
contains all the tags and values that are considered for encoding.
|
||||||
|
|
||||||
|
For each tag there are 2 special values:
|
||||||
|
|
||||||
|
- `<empty>` if the tag is not set or the value is empty
|
||||||
|
- `unknown` if the value is not contained in the table
|
||||||
|
|
||||||
|
Each value can have optional *aliases*, these alias values are encoded into the
|
||||||
|
same binary value as the associated primary value.
|
||||||
|
|
||||||
|
A profile must use the primary value in expressions, as aliases trigger a parse
|
||||||
|
error. E.g. if there is a line in `lookups.dat` file:
|
||||||
|
|
||||||
|
`bicycle;0001245560 yes allowed`
|
||||||
|
|
||||||
|
then a profile must use `bicycle=yes`, as `bicycle=allowed` gives an error.
|
||||||
|
|
||||||
|
The numbers in the lookup table are statistical information on the frequency of
|
||||||
|
the values in the map of Germany - these are just informational and are not
|
||||||
|
processed by BRouter.
|
||||||
|
|
||||||
|
Context-Separation
|
||||||
|
------------------
|
||||||
|
|
||||||
|
Way-tags and Node-Tags are treated independently, so there are different
|
||||||
|
sections in the lookup table as well as in the profile scripts for each context.
|
||||||
|
The special tags: `---context:way` and `---context:node` mark the beginning of
|
||||||
|
each section.
|
||||||
|
|
||||||
|
An exception from context separation is the node-context, where variables from
|
||||||
|
the way-context of the originating way can be accessed using the `way:` prefix.
|
||||||
|
For the variable nodeaccessgranted there's an additional legacy-hack to access
|
||||||
|
it as a lookup value without prefix:
|
||||||
|
|
||||||
|
`if nodeaccessgranted=yes then ...`
|
||||||
|
|
||||||
|
while in the general case the prefixed expressions are variables:
|
||||||
|
|
||||||
|
`if greater way:costfactor 5 then ...`
|
||||||
|
|
||||||
|
In the profile scripts there is a third context `global` which contains global
|
||||||
|
configuration which is shared for all contexts and is accessible by the routing
|
||||||
|
engine.
|
||||||
|
|
||||||
|
The variables from the `global` section in the profile scripts are read-only
|
||||||
|
visible in the `way` and `node` sections of the scripts.
|
||||||
|
|
||||||
|
Predefined variables in the profile scripts
|
||||||
|
-------------------------------------------
|
||||||
|
|
||||||
|
Some variable names are pre-defined and accessed by the routing engine:
|
||||||
|
|
||||||
|
- for the global section these are:
|
||||||
|
|
||||||
|
- 7 elevation configuration parameters:
|
||||||
|
|
||||||
|
- `downhillcost`
|
||||||
|
- `downhillcutoff`
|
||||||
|
- `uphillcost`
|
||||||
|
- `uphillcutoff`
|
||||||
|
- `elevationpenaltybuffer`
|
||||||
|
- `elevationmaxbuffer`
|
||||||
|
- `elevationbufferreduce`
|
||||||
|
|
||||||
|
- 3 boolean mode-hint flags
|
||||||
|
|
||||||
|
- `validForBikes`
|
||||||
|
- `validForFoot`
|
||||||
|
- `validForCars`
|
||||||
|
|
||||||
|
- 2 variables to change the heuristic coefficients for the 2 routing passes (
|
||||||
|
<0 disables a routing pass )
|
||||||
|
|
||||||
|
- `pass1coefficient`
|
||||||
|
- `pass2coefficient`
|
||||||
|
|
||||||
|
- 3 variables to influence the generation of turn-instructions
|
||||||
|
|
||||||
|
- `turnInstructionMode` 0=none, 1=auto-choose, 2=locus-style,
|
||||||
|
3=osmand-style
|
||||||
|
- `turnInstructionCatchingRange` default=40m
|
||||||
|
- `turnInstructionRoundabouts` default=true generate explicit roundabout
|
||||||
|
hints
|
||||||
|
|
||||||
|
- variables to modify BRouter behaviour
|
||||||
|
|
||||||
|
- `processUnusedTags` default=false
|
||||||
|
|
||||||
|
If an OSM tag is unused within the profile, BRouter totally ignores the
|
||||||
|
tag existence. Skipping unused tags improves BRouter speed. As a side
|
||||||
|
effect, the tag is not even listed in the route segment table nor the
|
||||||
|
table exported as CSV. Setting it to true/1, Brouter-web Data page will
|
||||||
|
list all tags present in the RD5 file.
|
||||||
|
|
||||||
|
- for the way section these are
|
||||||
|
|
||||||
|
- `turncost`
|
||||||
|
- `initialcost`
|
||||||
|
- `costfactor`
|
||||||
|
- `uphillcostfactor`
|
||||||
|
- `downhillcostfactor`
|
||||||
|
- `nodeaccessgranted`
|
||||||
|
- `initialclassifier`
|
||||||
|
- `priorityclassifier`
|
||||||
|
|
||||||
|
- for the node section this is just
|
||||||
|
|
||||||
|
- `initialcost`
|
||||||
|
|
||||||
|
Operators of the profile scripts
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
The profile scripts use polish notation (operator first).
|
||||||
|
|
||||||
|
The `assign` operator is special: it can be used only on the top level of the
|
||||||
|
expression hierarchy and has 2 operands:
|
||||||
|
|
||||||
|
`assign <variable-name> <expression>`
|
||||||
|
|
||||||
|
It just assigns the expression value to this variable (which can be a predefined
|
||||||
|
variable or any other variable, which in this case is defined implicitly). The
|
||||||
|
expression can be a complex expression using other operators.
|
||||||
|
|
||||||
|
All other operators can be used recursively to an unlimited complexity, which
|
||||||
|
means that each operand can be a composed expression starting with an operator
|
||||||
|
and so on.
|
||||||
|
|
||||||
|
All expressions have one of the following basic forms:
|
||||||
|
|
||||||
|
- `<numeric value>`
|
||||||
|
- `<numeric variable>`
|
||||||
|
- `<lookup-match>`
|
||||||
|
- `<1-op-operator> <operand>`
|
||||||
|
- `<2-op-operator> <operand> <operand>`
|
||||||
|
- `<3-op-operator> <operand> <operand> <operand>`
|
||||||
|
|
||||||
|
- A numeric value is just a number, floating point, with `.` as decimal
|
||||||
|
separator. Boolean values are treated as numbers as well, with `0` = `false`
|
||||||
|
and every nonzero value = `true`.
|
||||||
|
|
||||||
|
- A lookup match has the form `<tag-name>=<value>`, e.g. `highway=primary` Only
|
||||||
|
the primary values can be used in lookup-matches, not aliases. The `<empty>`
|
||||||
|
value is referred to as an empty string, e.g. `access=`
|
||||||
|
|
||||||
|
- 1 Operand operators are:
|
||||||
|
|
||||||
|
- `not <boolean expression>`
|
||||||
|
|
||||||
|
- 2 Operand operators are:
|
||||||
|
|
||||||
|
- `or <boolean expression 1> <boolean expression 2>`
|
||||||
|
- `and <boolean expression 1> <boolean expression 2>`
|
||||||
|
- `xor <boolean expression 1> <boolean expression 2>`
|
||||||
|
- `multiply <numeric expression 1> <numeric expression 2>`
|
||||||
|
- `add <numeric expression 1> <numeric expression 2>`
|
||||||
|
- `sub <numeric expression 1> <numeric expression 2>`
|
||||||
|
- `max <numeric expression 1> <numeric expression 2>`
|
||||||
|
- `min <numeric expression 1> <numeric expression 2>`
|
||||||
|
- `equal <numeric expression 1> <numeric expression 2>`
|
||||||
|
- `greater <numeric expression 1> <numeric expression 2>`
|
||||||
|
- `lesser <numeric expression 1> <numeric expression 2>`
|
||||||
|
|
||||||
|
- 3 Operand operators are:
|
||||||
|
|
||||||
|
- `switch <boolean-expression> <true-expression> <false-expression>`
|
||||||
|
|
||||||
|
So the switch expression has a numeric value which is the true-expression if
|
||||||
|
the boolean expression is true, the false-expression otherwise.
|
||||||
|
|
||||||
|
Syntactic Sugar
|
||||||
|
---------------
|
||||||
|
|
||||||
|
To improve the readablity of the profile scripts, some syntactic variations are
|
||||||
|
possible:
|
||||||
|
|
||||||
|
- if then else: `if` can be used instead of the `switch` operator, if the
|
||||||
|
additional keywords `then` and `else` are placed between the operators:
|
||||||
|
|
||||||
|
`if <boolean-expression> then <true-expression> else <false-expression>`
|
||||||
|
|
||||||
|
- Parentheses: each expression can be surrounded by parentheses:
|
||||||
|
`(<expression>)`
|
||||||
|
|
||||||
|
Please note that the profile syntax, due to the polish notation, does not need
|
||||||
|
parentheses, they are always optional. However, if there are parentheses, the
|
||||||
|
parser checks if they really match the expression boundaries.
|
||||||
|
|
||||||
|
- or-ing lookup-matches: the pipe-symbol can be used as a short syntax for
|
||||||
|
lookup matches where more than one value is accepted for a key:
|
||||||
|
`highway=primary|secondary|tertiary`
|
||||||
|
|
||||||
|
- additional `=` symbol for `assign` operations:
|
||||||
|
|
||||||
|
`assign <variable-name> = <expression>`
|
||||||
|
|
||||||
|
- boolean constants: `true` and `false` can be used instead of 1 and 0
|
||||||
|
|
||||||
|
Please note that the tokenizer always expects blank space to separate symbols
|
||||||
|
and expressions so it is not allowed to place parentheses or the `=` symbol
|
||||||
|
without separating blank space!
|
||||||
|
|
||||||
|
The initial cost classifier
|
||||||
|
---------------------------
|
||||||
|
|
||||||
|
To trigger the addition of the `initialcost`, another variable is used:
|
||||||
|
`initialclassifier` - any change in the value of that variable leads to adding
|
||||||
|
the value of `initialcost`.
|
||||||
|
|
||||||
|
Initial cost is used typically for a ferry, where you want to apply a penalty
|
||||||
|
independent of the length of the ferry line.
|
||||||
|
|
||||||
|
Another useful case may be an initial cost for bicycle mounting/dismounting,
|
||||||
|
having set an initialclassifier for ways without bicycle access, with high
|
||||||
|
initialcost. For backward compatibility, if `initialclassifier` = 0, it is
|
||||||
|
replaced by the costfactor.
|
||||||
|
|
||||||
|
The priority classifier
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
`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, as far as it can be
|
||||||
|
predicted from OSM data.
|
||||||
|
|
||||||
|
To avoid a navigation instruction flood, it was decided that the instructions
|
||||||
|
are provided only if:
|
||||||
|
|
||||||
|
1. You are supposed to turn at a crossroad/junction and some other ways having
|
||||||
|
the same or higher `priorityclassifier` value.
|
||||||
|
|
||||||
|
2. You are supposed to go straight ahead and some other ways having the higher
|
||||||
|
`priorityclassifier` value.
|
||||||
|
|
||||||
|
The elevation buffer ( From Poutnik's glossary )
|
||||||
|
------------------------------------------------
|
||||||
|
|
||||||
|
With related 3 internal BRouter variables:
|
||||||
|
|
||||||
|
- `elevationpenaltybuffer`
|
||||||
|
- `elevationmaxbuffer`
|
||||||
|
- `elevationbufferreduce`
|
||||||
|
|
||||||
|
the 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 km = 15 m` is taken away and only remaining 5 m accumulates. But if
|
||||||
|
it climbed only 10 m on those 500 m, 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` - default 5(m).
|
||||||
|
|
||||||
|
The variable value is used for 2 purposes
|
||||||
|
|
||||||
|
- with `buffer content > elevationpenaltybuffer`, it starts partially convert
|
||||||
|
the buffered elevation to ElevationCost by Up/downhillcost
|
||||||
|
|
||||||
|
- with `elevation taken = MIN (buffer content - elevationpenaltybuffer, WayLength[km] * elevationbufferreduce*10`
|
||||||
|
Up/downhillcost factor takes place instead of costfactor at the percentage
|
||||||
|
of how much is `WayLength[km] * elevationbufferreduce*10` is saturated by
|
||||||
|
the buffer content above elevationpenaltybuffer.
|
||||||
|
|
||||||
|
- `elevationmaxbuffer` - default 10(m)
|
||||||
|
|
||||||
|
is the size of the buffer, above which all elevation is converted to
|
||||||
|
Elevationcost by Up/Downhillcost ratio, and - if defined -
|
||||||
|
Up/downhillcostfactor fully replaces costfactor in way cost calculation.
|
||||||
|
|
||||||
|
- `elevationbufferreduce` - default 0(slope%)
|
||||||
|
|
||||||
|
is rate of conversion of the buffer content above elevationpenaltybuffer to
|
||||||
|
ElevationCost. For a way of length L, the amount of converted elevation is
|
||||||
|
L[km] * elevationbufferreduce[%] * 10. The elevation to Elevationcost
|
||||||
|
conversion ratio is given by Up/downhillcost.
|
||||||
|
|
||||||
|
Example: Let's 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.5m 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 5m
|
||||||
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
Technical constraints
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
- The costfactor is required to be >= 1, otherwise the cost-cutoff logic of the
|
||||||
|
routing algorithm does not work and you get wrong results.
|
||||||
|
|
||||||
|
- The profile should be able to find a route with an average costfactor not very
|
||||||
|
much larger than one, because otherwise the routing algorithm will not find a
|
||||||
|
reasonable cost-cutoff, leading to a very large search area and thus to long
|
||||||
|
processing times.
|
||||||
|
|
||||||
|
- Forbidden ways or nodes must be treated as very high cost, because there is no
|
||||||
|
*forbidden* value. Technically, values >= 10000 for a (way-)costfactor, and >=
|
||||||
|
1000000 for a nodes `initalcost` are treated as infinity, so please use these
|
||||||
|
as the *forbidden* values.
|
||||||
|
|
||||||
|
- Ways with costfactor >= 10000 are considered as if they did not exist at all.
|
||||||
|
|
||||||
|
- Ways with costfactor = 9999 are considered as if they did not exist during
|
||||||
|
route calculation, but the navigation hint generator takes them into account.
|
||||||
|
|
||||||
|
|
||||||
|
Developing and debugging scripts
|
||||||
|
--------------------------------
|
||||||
|
|
||||||
|
For developing scripts, the *brouter-web* web-application is your friend. You
|
||||||
|
can use that either online at https://brouter.de/brouter-web or set up a local
|
||||||
|
installation.
|
||||||
|
|
||||||
|
*brouter-web* has a window at the lower left corner with a *Profile* and a
|
||||||
|
*Data* tab. Here, you can upload profile scripts and see the individual cost
|
||||||
|
calculations per way-section in the *Data*-tab.
|
||||||
|
|
||||||
|
For profile debugging activate `assign processUnusedTags = true` to see all
|
||||||
|
present OSM tags on the Data tab, not just those used in the tested profile.
|
||||||
|
|
||||||
|
|
||||||
|
Lookup-Table evolution and the the *major* and *minor* versions
|
||||||
|
---------------------------------------------------------------
|
||||||
|
|
||||||
|
The lookup-table is allowed to grow over time, to include more tags and values
|
||||||
|
as needed. To support that evolution, it carries a major and a minor version
|
||||||
|
number. These numbers are also encoded into the routing data files, taken from
|
||||||
|
the lookups.dat that is used to pre-process the routing data files.
|
||||||
|
|
||||||
|
A major version change is considered to always break compatibility between the
|
||||||
|
routing datafiles and the lookup table.
|
||||||
|
|
||||||
|
A minor version change keeps the routing data files and the lookup-table
|
||||||
|
compatible in both directions, using the following rules:
|
||||||
|
|
||||||
|
- if the data contains a key that is not contained in the lookup tables, it is
|
||||||
|
ignored
|
||||||
|
|
||||||
|
- if the data contains a value that is not contained in the lookup tables (but
|
||||||
|
its key is known) that value is treated as `unknown`
|
||||||
|
|
||||||
|
- if a profile uses a key that is not present in the data, it sees empty
|
||||||
|
(=unset) values for that key
|
||||||
|
|
||||||
|
- if a profile uses a value that is not present in the data, lookup matches for
|
||||||
|
that value are always false.
|
||||||
|
|
||||||
|
For a minor version change it is required that tags are only appended at the end
|
||||||
|
of the table (or replace one of the dummy tags located between the way-tags and
|
||||||
|
the relation pseudo-tags), and that values are only appended at the end of the
|
||||||
|
value lists. This is because the routing data files address tags and values by
|
||||||
|
their sequence numbers, so changing sequences would produce garbage data.
|
||||||
|
|
||||||
|
Other resources
|
||||||
|
---------------
|
||||||
|
|
||||||
|
See [Poutnik's glossary](https://github.com/poutnikl/Brouter-profiles/wiki/Glossary)
|
||||||
|
as a complementary source about various profile internals.
|
||||||
24
docs/features/alternatives.md
Normal file
24
docs/features/alternatives.md
Normal file
|
|
@ -0,0 +1,24 @@
|
||||||
|
---
|
||||||
|
parent: Features
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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.
|
||||||
31
docs/features/costfunctions.md
Normal file
31
docs/features/costfunctions.md
Normal file
|
|
@ -0,0 +1,31 @@
|
||||||
|
---
|
||||||
|
parent: Features
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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](https://brouter.de/brouter/profiles2/) provided for the online router.
|
||||||
|
|
||||||
|
See the trekking-profile [`trekking.brf`](https://brouter.de/brouter/profiles2/trekking.brf) as the
|
||||||
|
reference-profile with some explanations on the meaning of this script.
|
||||||
|
|
||||||
|
See the [Profile Developers Guide](../developers/profile_developers_guide.md)
|
||||||
|
for a technical reference.
|
||||||
19
docs/features/cycleroutes.md
Normal file
19
docs/features/cycleroutes.md
Normal file
|
|
@ -0,0 +1,19 @@
|
||||||
|
---
|
||||||
|
parent: Features
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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).
|
||||||
28
docs/features/elevation.md
Normal file
28
docs/features/elevation.md
Normal file
|
|
@ -0,0 +1,28 @@
|
||||||
|
---
|
||||||
|
parent: Features
|
||||||
|
---
|
||||||
|
|
||||||
|
# Elevation awareness
|
||||||
|
|
||||||
|
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.
|
||||||
5
docs/features/index.md
Normal file
5
docs/features/index.md
Normal file
|
|
@ -0,0 +1,5 @@
|
||||||
|
---
|
||||||
|
title: Features
|
||||||
|
has_children: true
|
||||||
|
nav_order: 2
|
||||||
|
---
|
||||||
29
docs/features/offline.md
Normal file
29
docs/features/offline.md
Normal file
|
|
@ -0,0 +1,29 @@
|
||||||
|
---
|
||||||
|
parent: Features
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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.
|
||||||
16
docs/features/vianogo.md
Normal file
16
docs/features/vianogo.md
Normal file
|
|
@ -0,0 +1,16 @@
|
||||||
|
---
|
||||||
|
parent: Features
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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.
|
||||||
|
|
||||||
|
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.
|
||||||
|
|
||||||
|
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.
|
||||||
70
docs/index.md
Normal file
70
docs/index.md
Normal file
|
|
@ -0,0 +1,70 @@
|
||||||
|
---
|
||||||
|
layout: default
|
||||||
|
title: Home
|
||||||
|
nav_order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
# 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](developers/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 [Android quickstart guide](users/android_quickstart.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)
|
||||||
22
docs/resources.md
Normal file
22
docs/resources.md
Normal file
|
|
@ -0,0 +1,22 @@
|
||||||
|
# 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)](https://brouter.de/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)](https://brouter.de/brouter_bin/fossgis_2015_neues_zu_brouter.mp4)
|
||||||
342
docs/revisions.md
Normal file
342
docs/revisions.md
Normal file
|
|
@ -0,0 +1,342 @@
|
||||||
|
# Revision history
|
||||||
|
|
||||||
|
(ZIP-Archives including APK, readme + profiles)
|
||||||
|
|
||||||
|
### [brouter-1.6.3.zip](../brouter_bin/brouter-1.6.3.zip) (current revision, 21.12.2021)
|
||||||
|
|
||||||
|
- Enable Android 11
|
||||||
|
- Move storage to /Android/media/btools.routingapp
|
||||||
|
- Coord reader in app specific folder (favourites.gpx and nogo*.gpx)
|
||||||
|
- new Logo
|
||||||
|
- increased download speed limit from 4 to 16 MBit/s
|
||||||
|
|
||||||
|
### [brouter_1_6_1.zip](../brouter_bin/brouter_1_6_1.zip) (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](https://brouter.de/brouter/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](developers/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
|
||||||
146
docs/users/android_advanced.md
Normal file
146
docs/users/android_advanced.md
Normal file
|
|
@ -0,0 +1,146 @@
|
||||||
|
---
|
||||||
|
parent: Using BRouter
|
||||||
|
nav_order: 2
|
||||||
|
---
|
||||||
|
|
||||||
|
# Android advanced configuration
|
||||||
|
|
||||||
|
### Directory structure
|
||||||
|
|
||||||
|
BRouter uses several subdirectories inside the base directory.
|
||||||
|
|
||||||
|
| directory | description |
|
||||||
|
| --------------------------------- | -------------------------------------------- |
|
||||||
|
| `<basedir>/brouter` | |
|
||||||
|
| `<basedir>/brouter/modes` | routing-mode/profile mapping and route cache |
|
||||||
|
| `<basedir>/brouter/profiles2` | lookup-table and routing-profiles (\*.brf) |
|
||||||
|
| `<basedir>/brouter/segments4` | **routing data files (\*.rd5)** |
|
||||||
|
| `<basedir>/brouter/import` | allow a small file exchange with other apps |
|
||||||
|
| `<basedir>/brouter/import/tracks` | place the `nogo*.gpx` files here |
|
||||||
|
|
||||||
|
`modes` contains `serviceconfig.dat` which defines _routing-mode_ /
|
||||||
|
_routing-profile_ mapping and cached route results which are used for
|
||||||
|
recalculations.
|
||||||
|
|
||||||
|
`profiles2` contains `lookup.dat` (OSM tag access), `serverconfig.txt` and
|
||||||
|
_routing-profiles_.
|
||||||
|
|
||||||
|
`segments4` contains `storageconfig.txt` and routing data files (\*.rd5). You
|
||||||
|
can download them using the _Download Manager_ or as described in
|
||||||
|
[Download Routing Segments](download_segments.md).
|
||||||
|
|
||||||
|
### Configuration files
|
||||||
|
|
||||||
|
#### serverconfig.txt
|
||||||
|
|
||||||
|
`serverconfig.txt` is used to configure download information for routing
|
||||||
|
profiles and routing segments.
|
||||||
|
|
||||||
|
#### serviceconfig.dat
|
||||||
|
|
||||||
|
`serviceconfig.dat` is used to configure mapping between _routing-mode_ and
|
||||||
|
_routing-profile_.
|
||||||
|
|
||||||
|
#### storageconfig.txt
|
||||||
|
|
||||||
|
`storageconfig.txt` is used to specifiy additional paths which BRouter should
|
||||||
|
use.
|
||||||
|
|
||||||
|
* `secondary_segment_dir` points to an additional directory containing routing
|
||||||
|
data files. This can be located anywhere.
|
||||||
|
|
||||||
|
When searching for datafiles, both the download manager and the router first
|
||||||
|
look in the primary (brouter/segments4) and then in the secondary directory.
|
||||||
|
On the other hand, the download manager always writes new datafiles to the
|
||||||
|
primary directory, so the secondary directory is read-only.
|
||||||
|
|
||||||
|
You can move datafiles downloaded by the download-manager to the secondary
|
||||||
|
directory, by using a file manager, in order to free disk space on the
|
||||||
|
internal card.
|
||||||
|
|
||||||
|
* `additional_maptool_dir` points to a directory that should be scanned for
|
||||||
|
maptool-installations in addition to the standard-guesses.
|
||||||
|
|
||||||
|
#### Redirect files
|
||||||
|
|
||||||
|
When using the _file interface_ with waypoints from other app's storage BRouter
|
||||||
|
tries to write the calculated tracks to the app storage. Depending on the
|
||||||
|
Android version this won't work. BRouter can be configured to write tracks to a
|
||||||
|
different directory by creating a `brouter.redirect` file which contains a
|
||||||
|
single line with the absolute path to the folder where the tracks should be
|
||||||
|
written.
|
||||||
|
|
||||||
|
* For LocusMap `brouter.redirect` has to be located in `Locus/mapItems`
|
||||||
|
* For OruxMaps `brouter.redirect` has to be located in `oruxmaps/tracklogs`
|
||||||
|
* For OsmAnd `brouter.redirect` has to be located in `osmand/tracks`
|
||||||
|
|
||||||
|
## Using nogo-areas
|
||||||
|
|
||||||
|
There's a special naming-convention to specify nogo-areas:
|
||||||
|
|
||||||
|
`nogo[radius] [name]` defines a nogo-area, where radius (in Meter) is optional
|
||||||
|
and defaults to 20m, and the name is also optional. So `nogo`, `nogo1000`, `nogo
|
||||||
|
roadblock`, `nogo200 badferry` are all valid names for nogo-waypoints.
|
||||||
|
|
||||||
|
The effect is that BRouter searches a route that avoids the area defined by the
|
||||||
|
position and the radius of the nogo-area.
|
||||||
|
|
||||||
|
Nogo-areas are used when routing via _service interface_ and _file interface_.
|
||||||
|
|
||||||
|
When using the _file interface_ you will get a nogo-dialog allowing to de-select
|
||||||
|
them if nogo-waypoints are found in the waypoint-database. This de-selection can
|
||||||
|
also be bound to a service mode using the _Server Mode_ button to make it
|
||||||
|
effective using the _service interface_ as well, but initially, every nogo-area
|
||||||
|
is effective in the _service interface_.
|
||||||
|
|
||||||
|
Nogo-areas can be used either to account for real obstacles or to enforce
|
||||||
|
personal routing preferences.
|
||||||
|
|
||||||
|
## Routing via _file interface_
|
||||||
|
|
||||||
|
The other option is using the BRouter app to calculate a route. This is the
|
||||||
|
prefered option when calculating long-distance-routes that would not finish
|
||||||
|
within the 60 seconds timout if calculated via the _service interface_.
|
||||||
|
|
||||||
|
To do this, start the BRouter app, select two or more waypoints and then start
|
||||||
|
the route calculation. BRouter either reads waypoints from the `import` folder
|
||||||
|
or tries to read waypoints from other map tools if it has the required
|
||||||
|
permission. These waypoints are called _Favorites_ in OsmAnd, _POIs_ in Locus or
|
||||||
|
_Waypoints_ in Oruxmaps and allow to associate a location with a name.
|
||||||
|
|
||||||
|
If your waypoint database contains a `from` and `to` waypoint the waypoint
|
||||||
|
selection will be skipped. BRouter also uses `via1`, ..., `via9` as via
|
||||||
|
waypoints.
|
||||||
|
|
||||||
|
If a route is calculated, it is stored as `brouter0.gpx`. Depending on the
|
||||||
|
waypoint database and permissions BRouter stores the route in
|
||||||
|
`<basedir>/import/tracks` or in the map tool track directory. If started once
|
||||||
|
more with identical input, BRouter will store a second route broute1.gpx for the
|
||||||
|
first alternative and so on.
|
||||||
|
|
||||||
|
### Permission issues
|
||||||
|
|
||||||
|
If using the file interface BRouter needs to access the files from other apps.
|
||||||
|
Depending on your android version, your BRouter version and location of other
|
||||||
|
apps locations it will be impossible to read or write those files.
|
||||||
|
|
||||||
|
## Mixed operation: _timeout-free recalculations_
|
||||||
|
|
||||||
|
You can combine both operation modes (_service interface_ + _file interface_ to
|
||||||
|
become able to calculate very long distances, but make use of the advantages of
|
||||||
|
the service interface as well, especially the dynamic recalculations if you get
|
||||||
|
off the track, without running into the 60 seconds timeout.
|
||||||
|
|
||||||
|
To support this, BRouter can do _timeout free recalculations_. It works by
|
||||||
|
initially calculating a track to your destination and binding it to one or more
|
||||||
|
routing-modes using the _Server Mode_ button. This way, BRouter stores a
|
||||||
|
_reference track_ in the `brouter/modes` subdirectory.
|
||||||
|
|
||||||
|
If afterwards a route to the exact same destination is calculated via the
|
||||||
|
service interface, BRouter uses a special calculation mode that makes use of the
|
||||||
|
reference track for faster processing that is guaranteed to give a result within
|
||||||
|
60 seconds. _Exact same_ destination means withing 5m, so best use the same
|
||||||
|
waypoint for re-calculating that you used for the initial calculation.
|
||||||
|
|
||||||
|
This way you can follow a long distance route via the _service interface_,
|
||||||
|
enjoying automatic recalculations if you get off the track.
|
||||||
92
docs/users/android_quickstart.md
Normal file
92
docs/users/android_quickstart.md
Normal file
|
|
@ -0,0 +1,92 @@
|
||||||
|
---
|
||||||
|
parent: Using BRouter
|
||||||
|
nav_order: 1
|
||||||
|
---
|
||||||
|
|
||||||
|
# Android quickstart guide
|
||||||
|
|
||||||
|
### Choosing and installing a map tool
|
||||||
|
|
||||||
|
BRouter just calculates tracks as GPX or GeoJSON files. It does not display maps
|
||||||
|
or give any navigation instuctions. Therefore you need a map-tool in order for
|
||||||
|
BRouter to be useful.
|
||||||
|
|
||||||
|
Several map tools support routing with BRouter:
|
||||||
|
|
||||||
|
- [_OsmAnd_](http://www.osmand.net): GPLv3, Free (limited features) and paid version available
|
||||||
|
- [_Locus Map_](http://www.locusmap.eu): Proprietary, Free (ads) and paid version available
|
||||||
|
- [_Oruxmaps_](http://www.oruxmaps.com): Proprietary, Free (previous version) and paid version available
|
||||||
|
|
||||||
|
Install any of those map tools using your favorite app store.
|
||||||
|
|
||||||
|
### Installing BRouter
|
||||||
|
|
||||||
|
You can install BRouter either from
|
||||||
|
[F-Droid](https://f-droid.org/packages/btools.routingapp), [Google Play
|
||||||
|
Store](https://play.google.com/store/apps/details?id=btools.routingapp) or from
|
||||||
|
the APK contained in the releases available in the [Revision
|
||||||
|
History](https://brouter.de/brouter/revisions.html).
|
||||||
|
|
||||||
|
### Choosing a base directory
|
||||||
|
|
||||||
|
When first starting BRouter (or after deleting/moving the base directory), it
|
||||||
|
asks for a directory and gives you proposals plus the option to enter any other
|
||||||
|
base directory.
|
||||||
|
|
||||||
|
Most phones have an internal and an external storage, where the external storage
|
||||||
|
is a SD card which can be removed from the device.
|
||||||
|
|
||||||
|
Navigation needs big data files that usually should go on an external storage
|
||||||
|
because it provides larger capacity. You should accept the external storage,
|
||||||
|
which is usually the one with the most space available.
|
||||||
|
|
||||||
|
Since Android 11 apps can only write to their app-specific storage so BRouter
|
||||||
|
can only use `<...>/Android/media/btools.routingapp/` as base directory. The
|
||||||
|
app-specific storage can be located on internal or external storage.
|
||||||
|
|
||||||
|
On Android versions prior to 11 it is possible to read and write to other
|
||||||
|
locations which is used for the _file interface_. For the _service interface_
|
||||||
|
access to other apps app-specific storage isn't required.
|
||||||
|
|
||||||
|
### Download routing segments
|
||||||
|
|
||||||
|
BRouter requires routing data which is independent of the displayed map of a map
|
||||||
|
tool. Routing segments (`rd5`) can be downloaded using the BRouter _Download
|
||||||
|
Manager_.
|
||||||
|
|
||||||
|
## Routing via _service interface_
|
||||||
|
|
||||||
|
BRouter is best used via it's _service interface_. It provides a service which
|
||||||
|
can be used by map tools without starting the BRouter app.
|
||||||
|
|
||||||
|
To use BRouter in your map tool you have to configure the map tool to use
|
||||||
|
BRouter as navigation service.
|
||||||
|
|
||||||
|
- [Instructions for LocusMap](https://docs.locusmap.eu/doku.php?id=manual:faq:how_to_navigate_offline)
|
||||||
|
- [Instructions for OsmAnd](osmand.md)
|
||||||
|
|
||||||
|
Note: OsmAnd only displays BRouter as navigation service if BRouter is
|
||||||
|
installed. You have to install BRouter before configuring OsmAnd.
|
||||||
|
|
||||||
|
The _service interface_ allows specifing either a _routing-mode_ (used by OsmAnd
|
||||||
|
and OruxMaps) or a _routing-profile_ (used by LocusMap). When using a
|
||||||
|
_routing-mode_ BRouter selects the _routing-profile_ according to a mapping.
|
||||||
|
|
||||||
|
By default BRouter uses the following mapping:
|
||||||
|
|
||||||
|
| routing-mode | routing-profile |
|
||||||
|
| -------------- | --------------- |
|
||||||
|
| motorcar_fast | car-test |
|
||||||
|
| motorcar_short | moped |
|
||||||
|
| bicycle_fast | fastbike |
|
||||||
|
| bicycle_short | trekking |
|
||||||
|
| foot_fast | shortest |
|
||||||
|
| foot_short | shortest |
|
||||||
|
|
||||||
|
This mapping, however, can be changed any time by starting the BRouter and using
|
||||||
|
the _Server Mode_.
|
||||||
|
|
||||||
|
If your routing request fails due to timeout you can open BRouter and select
|
||||||
|
_Server Mode_ and recalculate the route using _\<repeat:...\>_. BRouter caches
|
||||||
|
the routing result and further requests using the _same_ destination using the
|
||||||
|
_service interface_ will be successful.
|
||||||
23
docs/users/download_segments.md
Normal file
23
docs/users/download_segments.md
Normal file
|
|
@ -0,0 +1,23 @@
|
||||||
|
---
|
||||||
|
parent: Using BRouter
|
||||||
|
---
|
||||||
|
|
||||||
|
# Download Routing Segments
|
||||||
|
|
||||||
|
Routing data files are organised as 5\*5 degree files, with the filename
|
||||||
|
containing the south-west corner of the square, which means:
|
||||||
|
|
||||||
|
- You want to route near West48/North37 -> you need `W50_N35.rd5`
|
||||||
|
- You want to route near East7/North47 -> you need `E5_N45.rd5`
|
||||||
|
|
||||||
|
These data files, called _segments_ across BRouter, are generated from
|
||||||
|
[OpenStreetMap](https://www.openstreetmap.org/) data and stored in a custom
|
||||||
|
binary format (rd5) for improved efficiency of BRouter routing.
|
||||||
|
|
||||||
|
## Download them from brouter.de
|
||||||
|
|
||||||
|
Segments files from the whole planet are generated weekly at
|
||||||
|
[https://brouter.de/brouter/segments4/](http://brouter.de/brouter/segments4/).
|
||||||
|
|
||||||
|
You can download one or more segments files, covering the area of the planet
|
||||||
|
your want to route, into the `segments4` directory.
|
||||||
22
docs/users/index.md
Normal file
22
docs/users/index.md
Normal file
|
|
@ -0,0 +1,22 @@
|
||||||
|
---
|
||||||
|
has_children: true
|
||||||
|
nav_order: 3
|
||||||
|
---
|
||||||
|
|
||||||
|
# Using BRouter
|
||||||
|
|
||||||
|
## Online
|
||||||
|
|
||||||
|
Check [brouter-web](https://brouter.de/brouter-web/) or
|
||||||
|
[bikerouter.de](https://bikerouter.de/) if you want to use BRouter online.
|
||||||
|
|
||||||
|
## BRouter on Android
|
||||||
|
|
||||||
|
BRouter provides offline route calculation on Android. To get started with
|
||||||
|
BRouter on Android see the [Quickstart](android_quickstart.md).
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
|
@ -1,9 +1,14 @@
|
||||||
Using BRouter on Android with OSMAnd
|
---
|
||||||
|
parent: Using BRouter
|
||||||
|
title: OsmAnd
|
||||||
|
---
|
||||||
|
|
||||||
|
Using BRouter on Android with OsmAnd
|
||||||
====================================
|
====================================
|
||||||
|
|
||||||
BRouter integration in OSMAnd changed a lot during the summer of 2019. This
|
BRouter integration in OsmAnd changed a lot during the summer of 2019. This
|
||||||
guide assumes you are using the BRouter Android app in version 1.5.0 or higher
|
guide assumes you are using the BRouter Android app in version 1.5.0 or higher
|
||||||
as well as OSMAnd in version 3.4 or higher.
|
as well as OsmAnd in version 3.4 or higher.
|
||||||
|
|
||||||
|
|
||||||
## Installing BRouter app on your Android device
|
## Installing BRouter app on your Android device
|
||||||
|
|
@ -26,9 +31,9 @@ the areas you want to route in. Then click "Start Download" and BRouter will
|
||||||
start downloading the [segments](http://brouter.de/brouter/segments4/) files
|
start downloading the [segments](http://brouter.de/brouter/segments4/) files
|
||||||
for the selected areas.
|
for the selected areas.
|
||||||
|
|
||||||
<img src="./brouter-main.png" alt="Main menu of BRouter android app"/>
|
<img src="osmand/brouter-main.png" alt="Main menu of BRouter android app"/>
|
||||||
|
|
||||||
<img src="./brouter-grid.png" alt="Grid selection of segments to download"/>
|
<img src="osmand/brouter-grid.png" alt="Grid selection of segments to download"/>
|
||||||
|
|
||||||
Note that you will have to repeat this step periodically, whenever you want to have an
|
Note that you will have to repeat this step periodically, whenever you want to have an
|
||||||
updated version of the OSM data used for the routing.
|
updated version of the OSM data used for the routing.
|
||||||
|
|
@ -41,24 +46,24 @@ entry on the main menu. Select the routing profile you want to use and click
|
||||||
"Server-Mode". Then, tick the boxes for the routing modes you want to use this
|
"Server-Mode". Then, tick the boxes for the routing modes you want to use this
|
||||||
profile for. You can use two different profiles per transportation mode, which
|
profile for. You can use two different profiles per transportation mode, which
|
||||||
will be mapped to the "shortest" and "fastest" presets (these are just
|
will be mapped to the "shortest" and "fastest" presets (these are just
|
||||||
labelling) in OSMAnd.
|
labelling) in OsmAnd.
|
||||||
|
|
||||||
<img src="./brouter-profiles.png" alt="Profiles selection"/>
|
<img src="osmand/brouter-profiles.png" alt="Profiles selection"/>
|
||||||
|
|
||||||
<img src="./brouter-profiles-summary.png" alt="Profiles selection summary"/>
|
<img src="osmand/brouter-profiles-summary.png" alt="Profiles selection summary"/>
|
||||||
|
|
||||||
|
|
||||||
## Configure OSMAnd to make use of BRouter offline navigation
|
## Configure OsmAnd to make use of BRouter offline navigation
|
||||||
|
|
||||||
You can now create an "Application profile" in OSMAnd which will be using
|
You can now create an "Application profile" in OsmAnd which will be using
|
||||||
BRouter for offline routing. Go to Settings -> Application profiles -> Add and
|
BRouter for offline routing. Go to Settings -> Application profiles -> Add and
|
||||||
create a new profile based on the base profile of your choice (cycling here,
|
create a new profile based on the base profile of your choice (cycling here,
|
||||||
for bicycle routing), with a custom name of your choice ("BRouter" on the
|
for bicycle routing), with a custom name of your choice ("BRouter" on the
|
||||||
screenshot below) and making use of "BRouter (offline)" for navigation.
|
screenshot below) and making use of "BRouter (offline)" for navigation.
|
||||||
|
|
||||||
<img src="./brouter-osmand.png" alt="BRouter configuration in OSMAnd
|
<img src="osmand/brouter-osmand.png" alt="BRouter configuration in OsmAnd
|
||||||
application profiles"/>
|
application profiles"/>
|
||||||
|
|
||||||
The BRouter app should be launched before OSMAnd for this specific entry to
|
The BRouter app should be launched before OsmAnd for this specific entry to
|
||||||
appear in OSMAnd. Therefore, if you cannot find "BRouter (offline)" navigation
|
appear in OsmAnd. Therefore, if you cannot find "BRouter (offline)" navigation
|
||||||
option, you should force quit OSMAnd and restart it.
|
option, you should force quit OsmAnd and restart it.
|
||||||
|
Before Width: | Height: | Size: 44 KiB After Width: | Height: | Size: 44 KiB |
|
Before Width: | Height: | Size: 20 KiB After Width: | Height: | Size: 20 KiB |
|
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 56 KiB |
|
Before Width: | Height: | Size: 48 KiB After Width: | Height: | Size: 48 KiB |
|
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 37 KiB |
|
|
@ -1,66 +0,0 @@
|
||||||
Surviving with Android 4.4 (KitKat) or 5.x (Lollipop) using latest BRouter
|
|
||||||
=======================================================
|
|
||||||
|
|
||||||
BRouter has some basic support to reclaim your external SD card.
|
|
||||||
|
|
||||||
Brouter must be installed on internal drive ("SD card"), but maps could be moved to external SD card.
|
|
||||||
|
|
||||||
What's new is a configuration file located at:
|
|
||||||
|
|
||||||
brouter/segments4/storageconfig.txt
|
|
||||||
|
|
||||||
which has 2 configuration items:
|
|
||||||
|
|
||||||
"secondary_segment_dir" points to an additional directory containing
|
|
||||||
routing data files. This can be located anywhere.
|
|
||||||
|
|
||||||
"additional_maptool_dir" points to a base-directory that should
|
|
||||||
be scanned for maptool-installations in addition to the standard-guesses.
|
|
||||||
|
|
||||||
Initially, the value for "secondary_segment_dir" is "../segments3" to support the
|
|
||||||
file-format transition from 1.2 to 1.3, so that, after upgrading, your existing
|
|
||||||
datafiles are found via the secondary directory.
|
|
||||||
|
|
||||||
However, for surviving KitKatn and later, you are supposed to change that to the
|
|
||||||
absolute path to a directory on the external card, e.g.:
|
|
||||||
|
|
||||||
secondary_segment_dir=/storage/external_SD/brouter_segments4
|
|
||||||
|
|
||||||
When searching for datafiles, both the download manager and the router first look in the primary (brouter/segments4) and then in the secondary directory.
|
|
||||||
On the other hand, the download manager always writes new datafiles to the primary directory, so the secondary directory is read-only.
|
|
||||||
|
|
||||||
So you can move datafiles downloaded by the download-manager to the secondary directory, by using a file manager, in order to free disk space on the internal card. Or you ca download datafiles directly to the secondary directory by doing manual http downloads
|
|
||||||
from http://brouter.de/brouter/segments4
|
|
||||||
|
|
||||||
Depending on how your maptool handles the file-system structure, you are done.
|
|
||||||
|
|
||||||
However, e.g. for OsmAnd it is likely that BRouter still has no access to OsmAnd's waypoint database. The reason is:
|
|
||||||
|
|
||||||
When, after installing OsmAnd, you choose to move it's resources to the external SD Card,
|
|
||||||
it moves it to a special directory where it has write-access even with Android 4.4, e.g.:
|
|
||||||
|
|
||||||
/storage/external_SD/Android/data/net.osmand/files
|
|
||||||
|
|
||||||
The package name slightly differs for OsmAnd+.
|
|
||||||
|
|
||||||
This directory is not found automatically by BRouter, so you have to configure
|
|
||||||
it as "additional_maptool_dir".
|
|
||||||
|
|
||||||
However, you are still not done, because if BRouter finds a wayoint-database file
|
|
||||||
under:
|
|
||||||
|
|
||||||
/storage/external_SD/Android/data/net.osmand/files/osmand/favourites.gpx
|
|
||||||
|
|
||||||
then it decides to write it's tracks to:
|
|
||||||
|
|
||||||
/storage/external_SD/Android/data/net.osmand/files/osmand/tracks
|
|
||||||
|
|
||||||
But this directory is not writable by BRouter. So what you have to do is to create
|
|
||||||
a redirection-file (create the tracks folder if it does not exist!)
|
|
||||||
|
|
||||||
/storage/external_SD/Android/data/net.osmand/files/osmand/tracks/brouter.redirect
|
|
||||||
|
|
||||||
and that should contain a single line with the absolute path to the folder where
|
|
||||||
the tracks should be written (e.g. /mnt/sdcard/brouter ). Redirection file is normal file named brouter.redirect and containing single line pointing to folder writable by BRouter and readable by OsmAnd.
|
|
||||||
|
|
||||||
THEN you are done.
|
|
||||||
|
|
@ -1,411 +0,0 @@
|
||||||
Profile developers guide - Technical reference
|
|
||||||
for BRouter profile scripts
|
|
||||||
==============================================
|
|
||||||
|
|
||||||
The tag-value lookup table
|
|
||||||
--------------------------
|
|
||||||
|
|
||||||
Within the routing data files (rd5), tag information
|
|
||||||
is encoded in a binary bitstream for the way tags and
|
|
||||||
the node tags each.
|
|
||||||
|
|
||||||
To encode and decode to/from this bitstream, a lookup
|
|
||||||
table is used that contains all the tags and values
|
|
||||||
that are considered for encoding.
|
|
||||||
|
|
||||||
For each tag there are 2 special values:
|
|
||||||
|
|
||||||
- <empty> if the tag is not set or the value is empty
|
|
||||||
- "unknown" if the value is not contained in the table
|
|
||||||
|
|
||||||
Each value can have optional "aliases", these alias
|
|
||||||
values are encoded into the same binary value as the
|
|
||||||
associated primary value.
|
|
||||||
|
|
||||||
A profile must use the primary value in expressions, as
|
|
||||||
aliases trigger a parse error. E.g. if there is a line
|
|
||||||
in lookups.dat file:
|
|
||||||
|
|
||||||
bicycle;0001245560 yes allowed
|
|
||||||
|
|
||||||
then a profile must use "bicycle=yes", as "bicycle=allowed"
|
|
||||||
gives an error.
|
|
||||||
|
|
||||||
The numbers in the lookup table are statistical
|
|
||||||
information on the frequency of the values in the
|
|
||||||
map of Germany - these are just informational and
|
|
||||||
are not processed by BRouter.
|
|
||||||
|
|
||||||
|
|
||||||
Context-Separation
|
|
||||||
------------------
|
|
||||||
|
|
||||||
Way-tags and Node-Tags are treated independently,
|
|
||||||
so there are different sections in the lookup table
|
|
||||||
as well as in the profile scripts for each context.
|
|
||||||
The special tags: "---context:way" and "---context:node"
|
|
||||||
mark the beginning of each section.
|
|
||||||
|
|
||||||
An exception from context separation is the node-context,
|
|
||||||
where variables from the way-context of the originating
|
|
||||||
way can be accessed using the "way:" prefix. For the
|
|
||||||
variable nodeaccessgranted there's an additional
|
|
||||||
legacy-hack to access it as a lookup value without prefix:
|
|
||||||
|
|
||||||
if nodeaccessgranted=yes then ...
|
|
||||||
|
|
||||||
while in the general case the prefixed expressions are variables:
|
|
||||||
|
|
||||||
if greater way:costfactor 5 then ...
|
|
||||||
|
|
||||||
In the profile scripts there is a third context "global"
|
|
||||||
which contains global configuration which is shared for
|
|
||||||
all contexts and is accessible by the routing engine.
|
|
||||||
|
|
||||||
The variables from the "global" section in the profile
|
|
||||||
scripts are read-only visible in the "way" and
|
|
||||||
"node" sections of the scripts.
|
|
||||||
|
|
||||||
|
|
||||||
Predefined variables in the profile scripts
|
|
||||||
-------------------------------------------
|
|
||||||
|
|
||||||
Some variable names are pre-defined and accessed by
|
|
||||||
the routing engine:
|
|
||||||
|
|
||||||
- for the global section these are:
|
|
||||||
|
|
||||||
- 7 elevation configuration parameters:
|
|
||||||
|
|
||||||
- downhillcost
|
|
||||||
- downhillcutoff
|
|
||||||
- uphillcost
|
|
||||||
- uphillcutoff
|
|
||||||
- elevationpenaltybuffer
|
|
||||||
- elevationmaxbuffer
|
|
||||||
- elevationbufferreduce
|
|
||||||
|
|
||||||
- 3 boolean mode-hint flags
|
|
||||||
|
|
||||||
- validForBikes
|
|
||||||
- validForFoot
|
|
||||||
- validForCars
|
|
||||||
|
|
||||||
- 2 variables to change the heuristic
|
|
||||||
coefficients for the 2 routing passes
|
|
||||||
( <0 disables a routing pass )
|
|
||||||
|
|
||||||
- pass1coefficient
|
|
||||||
- pass2coefficient
|
|
||||||
|
|
||||||
- 3 variables to influence the generation of turn-instructions
|
|
||||||
|
|
||||||
- turnInstructionMode 0=none, 1=auto-choose, 2=locus-style, 3=osmand-style
|
|
||||||
- turnInstructionCatchingRange default 40m
|
|
||||||
- turnInstructionRoundabouts default=true=generate explicit roundabout hints
|
|
||||||
|
|
||||||
- variables to modify BRouter behaviour
|
|
||||||
|
|
||||||
- processUnusedTags ( default is false )
|
|
||||||
If an OSM tag is unused within the profile,
|
|
||||||
BRouter totally ignores the tag existence.
|
|
||||||
Skipping unused tags improves BRouter speed.
|
|
||||||
As a side effect, the tag is not even listed
|
|
||||||
in the route segment table nor the table exported as CSV.
|
|
||||||
Setting it to true/1, Brouter-web Data page will list
|
|
||||||
all tags present in the RD5 file.
|
|
||||||
|
|
||||||
- for the way section these are
|
|
||||||
|
|
||||||
- turncost
|
|
||||||
- initialcost
|
|
||||||
- costfactor
|
|
||||||
- uphillcostfactor
|
|
||||||
- downhillcostfactor
|
|
||||||
- nodeaccessgranted
|
|
||||||
- initialclassifier
|
|
||||||
- priorityclassifier
|
|
||||||
|
|
||||||
- for the node section this is just
|
|
||||||
|
|
||||||
- initialcost
|
|
||||||
|
|
||||||
|
|
||||||
The operators of the profile scripts
|
|
||||||
------------------------------------
|
|
||||||
|
|
||||||
The profile scripts use polish notation (operator first).
|
|
||||||
|
|
||||||
The "assign" operator is special: it can be used
|
|
||||||
only on the top level of the expression hierarchy
|
|
||||||
and has 2 operands:
|
|
||||||
|
|
||||||
assign <variable-name> <expression>
|
|
||||||
|
|
||||||
It just assigns the expression value to this
|
|
||||||
variable (which can be a predefined variable or
|
|
||||||
any other variable, which in this case is defined
|
|
||||||
implicitly). The expression can be a complex expression
|
|
||||||
using other operators.
|
|
||||||
|
|
||||||
All other operators can be used recursively to an unlimited
|
|
||||||
complexity, which means that each operand can be a composed
|
|
||||||
expression starting with an operator and so on.
|
|
||||||
|
|
||||||
All expressions have one of the following basic forms:
|
|
||||||
|
|
||||||
- <numeric value>
|
|
||||||
- <numeric variable>
|
|
||||||
- <lookup-match>
|
|
||||||
- <1-op-operator> <operand>
|
|
||||||
- <2-op-operator> <operand> <operand>
|
|
||||||
- <3-op-operator> <operand> <operand> <operand>
|
|
||||||
|
|
||||||
- A numeric value is just a number, floating point, with "." as
|
|
||||||
decimal separator. Boolean values are treated as numbers as well,
|
|
||||||
with "0" = false and every nonzero value = true.
|
|
||||||
|
|
||||||
- A lookup match has the form <tag-name>=<value>, e.g. highway=primary
|
|
||||||
Only the primary values can be used in lookup-matches, not aliases.
|
|
||||||
The <empty> value is referred to as an empty string, e.g. access=
|
|
||||||
|
|
||||||
- 1 Operand operators are:
|
|
||||||
|
|
||||||
not <boolean expression>
|
|
||||||
|
|
||||||
- 2 Operand operators are:
|
|
||||||
|
|
||||||
or <boolean expression 1> <boolean expression 2>
|
|
||||||
and <boolean expression 1> <boolean expression 2>
|
|
||||||
xor <boolean expression 1> <boolean expression 2>
|
|
||||||
multiply <numeric expression 1> <numeric expression 2>
|
|
||||||
add <numeric expression 1> <numeric expression 2>
|
|
||||||
sub <numeric expression 1> <numeric expression 2>
|
|
||||||
max <numeric expression 1> <numeric expression 2>
|
|
||||||
min <numeric expression 1> <numeric expression 2>
|
|
||||||
equal <numeric expression 1> <numeric expression 2>
|
|
||||||
greater <numeric expression 1> <numeric expression 2>
|
|
||||||
lesser <numeric expression 1> <numeric expression 2>
|
|
||||||
|
|
||||||
- 3 Operand operators are:
|
|
||||||
|
|
||||||
switch <boolean-expression> <true-expression> <false-expression>
|
|
||||||
|
|
||||||
So the switch expression has a numeric value which is the
|
|
||||||
true-expression if the boolean expression is true, the
|
|
||||||
false-expression otherwise.
|
|
||||||
|
|
||||||
|
|
||||||
Syntactic Sugar
|
|
||||||
---------------
|
|
||||||
|
|
||||||
To improve the readablity of the profile scripts, some syntactic variations
|
|
||||||
are possible:
|
|
||||||
|
|
||||||
- "if then else" : "if" can be used instead of the "switch" operator, if the
|
|
||||||
additional keywords "then" and "else" are placed between the operators:
|
|
||||||
|
|
||||||
if <boolean-expression> then <true-expression> else <false-expression>
|
|
||||||
|
|
||||||
- Parentheses: each expression can be surrounded by parentheses: ( <expression> )
|
|
||||||
Please note that the profile syntax, due to the polish notation, does not
|
|
||||||
need parentheses, they are always optional. However, if there are parentheses,
|
|
||||||
the parser checks if they really match the expression boundaries.
|
|
||||||
|
|
||||||
- or-ing lookup-matches: the pipe-symbol can be used as a short syntax for
|
|
||||||
lookup matches where more than one value is accepted for a key:
|
|
||||||
highway=primary|secondary|tertiary
|
|
||||||
|
|
||||||
- additional "=" symbol for "assign" operations:
|
|
||||||
assign <variable-name> = <expression>
|
|
||||||
|
|
||||||
- boolean constants: "true" and "false" can be used instead of 1 and 0
|
|
||||||
|
|
||||||
Please note that the tokenizer always expects blank space to separate
|
|
||||||
symbols and expressions so it is not allowed to place parentheses or
|
|
||||||
the "=" symbol without separating blank space!
|
|
||||||
|
|
||||||
|
|
||||||
The initial cost classifier
|
|
||||||
---------------------------
|
|
||||||
|
|
||||||
To trigger the addition of the "initialcost", another variable is used:
|
|
||||||
"initialclassifier" - any change in the value of that variable leads
|
|
||||||
to adding the value of "initialcost".
|
|
||||||
|
|
||||||
Initial cost is used typically for a ferry, where you want to apply
|
|
||||||
a penalty independent of the length of the ferry line.
|
|
||||||
|
|
||||||
Another useful case may be an initial cost for bicycle mounting/dismounting,
|
|
||||||
having set an initialclassifier for ways without bicycle access, with high initialcost.
|
|
||||||
For backward compatibility, if "initialclassifier" = 0, it is replaced
|
|
||||||
by the costfactor.
|
|
||||||
|
|
||||||
|
|
||||||
The priority classifier
|
|
||||||
-----------------------
|
|
||||||
|
|
||||||
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,
|
|
||||||
as far as it can be predicted from OSM data.
|
|
||||||
|
|
||||||
To avoid a navigation instruction flood, it was decided
|
|
||||||
that the instructions are provided only if:
|
|
||||||
|
|
||||||
1/ You are supposed to turn at a crossroad/junction
|
|
||||||
and some other ways having the same or higher Priorityclassifier value.
|
|
||||||
OR
|
|
||||||
2/ You are supposed to go straight ahead
|
|
||||||
and some other ways having the higher Priorityclassifier value.
|
|
||||||
|
|
||||||
|
|
||||||
The elevation buffer ( From Poutnik's glossary )
|
|
||||||
------------------------------------------------
|
|
||||||
|
|
||||||
With related 3 internal BRouter variables:
|
|
||||||
- elevationpenaltybuffer
|
|
||||||
- elevationmaxbuffer
|
|
||||||
- elevationbufferreduce
|
|
||||||
|
|
||||||
the 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 percentage of
|
|
||||||
how much is WayLength[km] * elevationbufferreduce*10 is saturated
|
|
||||||
by the buffer content above elevationpenaltybuffer.
|
|
||||||
|
|
||||||
elevationmaxbuffer - default 10(m) - is the size of the buffer, above which
|
|
||||||
all elevation is converted to Elevationcost by Up/Downhillcost ratio,
|
|
||||||
and - if defined - Up/downhillcostfactor fully replaces Costfactor
|
|
||||||
in way cost calculation.
|
|
||||||
|
|
||||||
elevationbufferreduce - default 0(slope%)- is rate of conversion of the buffer content
|
|
||||||
above elevationpenaltybuffer to ElevationCost. For a way of length L,
|
|
||||||
the amount of converted elevation is L[km] * elevationbufferreduce[%] * 10.
|
|
||||||
The elevation to Elevationcost conversion ratio is given by Up/downhillcost.
|
|
||||||
|
|
||||||
Example:
|
|
||||||
Let's 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.5m 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 5m 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.
|
|
||||||
|
|
||||||
|
|
||||||
Technical constraints
|
|
||||||
---------------------
|
|
||||||
|
|
||||||
- The costfactor is required to be >= 1, otherwise the cost-cutoff
|
|
||||||
logic of the routing algorithm does not work and you get wrong results.
|
|
||||||
|
|
||||||
- The profile should be able to find a route with an average costfactor
|
|
||||||
not very much larger than one, because otherwise the routing algorithm
|
|
||||||
will not find a reasonable cost-cutoff, leading to a very large
|
|
||||||
search area and thus to long processing times.
|
|
||||||
|
|
||||||
- Forbidden ways or nodes must be treated as very high cost, because
|
|
||||||
there is no "forbidden" value. Technically, values >= 10000 for a
|
|
||||||
(way-)costfactor, and >= 1000000 for a nodes "initalcost" are treated
|
|
||||||
as infinity, so please use these as the "forbidden" values.
|
|
||||||
|
|
||||||
- Ways with costfactor >= 10000 are considered as if they did not exist at all.
|
|
||||||
|
|
||||||
- Ways with costfactor = 9999 are considered as
|
|
||||||
if they did not exist during route calculation,
|
|
||||||
but the navigation hint generator takes them into account.
|
|
||||||
|
|
||||||
|
|
||||||
Developing and debugging scripts
|
|
||||||
--------------------------------
|
|
||||||
|
|
||||||
For developing scripts, the "brouter-web" web-application is your
|
|
||||||
friend. You can use that either online at https://brouter.de/brouter-web
|
|
||||||
or set up a local installation.
|
|
||||||
|
|
||||||
BRouter-Web has a window at the lower left corner with a "Profile"
|
|
||||||
and a "Data" tab. Here, you can upload profile scripts and see
|
|
||||||
the individual cost calculations per way-section in the "Data"-tab.
|
|
||||||
|
|
||||||
For profile debugging activate "assign processUnusedTags = true"
|
|
||||||
to see all present OSM tags on the Data tab, not just those used in the tested profile.
|
|
||||||
|
|
||||||
|
|
||||||
Lookup-Table evolution and the the "major" and "minor" versions
|
|
||||||
---------------------------------------------------------------
|
|
||||||
|
|
||||||
The lookup-table is allowed to grow over time, to include more tags
|
|
||||||
and values as needed. To support that evolution, it carries a major
|
|
||||||
and a minor version number. These numbers are also encoded into
|
|
||||||
the routing data files, taken from the lookups.dat that is used
|
|
||||||
to pre-process the routing data files.
|
|
||||||
|
|
||||||
A major version change is considered to always break compatibility
|
|
||||||
between the routing datafiles and the lookup table.
|
|
||||||
|
|
||||||
A minor version change keeps the routing data files and the lookup-table
|
|
||||||
compatible in both directions, using the following rules:
|
|
||||||
|
|
||||||
- if the data contains a key that is not contained in the lookup
|
|
||||||
tables, it is ignored
|
|
||||||
|
|
||||||
- if the data contains a value that is not contained in the lookup
|
|
||||||
tables (but its key is known) that value is treated as "unknown"
|
|
||||||
|
|
||||||
- if a profile uses a key that is not present in the data,
|
|
||||||
it sees empty (=unset) values for that key
|
|
||||||
|
|
||||||
- if a profile uses a value that is not present in the data,
|
|
||||||
lookup matches for that value are always false.
|
|
||||||
|
|
||||||
For a minor version change it is required that tags are only
|
|
||||||
appended at the end of the table (or replace one of the dummy
|
|
||||||
tags located between the way-tags and the relation pseudo-tags),
|
|
||||||
and that values are only appended at the end of the value lists.
|
|
||||||
This is because the routing data files address tags and values
|
|
||||||
by their sequence numbers, so changing sequences would produce
|
|
||||||
garbage data.
|
|
||||||
|
|
||||||
|
|
||||||
Other resources
|
|
||||||
---------------
|
|
||||||
|
|
||||||
See https://github.com/poutnikl/Brouter-profiles/wiki/Glossary
|
|
||||||
as a complementary source about various profile internals.
|
|
||||||
|
|
||||||
|
|
@ -1,262 +0,0 @@
|
||||||
BRouter - Version 1.4 - Setting up the Android App
|
|
||||||
====================================================
|
|
||||||
|
|
||||||
Choosing and Installing a Map-Tool
|
|
||||||
----------------------------------
|
|
||||||
|
|
||||||
BRouter just calculates tracks as GPX-Files, it
|
|
||||||
does not display any map or give any navigation
|
|
||||||
instuctions. Therefore you need a map-tool in
|
|
||||||
order for BRouter to be useful.
|
|
||||||
|
|
||||||
Currently, BRouter cooperates with three different
|
|
||||||
maptools, so you need to install, and get familiar with,
|
|
||||||
at least one of them:
|
|
||||||
|
|
||||||
- "OsmAnd": See http://www.osmand.net Get It from Google-Play
|
|
||||||
or get it as an APK from the release-build archive:
|
|
||||||
http://download.osmand.net/releases/
|
|
||||||
|
|
||||||
- "Locus": See http://www.locusmap.eu There's a "Pro"
|
|
||||||
Version which is ad-free and a free version with ads.
|
|
||||||
You can get it from Google-Play, but for the free-version
|
|
||||||
there's also an APK-Download.
|
|
||||||
|
|
||||||
- "Oruxmaps": See http://www.oruxmaps.com Oruxmaps is
|
|
||||||
Donation-Ware, which means it's free and you're supposed
|
|
||||||
to donate to the project if you want to support it.
|
|
||||||
|
|
||||||
Which one to use is a matter of taste. Maybe OsmAnd is
|
|
||||||
more plug&play and has a reasonable voice-guidig. Locus
|
|
||||||
and Oruxmaps are more powerful and better for outdoor
|
|
||||||
use. All three have elevation profile diagrams.
|
|
||||||
|
|
||||||
Locus and Oruxmaps are best used with third-party vector
|
|
||||||
maps, check http://www.openandromaps.org if you consider
|
|
||||||
to go for Locus or OruxMaps.
|
|
||||||
|
|
||||||
Installing the BRouter App
|
|
||||||
--------------------------
|
|
||||||
|
|
||||||
You can install the BRouter-App either from Google's Play Store
|
|
||||||
or directly from the APK-File contained within the "brouter_1_4.zip"
|
|
||||||
distribution zip-file.
|
|
||||||
|
|
||||||
Choosing a SD-Card Base Directory
|
|
||||||
---------------------------------
|
|
||||||
|
|
||||||
When first starting BRouter (or after deleting/moving
|
|
||||||
the brouter folder on the sd-card), it asks for a
|
|
||||||
sd-card base directory and gives you proposals plus
|
|
||||||
the option to enter any other base directory.
|
|
||||||
|
|
||||||
Most phones (namely those with Android 4.x) have 2 logical
|
|
||||||
"SD-Cards", where the first one is internal and not an actual
|
|
||||||
Card, and the second one is a an optional "external" micro-sd-card
|
|
||||||
that can be taken out of the device.
|
|
||||||
|
|
||||||
Navigation needs big data files that usually should go on an
|
|
||||||
external, big sd-card. You should accept the external card, which
|
|
||||||
is usually the one with the most space available.
|
|
||||||
|
|
||||||
However, on Android >= 4.4, write access to the external card
|
|
||||||
is restricted, and usually you will not get a proposal to use
|
|
||||||
the external card. Here you should accept to go with the
|
|
||||||
internal card - later on you can setup a "secondary" data
|
|
||||||
directory on the external card where you can move the datafiles
|
|
||||||
to.
|
|
||||||
|
|
||||||
*** see the kitkat_survival_readme.txt for special Android 4.4 and Android 5x issues ***
|
|
||||||
|
|
||||||
Try to make sure your map-tool uses the same base directory
|
|
||||||
to store the offline maps and other stuff, because BRouter
|
|
||||||
tries to access the maptool's waypoint-database and tracks-directory,
|
|
||||||
and this works only if they use either the same base directory
|
|
||||||
or if the maptool uses the standard, internal base /mnt/sdcard.
|
|
||||||
|
|
||||||
In OsmAnd, this works by choosing an "SD-Card base directory".
|
|
||||||
|
|
||||||
In OruxMaps, path configuration is only possible for the actual
|
|
||||||
map data, but the configuration database file that BRouter tries
|
|
||||||
to access is hardwired to the /mnt/sdcard/oruxmaps directory.
|
|
||||||
As a workaround for this specific setup, you can place a
|
|
||||||
redirection file in the directory where BRouter would normally
|
|
||||||
place the gpx-files (e.g. /mnt/sdcard/oruxmaps/tracklogs).
|
|
||||||
The first line of that redirection file called "brouter.redirect"
|
|
||||||
must contain the absolute path of the directory where you want
|
|
||||||
the gpx-files to go (e.g. /storage0/oruxmaps/tracklogs).
|
|
||||||
|
|
||||||
If you have a non-standard maptool location, that is not
|
|
||||||
detected by the default logic, you can configure an "additional maptool directory"
|
|
||||||
in a configuration file located unter brouter/segments3/storageconfig.txt
|
|
||||||
This is neccessary e.g. if you operate OsmAnd on the external SD card
|
|
||||||
under Android 4.4. Then this uses a special base directory to obey
|
|
||||||
Android 4.4's access restrictions, and this base directory is not found
|
|
||||||
by the default logic. See the kitkat_survival_readme.txt for details.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Completing your installation
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
After accepting a base-directory proposal, "BRouter" creates a subfolders
|
|
||||||
relative to this base directory, so you end up with e.g. the following structure:
|
|
||||||
(depending on base dir and your map-tool choice):
|
|
||||||
|
|
||||||
/mnt/sdcard/brouter
|
|
||||||
/mnt/sdcard/brouter/segments4 <- ** put routing data files (*.rd5) here **
|
|
||||||
/mnt/sdcard/brouter/profiles2 <- lookup-table and routing profiles
|
|
||||||
/mnt/sdcard/brouter/modes <- routing-mode/profile mapping
|
|
||||||
|
|
||||||
/mnt/sdcard/osmand <- OsmAnd's sd-card dir
|
|
||||||
/mnt/sdcard/osmand/track <- OsmAnd's track storage
|
|
||||||
|
|
||||||
/mnt/sdcard/Locus <- Locus's sd-card dir
|
|
||||||
/mnt/sdcard/Locus/mapitems <- Locus's track storage
|
|
||||||
|
|
||||||
/mnt/sdcard/oruxmaps <- Oruxmaps's sd-card dir
|
|
||||||
/mnt/sdcard/oruxmaps/tracklogs <- Oruxmaps's track storage
|
|
||||||
|
|
||||||
|
|
||||||
The "profiles2" and the "modes" directory get some reasonable default-configuration
|
|
||||||
from the installation procedure, but the "segments4" directory is basically empty
|
|
||||||
(except for the storageconfig.txt file) so you have to get routing-datafiles in
|
|
||||||
order to complete your installation.
|
|
||||||
|
|
||||||
After accepting the base directory, the download manager starts automatically to
|
|
||||||
help you with this download. Or you can download
|
|
||||||
them manually from the following location:
|
|
||||||
|
|
||||||
http://brouter.de/brouter/segments4
|
|
||||||
|
|
||||||
Routing data files are organised as 5*5 degree files,
|
|
||||||
with the Filename containing the south-west corner
|
|
||||||
of the square, which means:
|
|
||||||
|
|
||||||
- You want to route near West48/North37 -> get W50_N35.rd5
|
|
||||||
- You want to route near East7/North47 -> get E5_N45.rd5
|
|
||||||
|
|
||||||
From the above link you find routing data for all places in the world where OSM
|
|
||||||
data is available. The carsubset datafiles are needed only if you want to
|
|
||||||
calculate car-routes over long distances, otherwise you are fine with just the
|
|
||||||
normal (full) rd5's.
|
|
||||||
|
|
||||||
The minimum files BRouter needs to work are e.g.
|
|
||||||
|
|
||||||
/mnt/sdcard/brouter/segments4/E5_N45.rd5
|
|
||||||
/mnt/sdcard/brouter/profiles2/lookups.dat
|
|
||||||
/mnt/sdcard/brouter/profiles2/trekking.brf
|
|
||||||
|
|
||||||
But of course you can put as many routing data files
|
|
||||||
and routing profiles as you like.
|
|
||||||
|
|
||||||
|
|
||||||
Routing via the service interface
|
|
||||||
=================================
|
|
||||||
|
|
||||||
BRouter is best used via it's "service interface". No need to start the BRouter-App
|
|
||||||
in order to do that, it's just a services that sits in the background and can be
|
|
||||||
called by the map-tools very much like on online routing service.
|
|
||||||
|
|
||||||
To do that, you have to choose BRouter as a navigation service in your map-tool.
|
|
||||||
This is supported by OsmAnd, Locus-Maps and OruxMaps (In OsmAnd starting with version 1.7,
|
|
||||||
you see BRouter as a navigation service if BRouter is installed. You do not see the
|
|
||||||
option if BRouter is not installed).
|
|
||||||
|
|
||||||
There's a mapping between the "routing-mode" asked for by the map-tool
|
|
||||||
(on out of 6: car/bike/foot * fast/slow) and BRouter's routing-profiles.
|
|
||||||
This mapping is stored in the file brouter/modes/serviceconfig.dat and is
|
|
||||||
pre-configured by the installation process to the following mapping:
|
|
||||||
|
|
||||||
motorcar_fast -> car-test
|
|
||||||
motorcar_short -> moped
|
|
||||||
bicycle_fast -> fastbike
|
|
||||||
bicycle_short -> trekking
|
|
||||||
foot_fast -> shortest
|
|
||||||
foot_short -> shortest
|
|
||||||
|
|
||||||
This mapping, however, can be changed any time by starting the BRouter-APP and using
|
|
||||||
the "Server Mode" button (or by editing the serviceconfig.dat manually). You can also
|
|
||||||
change gthe profiles themselves or create new ones. Please refer to the
|
|
||||||
"profile_developers_guide.txt" (contained in the distribution-zip) if you plan to
|
|
||||||
adapt routing profiles to your preferences.
|
|
||||||
|
|
||||||
Note that if called via the service-interface, BRouter uses a timeout of 60 seconds,
|
|
||||||
which sets a limit on the distances you can calculate.
|
|
||||||
|
|
||||||
|
|
||||||
Calculate routes using the file interface
|
|
||||||
=========================================
|
|
||||||
|
|
||||||
The other option is using the BRouter-App to calculate a route. This is the prefered option
|
|
||||||
when calculating long-distance-routes that would not finish within the 60 seconds timout
|
|
||||||
if calculated via the service-interface.
|
|
||||||
|
|
||||||
To do this, start the BRouter-App, select two or more waypoints from the waypoint-database
|
|
||||||
of your map-tool and then start the route calculation. These waypoints are called "Favorites"
|
|
||||||
in OsmAnd, "POI"s in Locus or "Waypoints" in Oruxmaps and allow to store a location
|
|
||||||
on the map and give it a name.
|
|
||||||
|
|
||||||
No need anymore to create special "to", "from", "via1..via9" points, but they are still supported
|
|
||||||
and if a "from" and a "to" wayppoint is found in the database, you will not be prompted
|
|
||||||
to select waypoints from the database.
|
|
||||||
|
|
||||||
If a route is calculated, it is stored as "brouter0.gpx" in the map-tools track directory
|
|
||||||
(or, if there is no write-access, in brouter's base directory)
|
|
||||||
If started once more with identical input, BRouter will store a second route broute1.gpx
|
|
||||||
for the first alternative and so on.
|
|
||||||
|
|
||||||
If more than one of the supported maptools is installed, BRouter chooses the way-point database
|
|
||||||
with the most recent timestamp.
|
|
||||||
|
|
||||||
|
|
||||||
Using nogo-areas
|
|
||||||
================
|
|
||||||
|
|
||||||
There's a special naming-convention to specify nogo-areas:
|
|
||||||
|
|
||||||
"nogo[radius] [name]" defines a nogo-area, where radius (in Meter)
|
|
||||||
is optional and defaults to 20m, and the name is also optional.
|
|
||||||
So "nogo", "nogo1000", "nogo roadblock", "nogo200 badferry" are all valid
|
|
||||||
names for nogo-waypoints.
|
|
||||||
|
|
||||||
The effect is that BRouter searches a route that does not touch the disc
|
|
||||||
defined by the position and the radius of the nogo-area.
|
|
||||||
|
|
||||||
Nogo-Areas are effective in the service-interface and in the BRouter-App.
|
|
||||||
In the BRouter-App, you will get a nogo-dialog allowing to de-select them
|
|
||||||
if nogo-waypoints are found in the waypoint-database. This de-selection
|
|
||||||
can also be bound to a service mode using the "Server Mode" button to make
|
|
||||||
it effective in the service-interface as well, but initially, every nogo-area
|
|
||||||
is effective in the service-interface.
|
|
||||||
|
|
||||||
Nogo areas can be used either to account for real obstacles or to enforce
|
|
||||||
personal routing preferences.
|
|
||||||
|
|
||||||
|
|
||||||
Mixed operation: "timeout-free recalculations"
|
|
||||||
==============================================
|
|
||||||
|
|
||||||
You can combine both operation modes (service-interface + BRouter-App) to
|
|
||||||
become able to calculate very long distances, but make use of the advantages of
|
|
||||||
the service interface as well, especially the dynamic recalculations if you get
|
|
||||||
off the track, without running into the 60 seconds timeout.
|
|
||||||
|
|
||||||
To support this, BRouter can do "timeout free recalculations". It works by
|
|
||||||
initially calculating a track to your destination and binding it to one or
|
|
||||||
more routing-modes using the "Server Mode" button. This way, BRouter stores
|
|
||||||
a "reference track" in the "brouter/modes" subdirectory.
|
|
||||||
|
|
||||||
If afterwards a route to the exact same destination is calculated via the service interface,
|
|
||||||
BRouter uses a special calculation mode that makes use of the reference track for
|
|
||||||
faster processing that is guaranteed to give a result within 60 seconds.
|
|
||||||
"Exact same" destination means withing 5m, so best use the same waypoint for
|
|
||||||
re-calculating that you used for the initial calculation.
|
|
||||||
|
|
||||||
This way you can follow a long distance route via the service interface, enjoying
|
|
||||||
automatic recalculations if you get off the track.
|
|
||||||
|
|
||||||
|
|
||||||
Issues and bugs:
|
|
||||||
================
|
|
||||||
<https://github.com/abrensch/brouter/issues>
|
|
||||||
|
|
@ -1,221 +0,0 @@
|
||||||
BRouter - Version 1.6.2 - Setting up the Android App
|
|
||||||
====================================================
|
|
||||||
|
|
||||||
Choosing and Installing a Map-Tool
|
|
||||||
----------------------------------
|
|
||||||
|
|
||||||
|
|
||||||
BRouter just calculates tracks as GPX- or Geojson-output, it
|
|
||||||
does not display any map or give any navigation
|
|
||||||
instuctions. Therefore you need a map-tool in
|
|
||||||
order for BRouter to be useful.
|
|
||||||
|
|
||||||
Currently, BRouter cooperates with any map tool that can use the BRouter
|
|
||||||
interface without file access. So you need to install some, and get familiar with,
|
|
||||||
at least one of them:
|
|
||||||
|
|
||||||
- "OsmAnd": See http://www.osmand.net Get It from Google-Play
|
|
||||||
or get it as an APK from the release-build archive:
|
|
||||||
http://download.osmand.net/releases/
|
|
||||||
|
|
||||||
- "Locus": See http://www.locusmap.eu There's a "Pro"
|
|
||||||
Version which is ad-free and a free version with ads.
|
|
||||||
You can get it from Google-Play, but for the free-version
|
|
||||||
there's also an APK-Download.
|
|
||||||
|
|
||||||
- "Oruxmaps": See http://www.oruxmaps.com Oruxmaps is
|
|
||||||
Donation-Ware, which means it's free and you're supposed
|
|
||||||
to donate to the project if you want to support it.
|
|
||||||
|
|
||||||
|
|
||||||
Installing the BRouter App
|
|
||||||
--------------------------
|
|
||||||
|
|
||||||
You can install the BRouter-App either from Google's Play Store
|
|
||||||
or directly from the APK-File contained within the "brouter-1.6.2.zip"
|
|
||||||
distribution zip-file.
|
|
||||||
|
|
||||||
Choosing a SD-Card Base Directory
|
|
||||||
---------------------------------
|
|
||||||
|
|
||||||
When first starting BRouter (or after deleting/moving
|
|
||||||
the brouter folder on the sd-card), it asks for a
|
|
||||||
sd-card base directory and gives you proposals plus
|
|
||||||
the option to enter any other base directory.
|
|
||||||
|
|
||||||
Most phones (namely those with Android 4.x) have 2 logical
|
|
||||||
"SD-Cards", where the first one is internal and not an actual
|
|
||||||
Card, and the second one is a an optional "external" micro-sd-card
|
|
||||||
that can be taken out of the device.
|
|
||||||
|
|
||||||
Navigation needs big data files that usually should go on an
|
|
||||||
external, big sd-card. You should accept the external card, which
|
|
||||||
is usually the one with the most space available.
|
|
||||||
|
|
||||||
Since Android 11 BRouter app uses only its local storage on
|
|
||||||
.../Android/media/btools.routingapp/
|
|
||||||
|
|
||||||
That means it can't access the folders from other apps like OsmAnd, OruxMaps or Locus.
|
|
||||||
|
|
||||||
|
|
||||||
Completing your installation
|
|
||||||
----------------------------
|
|
||||||
|
|
||||||
After accepting a base-directory proposal, "BRouter" creates a subfolders
|
|
||||||
relative to this base directory, so you end up with e.g. the following structure:
|
|
||||||
(depending on base dir and your map-tool choice):
|
|
||||||
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/brouter
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/brouter/segments4 <- ** put routing data files (*.rd5) here **
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/brouter/profiles2 <- lookup-table and routing profiles
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/brouter/modes <- routing-mode/profile mapping
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/import <- allow a small file exchange with other apps
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/import/tracks <- place the nogo* files here
|
|
||||||
|
|
||||||
|
|
||||||
The "profiles2" and the "modes" directory get some reasonable default-configuration
|
|
||||||
from the installation procedure, but the "segments4" directory is basically empty
|
|
||||||
(except for the storageconfig.txt file) so you have to get routing-datafiles in
|
|
||||||
order to complete your installation.
|
|
||||||
|
|
||||||
After accepting the base directory, the download manager starts automatically to
|
|
||||||
help you with this download. Or you can download
|
|
||||||
them manually from the following location:
|
|
||||||
|
|
||||||
http://brouter.de/brouter/segments4
|
|
||||||
|
|
||||||
Routing data files are organised as 5*5 degree files,
|
|
||||||
with the Filename containing the south-west corner
|
|
||||||
of the square, which means:
|
|
||||||
|
|
||||||
- You want to route near West48/North37 -> get W50_N35.rd5
|
|
||||||
- You want to route near East7/North47 -> get E5_N45.rd5
|
|
||||||
|
|
||||||
From the above link you find routing data for all places in the world where OSM
|
|
||||||
data is available. The carsubset datafiles are needed only if you want to
|
|
||||||
calculate car-routes over long distances, otherwise you are fine with just the
|
|
||||||
normal (full) rd5's.
|
|
||||||
|
|
||||||
The minimum files BRouter needs to work are e.g.
|
|
||||||
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/brouter/segments4/E5_N45.rd5
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/brouter/profiles2/lookups.dat
|
|
||||||
/mnt/sdcard/Android/media/btools.routingapp/brouter/profiles2/trekking.brf
|
|
||||||
|
|
||||||
But of course you can put as many routing data files
|
|
||||||
and routing profiles as you like.
|
|
||||||
|
|
||||||
Since folders on other apps are not longer available you could use the
|
|
||||||
import folder to place a favourites.gpx with waypoints or
|
|
||||||
in subfolder 'tracks' your nogo*.gpx files.
|
|
||||||
|
|
||||||
|
|
||||||
Routing via the service interface
|
|
||||||
=================================
|
|
||||||
|
|
||||||
BRouter is best used via it's "service interface". No need to start the BRouter-App
|
|
||||||
in order to do that, it's just a services that sits in the background and can be
|
|
||||||
called by the map-tools very much like on online routing service.
|
|
||||||
|
|
||||||
To do that, you have to choose BRouter as a navigation service in your map-tool.
|
|
||||||
This is supported by OsmAnd, Locus-Maps and OruxMaps (In OsmAnd starting with version 1.7,
|
|
||||||
you see BRouter as a navigation service if BRouter is installed. You do not see the
|
|
||||||
option if BRouter is not installed).
|
|
||||||
|
|
||||||
There's a mapping between the "routing-mode" asked for by the map-tool
|
|
||||||
(on out of 6: car/bike/foot * fast/slow) and BRouter's routing-profiles.
|
|
||||||
This mapping is stored in the file brouter/modes/serviceconfig.dat and is
|
|
||||||
pre-configured by the installation process to the following mapping:
|
|
||||||
|
|
||||||
motorcar_fast -> car-test
|
|
||||||
motorcar_short -> moped
|
|
||||||
bicycle_fast -> fastbike
|
|
||||||
bicycle_short -> trekking
|
|
||||||
foot_fast -> shortest
|
|
||||||
foot_short -> shortest
|
|
||||||
|
|
||||||
This mapping, however, can be changed any time by starting the BRouter-APP and using
|
|
||||||
the "Server Mode" button (or by editing the serviceconfig.dat manually). You can also
|
|
||||||
change gthe profiles themselves or create new ones. Please refer to the
|
|
||||||
"profile_developers_guide.txt" (contained in the distribution-zip) if you plan to
|
|
||||||
adapt routing profiles to your preferences.
|
|
||||||
|
|
||||||
Note that if called via the service-interface, BRouter uses a timeout of 60 seconds,
|
|
||||||
which sets a limit on the distances you can calculate.
|
|
||||||
|
|
||||||
|
|
||||||
Calculate routes using the file interface
|
|
||||||
=========================================
|
|
||||||
|
|
||||||
The other option is using the BRouter-App to calculate a route. This is the prefered option
|
|
||||||
when calculating long-distance-routes that would not finish within the 60 seconds timout
|
|
||||||
if calculated via the service-interface.
|
|
||||||
|
|
||||||
To do this, start the BRouter-App, select two or more waypoints from the favorite waypoint-database
|
|
||||||
in your import folder and then start the route calculation. These waypoints are called "Favorites"
|
|
||||||
in OsmAnd, "POI"s in Locus or "Waypoints" in Oruxmaps and allow to store a location
|
|
||||||
on the map and give it a name. Export them from the app to the import folder.
|
|
||||||
|
|
||||||
No need anymore to create special "to", "from", "via1..via9" points, but they are still supported
|
|
||||||
and if a "from" and a "to" wayppoint is found in the database, you will not be prompted
|
|
||||||
to select waypoints from the database.
|
|
||||||
|
|
||||||
If a route is calculated, it is stored as "brouter0.gpx" in the BRouter import/tracks directory.
|
|
||||||
If started once more with identical input, BRouter will store a second route broute1.gpx
|
|
||||||
for the first alternative and so on.
|
|
||||||
|
|
||||||
|
|
||||||
Using nogo-areas
|
|
||||||
================
|
|
||||||
|
|
||||||
There's a special naming-convention to specify nogo-areas:
|
|
||||||
|
|
||||||
"nogo[radius] [name]" defines a nogo-area, where radius (in Meter)
|
|
||||||
is optional and defaults to 20m, and the name is also optional.
|
|
||||||
So "nogo", "nogo1000", "nogo roadblock", "nogo200 badferry" are all valid
|
|
||||||
names for nogo-waypoints.
|
|
||||||
|
|
||||||
The effect is that BRouter searches a route that does not touch the disc
|
|
||||||
defined by the position and the radius of the nogo-area.
|
|
||||||
|
|
||||||
Nogo-Areas are effective in the service-interface and in the BRouter-App.
|
|
||||||
In the BRouter-App, you will get a nogo-dialog allowing to de-select them
|
|
||||||
if nogo-waypoints are found in the waypoint-database. This de-selection
|
|
||||||
can also be bound to a service mode using the "Server Mode" button to make
|
|
||||||
it effective in the service-interface as well, but initially, every nogo-area
|
|
||||||
is effective in the service-interface.
|
|
||||||
|
|
||||||
Nogo areas can be used either to account for real obstacles or to enforce
|
|
||||||
personal routing preferences.
|
|
||||||
|
|
||||||
Please note that nogo values can transfer also by new interface
|
|
||||||
parameter: polylines, polygons
|
|
||||||
see 'IBRouterService.aidl' for more information.
|
|
||||||
|
|
||||||
|
|
||||||
Mixed operation: "timeout-free recalculations"
|
|
||||||
==============================================
|
|
||||||
|
|
||||||
You can combine both operation modes (service-interface + BRouter-App) to
|
|
||||||
become able to calculate very long distances, but make use of the advantages of
|
|
||||||
the service interface as well, especially the dynamic recalculations if you get
|
|
||||||
off the track, without running into the 60 seconds timeout.
|
|
||||||
|
|
||||||
To support this, BRouter can do "timeout free recalculations". It works by
|
|
||||||
initially calculating a track to your destination and binding it to one or
|
|
||||||
more routing-modes using the "Server Mode" button. This way, BRouter stores
|
|
||||||
a "reference track" in the "brouter/modes" subdirectory.
|
|
||||||
|
|
||||||
If afterwards a route to the exact same destination is calculated via the service interface,
|
|
||||||
BRouter uses a special calculation mode that makes use of the reference track for
|
|
||||||
faster processing that is guaranteed to give a result within 60 seconds.
|
|
||||||
"Exact same" destination means withing 5m, so best use the same waypoint for
|
|
||||||
re-calculating that you used for the initial calculation.
|
|
||||||
|
|
||||||
This way you can follow a long distance route via the service interface, enjoying
|
|
||||||
automatic recalculations if you get off the track.
|
|
||||||
|
|
||||||
|
|
||||||
Issues and bugs:
|
|
||||||
================
|
|
||||||
<https://github.com/abrensch/brouter/issues>
|
|
||||||
Loading…
Reference in a new issue