Re: [OSM-talk] Routing over barrier nodes
On Fri, 11 Sep 2009 00:51:17 +0200, andrzej zaborowski balr...@gmail.com wrote: 2009/9/10 lulu-...@gmx.de: Currently the problem with routing is, that routing applications can not check for millions of nodes, but only for thousands of ways without performace problems. That results in the problem, that for example barrier bollards in the middle of the road can not be considered. I recommend to add a route_nodes=yes or router:check_nodes=yes to such ways, so that the routing software can check only the ways in first run and then check the nodes on ways only where this is set. Comments? Bad idea. Violates first normal form and just invites inconsistent data. Traveling Salesman (to speak about mine )already checks the nodes on evaluated ways and works just fine without such a thing. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Routing over barrier nodes
Currently the problem with routing is, that routing applications can not check for millions of nodes, but only for thousands of ways without performace problems. That results in the problem, that for example barrier bollards in the middle of the road can not be considered. I recommend to add a route_nodes=yes or router:check_nodes=yes to such ways, so that the routing software can check only the ways in first run and then check the nodes on ways only where this is set. Comments? Lulu-Ann -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing over barrier nodes
2009/9/10 lulu-...@gmx.de: Currently the problem with routing is, that routing applications can not check for millions of nodes, but only for thousands of ways without performace problems. That results in the problem, that for example barrier bollards in the middle of the road can not be considered. I recommend to add a route_nodes=yes or router:check_nodes=yes to such ways, so that the routing software can check only the ways in first run and then check the nodes on ways only where this is set. Comments? Isn't that tagging for software? Also the software wouldn't need special tags if it dealt with barriers in the pre-processing to basically split a way or prevent you from routing a particular way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing over barrier nodes
lulu-...@gmx.de wrote: Currently the problem with routing is, that routing applications can not check for millions of nodes, but only for thousands of ways without performace problems. No, the problem is that programmers haven't implemented it yet. If the software can deal with turn restrictions, it shouldn't have a problem with barriers at all. Performance problems instantly disappear with appropriate preprocessing. I recommend to add a route_nodes=yes or router:check_nodes=yes to such ways I disagree. It is possible to take barriers into account without that tag (I've implemented it for the GraphView plugin, for example), so the tag obviously wouldn't add or improve information. Mappers shouldn't do the job of a software preprocessor. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing over barrier nodes
On Thu, Sep 10, 2009 at 09:29:23AM +0200, lulu-...@gmx.de wrote: Currently the problem with routing is, that routing applications can not check for millions of nodes, but only for thousands of ways without performace problems. That results in the problem, that for example barrier bollards in the middle of the road can not be considered. I recommend to add a route_nodes=yes or router:check_nodes=yes to such ways, so that the routing software can check only the ways in first run and then check the nodes on ways only where this is set. Comments? Thats something data preprocessing can easily do - Also a typical preprocessing might insert a little way which represents that node and contains all restrictions so it fits into the Dijkstra ... Flo -- Florian Lohoff f...@rfc822.org Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Routing over barrier nodes
2009/9/10 lulu-...@gmx.de: Currently the problem with routing is, that routing applications can not check for millions of nodes, but only for thousands of ways without performace problems. That results in the problem, that for example barrier bollards in the middle of the road can not be considered. I recommend to add a route_nodes=yes or router:check_nodes=yes to such ways, so that the routing software can check only the ways in first run and then check the nodes on ways only where this is set. Comments? I hate to say the same thing everyone else already said, but yeah, software doesn't work this way. There's something called complexity ([0]) that increases and decreases when the problem changes, but sometimes in unobvious ways. A change that lowers the complexity of the routing problem would be worth considering, but the change you propose does not affect the problem's complexity, where the operation with highest cost is still the path finding. Ways with a barrier can be completely removed from the database during population, or be given higher cost when the barrier is one that only slows down traffic such as crossings with traffic lights. The software still has to process all crossings with other roads because a level-crossing with a primary road is costlier than a crossing with a tertiary road on your path. [0] http://en.wikipedia.org/wiki/Computational_complexity_theory Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
