SoC Report 2007

OSGeo participation in Google Summer of Code 2007

by Wolf Bergenheim

Last summer, from May 1st 2007 to August 31st 2007, OSGeo participated in the Google Summer of Code. This article sums up that experience and gives a short presentation of each Summer of Code project.

What is SoC?

Quoting Google FAQ

Google Summer of Code TM is a program that offers student developers stipends to write code for various open source projects. Google will be working with a several open source, free software and technology-related groups to identify and fund several projects over a three month period. Historically, the program has brought together over 1,000 students with over 100 open source projects, to create hundreds of thousands of lines of code. The program, which kicked off in 2005, is now in its third year, following on from a very successful 2006.

While the majority of past student participants were enrolled in university Computer Science and Computer Engineering programs, GSoCers come from a wide variety of educational backgrounds, from computational biology to mining engineering. Many of our past participants had never participated in an open-source project before GSoC; others used the GSoC stipend as an opportunity to concentrate fully on their existing open source coding activities over the summer. Several of our 2005 students went on to become mentors in 2006.

What projects participated?

First of I'd like to congratulate the students on a job well done. A lot of cool and very usefull projects were completed in SoC 2007. We did loose a student or two, who were overtaken by other priorities. But the overall success of projects is something we should be proud of. Good work! Hope SoC 2008 will be at least as good.

Now on to present the Projects of Summer 2007.

GDAL

GDAL2Tiles

Student: Klokan Petr Pridal Mentor: Howard Butler

This project is to allow easy publishing of raster maps on the Internet. Raster maps (like TIFF/GeoTIFF, MrSID, ECW, JPEG2000, JPEG, PNG) are converted into a directory structure of small PNG tiles (TMS compatible), which can be copied to a webserver. Simple webpages with viewers based on Google Maps and OpenLayers are also generated as well. This tool makes publishing even large maps without needing to install or configure any special software (like mapserver) and the map displays very fast in the webbrowser. GDAL2Tiles also generates necessary metadata for Google Earth (KML SuperOverlay), if the supplied map uses EPSG:4326 projection. The gdalwarp utility can be used to convert raster maps with another projection. World files and embedded georeference is used during tile and KML generation, but proper georeference is not mandatory.

Tile structure follows recommendation from OSGeo Tile Map Service Specification

Manual page for utility is part of the solution, as well as a document describing several existing tile structures with links to further documentation. Analysis of rotated SuperOverlay KML is done as well.

For more info look at the project page

This project was accepted by GDAL community as ticket #1763. This utility is distributed with the new stable version of GDAL 1.5.0.

KML read support for the existing driver

Student: Mateusz Loskot Mentor: Jens Oberender

This project added KML vector read support.

For more information read Wiki page

This project is included in the new version 1.5.0 of OGR

Web Map Services GDAL driver

Student Adam Nowacki Mentor: Daniel Morissette

Development of a OGC Web Map Services GDAL driver, with support for the following Web Map Services:

• OGC WMS and WMS-C cache
• WorldWind TileService

The new driver has been included in the official GDAL codebase and included in the 1.5.0 release. Driver documentation is available and the Wiki page hase more information.

This project is included in the new version 1.5.0 of OGR

GRASS

v.generalize

Student: Daniel Bundala Mentor: Wolf Bergenheim

v.generalize is a project which does line simplification as described by McMaster. The original plan was to implement Douglas-Peucker and a few more line simplification algorithms. Daniel Bundala (the student) surprised his mentor by working a lot more efficiently and as a result GRASS 6.3 now includes a brand new generalization module which is capable of not only simplification but also smoothing and displacement. There is also a method for network simplification in the module.

For more information see the module documentation

v.generalize is included in the new 6.3.0 release of GRASS (as of RC4).

The module has also been used to substantially speed-up and improve quality of interpolation from contour data when computing digital elevation models.

v.net.visibility

Student: Maximilian Maldacker Mentor: Wolf Bergenheim

v.net.visibility builds a visibility network around some obstacles. The created network can then be further analyzed with existing v.net.* modules. It can also be merged with an existing network, like a road network, and this enable plotting shortest paths beyond an existing road network, say for emergency vehicles.

For more information see the module documentation

v.net.visibility is included in the new 6.3.0 release of GRASS (as of RC4)

uDig

Caching data

Student: Christophe Rousson Mentor: Ian Turton

A feature cache. A RAM cache might use the LRU algorithm and have a maximum amount of RAM to consume setting. A local disk cache and local disk cache might use a size-only and/or maximum age based algorithm. Ideally as items fall out of RAM, they would be written to disk. At session close, remaining items in RAM would also be written to disk (much like Google Earth). Upon startup, cache could be polled to see if anything already exists within the current spatial window (if it hasn't expired).

For more information see the data Wiki page

This project is on the trunk/development version of uDig.

Transformation Algorithms

Student: Jan Jezek Mentor: Jesse Eichar

GeoTools Referencing module has been becoming one of the most powerful tools focused on coordinate system transformations in JAVA GIS world in recent years. Referencing module in conjunction with Coverage module presents a really strong tool for raster operations like re-projecting and transforming. One of the frequently required operations in GIS is to fit rasters like scans of maps or remote sensing images that have unknown coordinate reference system into the real world coordinate reference system. In GeoTools there are already few possibilities to do so. The aim of this project is to add other algorithms for that purpose and then to make a simple GUI for uDig to apply these new functions.

These new algorithms are:

• New interpolation-based methods - inverse distance weighted (IDW) interpolation, bilinear interpolation.
• Thin-plate Spline method (TPS).
• More general piecewise transformation.

For more information see the Wiki page

This project is on the trunk/development version of uDig.

Interactive GeoRSS Tool

Student: Rui Li Mentor: Richard Gould

As a user focused geographical information system, one of its goals is to satisfying system users by providing sufficient information to their specific needs. In many cases like traveling or moving, a traveler would like to find Places of interest close to his/her hotel, or a student wants to find an apartment within feasible walking distance to school. The traditional way contains two separate steps which are looking for potential locations and then confirming the distance by the user him/herself. This project combines the two steps together.

For more information see the Google Summer of Code abstract

Geoserver

JTileCache

Student: Chris Whitney Mentor: Justin Deoliveira

Implemented a WMS-C server (similar to TileCache of MetaCarta) as a Java servlet, including support for existing cache libraries in order to support memory, disk, and distributed caches. The Open Planning Project (TOPP) is continuing development on the project. In particular, Arne Kepp contributed significant new features and bug fixes, including releasing a 0.5 version under a more suitable name, GeoWebCache. The project currently lives at http://geowebcache.org. The GeoServer demonstration site now uses GeoWebCache for serving WMS tiles to the client.

Style Editor

Student: Anthony Manfredi Mentor: Andrea Aime

To design and implement an editor for SLD files with using JavaScript.

• Standalone - editor is not tied to a particular program (uDig, MapBuilder, GeoServer)
• Visual - users can preview the results of changes as they are made.
• Intuitive - easy to learn but not cumbersome or limiting for the advanced user.

For more information see the Wiki page

GeoTools

Multi-Dimensional Raster Data Sources

Student: Daniele Romagnolil Mentor: Simone Giannecchini

This is a set of Java Image I/O plugins capable to provide a starting point for building GeoTools plugins to manage multidimensional data formats such as NetCDF, HDF, GRIB1.

• HDF (Hierarchical Data Format) is a library and a multi-object file format

created and developed by NCSA (http://www.ncsa.uiuc.edu/).

• NetCDF. Quoting from (http://www.unidata.ucar.edu/software/netcdf/), "NetCDF (network Common Data Form) is a set of software libraries and machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data."
• GRIB1 is a data format standardized by the World Meteorological Organization's Commission (http://www.wmo.ch/) for Basic Systems, which is commonly used in meteorology to store historical and forecasted weather data.

For more information see Wiki page

3D Rendering Pipeline

Student: Hans Haggstrom Mentor: Jody Garnett

The 3D Renderer provides a three dimensional view of GeoTools geographical data. It uses the normal 2D renderer for rendering the surface texture. It implements a level of detail based loading and caching system for the geographical data to speed up rendering, and allow perspective views showing both nearby and far away features at the same time. Possible future improvements are rendering elevation data based on height coverage data. In addition, there could be support for some common 3D rendering styles that can be used for features consisting of points, lines, and areas.

For more information see Rendering Pipeline for GeoTools Wiki page

PostGIS

Coverage Model and Operations

Student: Xing Lin Mentor: Timothy Keitt

This project includes a raster data model and its storage in PostGIS. Import and export tools are also available for popular image formats. There is a paper about this project available at http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1370128

For more information see the Google Summer of Code abstract

Mentor Summit

Some (well behaving, meaning turning in their surveys in time etc.) projects were asked to send a mentor to the SoC Mentor summit. OSGeo sent me (Wolf Bergenheim from the GRASS project). Mentors from over 100 projects joined forces at Google HQ in Mountainview CA, and discussed varied aspects of the SoC. The summit was arranged as an unconference, meaning that the participants generated the program. A wiki with the talks is set up at http://googlesummerofcode.jot.com/

Lessons learned

Many lessons were learned in the SoC 2007 (at least by me), both as a mentor, but also general points on how to attract more developers and how to "keep" SoC students with the projects. Burst let me talk about how to attract students.

How to attract students?

We did get about twice as many projects proposals as we had slots available, but compared to other projects it was actually quite slim. I will now discuss how we could maybe attract more students this year.

Promise fame and glory

With this I mean that it should be clearly indicated that the students will be given "media time". This means spotlights at the OSGeo website, maybe even a news item telling about their prograss. And similar exposure within the project that they work.

Show that you appreciate their work

The code that the students produce should end up in the main code repository, and it should be made clear from the start that this will happen. Also We should promise to include their project in the next release after it is completed. If we promise that their code will become part of the project it should motivate the students even more.

Have interesting but a vague ideas list

When we compose a project idea list we should leave room for innovation. Let the students fill the gaps. That way we will attract maybe the more correct types.

Work with the student from day 0

This means that when you see an interesting application, take the time to set up a wiki page to flesh out the idea with the student. Last year there was plenty of time to talk things with the would be students. Chatting on IRC is also good. When the students see that we are committed to the SoC and that we listen to them they should become more interested.

Integration to the community

Once we have selected the best students to work on the coolest projects we should integrate them into the community to hopefully get new eager committed developers (fresh blood, as I like to call it). How do we accomplish that?

Have the student talk on public mailing lists and IRC channels

Most, if not all project communication should be on the main project development list and IRC channel. If the student is shy, one trick is to say "I don't know, try the developers list" Once they get used to sending mail there (and see that nobody bit their head off) they should have no problem in becoming integrated, maybe they might even answer some unrelated emails.

Make sure that the whole project knows about and is aware of the SoC

If the whole project knows about the student, they will help you make him feel welcome.

Help them finish successfully

If the student struggles, chances are that he won't finish the project. If he is provided with help and a whole community of supportive developers, he won't have to struggle as much, and he will most likely finish.

Keep the student happy

A happy developer is a productive developer. If the student feels welcome and liked he will probably enjoy being part of the community, and thus will most probably stay with us.

Cross-project cooperation and cooperation outside OSGeo

There was also talk about collaborating with other organizations over the SoC. For us this means either that we could come up with SoC projects which involve more then one OSGeo project, or it could mean that we collaborate with a non OSGeo project like Drupal. Drupal has shown interest in collaborating with PostGIS regarding geo stuff. This means that we could give them one mentor to help with geo things while they would give us a mentor to help with the PHP. It could be one or two projects.

Wrap-up

Last year SoC came a bit like a surprise for us at GRASS, so we were not really able to organize ourselves to bring more SoC project ideas, but in the end we were able to finish two students. Also last year was a bit confusing and maybe not as organized as it could have been. Mentors from other projects didn't seem to talk together and it felt a bit like a fragmented effort. This year I hope to be able to use the knowledge gained from last year to make it easier and less confusing to new mentors, and maybe have a more united OSGeo SoC experience.

Some words from Our students

Two students, Chris and Daniel, felt like sharing their SoC experience with us.

Chris Whitney

I enjoyed participating in Google Summer of Code. The project was my first experience working on a GIS software project, and definitely my first exposure to many of the open-source GIS projects. Fortunately, the Geoserver community was a very knowledgeable and friendly environment for starting my project. I was sponsored by Google to attend FOSS4G 2007, which was an exciting opportunity for me to present my project and learn more about OSGeo-related technologies.

Daniel Bundala

Here, I would like to make some comments on my experience with GRASS, Summer of Code and such. This is not very official, however, I hope that some people may find this quite useful and/or interesting.

When I applied to SoC, I had absolutely no experience with GRASS or any other GIS. Actually, my only experience with any digital maps/geography/whatever was via Google Maps. I had never had a need to use anything else before and so I had though that it is basically the only thing one may ever need. It did not take a long to realize how wrong I was...

In general, I was very satisfied with my work on GRASS; definitely, it was much better than I expected. I learnt, many new algorithm and methods that I implemented into GRASS. Also, the courses on linear algebra and calculus I have taken were quite handy at some point. Finally! Moreover, I am now more experienced and confined user of GRASS. I recall, that during the first few weeks, I did everything with mouse and worked almost solely with GUI. But at the end of the summer, I discovered the beauty and effectiveness of command line and so I run GRASS in text mode only now...

One particular event, I still remember, is that Wolf, my mentor, once sent me a paper concerning some vector generalization I worked on. This would not be a big deal if it were not in German. I really believe, that my German teacher would be proud of me as I read it and understood what was it about. Well, maybe not, as after 4 years of "intensive" study I was able to understand not even the every other word.

To sum up, I have to say, that I spent the last summer very productively. I still read GRASS mailing list almost every day. Partially, because I want to know about any possible bugs in my module, but mostly because I am still interested in the project itself. Also, it was great programming/linguistic experience and I hope I will be able to repeat it at some point in the future.