Wednesday, 22 May 2013

Will OGC’s standards meet government purchasing guidelines?

In what has become the OGC’s 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 are listed in an Open Letter from the Open Source Geospatial Foundation (OSGeo) to the OGC. However, the crux of contentions hinge 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 OGC standards when purchasing spatial systems. This places a responsibility on the OGC and OGC members to protect government policy when selecting and defining the OGC 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.
Lets 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.
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

Lets 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. LISAsoft provides an Effective Software Selection course which closely aligns with such training requirements.
  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 OSGeo-Live 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.

Thursday, 16 May 2013

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.

Monday, 13 May 2013

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.

Wednesday, 20 March 2013

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

Monday, 4 March 2013

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.

Thursday, 28 February 2013

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.


Wednesday, 27 February 2013

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

Tuesday, 5 February 2013

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"

Wednesday, 30 January 2013

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:
Kickoff:
Review process:
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)

Monday, 10 December 2012

Geospatial Open Source Lightening Overview

Here is a 25 minute lightening overview of the Geospatial Open Source stack, presented at the Open Source Developers Conference in Sydney, Australia. It is a cut down version of the OSGeo-Live Lightening Overview (which now takes ~ 40 minutes). For more details, refer to the OSGeo-Live Project Overviews and LISAsoft training from which this presentation was derived.

Tuesday, 30 October 2012

Starting build cycle for OSGeo-Live 6.5

Grass on OSGeo-Live
We are starting the build cycle for the 6.5 OSGeo-Live DVD/USB/VM which will be released in March 2013, ready for the FOSS4G - North America, Spanish FOSS4G, FOSSGIS Germany, among others. We would like to hear from anyone wishing to add new projects to OSGeo-Live, 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 on OSGeo-Live 6.5.

Key Milestones

  • 10 Dec 2012 All new applications installed, most old applications updated 
  • 24 Dec 2012 Feature Freeze (all apps updated) 
  • 28 Jan 2012 User Acceptance Test (all apps installed and working) 
  • 18 Feb 2012 Final ISO sent to printers
... full schedule

OSGeo-Live 6.5 Alpha1 released

We have released the first alpha version of OSGeo-Live, which includes an update from Xubuntu 12.04 to 12.04.1 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.

Monday, 17 September 2012

Will Australia's CRCSI "Spatial Infrastructure" research see the light of day?

CRCSI Focus: http://www.crcsi.com.au/Research
Australia's Cooperative Research Centre for Spatial Infrastructures, CRCSI, has announced its research agenda for Spatial Information in a series of workshops around Australia, and in Sydney the presentation was met with a sceptical audience.
The CRCSI have $180 million worth of research budget, and "Spatial Infrastructure" represents 1/3 of the CRCSI's core agenda, and as such there is the potential to make some great contributions to Spatial Infrastructure. So why were the audience sceptical?
This is the second 7 year CRCSI agenda. In the first there was a feeling that many of the research projects did not follow through into practical implementations. As such, the bid for this second CRCSI emphasised a changed focus toward practical research. However audience sentiment was that the recent research proposed would not see the light of day. Here are some of the reasons why:

Lack of collaboration with Spatial Infrastructure champions

The Open Geospatial Consortium (OGC) is the leading international body coordinating research, development and testing of the standards which back Spatial Infrastructure. I would ague that for a research program to be of value, it needs to advance OGC standards. However, CRCSI's current agenda mentions only the use of existing standards.
Australia's Commonwealth Scientific and Industrial Research Organisation, CSIRO, are already world leaders in spatial research, having led development of a number of Spatial Initiatives and standards developments in conjunction with the OGC. In particular, CSIRO are currently leading the world in research into  Ontologies, Linked Data, and Catalogs which has many synergies with the the Australian and New Zealand Spatial Marketplace being promoted as a focus for the CRCSI's research agenda. However the CRCSI strategy has no mention of collaboration with CSIRO and seems to be proposing to solve similar problems themselves. Long term, this will result in the technology behind the Marketplace becoming obsolete as the rest of the world pick up and mature CSIRO's research, while Australian/New Zealand will be solely left to maintain the Marketplace.

Gap between Research and Implementation

