Ilwis 3.8 is almost done (sigh, finally) and apart from some bug tracking I don’t expect significant changes anymore. I am not sure if I will release it before my own holidays ( after 2nd week of february) but we will see.

The last few weeks a discussion has started internally but also within 52n, about the future of Ilwis. All parties see Ilwis as worthwhile (for different reasons) but also see sginificant risks in the future. The risks boil down to the following points (note that I don’t agree with all points, but I mention them anyway).

1. Ilwis is based on old technologies, programming wise. This is true. Many choices were made 10-15 years ago when the IT world was quite different from the current IT world. That we are still able to make a quite nice product out if proves that the choices we made were quite reasonable, also in the long term but still the point stands.
2. Ilwis is based on an old fashioned programming paradigm: Desktop applications. We should change towards a more web/browser/service oriented model as this will be the future. Yes and no. True, our support for web based things is limited, though the options in 3.8 have increased significantly.  Ilwis was designed in a world where the internet played a limited role, certainly with respect to data access and services. That has of course dramitically changed since then and we should better support that. But I question the statement that desktop applications are ‘old fashioned’. Browsers are quite limited in what they can do with local data and doing all processing remote is a pipe dream. In the long run I believe we will see a merge between dekstop and browser enviroments. A bit like Google envisions with Chromium OS; though they are probably not the right party for it to succeed.
3. Ilwis is based on an old fashioned language, C++. We should change to something more modern like Java. Sigh. People who propose this don’t have a clue in my opinion. First of all, these days, C++ is probably more modern than Java. The last overhaul of the C++ language is from July 2011. Java specs are older.  The C/C++ combination is still king when it comes to raw performance  and Java lags (literally) behind. Some claim that Java is “easier”, but seeing that both laguages are very similar with respect syntax and structure  I don’t see were that claim is comming from( I programmed in both languages). Sure C++ can be quite difficult when delving deep into the generics but this is hardly something you do regulary. Ever tried class loaders to work flawless in Java? urgh. Probably every language has its nooks and crannies were you rather keep out. Anyway, the complexity of big applications like Ilwis is not in the language, but in the size and design of the application itself.
4. Ilwis is rooted in the Windows enviroment and we should be able to run on more platforms. I agree with this. When Ilwis was designed, Windows was absolute king. It made no sense to make it for different platforms. Sure the Mac was there but nobody used in the field we were working in. That is different these days of course. Windows is still king, but there are other platforms also. Linux (though desktop Linux is still a midget), the Mac is more viable these days, Server enivorments. And then of course the growing market of the mobile applications ( both for smart phones as for tabs). Though I dont have a clear vision what ‘meaning’ Ilwis will have for these (mobile)platforms I still feel we have to prepare in someway for it.
5. The developer base of Ilwis is too small. True. Basically there are two developers and that is not good. This is partly due to the fact that Ilwis is quite complex to program with. The current version, though there were some overhauls in the last years, is with respect to structure and concepts 15+ years old. Many things were added to it, sometimes in a haphazard way, sometimes in a clean way. As expected the internals of the software are as a consequence sometimes difficult to fathom. Now, this need not to have any consequences for the users of Ilwis. The outside works ok I think. But for programmers wanting to contribute to Ilwis it is another story. So yes, an Ilwis 4 might create a more attractive  Ilwis for outside developers.

Both these editors have been significantly changed. This was a side effect of having changed the drawing system of Ilwis. The way the old editors worked could not maintained in the new system and so I had to redesign them from ground up. This proved to be a more time consuming job then I had anticipated. Particulary in the segment editor there were so many states and state transistions to be reckoned with that I sometimes had trouble determining the right course of action.  Anyway, I think I now have a working editor for both pointmaps and segment maps;

Both editors are now simply display tools, just like any other display tool and they can be found in the context menu of the display options (default it is off).

Select the the item and a new node is added to the tree looking like:

Fairly identical to the “old” button bar. Maybe a bit more understandable as I found the “old” icons always a bit vague. The layer (for which you opened the editor) is seemingly unchanged. When you select a segment, be it for a direct select or for moving/spliting etc.. The nodes of the segment become visible like:

Nodes can moved, deleted, inserted just like the old editor. When inserting a new line, you stop the line by pressing enter. In the insert mode, clicking in the middle of the segment will insert a point at that point; clicking at one the ends will extend the line(and you can add more points).

Snapping has now a big brother. You can indicate that after stopping a line it will automatically close how large the distance between both ends may be (so an auto-close).

A big change is how values are added/changed for the segments. All is now controlled by the layer info on the bottom left side. When in edit mode, the fields (not coordinates) are editable. See for example below

Also the fields of any attached attribute tables are editable.

Line and point editor work fairly identical ( point editor is of course little bit simpeler). One extra option in the point editor is though that you can double click on a point and enter exact coordinate when clicking on the map is not sufficient. Maybe I will implement this also for the nodes of the segment editor but it is not there yet.

I feel that the editors are fairly basic ( but that was also true in the old version) but as usual it is a compromise between time and functionality.

Ifgi recently hosted Münster’s first HackDay to promote contributions to the nationwide “Apps4DE” competition. Between 40 and 60 hackers and thinkers from Münster met throughout the day to discuss “open data” and come up with ideas for Apps which demonstrate the use of public sector information. An opening presentation by Albert Remke was followed by a series of lightening talks about linked science, linked open data, map Apps and Augmented Reality. After several hours of brainstorming and hacking in small groups, the participants presented resulting ideas and small prototypes such as:

• Family and Recreation App
• App for Open Sensor Data
• Linked open data applications for the Bundestag  members and their private activities in the market economy

Several participants also announced that they plan to submit their idea or App as a proposal to the “Apps4DE” competition. In the eyes of the particpants, the Münster HackDay – one in a series of Hackdays promoted by the Open Knowledge Foundation – proved to be a highly successful event!

Organisers: Geonetzwerk Münsterland, 52N, ifgi, con terra, Open Knowledge Foundation

Finally back after a long break. Happy new year to all.

Some people have voiced to me some concerns about my remarks about printing of maps in Ilwis 3.8. Or basically the lack of it. So I think it might be  usefull if I explain a little bit better.

First of all the baseline

• The layout object is gone. It is no more. It has been deleted. No directly printing of maps anymore.
• The copy of the content of the mapwindow is now realy a WYSIWYG copy. Everything there  will be placed as a 300 dpi image on the clipboard.

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.

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 .