Voice hint for route point on junction node

[nrenner]

Reported by @EssBee59 in brouter-web#356 "voice hint generation" after "Load Track as Route".

In this simplified example with a left turn, a wrong "turn right" hint is generated (e.g. with turnInstructionMode=3 osmand-style): http://brouter.de/brouter-web/#map=17/50.03360/8.73385/standard&lonlats=8.732253,50.033975;8.733453,50.032993;8.735944,50.03403

The via point is exactly at the position of the junction node 269491681 (rounded to 6 digits). As each route segment is calculated separately, I would have expected that no voice hint can be given.

Therefore I guess we need to move the via points a bit when converting a track to a route in the client anyway, as the Douglas-Peucker simplification probably tends to leave junction nodes at turns.

This minimal example without turn, only two route points and the destination on the junction node also generates the voice hint: http://brouter.de/brouter-web/#map=17/50.03359/8.73189/standard&lonlats=8.732253,50.033975;8.733453,50.032993

[EssBee59]

Hello,

In #356 I explained a workarround to this problem: As sugested by Norbert, after the conversion of the track to a route, the idea is to change the created route-points in order to avoid setting them exactly to junctions. A "new" route-point is now calculated in my version as the middle of the "raw" route-point and his previous trkpt in the original track. The change can be tested on this instance: http://brouter.de/essbee/#map=11/49.9576/8.5752/standard

I hope the change (or a similar or a better one) will be accepted as standard and deployed in the Brouter-web. Regards

[0709wiwiwi]

@EssBee59 Nice that you are investigating this. But it remains a difficult task anyway.

I have tested next import file on the mentioned web router. TET_trk_download.gpx.txt At import I kept the default 'fuziness' setting. Routing Profile: (Fastbike-very low traffic).

Detection of possible trackglitches. Too time-consuming detection without U-turn alerts. On a quick check I do notice 2 trackglitches. So in those locations expect confusing turn instructions.

Since mistakes are so hard to avoid, show_trace the suspected locations and correct manually to the best of your ability and insight.

Regards, Willy.

[EssBee59]

Hello 0709wiwiwi,

I agree, in 3 locations "confusing turn instructions" are generated! I think, the quality of the original track is responsible for this: Some poinst are very strange (outside the route), in other places, due to a long distance between 2 points, the track line is also many meters outside the route.

[0709wiwiwi]

Sure, If you convert the track for Locus as described (with attachment of turn instructions by BRouter web), it is with errors.

Usually I, a gps user, limit myself to the Locus results with the plug and play ready attached instructions by BRouter web. Due to the A11 problems the Locus gps development paused for a while, so I made a very instructive trip to the Kurviger app.

Crazy track(s). Unfortunately, there is a lot of imperfect track material available for download on the internet.That's just a fact. No matter how hard designers (thank you, thank you) try to improve results, there are no miracle solutions.

I already carried out dozens of similar tests, by now I so simply accept such unavoidable imperfections. Should not be a real operational problem when a tool is available to detect and show the trouble spots. What interests me, a gps user, is a quick tool that shows me where exactly there may be possible errors.

The tested Kurviger app with its U-turns in the turn list is in my experience been the most helpful tool. That is why I plead for the Brouter to generate the very functional (180°) U-turns just like the GH engine. The tool is so useful both for a completely manual new design and for an automatic track conversion.

In Kurviger, you detect the U-turns in the turnlist and deal with the corresponding triggering planner point. What is not yet been implemented in the app is a fast nice on map indication of the problematic locations.

[EssBee59]

Hello brouter experts,

I spend last year a lot of time to search the cause of the original problem (voicehint generation when a route point has exact the same position as a junction node)

Now I had a look at the code and I suspect the following behaviour to be the cause of the problem:

• The "RoutingEngine" calculates the track for each part of the route (from a route-point to the next)
• If several route-points are entered, the tracks are added together: This is OK!
• But the RoutingEngine calls in the same way the "ProcessVoiceHints" for each part of the route.... and I think this leads to the problem of this issue!!! (without knowledge of the previous track-point, the angle at the junction / start point can not be calculated) A redesign should be done to call "ProcessVoiceHints" for the total route at once!

[poutnikl]

If BRouter knows, what the total route is.....

[polyscias]

