pgRouting

Forum #15 - Topic #164 - Message List

Route by minimum number of different roads.

I'm having some trouble with OSM maps, lack of speed limit data and gaps in road type entries are making it difficult to get a realistc quickest route. Is it possible to search for a route with the minimum number of road changes to force the use of longer (and hopefully quicker) roads?

Thanks

stan.distortion
08/20/08 07:41:25
Tree View Flat View (newer first) Flat View (older first)
  • Message #568

    Have this kind of sorted. The OSM 'highway' data is fairly good for primary roads and motorways, re-calculating the 'length' data to give motorways a value of 1/2 their true length, primary roads a value of 3/4 of their true length and leaving all other roads at their real length should compensate for the lack of speed data. From there getting the square root of the 'length' value will give a bias favoring longer stretches of road over a greater number of short stretches of road. Hopefully all this together will work ok, the values will need a lot of tuning first though. So far only I've only tested using the square root of the length, that worked very well but tended to use long country roads a lot. Deviding the major road data should fix that, the values of 1/2 and 3/4 seem excesive but they are fairly close to the speed limits, plus getting the square root after the division will reduce the effect quite a lot. Anyway, lots of testing to do. Any thoughts would be appreciated, there are probably far better ways of doing this but it's the best I can come up with for now. Cheers

    stan.distortion
    08/21/08 05:24:10
    • Message #569

      Hi Stan,

      We call it "dynamic cost". If you look at "mapconfig.xml" file, you will see the road classes and types to import from OSM data with their ids. Later the script will create types table according to those records. And at that table you can specify a rate value for every road class (for example 0.2 for highways, 0.6 for major roads etc) and later just simply multiply a cost by the rate value for each edge of that type.

      Of course you can create a cost function which checks a road type first and then calculate a cost with square root, for example. But remember, you need to do it for each and every edge in the data set and simple multiplication by rate is much faster. We had some experience with complicated cost function and now we know that it can be a real bottleneck.

      Also you need to calibrate rate values - adjust them for different road types to make results more accurate. It is quite simple and funny job. You can note how cost changes a result.

      And not only that - you can specify different rates for different cases - one for pedestrians (who can't walk on highways), one for trucks, one for normal cars etc.

      anton
      08/21/08 11:27:00
      • Message #572

        We call it "dynamic cost".

        Knowing what it's called makes things much easier, thanks :) I only had a quick glance at mapconfig.xml, trying to get my head around how sql, postgis, pgrouting, etc. work all at once.

        I'll dig deeper into the type id's and how to use them with the functions, I was planning on creating a new column for re-calculated length values to keep all the overhead in the database creation but that would get bloated for different transport types so the id's will have to be used.

        Also having to keep small devices in mind so floating points have to be kept to a minimum, though with the chain of software between the data and the display that could be tricky.

        Thanks for the feedback, Stan.

        stan.distortion
        08/21/08 20:04:56
Tree View Flat View (newer first) Flat View (older first)