GIS-Enabled Desktop Software Development Pardigms

2009 International Conference on Advanced Geographic Information Systems & Web Services

GIS-Enabled Desktop Software Development Pardigms Ahmad O. Aburizaiza and Daniel P. Ames, PhD, PE Geospatial Software Lab - Idaho State University Idaho Falls, ID, USA [email protected]

Another example of a GIS software package that enables the use of plug-ins is the open source MapWindow GIS application and application programming interface (API). Developers from all over the world are creating various plugins to extend functionalities of the MapWindow GIS. Quantum GIS is another example of an open source GIS desktop application in which developers can assemble plugins using Python or C++.

Abstract—In the world of GIS enabled desktop software development, there are two commonly used development paradigms: the plug-in (or extension) approach and the standalone application approach. A plug-in based application runs on and interacts directly with a host application. Alternatively, standalone GIS-enabled software applications typically use modular GIS components and run independently of any host application. Each of these methods has its own advantages and disadvantages for both the end-user and the developer. Some of these are presented in this paper. Additionally, a case study is presented exploring both software development paradigms in the context of the MapWindow GIS open source software package.

III.

Keywords-GIS; desktop; enabled; development; pardigms; MapWindow; plug-in; standalone

I.

INTRODUCTION

When a new GIS desktop project is proposed by a client, programmers have at least two options to consider when developing a GIS-based or GIS-enabled software application: either to build a standalone application or to develop a plug-in “extension”. Each approach has its own challenges and benefits for both the developer and the end user or client and, hence, it is useful to consider some of the ramifications and key issues associated with such a decision. This paper discusses some of the challenges and benefits of these two software development paradigms and presents a case study based on standalone and plug-in development tools associated with the MapWindow GIS open source software project. II.

IV.

DECISION-MAKING CRITERIA FOR DEVELOPMENT SELECTION PROCESS

This paper considers five important aspects pertaining to the decision making process of whether to build a plug-in or a standalone application. They include the GIS skill level of the end users, the GIS functions required by the client, the ease of development for the GIS developer, the access security needed by the client, and the performance of the workstations running the application. The GIS developer has to consider all these factors before deciding on the development scheme for the application demanded. Decision-makers will need to be assured that the GIS project will be developed and managed in a sound manner and that there will be measurable benefits for the organization resulting from GIS implementation [5].

PLUG-IN DEFINITION

A plug-in (also called add-in, add-on, or extension) is typically defined as a computer program that interacts with a host application to enhance a capability for a particular type of analysis [4]. In other words, developing a plug-in is expanding the capabilities of a host application. Plug-ins can usually be “turned on” and off – allowing a user to only use it when needed. When a GIS developer builds a plug-in, a host application should be running in order for the plug-in to function. As an example from ESRI products, there are many plug-ins that can run through ArcMap such as the Maplex Labeling Extension “plug-in”. Some of the ArcMap extensions are developed through ESRI and some via third party developers. Either way, ArcMap must be running all the time in order for the extensions to operate. 978-0-7695-3527-2/09 $25.00 © 2009 IEEE DOI 10.1109/GEOWS.2009.28

STANDALONE DEFINITION

GIS standalone desktop application can be defined as a software application that uses a component or a GIS API to gain GIS functionality, but it runs independently of any other executable host application. Standalone application can be easier to maintain than a plug-in based application because of the full control the developer has over the full code base [2]. A standalone GIS desktop application can be developed in different programming languages such as Java or Microsoft .NET frameworks. In the ESRI’s ArcGIS software, the GIS developer can use components in the MapObjects toolkit to develop a standalone application using Microsoft .NET framework, Java, or older component object model (COM) based languages. The GIS desktop standalone application can run separately from ArcMap or any ArcGIS product. However, the components of the ArcGIS Engine must be licensed in order for the standalone application to run.

A. GIS Skills of the End Users A GIS developer should recognize the GIS skill level of the end users who are going to use the resulting tool. It could 75

be that the end users are GIS analysts or cartographers whose everyday job is to analyze and build digital maps. In contrast, they could be users from the public who do not know anything about GIS. If the end users are regular-to-expert GIS users, a plug-in can be more beneficial for their tasks. The plug-in will run as part of a GIS host application. For instance, a GIS developer created a plug-in that imports GPS data to the host application as a point shapefile. If the end users are cartographers, they may want to carry on with GIS analyses to the created point shapefile. Since they are using a plug-in, the GIS host application is running and it should help them to continue their GIS analyses. A standalone GIS application would likely be better for non-GIS users. They often need simplified GUI and terminology to be able to use the application. As an example, if the GIS developer built a GIS tourism viewer for tourists, the tourists would not need any complicated GIS analysis in the viewer. The viewer might have large buttons with understandable words such as “Find Restaurant”, “Get Direction”, and “Cheap Hotels”; for that, the tourist will find the application easy to use.

