|
1 | 1 | # How to Guide Routing Algorithms Towards Pleasant Hiking |
2 | 2 |
|
3 | | - |
| 3 | + |
4 | 4 |
|
5 | 5 | *source: [sydneycoastwalks.com.au](https://www.sydneycoastwalks.com.au)* |
6 | 6 |
|
@@ -43,7 +43,7 @@ Alternatively, feel free to download the output of this step [here](https://gith |
43 | 43 |
|
44 | 44 | As mentioned above, we will use *osm2po* to generate the topology from the OSM data we generated in the previous step. It is important to understand that OSM data is not routable in its raw form. The geniality of this software is that it isn't only a light-weight routing engine, it also processes the OSM data and outputs a SQL file which can directly be imported to your PostgreSQL database and be used with **pgRouting**. For this tutorial our task is to make sure we output a topology including all highways in the area of interest as we will want to post-process these in the database. |
45 | 45 |
|
46 | | - |
| 46 | + |
47 | 47 |
|
48 | 48 | *source: [osm2po](http://osm2po.de/)* |
49 | 49 |
|
@@ -102,7 +102,7 @@ Objective of this tutorial is to guide Dijkstra's algorithm along the coast of S |
102 | 102 |
|
103 | 103 | The choice being Sydney's coastal walk is quite convenient. There exist many roads you could walk on which are more or less parallel to the coastal footpaths, obviously getting you faster to the destination. The reason is straightforward: the distance is shorter. If you take a quick glimpse at what common routing services usually compute, such as [Google Maps](https://maps.google.com/), you will understand what we mean and why you may want to do some customizing. |
104 | 104 |
|
105 | | - |
| 105 | + |
106 | 106 |
|
107 | 107 | *source: [Google Maps](https://maps.google.com/)* |
108 | 108 |
|
@@ -147,7 +147,7 @@ JOIN syd_2po_4pgr AS pt |
147 | 147 |
|
148 | 148 | ...your result should look like the following (which is very similar to what we got using Google Maps up top): |
149 | 149 |
|
150 | | - |
| 150 | + |
151 | 151 |
|
152 | 152 | Well, it's the shortest path and we aren't satisfied with this result as we want to see the coast non-stop. This is where we will exploit the nature of the algorithm and guide it onto footpaths as much as we can (and guess what: the coastal tracks are foopaths). If you remember we imported the OpenStreetMap data at the beginning which we will now join to the topology allowing us to decrease the cost of the edges in question. To this end, we will add an auxiliary column `cost_updated` to our topology table (which will be consumed by pgRouting later on). Subsequently we will populate this column using a very straightforward logic. If the source osm_id of the record (edge) is tagged `footway, pedestrian, living_street, cycleway, track` or `steps` (in `planet_osm_line` or `planet_osm_polygon`), we will divide the length of the edge by 1000, otherwise the cost remains the metric length. The division ultimately makes the cost very cheap, i.e. the algorithm will be guided onto this subset of edges. |
153 | 153 |
|
@@ -184,7 +184,7 @@ WHERE t.osm_id = l.osm_id; |
184 | 184 |
|
185 | 185 | Executing the query once again from above and instead of using `ST_Length(ST_Transform(geom_way, 3857)) AS cost` but `cost_updated AS cost`, your route will look something like this - enjoy the walk! |
186 | 186 |
|
187 | | - |
| 187 | + |
188 | 188 |
|
189 | 189 | ### Wrap-up |
190 | 190 |
|
|
0 commit comments