Comments (14)
Also, I notice that ORS returns the duration time around 3-4 minutes, while OSRM and Google Maps return 7-8 minutes, both use driving car.
http://router.project-osrm.org/route/v1/driving/13.392786,52.524078;13.411185,52.521321
from openrouteservice.
Regarding the duration times, I am not sure what OSRM and Google Maps use as average speeds for different function classes of segments (edges). You can check the limits we use here:
from openrouteservice.
In terms of the distances, I compared your geojson output with the output generated by openrouteservice.org and I can see that the snapped destination point is behind bahnhof Alexanderplatz which results in a different route. This could have to do with changes of the underlying graph structure which might have been changed by OpenStreetMap users.
from openrouteservice.
Thank you for your explanation about the routing distance.
I checked your car profile and the max speed for Germany is only 130 km/h, while OSRM produces 1.7km in 0:03, which results in 340 km/h. Can you check again?
from openrouteservice.
The speeds you have to check are
"motorway_link": 60,
"motorroad": 90,
"trunk": 85,
"trunk_link": 60,
"primary": 65,
"primary_link": 50,
"secondary": 60,
"secondary_link": 50,
"tertiary": 50,
"tertiary_link": 40,
"unclassified": 30,
"residential": 30,
"living_street": 10,
"service": 20,
"road": 20,
"track": 15
Depending on the OSM street attribute types of the segments the algorithm traverses it will use different speeds.
from openrouteservice.
I checked all the values, the maximum values I can find are still less than 150, not even close to 300 km/h in the result.
from openrouteservice.
@nguyen-dinh-dh this is definitely a bug, we will fix by the end of next week - thanks for pointing this out!
from openrouteservice.
@TimMcCauley Thank you for your quick reply :)
from openrouteservice.
@nguyen-dinh-dh I just double checked and with regards to the speed at 340km/h, I believe this is a misunderstanding with regards to the units shown on the website (I presume that when you say OSRM you mean the OpenRouteService page). The 00:03 does not mean 3 seconds, but 3 minutes (the numbers are rounded to the nearest minute). Taking that into account, traveling 1.7km in 3 minutes results in a speed of ~0.6km/min which equates to 36km/h.
For the other time differences between ORS and Google (the 3-4min in ORS and 7-8min in Google), this is due to Google taking into account more factors with regards to driving within urban areas. In ORS, it is currently assumed that you travel close to the speed limit of 30km/h whereas Google appears to indicate travel closer to half the speed limit. We are currently looking into implementing an additional step in our speed calculations that will hopefully provide a bit more realistic results within urban areas.
Hope that covers things :)
from openrouteservice.
My bad, thank you for your explanation :)
from openrouteservice.
@rabidllama As far as I know, ORS is using a forked version of graphhopper for routing, however when I use graphhopper:
https://graphhopper.com/maps/?point=52.524078%2C13.392786&point=52.521321%2C13.411185&locale=en-US&vehicle=car&weighting=fastest&elevation=true&use_miles=false&layer=Omniscale
It returns duration of 6 min (similar to OSRM and GoogleMaps), while ORS returns 3min. Are there any difference in your graphhopper which causes this problem? Also, does this affect the isochrone service too?
from openrouteservice.
@nguyen-dinh-dh it is a forked but changed version and as mentioned above we use different speed limits. It does effect the isochrone service, yes.
from openrouteservice.
@TimMcCauley I tried modifying the car.json by halving all the speed for testing, but the duration is still around 3min, here is the car.json
{
default:
{
"motorway": 50,
"motorway_link": 30,
"motorroad": 45,
"trunk": 43,
"trunk_link": 30,
"primary": 33,
"primary_link": 25,
"secondary": 30,
"secondary_link": 25,
"tertiary": 25,
"tertiary_link": 20,
"unclassified": 15,
"residential": 15,
"living_street": 5,
"service": 10,
"road": 10,
"track": 8
},
surface:
{
"asphalt": -1,
"concrete": -1,
"concrete:plates": -1,
"concrete:lanes": -1,
"paved": -1,
"cement": 40,
"compacted": 40,
"fine_gravel": 30,
"paving_stones":20,
"metal": 20,
"bricks": 20,
"grass": 20,
"wood": 20,
"sett": 20,
"grass_paver": 15,
"gravel": 15,
"unpaved": 15,
"ground": 15,
"dirt": 15,
"pebblestone": 15,
"tartan": 15,
"cobblestone": 10,
"clay": 10,
"earth": 8,
"stone": 8,
"rocky": 8,
"sand": 8,
"mud": 5,
"unknown" : 15
},
tracktype:
{
"grade1": 20,
"grade2": 15,
"grade3": 10,
"grade4": 8,
"grade5": 5
},
max_speeds: {
"AT:urban": 50,
"AT:rural": 100,
"AT:trunk": 100,
"AT:motorway": 130,
"CH:urban": 50,
"CH:rural": 80,
"CH:trunk": 100,
"CH:motorway": 120,
"CZ:urban": 50,
"CZ:rural": 90,
"CZ:trunk": 80,
"CZ:motorway": 80,
"DK:urban": 50,
"DK:rural": 80,
"DK:motorway": 130,
"DE:living_street": 4,
"DE:urban": 25,
"DE:rural": 50,
"DE:motorway": 65,
"FI:urban": 50,
"FI:rural": 80,
"FI:trunk": 100,
"FI:motorway": 120,
"FR:urban": 50,
"FR:rural": 90,
"FR:trunk": 110,
"FR:motorway": 130,
"GR:urban": 50,
"GR:rural": 90,
"GR:trunk": 110,
"GR:motorway": 130,
"HU:urban": 50,
"HU:rural": 90,
"HU:trunk": 110,
"HU:motorway": 130,
"IT:urban": 50,
"IT:rural": 90,
"IT:trunk": 110,
"IT:motorway": 130,
"JP:national": 60,
"JP:motorway": 100,
"PL:living_street": 20,
"PL:urban": 50,
"PL:rural": 90,
"PL:motorway": 140,
"RO:urban": 50,
"RO:rural": 90,
"RO:trunk": 100,
"RO:motorway": 130,
"RU:living_street": 20,
"RU:rural": 90,
"RU:urban": 60,
"RU:motorway": 110,
"SK:urban": 50,
"SK:rural": 90,
"SK:trunk": 90,
"SK:motorway": 90,
"SI:urban": 50,
"SI:rural": 90,
"SI:trunk": 110,
"SI:motorway": 130,
"ES:urban": 50,
"ES:rural": 90,
"ES:trunk": 100,
"ES:motorway": 120,
"SE:urban": 50,
"SE:rural": 70,
"SE:trunk": 90,
"SE:motorway": 110,
"GB:nsl_single": 95,
"GB:nsl_dual": 112,
"GB:motorway": 112,
"UA:urban": 60,
"UA:rural": 90,
"UA:trunk": 110,
"UA:motorway": 130,
"UZ:living_street": 30,
"UZ:urban": 70,
"UZ:rural": 100,
"UZ:motorway": 110
}
}
from openrouteservice.
@nguyen-dinh-dh The fork we are using in our version is a bit behind that of the main Graphhopper because of the enhancements we have made to our core to allow many of the additional functionalities that we provide. As such it may well be that the reason for difference between ours and the main Graphhopper is something that they have changed in a newer version.
The main reason for difference between ORS and Google (for example) is that when routing through urbanised areas, Google uses complex algorithms to determine the travel speed. In ORS, currently it assumes that you travel close to the allowed speed, hence why there is a difference between speeds (Google appears to indicate that you travel around half of the designated speed limit. We have a fix to make the results more similar to those of other engines, but this is not in the production version yet.
from openrouteservice.
Related Issues (20)
- CVE-2024-22259 org.springframework:spring-web (ors.jar) HOT 1
- Migration info printed even if using yaml HOT 1
- Application startup fails org.yaml.snakeyaml.error.YAMLException: java.io.IOException: Is a directory HOT 2
- Not ready after ten a week of creating graph HOT 7
- Review configuration
- Improve track grade parsing
- Cannot find routable point HOT 1
- Extra Info - Surface returns paved instead of grass HOT 3
- Consider side of road for departure and destination points HOT 1
- Support bicycle=destination for bike profiles HOT 3
- Matrix endpoint returning null for all locations when one route does not exist HOT 4
- Confusing error message in isochrones api
- fix: Fix some CVEs
- Dead link in docs
- Example mentions non-existent way category "Tunnel"
- Unify snapping behaviour across services HOT 1
- Wrong caculation bus
- Ways tagged as `highway=construction` not considered for bike profiles HOT 1
- Driving speeds too fast on single lane roads (highway = primary, lanes = 1). ORS says 12 mins; Google/TomTom/HERE say 20 mins HOT 1
- Missing danish translation
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 openrouteservice.