GRIFIN Experiment

Connecting and communicating models of things from our real-world environment.

Functional programing with Scala and GRIFIN

I took an online course on “Functional programing with Scala” given by professor Odersky from the Ecole Polytechnique Federale de Lausanne (EPFL) in Switzerland - the author of Scala himself. Here are some stats about the course. There are several reason why I bother to write about it.

Firstly, I do not remember learning so much about programing in two months time period. The course certainly requires determination, time and focus to pass, but the effect was better then my expectations.

That comes to the second point that quality of the course is superb.  I was expecting solid ground quality from the lectures by Odersky, but the content of the assignments, selection of tools and instructions for their setup, and their submission-evaluation-grading mechanism for the assignments - that made my jaw drop. Especially when I learned this single course drew an astounding 50,000 registrants worldwide! It is more than twice the number of all students currently studying at AAU, where I was developing and teaching master-degree courses myself for few years. The functional programing style is clean and scalable - that attracted me to the course. Now the course leans on Scala as the functional programing technology, Scala is designed by Odersky, and Scala was used for the management of the course, which makes the course itself a beauty. It is so compact, self referencing, and proving itself capable that you end up convinced about the power of what you have learned.

The third reason is that I have been using Scala for GRIFIN Shell for about two years.
The main original reason was that it provided GRIFIN with an interactive interface with JVM, which could help relaxing the fact that geospatial computation and its connection to information systems gets very easily (and very often) drawn in large blocks of Java, C or Fortran code. I still believe Scala can help with that. But there was also this “functional bonus” which, they say, could make GRIFIN to be much easier for the domain geniuses to both write and troubleshoot a software that keeps up with the new multiprocessor hardware. Designing and running geospatial models is a lot about dynamic cases with many different actors at static or changing positions influencing each other over time, which in computer science terms leads to a multi-threaded software. As Odersky says: “If you want to write a multi-threaded application now it’s still nightmarishly difficult. There are lots of mistakes that are hard to detect. We have to make programming these kinds of applications feasible for everyone, not just experts and that is very hard.” Hard that is indeed, but Scala (hopefully) tackles that. What I know by now is that Scala successfully mixes functions and objects; it resolves multiple inheritance problem; has effective type inference; and works seamlessly with JVM. That is a list that makes it altogether both an original and an impressive technology for me.

Most relevantly, however, this makes Scala a seemingly perfect match for the user-level creation of contents for GRIFIN using GRIFIN Shell.

Intel hosts Dr. Martin Odersky presenting Scala 2.10 from Typesafe on Vimeo.

Architects and BIM

I attended Confluence Symposium last Friday to learn more about possible collaboration with architects in terms of building information modelling (BIM), which is a relevant application for GRIFIN on the level of software. I found all presentations very interesting, some even amazing. BIM, however, is probably a less interesting subject for collaboration with architects. Here I share my observations:

Architects do not care much about software or any information technology in itself.
They might care about properties of a given software, but they do not care how are these properties influenced by the internal design of the software. Certainly the software’s design influences their work, but architects consider it as somebody’s else concern. Some architects might care little bit more, but in general not to an extent of designing new software tools. My impression is that software is a tool on the same level as a driller, pencil or a bulldozer, which is probably not entirely the case because there is a great deal of intellectual overlap in software design and the work of architects.

It was obvious that workshops, physical materials and the actual environment at a given location is much closer to their hearts. Together with purpose of a given structure and its influence on the use of the place are architects’ core challenges - exclusively if possible.

For architects BIM is a push technology from industry, namely from the AEC industry with which they are professionally associated. Though I am not an expert, I guess BIM was pushed by the engineering community of AEC industry, which is quite separated from architects. BIM’s focus is on (extremely complex) procedure/method in AEC industry. Architects benefit from BIM in terms of communication and coordination with other actors in the AEC production and delivery chain. In this sense BIM does not enforce any new technology on architects - they can keep using the same CAD tools.

Architects have a relatively “posh” professional culture. Costs on scales of tens to hundreds of thousands are negligible. That is perhaps given by the budgets needed for building even a small structure, but I suspect it also transforms their notion of “free”, “open” or “cheap” to anything but attractive.

ArchiCAD, Tekla, Bentley, Autodesk or Gehry Technologies products are probably great tools, but they are proprietary to retain their commercial advantage, and architects do not dare to deal with concepts behind their design. Architects accept the marketing image of these BIM products, which presents them as a solved issue. Yet there are many issues and gaps in making things work together. Architects seem to be unaware that BIM still has R&D challenges they could address and since the CAD era continue being customers who can be dragged by the software producers.

After a short analysis, at the moment sticking to BIMserver technology and community seems to be the best direction for bringing BIM concepts to GRIFIN.

Screen-cast of the presentation given at the closing seminar of InfraWorld R&D project in Sandvika, Norway. The seminar had five presentations and a demo. Things went well, and we had more than 50 interested people from 32 institutions. The guys from Vianova AS also recorded the life demo session presented at the end of the seminar.

This demo shows three different software applications (each using one screen) connected to a server providing geospatial managed objects (GMO). If you want to learn more about those have a look at GMO Technology presentation, which was given before this demo. The demo is from the closing seminar of InfraWorld R&D project in Sandvika, Norway.

Today I have made the first GMO definition making use of laser scanned data, which I downloaded from the Web. 
It was surprisingly simple - it took me half the time of making this video showing the result. There are five GMOs created using this representation that can be recognized visually by color: white = ground, purple = tree, cyan = light post, yellow = vegetation, blue = fence.


It is fairly trivial definition that does not provide any analytical functions, which is the main strength of the GMO concept. It is more than ready for adding something later. The scene counts almost four and half million points (4 489 087). The size of the GMO database is approximately 32 MB (32190413).

The Virtual Globe component handled this scene without any noticeable slowdown in rendering performance. The point cloud objects are NOT georeferenced properly to its real location. That is also the reason for using the wireframe representation of the terrain with transparency so that it does not visually interfere.

Data source: webgl.uni-hd.de/pointCloudViewer/index.html

Taxis In Oslo Area as GMOs

These sticks show the latest position of Taxis in Oslo area. The data are obtained from a web service once every 60 seconds. Each stick is an independent georeferenced managed object (GMO), which has the corresponding cab ID and could do things like logging and analyzing the past motion, the latest position, or following a selected taxi. The technology would also allow for messaging, but its practical use in this scenario is unclear.

As you might expect - all is made using the GRIFIN platform.

The video capture of the presentation on Georeferenced Managed Objects from the 7th gvSIG International Conference. NOTE: the presentation is given in English although the introduction is in Spanish. The materials for all the presentations is available at the conference website.

NASA WorldWind client for GRIFIN

Le Thanh Vu presented the first Georeferenced Managed Objects from GRIFIN platform using NASA WorldWind technology. As you can see on the screenshots bellow, it is just a big bunch of cubes distributed around the globe at the moment. Nevertheless, thanks to Vu, NASA WorldWind is slowly becoming the fourth visual client for GRIFIN, after Rune Aasgaard’s Virtual Globe, gvSIG Desktop and Vianova’s Virtual Map.