Sensor Web, Geoprocessing, Security & GeoRM, Geostatistics, Semantics, 3D, Ilwis, Earth Observation


December 12th, 2011 @ 10:01 by Martin Schouwenburg
Posted in ILWIS

Though ILWIS was in theory multilingual from the 2.0 version it was hardly used. I believe there were a (partly?) Italian version and partly Spanish version but they never ended up in the release version and/or were maintained. In the 3.7 this for the first time changed. Thanks to the work of Robin Prest and the money from the Geonetcast project a french translation of the user interface could be made.

The work of mr Prest made me also realize that the existing translation system was cumbersome and difficult to maintain. Oh, it worked, the results are ok. But it is more work than needed and difficult to track changes. Furthermore I found is as a programmer also quite annoying. Basically I had to touch multiple files when adding a string in the code. So one of the goals for the 3.8 was a more comprehensive translation system.

From the GeontetCast project the clear whish was there to have a Spanish and Portugese translation. So it was reasonable to spend some time to make this easier

I had a few goals with the new translation system,

  • The translator should have to touch as few files as possible.
  • The programmer should have to touch as few files as possible
  • Maintainance should be easy
  • The translation files can be changed without needing the change anything in ILWIS.
Fortunately I had come across the Qt platform. For some time I am pondering how to move the Ilwis code base from Windows/MFC to something more modern and platform independent ( enough stuff there for another blog) and in this context I came along the Qt framework. Apart from other nice things they had a suitable translation system in place that I adopted with some modifications for Ilwis.
What basically happens it that every “translateable’ expression in the code is compared to a lookup table that is loaded at startup time of ILWIS. If there is a translation, it will choose the translation. If not it will use the original English phrase. Internally, Ilwis only uses English. The advantage of this system is that I can extend Ilwis without needing to update the translation files each time. Incomplete translation files will simply lead to more non-translated English in the UI. Not ideal, but much better than having nothing at all. Once in a while you update the actual translation files and then everything is cool again.
So how does translating ILWIS works? It is very simple.The language files exist inside a folder in the instalation folder of ILWIS : Resources\Strings. At the moment you will see there a number files with the extension .fr and .sp. French and Spanish translations ( I am not 100% sure if the spanish is already there in the beta-2, it is now). For each language there are three files (I take french as an example)., and From a technical point ‘Men’ and “Dsc’ could probably be merged but I’ll leave it as they are not that big anyway.
  • Men contain the texts of all the menus except for the operations menu. So when you translate ‘Men’ you will get a translation of all the menus. The men file consists of a number and a string. Each menu item is coupled to the number, and through the number it can find the string. This is a different organization than the ‘string_table’ file(see later) but there are technical reasons for that (never mind). When translating the file take care that the special signs (e.g. ‘&’) als end up in the translation. They have a meaning. The ‘Men’ file is not very large and can easily be translated
  • Dsc ( short for description) is a direct companion of the ‘Men’ file. Basically it contains the description/short explanation of the menu commands that appear on the status-bar below ilwis windows. it is structure and numbering are identical to the Men file.
  • The big translation table is the ‘String_Table’ file. it contains ‘the rest’. So all the forms, operation menu, windows etc.. The structure of this file is different. The file consist of a pair of strings separated by a ‘|’. For example  “Invalid Map|Mapa Incorecto”. The software, internally, knows of the first english string and simply looks it up in the table constructed of this file to see if their is an (translated) alias. If so, great, it uses it. If not, it will use the internal english version. Note that when translating these texts it is very important to take over all the special symbols. Particual the ones marked with % ( e.g. %S,  %i etc. These are, during execution, filled with internal values. So for example a string “Adding File %S” might become “Adding File MyMap” because that is something that was happening during execution.
    This table is quite big, at the moment around 3700 entries. Not difficult to translate, simply a lot of work,
That is all there is need for translating ILWIS to a ‘local’ language. Ilwis translations have their limitations. When the internals of ILWIS were designed, many years ago, Unicode was in its infancy. It was not considered and still isnt part of Ilwis. So translations are limited to alphabets that uses the extended Ascii table. An annoying limitation these days but it is very difficult to change that (probably for a rewrite of Ilwis).
Ok, nice that we can translate things. But how do we activate a translation? Well, Ilwis contains a form that most people don’t seem to be aware of , the preferences form (under the file menu). In that form you have the ‘General’ page in the tree. That looks like this
In the form you can indicate which language files should be used (based on extension). In this example I have choosen Spanish (.sp). When I press Ok and restart ILWIS it will use the spanish translation. So a contour interpolation form suddenly looks like

A spanish form :).
Ilwis 3.8 will contain a french and a spanish translation. It is likely that there will also be a portugese translation but that remains to be seen.
One thing. The translation is about the user-inteface of Ilwis, not of the help files. That is far too much work to do for volunteers.

