Difference between revisions of "FOSS4G 2009 Code Sprint"
| Line 83: | Line 83: | ||
'''Goals:''' | '''Goals:''' | ||
| − | * Progress ISO 19107 / GML 3D geometry collaboration (OSGeom) | + | * Progress ISO 19107 / GML 3D geometry collaboration (OSGeom). See <tt><java-collab@lists.osgeo.org></tt> for more. |
| Line 89: | Line 89: | ||
Some subset of Markus Schneider's proposal: | Some subset of Markus Schneider's proposal: | ||
| − | + | # 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. | sanitizing the model. Of course we would take on the operations subject again, when we find consensus here. | ||
| − | + | # 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 | |
| − | SFS geometries: | + | #* 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 | |
| − | |||
| − | ISO 19107/GML 3 | ||
| − | |||
| − | |||
| − | |||
| − | 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. | in the osgeom repository for now (and no implementations), I would create interfaces from the factories. | ||
| − | + | # Add a basic implementation that is just a bean representation without operations. We could finally start to add JUnit | |
| − | |||
tests then. | tests then. | ||
| − | + | # 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 | 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 | setting up geometries for testing much easier. Maybe we could keep the GML parsing/exporting isolated from the rest of | ||
the code. | the code. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Project == | == Project == | ||
Revision as of 23:31, 15 September 2009
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). See <java-collab@lists.osgeo.org> for more.
Plan:
Some subset of Markus Schneider's proposal:
- 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.
- Add factories. I would like to add two factories similar to the ones in the deegree 3 SVN:
- SFS geometries:
- ISO 19107/GML 3
- 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.
- Add a basic implementation that is just a bean representation without operations. We could finally start to add JUnit
tests then.
- 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.
Project
Coordinator:
- .
Attending:
- Person 1
- Person 2
Goals:
Describe goals ...