Using this file
http://imaptools.com:8080/dl/Sion.zip
from pgRouting/pgrouting#278

osm2pgrouting -file "Sion.osm"   \
                       -conf "/usr/share/osm2pgrouting/mapconfig.xml"   \
                      -user myuser
                      -dbname issue278
                      -host localhost
                     -clean

psql issue278

select count(*) from ways where  to_cost is NULL;
 count 
-------
 20399

select count(*) from ways where not to_cost is NULL;
 count 
-------
     0

boost.geomtery have various coordinate system here, which one to choose for osm data and do user have to be given an option to choose coordinate system .
If the user wants to choose which coordinate system he wants what do we need?

this is the cartisian model followed by osm.

-conf <conf file>
specifics: required
Component of issue: #43

-host <host>
specifics: optional with default: localhost (127.0.0.1)
Component of issue: #43
be consistent with psql options

I've been unable to find any information on plans for such support, aside from a message within the pgRouting documentation stating that osm2pgrouting does not work with pgRouting 2.x

Opening this issue in an effort to be able to find out when support for 2.x lands.

Since OSM is using 32-Bit-IDs, I get some problems importing my files. I don't understand enough for fixing it, but I'm pretty sure changing "atol()" to "atoll()" in OSMDocumentParserCallback.cpp could help.

-prefixtables <prefix>
specifics: optional (default value???)
In the help suggest meaningfull prefixes eu_ or mx_
and its a pŕefix to ways
Component of issue: #43

--prefix instead of --prefixtables

Some Q's:
if "multimodal" then tables can have also a predefined suffix?
mx_ways_bus
mx_ways_train
etc.
or multimodal can fit on the same table with an extra column that indicates which kind of transportation???
if the user only wants to do train routing, can it be compulsory _train??, or can he choose??
if he can choose the we also need --sufix
The --help should be clear on what we decide.

-passwd <passwd>
password for database access
specifics: optional
be consistent with psql options
Component of issue: #43

-f --file <filename>
specifics: required
Component of issue: #43

I noticed a strange error during the osm2pgrouting import. Right now I use a ppa repository as my installation source. Unfortunatly I can no tell the exact version..., but should be in the 2.0.x. I run pgrouting 2.0.1 final.

It seems that the import clears quite well.

But costs columns are empty...

Is this really a new bug? Or do I need to patch the piece of software?

Program parameters, like name of file, database.
Basically from https://github.com/pgRouting/osm2pgrouting/blob/master/src/osm2pgrouting.cpp#L37
to L141 is to be “transformed” to use boost::program_options

Difficulty: Easy
Urgency: First things first. This is first
I would like Sarthak to define the help message for each option. I think it will help him understand why we require what we require. (some things are obvious, but what is obvious for me its not obvious for all), If he has questions then in the appropriate issue he can ask.

I am creating an ISSUE for each parameter we think we might use and make a reference to this issue.
All the issues/parameter can be worked in parallel.
Due to time constraints some of them are to be commented out for implementation in a future release.

This will give us a general skeleton. And if something at the end results redundant, not implemented, then we can just delete it or comment it out.

Use boost program Options.
http://www.boost.org/doc/libs/1_58_0/doc/html/program_options.html
some examples:
https://github.com/boostorg/program_options/tree/develop/example

I suggest that to any boost library that is going to be used, to gain experience:

1. make a “fast read” to the boost documentation,
2. copy 2 or 3 small examples and execute them as they are
3. modify the examples a little, focusing on “how it could be integrated” into osm2pgrouting and “see what happens”

After running osm2pgrouting on the Greater London OSM data (listed below) I'm left with a bunch of ways in the ways table that have an identical node id for both the source and target. This makes those ways un-routable, even though the ways seem completely legit and aren't broken in OSM.

The only thing I can think of that may be triggering this bug is that the affected ways are so short (length values in the database of less than 0.00…).

Any ideas? I'd like to see this fixed but in the meantime I'd be happy to settle for a short-term workaround.

Further info

• OSM Data
  • http://download.geofabrik.de/europe/great-britain/england/greater-london.html
• Example way exhibiting issue:
  • GID 420764 (OSM_ID 165256657) in generated ways table
  • SELECT * FROM ways WHERE gid = 420764
• 354 ways with the same issue
  • SELECT * FROM ways WHERE source = target

I think Makefile.orig is not necessary anymore since osm2pgrouting uses CMake now.
Instead this causes troubles when building Debian packages.

post by mapBaker
Is it possible to set the target database schema using osm2pgrouting?
After some debate and troubleshooting, I've decided to host my OSM-based pgRouting data in the same database as the rest of my data, but want to use a different schema (one big issue was using dblink, which I can't get to work anyway).
However, osm2pgrouting doesn't expose the ability to specify the target schema.

osm2pgrouting/build/osm2pgrouting  -file russia-european-part-latest.osm -conf osm2pgrouting/mapconfig_for_cars.xml

Split ways
Creating tables...
Nodes table created
2create ways failed:
Types table created
Way_tag table created
Relations table created
Relation_ways table created
Classes table created
Adding tag types and classes to database...
Adding relations to database...
Adding ways to database...
ERROR: invalid byte sequence for encoding "UTF8": 0xd1
CONTEXT: COPY pgroute_ways, line 87620

Hello,

I just installed a brand new Ubuntu server 14.04 LTS (Thursty).
Installing the pakages via apt-get (postgres, postgis and pgrouting from instable PPA) worked like a charm.

However I'm fronting a strange error while trying to load data from an OSM xml.
Everything run fine until the "create topology" step.

$ osm2pgrouting -file "20140429_highways_overpass.osm" 
 -conf "/usr/share/osm2pgrouting/mapconfig.xml"   
 -dbname bd_routing  
  -user                     admin       
   -passwd xxxxxxx     
    -clean

(...)

Creating topology...
NOTICE:  PROCESSING:
NOTICE:  pgr_createTopology('ways',1e-05,'the_geom','gid','source','target','tru                    e')
NOTICE:  Performing checks, pelase wait .....
NOTICE:  -------> ways not found
Create Topology success

(...)

Please notice I don't run the command as postgres user, this is by design as our policy is to 'SET ROLE to postgres' once logged-in with 'admin' when superuser right are needed.

I managed to succesfully create the topology afterward using this command in PgAdminIII:

SELECT pgr_createTopology('ways',1e-05,'the_geom','gid','source','target','true')

So this might indicate that it just a wrong escaping problem when the command is run by osm2pgrouting so this could be fixed quite easily.

Don't hesitate to ask for more details (and sorry for my english, I'm french ;)
Best regards

Martin Hoffmann

Configuration:

Ubuntu 14.04 LTS (GNU/Linux 3.13.0-24-generic x86_64)
PostgreSQL 9.3.4 on x86_64-unknown-linux-gnu, compiled by gcc (Ubuntu 4.8.2-16ubuntu6) 4.8.2, 64-bit
Postgis 2.1 USE_GEOS=1 USE_PROJ=1 USE_STATS=1
PgRouting v2.0.0 (build 3) master (boost 1.54.0)

OSM Overpass query (pretty huge 326Mo) :

(provided for information only as this don't seems to be the problem)

`<osm-script>
  <osm-script output="xml">
    <!-- Selectionner toutes les relation de routes dans l'emprise-->
    <query into="cr" type="relation">
      <bbox-query e="7.823638916015625" into="_" n="48.372672242291294" s="47.39463076190644" w="6.686553955078124"/>
      <has-kv k="highway"/>
    </query>
    <!-- Selectionner toutes les way de routes dans l'emprise-->
    <query into="cw" type="way">
      <bbox-query e="7.823638916015625" into="_" n="48.372672242291294" s="47.39463076190644" w="6.686553955078124"/>
      <has-kv k="highway"/>
    </query>
    <!-- Réaliser une union des deux séléction et inclure tous les élément enfants-->
    <union>
      <item set="cr"/>
      <recurse from="cr" type="down"/>
      <item set="cw"/>
      <recurse from="cw" type="down"/>
    </union>
    <print mode="meta" order="quadtile"/>
  </osm-script>
</osm-script>

This question came up on the OSRM issues list and it generally has to do with postgres, routing, OSRM, lua, and might have some interesting ideas that can come out of it:
Project-OSRM/osrm-backend#1520

It also represents a use case for osm2pgrouting regarding turn restrictions that will need to be solved in osm2pgrouting.

-dbname <dbname>
specifics: required
Component of issue: #43
be consistent with psql options

--threads = yes/no default no
--multimodal yes/no default no
--multilevel yes/no default no

specifics: optional
specifics: make sure the options work and comment out for a future release???

Origin of issue
osm files can be big, users might have world, continent, country, states, county/municipalities, or might just have a small bbox download of osm data.
difficulty: Unknown but probably high
Urgency: yes, urgent, this version should work with any size of osm file.

Specifics: optional with default: 5432
Component of issue: #43
be consistent with psql options

I discovered that the length of a way is measured by the (air line) distance between the start point and the end point of that way.

So when importing a way like this: http://www.openstreetmap.org/browse/way/66437490 the resulting distance is way smaller than the real length of the way. I think that's because the start and end points are really close together.

I think it would be more reasonable when the length of a way is the sum of lengths of the splitted way. i.e. adding the length in the else case of OSMDocument.cpp line 155.

To be able to use multiple cores, probably using threads might do the trick, you might want to see how boost::threads works.
http://www.boost.org/doc/libs/1_58_0/doc/html/thread.html
Here are some examples of how to use them:
https://github.com/boostorg/thread/tree/master/example

One thread can be processing data (producer), and another thread (consumer) can be uploading to the database the data that has being finished processing.
So from the examples, you might want to have a more deeper look to the producer-consumer examples.
Difficulty: Unknown, probably from medium to high
Urgent: not so urgent, but if the code is designed in such a way that the two tasks can be performed one after the other, then probably the implementation of making the 2 tasks with threads will be easier.

-user <user>
specifics: required ??? can it have default values like psql???
Component of issue: #43
be consistent with psql options for user

Anyone had this problem on mac osx at

$ make

inside the build folder?

Is it possible to get osm2pgsql to export to a SQL file rather than assuming it has to connect to a DB?

Topic derived friom #64
Tags needed to detect "road" segments
Tags needed to assign default lua values, that are on roads (highway, residential, paved)
Tags needed to assign default lua values, that are on vertices (stop lights, barriers)
I mention default Lua values, because I think that if osm_id 's for edges and vertices are stored in the data base the lua values can also be stored in separate tables and by a sequence of joins the new lua values can be set up.

Hi,

I am using osm2pgsql and when finishing these three columns are empty in the ways table. It generates geometries, tables and everything but doesn't fill source, target and cost values. Here's the execution:

Split ways
Dropping tables...
Creating tables...
NOTICE:  CREATE TABLE / PRIMARY KEY creará el índice implícito «nodes_pkey» para la tabla «nodes»
Nodes table created
2create ways failed: 
NOTICE:  CREATE TABLE / PRIMARY KEY creará el índice implícito «types_pkey» para la tabla «types»
Types table created
Way_tag table created
Relations table created
Relation_ways table created
NOTICE:  CREATE TABLE / PRIMARY KEY creará el índice implícito «classes_pkey» para la tabla «classes»
Classes table created
Adding tag types and classes to database...
Adding relations to database...
Adding nodes to database...
Adding ways to database...
Creating topology...
NOTICE:  PROCESSING:
NOTICE:  pgr_createTopology('ways',1e-05,'the_geom','gid','source','target','true')
NOTICE:  Performing checks, pelase wait .....
NOTICE:  -------> ways not found
Create Topology success
#########################
size of streets: 123588
size of splitted ways : 271734
finished

In Export2DB::createTables the query " SELECT AddGeometryColumn('" + tables_prefix + "ways','the_geom',4326,'LINESTRING',2);" is returning a 2 so the execution says that "create ways failed" although having done it.

In Export2DB::exportWays I see that each way is inserted in the database but source, target and to_cost fields not inserted. Why aren't these inserted?

Finally I don't know where the NOTICE: -------> ways not found error is coming from and what it means. Maybe here is where the missing values are filled and it is not able to find the table?

Thank you very much.

I'm trying to build osm2pgrouting under Mingw64 and it compiles okay, however it seems to insist on installing the binaries in /usr/share/osm2pgrouting

My CMAKE looks something like this: the placeholders of variables are just so I can compile for different versions of things so ignore those -- but the DCMAKE_INSTALL_PREFIX seems to be ignored. I've used the same to build sfcgal and geos for example and that setting works fine on those.

cmake -G "MSYS Makefiles" -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX:PATH=${PROJECTS}/pgrouting/rel-osm2pgrouting-${PGROUTING_VER}w${OS_BUILD}${GCC_TYPE} -DBOOST_ROOT:PATH=${PROJECTS}/boost/rel-${BOOST_VER_WU}w${OS_BUILD}${GCC_TYPE} -DEXPAT_INCLUDE_DIR:PATH=${PROJECTS}/expat/rel-expat-${EXPAT_VER}w${OS_BUILD}${GCC_TYPE}/include -DEXPAT_LIBRARY:PATH=${PROJECTS}/expat/rel-expat-${EXPAT_VER}w${OS_BUILD}${GCC_TYPE}/bin/libexpat-1.dll -DBoost_USE_STATIC_LIBS=ON -DBoost_USE_MULTITHREADED=ON ../branches/osm2pgrouting${PGROUTING_VER}

--clean
specifics: optional (default value???) false (dont drop previously created tables)
Component of issue: #43
To allow false be the default, the incremental topology version of pgr_createTopology needs to be merged with pgRouting.

On Ubuntu 13.04 - raring:

Importing benelux subset ends in killed, using up all memory (2gig machine). fyi: Nominatim import of pbf file processed fine with postgresql settings.

top memory right before kill:

2537 postgres  20   0 2138m 1.8g  316 R  81.8 91.8   1:03.82 osm2pgrouting     

postgres@osm:~$ osm2pgrouting -file /usr/local/src/planet-benelux-130726.osm -conf /usr/local/src/mapconfig.xml -dbname routing -user postgres -clean 

host=127.0.0.1 user=postgres dbname=routing port=5432
connection success
Trying to load config file /usr/local/src/mapconfig.xml
Trying to parse config
Trying to load data
Trying to parse data
Killed

How much memory would one actually need to process this?

root@osm:~# dpkg --list | grep postg | grep -v java
ii  postgis                                  1.5.3-2ubuntu1                      amd64        Geographic objects support for PostgreSQL -- common files
ii  postgresql                               9.1+140                             all          object-relational SQL database (supported version)
ii  postgresql-9.1                           9.1.9-1ubuntu1                      amd64        object-relational SQL database, version 9.1 server
ii  postgresql-9.1-pgrouting                 2.0.0-rc1-ppa17                     amd64        Routing functionality support for PostgreSQL/PostGIS
ii  postgresql-9.1-postgis                   1.5.3-2ubuntu1                      amd64        Geographic objects support for PostgreSQL 9.1
ii  postgresql-client-9.1                    9.1.9-1ubuntu1                      amd64        front-end programs for PostgreSQL 9.1
ii  postgresql-client-common                 140                                 all          manager for multiple PostgreSQL client versions
ii  postgresql-common                        140                                 all          PostgreSQL database-cluster manager
ii  postgresql-contrib                       9.1+140                             all          additional facilities for PostgreSQL (supported version)
ii  postgresql-contrib-9.1                   9.1.9-1ubuntu1                      amd64        additional facilities for PostgreSQL
ii  postgresql-server-dev-9.1                9.1.9-1ubuntu1                      amd64        development files for PostgreSQL 9.1 server-side programming

postgresql error

2013-07-28 16:21:07 UTC LOG:  could not receive data from client: Connection reset by peer
2013-07-28 16:21:07 UTC LOG:  unexpected EOF on client connection

strace says:

...
read(4, "9586\" version=\"1\"/>\n\t<node id=\"6"..., 8192) = 8192
read(4, "n=\"1\"/>\n\t<node id=\"680886887\" la"..., 8192) = 8192
read(4, "ode id=\"680887060\" lat=\"51.92231"..., 8192) = 8192
read(4, "7345\" lat=\"51.918674\" lon=\"4.612"..., 8192) = 8192
read(4, "\"51.9152755\" lon=\"4.580735\" vers"..., 8192) = 8192
read(4, " lon=\"4.612746\" version=\"2\"/>\n\t<"..., 8192) = 8192
read(4, ".5918497\" version=\"1\"/>\n\t<node i"..., 8192) = 8192
read(4, "5935244\" version=\"1\"/>\n\t<node id"..., 8192) = 8192
brk(0x81dad000)                         = 0x81dad000
read(4, ".5969857\" version=\"1\"/>\n\t<node i"..., 8192) = 8192
read(4, "6095411\" version=\"1\"/>\n\t<node id"..., 8192) = 8192
read(4, "rsion=\"1\"/>\n\t<node id=\"680889170"..., 8192) = 8192
+++ killed by SIGKILL +++
Killed

What can I do to help locate, reproduce and fix this? Any information you need? Things to try out ? Love to assist.

-h -- help
specifics: help should show also if an unknown/required or any parameter is wrong, the help message should be displayed.
Component of issue: #43

The OSGeo LiveDVD build returned the following error: https://trac.osgeo.org/osgeo/ticket/1187

I suggest making them negative ie. wrong ways have negative value in one way scenarios

Hi!

I am kind a noob in all this geospatial stuff, but I have been trying to do this:

osm2pgrouting -dbname mydb -user myuser -passwd mypass -conf mapconfig.xml -file bilbao.osm 

But when it is executed I get the following error:

Create index add on source failed: ERROR:  relation "source_idx" already exists

Create index add on target failed: ERROR:  relation "target_idx" already exists

Create geom index on ways failed: ERROR:  relation "geom_idx" already exists

Create unique index on ways failed: ERROR:  relation "ways_gid_idx" already exists

Create Topology failed: ERROR:  function pgr_createtopology(unknown, numeric, unknown, unknown) does not exist
LINE 1: SELECT pgr_createTopology('ways', 0.00001, 'the_geom', 'gid'...
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

Looks like that it can't create the new topology.

Any help would be appreciated!

Thanks in advance!

Difficulty level: Unknown
Urgency: Before coding starts.
preconditions: After several ISSUES being marked as feature request .
How its going to be implemented: Based on how this tagging scheme works, we can decide how to handle the branching model:

• can be based on issues preconditions/postconditions?,
• based on difficulty?,
• a combination?
• Branches with meaningful names.

http://nvie.com/posts/a-successful-git-branching-model/

Label Handling on issues:
Discussion(black) -> feature request -> implementing -> testing -> implemented -> approved(green) -> merged

Discussion:
Use to discuss things like:
Difficulty level: easy, intermediate, hard
Urgency: for yesterday, as soon as possible
Preconditions: after issue#, #, #
Postconditions: before issue#, #, #
In parallel with: issue#, #, #, #
How it is going to be implemented. Algorithm / Classes / Structures etc.

Once we agree we tag it as feature request as well.

Implementing is a flag for us that Sarthak is working on the issue.
Testing is a flag for us that Sarthak is testing his implementation.
Implemented is a flag for us that Sarthak finish the tests.
Approved is a flag for Sarthak that we like what he did.
Merged is a flag for all that is being merged.

Note: This has been posted on the pgRouting TRAC wiki. Since I'm not sure it has been applied to the source code, I post it as a ticket:

Here is a patch for osm2pgrouting to import more then one file.

How to install

1. svn checkout -r 352 http://pgrouting.postlbs.org/svn/pgrouting/tools/osm2pgrouting/trunk osm2pgrouting
2. download the patch
3. cd into osm2pgrouting
4. patch -p0 -i append.patch
5. make
   How to Use:

for the first file :
osm2pgrouting -clean

for other files (except last)
osm2pgrouting -append

for the last file
osm2pgrouting -append -finalize

How it works:

you have to split a large osm file with osmosis like this way (the boundingboxes must overlap on all sides, maybe 0.1°)
./osmosis --read-xml europe.osm --bb left=14.0 right=14.6 top=48.5 bottom=47.8 --write-xml ./1116.osm
./osmosis --read-xml europe.osm --bb left=14.5 right=15.1 top=48.5 bottom=47.8 --write-xml ./1117.osm

or use osmosis with parameter --bb completeWays="yes", with no overlapping but splitting may take longer... its not testet

you can also define the boundingboxes for osmosis in a file like explained here http://wiki.openstreetmap.org/wiki/Osmosis/Examples
this patch also adds the original osm id to the ways table, and it adds the filename of the imported file

It seems to me that we need to define the processing work flow. For example:

• processing command line arguments
• reading data
  • what formats? what tools/libraries?
  • what tags
  • do we plan to use osrm lua scripting
  • how do we handle turn restrictions
• processing the data
  • what processing needs to take place
  • do we node it here or later in postgres with postgis/or pgr_nodenetwork
  • does the processing need to modify the node ids if yes how do we track the originals
• writing data to postgres
  • what are the tables that will get created: nodes, edges, restrictions, others?
  • should names be extracted into a separate table and let the edges point to that table?
  • what columns and types
• postprocessing in the database?
  • what needs to be done, why?
  • can it be done fast in c++ before it is loaded?

osm2pgrouting fails to import when PostGIS is version 2.x

Using the same file of #62
19195 out of 20399 values are less than 1,
the max value it has is 7806636.41134386

 select count(*) from ways where reverse_cost <1;
 count 
-------
 19195

select count(*) from ways where reverse_cost >=1 and reverse_cost < 100;
 count 
-------
   224

select count(*) from ways where reverse_cost >=100;
 count 
-------
   980

select max(reverse_cost), min(reverse_cost) from ways where reverse_cost > 100;
       max        |       min        
------------------+------------------
 7806636.41134386 | 537.270153633201

i am building on opensuse 13.2 64bit

when i make

it says

/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: cannot find -lpq
collect2: error: ld returned 1 exit status
make[2]: *** [osm2pgrouting] Error 1
make[1]: *** [CMakeFiles/osm2pgrouting.dir/all] Error 2
make: *** [all] Error 2

What i need to change?

boost.geomtery have various coordinate system here, which one to choose for osm data and do user have to be given an option to choose coordinate system .
If the user wants to choose which coordinate system he wants what do we need?

this is the cartisian model followed by osm.

could this crash be caused by only using integer for IDs? I guess now that osm_ids became larger than 2^31 the import tool should switch to bigint

jeff@city:/home/jeff/osm-data% ../src/osm2pgrouting/osm2pgrouting -conf ../src/osm2pgrouting/mapconfig.xml -file germany_ways.osm -dbname routing -user jeff -clean
.
.
.
Reference nd=1016498041 has no corresponding Node Entry (Maybe Node entry after Reference?)
Reference nd=829127429 has no corresponding Node Entry (Maybe Node entry after Reference?)
Reference nd=2070368715 has no corresponding Node Entry (Maybe Node entry after Reference?)
Reference nd=2073921025 has no corresponding Node Entry (Maybe Node entry after Reference?)
Reference nd=2073921025 has no corresponding Node Entry (Maybe Node entry after Reference?)
Reference nd=767876768 has no corresponding Node Entry (Maybe Node entry after Reference?)
Reference nd=2074526606 has no corresponding Node Entry (Maybe Node entry after Reference?)
Split ways
zsh: segmentation fault (core dumped) ../src/osm2pgrouting/osm2pgrouting -conf ../src/osm2pgrouting/mapconfig.xml

@aj07mm mentions in #59 about a value that is too large for an int, the code might be trying to store those values on an int4 and not on a int8.
This error might be independent of the architecture, but needs to be verified.

Joseph post

I'm trying to install osm2pgrouting. I have installed all the required packages and I also have changed the #include "libpq-fe.h" to #include postgresql/libpq-fe.h" in the src/Export2DB.h. However when I'm trying to do "make", I get this error:

Linking CXX executable osm2pgrouting
CMakeFiles/osm2pgrouting.dir/src/Export2DB.cpp.o: In function `Export2DB::~Export2DB()':
Export2DB.cpp:(.text+0x2ea): undefined reference to `PQfinish'
CMakeFiles/osm2pgrouting.dir/src/Export2DB.cpp.o: In function `Export2DB::connect()':
Export2DB.cpp:(.text+0x38c): undefined reference to `PQconnectdb'
Export2DB.cpp:(.text+0x3a2): undefined reference to `PQstatus'
CMakeFiles/osm2pgrouting.dir/src/Export2DB.cpp.o: In function `Export2DB::createTables()':
Export2DB.cpp:(.text+0x46f): undefined reference to `PQexec'
Export2DB.cpp:(.text+0x47f): undefined reference to `PQresultStatus'
Export2DB.cpp:(.text+0x49b): undefined reference to `PQerrorMessage'
Export2DB.cpp:(.text+0x4d1): undefined reference to `PQclear'
Export2DB.cpp:(.text+0x5f2): undefined reference to `PQexec'
Export2DB.cpp:(.text+0x602): undefined reference to `PQresultStatus'
Export2DB.cpp:(.text+0x618): undefined reference to `PQresultStatus'
Export2DB.cpp:(.text+0x636): undefined reference to `PQerrorMessage'
Export2DB.cpp:(.text+0x66c): undefined reference to `PQclear'
Export2DB.cpp:(.text+0x6fd): undefined reference to `PQexec'
Export2DB.cpp:(.text+0x70d): undefined reference to `PQresultStatus'
Export2DB.cpp:(.text+0x729): undefined reference to `PQerrorMessage'
Export2DB.cpp:(.text+0x75f): undefined reference to `PQclear'
Export2DB.cpp:(.text+0x7e7): undefined reference to `PQexec'
Export2DB.cpp:(.text+0x7f7): undefined reference to `PQresultStatus'
Export2DB.cpp:(.text+0x813): undefined reference to `PQerrorMessage'
Export2DB.cpp:(.text+0x849): undefined reference to `PQclear'
Export2DB.cpp:(.text+0x8cb): undefined reference to `PQexec'
Export2DB.cpp:(.text+0x8db): undefined reference to `PQresultStatus'
Export2DB.cpp:(.text+0x8f7): undefined reference to `PQerrorMessage'
Export2DB.cpp:(.text+0x92d): undefined reference to `PQclear'
Export2DB.cpp:(.text+0x9af): undefined reference to `PQexec'
Export2DB.cpp:(.text+0x9bf): undefined reference to `PQresultStatus'
Export2DB.cpp:(.text+0x9db): undefined reference to `PQerrorMessage'
Export2DB.cpp:(.text+0xa11): undefined reference to `PQclear'
Export2DB.cpp:(.text+0xa93): undefined reference to `PQexec'
Export2DB.cpp:(.text+0xaa3): undefined reference to `PQresultStatus'
...

I would like to use the area that workshop use. Mainly because workshop is based on that information, and the integrity of the workshop should remain intact.
Incremental insertions can be tested by inserting smaller bounding boxes of the workshop data.

@dkastl
The bounding box defined here:
http://workshop.pgrouting.org/chapters/installation.html#data
Doesn't correspond to the data that has the pgrouting-workshop repository when using:
sudo apt-get install pgrouting-workshop

1. Readme
2. man page
3. Website

Default config file doesn't contains classes for secondary_link and tertiary_link.
Both of them are widely used (secondary_link: 81.000+; tertiary_link:49.000+)