Starting build cycle for OSGeo-Live 7.9

20 December 2013
We are starting the build cycle for version 7.9 of the OSGeo-Live DVD/USB/VM which will be released in March 2013, ready for several special events, including the OSGeo Code Sprint in Vienna, Spanish FOSS4G, French FOSS4G, FOSSGIS Germany, among others.
Our aim for this release is to focus on .deb packaging, which will make projects simple to install on all debian and ubuntu based distributions.
We would like to hear from anyone wishing to add new projects to OSGeo-Live, anyone wishing to extend or add translations, or anyone who has ideas on how we should shape the upcoming release.
IMPORTANT : Could all projects please reply to us with the preferred, stable version of software to be included in this release.

Key Milestones

14 Jan 2014 All new applications installed, most old applications updated

31 Jan 2014 Feature Freeze (all apps updated)

21 Feb 2014 User Acceptance Test (all apps installed and working)

14 Mar 2014 Final ISO sent to printers

... full schedule

OSGeoLive 7.9 Alpha1 released

We have released the first alpha version of OSGeo-Live, which builds upon Xubuntu 12.04.3 release along with updated versions of applications from UbuntuGIS repository. Feel free to start testing your applications in the latest release. Download Alpha 1

About OSGeo-Live

OSGeo-live is an XUbuntu based distribution of Geospatial Open Source Software, available via a Live DVD, Virtual Machine and USB. You can use OSGeo-Live to try a wide variety of open source geospatial software without installing anything.

"How to publish maps" - at Envirohack

At the upcoming Envirohack  event, I'll be compressing weeks worth of LISAsoft's Open Source Geospatial training material into a 10 minute lightning overview on how to publish geographic maps. I confess that I'll need to skimp on a few details, but it will give attendees direction on where to start, and where to look for more information.

Envirohack is a one day hack-a-thon being held 29 November 2013 in Canberra, Sydney and Brisbane, aimed at building prototypes of application prototypes which make use of  Australian geospatial datasets.
Datasets include:

• Administrative and statistical boundaries
•  Hydrography
• Transport, Utilities
• Geocoding and reverse geocoding
• Terrain, elevation, land use, ...
• Climate change, health, ...
• Imagery

A Call to Action: Digitize Imagery for the Philippines

Request from the World Bank:
Typhoon Yolanda has had a devastating impact on the Philippines.  Thousands are feared dead and many more have been affected by one of the strongest storms on record. The work required to respond and recover from this event will be massive.

One way that you can help is by contributing to OpenStreetMap (OSM).  OSM is a free and open map of the world that everyone can access and contribute to. Right now, hundreds of volunteers from all over the world are working together to digitize roads, buildings, and other features from satellite imagery made freely available by Microsoft and the US State Department's Humanitarian Information Unit. With the coordination of our partners at the Humanitarian OpenStreetMap Team, the geographic information they are creating is already being used by the Red Cross, the United Nations and other responding organizations working in the Philippines. There is more work to be done and the Understanding Risk Community is uniquely positioned to help.

To get started, you can:

• Visit the project coordination page for more information: http://wiki.openstreetmap.org/wiki/Typhoon_Haiyan
• Login to OSM Tasking Manager (OpenStreetMap account required) and click on a task to contribute: http://tasks.hotosm.org/
• If you have any questions or want to learn more you can join the mailing list of the Humanitarian OpenStreetMap Team: https://lists.openstreetmap.org/listinfo/hot

Image available under creative commons.

Ideas4OGC - the phoenix rising from the "GeoServices REST API" ashes

You may remember the contentious proposal for the GeoServices REST API to become an OGC standard? After strong community concerns, largely focused on duplication of existing standards, the motion to approve the proposed standard was withdrawn. The fact that the proposal progressed as far as it did, to the point where it was almost ratified as a standard before being blocked, was a primary driver leading the OGC to initiate an "Ideas for OGC" (Ideas4OGC) review, aimed at re-baselining OGC priorities and processes.
Re-assessing OGC priorities and processes was timely. The OGC is almost 20 years old. OGC standards are now addressing broader and more complicated use cases than OGC's original focus, including mass market, mission critical and production uses. This leads to greater complexity, pressure to maintain consistency between standards, as well as higher requirements for robustness, quality, and clear documentation.
These drivers were fed into the Ideas4OGC initiative, and I've been impressed with the initial set of recommendations which clearly and concisely address OGC's revised priorities and objectives. Highlights include:

• ... any [standard] coming to OGC .. should go through an “early” evaluation process to test the validity of adding it to the OGC baseline. ...
• Early evaluation of [a] new domain's [uniqueness], usefulness and applicability  to OGC ...
• ... strongly encourage internal harmonization of OGC standards  ...
• Routine harmonization through regular standards maintenance. ...
• Develop concise overviews for each standard for managers, architects and programmers. ...
• Develop a set of accessible, concise summaries of OGC rules, policies and procedures ... 
• Provide engineers/architects with [a] well-defined collection of guidelines, templates and tools  ...
• Consistent editorial review ...

The next challenge for the OGC will be to re-prioritise sponsor focus on improving core quality over features. It is exactly what is required, but is a tough sell, as the value is much harder to quantify and justify than developing a standard for a specific use case.

OSGeo-Live 7.0 Released

The OSGeo-Live geospatial software collection version 7.0 has been released, featuring more than sixty open source, standards compliant geospatial desktop applications, web applications and frameworks. A complete installation kit and high-quality sample data in multiple industry standard formats are included. The OSGeo Live will be officially launched at FOSS4G 2013 in Nottingham, UK, 17-21 September, 2013.

