Comments (20)
Adding a few examples here.
1: Korsør, Denmark
Ground truth (signs says "driving allowed" and "one way")
Graphhopper maps route
2: Korsør, Denmark
Ground truth (signs says "driving allowed")
Destination is parking spots in Pedestrian zone
3: Slagelse, Denmark (bicycles allowed)
This was remove as it was an issue with a missing tag on the node. (Fixed in open street map data now)
4: Slagelse, Denmark (tricky one, this one)
Ground truth
Signs say (in order):
- Errand driving allowed to church. Cycling allowed.
- goods traffic allowed 0-11
- taxis allowed
- Resident driving allowed
from graphhopper.
So as I understand it, only about a tenth is applicable to a car profile
Yes, this way the number of additional edges would be reduced, but really the overall number of pedestrian edges will be small compared to the rest either way (less than 1% of all OSM highways are pedestrian).
The first place where OSM ways are filtered is in OSMParsers.java#acceptWay. Everything that passes here will produces some edges. If we wanted to apply the optimization you have in mind it would be here, but like I said maybe that's not even necessary.
We then need to make sure that in CarAccessParser.java#handleWayTags the access of these edges is false unless there is some tag like vehicle=car.
from graphhopper.
Shouldn't this rather be tagged as living_street
?
from graphhopper.
The translation of Gågade zone
is literally pedestrian zone
: https://www.deepl.com/translator#da/en/g%C3%A5gade%20zone
It's even listed in the OSM tagging examples(last one): https://wiki.openstreetmap.org/wiki/Tag:highway=pedestrian?uselang=en
from graphhopper.
Seems to be pretty common: https://overpass-turbo.eu/s/1BFa
from graphhopper.
Maybe exclude area=yes
, but it's true there seem to be quite a few pedestrian highways using vehicle=yes
(https://overpass-turbo.eu/s/1BFq)
from graphhopper.
And a bit more if we also take different values like destination
into account: https://overpass-turbo.eu/s/1BFr
from graphhopper.
This has also implications for bike routing. If cyclists are explicitly allowed to enter, we shouldn't treat it as a pushing section.
from graphhopper.
I wouldn't mind giving this a shot as my first contribution.
Any pointers for me where to start?
Leaving a links here with info about the specific tags:
from graphhopper.
It would be nice to see a few more real-world examples where accepting the pedestrian roads is necessary. I know the overpass query returns lots of ways with this tag combination, but looking for some actual examples where this is an issue would make it clear that we really need to change this and we do not break more cases than we fix.
Once this is clear it should be a matter of leaving out pedestrian
from import.osm.ignored_highways
(it is currently included in config-example.yml
and also in the hosted car profile) (this will impact the performance of the OSM import as well as the resulting graph size) and adding pedestrian
to highwayValues
in CarAccessParser.java
(and possibly a few other access parsers).
from graphhopper.
Ok.
I can dig up some more examples from Denmark. It is a pretty common thing here to have pedestrian areas that allows vehicles - also for drive throughs.
Normally it isn't an issue I guess, because driving around is often more optimal because of the low max speed.
But for deliveries in the pedestrian zone and drive throughs to reach an "island", it is difficult to do without.
from graphhopper.
It is a pretty common thing here to have pedestrian areas that allows vehicles - also for drive throughs.
Are they allowed to drive through for anyone or only for delivery vehicles and such?
and drive throughs to reach an "island", it is difficult to do without.
Yes, of course excluding an entire island because of such a pedestrian road is bad.
from graphhopper.
It would be nice to see a few more real-world examples where accepting the pedestrian roads is necessary.
Here's an example from the OSM wiki:
"Gågade" Pedestrian street with "Kørsel tilladt" vehicles allowed. Driving is allowed here, but (tourist)pedestrians are prioritized higher, so motorists basically can't expect to move faster than the pedestrian in front of them.
from graphhopper.
This has also implications for bike routing. If cyclists are explicitly allowed to enter, we shouldn't treat it as a pushing section.
What do you mean by "pushing section"? To me it seems that it works for bikes when they are allowed in pedestrian zones.
from graphhopper.
Seems like we handle this case already properly for bike routing:
highway=pedestrian
+bicycle=yes
: https://www.openstreetmap.org/way/333794059 -> driving allowedhighway=pedestrian
: https://www.openstreetmap.org/way/10710648#map=19/55.40315/11.35446 -> pushing section
from graphhopper.
Oh. Literally a section for pushing bicycles. 😀 I thought pushing section was a technical term in Gaphhopper I didn't know of. I get it now.
from graphhopper.
this will impact the performance of the OSM import as well as the resulting graph size
Would it make any sense to introduce a tag filter (if none exists already), allowing fx. the car profile to include pedestrian only if it also has specific tags?
from graphhopper.
Yes, we need to allow highway=pedestrian for car only if it is explicitly allowed by other tags. The import performance is probably not too critical since there aren't so many ways tagged as highway=pedestrian
overall.
from graphhopper.
Okay. What I meant was filtering by tags already during the import process to only process a minimum highway=pedestrian
.
I tried to se the difference in nodes/ways for with and without a filter on tags with a bbox just for Denmark.
way["highway"="pedestrian"][~"^(vehicle|motor_vehicle|motorcar)$"~"^(yes|destination)$"]["area"!~"yes"]({{bbox}});
Nodes: 1424
Ways: 371
way["highway"="pedestrian"]({{bbox}})
Nodes: 20236
Ways: 2898
So as I understand it, only about a tenth is applicable to a car profile (for Denmark at least - but maybe somewhere in the samme ballpark for other parts o the world)
from graphhopper.
@easbar I am gonna take a look at the issue with routing to/through pedestrian streets.
But... Isn't it gonna cause issues in big city centers where routing through pedestrian streets will often be the shortest route?
It is quite common (in Denmark at least) for pedestrian streets to not have a tag for max speed, although common knowledge here is that pedestrians streets have a low advised max speed (15kmh). Some pedestrian streets are =destination which would hinder route through, but not all pedestrian streets has that and it requires correct tagging.
I am afraid that allowing routing through pedestrian streets will cause unwanted routes in many city centers with poor tagging. 🤔
Edit
I see that destination and conditionals for opening-hours are open issues. Together with specific legal_default_speeds for pedestrian I think it will work fine.
I have added a PR for my current progress on this.
#2940
from graphhopper.
Related Issues (20)
- Routing wrong if change edge encoder access at caculate weight edge HOT 2
- opening_hours is ignored for way HOT 5
- Please provide better upgrade instructions between major versions HOT 7
- Route: Legs information empty in Java API
- Isochrone: No buckets when using public transport
- I just finished translating all zh_CN & zh_HK HOT 1
- Default bicycle profile ignoring turn restrictions? HOT 2
- Tags vehicle=no + bicycle:conditional=yes@… should trigger warning instead of failing to route in cycle profiles HOT 3
- Bike priority determination problem for tag combination of `cycleway:left` and `cycleway:right`
- GHUtility's method not found
- LMApproximator overhead HOT 3
- Benchmark stops with PointOutOfBoundsException HOT 5
- make `edges` byte-based
- highway=cycleway + access=no + bicycle=NULL is used for routing HOT 7
- should locked=yes have lower priority? HOT 4
- Default MaxWeight resolution is insufficient for truck routing HOT 11
- bad u-turn on road with turn restriction HOT 4
- correctness vs. speed: astarbi.epsilon
- Snapping to turn restriction via-edges yields bad routes HOT 2
- bike should better avoid primary roads 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 graphhopper.