I am unsure of the correct terminology to use, so please forgive that.
I am rendering OSM data for printed topographic maps. I’d like to indicate the distance between junctions of footways/paths/trails. With the OSM data loaded into Postgresql using osm2pgsql I can get the length of the ways and display that.
However there are two related problems:
Some trails are split into multiple ways in places I don’t care about for accumulating distances (bridges, etc.).
Many through trails are not split at trail junctions so I get the length of the total trail segment, not the distance between junctions.
This is slightly complicated by the fact that while I don’t care about things like bridges for computing distance but I do care about having the ways separate for rendering. For example, trails are rendered one way for the general case and another when on a bridge.
I thought maybe looking at the ways of converting OSM data to something common for routing (nodes and edges) might be helpful but what I found did not seem fit the problem. Obviously this problem has been solved by a number of map renderers and routers, I just don’t see how.
Can someone give me a hint about how this can be done?
Thanks!
edit: Clarified title.
Looks like maybe adding new tables to my Postgresql database using osm2pgrouting and then us the pgrouting library in Postgresql might work but I don’t see an easy to follow tutorial for my specific need.
I’ve always been vaguely interested in doing something similar as this was a standard feature on various motoring paper maps.
Most routing applications allow you to build a distance table, but probably from more distant points. I’ve certainly used pgrouting to calculate distances between towns in Northern Ireland (a relatively small data set), but I’m not sure I know how to keep the results just for immediately adjacent nodes in the network.
You’ll need some way of finding all the path junctions which you will use as routing nodes.
I’ve also called pgrouting iteratively with a stored procedure with pairs of nodes of generate routes, but it appears to leak memory when doing this.
One other thing I’ve noticed with pgrouting is that the cost returned sometimes doesn’t seem to relate to the input measure (I presume cost should be distance in your case) with some functions.
Either way I think pgrouting is a good place to start and ought to produce good enough results to begin with.
No if this can help:
The program mkgmap has to calculate arcs between (highway) junctions nodes together with their length and further information about bearings and restrictons. Style rules are used to classify the importance of these arcs. The Garmin routing algo uses this information to compute the routing.
I have added tables generated by osm2pgrouting to my Postgresql database with options set so only what I consider hiking trails (highway=path but also highway=track, motor_vehicle=no, foot=yes or designated) are processed. osm2pgrouting script ends up creating two tables of interest to me: route_ways_vertices_pgr which I use for marking the intersections the distances are between and route_ways that I use for displaying the distances. The ways are not exactly the same as the original OSM ways as they are split on each intersection. Turns out that both of the tables have fields with the geometry so putting the distance text and intersection markers on the map are trivial. And the route_ways table has a field giving the way length in meters so the conversion to distance text is trivial.
All this gets me pretty close to what I want. And, looking at some other maps that display hiking distances based on OSM data is what I suspect the others do. If they are doing things differently, they have arrived at identical functionality.
But there are some issues that I haven’t yet addressed. For example, if a trail crosses a highway I’d like to treat that the same as I would for two trails intersecting (i.e. place a marker at the intersection and show distance on the trail from the road crossing). For osm2pgrouting to split the hiking trail at those points I’d need to have it also process all highways. But then I’d need a little smarter logic to know which ways in the resulting database should have their distance displayed.
Second problem: A trail may be split by the mapper for any number of valid reasons (crosses a bridge, change in surface, change in SAC scale, etc.) but I would rather show the distance between intersections only. To do that I think I’ll need to add logic to merge ways in the database if a number of conditions are met.
But those are exercises for the future. At present I figure I’ve 90% of what I want with the remaining 10% requiring far more thought and effort than what I’ve done so far.