Release Highlights

Projects new to this release include:

• GeoNode -- a web-based application and platform for developing geospatial information systems (GIS) and for deploying spatial data infrastructures (SDI)
• Leaflet -- a modern, open source JavaScript library for mobile-friendly interactive maps
• ncWMS -- a Web Map Service (WMS) for geospatial data stored in CF-compliant NetCDF files
• netCDF dataset -- daily maximum temperature and rainfall, worldwide

All geospatial applications on the disc have been updated to their latest stable releases.

About OSGeo-Live

OSGeo-Live is a self-contained bootable DVD, USB flash drive and Virtual Machine based upon Ubuntu Linux (version 12.04 LTS). OSGeo-Live is pre-configured with a wide variety of robust open source geospatial software. All applications can be trialled without installing anything on your computer, simply by booting the computer from a DVD or USB drive, or running in a Virtual Machine environment. Each featured package is accompanied by both a publication quality one page descriptive summary and a short tutorial on how to get started using it.

• http://live.osgeo.org

OSGeo-Live includes:

• Over sixty quality geospatial Open Source applications installed and pre-configured
• Free world maps and geodata
• One page overview and quick start guide for every application
• Overviews of key OGC standards
• Translations to multiple languages

Credits

Over 160 people have directly helped with OSGeo-Live packaging, documenting and translating, and thousands have been involved in building the packaged software.
Packagers, documenters and translators include:
Activity Workshop, Agustín Dí­ez, Aikaterini Kapsampeli, Alan Beccati, Alan Boudreault, Alessandro Furieri, Alexander Bruy, Alexander Kleshnin, Alexander Muriy, Alexandre Dube, Alexey Ardyakov, Alex Mandel, Amy Gao, Andrea Antonello, Andrea Yanza, Andrey Syrokomskiy, Andry Rustanto, Angelos Tzotsos, Anna Muñoz, Antonio Falciano, Anton Novichikhin, Anton Patrushev, Argyros Argyridis, Ariel Núñez, Assumpció Termens, Astrid Emde, Barry Rowlingson, Benjamin Pross, Brian Hamlin, Bruno Binet, Cameron Shorter, Christophe Tufféry, Christos Iossifidis, Cristhian Pin, Damian Wojsław, Dane Springmeyer, Daniel Kastl, Daria Svidzinska, David Mateos, Denis Rykov, Diego González, Diego Migliavacca, Dimitar Misev, Dmitry Baryshnikov, Dominik Helle, Edgar Soldin, Eike Hinderk Jürrens, Elena Mezzini, Eric Lemoine, Estela Llorente, Etienne Delay, Etienne Dube, Evgeny Nikulin, Fran Boon, François Prunayre, Frank Gasdorf, Frank Warmerdam, Friedjoff Trautwein, Gavin Treadgold, Giuseppe Calamita, Grald Fenoy, Grigory Rozhentsov, Guy Griffiths, Hamish Bowman, Haruyuki Seki, Henry Addo, Hernan Olivera, Howard Butler, Hyeyeong Choe, Ian Edwards, Ian Turton, Ilya Filippov, Jackie Ng, Jan Drewnak, Jane Lewis, Javier Rodrigo, Javier Sánchez, Jesús Gómez, Jim Klassen, Jing Wang, Jinsongdi Yu, Jody Garnett, Johan Van de Wauw, John Bryant, Jorge Arévalo, Jorge Sanz, José Antonio Canalejo, José Vicente Higón, Judit Mays, Klokan Petr Pridal, Kristof Lange, kuzkok, Lance McKee, Lars Lingner, Luca Delucchi, Lucía Sanjaime, Mage Whopper, Manuel Grizonnet, Marc-André Barbeau, Marco Curreli, Marco Puppin, Marc Torres, Margherita Di Leo, Maria Vakalopoulou, Mario Andino, Mark Leslie, Massimo Di Stefano, Mauricio Miranda, Mauricio Pazos, Maxim Dubinin, Michaël Michaud, Michael Owonibi, Micha Silver, Mike Adair, Milena Nowotarska, M Iqnaul Haq Siregar, Nacho Varela, Nadiia Gorash, Nathaniel V. Kelso, Ned Horning, Nobusuke Iwasaki, Oliver Tonnhofer, Òscar Fonts, Otto Dassau, Pasquale Di Donato, Patric Hafner, Paul Meems, Pavel, Pedro-Juan Ferrer, Pirmin Kalberer, Raf Roset, Ricardo Pinho, Roald de Wit, Roberta Fagandini, Roberto Antolin, Roberto Antolí­n, Roger Veciana, Ruth Schoenbuchner, Samuel Mesa, Scott Penrose, Sergey Grachev, Sergio Baños, Simon Cropper, Simon Pigot, Stefan A. Tzeggai, Stefan Hansen, Stefan Steiniger, Stephan Meissl, Steve Lime, Thierry Badard, Thomas Baschetti, Thomas Gratier, Tom Kralidis, Toshikazu Seto, Trevor Wekel, Valenty González, Vera, Xianfeng Song, Yoichi Kayama, Zhengfan Lin

Sponsoring organisations

• The Open Source Geospatial Foundation OSGeo provides the primary development & hosting infrastructure and personnel for the OSGeo-Live project, and infrastructure for many of the software projects themselves.
• LISAsoft provides sustaining resources and staff toward the management and packaging of software onto the Live DVD. http://www.lisasoft.com
• Information Center for the Environment (ICE) at the University of California, Davis provides hardware resources and development support to the OSGeo Live project. http://ice.ucdavis.edu
• Remote Sensing Laboratory at the National Technical University of Athens, provides hardware resources and development support to the OSGeo-Live project. http://www.ntua.gr
• The DebianGIS and UbuntuGIS teams provide and quality-assure many of the core packages. http://wiki.debian.org/DebianGis and https://wiki.ubuntu.com/UbuntuGIS

