So I am building this using the OpenRouteService Routing Engine, but since that is based off of Graphhopper (and more importantly) the issue is mainly regarding concepts and OpenStreetMaps best practices - rather than technical issues. So more advice than technical assistance…
So I’ve outlined the context of my question in this short video. All of my data layers are derived from OSM data, and all roads have associated OSMIDs.
**My Main questions - First, since custom weighting files (at least for ORS) depend on OSM Way IDs, the shorter the road segment, the more precise/granular you can make your custom weighting file. Is this okay (?) - Splitting roads into smaller segments to improve routing for routing engines?
That way, I can setup a cycling/walking profile that actually takes advantage of those crossings. I’ll split the road segment that are proximal to those crosswalks, and generate a new OSM IDs for that segment. Those OSM IDs can go into my weighting file.
According to this source and this source, it seems like this would be okay with the community, but I just wanted to ask explicitly and see what others thought.
In all honestly, I’m not sure if even I’m convinced. I feel like I do need to apply a OSM tag or some content to these roadways to justify the split. Otherwise there is nothing to stop another developer from just merging those roadways back together.
Curious for feedback. Thanks in advance! And please watch the video I made for a specific example.
Impressive demo, thanks! But probably as your question is about ORS it should be asked there (?) Especially since they use an outdated GraphHopper version and we only support the most recent one.
Mapping crosswalks to edge ids should be possible with GraphHopper without the mentioned drawback, but we currently do not support this.
I’ll split the road segment that are proximal to those crosswalks, and generate a new OSM IDs for that segment. Those OSM IDs can go into my weighting file.
We recommend to never tag for the router. I’m pretty sure there are better solutions inside the routing engine alone.
I just saw your video. I think the first thing you should know is that GraphHopper creates an edge for every road segment. A road segment is a piece of a road between two junctions and a ‘junction’ is defined as a point where OSM ways are crossing. Every such edge has a unique ID (which has nothing to do with the OSM Way ID) and in principle there is no problem to assign a specific weight to each of these edges. The question is just how do you recognize the edges you want to change the weight for? I assume every segment that was created from the same (OSM ID) way has the same tags on it?
For your ‘third/last’ question. If all your ‘high stress’ roads have some specific tags increasing their weight should also be straight forward and this is actually one thing that will become very easy to do (without much coding) starting with soon to be released GraphHopper 1.0
I assume every segment that was created from the same (OSM ID) way has the same tags on it?
Yes, that’s correct. There is no additional tag I in OSM guidelines that would make a reasonable excuse to split the segments to my needed lengths in the video.
Every such edge has a unique ID (which has nothing to do with the OSM Way ID) and in principle there is no problem to assign a specific weight to each of these edges. The question is just how do you recognize the edges you want to change the weight for?
Ha that seems to be the 10 million dollar question! And if you have any idea, or know of any examples that do this, I’d gladly study them in depth! (I should add I’m surprising novice at programming - all self taught, with a lot of knowledge gaps, so while I get the concepts, without concrete examples it’s difficult for me). That’s part of why I initially went with ORS because because creating a custom weighting profile was as easy as a csv of <osm id>,<weights between 0-1>
Ok, I meant how do you recognize these edges? What makes them different to the others on the same OSM way? For example you were plotting them so you must know how to find them?
First off thank you for your replys @easbar, I’m working on all of this by myself, so even a brief discussion like this is greatly appreciated, (even if we don’t get to the bottom of this in this forum post).
how do you recognize these edges? What makes them different to the others on the same OSM way?
The only thing that makes them different is the they have been extracted as their own shapefile (offline), and geojson (online in the mapbox web-map).
So can I just take the geojson of those ‘crosswalk road’ segments, and somehow input that geojson coordinates geometry in graphhopper… “Hey graphhopper, take this geojson file, and whatever Edge IDs have the same coordinates, weight them stronger 1.5x stronger”?
Unless I’m mistaken, it seems like I can do this in graphhopper based on the custom profile documentation. I’m a little bit lost on the technical process of converting a geojson input file (e.g. the crosswalks roads) into “Edges” that graphhopper can read to weight. Can that be done?
I don’t think that there currently is any kind of support to include external information like that with graphhopper, but of course there should be no real problem doing this. You could take the OSM data and split the ways you want before feeding them to GraphHopper (offline no need to change the ways on openstreetmap.org for this). Or you could first import the OSM data as usual and then afterwards match the GraphHopper edges using the coordinates taken from your shapefile. But either way this takes some programming skills. Are you looking to do this once for a single area or do you need a reliable automated process that does this over and over again?
You could take the OSM data and split the ways you want before feeding them to GraphHopper (offline no need to change the ways on openstreetmap.org for this).
Eureka! Of course! This may show my knowledge gap, but I didn’t make the connection that Graphhopper and these routing engines are building the graphs purely based on the offline pbf file. So of course I can edit that file before building the graphs!
Okay, I really want to understand this part of the workflow. As you stated I can either:
Take the OSM data (the pbf file), open it in JOSM (I assume?), split the necessary way IDs, re-save that file, gather the list of newly split OSM IDs (?), input my weighting file of OSM IDs to weight (?) and build the graphs from there. Conceptually I do understand this, but I feel doing this programmatically does seem challenging.
My other option is processes my OSM Arizona data as usual, open the edge file generated (not sure with what program? it seems like an unreadbale file), and somehow match the coordinates listed in there with the coordinates of my shapefile, and input a stronger cycling weight for those edges… Again I do understand these processes conceptually, but not in practice…
If anyone out there has done this, I’d be really curious about how you would go about these two workflows!
Are you looking to do this once for a single area or do you need a reliable automated process that does this over and over again?
Ideally I’d like to have it an easily reproduced batch process, because I’d imagine each step would take several days to do by hand (there are literally hundreds of crosswalks through my city.)
With that said, I’m going to start researching what I can based on what you recommended @easbar!
For OSM ID mapping there is also this outdated repo: https://github.com/karussell/graphhopper-osm-id-mapping The problem with this approach is that it uses OSM way IDs. This is a dead end and OSM node IDs are the much better choice (especially for your use case where you have probably only the OSM node IDs of the crosswalks). But they are more complicated to integrate in GraphHopper (of course not impossible!). We’ll probably add support for this at some point in the future: https://github.com/graphhopper/graphhopper/issues/917
