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

I like Spheres

January 31st, 2012 @ 10:23 by Martin Schouwenburg
Posted in ILWIS


But the world is not a sphere. Sad panda face. So things become complicated when trying to project a 2D image (the map) on 3D surface (the not so sphere like Earth) and then back again to a 2D screen. I am not going to bore you here with the whole theory of projections, datums coordinate systems etc.. They are failry well described in the Ilwis help and there numerous sources on the internet that give more information about this.

What I do want to show is we handle this when displaying maps. After all displaying maps is the main “thing” of Ilwis 3.8 and the way of how real world coordinates are mapped on the screen is could be essential in understanding the spatial context of your maps.  In the old system of Ilwis we had a very restrictive system. The georeference of the first raster maps was leading and all subsequent rastermaps must have the same georeference or else they dont display. Feature maps had more freedom as you could change coordinate systems and full,on the fly, reproject would take place resulting in a different rendering of the map. This was kind of nice as you could teach people in a very visual way what the difference between the various projections were. The restriction on rastermaps was not nice. It made sense at the time as a on the fly resampling of the map to a different georef/coordinate system is very expensive and basically still is.

For the 3.8 my approach was different. The leading principle here is the coordinate system. The coordinate system of the first map is the coordinate system into everything is reprojected, both feature maps and rastermaps. Later you may change this but the default is the first map. You may ask, ‘But you stated that on the fly reprojection is too expensive’ ? This still is true, but the underlying technology we use gives us a shortcut through which can achieve our goal.

The new drawing mechanism of ILwis is based on OpenGL. Without boring you by explaining exactly what OpenGL is , suffice to say it is one of the two big display technologies (the other DirectX from Microsoft) that dominates the world of the pc’s. Because it is so widespread and used by many parties it is these days actually embedded in the hardware of your graphics board. This makes it blazingly fast and gives us (programmers) access to very fast execution of graphical operations.  The other thing you should realize is that, when you look at it, reprojecting is nothing else but morphing one image to a ‘distorted’ new version of the same image. Luckily this distortion proces is something that OpenGL is good at, many games use these kind of distortions when mapping their textures on game objects. So we piggyback on the native OpenGL to reproject pur rastermaps to a different coordinate system. This works realy fast and then we can create images like

 

In this we combine three raster maps with very different geometries into a single rendering. All the reprojections stuff was done by OpenGL. Fortunately OpenGL allows you to define your own coordinate system so I can acutally use ‘real’ coordinates to do those operations.

Under the global tools there is now an options to change your coordinate system. If I would change the coordinate system of this rendering to lets say  LatLonWgs84 you suddenly get a different image.

The ratser have now morphed to the new LatLon system on the fly.

But, …. still there was a case for having the georeference as being the leading factor. There are a few cases were you realy need a rectangular grid of pixels irrespective if the image rotated or morphed  in the coordinate system. For example stereopair needs this. All pixels need to be of the same size to get the stereocopic effect. In the ‘normal’ situation, coordinate system leading, the pixels might not be the same size everywhere as the images is morphed on the model of the earth supported by the coordinate system. If you look at the Geometry node in the global opetions you see the option of also changing the georeference, this makes the georeference leading. For example

would morph into

In which all pixels have the same size and the image is turned straight up.

So in Ilwis 3.8 we can play a lot with how the geometry of maps is rendered. Of course you can make a total mess of it but that is op to the user.

 

 

 

 

 

OGC adopts PUCK standard… Congratulations, Tom!

January 31st, 2012 @ 10:07 by Arne Bröring
Posted in Sensor Web

Congratulations to Tom O’Reilly (MBARI), the editor of the PUCK standard! Today, the OGC membership has voted to adopt the OGC PUCK Protocol Standard.

PUCK enables the standardized retrieval of metadata about a sensor instrument. It standardizes commands to retrieve this metadata directly from the instrument. Therefore, the simple PUCK protocol is added to a sensor instrument’s native protocol. PUCK has already been implemented by several sensor manufacturers.

At 52°North, we were able to contribute the Sensor Interface Descriptor (SID) concept to the PUCK specification. The SID specification [1] is based on SensorML and allows the declarative description of the protocol of a sensor instrument. By providing a well-defined model for such descriptions, SID can replace proprietary driver software needed to run a sensor instrument. In combination with PUCK, SIDs can be directly stored on the instrument. Having this self-description of an instrument’s protocol stored on and retrievable from the instrument itself enables sensor plug & play.

For more information on this please see this blog post as well as this one. Also, the publications [2] and [3] give further information.

 

[1] Bröring, A. & S. Below (2010): Sensor Interface Descriptors. OGC Discussion Paper. Open Geospatial Consortium. OGC 10-134. [final] [slides]

[2] Joaquin del Rio, Daniel Mihai Toma, Thomas C. O’Reilly, Arne Bröring, Antoni Manuel, Kent L. Headley & Duane Edgington (2011): Interoperable Data Management and Instrument Control Experiences at OBSEA. IEEE Oceans 2011. 6.-9. June 2011. Santander, Spain. pp. 1-4. [final]

[3] Daniel Mihai Toma, Tom O’Reilly, Joaquin del Rio, Kent Headley, Antoni Manuel & Arne Bröring, Duane Edgington (2011): Smart Sensors for Interoperable Smart Ocean Environment. IEEE Oceans 2011. 6.-9. June 2011. Santander, Spain. pp. 1-4. [final]

Ilwis 4

January 23rd, 2012 @ 10:19 by Martin Schouwenburg
Posted in ILWIS

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.
Though there are some other points I think these are the main points. What will happen is still very much unclear. It is under discussion and as always money ,time allocation  and commitment are the deciding factors.  Some people like to maintain the status quo, “it works fine now, why change?”, others want it to conform to their pet vision. I do agree that a new design of Ilwis is probably in order. I also think that you should not forget your roots. Slowly drifting away in a cloud of vague future visions and short lived hypes is also not a good idea.

Segment and Point editors

January 16th, 2012 @ 11:06 by Martin Schouwenburg
Posted in ILWIS

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.

 

 

 

 

 

 

 

Successful HackDay Münster 2011

January 12th, 2012 @ 09:41 by Ann Hitchcock
Posted in 52°North, Communities, Sensor Web

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

Next Page »