Open Geospatial Consortium - Reloaded

One of the valuable qualities I've observed of the Open Geospatial Consortium (OGC) during the past decade, is the extent to which they embrace feedback and constructive criticism and search out innovated ways to improve themselves. We are currently seeing another example of this following heated debate which resulted in the withdrawal of the "GeoServices REST API" as a proposed standard. The debate highlighted divided opinions around the primary purposes of standards, what should constitute a standard, and whether OGC and sponsors should be placing a greater emphasis on quality over quantity.
This has been the first time that there has been so much contention around a proposed standard, and I'd argue that it is an indication that the OGC has reached a threshold moment. Spatial Data Infrastructures around the world have been moving from pilots and non-core systems into central mission critical infrastructure. This in turn has impacted government policy, business models, and requirements of OGC standards.
In response, the OGC has reached out to OGC membership to help re-define the OGC. Mark Reichardt , President and CEO of the OGC, called on OGC membership to help redefine and strengthen the OGC:

... I have asked Geoff Zeiss and Jack Pellicci from our board to join me in establishing a leadership group to solicit your ideas and concerns, and to produce a slate of recommendations for action within 90 days. If you have an interest in working with us as part of this group to represent the interests of the OGC membership please contact me as soon as possible. An online forum will also be created to provide an open and accessible environment for members and the public to participate. We will be setting up a series of online meetings in the coming weeks, with a first meeting scheduled on 2 July for OGC members only. Registration details can be found here. A meeting open to the public will be scheduled for 11 July with several follow-up sessions for members and the public planned for late July and early September. We’ve also set up a wiki and email address to receive your feedback. My commitment is to have resulting recommendations brought to OGC membership, staff and the OGC Board of Directors for action as part of our upcoming September TC/PC meetings in Frascati, Italy. ...

So what should be on the OGC agenda? I suggest:

• Consider redirecting OGC sponsorship to provide a greater emphasis on Quality over Quantity. In particular, improve criteria for understandability through better documentation, improve testing frameworks, ensure robust implementations are in place before declaring a standard production ready.
• As governments around the world start embracing Open Government principles, they will find they need to take greater responsibility for protecting the principles of Open Government, and be empowered and confident enough to write something like this statement, and help take a leadership role within the OGC.
• Revisit the definition of an Open Standard, and ensure it meets the goals of SDI champions (primarily governments).

OGC heed community pressure regarding "GeoServices REST API"

Following on from signification discussion and concern from OSGeo and OGC communities, members of the OGC have withdrawn the "Geoservices REST API" candidate OGC standard.
Thank you to all the people who have voiced their concerns, thank you to those who provided detailed reasoning and analysis, and thank you to the OGC and OGC members who have acknowledged and have started actioning this reasoning. You are contributing toward a better OGC for us all.

---

Carl Reed, CTO and Executive Director of OGC Standards Program made the following announcement:

On Tuesday of this week, the GeoServices REST API Standards Working Group (SWG) voted to approve the following recommendation to the TC Voting Members:

The GeoServices REST SWG recommends the Technical Committee (TC) approve withdrawal of the motion to approve the OGC GeoServices REST API documents as an official OGC standard.

Moved: Keith Ryden. Second: Clemens Portele. There was no objection to unanimous consent.
The following is the reason for requesting the motion to approve the candidate standard be withdrawn:

“Considering the breath of discussion both internal and external to the OGC process since the vote announcement, the SWG members feel that the vote cannot continue until the many questions raised have been addressed. Issues regarding OGC process, vendor advantage, duplication of capabilities, etc. have now overshadowed technical discussions of the merits of the specification. By withdrawing the OGC GeoServices REST API candidate standard, the necessary discussions regarding OGC process, policy, and position can continue separately.”

The SWG further discussed the need for OGC Members and staff to debate, clarify and potentially amend a number of policy and procedural issues before the SWG can decide to either disband or to resume technical work on the candidate standard.
Today or tomorrow the TC Chair (me) will be asking the TC Voting Members to consider the GeoServices REST API SWG recommendation. The motion is:

"The GeoServices REST API SWG recommends that the GeoServices adoption vote be withdrawn.  If there is no objection to unanimous consent in the next 10 calendar days, then the motion is approved. If there are objections, than a two week e-vote will be initiated."

Over the coming months there will be opportunities for OGC staff, members and the general public to engage in discussions related to policy and procedures, such as clear statements on openness and interoperability, overlapping standards, backwards compatibility and so forth. The idea is to begin a dialogue as part of the virtual meetings this and next month with a goal to address the issues raised and recommend changes at the upcoming September Frascati meetings.
I would like to thank the SWG for all of their hard work on the candidate standard. I would also like to thank everyone who contributed to the conversation.

Will OGC’s standards meet government purchasing guidelines?

In what has become the Open Geospatial Consortium’s (OGC) most contentious vote to date, OGC members are being asked whether the proposed "Geoservices REST API" should be accepted as an OGC standard. A summary of concerns is listed in an Open Letter from the Open Source Geospatial Foundation (OSGeo) to the OGC. However, the crux of contentions hinges around the definition of an Open Standard and whether the "Geoservices REST API" qualifies as one.
When measured against government’s policy drivers of interoperability, fair competition, and economical use of government funds, the evidence is overwhelming. "Geoservices REST API" fails on all accounts. In fact, we should be questioning why our OGC processes haven’t identified and then addressed these issues much earlier.