standalone application, he/she adds a component or more to a specific development framework, such as Microsoft .NET, and assigns reference libraries; from there, the component is ready for implementation. Another advantage of the standalone method over the plug-in is the less conflict in its implementation. For example, a GIS developer may build a plug-in that would generate an output when the user clicks on the map. This means that the plug-in will function when the MouseDown event is triggered. Assuming that the core application has three other buttons that use the MouseDown Event, the developer will need to create flags to indicate that the plug-in function is the current one using the MouseDown Event. This occurs less when the GIS developer is building a standalone application because all the functions and buttons on the interface will be known to the GIS developer since the developer created everything from scratch. D. Access Security The fourth factor that the GIS developer has to keep in mind is whether the customer needs access security for the requested application. Suppose that the customer is a private government agency. They are working with a secure project and they have different user privileges utilized to access the application. It is far easier to develop a stand-alone application that has the necessary security measures built in from the beginning than to attempt to suddenly outfit an existing, open framework with security measures that only apply to the use of a specific plug-in. The GIS developer can add user authentication functionality to the GIS standalone application which will secure the application for the government agency users. Apparently, the private government agency would decline the plug-in paradigm.

B. GIS Functions Required by the Client The GIS functions required for the application play a big role in the decision-making process of the GIS development paradigm. Assume that the client requested an application that displays only three GIS layers and has only the following buttons: zoom in, zoom out, pan, measure distance, open attribute table, and function X. All of the requested buttons are mostly implemented in any GISenabled desktop package except for function X. For such a scenario, the first option of developing a plug-in will save time and energy. The users can run the GIS host application and activate the plug-in. The plug-in will run function X and the rest of the functions will run through the GIS host application. A second option is to build a standalone application to apply the same functionality. This option would take the GIS developer longer period of time and would be more costly since the GIS developer has to implement function X and the other GIS buttons requested. Another example is where the client wants a tool that should operate many functions which are not implemented in the GIS host application. In such a case, the GIS developer has the choice of building either development paradigm depending on the client preference.

E. Workstation Capabilities Another consideration of the decision-making process is the performance capabilities of the target workstations where the client will install the application. Memory (RAM), hard disk, processor speed, and video cards all play roles in the performance of the workstation. Assuming that a client requested a GIS tool and emphasized that the GIS users in his/her agency have low-performance workstations; furthermore, the agency is not planning to upgrade the workstations in recent time. The GIS developer would consider building a light weighted application. In this case of a plug-in, the plug-in itself is usually lightweight, but it still requires that the host application is actively running for it to work. Most GIS host applications are memory intensive. Using the plug-in method would cause end users to suffer slowness. On the contrary, if the GIS developer built a GIS standalone application, there is no need for a heavy GIS host application to be active. As a result, the performance of a GIS standalone application will normally be faster and more convenient than a plug-in.

C. Ease of Development for the GIS Developer Starting with the plug-in paradigm, many GIS developers prefer to use the existing core functions in the host application and implement only the unavailable functions requested by the client. For instance, the functions: “Save Project”, “Open Project”, and “Print Map” can be used in the plug-in code through the already implemented core functionality of the host application. Alternatively, setting up the framework environment to develop a plug-in is usually harder than to set it up for a standalone application. When the developer is building a GIS

76

V.

associated with the map components such as: legend, north arrow, scale bar, title, description, etc., the standalone Hiking Trail Difficulty Analysis Tool does not support this functionality. As a result, if there are limited GIS functions needed for the application, standalone can work properly for the user. But if the client has experienced GIS users who can utilize other GIS functions, the plug-in would be the perfect choice for the end users.

CASE STUDY “MAPWINDOW GIS”

MapWindow GIS is an open source GIS application under the Mozilla Public License, started at Utah State University, Logan, Utah. Currently, the development team resides in the Geospatial Software Lab in Idaho State University at its location in Idaho Falls, Idaho. Since MapWindow GIS is an open source software package, developers may configure, use, and improve the software code for their specific needs. MapWindow GIS developers can use both GIS desktop paradigms of development: standalone applications or plug-ins. For a case study in software development paradigms, two tools were created using the MapWindow GIS project components and APIs. Both were built to solve the same problem – extraction of terrain data from a digital elevation model file along a polyline. In both cases, the user can draw a polyline on the map using the mouse. Then the main function is to display the distance of the line and the changes in elevation along the track. The technique of comparing the plug-in and the standalone application will use each of the previous discussed criteria in steps 4A through 4E. Fig. 1 shows a snap shot of the Path Analyzer Plug-in along with the MapWindow GIS application interface. Fig. 2 has a snap shot of the Hiking Trail Difficulty Analysis Tool.

