\title{Mapbuilder}
\maketitle

\begin{description}
		\item  [Period covered by report:] Jan-Dec 2007 
		\item  [Contact name:] Cameron Shorter 
\end{description}
 
\section*{Introduction}

This document summarises the state of the Mapbuilder project and it's relationship with projects around it.  It doubles as Mapbuilder's OSGeo annual report.\footnote{For the complete Mapbuilder report including metrics and graphs see: \url{http://docs.codehaus.org/display/MAP/Strategic+Direction+-+February+2008}}

Community Mapbuilder is a browser based, standards compliant advanced web mapping client and framework.


2007 has been a solid year for Mapbuilder which has grown into a mature, stable project. Many new features have been added, there has been significant collaboration, sharing of code and developers with OpenLayers and our Project Steering Committee has steadily grown.

 
\section*{Mapbuilder related to other OSGeo projects}
 
\subsection*{OpenLayers}

\href{http://OpenLayers.org/}{OpenLayers} is a browser based mapping library while Mapbuilder is more of a \href{http://en.wikipedia.org/wiki/Framework}{framework}. OpenLayers provides one Javascript API which can access multiple data sources: Google Maps, Yahoo Maps, MSN Maps, WMS, WFS, Tiled Cache, KML, GML, etc. OpenLayers has a strong community behind it and its feature set continues to grow. If I were writing a SWAT analysis, OpenLayers could be listed under ``Threats''.


 There has been significant collaboration between OpenLayers and Mapbuilder. Developers from the two projects regularly and openly share ideas and code and make adjustments to ensure functionality is useful for both projects. Many developers contribute to both projects. Recent areas of collaboration include:
\begin{itemize}
	\item Sharing design ideas
	\item Vector Rendering
	\item Styling
	\item Projection (Proj4js)
	\item KML layers
\end{itemize}


 Mapbuilder differs from OpenLayers by:
\begin{enumerate}
	\item Using a Model/View/Controller design pattern in the client, which means that multiple widgets (views) can present data from one model in numerous ways, or one widget can aggregate data from multiple models. There is no dependency between widgets, so a designer can add/remove widgets without effecting the overall Mapbuilder framework. \begin{enumerate}
	\item Mapbuilder is good at handling multiple models which drive interdependent widgets.
\end{enumerate}

	\item Most state is stored as XML inside the model. Consequently: \begin{enumerate}
	\item Using XML makes transactions with XML based web services simpler. In particular, standards based OGC services are mostly defined as XML and there is no loss of information round tripping XML-$>$JS-$>$XML.
	\item XSLT can be used to transform Models to views or transactions. XSLT is easier to work with than Javascript transformations from XML to Javascript then back to XML again.
\end{enumerate}

	\item OWS Context: Mapbuilder stores state in OWS Context format. OWS Context is a draft OGC standard for describing layers and an AreaOfInterest from multiple data sources. It can be shared between supporting clients (like uDig).
	\item The configuration of Mapbuilder is stored in an XML file making it easy to develop a Mapbuilder application and migrate an application from one version to the other.
\end{enumerate}


For less complicated web mapping applications, OpenLayers should be considered.


 
\subsection*{Mapbender}


\href{	http://www.mapbender.org/Main_Page}{Mapbender} is another OSGeo webmapping client.


 
\subsection*{Web Services}


 Mapbuilder acts as a client to WMS and WFS services like \href{http://geoserver.org/}{Geoserver} and \href{http://mapserver.gis.umn.edu/}{Mapserver}. In particular, Mapbuilder shares examples with OpenLayers which makes it easy to test both applications.


 
\subsection*{Heavy clients}


 Mapping systems usually need a light, web based client, as well as functionally complete desktop applications like uDig, Jump, OpenJUMP, etc.


 
\subsection*{Key Accomplishments}


 \textbf{Feb 2006:} OSGeo was founded with Mapbuilder one of the founding projects. The extra visibility meant the number of Mapbuilder downloads doubled overnight.


 \textbf{Oct 2006:} Mapbuilder was the second OSGeo project to graduate OSGeo incubation. This involved a code license audit, and refining and documenting our processes:


 \textbf{Dec 2006:} GML Viewer client completed as part of OGC Testbed OWS4. This project introduced OpenLayers as a rendering engine and developed vector rendering in conjunction with OpenLayers.\\ 
 started serious collaboration between OpenLayers and Mapbuilder as the projects shared the development of cross-browser vector (GML) rendering.


 \textbf{2007:} Migration to OpenLayers' rendering engine completed. Through OpenLayers, Mapbuilder has access to the multitude of different layers types: WMS, WFS, Google Maps, MSM Maps, Yahoo Maps, GML, KML, ...


 \textbf{2007:} Mapbuilder's re-projection code was re-factored and migrated to its own library so that it can:
\begin{enumerate}
	\item Be used by other AJAX libraries - the code is currently being incorporated into OpenLayers.
	\item Use re-projection as a service.

\end{enumerate}


 \textbf{2007:} Internationalization. Mapbuilder uses a language lookup table for all user messages.


 \textbf{2007:} \href{http://docs.codehaus.org/display/MAP/Commercial+Support}{Commercial Support} officially provided.


 
\section*{Areas for Improvement}


 Mapbuilder needs to define and sell its market position with respect to other webmapping clients, particularly OpenLayers. OpenLayers has attracted many of the potential Mapbuilder developers at the low end of the market. Our next focus needs to be on make Mapbuilder functionality accessible to OpenLayers developers, enabling Mapbuilder to be an extension to OpenLayers. This is to be achieved by moving Mapbuilder to use the same inheritance model as OpenLayers. (Some work has already been done in this area. For instance, projection code has been restructured to make it accessible to OpenLayers).


 While Mapbuilder's documentation is now passable and has most issues covered, there is still room for improvement.


 
\section*{Opportunities for help}


 Key areas where people can help Mapbuilder include:
\begin{enumerate}
	\item Marketing, including demonstrating Mapbuilder functionality at conferences, providing workshops etc.
	\item Focusing documentation. Refining the documentation to be easier to use. Writing and refining tutorials.
	\item Integrate codebase with OpenLayers, to enable OpenLayers users to use Mapbuilder.

\end{enumerate}


 
\section*{Outlook for 2008}


 Expect to see:
\begin{enumerate}
	\item proj4js spin off into a separate project
	\item Reshaping of Mapbuilder as a framework which complements OpenLayers and makes it easy for OpenLayers users to access Mapbuilder functionality. This is a good opportunity for a Google Summer of Code student.
	\item Extension of Mapbuilder's testing process to include TestAnotherWay, as used by OpenLayers. The will complement Mapbuilder's existing testing which targeted at the integration level.\\ 


\end{enumerate}

\noindent [For the complete Mapbuilder report including metrics and graphs see \href{http://docs.codehaus.org/display/MAP/Strategic+Direction+-+February+2008}{here}.]\footnote{Complete Mapbuilder report: \url{http://docs.codehaus.org/display/MAP/Strategic+Direction+-+February+2008}}
