3 issues with distance calculation in BRouter:

• duplicate code ( 3 implemantions of public in calcDistance )
• significant distance mismatch compared to other tools evaluating the tracks (earth radius?)
• fails at lon = 180 degree

However, as distance calucation is called frequently within brouter, any cleanup also must obey the performance constraints

For both brouter.de/brouter-web and brouter-web-preview I get an net::ERR_CONNECTION_REFUSED with Chrome.

It seems like the last segment is missing from the result of OsmTrack.writeMessages.

Example: brouter-web, old demo CSV
Only one row returned, the track segment is missing in the CSV data.

Hi Arndt,

could you please update some references to segments4 with the following steps:

• update server.cmd, see #53
• update the standalone server scripts in your release zip template/preparation and check if the server.sh script then still has Unix line endings
• update brouter-web index.html (link in "about"), see nrenner/brouter-web@f49178d

In this example brouter issues a keep left instruction at lon="9.182407" lat="48.829950"

The road is almost straight and the crossing way is a footway. An instruction like this is unnecessary and should not be created to reduce noise/confusion.

Currently, profile parsing is done in the RoutingEngine constructor (?). Errors are thrown as RuntimeException (IllegalArgumentException) and are not reported back to the client (catch Throwable in RouteServer.run).

I would like to parse a custom profile for validation right on profile upload and send an error message (if any) with the response.

1. What would I need to do profile validation?
   Initialize a RoutingEngine? Are there any validations/checks afterwards?
   Can I call BExpressionContext.parse once or do I need to parse with different contexts as in RoutingEngine?
2. Some exception messages might not be suitable for the client, e.g. readMetaData includes an getAbsolutePath(). Should we distinguish client and server error messages and e.g. have a custom ParseException with line and path members and custom getMessage/getClientMessage methods?

Is it possible to add tag traffic_calming to supported tags for nodes?

Is it possible to add tag smoothness to supported tags for ways?

http://wiki.openstreetmap.org/wiki/Key:mtb:scale#mtb:scale:uphill.3D0-5
This will be useful to calculate uphillCostFactor

the trigger for adding initial costs to a way section is a change in costfactor. This is why ferry distance cost is 5.67, not 5, just to make it a unique identifier.

That concept should be made explicit by introducing a classifier separated from the costfactor, to describe e.g. any non-paved way, a ferry, or steps.

BRouter evaluates terms of logical expressions conditionally , as well as the branches of if/switch commands.

OTOH, if I got it correctly when we talked about it in past, user defined variables are always evaluated, even if they occur only in expression branches unused for current way/node.

If not addressed yet, would be possible to implement conditional evaluation of variables as well ? As they are very useful to keep simplicity of code, but may cause profile performance decrease.

What about switching the paradigm from the variable based imperative one to macro based declarative one ? Assign would not be taken as assignment executive command for a variable, but as a declaration of macro expression.

Variable=Macro would be evaluated only when called for its value the first time. Then it would get expanded to ( macro expression code ) and its value would be stored for the eventual reuse for multiple occurences.

In such case, user variables would be evaluated only if used, what can increase performance of profile processing.

Hi,
First of all great project!
When running the following request the response returns with only one value in coordinates:
http://h2096617.stratoserver.net:443/brouter?nogos=&alternativeidx=0&format=geojson&profile=trekking&lonlats=34.7094,30.5926|34.7107,30.5928
is it working as designed or a bug?

Thanks,
Harel M.

Hi Arndt,

there is a new config.js in brouter-web that chooses the appropriate configuration for online or desktop at load time. The idea is that no customization is needed after updating (assuming the config file is kept up-to-date in the repo).

Have you made any other changes beside URL and profile list for the online service?
Should the new all.brf and softaccess.brf be included? The softaccess.brf gives me "does not contain expressions for context node".

Norbert

Please, add "indoor" key to lookups.dat (and to data :)
https://wiki.openstreetmap.org/wiki/Key:indoor

Reason: ability to don't use "highway=footway indoor=yes" for bicycle routes.

Currently no cross-checking is done on the integrity of the rd5 data files, so it's difficult to answer support questions for problems that could possible be caused by corrupted downloads or broken sd-cards.

Therefore at least some checksum stuff is neccessary to distinguish real bugs from bad data. Unfortunatly, the rd5-data-file format is not well designed and does not offser much space for downward-compatibel enhancements, but there's one place where data can be added without breaking old versions of brouter:

