Dilemma of thrid party libraries

I assume you might have some experience with compiling applications and or libraries from source code. Well, it doesn’t matter your experience is good, bad or worse. Just having some experience is enough for me.

Unless we are taking about simple applications or as the trend is to call them Utilities( biting teeth and expanding my cheek to a side as I spell) you have to deal with some other libraries that must be installed properly before you start configuring your application or maybe even you fire-up your OS !!. So I am not specific about libraries here. So lets disguise them with alphabets. A,B,,,, ZZ (yes two Z’s not a typo here. you may have AA, AB and so on…)

The application you want to install is A which depends on other libraries say B, C & D. and each of it depends on other or new ones.  So lets call all of them expect A as third party libraries.

Now to deal with these so called third party libraries, there are two ways.

1. List them in a README or wiki page and let user fight for the existence of your library on their system.
This way you have a clean plate in your code repository and your users learn a lot. Okay, I said in a much nicer way rather than saying let them suffer. Or it should be hard to install because it was hard to write or something else that’s mean !!. No we can’t turn away to users who want to try our code.

Now As true as the famous chaos theory, a small commit/change in the dependent libraries may result in total disaster on your inbox first thing in the morning. Now you can stop your users from writing these long mails by maintaining a copy of third party libraries in your source tree. So you get the mess and they have the pretty!!. What a wow deal. Isn’t it?

That deal is our second option for third party libraries

2. Maintaining a copy of them with your source code.

So the second option is a good one for two other reasons.
a) prevent extinction by natural disasters ( no funding, loss of interest by developers, etc..).
b) Maintain stability of your code to some extent.

Il fait bonne!! We move on to fixing bugs, writing docs, adding enhancements and all is well.

So what’s wrong with this model? Nothing.


And the summer is gone. You are creating package for linux, windows, OSX.. In the latter two platforms people dont care, All that means by package is an easy installation. In linux distro there are policies and rules for making a package official. I am all for having such governance for adding packages and mentioning it for presenting the dilemma

So the copies of third party libraries that we maintained comes back in the play. The packagers don’t want these for several good reasons. (Yes “reasons” with plural). One is to use efforts of existing packages and encourage developers to provide a package so that it can be used in A and other libraries.

But we cannot go back to option 1 always. because a library X in the list of third parties is inactive for years or have some patches exclusively for library A and developers of X of course don’t want to include these patches.

So this is promised dilemma of including third party libraries in your source code.

Building OSSIM library from source


, , ,

  • Introduction

I was thinking a long time ago to write a HOWTO for building OSSIM. Unfortunately it didn’t happened. One reason for not writing is that OSSIM wiki has some tutorials and wiki pages dedicated for this purpose.
So,  everything is there.. all you need to do is install a couple of libraries which by the way are available via package manager in every linux distro. (cmake, geotiff, jpeg, png, zlib, qt, ffmpeg). Then configure using cmake and run make, and finally make install!.


Well, cmake configure won’t work straight away with OSSIM. It fails with a bunch of error messages and these are not that helpful and a bit cryptic for a new user. But Once you set the proper module path then nothing to worry.

So What is the big deal with a new HOWTO? It seems trivial or maybe redundant.!. There is already enough material from developer team. Anyway today I decided to overcome these inner voice and here we are..

Do not confuse with another library with same name. This happened recently on OSSIM list

I will start by installing dependencies for OSSIM , checkout sources, cmake configure, build, test and finish by installing OSSIM.

  • Install dependencies

OSSIM requires some external libraries for reading and writing images. For convenience, I will show how to install them on Ubuntu and Fedora. If you are using another distro, then please find the correct package manager and library names(see the difference in Ubuntu vs Fedora)

For Ubuntu:

sudo apt-get install -f subversion cmake libgeotiff-dev libtiff-dev libpng-dev libjpeg-dev zlib-dev libopenthreads-dev

For Fedora:

sudo yum install -y subversion cmake libgeotiff-devel libtiff-devel libpng-devel turbojpeg-devel zlib-devel OpenThreads-devel
  • Download OSSIM

You can download OSSIM as compressed file (zip/tar). but we are not going to do that. We checkout it using subversion. I checkout my sources into a sub directory in my home (~/packages)

cd ~/packages/
svn co http://svn.osgeo.org/ossim/trunk/ ossim_trunk