Background

As background, the "Geoservices REST API" describes the interface to a dominant vendor’s web service (ESRI’s ArcGIS Server), and overlaps substantially with OGC’s existing suite of web service standards.

What is an Open Standard?

Most government purchasing guidelines, such as the United Kingdom Open Source, Open Standards and Re­Use: Government Action Plan, now include clauses such as:

The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.

Consequently, government contracts typically specify use of standards when purchasing systems. This places a responsibility on standards organisations to protect government policy when selecting and defining the standards baseline.
Superficially, the "Geoservices REST API" meets the European Interoperability Framework minimal definition of a standard:

• The standard is adopted and will be maintained by a not-for-profit organisation, and its ongoing development occurs on the basis of an open decision-making procedure available to all interested parties (consensus or majority decision etc.).
• The standard has been published and the standard specification document is available either freely or at a nominal charge. It must be permissible to all to copy, distribute and use it for no fee or at a nominal fee.
• The intellectual property - i.e. patents possibly present - of (parts of) the standard is made irrevocably available on a royalty-free basis.
• There are no constraints on the re-use of the standard.

However, the "Geoservices REST API" falls short of addressing government policy drivers for the creation of standards. These are summarised in the Guideline on Public Procurement of Open Source Software, written for the European Commission:

Public sector consumers of software have an obligation to support interoperability, transparency and flexibility, as well as economical use of public funds. When it comes to public procurement, the principles applied to the public sector require them to support (and certainly not to harm) competition through their procurement practices.
Good practice eGovernment services should provide access based on open standards, and in particular, never require citizens to purchase or use systems from specific vendors in order to access public services: this is equivalent to granting such vendors a state-sanctioned monopoly.

Let's address these issues point by point.

Costs and Interoperability

Regarding when to create new standards, the United States Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software has the following advice:

... use/modify/create open standards, in that order.

Unfortunately, the "Geoservices REST API" would create new standards rather than use and/or extend existing OGC web services. Emphasis on reuse of standards is important for increasing interoperability, as duplication of standards typically results in:

1. Implementation costs to support multiple standards increases.
2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
3. Sponsors (such as governments) who require compliance with standards will discover that applications don't communicate together, due to applications supporting different standards that essentially do the same thing.
4. After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one prefered standard for all agencies to follow. To date, the OGC has provided this leadership.
5. One standard taking prominence 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.

Costs increase, interoperability decreases.

Fair competition

ESRI’s ArcGIS Server is currently the only server which provides a full implementation of the "Geoservices REST API", as you would expect when an API is derived directly from a product. As such, if the "Geoservices REST API" were to be included in the OGC baseline, and government contracts continue to reference the OGC baseline in contracts, then governments would be giving one vendor a significant market advantage while other vendors wear the cost of developing matching implementations for the proposed standard.
Further, ESRI may continue to use its market dominance to promote use of the "Geoservices REST API" at the expense of existing OGC web services. (As described in ArcGIS Server documentation, support for OGC’s W*S services are disabled by default while GeoServices REST and KML are enabled).

Where are the Open Source implementations?

Another test for identifying open standards is defined by the United States Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software:

Verify that the standards used are open; a simple test for openness is to determine if the standard is implemented by open source software.

Currently, very little open source has been developed to support the "Geoservices REST API" and there is wide opposition to the proposed standard from the Open Source community.
Open Source implementations referenced by proponents of the "Geoservices REST API" include immature implementations, partial implementations and a library application. That is: a roadmap document for GeoServer, a sandbox implementation of an Openlayers client, a 52North SOS extension to ArcGIS Server and the GDAL translation library.
By comparison, there are multiple production-grade, client and server, open source implementations, which cover the full breadth of existing OGC standards, which have matured over the past decade, and there are open source reference implementations for most (all?) current OGC standards.
So by the Open Technology Development definition, The "Geoservices REST API" hasn’t yet reached the maturity of an Open Standard.

Where are OGC’s gatekeepers?

There are 481 OGC members, with close to 100 of them with voting privileges, yet regularly, less than 40% of these voting members actually vote on proposed standards. This is a concern if these members are being relied upon to uphold OGC values, and we should question why voting is so low. A key factor in low voter turnout is likely the complexity and volume of material voters need to understand in order to make an informed decision. Gatekeepers just don’t have the time to be abreast of all the issues, and current standards are hard to read. The increase in the breadth and application of OGC standards has led to a stronger need for integration of standards, architectural overviews, and clearer implementation guidelines.
Maintaining and verifying quality best addressed by defining and following development and validation processes, and OGC processes should be improved to match the complexity of the systems they represent. In particular, OGC should revisit goals and requirements for quality standards, then resource technical writers and reviewers to work against such requirements. Approving a standard is therefore simplified to verifying the process is valid and has been followed. This would require OGC sponsorship priorities changed to provide greater emphasis on quality over quantity of standards.

A blueprint for moving forward

Let's expand on the steps involved in deciding on the value of a standard:

1. Governments policies should embody government best practices. Many countries have already taken this initiative.
2. Standards organisations should embrace such government policies.
3. A clear definition of an "open standard" is required, which addresses government policy requirements of interoperability, fair competition, free access to government services, and economical use of public funds. This should be expanded into clear guidelines to be applied by OGC Gatekeepers and standards developers. The OGC should revisit the "open standards" definition, and in particular, ensure the definition extends beyond the technical to include policy implications.
4. Suitable training should be available to OGC Gatekeepers and implementers of OGC based solutions.
5. The OGC and OGC sponsors should consider realigning priorities. In particular:

• Place a greater emphasis on quality over quantity of standards. This includes: harmonising competing standards, improving quality of writing to support understandability and implementability, and extend testing to verify standards are implemented correctly.
• Provide simple and clear descriptions of standards. The OSGeoLive project has addressed similar issues by providing a concise one-page project overview, plus a ten-minute quickstart, translated into 11 languages, for fifty of the best geospatial open source applications.

Summary

As the success of the OGC increases, the OGC will need to be mindful of business and policy implications associated with adopting established interfaces as standards. Specifically, accepting the currently proposed "Geoservices REST API" as a standard will have detrimental impacts on interoperability, fair competition, and economic use of public funds. Instead, the positive aspects of the "Geoservices REST API" should be harmonised and incorporated into the existing OGC baseline of standards. Also, as the breadth of technology covered by OGC standards increases, it is becoming more difficult for gatekeepers to monitor the quality of these standards and consequently it is becoming more important to focus on quality and understandability of these standards. In moving forward, the OGC membership should revisit OGC priorities, and consider placing a greater emphasis on quality over quantity.

Post Note

As a result of this, an open letter, and many other objections, the Geoservices Rest API was withdrawn from being considered as an OGC standard, as described here. The OGC then initiated an Ideas4OGC review, to rebaseline OGC priorities and processes in order to address weaknesses that had been identified in OGC processes.

Starting build cycle for OSGeo-Live 7.0

We are starting the build cycle for the 7.0 OSGeo-Live DVD/USB/VM which will be released in September 2013, ready for the global FOSS4G conference in Nottingham, UK. We would like to hear from anyone wishing to add new projects to the live DVD, anyone wishing to extend or add extra translations, or anyone who has ideas on how we should shape the upcoming release.
Also, could all projects please reply to us with which stable version of their software should be included in this release.

Key Milestones

17 Jun 2013 All new applications installed, most old applications updated

15 Jul 2013 Feature Freeze (all apps updated)

05 Aug 2013 User Acceptance Test (all apps installed and working)

26 Aug 2013 Final ISO sent to printers

... full schedule

OSGeoLive 7.0-alpha1 released

We have released the first alpha version of OSGeo-Live, which includes an update from Xubuntu 12.04 to 12.04.2 along with updated versions of applications from UbuntuGIS repository. Feel free to start testing your applications in the latest release. Download Alpha 1

About OSGeo-Live

The OSGeo Live demo DVD/VM/USB is an Xubuntu based distribution of Geospatial Open Source Software, available via a Live DVD, Virtual Machine and USB. You can use it to try a wide variety of open source geospatial software without installing anything.

Last chance to reject "Geoservices REST API" standard

Next Wednesday, the OSGeo Board will deliver an Open Letter to the OGC and OGC voting members, with multiple signatures, demonstrating the large number of people concerned about the negative consequences associated with making the "Geoservices REST API" an OGC standard.
The "GeoServices REST API" was initially developed by ESRI and implemented on the ArcGIS Server platform before going through the OGC process. It significantly overlaps with OGC's existing W*S services, but isn't based upon these existing standards.  Consequently, we have grave concerns that the two competing sets of standards, which essentially cover the same use cases, will have far reaching, detrimental impacts on interoperability, complexity, and costs within the spatial industry, including being bad for Geospatial Open Source software.

Many people, including leaders of OSGeo and related communities, have already signed this letter. Thankyou. If you agree that "Geoservices REST API" will be bad for OSGeo and/or the greater spatial community, then please help us deliver this concern to OGC voters before they vote. Add your signature to the Open Letter before we deliver it on Wednesday 15 May 2013, and forward this message onto other OSGeo communities. (I notice that messages from this thread are being forwarded to the Spanish OSGeo email list. Thankyou.)

If you are looking for a deep analysis of the issues, I suggest reading the open letter which is now draft complete: http://wiki.osgeo.org/wiki/Geoservices_REST_API.

Design Principles of UK Government Digital Services

The UK Government have defined excellent design principles for deploying digital services, which is broadly applicable, and should be considered, by anyone developing applications for the web. They are summarised below:

1. Start with [user] needs
   ...
2. Build digital services, not websites
   Our service doesn’t begin and end at our website. It might start with a search engine and end at the post office. We need to design for that, even if we can’t control it. And we need to recognise that some day, before we know it, it’ll be about different digital services again.
3. Do less
   Government should only do what only government can do. ... We should concentrate on the irreducible core.
4. Design with data
   ... we can learn from [current] real world behaviour. ...
5. Do the hard work to make it simple
   Making something look simple is easy; making something simple to use is much harder — especially when the underlying systems are complex — but that’s what we should be doing.
6. Iterate. Then iterate again.
   The best way to build effective services is to start small and iterate wildly. Release Minimum Viable Products early, test them with real users, move from Alpha to Beta to Launch adding features and refinements based on feedback from real users.
7. Build for inclusion
   ...
8. Be consistent, not uniform
   ...
9. Make things open: it makes things better
   We should share what we’re doing whenever we can. With colleagues, with users, with the world. Share code, share designs, share ideas, share intentions, share failures. The more eyes there are on a service the better it gets — howlers get spotted, better alternatives get pointed out, the bar gets raised.
   Partly because much of what we’re doing is only possible because of open source code and the generosity of the web design community. So we should pay that back. But mostly because more openness makes for better services — better understood and better scrutinised. If we give away our code, we’ll be repaid in better code. That’s why we’re giving away all this...

