.

Geoinformatics_04-2009
article geoprocessing for many people, viewing and importing existing data is all the functionality they will need in an osgis application. for others, the ability to create data (by digitizing or programatically) and perform analysis is important. fortunately osgis is up to the task. the heavyweight in this arena is the geographic resources analysis support system, better known as grass (http://grass.itc.it). grass has been maligned in the past for a variety of reasons. in fact, grass is a highly proficient gis which is capable of sophisticated analysis. much of the past criticism has centered around its user interface (ui) and perceived difficulty of use. to be certain there is a learning curve---a manageable one, however things have improved with respect to the ui issues. quantum gis (qgis) can be used as a front-end for grass and provides access to a large number of grass modules. work also continues on a new native ui written in python and wxwindows. these projects have made grass available to a wider audience. that said, what can be accomplished with grass? in addition to viewing data grass provides: projection of raster and vector data between coordinate systems cell-based (grid) analysis, including grid algebra line of sight (visibility) analysis hydrologic modeling creation of hillshades merging rasters clipping of vector and raster data figure 1 - some open source gis applications in relation to class of user users, but has greater needs. beyond viewing, data creation, and map production, this class of user uses gis to answer questions based on spatial relationships, does cell-based analysis, and perhaps even routing and geocoding. she also may need to write programs and scripts to accomplish her tasks. with these needs in mind, figure 1 shows some of the major gui applications and where they rank. as you can see, the majority of applications have something to offer for nearly everybody. more information on the pros and cons of each can be found in the survey of osgis applications appendix of the book. command line applications "desktop gis" examines a couple of very handy command line (cli) applications for manipulating raster and vector data as well as creating cartographic output. gdal/ogr provides both a programmers api and utilities for converting, transforming, and manipulating raster and vector data. for example, a vector layer can easily be transformed from one coordinate system to another. a raster can be converted from tiff to png. these utilities provide a powerful cli toolset, as well as being integral components of scripts to perform geoprocessing on large quantities of data. in just a few lines of code, a simple shell (or python, ruby, perl, etc.) script can easily warp thousands of rasters from one coordinate system to another. gmt, the generic mapping tools, provide the ability to create high quality maps used for printing or inclusion in documents and reports. gmt includes high resolution worldwide data for coastlines, rivers, and political boundaries. gmt can easily be incorporated into scripts to generate customized maps. figure 2 is an example of a gmt generated map of the world with an overlay of quantum gis users. of course, this is not a complete list of all that can be done using grass. the other nice thing about grass is that it is fully scriptable, using shell, python, ruby, and perl, among others. projections and coordinate systems in "desktop gis" we take a look at projections and coordinate systems from a practical standpoint. this topic can be confusing when first starting to work with data that needs to be transformed prior to use. fortunately there are some good open source tools available for working with projections, including the suite of utilities that are part of the proj.4 projections library (http://trac.osgeo.org/proj). for simple calculations you can use proj, invproj, and cs2cs to interactively transform coordinates. to use a proj.4 utility you must specify the projection parameters in the proper format. the parameters for a projection can be found in the "epsg" file that is installed with proj.4. another good way to find lots of information about a projection is the spatial reference website found at http://spatialrefe rence.org. if for example, we had data in utm zone 6 that we wanted to transform to geographic, we could get the needed parameters by entering nad27 utm zone 6n as the search string to quickly find the projection. the parameters can then be copied from the website in a number of formats, including proj.4: +proj=utm +zone=6 +ellps=clrk66 +datum=nad27 +units=m +no_defs using this information, we can convert projected coordinates to geographic using the invproj utility: $ invproj +proj=utm +zone=6 +ellps=clrk66 +datum=nad27 +units=m +no_defs 312244.49 6795460.41 150d30'w 61d15'n entering the coordinate pair 312244.49, 6795460.41 results in the geographic coordinates 150 degrees 30 minutes west, 61 degrees 15 minutes north. this is fine for singular use, but in many cases you may want to 19 figure 2 - quantum gis users plotted on a robinson projection using gmt latest news? visit www.geoinformatics.com june 2009
Powered by fluidbook tm