I checkout the trunk branch(active development) but you checkout a release branch or a specific tag. See (http://svn.osgeo.org/ossim/ [branches]/[tags])

  • Configure

All configuration and build files are kept in a seperate directory. This is not mandatory in case of OSSIM library and cmake does not prevent in-source-builds. But we do this to have clean source tree.

mkdir ~/packages/build-ossim && cd ~/packages/build-ossim

OSSIM library sources are inside OSSIM sub-directory. ossim_trunk directory which we checked out contains a lot of other libraries such as ossimPlanet, ossimPredator, ossimPlanetQt, ossimGui etc.. We don’t need them to build OSSIM. But the vice-versa is not true.

So we run cmake in the OSSIM sub-directory (~/sources/ossim_trunk/ossim)
Usually running cmake with default option is as easy as:

cmake ~/packages/ossim_trunk/ossim

But in case of OSSIM this command gives a bunch of error messages as I explained in the introduction part. You need to update cmake module path. (CMAKE_MODULE_PATH)

Now, Where are these files? Why are they not included in OSSIM? Why can’t they be auto-detected during configure?
If you are asking above questions, I can try to answer.

Q. Where are these files?
A. These files are in the ossim repository!. They are inside ossim_trunk/ossim_package_support/cmake/CMakeModules

Q. Why are they not included in OSSIM?
A. Maybe(yes!. I said I can try) ossim developers don’t want to have take up space inside the sources!

Q. Why can’t they be auto-detected during configure?
A. Yes. I am there with you for this. But it is up to ossim developers to make this happen. Even though a patch seems trivial.

cmake ~/packages/ossim_trunk/ossim -DOSSIM_MODULE_PATH=~/packages/ossim_trunk/ossim_package_support/cmake/CMakeModules
  • Build

Start building library using make

  • Testing

Test if everything is fine before installing. Here I run ossim-info on a sample tif image available with OSSIM.

./ossim-info ~/packages/ossim_trunk/ossim_package_support/images/reference/earth.tif


image0.band0.max_value:  255
image0.band0.min_value:  1
image0.band0.null_value:  0
image0.band1.max_value:  255
image0.band1.min_value:  1
image0.band1.null_value:  0
image0.band2.max_value:  255
image0.band2.min_value:  1
image0.band2.null_value:  0
image0.driver:  ossim_tiff
image0.entry:  0
image0.geometry.decimal_degrees_per_pixel_lat:  0.133234641006662
image0.geometry.decimal_degrees_per_pixel_lon:  0.133283968900407
image0.geometry.decimations:  (1,1) (0.5,0.5) (0.25,0.25) (0.125,0.125) (0.0625,0.0625) (0.03125,0.03125) (0.015625,0.015625) (0.0078125,0.0078125) (0.00390625,0.00390625) (0.001953125,0.001953125)
image0.geometry.gsd:  (14820.517849692,14815.032831983)
image0.geometry.image_size:  (2701,1351)
image0.geometry.ll_lat:  -89.933382679497
image0.geometry.ll_lon:  -179.93335801555
image0.geometry.lr_lat:  -89.933382679497
image0.geometry.lr_lon:  179.933358015549
image0.geometry.meters_per_pixel_x:  14820.517849692
image0.geometry.meters_per_pixel_y:  14815.032831983
image0.geometry.projection.central_meridian:  0
image0.geometry.projection.datum:  WGE
image0.geometry.projection.elevation_lookup_flag:  0
image0.geometry.projection.ellipse_code:  WE
image0.geometry.projection.ellipse_epsg_code:  7030
image0.geometry.projection.ellipse_name:  WGS 84
image0.geometry.projection.false_easting_northing:  (0,0)
image0.geometry.projection.false_easting_northing_units:  meters
image0.geometry.projection.major_axis:  6378137
image0.geometry.projection.minor_axis:  6356752.3142
image0.geometry.projection.origin_latitude:  0
image0.geometry.projection.pcs_code:  4326
image0.geometry.projection.pixel_scale_units:  degrees
image0.geometry.projection.pixel_scale_xy:  (0.133283968900407,0.133234641006662)
image0.geometry.projection.srs_name:  EPSG:4326
image0.geometry.projection.tie_point_units:  degrees
image0.geometry.projection.tie_point_xy:  (-179.93335801555,89.9333826794967)
image0.geometry.projection.type:  ossimEquDistCylProjection
image0.geometry.target_rrds:  0
image0.geometry.tie_point_lat:  89.9333826794967
image0.geometry.tie_point_lon:  -179.93335801555
image0.geometry.type:  ossimImageGeometry
image0.geometry.ul_lat:  89.9333826794967
image0.geometry.ul_lon:  -179.93335801555
image0.geometry.ur_lat:  89.9333826794967
image0.geometry.ur_lon:  179.933358015549
image0.lr_x:  2700
image0.lr_y:  1350
image0.number_decimation_levels:  10
image0.number_input_bands:  3
image0.number_lines:  1351
image0.number_output_bands:  3
image0.number_samples:  2701
image0.overview.type:  ossimTiffTileSource
image0.radiometry:  8-bit
image0.type:  ossimTiffTileSource
image0.ul_x:  0
image0.ul_y:  0
number_entries:  1
  • Install OSSIM
sudo make install

This will install ossim usually to /usr/local.

Done!. Comments or suggestions are most welcomed.

Last Updated: 01/11/2014

Importing raster maps in GRASS location


, ,

GRASS stores data in the form of location and mapset. Location Wizard avaialble in Startup will allows to create your own location


A location is defined by its coordinate system, map projection, datum and geographical boundaries. The subdirectories and files defining a location are created automatically when GRASS is started the first time with a new location. Different location have its own CRS defined by user.


Each location can have any number of mapsets. A Mapset is a location’s subdirectory. A new mapset can be added at GRASS startup. A default mapset “PERMANENT” is automatically created when creating a new location.

Once the Location/Mapset is created you can import raster map using File Menu.

File -> Import raster data -> Coomon formats import [r.in.gdal]


Import Tool


Importing data without knowing location information

The above method will only work if you are aware of the projection, datum and geographical extent of the data you have. If you only have data and need to import into GRASS for visualization and do further analysis, GRASS allows to create a new location from the metadata associated with the raster maps. For this you need to setup a arbitrary location xy using location wizard or open up a location in sample data available from here.

From GRASS shell  issue the command r.in.gdal which shows up a dialog shown below

r.in.gdal(required parameters)

r.in.gdal(required parameters)\

Specifying Optional Parameters

Optional parameters

Optional parameters




Restarting GRASS into new Location

select newly created location “mylocation“. You can see a default mapset “PERMANENT” is created automatically

starting grass in new location

starting grass in new location

Your new map is already available in the mapset. You can view it using Layer Manager for visualization

Happy grassing

Installing GRASS GIS on Ubuntu


, , ,

GRASS GIS 7.0 is the current development (unstable) version in the GRASS GIS family. Here is a set of notes on how to build it from source on Ubuntu 12.04 LTS/ Linux Mint 15

Package Requirements

sudo apt-get -y install flex bison libfreetype6-dev
libnetcdf-dev libproj-dev libfftw-dev libreadline-dev
netcdf-bin liblapack-dev libwxgtk2.8-dev sqlite3
libpq-dev libavcodec-dev subversion libcairo2-dev

Get source code

svn checkout https://svn.osgeo.org/grass/grass/trunk grass_trunk

Minimal Install

./configure --with-freetype-includes=/usr/include/freetype2 --with-freetype
sudo make install

Full Install

If you wish to install GRASS with liblas support. You need to compile it manually and builds clean on ubuntu 12.04 LTS.

Download libLAS from OSGeo Download Site


Building libLAS

1. Untar the file
2. Run cmake
3. Install

tar -xzvf libLAS-1.7.0.tar.gz
cd libLAS
sudo apt-get install libboost-system-dev
libboost-program-options-dev libboost-thread-dev
cmake .
sudo make install

Configuring GRASS GIS with all options

./configure --with-freetype-includes=/usr/include/freetype2 \
--with-postgres-includes=/usr/include/postgresql \
--with-postgres --with-readline --with-nls --with-blas \
--with-lapack --with-wxwidgets --with-sqlite --with-geos \
--with-mysql-includes=/usr/include/mysql \
--with-mysql --with-netcdf --with-liblas --with-freetype

configuration summary


Check your configuration settings and if you are satisfied you can build GRASS now.

build summary

build summary

Installing GRASS GIS

sudo make install

This will build and install GRASS under /usr/local/grass7.0svn. If you wish to install in a different location specify –prefix=/path/to/installdir

along with other configuration options

Happy grassing


Get every new post delivered to your Inbox.