FOSS4G 2009 Code Sprint

Organizing Contacts

• Jody Garnett, Tyler Mitchell

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...

Venue

Venue hasn't been confirmed yet, but will likely be Ultimo TAFE, which is 15 minutes walk from the Sydney Convention and Exhibition Centre where the conference is being held. TAFE is a government sponsored Tertiary Education centre and has plenty of rooms, white boards etc.

Time and Date

Date: Saturday 24 October (the day after the conference).

Time to be confirmed.

Motivation and Direction

A day, a code base, and your imagination?

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.

Project

Coordinator:

• Paul Ramsey

Attending:

• Person 1
• Person 2

Goals:

• Bug fixes and clean-up for a 1.5 release.

uDig & friends

Coordinator:

• Andrea Antonello

Attending:

• Person 1
• Person 2

Goals:

Describe goals ...

OSGeo Marketing & Education

Coordinator:

• Tyler Mitchell

Attending:

• Person 1
• Person 2

Goals: Review marketing and outreach ideas and needs. For all those who are around during this day but not going to do coding and want to talk more generally about OSGeo directions, etc. Likely follow-up from BoF events

Geometry

Venue:

• This sprint will occur at Intersect (?) on Sunday 25 October (?)

Coordinator:

• Ben Caradoc-Davies

Attending:

• Ben Caradoc-Davies
• ...

Goals:

• Progress ISO 19107 / GML 3D geometry collaboration (OSGeom) between GeoTools/GeoServer and deegree communities.

Plan:

Some subset of Markus Schneider's proposal:

-------- Original Message --------
Subject: [Java-collab] Re: geometry next steps
Date: Thu, 20 Aug 2009 17:13:02 +0800
From: Markus Schneider
To: java-collab@lists.osgeo.org

Hi all,

Jody Garnett wrote:
> I was hoping to write code examples in order to compare how easy the
> code is to read / use / understand. I don't need the classes to work for
> that; only to define the factory interfaces. Many of the trade-offs I
> would like to make at this stage are about making the work accessible to
> java programmers (and if we are keen - reducing the number of keystrokes
> they need to type). I also should check that the "mvn javadoc:javadoc"
> target works and review the resulting javadocs.

Looking at the amount of emails and subjects, I got the feeling that we should focus on the representation and creation
aspects first. Especially the integration of operations appears to be quite a subject and we will need time to check the
different approaches (e.g. the one proposed by Jorge). And there seem to be enough issues to be solved first. Therefore
I would suggest the following next steps:

1. Remove all topological and spatial analysis methods in the interfaces from the SVN for now, so we can focus on
sanitizing the model. Of course we would take on the operations subject again, when we find consensus here.

2. Add factories. I would like to add two factories similar to the ones in the deegree 3 SVN:

SFS geometries:

- http://download.deegree.org/deegree3/nightly/core/javadoc/org/deegree/geometry/SimpleGeometryFactory.html

ISO 19107/GML 3

- http://download.deegree.org/deegree3/nightly/core/javadoc/org/deegree/geometry/GeometryFactory.html

In deegree 3, these factories are bound to a JTS-based implementation. As we only have interfaces for the geometry types
in the osgeom repository for now (and no implementations), I would create interfaces from the factories.

3. Add a basic implementation that is just a bean representation without operations. We could finally start to add JUnit
tests then.

4. Add GML parsers/exporters. I understood that one may want to keep this aspect out of the repository, but I don't see
how we could test the difficulties in representing GML geometries (e.g external xlinks) without this. It also would make
setting up geometries for testing much easier. Maybe we could keep the GML parsing/exporting isolated from the rest of
the code.

A huge benefit would be people can actually start to put the library to use -- and this will most likely add momentum to
the whole project.

> Actually do we have a place where we could publish the javadocs; we
> would get more feedback from this email list if there was a link to
> javadocs to review.

Can you make sure that the javadoc target works? We can set up an automated build process and publishing of the javadocs
(probably next week). BTW, the deegree 3 geometry javadocs can be found here:
http://download.deegree.org/deegree3/nightly/core/javadoc/

Best regards,
Markus

-- 
Markus Schneider

Project

Coordinator:

• .

Attending:

• Person 1
• Person 2

Goals:

Describe goals ...