Below is a list of common problems and solutions related to GeoDa (access a complete list of questions and comments posted to the Openspace mailing list at the Openspace archive). It includes known bugs and problems as well as file-related problems and error-related user questions (a bugs-only list is also available).
If the problem you are facing is not addressed on this page, please post your question on the Openspace mailing list.
Most of the links in the help system are internal. However, several links access resources on the internet (such as links to Openspace threads). If you are using the help system without an internet connection, you will receive "Page not Found" error messages in these instances.
Getting Started: Input, Mapping and Table Operations
- My shape file won't load
- Installation Problems
- Problems with field names/calculation
- Problems with quantile map categories
- GeoDa crashes when I try to create Thiessen polygons
- The bounding box does not clip my Thiessen polygons
- Problem with standardization in Parallel Coordinate Plot
- The conditional map freezes after adding centroids
- My weights characteristics show the wrong number of neighbors
- Error message when trying to open weights file
- LISA maps incompatible with islands
- Problem with saved results of bivariate LISA
- Title problem with multiple open LISA EB standardization maps
- I get a p-value of 1 with the EB Moran scatter plot
- Problem with running 9,999 permutations with EB Moran scatter plot
- Why are my Moran's I values larger/smaller than 1?
- GeoDa crashes when I run a regression
- GeoDa crashes when I run a regression without a constant term
- My output contains a mixture of multiple models
- Why are there differences in the Breusch-Pagan results of GeoDa and R?
- Why does the White test return an N/A result?
Getting Started: Input, Mapping and Table Operations
- no long text fields (e.g., with comments),
- no more than 255 variables in your dataset, and
- all shape file components (.shp, .shx, .dbf) in the same folder.
- Fields formatted as dates can cause problems, too.
In most cases where the shape file does not load, the ID is either not unique, not numeric, or not integer. Some IDs look like they are numeric but are actually formatted as character fields (e.g., this can occur with FIPS codes from the Census Bureau). Note that in some cases, unique character fields, such as names, will load.
The easiest solution is to add a new field with a unique ID in a spreadsheet program or a GIS. For instance, in ArcView 3.x, add a new field and type in rec in the field calculator. In ArcGIS, type in [OID]+1 or populate the new field with the FID field (type FID in the field calculator dialog). More information.
If the problem persists, make sure that all the component files of your shape file (e.g., .shp, .dbf, and .shx) are present, share the same file name, and are in the same directory.
If your shape file will not load even though you have a unique ID, make sure you have:
Although a generic "out of memory" error message usually appears in response to not being able to load a shape file, the problem is generally not related to a lack of memory.
If you are having problems running GeoDa or opening maps in GeoDa in a network or lab setting, this is most likely due to restricted permission to access library files on the server. Besides the setup.exe file, several library files are installed in other system folders during the GeoDa installation. The user has to have access to these files in order to be able to properly run the software.
You will face the same problem if you are only running the GeoDa upgrade without the full installation (the upgrade does not contain the library files, which is why it is smaller in size).
Appendix C of the GeoDa User's Guide contains a list of these library files and their locations (although the list refers to an earlier version of GeoDa, network administrators can get a good general idea where library files are installed).
Another frequent problem refers to an error message that C:\Windows\System32\MSXBSE35D.DLL failed to register. You can generally ignore this message. Your machine might have permissions set in a way that access is restricted to the system32 directory. If you manually browse to C:\Windows\System32\ (make sure hidden files are visible), you can check if the MSXBSE35D.DLL file is already in this folder. If so, you should be fine. If not, see if you can change the permissions to access the system32 folder. Try opening GeoDa and some sample data file to see if you can run the program and open files.
There are several instances where GeoDa is unable to distinguish between field names with the same beginning. For instance, if you create a new column with a field name that has the same beginning as an existing field name (e.g., FIPS and FI) and try to do a field calculation to populate the new field, the calculation is not implemented.
With smoothing, if you specify a variable for the numerator or denominator with the same beginning as another variable, GeoDa has been reported to select another variable with the same beginning.
The only current workaround to these problems is to use unique field name beginnings.
If there are large differences in the number of observations in your quantile map categories, e.g., zero in your first quartile and 38 in your second, you are probably working with observations with many of the same values. In the case of such ties between values, it is not possible to consistently assign interval break points since the same tied values could appear in different categories (and therefore result in a different map) with different map iterations.
The decision rule GeoDa applies in the case when values are tied across quantiles, is to assign all of the values from the previous quantile to the next quantile. As a result, you end up with large differences in the number of observations per quantile category. For instance, in a quartile map of 100 observations, many of which have zero values, you could end up with no observations in your first quantile and 38 observations in your second quantile instead of 25 in each, as expected.
In these instances, quantile maps based on equal interval breaks are not appropriate. Instead, try using rates (if the ties were related to counts), or use standard deviation maps.
GeoDa crashes in the attempt to create Thiessen polygons if more than one point shares the same location (e.g., when two apartment residents share the same address or you are working with the same addresses over time). This problem occurs because GeoDa computes the Thiessen polygon boundaries using a k-nearest neighbor algorithm, which requires unique coordinates. To address this problem, make sure your points do not have identical x-y coordinates. If this is the case, change the last decimal points of your x or y to make them unique. The problem may also arise from points whose proximity is too close.
Another work-around is to convert your points to a Triangulated Irregular Network (TIN) (e.g., using a GIS) and then create the Thiessen polygons.
Note that the Thiessen polygons do not use the actual boundary of the bounding box file. The outmost points of the borders of the bounding shape file are used to create a new reference rectangle that constrains the Thiessen polygons. Clip GeoDa's Thiessen polygon file in a geographic information system if you want it cut to the outlines of your bounding box.
Exploratory (Spatial) Data Analysis
There is a problem with visualizing outliers in the standardized data version of the Parallel Coordinate Plot (they are no longer visible and it looks like they go off the chart). We are aware of this problem and are in the process of fixing it for the next release.
Sometimes the conditional map freezes when x and y variables are selected that were created immediately before through the Add Centroids operation. We believe this might be due to a memory leak. You can bypass the problem for now by right-clicking on the table with the added centroids (which are actually central points) and choose Save to Shape File As ..., which will permanently add the two columns to a new shape file. Then load the new shape file and create the conditional map this way.
In almost all cases, this problem is related to digitizing problems of your shape file (e.g., with TIGER files) where there are gaps between the polygons, which is why you end up with zero neighbors or the wrong number of neighbors. To determine if this is the case, try zooming far into your shape file to see if several polygons are surrounded by polygon "slivers" or gaps between polygons. This problem sometimes also occurs as a result of dissolving or merging shape files.
To get a shape file that can be used to create a working weights matrix, you need to clean the shape file (e.g., using the CLEAN command in ArcInfo). Check your shape file after the clean operation to make sure it works correctly (sometimes there are problems with the operation; note that you can often adjust your tolerance level). If the clean command worked, you can create a correct weights matrix in GeoDa.
(Additional information on Openspace's No connectivity in dataset thread.)
If you are unable to clean the shape file, one possible work-around is to convert your polygons to central points and then create Thiessen polygons from these points. These polygons will be contiguous but you lose the original polygon shapes.
If you are getting an error message when trying to open a weights file, open the weights file in a text editor. Make sure that the file name and key variable name in the weights file are identical to those in your current shape file. Also make sure that the .dbf file is in the same directory folder as your .shp and .shx files (the other two components of your shape file).
Do not create local Moran maps for shape files with islands since the significance levels for the islands will not be computed correctly. You can either exclude the islands from the shape file in a mapping program outside of GeoDa (or edit the shape file manually in ASCII after exporting it from GeoDa). Or you can manually edit your weights file in a text editor and associate the island with the mainland (more information).
Non-significant areas in bivariate LISA maps do not get saved correctly (they are assigned a value of 2 instead of 0 and therefore cannot be distinguished from the 2 assigned to low-low clusters). We are working on correcting this problem.
As a workaround (if your dataset is not too large or you do not have too many low-low areas), you can select the low-low areas and create a new dummy variable for them (right-click on the table and choose Save Selected Obs.). You can then create a new field by combining both fields, which will allow you to distinguish low-low areas from non-significant ones.
This problem is related to a negative estimate of variance, in which case GeoDa assigns the mean to all areas by convention (see Bailey-Gatrell (1995) (pp. 303-308). As a workaround, try one of the other smoothers.
When two different LISA significance maps with EB standardization are open, and the randomization options are chosen for both maps, the titles are synchronized even though they refer to different variables. This is a bug. Although the titles are incorrect, the maps display the correct results for the different variables.
This is a bug in the Moran scatter plot with EB standardization. In cases of negative spatial autocorrelation where the observed Moran's I value is smaller than the theoretical value of Moran's I and the reference distribution, GeoDa erroneously treats this case as positive spatial autocorrelation in comparing the theoretical mean to the observed Moran's I. We are in the process of fixing this problem.
There is a problem with visualizing the reference distribution for the Moran scatter plot with EB standardization with 9,999 permutations (it does not get drawn correctly). The best work-around for this problem is to use 999 permutations since in general the significance assessment will not change between 999 and 9,999 permutations.
Most likely, you are running a spatial regression with k-nearest neighbor (KNN) weights, which are not yet supported for regressions in GeoDa because they are asymmetric (you can get results for small data sizes but they are incorrect; more information on Openspace (Sept. 2005))).
Try using a different weights format (e.g., higher order rook or queen). Alternatively, the only way to currently run a spatial regression in GeoDa with KNN weights is to convert your weights to symmetric format, e.g., in R, and then bring it back into GeoDa (more information on Openspace (July 2004) and Openspace (Sept. 2005)).
The diagnostic tests for spatial dependence are accurate with k-nearest neighbor weights.
This problem occurs when you run a regression without a constant term without loading a shape file first. It is a bug we are working on. The only work-around right now is to load the shape file first and then run the regression from within the program.
If you are running multiple models, save them under a different name in the initial Output file name box to avoid getting weird results of mixed prior and current models.