OSGeo Board priorities

A productive virtual meeting of the OSGeo Board resulted in general consensus over OSGeo's priorities, which in turn should help the OSGeo Board and OSGeo committees when guiding OSGeo into the future.
These principles are:

• OSGeo should act as a low capital, volunteer focused organisation.
• OSGeo should focus support on OSGeo communities and initiatives which support themselves.

Current priority areas include:

• Global, regional and local FOSS4G related events, or events which include a FOSS4G stream.
• Marketing OSGeo, which is currently focused around OSGeo-Live.
• Education, which is currently focused around the network of Open Source Geospatial Research and Education Laboratories.
• Local Chapters, as outreach initiatives are typically driven at the local level.

So lets expand on these:

OSGeo as a low capital, volunteer focused organisation

Should OSGeo act as a high capital or low capital organisation? I.e., should OSGeo dedicate energy to collecting sponsorship and then passing out these funds to worthy OSGeo causes.
While initially it seems attractive to have OSGeo woo sponsors, because we would all love to have more money to throw at worthy OSGeo goals, the reality is that chasing money is hard work. And someone who can chase OSGeo sponsorship is likely conflicted with chasing sponsorship for their particular workplace. So in practice, to be effective in chasing sponsorship, OSGeo will probably need to hire someone specifically for the role. OSGeo would then need to raise at least enough to cover wages, and then quite a bit more if the sponsorship path is to create extra value.
This high capital path is how the Eclipse foundation is set up, and how LocationTech propose to organise themselves. It is the path that OSGeo started following when founded under the umbrella of Autodesk.
However, over the last seven years, OSGeo has slowly evolved toward a low capital volunteer focused organisation. Our overheads are very low, which means we waste very little of our volunteer labour and capital on the time consuming task of chasing and managing money. Consequently, any money we do receive (from conference windfalls or sponsorship) goes a long way - as it doesn't get eaten up by high overheads. As discussed and agreed by the board, this low capital path is something that is working very well for us, and is the path we should continue to follow.

Support initiatives which support themselves

With the thousands of great initiatives and opportunities that OSGeo could get involved in, and limited budget, how should OSGeo set funding priorities? Acknowledging that our volunteer community is blessed with many talented individuals, our most effective way to tap into community potential is to welcome individuals to "help scratch their itch". Extending on this, funding priorities should follow the actions of already successful communities. (Note the difference between "talk" and "action"). If a task or project is important enough, it will attract volunteers and/or sponsors to make it happen. In practice, this will usually equate to providing co-contributions rather than outright funding.
OSGeo's focus should be on initiatives which are of value to all or most OSGeo projects, and to get best value for our limited budget, OSGeo should target initiatives which have high value with minimal investment.
With that in mind our priorities should be:

• Cover the costs of running OSGeo: Bank fees, insurance, infrastructure, hosting etc.
• Support marketing and out reach activities, with a primary focus on our FOSS4G global conference, followed by regional and then local FOSS4G or related events.
• Educational type activities are a high priority, but likely will be a minimal cost activity from OSGeo's perspective.
• Other initiatives which fit our priorities, as suggested by membership.

Initiatives which probably wouldn't quality:

• Sponsoring core development of a particular project. (Too expensive, and only supports one project)
• OSGeo speaker travel expenses, or booth registration costs at a conference. (If conferences/local community feel this is important, they will either: 1. pay for the keynote, 2. make use of local talent, 3. waive fees for our non-profit, 4. find a local sponsor)

Conferences and related events

Conferences are financially risky events. They need to be planned well in advance, and you are never sure how many people will turn up, or whether some global event will have a substantial impact on registrations. Consequently, conferences such as FOSS4G require financial guarantees up front in order to secure a venue. To support and enable these conferences, OSGeo will endevour to retain sufficient capital to offer such guarantees for any FOSS4G event requesting it. If OSGeo's support is requested, then OSGeo would expect these events to budget for a modest profit under conservative estimates, and for OSGeo to retain profits from such events. To date, such profits, while relatively modest, have been OSGeo's primary income source.
Other spatial conferences regularly request an OSGeo involvement, such as providing presenters, workshops, OSGeo-Live DVDs for distribution, or providing a booth. OSGeo facilitates such requests to the level we can achieve with interested volunteers, but typically expects the conference or sponsors to cover expenses.
OSGeo has limited budget set aside for code sprints, which are seen as a valuable forum for giving directly back to development teams. OSGeo will typically expect co-contributions from interested sponsors, and would prefer to support code sprints which are of benefit to multiple projects and communities.

Education

OSGeo is very supportive of educational initiatives which is helping the spread of OSGeo to students across the globe. This is currently focused around the growing network of Open Source Geospatial Research and Education Laboratories within Universities around the world.
This educational initiative is currently progressing well without requiring OSGeo's financial support.

Packaging and Marketing

OSGeo's marketing effort has primarily been focused around the packaging and documentation efforts of OSGeo-Live, and to a lesser extend, osgeo4w. In 2012, OSGeo-Live was used at 45 events without OSGeo's financial support. It has been entirely driven by volunteer labour, by 140 OSGeo-Live volunteers, and printing costs have been covered by local events or sponsors.
In the last couple of years, OSGeo has covered local chapter expenses required to purchase non-consumable items for conference booths (such as a retractable banner).
In moving forward, OSGeo hope to extend marketing reach by providing co-contributions toward printing costs of consumable items at conferences, such as toward OSGeo-Live DVDs.

Local Chapters

