maxspeed tag vs road_speed preset

Hi First of all: great job. And now, my issue: I'm trying to make some personal styles but I encountered the following problem: if a highway has a maxspeed tag in OSM, whatever road_speed I put in the style, it seems it is ignored for a value that is decided by mkgmap based on the OSM tag. If I put some lines like those: .... highway=trunk & maxspeed>100 [0x02 road_class=4 road_speed=5 resolution 16] highway=trunk & maxspeed>80 [0x02 road_class=3 road_speed=5 resolution 16] highway=trunk & maxspeed>60 [0x02 road_class=3 road_speed=4 resolution 16] highway=trunk & maxspeed<61 [0x02 road_class=3 road_speed=3 resolution 16] highway=trunk [0x02 road_class=3 road_speed=5 resolution 16] .... it seems it is not working as I expected: if the trunk has a maxspeed tag in OSM, it always get a road_speed value that is independent by the one I've declared in the style (I don't know if it is the same for the road_class); if the trunk has not maxspeed, it takes the default row (last one) in the style. I'm sure the style row is parsed and selected correctly in accordance with the maxspeed tag, but the road_speed is not set as I would like. If this is a wanted feature of mkgmap, the relationship between the maxspeed in the OSM data and the road_speed parameter given to the way should be configurable in some way and should be configurable per highway type. Can you help me? Ciao, Marco.

Hi Marco, the relationship between the maxspeed tag and the road_speed is hardcoded in mkgmap. This is reasonable in general, because otherwise the style files had to be much larger to cover all the possible road_speeds per road. But if you want to use the road_speed in a creative way (say for a cycle map) this gets in the way. The evaluation of the maxspeed tag is implemented in src/uk/me/ parabola/mkgmap/osmstyle/StyledConverter.java. The following patch will remove it. Index: StyledConverter.java =================================================================== --- StyledConverter.java (revision 1038) +++ StyledConverter.java (working copy) @@ -619,16 +619,8 @@ road.setOneway(); } - // maxspeed attribute overrides default for road type - - String maxSpeed = way.getTag("maxspeed"); - int speedIdx = -1; - - if(maxSpeed != null) - speedIdx = getSpeedIdx(maxSpeed); + road.setSpeed(gt.getRoadSpeed()); - road.setSpeed(speedIdx >= 0? speedIdx : gt.getRoadSpeed()); - boolean[] noAccess = new boolean[RoadNetwork.NO_MAX]; String highwayType = way.getTag("highway"); if(highwayType == null) { Regards Thilo

Hi Thilo,
the relationship between the maxspeed tag and the road_speed is hardcoded in mkgmap. This is reasonable in general, because otherwise the style files had to be much larger to cover all the possible road_speeds per road. But if you want to use the road_speed in a creative way (say for a cycle map) this gets in the way.
The evaluation of the maxspeed tag is implemented in src/uk/me/ parabola/mkgmap/osmstyle/StyledConverter.java. The following patch will remove it.
It occurs to me that some people will want the maxspeed tag to override the speed code in the rules file (obviously, the person who wrote that code thought it was a good idea) but others, like Marco, would prefer not to have that feature. So, I guess, we need (yet another) option to control this behaviour. I attach a patch that does, essentially, the same thing as your patch with the addition that you can switch that behaviour on and off. Cheers, Mark

Hi Mark,
It occurs to me that some people will want the maxspeed tag to override the speed code in the rules file (obviously, the person who wrote that code thought it was a good idea) but others, like Marco, would prefer not to have that feature. So, I guess, we need (yet another) option to control this behaviour. I attach a patch that does, essentially, the same thing as your patch with the addition that you can switch that behaviour on and off.
Thank you for that patch. The patch I posted was intended to be applied locally if one wanted to remove that behaviour. With the state of mkgmap right now I think it is reasonable to hardcode such things as the maxspeed, because otherwise the style files will get overly complex and with the current syntax of the style files a lot of things can not be encoded at all (for example motorway exits, roundabouts etc.) For special "map- tuning" one will have to modify the mkgmap source. Which is probably even easier than coming up with highly complex style files to accomplish the same thing. So if you like to integrate the switch for the maxspeed handling into the trunk I will be happy, but I also understand that you might not want mkgmap to be cluttered with lots of "special options". Regards Thilo

Hi Thilo,
So if you like to integrate the switch for the maxspeed handling into the trunk I will be happy, but I also understand that you might not want mkgmap to be cluttered with lots of "special options".
Well, I don't have a problem with lots of options so I am happy to commit that patch if people are agreed that it's useful. Cheers, Mark

From the various posts on this topic, I get the impression that there is much more to this business than just zapping the maxspeed tags. Why don't those people who care about this stuff work out what is really required and either come up with a concrete proposal as to how it should be done, or even better still, come up with a patch that does it? In the meantime, shall I commit this little option? Cheers, Mark
participants (3)
-
Marco Certelli
-
Mark Burton
-
Thilo Hannemann