The Project‎ > ‎

Sustainability

This project involves assisting participants having a wide variety of backgrounds to produce their own GIS data/map products, and creating interactive web map versions of these products.

The ability of the participants to maintain and/or revise these products is another important goal of this project.

Sustainability in Desktop GIS

Given the generally straightforward mapping needs of the participants, sustainability in the desktop GIS portion of this project could mean developing and maintaining individual skills in the following areas:
  • basic familiarity with datums and map projections so that participants can recognize the native datum/projections of GIS data from outside sources and successfully convert them to NAD83 State Plane Coordinate System, Michigan Central Zone (FIPS 2112/EPSG:2252).   Most data obtained for the project area from outside sources will be in one of the following projections:

    Datum Projection Likely Source
     WGS84  GCS*  GPS tracks and waypoints, other
     NAD83  GCS  Federal gov't, NGOs
     NAD83  MI GeoRef  MI State CGI**
     NAD83  State Plane  County, consultants, NGOs
    * - Geographic Coordinate System (not really a "projection")
    ** - Center for Geographic Information (Geographic Data Library)

  • techniques using QGIS and uDig for converting above data to State Plane coordinate system.
  • intermediate-level software familiarity (QGIS capabilities most useful to participants)
  • basic cartographic layout principles (minimal map design)
The initial medium for transmitting these principles to project participants will be through individual tutoring and training in map-making using open source tools.

This website's Project Tutorials section provides follow-up documentation and write-ups specific to the needs of, and questions by, the participants.   The Resources section will list links to tutorials, videos, blogs, and other resources on the web covering general GIS and cartography, software (QGIS, uDig, and GDAL), and other useful references.

Sustainability in Web Maps

Interestingly, all of the project participants are either webmasters of their township/village websites, or have read/write privileges on their township web servers.  The same applies to the NGO participant.  This raises the possibility that the participants will be in a position to proactively maintain the web maps that have been created from their desktop GIS products.

The sustainability issue will probably be the ultimate determinant of the type web map the township decides to deploy on a regular basis.  This in turn will be determined by how maintainable are the various data files and data stores.

A case in point is shapefiles versus KML files.  Most participants will use shapefiles in QGIS for data their layers.  Once the GIS product is finished, converting the shapefiles to KML files and transferring the styling information for each shapefile (from the QGIS project) to their respective KML files allows the KML files to be used as data layers at the web mapping stage.  (It also allows the KML files to be manipulated further and converted to KMZ files to be used with Google Earth.)

KML files are ASCII (text) files with XML-style formatting tags.  Included within the rather ponderous formatting is the file's geometry information, as well as the data that was stored in an attribute table in the original shapefile.  “Description” information can also be added to each geometry feature to be used in popup balloons in Google Earth, mashups, and open web maps.  Coordinates for the geometries are expressed as WGS 84 geographical coordinate (longitude and latitude) pairs.

Because these files are text files, they can be edited without much effort by project participants if only the attribute data or descriptions need to be changed.  The KML files thus edited can be uploaded to the appropriate folder in the web server to update the map.  The same applies to other text files that may be serving as data layers in web maps (GeoRSS, GeoJSON, and others).  If the geometry needs to be edited, it may be easier (and safer) to edit the original shapefile in QGIS and then re-converting the edited file to KML or other text-based data format.

The advantages described above of maintaining a KML file in this case also applies to Google mashups.

As editing a text file is simpler than establishing and maintaining a powerful geodatabase package such as the PostgreSQL-based PostGIS, standardizing on text-based data files for web maps may be a more "sustainable" solution.

If the data file in a Google mashup web map is a Google Fusion Table, updating the fusion table may not involve much more than re-loading an edited csv (comma-separated values) file or updating a Google Docs spreadsheet, if the Fusion Table is set up appropriately.  With a bit of planning, a Fusion Table-drive mashup should also be maintainable by LUGs without too much effort.

Editing of data files can be accomplished by using tools familiar to the participants such as word processors and spreadsheets.  Such tools could include:
  • VBA macros for Excel and Word that automatically generate much of the tags and formatting
  • Application of Excel string concatenation functions in spreadsheet cells
  • Available web-based tools such as Mr Data Converter

Thus far the emphasis by the participants have been in creating new GIS data products and their associated web-based products, not in maintaining and editing these products.  The methods selected for web product maintenance are expected to be decided by the computer skill level of the participants.

This section and the various how-to articles in the Project Tutorials and Resources sections will describe these methods as they evolved in the course of this project.
Comments