When initializing the data for a micro-cache, extra data can be added to what's delivered by OsmFile.getDataInputForSubIdx without breaking the node's decoding. Here, a checksum for that micro-cache's data can be placed.

Forwarding these requests:

nrenner/brouter-web#14

It would be better to redirect it to some useful page

nrenner/brouter-web#7

[...] I guess the main domain URL should lead to something useful. =} The online demo and mobile download should be very visible there.

Questions about the age of the data files like nrenner/brouter-web#25 probably will arise frequently.

A suggestion would be to create a status.txt file similar to replication files that contains the timestamp from the header of the planet file used.

Using BRouter as a service in OsmAnd 1.9.5 gives me excellent directions, but no street names. Do you happen to know in which software that limitation occurs (BRouter or OsmAnd)? Using the default router in OsmAnd gives me street names while navigating.

There's frequent demand on having profile scripts with different preferences for uphill-, downhill- and flat sections. Part of that is driven by the problem of really steep sections that just can't be managed with a bike. This problem is adressed in 1.0.1 to a certain extend by including the "incline" tag in the lookup table.

But some people wish to select fast surfaces for going dowhill, but prefer forest-tracks for going uphill. There's not yet a solution for that.

Solution would be to expose a new variable for the incline estimated from the SRTM data. However, there are some conceptual problems here, partly due to SRTM-Noise, but also due to the fact that adding more context to the profile-scripts reduces the cache-hit rate for the hash-cache that reduces the number of profile-evaluations.

However, just adding a 3-state variable (down/flat/up) to the context should be o.k. in terms of the cache-hit-rate. The challange here is to define a filter to calculate a meaningful value for that variable.

I was asked to forward the U turn versus Left U-turn + Right U-turn issue ( action 12 vs 13+14 ), related to
confusing-u-turn-instruction thread at Locus Helpdesk.
Locus users and the author have the opinion you may want to implement Left/Right U-turn actions, eventually review the sharp turn versus U-turn evaluation.

My understanding is sharp turn = 135 +- 22.5 degress, U-turn is 157.5..180 degress.
Perhaps such a U-turn versus Turn Around are to be distinguished, if possible.

BRouter does not (yet) calculate travel times.

When used with OsmAnd, OsmAnds implicit "20km/h" for bikes is fine for me, but for car-routes, the implicit 60km/h is just a course guess and hust wrong for motorway trips.

Since BRouter's cost funtion is not based on speed, travel time calculations would require to create twins for the relevant terms in the routing profiles (costfactor, initialcost, turncost, ...) that deliver the estimated contribution to the travel time.

Simplest way to achieve that is to use separate files that are referenced from the profile-files that are processed by the same engine but deliver times in seconds instaed of costs and speeds instaed of costfactors.

After changing the nogo-logic in the service-interface for immediate effect of changes in the coordinate source, the invalidation logic for the template track is wrong: it should be invalidated if a nogo-change is detected.

The waypoint matching first searches for nodes in a given area ( +- 1/8 degree= ca 10 km at max) around the waypoint and then searches for way sections starting at these nodes that come close to the wayoint to be matched.

This can fail if the way-segements (=connecting links between "non-trivial" nodes) are too long. This is not an issue for streets in urban areas, but for rivers, railways, motorways or hiking trails off the beaten track.

Solution will be to limit the lengh of these segments by changing some intermediate transfer nodes to network nodes.

Please add the class:bicycle family http://wiki.openstreetmap.org/wiki/Class:bicycle to lookups.dat. I need at least class:bicycle and class:bicycle:mtb.

Hi,

The lookup seems to mash concrete, concrete:plates and concrete:lanes into one single thing
surface;0000212587 concrete concrete:plates concrete:lanes
It would be nice to have these separated, because concrete is pretty smooth and nice to bike on, while the plates and lanes are a major pain and slow down roadbikes significantly

Thanks for consideration

It'd be great if there was a way to export way ID's of a route.
I'm writing my own mapping application, and using these ID's, I could draw ways that are part of a route differently, instead of drawing the route on top of it.

I was experimenting in past with negative turncost, initially on a user demand to promote winding to straight roads. It does the effect, but sometime brings problems.

I got occationally at Brouter-web "Error: error re-tracking track". It looked mysteriously until I realized at Data tab some very winding way segments got significant negative Turncost comparable with the way cost.
It could lead to the final cost < segment length, or perhaps even final cost < 0, what is forbidden.

Ensuring turncost >=0 for the same profile and route avoided the above error.