The Losers

December 5th, 2011 @ 09:30 by Martin Schouwenburg
Posted in ILWIS

When implementing such a large operation as we are doing for the 3.8, there is inevitably functionality of the old code that has to be reevaluated. Mostly it is because you want something better, sometimes you have to remove some non performing functionality and sometimes you have to set priorities to determine what must be ported to the new structure and what will be dropped. This blog is about the losers of that judgment.

Printing Maps

Designer : You can’t print maps in 3.8.

Users : What? I think I misunderstood.

Designer : No really, no printing of maps. No layouts.

User : Eeeh, seems to me a big blunder. Everybody wants to print their maps at a certain moment. Stupid programmers!

Well indeed the layout has gone from ILWIS. No direct printing of maps anymore. It was the result from a discussion between me and several users about printing, how it is used and how important it was. The background was of course a setting of priorities. The basic reasoning was: You don’t want to print; you want to use the rendering of a view in a report or some other kind of document. You can combine it with other texts, figures and tables based on that software.  The final result can be printed if needed. In that way you combine the strength of one piece of software (LWIS), rendering spatial data, with the strength of let’s say a word processor (rendering texts/tables + printing) without needing to reinvent the wheel.

As such, this line of reasoning suited me well. I disliked the layouts as being too primitive for real cartographic output. I have never considered ILWIS to be a cartographic package, it’s an analyses package. Sure if you have enough resources it might be feasible to implement such functionality but it certainly has low priority. So the above line of reasoning suited me well, however, it is has two important consequences. First of all ILWIS has to be able to copy the contents of its mapwindow perfectly to the clipboard. Second, that some annotation elements are available in the mapwindow that were previously in the Layout. Elements that are not easily generated by a word processor.

The first task is rather easy. Instead of rendering to the screen, I render to a bitmap of suitable size and put that on the clipboard. At the moment, I render a 300 dpi image to the clipboard. This is quite large and should be sufficient for most documents or posters. I can scale op the image to 600 dpi but that creates a really huge bitmap, so for the moment I leave it at 300 dpi. Note that the image I render is identical to the view you have in your Mapwindow (incl. zoom and such).

The second is somewhat more work, though not overly so. I choose to implement Legend, MapBorder and North Arrow in the mapwindow. In the current internal version, the first two work reasonably well, the third needs to be done. The third one is easy though. I will probably use some ivg file(s) (see earlier blog) and rotate them appropriately. In this way people can add their own arrows and I hardly have to program anything as the ivg rendering is already done with the point maps.

Point graph symbols

The second thing to go was the point graph symbols. You could make a mini graph of the values of an attribute table that appeared at the location of a point. There were a number of types and a lot of properties. Apart from maybe the pie chart they were difficult to read and often quite ugly. Reimplementing them would have been a lot of work for a feature that I judged to be fairly useless ( apart maybe of the pie chart). Now if users can convince me of the usefulness of it, I might reconsider. But for the 3.8 they are out (for the moment).


Point labels are gone for the moment. I am not completely happy with that, but as such they have been given low priority. Partly this was because it took some time to get the scaling of texts correct, that was quite difficult in OpenGL (needed that in the annotations), partly because a good placement algorithm for labels is not trivial (problems with overlapping labels and such). Now that I have good control over the size of fonts I might implement a simple labeling scheme. We will see, for the moment it not on my list of things to do.

Double click action on maps

In the past you could attach the opening of a document (in the broadest sense) to double clicking on locations. As such this was cool (when it was developed) but at the moment I feel that it is not enough. More can be done here, more should be done. But what? So for the moment I leave it out. Maybe it will reappear in the 3.8 or later, maybe not. It is one of those features that are fun to play around with as programmer but I doubt its priority a bit .

