Visualisation technical 54 PositionIT - April/May 2009 Restructuring of the MapWindow GIS project by Harold Dunsford Jr. and Dr. Daniel Ames, Idaho State University In an open source GIS software development paradigm, the availability of a robust, extensible, programming architecture can be critical to project success. Indeed, though tiered-code software development is used throughout the industry (proprietary and open source) modularity, extensibility, and internal transparency are absolutely essential when writing code in a largely volunteer, spatially distributed, programmer community. T his provides future and co-developers with a common platform that can be extended without fear of breaking other parts of the code – hence saving time and development costs, and improving the code base at a greater pace. In light of this, the MapWindow GIS project is undergoing a major restructuring to a more fully modular and extensible architecture in the context of interfaces for three-dimensional, spatio-temporal modelling. Specifically, we developed a set of base interfaces for all low level data access objects, visualisation (2D and 3D), and geoprocessing tools; and developed a set of plug-in managers for each type of interface to handle loading new functionality directly from .NET assemblies (DLLs) at run time. The result is a set of core components that provide base GIS functionality in the .NET environment, but can be easily extended by third party developers through the implementation of the base interfaces. Nomenclature for the majority of the interfaces is derived from standards published by the Open Geospatial Consortium (OGC). From the perspective of multi-platform support, a platform independent core can be extended with platform specific modules (e.g. for Mono on Linux, or Windows Mobile). Introduction The purpose of the MapWindow project is to provide a developer toolkit for the Windows platform and a fully functional mapping application [1]. Much of the success of the MapWindow project has been its easy-to-use plug-in programming environment allowing third party developers to quickly extend the application using simple languages such as VB.NET and C#. The current plug-in extensibility architecture in MapWindow is based on an “application-wide” design where each plug-in implements an interface that provides direct interaction with and access to all elements and components in the full MapWindow application. This provides a simple “single interface” approach that has proven quite usable, but has some critical deficiencies. Specifically, developers who only need to use one or two components from the full system, should not be required to implement such a large and inclusive interface. More specifically, a plug-in that only provides a new data type, or one that only provides a new geoprocessing tool, should not necessarily require implementing an interface with hooks to the GIS map, legend, or toolbar. Indeed, every custom GIS application is generally different enough that no one plug-in interface would be suitable for every conceivable configuration of modular components. The architectural solutions introduced in this paper (and implemented in the source code of the MapWindow 6.0 project) address improving the extensibility model itself by creating a series of plug-in manager components (and a much more granular set of interfaces), each one handling a narrow focus of extended functionality. We presume that the easier it is to extend a GIS platform, the more usable it will be for scientists and engineers who are not programmers. To cater to this need, proprietary software (e.g. ArcGIS) supports writing plug-ins that extend the capabilities of the software without having to re-compile the binaries or be expert programmers [2]. Many open source GIS software projects also benefit from a plug-in environment because it offers a layer of insulation between the core application required by all users, and the newest, least stable code that is actively being developed. It is therefore useful to include the concept of plug-in extensibility into a modular framework that mirrors the modular component development itself. MapWindow GIS is only weakly copyleft, allowing the use of components in both open and closed source applications, and so designing the plug-in architecture itself to be modular gives greater flexibility to developers using the MapWindow developer tools [3]. Component development presents the interesting challenge of trying to anticipate all ways people will use the software, extend it, or incorporate it into projects of their own. The solution is non-obvious because most accepted paradigms for extensibility make the assumption that a project will lie entirely within the open source or proprietary domains. It is also challenging to develop an architecture that is equally suitable to open source development (and hence maximum transparency) and proprietary derivative software (usually with restricted control). The open source aspect of the project also means that the code enabling this extensibility can not be overly complex or future programmers will likely abandon it the first time it conflicts with changes to the project layout or design. A new user of an open source GIS project might ask the question, “Why write a plug-in when you can simply download the source and modify any aspect of it to suit your needs?” However, plug-in extensibility can be beneficial for open source projects by appealing to non-programmers that want to make small improvements, and by insulating the core application from unstable new additions. Even commercial software can benefit from a modular, re-usable plug-in architecture