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.

Dunbar number - size of effective groups

Very interesting talk by Christopher Allen at http://www.itconversations.com/shows/detail1072.html

"The Dunbar number is a measure of the cognitive limit to the number of individuals with whom a person can maintain stable relationships. The concept has intrigued sociologists and anthropologists since it was first recognized as the correlation between brain capacity and group size in primates. In this talk, social software observer Christopher Allen discusses the interesting implications the Dunbar number theory has for the gathering of humans on line in the digital age. "

The dunbar number = 150. Number of people in an effective group based on amount of time that you need to dedicate to social grooming.
Group sizes:
* Small < 10. Intimate. Good size for chats sessions.
* Medium ~ 100 people. Email lists. Wikis.
* Large > 150. Trust needs to be built into the application. (Eg like slashdot)

Business Model for Measurement Repository tool using Open Source

ADI should build a business around the Measurement Repository tool it is building by using an Open Source business model.
ADI is about to develop an in house Measurement Repository tool to address CMMI requirements for project measures.
This will be an effective, professional tool that has the potential to be sold to the broader community. There are currently no plans to sell the tool as the cost of promotion probably outweigh potential sales.
ADI would do well to Open Source the core Measurement Repository software and make money by selling services to the Software.
Key benefits from open sourcing the software include:

• ADI can sell software module enhancements for enterprise customers.
• ADI can sell support to enterprise customers.
• Open source developers will enhance the software and ADI will benefit from these enhancements.

Key requirements needed to make this business model a sucess.

• The software needs to be built upon Open Source components so that users can download a free product.
• ADI needs to retain ownership of the source code.

An excellent example of how this business model has been applied is Sugar CRM as explained in an interview at http://www.itconversations.com/shows/detail1137.html.

How to innovate in a large company

For a large company to behave as inovators, it needs to set up small, disconnected divisions within the company which can act like a startup company. This is the theme of a speech by Mark Bregman, chief technology officer of Symantec. http://www.itconversations.com/shows/detail1032.html
My employer could do well to take note. Two of my employer's key values are:

• Develop People
• Behave as Entrepeneurs and Innovators

I've been actively trying to build a new business line within my company based on building Geospatial Open Source solutions. My goal has been to win small contracts, build credability and then become a contendor for larger work. We have had a few wins but have had more lost opportunities because:

• The opportunities are small and have not been given the priority required for small jobs.
• The processes of large contracts are being forced upon small jobs and making ADI uncompetitive.

Typically, large companies buy small innovative companies to get inovation into their product suite. However this has downsides:

• It is usually difficult to retrofit products from the small company with existing products in the large company.
  
• Innovative employees from the small company are less likely to want to work in a large company without an opportunity to innovate.
  

Community Mapbuilder State Of Play - April 2006

---

1. What is Mapbuilder?

2. What big ticket items are in the pipeline?

2.1. Geographic wiki

2.2. Integrated Suite of Open Source Mapping products

2.3. Roll your own Webmapping Client

2.4. AJAX drawing tool

2.5. Lots of extra widgets and features

3. Managing growth

4. Funding

5. Integrating with projects around us

5.1. Web mapping clients

5.2. OpenStreetMap and other Geowikis

5.3. Basemap providers

5.4. AJAX Engines

5.5. Geoserver

5.6. UDig

5.7. Open Web Services Testbed (OWS4)

6. Areas for improvement

6.1. Documentation

6.2. Testing

6.3. Core code

6.4. Managing new developers and funding

6.5. Visibility

Abstract

This document summarises the state of the Mapbuilder project and it's relationship with projects around it, identify upcoming features and opportunities, and suggest where to focus future effort and funding to maximise Mapbuilder's potential.

There has been a significant increase in developers downloading and extending Mapbuilder code. To maximise Mapbuilder's potential for developers, users and sponsors, the focus of core developers should move from development toward supporting and mentoring new developers. Similarly, sponsors should dedicate part of their funds to Mapbuilder mentors. Sponsor one mentor and you get five developers for free.

1. What is Mapbuilder?

