Geospatial Design Methodologies

Geospatial Design Methodologies

Geospatial design incorporates the basic planning, structure, and features associated with different systems. The geospatial design will change depending on the type of project, application of the project, size of the project, and management. Several different geospatial system designs exist – as outlined below (see also Ananda et al. (2016) for more information).

Design 1:
Rebecca Sommer, 2001: quick guide to GIS implementation and management.

This is a general introduction to GIS design and includes various aspects of GIS. It is intended to provide a framework for approaches to GIS implementation and management. Therefore, the workflow or a subset of the workflow may have multidisciplinary applications (Figure 1).

Figure 1: The GIS design by Rebecca Sommer that outlines the GIS design process in two stages: GIS implementation and GIS management.

Credit: Brandi Gaertner © Penn State is licensed under CC BY-NC-SA 4.0. See also Somers, R. (2001) and Ananda et al., 2001.

Design 2:
Harmon, 2003. The design and implementation of geographic information systems. (Harmon & Anderson, 2003).

This GIS Design provides a more detailed methodology, and includes some business related steps and more specific geospatial design steps.

Figure 2: The Harmon (2003) GIS Design, which includes Needs Assessment, GIS Database, Implementation, Organization, and managing, as well as, specific details related to IT requirements such software, hardware, networks and business requirement such as staffing and user roles.

Credit: Brandi Gaertner © Penn State is licensed under CC BY-NC-SA 4.0. See also Harmon, 2003 and Ananda 2016. Note* Book not available through PSU library, however, book contents are publicly available.

Design 3:
Tomlinson, R. F. (2007). Thinking about GIS: geographic information system planning for managers (Vol. 1). ESRI, Inc.

This design incorporates detailed processes and relationships, as well as management and business steps and solutions.

Figure 3: The Tomlinson, 2007 GIS Desing approach, which includes a business and management approach.

Credit: Brandi Gaertner © Penn State is licensed under CC BY-NC-SA 4.0. See also Tomlinson, 2007 as well as Anada et al, 2006

Figure 4: The design followed in this course, which includes several components of each of the design illustrated in Figure 1-3.

Credit: Brandi Gaertner © Penn State is licensed under CC BY-NC-SA 4.0

When Design Goes Awry

So now that we've covered a few basics on good design, here are a few situations that can cause designs to fail:

Little/No Design Effort

This is probably the most common issue with respect to geospatial system design. Sometimes, there just isn't any money in the budget to really spend time thinking out and evaluating what should be implemented. Some customers don't see the immediate value in spending money on what may be perceived as an intellectual effort, when, in fact, it is essential for success to have spent some serious attention on design issues.

Design After The Fact

 Another common problem is the "Tool In Search Of An Application" that I'm sure all of you have encountered from time to time. Someone starts with a simple idea (e.g., a web mapping tool to disseminate emergency management information); a consulting group takes on the task and delivers what they think will work well. Eventually, a real person uses the tools, and it becomes clear that the tools do something new and exciting, but not something terribly useful. This leads to two related issues, first "I know what they need" and second "Build it and they will come." Both of these can lead to a lack of adoption, user resentment, and poor management acceptance and investment.

Scope Creep

Taking some time to design a new system can reveal all sorts of opportunities for new tools, data sources, output formats, etc... A common problem is managing all of the possibilities adequately so that the scope of the project does not continuously increase over time. The design focus may start with a relatively small problem area, and as momentum on the project builds, decision-makers and stakeholders all chime in, until eventually, you are responsible for designing One System To Rule Them All that is all things to all people.

References: