mkmurray wrote:Or in other words, if you wouldn't mind, please list the most common and helpful features that one would need in GIS software (for the purpose of doing membership maps and the like).
Well, here is a modest description and primer on features I think are important. I am not trying to define all possible features of GIS systems, but focusing on what I think wards and stakes might need. Conceptually, it is helpful to think of GIS software as a conventional DBMS married to geographic objects. It's not just about drawing maps.
The sofware must read and write common GIS file formats. The most common interchange format is the ESRI-sponsored, open format called a shapefile
, which really is a collection of several physical files. (Years ago I wrote some software from scratch to read and create .shp files. I don't want to do that again.) In recent years, the Google-sponsored KML
file format also has become important, mostly as a platform for publishing maps to end-users. KML is not readily comparable to a GIS format, partly because it lacks tabular data, but it is becoming a popular display format that does define basic geographic coordinates. (I find it useful that my own GIS sofware, Manifold, will import and export simple KML. To create rich and complex KML, I write my own scripts.)
It is important to remember that just having the GIS software is not sufficient. One must also have base map data for the areas in question. Hopefully the user can locate public-domain sources for such data. Commercial map layers are expensive. A good, but not perfect, source of U.S.base map data is the Census TIGER data
, which now is being disseminated in shapefile format. Some states and localites publish their own base map data. (Luckily,my own city
is such a place. If yours is not, start pestering your local officials. They probably have this stuff internally.)
The GIS sofware should be able to read and convert a variety of map projections
-- the various schemes that geographers have devised for representing a curved planet on a flat surface. It also should be able to read and convert from one datum
to another. (A datum is a mathematical model of the Earth, which is not a sphere but an ellipsoid. Unless you know what datum you are using, you don't know precisely where a given latitude-longitude coordinate is on the planet.)
The GIS platform should provide a GUI for displaying, selecting, editing and creating basic geographic objects (points such as addresses, lines such as streets and creeks, and polygon boundaries defining such areas as counties, cities, census tracts, stakes and wards.) Typically, these geographic objects are organized into separate layers. There should be tools to transform sets of intersecting lines into poylygons, and vice versa. Also, there should be the capablity to combine such objects from different map layers into new layers. The interface should provide easy means to divide existing polygon areas with bisecting line objects or polygon subdivisions, and to merge line and polygon objects. In practice, for example, that allows a user to define a stake or ward boundary that combines streets, creeks, political boundaries and custom-created lines.
The program should provide rich options for formatting and displaying maps that are created by such dynamic processing -- both on screen, in print, and in export formats.
The sofware should provide relational tables for storing, querying and transforming text and numeric data (integer, decimal and floating point) associated with such geographic objects. For example, streets and street segments associate street names and address ranges; creeks typically are associated in network hierarchies; points might be associated with addresses and with families or indiviudals; polygon areas might have names and codes for counties, Census tracts, population values, etc. I consider a decently implemented SQL engine to be the best database platform. It should allow import and export of common tabular data formats and sources such as ODBC or OLEDB in Windows. That way, for example, all the MLS export files can be imported and manipulated as SQL tables. Some of those tables, such as addresses, would be associated directly with geographic coordinates.
The basic SQL query language also should be extended include geographic functions. One such basic function is commonly known as a "point in polygon" query -- find all points from a certain map layer that are within a certain polygon. Similar functions should exist to find lines and polygons that contain, touch or overlap each other. In addition to the query language, it is useful to have a scripting language to perform repetitive tasks, and and API is even better.
Taken together, those functions allow the user to perform such tasks as calculating the total number of members, families, priesthood holders with current temple recommends, YM/YW, etc. within a given boundary area or set of boundary areas. In performing such analysis, the user is essentially performing the same task that a legislature does when gerrymandering congressional districts. The typical method is to divide the overall area into small jigsaw pieces and recombine them in different ways to provide different possible outcomes. A legislature does this with voting precincts; stakes do this with "GEO Code" areas of their own choosing. With a GIS system, it is often useful to start with the work of others, such as the Census Bureau, or postal service, who have professionally created areas such as Census tracts and carrier routes that make intuitive sense on the ground. These can then be customized as needed. Of course it is also possible to invent such jigsaw pieces from scratch. It is also nice if the GIS package provides any easy GUI to do all that what-if querying by clicking around a base map. This is much easier than combining pieces in SQL queries.
Some GIS software offers add-on modules for geocoding. This function can be integrated, and might theoretically involve some of the same base map data. But it really is a distinct function, and I consider the choice of geocoding tools to be a separate question.
There are other nice-to-have features, such as calculating driving directions and measuring driving distances. Even if the GIS software has this functionality, it requires sophisticated base-map data that handles such things as one-way streets and freeway ramps. So it is difficult to implement well in a reasonably priced, standalone package. The online providers such as Google and Microsoft have a natural advantage there because of the expensive base maps they license from providers such as Tele Atlas and NAVTEQ.
For further GIS primer stuff, here is aWikipedia link
I'm leaving out a lot of stuff. In general, a full-featured GIS program has a lot of complex functionality. So I have no qualms about writing a check for such power if I can afford it. (That's why I like Manifold
when I am spending my own money.) I should add that the professional GIS market is dominated by ESRI
I certainly can't afford ESRI's flagship products myself, and its price tag would make a stake president blanch. Another significant commercial player is MapInfo
, which my state agency uses for its web site and some desktop mapping. I like the feature set of Manifold better, so it is on my desktop at work.