Much of OSGeo's marketing initiates are applied at the local level. In many cases, this is best supported through as little as an email list and wiki page. OSGeo also supports local chapters by offering to pay for an Exhibition starter pack for local chapters. Local chapters are also usually the coordinators of conferences and related events, as mentioned above.

Sponsorship

OSGeo will continue to welcome sponsorship. Due to OSGeo's low capital model, we are able to make sponsor's contribution provide substantial benefit to the greater OSGeo community. In return, we promote sponsors' logos on our website and through our OSGeo-Live marketing pipeline (which was used at 45 geospatial events around the world in 2012).
However, OSGeo is doesn't plan to either task volunteers with specifically chasing sponsors, or hire someone to chase sponsorship on OSGeo's behalf.

Should OGC re-prioritise Quality over Quantity?

There is a constant tension in development between doing less, but doing it well, verses doing more with less attention to detail.
Recently members of the Open Source community have raised concerns about the quality of OGC standards, which leads to reduced uptake and effectiveness of these standards. This should be of concern to sponsors of OGC initiatives, and I'd suggest that the OGC, and OGC initiative sponsors should assess funding priorities, and place a greater emphasis on quality over quantity.
Here is a sample of a few recent comments:

• Daniel Morissette, board member of OSGeo, blogged: Don't upgrade to WMS 1.3.0 unless you have to, stick to 1.1.1.
• Chris Holmes, a prominent OSGeo thought leader, recently said: "we've found that in recent years there are even more 'ideas' added to the specifications that have no true production ready working code against them. Past the surface accessibility this is the thing that has become clear to us as implementors - there is less quality control at the core of the standards process."
• Chris quotes Justin Deoliveria, an experienced implementer of OGC standards as saying "... the geopackage spec makes me want to run for the hills".

In the last OGC OWS-9 testbed, LISAsoft was engaged as part of the CITE compliance program to test the WMS 1.3 client reference implementation. We are strong supporters of testing, but the scope of LISAsoft's recommended testing was substantially trimmed due to lack of budget. Consequently, the level of testing sponsored fell well short of what should be covered by a standards organisation. By acknowledging that testbeds like OWS-9 are vehicles for rapid prototyping, full compliance testing should probably be advanced into another forum.

Here is an exert of what we summarised in our wrap up Engineering Report:

The WMS 1.3 Client testing provided in this testbed is an excellent step forward, and is useful for checking integration between a specific WMS client and specific WMS server, however, the WMS 1.3 client testing falls short of providing comprehensive tests confirming that a client conforms with all WMS servers, under all conditions. As such, LISAsoft considers it inappropriate for the OGC to consider a WMS client to be certified as compliant based upon the level of testing sponsored to date.
For instance:

• Boundary testing was not sponsored: Can the client send a query which crosses maximum latitude or longitude lines? ... 
• Exception testing was not sponsored: Would the client perform suitably if the server provided a valid exception as a response? ...
• Sponsorship only covered testing of integration with one WMS service (which only supported a subset of the WMS spec). Testing the rest of the client's WMS support wasn't sponsored. ...

The recommendations from our report explain steps to bring OGC compliance testing in line with  best practices. However, they could be summarised by recognising that:

1. Quality of OGC standards is strategically important in reaching OGC goals.
2. Greater focus on testing is required if OGC wish to reach this level of quality.
3. Sponsors of OGC initiatives should adjust funding priorities to put a greater emphasis on quality over quantity.

OSGeo-Live 6.5 released

Version 6.5 of the OSGeo-Live GIS software collection has been released, ready for distribution at a large number of geospatial conferences and workshops from around the world.

Release Highlights

Applications

Geospatial applications on the disc have been updated to their latest stable releases.

Increased quality

With each release, the quality of OSGeo-Live is steadily increasing. This release has seen a concerted review of OSGeo-Live quickstarts, ensuring the every step of quickstarts have been tested, and increasing consistency and readability of the quickstart documentation.

Translations

OSGeo-Live is now translated into Russian. Translations are available for: Catalan, Chinese, English, French, German, Greek, Italian, Japanese, Korean, Polish, Russian (new), Spanish

About OSGeo-Live

OSGeo-Live is a self-contained bootable DVD, USB flash drive and Virtual Machine based upon Ubuntu Linux that is pre-configured with a wide variety of robust open source geospatial software. The applications can be trialled without installing anything on your computer, simply by booting the computer from a DVD or USB drive, or running in a Virtual Machine environment. An accompanying collection of lightning presentations introduces the breadth and depth of Free and Open Source for Geospatial (FOSS4G).
Homepage:

• http://live.osgeo.org

OSGeo-Live includes:

• Fifty (50) Quality Geospatial Open Source applications installed and pre-configured
• Over a gigabyte of free world maps and geodata
• One page overview and quick-start guides for every application
• Overviews of key OGC standards
• Translations for multiple languages

Credits

Over 140 people have directly helped with OSGeo-Live packaging, documenting and translating, and thousands have been involved in building the packaged software.
Packagers, documenters and translators include:
Activity Workshop, Agustín Dí­ez, Aikaterini Kapsampeli, Alan Boudreault, Alessandro Furieri, Alexander Bruy, Alexander Kleshnin, Alexander Muriy, Alexandre Dube, Alexey Ardyakov, Alex Mandel, Amy Gao, Andrea Antonello, Andrea Yanza, Andrey Syrokomskiy, Angelos Tzotsos, Anna Muñoz, Anne Ghisla, Antonio Falciano, Anton Novichikhin, Anton Patrushev, Argyros Argyridis, Assumpcio Termens, Astrid Emde, Barry Rowlingson, Benjamin Pross, Brian Hamlin, Bruno Binet, Cameron Shorter, Christophe Tufféry, Christos Iossifidis, Cristhian Pin, Damian Wojsław, Dane Springmeyer, Daniel Kastl, Daria Svidzinska, David Mateos, Denis Rykov, Diego González, Dimitar Misev, Dmitry Baryshnikov, Dominik Helle, Edgar Soldin, Eike Hinderk Jrrens, Elena Mezzini, Eric Lemoine, Estela Llorente, Etienne Delay, Etienne Dube, Evgeny Nikulin, Fran Boon, François Prunayre, Frank Gasdorf, Frank Warmerdam, Gavin Treadgold, Giuseppe Calamita, Grald Fenoy, Grigory Rozhentsov, Hamish Bowman, Haruyuki Seki, Henry Addo, Hernan Olivera, Howard Butler, Hyeyeong Choe, Ian Turton, Ilya Filippov, Jackie Ng, Jan Drewnak, Javier Sánchez, Jesús Gómez, Jim Klassen, Jing Wang, Jinsongdi Yu, Jody Garnett, Johan Van de Wauw, Jorge Arévalo, Jorge Sanz, José Antonio Canalejo, Judit Mays, Klokan Petr Pridal, Kristof Lange, kuzkok, Lance McKee, Lars Lingner, Luca Delucchi, Lucía Sanjaime, Mage Whopper, Manuel Grizonnet, Marc-André Barbeau, Marco Curreli, Marco Puppin, Marc Torres, Margherita Di Leo, Maria Vakalopoulou, Mario Andino, Mark Leslie, Massimo Di Stefano, Mauricio Miranda, Mauricio Pazos, Maxim Dubinin, Michaël Michaud, Michael Owonibi, Micha Silver, Mike Adair, Milena Nowotarska, Nacho Varela, Nadiia Gorash, Nathaniel V. Kelso, Ned Horning, Nobusuke Iwasaki, Oliver Tonnhofer, Oscar Fonts, Òscar Fonts, Otto Dassau, Pasquale Di Donato, Paul Meems, Pavel, Pedro-Juan Ferrer, Pirmin Kalberer, Raf Roset, Ricardo Pinho, Roald de Wit, Roberto Antolín, Roger Veciana, Ruth Schoenbuchner, Samuel Mesa, Sergey Grachev, Sergio Baños, Simon Cropper, Simon Pigot, Stefan A. Tzeggai, Stefan Hansen, Stefan Steiniger, Stephan Meissl, Steve Lime, Thierry Badard, Thomas Baschetti, Thomas Gratier, Tom Kralidis, Toshikazu Seto, Trevor Wekel, Valenty González, Vera, Xianfeng Song, Yoichi Kayama, Zhengfan Lin.

Sponsoring organisations

• The Open Source Geospatial Foundation OSGeo provides the primary development & hosting infrastructure and personnel for the OSGeo-Live project, and infrastructure for many of the software projects themselves.

• LISAsoft provides sustaining resources and staff toward the management and packaging of software onto the Live DVD. http://www.lisasoft.com
• Information Center for the Environment (ICE) at the University of California, Davis provides hardware resources and development support to the OSGeo Live project. http://ice.ucdavis.edu
• Remote Sensing Laboratory at the National Technical University of Athens, provides hardware resources and development support to the OSGeo-Live project. http://www.ntua.gr/index_en.html
• The DebianGIS and UbuntuGIS teams provide and quality-assure many of the core packages. http://wiki.debian.org/DebianGis and https://wiki.ubuntu.com/UbuntuGIS

Happy 7th Birthday OSGeo

Image Source

As reported by Jeff McKenna, The OSGeo Foundation has turned 7. And if you wish to understand why OSGeo software innovates so quickly, it is worth looking at these OSGeo statistics which hint at the size of the OSGeo community:

• 195 mailing lists
• unique mailing list subscribers: 19,160
• http://osgeo.org: 30,487 unique visitors for month of January 2013
• http://wiki.osgeo.org: 2720 pages, 12550 users, 17 million views to date
• 1,350,000 google hits for "osgeo"

OSGeo-Live Quickstart 48 hour Hackathon

Image Source

As announced, We are organising an "OSGeo-Live Quickstart 48 hour hackathon", aimed squarely at bringing OSGeo-Live documentation quality up one notch, by putting the Quickstarts through the same comprehensive testing and review that we have provided for our Project Overviews. (Credit to Javi and the OSGeo-Live Spanish community for suggesting the initiative).

The Hackathon will kick off with a one hour IRC meeting with everyone, followed by a 48 hour round the clock hangout, with people dropping in where appropriate for their timezone and work/family schedules.

Pre Hackfest:

• Download our current stable OSGeo-Live release from: http://osprey.ucdavis.edu/downloads/osgeo/gisvm/latest/

Kickoff:

• Log onto: irc://irc.freenode.net#osgeolive (details)
• Time: Thursday, 31 January 2013 at 19:30:00
• New York, USA: 2:30PM EST, Th 31 Jan
• San Francisco USA: 11:30AM PST, Th 31 Jan
• Sydney Australia: 6:30AM Fr 1 Feb
• Rome Italy: 8:30:00PM CET, Th 31 Jan
• Spain: 8:30:00PM CET, Th 31 Jan

Review process:

• http://wiki.osgeo.org/wiki/Live_GIS_Add_Project#Quickstart_Review_Checklist

Please let us know on the OSGeo-Live email list if you would like to join us, and we'll make sure to look out for you. Depending on numbers, we might also set up a Google Hangout. (Contact me if you want more details: cameron.shorter AT gmail .com)