Threat images for Udig 1.1

As some of you might know Udig doesn't threat images very well and loads them directly in memory and... and...

In Italy we have some black & white maps that have a particular compression that doesn't work at all.

Ortophotos are usually large and in jpg format, which in memory expand to infinity. And the OutOfMemory complains.

So what?

Until udig 1.2 wil not be ready we need some workarounds and the gdal friends come and help.

After lots of tests, here is my best bid:

1) If you have a jpg, convert it to geotiff.

2) If the image is black & white, convert it to greyscale (in case of indexed image give you trouble as they did for me)

For these two operations you can use the gimp.

Tile the image and create overviews:

• gdal_translate -co "TILED=YES" -co "COMPRESS=PACKBITS" imagename.tif finalimagename.tif
• gdaladdo -r average finalimagename.tif 2 4 8 16 32 64
  

That should be enough to make things work.

If someone can do it better, let me know. Glad to be corrected.

-------------------------------

UPDATE form comment by Andrea Borruso to do everything in gdal:

To generate 8 bit maps:
gdal_translate -scale in.tif out.tif

To make it again 1 bit and viewable in uDig:
gdal_merge -co NBITS=1 -o dst.tif src.tif

Advanced console using under windows vista

I have to say that I am pretty happy with my console environment under windows. I mean, it will never be like in linux, but that was never going to happen in Macosx also, so no big change here. 

I m currently using Console2 loading Cygwin's bash as shell.

Everything worked fine until I didn't try to open a tiff file with imagemagik's display command, which resulted into a: Can't open display...

Being not so used to cygwin, I had some problems to get those things working. Inspired by the startxwin.sh script contained in the xinit cygwin package, I got it working by adding the following to my cygwin's home .bashrc:

rm -rf /tmp/.X11-unix

export DISPLAY=127.0.0.1:0.0

if [ "`ps |  grep XWin`" == "" ];

then

    XWin -multiwindow -clipboard -silent-dup-error &

fi

Cheers...

BSOD, the blue screen of death

Hell, I'm no more used to it.

I'm really no more used to it.

A month ago in HydroloGIS we decided to make me use windows on my freetime pc, in order to be able to give better support to JGrass users. Up to that point I had always used linux at work and Mac at home... 

One week ago the sparkling new Dell XPS m1330 arrived.

Today, after one week, I got my first BSOD. Reboot, again BSOD. Visible irritated by the windows application that wants to help me guessing what could be the problem, I start over again and again, until I note that it happens due to a wirless network card problem. 

It got solved... but hell, I'm no more used to it.

The only good point in all this story is that there are a huge amount of good FOSS applications for windows now. Very good. And whatever is not there is more or less in cygwin. 

v.addattributes or... have you ever seen the rain?

As some of you might know, we are working on large hydrologic model that is going to be put into JGrass following the openmi standards.

One of the issues we found is that to have a good feeling of the spatial distribution of data over the studied basin. With raster data that has never been an issue (in fact the issue is the space taken by the rasters :)), but how to be quick when you have resulting values placed in the baricenter of a basin?

Usually you get a nice matricx of values that you then have to somehow push into the attributes table of a shapefile in order to have some visual result of your calculus. But what if the values are temporal???

Copy and paste the result of every timestep into a shapefile? Hmmm.... no way!

We now have a module in JGrass that is called v.addattributes and I'm gonna show you an example of it.

Assume I have a file that contains a line for every timestep of my model and that line is formatted like the following: 

idbasin1, value11, value12, idbasin2, value21, value22,... idbasinN, valueN1, valueN2

The values could be any numeric thing, we could have 1, 2, ...n values.

In my example I have a file with interpolated rainvalues in the baricenters of these basins:

The file looks like:

1739.0 0.0 1535.0 0.0 1655.0 0.0 2157.0 0.0 1930.0 0.0 1801.0 0.0 1460.0 0.0 632.0 3.684153909618608 906.0 ...

1739.0 0.4793081233266918 1535.0 0.048572411261128046 1655.0 0.6070006443236106 2157.0 0.44196721516998566   ...

1739.0 0.0532564581474102 1535.0 0.0 1655.0 0.042013300835839144 2157.0 0.04910746835222063 1930.0 0.0909374550600321   ...

1739.0 0.5304998409078074 1535.0 1.0377122085218624 1655.0 0.7508780110017237 2157.0 0.6222435955068898 1930.0   ...

i.e. idbasin1, rainvalue1, idbasin2, rainvalue2... and so on

With the following script I am now able to merge the two informations, based on the basin ids. 

jgrass { 
       v.addattributes
  --iflayer-infeatures "bacini_bz_idlikedb0"
  --itscalar-attributes "C:\\zcontainer\\TMP\\THEBIGTEST\\rain-allbasin.csv"
  --oshapefile-outfeatures "C:\\zcontainer\\TMP\\THEBIGTEST\\testoutput\\test"
  --joinfield "NETNUM"
}  

The field used to join the informations has to be defined as a parameter, in this case NETNUM.

The result is a shapefile for every time step that the model runs for. The shapefile will have a new field (by deafult called new_0, new_1...) containing the information. In this case it is just one field containing the rain values, but could be as well more fields as forexample the temperature in different elevation bands for every basin.

The result is quite nice, can you see the strom moving in the following three screenshots?

Timestep 1:

Timestep 2:


Timestep 3: