Summer Of Code

Google's SoC program allows for students to receive a stipend for developing open source software under the tutelage of a mentor from the project. Here are some Google Summer of Code evelopment ideas:

Applications

Improved Editing Application

Editing GIS data usually means working with a schema, fixed attributes, etc. Additionally, users expect to simply be able to deploy an 'application' rather than needing to write a lot of custom code to deploy an editing interface. Create a generalized editing application which has support for reading from a schema (either via some remote request, or defined locally) to determine attributes, and using that schema to build a UI for editing the attributes of various features. The end result of this would be a product which is suitable for deployment against a specific remote-server with minimal configuration of application level setup: simply set up the server information, and possibly the schema (if the server can't deliver it) and no additional code is necessary.

This would teach the student about:

• How OpenLayers works with remote data sources
• How the vector editing tools need to interact with each other
• How web-based editing happens via the specific protocol supported.

KML WYSIWYG

KML has essentially become the "HTML of the GeoWeb"... but unlike HTML, there are relatively few tools for crafting KML in a GUI-like interface. Unlike HTML, geographic information is hard to visualize as text, so a UI for building this information is even more important than in the case of HTML. Create an OpenLayers-based KML generation tool, which allows users to do something akin to WYSIWYG development of KML information, including styling, name/description fields, etc. The end result should be a KML file which can be serialized from the information -- this will most likely be a specialized KML serializer, built on top of Format.KML, with the additional serialization of styles, descriptions, etc. that might otherwise not be included in the KML.

This would teach the student about:

• The KML Format and how it is used on the web
• How the KML format is used in OpenLayers
• How to build a UI for allowing user-centric development of interesting geographic-based information.

Style Editing

One of the biggest difficulties with developing cartography in open source tools is the lack of support for any tools to build cartographic styles. Web-based mapping is especially suffers in this regard, since web mapping typically requires significantly more cartographic development to support the many scales of visualization. One of the best ways to improve this is via in-browser cartographic development, using standards like SLD to describe styles, and then passing these styles up to a server for rendering. This project could be to build a browser-based styling engine to develop high-quality cartographic representations in a standards oriented way. It is likely that some level of vector-based rendering would be useful as a first pass, allowing the user of the application a highly interactive styling approach which can then be confirmed with a round trip to the server.

This would teach the student about:

• The way that OpenLayers does styling of its vector features
• Standards for generating style information (SLD)
• The way to interact with remote servers to request styled layers
• The aspects of styling which are important to users, and how to build a good UI around them.

Library Improvements

Remote Data Management Improvements

Improve the way that OpenLayers interacts with remote datasources by writing code to abstract protocols away from the application level, allowing for the use of any number of different protocols for managing remote data.

Vector rendering improvements

Support for text in vector rendering?

Good for a student who is interested in:

• SVG / VML-based in-browser rendering
• Improved support for in-browser vector visualization

Memory Management

Due to quirks in the way that browsers handle memory management, it is necessary in Javascript to carefully clean up references in Javascript to DOM objects and vice versa. Currently, OpenLayers has a framework for doing this, but the way it is done is not always sufficient to ensure that the memory leaks are properly cleaned up.

It should be possible, using tools like  Drip, and other memory leak finding tools, to explore the different OpenLayers classes looking for memory leaks. It is likely that the end result of this would be to make OpenLayers more robust, and usable for longer sustainted periods of time.

The student would:

• Get a good overview of OpenLayers coding practices without requiring too much in the way of understanding of Javascript ahead of time
• Be developing a more robust baseline application profile for use of OpenLayers in a broader variety of situations.
• End up with a good solid baseline knowledge of a wide swath of the OpenLayers codebase.

Documentation Efforts

Improved Prose User Documentation

Currently, user documentation for OpenLayers is lacking. Writing a prose getting started document which describes how to move forward with some trivial tasks in OpenLayers would help recruit more users. A student could take this as a task and develop a significant body of text for describing aspects of how to use OpenLayers, by looking at the various examples and writing descriptions on the various ways to use them. Some areas which could use significantly more documentation are:

• Getting Started
• Styling vector features
• Configuring OpenLayers to talk to your own server
• Using OpenLayers with Google Maps and other commercial layers
• How to manage loading data from remote servers

Each of these would allow for significant expansion into the how, why, and wherefore of the task.