C. Ease of Development for the GIS Developer There are two main aspects that concern the GIS developer from which to choose between plug-in and standalone paradigms. The first is whether the developer wants to implement everything from scratch, as for the standalone implementation, or to use some of the existing core functions of the MapWindow GIS, as for the plug-in development. Second, the GIS developer has to have in mind that when implementing the different functions or sub procedures in the plug-in interface, there should be many flags to make sure that the event-calls of his/her plug-in are not conflicting with other event-calls by other plug-ins or core functionality. When a GIS developer is building a MapWindow plugin, there is an interface generated automatically with different sub procedures and properties such as: Initialize, ItemClicked, MapMouseDown, and ShapesSelected. The developer can implement only the sub procedures and properties required for the plug-in. For example, the code shown below can be the implementation of the MapMouseDown event. Through this code, the user is able to get the X and Y coordinates where ever one clicks on the map and the coordinates will appear on a message box.

A. GIS Skills of the End Users Starting with the plug-in interface in Fig. 1, the main window is the MapWindow GIS application interface. The main menu of MapWindow GIS has the plug-in menu where the user can check the Path Analyzer Plug-in to activate it. The user has to use MapWindow GIS core interface to load the GIS data. Then, the Path Analyzer plug-in is used to draw the line and retrieve the output. For non-GIS users, the terminologies used in MapWindow GIS application and the steps of preparing the GIS layers might be confusing. As for the standalone interface in Fig. 2, all the commands that the user needs are displayed as relatively large, self-explanatory buttons. All components including statistics output can be displayed in one window. There is no need to activate a plug-in to enable extra functionality. Accordingly for non-GIS users, the standalone option will most likely be more comfortable to use and understand. On the other hand, GIS regular-to-expert users can use either pattern since they are familiar with GIS terminologies and major GIS applications use.

Dim XProj, YProj As Double g_MapWin.View.PixelToProj(x, y, XProj, YProj) MsgBox("X = " & XProj & " Y = " & YProj)

There is a problem with the previous implementation of the MapMouseDown event. No flag is set to guarantee that the plug-in event-call would not conflict with other MapMouseDown event-calls. A right way is to set a flag, for instance “myPlugIn” as “Boolean = False”. The user must set the flag “myPlugIn” to “True” once the plug-in is active. The “If Statement” shown below will ensure that MapWindow GIS will trigger the correct call of the plug-in; for that, there is no inconsistency with other MapMouseDown event calls. The code of MapMouseDown event should be as follows:

B. GIS Functions Required by the Client Since the Path Analyzer Plug-in is running as part of the MapWindow GIS application, the user has access to all buttons and menus in MapWindow GIS. In addition, the user has the ability to activate any of the additional plug-ins available in the MapWindow Plug-ins Menu. Either core MapWindow GIS functions or other plug-ins can be applied for further GIS analyses to the output of the Path Analyzer plug-in. The interface of the standalone Hiking Trail Difficulty Analysis Tool has no more than ten buttons to use. There is a lag of use for further GIS analyses especially for GIS experts. For instance, if the user wishes to print the map

If (myPlugIn = true) then Dim XProj, YProj As Double g_MapWin.View.PixelToProj(x, y, XProj, YProj) MsgBox("X = " & XProj & " Y = " & YProj) End if

Sometimes it becomes very complicated with plug-ins implementation by setting multi flags and ending up having

77

nested “If Statements” because of the limitation of conflict between the componenets of the standalone interface. The code shown below indicates the same function in the standalone Hiking Trail Difficulty Analysis Tool:

bulky nested “If Statements” to avoid all possibilities of conflict. The code below is from the Path Analyzer Plug-in where there is a large nested “If Statement”: Public Sub MapMouseDown(ByVal Button As Integer, ByVal Shift As Integer, ByVal x As Integer, ByVal y As Integer, ByRef Handled As Boolean) Implements MapWindow.Interfaces.IPlugin.MapMouseDown

Private Sub Map_MouseDownEvent(ByVal sender As System.Object, ByVal e As AxMapWinGIS._DMapEvents_MouseDownEvent) Handles Map.MouseDownEvent

Dim CurrentLayerGood As Boolean = False

If DrawingNewShape Then . If (LastStartPtX = -1) Then LastStartPtX = Control.MousePosition.X LastStartPtY = Control.MousePosition.Y EraseLast = False Else ReversibleDrawn.Add(LastStartPtX) ReversibleDrawn.Add(LastStartPtY) ReversibleDrawn.Add(Control.MousePosition.X) ReversibleDrawn.Add(Control.MousePosition.Y) 'Update for next loop LastStartPtX = Control.MousePosition.X LastStartPtY = Control.MousePosition.Y

