End of life for Community Mapbuilder

We, the Mapbuilder Project Steering Committee, have agreed that the time has come for the Community Mapbuilder project to gracefully retire. We will release a final, stable 1.5 version of the software, and afterwards there are no planned enhancements to Mapbuilder. The web pages and code will be kept alive, a few bugs might be fixed and we will likely continue answering user queries, but we expect Mapbuilder will gradually fade away into history.

Why?

Mapbuilder is a stable, feature rich, standards compliant, fast, webmapping framework with a strong developer community. Why has it come to the end of its life?

The browser based webmapping space has become crowded and other webmapping clients have increased in functionality and attractiveness to users. In particular, Openlayers is simpler to use, has attracted an incredibly strong developer community, has good quality control and development processes, and has developed most of the webmapping functionality previously only offered by Mapbuilder. Basically Openlayers is attracting the majority of the users and developers that previously would have used Mapbuilder. One day someone will write a compelling paper on the history of the two similar projects and analyse the key differences and decision points which led to one project out shining the other.

But we are not crying

Well, maybe we feel a twinge of loss for the Mapbuilder project we started years ago, but in the bigger picture, we see the retiring of Mapbuilder as a good thing. It will allow the greater web mapping community to consolidate and rally around the remaining webmapping tools – in particular, around Openlayers.

There has been significant collaboration between the Mapbuilder and Openlayers communities over the last couple of years. Mapbuilder has incorporated Openlayers as its rendering engine and features have been shared between projects. In many cases, developers from both projects worked on the same codebase (in Openlayers), then ported up to Mapbuilder. This was a deliberate move toward the merging of the two developer communities and most of the Mapbuilder Project Steering Committee have contributed to the Openlayers codebase.

So in essence, by changing our allegiance from Mapbuilder to Openlayers we take with us some of our code, we replace some features with equivalent Openlayers features, we take our community with us, and we gain an existing, robust and welcoming community. We loose a little and gain a lot more.

What should Mapbuilder users do?

Users have a few options. You already own the source code, so you are welcome to continue maintaining and extending the Mapbuilder code for as long as you like. At some point, users will likely want to upgrade, and at that point we suggest considering Openlayers for your application. It now provides the majority of the functionality that was previously only offered by Mapbuilder.

What about Mapbuilder's standing with OSGeo?

Loosing a graduated project might seem like an embarrassment for OSGeo, however, I'd argue it is a strength. It shows two projects growing together under the OSGeo umbrella and eventually merging into a stronger, more focused community.

Even so, it raises a dilemma with regards to what should be done with a retired project. Some key OSGeo criteria like “Community Backing” and “Best of Breed Software” will gradually be lost, so OSGeo should stop recommending Mapbuilder. But, OSGeo shouldn’t erase Mapbuilder's history with OSGeo as Mapbuilder has documented valuable lessons learned during the graduation process.

We suggest OSGeo create a new “retired” project category.

Thanks

We, the Project Steering Committee, have derived a huge amount of pleasure building Mapbuilder and working with the Mapbuilder Community. For many of us, Mapbuilder has been a launching pad into a full-filling Open Source and/or Geospatial careers. We'd like to thank all the users, developers and supporters of Mapbuilder we have met along the way.

The Mapbuilder Project Steering Committee, (in order of appearance):

• Cameron Shorter

• Mike Adair

• Patrice Cappelaere

• Steven M. Ottens

• Matt Diez

• Olivier Terral

• Andreas Hocevar

• Gertjan van Oosten

• Linda Derezinski

Want a religious Open Source experience?

This week, half a million Catholic youth are congregating in the holy city of Sydney, Australia and are being led in prayer by Pope John Paul himself. You have probably seen it covered in the news each night.

You recognise the city? Yes, its the same Open Source mecca where the 12 tribes of OSGeo will gather in November 2009 for the FOSS4G conference.

Of course, you don't have to wait until 2009 to hear your favourite OSGeo preachers. FOSS4G 2008 in South Africa is almost upon us.

Government purchasing encourages monopolies

Misapplication of “value for money” requirements when purchasing software results in poor value for money - Government purchasing policies for software tend to support the creation of monopolies.

Government purchasing has effects on the price paid by citizens for the product purchased. In some cases purchasing produces volume which permits scale discounts and therefore a net benefit to citizens who also purchase the product. However, in the case of lock in software Government purchasing can create a monopoly in the software which leads to increased costs for citizen purchasers and a net detriment for society as a whole. It is not appropriate for value for money policies to be assessed on a per acquisition basis when software is being acquired. Doing so will almost certainly create net costs for the community when considered in the aggregate.

Read the rest of Brendan Scott's article here: The Tragedy of the Anti-Commons.

Effective Open Source Sponsorship

Many government agencies are extending Open Source Software to solve their business problems. Open Source offers many advantages, including free licensing and engagement of an international pool of developers, but it does require appropriate investment and management to capitalise on Open Source’s offerings effectively.

After deciding to extend Open Source Software, agencies are faced with a relatively new business model, open source sponsorship. Agencies need to align purchasing policies, based upon deliverables and milestones, with Open Source community development.

Under a proprietary business model, a company builds and markets a product. Multiple customer sales cover the cost of development, supporting infrastructure, marketing, support, future enhancements and hopefully include a profit. While Open Source business models incur the same costs as the proprietary models they generally distribute the costs to the end users differently, charging for the implementation of specific functional or usability improvements.

Initial investment in communities, infrastructure, and marketing for an Open Source project is often the most effective way to ensure a long term return on investment as these areas are commonly neglected in favour of feature enhancements. Proper promotion and infrastructure support, instead of a sole focus on missing features, will encourage project growth and ultimately lead to open source Nirvana: hundreds of developers building your application using someone else’s budget.

Management should justify investment in a project as Opportunity Management.

Opportunity Management is the inverse of Risk Management. With risk management you quantify what can go wrong then identify mitigation strategies to avoid or reduce the impact of the risks. With opportunity management you list potential windfalls and deploy strategies to enable and benefit from the windfalls. Table 1 shows an example opportunity management matrix.

Table 1: Opportunity Management

