Cross compiling OTB

Recently, I compiled OTB for Windows 7 from a Fedora system using cross compiling tools. There are good support for the Microsoft compilers already in OTB project. But I used MinGW tool-chain via MXE packages. MXE is a cross compile environment supported on any Linux machine.

Already OTB gives packages for windows via OSGeo4W distribution, There is also an NSIS installer generated daily.

So Why do you need to go for GCC tool-chain on Windows.? Why should I cross-compile instead of compiling it on windows ? What is wrong in using visual studio?

Okay. I am not a fan of visual studio and MSVC++ compilers. It maybe very good but I am not a fan. That doesn’t mean there is fundamentally something wrong with that compiler. So I prefer GCC. Well, you can say loud: “news flash fella.. GCC a’int that great either”. But for me it was less painful experience.

MXE is great for generating windows binaries from a Linux box. It is not hard to setup up. It does not use any complex external dependencies. Best of all the build system of mxe is simple and elegant.

cloning the source and running just “make” command will start building packages. You can run “make boost” to build the cross compile tool-chain and use it to download and build boost. It is not a super build system but ‘the’ superbuild.

Next I will try to explain some steps on building OTB.


libkml development (part 3)

Good things

libkml was released under an  opensource license. Google paid their engineers to implement a reference implementation of KML 2.2 standard. There is an OGC standard for KML developed by Google.

LibKML is a standard and the only library to process kml files.

Bad things

Since they don’t accept external contributions, the official library is much worthless. They might use some non-open source version in their products. They see libkml without any value so far.

As the license allows us to make modification and continue development, anyone can work on it. And I am not selling this library and as far as I can tell, nobody is.

There are now a lot of version of forked either from googlecode or github. So anyone who wants to make it into a product is confused. If he ask google there is no response. Since there is no “upstream” in this case, library is ruined for good. No fork developers can claim anything on the work.

As the library is inactive and dead this will affect the KML standard on OGC. But maybe that is what the company is so afraid of. What if the KML standard gets better with the help from open source community.

This is a very good strategy on google side to destroy a market. You develop something make it open source and let it rot there.

The minute we tried to use the forked version with other projects they jumped and stopped it. One of them made a huge commit into the repo changing a lot of Visual studio solution files. Anyone could see that it was auto-generated by opening the solution file in the Visual Studio IDE. Also they did add a file into their repository.

Well, If I check the commits page, there is a very recent activity in their repository! Really..?

libkml development (part 2)

Back to the story..

There was an open issue on libkml’s bug tracker asking about project status. The best thing happened in that discussion was Sebastiaan Couwenberg encouraged me to continue development as much I can. He can use the work in offical debian packaging. This was more of an incentive to me and forced to put some more time. So I tried to contact with other fork developers on github about unifying the efforts on development. Sebastiaan and I worked together to finally make an Release Candidate(RC). Since we want to get some feedback from users of libkml, we did an rc0 of libkml 1.3.0!. The next is to get people involved. Let them try the new version and come up with some features and bugs if any.. I ask/advertise other projects about the fork. GDAL was on the top of list as it includes a libkml driver which indeed uses the google/libkml version.

To our surprise, Google engineers came up with a “renewed” interest in the development and asked if it is not too late… we can unify the development efforts.  There was some momentum on the google/libkml bug tracker for a day or two. Personally, I am glad about this change because their decision was to keep the current efforts!.

Google needs a CLA for every contributor and asked if that is okay for us. We don’t had any objection and I tried to keep all my libkml efforts out of work perimeter. I could ask my company for some spare time but then I need to get the corporate CLA. It is not that hard, but I prefer to keep the work open.

After a day or two, there was the same silence. The response from google was they are pondering things internally and I should wait. Well, I wasn’t waiting around and this was supposed to be part-time thing. Silence from google was awful. But this can’t be a surprise. Especially to me.!

Finally, everything works as normal. The fork still exists and I didn’t closed it yet. Google never responded back..


libkml development

For an year ago, I started working on libkml library. My primary interest is to cleanup the build system and change it to much powerful cmake. Along the way, I fixed some bugs and cleaned all embedded third party sources.

Initially I forked the google/libkml from github and did everything on the fork. I was thinking..Hey,  I can do a pull request to upstream and it will be simple and just fine. The development activity from the side of google is almost nothing. So during my long vacation… libkml got better.! I stopped caring about whether changes will be merged into upstream.

The “idea” of me taking in charge of development activity is not to replace or take over the library.  It was not used much in my day work. It was not to donate most of my free time into open source community.  It was definitely not to get work with Google. It just happened like that..

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 ossim_trunk

I checkout the trunk branch(active development) but you checkout a release branch or a specific tag. See ( [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 []


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 which shows up a dialog shown below parameters) 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 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.