I have already previously posted it on Google group, but I put it here to keep track, as I got no response.

I suppose this should be addressed.

Either not to allow negative turncost,
Either (preferred) by internal clipping for total segment cost >=segment length.

The latter would still allow to have the winding preference, but would avoid routing error.

If I understand it correctly, it is possible to define a "turncost" variable in the routing profile, which in turn is used to calculate the cost of turns depending on the turn angle.

However, in city traffic, the angle itself is much more important, as it can be used to determine left turns and right turns which should be treated differently. Can I directly access this angle? In general, is there an exhaustive documentation of the routing profile?

It seems the BRouter standard TRekking profile ( and my profiles as well ) ignore cycleways in costfactor context, if they are marked as an additional tag for highway="mainroad" cycleway=, resp cycleway:=*.

These tags are listed in lookups.dat and BRouter-web data tab, e.g. cycleway:right=track,
but the tags seem to be ignored by the Trekking profile ( and by mine as well until now. )

It is a pity, as all data providing bike friendly hints are important.

The above may lead to improper full penalization of highway=primary with costfactor 3.0, while there should be probably 1.0 because of integrated cycleway. ( Inspired by a recent post to Brouter group )

If a waypoint is set behind a OSM node with a following long segment of incline without a OSM node in the route, the hight model will show a peek. Example:
http://brouter.de/brouter-web/#zoom=16&lat=50.97287&lon=7.19881&layer=OpenStreetMap&lonlats=7.207654,50.972292|7.201576,50.972663|7.196796,50.974305&nogos=&profile=trekking&alternativeidx=0&format=geojson

If than the annoying waypoint is deleted, you can see the incline without the peek.

If a waypoint is set on a bridge, the height model of the complete route shows an error. Example:
http://brouter.de/brouter-web/#zoom=17&lat=50.936377&lon=6.96419&layer=OpenStreetMap&lonlats=6.961185,50.935677|6.965976,50.936269|6.970396,50.936397&nogos=&profile=trekking&alternativeidx=0&format=geojson
If the bridge-waypoint is deleted, the height model mostly went to ok.

Installing BRouter is still complicated and people are asking for a click&pray installation from Google's play store.

Such an installation would require to obtain an installation of BRouter's service-mode to be, with datafiles for the relevant region downloaded and with a default routing-mode->routing-profile mapping in effect.

So it would be a modified APK with additional permissions for internet- and location-access doing all the downloads and installing all config files as well as the "traditional" APK without the extended permissions.

highway=construction is already in your lookup file, but the trekking profile does not check for it
Please add it, it is really unpleasant to end up on such way
Thank you

Bicycle ways having a oneway:bicycle and a missing oneway are not treated as oneways.

For example here the direct route against the oneway:bicycle should not be taken, it would be better to route on the opposite cycle path:
http://brouter.de/brouter-web/#zoom=16&lat=50.93419&lon=6.97131&layer=OpenStreetMap&lonlats=6.971506,50.936621|6.971871,50.931478&nogos=&alternativeidx=0&format=geojson&profile=trekking

This assign statement should correct that.

assign oneway =
       if oneway=yes|true|1 then true
       else if oneway:bicycle=yes then true
       else if oneway= then junction=roundabout else false

The warning about big amounts of data being downloaded is great. It usually makes me check my data connection.
Not easy when the status bar is not visible ...

--> don't hide status bar

Could you please consider adding more maxspeed values:

maxspeed:conditional
maxspeed:forward
maxspeed:backward
maxspeed:motorcar

It would be really useful to have the maximum between all these and the normal maxspeed tag merged to the single maxspeed in the lookups.dat

Thanks

Bug if 2 nogo-areas exist for same location (with different radius):

• if one is not veto'ed to create a reference-track, the other still cretes a veto for both, so at the time of a timeout-free recalc, a nogo is missing that was effective when creating the reference track. That also leads to invalidation of the refernce track.
• if a profile is changed, reference tracks using this profile are not invalidated.

So there should be the nogo-name part of the key for the veto list, and checksum of the profile part of the reference track.

Currently the data files are showing the 30th of October. Wasn't there a weekly update?

Using the Android-App, alterative routes are calculated by running the calculation with the same parameters once more. This is time consuming for both entering the parameters and (for long distances) for the routing itself, since teh previous alternatives are calculated over and over again.

A "next alternative" button on the route summary page would help.

A week or two ago I have had in-app downloads of N10_N45.rd5 (and others) failing at around 33% completion due to timeout.