• The "RoutingEngine" calculates the track for each part of the route (from a route-point to the next)
• But the RoutingEngine calls in the same way the "ProcessVoiceHints" for each part of the route.... and I think this leads to the problem of this issue!!!

100% agreed, that is what I already wrote in https://github.com/abrensch/brouter/issues/436#issuecomment-1136364940

I also still think we need to have functionality to snap via points to the way network, especially if the via point are close to crossing.

[0709wiwiwi]

I also still think we need to have functionality to snap via points to the way network,

They already are....in the result as a corresponding trackpoints they always match the way network. Each plannerpoint generates a corresponding associated trackpoint. Trackpoints are automatically attached on the road network. But you should stay away from street junctions otherwise they can be be snapped to a nearby false road. = trackglitch.

[polyscias]

Yes and no, trackpoints are not snapped to the way network in the sense that the track contains a line from the actual trackpoint to the point on the closest way of the way network. That is typically no problem for via points as long as they are not close to a crossing.

I think that in almost all cases the user will be happy if the waypoint is moved to be on the way-network; I am eager to hear reasons for not doing so.

[0709wiwiwi]

You can even see in the actual BRouter where the Via Point has his corresponding trackpoint located. Near the planner point Via or Shaping you do notice a fine little small line over the visual track. No ?

[EssBee59]

If BRouter knows, what the total route is.....

Hi Polischias, In the requests to Brouter (from brouter-web or Navi-apps) many route-points can be specified. In the example of this issue with brouter-web, a track was previously loaded as route... (assuming 50 route-points were generated and coded in the URL of brouter-web)

As result, brouter-web send a similar rquests to brouter with 50 route-points... The problem I see, currently the brouter calculates the 49 tracks between this points separatly and concatenates these 49 tracks to get the total track... But it do the same for the voicehints!

The problem is, when as example the point between track 1 and track 2 needs a voice hint (as it is a node), who is responsible for that / who can produce the voicehint? To produce the right voicehints, track1 and track2 must be processed in the same run / together!

[polyscias]

To produce the right voicehints, track1 and track2 must be processed in the same run / together!

Yes, like I wrote above, I already did 100% agree on that ;-)

@0709wiwiwi : Yes, correct, I was wrong, no line from the waypoint to the neatest way is drawn.

Still I think that if there is a crossing nearby, the waypoint is better snapped to that crossing.

My proposal would be: Take the distance to the nearest way using the method that is currently used, let call that Lw. Now check if there is a crossing within 1.5*Lw distance of the waypoint and if so, take that crossing.

[0709wiwiwi]

Automatically convert a track into a track with navigation instructions. (I avoid the expression convert to (rte) route because that is it not either)

@EssBee59

The example with what the "user" experiences as being a wrong turn instruction Right.

Which voicehints to expect at the 'snapped' planner point positons ? There are two instructions which belong to planner point position.

1. A continuous or straight. As I am already riding forward, this straight is not necessary and even undesirable. At shaping points I do not want any announcement, no sound, no symbol, no auto display on.

2. A U-turn. A U-turn command (usually unwanted) is what I expect for sure. Serves as alarm sign ! BRouter does not generate U-turns. A possible nice alarm sign but the light is missing. The U-turn would otherwise tell you that your planning point is not well positioned.

In the example, the turn instructions (near the snapped planner point position) are technically correct. But the planner point is at a false position. So triggers a Right but the next (cm distance) U-turn is missing.

The planner point triggers an unexpected U-turn? Then be bold and remove that planner point. Do as a good surgeon does, don't hesitate, cut. Compare the routing result with the original track import overlay.

=========

Another convert example video by using the Cruiser_Brouter app. https://youtu.be/MmedcoEtupo Calculation (fast) using (rtept) distance tickmarks derived from the import track. Without U-turn, the single wrong planner position is quite difficult to find. By using tickmarks there are less critical planner points near junctions.

[afischerdev]

@EssBee59

* But the RoutingEngine calls in the same way the "ProcessVoiceHints" for each part of the route....
  and I think this leads to the problem of this issue!!!
  (without knowledge of the previous track-point, the angle at the junction / start point can not be calculated)
  A redesign should be done to call "ProcessVoiceHints" for the total route at once!

Thats what I try with the #441. The point to point tracks are collected as well as the detours. And at the end the voice hint process is called.

Your very first sample in this thread comes now like this:

testtrack0.same_pts.gpx.txt

[EssBee59]

Thats what I try with the #441. The point to point tracks are collected as well as the detours. And at the end the voice hint process is called.

Hello, I restarted a first test using version 1.6.4 and found no voicehint-errors ! Gratulations to the change!

I will try to start further tests in the next days...and will report in #441 (about problems not concerning voice-hints)

[afischerdev]

@EssBee59 Great to hear that, many thanks.

[nrenner]

This issue only came up because the "load as route" feature in the client, that programmatically generates via points at node positions with a bias for junctions (brouter-web#356), so I suppose it's a rare edge case otherwise that might not need fixing.

There is a proposed workaround for that, it just needs some more work before merging: brouter-web#369 .

The weird thing is just that it always generates a right turn instead of just none or maybe some kind of "heads up" warning (maybe "Off route").

[EssBee59]

The weird thing is just that it always generates a right turn instead of just none or maybe some kind of "heads up" warning

Hello Norbert, I did not know about that... For me the workarround I suggested (not using the junction point, but the middle of junction point and last track-point) is running, could you give some details? The bad thing: by testing #441 I discovered further problems: Not only "voiceHints" are in error: some times, the generated track is in error after a load "track as route"

http://brouter.de/brouter-web/#map=16/50.0078/8.8099/osm-mapnik-german_style&lonlats=8.799857,50.004894;8.808872,50.007659;8.80993,50.007943;8.810851,50.006446;8.81355,50.003108;8.814458,50.002141;8.815893,50.000959&profile=fastbike

[nrenner]

The weird thing is just that it always generates a right turn instead of just none or maybe some kind of "heads up" warning

For me the workarround I suggested (not using the junction point, but the middle of junction point and last track-point) is running, could you give some details?

I don't mean your solution, I'm just referring to this issue, see issue description in first comment.

[afischerdev]

@EssBee59 To change his problem I added a logic with direction detection. This will also work with only two points, you have reported as well.

@all The new waypoint matcher is added to the bigger update lib #441 because some of the problems reported there and the tests taking place there. But if wanted I could do an extra PR for this - the library update will take a longer time, if it's ever done.

[EssBee59]

Hello,

Is it allready possible to start tests? (need a link to download the new version) Wich use case should be retested (the original "voiceHint" issue, or the new detected "track/routing" issue)? With use of brouter-web? version? Regards

[afischerdev]

The library is generated by git actions. The ZIP below on side contains new jar file.

[EssBee59]

Hello,

My retest was not successfull:

Firtst, I liked to describe my 2 use cases: A- My bike-club organizes every year bike tours (so called RTF in germany), 4 different routes are defined. But the routes have to be changed a bit every year ....(this year we had to build 3 changes each after one)

B- Most of the time the GPX I receive have only a track, and I enrich the GPX with voiceHints to get the best guiding

For that, I am using the feature "load track as route" in brouter-web, I modify the route by need, select the right turnInstructionMode and export the new track (kinf of reexport)

And exact in this situation (in the origin track, points are = node/junction) as reported in this issue "voiceHint" issues occur, worst, some times Routing issues occur too.

No idea how many users are using Brouter in this way.

I attach a new example: 1- the origin track 2- the reexported gpx using brouter.164 (track and route with voicehints for Osmand) 3- the reexported gpx using brouter.163 and brouter-web 0.16.0 + my own workarround in "load track as route"

"gpx 2" contains many issues ( voiceHints and routing) 47km_original.gpx.txt

47km_Brouter164_New.gpx.txt

47km_essbee.gpx.txt

[afischerdev]

@EssBee59 Great sample. So I found my fail. But I have one more unexpected direction before I will have a view on voicehints.

[0709wiwiwi]

@EssBee59 Fine while afischerdev is still working on this huge task. (Voluntary) In the mean time I so made another (on sofa) use test.

I maintain that putting routepoints (or planner points if you like) at road junctions is a mortal sin. If you make sure you stay away with the route points from road junctions, you won't have wrong instructions. And if by chance or accidentely there is still an unexpected U-turn, than a U-turn alert tool would warn you about it.

The test. Cruiser app using the BRouter apk 1.64 test version. Profile fastbike with add assign avoidPeaks = 0

Convert the original track to route with next online Javawa tool. https://geo.javawa.nl/routefilter/ This tool places almost no routepoints on road intersections. How the designer Jaco manages to do this I do not know. But no routepoints at road junctions is the key to success.

Convert the Garmin extension Shaping Points to type Shaping for import in the Cruiser app. Merge the original track and the route into one gpx file for import into the Cruiser app. Upon import, than use the track as a visual template and the route to calculate with.

Neu-Isenburg_47km_rte_trk.gpx.txt

Cruiser result. Position the start and end that are close to each other, logically, so to avoid a direct navigation to end. There are two U-turns in the new generated navigation result by the Cruiser_Brouter app. The first one is at Eppersthausen.

• Is it expected that you swoop into the shopping centre? The second one is near Bleiswijker Strasse.
• Reposition the Shaping Point further onto the side road so exactly follows the original track.

Conclusion. That result is reliable and can usefully be used for a real fine navigation operation. No route points at road crossings is a guarantee for generating neat instructions anyway.

Translated with www.DeepL.com/Translator (free version)

[EssBee59]

This tool places almost no routepoints on road intersections. How the designer Jaco manages to do this I do not know. But no routepoints at road junctions is the key to success.

Hello, I agree, I am using a similar workarround since 2 years.

Sorry, I do not understand what your test do exactly (possible translation issue?):

• The generated route is not optimal: as example the U-turn in Eppertshausen (catering place for the bikers!) do not appear.

• "merge the original track in the GPX" ...is not what I want: my goal is to apply a minor change to the route and "re"-export the new track

[poutnikl]

Profile fastbike with add assign avoidPeaks = 0

Is avoidPeaks a variable of customized/not yet published fastbike profile, or recently implemented system variable? Is it about extreme avoidance of hills, or anything else?

[EssBee59]

Great sample. So I found my fail. But I have one more unexpected direction before I will have a view on voicehints.

Again, thank for working on that! As my workarround is quite running, feal free to decide how much time you can invest in these special problems.

But I try to help and created a detailled documentation of the new detected "routing issue" (not voiceHint) regards routing_nok.pdf

[afischerdev]

@EssBee59 Many thanks for the clearing. But I already use exact this test mini parts to verify new functions. And they are done. I'm hanging on an other part:

This is a problem in old lib 1.6.3 (pure) and it is also present in 1.6.3 with new waypoint matcher - my current test scene. All via points are checked for equal with junction and moved a little backwards than. All directions looking fine but the result is still bad.

[afischerdev]

@EssBee59 I did a test with the JaVaWa file. They have reduced the input to 50 points. With this the new waypoint matcher also produces a nice track. May be this is the point I can't follow: I don't know what web client is doing with an imported old track. Does it also reduce the input points? I always try the hole input file 47km_original.gpx - all points.

[EssBee59]

Hello,

Brouter-web is using the "turf.simplify" utility (https://www.npmjs.com/package/@turf/simplify) The trkpt´s are given as input (+ a tolerance prameter that impact on the number of route points that will be created), a list of route points is returned (= reduced point list, also named "simplified wp") I attach the java-scrit module that also contains my workarround regards

RouteLoaderConverter.js.txt

In my opinion (after tests) this turf.simplify utility is doing a very very good job!

By need, my test instance: http://brouter.de/essbee (when using the developper-tools in the browser you get a lot of informations on the console during the "load track as route")

[0709wiwiwi]

@EssBee59

Do you know the Cruiser app? The original track is imported as a passive template to visually check if the new recalculation result matches. And I have attached the used import test file. Currently manual preparations are required.

Converting tracks to add turn instructions automatically is quite useless up till now. The necessary checking of the result is more time-consuming than manual retracing. You absolutely must catch wrong instructions already in the design and not during cycling. And a U-turn alerter tool could point out these turn errors more quickly.

What is the intention? Avoiding routepoints onto road junctions. Eliminate unexpected U-turns by deleting the corresponding routepoint. There are enough routepoints left to reproduce the original trackpath.
Compare the new calculated track result with the import track template.

Find a second test file by another method intended for Cruiser_Brouter import. Ready for Cruiser NI_trk_47km_rte_0.5km_tickmarks.gpx.txt

Contains medium density total routepoints. More rtept's results in longer (re)calculation time. (Low density < 50 rtpet) (Medium density 50 to 100 rtept) (High density 100 to 200 rtept)

Here by using fixed track 0.5km distance tickmark routepoints. (Max is 200). Video: https://youtu.be/FPqvpPrt7h8 A new calculated track by using more rtept's will be more faithful, but the chance of U-turns increases. Find unexpected harmfull U-turns in the turn list and eliminate the corresponding routepoint.

THE QUESTION. Even if completely automated, does it save you time compared to manual retracing? Y or N ? Because a final check on the track fidelity and U-turns remains necessary.

The U-turn in Eppertshausen (catering place for the bikers!) Just by luck the tickmark Shaping routepoint is located near that place. If not, assisted by the track template quickly create a routepoint.

@poutnikl This was needed for a BRouter test apk.

[afischerdev]

@poutnikl

Is avoidPeaks a variable of customized/not yet published fastbike profile, or recently implemented system variable? Is it about extreme avoidance of hills, or anything else?

avoidPeaks is a new variable for the global part of a profile. This is default true when not defined. But this is on work and the naming was not a very lucky selection. And it doesn't follow the rules other variables use. So I think next time you will see something like 'avoid_spikes' with the text 'Set to true to avoid glitches in your result route' for the standard profiles.

[afischerdev]

@EssBee59 Thanks for the pointer to the pre selection in web client. I will next time pre work with the simlify script on my node installation. Tomorrow I will update the 1.6.4 version with the updated waymatcher. So we have time for the voicehints.

[0709wiwiwi]

What I have not yet mentioned by Cruiser_BRouter is the following. This can only be done recently by the test apk 1.6.4 U-turn support ! The procedure is similar to what you are doing in BRouter web. But current operational BRouter web lacks the necessary U-turn support.

Import in the Cruiser_BRouter app the original track and select. Overlay: Track Routing: Track. Set max number of waypoints with the slider. Many or few? (To be tested)

There might be U-turns caused by some Shaping Points. Using the track template adjust and fine tune if necessary.

[EssBee59]

Hello 0709wiwiwi!

Your enthusiasticacly comment the cruiser app on this thread and a lot of current brouter/brouter-web issue.... Every one has his prefered app, I undersdand this, I also want to learn... But.. this is a thread to enhance the Brouter!!! (not to promote new apps)

Every tipp to get "better" the brouter is welcomed! Sorry, I tested the cruiser app shortly... without real success.. (A discussion about this is NOT right at this place)

For my me, brouter, brouter.app and brouter-web are the core application I intend to use.

[0709wiwiwi]

@EssBee59 No no, it's definitely about Brouter and BRouter web promotion. But with the current BRouter web I can't show what is now possible with an app, for me whatever app. The app allows to display the import track on top of the recalculated track and so is ideal to compare.

[poutnikl]

Improving on-topic apps sometimes takes off-topic ones.

[afischerdev]

Repair of waypoint matcher is out. You find it in git actions in the ZIP file.

Next part I like to have a view on the voicehints. Based on the route points in EssBee59 Neu-Isenburg_47km_rte_trk.gpx.txt file.

[EssBee59]

My retests:

Brouter version 1.6.4 of this morning and brouter-web 0.18.1:

Test data: 10 tracks (generated with brouter), summary 1.000 km

test scenario: "load track as route" and reexport

results: 0 "routing" error detected!

Very good job!

I will try to execute further tests next week and report by need

regards

[EssBee59]

further tests: calculate 3 new routes (70 km, from A to B) and compare the results of 1.6.3 and 1.6.4:

No problem found!

[0709wiwiwi]

Concerning the BRouter turn instructions and the Voice hint generation.

A cycle route that largely follows an old railway line seems to be quite a challenge for the Brouter. Brouter definitely sees more turning in it than the locomotive drivers ever did in the past. Attached the gpx file export in the Locus (7) compatible navigation track format from the RouteYou web planner.

routeyou-zelzate-eeeklo-i55-oude-spoorweg-route-locusmap.htm.txt routeyou-zelzate-eeeklo-i55-oude-spoorweg-route-locusmap.gpx.txt

[afischerdev]

@0709wiwiwi I'm not sure if I understand you right. From my point of view everything looks well. Old spooway is not defined all over the way. Could you tell us please what points you see faulty.

[0709wiwiwi]

I retested by by Bikerouter.de and that result is indeed fine.

https://bikerouter.de/#map=17/51.19887/3.62578/standard&lonlats=3.79456,51.208156;3.704341,51.247367;3.637936,51.223555;3.589921,51.17769;3.574242,51.181758

(Ok to use)

Find the Bikerouter result also in the htm. Zelzate -_ Eeklo (22.5km)_Locus(2) by BRouter web.htm.txt

I so tested again by the current Cruiser_Brouter app combination. (BRouterApp.1.6.4g-release.apk) And I copied and so used that same trekking.brf file as was used by Bikerouter.de

result has false instructions and surprisingly routes even direct over that motorway. As Cruiser does not export a plug and play ready to go gpx navigation track :-(( So I can't easily share you that results inclusive the turn instructions. (But Locus map by the same Brouter apk and profile is also not ok and does also not match the Bikerouter.de result) Any idea ?

The imported file with the reference wpt's to be used for the routing in the CruiserBrouter app combination. [Zelzate - Eeklo (22.5km)_None (0wpt).gpx.txt](https://github.com/abrensch/brouter/files/9242363/Zelzate.-.Eeklo.22.5km._None.0_wpt.gpx.txt)

[afischerdev]

@0709wiwiwi The way points gpx was very helpful. It shows where the route is about. But I got a different result to your first and second sample.

1. routeyou sample doesn't use the tunnel under the road A11
2. bikerouter sample has same problem but other result and it doesn't use the spoorway around Assenede.

For this gpx I used lib 1.6.4, trekking and Locus output. testtrack0_spoorway.gpx.txt

It is hard to compare when apps don't use the sample profile. I know Locus uses its own profile and send it to BRouter. But I can't say what Cruiser is doing.

[0709wiwiwi]

There is no tunnel under the road A11. You have to pass by the traffic lights. (Dangerous crossing) Locus uses the same Brouter app (BRouterApp.1.6.4g-release.apk) And the same identical trekking profile as the Cruiser app does.

To know. _To test in Locus map you add a custom profile into the Locus folder router profiles2 folder. The more recent Locus map versions do not use custom profiles in the BRouter app profiles2 folder Example on A9 phone use the folder in: /storage/emulated/0/Locus/router/profiles2/trekkingap0.brf

Result by Locus app is: Zelzate-Eeklo_Locus_app_trekking_ap0_navwpt.gpx.txt

[devemux86]

But I can't say what Cruiser is doing.

Cruiser uses what is described in IBRouterService:

• BRouter app: "v" --> [motorcar|bicycle|foot]
• Brouter website: "profile" = profile file name without .brf [car-fast|fastbike|trekking]

It does not map any custom profiles, this is left for the users (as described here).

[afischerdev]

@0709wiwiwi

There is no tunnel under the road A11.

I can see one in OSM. And the Locus routing also use this tunnel. Defined: highway=no railway=abandoned tunnel=yes and a biker route 'F423 Fietssnelweg Kaprijke'

@devemux86 Thanks for the clearing.

[0709wiwiwi]

For 100% sure there is no (never was a) tunnel. The current bikerouter.de result by using the standard trekking profile is absolutely more correct. Changed was turninstructionCatchingRange = 4. And it has also attached so the more correct valuable "straight" turninstructions. There is probably a serious problem in that beta apk. As well the routing results nor the turns are fine

This also demonstrates the multiple problems, you as a gps user, usually than get when sharing and using (rte) routes. Calculation by reference wpt's or by rtept's, you frequently do get a different result with the original planned design. :-(( The slightest difference in router engine or profile or routing data are causing than unexpected changes and results. By sharing a plug and play, ready to go, gpx navigation track inclusive integrated instructions in trkpt such troubles do not occur. Always transfer 100% faithfull designs, this on the condition of course that no recalculation nor (auto)rerouting is allowed after import in the navigation app.

Update. I had a quick look at that so-called tunnel. So it is a "NL wenstunnel F423"or "EN wish tunnel F423". According to the added note based on news paper talk. That "wish tunnel" was highway=no https://github.com/abrensch/brouter/issues/402 I asked in the BE OSM forum what to do with it. The E0_N50.rd5 file is updated.

[carg0cult]

This bug is still present on brouter.de/brouter-web. Many turn instructions are generated in the wrong direction. I tested an example on brouter.de/essbee and it was correct. Could you please apply the fix to brouter.de/brouter-web or what needs to be done? Maybe I can help.