If g_mapWin.Layers.NumLayers > 0 Then CurrentLayerGood = g_mapWin.Layers.Item(g_mapWin.Layers.CurrentLayer).FileName = currPath End If If g_mapWin.View.CursorMode = MapWinGIS.tkCursorMode.cmSelection Then lastSelectedIdx = -1 If CurrentLayerGood Then If g_Chart.Visible Then showPathStats(Nothing, -1) End If End If

EraseLast = False End If

ElseIf g_mapWin.View.CursorMode = MapWinGIS.tkCursorMode.cmNone Then If isDrawing And CurrentLayerGood Then If Button = 2 Then ClearTempLines() AddPathToShapefile() Else 'add new draw point Dim currPoint As New MapWinGIS.Point Dim locx, locy As Double g_mapWin.View.PixelToProj(x, y, locx, locy) currPoint.x = locx currPoint.y = locy lstDrawPoints.Add(currPoint)

Coordinates.Add(e.x) Coordinates.Add(e.y) End If End Sub

In short, the GIS developer must be more careful with conflicting the events and sub procedures calls when developing a plug-in. In standalone implementation, the GIS developer is the master of the whole application, and it will be much easier to track conflicts within the code implementation.

If (LastStartPtX = -1) Then LastStartPtX = System.Windows.Forms.Control.MousePosition.X LastStartPtY = System.Windows.Forms.Control.MousePosition.Y EraseLast = False Else ReversibleDrawn.Add(LastStartPtX) ReversibleDrawn.Add(LastStartPtY) LastStartPtX = System.Windows.Forms.Control.MousePosition.X LastStartPtY = System.Windows.Forms.Control.MousePosition.Y

D. Access Security The Path Analyzer Plug-in is one of the plug-ins that can be downloaded from the MapWindow GIS website http://www.mapwindow.org. The trend of plug-in development in general is for GIS users all over the world to be able to download it and add it to the plug-in list in the GIS host application. It is unlikely for a plug-in to have user authentication for access. The Hiking Trail Difficulty Analysis Tool does not have user authentication functionality because the developer was not requested to implement it. Still, it would be more reliable for the standalone paradigm to have user authentication functionality than for the plug-in development.

EraseLast = False End If End If End If End If

E. Workstation Capabilities As for any GIS application viewer or editor, MapWindow GIS application is large in size. For lowperformance workstations, MapWindow GIS might take a long time to load. The Path Analyzer Plug-in has to run

End Sub

As for the standalone Hiking Trail Difficulty Analysis Tool, the same sub procedure of MouseDown has smaller

78

through MapWindow GIS. The plug-in scheme would cause more slowness in low-performance workstations. The Standalone Hiking Trail Difficulty Analysis Tool is much lighter in weight compared to the MapWindow GIS application. There are fewer libraries loaded with the Hiking Trail Difficulty Analysis Tool compared to the MapWindow GIS since, MapWindow GIS has more functionality attached to it. Thus, for low-performance workstations, the standalone will be faster and more reliable. For high-performance workstations, either the plug-in or the standalone tool will work consistently upon the client preference. VI.

functionality is available in the host application. A Standalone application, on the other hand, is better for nonGIS users and for clients who require user access authentication on their application. As for the ease of development, each scheme has its own returns and drawbacks, several of which have been presented here and discussed in the form of the MapWindow-based case study. REFERENCES [1] Anselmo, A., “MapWindow Plug-in Development Sample Project: Simple Path Analyzer Plug-in”, Free and Open source Software for Geoinformatics (FOSS4G), Lausanne, Switzerland, 2006.

CONCLUSION

In conclusion, at least two GIS application development paradigms–both of which make use of existing libraries and toolkits–are available to software developers. Choosing the best option (plug-in versus standalone) may not be a simple task. Each project has its own circumstances and conditions, as well as associated benefits and challenges. There are several factors that affect the decision-making of the method used, either plug-in or standalone. Five of the potential factors are presented here including the end user GIS skills, the functionality required by the client, the ease of the development for the GIS developer, the access security needed from the GIS client for the application, and the performance of the workstations where the client tend to install the requested GIS tool. In our view, the plug-in paradigm is more suitable for highly skilled GIS users and when most of the required

[2] Campagna, M., GIS for Sustainable Development, CRC Press, Boca Raton, FL, USA, 2006, pp 147 [3] Michaelis, C., “MapWindow GIS ActiveX Control Sample Project: Data Visualization Tool Free and Open source Software for Geoinformatics (FOSS4G), Lausanne, Switzerland, 2006. [4] Steinberg, S.J, GIS: Geographic Information Systems for the Social Sciences: Investigating Space and Place, SAGE, Thousand Oaks, CA, USA, 2006, pp 157 [5] Wyatt, P., and Ralphs, M., GIS in Land and Property Management, Taylor & Francis, London, UK, 2003, pp 336

Figure 1. The Path Analyzer Plug-in along with the MapWindow GIS

Figure 2. The Hiking Trail Difficulty Analysis Tool

79