What do you think about adding new category to details, like bicycle_infra (or something more appropriate) which would return informations if route goes to cycleway or bike lane for example.
Right now, road_class only encodes highway=cycleways but it returns path even if there is a designeted bicycle lane (like here Way: 207501586 | OpenStreetMap).
I’m building website for cyclists and would like to show statistics about routes. Information if route goes through regular roads or dedicated cycling infrastructure is very useful.
Not sure what should be returned if route isn’t going on bicycle infrastrucutre
We could encode road_class to value CYCLEWAY for highway=path or highway=footway with the combination of bicycle=designated.
But for all further details like bicycle.right=lane, opposite_lane or similar I would encode the OSMID and extract the OSM tags via this OSMID reference.
The drawback of this approach is that it requires an extra database, but I don’t think it is a good idea to create separate graphhopper encoded values for all such bicycle related details.
If you fork GH you can easily store this information in the KVStorage and fetch it via the KVStringDetails without much overhead (no extra database required). See how we store data in OSMReader.preprocessWay for e.g. name, motorway_junction etc.
Information if route goes through regular roads or dedicated cycling infrastructure is very useful.
There are certain bike path details already: bike_network, get_off_bike and bike_priority.
but I don’t think it is a good idea to create separate graphhopper encoded values for all such bicycle related details.
There are certain bike path details already: bike_network, get_off_bike and bike_priority.
Which are great but more details would be useful for bicycle apps. For example, I would like to diffrentiate between type of cycleways:
Is it fully spearate track? This is useful for racing bikes that don’t prefer not to share roads with pedestrians. Even if cycleway is segregated from the footway sometimes pedestrians can easily jump into cycleway, especially kids.
Is it bike lane within road itself? Great solution for road cyclists but cyclists with kids inside bike trailers may want to avoid it. I personally don’t feel comfortable on such lanes when my kid is in the trailer.
In my use case I don’t need those details to impact routing algorithms. I just need to get this information after map matching.
If you fork GH you can easily store this information in the KVStorage and fetch it via the KVStringDetails without much overhead (no extra database required). See how we store data in OSMReader.preprocessWay for e.g. name, motorway_junction etc.
Why do we need to store this information in the KVStorage in the first place? Can’t we just encode type of bicycle infrastructure and put it into way?
Using the KVStorage does not require to create encoded value classes and does not reserve bits for every edge. I.e. if the tag is relative seldom compared to the total amount of edges it is more memory efficient to use this, especially since you only need it to get this info after the algorithm is done.
Encoded value in comparison are much faster to access and so are the preferred choice to guide the routing algorithms but must have predefined values.
Because the client side interpretation of all these combinations would become quite complicated.
Originally I thought that the proposed new bike_infrastructure encoded value would not have any chance of getting merged. But as @caspg plans to fork the project I now think that this would be the best option.
I plan to split up the bike parsers (or all parsers) at some point so that we only have single purpose encoded values. The custom models would become more complex but they would be put server-side (so client-side does not see this complexity) and it would become easier to tweak them (without forking).
Because the client side interpretation of all these combinations would become quite complicated.
@ratrun What do you mean by client side interpretation? Client side custom models?
I’m thinking right now only about using this data to display infromation about route. So that wouldn’t be that complex. I have map where I present different kind of bike infra already Mapa infrastruktury rowerowej (Ścieżki Rowerowe) | Velomapa
I created a fork already which I will be using for my website but I think this extra details may be interesting for others.
No, I did’t meant custom models but the aggregation of extended path details in order to generate a textual classification of the bicycle infrastructure.
I had a look on your map but without English translation I’m lost. The only thing I could identify there is that you already seem to do some kind of aggregation in a map overlay.
Yes, it’s polish only. And yes, I did some aggregation to match bike infra in Poland. So it seems like a complex task but achivable. I did it with a help from polish OSM user group.
I could open source it and probably there could be one generic aggregation for all countries.