There were serious concerns raised by both industry and government audience members about the usefulness of any research likely to be generated. You see, most of the pressing (and expensive) Spatial Infrastructure problems needing to be solved are found in the integration of systems. However, the CRCSI seem to have abdicated responsibility for tacking these hard problems, as they don't constitute "research". What would be preferable is that the success of research be judged by whether it has been integrated into Spatial Infrastructure software and processes, not by the earlier stage of being published in an academic journal.

What should the CRCSI do instead?

If the CRCSI is to heed the feedback from the Sydney meeting, the CRCSI will tackle less research topics, but will take these topics right through to implementation. The CSCSI will engage deeply with the OGC, probably leading a stream in an OGC testbed or pilot. The CRCSI would also work closer with the CSIRO and collaborate on initiatives.

Saturday, 25 August 2012

OSGeo Board and Charter members refreshed

The annual OSGeo Board of Directors and Charter Membership elections have come to a close with the first meeting of the new board, and the selection of a new executive. During the process 22 new charter members were added bringing this group to 144 charter members from around the world. During the Board of Directors election, the following new board members were elected for a two year term:

Jáchym Čepický (Czech Republic) has been welcomed onto the board for a one year term to complete Jo Cook's term who stepped down just before the elections.
These new board members will join existing members, Peter Batty (United States), Michael Gerlek (United States), and Mark Lucas (United States).

The new board is pleased to announce the following executive:
  • President: Frank Warmerdam
  • Treasurer: Daniel Morissette
  • Secretary: Michael Gerlek
As the new President of OSGeo, Frank Warmerdam brings many years of geospatial experience and has been involved in the OSGeo foundation since its inception. He is known for his work with the GDAL/OGR translation library, which has become the backbone of the spatial industry. Daniel Morissette is continuing the role of Treasurer and brings practical experience as a business owner to this key role as well as over a decade of experience as a technical contributor and community leader in the MapServer project and OSGeo. Michael Gerlek is returning to the role of Secretary and brings a passion for supporting OSGeo both locally and globally.

About his new role as OSGeo President Frank Warmerdam says, "OSGeo has a fantastic set of volunteers, projects and an energized board and I believe we can continue to move forward on many fronts in the coming year. I can't thank Arnulf Christl, our past president, enough for his tireless work. While I can't fill his shoes as a globe trotting speaker on behalf of OSGeo, I believe we can as a community continue to be everywhere."

Wednesday, 22 August 2012

Analysing the downfall of FOSS4G 2012

The international FOSS4G 2012 conference, which was scheduled to be held in Beijing in Sept 2012, was cancelled. This has been a disappointing setback for our OSGeo community, and here I capture some of the key events which lead up to this cancellation, and with our hind site perspective, identify areas we can change to make future conferences more resilient and successful.
This conversation started on the OSGeo Conference email list, then moved to the FOSS4G 2012 Lessons Learned wiki page as ideas consolidated.
The following discussion ground rules applied:
  • Avoid letting the discussion break into a witch hunt, or blame game. Remember that almost all people involved in FOSS4G 2012 were volunteers, giving of their precious time freely.
  • Instead, identify an event or decision, discuss the implications of the event, and ideally follow up with some recommendations on what we can do in future. 

Host City Selection

Prior to 2012, OSGeo's Conference Committee had agreed to a 3 year rotation for the location of FOSS4G conferences, which went:
  • Europe (2010)
  • North America (2011)
  • Rest of the world (2012)
  • Europe ...
The bid process involves cities providing a light, 2 page, "Letter of Intent", followed by a comprehensive bid if the "Letter of Intent" was approved. However by Letter of Intent deadline for FOSS4G 2012 there were no Letters of Intent. The deadline was extended, and Letters of intent were received from Rome (Europe), Prague (Europe), Hanoi (Asia), and a late entry from Beijing (Asia).
This was summarised by OSGeo Conference chair,
What happened is that we did not receive any submissions before the initial deadline, and then we opened the bidding to all areas, and then we received 1 submission from the desired region and 2 from Europe, and then a second late submission from the desired region.
My opinion is that the stated desired region is in fact still the desired region, and that all OSGeo conference committee members should keep this information in their head as they vote. (meaning: all 4 letters are an option for this voting stage, but the preferred region is 'anywhere other than NA or Europe')
In the end, only Prague [Europe] and Beijing [desired region] submitted a full FOSS4G bid, and when it came to a final vote, the OSGeo Conference committee was split between a bid from a more experienced team in Prague, and following OSGeo's established rotation with Beijing. In retrospect, we should have put more emphasis on selecting the experienced FOSS4G team.
European and North American international FOSS4G events have traditionally attracted more delegates and sponsors, which makes these conferences:
  1. More financially profitable
  2. Less financially risky
  3. Reach more people (although not necessarily reaching more regions)
As we move forward, we may wish to favour selection of committees and cities with prior experience of holding local or regional FOSS4G events before being awarded an international event.

Competing regional conferences

In 2011, major regional conferences started in both Europe and North America, which competed for international FOSS4G attendance, along with some FOSS4G conferences from the region. It was debated whether OSGeo should support and encourage these new regional conferences, knowing that they would have an impact on attendance at Beijing.
As explained in a post by the Chair of the OSGeo Board:
From all that I can tell, now FOSS4G Beijing will become a local conference with support from "OSGeo international". This and no more. It will not be the Global or World conference that FOSS4G was before because we will have a FOSS4G CEE and FOSS4G North America event (plus the regular local ones) in the same year. There is no chance at all that Beijing can attract the same vibrant global participation that we had at the last global FOSS4G conferences.
The question is not whether we will have a FOSS4G in Beijing or CEE or North America. From all that I can tell we will have them all. There is no reason (and probably no way) to stop the North American or CEE initiative or both. Instead it is great to see so much interest and momentum - and we would be stupid to stifle it.
The competing regional conferences are listed here and here.

Local Organising Committee experience

Lack of Professional Conference Organiser

The Local Organising Committee (LOC) had teamed with a Professional Conference Organiser (PCO), starting from the bidding for the FOSS4G 2011 conference. However, it seems that at some point the PCO stopped helping with FOSS4G. The LOC were then unsuccessful in trying to sign up a new PCO. This was a significant setback for FOSS4G 2011, as PCO's bring significant experience in running a conference. They have experience with local venues and business, and they manage many of the day-to-day tasks which takes workload off the LOC.
From what I can gather, the PCO were not contractually engaged with the PCO up front, which allowed them to disengage later. What are the lessons? The LOC should contractually engage with the PCO very early in the conference cycle, and OSGeo oversight should ensure this happens.

Loosing key LOC members

One of the key Chinese OSGeo community members, Professor Yu, passed away shortly after Beijing was awarded the conference. This was very unfortunate, both on a personal level, and organisation level.
Loss of key committee members is reasonably common (although usually people step down for various reasons, rather than pass away). For instance, a key FOSS4G-Sydney evangelist, who promoted the Sydney event at prior FOSS4G conferences, stepped back and didn't attend Sydney's FOSS4G 2009. The original FOSS4G-Devar 2011 chair had to stand down for personal reasons shortly after the bid was accepted. These examples highlight the need for organizing committees to have strength in depth, and in particular to have a backup plan if the conference chair has to step down. This was a question that was asked of the Nottingham FOSS4G 2013 contenders, who have two backups to the conference chair, as well as a committee with strength in depth overall.

Decision Making

A conference chair is asked to make many decisions related to the conference, and the majority of the time, there is no clear understanding about the benefits or downsides of each option. Usually the only sure thing is that not making a decision will be detrimental to the conference. Consequently, it is important for LOCs to become quick and efficient at analyzing possibilities and then making decisions.
From what I can gather, the Beijing LOC would have benefited from being more efficient in making decisions. For instance, in mid-November 2012 the OSGeo-Live community asked the LOC to commit to distributing OSGeo-Live DVDs at the Beijing conference. The LOC took almost 3 months to confirm they would support this. Other conferences usually provide such confirmation within a week, often within a day or two.
I suspect delays related to decisions would have contributed to schedule slipages. The lesson here is that LOC's should be structured and resourced such that they can make decisions efficiently. A prior conference chair extended this observation to note the importance of the conference chair:
[A key lesson is the] importance of an active LOC and even more importantly an active CHAIR. Committees don't move, they can't communicate, they can't move. People can, so an active CHAIR is the single critical ingredient. And the more that person in invested in both organizing and communicating the event, the better it will be.

