GraphHopper with PostGIS Data Reader

GraphHopper is a new fast routing engine that is written in 100% Java. It is very memory efficient and is able to load large amounts of road data when creating routing networks for fast searches. And since it is written in Java, GraphHopper is easily installed in most major server environments.

GraphHopper has a very rich set of API which makes applications that require Text Directions and coordinates from a path, GPS nodes matching to a road network, and creation of Isochrone (Driving Distance) polygons for Analysis, etc. possible. When creating a custom application, all that has to be done is to include the GraphHopper library as a Maven dependency, and all the API will be made available to the application.

OSM Data

GraphHopper uses the OpenStreetMap (OSM) road data primarily when creating a native route network. The benefit of this is that there are world wide data that will always be available for GraphHopper usage. The OSM’s speed and road type attributes are being used by GraphHopper as cost when calculating the fastest or shortest paths between two designated points. Using these OSM attributes GraphHopper can also create car, bicycles, foot, etc. routing profiles when doing path searches.

Disadvantages of OSM Data

As mentioned above, using OSM road data as GraphHopper’s primary data source offers many advantages. But problems arise when there is a need to either use a different data source for GraphHopper or create customized costs for path searches.

When a different road network has to be used in GraphHopper, the following has to be done ( this is on the presumption that there is no direct converter of the road network into OSM data format ) :

Convert the road network either into Shapefile format or into PostGIS table in PostgreSQL. The reason for this is that almost all data converters for OSM are for these 2 data formats. Use a 3rd party data converter and convert either the Shapefile or PostGIS data into OSM data. And finally, use GraphHopper to convert the OSM data into GraphHopper’s own data network.

Since road networks usually entails large amounts of data, converting to OSM format consumes large amounts of time as well as computer resources. The reason for this is because with the way the OSM data format is structured, the conversion process will need ample memory, disk space, and computing power to complete its operation.

And since GraphHopper relies solely on OSM’s road type and speed to compute the cost when searching for a path, the new data source’s attributes have to be changed in order to conform with that of the OSM’s unique road definitions. Again, since road networks are quite large, converting attributes of all the data will also entail time and effort.

Creating a GraphHopper PostGIS Data Reader

GeoRepublic completed a project that requires using Japan’s Digital Road Map (DRM) with GraphHopper because there is a need for fast route searches which GraphHopper can accomplish. The DRM road data is quite expansive with its entire Japan coverage, and when converted into PostGIS, has over 13 million records. Converting the DRM in PostGIS into the OSM data format required a server with a Xeon CPU, 32GB of RAM with another 32GB of disk swap space with a fast SSD hard disk, and it required over 10 hours of processing time in order for the data conversion to complete. If an attribute in the DRM has to be modified for whatever reason, the entire 10 hour process has to be done all over again.

The entire process was very expensive, and an alternative method had to be found. Fortunately, there exists already a Shapefile reader in the GraphHopper package that converts data in the Shapefile format into GraphHopper’s native data format. Using the Shapefile reader source code as basis (it is Open Sourced), a PostGIS reader was written which can convert PostgreSQL tables or views directly into GraphHopper’s native data format as well.

Since creating an OSM output is not necessary anymore, converting the DRM data directly for GraphHopper’s usage went down from 10 hours processing time to less than 1 hour. A very big improvement which can make data conversions done in a regular basis if ever there are modifications in the DRM data. And with the PostGIS data reader, the input data is not just limited to the DRM but to any road network data such as that of Navteq’s.

This applies also of course to all the data developed for pgRouting. Since pgRouting data is not confined to just road navigation, with applications created for broad categories (such as water flow management, optical fiber utilization, etc), the PostGIS reader opens up all of a sudden more usages for GraphHopper.

Dynamic Costs

But the biggest advantage the PostGIS reader gives is the ability to have dynamic costs for the road network.

GraphHopper requires the following OSM columns when creating it native network data (please refer to OSM documentation for the proper values of these columns) and is thus required by the PostGIS data reader for the conversion process :

• osm_id
• maxspeed
• oneway
• fclass
• name
• geom

GraphHopper will use the values of maxspeed, oneway, and fclass to determine the cost of the route and/or create routing profiles. Now since the PostGIS data reader can use SQL Views as well as Tables, these columns can be derived from other tables linked together by SQL when creating a View.

For Example:

CREATE view myroad_view
  (osm_id, maxspeed, oneway, fclass, name, geom)
  AS SELECT id, 0, oneway, 'tertiary'::text, name, geom FROM custom_road_network;

This will create a View, myroad_view, that can be converted into GraphHopper. Since all the data will have the same maxspeed as 0 and all fclass as tertiary values, the resulting network will always give only a Shortest Path for all route queries.

In the case of the DRM data, the SQL below is used to match the road classification of the DRM with that of OSM’s fclass:

CREATE VIEW drmview (osm_id, maxspeed, oneway, fclass, name, geom ) AS
  SELECT id, 0, 'B'::text,
    CASE
      WHEN rdclass = '1' THEN 'motorway'
      WHEN rdclass = '2' THEN 'motorway'
      WHEN rdclass = '3' THEN 'trunk'
      WHEN rdclass = '4' THEN 'primary'
      WHEN rdclass = '5' THEN 'primary'
      WHEN rdclass = '6' THEN 'secondary'
      WHEN rdclass = '7' THEN 'tertiary'
      WHEN rdclass = '9' THEN 'road'
    END,
  id::text, geom
  FROM network_table;

Since the speed is all set to 0 value, the searches will just use the road classifications as the value for the cost when creating a search path.

Now if there are traffic information in an another table, another View can be created that links the traffic information table with the road network table via SQL that gives the maxspeed a higher value for roads that have less traffic and lower values that have more traffic. This will give priority to roads with less traffic when doing path searches.

So again as a retrospect, with the ability to use other information as cost, which goes beyond the basic OSM attributes, the PostGIS data reader provides more interesting applications that can be created for GraphHopper.