Finally, my promised follow up to my build your own routing solution article. For those who have had success massaging their data to work the pgdjikstra module, lets rock and roll. I’m writing this on the fly so hopefully by the end we can get a usable, user-friendly routing solution into Kamap.

1. Kamap install.

Grab the latest stable (or CVS if you’re feeling lucky) release and follow the instructions to get it up an running. Paul and the rest of the crew have made this possibly the easiest frontend to get up and running in a flash, but if you do run into problems please contact the list.

Ignore my setup / mess, this was an existing mapfile used for benchmarks. This is possibly what you shouldn’t have setup, but its got the road centrelines so it’ll do for our purposes.

2. Create a database handler

Since we would like the users to be able to interface with our db, we need to create a little interface to query the roads and execute the shortest_path_as_geometry call. For the sake of simplicity, the following should give you somewhere to start. (Source: querydb.php, if the output below gets munged)

Dont worry if the output format doesnt really make much sense at the moment, we’ll touch on this in the next step.

< ?php
//SQL query
$query = "SELECT astext(the_geom) FROM shortest_path_as_geometry('roads', ".$start.", ".$end.");";
$result = pg_query($query) or die('Query failed: ' . pg_last_error()); // output
echo "n";
echo "n";
echo "	Startn";
echo "  ";
while ($line = pg_fetch_array($result, null, PGSQL_ASSOC)) {
      foreach ($line as $col_value) {
               $col_value = str_replace("MULTILINESTRING((", " ", "$col_value");
               $col_value = str_replace("))", ", ", "$col_value");
               echo "$col_value";
      }
}
echo "n";
echo "n";
echo "n";  // Free resultset
pg_free_result($result);  // Closing connection
pg_close($dbconn);
} ?>

3. Integrating PG’s kaXmlOverlay code

PG has done some great work looking into how best to integrate vector overlays on kamap, much like google maps does. Technically, there are lots of different options, but PG’s latest code uses a mix of the wz_jsgraphics and the PHP GD library.

This option has arguably the best cross browser support in that the route is actually rendered and thus positioned, as a PNG/gif image. But more on that later.

PG has posted a demo of the capabilities at his site (http://sistel.dyndns.info/ka-map/indext.html).

You will need to download the kaXmlOverlay.js, drawGeom.php and the wz_jsgraphics library.

Edit your existing kamap index.html and add,

The code is pretty self explanatory, we simply define the path to the XML (querydb.php) and attach it to the map initialised handler. PG has a slightly alternative setup on his demo website, adding a refresh function to automatically refresh the XML doc at a set period. This is a real handy feature if you’re tracking a live GPS feed, but in our case it just adds extra overhead.

4. Time to test

Since the code contains a few point of failures its best to start at the beginning,

1. Chose a start and end edge id from your postgis table and try running http://your.host/kamap/querydb.php?ST=startid&EN=endid. You should get a well formatted text/xml response with the routing coordinates. If the edge ids dont exist or the geometry function did not work, you will get an error here.
2. Now you have determined that you have got the coords, time to try kamap. Load up the modified index from step #3 and tail the apache logs. Amongst all the js queries, there should be one eventual request for the querydb, and then for the drawgeom (something like drawgeom.php?gt=L&st=5&bp=5&sc=25&cl=15,1800,0..). If after 30 seconds or so you dont appear to see any overlays, strip out the exact request from your log and try to run it in isolation. eg. http://localhost/kamap/drawgeom.php?gt=L&st=5&bp=5&… if GD is configured properly you should get an image output like below (PNG)



3. If its still not working, there probably just a URL thats throwing a 404. Keep checking the logs for what its requesting just to make sure its not trying to find a file in / and not /kamap

5. The result

Apologies in advance as i just didnt have time to implement a more dynamic approach such as a user entering a start/end address. I hope someone else out there has the time and the inclination to extend this stuff. The possiblities are endless.

6. Problems and future additions?

1. Needs a better way of converting geo2pix. The existing js function has meant that potentially you could have 40 + coordinate pairs being converted (DB->XML->JS->Drawgeom->Image) to pixel space, and then passed via a URL parameter to drawgeom.php. Very inefficient, and can also go beyond the URL size limit … maybe short term the use of POST might be more suitable?
2. Line simplification. Further work needs to see how suitable the PostGIS simplify() function is. Conceptually, a function to guesstimate a suitable tolerance for the zoom level, and then retrieve the new coords would be suitable but how easy at guessing said tolerance would be interesting.
3. JS bloat. I’d prefer to move as much code as possible server side, especially for “calculations”. Being able to pass the current client params such as pixel/cell size, coords, scale etc. would mean much of the xmlOverlay.js code done by PG could be done server side, and potentially drawn in the same thread (eg. no need for a separate drawgeom.php … the initial query would pass the results direct)
4. An extension to the current querying abilities, where users can click on the map for their start and end points, and the click points would be translated into geo and then fed back into a postgis function to grab the closest road edge. This was what i wanted to do for this article, but alas theres never time.