Building an Effective open source GIS application - Chapter I

Recently I was thinking about what goes in to building of a GOOD GIS application, open source or otherwise. I have been involved in creating a number of applications, both web based and desktop, and think I am fairly adept at planning the development of such things, but what really goes in to making a useful open source GIS application. This has lead me to dedicate the next four blog posts to looking at the art of designing, developing and deploying an effective GIS using open source technologies. The first chapter touches on the pre-planning and information gathering stage, Chapter II will look at the planning stage, the third chapter is dedicated to the development phase (looking at the process and is not technical), and finally the last chapter will look at deployment and the issues surrounding this critical stage.

Chapter I: Know your audience?
There is an old adage in the newspaper industry that goes something like "Always write to the lowest common denominator". What I understand this to mean is, don't use a bunch of technical jargon which will confuse the general public. This concept is equally important when building a GIS application. You need to understand who will be using the application and what it will be used for.

I guess the first question to be asked is what does the thing need to do. This seems like an obvious question but, in my experience, many application developers don't fully understand what their application needs to do, I mean REALLY understand what it needs to do. This is not an exercise of putting a list of features together that will go into the software. That list should spawn out of a true understanding of what the software needs to accomplish and who will use it. The second part is possibly the most important question that MUST be answered prior to building the application. You must understand whether the application will be used by technical practitioners, non-technical management, non-technical other and so on. Once you understand who will use the application then you can better understand what the application must do.

Example:
Your boss, a technical GIS practitioner, comes to you and says you need to build an application that will allow the user to track a set of assets by grabbing coordinates from a GPS and giving the user the ability to update attribute values on the fly, now go build it. Sounds easy, you need to build an application that can connect to a GPS unit, read the NEMA strings (or equivalent), plot on a map, allow the user to update field values on the fly and convert to a format that can be used in other GIS or web mapping applications. Simple right? Just find out what the assets are and go build it. Now wait a minute. What kind of data collection will it be used for? Environmental monitoring? Engineering? Search and rescue? This is extremely important because it may allow the developer to limit any of the presets to values specific to the target industry. Perhaps some predefined values in pull downs to populate field values and that sort of thing. And what is the level of GIS knowledge of the user? If they are experts you may be able to build the application as a plug-in or add on for an existing application such as QGIS. These are just a couple of reasons why it is imperative to understand the end users needs.

The image on the right is a screen capture of the Quantum Navigator plug-in for QGIS. This plug-in is still in development but will be intended to track GPS input in real time and allow the user to update values, translate between points and tracks and output different data types. The application is being written in Python so will integrate with any operating system. The application is intended to give quick route analysis capabilities to the user will allowing them to add their own data and integrate open street map. This application shows great promise but is intended for the user that may be interested in looking for a optimal route from a specified location to another. This application would not provide all of the functionality that an environmental monitoring team might need for example. Now this application is intended for a very broad audience so it probably meets the objectives of its developers but it helps to illustrate the need to intimately understand your end users requirements. If you were wanting this application to be adequate for an environmental consultant, for example, you would need to add the capabilities to update attribute values and even provide a series of preset values for certain fields. Capabilities that can only be added with intimate knowledge of the intended use.

What should I ask?
So after the this seemingly endless diatribe lets try to understand who the end user is and what questions should I ask that user. So who is going to use this application? Sometimes the initiator of the project will know exactly who the end user will be and what they will user the application for. In this case you as a developer can simply ask them, "Who is the end user and what will they be using the application for". However, quite often it is unclear who all of the users will be and, if you don't know who's using it, how can you know what they need. In these cases it requires some detective work and some of the things you should know up front are:

1. What information are you hoping to gather?
2. What asset(s) is this information attached to?
3. Traditionally, who has collected this data?
4. Which GIS applications are already being used? (you should probably already know this information)
5. How will the resultant data be stored (e.g. PostgreSQL, Oracle etc.)

These are just a few of the questions that need to be asked but I hope they provide a good start. This chapter has focused on the pre-planning process, the next chapter will focus on the planning process and will hopefully answer questions like; how do I keep up with clients changing needs, who should be involved in the planning process, should I create a Gantt chart? and more.

I hope you found this chapter to be informative and will come back for the next post.