OSGeo - User contributions [en]

Geoservices REST API

2013-05-09T11:22:37Z

Wiki-Gabi: /* Signed */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= Open Letter to OGC and voting members =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

May 2013

We, the undersigned, have concerns that approving the "Geoservices REST API" as an OGC standard, would have detrimental impacts on interoperability within the spatial industry.

We strongly urge that the proposed "Geoservices REST API", as it stands in May 2013, be rejected as an OGC standard.

People have listed different reasons for concern. They are described below.

== Signed ==
''Please add your name here if you agree with the above statement. Include name, work title (if appropriate), very brief title/involvement in OSGeo if appropriate. (Link to OSGeo profile if appropriate). You may sign as a group, such as the Project Steering Committee of XXX project if you wish, or as Your Name on behalf of YYY company.''

* [[User:camerons|Cameron Shorter]], Geospatial Solutions Director at [http://lisasoft.com LISAsoft], core contributor & coordinator of [http://live.osgeo.org OSGeo-Live]
* [[User:Woodbri|Stephen Woodbridge]], Director of [http://imaptools.com iMaptools.com], Contributor and/or PSC of [http://mapserver.org Mapserver], [http://pgrouting.org/ pgRouting], [http://www.pagcgeo.org/ PAGC], and [http://www.postgis.org/ PostGIS]
* [[User:rouault|Even Rouault]], Geospatial developer, OSGeo Charter Member, core contributor and PSC member of [http://gdal.org GDAL/OGR], contributor of [http://mapserver.org Mapserver], [http://trac.osgeo.org/proj/ PROJ.4], [http://trac.osgeo.org/geotiff/ libgeotiff], [http://shapelib.maptools.org/ shapelib], [http://www.remotesensing.org/libtiff/ libtiff]
* Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
* [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
* [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
* [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
* [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], member at [http://www.opengeogroep.nl OpenGeoGroep]
* [[User:milovanderlinden|Milo van der Linden]], member at [http://www.opengeogroep.nl OpenGeoGroep]
* [[User:surveyor|Landon Blake]], GIS Department Manager/Land Surveyor at [http://www.ksninc.com KSN], OSGeo California Chapter Board Representative.
* [[User:dmorissette|Daniel Morissette]], President at [http://mapgears.com/ Mapgears], core contributor and PSC member of [http://mapserver.org Mapserver] and [http://gdal.org GDAL/OGR]. Former OGC TC member and involved in the implementation of several OGC WxS services specs in MapServer.
* [[User:blammo|Bob Basques]], GIS Systems Developer at the City of Saint Paul, MN. [http://gis.ci.stpaul.mn.us Public Works GIS (GISmo)], Technical Director at [http://www.sharedgeo.org SharedGeo], OSGeo Charter Member, OSGeo TCMUG local chapter member, Co-founder and PSC member of [http://www.geomoose.org GeoMoose] project.
* [[User:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
* Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
* [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
* [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
* [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
* [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Italy
* [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
* [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
* [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
* [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
* [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
* [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
* [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
* [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
* [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]

= Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. Where appropriate, link to external web pages (such as email achieves)''

== Summary ==
As at May 2013, OGC members have been asked to decide whether to accept the "GeoServices REST API" as an OGC standard. This is a contentious issue, with many people arguing that introduction of the “GeoServices REST API” will have costly, far reaching, negative impacts on interoperability, and significantly tarnish the OGC's reputation as a champion of interoperability.

The key points of contention revolve around the fact that the proposed "GeoServices REST API" does not build upon or extend existing OGC standards, but rather addresses similar requirements using an alternative API. In particular, the overlap and/or duplication of existing standards is widespread: OGC's core standards of WMS, WMTS, WFS, SE/SLD, WCS, CS/W are all duplicated to a significant extent. This defeats the purpose of having standards in the first place.

Duplication of standards will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different OGC standards that essentially do the same thing.
# This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
# After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one standard as the preferred standard for all agencies to follow. To date, the OGC has provided this leadership.
# One standard taking prominance over the other will likely lead to the other being neglected or deprecated, resulting in many OGC compliant systems becoming legacy systems in the process. This should be considered an undesirable outcome for a standards organisation. Backward compatibility to the existing WxS standards is important in this respect.
# Given backwards compatibility with the ESRI Restful implementation is mandated, this is not an Open Standard, and should not be ratified as if it was.

== Political Concerns ==

* Adopting the standard will expose the OGC to a strong suspicion of acting as a rubber stamp organization under ESRI weight, and will be detrimental to its recognized position as a reference organization for geospatial standards.
* It is a dubious practice that a standardization organisation promotes competing standards, without explicitely obsoleting (or at least recommending) some of them. How is a new comer to the industry supposed to select the appropriate standard if several ones share the same scope : WFS or GeoServices REST API Feature Service, WMS or GeoServices REST API Map Service, etc. ?

== Commercial Concerns ==

* Promoting standards from an existing implementation made by a single vendor leads to an obvious bias in competition.
* Supporting multiple overlapping standards greatly reduces usability while it increases complexity and cost of development and maintenance.
* Many SME's have invested in supporting existing OGC standards in their products. They will be forced to choose the standards they support (and can explain), resulting in decreased interoperability, confusion and frustration for clients.
* Confusing customers with new, overlapping OGC standards will lower the credibility of companies and of OGC, reducing business opportunities.

== Technical Concerns ==

* The Geoservices REST API overlaps in large proportion with existing OGC standards such as WMS, WCS, WFS, WMTS, CSW, with no effort made to reconcile with those standards.
* The standardization of WKT for Spatial reference systems is unfortunately currently quite weak in OGC standards. Geoservices REST API is tied with ESRI's version of WKT, which is not properly specified in the Geoservices REST API documents, and is known to be incompatible with other OGC documents, which will lead to a larger confusion. See the following [http://lists.opengeospatial.org/pipermail/requests/2012-July/000166.html comment] for more details on this issue.
* The Geoservices REST API is not particularly RESTful - it's a thinly disguised service call, not an address space for RESTful objects that can be operated on.
* At least as far as "imagery" is concerned, OGC standards arguably are substantially more mature, powerful, flexible, and modular then the ESRI "Geoservice REST API" Part 6 (and some design principles suggest that scalability may be hampered as well):
** data model:
*** the ESRI "Geoservice REST API" appears constrained to 2-D imagery, plus optional time stamps. OGC has established a [http://en.wikipedia.org/wiki/Coverage_data unified coverage model] which fully supports n-D spatio-temporal data. It allows use and exchange of coverages between different services, such as [http://en.wikipedia.org/wiki/Web_Coverage_Service WCS], [http://en.wikipedia.org/wiki/Web_Coverage_Processing_Service WCPS], WPS, and SWE.
*** OGC coverages support both regular and irregular grids; the ESRI "Geoservice REST API" supports only regular grids, more specifically: only rectified grids with quadrilateral pixels.
*** the ESRI "Geoservice REST API" lacks support for temporal data; it only offers timestamps, measured in milliseconds; this is inconvenient for users and immediately excludes, e.g., geological dates. OGC has established uniform handling of horizontal, vertical, and temporal coordinate reference systems (CRSs), following a deep consensus process with GIS science and backwards compatible with EPSG. The ESRI "Geoservice REST API" specific way of handling coordinates is not known to support this, thereby excluding appropriate timeseries handling in remote sensing, air traffic, MetOcean, etc.
*** OGC coverages provide a concise, versatile model for supporting different binary formats; the ESRI "Geoservice REST API" supports only very few selected 2-D formats, excluding, e.g., JPEG2000, NetCDF, HDF, etc.
*** the ESRI "Geoservice REST API" lacks a clear model of their data structures, it can be deduced only implicitly from the operation mechanics.
** service model:
*** The ESRI "Geoservice REST API" Part 6 lacks conciseness, thereby opening up ways for implementations that are not interoperable. For developers of alternative implementations this will mean they have to acquire ESRI licenses for finding out the intended behavior.
*** Functionality in the ESRI "Geoservice REST API" appears randomly chosen, with no clear concept visible; this burdens implementers while still leaving holes of functionality. For example, this functionality appears restricted to mapping applications and does not easily extend into other domains.
*** It has been said that the ESRI "Geoservice REST API" can be seen as a "wrapper around OGC W*S" services. This is not true for WCS (and WCPS), at least: the ESRI "Geoservice REST API" Part 6 is too poor in functionality and too different in mechanics to accomplish this.
** In summary, the ESRI "Geoservice REST API" Imaging part is at a technological level where WCS departed from some 5 years ago. Inconciseness of the specification at large will make it difficult for third parties to come up with interoperable implementations. Therefore, Part 6 of the ESRI "Geoservice REST API", if to become a standard, needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.

== Methodological Concerns ==

* No public response (nor private to the authors of the comments) has been made to the various comments sent on the OGC Requests mailing list in [[http://lists.opengeospatial.org/pipermail/requests/2012-July/date.html July 2012]] and [[http://lists.opengeospatial.org/pipermail/requests/2012-August/date.html August 2012]] during the 30 day public comments period.
* The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement of backward compatibility with ESRI implementation. Consequently, the standard is unlikely to improve, or its evolution will be only lead by ESRI.
* OGC standards normally require interoperability experiments and a richer process to ratify a standard such as this one. No explanation has been forthcoming as to why a simplified process is appropriate in this case.

= History =

Todo: please expand
* Explain how this standard came to be
* Based on ArcGIS Server API
* Attempted but failed to go through OGC fast track process
* Recent voting history: refer to: http://lists.osgeo.org/pipermail/discuss/2013-May/011602.html

= References =
Todo: Link to key external docs, such as the proposed standards

[[Category: OGC]]
[[Category: Standards]]

User:Gabi

2013-05-09T10:35:37Z

Wiki-Gabi:

Gabriel Carrión Rico

carrion_gab AT gvsig DOT com

gvSIG association / Strategy Manager

http://www.gvsig.com

http://www.gvsig.org

http://blog.gvsig.org/

http://outreach.gvsig.org/

User:Gabi

2012-05-25T09:41:42Z

Wiki-Gabi:

Gabriel Carrión Rico

carrion_gab AT gva DOT es

Proyecto gvSIG

http://www.gvsig.org

http://blog.gvsig.org/

http://outreach.gvsig.org/

User:Gabi

2012-05-25T09:41:27Z

Wiki-Gabi:

Gabriel Carrión Rico

carrion_gab AT gva DOT es

Proyecto gvSIG

http://www.gvsig.org
http://blog.gvsig.org/
http://outreach.gvsig.org/

User:Gabi

2007-03-14T09:24:33Z

Wiki-Gabi:

Gabriel Carrión Rico

Conselleria de Infraestructuras y Transporte

Generalitat Valenciana

carrion_gab AT gva DOT es

Director del proyecto gvSIG

http://www.gvsig.gva.es/

User:Gabi

2007-03-13T16:56:23Z

Wiki-Gabi:

Gabriel Carrión Rico

carrion_gab AT gva DOT es

Director del proyecto gvSIG

http://www.gvsig.gva.es/

User:Gabi

2007-03-13T16:54:38Z

Wiki-Gabi:

Gabriel Carrión Rico

carrion_gab AT gva DOT es

Director del proyecto gvSIG

2007-03-13T16:51:43Z

Wiki-Gabi: /* Lista de Interesados */

==Introducción (es)==

En dos eventos distintos se ha manifestado la intención de crear un Capitulo Local OSGeo de idioma Español.
El primero tuvo lugar [http://wiki.osgeo.org/index.php/Resultados_del_Tutorial_ISSTOCAM_WebGIS ISSTOCAM WebGIS Meeting] en Ostende, Belgica (resultando en la página [[Sudamerica]]) y el segundo han sido las [[Meeting_Girona| I Jornadas de SIG Libre]] en Girona, España.
Se trata de un muy buen comienzo para juntar esfuerzos y crear una comunidad muy amplia dentro de OSGeo.

==Introduction (en)==
Two different meetings have manifested the intention to create a Spanish language OSGeo local chapter.
One is the [http://wiki.osgeo.org/index.php/Resultados_del_Tutorial_ISSTOCAM_WebGIS ISSTOCAM WebGIS Meeting] in Oostende Belgium (also giving birth to the page [[Sudamerica]]),
and the other is the [http://www.sigte.udg.es/jornadassiglibre/ first Spanish meeting about foss4g] in Girona Spain.
This is a very good starting point to join efforts and create a widespread community inside OSGeo.

==Lista de Interesados==
Por favor leed [[Español#Chapter_Roles|el rol del Local Chapter]] y sus [[Español#Chapter_Responsibilities|Responsabilidades]] antes de ajuntar el propio nombre.

* [[User:ominiverdi|Lorenzo Becchi]]
* [[User:Arnulf Christl|Arnulf Christl]]
* [[User:Luisw|Luis W. Sevilla]]
* [[User:Jsanz|Jorge Gaspar Sanz]]
* [[User:Alvaro|Alvaro Anguix Alfaro]]
* [[User:Rantolin|Roberto Antolín Sánchez]]
* [[User:jacarma|Javier Carrasco Marimón]]
* [[User:MMontesinos|Miguel Montesinos]]
* [[User:mpaul42|Michael Paul]]
* [[User:Koen Verbist|Koen Verbist]]
* [[User:Lluís|Lluís Vicens]]
* [[User:jcfernan|Juan Carlos Giménez Fernández]]
* [[User:FranciscoPalm|Francisco Palm]]
* [[User:mdelacalle|Manuel de la Calle]]
* [[User:volaya|Víctor Olaya]]
* [[User:mapas|Oscar Beaurain]]
* [[User:Gabi|Gabriel Carrión Rico]]
* añadete tu mismo

==Lista de correo==
[[User:ominiverdi|Lorenzo]] ya ha puesto en marcha la lista de correo '''Spanish''' para OSGeo:

[http://lists.osgeo.org/mailman/listinfo/spanish http://lists.osgeo.org/mailman/listinfo/spanish]

==Difusión del proyecto==
Listado de medios en los que sería interesante que se anunciara el inicio del proyecto.Indicar responsable de avisar al medio y conforme se vayan publicando las reseñas se pueden ir <s>tachando</s>.
=== Newsletters ===
* [[Newsletter]]
=== Listas de Correo ===
* <s>Lista SIG RedIRIS</s>
* <s>Discussion List de OSGeo</s>

=== Foros ===
=== Sitios de noticias ===

* [http://www.nosolosig.com/ Nosolosig] (encargado de avisar: Alvaro Anguix)
* <s>[http://www.cartesia.org/ Cartesia]</s>
* <s>[http://www.libroblanco.com/html/index.php Libro Blanco del Software Libre]</s>

=== Revistas ===
* [http://geofocus.rediris.es/ geofocus]
* [http://www.mappinginteractivo.com/ Mapping Interactivo]
* [http://www.geoconnexion.com/ Geonnexion International Magazine]
* [http://www.gim-international.com/ GIM International]
===Blogs===
* <s>[http://geomaticblog.net/ geomaticblog]</s>
* <s>[http://blog.ominiverdi.org/ Ominiverdi's Blog]</s>
* <s>[http://www.alpoma.net/carto/ La Cartoteca]</s>

== Roles del Capítulo (es) ==

El software Open Source ha demostrado ser un entorno para construir software más fuerte mediante la colaboración global. La Fundación Software Abierto Geoespacial, a partir de ahora OSGeo, ha sido creada para apoyar y construir el software geoespacial de más alta calidad.

La meta de OSGeo es aumentar el uso de proyectos OSGeo globalmente promoviendo una fuerte asociación localizada y la presencia en diferentes dominios geográficos y lingüisticos. Además de ser una fuerte voz local para OSGeo, algunas de las principales tareas con las que esta asociación local de OSGeo puede enriquecer y mejorar las iniciativas geoespaciales globales pueden ser:

* Proporcionar soporte y oportunidades de trabajo a los miembros a través de la red
* Internacionalización y localización de software
* Desarrollar prototipos de aplicaciones para demostrar las capacidades del software abierto geoespacial a audiencias locales o regionales
* Empaquetado y personalización para las necesidades locales y regionales
* Educación, soporte y desarrollo de contenidos de aprendizaje en lenguaje español
* Soporte de estándares abiertos y acceso abierto a datos geoespaciales de la región
* Promover OSGeo y mejorar su visibilidad en varios foros

Estas actividades complementarían y fortalecerían los esfuerzos de OSGeo en aumentar el conocimiento acerca de soluciones geoespaciales de código abierto estimulando su adopción en la educación, en la industria, en el gobierno y organizaciones sin ánimo de lucro y en variados dominios geográficos y lingüisticos.

== Chapter Roles (en) ==

Open Source software has come to be a proven environment for building stronger software through open global collaboration. The Open Source Geospatial Foundation, hereafter referred to as OSGeo, has been created to support and build the highest-quality geospatial software.

The OSGeo's goal is to promote the use OSGeo projects globally by fostering strong localized OSGeo partnership and presence in different geographic and linguistic domains. Apart from being a strong local voice for the OSGeo, some of the major tasks whereby localized OSGeo partnership and presence could enrich and enhance global geospatial initiatives would be;

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

The above activities would complement and strengthen the efforts of OSGeo in increasing awareness about available Open Source Geospatial solutions and stimulating adoption in education, industry, government and non-profit organizations in various geographic and linguistic domains.

== Responsabilidades del Capítulo (es) ==
OSGeo no diferencia entre un grupo geográfico y uno lingüístico y estimula la organización autónoma de forma similar a los ''Grupos de Usuarios'' o ''Grupos de Interés Especial'' en otros proyectos ''Open Source''. Los ''Grupos de Usuarios'' o los ''Grupos de Interés Especial'' no representan formalmente a OSGeo pero pueden aprovechar algunos de los servicios como el uso del Wiki de OSGeo. El ''Capítulo Español'' ofrece una estructura formal de organización autónoma basada en una pocas directrices listadas a continuación:
* El ''Capítulo Español'' oficialmente representa OSGeo y es formalmente reconocido como un proyecto de OSGeo.
* El ''Capítulo Español'' debe apoyar las misiones y objetivos de OSGeo.
* El ''Capítulo Español'' debe mantener encuentros regulares (al menos uno anual) y proporcionar un informe anual sobre las actividades del mismo al Comité de Dirección (?) de OSGeo.
* El ''Capítulo Español'' no dispondrá de ningún compromiso financiero de o en nombre de OSGeo. De igual forma, OSGeo no proporcionará ningún presupuesto al ''Capítulo Español''.
* El ''Capítulo Español'' debe esforzarse en su relación con las organizaciones para conseguir la participación y el soporte para OSGeo.
* OSGeo se reserva el derecho a terminar su relación con el ''Capítulo Español'' si tiene razones para creer que las actividades del ''Capítulo Español'' son contrarias o en detrimento de la Misión y Objetivos de OSGeo.

== Chapter Responsibilities (en) ==

OSGeo does not differentiate between a geographic or linguistic grouping and strongly encourages self-organization similar to "User Groups" or "Special Interest Groups" in other
Open Source Projects. "User Groups" or "Special Interest Groups" do not formally represent OSGeo but can avail some of the services such as the use of OSGeo Wiki. "OSGeo Chapter" offer
a more formal framework for self-organization based on a few simple guidelines listed below;

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

== Ventajas del Capítulo (es) ==
* Se permite al ''Capítulo Español'' el uso del logotipo de OSGeo y otros recursos de imagen corporativa (???) para promocionar la Misión y Objetivos de OSGeo.
* OSGeo proporcionará la infraestructura necesaria para promocionar la comunicación y visibilidad del ''Capítulo Español''. La infraestructura incluye una lista de correo, hospedaje para páginas wiki y servicio de dominio para el ''Capítulo Español''.

== Chapter Benefits (en) ==

* “OSGeo Chapter” is permitted to use OSGeo Logo and other branded resources for promoting the Mission and Objectives of OSGeo.
* OSGeo will provide necessary infrastructure to promote communication and visibility of “OSGeo Chapter”. The infrastructure will include mailing list, hosting of wiki pages, domain service for “OSGeo Chapter”.

== 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.
##DONE: [http://lists.osgeo.org/mailman/listinfo/spanish Mailing List] and this page. Hope to have soon a dedicated Wiki and a Web Site.
# "OSGeo Chapter" should prepare a mission and objectives indicating the scope of the planned chapter (geographic or linquistic extent for instance).
##DONE: The mission is to sustain and spread OSGeo principles in Spanish Language without country borders limitations.
# “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?
* Does the chapter appear to have sufficient interest to justify official formation?
* 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)

[[Category:Local Chapters]]
[[Category:Español]]