Comments (12)
@ppete2
This data is available in the Json export. Sample:
["13789746", "47830291", "453", "267", "0", "0", "0", "0", "0", "reversedirection=yes highway=primary surface=asphalt maxspeed=70 lit=yes lanes=2 foot=no bicycle=no tunnel=yes", "", "122", "88808"],
from brouter.
I was wondering what has BRouter to do with brides in context of tunnels, until bridges came on mind..... :-D
from brouter.
Is it ok when I use this data on BRouter-Web?
I'll take a look at it one day.
from brouter.
Without via point on the tunnel segment:
With via point on the tunnel segment:
from brouter.
Inside the tunnel is no elevation data available- as shown above.
But when you look into our way data the points are present
<wpt lon="13.786779" lat="47.831624"><ele>476.25</ele></wpt>
<wpt lon="13.790937" lat="47.829418"><ele>447.25</ele></wpt>
And will be used when having a route starting/ending outside.
The data is different than announced in Locus forum - both portals are at an altitude of about 430 m
and differs to DEM data at GPX Visualizer (455m and 441m)
As you see on the BErouter-web link the contour line forms a plateau when driving in a tunnel and is not moving to mountain level - as shown in the locus forum.
from brouter.
Well, I think I have to clear some things:
1.)
Within Locus we can use custom elevation-files which are much more accurate than those used by GPX Visualizer, BRouter and BRouter-webs'map "OpenTopoMap": namely Austria 1" from https://sonny.4lima.de/
Using this accurate elevation file, there's no elevation difference betwen both tunnel portals. And this is correct - I know the tunnel.
2.)
But also if BRouter is using more unaccurate elevation info, in worst case e.g. "476.25" and "447.25": The elevation line between both portals should be linear - this usually works correct! But for some reason not in this case: if you look at the elevation line within the Locus forum. The line is clearly is following the elevation of the terrain outside the tunnel, peaking at an elevation of ca. 510 m.
3.)
I'm not sure if I got you right when you're writing: "the contour line forms a plateau when driving in a tunnel and is not moving to mountain level"
For calculating elevations WITHIN a tunnel these contour lines are unimportant, because they just telle the eelvation of the the terrain ABOVE the tunnel - which can be hunderds of meters higher than the elevation of the street within the tunnel.
4.)
In the example of BRouter-Web by quaelnix: Why the ascends of both versions differs (29m vs. 0m) ? Both are identical routes with the same start and end-points.
from brouter.
1
fine to hear this about the quality. We are on the way to use this source as well. But it will take its time.
2
line between both portals should be linear
I would agree that. Next BRouter library has this feature.
3
forms a plateau
means the entry and exit point on a road are often a little bit higher up as street level cause of the interpolation for the points but from entry to exit point we have a line (see 2) and not the terrain ABOVE
.
from brouter.
I think BRouter-Web is doing the right thing here, because if you look at the elevation diagram, it's just a linear rise between the 2 tunnel portals - ok!
But not Locus, because it start with 430 m at one portal, goes up to 510 m somewhere WITHIN the tunnel and falls down to 430 m at the other portal. If I remove the custom Sonny-elevation files of Locus, Locus is likely to use BRouters internal elevation data. In this case I also receive a correct ramp like with BRouter-Web. So in my opinion if there are custom elevation files used within Locus, Locus is using them (ok!) but ignores the info of Brouter that parts of the route are crossing a tunnel and Locus shouldn't use custom elevation data WITHIN the tunnel.
Another case where the opposite is true is the tunnel at location N 47.7761°, E 14.4869°
If I use Locus Route planner here (profile: bicycle) even with custom elevation data, Locus respects the tunnel, nomore elevation peak within the tunnel. So why is Locus treating both cases different? Is it because one time I used car-profile, one time bicycle profile? And most important: Is this bug caused by BRouter or by Locus?
from brouter.
Why the ascends of both versions differs (29m vs. 0m) ?
This is due to a bug in BRouter v1.6.3 (the version currently used on brouter.de), which has been fixed in BRouter v.1.7.0 (see: #498). However, the via points still affect the elevation output displayed in BRouter-Web (since BRouter-Web concatenates the results of individual routing requests between consecutive pairs of via points).
BRouter v1.6.3:
curl -s "https://brouter.de/brouter?lonlats=13.790931,47.829405|13.788186,47.830969|13.786767,47.831625&profile=car-eco&alternativeidx=0&format=gpx" | grep "filtered ascend = "
<!-- track-length = 410 filtered ascend = 0 plain-ascend = 0 cost=900 energy=.0kwh time=1m -->
BRouter v1.7.0:
curl -s "localhost:17777/brouter?lonlats=13.790931,47.829405|13.788186,47.830969|13.786767,47.831625&profile=car-eco&alternativeidx=0&format=gpx" | grep "filtered ascend = "
<!-- track-length = 406 filtered ascend = 22 plain-ascend = 22 cost=886 energy=.0kwh time=59s -->
Is this bug caused by BRouter or by Locus?
To me it sounds like a bug in Locus, but I cannot tell for sure.
from brouter.
@ppete2
If you use Locus elevation data there is nothing BRouter can do.
The better elevation data from Locus don't know about tunnels or bridges, so the terrain above or below is used. In the other example the tunnel is one line and the elevation is fetched by Locus only for start and end of each segment, so it is just luck.
from brouter.
I think you're right! Locus is inserting its own elevation data into each OSM point of the created route.
The important question is: is there an option of BRouter which tells 3rd party apps like locus from where to where a route crosses a tunnel or bridge? In this case 3rd party apps could insert a linear elevation line between both tunnel portals instead of summing up the elevation of each OSM-point within the tunnel, done by Locus right now.
from brouter.
This data is available in the Json export.
Only if the profile used evaluates the tunnel tag or enables processUnusedTags
, which is not the case with the car profiles:
curl -s "https://brouter.de/brouter?lonlats=13.790931,47.829405|13.788186,47.830969|13.786767,47.831625&profile=car-eco&alternativeidx=0&format=geojson"
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": {
"creator": "BRouter-1.6.3",
"name": "brouter_car-eco_0",
"track-length": "410",
"filtered ascend": "0",
"plain-ascend": "0",
"total-time": "60",
"total-energy": "146459",
"cost": "900",
"messages": [
["Longitude", "Latitude", "Elevation", "Distance", "CostPerKm", "ElevCost", "TurnCost", "NodeCost", "InitialCost", "WayTags", "NodeTags", "Time", "Energy"],
["13789746", "47830291", "447", "140", "1708", "0", "0", "0", "0", "highway=primary surface=asphalt maxspeed=50", "", "23", "53465"],
["13786684", "47831699", "475", "270", "2816", "0", "0", "0", "0", "highway=primary surface=asphalt maxspeed=70", "", "60", "146460"]
],
"times": [0,1.711,9.548,14.476,16.681,23.167,34.049,51.933,56.339,60.088,60.186]
},
"geometry": {
"type": "LineString",
"coordinates": [
[13.790941, 47.829407, 447.0],
[13.790937, 47.829418, 447.25],
[13.790806, 47.829671, 447.25],
[13.790557, 47.829889, 447.25],
[13.790407, 47.829992, 447.25],
[13.789746, 47.830291, 447.25],
[13.788182, 47.830965, 447.25],
[13.787503, 47.831258],
[13.787117, 47.831418],
[13.786779, 47.831624, 476.25],
[13.786773, 47.831628, 475.75]
]
}
}
]
}
from brouter.
Related Issues (20)
- Support for node-tags in lookups.dat HOT 8
- "bicycle:backward=no" is not considered HOT 1
- Generating segments by process_pbf_planet.sh fails HOT 5
- Distinguish between villages/towns and country HOT 11
- Problem building from Dockerfile HOT 4
- Brouter Java error HOT 7
- The least cost route is not being used HOT 3
- Make timestamp format in server log to ISO8601 compatible HOT 1
- RFC: Improvement to Logging HOT 3
- Using segment cost instead of distance when processing bicycle kinematic model. HOT 22
- Success message on routing HOT 4
- bug with brouter.damsy HOT 1
- Cycling overlay doesn't work HOT 4
- Problem with communication between BRouter lib 1.7.5 and BRouter-web
- Car Profiles Not Working v1.7.5 HOT 7
- Adding waypoints beyond 9 HOT 1
- Feature Request: Implementation of Altitude Parameters for Route Calculation
- Update in F-Droid? HOT 6
- `Stick to cycleroute` does not minimize the non-bike-lane path HOT 9
- Add Panoramax Optional Coverage Layer HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from brouter.