Re: [PATCH v1] Re: [mkgmap-dev] maxspeed tag vs road_speed preset
Hi Greg Troxel <gdt@ir.bbn.com> 1st: I do not know very well how to keep the answer in the same thread... anyway, I do not think there is a simple way to hard-code a proper speed of a road that is right for all cases (expecially if it is indifferentiated for all highway types). I can speed on a city road at 60 km/h during night and 15 km/h during day (yes, 15 km/h is the average speed in Rome, as measured by the public transportation company). Maybe only real time traffic information systems can work well in such messy cases. And of course I can just imagine the endless discussions for each road about the right value to give to an "average_speed" tag... Much better would be to automatically calculate an average_speed tag by using all information the OSM DB already have: the highway type, the maxspeed tag, the number of crosses per kilometer, the curves (radius and frequency) and also the available GPX real speed data. For now I think much simpler: a tertiary road in the countryside, maybe full of curves, slopes, narrow points, you might have a "law limit" of 90 but you will never go to 90. I'd say 60 average. In the same countryside, a primary road is wide, straight, has precedence over smaller roads, but the limit is still 90. I'd say you go 90 average. Back to the city: both tertiary and primary share a maxspeed of 50, then you go maybe at 40 on tertiary and only slighlly faster on primary. highway=tertiary & maxspeed>60 [... road_speed=3 ...] highway=tertiary & maxspeed<61 [... road_speed=2 ...] highway=primary & maxspeed>80 [... road_speed=5 ...] highway=primary & maxspeed>60 [... road_speed=4 ...] highway=primary & maxspeed<61 [... road_speed=3 ...] If you want I can post my style file (I'm still workin on it...). I think this speed differentiation would help the router to guess the right way and the right ETA both inside the city and outside. In Java, someone smarter could count crosses per kilometer or curve radius. Maybe next year... Ciao, Marco.
0> In article <212454.24051.qm@web28515.mail.ukl.yahoo.com>, 0> Marco Certelli <URL:mailto:marco_certelli@yahoo.it> ("Marco") wrote: Marco> 1st: I do not know very well how to keep the answer in the same Marco> thread... Just follow-up in the normal way (sometimes called "group reply" or "reply to all"), then remove the original sender from the recipients (so that you don't annoy them by sending two copies). Marco> I can speed on a city road at 60 km/h during night and 15 km/h Marco> during day. ... And of course I can just imagine the endless Marco> discussions for each road about the right value to give to an Marco> "average_speed" tag... Much better would be to automatically Marco> calculate an average_speed tag by using all information the OSM Marco> DB already have: the highway type, the maxspeed tag, the number Marco> of crosses per kilometer, the curves (radius and frequency) and Marco> also the available GPX real speed data. Yes - IIRC there is a Summer of Code project to collect and use gathered speed data from GPS tracks to give realistic speed estimates. But the Garmin maps don't (as far as we know!) have any provision for time-dependent speeds. So it's always going to be a very rough estimate. Let's not get too worked up about these details yet!
No hardcoding speeds would be awful. Not everyone wants to have OSM maps for carrouting (commercial alternatives are not very expensive and still much in advance), for cycling, biking, hiking however alternatives are much more expensive and not allways better. hardcoding will not work. I have since quite some time deleted those maxspeed lines out of the source because it would really mess up routing for bicycles and mtbikers. The best would be to have a switch that deactivates all carrelated settings (there are some more). For bicycle use to get good routing you need to switch quite a lot of things (i.e. delete all motorcar=no, then set bicycle=no to motorcar=no), delete maxspeed, and give high road_class and road_speed to footways, else they will not be chosen when autorouting. Then on the other hand degrade ways that have sac_scale=alpine_hiking or higher (just as expample, rules depend on user preferences). So there is quite a lot to be setup. Being able to set this in the style-file without needing to patch and delete rules in the sources would make it much easier. I.e. for cycling turn restrictions - I would only keep them for primary and secondary roads, maybe on tertiary roads. On residential streets turn restrictions would usually only apply to cars. and so the list goes on. The most important IMHO is to read the whole style-file from top to bottom, and only apply rules to what follows below. If you are afraid the style-file gets too complex, maybe define a second file in which one can find centralised all hardcoded behaviour of now, easy to change (editing styled.converter is pretty advanced). Toby Speight wrote:
0> In article <212454.24051.qm@web28515.mail.ukl.yahoo.com>, 0> Marco Certelli <URL:mailto:marco_certelli@yahoo.it> ("Marco") wrote:
Marco> 1st: I do not know very well how to keep the answer in the same Marco> thread...
Just follow-up in the normal way (sometimes called "group reply" or "reply to all"), then remove the original sender from the recipients (so that you don't annoy them by sending two copies).
Marco> I can speed on a city road at 60 km/h during night and 15 km/h Marco> during day. ... And of course I can just imagine the endless Marco> discussions for each road about the right value to give to an Marco> "average_speed" tag... Much better would be to automatically Marco> calculate an average_speed tag by using all information the OSM Marco> DB already have: the highway type, the maxspeed tag, the number Marco> of crosses per kilometer, the curves (radius and frequency) and Marco> also the available GPX real speed data.
Yes - IIRC there is a Summer of Code project to collect and use gathered speed data from GPS tracks to give realistic speed estimates. But the Garmin maps don't (as far as we know!) have any provision for time-dependent speeds. So it's always going to be a very rough estimate. Let's not get too worked up about these details yet! _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
__________ Information from ESET Smart Security, version of virus signature database 4093 (20090521) __________
The message was checked by ESET Smart Security.
__________ Information from ESET Smart Security, version of virus signature database 4093 (20090521) __________ The message was checked by ESET Smart Security. http://www.eset.com
participants (3)
-
Felix Hartmann -
Marco Certelli -
Toby Speight