[pgrouting-users] PgRouting-Problems with own OSM-data

[Stephen Woodbridge]

Kai,

First off you probably need to build some diagnostic tools to help you 
understand the problem better, especially to help you determine if it is 
a data problem. I find two tools that are easy to build and help a lot. 
You can see them in action here:
http://imaptools.com/leaddog/routing/dd.html
Zoom into a city, open the layerswitcher and select "Just the Streets" 
and "Dead Ends"

1) create a mapfile that displays the street segments from the routing 
database and add this as an optional base layer. You might want to add 
color oneway streets a different color, but in general keep the display 
simple and probably single pixel lines. You might label the segments 
with their UID so you can go back to the database and query them in detail.

2) add a column cnt integer to the vertices_tmp table and update it with 
the count of segments that reference that node. Maybe something like this:

alter table vertices_tmp add column cnt integer;
update vertices_tmp set cnt=0;
update vertices_tmp set cnt=cnt+1 where streets.source=id;
update vertices_tmp set cnt=cnt+1 where streets.target=id;

Now create a mapfile layer for points and display the vertices_tmp

LAYER
   NAME "deadends"
   TYPE POINT
   CONNECTIONTYPE "postgis"
   CONNECTION ...
   DATA ...
   CLASSEXPRESSION "cnt"
   CLASS
     EXPRESSION "cnt=1"
     STYLE
       SYMBOL "circle"
       SIZE 5
       COLOR 255 0 0
     END
   END
   CLASS
     EXPRESSION "cnt>2"
     STYLE
       SYMBOL "circle"
       SIZE 3
       COLOR 0 255 0
     END
   END
END

This will display red dots at dead ends and green dots as good 
connections be segments. If you have a lot of red dots between segments 
that should be joined, you probably need to rebuild your vertices tmp 
table with a larger tolerance.

It is very hard to debug a large black box like a router without having 
some tools that can give you some better insight as to what is going on.

-Steve



Kai Behncke wrote:
> Dear Stephen, Dear Users,
> 
> first of all thank you for answering and sorry, that I reply so late.
> 
> 
>> This problem may be because the start and stop point are almost vertical 
>> and the code uses these two points to construct a bounding box to select 
>> street segments from to run the analysis. It adds a buffer to the bbox 
>> but it might not be enough to capture all the segments need for a 
>> solution. You can change the buffer size in pgpsql code. ou might want 
>> to use and algorithm like if the bbox is nearly horizontal or vertical 
>> then make is square based on the larger dimension. This is have a small 
>> performance penalty but you will get less failures.
> 
> I think the street segments are find correctly.
> In the picture
> 
> http://www.selbstverwaltung-bundesweit.de/routingfrage_1.png (screenshot 1)
> 
>  you can see the start and the endpoint
> (the red square is the box within is looked for overlapping geometries).
> 
> Definetely the first requests for the start and finalpoint work fine
> (    $sql = "SELECT gid, source, target, the_geom,
>                distance(the_geom, GeometryFromText(
>                  'POINT(".$lonlat[0]." ".$lonlat[1].")', 900913)) AS dist
>            FROM ".TABLE."  
>            WHERE the_geom && setsrid(
>                  'BOX3D(".($lonlat[0]-200)."
>                         ".($lonlat[1]-200).",
>                         ".($lonlat[0]+200)."
>                         ".($lonlat[1]+200).")'::box3d, 900913)
>            ORDER BY dist LIMIT 1"
> 
> I get results ands they seem to be correct
> (you can see in the screenshot the red stars symbolize the nodes of the two
> roads (OSM-Data)
> (the blue, little stars are the nodes of the other OSM-roads/ways/etc.).
> 
> but then the problem comes  if I use the Dijkstra-SQL:
> 
>    case 'SPD' : // Shortest Path Dijkstra
>      $sql = "SELECT rt.gid, AsText(rt.the_geom) AS wkt,
>                   length(rt.the_geom) AS length, ".TABLE.".id
>                FROM ".TABLE.",
>                    (SELECT gid, the_geom
>                        FROM dijkstra_sp_delta(
>                            '".TABLE."',
>                            ".$startEdge['source'].",
>                            ".$endEdge['target'].",
>                            3000)
>                     ) as rt
>                WHERE ".TABLE.".gid=rt.gid;";
> 
> (Of course it is filled with values)...but it gives no result, but I don`t understand why????
> 
> 
> I tested it with the victoria-data and the same code.
> 
> It doens`t seem as if the topology has more nodes as you can see in screenshot 2:
> 
> http://www.selbstverwaltung-bundesweit.de/routing_geht.png
> 
> 
> 
> The geom is correctly recognized and with:
> 
> SELECT rt.gid, AsText(rt.the_geom) AS wkt,
> 
>                   length(rt.the_geom) AS length, routing_victoria.id
> 
>                FROM routing_victoria,
> 
>                    (SELECT gid, the_geom
> 
>                        FROM dijkstra_sp_delta(
> 
>                            'routing_victoria',
> 
>                            1089,
> 
>                            1369,
> 
>                            3000)
> 
>                     ) as rt
> 
>                WHERE routing_victoria.gid=rt.gid;
> 
> I get correctly that:
> 
> http://www.selbstverwaltung-bundesweit.de/datenbank.png
> 
> 
> Can anybody please explain what happens in the above mentioned function please?
> What could be the difference between the victoria-data and my osm-data?
> 
> 
> 
>>> Problem 2:
>>>
>>>
>>> If I get a result it`s mostly wrong, as you can see here:
>>>
>>>
>>> Screenshot 2:
>>> http://www.selbstverwaltung-bundesweit.de/too_long.png
>>>
>>> The route is far too long.
>>>
>>> How can this be?
>> This might depend on which analysis you requested. The shooting star 
>> evaluates based on edges and I do not think it trims the edges. Where 
>> the dijkstra's evaluates nodes and adds the start and stop node. I had 
>> to modify the code to trim segments, unfortunately those changes are 
>> mixed in with a bunch of other changes that I made and not easy to
>> extract.
> 
> Hmmm.....I just use the dijkstra
> 
> 
> SELECT rt.gid, AsText(rt.the_geom) AS wkt,
> length(rt.the_geom) AS length, routing_victoria.id
>  FROM routing_victoria,
> (SELECT gid, the_geom
> FROM dijkstra_sp_delta(
> 'routing_victoria',
> 1089,
> 1369,
> 3000)) as rt
> WHERE routing_victoria.gid=rt.gid;
> 
> The start and stop node are set, but the result (if I at least get one) very weird....
> I think it MUST be a data-problem......
> But in the moment I have no idea how to fix it :-(
> 
> Beste regards, Kai
> 
>