Mapbuilder is a modern, web based geographic mapping client. It's modular design has made it easy for developers to build an every increasing library of widgets and tools to plug into Mapbuilder. In particular, Mapbuilder stands out from other Webmapping clients because it allows users to draw vector features on a map then load the feature into a Transactional Web Feature Service.

Mapbuilder is built upon OGC standards and hence is interoperable with many other Geospatial applications.

Mapbuilder has grown a strong, diverse and active developer community and as Mapbuilder reaches it's 1.0 release it is being recognised as a quality product. Mapbuilder is bundled with Geoserver, an Open Source Web Map Service (WMS) and Transactional Web Feature Service (WFS), and Mapbuilder was selected as one of the founding projects for OSGeo, the Open Source Geospatial Foundation.

2. What big ticket items are in the pipeline?

2.1. Geographic wiki

Web Mapping to date has focused on Publishing mapping data. Feature entry functionality is being added to Mapbuilder which will allow users to create, edit, then upload geographic features.

2.2. Integrated Suite of Open Source Mapping products

There is a full range of high quality open source geospatial software which interacts which each other using Open Standards - however the installation and configuration of these products is still disjointed. Over the next few years, these projects are likely to integrate more closely providing easy to install and configure solutions.

In particular, Mapbuilder is currently bundled with Geoserver, an open source WFS/WMS, and there is an opportunity for Mapbuilder to be bundled with Udig to provide a heavy/light client solution.

2.3. Roll your own Webmapping Client

Imagine a web page which looked like a drawing program like Visio. On the left is a list of widgets which can be dragged onto a Pane on the right. After the user has selected and placed their widgets, the use can assign attributes like Map Layers.

http://www.netvibes.com/ uses a similar concept which made it very popular.

2.4. AJAX drawing tool

Mapbuilder has developed effective drawing functionality which would be useful for a wide range of applications. This should be factored out into a separate library so that it can be used by other applications.

2.5. Lots of extra widgets and features

Google and Yahoo Map layers, fast vector rendering of features (eg using SVG), tiled maps, and much more.

3. Managing growth

Figure 1. 

Over the last year Mapbuilder has had a steady increase in interest from developers and users. Traffic on our email lists has increased by a factor of five over the last year. Increasingly we are seeing questions from paid portal developers who extend Mapbuilder, then move on. Since most core developers work on Mapbuilder in their spare time the core developers are having problems supporting users and incorporating the user's code.

Almost all Mapbuilder queries are from developers, which is an indication that Mapbuilder documentation and installation procedures are too difficult for average internet users.

Mapbuilder's user documentation is still poor which is part of the reason for the large number of user queries. Improving documentation will empower users to answer their own queries, and will increase Mapbuilder's user base because more people will be able to use it.

4. Funding

Mapbuilder has grown to privileged position where we are starting to have access to more developers than the core team can support. To accept developer contributions, we need to provide guidance, answer technical questions, review code and incorporate additions into the code base. Part of the support can be provided by writing good supporting documentation.

If you are considering using or extending Mapbuilder, sponsoring a Mapbuilder mentor will probably make sense for you. Sponsor one mentor and get five developers for free. For a company who wants to extend Mapbuilder, I suggest you hire a developer to implement your desired features and a mentor for 1/5 of your developer's time. This will ensure your code is reviewed and incorporated into the Mapbuilder codebase and available in future Mapbuilder releases. If your desired functionality is popular, it may be more economical to just support a Mapbuilder mentor which in turn will empower other Mapbuilder developers to implement features on your behalf.

5. Integrating with projects around us

The commercial world regularly tries to out do and compete against similar projects, but in Open Source we can do much better by embracing and working together.

5.1. Web mapping clients

There are a number of web mapping clients doing similar things to Mapbuilder or with features that Mapbuilder would like to copy. The projects all contain talented software developers and we would all do better if we could share our workload and focus on one great product instead of lots of good products.

Unfortunately it is difficult to merge two code bases together and no one wants to give up a project they have spent lots of time on to go and work on someone else's code.

So what I propose is that we work toward a long term goal of merging projects. We start by gradually factoring out common libraries that we work on together, and whenever we make future design decisions, we run the idea past other projects and see if we reuse code or interfaces which will ease merging some time in the future. webmap-discuss@lists.osgeo.org has been set up to facilitate this.

5.2. OpenStreetMap and other Geowikis

http://www.openstreetmap.org/ is a project which allows users to upload tracks from GPS devices (like handheld computers or phones) into a geographic database, then provides a java applet to edit those same features. They have addresses some of the hard issues, like version control on features at the expense of breaking away from Open Standards. And they are already collecting data from users.

This is a project that would be great to work with. They have a great vision, and some good ideas. We could add value to them by providing our AJAX based web mapping client - they have a Java applet. Java applets are a stumbling block for many non-technical users because it requires them to download and install extra software into their browser. We could help them migrate toward a standards based solution, which would enable them to tap into other powerful mapping applications (like UDig).

There has been talk on Wikipedia about setting up a geographic wiki. Mapbuilder could be the tool used for a Wikipedia for geographic maps.

5.3. Basemap providers

There has been an explosion of quality free basemaps on the internet from companies like Google, Yahoo, and MSN. These companies also provide viewers which could be seen as competitors to Mapbuilder. These companies could be seen as potential sponsors for the Mapbuilder project as their code value is in their maps, not the mapping client.

5.4. AJAX Engines

Mapbuilder has built it's own AJAX software - (software which handles asynchronous loading, events, javascript inheritance etc). It is powerful, and it works, however some of the code is not very elegant, and because we were experimenting as we wrote it, we have instances where concepts like inheritance are implemented in two different ways. This makes the code harder to understand and more prone to bugs.

Since we wrote Mapbuilder, there have been a number of quality AJAX Engines written. It would be wise of Mapbuilder to replace our engine with one of the dedicated engines. The advantages would be: more reliable code, maintenance would be spread across a larger user base and we can tap into the expertise of the developers on these projects.

5.5. Geoserver

Geoserver is a Java based Transactional Web Feature Service (WFS-T) and Web Map Service. Mapbuilder is currently bundled with Geoserver which probably explains why a number of our quality developers have been attracted to Mapbuilder.

We need to ensure that Mapbuilder continues to be bundled with Geoserver and ensure that Geoserver ships with the latest version of Mapbuilder.

5.6. UDig

UDig is a powerful GIS desktop application. It would be very useful for users to bundle Mapbuilder with UDig to provide a light/heavy client option.

5.7. Open Web Services Testbed (OWS4)

The OWS4 testbed sponsored by the Open Geospatial Consortium would be an excellent opportunity to show case Mapbuilder and UDig integration.

6. Areas for improvement

6.1. Documentation

Mapbuilder's documentation needs to catch up to the quality of the code. By improving our documentation, we won't need to keep answering the same questions on email lists and will increase our user base. Increased users, means increased developers and sponsorship and a healthier project.

The catch is that the people who know the most about the code (the developers) don't need the documentation and sponsors often want to pay for a feature and move on. Good documentation is a long term investment in a project.

6.2. Testing

It is a credit to the Mapbuilder team that Mapbuilder is so stable considering that it targets the flaky browser platforms.

To date Mapbuilder has only just started looking at automated testing, however it has not been rolled out across the project. Automated testing will help ensure Mapbuilder remains stable and give us confidence to take on more developers.

6.3. Core code

Mapbuilder's code has gone through many improvements as we have pioneered and experimented with AJAX techniques. As such there are areas of code which still contain old hacks and plenty of areas where we could simplify code. This would reduce download size, reduce complexity and improve maintainability.

We should do a systematic code review and clean up and improve our existing core code, and replace some of our code with standard AJAX libraries.

6.4. Managing new developers and funding

We have become overwhelmed with new developers and their questions. This is a good thing, but we do need to change the way we do things. In particular, the core team needs to focus more on Mentoring new developers. Ideally, sponsors should consider sponsoring a Mapbuilder mentor. Sponsor one mentor, get five developers for free.

6.5. Visibility

To build the project's profile, we should present Mapbuilder at various conferences.

Issues with Google Maps and Web Map Server (WMS) Mashups

