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 .

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).

Labels

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’.

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.

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.