The following QGIS screenshot illustrates the problem (click for bigger version):

Some segments with wrong direction

You can see clearly that the line arrows do not all point in the same direction.

But don’t despair! My SQL skills are admittedly a bit rusty, but I managed to write a PL/pgSQL script that fixes the problem.

-- Wrapper for shortest_path() function to find the shortest route between two points
CREATE OR REPLACE FUNCTION dijkstra(
    geom_table varchar, source int4, target int4)
    RETURNS SETOF GEOMS AS
$$
DECLARE
    r record;
    path_result record;
    v_id integer;
    e_id integer;
    geom geoms;
    id integer;
BEGIN
    id := 0;
    FOR path_result IN EXECUTE 'SELECT gid,the_geom FROM ' ||
          'shortest_path(''SELECT gid AS id, start_id::integer AS source, end_id::integer AS target, ' ||
          'length(the_geom)::double precision AS cost FROM ' ||
      quote_ident(geom_table) || ''', ' || quote_literal(source) ||
          ' , ' || quote_literal(target) || ' , false, false), ' ||
          quote_ident(geom_table) || ' WHERE edge_id = gid '
        LOOP
            geom.gid      := path_result.gid;
            geom.the_geom := path_result.the_geom;
            id            := id + 1;
            geom.id       := id;
            RETURN NEXT geom;
        END LOOP;
    RETURN;
END;
$$ LANGUAGE 'plpgsql' VOLATILE STRICT; 

-- Returns records for the route from start to end with correct directions
CREATE OR REPLACE FUNCTION calc_route(
    geom_table varchar, start_id int, end_id int)
    RETURNS SETOF record AS
$$
DECLARE
    r record;
    id int;
    prev int;
    i int;
BEGIN
    prev := 0;
    id   := start_id;
    FOR r IN EXECUTE 'SELECT start_id, end_id, route.* ' ||
      'FROM ' || quote_ident(geom_table) || ' JOIN ' ||
      '(SELECT * FROM dijkstra(' || quote_literal(geom_table) || ',' || start_id || ', ' || end_id || ')) AS route ' ||
      'ON ' || quote_ident(geom_table) || '.gid = route.gid ORDER BY route.id; '
    LOOP
        IF (r.start_id = id AND r.end_id <> prev) THEN
            RETURN NEXT r;
        ELSIF (r.end_id = id AND r.start_id <> prev) THEN
            i           := r.end_id;
            r.end_id    := r.start_id;
            r.start_id  := i;
            r.the_geom  := ST_Reverse(r.the_geom);
            RETURN NEXT r;
        ELSE
            RAISE NOTICE 'error: record % % %', r.start_id, r.end_id, r.id;
            RETURN;
        END IF;
        prev := r.start_id;
        id   := r.end_id;
    END LOOP;
    RETURN;
END;
$$ LANGUAGE 'plpgsql' VOLATILE STRICT;

Sample usage:

DROP TABLE IF EXISTS result;
SELECT start_id, end_id, gid, the_geom INTO result FROM calc_route('network', 22353, 21587)
AS (start_id int, end_id int, id int, gid int, the_geom geometry);

As a result, here is a QGIS screenshot with all segments in the correct direction (again, click for bigger version)

All segments with correct direction

A note about line 59: this script assumes that pgRouting returns the segments in the correct order, which means that either the condition from line 50 or from line 52 evaluates to true. So, line 59 should never be executed. However, some people have reported on the pgrouting-users mailing list that the segments returned from pgRouting are not in the right order – in which case you would see the message from line 59.

pgRouting adds geospatial routing functionality to a PostGIS / PostgreSQL geospatial database. So, as a preliminary requirement, we have to start with installing PostgreSQL and PostGIS.

I’ve done this using MacPorts, so

$ sudo port -d install postgresql90 postgresql90-server postgis

If you like, you can also install pgAdmin3 via MacPorts, an administration program to PostgreSQL

To create a database instance, after install do

$ sudo mkdir -p /opt/local/var/db/postgresql90/defaultdb
$ sudo chown postgres:postgres /opt/local/var/db/postgresql90/defaultdb
$ sudo su postgres -c '/opt/local/lib/postgresql90/bin/initdb -D /opt/local/var/db/postgresql90/defaultdb'

When executing the last command from above, I remember I had some trouble with the postgres user that was created during installation. Check that the postgres user account can be executed using the su command, e.g.

$ sudo su - postgres

If not, make sure that the postgres account has a valid shell

$ sudo dscl . -create /Users/postgres UserShell /bin/sh

Note that the installation has created a startup item for starting postgresql90-server with launchd. It is disabled by default. Execute the following command to start the server, and to cause the server to launch at startup:

$ sudo port load postgresql90-server

As an alternative to launchd, you can also start the database server using:

$ /opt/local/lib/postgresql90/bin/postgres -D /opt/local/var/db/postgresql90/defaultdb

or

$ /opt/local/lib/postgresql90/bin/pg_ctl -D /opt/local/var/db/postgresql90/defaultdb -l logfile start

After starting the server, you might want to look at /opt/local/var/log/postgresql90/postgres.log to check if the server is running OK.

Now, let’s try to install pgRouting.

The pgRouting package is also available from MacPorts, but only an older version 1.03. So, I just went to www.pgrouting.org and downloaded the latest source package pgrouting-1.05.tar.gz from 2010/11/22.

However, you won’t be available to successfully build from this archive (at least not on Mac OS X…)! Instead, you will end up with a couple of “undefined symbols” when linking.

For solving this, go to the pgRouting GitHub repository instead. This issue explains the cause why the linking fails on Mac OS X. Fortunately, this issue has already been fixed, so download a current snapshot from the repository and try to build this one instead.

First, you need to edit cmake/FindPostgreSQL.cmake. Add the include path /opt/local/include/postgresql90/server
and the library path /opt/local/lib/postgresql90 to the file so that cmake is able to locate your PostgreSQL installation.

Then build pgRouting with

$ cmake .
$ make
$ sudo make install

You should end up with something like this

[100%] Built target routing
Install the project...
-- Install configuration: ""
-- Installing: /opt/local/lib/postgresql90/librouting.so
-- Installing: /usr/share/pgrouting/routing_core.sql
-- Installing: /usr/share/pgrouting/routing_core_wrappers.sql
-- Installing: /usr/share/pgrouting/routing_topology.sql
-- Installing: /usr/share/pgrouting/matching.sql

Finally, I hope my memory still serves me right:

$ createdb -U postgres -E utf8 template_postgis
$ psql -U postgres -d template_postgis -f /opt/local/share/postgresql90/contrib/postgis-1.5/postgis.sql
$ psql -U postgres -d template_postgis -f /opt/local/share/postgresql90/contrib/postgis-1.5/spatial_ref_sys.sql
$ psql -U postgres -d template_postgis -f /usr/share/pgrouting/routing_core.sql
$ psql -U postgres -d template_postgis -f /usr/share/pgrouting/routing_core_wrappers.sql
$ psql -U postgres -d template_postgis -f /usr/share/pgrouting/routing_topology.sql

Create a pgRouting enabled database using the new template_postgis template

$ createdb -U postgres -T template_postgis routing

That’s it! If you are new to pgRouting, you can find a good example about route calculation using pgRouting here.

Let’s take a closer look at the results of some different methods I’ve tried out. The color relief and the hillshade relief images were created with the following commands:

$ gdalwarp -te 29 39 31 41 SRTM30.tif clip.tif
$ gdaldem color-relief clip.tif palette.cpt color.tif
$ gdaldem hillshade clip.tif hills.tif -z 3 -s 111120

Color relief

Hillshade

One option for combining these two images is the hsv_merge.py script from Frank Warmerdam. This script merges the two images in a way where the Hue and Saturation come from the color bands, and the Value comes from the panchromatic band.

But as stated here, “[this approach] works ok, but usually turns vegetation from a deep forest green to a minty pistachio green. This is because vegetation is very reflective in the IR band, which the pan band covers.” Let’s take a look at the result of hsv_merge.py:

$ ./hsv_merge.py color.tif hills.tif merged.tif

Result of hsv_merge.py

As you can see very clearly, the resulting image doesn’t match well with the original color relief in the lower green regions. I didn’t find this result satisfactory, so I looked into whether ImageMagick can be of help here.

A very simple operation would be

$ composite -blend 60 color.tif hills.tif output.tif

but the composite image looks, well, a bit gray (no surprise here):

Simple blend operation

A much better approach consists of two steps: adjusting the gamma level of the hillshade image so that the resulting gamma-corrected hillshade has the RGB value (128, 128, 128) in the plain areas, followed by a lighting composition. I’ve used the “overlay” method below, but you can also experiment with the other lighting methods available.

$ convert -gamma .5 hills.tif hills_gamma.tif
$ convert color.tif hills_gamma.tif -compose Overlay -composite output.tif

Gamma-corrected hillshade

Result

Looks good doesn’t it? Note that the colors of the composite image match very well with the original color relief image.

Finally, note that applying any ImageMagick conversion leads to loosing the georeferencing in the TIFF image. To keep the georeferencing information, you can save the GeoTIFF metadata to a file, and then copy the metadata into a new image:

$ listgeo clip.tif > meta.txt
$ geotifcp -g meta.txt output.tif final.tif

After this, final.tif should be georeferenced (you can check this with gdalinfo).

#include <iostream>

template <long long u, int m>
struct S
{
    static long long const val = S<u/10, m%2+1>::val + ((u%10)*m)/10 + ((u%10)*m)%10;
};

template <int m>
struct S<0, m>
{
    static long long const val = 0;
};

template <long long u>
struct UIC
{
    static long long const val = u*10+(10-S<u,2>::val%10)%10;
};

int main()
{
    std::cout << UIC<21812471217LLU>::val << std::endl;
    return 0;
}

As one would expect, the output is 218124712173

This can be solved quite elegantly with a policy-based design. Take a look at the following (non thread-safe!) implementation:

#ifndef SINGLETON_HPP
#define SINGLETON_HPP

// Creation policies
template<class T> struct CreateWithIntParameter
{
    static T* Create()
    {
        return new T(m_intParameter);
    }
    static const int m_intParameter;
};

// Non-thread-safe singleton
template <class T, template<class> class CreationPolicy>
class Singleton
{
public:
    static T& instance()
    {
        if (!m_instance)
        {
            m_instance = CreationPolicy<T>::Create();
        }
        return *m_instance;
    }
private:
    Singleton();
    Singleton(const Singleton&);
    Singleton& operator=(const Singleton&);

    static T* m_instance;
};

template <class T, template<class> class C>
T* Singleton<T, C>::m_instance = 0;

#endif // SINGLETON_HPP

Here is a small example how to use it:

#include "singleton.hpp"
#include <iostream>

using namespace std;

class Foo
{
public:
    Foo(int a) : m_a(a)
    {
        cout << "Foo constructed" << endl;
    }
    void bar()
    {
        cout << "a = " << m_a << endl;
    }
private:
    Foo();
    int m_a;
};

template<> const int CreateWithIntParameter<Foo>::m_intParameter = 5;

typedef Singleton<Foo, CreateWithIntParameter> FooSingleton;

int main()
{
    FooSingleton::instance().bar();
    FooSingleton::instance().bar();
    return 0;
}

The output looks like this:

Foo constructed
a = 5
a = 5


I’ve tried to add a javascript file (jquery-1.3.2.min.js) to clearcase, and got the following response:

jquery-1.3.2.min.js is not a 'text file': it contains a line exceeding 8000 bytes. Use a different type manager (such as compressed file).
Type manager "text_file_delta" failed create_version operation.

Huh? Anyway, this can be solved by

$ cleartool chtype -nc compressed_file jquery-1.3.2.min.js


Change version manager and reconstruct all version for "jquery-1.3.2.min.js"? [no] y
Changed type of element "jquery-1.3.2.min.js" to "compressed_file".

Afterwards, the file can be checked in without problems.

For a simple example, consider the following scenario :
Assume a controller has one push button switch wired to an input, and one lamp wired to an output. The first time the button is pressed the lamp must come on. The next time the button is pressed, the lamp must turn off. On the next press the lamp comes on, etc. etc. Don’t forget to allow for the button to be released before it is pressed again.

Sounds easy, doesn’t it? However, often the required behavior is not so trivial (when we’d like to restore previous state, or when reactions depend on the active state in many orthogonal regions). In this case, I typically use a statechart design. IMO this method scales up very well to large and complicated systems.

A possible solution for our example looks like this: We have two orthogonal regions, one region with two states for button pressed/released and another region with light on/off.

As with many of the Boost libraries, boost::statechart is header-only and uses templates quite heavily. In general, the documentation is quite good, so don’t be afraid to read it. There is also an excellent tutorial for those just starting out, with plenty of examples.

So without further ado, here’s the source code that implements the statechart from above:

#include <boost/statechart/event.hpp>
#include <boost/statechart/state_machine.hpp>
#include <boost/statechart/simple_state.hpp>
#include <boost/statechart/state.hpp>
#include <boost/statechart/transition.hpp>
#include <boost/mpl/list.hpp>
#include <iostream>

using namespace std;

namespace sc = boost::statechart;
namespace mpl = boost::mpl;

struct EvPressButton : sc::event<EvPressButton>
{
  EvPressButton()
  {
    cout << "Button is pressed" << endl;
  }
};

struct EvReleaseButton : sc::event<EvReleaseButton>
{
  EvReleaseButton()
  {
    cout << "Button is released" << endl;
  }
};

struct EvToggleLight : sc::event<EvToggleLight> {};

struct Active;
struct Switch : sc::state_machine<Switch, Active> {};

struct ButtonReleased;
struct ButtonPressed;
struct LightOff;
struct LightOn;

struct Active: sc::simple_state<Active, Switch,mpl::list<ButtonReleased, LightOff> > {};
struct ButtonPressed : sc::state<ButtonPressed, Active::orthogonal<0> >
{
  typedef sc::transition<EvReleaseButton, ButtonReleased> reactions;
  ButtonPressed(my_context ctx) : my_base(ctx)
  {
    post_event(EvToggleLight());
  }
};

struct ButtonReleased : sc::simple_state<ButtonReleased, Active::orthogonal<0> >
{
  typedef sc::transition<EvPressButton, ButtonPressed> reactions;
};

struct LightOff : sc::simple_state<LightOff, Active::orthogonal<1> >
{
  typedef sc::transition<EvToggleLight, LightOn> reactions;
  LightOff()
  {
    cout << "Light is off" << endl;
  }
};

struct LightOn : sc::simple_state<LightOn, Active::orthogonal<1> >
{
  typedef sc::transition<EvToggleLight, LightOff> reactions;
  LightOn()
  {
    cout << "Light is on" << endl;
  }
};

int main()
{
  Switch sw;
  sw.initiate();
  for (int i = 0; i < 5; i++)
  {
    sw.process_event(EvPressButton());
    sw.process_event(EvReleaseButton());
  }
  return 0;
}

The output:

Light is off
Button is pressed
Light is on
Button is released
Button is pressed
Light is off
Button is released
Button is pressed
Light is on
Button is released
Button is pressed
Light is off
Button is released
Button is pressed
Light is on
Button is released

Which looks about right, I think.

I found that you have to do some additional things for building, running and debugging the executable project in Eclipse (note that I’m doing this on Linux using CDT 4.0.3):

Define your shared library’s project as a reference for your application. In order to do so open the project properties of the executable project, go to project references and select the shared library project (where in my case “shared” is also the name of the shared library).

In the project settings of your executable project, add the shared library to the linker settings, as shown in the following screenshot:

Bear in mind that the library search path must be adjusted every time when switching between Debug and Release versions.

In the project settings of your executable project, add the working directory of your shared library project to the compiler include path, as shown in this screenshot:

Now you should be able to compile your application, but in order to run it from within Eclipse, there’s a last step that needs to be done:

In the run dialog (top menu Run -> Open Run Dialog), define the LD_LIBRARY_PATH variable as ${workspace_loc}/shared/Debug/, as shown inthe following screenshot.

Again, this needs to be adjusted when switching between Debug and Release versions.

All this is very tedious stuff, so hopefully this will be a bit improved in the upcoming CDT releases.

Put the statement

set follow-fork-mode child

in the .gdbinit file, located in the project work directory.
Now, setting some breakpoints in the code of the child process will cause gdb to halt execution.

Btw, I’ve looked for a corresponding GUI option in the debug dialog (CDT version 4.0.3), but I found none. So it seems that creating a .gdbinit file is currently the only solution for this.

Unfortunately, Valgrind currently only supports Linux. At least the porting plan states that enabling support for the x86/darwin platform is on the top priority list. I’ll keep my fingers crossed