GRIFIN Experiment

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.

GRIFIN will be at InfraWorld Seminar

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.

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.

What is GRIFIN?

The question that always comes back. Here is a collection of few possible answers used during the last few years. The fact is that I do not know what is the single best answer to the question.