Opportunity	Enabler
Use data from external agencies.	Agencies are given access to open source tools to reduce their barrier to sharing data. Use Open Standards for tools to facilitate communication. Use Open Standards for data schemas so data can be integrated.
External Agencies extend our toolset.	Use and share our tools as Open Source Software so that others can use and extend them. Support the Open Source development processes to reduce the barrier of entry to potential development sponsors.

Keys to Success in Open Source

There are a number of key elements that a potential sponsor should consider when evaluating an open source project in order to ensure maximum return on investment. These include:

• Solves a specific need effectively.

• Has an active, diverse and inclusive community.

• Enjoys support from multiple sponsors.

• Established development processes including:

  • Issue tracking

  • Communication channels like email lists and IRC

  • Quality control

• Clear and comprehensive documentation and marketing material.

The OpenLayers project is a good example of a commercial entity driving the creation of a thriving open source project. OpenLayers is an open source, browser based web-mapping client which provides a front end to various proprietary and open data sources like Google and Yahoo Maps, WMS and WFS. In three years OpenLayers has grown from nothing to be the dominant open web-mapping client, attracting the majority of the users and developers in this space.

OpenLayers was initially sponsored by MetaCarta who needed a browser based application to support their mapping services. Rather than focusing on features, MetaCarta focused much of their investment on infrastructure and community support. In particular their effort was spent answering developer and user questions on email and IRC, monitoring the quality of code contributions, and setting up automated testing. Many of MetaCartas engineers have developed a personal interest in OpenLayers which MetaCarta encourages by allowing the engineers to spend some work time on the project.

Today, OpenLayers has an incredibly active developer community requiring minimal support from MetaCarta and have provided functionality significantly greater than MetaCarta’s original scope. Key to the success of OpenLayers has been the long running, dedicated community support provided by Chris Schmidt from MetaCarta. GeoServer¹, another Open Source project, has recently introduced a similar community liaison role, dedicated to community support and marketing.

The role of Community Liaison has always been key to Open Source and often is filled by volunteer enthusiasts, however commercial deployments of Open Source creates a workload volunteers can’t maintain and hence industry hires these volunteers instead. Ensuring that the community is supported in this fashion promotes the uptake of the project, increases the user base, which in turn attracts more sponsors and more developers. This leads to the situation where many developers are employed by a variety of sponsors to create new features and improve the performance and stability of the project.

Sponsorship Checklist

There are a number of tasks and roles that need to be addressed in order to ensure a successful open source project. These are described below.

• Community Support

A person or team is required to answer user and developer questions, review submitted code from external developers to ensure quality control and ensure that all submissions meet the project requirements in terms of test coverage and documentation. This is one of the most effective investments in a project.

• General Project Processes

All projects should invest in tools and processes such as automated build systems, issue trackers, concurrent versioning systems as well as ensuring that releases are performed smoothly and regularly.

• Documentation

Good, current design and implementation documentation lowers the learning curve for developers supporting and extending software and greatly increases productivity. Good user documentation engenders confidence in project reviewers which in turn will lead to greater adoption.

• Marketing

While Open Source benefits significantly from community generated promotion, it is enhanced by prudent investment in web pages and presentations for targeted conferences.

• Commercial Support

One of the main reasons given for avoiding Open Source is not being able to call someone to fix problems. Offering commercial support for a project you use will go far in encouraging adoption by other organizations.

• Integrate and bundle with related software

Microsoft Office has been especially successful because it integrates a suite of related products and bundles them all together in one easy install. Open Source products improve their attractiveness in the same way.

• Open Standards

Due to the release-early/release-often approach of most open source projects, they are often leveraged to develop, test and extend open standards. This makes open source projects among the earliest adopters of emerging standards, encourages the uptake of open standards and makes the projects attractive to those interested in sharing data between agencies.

• Project Management

Just like proprietary software, a sponsor’s software development should be managed using standard software development processes. This includes estimation; planning resources, work activities, schedules, budgets, deliverables; monitoring schedule, quality, risk, issues, contractors, configuration management.

• Measurement

Measurement is a key tool used during proprietary Project Management, as good metrics enable good management decisions. Good measures highlight whether specific business goals are being met and enable management to alter their strategy early if issues arise.

Metrics are under-utilized in many open source projects as developers usually drive their own agendas, are self motivated, and spend less time on Project Management. However metrics based decision making can be equally effective for Open Source projects especially for sponsors who will need to answer to commercial milestones and targets.

Standard software development metrics should be complemented by measures to monitor the health of an Open Source community. The Community MapBuilder project tracks many of these metrics. There are now a number of dedicated tools which automate many of the common software metrics.

Should my organisation sponsor Open Source?

If your organisation is considering a long term use of an Open Source product, it will likely be smart to invest in the project’s infrastructure. Audit the project against the checklists above, cost the areas needing improvement, set up an opportunity register and determine whether prudent investment will be of value.

Hopefully supporting Open Source will prove to be an effective solution. Then you will discover one more thing,

“Writing Open Source is very good for the soul.”

Accepting and embracing employee turn over

The value a good employee brings to a business eventually plateaus when the employee has less new ideas they can contribute. At that point, the employee will look for challenges of a new role or a new job.
As employees and employers we need to recognise and embrace this cycle so that we can maximise the potential benefits.
The following article saves me the need to explain this further:
http://thedailywtf.com/Articles/Up-or-Out-Solving-the-IT-Turnover-Crisis.aspx

Tour Hosts selected to manage the FOSS4G conference in Sydney 2009

Sydney, Australia. Monday 5 May 2008.

Bruce Bannerman +61 3 9658-4572

The Open Geospatial Foundation (OSGeo) has selected Tour Hosts to manage the international conference for Free and Open Source Software for Geospatial (FOSS4G) to be hosted in Sydney 17-21 November 2009.

FOSS4G is heralded as the international "gathering of tribes" of open source geospatial communities, where developers and users show off their latest software and projects. The theme for 2009 is "User Driven", highlighting the power of Open Source to solve business problems.

Tour Hosts were selected based upon their track record hosting quality international conferences for technically savvy audiences, their experience marketing to the government sector (a key user group), and their experience attracting international audiences, especially within the Asia-Pacific region.

Bruce Bannerman, chair of the selection committee, summarized, "I'm confident Tour Hosts will ensure FOSS4G is well attended and memorable for all delegates".

This adds another great reason for coming to the FOSS4G conference in Sydney in 2009:

• Great conference full of the latest open source geospatial goodies and all the geospatial open source celebrities.


• Hosted in Sydney, with a beautiful harbour and golden beaches.


• November is almost summer and is beautiful warm weather.


• And now add first-class conference organisers who will ensure the event is run like clockwork.

About OSGeo

The Open Source Geospatial Foundation (OSGeo) has been created to support and build the highest-quality open source geospatial software. The foundation's goal is to encourage the use and collaborative development of community-led projects, data development and education.[1]

About OSGeo - Australia/New Zealand

The Australian and New Zealand chapter of OSGeo focuses on local issues like promoting OSGeo principles at conferences and lobbying for and building open, local, geographic datasets.

About FOSS4G

FOSS4G is the international gathering of open source, geospatial tribes. The spatial industry is undergoing rapid innovations and the open source spatial community is one of the forces driving the change. From its beginnings the FOSS4G conference has been the gathering of the spatial tribes and has a reputation of being a melting pot for great ideas in the spatial industry and a catalyst for many successful geospatial products, standards and protocols. The 2007 conference was held in Victoria, BC, Canada and was a huge success[2]. The 2008 conference will be held in Cape Town, South Africa[3]. FOSS4G 2009 Sydney will be the seventh "formal" gathering of the open source geospatial community and is expected to focus on the increasing importance of FOSS4G in the public and private enterprise.

[1] http://osgeo.org

[2] http://www.foss4g2007.org

[3] http://www.foss4g2008.org

WFS Performance Testing

LISAsoft has been contracted to test robustness and conformance of Web Feature Services (WFS) in the Australian Water Data Infrastructure Project (AWDIP).

An Open Source robustness and conformance testing framework will be developed as part of this project. These testing tools will help system integrators and tool developers build quality Spatial Data Infrastructure which is robust and scalable.

What are Community Schemas?

The WFSs deployed in AWDIP use the Community Schema functionality which was recently introduced to the stable 1.6 release of Geoserver.

The GML returned by Web Feature Services (WFS) includes semantically defined geometric data describing points, lines polygons as well as other information, like Water Level or Water Use.

Community Schemas define specific fields and acceptable values for the “Other Information” inside GML. Eg: Within a Community Schema we can define Water Use as: agriculture, irrigation, domestic, … but not farming. Using Community Schemas facilitates sharing data between data stores, and enables powerful business applications like the data analysis provided by AWDIP.

More information at on Community Schemas is available at: https://www.seegrid.csiro.au/twiki/bin/view/Infosrvices/InformationViewpoint

What sort of testing?

Stress, reliability, load, performance, error handling and conformance testing will all be supported. Black Box testing will be used for most of tests, interfacing with the WFS through the Web Service interface.

The tests will be configured using JUnit, allowing it to be incorporated into existing testing and continuous integration frameworks. Project specific tests, as required by AWDIP, will be developed as separate modules.

White box testing will be done for specific AWDIP installs to test internal bottlenecks and database responsiveness.

Who’s involved?

The Australian Bureau of Rural Sciences is responsible for the Australian Water Data Infrastructure Project (AWDIP), and have contracted LISAsoft to build a deployable testing framework for Geoserver deployments.

The testing framework will build upon prior Geoserver/Mapserver testing done by TOPP and others. In particular, we will use Andrea Aime's blue print for performance tests which integrate into Geoserver's continuous testing framework.

Rob Atkinson (CSIRO Australia) has been leading the effort to support data standards in Geoserver and has been involved in the design and deployment of AWDIP WFS nodes, as well as ongoing support for other international data standards such as GeoSciML.

Join the Project

Duckhawk is the Open Source, WFS testing project. Interested parties are invited to join our email list and monitor or participate in the project.

Convert Web Map Context (WMC) to OWS Context

After manually converting many WMC files to OWS Context I convinced myself that it would be easier to write a stylesheet to do the job for me. As usual, the XSL took longer to write than expected, but it was much more satisfying.

You can try out the stylesheet yourself, it is incorporated into Mapbuilder's codebase at:

http://svn.codehaus.org/mapbuilder/trunk/mapbuilder/lib/tool/xsl/Wmc2OwsContext.xsl


To run, from a linux command line:

xsltproc http://svn.codehaus.org/mapbuilder/trunk/mapbuilder/lib/tool/xsl/Wmc2OwsContext.xsl YourWMC.xml > NewOWSContext.xml

If you find any bugs, please report them in http://jira.codehaus.org/browse/MAP, and let me know you have reported them.

Open X reaching main stream at WALIS conference

Open Source, Open Standards, Open Architecture, Open Data, Open Communities were all hot topics at the West Australian Land and Information Systems (WALIS) Conference held in Perth Australia last week.
Open X Presentations
I was honoured to chair an afternoon of well attended presentations on these topics, and help man an OSGeo stand where Open Source was discussed non-stop with attendees.
Tim Bowden, a colourful Open Source personality introduced with an overview of Open Source, Open Standards and Open Data.
Liz Kolster from the State Services Commission in New Zealand provided a lightning speech explaining how community engagement was achieved in New Zealand Government using techniques seen in Open Source development communities and Web 2.0 web sites.
Mark Leslie, a software architect at LISAsoft gave an excellent high level summary of all the key packages in the Geospatial Open Source Stack. (He will be putting this presentation into the Creative Commons for those who want to use it.)
I presented with Simon Cox from CSIRO on Engaging the OGC in your R&D.
Tim Cargo from the Navel Division at Thales Australia described the benefits of Open Architecture when extending a large legacy Combat System to include new components - use gateways to convert legacy system interfaces to standard interfaces.
Sony Tham from Amristar talked about Workflow in business problems, when to apply Open Standards and when not to, focusing on issues associated with bandwidth.
James Write and Alistair Fox from SKM reviewed browser based mapping clients. The top 5 recommended clients were open source, despite both proprietary and open source being considered.
In another thread, Steve Jacoby from Information Queensland explained how Queensland government is moving to store most of its data under a Creative Commons license.
OSGeo interest
High profile applications within the WALIS framework now use Open Standards and Open Source, and other agencies are investigating get involved. This is evidenced by the strong turn out at Open X thread of presentations and the continuous steam of people hovering around the OSGeo stand.
Four commercial companies sponsored the OSGeo stand at WALIS demonstrating stable commercial support for Open Source. Support was sponsored by: Lisasoft, Gaia Resources, Maunsell and Lat-Lon. Equal numbers of government and research employees also wore OSGeo shirts and explained what OSGeo was all about.
It was excellent to see such interest in Geospatial Standards and Open Source and I expect to see a lot more OSGeo in the near future.

International conference delivered to your doorstep

What do you do when you can't travel to best international conference for Open Source Geospatial Software? Get it to come to you of course. With some astute lobbying and networking, FOSS4G 2009 is coming to my home town in Sydney.

I've had a burning desire to attend the FOSS4G conference since it started. It attracts the cream of Geospatial Open Source developers. People I collaborate with, sharpened theories against, and who share my virtual life. FOSS4G is where everyone meets face to face, networks and shows off the latest technologies. I want in!
Travel is an issue for me. Initially, writing Open Source software was a hobby and I couldn't justify travel costs. Now, my wife works and we share kid pick up and drop off from school. It works like clockwork until someone leaves for a week.
In true Open Source sense, I have an itch to scratch, which leads to creative thinking. If I can't travel to my friends, then why not bring my friends to me - all 700 of them.
The idea sounded arrogant, self serving and daunting. I knew a couple of OSGeo sympathizers and developers in Australia, but they were already committed up to the eyeballs and I couldn't see where we could get enough spare energy to build a conference. And I knew nothing about conferences - hadn't even attended a major one.
I mentioned the idea to a few people, one being Tim Bowden. Tim overflows with enthusiasm, especially when talking about Geospatial Open Source. Between the two of us, we found others who supported the idea, OSGeo users in Australian government (who later shaped our bid theme of "User Driven"), key people behind a Linux Australia conference in Sydney, and most importantly the Sydney Convension and Visitors Bureau (SCVB). The SCVB sole responsibility is to bring conferences to Sydney. Core business is putting out glossy proposals backed by statistics and great facts about Sydney. They put themselves at our service at no cost, being funded by government and the tourist industry. Wow! Suddenly my dream seemed feasible, even if it is blatantly self serving.
Bid Strategy
We decided to be open in developing our bid as it builds a stronger, friendlier community and we would be pitching our bid to Open Source developers who share these ideals. This strategy paid dividends when the bid committee joined our email list and provided valuable feedback as we developed our proposal. They watched the strength and enthusiasm of our team grow.
We telegraphed our intention to bid a year early and while 4 cities vied to host FOSS4G 2008, Sydney's bid was uncontested in 2009. Feedback suggested that other cities didn't bid based upon the apparent strength of our bid. This is a pity. If a city doesn't win the conference one year, it should be considered a likely contender the following year. Having numerous cities bid helps the committee plan ahead.
Lessons Learned

• Plan ahead. FOSS4G moves around the world to give everyone a chance to attend locally.
• Bidding cities should take a long term strategy. If you don't win one year, keep submitting until you do.
• The bid committee should suggest regions they would like to move to in the near future which will encourage cities in that region to bid.
• Feedback to unsuccessful bids should include targeted feedback, including rankings, to help cities refine their bid.
• Cities should engage the local conference industry. They are likely to provide their services for free in order to secure the conference.
• Network locally. A large, diverse team is attractive to selectors.
• Be open in your bidding process. While it may allow competing cities to gain advantage, you will demonstrate your strength and openness to the OSGeo bid committee.

Bid Team
While I write this article as if our conference bid was solely driven by my selfish motivations, this was not the case. We had a large team of enthusiastic, motivated individuals who all contributed in major ways, which is why FOSS4G 2009 will be such a successful event. I'm just delighted that my dream to attend FOSS4G will be realized in the process.

Path to Ubiquitous OSGeo Software and Documentation

The time is ripe to integrate our Open Source Geospatial (OSGeo) applications, and build supporting documentation. The goal:

Powerful, Simple, Integrated, Documented, Ubiquitous Open Source Geospatial Applications

Ease of installation will pave the way for mainstream OSGeo adoption, increase users and developers exponentially and greatly increase OSGeo offerings.
Here I define achievable steps to reach the goal and likely resources for each step.
Current status
We already have powerful Open Source Geospatial applications, but we still need geeks to install and then use a full stack of OSGeo software.
Our applications are often easy to install by themselves, but project release schedules are independent of each other and it is hard to keep up with which versions of software work with each other.
There has been good work getting many OSGeo packages into linux, notably UbuntuGIS, DebianGIS and liveCD. A windows distribution is needed.
Documentation and training material is in an early phase. This material needs to be cross project, and match versions of OSGeo Software.
Key Steps
Set up project version dependency matrix (OSGeoMatrix)
A table which lists, for each project version, the other project versions it depends upon. The OSGeoMatrix should be seeded by existing efforts from UbuntuGIS, DebianGIS and liveCD projects.
OSGeoMatrix would feed into the various linux and windows distributions.
Once the OSGeoMatrix exists, the onus on updating it will become the responsibility of projects and should become an entry criteria for the OSGeo graduation process.
OSGeoMatrix will require release, testing and feedback processes to maintain quality control. These processes should start from existing linux distribution projects.
For efficiency, it would help to align OSGeoMatrix release schedules with linux distribution schedules.
OSGeo Workshops & Tutorials
I see an immediate opportunity to present OSGeo Workshops at Geospatial Conferences. Agencies want to learn about OSGeo, and workshops are a great advertising tool for companies looking for OSGeo work.
Together we can collectively build quality workshops, and we have the resources (potential presenters) to develop the documentation.
These workshops require a stable set of software, so should provide volunteers to help seed the OSGeoMatrix.
Further documentation
Comprehensive documentation which has already started in the education committee should be able to tap into and get a boost from the workshops and tutorials. I'll let others comment on the path this should take.
Dependencies
The project dependencies I see are:

+-OSGeo Packages
..+-OSGeo Matrix Project
....+-LiveCD
....+-MandrivaGIS
....+-DebianGIS
......+-UbuntuGIS
........+-Ubuntu
....+-WindowsGIS (yet to be started)
....+-Other distributions

....+- Distributions
......+-OpenSource Workshops
......+-Documentation

Actions:
The effort required to achieve all the above is huge. But there are already many people working on each of these sections, and by integrating our efforts we are all going to benefit.

So I suggest the following:
1. Get buy in from the existing linux geospatial projects: LiveCD, UbuntuGIS, DebianGIS and MandrivaGIS. These projects are already doing much of the effort required for an OSGeoMatrix project and can seed OSGeoMatrix. The benefit for the linux distributions is that they will reduce their overhead by sharing integration efforts with other distributions, and after OSGeoMatrix has started, projects will maintain dependencies for their own project.

2. Start an OSGeoMatrix project. It should contain:

• Web page
• Email list
• Version dependency matrix (how should we store this)
• Build processes
• Test processes
• Release schedule

This project would be an excellent candidate for OSGeo Labs.

3. Have projects like UbuntuGIS, DebianGIS, liveCD use OSGeoMatrix as the core for building their own distributions, which in turn will ensure that testing, bug fixes etc all feed back into the core repository.
How to get involved?
Do you have a piece of the puzzle or some spare time or strong opinions on how to make Ubiquitous OSGeo a reality? Let yourself be known. Speak up on the OSGeo Discussion list, or IRC channel irc://freenode.net#osgeo, leave a comment on this article, or you can contact me directly. I want to get in touch with all the key players who are required to make this happen.
References

• This idea has been bouncing around for a while, but recently resurfaced in an email thread at: http://lists.osgeo.org/pipermail/discuss/2007-October/002617.html
• UbuntuGIS
• DebianGIS
• LiveCD
  
• James Fee's blog talking up UbuntuGIS
• Matthew Perry's blog explaining how to turn Ubuntu into a GIS Workstation
  

Engaging the OGC in R&D

Attached is a presentation given to the Department of Primary Industries in Victoria which addressed:

• Overview of Open Geospatial Consortium (OGC) Standards
• How to engage the OGC in your Research and Development
• The Open Source Geospatial Stack which implements the standards
• Commercial Open Source Support

PDF - 2 Meg

GeospatialStandardsSpatialSciencesWorkshop3.ppt

Open Standards, Open Source, Open Data
Below is a presentation delivered at the GITA conference in Brisbane, August 2007.
It covers the benefits from using Open Standards and Open Source, how to effectively engage Open Source, sources of Australian map data, advantages of using Creative Commons licence for Open Data, and proposed extensions to Creative Commons for proprietary data.

Unfortunately I had a bicycle crash a couple of days before I was due to present and my face was too ugly to put on stage, so Tim Bowden kindly stepped in on my behalf.
PDF - 1 MByte.
Powerpoint - 10 MBytes.

Federated Geo-synchronization

Standards and tools for reliable data synchronization in Spatial Data Infrastructure and field based data collection.

Overview

This article describes the issues and technical solutions associated with Federated Geo-synchronization.

Lisasoft aims to contribute to these solutions as part of the OGC’s Open Web Services Testbed 5.2.

To strengthen and refine our requirements, we are looking for Agencies which would benefit from solutions identified here. Please leave a comment, or contact me if you are interested.

Technical Problem Statement

As spatial databases become distributed and collaboratively maintained, traditional database transaction models ineffectively handle modern scenarios.

Figure 1 Synchronising databases in a Spatial Data Infrastructure

Users require current data from remote agencies. Data may be stored on a slow or unreliable server or behind an unreliable internet connection.

Updates may come from remote field workers, trusted external organizations, or general internet users. Identities must be confirmed, updates validated and applied, or rolled back to a previous version.

Technical Design

Figure 2 Caching WFS-T in field, local and remote networks

This project will:

• Make a Spatial Data Infrastructure (SDI) fast and robust by caching remote WFSs locally.

• Provide WFS Synchronization to allow real time data updates between agencies.

• Ensure interoperability between agencies and applications by proposing required extensions to Open Standards.

• Ensure wide adoption by providing all components free as Open Source Software.

• Provide desktop and mobile, field based data collection tools.

Version WFS-T

A Transactional Web Feature Service (WFS-T) provides an OGC standards compliant web interface for downloading and updating vector features over the internet. To date the WFS-T standard doesn’t address version history.

Versioned WFS-T enables users to roll back to previous versions, track update history, check differences between updates. A versioned WFS is required to support a cached WFS.

Version WFS-T Development

Geoserver developers have developed a Versioned WFS-T by extending the WFS-T specification to include standard version attributes. As at May 2007, the Geotools version code is complete, but still in alpha state. It requires configuration web pages to ease operator use, packaging into a release and real world testing.

The extensions to the WFS-T specification need to go through the OGC standards process.

Security

Security involves: authentication (to verify who a user is) and authorization (to specify what a user can view or update).

Security Development

Geoserver has prototype authorization and authentication code. Access is provided to the level of WFS. Granular access to a layer or a specific feature is not supported. The code still requires refinement, a user interface and integration with the baseline.

Clients like Udig, Mapbuilder and OpenLayers require security logic. Some of this will be addressed during the Canadian Geographic Data Infrastructure Interoperability Pilot, due to complete October 2007.

Cached WFS-T

A Cached WFS mirrors a remote WFS locally. A Cached WFS-T also caches WFS-T updates when disconnected from the remote WFS.

A Cached WFS-T is used when:

• The remote WFS uptime is not guaranteed.

• The remote WFS connection is unreliable or unable to handle traffic required.

Cached WFS-T depends upon the Version WFS-T protocol.

Cached WFS-T Development

An alpha version of Cached WFS (read only) is implemented by Geoserver. A friendly user interface is required to bring this to COTS quality.

Minimal development is required to implement Cached WFS-T (with writes) which has a basic conflict management interface.

Business rules for managing updates and conflicts from disconnected clients will be addressed in a second development phase.

Desktop Mapper

Figure 3 JGrass desktop mapping application

Desktop Mapping offers powerful data manipulation and analysis. There are a number of clients available both proprietary and open source with varying levels of functionality and standards compliance.

Desktop Mapper Development

A prime candidate for an Open Source Desktop Mapper is UDig and JGrass which are combining forces to provide:

• User friendly mapping interface.

• Extensive map analysis tools from Grass.

• Access to numerous mapping format and data sources from Geotools.

• Extensible architecture from Eclipse

Development is required to include:

• Embedded cached WFS-T from Geoserver (developed but requires integration and testing)

• Embedded data store using H2 (in development)

• Access to images in a compressed format like ECW or JPG2000.
  

More work is required to add:

• Business logic, views and reports to manage collaborative editing and information from a versioned WFS-T.

Mobile Mapper

Field operators need to create or update geographic data while in the field.

A typical use case involves:

• Download geographic data while in the office

• Disconnect from the network

• Modify, create and delete features and datasets. Interface with a GPS to collect feature information.

• Synchronize changes with local or remote data-stores via Standards compliant WFS-T protocol.

Mobile Mapper - Tablet Development

Figure 4 Ultra Mobile PC with slide down keyboard

A Tablet or Ruggedized PC provides the same operating environment as a desktop PC. So the Desktop Mapper will port directly to the Tablet.

Integration with a GPS is the only extra development required for the Mobile Tablet.

Mobile Mapper - PDA Development

Figure 5 Mapping on a PDA

PDAs are often used for field work because they are cheaper and smaller than laptops. Along with smaller size they are also less powerful and have less storage capacity.

Cut down versions of Windows (Windows CE) and Java (J2ME) run on most PDAs.

Investigation is required to determine effort required to port the Desktop Mapper to the PDA and whether alternative development would be more effective.

Browser Editor

Figure 6 Mapbuilder, a browser map editor/viewer

Browser editors efficiently enable data collection from the public or remote workers.

Browser clients can also publish public map data.

Browser Editor Development

Openlayers and Mapbuilder are working together to produce Open Source, Open Standards Browser Based mapping client. WFS-T editing is supported but needs to include business logic associated with user authentication and access rights.

Open Standards

Multiple agencies tend to run multiple technical solutions. This is fine so long as they interoperate through Open Standards.

The Versioned WFS-T protocol will be presented to the OGC to be formalized as an Open Standard.

Open Source

Free tools reduce entry costs to a Spatial Data Infrastructure which will maximize participation.

Open Source software already provides the majority of the functionality required by this project which means tools can be built for minimal cost.

Deliverables

Essential Deliverables

Essential Deliverables are required to meet immediate customer needs. These phases are low risk as the functionality already exists in tested or prototype code.

Phase 1: Mirror remote WFS locally

• Cached WFS (view only). Builds upon Geoserver/PostGIS.

• Standard UDig for WFS viewing

Phase 2: Update remote WFS-T from remote or disconnected client

• Cached WFS-T (read/write). Builds upon Geoserver/PostGIS. Add simple update business rules.

• Standard UDig for WFS-T editing

Phase 3: Security - Role based editing and views

• Security added to Geoserver

• Role based options available in UDig

Optional Deliverables

Optional Deliverables are nice to have and involve further development with associated risk.

Phase 4: Universal Client for easy install

• UDig with embedded database (H2) and Cached WFS (Geoserver)

Phase 5: Universal Client on PDA

• Port universal client to PDA

Schedule

OWS 5.1
RFQ (5.1) Issued	May 11, 2007
OWS 5.2
Revised RFQ issued	July 9, 2007
Questions Due & Bidders’ Conference	July 16, 2007 (TBR)
Clarifications Posted	July 23, 2007 (TBR)
RFQ Responses Due	August 3, 2007
Kickoff Meeting	week of September 10, 2007
Interim Milestone	week of November 12, 2007
Demonstration Milestone	week of January 7, 2008
Final Delivery	February 18 – February 22, 2008
Commercialize product, provide support, consulting and customized solutions.	March 2008 – 2009.

Geospatial Industry moves Web Publishing to Open Source

James Free writes his observations of ESRI MVP types moving away from ESRI servers (ArcGIS Server, ArcIMS, ArcSDE) to Open Source for web publishing. The MVPs report Open Source is faster and offers better value.
This lines up with anecdotal reports I'm hearing from developers. For instance, developers on the West Australia's Landgate project compared optimized Oracle Spatial + ESRI SDE with unoptimized PostGIS and found PostGIS ten times faster for the queries they were running.

Open Standards & Open Source at SSC Conference, Hobart, Australia.

There was significant buzz about Open Standards and Open Source around the Terrapages/Lisasoft and OSGeo stands at the Australian Spatial Sciences Institute conference 14-18 May 2007 in Hobart, Australia.
Open Standards and testbeds
There was a lot of interest from a number of Government Departments in using Open Standards. Some departments like Landgate in Western Australia have already made major inroads into a Spatial Data Infrastructure using Open Standards and a lot of Open Source.
Opportunities to tap into international testbeds exist for Australian Industry and Government Departments. Investment in international testbeds allows best practices from Overseas to be deployed locally, and for local industry to break into international markets.
Federated Geo-synchronisation
Federated Geo-synchronisation involves synchronising a remote WFS locally so that the local WFS users don't require a stable internet connection.
Many people noted their desire to have this functionality for current needs. This is an unfunded thread in the upcoming OGC Testbed (OWS5) but I think there is enough desire to initiate Australian funding for this functionality.
Metadata collection
A few people, including Rob Atkinson from Socialchange Online discussed automating much of the metadata entry for Web Services, which can then be fed into Catalogs.
Rob talked about the need to create default Metadata schemas for different industries which services can subscribe to. There is room for a Research Project here, and backing implementation.
A number of agencies discussed their needs to comply with ANZLIC metadata standards. Again, there are opportunities for agencies to work together on this problem to create a shared solution.
Canadian Geographic Data Infrastructure Interoperability Pilot
The CGDI IP will provide widespread, cross agency dissemination of data which can be updated locally. This same use case is similar to the Federated Geosynchronisation required by the Australian Spatial Data Infrastructure and we should be looking to deploy results of this project locally.
Lisasoft is negotiating to build an integrated, browser based client for this application.
Open Web Services Testbed 5
OWS Testbed 5 is this year's major testbed sponsored by the OGC. There are significant opportunities for Australian Government Departments and Australian Industry to participate in these testbeds.
Open Source
Geoff Zeiss from Autodesk talked about the Open Source business. Unfortunately I wasn't able to make his talk, but heard a lot about it from enlightened people walking past our booth.
A high government official noted that it was important for the Australian government to promote Open Standards for interoperability and to a lesser extent, to support Open Source to promote adoption of technologies being developed.
We announced our Commercial Support for Open Source Geospatial Software. This attracted a lot of positive response. One techie noted that he would be recommending his department buy support after he left so that his applications would keep running. Another talked about having problems running Open Source applications after their key techie left. We hope Commercial Open Source Support will provide the stepping stone required to migrate to Open Source.
Open Source Education
We had a fruitful conversation with Anthony O Flaherty from South Australia TAFE. Anthony noted that some of his students were using Open Source and was happy to encourage it. We pointed out that we'd be happy to provide industry relevance to his training and would be looking at his graduates in future when hiring. In particular, we pointed Anthony at Ian Turton's Open Web Mapping Course.

The Economic Motivation of Open Source Software: Stakeholder Perspectives

Dirk Riehle provides an excellent explanation of business behind Open and Closed Source Software: http://www.riehle.org/computer-science/research/2007/computer-2007-article.html.

LISASoft/TerraPages apply these Open Source business principles to Geospatial Software. LISASoft provide value using Open Source Geospatial Software.

Using free Open Source allows Systems Integrators to increase services or reduce price.

The price of dominant, closed source software reflects market demand rather than development cost. As open source projects mature, their cost undercuts closed source competitors. Dominant projects are forced to use lock in tactics or to open source as well.
Many Open Source Geospatial Products offer equivalent functionality and quality to existing dominant Closed Source products. Initial costly development is complete and Open Source offers better value for money.

Open Webmapping Course

Ian Turton has completed an Open Web Mapping course well worth studying:

... I was busy writing and delivering a new course for PennState on Open Web Mapping. Finally its all over and its time to give back to the community first there is a page of student projects the majority are a built with GeoServer and MapBuilder at http://webmapping.mgis.psu.edu/mapbuilder/demo/index2.html. PennState has also generously agreed to give away the course ware under a CCSA license so you can all see what I've been saying about your projects at https://courseware.e-education.psu.edu/courses/geog585/content/home.html. If any one would like to take the two case study lessons and roll them in to tutorials you're welcome.

In general all the students were very happy about the quality and ease of use of the open source tools they used, mostly they wanted more MapBuilder documentation and more projections.

WebService Security - Problem Description

Background
We offer web based services like Web Map Service layers and Geocoders to developers and organisations. We need to associate Web Service requests to Web Host customers for billing purposes.
Web pages which use our web services (at the Web Host) will be implemented by third parties. The services should be available via a simple javascript API.

Actors
Web Service - Application or service on offer
Web Host - Actor offering application or service to end user
Browser - The End User

Statement of Problem
To provide Web Hosts a secure, online service to our Web Services, for their end user Browser applications. A Web Host must be authorized as having access to the Web Service requested.

Once authorization is established, the Browser will be allowed use of the Web Service on behalf of the Web Host. The Browser will have access to the Web Service.

Authorization must be invisible to the Browser, the authorization is between the Web Host and Web Service. This may require distinction from how the Browser interacts with the Web Service once authorized. The Browser must be informed if authorization fails.

Web Service Access levels supported is allow or deny. Tiered level of access is not addressed yet. Access of data and services will be determined by the web service.

Multi touch interface

Here is an excellent interface for viewing maps - even if it has been around for ages. Project the maps on the wall, then move the maps around by stroking the wall with your hands.
http://www.bassictech.com/blogs/bassictech_news_blog/archive/2007/01/20/remapping-the-universe-using-this-gui.aspx

Why Gender Matters

I listened to a very interesting arguments against co-education of children based on boys and girls sight, hearing, and smell being wired differently which caused them to learn differently.

http://www.abc.net.au/rn/lifematters/ Monday 22 January.

Interviewee was Leonard Sax, http://www.whygendermatters.com/#1

Summary
Forget everything you think you know about gender differences in children. Forget "boys are competitive, girls are collaborative." In recent years, scientists have discovered that differences between girls and boys are more profound than anybody guessed. Specifically:

The brain develops differently. In girls, the language areas of the brain develop before the areas used for spatial relations and for geometry. In boys, it's the other way around. A curriculum which ignores those differences will produce boys who can't write and girls who think they're "dumb at math."

The brain is wired differently. In girls, emotion is processed in the same area of the brain that processes language. So, it's easy for most girls to talk about their emotions. In boys, the brain regions involved in talking are separate from the regions involved in feeling. The hardest question for many boys to answer is: "Tell me how you feel."

Girls hear better. The typical teenage girl has a sense of hearing seven times more acute than a teenage boy. That's why daughters so often complain that their fathers are shouting at them. Dad doesn't think he's shouting, but Dad doesn't hear his voice the way his daughter does.

Girls and boys respond to stress differently - not just in our species, but in every mammal scientists have studied. Stress enhances learning in males. The same stress impairs learning in females.

These differences matter. Some experts now believe that the neglect of hardwired gender differences in childrearing may increase a son's risk of becoming a reckless street racer, or a daughter's risk of experiencing an unwanted pregnancy.

Since the mid-1970's, educators have made a virtue of ignoring gender differences. The assumption was that by teaching girls and boys the same subjects in the same way at the same age, gender gaps in achievement would be eradicated. That approach has failed. Gender gaps in some areas have widened in the past three decades. The pro-portion of girls studying subjects such as physics and computer science has dropped in half. Boys are less likely to study subjects such as foreign languages, history, and music than they were three decades ago. The ironic result of three decades of gender blindness has been an intensifying of gender stereotypes.

For parents, Dr. Sax provides concrete guidelines regarding the tough issues of discipline, sex, and drug abuse, and other problem areas.

For educators, Dr. Sax offers practical suggestions to help break down gender stereotypes and help all children to reach their potential.

For everybody, Dr. Sax offers a provocative analysis of how gender influences every aspect of our lives.

OSGeo stand at Linux Australia conference

I've just come off the OSGeo stand at Linux Australia. Behind the stand were:

• Tim Bowden
• Milton Lofberg
• Antel (sp?)
  
• Myself

Data
Every second person at the stand asked about data, to which we explained that there is very limited "free" data in Australia. Many of the participants were excited by the idea of an Open Street Map idea and said they would be keen to enter data if the project existed in Australia.
Education
There were a few teachers and lecturers who came past. The guy I talked to said he used the ESRI stack for teaching. It was noted that if people are to use the Open Source stack then we need to start at the educational institutions. Teachers in this area should feed their notes back into the OSGeo Education group.
Proprietary verses Open Stack
There were a significant number of questions from users of the proprietary stack about equivalent applications for their current ESRI product. I used Arron Raciot's slide which shows a comparison between stacks a number of times. This slide should be converted into a handout and/or poster.
Packaging
A guy from Red Hat offered his help to package up the Geospatial stack for the Red Had distribution. Apparently we need to look into "yum".
A guy from Gentoo showed me that QGIS is already being packaged for Gentoo. To get other packages included, we should add a bug report and set up a list of dependencies and documentation.
Wearable Computing
We chatting for a bit with Wayne Piekarski about wearable computing. He had some very sexy stuff. Wearing Virtual Reality glasses he could walk around an area and mix real backgrounds with virtual objects. There are opportunities to work with OSGeo here but we did not get much time to talk details before the crowds came and we had to go back to our tables.

5 steps for community building

An interesting article from Amy Jo Kim on what makes games and websites addictive. http://www.we-make-money-not-art.com/archives/008152.php

1. Collecting
2. Earning Points
3. Feedback
4. Exchanges
5. Customization

I see many parallels with the Open Source development I participate in.
Developers collect credibility and earn status by submitting code and answering questions. In particular, good developers are given write access to the repository - a priveledge that needs to be earned. This status is remembered when asking for help.
Feedback is provided by the community when reviewing code or following an email thread.
There are numerous exchanges over email and chat sessions where relationships are built.
Customization probably can be considered as code that is developed.
No wonder I find Open Source development so addictive.
Even so, there would probably be other ways to strengthen these drivers. For instance:

1. We could automatically collect statistics for users and display them publicly. Like lines of code written, bugs fixed, questions answered which could all be aggregated into an overall rating.
   

AJAX Vector Rendering design

Continued development of this design has moved to http://wiki.osgeo.org/index.php/AJAX_WebMapping_Vector_Rendering_Design .

This design aims to be a summary of ideas from Mapbuilder, OpenLayers, and webmap-dev communities regarding vector rendering design.
This is not supposed to be the final design, but rather draft to be used to facilitate further discussions.
My hope is that the final version of this design will be used by all the AJAX webmapping clients to make sharing the same code base easier.
I'd like to credit Patrice Cappelaere who has SVG/VML rendering working in Mapbuilder and deployed at GeoBliki. This design aims to extend Patrice's code to be more generic and extensible.
Vector Layers Class Diagram


Layer/Renderer Class DiagramThe key here is that the DataSource (or Layer) is being kept seperate to the Rendering mechanism. This is a graduation away from existing OpenLayers code which previously merged the DataSource and Rendering in the same Object.
Graphics Class Diagram
There are opportunities for collaboration with other projects/libraries in this Graphics package.
In particular:

• This Graphics library should be able to stand alone as a graphics rendering library, independant of the Geospatial side of the code. It can then be packaged up and used for other AJAX clients requiring Vector rendering graphics.
  
• ExplorerCanvas is a cross browser Canvas library. This could be extended to support SVG, WZGraphics, Flash etc.
• http://starkravingfinkle.org/blog/2006/03/svg-in-ie is worth watching too.
  

Parsers Class Diagram
MouseEvent Processing Class Diagram
MouseEvents can be attached to each SVG/VML shape. This means that we can add functions like:

• Popups when a user hovers over a feature.
• Select a feature when a user clicks on the feature.
• Select a vertex when a user clicks on a vertex. (This would require a shape to be drawn on each vertex of a line being queried).
  

Initialisation Sequence Diagram
Paint Sequence Diagram
Use Cases from John Frank
John Frank did an excellent job outlining the major use cases for Geospatial Vector Rendering:

Better vector data support in OpenLayers will help many of us. I am totally in favor of it. To reality check the proposed design, I'd like to see a few use cases sketched out. Here are a few that seem important to me. Each use case has two components: a user interface challenge and a datastructure challenge. There will typically be many solutions to the user interface challenge; I'm suggesting we think of at least one UI solution to check the proposed nouns and verbs. The canonical "user" is always a very Tough Customer, so I use that as though it were a person's name, and their initials are TC 1) An open polyline and also a point are rendered on the screen. TC wants to *add* the point to the polyline to increase its depiction of some underlying reality. How does TC specify where in the line to add the point, and how do these classes handle that insertion? Logically, the input needs to specify which existing segment of the polyline to break and replace with two new line segments. 2) Continuing one: TC wants to move an existing point in a polyline... 3) TC constructs a sequence of points by clicking in the map, and wants to see those points connected together in a polyline. Naturally, TC will construct a self-intersecting path. What is the sequence of method calls? 4) After loading several vector data layers from various sources, TC wants to merge ten different features together into one "thing" that can be stored separately. How does she do that? What happens in the code? How does it keep track of where the data came from originally? 5) After loading a vector data layer that may or may not have come with styling information, TC wants to change the styling information used in presenting that data on her map. Using some eye candy on the screen, she can input some choices, and then: what are the sequence of actions under the hood? 6) Continuing four: TC wants to change the *displayed position* of a point or a line without changing the underlying data. As cartography, each map's visual appearance communicates information that a particular scale might not permit the raw data to easily reveal. The canonical example was shown at the ESRI UC a few weeks ago: two road segments are distinct, but at a particular scale, the cartographic styling makes them appear so wide that they merge visually. The best known solution to this is to actually move one of the line's pixel position to visually indicate the merger. What is the sequence of steps and what datastructures change? How are the styling choices associated with the chosen scale? 7) After laying out a sequence of points that form a closed polygon, TC wants to know the area and perimeter of the polygon. How does this information get calculated and passed out? 8) A group of cyclists documents their summer trip in a data set with a long polyline covering four thousand miles miles and various point features with interesting styling and labels. TC wants to *play* the story in an OpenLayers map. By "play," I mean the video analogy of having a stop/play forward/play backward button, fast forward and fast backward buttons, and when the system is in action, the map automatically moves and the popups automatically appear as the map moves along the route at some scale specified in the styling made by the cyclists. What data structures represent the cyclists' details? What sequence of methods cause the movie to play? 9) TC gets assigned a task: digitize all the roads in Madagascar using this 60cm satellite imagery. How does this design make that easy? I realize that some of these may get cast out of initial designs as being too advanced for our first pass. However, I think such a choice should be made consciously.