---
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.
