Geo-spatial Modelling

Here are some of the pitfalls you might run into if you use the Geospatial Modelling Environment (GME):

1st warning: GME summarizes variables by appending them to your shapefile’s attribute table. If you don’t want all those added columns in your “one good input file,” first make a copy of your input file then use another copy to play with in GME. (I have a separate folder for all the work I do in GME, and I copy files there to use with the program. That way, I still have untarnished shapefiles left in my main folders for all my other purposes, especially if I’m doing something exploratory in GME.)

GME has a variety of input methods (common), from simple point-and-click to a scripting interface. You already know which direction I lean when interfacing with it. Save yourself some time and trouble! Your time is more valuable than that; let the computer do the repetitive stuff. Here’s a small example of a loop in GME.

1:  for (i in 2000:2013) {  
2:  isectlinerst(in="shapefile", raster=paste("path",i), prefix=paste("datatype",i), thematic=FALSE, proportion=FALSE);  
3:  };  

I have rasters that are simply named by the year they were captured (newer remote sensing data).

2nd warning (already a caveat to my earlier post…and there’s a follow-up caveat): for some reason the GME doesn’t like underscores in the prefixes?! Annoying, as it’s a pretty standard alternative to a space for computer science naming conventions. It also would allow for it to interface pretty seamlessly when importing that info into R, as it’s specifically designed to do, but hey, I guess we live in an imperfect world. Since R is so built as a stats language, “-” looks too much like a minus sign for it. All the other operators are thus out too, and anything else special character-y (like ampersands) could get too format-y for me (check out how weird they parse in HTML) to be comfortable with (but maybe I’m wrong there…maybe that would be just fine). Anyway, to me, it looks like we have no good options for special character separators (ARGH…who’s idea was that?).

3rd warning (but you’ll also just have to deal with this): R fusses when you try to import a column name that starts with a number, so avoid it. In my case, since I want to import it straight from the DBF (because I’m difficult) it’s fairly impossible to not at least throw warnings that way. So, even though the years are both…

  • the names of my rasters
  • the most important info I want

…I add a prefix that is the type of data that’s been summarized (probably smart anyway).

Until 4th warning: GME fusses again if you’re trying to do this for polygons, saying that the prefix “should be no longer than 4 characters.” So guess what? I’m just doing my year, and read.dbf will have to throw me a long list. Oh well.Special bonus: don’t try to do anything in Arc after you’ve made a col name starting with a number from GME…

 for (i in 2000:2013) {   
 isectpolyrst(in="your shapefile", raster=paste("path to rasters",i), prefix=i);   
 };  
I get the relevant info in the column names out with a regular expression in my R script. As mentioned, we can’t take advantage of any convenient splitting characters this time (sad face). For an example specific to my data, I have “VCF2000MIN” as a resulting column name from GME. “VCF” is what I came up with to not have the column name start with a number, and reminds me what variable I’m summarizing. The year is 2000, and MIN is a summary stat generated by GME.

You can also do a nested for loop (if you must). In my case, I have folders numbered corresponding to months, and annual observations for each month.

 inpath <- "C:\GIS\";  
 rasters <- "C:\grids\";  
 for (i in 5:7) {  
 for (j in 2003:2012) {  
 isectpolyrst(in=paste(inpath, "buffers.shp"), raster=paste(rasters, i, "\", j), prefix=paste(i,"~",j));  
 };  
 };  

Leave a Reply

Your email address will not be published. Required fields are marked *