FOSS4G2007 CodeSprint
Back to FOSS4G2007...
Organizing Contacts
Code Sprint - what's that?
A code sprint is usually organized by a group that is using an open source project and wants to see something done. They fly the developers to a single location and feed them for a couple of days with the necessities of the hacking life (internet, caffeine, electricity). The communication that happens from face to face hacking usually lasts the project for a year or more. You see this a lot in projects like Drupal etc...
Motivation and Direction
A day, a code base, and your imagination?
On the Friday after the conference, a big room with internet connectivity, lots of tables and flip charts will be arranged. Projects can use the time and venue for organizational discussions, development roadmaps, and group resolution of thorny issues in their code bases.
Is this your First Sprint? Here is some background information to get you started:
- http://www.infrae.com/about/activities/sprintathon/tips
- http://www.onlamp.com/pub/a/python/2006/10/19/running-a-sprint.html
- Example Sprint (from same people who do GeoServer): http://www.openplans.org/projects/bbq-sprint
To participate, start a section below for your project.
GeoTools
Attending
Goals
- To flesh out issue X until it works right.
GRASS
Attending
Goals
- Hack session
GDAL / Mapserver
Attending
Goals
GeoNetwork / Metadata Madness
Goals
Building crawler/harvester/aggregator applications on top of the GeoNetwork metadata catalog network and similar interfaces. Plugging client stuff like gvSIG and uDig into it.
Attending
OpenLayers
Attending
Goals
Hack, hack, hack. I think this will be OpenLayers 2.6 or 2.7?
Some specific ideas:
- OL Context/WMC+ - read/write support for and OWS Context style doc
- SLD support - edit/read/write
- Renderer Optimizations
- consider attributing geometry components with a minResolution below which the renderer doesn't deal with them
- clipping - svg supports clipping, we need to consider clipping or another method of dealing with geometries that extend beyond the renderer bounds
QGIS
Attending
Goals
Here are some goals/wishes/ideas for the code sprint:
1. I would love to get some traction on expanding the "Tim Tutorials" into a more generic and robust framework for stand alone apps. Focusing on the Python bindings would be my preference. (Aaron Racicot)
2. Build an all-in-one data browser:
- Display a tree of all QGIS supported types, including PostGIS and WMS
- Support drag and drop from the browser to the QGIS map canvas
- Include file/layer management tools
3. I would prefer a discussion in which direction symbolisation should go. (Horst Düster)
SWIG Bindings
SWIG bindings are increasingly used and could be used by many projects. GDAL uses them, and this sprint will focus in GDAL's (new generation) bindings but more general discussion, goal setting, and talk on integration is very much hoped for.
Attending
Goals
- present a short introduction to SWIG (AJ: I'll prepare this)
- develop a vision of how we integrate tools and create common look and feel high-level programming interfaces with SWIG bindings
Specifically for GDAL (from Tamas Szekeres' email):
- harmonize the typemap usage between the various bindings (and update the README.typemaps accordingly)
- determine which of the gdal/ogr features should be added to (or perhaps removed from) the SWIG interface.
- look over the possibilities to automate the creation of the code-comment-documentation for the various languages.
- construct the expected object model diagram to follow by the various languages (and publish the model itself)
- discuss the language specific issues and the expected treatments.
Udig / JGrass
Attending
Goals
Currently these are proposals we are working on selecting a subset of these goals.
| Topic | Description |
|---|---|
| Animation Framework | If we could code up an example animation (say a point moving over a road network), then it becomes much easier for newcommers to work on fleshing this out. We could come up with a list of topics as the meeting draws nearer and decide on site as to which we wanted to tackle. |
| Debug uDig Trunk | uDig trunk was moved to Geotools trunk some time ago but the changes were major and many bugs still exist. Styling for example still doesn't work |
| Better GRASS compatibility | better GRASS compatibility through JGrass |
| Wizard and DND | Separate catalog wizards and Drag and Drop code to simplify both problems |
| Rendering | Rendering has been in need of an overhaul for quite some time. Lets fix it |
| Remove Cruft | Lets comb the code base and get rid of some of the ugly/unused |
| 3D visualization | let's talk a bit about 3D, jogl, jirr and other nasty things and udig |
| Italian translation of uDig | I know this is rather utopic, but you never know :) |
| Definition of a portable workspace | UDig should have the possibility to export the workspace, either automagically or even by just moving a folder from one user to the other. It's about relative paths, about copying data eventually into the workspace and things like that. I believe this is a critical problem for usability. |
Voting (scale 1-5)
| ID | Voter | Voter | Voter |
|---|---|---|---|
| Animation Framework | 1 | 4 | 4 |
| Debug uDig Trunk | 1 | 1 | 0 |
| Better GRASS compatibility | 3 | 5 | 5 |
| Wizard and DND | 4 | 3 | 0 |
| Rendering | 4 | 3 | 5 |
| Remove Cruft | 4 | 3 | 0 |
| 3D visualization | 5 | 5 | 5 |
| Italian translation | x | 3 | 5 |
| Portable workspace | x | 5 | 5 |
French translation
Contact: Yjacolin
Attending
See Translation sprint (in french)
Goals
Translate a documentation into french. The document has to be defined, some exemple : qgis, openlayers, OSGeo website, GRASS, MapBuilder, MapLab, OSGeo Journal Vol. 2, etc.