Just to close this loose end, since I asked the question a new package was released called osmar which contains a vignette of how to implement shortest path algorithms in R using Open Street Map data: http://osmar.r-forge.r-project.org/ . It uses the function get.shortest.paths from the igraph package.
Excellent article on this can be found here:
For osm2pgrouting V2.1:
length is length of the segment in degree units
cost and reverse_cost is the length in degree units. (include the negative values for wrong way)
length_m is in meters (there is no cost_m or reverse_cost_m)
cost_s and reverse_cost_s is in time: seconds units (using the maxspeed value that is in km/hr transforming it to meters/second ...
There are a couple of sources which describe how to develop isochrone maps:
Public transport isochrones with pgRouting
This post contains information in great detail on how to install, run and conduct a variety of analyses on isochrone maps with pgRouting. Included a couple of images so you can if it's something you are looking for:
Image of pgRouting ...
The "Topology" chapter of the workshop is there to explain the basics about the routing network. The first paragraph should actually explain that. If it's not so clear, then I will change this with the next version of the workshop.
But if you import OSM data you just use an import tool named "osm2pgrouting", which is explained in detail a few chapters later:...
pgr_dijkstra(edges_sql, start_vid, end_vid, directed:=true ) is a SQL function. It returns the following, regardless of what you input into its TEXT edges_sql argument.
RETURNS SET OF (seq, path_seq, node, edge, cost, agg_cost)
To answer your first question: yes, joining will be the only way you can get information from an external table to be added to ...
It seems that the problem is with the the multi-student sub-query below you were using to replace the single student query:
(SELECT id FROM osm.osm_ways_vertices_pgr ORDER BY the_geom <->
(select geom from dpsdata."Geo_Active_Student" as stu where stu.studentid in ( '750939', '814767', '768922')) limit 1)
The single-student sub-query below ...
You are passing in the metric length ST_Length(geom::GEOGRAPHY) of each edge E as both cost & reverse_cost - rendering it equal to to the undirected counterpart.
pgRouting realizes ordered graph restrictions via the [reverse_]cost parameters; generally speaking, while an undirected graph considers only a single cost per edge E, a directed graph treats ...
There are a couple of things coming to my mind here:
First, and foremost, why you feel the need to use an unproven HPC routing solution to do something for which the OSM community already developed proven and tested solutions? Routing on OSM data has been implemented as several Open Source projects (See http://wiki.openstreetmap.org/wiki/Routing. Even ESRI ...
OSM attributes can vary a lot, so attributes used in osm2pgrouting are commonly used and available in general. Because there can be so many different attributes, it's not possible (and not a good idea) to import them all.
There are tools, which can do this better, for example osm2pgsql or Imposm. osm2pgrouting imports the osm_id attribute, so you should be ...
Checkout this tool that converts OSM PBFs to Parquet files:
.. and the following blogpost containing a demo where Spark is used to reconstruct Way geometries:
After analyzing my dataset more with QGIS I think I've found most of the differences.
Using osm2pgrouting with mapconfig_for_cars.xml still includes vertices related to pedestrian interaction, whereas osm2po with wtr.finalMask = car does not.
Here is a view of OSM of an intersection with crosswalks...
Here is a view of my dataset (which is roads only) ...
They are called diff updates. You have two options ..
Apply the Diffs from PlanetOSM and then remove the imported geometry that are outside of your bounding box
Use the Geofabrik Extracts for North America and apply the Geofabrik diffs which are updated daily.
I do both, 3 minute diff updates for the planet and daily diff updates for the Philippines, in ...
Should be here: /usr/share/bin/osm2pgrouting
But particularly if you are dealing with large data (e.g. europe.osm) you might want to try osm2po instead of osm2pgrouting.
First you want to post your question in a readable form, so I don't have to spend time making it readable (already done, so remember for your next question, please).
Second, read the documentation how to compile pgRouting and what is required: http://docs.pgrouting.org/2.0/en/doc/src/installation/build.html#build
Third, read the error message, which ...
We mentioned this issue in the pgRouting Practical Guide - http://locatepress.com/pgrouting (still in draft). Hopefully will be fixed in later pgRouting versions.
The work around is to do this (as DavidP pointed out using $$ is a first step), but the bug is that you still need '' in the inner query where as you really shouldn't need that:
I guess that you took the example createTopology function which is shown for WGS84 geometries, using degrees as a projection unit. 0.00001 degree tolerance means that your points have to be less than 1.19 meters away from each other to be connected.
As seen here : https://epsg.io/900913
The system that you're using uses meter as projection unit. Which ...
You have to change the used speed profile (defined in a .lua file) depending on the specific attributes of your edges/ways.
By default, car.lua considers edges with common OSM attributes like highway=secondary which are suitable for cars.
I realized I had omitted another good link for you. There is an interesting blog by one of the ESRI developers involved in the HPC stuff (Mansour Raad). I hadn't visited it for a while, but it turns out he actually wrote an article about invoking a Spark job from within ArcGIS for Desktop using ArcGIS Geoprocessing tools. There is code samples as well. I don'...
If appears the book that I'm following has either some unreported errata or uses some old syntax.
The fix is using --clean with an argument instead of just -clean, which was conflicting with the -c switch.
As suggested in the comments, expecting a complete tutorial for someone with little computer admin experience is unrealistic, and unlikely to really help you. Sorry if that isn't what you wanted to hear.
I'd suggest two options, depending on your cash / time trade-off, and what you are actually trying to achieve:
Pay someone to do this for you. In the end, ...
Are you using the master or develop branch of osm2pgrouting, I notice the help is a little different between the two.
I'm using the develop branch and it has these instructions:
-c [ --conf ] arg (=/usr/share/osm2pgrouting/mapconfig.xml)
--help Produce help message for this version.
Only way I've been able to do it (I think it works for osm2pgrouting, but haven't tried recently)
Is to first change the search_path of your database temporarily so preferred schema is first:
ALTER DATABASE yourdb SET search_path = osm_data, public;
Then run osm2pgrouting
Alternatively you could create a user specifically for loading and then set the ...
Adding next countries to existing table is not a good idea, because added data will not be joined with existing one topologically. Although PGRouting provides some functions for creating topology in my opinion there'll be simplest and quickest way to load a new data.
Osmosis will do a good job with joining few countries extracts into one file
osmosis --rx ...
osm2pgrouting converts the osm data "as is".
In osm segments are defined using sequence of node_ids
so for example:
(node_id, x, y)
(1234, 2, 3.9999999)
(5678, 2, 4)
if a segment A, ends with 1234 and a segment B starts with 5678
there will be a gap 0.0000001 wide
Validity of gaps:
maybe if you are routing pedestrians you don't want that gap.
maybe if ...
The function used in UpdateGeometrySRID is st_setsrid instead of st_transform.
st_setsrid just sets the srid value without changing the coordinates. Since there is no function for looping tables to transform projection in PostGIS according to updateGeometrySRID function.
I suggest you to write a script in python to execute it:
Firstly execute to get the ...
An alternative approach is to NOT select the road segments at all!
Working with costs only makes sense in case you have different costs by direction (ie. one way streets), or if you want to make the route prefer certain road classes.
The parts of your network, that you want to exclude completely, you better don't load at all. It will also make your query ...
Follow this guide to find your tolerance and to create the nessesary columns before running pgr_createTopology:
4326 => 0.00001 in tolerance
ALTER TABLE planet_osm_roads ADD COLUMN "source" integer;
ALTER TABLE planet_osm_roads ADD COLUMN "...