Wrong elevation in route planner
Solved
I don't know exactly when this started. Im am now on Locus 3.68.2.
Yesterday I planned a route that was almost the same as one i planned some months ago. The old route hat about 1400m of elevation gain, which is realistic. The new one however, shows 1800m, which cannot be true. When i save the route and update the elevation, it corrects to the 1400m. I always use BRouter for route calculation.
The same problem 
Hello,
the calculations of elevation were updated recently, but there are not implemented across all platforms right now, so they could differ. We are working on that.
Also, the BRouter is an external service and we do not know how the elevation is calculated here.
In general, all routers only calculate estimated values and as there is no standardized method, they may vary a lot during a lot of smoothening and averaging and imprecise altitude data.
From our sight - LM4 with LoRouter should provide the most precise data right now (from our range of products).
Regards,
Zdenek, Locus team
Hello,
the calculations of elevation were updated recently, but there are not implemented across all platforms right now, so they could differ. We are working on that.
Also, the BRouter is an external service and we do not know how the elevation is calculated here.
In general, all routers only calculate estimated values and as there is no standardized method, they may vary a lot during a lot of smoothening and averaging and imprecise altitude data.
From our sight - LM4 with LoRouter should provide the most precise data right now (from our range of products).
Regards,
Zdenek, Locus team
As written here https://help.locusmap.eu/topic/31519-route-planner-respect-tunnels-and-brides-for-elevation-sums#comment-129131
LM3 and LM4 are using BROUTER in a different way: In case of LM3 Locus inserts on-the-fly its internal elevation data from "SRTM"-folder. This is not true for LM4, where first BROUTER's internal (very rough) elevations are used.
@Matthias: to reproduce your problem you have to attach a GPX-track of your route and tell if you're using indivual elevation files (e.g. those downloaded by Locus, or those from Sonny ? )
As written here https://help.locusmap.eu/topic/31519-route-planner-respect-tunnels-and-brides-for-elevation-sums#comment-129131
LM3 and LM4 are using BROUTER in a different way: In case of LM3 Locus inserts on-the-fly its internal elevation data from "SRTM"-folder. This is not true for LM4, where first BROUTER's internal (very rough) elevations are used.
@Matthias: to reproduce your problem you have to attach a GPX-track of your route and tell if you're using indivual elevation files (e.g. those downloaded by Locus, or those from Sonny ? )
I am using the sonny elevation files. But it seems like LM3 is not using them when planning with BRouter. It only uses them when i manually update the elevation.
Here is an example GPX:
https://drive.google.com/file/d/1XUq3u6X6cXk_0TRtFyQ8bo4au41n8l0V/view?usp=drivesdk
After planning, elevation gain is 1122m, after 'Update elevation' via Locus it is 851m, which is the expected value. Looking at the elevation plot, the original route has a lot of elevation spikes that do not exist in reality. So either the lower quality internal elevation data of BRouter is used or there is some issue with smoothing the elevation data.
I am using the sonny elevation files. But it seems like LM3 is not using them when planning with BRouter. It only uses them when i manually update the elevation.
Here is an example GPX:
https://drive.google.com/file/d/1XUq3u6X6cXk_0TRtFyQ8bo4au41n8l0V/view?usp=drivesdk
After planning, elevation gain is 1122m, after 'Update elevation' via Locus it is 851m, which is the expected value. Looking at the elevation plot, the original route has a lot of elevation spikes that do not exist in reality. So either the lower quality internal elevation data of BRouter is used or there is some issue with smoothing the elevation data.
I've tested your route, and you're right. Current behaviour of LM3 is to use the (quite useless, since quite wrong by nearly 300 m) internal elevation data of Brouter which calculates -293m / +1122 m for this route. The correct values (after clicking onto "Update elevation" using Sonny's DTM files) are: -10 m / + 851 m
The correct values can easily be checked, cause the route is a constant inclining way from 613 m to 1454 m above sea level.
I think this behaviour of LM3 changed recently cause I think before LM3 automatically used elevation data of "SRTM"-directory. Just in the case if no files of this area available, LM3 used BROuter's internal elvation data.
In my opinion the current behaviour is not ideal, cause after using Route planner, people get completely wrong elevation totals and a wrong chart. I also think, that many Locus users don't even know that they get wrong elevation sums, trust them and don't know that there's a (quite hidden) option "Update elevation" to get correct sums.
I've tested your route, and you're right. Current behaviour of LM3 is to use the (quite useless, since quite wrong by nearly 300 m) internal elevation data of Brouter which calculates -293m / +1122 m for this route. The correct values (after clicking onto "Update elevation" using Sonny's DTM files) are: -10 m / + 851 m
The correct values can easily be checked, cause the route is a constant inclining way from 613 m to 1454 m above sea level.
I think this behaviour of LM3 changed recently cause I think before LM3 automatically used elevation data of "SRTM"-directory. Just in the case if no files of this area available, LM3 used BROuter's internal elvation data.
In my opinion the current behaviour is not ideal, cause after using Route planner, people get completely wrong elevation totals and a wrong chart. I also think, that many Locus users don't even know that they get wrong elevation sums, trust them and don't know that there's a (quite hidden) option "Update elevation" to get correct sums.
Thanks for your analysis Sonny. I fully agree to both of your points.
1) This behavior is new in LM3. Seems like the change was with one of the last updates.
2) This behavior is not ideal as it delivers completely exaggerated values for elevation gain/loss.
I hope the Locus team considers reverting this change.
Thanks for your analysis Sonny. I fully agree to both of your points.
1) This behavior is new in LM3. Seems like the change was with one of the last updates.
2) This behavior is not ideal as it delivers completely exaggerated values for elevation gain/loss.
I hope the Locus team considers reverting this change.
I reported this problem too.
In LM4 there are two issues:
- There is always a discrepancy between the elevation gain before and after saving the route.
- Using srtm data the elevation gain is heavily wrong. Using Sonny's Lidar data, the value is by far more realistic. Although when comparing the Lidar calculated value with the elevation gain of a recorded track, it seems to be too optimistic, that is, regularily too low.
Please find attached screenshots of the different situations and also from the same routein Komoot and OutdoorActive
,
I reported this problem too.
In LM4 there are two issues:
- There is always a discrepancy between the elevation gain before and after saving the route.
- Using srtm data the elevation gain is heavily wrong. Using Sonny's Lidar data, the value is by far more realistic. Although when comparing the Lidar calculated value with the elevation gain of a recorded track, it seems to be too optimistic, that is, regularily too low.
Please find attached screenshots of the different situations and also from the same routein Komoot and OutdoorActive
,
BRouter srtm
BRouter srtm
Lidar updated
Lidar updated
Here again the results with different settings and compared with the other tools:
BRouter/srtm
before saving: 776m
after saving: 910m
LoRouter/srtm
before saving: 723m
after saving: 818m
Elevation correction with Lidar data
before saving: 424m
after saving: 554m
Komoot: 580m
OutdoorActive: 351m 😆
I do not know since when Locus calculations are such a mess.
Based on srtm data elevation gain was always higher compared with the recorded track.
But now route planning for road biking is for me rather useless.
Here again the results with different settings and compared with the other tools:
BRouter/srtm
before saving: 776m
after saving: 910m
LoRouter/srtm
before saving: 723m
after saving: 818m
Elevation correction with Lidar data
before saving: 424m
after saving: 554m
Komoot: 580m
OutdoorActive: 351m 😆
I do not know since when Locus calculations are such a mess.
Based on srtm data elevation gain was always higher compared with the recorded track.
But now route planning for road biking is for me rather useless.
2 strange things: Why the values after saving in case of "BRouter/srtm" and "LoRouter/srtm" are that different? Shouldn't be both routes identical and hence fillled with the same srtm-elevation values?
As far as I know Komoot is using Sonny's elevation data, so their values are quite ok. But so do OurdoorActive I think regarding to https://www.outdooractive.com/de/map-information.html
Are Sonny's files only used for the elevation lines of their maps - but not their route planner?
2 strange things: Why the values after saving in case of "BRouter/srtm" and "LoRouter/srtm" are that different? Shouldn't be both routes identical and hence fillled with the same srtm-elevation values?
As far as I know Komoot is using Sonny's elevation data, so their values are quite ok. But so do OurdoorActive I think regarding to https://www.outdooractive.com/de/map-information.html
Are Sonny's files only used for the elevation lines of their maps - but not their route planner?
BRouterWeb: 489m
BRouterWeb: 489m
So, AFAIK, BRouter uses srtm data in this area. Nevertheless the result is fairly good compared with the computation based on Lidar data. See above.
So what the heck is LM doing when using BRouter as external router?
Elevation calculation is one of the most important features for me.
I am using LM frequently for a rather long time now and are paying for a gold subscription.
So please tell when this bug is going to be fixed.
So, AFAIK, BRouter uses srtm data in this area. Nevertheless the result is fairly good compared with the computation based on Lidar data. See above.
So what the heck is LM doing when using BRouter as external router?
Elevation calculation is one of the most important features for me.
I am using LM frequently for a rather long time now and are paying for a gold subscription.
So please tell when this bug is going to be fixed.
Even more "funny":
I exported the route from BRouterWeb and imported it to LM not checking elevation update in import dialog.
Result: 790m
Even more "funny":
I exported the route from BRouterWeb and imported it to LM not checking elevation update in import dialog.
Result: 790m
LM3+BRouter has spikes in the elevation profile. That's where the exaggerated elevation gain/loss comes from. On my test route, which should have 0m elevation loss, LM Route Planner shows 248m (before saving) and 293m (after saving) elevation loss. The profile looks identical before and after saving, I don't know where the extra 45m after saving come from.
LM3+BRouter has spikes in the elevation profile. That's where the exaggerated elevation gain/loss comes from. On my test route, which should have 0m elevation loss, LM Route Planner shows 248m (before saving) and 293m (after saving) elevation loss. The profile looks identical before and after saving, I don't know where the extra 45m after saving come from.
Tried now in BRouter web. It shows 1035m of elevation gain. When exporting as gpx and importing that into LM, LM shows 1077m elevation gain, which is exactly the same as planned in LM+BRouter before saving.
Tried now in BRouter web. It shows 1035m of elevation gain. When exporting as gpx and importing that into LM, LM shows 1077m elevation gain, which is exactly the same as planned in LM+BRouter before saving.
I planned now the same route (Freudenstadt - BadenBaden) in LM3 using BRouter with the same far to high elevation gain of more than 900m.
Since I installed LM3 anew (next to LM4) the data/srtm folder is empty. So the elevation data seem to come from BRouter.
My BRouter data are up-to-date.
I planned now the same route (Freudenstadt - BadenBaden) in LM3 using BRouter with the same far to high elevation gain of more than 900m.
Since I installed LM3 anew (next to LM4) the data/srtm folder is empty. So the elevation data seem to come from BRouter.
My BRouter data are up-to-date.
Another finding for the same topic in LM4:
I planned the same route from Freudenstadt to Baden-Baden using LoRouter and updated the elevations with Locus srtm data which yields an elevation gain of 708m.
When selecting a point of track, the statistics tells that up to this point the elevation gain was 356m and 218m still to go.
218 + 356 = 574 and not 708
574m is roughly the same value which is calculated by Komoot and Sonny's Lidar data.
Another finding for the same topic in LM4:
I planned the same route from Freudenstadt to Baden-Baden using LoRouter and updated the elevations with Locus srtm data which yields an elevation gain of 708m.
When selecting a point of track, the statistics tells that up to this point the elevation gain was 356m and 218m still to go.
218 + 356 = 574 and not 708
574m is roughly the same value which is calculated by Komoot and Sonny's Lidar data.
Same route in Locus WebPlanner: 1454m
Same route in Locus WebPlanner: 1454m
So my conclusion is that the computation of the overall elevation gain is buggy!
In each route, regardless which router was used and which data for elevation correction,
when selecting a track point, the sum of "from start" and "to end" elevation gain seems to yield the correct value. It is always significantly lower than the overall elevation gain!
So my conclusion is that the computation of the overall elevation gain is buggy!
In each route, regardless which router was used and which data for elevation correction,
when selecting a track point, the sum of "from start" and "to end" elevation gain seems to yield the correct value. It is always significantly lower than the overall elevation gain!
Freudenstadt to Baden-Baden:
- GPS measured three days ago : 432 m
- Planned route corrected with Sonny's data: 449 m
I would say this is fairly good.
Freudenstadt to Baden-Baden:
- GPS measured three days ago : 432 m
- Planned route corrected with Sonny's data: 449 m
I would say this is fairly good.
I did not observe the issue with the different elevation gain/loss before and after saving after the last LM update. Al least the elevation is now consistently wrong :)
I did not observe the issue with the different elevation gain/loss before and after saving after the last LM update. Al least the elevation is now consistently wrong :)
Can confirm. The difference before and after saving is gone.
And both, offline LoRouter and BRouter consistently yield the same wrong result of about 800m for the track Freudenstadt to Baden-Baden.
Can confirm. The difference before and after saving is gone.
And both, offline LoRouter and BRouter consistently yield the same wrong result of about 800m for the track Freudenstadt to Baden-Baden.
Question: What is the intention of the need to correct the elevation manually, when the results of the routers are significantly wrong in mountainous and/or wooded environments?
Question: What is the intention of the need to correct the elevation manually, when the results of the routers are significantly wrong in mountainous and/or wooded environments?
Topic solved without solution. Awesome.
Topic solved without solution. Awesome.
This is rather odd, indeed.
I wonder why Locus is not capable producing reliable elevation values when Komoot does?
Firstly, it is quite strange that one needs to call elevation update manually, in order to get a better (but still wrong) result.
Secondly, why providing SRTM data, when these are known to yield systematically wrong elevation values?
As far as I remember, Sunny stated that Komoot uses his Lidar based data. What hinders Locus to do so likewise? Is this a matter of money?
This is rather odd, indeed.
I wonder why Locus is not capable producing reliable elevation values when Komoot does?
Firstly, it is quite strange that one needs to call elevation update manually, in order to get a better (but still wrong) result.
Secondly, why providing SRTM data, when these are known to yield systematically wrong elevation values?
As far as I remember, Sunny stated that Komoot uses his Lidar based data. What hinders Locus to do so likewise? Is this a matter of money?
At least the topic was now re-opened. Thanks Zdeněk!
@Zdeněk: How about adding the option to override elevation data from external routers and use local internal data instead? The elevation data from brouter is really not usable. Every time planning a route, I need to update elevation afterwards to correct it, which is very annoying. Especially for hiking and mountain biking, it is very useful to have correct elevation data already during planning, which is currently not possible because during planning, the highly inaccurate elevation data from local brouter is displayed.
At least the topic was now re-opened. Thanks Zdeněk!
@Zdeněk: How about adding the option to override elevation data from external routers and use local internal data instead? The elevation data from brouter is really not usable. Every time planning a route, I need to update elevation afterwards to correct it, which is very annoying. Especially for hiking and mountain biking, it is very useful to have correct elevation data already during planning, which is currently not possible because during planning, the highly inaccurate elevation data from local brouter is displayed.
Hi guys,
sorry for the "closed" topic. Probably incorrect communication on our side.
I'll try to bring some light here.
This idea opens two problems:
1. Compute of elevation (algorithm used for computing)
The algorithm has changed a few months ago and after some fine-tuning, I believe that in the Android app, it now works correctly. How to test if values are optimal? Please use more precise 1'' data from Sonny for offline elevation and use the "Update elevation" method in the Android app. If you will be satisfied with the results? Perfect!
The same algorithm will be, during next months, added to the web portal and into the new iOS app.
2. Quality of elevation data
Currently, data generated for our (online/offline) LoRouter use 3'' SRTM data. That's why I suggested testing "Update elevation" with 1'' data in the previous post. This will also change, hopefully in September and data generated by the LoRouter will use more precise data for the whole world. So computed routes will benefit from this.
---
Feel free to ask if something is not clear!
Hi guys,
sorry for the "closed" topic. Probably incorrect communication on our side.
I'll try to bring some light here.
This idea opens two problems:
1. Compute of elevation (algorithm used for computing)
The algorithm has changed a few months ago and after some fine-tuning, I believe that in the Android app, it now works correctly. How to test if values are optimal? Please use more precise 1'' data from Sonny for offline elevation and use the "Update elevation" method in the Android app. If you will be satisfied with the results? Perfect!
The same algorithm will be, during next months, added to the web portal and into the new iOS app.
2. Quality of elevation data
Currently, data generated for our (online/offline) LoRouter use 3'' SRTM data. That's why I suggested testing "Update elevation" with 1'' data in the previous post. This will also change, hopefully in September and data generated by the LoRouter will use more precise data for the whole world. So computed routes will benefit from this.
---
Feel free to ask if something is not clear!
Menion, Thanks for your statement!
Both points are correct and acceptable. But not for the main issue of this thread which isn't treated or solved yet: The totaly wrong elevation sums using "Route planer" in Locus Android Apps - ALTOUGH having precise 1"-Sonny elevation data installed. I'll explain it using a typical test case:
1a) Download Sonny 1" Austrian elevation files from https://bit.ly/dtm-austria-1s-v2
1b) Decompress them and put it in Locus' "SRTM"-folder
2) Dowload GPX-track of Mathias from https://help.locusmap.eu/topic/32125-wrong-elevation-in-route-planner#comment-129807
3a) Import it in Locus with "Update elevation" OFF => Open the "STATISTICS"-tab of imported track: elevation sums: -248/+1077m (=completely wrong, cause based on SRTM-data)
3b) Within the opened track click on "^" on the botttom > "More" > "Update elevation". Now the track is updated with precise Sonny elevation data => elevation sums: -6m/+844m. THIS are the correct values which a route planner should deliver!
4) Use Locus app "Route planner": Using the imported track of 3a) as background, create a new identical track by clicking point by point within "Route planer".
Now the core problem discussed in this thread: After adding the last point locus Route planer tells: -293m/+1122m => completely wrong elevation sums (+1122 instead of +844m) ALTHOUGH Sonny 1" elevation values installed. Also after saving this track, the wrong elevation values aren't recalculated.
Ideally there should be an on-the-fly replacement of the wrong elevation values delivered by the router-engine (like BRouter) with the precise elevation values of Locus' "SRTM"-folder already during the use of Route planer. But at minimum during saving the track.
This has been working in the past, and has been a great advantage over other online Track-planers or offline track planers of competition apps.
A click onto "Update elevation" AFTER the planned track has been saved is way to late! Most users trust on the elevation sums (and min- max values) during drawing the track within Route planer - and on the track statitistics after it has been saved! Additional using "Update elevation" after the planed track has been saved is a nice feature, but found and used just by "experts"!
Menion, Thanks for your statement!
Both points are correct and acceptable. But not for the main issue of this thread which isn't treated or solved yet: The totaly wrong elevation sums using "Route planer" in Locus Android Apps - ALTOUGH having precise 1"-Sonny elevation data installed. I'll explain it using a typical test case:
1a) Download Sonny 1" Austrian elevation files from https://bit.ly/dtm-austria-1s-v2
1b) Decompress them and put it in Locus' "SRTM"-folder
2) Dowload GPX-track of Mathias from https://help.locusmap.eu/topic/32125-wrong-elevation-in-route-planner#comment-129807
3a) Import it in Locus with "Update elevation" OFF => Open the "STATISTICS"-tab of imported track: elevation sums: -248/+1077m (=completely wrong, cause based on SRTM-data)
3b) Within the opened track click on "^" on the botttom > "More" > "Update elevation". Now the track is updated with precise Sonny elevation data => elevation sums: -6m/+844m. THIS are the correct values which a route planner should deliver!
4) Use Locus app "Route planner": Using the imported track of 3a) as background, create a new identical track by clicking point by point within "Route planer".
Now the core problem discussed in this thread: After adding the last point locus Route planer tells: -293m/+1122m => completely wrong elevation sums (+1122 instead of +844m) ALTHOUGH Sonny 1" elevation values installed. Also after saving this track, the wrong elevation values aren't recalculated.
Ideally there should be an on-the-fly replacement of the wrong elevation values delivered by the router-engine (like BRouter) with the precise elevation values of Locus' "SRTM"-folder already during the use of Route planer. But at minimum during saving the track.
This has been working in the past, and has been a great advantage over other online Track-planers or offline track planers of competition apps.
A click onto "Update elevation" AFTER the planned track has been saved is way to late! Most users trust on the elevation sums (and min- max values) during drawing the track within Route planer - and on the track statitistics after it has been saved! Additional using "Update elevation" after the planed track has been saved is a nice feature, but found and used just by "experts"!
Thank you Sonny for clarifying the purpose of my original post. This is exactly my point. Locus with Sonny data was working perfectly for years, but this changed recently. I just want it to work as before this update.
Thank you Sonny for clarifying the purpose of my original post. This is exactly my point. Locus with Sonny data was working perfectly for years, but this changed recently. I just want it to work as before this update.
If using GraphHopper instead of BRouter in LM3, the resulting elevations are much more accurate - but Locus don't seem to use the Elevation files of its "SRTM"-folder on-the-fly here as well. Because after applying "Update elevation" on the saved track, its values also got changed as with BRouter.
If using GraphHopper instead of BRouter in LM3, the resulting elevations are much more accurate - but Locus don't seem to use the Elevation files of its "SRTM"-folder on-the-fly here as well. Because after applying "Update elevation" on the saved track, its values also got changed as with BRouter.
I created a test-series using Route planner of latest LM3 and LM4 at Oct. 25th 2023 on the test-track:
a) Locus Online Web Planer: +853 m | -11m => very good
b) LM4:
*) LoRouter online: +853m | -11m=> very good
*) GraphHopper online: +0m | -0m (independend if .hgt files within Locus' "SRTM" folder present or not) => no values
*) BRouter offline: +1121m | -293m (independend if .hgt files within Locus' "SRTM" folder present or not) => quite false values
- (No usage of "update elevation" AFTERWARDS possible in Free version)
c) LM3:
*) GraphHopper online: +838m | -0m (.hgt files within Locus' "SRTM" folder present) => good, but not acccurate (interesting why these values are different from usage of "update elevation", they should be identical)
+0m / -0m (.hgt files within Locus' "SRTM" folder not present) => no values
*) BRouter offline: +1122m | -293m (independend if .hgt files within Locus' "SRTM" folder present or not) => quite false values
- Usage of "update elevation" on the tracks AFTERWARDS using Sonny 1" elevation files: -10m / +852m => ideal values
I created a test-series using Route planner of latest LM3 and LM4 at Oct. 25th 2023 on the test-track:
a) Locus Online Web Planer: +853 m | -11m => very good
b) LM4:
*) LoRouter online: +853m | -11m=> very good
*) GraphHopper online: +0m | -0m (independend if .hgt files within Locus' "SRTM" folder present or not) => no values
*) BRouter offline: +1121m | -293m (independend if .hgt files within Locus' "SRTM" folder present or not) => quite false values
- (No usage of "update elevation" AFTERWARDS possible in Free version)
c) LM3:
*) GraphHopper online: +838m | -0m (.hgt files within Locus' "SRTM" folder present) => good, but not acccurate (interesting why these values are different from usage of "update elevation", they should be identical)
+0m / -0m (.hgt files within Locus' "SRTM" folder not present) => no values
*) BRouter offline: +1122m | -293m (independend if .hgt files within Locus' "SRTM" folder present or not) => quite false values
- Usage of "update elevation" on the tracks AFTERWARDS using Sonny 1" elevation files: -10m / +852m => ideal values
Hi guys,
changes to the next Locus Map 4 AND Locus Classic version
To your question Sonny: LoRouter (+ LoMaps) now contains Sonny 1" data where available + 3" data in some smaller areas around the world.
Hi guys,
changes to the next Locus Map 4 AND Locus Classic version
To your question Sonny: LoRouter (+ LoMaps) now contains Sonny 1" data where available + 3" data in some smaller areas around the world.
Thanks Menion, sounds very good! I'm curious to test the improvements soon :-)
Thanks Menion, sounds very good! I'm curious to test the improvements soon :-)
Hi Menion, I downloaded latest beta-version LM v4.19.0.12 (no latest LM v3 Beta-version available), but using external BRouter still calculates the wrong values - during planing as well as after saving the route. Also GraphHopper online still +0m | -0m in both cases
Hi Menion, I downloaded latest beta-version LM v4.19.0.12 (no latest LM v3 Beta-version available), but using external BRouter still calculates the wrong values - during planing as well as after saving the route. Also GraphHopper online still +0m | -0m in both cases
Hi Menion. I just tested the new LM3 version from yesterday, but the behaviour didn't change. I am planning a route using brouter and it shows 1122m elevation gain. Then I trigger the "update elevation" and it corrects to 851m elevation gain. So it obviously does not use the local elevation files in the first place.
Hi Menion. I just tested the new LM3 version from yesterday, but the behaviour didn't change. I am planning a route using brouter and it shows 1122m elevation gain. Then I trigger the "update elevation" and it corrects to 851m elevation gain. So it obviously does not use the local elevation files in the first place.
Fixed for Brouter now with yesterday's new version (3.70.4 i think). Thank you!
Fixed for Brouter now with yesterday's new version (3.70.4 i think). Thank you!
Yes, that's my impession, too.
I love the revised routing function and fast and shiny start of Locus.
Thank you.
Merry Christmas and a Happy New Year to all of you!
Yes, that's my impession, too.
I love the revised routing function and fast and shiny start of Locus.
Thank you.
Merry Christmas and a Happy New Year to all of you!
Yes finally working correct again, thanks! :-)
Yes finally working correct again, thanks! :-)
Hi guys,
glad to read that all seems to be set up correctly ... finally :). Thanks for your patience.
Hi guys,
glad to read that all seems to be set up correctly ... finally :). Thanks for your patience.
Replies have been locked on this page!