Routing Engines Such as OpenRouteService and Graphhopper, allow for custom weighting profiles to influence their default algorithms. The inputs for these weighting profiles are usually csv files. They are a simple list of OSM Way IDs and an associated weight, separated by comma. So obviously, as you can imagine the shorter each road segment is divided, the more accurate you can setup weighting profiles for routing engines.
My question: So is it okay for me to split Way IDs of roads? I mean all the appropriate tags are are preserved so it doesn’t affect the overall map quality? I am mainly interested in splitting a roads along traffic-signal controlled pedestrian crossing, as seen here , and are represented on OSM here.
That way, I can setup a cycling profile that appropriately weights those newly created OSM IDs, so that routing engines can take advantage of those segments.
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.
PS. And no, there doesn’t seem to be a way specifically use the footpaths like these directly in the the various Routing Engines
It’s OK to split a road when the attributes change, or when only part of the road belongs to a route (bus, hiking, cycling). I doubt there is a consensus to split a road because of 1 navigation tool. The tool an split any road into smaller segments if that is better for their algorithm. They will already split a road automatically on each junction in order to make a turn, not?
I also wonder why you think that smaller segments would mean better accuracy. I would assume that long and shorts segments with the same characteristics already get different weight because of their different length.
I agree. OSM ways should not be split for this reason. In general this just adds complexity like more relation members. Also othe mappers might be tempted to merge the ways again “because they were split for no reason”. I’ve just commented an old JOSM ticket regarding this, see https://josm.openstreetmap.de/ticket/3495
I do see your point. Is there additional tags or data that I could input into those segments that you feel would justify the split?
Its not better accuracy. It would allow for better routing for cycling and walking profiles in open source routing engines such as Graphhopper and Open Route Service. I would suggest watching the brief video I made to get a better sense of the problem. But as I stated (and perhaps not clearly enough) - signaled pedestrian crosswalks with appropriate tags such as this on the map, and look like this in person; these crosswalks are digitized seperately from the road. They are tagged
highway=crossing , crossing=traffic_signals
. But if the proximal road segment is split, and tagged, then they will have their own OSM ID, and fundimentally Open Source Routers such as OpenRouteService would be able to use that OSM ID and segment in its weighting algorithm. **I.e. when it is calculating a cycling route that needs to cross the street, it will do so where there is a crosswalk!
**
Currently the given Way IDs for some of these roads in this neighborhood stretches like ~1/2 mile several street blocks, there is no way to weight those specific bicycle friendly segments…
I do understand your reasoning for this, truly - With that said is there anything I can appropriate tag by OSM standards on those crosswalk roads to justify the split? I mean if we are thinking about this not in terms of mapping perse, but in terms of building the most robust open source routing network. By that logic it would seem reasonable to have the road segment tagged with the appropriate crossing tag, since those are the roads network which the crossing occurs at.
Simple answer: making alterations to solely improve your routing algorithm is not any more acceptable than changing things to make them appear in the renderer.
Longer answer: AFAIK state of the art cycle routing engines (cycle.travel, CycleStreets etc.) do not need to do this. For a generic router capable of working across a whole country or continent it is simply not practical to massage the OSM data to improve routes. Instead effort should be directed at improving your data processing or routing software & algorithms. There is ample scope for post-processing OSM data, for instance to cut (or merge) underlying ways if that helps routing. For instance, I know that Richard Fairhurst makes extensive use of LUA processing for cycle.travel, which uses (a heavily customised version of) OSRM.
It is not necessary (and indeed, it’s not ok) to split ways in this context.
It’s perfectly possible for a bike router to favour crossing a road where there’s a marked crossing. cycle.travel (which as SK53 says, uses a fork of OSRM) already does that. There’s no need to split the ways.
If OpenRouteService or any other router can’t do that, then you should submit a feature request to the router authors, not needlessly complicate the data to make up for its omissions.
A counter-argument to splitting ways for one client is that it produces worse results in other clients, eg renderers. You would see duplicate labels in close proximity where just one would be enough. This would likely cause another mapper to undo your work.
Okay, I’m convinced. I’ll look for another solution. So graphhopper Routing Engine takes OSM Road Network and converts it to individual Edges each with a Unique ID, those edges are defined everywhere two OSM Ways intersect at a node. If anyone on this forum is familiar with taking a geojson input file and weighting it in the Graphhopper Edge ID network, I’d really appreciate a technical walkthough.
Not sure if one is out there, but yea, figured id ask =]
I don’t know if it is the equivalent of what Kaart is doing in my country. Splitting a highway into so many segments in order to do the turn lanes thing.
I understand and actually see the merit of lane assist in big city motorways that criss cross and merge, but when taken to smaller towns it seemed like way overkill. In those situations you can see a right turn coming from a distance and know that there’s probably a merging lane to turn into without needing navigation app help. A kilometer main highway through town would be cut and minced into pieces just to model the turn assist thing.
Probably in the wrong comment section, but anyways…
