Please consult this list of frequently asked questions before contacting SpaceStat support or requesting further information.
Why are there never any problems in SpaceStat?
Just kidding.
The opening screen and menu look weird (strange characters).
The ansi.sys device has not been properly specified in the config file. This must be done or else the DOS screen characters will not be recognized.
SpaceStat does not recognize the data set and/or the SpaceStat data set is corrupt.
After the screen issue, this is the most common problem with SpaceStat. It is almost always due to the presence of missing values and/or characters in the input file (other possible causes are typos in the number of observations and/or variables and extra variable names without matching data — when creating the data set from an ASCII file).
The file name for the ASCII input file should conform to the "old" DOS standard (max 8 characters). Also, SpaceStat does not recognize characters in the input file other than in the variable names.
The missing value problem often occurs when a SpaceStat data set is created from an ArcView shape file (using the SpaceStat Extension) and the latter contains some missing values. The "fix" for this problem is to avoid loading the variables with missing values into SpaceStat (do not use "all" variables, but select them explicitly) or to remove the observations with missing values from the shape file in ArcView.
To check for potential problems with the data set, always list a subset of the variables/observations explicitly after creating the data set. Problems will be apparent as mismatches between what you expect (e.g., an integer value for a county code) and what is present (e.g., the income is given as the county code). Another quick diagnostic is to run simple descriptive statistics on the data: unexpected values for min and max will typically point to problems.
Spatial weights file not recognized.
Spatial weights must follow the specified formats (either gal or gwt as ASCII files or fmt as binary files) and be indexed by observation number or by an index variable that has a one-to-one correspondence with each observation in a matching SpaceStat data set. Problems occur when mismatches are present between the values for the index variable in the weights file and the values in the data set. This can be caused by a number of factors, such as typos, missing data set for the index variable, mismatches between the number of observations in the data set and weights file, etc.
Fix (other than carefully editing the ASCII input files): use the SpaceStat Extension to generate both the data set and the contiguity weights from ArcView shape files (make sure that the data set contains the index variable specified for the spatial weights).
Spatial weights characteristics fail or are incorrect.
The connectedness characteristics of a spatial weights file are reported by observation number or index value. This requires the presence of a matching SpaceStat data set. When creating weights files from ArcView (using the SpaceStat Extension) the program assumes that the matching data set has the same file name as the ArcView shape file. If such a data set is not present (in the same working directory) or has a different name, the input gal file must be edited to reflect this (change the default name for the data set to the correct one).
Note that after you edit a gal or gwt file (e.g., to add or remove a link between observations), you must delete the matching *.sum and *.tra files from the working directory or the weights file characteristics will be wrong (the sum and tra files are not automatically updated).
Spatial weights file created from ArcView shape file is missing some neighbors .
This problem occurs when the shape file has multiple polygons for the same "observation", e.g., when a county (the "observation") consists of multiple islands. Often this is an issue when the original data were constructed as an ArcInfo coverage and exported to ArcView. The SpaceStat Extension requires a single record in the shape file for each observation.
Fix: use the clean shape file function in the SpaceStat Extension before creating the contiguity weights (or clean the coverage in ArcInfo before exporting).
Out of workspace error (insufficient memory).
Memory problems are common when using or creating full weights (fmt binary format) for large data sets. Since the full matrix is loaded into memory, the extent of available memory on the system is the effective constraint on problem size. However, RAM memory is not identical to "workspace" memory since the latter can be more (using disk swap space) or less (as set in the configuration file).
The default workspace is 4 megabytes, which may not be sufficient for larger data sets. This is indicated by the following line in the gsruni.cfg file in your main SpaceStat directory:
max_workspace = 4.0 # maximum workspace in megabytes
To change this, edit this entry to the desired value (use any text editor, but make sure to save the file as a pure text file). You can make the workspace very large (e.g., 128 megs), but keep in mind that once the capacity of the physical RAM is exceeded, swap space will be used, which considerably slows down performance. You may need to do some trial and error to find the optimal mix. Also, make sure you have sufficient disk swap space available (set this in Windows or ask your systems administrator).
Memory problems with distance weights in sparse format.
Spatial weights based on inter-observation distance will take up as much memory as determined by the distance cut-off. If the cut-off distance does not induce sufficient sparsity, similar problems will appear as with full distance weights.
Error message on "some variables specified that are not in data set," but all variables are in the data set.
This will happen when the "indicator variable" option is set to a variable that is not in the data set, irrespective of whether this variable is used in the analysis at hand. For example, if you set the indicator variable to ID1 but then move on to another data set to do a different type of analysis, SpaceStat will look for ID1 in the new data set and not find it. Hence the error message.
Fix: change the indicator variable option (use F1)
Computation of Local Moran with permutation option takes forever.
The computation time for the Local Moran depends on three factors: the number of observations, the number of neighbors for each observation and the number of permutations. The most crucial of these is the number of neighbors: for spatial weights structures that have many neighbors for each location (e.g., more than 10 on average) the permutation algorithm slows down considerably.
Note: never use a full distance based spatial weights file with the Local Moran.