Schedule slip

As the deadline for the FOSS4G conference approached, there was significant schedule slip on key milestones, such as the ability to accept conference papers. This was providing a visible indication of some of the other issues listed in this analysis.
I think the lesson here is quite simple. Make sure there is an appropriately resourced project manager responsible for managing the conference schedule. (This task is usually provided by a PCO).

OSGeo Oversight

A second issue is that although OSGeo had identified concerns with FOSS4G Beijing's progress reasonably early, intervention from OSGeo was late in coming. A prior FOSS4G chair noted:
We need to put harder stops in place to short circuit failure. If you don't have a call for workshops out by February, [serious questions are asked, such as should the conference be cancelled?]. If you don't have $30K in sponsorship in place by April, [serious questions]. If you don't have a call for papers out by May, [serious questions]. This [FOSS4G 2012 conference] dragged out longer than it should of because there were no hard stop points.
During the build up to FOSS4G Beijing, one of the key volunteers on OSGeo conference committee, who had previously been very active, was showing signs of burnout and was not contributing to his prior levels. This left a noticeable hole in the OSGeo conference committee which was not filled by another volunteer. The OSGeo Conference committee had previously provided checks on conferences, such as reviewing and approving the conference's budget and submitting to the OSGeo board for approval, however this didn't happen for the FOSS4G Beijing conference.
What are the lesson's here? It may be that the critical role of approving finances should be covered by a paid position, funded by profits of FOSS4G conferences. Something like this was considered as described under the No mentor section below.

Is Failure Acceptable?

There has been discussion over the level of OSGeo Oversight that should be applied to a LOC. An OSGeo board member noted:
It is still desirable to give the local organizers quite a bit of freedom and that we should accept that occasional failure is not a disaster.
Which a prior FOSS4G chair responded with:
On the contrary, I'd say that random failures are a disaster and will actually contribute to more failures. ...The success of a conference is tied to the perceived expectations. Throwing a conference is like throwing a party. Do you want to go to a lame party? No, you want to go to a rocking party. If PartyPete throws awesome parties every Thursday, you'll clear your schedule as next Thursday rolls around. If LameLou throws passable parties sometimes, and sometimes cancels them, you'll start going to PartyPete's instead. Consistency is very important.
The same thing will go double for sponsors: are you going to commit to early sponsorship and send a cheque to an event that was cancelled last year? Or will you hold on to your cheque until the last minute just in case? The uncertainty effect is going to make the financial situation of future conferences more precarious as sponsors and registrants hedge their bets until later in the calendar. This will only get worse if we embrace failure as an occasionally acceptable mode.
I'd argue that while it may be ok to experiment with some fringe elements of a FOSS4G program, occasional failure of the international FOSS4G conference should be considered unacceptable.

No mentor

A proposal was put to the OSGeo board, which was eventually approved, to have an experienced FOSS4G mentor support the Beijing Local Organising Committee. (A funded mentor was not provided to previous conferences). This proposal fell through, and although some prior FOSS4G chairs were approached (and others?), a replacement mentor was not found.
This left the Beijing FOSS4G LOC committee without some key expertise which could have been very valuable.
What is the lesson here? I think this was a good idea which fell through, and is worth pursuing again in future.

Communication

Language barrier

From what I understand, Beijing LOC were most comfortable speaking in Chinese, and had varying levels of experience with English. I observed that finding the right English words to support a conversation and convey important messages was a time consuming task, often involving decisions being made in Chinese, then translated to English. This communication overhead would have produced a significant workload on the LOC, who were already working on the difficult and time consuming task of running a FOSS4G conference.
I believe this communication gap also contributed to many of the other symptoms discussed here. Slow communication between the LOC and community would have:
  • Contributed toward slow responses to community queries, hindering the international community contributing prior experience toward the LOC,
  • Slowed decisions from the LOC resulting in schedule slip,
  • Caused difficulties getting the quality control of the website correct,
  • and reduced marketing and communication to potential international delegates.

Cultural Differences