So these things are the main things that will not reappear in 3.8. A shame? Maybe, maybe not. It is not bad sometimes to clean up some features as ‘more’ doesn’t always mean ‘better’.

SenseBox & standardization recommendations for the Internet of Things

December 2nd, 2011 @ 16:31 by Arne Bröring
Posted in Sensor Web

At the Internet of Things workshop of the OGC TC meeting in Brussels, we presented the SenseBox project which we are conducting together with the SWSL group at the Institute for Geoinformatics of the Uni Münster.
Besides demonstrating the SenseBox project, we gave recommendations for bringing the Internet (or better Web) of Things field together with the standardization efforts at OGC. Standardized REST APIs for things as well as well-defined JSON encodings for exchanging data about / from things could be an interesting contribution of the OGC to this emerging technology field. Similar suggestions were made by other particiapnts. E.g., Ben Pirt from the Internet of Things platform pachube announced their interest in OGC and standardized protocols for the Internet of Things.

Please find below the presented slides.

SOS extension for GeoServices REST API based on ArcGIS Server

December 2nd, 2011 @ 15:27 by Arne Bröring
Posted in Sensor Web

At the OGC TC meeting which took place this week in Brussels, our new SOS extension for the GeoServices REST API was presented. This extension, which is based on ArcGIS Server 10.1, embeds the functionality of a Sensor Observation Service (SOS) into the GeoServices REST API. The GeoServices REST API is currently making its way through the OGC standardization process.

The implementation of the SOS extension for the GeoServices REST API based on ArcGIS Server is developed for a project with the European Environment Agency (EEA). With the help of this software, the provision of Europe’s environmental data shall be facilitated – accessing data such as Ozone, noise, or water quality will become easier in future.

Please find below the presentation hold at the OGC TC meeting. The slides introduce to the project with EEA and the SOS extension.

Stacking rasters

November 29th, 2011 @ 10:15 by Martin Schouwenburg
Posted in ILWIS

It is always difficult when you have sets of different overlapping rasters to visualize properly. Rasters are usualy a full coverage and so two rasters(or more) on top of each other block the view on one of them. As historically ILWIS is oriented towards rasters  I felt I had to offer more flexibility when displaying rasters. So what options do we have? Well basically three

  1. Transparency. Make one layer (partially) transparent so you can view the “lower” layer
  2. 3D Orientation. seperate the two layers in 3D space and view them there
  3. Time shift. Quickly blink between layers to inspect different layers
So lets explore these options
Transparency and visibility
ILWIS 3.8 has fairly extensive transparency facilities. There is of course the “normal” full layer transparency. This applies transparency to each and every pixel in the map. It is fine but it has its limitations. The view you create has basically merged the pixels of two layers and it is not always that clear which features come from the upper or lower map.
I felt we needed a way to emphasize “interesting” pixels (whatever that maybe) in one map more and to filter out the rest.  Than you would see only partially one map, the interesting bits, and keep the rest of the underlying map. To do this ILWIS has two methods.
  • Class maps may make some of their class fully transparent. In the legend one can deselect classes which than become fully transparent. You get than a picture like this
Two classes have been deselected and the underlying map becomes visible.
  • A value range can become transparent. In the beta you already have the interactive representation (discussed in an earlier blog), in the internal version I have(2011-11-29) I have added two, related, extra options. The first one is directly through the tranparency form of a layer.

  • In this you see a range of values(0-150) being indicated as being 100% transparent and the underlying polygon map becomes visible. Related to this is the “command-line” method. In the internal version each mapwindow has a commandline that is similar to the command line of the mainwindow, Similar, but not 100% equal. Calculated maps from that command line are automatically added to the mapwindow. It has one extra option. The ability to add a displayoptions parameter that describes how the added map should be rendered. One of the parameters in there is similar to the transparency in the form. Below is such a result( with the calc expression)
3D orientation
Another way to reach the same goal is using 3D. It is not as flexible as the previous method but it might be usefull some cases. Below is a combination of the two methods with a 3D grid to get a better orientation.
 3D is more usefull in this respect when you have 3 or more layers (geologist studying layers in the earth use this view for example).
This is a special way to detect differences between two raster maps. It of course only relevant for two (or more) maps that are mostely the same but might differ on a number of places. One can make a small maplist with the maps, animate it and detect the differences.
Next Page »