OSGeo - User contributions [en]

Draft Project Graduation Checklist Draft

2012-01-16T14:14:33Z

Wiki-Pagameba: /* Processes */

'''Draft copy of [[Project_Graduation_Checklist]]. The official copy of this document lives at http://www.osgeo.org/incubator/process/project_graduation_checklist.html'''.

= Document Status =

'''IncCom Document Number''': X

'''Version''': 2.0-RC1

'''Last Updated''': January 2012.

'''Status''': Draft

= Purpose =

The purpose of this checklist is to determine whether an Incubator Project produces quality products, remains true to its stated licence and is sustainable. Satisfying this checklist is a pre-requisite for graduation.

A project should have institutionalized the processes in this list or provide justification why the process is not used.

= Terms and Definitions =

; Mentor : A member of the Incubation Committee chosen to assist a Project through the Incubation Process.
; Institutionalized Process : A documented process which which addresses a need and is actively in use. It typically takes months before a process becomes institutionalized. ''A more detailed definition of institutionalization is found in the [http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr012.pdf Capability Maturity Model (CMMI)] - "Generic Goal 2: Institutionalize a Managed Process"''

= Checklist =

== Intellectual Property and License ==

We need to ensure that project owns or otherwise has obtained the ability to release the project code by completing the following steps:
# The project code, documentation and data has been adequately vetted to assure it is all properly licensed as per a [http://www.osgeo.org/incubator/process/codereview.html provenance review].
# All code contributors have agreed to abide by the project's license policy, and this agreement has been documented and archived.
# The project has checked for inappropriate use of trademark or patents and the results of such checks have been documented.
# The project has the ability to shut off downloads if a blocking legal issue is found.

== Processes ==

# The project has code under configuration management. Eg, subversion, git.
# The project uses an issue tracker and keeps the status of the issue tracker up to date.
# The project has documented its management processes. This is typically done within a Developers Guide or Project Management Plan.
#* The project has a suitable governance policy ensuring decisions are made, documented and adhered to. This typically means a Project Management Committee has been established with a process for adding new members. A robust Project Management Committee will typically draw upon developers, users and key stakeholders from multiple organisations as there will be a greater variety of technical visions and the project is more resilient to a sponsor leaving.
#* The project uses public communication channels for decision making to maintain transparency. E.g. archived email list(s), archived IRC channel(s), public issue tracker.

== Documentation ==

# The project has user documentation:
#* Including sufficient detail to guide a new user through performing the core functionality provided by the application.
# The project has developer documentation:
#* Including checkout and build instructions.
#* Including commented code, ideally published for developer use. Examples: javadocs for Java applications, or Sphinx documentation for Python applications.
#* Providing sufficient detail for an experience programmer to contribute patches or a new module in accordance with the project's programming conventions.

==Release Procedure==

In order to maintain a consistent level of quality, the project should follow defined release and testing processes.

# The project follows a defined release process:
#* Which includes execution of the testing process before releasing a stable release.
# The project follows a documented testing process:
#* Ideally, this includes both automated and manual testing
#* Ideally this includes documentation conformance to set quality goals, such as reporting Percentage Code Coverage of Unit Tests.
# Release and testing processes provide sufficient detail for an experienced programmer to follow.

= Community =

The OSGeo Foundation is made up of a number of committees, projects and local chapters. This section gathers up information these groups have requested from OSGeo projects.

== Board ==

The OSGeo [[Board]] holds ultimate responsibility for all OSGeo activities. The Board requests:

# A project provide a Project Officer as a contract point:
#* The Project Officer should be listed at: [[Contacts#Software_Projects|Project Officer]]
#* This person is established when the incubation committee recommends the project for graduation
#* Your community can change the project officer as needed (just add an agenda item to the next board meeting so they can recognise the change of officer).

== Marketing ==

Access to OSGeo's [[Marketing_Committee]] and associated [[Marketing_Pipeline]] is one of the key benefits of joining the OSGeo foundation. The Marketing Committee requests:

# Marketing artefacts have been created about the project in line with the incubation criteria listed in the OSGeo Marketing Committee's [http://wiki.osgeo.org/wiki/Marketing_Artefacts Marketing Artefacts]. This lists the documentation requirements for [http://live.osgeo.org OSGeo-Live]. Marketing Artefacts include:
#* Application Overview
#* Application Quick Start
#* Logo
#* Graphical Image
# Ideally, stable version(s) of executable applications are bundled with appropriate distributions, (In most cases, this will at least include [http://live.osgeo.org OSGeo-Live], but may also include [http://wiki.debian.org/DebianGis DebianGIS], [https://wiki.ubuntu.com/UbuntuGIS UbuntuGIS], and/or [http://trac.osgeo.org/osgeo4w/ osgeo4w] [http://www.maptools.org/ms4w/ ms4w], etc.)

== Projects ==

Projects do not exist in isolation; and are expected to communicate and collaborate on key issues. As an example the PostGIS release procedure asks that the release be checked with MapServer, GeoServer and others.

== SAC ==

The [[SAC|System Administration Committee]] is available to help infrastructure and facilities. Information for this committee is collected as part of the [[Project Status Template]]. The following should be set up:
* A http://projectname.osgeo.org domain name.

A project may optionally request SAC help to make use of:
* OSGeo issue tracker
* OSGeo mailing list
* OSGeo svn
* http://downloads.osgeo.org

[[Category: Incubation]]

Draft Project Graduation Checklist Draft

2012-01-16T14:14:06Z

Wiki-Pagameba: /* Intellectual Property and License */

'''Draft copy of [[Project_Graduation_Checklist]]. The official copy of this document lives at http://www.osgeo.org/incubator/process/project_graduation_checklist.html'''.

= Document Status =

'''IncCom Document Number''': X

'''Version''': 2.0-RC1

'''Last Updated''': January 2012.

'''Status''': Draft

= Purpose =

The purpose of this checklist is to determine whether an Incubator Project produces quality products, remains true to its stated licence and is sustainable. Satisfying this checklist is a pre-requisite for graduation.

A project should have institutionalized the processes in this list or provide justification why the process is not used.

= Terms and Definitions =

; Mentor : A member of the Incubation Committee chosen to assist a Project through the Incubation Process.
; Institutionalized Process : A documented process which which addresses a need and is actively in use. It typically takes months before a process becomes institutionalized. ''A more detailed definition of institutionalization is found in the [http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr012.pdf Capability Maturity Model (CMMI)] - "Generic Goal 2: Institutionalize a Managed Process"''

= Checklist =

== Intellectual Property and License ==

We need to ensure that project owns or otherwise has obtained the ability to release the project code by completing the following steps:
# The project code, documentation and data has been adequately vetted to assure it is all properly licensed as per a [http://www.osgeo.org/incubator/process/codereview.html provenance review].
# All code contributors have agreed to abide by the project's license policy, and this agreement has been documented and archived.
# The project has checked for inappropriate use of trademark or patents and the results of such checks have been documented.
# The project has the ability to shut off downloads if a blocking legal issue is found.

== Processes ==

# The project has code under configuration management. Eg, subversion, git.
# The project uses an issue tracker and keeps the status of the issue tracker up to date>.
# The project has documented its management processes. This is typically done within a Developers Guide or Project Management Plan.
#* The project has a suitable governance policy ensuring decisions are made, documented and adhered to. This typically means a Project Management Committee has been established with a process for adding new members. A robust Project Management Committee will typically draw upon developers, users and key stakeholders from multiple organisations as there will be a greater variety of technical visions and the project is more resilient to a sponsor leaving.
#* The project uses public communication channels for decision making to maintain transparency. E.g. archived email list(s), archived IRC channel(s), public issue tracker.

== Documentation ==

# The project has user documentation:
#* Including sufficient detail to guide a new user through performing the core functionality provided by the application.
# The project has developer documentation:
#* Including checkout and build instructions.
#* Including commented code, ideally published for developer use. Examples: javadocs for Java applications, or Sphinx documentation for Python applications.
#* Providing sufficient detail for an experience programmer to contribute patches or a new module in accordance with the project's programming conventions.

==Release Procedure==

In order to maintain a consistent level of quality, the project should follow defined release and testing processes.

# The project follows a defined release process:
#* Which includes execution of the testing process before releasing a stable release.
# The project follows a documented testing process:
#* Ideally, this includes both automated and manual testing
#* Ideally this includes documentation conformance to set quality goals, such as reporting Percentage Code Coverage of Unit Tests.
# Release and testing processes provide sufficient detail for an experienced programmer to follow.

= Community =

The OSGeo Foundation is made up of a number of committees, projects and local chapters. This section gathers up information these groups have requested from OSGeo projects.

== Board ==

The OSGeo [[Board]] holds ultimate responsibility for all OSGeo activities. The Board requests:

# A project provide a Project Officer as a contract point:
#* The Project Officer should be listed at: [[Contacts#Software_Projects|Project Officer]]
#* This person is established when the incubation committee recommends the project for graduation
#* Your community can change the project officer as needed (just add an agenda item to the next board meeting so they can recognise the change of officer).

== Marketing ==

Access to OSGeo's [[Marketing_Committee]] and associated [[Marketing_Pipeline]] is one of the key benefits of joining the OSGeo foundation. The Marketing Committee requests:

# Marketing artefacts have been created about the project in line with the incubation criteria listed in the OSGeo Marketing Committee's [http://wiki.osgeo.org/wiki/Marketing_Artefacts Marketing Artefacts]. This lists the documentation requirements for [http://live.osgeo.org OSGeo-Live]. Marketing Artefacts include:
#* Application Overview
#* Application Quick Start
#* Logo
#* Graphical Image
# Ideally, stable version(s) of executable applications are bundled with appropriate distributions, (In most cases, this will at least include [http://live.osgeo.org OSGeo-Live], but may also include [http://wiki.debian.org/DebianGis DebianGIS], [https://wiki.ubuntu.com/UbuntuGIS UbuntuGIS], and/or [http://trac.osgeo.org/osgeo4w/ osgeo4w] [http://www.maptools.org/ms4w/ ms4w], etc.)

== Projects ==

Projects do not exist in isolation; and are expected to communicate and collaborate on key issues. As an example the PostGIS release procedure asks that the release be checked with MapServer, GeoServer and others.

== SAC ==

The [[SAC|System Administration Committee]] is available to help infrastructure and facilities. Information for this committee is collected as part of the [[Project Status Template]]. The following should be set up:
* A http://projectname.osgeo.org domain name.

A project may optionally request SAC help to make use of:
* OSGeo issue tracker
* OSGeo mailing list
* OSGeo svn
* http://downloads.osgeo.org

[[Category: Incubation]]

GeoMajas Incubation Status

2010-10-05T13:44:38Z

Wiki-Pagameba:

= Document Status =

'''IncCom Document Number''': X

'''Version''': 1.2

'''Status''': draft

= Purpose =

The project representative and mentor will use this template to inform the IncCom of the project status on a periodic basis. The state of the project, as reported using this template, will be the initial indication that a project is reaching graduation.

= Terms and Definitions =

; IncCom : definition

= Template =

== General ==

; Has the project been approved for incubation by the OSGeo board?
: Yes

; Has an Incubation Mentor been assigned to the project?
: Paul Spencer
: Pieter De Graef has been assigned by the Geomajas project as formal contact with the project.

== Infrastructure Transition ==

; Has the projectname.osgeo.org domain been populated with the projects web presence?
: Analogous to the other OSGeo projects, a project description page has been created: http://www.osgeo.org/geomajas

; Is the OSGeo bug tracker being used for the project?
: The Geomajas project already has a JIRA issue tracker set up. Currently there are no plans to migrate. The Geomajas PSC has full control over this issue tracker (including user management, project management, ...), and it also has a long history. The history is important, and also, a migration would take quite some time for which noone on the Geomajas PSC has time available atm.

; Is the OSGeo mailing list manager (http://lists.osgeo.org/) being used for the project?
: Geomajas currently has 3 mailing lists: a technical list, an automated issues list and an automated commit list. The technical list is hosted by Geosparc (see [http://lists.geomajas.org/mailman/listinfo/MAJAS-dev technical mailing list]). The other 2 are hosted on sourceforge. There is no real reason why the technical mailing list can't be migrated to OSGeo, provided that the entire history can easily be migrated as well (also on markmail, nabble, etc...)

; Is the OSGeo SVN being used for the project?
: The Geomajas project already has a SVN set up. There have been some discussion around moving to GIT, but nothing concreet has come out of it.

; Are binary and source downloads available from http://download.osgeo.org ?
: Geomajas makes use of the Maven distribution system. All files can be found in the Geomajas Maven repository (http://maven.geomajas.org). Instead of downloading, users are encouraged to follow the getting started guide.
: Packaged downloads of the demo application are stored on [https://sourceforge.net/projects/geomajas/ Sourceforge]. Sourceforge provides easy access, and has excellent statistics. Keep in mind that this is a demo, not the core Geomajas library itself.

== Community Functioning ==

; Is there a functioning user support mechanisms (ie. mailing list)?
: The Geomajas project website features a [http://www.geomajas.org/forum forum] for end-user questions.
: For developers, there is a [http://lists.geomajas.org/mailman/listinfo/MAJAS-dev technical mailing list].
: For contributors, there is a [https://lists.sourceforge.net/mailman/listinfo/geomajas-issues issue mailing list] onto which all JIRA issue changes are published.
: For contributors, there is also a [https://lists.sourceforge.net/lists/listinfo/geomajas-commits commit mailing list] onto which all SVN commits are automatically published. There is also a Hudson present who makes hourly builds, and publishes it's findings on the commit mailing list.

; Are source and binary downloads for the package available?
: Packaged downloads are stored on [https://sourceforge.net/projects/geomajas/ Sourceforge]
: Geomajas maven repositories:
:: [http://apps.geomajas.org/nexus/content/repositories/thirdparty third party repository]
:: [http://apps.geomajas.org/nexus/content/repositories/snapshots snapshot repository]

; Has a Project Steering Committee been formed, and given control of the project?
: The Geomajas project has set up a governing body, called the Project Steering Committee (PSC). See [http://www.geomajas.org/community/project-steering-committee Geomajas PSC]

; Does the Project Steering Committee have documentation on project procedures for PSC decisions, contributor guidelines, etc.
: Project procedures regarding new proposals, or PSC changes: see [http://www.geomajas.org/community/project-steering-committee Geomajas PSC]
: Contributor guidelines, see: [http://files.geomajas.org/maven/trunk/geomajas/docbook-contributorguide/html/master.html contributor guide]

; How many active developers are there? Are they from multiple organizations?
: At the moment of writing, 9 people have signed a CLA . These people work for the following companies: Geosparc nv, DFC Software Engineering, BeanPole and FKS.
: Detailed information, see [http://spreadsheets.google.com/pub?key=0Auonpsn-5BeQdDd6SF8yS3lrb0ZqbGxiVzBRQlFhWHc&gid=2 spreadsheet]

== Foundation Membership ==

; Have project documents been updated to reflect membership in the foundation, and the relationship of the project to the foundation?
: The Geomajas website clearly indicates OSGeo membership, through a banner at the top of each page.

; Has an effort been made to brand the project web site with OSGeo foundation web styling and branding marks?
: The banner of the Geomajas project website contains an OSGeo logo, that links to the OSGeo website.

== Code Copyright Review ==

; Has a [[Code Provenance Review]] document been prepared for the project?
: yes - [[GeoMajas_Provenance_Review]]

; Have issues raised in the provenance review been adequately addressed?
: Yes, all questions raised about the provenance review have been addressed.

; Are [[Commiter Responsibilities Guidelines]] covering legal issues in place?
: In general, see: [http://files.geomajas.org/maven/trunk/geomajas/docbook-contributorguide/html/master.html contributor guide]
: The Geomajas project has set up a governing body, called the Project Steering Committee (PSC). See [http://www.geomajas.org/community/project-steering-committee Geomajas PSC]
: All contributors has signed a Contributor License Agreement.
:: CLA Document [http://files.geomajas.org/maven/trunk/geomajas/docbook-contributorguide/html/master.html#cla CLA]
:: All contributors have signed a CLA: see [http://spreadsheets.google.com/pub?key=0Auonpsn-5BeQdDd6SF8yS3lrb0ZqbGxiVzBRQlFhWHc&gid=2 spreadsheet].

[[Category:Incubation]]

GeoMajas Incubation Status

2010-05-11T12:54:26Z

Wiki-Pagameba:

= Document Status =

'''IncCom Document Number''': X

'''Version''': 1.1

'''Status''': draft

= Purpose =

The project representative and mentor will use this template to inform the IncCom of the project status on a periodic basis. The state of the project, as reported using this template, will be the initial indication that a project is reaching graduation.

= Terms and Definitions =

; IncCom : definition

= Template =

== General ==

; Has the project been approved for incubation by the OSGeo board?
: Yes

; Has an Incubation Mentor been assigned to the project?
: Paul Spencer

== Infrastructure Transition ==

''Note, for each of the following it isn't necessary to move to foundation infrastructure, but if you aren't a reason should be provided.''

; Has the projectname.osgeo.org domain been populated with the projects web presence?
: If not why, and has the project page got a prominent link to the real home?

; Is the OSGeo bug tracker being used for the project?
: If not, why?

; Is the OSGeo mailing list manager (http://lists.osgeo.org/) being used for the project?
: If not, why?

; Is the OSGeo SVN being used for the project?
: If not, why?

; Are binary and source downloads available from http://download.osgeo.org ?
: If not, why?

== Community Functioning ==

; Is there a functioning user support mechanisms (ie. mailing list)?
: indicate the available user support mechanisms, and whether they seem to be functioning well (are getting used and get answers).

; Are source and binary downloads for the package available?
: yes/no (and any caveats)

; Has a Project Steering Committee been formed, and given control of the project?
: yes/no, indicate members and whether it has effective control.

; Does the Project Steering Committee have documentation on project procedures for PSC decisions, contributor guidelines, etc.
: yes/no - provide pointers to various related documents.

; How many active developers are there? Are they from multiple organizations?
: Indicate number and some organizations involved.

== Foundation Membership ==

; Have project documents been updated to reflect membership in the foundation, and the relationship of the project to the foundation?
: If not, indicate when this will occur.

; Has an effort been made to brand the project web site with OSGeo foundation web styling and branding marks?
: If not, indicate what is planned. (''note: currently an OSGeo web style has not bee established'')

== Code Copyright Review ==

; Has a [[Code Provenance Review]] document been prepared for the project?
: yes - [[GeoMajas_Provenance_Review]]

; Have issues raised in the provenance review been adequately addressed?
: indicate outstanding issues.

; Are [[Commiter Responsibilities Guidelines]] covering legal issues in place?
: yes/no - point to the guidelines and indicate if it is adopted by PSC, and accepted by all commiters.

[[Category:Incubation]]

Layout Specification

2010-04-08T12:50:22Z

Wiki-Pagameba: Created page with 'This is just a starting point for discussion on how to describe the layout of a print production document. == DMSG INI File Format == This structure was developed by [ht…'

This is just a starting point for discussion on how to describe the layout of a print production document.

== DMSG INI File Format ==

This structure was developed by [http://dmsolutions.ca DM Solutions Group] for its [http://mapsherpa.com MapSherpa] PDF map generator. It is processed by some PHP code and a PDF is generated using [http://www.fpdf.org/ FPDF], although any PDF library could be used. [http://mapserver.org MapServer] is used.  The structure could easily be converted to another format such as XML or YAML.  This structure is focused on producing PDF documents from flexible templates, it is not designed to handle generic production layout tasks but it can hopefully be extended to include additional needs as they are discussed/discovered.

Here is a [http://www.mapsherpa.com/wp-content/uploads/Mont-Tremblant-Topo.pdf sample PDF ].

There are several concepts central to the structure:

*an overall document section that describes the pages in the document and default style values (font face, units of measure, document metadata)
*page sections that describe individual pages in the document (size, orientation, margins, and style values for that page) and a list of blocks in the page
*blocks that are rectangular regions to be rendered on a page.  Blocks have size, position, style values and a type
*styling uses CSS-like naming structure and values where practical
*Styles are inherited by child blocks when not explicitly defined in a child block
*all values that have units inherit the default units of the document or can have units as part of the value and are automatically converted

=== Style Keys ===

any section may define the following style keys
<pre>font-face = DejaVuSans
font-size = 12pt
font-style = normal
font-weight = normal
text-decoration = none
line-height = 16pt
text-align = left
vertical-align = top
background-color = 255 255 255 ; colors are RGB 0-255
color = 0 0 0
border-color = 0 0 0
border-width = 0 ; may use two (top-bottom and left-right)
 ; or four (top, right, bottom, left) values
margin = 0pt  ; may use two (top-bottom and left-right)
 ; or four (top, right, bottom, left) values
padding = 0pt  ; may use two (top-bottom and left-right)
 ; or four (top, right, bottom, left) values

</pre>
In addition, you can create sections that contain common styles and refer to them directly rather than defining the styles individually in a block.  It is not necessary to define all the style values, there are always default values that get inherited.
<pre>[DefaultStyle]
font-face = DejaVuSans
font-size = 12pt
font-style = normal
font-weight = normal
text-decoration = none
line-height = 16pt
text-align = left
vertical-align = top
background-color = 255 255 255
color = 0 0 0
</pre>
=== Document Section ===
<pre>; mandatory section called Document
;
; Document section can set default style values
; to be inherited by all pages/blocks either inline
; or by including a style = StyleBlock to point
; to another section that defines any or all of
; these styles

[Document]
margin = 0
units = mm
style = DefaultStyle

; document metadata embedded in the PDF, visible
; to the viewer in document info
creator = My Application
author = My Name
subject = My Subject
keywords = a list of keywords

; pages in the Document, a quirk of PHP is that
; when it parses an ini file and a key contains
; square brackets, it converts it to an array
; containing values for each key thus defined
pages[] = Page1
pages[] = Page2
</pre>
=== Page Section ===
<pre>; a Page section is a page because it was referred
; to as such by the Document section. There is no
; other identifier
[Page1]
; may define any of the style rules here and/or use
; a style = StyleBlock to import styles. Any styles
; not explicitly set inherit the style values of the
; Document.  The values that can be set explicitly on
; a page are
page-size = Letter ; Letter, Legal, A3, A4, A5 or a
 ; custom size using the format
 ; <width><units> <height><units>
orientation = Landscape ; or Portrait
margin = 0.5in ; note we use mm for the document units
 ; but we can set any sized value in any
 ; unit we wish
; the other thing that pages contain is a list of blocks
; to be rendered in that page, again using the [] syntax
; for PHP
blocks[] = MapArea
blocks[] = LegendArea
blocks[] = DetailArea
blocks[] = AttributionArea

</pre>
=== Block Sections ===

A block section has a location specified relative to its containing block, a list of blocks it contains, a type and any type-specific values.  Positioning can be broken into vertical and horizontal components.  Horizontally, you must specify at least two of left, width and right. If you specify left and right then the width is calculated automatically from the size of the parent, taking into consideration the margin, border, padding of the parent block.  Vertically you must specify at least two of top, height and bottom.  Same rules apply for height. 

Also, a block section can specify an overflow block.  When content exceeds the size of a block, the extra content is then sent to the overflow block.  Overflow blocks can be chained to other overflow blocks.  Content continues to flow until it has been completed rendered or there are no further blocks (at which point the content is truncated).
<pre>[MapArea]
top = 0 ; pinned to the top of the block it is contained in
left = 0 ; pinned to the left of the block it is contained in
right = 2in  ; pinned to the right of the block it is contained in,
 ; width is calculated automatically from the
bottom = 2in ; pinned to the right of the block it is contained in,
 ; width is calculated automatically from the
type = map  ; means use the MapBlock plugin to render this block
map = %map%  ; the map file or PHP MapScript map object to use
 ; in this case it comes from a variable that is passed
 ; to the PDF Document rendering engine at runtime
resolution = 300 ; render the map at 300 dpi, which increases the
 ; size in pixels of the map and scales all sizes
 ; and widths in the map file by the appropriate
 ; amount. This would not be necessary if we could
 ; get appropriate PDF vector output from MapServer
grid = true ; render a grid surrounding the map and on the map
gridticksize = 1mm
gridstyle = [GridStyleBlock] ; a style block that controls the style
 ; of the fonts etc when rendering the
 ; grid surround

</pre>
=== Block Types ===

There are several block types that have been created for the DMSG layout engine

*text. A generic block of text
*image. An image
*northarrow. Renders a true north arrow for a particular map block.
*map.  The map block draws a mapserver map as a raster, automatically scaling the map to higher resolution as required and embedding it as an image in the PDF.  The map block includes the ability to specify a grid surrounding the map based on a GRID layer in the map.  We extract the pixel coordinates of the intersection of the grid lines on the map with the edge of the map, do some funky math to figure out PDF coordinates based on the position of the map in the PDF and then add a neatline, grid tick marks and values outside the map itself using PDF objects
*legend.  Renders a legend for a particular map block.  We generate the legend in PDF objects rather than relying on MapServer's legend
*scalebar.  Renders a scalebar using PDF objects

OSGeo Cartographic Engine Discussion

2010-04-07T16:37:35Z

Wiki-Pagameba: /* Specification */

For more info see: [[OSGeo Cartographic Engine]]
----

== Functionality ==

Shared functions may include

* class breaks (various algorithms)
* histogram analysis
* color ramps
* RGB and possibly CYMK support (aka color transformations) etc.
* Algorithms for intelligent label placement -- for example, collision management based on rotated extent rectangles. Also, collision management against line and polygon and point features. Provision for prioritized set of text placement rules, first one to prevent collision wins.
* Symbology management
* map surround
* legend
* cartographic templates (ie. predefined map styles)
* parse and print map (geovisualization) description files

This paper might be worth looking at: [http://utpjournals.metapress.com/content/b584484743vk910g/ Extended Cartographic Interfaces for Open Distributed Processing]

== Programming Language ==

* C? C++?

Perhaps we could implement the core in C++, but provide a high level C API for applications and environments wanting to drive the library. C++ is a strong implementation language, but presenting a C API to the outside world reduces complexity calling from other languages or compiler versions and reduces "interface fragility".

* Python bindings?

There has been talk on the [http://gmt.soest.hawaii.edu/ GMT] mailing list about Python bindings to the core C API. Since GMT already has a wealth of routines for plotting directly to PS|EPS format files, this route may give developers a great head-start. There has been [http://casoilresource.lawr.ucdavis.edu/drupal/node/561 some work] on the integration of GRASS and GMT in the past, with [http://grass.gdf-hannover.de/wiki/GRASS_AddOns several user-submitted modules].

== Output Formats ==

What output formats do we want to target. I think at the core this question comes down to whether we want to render everything to a raster format or whether we wish to preserve linework, and text in non-raster form. That is, whether output output is a raster format, or a raster+vector+text format like postscript/pdf.

If a cartographic product is the objective, I think selection of an output format like PDF makes a lot of sense, but it does make interactive composition more complicated and it is possible we have limited pdf/postscript development expertise in our developer community (the GMT developers may be of help here...).

What about the possibility of exporting SVG and using Inkscape for cartographic styling and design? Inkscape is written in C++ and already has a wealth of vector graphics functionality. You could also consider using Scribus for map layout. I believe Scribus is also written in C++. Why implement the great functionality that already exists in open source programs?

Coming from the Web Mapping angle it will be interesting to be able to acquire OGC WMS maps with a pixel sizes < 0.28 mm (which is the current standard of ~ 72 or 90 dpi). This option has been suggested as a change request and is currently being discussed. It will allow to compose high resolution print maps also using OGC WMS.

Actually (2008) some GIS desktop allow to export the view to SVG format (QGIS, OpenJUMP, etc). While almost all software could save to SVG throughtPDF/Postscript drivers (ex PDF creator, opensurce). Implementing a complete symbology in Inkscape would be preferable and would solve many problem of compatibility between GIS desktops.
There are some proposal available on the web: GFOSS[http://wiki.gfoss.it/index.php/Vestire_una_mappa_con_inkscape_partendo_da_SVG] (in Italian).

== Existing code to be recycled ==

There will be code in GRASS, QGIS, the Python Cartographic Library (http://zcologia.org/cartography) and other sources which could be integrated (check license compatibility). Please indicate precisely where to find the source code, license, programming language. Please keep in mind that this is underlying library, not the graphical user interface.

* Label placement code:
** Mapserver [http://trac.osgeo.org/mapserver/browser/trunk/mapserver/maplabel.c labeling code] (MapServer License, C language)
** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.label.sa v.label.sa] (GPL, C language)
** PAL/JPAL [http://geosysin.iict.ch/PAL cartographic labelling library] (GPL, C++ language, JNI wrapper)
* Color management:
** MapGuide [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/PlatformBase/Data/Color.cpp Color] (LGPL.C++)
** OpenJump ?

* Stylization
** Cartagen Geo Style Sheets: http://wiki.cartagen.org/wiki/show/HomePage ([http://code.google.com/p/cartagen/ more])

* Symbology
** [http://www.iho.shom.fr/PUBLICATIONS/download.htm#special S-52 standard for nautical chart (ENC) symbology] and cartography from the [http://www.iho.shom.fr/ International Hydrographic Bureau]
:: [http://openev.cvs.sourceforge.net/openev/contrib/S52/ GPL library implementing the S-52 standard] (OpenEV)

* Class breaks:
** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/lib/arraystats different algorithms for class breaks] (GPL, C)
** MapGuide [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Server/src/Services/Feature/FeatureNumericFunctions.cpp CalculateDistribution] (LGPL.C++)

* Data access:
** GDAL [http://www.gdal.org/frmt_wms.html WMS driver] can help grab tiles at appropriate scale/size/resolution (to what extent?)

* Output:
** Postscript/PDF output:
*** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/ps/ps.map ps.map] (Postscript output) and [http://trac.osgeo.org/grass/browser/grass/trunk/lib/psdriver PS driver] (GPL, C)
*** [http://sourceforge.net/projects/geofunctions GeoFunctions]: Geographic XML to PDF. Not sure what specific code, but the project leaders might have some insight.
** PNG output:
*** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/lib/pngdriver PNG driver] (GPL, C)
*** See AGG below
** CAIRO output
*** GRASS [http://trac.osgeo.org/grass/browser/grass/trunk/lib/cairodriver CAIRO driver] (GPL, C)
*** [http://cairographics.org/ Cairo Graphics Library] (LGPL or MPL)
** [http://mapnik.org Mapnik] is a Free Toolkit for developing mapping applications, that can also output via Cairo
*** [http://trac.mapnik.org/wiki/XMLConfigReference Mapnik configure file format (XML)]
*** Many applicable utilities for handling Mapnik stuff.. [http://code.google.com/p/mapnik-utils/ here] - e.g cascadenik css for styling and nik2img for command line testing!

== End User Needs ==
* Print to small format medium (eg 8.5in x 11in, 11in x 14in) and large format (eg 34 x 44in)
* Interactive layout
* High quality printing
* Storage of cartographic symbolizing
* [[OSGeo map symbol set|Symbols library]]
* Separate cartographic and geographic representation (eg changes to carto does not affect geo).
* Generalization on-the-fly, based on current scale.
* Rules based cartography stored in RDBMS (eg series 400 highways are blue with double lines)
* Multiple export formats
** Geotiff
** PNG
** PDF / GeoPDF
** Postscript (need for directly sending files to printers)
** SVG
* Layout Functionality
* Text-based configuration file that applications can output to or humans can manually hack/script
* Common, interoperable data file input options
* Customizable legend with Symbology representation (textures, object symbols, etc.)

==Layout Functionality==
===Design Modeling===
Issues of layout will always be important in creating the final cartographic product. Layout templating such as that used in Natural Resources Canada's (NRCAN) Cartographic Design Specifications (http://ess.nrcan.gc.ca/pubs/carto/downloads/design_specs.pdf#page=13).

Perhaps we can learn from the desktop publishing world from the likes of the Scribus project (http://www.scribus.net/). Maybe being able to export a certain portion to scribus to handle some the major layout hurdles. A link between the cartographic library and scribus could allow for auto generation of some layout features and text such as changing declination, Projection info, and others.

=== XML and PDF===
OSGEO might be able to get behind the [http://sourceforge.net/projects/geofunctions Geo Functions] project. "Geo Functions is an open-source library of XSLT-2 / XQuery functions, templates, stylesheets and classes devoted to the processing of geographic data in XML." I understand that the original purpose of the project is to produce PDF maps from XML based data.

== Technologies ==
* Examples of application [[Configuration Files]]
* AGG (sophisticated rendering of vector/text graphics to raster format - used by MapServer, MapGuide, Mapnik).
* Freetype - text management and rendering library
* [http://cairographics.org/ Cairo] graphics library - vector, text and raster input, various output including Postscript
* [http://schemas.opengis.net/se/1.1.0/ OpenGIS Symbology Encoding Schema] A language for describing coverage and feature styles
* [http://trac.mapfish.org/trac/mapfish/wiki/PrintModuleDoc MapFish print module]

== Workflow ==

By working from the end product to a workflow might let us identify specific libraries to help with each task in the workflow required to produce a map. Edit at will.

* read geo data
** geometries
** projection
** metadata (if required)
* apply styling
** feature to style coding
* Cartographic edits
** overide some of the geometry if required (eg roads don't run through lakes)
* manual edits / retouching
* Produce other cartographic edits objects
** create suround
** create grids
** create legend
** create scale bar
** create north arrow
** Copyright notices from text file or DB
** Licensing notices from text fiel or DB
* Other
** Output size

=== Other Workflow Models ===
* [http://casoilresource.lawr.ucdavis.edu/drupal/node/561 Generic GRASS-GMT Workflow]
* [http://169.237.35.250/~dylan/grass_user_group/#GMT_and_GRASS-overview Quality Digital Cartography with GMT and GRASS]

== License ==

It is proposed to license the OSGeo Cartographic Library under LGPL. The license needs to be GPL compliant.

== Interested people ==

* [[User:Neteler|Markus Neteler]] (proposer)
* Horst Düster
* [[User:Landa|Martin Landa]]: GRASS developer
* [[User:MarcoHugentobler|Marco Hugentobler]]
* Frank Warmerdam
* [[User:Adiez|Agustin Diez]]
* [[User:mlennert|Moritz Lennert]]
* [[User:Dsampson | Dave Sampson]]: End User, Search and Rescue Maps,
* [http://casoilresource.lawr.ucdavis.edu/drupal/node/38 Dylan Beaudette]: Soil Science Researcher, OSGeo evangelist
* [[User:Tmitchell|Tyler Mitchell]]: Interested in Cairo through Mapnik
* [[User:reholl|Robert Hollingsworth]]
* [[User:Wolf|Wolf Bergenheim]]: v.label.sa developer
* [[User:HamishBowman|Hamish Bowman]]: ps.map developer
* [[User:GAruta|Giuseppe Aruta]]: Geologist
* [[User:Roy|Roy Braam]]: Software Engineer
* Ionut Iosifescu
* [[User:ajolma|Ari Jolma]]: Wants to go ahead with Cairo
* [[User:vasile|Vasile Crăciunescu]]
* [[User:Peterrushforth|Peter Rushforth]]
* [[User:Turban|Bjorn Sandvik]]: thematicmapping.org
* [[User:JoCook| Jo Cook]]
* [[User:Mloskot|Mateusz Loskot]] (potential tester, contributor and user)
* [[User:kotzino|Dimitris Kotzinos]]
* [[User:drrho|Robert Barta]]: semantic aspects of visualisation
* Giovanni Allegri: Environmental Geologist, (Web)GIS and RS Researcher
* [[User:MaksimS|Maksim Sestic]]
* [[User:oertz|Olivier Ertz]]: PAL/JPAL project, OGC Symbology Encoding conformance
* [[User:Phdbrianlee|Brian Lee]]: cartographer,GISer.
* [[User:alf|Alessandro Frigeri]]: Researcher (geophysics, planetary sciences).
* [[User:springmeyer|Dane Springmeyer]]: Mapnik Dev, keen on addressing gap in high-res printing from OS GIS
* Allan Hollander: GIS analyst and GRASS user
* The Sunburned Surveyor

==Links==
===Specification===
* [http://trac.mapfish.org/trac/mapfish/wiki/PrintModuleServer MapFish YAML Page]
* [[Layout Specification]] work in progress

[[Category: Software Stack]]
[[Category: Printing]]

GeoMajas Provenance Review

2010-02-25T13:29:39Z

Wiki-Pagameba: New page: This is a place holder for the GeoMajas Code Provenance Review

This is a place holder for the GeoMajas Code Provenance Review

GeoMajas Incubation Status

2010-02-25T13:21:13Z

Wiki-Pagameba: New page: = Document Status = '''IncCom Document Number''': X '''Version''': 1.1 '''Status''': draft = Purpose = The project representative and mentor will use this template to inform the IncCo...

= Document Status =

'''IncCom Document Number''': X

'''Version''': 1.1

'''Status''': draft

= Purpose =

The project representative and mentor will use this template to inform the IncCom of the project status on a periodic basis. The state of the project, as reported using this template, will be the initial indication that a project is reaching graduation.

= Terms and Definitions =

; IncCom : definition

= Template =

== General ==

; Has the project been approved for incubation by the OSGeo board?
: Yes

; Has an Incubation Mentor been assigned to the project?
: Paul Spencer

== Infrastructure Transition ==

''Note, for each of the following it isn't necessary to move to foundation infrastructure, but if you aren't a reason should be provided.''

; Has the projectname.osgeo.org domain been populated with the projects web presence?
: If not why, and has the project page got a prominent link to the real home?

; Is the OSGeo bug tracker being used for the project?
: If not, why?

; Is the OSGeo mailing list manager (http://lists.osgeo.org/) being used for the project?
: If not, why?

; Is the OSGeo SVN being used for the project?
: If not, why?

; Are binary and source downloads available from http://download.osgeo.org ?
: If not, why?

== Community Functioning ==

; Is there a functioning user support mechanisms (ie. mailing list)?
: indicate the available user support mechanisms, and whether they seem to be functioning well (are getting used and get answers).

; Are source and binary downloads for the package available?
: yes/no (and any caveats)

; Has a Project Steering Committee been formed, and given control of the project?
: yes/no, indicate members and whether it has effective control.

; Does the Project Steering Committee have documentation on project procedures for PSC decisions, contributor guidelines, etc.
: yes/no - provide pointers to various related documents.

; How many active developers are there? Are they from multiple organizations?
: Indicate number and some organizations involved.

== Foundation Membership ==

; Have project documents been updated to reflect membership in the foundation, and the relationship of the project to the foundation?
: If not, indicate when this will occur.

; Has an effort been made to brand the project web site with OSGeo foundation web styling and branding marks?
: If not, indicate what is planned. (''note: currently an OSGeo web style has not bee established'')

== Code Copyright Review ==

; Has a [[Code Provenance Review]] document been prepared for the project?
: yes/no - point to review document.

; Have issues raised in the provenance review been adequately addressed?
: indicate outstanding issues.

; Are [[Commiter Responsibilities Guidelines]] covering legal issues in place?
: yes/no - point to the guidelines and indicate if it is adopted by PSC, and accepted by all commiters.

[[Category:Incubation]]

Incubation Committee

2010-02-25T13:19:30Z

Wiki-Pagameba:

The project incubation committee is responsible for overseeing the incubation process for new projects entering the foundation. The incubation committee provides resources to assist new projects to reach full membership, and makes recommendations to the board when they feel projects have completed incubation.

== Documents ==

* Official incubator web page is at: http://osgeo.org/incubator/index.html (with members list)
* Incubation process docs: http://osgeo.org/incubator/process/index.html (original [[Official_IncCom_Documents|wiki draft documents]])
* [[OSGeo Labs]] - for young, OSGeo related projects that haven't reached incubation status
* List of [[Project Steering Committees]]
* Draft [[Commiter Responsibilities Guidelines]]
* Geotools Copyright Assignment ([http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.pdf pdf], [http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.odt odt]) -suitable for use as a template by other projects
* [[Project Copyright Assignment]] (older copyright assignment - GeoTools template now preferred)
* [[Contributor Agreement]] and FAQ
* [[Incubation FAQ]] (very incomplete)
* [[Project Infrastructure Migration]]
* [http://producingoss.com/html-chunk/index.html Producing OSS] - by Karl Fogel - an excellent primer on running an FOSS project.
* [http://trac.osgeo.org/osgeo/query?status=new&status=assigned&status=reopened&component=Incubator&order=priority Open Incubator Trac Issues]
* [http://trac.osgeo.org/osgeo/query?status=new&status=assigned&status=reopened&component=Incubator&keywords=%7Eapplication&order=priority Pending Incubation Applications]

== Meetings ==
Meetings are scheduled via [http://lists.osgeo.org/mailman/listinfo/incubator Mailing List] and take place via [[Getting_Started#Jump_on_IRC | IRC]] at the times specified in the [[Foundation Calendar]].
* [[IncCom Meeting1|First Meeting]]
* [[IncCom Meeting2|Second Meeting]]
* [[IncCom Meeting3|Third Meeting]]
* [[IncCom Meeting4|Fourth Meeting]]
* [[IncCom Meeting5|Fifth Meeting]]
* [[IncCom Meeting6|Sixth Meeting]]
* [[IncCom Meeting7|Seventh Meeting]]
* [[IncCom Meeting8|Eighth Meeting]]
* [[IncCom Meeting9|Nineth Meeting]]
* [[IncCom Meeting10|Tenth Meeting]]
* [[IncCom Meeting11|Eleventh Meeting]]
* [[IncCom Meeting12|Twelfth Meeting]]
* [[IncCom Meeting13|Thirteenth Meeting]]

== Progress in the incubator ==
We are watching the initial projects go through the incubation process as a method of defining what is required. The following pages track the progress (and experience) of these projects.

* [[Project Status Template]]

# gvSIG: [[gvSIG Incubation Status]] | [[gvSIG Provenance Review]]
# GEOS: [[GEOS Incubation Status]] | [[GEOS Provenance Review]]
# MetaCRS: [[MetaCRS Incubation Status]] | [[MetaCRS Provenance Review]]
# PostGIS: [[PostGIS Incubation Status]] | [[PostGIS Provenance Review]]
# GeoMajas: [[GeoMajas Incubation Status]] | [[GeoMajas Provenance Review]]

Each project may also have a page describing the Incubation process on their own community website. Please make sure to you link to the above pages and update the OSGeo Wiki page regularly so that IncCom can keep up to date.

== Graduated ==

The following status and provenance documents are for historical purposes, and are no longer actively maintained.

* Community Mapbuilder: [[Community Mapbuilder Incubation Progress]] | [[Community Mapbuilder Provenance Review]]
* FDO: [[FDO Incubation Status]] | [[FDO Provenance Review]]
* GDAL/OGR: [[GDAL Incubation Progress]] | [[GDAL Provenance Review]]
* GeoNetwork: [[GeoNetwork Incubation Status]] | [[GeoNetwork Provenance Review]]
* Geotools: [[GeoTools Incubation Progress]] | [[GeoTools Provenance Review]]
* GRASS: [[GRASS Incubation Progress]] | [[GRASS Provenance Review]]
* Mapbender: [[Mapbender Incubation Progress]] | [[Mapbender Provenance Review]]
* MapGuide: [[MapGuide Incubation Status]] | [[MapGuide Provenance Review]]
* MapServer: [[MapServer incubation status]] | [[MapServer Provenance Review]]
* OpenLayers: [[OpenLayers Incubation Status]] | [[OpenLayers Provenance Review]]
* OSSIM: [[OSSIM incubation status]] | [http://trac.osgeo.org/ossim/wiki/ossimprovenance OSSIM Provenance Review]
* QGIS: [[QGIS Incubation Status]] | [[QGIS Provenance Review]]
* deegree: [[deegree Incubation Status]] | [[deegree Provenance Review]]

[[Category:Incubation]]
[[Category:Committees]]

User:Pagameba

2008-04-20T20:56:26Z

Wiki-Pagameba:

Paul Spencer
[[Category:OSGeo Member]]
CTO, [http://www.dmsolutions.ca DM Solutions Group]

* [http://trac.osgeo.org/fusion Fusion]
* [http://www.openlayers.org Open Layers]
* [http://mapguide.osgeo.org Map Guide Open Source]
* [http://ka-map.maptools.org ka-Map]
* [http://chameleon.maptools.org Chameleon]
* [http://maptools.org MS4W/MapLab]
* [http://openev.sourceforge.net OpenEV]

FOSS4G2007 CodeSprint

2007-09-08T19:39:59Z

Wiki-Pagameba: /* Goals */

Back to [[FOSS4G2007]]...

== Organizing Contacts ==

* [[User:Jive | Jody Garnett]]

== 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 [http://www.foss4g2007.org/code_sprint/ 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 ===

* Andrea Aime
* [[User:Jdeolive | Justin Deoliveira]]
* [[User:Jive | Jody Garnett]]
* [[User:Chorner | Cory Horner]]

=== Goals ===

We are going to to do a cross project code sprint (with GeoServer and uDig developers) focused on changing the internals over to the new Feature model. If we run across any old Filter code we will take care of it as well. The "old" Feature interface will still be available for client code to use - this sprint is just focused on updating (and testing the heck out of) our internals.

=== Preparation ===

We need *good* code examples of how to do the following before we start: Use SimpleFeatureTypeBuilder, use SimpleFeatureBuilder. It may also help to have a big old class diagram of the Feature model.

We expect each developer to have a working build of trunk, have read the interfaces for SimpleFeature and the above code examples.

=== Out of Scope ===

There are lots of things that are going to have to follow out of scope for this sprint. I am going to bring attention to the following explicitly. *Performance* (the implementation of SimpleFeature available here is for the transition period only - optimize on your own time after we have updated the codebase to handle it). *Javadocs* - much of the javadocs will be out of date by the time we are done, type a sentence and move on.

During the code sprint you will be tempted - when you run into any good ideas on these topics simply fire an email off to the devel list and we will revisit it later.

== GRASS ==

=== Attending ===

=== Goals ===

* Hack session

== GDAL Bug Squash ==

Details at: http://trac.osgeo.org/gdal/wiki/BugSquash2007

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

* [[User:JoWalsh|Jo Walsh]]
* [[User:Fxp|François Prunayre]]

== OpenLayers ==

=== Attending ===

* [[User:crschmidt|Christopher Schmidt]]
* [[User:aaronr|Aaron Racicot]]
* [[User:tschaub|Tim Schaub]]
* [[User:euzuro|Erik Uzureau]]
* [[User:ominiverdi|Lorenzo Becchi]]
* [[User:SchuylerErle|Schuyler Erle]]
* [[User:pagameba|Paul Spencer]]

=== 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
** add <canvas> renderer
* integrate emanual's animated zooming stuff

== QGIS ==
=== Attending ===
* [[User:Gsherman|Gary Sherman]]
* [[User:Aaronr|Aaron Racicot]]
* [[User:hdus|Horst Düster]]
* [[User:spacedman|Barry Rowlingson]]

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

* [[User:ajolma|Ari Jolma]]
* [[User:szekerest|Tamas Szekeres]]

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

Cross project code sprint with the JGrass and uDig projects.

=== Attending ===

* [[User:Moovida | Andrea Antonello]]
* [[User:jeichar | Jesse Eichar]]
* [[User:silli | Silvia Franceschi]]
* [[User:Jive | Jody Garnett]]

=== Goals ===
Currently these are proposals we are working on selecting a subset of these goals.

{| border="1"
|-
! 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
|-
| Simple Feature
| GeoTools is doing a cross project code sprint and will need a uDig developer to update our trunk to SimpleFeature
|-
| 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. Should remember to isolate username/password information as well.
|}

==== Voting (scale 1-5)====
{| border="1"
|-
! ID
! Voter
! Voter
! Voter
! Voter
! Voter
|-
| Animation Framework
| 1
| 4
| 4
| 1
| 4
|-
| Debug uDig Trunk
| 1
| 1
| 0
| 4
| 4
|-
| Simple Feature
| 2
|
|
|
| 2
|-
| Better GRASS compatibility
| 3
| 5
| 5
| 2
| 0
|-
| Wizard and DND
| 4
| 3
| 0
| 4
| 3
|-
| Rendering
| 4
| 3
| 5
| 4
| 4
|-
| Remove Cruft
| 4
| 3
| 0
| 3
| 4
|-
| 3D visualization
| 5
| 5
| 5
| 4
| 4
|-
| Italian translation
| 2.5
| 3
| 5
| x
| 0
|-
| Portable workspace
| 4
| 5
| 5
| 4
| 1
|}

== French translation ==
Contact: [[User:Yjacolin|Yjacolin]]
=== Attending ===
See [[OSGeo_fr_FOSS4G_2007_fr#Traduction_sprint|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.

[[Category:Events]]
[[Category:FOSS4G2007]]
[[Category:FOSS4G]]

FOSS4G2007 CodeSprint

2007-09-08T19:30:15Z

Wiki-Pagameba: /* Attending */

Back to [[FOSS4G2007]]...

== Organizing Contacts ==

* [[User:Jive | Jody Garnett]]

== 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 [http://www.foss4g2007.org/code_sprint/ 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 ===

* Andrea Aime
* [[User:Jdeolive | Justin Deoliveira]]
* [[User:Jive | Jody Garnett]]
* [[User:Chorner | Cory Horner]]

=== Goals ===

We are going to to do a cross project code sprint (with GeoServer and uDig developers) focused on changing the internals over to the new Feature model. If we run across any old Filter code we will take care of it as well. The "old" Feature interface will still be available for client code to use - this sprint is just focused on updating (and testing the heck out of) our internals.

=== Preparation ===

We need *good* code examples of how to do the following before we start: Use SimpleFeatureTypeBuilder, use SimpleFeatureBuilder. It may also help to have a big old class diagram of the Feature model.

We expect each developer to have a working build of trunk, have read the interfaces for SimpleFeature and the above code examples.

=== Out of Scope ===

There are lots of things that are going to have to follow out of scope for this sprint. I am going to bring attention to the following explicitly. *Performance* (the implementation of SimpleFeature available here is for the transition period only - optimize on your own time after we have updated the codebase to handle it). *Javadocs* - much of the javadocs will be out of date by the time we are done, type a sentence and move on.

During the code sprint you will be tempted - when you run into any good ideas on these topics simply fire an email off to the devel list and we will revisit it later.

== GRASS ==

=== Attending ===

=== Goals ===

* Hack session

== GDAL Bug Squash ==

Details at: http://trac.osgeo.org/gdal/wiki/BugSquash2007

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

* [[User:JoWalsh|Jo Walsh]]
* [[User:Fxp|François Prunayre]]

== OpenLayers ==

=== Attending ===

* [[User:crschmidt|Christopher Schmidt]]
* [[User:aaronr|Aaron Racicot]]
* [[User:tschaub|Tim Schaub]]
* [[User:euzuro|Erik Uzureau]]
* [[User:ominiverdi|Lorenzo Becchi]]
* [[User:SchuylerErle|Schuyler Erle]]
* [[User:pagameba|Paul Spencer]]

=== 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 ===
* [[User:Gsherman|Gary Sherman]]
* [[User:Aaronr|Aaron Racicot]]
* [[User:hdus|Horst Düster]]
* [[User:spacedman|Barry Rowlingson]]

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

* [[User:ajolma|Ari Jolma]]
* [[User:szekerest|Tamas Szekeres]]

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

Cross project code sprint with the JGrass and uDig projects.

=== Attending ===

* [[User:Moovida | Andrea Antonello]]
* [[User:jeichar | Jesse Eichar]]
* [[User:silli | Silvia Franceschi]]
* [[User:Jive | Jody Garnett]]

=== Goals ===
Currently these are proposals we are working on selecting a subset of these goals.

{| border="1"
|-
! 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
|-
| Simple Feature
| GeoTools is doing a cross project code sprint and will need a uDig developer to update our trunk to SimpleFeature
|-
| 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. Should remember to isolate username/password information as well.
|}

==== Voting (scale 1-5)====
{| border="1"
|-
! ID
! Voter
! Voter
! Voter
! Voter
! Voter
|-
| Animation Framework
| 1
| 4
| 4
| 1
| 4
|-
| Debug uDig Trunk
| 1
| 1
| 0
| 4
| 4
|-
| Simple Feature
| 2
|
|
|
| 2
|-
| Better GRASS compatibility
| 3
| 5
| 5
| 2
| 0
|-
| Wizard and DND
| 4
| 3
| 0
| 4
| 3
|-
| Rendering
| 4
| 3
| 5
| 4
| 4
|-
| Remove Cruft
| 4
| 3
| 0
| 3
| 4
|-
| 3D visualization
| 5
| 5
| 5
| 4
| 4
|-
| Italian translation
| 2.5
| 3
| 5
| x
| 0
|-
| Portable workspace
| 4
| 5
| 5
| 4
| 1
|}

== French translation ==
Contact: [[User:Yjacolin|Yjacolin]]
=== Attending ===
See [[OSGeo_fr_FOSS4G_2007_fr#Traduction_sprint|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.

[[Category:Events]]
[[Category:FOSS4G2007]]
[[Category:FOSS4G]]

User:Pagameba

2007-08-20T02:34:51Z

Wiki-Pagameba:

FOSS4G2007 Session Chairs

2007-08-20T02:20:54Z

Wiki-Pagameba: /* 10:30 to 12:00 */

'''Back to [[FOSS4G2007]] ...'''

Session chairs serve as the "master of ceremonies" for one 90 minute session of presentations. Each session has three 25 minute presentations, with a 5 minute question-and-answer period after each. Chairs are expected to:
* introduce the speakers,
* ensure each speaker stays within his or her 30 minute combined presentations-plus-questions presentation limit,
* ensure the next presentation starts promptly as scheduled, and
* occasionally read off a few reminders and announcements at the end of the session.

Please add your name and email to one or more of the time slots below.

'''We need 5 session chairs for each time slot.'''

Check to ensure you are not presenting or teaching a lab during the session timeslot you are volunteering for.
([http://www.foss4g2007.org/program_overview/tuesday Tuesday Schedule,]
[http://www.foss4g2007.org/program_overview/wednesday Wednesday Schedule,]
[http://www.foss4g2007.org/program_overview/thursday Thursday Schedule])
If you have a particular room you want to chair, please note it in your entry.

= Tuesday =

== 13:00 to 14:30 ==
* Gary Sherman sherman@mrcc.com
* [[User:ajolma | Ari Jolma]]
* [[User:ianturton | Ian Turton]] View Royal - GeoRSS session
* [[User:pagameba | Paul Spencer]] Oak Bay 1

== 15:00 to 16:30 ==
* [[User:jlivni | Josh Livni]] (Saanich Room - REST stuff)
= Wednesday =

== 8:30 to 10:00 ==

* [[User:pagameba | Paul Spencer]] Lecture Theatre

== 10:30 to 12:00 ==
* [[User:Tbadard | Thierry Badard]] (Oak Bay 1)
* [[User:pagameba | Paul Spencer]] Lecture Theatre

== 13:00 to 14:30 ==

* Frank Warmerdam (Saanich)
* Tamas Szekeres (Lecture Theatre)

== 15:00 to 16:30 ==
* [[User:Greenwood | Richard Greenwood]] (Saanich)

= Thursday =

== 8:30 to 10:00 ==
* [[User:Tbadard | Thierry Badard]] (View Royal)
* [[User:mpg | Michael P. Gerlek]] (Lecture Theatre)

== 10:30 to 12:00 ==

* [[User:JoWalsh|Jo Walsh]] (Saanich)
* Frank Warmerdam (Lecture Theater)

= "On call" =
* [[User:mpg | Michael P. Gerlek]]
* [[User:venka | Venkatesh Raghavan]]

[[Category:FOSS4G]]
[[Category:FOSS4G2007]]

FOSS4G2007 Session Chairs

2007-08-20T02:20:22Z

Wiki-Pagameba: /* 8:30 to 10:00 */

'''Back to [[FOSS4G2007]] ...'''

Session chairs serve as the "master of ceremonies" for one 90 minute session of presentations. Each session has three 25 minute presentations, with a 5 minute question-and-answer period after each. Chairs are expected to:
* introduce the speakers,
* ensure each speaker stays within his or her 30 minute combined presentations-plus-questions presentation limit,
* ensure the next presentation starts promptly as scheduled, and
* occasionally read off a few reminders and announcements at the end of the session.

Please add your name and email to one or more of the time slots below.

'''We need 5 session chairs for each time slot.'''

Check to ensure you are not presenting or teaching a lab during the session timeslot you are volunteering for.
([http://www.foss4g2007.org/program_overview/tuesday Tuesday Schedule,]
[http://www.foss4g2007.org/program_overview/wednesday Wednesday Schedule,]
[http://www.foss4g2007.org/program_overview/thursday Thursday Schedule])
If you have a particular room you want to chair, please note it in your entry.

= Tuesday =

== 13:00 to 14:30 ==
* Gary Sherman sherman@mrcc.com
* [[User:ajolma | Ari Jolma]]
* [[User:ianturton | Ian Turton]] View Royal - GeoRSS session
* [[User:pagameba | Paul Spencer]] Oak Bay 1

== 15:00 to 16:30 ==
* [[User:jlivni | Josh Livni]] (Saanich Room - REST stuff)
= Wednesday =

== 8:30 to 10:00 ==

* [[User:pagameba | Paul Spencer]] Lecture Theatre

== 10:30 to 12:00 ==
* [[User:Tbadard | Thierry Badard]] (Oak Bay 1)

== 13:00 to 14:30 ==

* Frank Warmerdam (Saanich)
* Tamas Szekeres (Lecture Theatre)

== 15:00 to 16:30 ==
* [[User:Greenwood | Richard Greenwood]] (Saanich)

= Thursday =

== 8:30 to 10:00 ==
* [[User:Tbadard | Thierry Badard]] (View Royal)
* [[User:mpg | Michael P. Gerlek]] (Lecture Theatre)

== 10:30 to 12:00 ==

* [[User:JoWalsh|Jo Walsh]] (Saanich)
* Frank Warmerdam (Lecture Theater)

= "On call" =
* [[User:mpg | Michael P. Gerlek]]
* [[User:venka | Venkatesh Raghavan]]

[[Category:FOSS4G]]
[[Category:FOSS4G2007]]

FOSS4G2007 Session Chairs

2007-08-20T02:11:42Z

Wiki-Pagameba: /* 13:00 to 14:30 */

'''Back to [[FOSS4G2007]] ...'''

Session chairs serve as the "master of ceremonies" for one 90 minute session of presentations. Each session has three 25 minute presentations, with a 5 minute question-and-answer period after each. Chairs are expected to:
* introduce the speakers,
* ensure each speaker stays within his or her 30 minute combined presentations-plus-questions presentation limit,
* ensure the next presentation starts promptly as scheduled, and
* occasionally read off a few reminders and announcements at the end of the session.

Please add your name and email to one or more of the time slots below.

'''We need 5 session chairs for each time slot.'''

Check to ensure you are not presenting or teaching a lab during the session timeslot you are volunteering for.
([http://www.foss4g2007.org/program_overview/tuesday Tuesday Schedule,]
[http://www.foss4g2007.org/program_overview/wednesday Wednesday Schedule,]
[http://www.foss4g2007.org/program_overview/thursday Thursday Schedule])
If you have a particular room you want to chair, please note it in your entry.

= Tuesday =

== 13:00 to 14:30 ==
* Gary Sherman sherman@mrcc.com
* [[User:ajolma | Ari Jolma]]
* [[User:ianturton | Ian Turton]] View Royal - GeoRSS session
* [[User:pagameba | Paul Spencer]] Oak Bay 1

== 15:00 to 16:30 ==
* [[User:jlivni | Josh Livni]] (Saanich Room - REST stuff)
= Wednesday =

== 8:30 to 10:00 ==

== 10:30 to 12:00 ==
* [[User:Tbadard | Thierry Badard]] (Oak Bay 1)

== 13:00 to 14:30 ==

* Frank Warmerdam (Saanich)
* Tamas Szekeres (Lecture Theatre)

== 15:00 to 16:30 ==
* [[User:Greenwood | Richard Greenwood]] (Saanich)

= Thursday =

== 8:30 to 10:00 ==
* [[User:Tbadard | Thierry Badard]] (View Royal)
* [[User:mpg | Michael P. Gerlek]] (Lecture Theatre)

== 10:30 to 12:00 ==

* [[User:JoWalsh|Jo Walsh]] (Saanich)
* Frank Warmerdam (Lecture Theater)

= "On call" =
* [[User:mpg | Michael P. Gerlek]]
* [[User:venka | Venkatesh Raghavan]]

[[Category:FOSS4G]]
[[Category:FOSS4G2007]]

FOSS4G2007 BOF Sessions

2007-07-26T19:24:15Z

Wiki-Pagameba:

Back to [[FOSS4G2007]]...

= Introduction =
During the [http://www.foss4g2007.org/ FOSS4G2007 conference] in Victoria, BC, Canada, there will be conference rooms available for people to hold Birds-of-a-Feather sessions.

BOF sessions are scheduled from 17:00 to 18:30, Tuesday September 25, 2007

= Conference Rooms available for BOF sessions =
'''The list of rooms will be made available by mid-August'''

= BOF organization =
You can use this page to organize your BOF session:
* create a section below for your BOF
* have people edit this page to indicate they will be attending
* once the BOF organizer(s) have a reasonable idea of how many people will be at their BOF, cut & paste one of the available rooms from the above list into your BOF's section (please choose a room with a size suitable for your group)

= BOF sessions =

[[Category:FOSS4G]]
[[Category:FOSS4G2007]]

* OpenLayers

GeoTecWorkshop2007

2007-04-24T21:16:04Z

Wiki-Pagameba: /* FUSION (1 hour, 15 minutes) */

= Abstract =
This workshop features the creation of a complete spatial data management system using only open source components. The course materials will provide an overview of the PostGIS/PostgreSQL spatial database, uDig desktop GIS application, MapGuide Open Source Web mapping platform, and the FUSION AJAX framework. Participants will have an opportunity to install the software, load demonstration data, publish cartographic maps to the Web, use the desktop application to view and edit the spatial information, and publish the live data to Google Earth, all on their own laptop.

= Spatial Data Management System =
[[Image:GeoPlatform.jpg|50%|center|Geospatial Platform]]

= Outline =
Workshop runs from: 9 a.m. to 5 p.m.
* Coffee will be supplied starting at 8:30 a.m.
* Boxed lunch from 12:30 - 1:30.
* Afternoon coffee break is from 3 - 4 p.m.

== Introduction (30 minutes) ==
* Why Open Source
* Attendee Poll (Used open source? what?)
* The Open Source Geospatial Technology Stack
* Overview of the Spatial Data Management System (talk through diagram above)

== PostGIS (1 hour, 15 minutes) ==
* Overview, Features, Architecture
* Labs
** Install Postgres/PostGIS
** Load Data Set
** Execute Spatial SQL

== uDig (1 hour, 15 minutes) ==
* Overview, Features, Architecture
* Labs
** Install uDig
** Connect to PostGIS
** View and Edit Data

== MapGuide (1 hour, 15 minutes) ==
* Overview, Features, Architecture
* Labs
** Install MapGuide
** Connect to PostGIS
** Create Layers/Maps
** View Application on the Web
** View Map in Google Earth
** Customize Application?

== FUSION (1 hour, 15 minutes) ==
* Overview, Features, Architecture
* Labs
** Install FUSION (unzip fusion.zip into www/ directory of MGOS WebServerExtensions)
** Look at simple HTML layout with Zoom In, Zoom Out, Pan, and Map (fusion/samples/mapguide/simple/index.html)
** Look at simple WebLayout document with these widgets (fusion/samples/mapguide/simple/WebLayout.xml)
** run the app, explain what is happening
** Add two new widgets, Select and Clear Selection (type in from handout)
** Add custom code to trap events related to Selection changes (type in from handout)
** run app, explain what is happening
** Dump Selection into a table (copy/paste from existing file)
** run app, explain what is happening

2007 Google SoC Application

2007-03-08T13:00:24Z

Wiki-Pagameba:

'''1. Describe your organization.'''

OSGeo is an incorporated not-for-profit organization serving as an umbrella organization for the Open Source Geospatial community in general, and 12 projects in particular.

'''2. Why is your organization applying to participate in GSoC 2007? What do you hope to gain by participating?'''

We hope to get more students involved in open source geospatial development to grow the development community, and to advance particular projects.

'''3. Did your organization participate in GSoC 2005 or 2006? If so, please summarize your involvement and the successes and failures of your student projects.'''

OSGeo was formed in early 2006 and hasn't participated in GSoC in previous years. However, Refractions Research did participate in 2006 on behalf of the GeoTools project, which is now an OSGeo project and will be participating through OSGeo. The previously participating mentors and administrator from 2006 are supporting the OSGeo 2007 effort.

'''4. If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?'''

'''5. Who will your organization administrator be? Please include Google Account information.'''

Frank Warmerdam, OSGeo President - account: fwarmerdam

'''6. What license does your project use?'''

Different OSGeo projects operate under a variety of OSI approved licenses.

* GRASS - GPL
* GeoTools - LGPL
* GDAL - MIT/X
* MapGuide - LGPL
* MapServer - MIT/X

'''7. What is the URL for your ideas page?'''

''fill in - transfer from http://wiki.osgeo.org/index.php/Google_Summer_of_Code#Project_Ideas_Lists ''

'''8. What is the main development mailing list for your organization?'''

discuss@lists.osgeo.org - see http://lists.osgeo.org/mailman/listinfo/discuss

''add discussion lists for active projects''

* GeoServer - geoserver-devel@lists.sourceforge.net ( [http://lists.sourceforge.net/lists/listinfo/geoserver-devel details] )
* GeoTools - geotools-devel@lists.sourceforge.net ( [http://lists.sourceforge.net/lists/listinfo/geotools-devel details] )
* uDig - udig-devel@lists.refractions.net ( [http://lists.refractions.net/mailman/listinfo/udig-devel details] )
* MapGuide
** mapguide-users@lists.osgeo.org ( [http://lists.osgeo.org/mailman/listinfo/mapguide-users details] )
** mapguide-internals@lists.osgeo.org ( [http://lists.osgeo.org/mailman/listinfo/mapguide-internals details] )

'''9. What is the main IRC channel for your organization?'''

#osgeo on irc.freenode.net

''list irc channels for active projects''

* irc://freenode/#geoserver
* irc://freenode/#geotools
* irc://freenode/#udig
* irc://freenode/#mapguide

'''10. Does your organization have an application template you would like to see students use? If so, please provide it now.'''

''consider''

'''11. Who will be your backup organization administrator? Please include Google Account information.'''

Landon Blake - ''add google account''

'''12. Who will your mentors be? Please include Google Account Information.'''

''to fill in''

* jody.garnett [] gmail.com - available for uDig, GeoTools, GeoServer
* hobuisu [] gmail.com - available for GDAL
* jason.birch [] gmail.com - MapGuide
* pagameba [] gmail.com - (Paul Spencer) MapGuide

'''13. What criteria did you use to select these individuals as mentors? Please be as specific as possible.'''

Mentors are selected by project steering committees based on their reputation as skilled developers, previously demonstrated ability to support new project developers, and stated willingness to devote time to the mentoring process.

'''14. What is your plan for dealing with disappearing students?'''

Leveraging Open Source software from the OSGeo stack, coupled with high-accuracy data sources, volunteers from the open source community will process the data, including student metadata, and the results will be used for the targeting instructions for high-powered space-based lasers. Results of this will be displayed on a large video wall, which will prove that the student really has disappeared, and should act as a deterrent to future student disappearances.

http://ossim.telascience.org/ossimdata/nhv/DSCF0129.JPG

'''15. What is your plan for dealing with disappearing mentors?'''

Project steering committees will appoint replacement mentors if existing mentors become unavailable or unresponsive during the project period. We considered a strategy similar to dealing with students, but we don't want to turn off potential future mentors.

'''16. What steps will you take to encourage students to interact with your project's community before, during and after the program?'''

''to fill in''

The steps taken depend on the individual projects, as example last year GeoTools project has asked for weekly attendence at IRC meetings or status email.

'''17. What will you do to ensure that your accepted students stick with the project after GSoC concludes?'''

''to fill in''

The steps taken depend on the individual projects, as example last year GeoTools project asked that students act as a "module maintainer" for their work. This roll has an expected level of support associated with it.

Open Source Training Providers

2007-01-27T17:17:33Z

Wiki-Pagameba:

This page is an informal effort to identify and collect professional training options for open source geospatial technologies. I am thinking primarily about companies offering professional training courses though other forms might also apply.

For each entry please include the name of the organization providing the training, a brief description of the technologies covered, and an external link to somewhere with more information. If an organization offers several pre-prepared courses, adding an entry for each should be fine.

* Frank Warmerdam, Canada: One day onsite "how to write a GDAL driver" course (this is a sample only!) - [http://home.gdal.org/~warmerda/consult.html]
* Redefined Horizons, USA: Customized training around OpenJUMP and related GIS software - [http://www.redefinedhorizons.com]
* DM Solutions Group, Canada: Various Training options for [http://mapserver.gis.umn.edu MapServer], [http://mapguide.osgeo.org MapGuide], [http://chameleon.maptools.org/ Chameleon], [http://ka-map.maptools.org/ ka-Map] and related [http://www.maptools.org/ MapTools.org] packages. [http://shop.dmsolutions.ca/training.html]
* Mapgears, Canada: Customized training on [http://mapserver.gis.umn.edu MapServer], [http://chameleon.maptools.org/ Chameleon], [http://ka-map.maptools.org/ ka-Map] and related [http://www.maptools.org/ MapTools.org] packages. - [http://www.mapgears.com/services_en.html English] [http://www.mapgears.com/services_fr.html Français]
* GDF Hannover, Germany: Various Training options for GRASS GIS and QGIS [http://www.gdf-hannover.de/training]
* nature-consult, Germany: GRASS and Quantum GIS training courses, workshops and talks [http://www.nature-consult.de]

MapGuide Release Process

2006-10-26T20:07:20Z

Wiki-Pagameba:

==MapGuide Release Process==

This document details the process the MapGuide PSC and development team will follow to create releases of MapGuide Open Source.

The process is intended to be a flexible tool used by the MapGuide PSC to ensure new features are regularly made available to the community through formal releases, while maintaining a reasonable level of control over when and how releases are made.

There are several core concepts to the release process:

* Versioning
* Release Types
* Release Schedule
* Release Process
* Release Manager

===Version Numbering===

MapGuide follows a traditional version numbering scheme using three numeric fields separated by periods. The three fields denote the major version number, the minor version number and the bugfix version number respectively.

Version numbers will be changed by single digit increments for each subsequent release of the same type.

Version numbers for bugfixes start at 0 for a new minor release. Version numbers for minor releases start at 0 for a new major release.

===Release Types===

There are several release types, each related to a particular part of the version numbering scheme:

* Major Release
* Minor Release
* Bug Fix Release
* Beta Release
* Release Candidate
* Final Release

====Major Release====

A major release is one that changes the major version number. The PSC can make any release a major release. There is no fixed schedule for a major release. A major release should be considered when there are major architectural changes or a substantial set of new features since the last major release.

====Minor Release====

A minor release is one that changes the minor version number for a given major release. Approximately two minor releases are made in each calendar year, ideally about 6 months apart. A minor release happens automatically and includes any new, stable features as decided by the PSC.

The PSC may advance or delay a minor release as required to accomodate development schedules. However, it is important for the PSC to consider the impact of delaying a minor release on the deployment of existing unreleased features.

====Bug Fix Release====

A bugfix release is one taht changes the bugfix version number for a given minor release. Bugfix releases can be made at any time. Generally, a bugfix release will include several minor bug fixes. However, a bugfix release can be made for a single bug fix if it is deemed necessary for security or functional reasons.

====Beta Release====

A beta release precedes any major or minor release. At least one beta release will be made before a final release of a major or minor version can be made. More than one beta release can be made if warranted by feedback on the mailing list. A beta release should be considered a 'feature complete' version with potential known issues. No new features should be added to a version after the first beta release. The PSC may vote to allow additional features in a release after the beta release process has started, but any new feature must result in another beta release.

====Release Candidate====

A release candidate follows the final beta release and precedes any major or minor release. At least one release candidate will be made before a final release of a major or minor version can be made. More than one release candidate can be made if warranted by feedback on the mailing list. A release candidate should be considered 'feature complete' and free of serious, known issues. Minor known issues may exist in a release candidate, but should be documented in the release notes.

Under no circumstances will new features be admitted to a version following a release candidate.

====Final Release====

A final release is approved by the PSC following a release candidate if no significant problems are uncovered.

===Release Schedule===

The MapGuide PSC is responsible for determining the MapGuide release schedule in the (link) MapGuide Road Map. As noted, a minor release will occur approximately twice in a calendar year.

A first beta release will be made approximately 2 months prior to the expected final release date. If required, a second beta will be released 2-3 weeks following the first beta. If additional beta releases are required, they are released as necessary and will delay the final release.

A first release candidate will be made approximate 2 weeks following the final beta release. If required, a second beta will be released 2-3 weeks following the first release candidate. If additional release candidates are required, they are released as necessary and will delay the final release.

The final release can be made 2-3 weeks following the final release candidate.

=== Release Process ===

The MapGuide PSC will determine the approximate date of the next release during regularly scheduled IRC meetings.

Approximately 2 months before a scheduled release, a Release Manager will be appointed and an initial release plan will be formed.

After the first release candidate has been cut, work will start to document the new features in the release (since no new features can be added) for the release notes and web site updates.

===Release Manager===

The release manager is responsible to the PSC for ensuring that the various stages of the release happen on schedule, including:

* preparation of binary builds and source code packages
* documentation updates
* preparing the release notes

Note that the release manager does not necessarily do these things, these roles may be filled by others. The release manager makes sure that they actually happen.

The release manager reports to the PSC at regular intervals to provide assurance that the release is proceeding normally. The release manager will make recommendations to the PSC as required to adjust the release schedule and to accomodate new features during the beta phase.

MapGuide Release Process

2006-10-26T19:57:24Z

Wiki-Pagameba:

MapGuide PSC Historic Meetings

2006-10-26T17:39:41Z

Wiki-Pagameba: /* PSC Tasks */

== Documents ==

* MapGuide Project Steering Committee: https://mapguide.osgeo.org/psc.html

== Bootstrap Meetings ==
* [[MapGuide PSC Meeting 10-19-2006]]
* [[MapGuide PSC Meeting 10-26-2006]]

== PSC Tasks ==
* Define Initial Roadmap
* Contributor Agreement
* [[MapGuide RFC Template|Create RFC Template]]

MapGuide PSC Historic Meetings

2006-10-26T17:39:28Z

Wiki-Pagameba:

MapGuide PSC Meeting 10-26-2006

2006-10-26T13:24:04Z

Wiki-Pagameba: /* Agenda */

== Meeting Info ==

The second meeting of the MapGuide PSC will take place Thursday October 26 at 17:00 UTC (1:00 PM EST / 11:00 AM MST / 10:00 AM PST).

Meeting Chair: Bob Bray
Universal Time: http://www.timeanddate.com/worldclock/fixedtime.html?month=10&day=26&year=2006&hour=17&min=0&sec=0&p1=0
Location: The meeting will be held on IRC at [irc://irc.freenode.net/mapguide #mapguide]

== Agenda ==
* PSC Nominations
* RFC Template Discussion
* Road Map/Release Schedule Discussion (PS)

MapGuide PSC Meeting 10-26-2006

2006-10-26T13:22:32Z

Wiki-Pagameba: /* Agenda */

Choosing a Web Mapping Platform

2006-09-22T01:42:49Z

Wiki-Pagameba: /* Choosing a Web Mapping Platform for your Application */

== Choosing a Web Mapping Platform for your Application ==

There are a great many web mapping platforms available to someone starting a new project. If you are new to this world ... or perhaps have a different type of project that won't work with the platform that you are familiar with, this page should help you decide which platform is right for your project.

A web mapping platform is a toolkit that helps you build a web mapping application. It may or may not depend on a particular server technology (like MapServer or MapGuide).

Note that many of the platforms discussed below are very similar in most respects. There is a move afoot to consolidate some of the core components of these platforms into a single shared library ... which will further blur the distinctions.

The major web mapping platforms are (each needs to be linked to a separate page that describes the project in more detail, esp the benefits to a potential user):

* MapBuilder
* MapBender
* Chameleon
* MapGuide
* OpenLayers
* ka-Map

I categorize these clients into two separate categories, each with two sub-categories ... this helps me sort out which platforms most closely match the type of application I am trying to build. At that point, I would go through the specific features of the contenders to figure out which one to actually use.

The two main categories are:

* How templates are implemented
* How maps are generated

=== Templates ===

In a web mapping platform, a template is simply the HTML that gets sent to the browser. All the web mapping platforms fall into one or both of the following sub-categories.

* Managed template. A managed template is one that the toolkit manages for you. The actual HTML is typically hidden from the application designer, and some sort of GUI interface is provided for setting up the look and feel of the application
* Unmanaged template. An unmanaged template is one that the toolkit uses, but doesn't manage for you. The actual HTML is hand-crafted by the application designer.

=== Maps ===

In a web mapping platform, maps seem to be used in two different ways (this is arguable for sure). The first is client-side. The second is server-side.

* Client Side. This type of platform uses pure OGC web services and manages the map and layer state entirely in the client.
* Server Side. This type of platform uses a server (MapServer or MapGuide) to generate the map, and relies primarily on the server's API to do so.

Undoubtedly, most platforms can do both. However, in my experience, each platform falls more into one of these categories due to its original architecture.

=== Where the projects ===

<pre>
managed | unmanaged
|
mapbender | mapbuilder
client | OpenLayers (2)
|
-----------
-----------------| WebMap.js |------------
-----------
|
| chameleon
server mapguide | ka-map (1)
|
|
</pre>

(1) ka-Map is actually a client side app and can do client-side direct from WMS but its not the primary mechanism and the default install requires a server side component.

(2) OpenLayers can do server-side from ka-Map, but its not the primary mechanism

Choosing a Web Mapping Platform

2006-09-22T01:42:05Z

Wiki-Pagameba:

== Choosing a Web Mapping Platform for your Application ==

There are a great many web mapping platforms available to someone starting a new project. If you are new to this world ... or perhaps have a different type of project that won't work with the platform that you are familiar with, this page should help you decide which platform is right for your project.

A web mapping platform is a toolkit that helps you build a web mapping application. It may or may not depend on a particular server technology (like MapServer or MapGuide).

Note that many of the platforms discussed below are very similar in most respects. There is a move afoot to consolidate some of the core components of these platforms into a single shared library ... which will further blur the distinctions.

The major web mapping platforms are (each needs to be linked to a separate page that describes the project in more detail, esp the benefits to a potential user):

* MapBuilder
* MapBender
* Chameleon
* MapGuide
* OpenLayers
* ka-Map

I categorize these clients into two separate categories, each with two sub-categories ... this helps me sort out which platforms most closely match the type of application I am trying to build. At that point, I would go through the specific features of the contenders to figure out which one to actually use.

The two main categories are:

* How templates are implemented
* How maps are generated

=== Templates ===

In a web mapping platform, a template is simply the HTML that gets sent to the browser. All the web mapping platforms fall into one or both of the following sub-categories.

* Managed template. A managed template is one that the toolkit manages for you. The actual HTML is typically hidden from the application designer, and some sort of GUI interface is provided for setting up the look and feel of the application
* Unmanaged template. An unmanaged template is one that the toolkit uses, but doesn't manage for you. The actual HTML is hand-crafted by the application designer.

=== Maps ===

In a web mapping platform, maps seem to be used in two different ways (this is arguable for sure). The first is client-side. The second is server-side.

* Client Side. This type of platform uses pure OGC web services and manages the map and layer state entirely in the client.
* Server Side. This type of platform uses a server (MapServer or MapGuide) to generate the map, and relies primarily on the server's API to do so.

Undoubtedly, most platforms can do both. However, in my experience, each platform falls more into one of these categories due to its original architecture.

=== Where the projects ===

<pre>
managed | unmanaged
|
mapbender | mapbuilder
client | OpenLayers (2)
|
-----------
-----------------| WebMap.js |------------
-----------
|
| chameleon
server mapguide | ka-map (1)
|
|
</pre>

(1) ka-Map is actually a client side app and can do client-side direct from WMS but its not the primary mechanism and the default install requires a server side component.
(2) OpenLayers can do server-side from ka-Map, but its not the primary mechanism

Main Page

2006-09-22T01:16:11Z

Wiki-Pagameba: /* Software Related */

== Introduction to the Open Source Geospatial Foundation Wiki ==
This is the community Wiki of the Open Source Geospatial Foundation. Please refer to [http://www.osgeo.org/ the official web site] for official documents and policies. This Wiki is the place where documents such as committee notes, discussion on software projects, and proposals can be created collaboratively.

See [[Getting Started]] for how to dive in and get involved. We have [[Local Chapters]], which work regionally and in other languages. We also have many active [[Mailing Lists]] for discussions. Take a moment to visit our [[Library]]. We have a list of email [[Contacts]] for various projects and functions.

The OSGeo has an [https://www.osgeo.org/content/foundation/about.html official structure] but the movement is much larger. You are free to join us and add yourself to the [[All Members]] page.

== Committees ==
The committees are part of the official structure of OSGeo. Committees meet on the IRC or use conference calls. [http://logs.qgis.org/osgeo/ IRC logs] of previous meetings are often available. For a list of scheduled or regularly scheduled meetings of many of the committees check the [[Foundation Calendar]].

From the committees' pages you will find the missions, names of the people involved, and links to the working documents.

Although committees are official and there is an official list of members please feel free to participate!

* [[Board of Directors]] (official) - [[Board tasks]]
* [[Website Committee]] (official) - [[WebComTODO|Current WebCom tasks]]
* [[Fundraising]] Committee (official)
* [[IncCom Wiki|Incubation Committee]] (official)
* [[Promotion and Visibility Committee]] (official)
* [[Public Geospatial Data Committee]] (official; maybe needs a catchier name)
* [[Education and Curriculum Committee]] (official)
* [[SAC|System Administration Committee (SAC)]] (official)
* [[Certification Committee]] (not official) - ''initial ideas stage!''
* [[Conference Committee]] (not official), [[Foss4g2006]] Conference

== Proposals and Other Working Pages ==
This section is for new proposals which need publicity, or are not yet assigned to any committee or need broader collaboration. Once the entry here has done its work, it should be moved to a more appropriate place.

Check out the [[Special:Recentchanges]] page also (a link in the navigation menu on the left).

=== Current Issues ===
* [[OSGeo Educational Project]]
* [[Response to RFI for US Gov GeoSpatial]]
* [[Volunteers Needed]]
* [[What's Working]]
* [[What's Not Working]]

=== General OSGeo ===
* [[OSGeo.org Project Tool FAQ]]
* [[OSGeo Description]]
* [[Press Release Process]]
* [[Press Release Template]]
* OSGeo [http://en.wikipedia.org/wiki/Open_Source_Geospatial_Foundation Wikipedia entry]
* [[Proposed Membership Rules]]
* [[Committee Guidelines]]
* [[Contacts]] - for projects, committees, etc
* [[Protocol for requesting letter of support]]

=== Networking ===
* [[Local Chapters]]
* [[NGO Project]]
* [[Like Minded Regional Organizations]]
* [[International Outreach]]

=== Software Related ===
* [[MapGuide_Open_Source]]
* [[Mobile Solutions]]
* [[Distribution Special Interest Groups]]
* [[AJAX WebMapping Project Request]]
* [[Choosing a Web Mapping Platform]]
* [[Programming Languages Project]]
* [[Cpanel Installer]]
* [[Script Repository]]

== Useful Notes ==
* [[Getting Started]] will help you to find about.
* [[How to Edit]] this Wiki.
* [[How to keep Track]] of what is going on in the Wiki.
* [[OSGEO:Protected page guidelines|Protected page guidelines]]

-----
[[OSGEO:About|Wiki Site Disclaimer]]

Official IncCom Documents

2006-06-12T19:28:00Z

Wiki-Pagameba:

This is a list of all the documents that are considered to be official IncCom documents. The intention is to get each document into its final form then take it (or the whole set) to the board for approval).

{| class="wikitable" cellspacing="1" cellpadding="4" style="background:#cccccc;" |
|+IncCom Document Status
|- style="background:#efefef;" |
! document (link)
! Editor
! Status
|- style="background:#ffffff;" |
| [[General Principles of Incubation]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubator Application Questionnaire]]
|
| pending review
|- style="background:#ffffff;" |
| [[Project Evaluation Criteria]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubation Mentor Guidelines]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubation Process]]
|
| pending review
|- style="background:#ffffff;" |
| [[Code Provenance Review Process]]
|
| pending review
|- style="background:#ffffff;" |
| [[Project Status Template]]
|
| pending review
|}

Official IncCom Documents

2006-06-12T19:23:00Z

Wiki-Pagameba:

This is a list of all the documents that are considered to be official IncCom documents. The intention is to get each document into its final form then take it (or the whole set) to the board for approval).

{| class="wikitable" cellspacing="1" cellpadding="4" style="background:#cccccc;" |
|+IncCom Document Status
|- style="background:#efefef;" |
! document (link)
! Editor
! Status
|- style="background:#ffffff;" |
| [[General Principles of Incubation]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubation Process]]
|
| pending review
|- style="background:#ffffff;" |
| [[Code Provenance Review Process]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubator Application Questionnaire]]
|
| pending review
|- style="background:#ffffff;" |
| [[Project Evaluation Criteria]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubation Mentor Guidelines]]
|
| pending review
|- style="background:#ffffff;" |
| [[Project Status Template]]
|
| pending review
|}

Project Evaluation Criteria

2006-06-12T19:21:12Z

Wiki-Pagameba:

Project Evaluation Criteria

2006-06-12T19:20:18Z

Wiki-Pagameba: /* Desirable */

= Document Status =

'''IncCom Document Number''': X

'''Version''': 1.0

'''Status''': draft

= Purpose =

The purpose of this document is to outline the criteria to be used for prioritizing projects for acceptance into the incubation process. The project must fully meet, or be capable of meeting by graduation, the Required Criteria. Projects should meet some or all of the Desirable Criteria. The intention is that the more criteria a project meets, the more likely it will be accepted for incubation.

= Terms and Definitions =

; term : definition

= Criteria =

== Required ==

# the code is under an OSI approved license (data & doc projects need to specify their choice for a type of license).
# the project is willing to keep code clear of encumbrances
# the project is "geospatial", or directly in support of geospatial applications.

== Desirable ==

The following are desirable traits of projects entering into the community:

# Open source software is already reasonably mature (working quality code).
# Project already has a substantial user community.
# Project already has a substantial and diverse developer community.
# Project members are aware of, and implements support for, relevant standards (ie. OGC, etc).
# Project has linkages with existing foundation projects.
# Project fills a gap related to software that the foundation supports.
# Project is prepared to develop in an open and collaborative fashion.
# Project has contributions and interest from more than just one company/organization.
# Project is willing to migrate some or all of its infrastructure (code repository, web site, wiki, mailing list, etc) to foundation support infrastructure, and to adopt a website style consistent with the foundation.

== New Project Proposals To Be Considered By The Incubation Committee ==

Not all projects are mature. It is understood that it takes time for a project to be created and become viable, but that a community like OSGeo.org and its hosting software would benefit the project. However, the foundation and the community want to make sure that the project is well conceived, properly supported, and worthy of the foundation's resources, and volunteer's time. The following should also be desirable when presenting a new project:

# A detailed proposal of what is to be built and why it applies to the OSGeo foundation.
# The person making the proposal is fully capable of developing the software or has a team that is capable of producing the software.
# The project proposal includes a scope of work that defines what is to be built. The scope should include requirements and at least minimal design elements so that reviewers understand what is to be built.
# Mockups (if applicable) and/or prototypes of the software to be built (desirable, but not necessary).
# A list of other software that members of the team have worked on.

= Related Documents =

* documents

Project Evaluation Criteria

2006-06-12T19:15:12Z

Wiki-Pagameba: /* Desirable */

= Document Status =

'''IncCom Document Number''': X

'''Version''': 1.0

'''Status''': draft

= Purpose =

The purpose of this document is to outline the criteria to be used for prioritizing projects for acceptance into the incubation process. The project must fully meet, or be capable of meeting by graduation, the Required Criteria. Projects should meet some or all of the Desirable Criteria. The intention is that the more criteria a project meets, the more likely it will be accepted for incubation.

= Terms and Definitions =

; term : definition

= Criteria =

== Required ==

# the code is under an OSI approved license (data & doc projects need to specify their choice for a type of license).
# the project is willing to keep code clear of encumbrances
# the project is "geospatial", or directly in support of geospatial applications.

== Desirable ==
The following are desirable traits of projects entering into the community:

# Open source software is already reasonably mature (working quality code).
# Project already has a substantial user community.
# Project already has a substantial and diverse developer community.
# Project members are aware of, and implements support for, relevant standards (ie. OGC, etc).
# Project has linkages with existing foundation projects.
# Project fills a gap related to software that the foundation supports.
# Project is prepared to develop in an open and collaborative fashion.
# Project has contributions and interest from more than just one company/organization.
# Project is willing to migrate some or all of its infrastructure (code repository, web site, wiki, mailing list, etc) to foundation support infrastructure, and to adopt a website style consistent with the foundation.

== New Project Proposals To Be Considered By The Incubation Committee ==

Not all projects are mature. It is understood that it takes time for a project to be created and become viable, but that a community like OSGeo.org and its hosting software would benefit the project. However, the foundation and the community want to make sure that the project is well conceived, properly supported, and worthy of the foundation's resources, and volunteer's time. The following should also be desirable when presenting a new project:

# A detailed proposal of what is to be built and why it applies to the OSGeo foundation.
# The person making the proposal is fully capable of developing the software or has a team that is capable of producing the software.
# The project proposal includes a scope of work that defines what is to be built. The scope should include requirements and at least minimal design elements so that reviewers understand what is to be built.
# Mockups (if applicable) and/or prototypes of the software to be built (desirable, but not necessary).
# A list of other software that members of the team have worked on.

= Related Documents =

* documents

Project Evaluation Criteria

2006-06-12T19:14:57Z

Wiki-Pagameba: /* Required */

= Document Status =

'''IncCom Document Number''': X

'''Version''': 1.0

'''Status''': draft

= Purpose =

The purpose of this document is to outline the criteria to be used for prioritizing projects for acceptance into the incubation process. The project must fully meet, or be capable of meeting by graduation, the Required Criteria. Projects should meet some or all of the Desirable Criteria. The intention is that the more criteria a project meets, the more likely it will be accepted for incubation.

= Terms and Definitions =

; term : definition

= Criteria =

== Required ==

# the code is under an OSI approved license (data & doc projects need to specify their choice for a type of license).
# the project is willing to keep code clear of encumbrances
# the project is "geospatial", or directly in support of geospatial applications.

== Desirable ==
The following are desirable traits of projects entering into the community:

# Open source software is already reasonably mature (working quality code).
# Project already has a substantial user community.
# Project already has a substantial developer community.
# Project members are aware of, and implements support for, relevant standards (ie. OGC, etc).
# Project has linkages with existing foundation projects.
# Project fills a gap related to software that the foundation supports.
# Project is prepared to develop in an open and collaborative fashion.
# Project has contributions and interest from more than just one company/organization.
# Project is willing to migrate some or all of its infrastructure (code repository, web site, wiki, mailing list, etc) to foundation support infrastructure, and to adopt a website style consistent with the foundation.

== New Project Proposals To Be Considered By The Incubation Committee ==

Not all projects are mature. It is understood that it takes time for a project to be created and become viable, but that a community like OSGeo.org and its hosting software would benefit the project. However, the foundation and the community want to make sure that the project is well conceived, properly supported, and worthy of the foundation's resources, and volunteer's time. The following should also be desirable when presenting a new project:

# A detailed proposal of what is to be built and why it applies to the OSGeo foundation.
# The person making the proposal is fully capable of developing the software or has a team that is capable of producing the software.
# The project proposal includes a scope of work that defines what is to be built. The scope should include requirements and at least minimal design elements so that reviewers understand what is to be built.
# Mockups (if applicable) and/or prototypes of the software to be built (desirable, but not necessary).
# A list of other software that members of the team have worked on.

= Related Documents =

* documents

Incubator Application Questionnaire

2006-06-12T19:12:08Z

Wiki-Pagameba: /* Questions */

= Document Status =

'''IncCom Document Number''': X

'''Version''': 1.0

'''Status''': development

= Purpose =

The purpose of this questionnaire is to gather information about projects wishing to be hosted at OSGeo shall answer. This information is used by the IncCom to determine whether or not a project should be recommended to the Board of Directors for incubation.

Prospective projects are encouraged to provide as much detailed information as possible.

= Terms and Definitions =

; term : definition

= Questions =

# Please provide the name and email address of the principal Project Owner.
# Please provide the names and emails of co-project owners (if any).
# Please provide the names, emails and entity affiliation of all official committers
# Please describe your Project.
# Why is hosting at OSGeo good for your project?
# Type of application does this project represent(client, server, standalone, library, etc.):
# Please describe any relationships to other open source projects.
# Please describe any relationships with commercial companies or products.
# Which open source license(s) will the source code be released under?
# Is there already a beta or official release?
# What is the origin of project (commercial, experimental, thesis or other higher education, government, or some other source)?
# Does the project support open standards? Which ones and to what extent? ([http://opengeospatial.org OGC], [http://w3c.org w3c], ect.) Has the software been certified to any standard ([http://www.opengeospatial.org/resources/?page=testing&view=testSuites CITE] for example)? If not, is it the intention of the project owners to seek certification at some point?
# Is the code free of patents, trademarks, and do you control the copyright?
# How many people actively contribute (code, documentation, other?) to the project at this time?
# How many people have commit access to the source code respository?
# Approximately how many users are currently using this project?
# What type of users does your project attract (government, commercial, hobby, academic research, etc. )?
# If you do not intend to host any portion of this project using the OSGeo infrastructure, why should you be considered a member project of the OSGeo Foundation?
# Does the project include an automated build and test?
# What language(s) are used in this project? (C/Java/perl/etc)
# What is the dominant written language (i.e. English, French, Spanish, German, etc) of the developer?
# What is the (estimated) size of a full release of this project? How many users do you expect to download the project when it is released?

Incubator Application Questionnaire

2006-06-12T19:11:43Z

Wiki-Pagameba: /* Questions */

= Document Status =

'''IncCom Document Number''': X

'''Version''': 1.0

'''Status''': development

= Purpose =

The purpose of this questionnaire is to gather information about projects wishing to be hosted at OSGeo shall answer. This information is used by the IncCom to determine whether or not a project should be recommended to the Board of Directors for incubation.

Prospective projects are encouraged to provide as much detailed information as possible.

= Terms and Definitions =

; term : definition

= Questions =

# Please provide the name and email address of the principal Project Owner.
# Please provide the names and emails of co-project owners (if any).
# Please provide the names, emails and corporate affiliation of all official committers
# Please describe your Project.
# Why is hosting at OSGeo good for your project?
# Type of application does this project represent(client, server, standalone, library, etc.):
# Please describe any relationships to other open source projects.
# Please describe any relationships with commercial companies or products.
# Which open source license(s) will the source code be released under?
# Is there already a beta or official release?
# What is the origin of project (commercial, experimental, thesis or other higher education, government, or some other source)?
# Does the project support open standards? Which ones and to what extent? ([http://opengeospatial.org OGC], [http://w3c.org w3c], ect.) Has the software been certified to any standard ([http://www.opengeospatial.org/resources/?page=testing&view=testSuites CITE] for example)? If not, is it the intention of the project owners to seek certification at some point?
# Is the code free of patents, trademarks, and do you control the copyright?
# How many people actively contribute (code, documentation, other?) to the project at this time?
# How many people have commit access to the source code respository?
# Approximately how many users are currently using this project?
# What type of users does your project attract (government, commercial, hobby, academic research, etc. )?
# If you do not intend to host any portion of this project using the OSGeo infrastructure, why should you be considered a member project of the OSGeo Foundation?
# Does the project include an automated build and test?
# What language(s) are used in this project? (C/Java/perl/etc)
# What is the dominant written language (i.e. English, French, Spanish, German, etc) of the developer?
# What is the (estimated) size of a full release of this project? How many users do you expect to download the project when it is released?

Official IncCom Documents

2006-06-12T19:06:28Z

Wiki-Pagameba:

This is a list of all the documents that are considered to be official IncCom documents. The intention is to get each document into its final form then take it (or the whole set) to the board for approval).

{| class="wikitable" cellspacing="1" cellpadding="4" style="background:#cccccc;" |
|+IncCom Document Status
|- style="background:#efefef;" |
! document (link)
! Editor
! Status
|- style="background:#ffffff;" |
| [[General Principles of Incubation]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubation Process]]
|
| pending review
|- style="background:#ffffff;" |
| [[Code Provenance Review Process]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubator Application Questionnaire]]
|
| pending review
|- style="background:#ffffff;" |
| [[Project Evaluation Criteria]]
|
| pending review
|- style="background:#ffffff;" |
| [[Project Graduation Checklist]]
|
| pending review
|- style="background:#ffffff;" |
| [[Incubation Mentor Guidelines]]
|
| pending review
|- style="background:#ffffff;" |
| [[Project Status Template]]
|
| pending review
|}

Project Graduation Process

2006-06-12T19:05:11Z

Wiki-Pagameba: /* Document Status */

= Document Status =

'''IncCom Document Number''': 3

'''Version''': 1.0

'''Status''': draft

= Purpose =

The purpose of the Project Graduation Process is to document how projects can graduate from the Incubator to full member status in OSGeo.

= Terms and Definitions =

; Project : the project wishing to enter into OSGeo
; IncCom : the Incubation Committee
; Incubation Process : the process by which a project becomes a full member project of OSGeo
; Mentor : a member of the Incubation Committee chosen to assist a Project through the Incubation Process
; PMC : Project Management Committee

= Process =

# Incubation Mentor determines that the project is ready for graduation based on its current status
# Incubation Mentor includes an agenda item in the next available IncCom meeting to propose graduation for the Project
# The IncCom reviews the [[Project Status Template]] of the project and votes (link to voting process for IncCom) on whether the project is ready for graduation. For a project to graduation, there must be
## a quorum of voters
## X +1 votes
## no -1 votes
# If graduation is approved by the IncCom, the IncCom will:
## include an agenda item on the next available Board of Directors meeting to accept the project graduation
## notify the project of the Board of Directors decision

= Related Documents =

* [[Project Graduation Checklist]]
* [[Project Status Template]]

Code Provenance Review Process

2006-06-12T18:55:27Z

Wiki-Pagameba: /* Purpose */

= Document Status =

'''IncCom Document Number''': 2

'''Version''': 1.0

'''Status''': draft

= Purpose =

The purpose of Code Provenance Review is to establish a reasonable comfort level that an Incubation Project does not have improperly contributed code, and that the code is all under the Project license.

A code provenance review is desirable because it reduces the risk to the foundation, to the project developers and to the software users becoming involved in a legal action or having their use of the software disrupted by sudden removal of improperly contributed code. In particular, many enterprises will not build on open source software projects without some degree of assurance that care is being taken to avoid improper contributions.

It is not the goal to be able to prove that every source file, and every contribution to those files, was contributed properly. The onus is not on the IncCom to prove there are no problems. However, IncCom does need to ensure that OSGeo does not officially endorse code with provenance issues that could have identified and corrected with a reasonable effort.

= Terms and Definitions =

; IncCom : the Incubation Committee
; Incubation Project : a project that has been accepted for incubation and that has not yet graduated.
; Project License : an approved OSI license under which the project is released to the public domain
; Provenance Review Document : a completed copy of [[Provenance Review Template]] specific to a single Incubation Project

= Process =

The Code Provenance Review is separated into two sections, each with a slightly different process.

# create a Provenance Review Document by copying the [[Provenance Review Template]]
# complete the Library/Component Review Process
# complete the Code Copyright Review
# submit the completed Provenance Review Document to the Project Mentor for review

== Library/Component Review Process ==

For the overall project, document potential Library/Component issues by:

# listing any external components that are included "in the source tree" for the project. For instance, GDAL includes a copy of libtiff, libjpeg, etc in the source tree. It is necessary to be able to identify things like that in the source tree that are under their own distinct license, and are not explicitly vetted by the project team. If practical, it is desirable to remove these internal components and treat them as external dependencies. If kept internal, notes on the licenses of the components should be documented using the [[Provenance Review Template]].
# listing all external dependencies with:
## potentially problematic license terms (all non-free libraries, for instance).
## all libraries with licenses that might conflict (for instance GDAL's use of GPL'ed GRASS libraries in the non-GPL GDAL).

== Code Copyright Review ==

For each project source file, perform the following:

# Does the file include the license information? If not, add it if there there is no ambiguity about whether the standard project license applies. If that is not obvious, make notes in the review document.
# Is the file under the normal project license? If not, make notes in the review document.
# Is there anything obviously unusual about the origin of the code? Does this pose any conflicts? Is the issue properly described in the source file? For instance, in GDAL, the gdal/port/cpl_strtod.cpp file is closely derived from external code that was placed in the public domain. cpl_strtod.cpp is placed under the normal GDAL MIT/X license, but detailed notes are kept in the header text on it's origin, the fact that this was public domain and so the fact that it is ok to relicense it. Oddities should be noted in the source file itself and in the review document.
# Maintain a list of all copyright holders identified in the Provenance Review Document. This list is essentially everyone who would need to agree to relicense the project. It may be desirable to seek copyright assignment to a "project lead", or to the foundation to reduce the number of copyright holders for the project, although this is not required.

= Frequently Asked Questions =

; Do we need to ensure there is a copyright and licence headers in every file?
: Projects are expected to embed a copyright and license header in every source file (.cpp and .h for instance). Machine generated files (such as lex or yacc output for instance) does not require a header if it is inconvenient to embed one, but then an effort should be made to embed a header in the original source file (ie. .l or .y). There is no need to embed copyright and license headers in build files (ie. Makefiles, Visual Studio project files), nor in small documentation fragments (like READMEs). Copyright/license headers should be included in substantial bodies of documentation if it can be done in such a way that it doesn't interfere with the document.

; Do I really need to embed the whole license agreement in every file?
: No, it is sufficient to refer to a single copy of the license agreement for the project, but each file should include an indication of what the license is, and the location of the full license document. For example:

/*
* Copyright (C) 2004-2005 Autodesk, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of version 2.1 of the GNU Lesser
* General Public License as published by the Free Software Foundation.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/

: or

* COPYRIGHT: (C) 2001 by the GRASS Development Team
*
* This program is free software under the GNU General Public
* License (>=v2). Read the file COPYING that comes with GRASS
* for details.

; Can I just write a script to check everything?
: No. The point of a human review is to ensure that human eyes have looked at the header of each file, looking for any anomolies. For instance it is not uncommon to have additional messages written in headers about the original source of particular code, but not necessarily in a way that a script could recognise.

; But I just did a review similar to this a few months ago, do I really need to do it again?
: If you believe you have already met or exceeded the rigor described in this review document, then you can present the results of your previous analysis along with an explanation of why you think it still applies. You will need to manually review additions since that earlier review. It will be up to the Incubator (and ultimately the foundation board) to determine if they are satisfied with any review.

; Do I need to track down every contributor and ask for permission to use their code?
: No. As long as code was knowingly provided by contributors to the project while it was under a clear licensing policy then it is reasonable to assume the project licensing arrangements are accepted unless there is some reason to have doubts. If code was brought into the project from outside sources under ambiguous circumstances then it may be necessary to contact the copyright holder for a legal release, or at least a statement of permission.

; Some project code was adapted from other sources with ambiguous copyrights, what do I do?
: First, document such concerns in the review document and within the source files themselves. Second, try to obtain a release to use the provide code. An email statement of permission should be sufficient, but pertinant details of such an email should be included in the source file in questions (eg. date, identification of releasing person, text of the release). If no release is possible, but the code isn't very necessary, consider removing or replacing it to simplify things. Otherwise the issue will need to be discussed in the incubator to assess risk.

; Should I be looking for patent problems?
: No. However, if the code review turns up notes about patent issues - or if there are known patent issues for the project, then these should be noted in the review document. Generally speaking a proper patent review is very difficult and may increase, rather than decrease, legal liability.

; Should I be looking for tracemark conflicts?
: Possibly. It may be prudent to check for trademark conflicts for the project name, or the name of public packages within the project. If issues are found they should be noted in the review document.

= Related Documents =

* [[Provenance Review Template]]

Code Provenance Review Process

2006-06-12T18:52:31Z

Wiki-Pagameba: /* Document Status */

= Document Status =

'''IncCom Document Number''': 2

'''Version''': 1.0

'''Status''': draft

= Purpose =

The purpose of Code Provenance Review is to establish a reasonable comfort level that an Incubation Project does not have improperly contributed code, and that the code is all under the Project license.

A code provenance review is desirable because it reduces the risk of the foundation, project developers or software users becoming involved in a legal action or having their use of the software disrupted by sudden removal of improperly contributed code. In particular, many enterprises will not build on open source software projects without some degree of assurance that care is being taken to avoid improper contributions.

It is not the goal to be able to prove that every source file, and every contribution to those files, was contributed properly. The onus is not on the IncCom to prove there are no problems. However, IncCom does need to ensure that OSGeo does not officially endorse code with provenance issues that could have identified and corrected with a reasonable effort.

= Terms and Definitions =

; IncCom : the Incubation Committee
; Incubation Project : a project that has been accepted for incubation and that has not yet graduated.
; Project License : an approved OSI license under which the project is released to the public domain
; Provenance Review Document : a completed copy of [[Provenance Review Template]] specific to a single Incubation Project

= Process =

The Code Provenance Review is separated into two sections, each with a slightly different process.

# create a Provenance Review Document by copying the [[Provenance Review Template]]
# complete the Library/Component Review Process
# complete the Code Copyright Review
# submit the completed Provenance Review Document to the Project Mentor for review

== Library/Component Review Process ==

For the overall project, document potential Library/Component issues by:

# listing any external components that are included "in the source tree" for the project. For instance, GDAL includes a copy of libtiff, libjpeg, etc in the source tree. It is necessary to be able to identify things like that in the source tree that are under their own distinct license, and are not explicitly vetted by the project team. If practical, it is desirable to remove these internal components and treat them as external dependencies. If kept internal, notes on the licenses of the components should be documented using the [[Provenance Review Template]].
# listing all external dependencies with:
## potentially problematic license terms (all non-free libraries, for instance).
## all libraries with licenses that might conflict (for instance GDAL's use of GPL'ed GRASS libraries in the non-GPL GDAL).

== Code Copyright Review ==

For each project source file, perform the following:

# Does the file include the license information? If not, add it if there there is no ambiguity about whether the standard project license applies. If that is not obvious, make notes in the review document.
# Is the file under the normal project license? If not, make notes in the review document.
# Is there anything obviously unusual about the origin of the code? Does this pose any conflicts? Is the issue properly described in the source file? For instance, in GDAL, the gdal/port/cpl_strtod.cpp file is closely derived from external code that was placed in the public domain. cpl_strtod.cpp is placed under the normal GDAL MIT/X license, but detailed notes are kept in the header text on it's origin, the fact that this was public domain and so the fact that it is ok to relicense it. Oddities should be noted in the source file itself and in the review document.
# Maintain a list of all copyright holders identified in the Provenance Review Document. This list is essentially everyone who would need to agree to relicense the project. It may be desirable to seek copyright assignment to a "project lead", or to the foundation to reduce the number of copyright holders for the project, although this is not required.

= Frequently Asked Questions =

; Do we need to ensure there is a copyright and licence headers in every file?
: Projects are expected to embed a copyright and license header in every source file (.cpp and .h for instance). Machine generated files (such as lex or yacc output for instance) does not require a header if it is inconvenient to embed one, but then an effort should be made to embed a header in the original source file (ie. .l or .y). There is no need to embed copyright and license headers in build files (ie. Makefiles, Visual Studio project files), nor in small documentation fragments (like READMEs). Copyright/license headers should be included in substantial bodies of documentation if it can be done in such a way that it doesn't interfere with the document.

; Do I really need to embed the whole license agreement in every file?
: No, it is sufficient to refer to a single copy of the license agreement for the project, but each file should include an indication of what the license is, and the location of the full license document. For example:

/*
* Copyright (C) 2004-2005 Autodesk, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of version 2.1 of the GNU Lesser
* General Public License as published by the Free Software Foundation.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library; if not, write to the Free Software
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/

: or

* COPYRIGHT: (C) 2001 by the GRASS Development Team
*
* This program is free software under the GNU General Public
* License (>=v2). Read the file COPYING that comes with GRASS
* for details.

; Can I just write a script to check everything?
: No. The point of a human review is to ensure that human eyes have looked at the header of each file, looking for any anomolies. For instance it is not uncommon to have additional messages written in headers about the original source of particular code, but not necessarily in a way that a script could recognise.

; But I just did a review similar to this a few months ago, do I really need to do it again?
: If you believe you have already met or exceeded the rigor described in this review document, then you can present the results of your previous analysis along with an explanation of why you think it still applies. You will need to manually review additions since that earlier review. It will be up to the Incubator (and ultimately the foundation board) to determine if they are satisfied with any review.

; Do I need to track down every contributor and ask for permission to use their code?
: No. As long as code was knowingly provided by contributors to the project while it was under a clear licensing policy then it is reasonable to assume the project licensing arrangements are accepted unless there is some reason to have doubts. If code was brought into the project from outside sources under ambiguous circumstances then it may be necessary to contact the copyright holder for a legal release, or at least a statement of permission.

; Some project code was adapted from other sources with ambiguous copyrights, what do I do?
: First, document such concerns in the review document and within the source files themselves. Second, try to obtain a release to use the provide code. An email statement of permission should be sufficient, but pertinant details of such an email should be included in the source file in questions (eg. date, identification of releasing person, text of the release). If no release is possible, but the code isn't very necessary, consider removing or replacing it to simplify things. Otherwise the issue will need to be discussed in the incubator to assess risk.

; Should I be looking for patent problems?
: No. However, if the code review turns up notes about patent issues - or if there are known patent issues for the project, then these should be noted in the review document. Generally speaking a proper patent review is very difficult and may increase, rather than decrease, legal liability.

; Should I be looking for tracemark conflicts?
: Possibly. It may be prudent to check for trademark conflicts for the project name, or the name of public packages within the project. If issues are found they should be noted in the review document.

= Related Documents =

* [[Provenance Review Template]]

Incubation Process

2006-06-12T18:51:53Z

Wiki-Pagameba: /* Related Documents */

= Document Status =

'''IncCom Document Number''': 1

'''Version''': 1.0

'''Status''': draft

= Purpose =

The purpose of this document is to describe the incubation process from entrance to exit.

= Terms and Definitions =

; Project : The project wishing to enter into OSGeo
; IncCom : The Incubation Committee
; Incubation Process : The process by which a project becomes a full member project of OSGeo
; Mentor : A member of the Incubation Committee chosen to assist a Project through the Incubation Process
; PMC : Project Management Committee

= Process =

# The Project completes the [[Incubator Application Questionnaire]] and sends it to <official incubation email here>
# The IncCom reviews pending Incubation Applications at the next regularly scheduled IncCom. Each Incubation Application is evaluated based on the [[Project Evaluation Criteria]].
# For Projects that meet the [[Project Evaluation Criteria]], an Incubation Mentor is chosen. Incubation Mentors are selected based on willingness to act as a Mentor for a particular Project. If no Mentor is chosen, the Project is placed on hold until a Mentor can be found. It is acceptable (and desireable) for a Project to recruit a Mentor for itself as part of the Project Submission Process.
# The chairman of the IncCom presents projects selected for Incubation to the OSGeo Board of Directors for acceptance or deferral.
# The Incubation Mentor reports incubation progress to the IncCom periodically using the [[Project Status Template]].
# Incubation Projects remain in incubation until the Incubation Mentor and the IncCom agree the project is ready for full status based on the [[Project Graduation Checklist]].
# The Chairman of the IncCom presents projects ready for graduation at the next regularly scheduled meeting of the OSGeo Board of Directors. The OSGeo Board of Directors accepts or rejects a Project's graudation from the Incubator.
# Upon graduation, a member of the project's PMC is selected to report to the foundation board periodically on project status.

= Related Documents =

* [[Incubator Application Questionnaire]]
* [[Project Evaluation Criteria]]
* [[Project Status Template]]
* [[Project Graduation Checklist]]

Incubation Process

2006-06-12T18:50:01Z

Wiki-Pagameba: /* Purpose */

Incubation Process

2006-06-12T18:47:32Z

Wiki-Pagameba: /* Document Status */

= Document Status =

'''IncCom Document Number''': 1

'''Version''': 1.0

'''Status''': draft

= Purpose =

The purpose of the Project Submission Process is to ensure that the procedure for getting new projects into the Incubation Process is well defined. This process is to be used for all new projects wishing to enter into OSGeo.

The process should be followed as is for most projects. The steps have been selected to best serve your project and to integrate it into the foundation. These steps have been chosen with great deliberation and evaluated as we run new projects through the process. Should your project find parts of this process either impossible or do not apply to your project, please inform the incubation committee and request removal or modification of parts of the process according to your needs.

= Terms and Definitions =

; Project : The project wishing to enter into OSGeo
; IncCom : The Incubation Committee
; Incubation Process : The process by which a project becomes a full member project of OSGeo
; Mentor : A member of the Incubation Committee chosen to assist a Project through the Incubation Process
; PMC : Project Management Committee

= Process =

# The Project completes the [[Incubator Application Questionnaire]] and sends it to <official incubation email here>
# The IncCom reviews pending Incubation Applications at the next regularly scheduled IncCom. Each Incubation Application is evaluated based on the [[Project Evaluation Criteria]].
# For Projects that meet the [[Project Evaluation Criteria]], an Incubation Mentor is chosen. Incubation Mentors are selected based on willingness to act as a Mentor for a particular Project. If no Mentor is chosen, the Project is placed on hold until a Mentor can be found. It is acceptable (and desireable) for a Project to recruit a Mentor for itself as part of the Project Submission Process.
# The chairman of the IncCom presents projects selected for Incubation to the OSGeo Board of Directors for acceptance or deferral.
# The Incubation Mentor reports incubation progress to the IncCom periodically using the [[Project Status Template]].
# Incubation Projects remain in incubation until the Incubation Mentor and the IncCom agree the project is ready for full status based on the [[Project Graduation Checklist]].
# The Chairman of the IncCom presents projects ready for graduation at the next regularly scheduled meeting of the OSGeo Board of Directors. The OSGeo Board of Directors accepts or rejects a Project's graudation from the Incubator.
# Upon graduation, a member of the project's PMC is selected to report to the foundation board periodically on project status.

= Related Documents =

* [[Incubator Application Questionnaire]]
* [[Project Evaluation Criteria]]
* [[Project Status Template]]
* [[Incubation Graduation Criteria]]

General Principles of Incubation

2006-06-12T18:46:27Z

Wiki-Pagameba: /* Purpose of Incubation */

== Purpose of Incubation ==

The purpose of the OSGeo incubation process is to ensure that projects that are officially part of OSGeo:

* have a successfully operating open and collaborative development community
* have clear IP oversight of the code base of the project
* adopt the OSGeo principles and operating principles
* are mentored through the incubation process

== Principles of OSGeo Projects (The OSGeo Way) ==

* Projects should manage themselves, striving for consensus and encouraging participation from all contributors - from beginning users to advanced developers.
* Contributors are the scarce resource and successful projects court and encourage them.
* Projects are encouraged to adopt open standards and collaborate with other OSGeo projects.
* Projects are responsible for reviewing and controlling their code bases to insure the integrity of the open source baselines.

== Operating Principles ==

* Projects should document how they manage themselves.
* Projects should maintain developer and user documentation.
* Projects should maintain a source code management system.
* Projects should maintain a discrepancy tracking system.
* Projects should maintain project mailing lists.
* Projects should actively promote their participation in OSGeo.
* Projects are encouraged to adopt OSGeo look and feel, branding, logos on their project sites.
* Projects are encouraged to participate in OSGeo standardization efforts to present a common interface for OSGeo visitors and members.
* Projects should have automated build and smoke test systems.

General Principles of Incubation

2006-06-12T18:27:23Z

Wiki-Pagameba:

== Purpose of Incubation ==

The purpose of the OSGeo incubation process is to ensure that projects that are officially part of OSGeo:

* have a successfully operating open and collaborative development community
* have clear IP oversight of the code base of the project
* adhere to the OSGeo principles and operating principles

== Principles of OSGeo Projects (The OSGeo Way) ==

* Projects should manage themselves, striving for consensus and encouraging participation from all contributors - from beginning users to advanced developers.
* Contributors are the scarce resource and successful projects court and encourage them.
* Projects are encouraged to adopt open standards and collaborate with other OSGeo projects.
* Projects are responsible for reviewing and controlling their code bases to insure the integrity of the open source baselines.

== Operating Principles ==

* Projects should document how they manage themselves.
* Projects should maintain developer and user documentation.
* Projects should maintain a source code management system.
* Projects should maintain a discrepancy tracking system.
* Projects should maintain project mailing lists.
* Projects should actively promote their participation in OSGeo.
* Projects are encouraged to adopt OSGeo look and feel, branding, logos on their project sites.
* Projects are encouraged to participate in OSGeo standardization efforts to present a common interface for OSGeo visitors and members.
* Projects should have automated build and smoke test systems.

General Principles of Incubation

2006-06-12T18:26:31Z

Wiki-Pagameba:

== Purpose of Incubation ==

The purpose of the OSGeo incubation process is to ensure that projects that are officially part of OSGeo:

* have a successfully operating open and collaborative development community
* have clear IP oversight of the code base of the project
* adhere to the OSGeo principles and operating procedures

== Principles of OSGeo Projects (The OSGeo Way) ==

* Projects should manage themselves, striving for consensus and encouraging participation from all contributors - from beginning users to advanced developers.
* Contributors are the scarce resource and successful projects court and encourage them.
* Projects are encouraged to adopt open standards and collaborate with other OSGeo projects.
* Projects are responsible for reviewing and controlling their code bases to insure the integrity of the open source baselines.

== Operating Procedures ==

* Projects should document how they manage themselves.
* Projects should maintain developer and user documentation.
* Projects should maintain a source code management system.
* Projects should maintain a discrepancy tracking system.
* Projects should maintain project mailing lists.
* Projects should actively promote their participation in OSGeo.
* Projects are encouraged to adopt OSGeo look and feel, branding, logos on their project sites.
* Projects are encouraged to participate in OSGeo standardization efforts to present a common interface for OSGeo visitors and members.
* Projects should have automated build and smoke test systems.

[https://incubator.osgeo.org/servlets/ReadMsg?listName=incubator&msgNo=224 Mark Lucas' thoughts on incubation]

General Principles of Incubation

2006-06-12T18:12:17Z

Wiki-Pagameba:

This document is meant to be a guide to the incubation principles of OSGeo.

* Projects should manage themselves striving for consensus and encouraging participation from all contributors - from beginning users to advanced developers.
* Projects should document how they manage themselves.
* Contributors are the scarce resource and successful projects court and encourage them.
* Projects are encouraged to adopt open standards and collaborate with other OSGeo projects.
* Projects should maintain developer and user documentation.
* Projects should maintain a source code management system - svn is preferred.
* Projects should maintain a discrepancy tracking system.
* Projects should maintain project mailing lists.
* Projects should actively promote their participation in OSGeo.
* Projects are responsible for reviewing and controlling their code bases to insure the integrity of the open source baselines.
* Projects are encouraged to adopt OSGeo look and feel, branding, logos on their project sites.
* Projects are encouraged to participate in OSGeo standardization efforts to present a common interface for OSGeo visitors and members.
* Projects should have automated build and smoke test systems
*

The OSGeo will in turn attempt to make available the best of breed
open source collaborative tools and resources to support those
efforts, if we offer better tools and resources projects will
naturally migrate to the better implementations.

I'm sure I've missed several important points, the main point being
that we lead vs control.

New projects compete for our approval with the same guidelines -
hopefully they will be included based on their perceived value to the
OSGeo overall goals and objectives.

[https://incubator.osgeo.org/servlets/ReadMsg?listName=incubator&msgNo=224 Mark Lucas' thoughts on incubation]

User:Pagameba

2006-06-05T20:03:05Z

Wiki-Pagameba:

User:Pagameba

2006-06-05T20:01:31Z

Wiki-Pagameba: