OSGeo - User contributions [en]

GeoForAll History

2009-11-02T09:56:30Z

Wiki-Giohappy: /* Membership */

== Mission ==

The mission of the education committee is to inventory, organize and coordinate the development of educational and curriculum material that supports OSGeo-related education. The intent is to provide [[Appropriately Licensed Material]] that is accessible by a broad audience including academia, professionals, and the general public. Material supported through this project should directly or indirectly build and strengthen the open source geospatial user and developer communities. This can be accomplished by integrating the use of FOSS4G tools in curricula that teach geospatial concepts and applications as well as the creating curricula to teach skills necessary for people to actively participate in FOSS4G and free geospatial data projects. The committee also seeks cooperation with academic research projects to promote the use of FOSS4G in research projects, to get FOSS4G used as a platform for research, and to present FOSS4G as a research subject.

== Education Committee related wiki pages ==

* [[Education Contributors]] - Provides a list of contributors or interested individuals. Add your name!
* [[Education committee liaisons to local chapters]] - Provides a list of people who help the education group work more closely with OSGeo local chapters.
* [[Educational Content Inventory]] - Please add information on what you'd like to contribute.
* [[Commitments for New Material Development]] - Please add information on new material that you can help develop.
* [[Education Committee Work Program]] - our current list of todos.
* [http://lists.osgeo.org/mailman/listinfo/edu_discuss Our mailing list]

== Meeting Minutes ==

* [http://logs.qgis.org/osgeo/%23osgeo.2006-09-08.log IRC chat log, Sep 9 2006]
* [[FOSS4G2006 minutes]] (Sept. 2006)
* [[EduCom Meeting 1 March 2007]]
* [[FOSS4G2007_Education_BOF_minutes]] (Sept. 2007)
* [[FOSS4G2009_Education_BOF_minutes]] (Oct. 2009) '''MOST RECENT!'''

== Membership ==
Formal members of this committee are as follows, however anyone is welcome to participate regardless of status. Please add yourself to the [[Education Contributors]] page and join the mailing to get involved.

* Puneet Kishor
* Ari Jolma
* Markus Neteler
* Venkatesh Raghavan
* Charlie Schweik (Chair)
* Pericles Nacionales
* Ned Horning (Co-chair)
* Helena Mitasova
* David Percy
* Ian Turton
* Maria Brovelli
* Giovanni Allegri

== Other Edu Group information of possible interest ==
* [[Puneet's Visit to Brazil]] (May 2007)

=== Educational Avendues ===
Bachelor's Degree in Mental Retardation
Offered by the National Institute for the Mentally Handicapped (NIMH), Manovikas Nagar, Secundarabad 500009 affiliated to Osmania University, Hyderabad. Duration of the course is 3 years and minimum eligibility is 10+2 with a minimum of 50% aggregate marks (40% for SC/ST). [http://www.topindianjobs.com/special-education-qualifications-required.shtml More..]

[[Category:Education]]
[[Category:Committees]]

Jobs Board

2008-10-15T23:15:52Z

Wiki-Giohappy:

== Introduction ==
This wiki page and associated wiki pages serve as a job board for members of the FOSS GIS Community. If you would like to post your resume or a job opportunity on this wiki, or if you have questions, please send an e-mail with the details to the [http://lists.osgeo.org/mailman/listinfo/jobs OSGeo Jobs Mailing List].

== Current Job Opportunities ==

== Resumes ==

=== FBK-MBPA (Post Date: 2008-10-16)===

I would like to know if you may be in touch with some junior scientist interested to spend 2 or more years in Trento at FBK. We have open positions at MPBA starting this Fall. In particular there are two open post-doc research positions in which international candidates would be welcomed.

All open positions are listed at
http://mpba.fbk.eu/en/node/82

I would like to point your attention to the recent job call for post-doc position recently posted at http://scjobs.sciencemag.org/jobs/default.aspx?job=28474
by the Kessler Foundation.

In particular, one senior/junior research position is being offered at my laboratory on "Computational methods for information display of scientific and socio-economic data (Ref. code FI_PMBE) (1 position)". Information about the call and the specific position are available at http://risorseumane.fbk.eu/sites/risorseumane.fbk.eu/files/Future%20internet%20call%20-%20detail%203007.pdf

We are looking for a scientist with computational skills interested in interdisciplinary research. MPBA (http://mpba.fbk.eu) has more than 10 years of research in predictive models and ICT platforms for geocoded data, with an emphasis on open source software and on ethical contribution to society. MPBA's scientific core is now within bioinformatics and molecular based epidemiology, and we aim at the connection with the environmental and socio-economic aspects on the spatio-temporal scale. We are developing methods, projects and international collaborations on both research areas. On this specific call, we expect opportunities both for international research (in collaboration with OECD Paris) and for new applications to exploit with a spin-off initiative.

We will be glad to provide further information or discuss with candidates about the research, potential for collaboration, or local logistics. In any case, please note that we expect to have a first round of selections at mid October. Applications and CV should be sent to jobs@fbk.eu with Ref.Code FI_PMBE, cc to Cesare Furlanello (furlan - AT - fbk.eu)

=== Tyler Technologies: Java Developer (Post Date: 2008-02-04)===

We are looking for a permanent hire that is extremely strong in Java/OO Design. GIS experience is highly desired, but not absolutely required. Advanced and Strong Development skills are a must. We hire developers that are very strong at all experience levels, so years in the industry is also open, based on development skills.

If you are interested, please email me offline to avoid clutter on the mailing list.

The Eagle division of Tyler Technologies is seeking Java Developer with GIS experience for permanent immediate hire. The position will be located in our Lakewood office, (Denver Metro area). Tyler has an agile fun, fast paced, stable environment, driven by our heavy growth.

'''Requirements'''

The ideal candidate will have the following characteristics:

* Exceptionally strong understanding of Object Oriented Design.

* Deep understanding and advanced skill set with an OO language.

* Experience in Java.

* Exceedingly strong knowledge of an OO language.

* Extremely strong problem solving skills.

* Abstract Problem Solver.

* Will to work hard and exhibit strong work ethic.

* Ability to learn and adapt quickly in a dynamic environment.

* Passion for Software Development.

* Self-Motivation.

Desired, but not required.

* Experience with GIS tools.

* Experience with ESRI, ideally the Java toolkit.

* Experience with GeoTools.

* Knowledge of GIS libraries and API’s.

* Understanding of how users interact with GIS.

'''Level of Experience'''

This position would ideally call for a developer with some level of experience beyond a Junior Developer, since this position will help to not only design and implement a GIS product, but also help define requirements and help lead the direction of the product. However, Junior Developers will be considered that have an extremely strong understanding of Java or another Object Oriented Language.

'''Responsibilities'''

Participate in the complete Software Development Lifecycle. This includes: Requirements Analysis, Design, Implementation, Unit Testing, Deployment Tools, and Maintenance. This position will help to lead and define the GIS product, including an integration to all eagleSoftware products. Experience with GIS, ESRI, ArcSDE, and other such technologies are a strong plus. Understanding of how users interact with GIS and their needs is also highly desired.

'''Tyler’s Java Team'''

Tyler’s Java team is comprised of a relatively small group of individuals that all share a passion for Software Development and are well above average in terms of development abilities. We are looking to add a similar person. Our interview process is very technical and requires a strong and deep understanding of Object Oriented Design and Development. If you consider yourself a strong developer and love writing software, please apply to learn more.

'''Tyler Technologies (TYL)'''

Tyler Technologies is publically traded on the New York Stock Exchange (TYL). The Eagle Division develops leading edge technology solutions for local government – document recording, document & content management, assessment and tax.

The Eagle Division of Tyler Technologies has been providing technology solutions to government offices for almost 30 years. Over 1,900 cities and 620 counties use Tyler products to run their offices efficiently and successfully.

In 2004, Forbes listed Tyler Technologies in the top 200 small companies to work for in the United States (93rd on the list). In 2007 Forbes listed Tyler Technologies as one of America’s Most Trustworthy Company (tied for 3rd on the list).

The Eagle division of Tyler has never laid anyone off in almost 30 years of being in business. The Eagle division is one of the fastest growing divisions of Tyler.

We offer competitive pay and benefits to over 1,600 employees and we have a long track record of supporting our employee’s careers and lives.

== General Advice on Mailing List Postings ==

Targetted mailing lists can be a great place to post about available jobs or resumes. But to avoid giving you or your organization a bad reputation it is important to use mailing lists in as polite a fashion as possible.

* Don't post to a mailing list that has a "no jobs, no resumes" policy. We will make some effort to keep track of these below in the "Appropriate Places to Post" but ideally you should do a bit of research on the lists you post to before posting.
* Do not post a job or resume repeatedly to the same list. If your organization has several job openings try and post them in a single post rather than sending several separate emails.
* Only post to lists very "on topic" for the job posting. For instance, don't post to the GRASS list if you don't need GRASS skills just on account you think there might be some folks there with the skills you are looking for.
* Try to minimize the total number of lists you post to. If you are posting to a job/resume to more than four or five mailing lists it is likely that many folks will get the post several times and their opinion of you will be lowered. So just select the optimal lists.
* Do not email out resumes or job postings as attachments. Send email as plain text with links to web pages for full details and nicely formatted postings/resumes.
* Prefix your subject line with "Job: " or "Resume: " so folks not interested can easily skip the email without reading into it. For instance "Resume: Frank Warmerdam" or "Job: Geoweb Developer - Washington, DC"
* If you have some absolute requirements try to make them clear early in the email so folks don't have to read far before skipping the message. If you require someone with extensive PHP skills, or who is a US citizen or who speaks French fluently make it clear up front.
* Most mailing lists require you to be subscribed to the list in order to accept posts from you. So, subscribe and get your email confirmation taken care of before posting. Otherwise your post may just be discarded, or sit waiting for a moderator to review.
* Stay subscribed, at least for a couple weeks after posting, so you will be aware of followup or discussion about your post that happens on the list. If you think the list produces too much email to stay subscribed for a while, then don't contribute to it by posting! The price of imposing your post on the community represented by the list is being part of that community for at least a while.
* If you are posting a resume, you will do yourself a huge favor by actually participating in the mailing lists you post to. Answer questions when you can for instance. Showing knowledge in a constructive way is better for you than fancy sounding fluff on your resume.
* If you are looking for work, considering add a link to your resume in your email signature so your availability is made clear to those who are impressed by your contribution to the mailing list. This sort of approach should be appropriate on any mailing list - even those which have a "no resume" posting rule.

== Geospatial Jobs Websites ==
* [http://www.gisuser.com Gisuser]: http://www.gisuser.com (See Jobs Tab)
* [http://www.gjc.org/ Geospatial Jobs Clearinghouse]: http://www.gjc.org/
* [http://www.freegis-italia.org/index.php?option=com_jobline&Itemid=123 GI & GIS in Italia]

Jobs Board

2008-10-15T23:14:40Z

Wiki-Giohappy:

== Introduction ==
This wiki page and associated wiki pages serve as a job board for members of the FOSS GIS Community. If you would like to post your resume or a job opportunity on this wiki, or if you have questions, please send an e-mail with the details to the [http://lists.osgeo.org/mailman/listinfo/jobs OSGeo Jobs Mailing List].

== Current Job Opportunities ==

== Resumes ==

=== FBK-MBPA ===

I would like to know if you may be in touch with some junior scientist interested to spend 2 or more years in Trento at FBK. We have open positions at MPBA starting this Fall. In particular there are two open post-doc research positions in which international candidates would be welcomed.

All open positions are listed at
http://mpba.fbk.eu/en/node/82

I would like to point your attention to the recent job call for post-doc position recently posted at http://scjobs.sciencemag.org/jobs/default.aspx?job=28474
by the Kessler Foundation.

In particular, one senior/junior research position is being offered at my laboratory on "Computational methods for information display of scientific and socio-economic data (Ref. code FI_PMBE) (1 position)". Information about the call and the specific position are available at http://risorseumane.fbk.eu/sites/risorseumane.fbk.eu/files/Future%20internet%20call%20-%20detail%203007.pdf

We are looking for a scientist with computational skills interested in interdisciplinary research. MPBA (http://mpba.fbk.eu) has more than 10 years of research in predictive models and ICT platforms for geocoded data, with an emphasis on open source software and on ethical contribution to society. MPBA's scientific core is now within bioinformatics and molecular based epidemiology, and we aim at the connection with the environmental and socio-economic aspects on the spatio-temporal scale. We are developing methods, projects and international collaborations on both research areas. On this specific call, we expect opportunities both for international research (in collaboration with OECD Paris) and for new applications to exploit with a spin-off initiative.

We will be glad to provide further information or discuss with candidates about the research, potential for collaboration, or local logistics. In any case, please note that we expect to have a first round of selections at mid October. Applications and CV should be sent to jobs@fbk.eu with Ref.Code FI_PMBE, cc to Cesare Furlanello (furlan - AT - fbk.eu)

=== Tyler Technologies: Java Developer (Post Date: 2008-02-04)===

We are looking for a permanent hire that is extremely strong in Java/OO Design. GIS experience is highly desired, but not absolutely required. Advanced and Strong Development skills are a must. We hire developers that are very strong at all experience levels, so years in the industry is also open, based on development skills.

If you are interested, please email me offline to avoid clutter on the mailing list.

The Eagle division of Tyler Technologies is seeking Java Developer with GIS experience for permanent immediate hire. The position will be located in our Lakewood office, (Denver Metro area). Tyler has an agile fun, fast paced, stable environment, driven by our heavy growth.

'''Requirements'''

The ideal candidate will have the following characteristics:

* Exceptionally strong understanding of Object Oriented Design.

* Deep understanding and advanced skill set with an OO language.

* Experience in Java.

* Exceedingly strong knowledge of an OO language.

* Extremely strong problem solving skills.

* Abstract Problem Solver.

* Will to work hard and exhibit strong work ethic.

* Ability to learn and adapt quickly in a dynamic environment.

* Passion for Software Development.

* Self-Motivation.

Desired, but not required.

* Experience with GIS tools.

* Experience with ESRI, ideally the Java toolkit.

* Experience with GeoTools.

* Knowledge of GIS libraries and API’s.

* Understanding of how users interact with GIS.

'''Level of Experience'''

This position would ideally call for a developer with some level of experience beyond a Junior Developer, since this position will help to not only design and implement a GIS product, but also help define requirements and help lead the direction of the product. However, Junior Developers will be considered that have an extremely strong understanding of Java or another Object Oriented Language.

'''Responsibilities'''

Participate in the complete Software Development Lifecycle. This includes: Requirements Analysis, Design, Implementation, Unit Testing, Deployment Tools, and Maintenance. This position will help to lead and define the GIS product, including an integration to all eagleSoftware products. Experience with GIS, ESRI, ArcSDE, and other such technologies are a strong plus. Understanding of how users interact with GIS and their needs is also highly desired.

'''Tyler’s Java Team'''

Tyler’s Java team is comprised of a relatively small group of individuals that all share a passion for Software Development and are well above average in terms of development abilities. We are looking to add a similar person. Our interview process is very technical and requires a strong and deep understanding of Object Oriented Design and Development. If you consider yourself a strong developer and love writing software, please apply to learn more.

'''Tyler Technologies (TYL)'''

Tyler Technologies is publically traded on the New York Stock Exchange (TYL). The Eagle Division develops leading edge technology solutions for local government – document recording, document & content management, assessment and tax.

The Eagle Division of Tyler Technologies has been providing technology solutions to government offices for almost 30 years. Over 1,900 cities and 620 counties use Tyler products to run their offices efficiently and successfully.

In 2004, Forbes listed Tyler Technologies in the top 200 small companies to work for in the United States (93rd on the list). In 2007 Forbes listed Tyler Technologies as one of America’s Most Trustworthy Company (tied for 3rd on the list).

The Eagle division of Tyler has never laid anyone off in almost 30 years of being in business. The Eagle division is one of the fastest growing divisions of Tyler.

We offer competitive pay and benefits to over 1,600 employees and we have a long track record of supporting our employee’s careers and lives.

== General Advice on Mailing List Postings ==

Targetted mailing lists can be a great place to post about available jobs or resumes. But to avoid giving you or your organization a bad reputation it is important to use mailing lists in as polite a fashion as possible.

* Don't post to a mailing list that has a "no jobs, no resumes" policy. We will make some effort to keep track of these below in the "Appropriate Places to Post" but ideally you should do a bit of research on the lists you post to before posting.
* Do not post a job or resume repeatedly to the same list. If your organization has several job openings try and post them in a single post rather than sending several separate emails.
* Only post to lists very "on topic" for the job posting. For instance, don't post to the GRASS list if you don't need GRASS skills just on account you think there might be some folks there with the skills you are looking for.
* Try to minimize the total number of lists you post to. If you are posting to a job/resume to more than four or five mailing lists it is likely that many folks will get the post several times and their opinion of you will be lowered. So just select the optimal lists.
* Do not email out resumes or job postings as attachments. Send email as plain text with links to web pages for full details and nicely formatted postings/resumes.
* Prefix your subject line with "Job: " or "Resume: " so folks not interested can easily skip the email without reading into it. For instance "Resume: Frank Warmerdam" or "Job: Geoweb Developer - Washington, DC"
* If you have some absolute requirements try to make them clear early in the email so folks don't have to read far before skipping the message. If you require someone with extensive PHP skills, or who is a US citizen or who speaks French fluently make it clear up front.
* Most mailing lists require you to be subscribed to the list in order to accept posts from you. So, subscribe and get your email confirmation taken care of before posting. Otherwise your post may just be discarded, or sit waiting for a moderator to review.
* Stay subscribed, at least for a couple weeks after posting, so you will be aware of followup or discussion about your post that happens on the list. If you think the list produces too much email to stay subscribed for a while, then don't contribute to it by posting! The price of imposing your post on the community represented by the list is being part of that community for at least a while.
* If you are posting a resume, you will do yourself a huge favor by actually participating in the mailing lists you post to. Answer questions when you can for instance. Showing knowledge in a constructive way is better for you than fancy sounding fluff on your resume.
* If you are looking for work, considering add a link to your resume in your email signature so your availability is made clear to those who are impressed by your contribution to the mailing list. This sort of approach should be appropriate on any mailing list - even those which have a "no resume" posting rule.

== Geospatial Jobs Websites ==
* [http://www.gisuser.com Gisuser]: http://www.gisuser.com (See Jobs Tab)
* [http://www.gjc.org/ Geospatial Jobs Clearinghouse]: http://www.gjc.org/
* [http://www.freegis-italia.org/index.php?option=com_jobline&Itemid=123 GI & GIS in Italia]

OSGeo Cartographic Engine

2008-06-10T13:17:44Z

Wiki-Giohappy: /* End User Needs */

== Motivation ==

There are plans for new/rewritten cartographic tools (map composer) for QGIS, as well as for GRASS. We suggest to develop a joint library for the various functions which could be shared across GRASS, QGIS and other projects with bindings to Qt, Python etc. The GUI part will be done within the individual software projects, while this project focuses on standard libraries or command line utilities.

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

== 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)
* Color management:
** MapGuide [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/PlatformBase/Data/Color.cpp Color] (LGPL.C++)
** OpenJump ?

* Stylization
** ...

* 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++)

* 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)
** [Mapnik http://mapnik.org/] is a Free Toolkit for developing mapping applications.

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

==Potential Components==
Breaking the end goal into some components will help to recognise which area(s) there is greatest need. There seems to be at least four primary components to the proposal.

=== Style & Layout Configuration Standards ===
* Specifications for styling of features and layout of a map composition
* Could re-use existing approaches where applicable (e.g. SLD, WMC, MapServer Mapfile, OGR Feature Styles)
* Specifications to be used in map definition/configuration files

=== Graphical Style & Layout Editor ===
* To create styles interactively
* To define map layout
* Could be stand-alone
* Could be adopted as part of another application
* Saves a style/layout definition document according to above standards

=== Graphical Map Composition Editor ===
* Implemented by existing applications (e.g. GRASS, QGIS, etc.)
* Sets up pointers to data layers
* Assigns styles definitions to the layers
* Applies layout definition to maps
* Outputs a map composition configuration file

=== Rendering Engine ===
* Stand-alone application (no GUI)
* Reads standard map composition configuration file
* Reads and applies the required style/layout definition documents
* Outputs final graphics to specific files

=== Libraries ===
* Sets of libraries could be created to implement parts of the above sections
* Add more here...

== Technologies ==

* 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

== 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]]
* [[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

== See also ==

* [[OSGeo map symbol set]]

[[Category: Software Stack]]

OSGeo Cartographic Engine

2008-06-10T13:12:49Z

Wiki-Giohappy: /* Interested people */

== Motivation ==

There are plans for new/rewritten cartographic tools (map composer) for QGIS, as well as for GRASS. We suggest to develop a joint library for the various functions which could be shared across GRASS, QGIS and other projects with bindings to Qt, Python etc. The GUI part will be done within the individual software projects, while this project focuses on standard libraries or command line utilities.

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

== 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)
* Color management:
** MapGuide [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/PlatformBase/Data/Color.cpp Color] (LGPL.C++)
** OpenJump ?

* Stylization
** ...

* 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++)

* 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)
** [Mapnik http://mapnik.org/] is a Free Toolkit for developing mapping applications.

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

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

==Potential Components==
Breaking the end goal into some components will help to recognise which area(s) there is greatest need. There seems to be at least four primary components to the proposal.

=== Style & Layout Configuration Standards ===
* Specifications for styling of features and layout of a map composition
* Could re-use existing approaches where applicable (e.g. SLD, WMC, MapServer Mapfile, OGR Feature Styles)
* Specifications to be used in map definition/configuration files

=== Graphical Style & Layout Editor ===
* To create styles interactively
* To define map layout
* Could be stand-alone
* Could be adopted as part of another application
* Saves a style/layout definition document according to above standards

=== Graphical Map Composition Editor ===
* Implemented by existing applications (e.g. GRASS, QGIS, etc.)
* Sets up pointers to data layers
* Assigns styles definitions to the layers
* Applies layout definition to maps
* Outputs a map composition configuration file

=== Rendering Engine ===
* Stand-alone application (no GUI)
* Reads standard map composition configuration file
* Reads and applies the required style/layout definition documents
* Outputs final graphics to specific files

=== Libraries ===
* Sets of libraries could be created to implement parts of the above sections
* Add more here...

== Technologies ==

* 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

== 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]]
* [[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

== See also ==

* [[OSGeo map symbol set]]

[[Category: Software Stack]]

OSGeo Cartographic Engine

2008-06-10T13:12:18Z

Wiki-Giohappy: /* Interested people */

== Motivation ==

There are plans for new/rewritten cartographic tools (map composer) for QGIS, as well as for GRASS. We suggest to develop a joint library for the various functions which could be shared across GRASS, QGIS and other projects with bindings to Qt, Python etc. The GUI part will be done within the individual software projects, while this project focuses on standard libraries or command line utilities.

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

== 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)
* Color management:
** MapGuide [http://trac.osgeo.org/mapguide/browser/trunk/MgDev/Common/PlatformBase/Data/Color.cpp Color] (LGPL.C++)
** OpenJump ?

* Stylization
** ...

* 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++)

* 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)
** [Mapnik http://mapnik.org/] is a Free Toolkit for developing mapping applications.

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

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

==Potential Components==
Breaking the end goal into some components will help to recognise which area(s) there is greatest need. There seems to be at least four primary components to the proposal.

=== Style & Layout Configuration Standards ===
* Specifications for styling of features and layout of a map composition
* Could re-use existing approaches where applicable (e.g. SLD, WMC, MapServer Mapfile, OGR Feature Styles)
* Specifications to be used in map definition/configuration files

=== Graphical Style & Layout Editor ===
* To create styles interactively
* To define map layout
* Could be stand-alone
* Could be adopted as part of another application
* Saves a style/layout definition document according to above standards

=== Graphical Map Composition Editor ===
* Implemented by existing applications (e.g. GRASS, QGIS, etc.)
* Sets up pointers to data layers
* Assigns styles definitions to the layers
* Applies layout definition to maps
* Outputs a map composition configuration file

=== Rendering Engine ===
* Stand-alone application (no GUI)
* Reads standard map composition configuration file
* Reads and applies the required style/layout definition documents
* Outputs final graphics to specific files

=== Libraries ===
* Sets of libraries could be created to implement parts of the above sections
* Add more here...

== Technologies ==

* 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

== 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]]
* [[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 research

== See also ==

* [[OSGeo map symbol set]]

[[Category: Software Stack]]

Italiano

2006-12-23T17:29:05Z

Wiki-Giohappy: /* Gli interessati */

[[Local_Chapters|<< Back to the Local Chapters page]]

== Comunità GFOSS italiana ==
E' attualmente in corso un tentativo di proporre agli utenti di lingua italiana la creazione di un Local Chapter di Osgeo.
La discussione è sulla mailing list di GFOSS.it :
* La mailing list: http://www.faunalia.com/pipermail/gfoss/

Si invita le persone interessate ad aggiungersi alla lista alla voce [[#Gli interessati]].

== Links==
''(siti in italiano)''

* Il portale: http://www.gfoss.it
* Il Wiki: http://wiki.gfoss.it
* La mailing list: http://www.faunalia.com/pipermail/gfoss/
* Il canale IRC: #gfoss su irc.freenode.net irc://irc.freenode.net/#gfoss
* [http://wiki.gfoss.it/index.php/PagineJabber Qui] gli indirizzi Jabber della comunità GFOSS italiana.

==Gli interessati==
* Paolo Cavallini
* Lorenzo Becchi
* Stefano Costa
* Maria Antonia Brovelli
* Francesco P. Lovergine
* Ivan Marchesini
* Giovanni Allegri

== Guidelines ==
=== Chapter Roles ===

* Provide member networking opportunities for support and job opportunities - '''OK'''
* Software Internationalization and Localization - '''OK'''
* Development of prototype applications to demonstrate Open Source geospatial capabilities to local and regional audiences - '''OK'''
* Software Packaging and Customization for local and regional needs - '''OK''' ( GFOSS live CD)
* Training, Support and Development of e-Learning Contents in local languages - '''OK'''
* Support Open standards and Open access to geospatial data in region '''OK'''
* Promoting OSGeo and enhancing visibility in various forums

=== Chapter Responsibilities ===

* “OSGeo Chapter” officially represents OSGeo and is formally recognized as OSGeo Project.
* “OSGeo Chapter” must support the OSGeo Mission and Objectives of OSGeo.
* “OSGeo Chapter” must hold regular meetings (at least annual) and provide annual report of activities to chapter membership and OSGeo Board. '''OK'''
* “OSGeo Chapter” will not entail any financial commitment from or on-behalf of OSGeo. OSGeo will also not provide any budget assistance to the “OSGeo Chapter”.
* “OSGeo Chapter” is encouraged develop and maintain “Directory Listing” of companies, people, universities and organizations involved with or using OSGeo projects.
* “OSGeo Chapter” must strive at networking with organizations to enlist participation and support for OSGeo.
* OSGeo reserves the right to terminate its relation with an “OSGeo Chapter” if OSGeo has reasons to believe that the activities of the “OSGeo Chapter” are contrary or detrimental to the Mission and Objectives of OSGeo.

===Chapter Formation ===

In order to form a chapter, the following steps should be taken:
# "OSGeo Chapter" should self-organize (for instance in the OSGeo wiki, via OSGeo mailing list, etc), seeking to determine if a critical mass of interest exists to justify a chapter. - '''READY'''
# "OSGeo Chapter" should prepare a mission and objectives indicating the scope of the planned chapter (geographic or linquistic extent for instance). - '''READY''' (lang:it)
# “OSGeo Chapter” should propose an official representative to liaise with the OSGeo Board. If accepted by the board, the representative will be an officer of OSGeo. - '''TODO'''
# “OSGeo Chapter” should submit an official expression of interest to form a chapter to the OSGeo board, listing initial members, mission, representative and other supporting information. - '''TODO'''
# The OSGeo board shall then consider passing a motion forming the chapter, and designating the liason officer. - '''TODO'''

In considering the formation of new OSGeo chapters, the board will consider issues including:
* Does the mandate (geographically or linguistically) conflict with other existing chapters or chapters-in-formation? - '''NO'''
* Does the chapter appear to have sufficient interest to justify official formation? - '''YES'''
* Does the chapter appear to be open to broad membership, and representative of the target geographic or linguistic community? (eg. if a chapter had the objective to cover all Spanish speakers, it would be inappropriate if the only interest demonstrated was from one country) - '''YES'''

[[Category:Local Chapters]]