I've been integrating a Google Map layer into Community Mapbuilder - a web mapping client so that we can display Web Map Server (WMS) layers over a GoogleMap base.
However, we have run into problems with Spacial Reference Systems (or projection). A projection is a way to describe a spherical world on a flat piece of paper.
The WMS specification (as defined by the Open Geospacial Consortium) defines thousands of different Spacial Reference Systems using EPSG codes. For example, simple (lat,long) uses EPSG:4326. And a WMS request looks something like:

http://www2.demis.nl/WMS/wms.asp?wms=WorldMap&wmtver=1.0.0&request=map&layers=Builtup+areas,Railroads,Highways,Roads,Trails,Borders,Cities,Settlements,Airports&srs=EPSG:4326&bbox=-160.14,-3.37,-19.69,55.23&amp;amp;amp;amp;width=800&height=400&format=image/gif&styles=default&transparent=true&uniqued=

Unfortunately, the Mercator projection & datum used by Google Maps does not have a corresponding EPSG code.
Consequently, as far as I can work out, it is not possible to use a standard way to request a WMS map which is in the same projection as Google Maps.
Existing WMS/Google Map mashups I've seen on the web so far use EPSG:4326. This projection is reasonably close if you zoom into a city, but is out by miles if you look at a map of the world. (See images).
Recommendation

1. Google, the OGC, and the owners of EPSG codes should get together and define a new EPSG code so these two types of maps can be incorporated together.
2. I'm guessing option 1 will take a while. So in the mean time, WMS servers and WMS clients (like Mapbuilder) should define our own EPSG code to use in the interum. Maybe EPSG:Mercator?

Disclaimer
I'm a programmer, not a geographer, so I'm likely to have some of the geographic terms incorrect.
Update 30 Sept 2006
John Deck has blogged describing a work around to rendering WMS on Google Maps at http://johndeck.blogspot.com/2005/09/overlaying-mercator-projected-wms.html and then an update at http://johndeck.blogspot.com/2006_02_01_johndeck_archive.html.
Open Layers have incorporated a hack into their codebase which includes stretching the WMS layer to fit. This will still have distortion issues as the projection of the WMS and Google Map use different projections.
The best solution would still be if a new EPSG code were created for GoogleMap layers.

Why does Open Source achieve better CMMI than CMMI practitioners?

(Rough thoughs that I hope to build into an essay.)

• What is CMMI?
• CMMI level 3 involves common processes across an organisation to ease.
  
• In a corporation, this means Processes and Tools are mandated from the top of a company down. Tools are often selected and then mandated by Management.
• In corporations, innovation in processes and tools are often stifled in a drive to try and maintain common processes across the corporations.
  
• OS achieves common processes across projects without having a mandate from the top. Eg: Most OS projects are now moving to Subversion for Configuration Management.
  
• Difference: Practictioners choose their tools based on their merits. The best tools become the defacto standard.

Why can't big companies compete on small contracts?

• Big companies can't bid on small projects because they are not competative. Reason given is they have too many overheads. This should not be the case. The big company should be able to reduce overheads by using the economies of scale.
• This implies to me that Big Companies are imposing inefficient processes on their staff.
• Why can't a big company sponsor a startup division without imposing the company overhead.

Recommendation:

• Allow each business unit to pick their own tools and processes.
• Provide opportunities for business units to share experience and suggest tools.
• Allow processes and templates to be developed as if they were an open source project.

Examples:

• My experiences with CMMI and OS.
  

Similar sites to Community Mapbuilder

• http://www.favoriterun.com/ Enter a route into a Google Map. Can't edit existing maps.
• http://www.openstreetmap.org/ Load tracks from a GPS and edit them in Java Applet. Contains a wiki like history. Quite advanced. Doesn't use Open GIS standards and doesn't seem to be interested in them.
  

Basemaps

http://www.lands.nsw.gov.au/MapsAndPhotos/didgitalpg.htm for NSW.
http://www.multimap.com - A possible business partner too.
"Wim Brinkhof (E-mail)" Phone: 02 98956193
http://maps.nsw.gov.au/viewer.htm - Free cadastral basemaps of Australia. Tony Hope is the person responsible for WMS/WFS interface.
Lands contacts:

• Tony Hope: WMS/WFS person. 6332-8464
  
• Paul Fields: answered phone - sounded positive
• Gary Tauton - contract manager. Mad keen cyclist. 6332-8270