I question whether cultural differences contributed to communication shortfalls. From my observations, it seems Chinese are more circumspect about sending public communication, often using face-to-face meetings, and waiting for review from a superior before making a public statement. This contrasts with open source communities I've observed, where many opinions are discussed publicly, both amongst senior and junior developers, until a rough consensus is reached.
The OSGeo board representative to FOSS4G 2011 noted:
For a while I attempted to play [the FOSS4G board representative] role ... Also, while I was nominally involved, in practice there was never any discussion on any mailing list I was on ...
To me, a lesson of the Beijing effort is that it is hard to be involved remotely if the LOC won't communicate by email/irc/etc. I presume all the discussions that did happen were done by private email or in person but I was left with no visibility or ability to assist.

Collective Knowledge

I believe our experience with this conference highlights how much of our collective FOSS4G knowledge is stored in volunteers' heads, and is passed between different events through our various communication channels. When we constrict information flow by introducing a language barrier, we have also constricted access to our knowledge on how to run a conference.
A few suggestions on ways to address this include:
  1. Collect our conference running knowledge in a central source, that can be handed on without the high level of communication currently being used. In particular, I'm suggesting starting to collect our processes in a FOSS4G Cookbook or similar.
  2. Set up a permanent FOSS4G coordinator role (one person, or an international PCO, or similar) who are responsible for coordinating conferences and personally remembering lessons learned between conferences. (Note the risk of this person resigning and loosing all collected knowledge)
  3. Additionally, ensure key members in the LOC can communicate fluently with the rest of the OSGeo community. In most cases at the moment, this would mean speaking fluently in English.

Response to emails

There were a number of comments that I was privately CCed on which indicated that the international community were not receiving responses after emailing the LOC. Here are some examples:
As I've told you before it has been frustrating to me to not receive any feedback from the LOC on my offer to sponsor the event. I basically had the plan to come with my whole team (5 people now), but can't afford such investment considering the state the conference and participation levels are at now. In fact we have moved focus to the Nottingham event just after Beijing because it appears to be (1) better organized (but that may just appear like it due to the lack of communication from Beijing, (2) an audience that is of interest to [company name] and (3) cheaper / closer to home.
Another from the academic lead, who later stepped down:
... [regarding email responses] from two "important players" I have had no feedback, namely from the local organizers and from OSGeo.
I think the lesson here is that the LOC and PCO should be suitably motivated and resourced, and be provided with enough delegation to respond to all community queries promptly. Every query should be responded to within one working day, even if the response is "we will have an answer to you after the LOC meets next week".

Website out of date

A conference's website is the primary form of communication with potential delegates. For FOSS4G 2012, the website took an excessively long time to be developed and brought online, and then when it was brought online, it contained incorrect information and broken links (mainly cut and paste from the prior FOSS4G website). People were having significant issues with submitting papers and registering to attend.
The FOSS4G LOC had hired an external web developer to create the website, who had done a poor job of development. It seemed that there was a lack of quality control from both the web developer, and LOC. In the past, development of the website has either been managed by technically experienced developers (as was the case in 2009), or by the PCO.
The lesson here is that the website needs to be made a priority and suitably resourced. There is the potential for website management software to be passed on from one conference to the next. (We considered this option in 2009 but found the Open Source conference management software used by FOSS4G 2008 was not going to integrate easily with the software our PCO was using). It would be worth future FOSS4G conferences revisiting this question.

Minimal "buzz"

To a certain extent, a conference is successful because the LOC says it is going to be successful (and potential attendees and sponsors believe the statement). Presenters and sponsors attend the conference because they believe there will be lots of delegates, and delegates attend because they believe there will be lots of quality presenters and sponsors. And one of the most effective ways for everyone to be convinced of the conference's success is to create lots of "buzz". I.e., lots of press releases, articles, blogs, twitter discussion and more talking about how good the conference is going to be.
FOSS4G 2009 possibly went a little too far by putting out 41 press releases. However, FOSS4G Beijing could certainly have benefited from more "Buzz", as the OSGeo Board Chair noted:
on the website at http://2012.foss4g.org/ there is still no option for submitting abstracts although the submission has been opened - apparently without notice to any of the regular OSGeo channels. Workshops submission ends in two weeks.
No international speakers have been announced and there are only Chinese sponsors listed (although interest by regulars was documented as early as December 2012).

Engaging international organisers

Compared to prior international FOSS4G events, there was minimal international involvement in organising the FOSS4G event. Of particular concern was that the international academic track lead resigned, saying:
... I regret [the LOC] did not fully support the setup I proposed. Specifically, the LOC insists on using their own deadlines and reviewing and publication plan. Of course they have every right to do so, because it is in fact their conference...
There is a significant amount of work involved in organising a conference, and it is very valuable to share tasks with the international community. This has two key benefits:
  • It allows the LOC to focus on the local issues (like sorting out the venue)
  • It facilitates knowledge transfer between years, as roles like the Academic track lead are often coordinated by the same core people over a number of years.
So lesson here is look for opportunities to make use of the international community to coordinate specific areas of the conference.

Weekly meetings

Less than 3 months before FOSS4G 2012 was due, weekly meetings were started between volunteers from the international community and the LOC. I understand that the LOC were having meetings internally, but there was little visibility of them from the international community. The extra meetings facilitated transparency from the international community into the progress of the LOC, which in turn provided opportunities for the international community to volunteer to help. Eventually, with the help of these weekly meetings it was assessed that the level of effort required to bring the conference back on track, along with the likely outcome, resulted in a decision to cancel the conference.
In retrospect, these meetings should have started much earlier, ideally from the start of the conference planning a year or so earlier such that support from the international community could have made a better impact in the earlier stages. So lesson hear is start having periodic meetings from early in the planning cycle, and invite the international community to participate if you can.

Who wrote this analysis?

The telling of history is always influenced by the perspective of the narrator, and as such it is useful to know who the narrator was. This narration was by myself, Cameron Shorter. I was the chair of FOSS4G 2009, I'm a member of the OSGeo Conference Committee, and I voted for FOSS4G 2012 to be held in Beijing. I helped volunteers add Chinese translations to the OSGeo-Live DVD, and commit to handing the DVD out at FOSS4G Beijing. I later attended weekly meetings with FOSS4G Beijing's LOC and other international volunteers, until it was decided by the LOC that the conference should be cancelled.

Tuesday, 21 August 2012

OSGeo-Live 6.0 released

image: osgEarth - 3D Terrain Rendering on OSGeo-Live
Version 6.0 of the OSGeo-Live GIS software collection has been released, and will be officially launched at OSGIS 2012, the Open Source GIS conference in Nottingham, UK, 4-5 September 2012.

Release Highlights

Applications
All geospatial applications on the disc have been updated to their latest stable releases.
OpenJDK 7
All OSGeo-Live java applications have been successfully migrated to OpenJDK 7. Migration to OpenJDK was driven by Oracle's announcement that including Sun Java in Linux distributions, such as Ubuntu, or OSGeo-Live, is no longer allowed.
Translations
There has been significant activity translating OSGeo-Live documentation. Core documents are available in ten languages, and comprehensive translations are available for many other languages, including: Catalan (new), Chinese (new), English, French (new), German, Greek, Italian (new), Japanese, Korean (new), Polish, Spanish
Xubuntu 12.04 LTS
The Xubuntu base has been upgraded to 12.04 LTS (Long Term Support)

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 introduce the breadth and depth of Free and Open Source for Geospatial (FOSS4G).

OSGeo-Live includes:

  • Fifty 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 for multiple languages

Credits

Over 120 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, Alex Mandel, Alexandre Dube, Amy Gao, Andrea Antonello, Andrea Yanza, Angelos Tzotsos, Anna Muñoz, Anne Ghisla, 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, Dane Springmeyer, Daniel Kastl, David Mateos, Diego González, Dimitar Misev, Dominik Helle, Edgar Soldin, Eike Hinderk Jrrens, Eric Lemoine, Estela Llorente, Etienne Delay, Etienne Dube, Fran Boon, François Prunayre, Frank Gasdorf, Frank Warmerdam, Gavin Treadgold, Grald Fenoy, Hamish Bowman, Haruyuki Seki, Henry Addo, Hernan Olivera, Howard Butler, Hyeyeong Choe, Ian Turton, 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, Lance McKee, Lars Lingner, Luca Delucchi, Lucía Sanjaime, Mage Whopper, Manuel Grizonnet, Marc Torres, Marc-André Barbeau, Marco Curreli, Marco Puppin, Margherita Di Leo, Maria Vakalopoulou, Mario Andino, Mark Leslie, Massimo Di Stefano, Mauricio Miranda, Mauricio Pazos, Micha Silver, Michaël Michaud, Michael Owonibi, Mike Adair, Milena Nowotarska, Nacho Varela, Nathaniel V. Kelso, Ned Horning, Nobusuke Iwasaki, Oliver Tonnhofer, Ã’scar Fonts, Otto Dassau, Pasquale Di Donato, Paul Meems, Pedro-Juan Ferrer, Pirmin Kalberer, Raf Roset, Ricardo Pinho, Roald de Wit, Roberto Antolín, Roger Veciana, Ruth Schoenbuchner, Samuel Mesa, 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, Xianfeng Song, Yoichi Kayama, Zhengfan Lin

Sponsoring organisations

  • The Open Source Geospatial Foundation, OSGeo, provides the hosting infrastructure for the OSGeo-Live project, and infrastructure for many of the software projects themselves. 
  • LISAsoft provides sustaining resources and staff toward the management of the Live DVD.
  • Information Center for the Environment (ICE) at the University of California, Davis provides hardware resources and development support to the OSGeo Live project.
  • The DebianGIS and UbuntuGIS teams provide and quality-assure many of the core packages.

Wednesday, 15 August 2012

Joining the OSGeo board

I feel quite humbled and very honoured to have been voted onto the OSGeo Board. I'll do my best to live up to what I believe are the expectations of a board member.That is:
  • I believe a board should listen to the community, work out what is the best for the community, then vote accordingly.
  • We need to recognise the limited time constraints of (already busy) board members. If most decisions are deferred to a 9  member board, then we are wasting the potential of the 1000s of OSGeo volunteers, and 100s of OSGeo charter members. So primarily, a board's role should purely be a job of oversight, validating decisions made in OSGeo's various committees and projects.
  • It is important to discuss ideas, but even more important is to follow through with solid actions, and I believe it is important to look for opportunities to enable volunteers to make a difference. It is important to work out ways to collate our volunteer efforts effectively and efficiently to make something much bigger than one person can do on their own. Effectively, the OSGeo Board should make way for OSGeo volunteers being more effective.
  • It is good for a board to have a breadth of experience and opinions, but even more important is for a board to be able to work together effectively to make decisions. This means that at times, each board member will need to compromise, because a compromise is almost always better than making no decision at all.

Thursday, 2 August 2012

All OSGeo-Live java applications now working with OpenJDK 7

100% of OSGeo-Live java applications are now running successfully using OpenJDK 7 in OSGeo-Live 6.0 beta releases.
This move to OpenJDK has been driven by Oracle's announcement that the "Operating System Distributor License for Sun Java has been retired", meaning that Sun Java is no longer allowed to be distributed in Linux distributions such as Ubuntu, or OSGeo-Live.
The good news is that OpenJDK, the fully Open Source implementation of java, has improved to the point where we have shown that all OSGeo-Live applications will run under OpenJDK 7. And by extension, we have shown it is feasible to incorporate these applications in linux distributions.
We have verified applications compile and quickstarts run as expected, and we have been impressed with what we have seen. However we have not done comprehensive testing of all functionality in each application. Nor have we tested performance or reliability. Users who wish to see a specific application deployed into production using OpenJDK should contact the project about whether more detailed testing has been completed.

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.
Image Source:  http://spagettikoodi.files.wordpress.com/2010/11/java-duke-guitar.png

Wednesday, 18 July 2012

Australian National Environmental Information Infrastructure pilot

 LISAsoft has recently supported the Australian Bureau of Meteorology set up a National Environmental Information Infrastructure pilot.
The natural environment plays an important role in Australia’s economy and way of life. To manage it effectively, governments, industry and the community need comprehensive, trusted and timely environmental information to make sound environmental decisions. To support this need, the Australian Bureau of Meteorology (the Bureau) is leading the National Plan for Environmental Information initiative that will deliver improved quality, coverage, usability and access to environmental information. As one element of the initiative LISAsoft has supported the Bureau in piloting parts of a National Environmental Information Infrastructure (NEII).  This pilot has demonstrated the process of modelling and publication of environmental information from atmosphere, ocean, land and water domains.

There are multiple challenges involved in achieving an effective infrastructure. First, the source data, which is continuously updated by multiple agencies, needs to be dynamically collated into aggregated datasets to facilitate macro analysis. This requires development and agreement upon standard data formats, processes and tools which source agencies can use to publish the source data. Once aggregated, the data requires distribution and publishing in a manner that can easily be accessed and manipulated by end users. This requires a robust and reliable publishing infrastructure, built upon standard interfaces, which can be used easily and efficiently by existing or provided tools. Furthermore, the infrastructure developed needs to be both feasible and sustainable. As such, the Bureau has selected a distributed design, based upon OGC standards based services and formats.
This early NEII pilot has focused on the development of standard information models, and a reference implementation of a source data node. LISAsoft has helped the Bureau by:
  • Consulting on and documenting the NEII architecture design.
  • Defining some of the information models required.
  • Developing pilot implementations of an NEII node. The NEII node publishes data via a Web Feature Service (WFS) interface using the GeoServer spatial data server.  GeoServer has been the target of recent CSIRO development efforts to create a service capable of supporting the complexity of data models required for projects such as NEII.
  • Configuring a web based catalogue which can be used to find datasets. This is based upon the Catalogue Service for the Web (CSW) interface, and implemented using the Open Source GeoNetwork application.
  • Testing of the conformance of the services within the pilot.
To support the Bureau, LISAsoft has drawn upon years of relevant experience, including:
  • Domain Modelling during international, OGC standards development testbeds
  • Co-authoring a Domain Modelling Cookbook with CSIRO
  • Testing conformance of Web Feature Services in both Australian Spatial Data Infrastructures as well as in OGC testbeds.
  • Deploying, configuring and optimising GeoServer for multiple projects.
The NEII pilot has completed successfully and has validated the feasibility of the proposed design, and provided valuable feedback into the practicality of the approach and tools. These valuable lessons will be fed into the greater National Plan for Environmental Information initiative.

Thursday, 21 June 2012

Calling for "OSGeo Advocate" profiles

Do you know a lot about aspects of Geospatial Open Source, and are prepared to stand up in public and talk about it? Then please consider adding your name to the "OSGeo Advocate" list.

Background:

With my role on the marketing committee, increased number of foss4g related conferences, and with the success of the OSGeo-Live DVD, I'm now regularly being asked to recommend speakers who can talk about OSGeo related topics. Arnulf, as chair of OSGeo, similarly reports being invited to present at more conferences than he can sustain. So the OSGeo Marketing committee has created a space to show off the breadth of experience amongst our OSGeo community, which at the same time will allow conference organisors find local OSGeo experts.
Is this something you can help with? If so, please register within the next month, before the end of July 2012, when we intend to officially launch.

Monday, 30 April 2012

Call for interest in OSGeo-Live 6.0

We are starting to build the 6.0 OSGeo-Live DVD which will be released in September 2012, ready for FOSS4G 2012 as well as many other spatial conferences. This upcoming version will be built upon the stable Xubuntu 12.04 Long Term Support (LTS) release. Documentation will be translated into eight languages, now also including Chinese and Catalan.
Any new applications?
We would like to hear from anyone wishing to add new projects to OSGeo-Live, anyone wishing to extend or add extra translations, or anyone who has ideas on how we should shape the upcoming release.

Key Priorities for next release

Package Updates
Migrate to Xubuntu 12.04 LTS
Update and test latest stable software releases
Migrating to OpenJDK
Due to Oracles changed license conditions for Sun-Java, Ubuntu users are now strongly encouraging to move to OpenJDK instead of Sun Java, due to both improvements in OpenJDK, and difficult licencing conditions with Sun Java. As such, we will be endevouring to move all java based applications to OpenJDK (instead of Sun Java).
Disk Space
We have reached our DVD size limits, and need to be creative about saving space and disciplined in not losing space to duplication. We hope to ship a single Java and single Tomcat version this time, in addition to further consolidation around shared sample datasets.
Testing
With Quality being a key focus area for us, we need lots of help with testing.

Key Milestones

10 Jul 2012 Feature Freeze
07 Aug 2012 User Acceptance Test (all Apps installed and working)
28 Aug 2012 Final ISO sent to printers
... full schedule

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.