Using BRouter 1.4 from F-Droid on Android 4.4.4 with OsmAnd.

I was still able to download them manually from elsewhere and then adb pushing.

Hello,
wonderful piece of software! So far I seem to have found a way to actually use a software for road bike routing!

Back to topic. I use OsmAnd and use it for voice guidance most of the time. This would be so much better, if the street names were also spoken. I read that this is due to missing road names in the rd5 database.
Is there any chance that we might have a db that includes those, preferably as 2nd choice so that everyone who does not need them can save the space?
Best regards and greetings from Düsseldorf!
Rodja A.

When planning a route, there may be sections in the routing result that require attention (e.g. a ferry).

A new expression for the profile parser:

warn

with being displayed in the calculation summary if that expression contributed to the final routing result would by a generic way to achieve that

I discovered a short path, which seems not be routeable. Look this query.

Is something wrong?

It seems like linknodecost (NodeCost) is never written to lastMessage, because it is set outside the for loop, after lastMessage is set?

Example

It may be useful for future hosting applications to consider implementation of alias or custom modes for Brouter mode-profile mapping.

Partially for bicycle and definitely for foot routing, the current schema car/bicycle/foot fast/short is confusing and misleading, if Brouter is used as the 3rd party local routing engine.

As talked with the LocusMap author, the direct consequence is the application uses just one Brouter foot mode - the shorrt one AFAIK.

Users of eventual future alias/custom mode aware applications would be able to select from a bunch of self-explaining modes ( if profiles abstraction layer is to be kept ).

Applications not alias/custom mode aware would use standard modes as usually.
Applications alias/custom mode aware could use the exposed alias/custom names as well.

Predefined names could be prepared in cooperation with hosting application developers.

My idea is to implement one of or both partially independent ideas.

ALIAS modes, mapped to current modes, like

 ALIAS mode  --> Brouter navigation mode --> Brouter profile 

* Trekking Good Weather --> Bicycle short --> Trekking Dry.brf
* Trekking Bad Weather --> Bicycle fast --> Trekking Wet.brf
* Walking --> Foot fast --> Walking.brf
* Hiking --> Foot short --> Hiking.brf

The ALIASes could be either predefined, either custom ( Advanced used could edit the config file ).

CUSTOM modes, mapped directly to profiles aside of standard modes., like

 CUSTOM mode --> Brouter profile 

* Trekking Fast --> Trekking Fast.brf
* Trekking MTB --> Trekking MTB Light.brf
* Walking --> Walking.brf
* Hiking --> Hiking.brf
* Mountain Hiking --> Demanding Mountain Hiking.brf

I've run into a way that brouter should traverse, but won't, with the fast-bike profile while trying to find a cycling route from Portland, Oregon to a trailhead in Washington State (just trying out brouter). It's causing an epic reroute through different counties.

I'm assuming it's either

• an error in the OSM data,
• or some complication in the OSM data which is confusing brouter.

Here is a simple test case with the start and end on either side of the problem way (OSM), with car-test profile:

and with bike-fast profile:

The bridge is one-way for car traffic and has a bike lane going the other way. Bikes going with the direction of car traffic are supposed to ride in the lane.

The Map.Creator evaluates bike relations by just looking for route=bicycle ( see OsmCutter.nextRelation() )

Though these are mostly the national and regional cycle networks (e.g. network = ncn ), there exists other networks ( e.g. network=radweit ) that have a different characteristic but also lead to tagging the way as a long-distance-cycle-way.

Todo here is at least to filter the cycle-routes for the relevant networks

ClusterGIS has released a 15m/px global height model under CCBY
http://www.theearthsrelief.com/

Maybe its worth thinking about using it.

Hi team,

Brouter is awesome :-)

I'm using the web version of Brouter for offroad 4wd track routing, and unlike most other modes of transport we active seek out poor quality roads.

I see you expose tracktype, smoothness and surface via lookups.dat - but would it be possible to also add the 4wd_only tag?

This tag is used quite a lot, particularly in Australia where it is used as a standalone (tracktype, smoothness and surface not set)
http://wiki.openstreetmap.org/wiki/Tag:4wd_only%3Dyes
http://taginfo.openstreetmap.org/tags/4wd_only=yes#map

Thanks in advance...

What about including "informal" tag (http://wiki.openstreetmap.org/wiki/Key:informal) in the way context into the routingfiles? This way routing over inofficial paths could be penalized, as they are not guaranteed to be maintained or save.