On this page you will find an extensive list of typical problems and cures that we have compiled over many months of using gvSIG in our own projects and evaluating user feedback. Note that not all of the problems listed here are still around with the latest version of the software, as they may have been fixed in the interim. We always recommend you use the latest available version of gvSIG OADE.
If you run into any trouble or have questions/comments regarding gvSIG:
This version of gvSIG has been optimized to run on Java 1.6 virtual machines.
On Linux and Windows platforms, gvSIG OADE comes with a bundled Java Runtime Environment (JRE) which has been tested and is known to work well with this release of the software. We recommend you keep it that way. Running gvSIG with a different JRE may or may not work. Try at your own risk.
On Mac OS X, Apple decides what version of Java you get to use, depending on the version of Mac OS X. For Java 1.6, you need to be running Mac OS X 10.5 or higher.
Please refer to the gvSIG OADE Installation Manual that comes with this software for further advice.
Even though gvSIG is 32 bit software, and its use of memory further limited by the Java Virtual Machine it runs in, it has been designed to be very effective when handling large spatial datasets. You will find that it elegantly handles even very large vector maps or high resolution raster data. However, some GIS tasks, especially those involving very high resolution raster images and remote sensing work, will quickly consume all available memory resources. For such cases, be aware of the fact that gvSIG only claims memory resources for those layers which are currently active (visible). Switching unneeded layers invisible or (better yet) closing the View that contains them will release the memory allocated for them and make it available for other purposes. It is therefore recommended to create a new View for data processing tasks that are heavy on memory and close all other Views temporarily.
Operating system specific problems
Please refer to the gvSIG OADE Installation Manual that comes with this software for additional advice on OS-specific problems and solutions.
This version requires a GLIBC version of 2.3 or higher. Other than that, any Linux distribution should be fine. At OA, we use mostly Ubuntu.
32 Bit Compatibility Libraries Needed
When starting gvSIG on a 64 bit Linux system, the following error message is generated:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /jre/lib/i386/xawt/libmawt.so:
This indicates that "libXext.so.6", which is a requirement of Orcale's JRE 1.6 32 bit (the one that comes bundled with gvSIG OADE) is missing. That library should be in some 32 bit compatibility package of your Linux distribution. On Debian based systems (including Ubuntu) it is called "ia32". For installation instructions, please consult your Linux distribution's manual.
You will need a Mac OS X version that comes with a Java 1.6 installation, i.e. Snow Leopard. Please read the operating system specific notes in the Installation Guide for more advice on this.
We recommend that you do not use Apple's Mac OS X look and feel for Java, as it does not comply with that of the other platforms and leads to numerous problems with the user interface (see below). You can change the user interface “look and feel” in gvSIG's preferences dialog (section “General->Appearance”). After a change, you will have to restart gvSIG to see the effects. We recommend “Plastic XP” (this is the default for a fresh gvSIG OADE installation).
Support for Mac OS X versions older than Snow Leopard
Please upgrade your system to Snow Leopard if you can.
It is possible to get gvSIG OADE to run on OS X versions prior to 10.6 (Snow Leopard) by using an alternative Java runtime environment. See the Installation Guide for details. However, be aware that this is untested by us and we cannot provide any support for it. We have users reporting that there are problems with older versions of Mac OS X, such as missing support for raster layers. However, we have also had reports of success running our software on Mac OS X versions as old as 10.4 (Tiger), using the SoyLatte JRE. It's up to you to try.
Associating .gvp files with the App does not work
Due to a flaw in the start-up script for Mac OS X, it is currently not possible to associate .gvp (gvSIG project) files with the gvSIG OADE App and have gvSIG open them up automatically.
Drop-down menus do not work: mouse clicks are ignored
This is caused be the behaviour of the Plastic XP (and possibly other) Java widgets on Mac OS X. To make a selection from a drop-down menu list: click on the list button, hold the mouse button down, select the option you want and then release.
Garbled dialogues (buttons displayed partially etc.)
Mac OS X uses very generous spacing between user interface components and this can result in problems with the layout of some dialogues. Where this appears, resizing the dialogue window to make it a little larger should resolve the problem.
GRASS interface (SEXTANTE) not working
Symptom: After setting up GRASS via SEXTANTE and then starting any GRASS module, an error about "g.version" not being able to run is displayed.
Explanation: The GRASS version bundled with gvSIG OADE does not run on versions of Mac OS X older than 10.6 (Snow Leopard).
Solution: Download a version of GRASS for your Mac OS X (preferably 6.4), e.g. from here, install it manually and then use that instead of the bundled version.
Preferences do not get saved
Symptom: Program settings made in the File->Preferences window do not get saved after exiting gvSIG.
Solution: Do not quit gvSIG via the Mac menu bar. Instead, use "File->Exit" from the gvSIG window. Otherwise, Mac OS X will simply "kill" the Java machine that gvSIG runs in and it may not be able to shut down cleanly, resulting in loss of changes to program preferences.
Quitting gvSIG does not show dialogue asking to save changes
See under "Preferences do not get saved".
Raster export (Save as...) throws a Java NULL pointer error
This may be caused by the Apple Java widgets, just like the garbled dialogues (see above).
Wrong File Type Settings in Some File Selectors
This may be caused by the Apple Java widgets, just like the garbled dialogues (see above).
Some file selection dialogues offer options for specific file types. On Mac OS X, these sometimes seem to get shuffled so that the wrong options are shown for the default file type. Simply select the correct file type one more time to make sure that the right options are being shown.
In general, gvSIG runs very well on Windows XP, Vista and 7. It is reported to also run on Windows 2000, but this has not been tested by us. Windows has poor memory management on 32 bit platforms, so the maximum amount of Java heap space that can be used will be more limited than on e.g. Linux. If you experience memory management problems under 32 bit Windows, we recommend upgrading your operating system to a current version of Linux.
Installer complains that it has no permission to write into target directory (Windows 7)
In Windows 7, right-click the installer's ".exe" file and then select "Run as administrator". This should allow you to install gvSIG into a system directory. However, you can also install gvSIG OADE into any user directory (including one on an external USB drive). No administrator rights are needed for this type of installation.
Cannot uninstall gvSIG via the Windows Control Panel
Uninstalling gvSIG via the Windows control panel is only possible if the software was installed with administrator privileges. A user-mode installation can be uninstalled by simply deleting the directory into which the software was installed, including all its contents.
Default vector layer symbols are missing (some raster colour schemes are missing)
Please take a look at the installation manual to learn how to reset your user settings.
Opening a project file (.gvp) from the Windows desktop does not launch gvSIG/launches wrong version of gvSIG
It is possible that the gvSIG project files extension (“.gvp”) is still associated with an earlier installation of gvSIG which may no longer exist. Or that gvSIG has been installed by another user on your system and your own user account does not have the right file association setting (gvSIG is portable software, so it never touches any system-wide settings).
It is easy to fix this. Simply open the project file's properties menu (right mouse button), choose “Open with” and then browse to the “gvSIG.bat” launcher script in your current installation folder. More information can be found here.
Display driver problems (grayed out areas etc.)
We have had some reports of strange graphics effects on Windows, notably gray (grey) areas occurring when trying to insert objects into a map layout. This was found to be caused by buggy Windows graphics card drivers. To cure such problems, first make sure that you have the latest version of the driver for your graphics card installed. If updating the driver does not help, go into Windows' graphics driver settings and disable some or all of the 2D acceleration options, until the problem disappears.
Problems with data stored on network shares
The Windows network protocols can be unreliable, leading to disconnected file shares. If data sources for layers are stored on such networked shares, then problems may occur. We have found gvSIG itself to be relatively robust against this. But SEXTANTE is known to produce empty result layers in such cases. Check the layer properties to see whether the data source is properly connected. If not, delete the layer from the TOC and add it again, or save your project and restart gvSIG.
System themes (“Look and Feel” extensions)
There are some “extensions” around for Windows XP that change the “look and feel”, e.g. to be more like Vista or Windows 7. They are known to cause trouble with Java Swing applications (gvSIG is such an application). So if you get complete and unexplained crashes of gvSIG on start-up, please deactivate or (even better) uninstall any such “extension”.
GRASS interface (SEXTANTE): Modules do not show progress info
Due to a limitation in Windows' inter-process communication abilities, processing status (progress) information is currently not available for the GRASS modules. We will try to fix this in a future update.
GRASS interface (SEXTANTE): Some modules always abort with an error
If a GRASS module consistently aborts with a generic error message, and you have checked all options to be correct, open the SEXTANTE History window and switch to the "GRASS output" tab. This contains the detailed status information and any more verbose error message that may have been produced by the module.
Check for some common sources of error:
GRASS interface (SEXTANTE): g.parser.exe complains about missing DLL file
This error may occur if you attempt to set up the GRASS interface with a GRASS installation other than the bundled one. There are different distribution of GRASS for Windows and they may differ in the way the files are structured. If you get an error about a missing DLL file then first use Window's search function to locate that file within you GRASS installation. Make a note of the full file path of the directory it is located in. Then set the environment variable GRASS_ADDON_PATH to include that path.
More information on how to set environment variable in different versions of Windows can be found here.
Do not install the 3D extension over this version of gvSIG. It will conflict with some of the updates and raster driver fixes for gvSIG OADE.
The only version of ArcSDE properly tested (and support) by gvSIG is 9.1.
Find the section “ArcSDE SDK Install for” (your operation system) and download the archive file. It should contain the files "jpe91_sdk.jar" and "jsde91_sdk.jar". Copy both to the “bin/gvSIG/extensiones/org.gvsig.sde/lib” suddirectory of your gvSIG installation, replacing any older versions. Then restart gvSIG.
JOIN (typed into console) may produce an error message, but joins the selected polygons, anyhow. Ignore.
General File Management
Many a hair has been pulled over seemingly inexplicable errors that have their cause in a very simple and basic thing: file naming conventions.
As a Java application, gvSIG is quite sensitive to "bad" file names. Even though operating systems like Windows may allow this, do not use accent characters, punctuation marks or white space in file names. not ever. If you do, brace yourself for all sorts of weird behavior from the application, such as bogus error messages or layers not being loaded.
In addition, the minus ("-") sign has been reported to sometimes cause trouble.
Also, avoid using capitalization. Windows' file system does not care about it when reading files, only when creating them. But on other platforms, case is respected for both reading and writing. To be on the safe side, use small caps only.
Careful with external editing of DBF attribute table files! Some software, such may save the edited file with a capitalised extension ("DBF" instead of "dbf") or file name.This will be OK on Windows, but operating systems that are case-sensitive on file names, such as Mac OS X and Linux will choke on it and produce strange error message when attempting to load the associated shapefile dataset.
Windows' file management is also limited in that it cannot deal with paths that are longer than 255 characters. Even if you use a short file name, the path can still get too long if the names of the directories that lead up to it form a long string. So refrain from creating folder structures that are many levels deep.
Concurrent file access
GvSIG does not manage any exclusive locks on files, which can lead to data corruption if more than one person edits a file-based resource, such as a project file, DBase table or Shapefile on disk.
General user interface
Dialogs and widgets garbled
There may be problems with some dialogs getting mutilated (most significantly, the "Filter" dialog for attribute table values). Change the user interface theme in the program preferences to fix this.
Grouped layers not accessible
Handling grouped layers: the “Spatial selection” tool does not show vector layers in groups properly. Instead, it shows the groups names. If temporary layers (observed with raster layers) are moved into a group, they become invalid. Layers in groups are also not accessible by many tools. Tested with: Remote Sensing Extension (Mosaic tool), Spatial selection tool.
In all these cases, you need to move a layer out of its group before you can process it. Hopefully, future updates to gvSIG will fix this problem.
Symbol folder setting overwrites Template folder setting
On the Preferences page "General->Default directories". Due to a bug in the interface logics, it is not possible to use the file selector, browse for a new "Symbols" directory and then set it. Instead, the "Templates" directory setting will be overwritten. Please enter the Symbols directory manually into the field.
Trouble with empty views
Opening the georeferencer with a View that has no layers as map background results in an error messages. When running the georeferencer from within a new, blank project, select to use no background map in the startup window, instead.
3.10.1 Project file versions
Project files written by gvSIG 1.9 and above (and thus OADE 2010 and above) differ very much from the earlier format used by gvSIG 1.1.2. The two file formats are not compatible. Newer gvSIG versions will read older project file formats and offer to save them in the new format. But older versions of gvSIG cannot read newer project file formats.
There have been problems reported opening old gvSIG version 1.1.2 project files with raster layers. Some rasters seem to have turned all red or black. The fix seems to be to delete the layers from the TOC and add the rasters anew.
Raster data formats
ERDAS IMAGINE RRD generation
Generating RRD format overviews when saving out IMAGINE format rasters does currently not work.
GRASS raster files
Because of linking problems on Windows, support for GRASS raster data via GDAL has been disabled for all platforms in gvSIG OADE. If you want to compile a GDAL version with GRASS support yourself and use it, please be aware of the following issue:
The GDAL GRASS driver will crash (and take the whole JRE down with it!) if a GRASS raster map is added to a gvSIG View and that raster map comes from a GRASS location without a properly defined spatial reference system (such locations are the result of choosing option "A x,y" when creating a new GRASS location).
You will get the following console log output:
Warning 1: GRASS warning: file not found for location
So make sure that the SRS for the GRASS location has been defined properly and the two files PROJ_INFO and PROJ_UNITS exist in the PERMANENT mapset. If they don't and you whish to load the data into a gvSIG View without any reprojection, just create two empty files in the PERMANENT folder.
HDF4/5 raster files not supported
These formats are currently not supported by gvSIG OADE.
ILWIS file name extension
ILWIS raster file output: gvSIG recognizes only ".mpl" as output extension. However, the actual file (as created by the GDAL driver that gvSIG uses) creates a ".mpr" file. This can be confusing when crying to create an ILWIS raster file, e.g. via "Save as" Raster Tool.
JPEG2000 files poorly supported
Support for JPEG2000 format raster data files is currently rudimentary at best. Most files in this format will probably not load correctly or not load at all.
Raster layer handling
Bad performance and annoyances with byte type raster data
Unfortunately, Java does not provide a Signed Byte (8 bit, -127 to 127 range) type, so that gvSIG currently cannot handle byte data with negative values directly. The work-around we have chosen is to convert Byte type data into Short type data on import, which is a representation that includes negative values, but unfortunately is 16 instead of 8 bits long. This means that data will take twice as much memory, reducing performance when loading and displaying the raster layers. There may also be problems with raster layer statistics (update them manually if they are incorrect) and exporting raster layers as new datasets (they will be exported as 16 bit instead of the original 8 bit).
Note: You can explicitly deal with raster data types if you use the GRASS GIS interface in SEXTANTE and the r.in.gdal/r.out.gdal modules.
Bleeding raster layers
When zooming to the full extent of a raster layer, a portion of it at the bottom sometimes seems to “bleed” downwards, i.e. the same horizontal line of pixels is displayed repeatedly.
Work-around: change the size of the View's window a little. This should refresh the raster and display it correctly. If this does not help, try creating a new View and loading the raster into that.
Changing raster preferences throws "java.lang.NullPointerException"
This error may occur when making changes on the "Raster" page of the "Preferences" dialog (e.g. changing the "Use NULL for transparency" setting). It only occurs when there is a view open that has one or more inactive (hidden) raster layers. Solution: close all views with raster layers before changing any raster preferences; reopen them when done.
Colour table tool does not list new gvSIG OADE schemes
This version of gvSIG OADE comes with a set of customized, useful colour schemes, such as “slope”, “aspect”, “elevation” and “morphometry”. If those do not show up in the Color Table Editor, then you must let gvSIG regenerate them.
Exit gvSIG, open the gvSIG settings folder (location differs: $HOME/gvSIG on *nix systems, C:\Documents and Settings\\gvSIG or similar on Windows) and move the file “palettes.xml” and the folder “colortable” to a different location.
Restart gvSIG. It should now regenerate the default colour schemes. If you have made your own changes to gvSIG's colour schemes library, then quit gvSIG again and merge those changes back into “palettes.xml” and “colortable”. If not, you can now safely delete the copies of both.
Raster layers display as single colour (black) “block”
There are several possible causes for this:
Raster “Save as” fails
Saving as raster (using "Save as" from the rastertools or raster layer context menu) may fail with an unspecific error message if there are raster layers (in the same or another project view) that were switched to "hidden" when the project was first loaded and not switched to "visible" since then.
Solution: switch all raster layers to "visible" at least once to make sure their data is loaded. You can switch them back to "invisible" afterwards.
Temporary raster layers disappear
There is a bug in the Colour Table tool that deletes temporary raster layers if the user chooses “Cancel”.
Reprojection and spatial reference systems
Grid file based reprojection not work working
An incompatible version of the PROJ.4 library is leading to grid file based reprojections being ignored. To fix this problem, you need to patch the projection support libraries. See instructions for your operating system below.
Exit gvSIG before commencing.
Windows: Download this file. Extract it into the directory "jre\bin" within your gvSIG installation directory (or the "bin" directory of whatever different JRE you may be using, if you are not using the default, bundled one). Overwrite any existing files.
Linux: Delete the files "libs/libproj.so", "libs/libproj.so.0" and "libs/libproj.so.0.6.6" from your gvSIG installation directory. Download this file. Extract its contents into the "libs" directory within your gvSIG installation directory. Overwrite any existing files.
Mac OS X: Use the Finder to browse the contents of the gvSIG App package in your gvSIG installation folder. Delete the files "Contents/Frameworks/libproj.dylib", "Contents/Frameworks/libproj.0.dylib" and "Contents/Frameworks/libproj.0.6.6.dylib" from the App package. Download this file. Extract its contents into the folder "Contents/Frameworks" within the App package. Overwrite any existing files.
Restart gvSIG. Grid file based reprojections should now work.
Geoprocessing tool "Reproject" returns "Empty layer"
It is not possible to use a layer that has been reprojected "on the fly" as a source for reprojection. Use the original shapefile as source instead.
Kosovo grid definition
We have added support for the new ETRS 1989 based Kosovo Grid ("KOSOVAREF") geodetic system. Support comes in the form of a "pseudo" or "inofficial" new EPSG:102157 entry. This allows you to reproject raster and vector data, but only with limited precision. There is currently no higher order or grid-based transformation available.
Windows: Please download this file and extract its contents directly into an existing installation folder of gvSIG, i.e. the folder level which has the "bin" and "lib" subfolders.
Linux: Please download this file and extract its contents directly into an existing installation folder of gvSIG, i.e. the folder level which has the "bin" and "libs" subfolders.
Mac OS X: Please download this file and extract its contents directly into the gvSIG App folder, i.e. the folder level which has the "Contents" subfolder. You can use the Mac Finder to browse into the gvSIG App folder.
In every case, the archive consists of three files which have to overwrite the existing files in your gvSIG installation. After that is done, restart gvSIG and you should be able to find EPSG:102157 in the SRS database (you can also search for "Kosovo").
Please note that EPSG:102157 is not an official EPSG code and thus not supported by any other software. It is, however identical with ESRI's SRS #102157 in ArcGIS. You can load such data into a gvSIG dataview with EPSG:102157. Just ignore the "projection" if asked.
On-the-fly reprojection problems
In general, the concept of on-the-fly reprojection of geodata (e.g. when loading a dataset or copying and pasting it between views with different spatial reference systems) is somewhat problematic. We have observed a number of problems with it in gvSIG. For reliable reprojection of data, use the "Reprojection" tools in the Geoprocessing toolbox (vector layers) or the Raster Tools (raster layers). Then save the explictly reprojected data into a new dataset.
Reprojecting raster data into a user-defined SRS crashed gvSIG
GvSIG is currently not capable of reprojecting raster data into a user-defined SRS. Attempting to do so will terminate the reprojection library code, which is native (non-Java) code, thus taking down the entire Java Virtual Machine in which gvSIG is running.
Semi-minor axis value looks wrong
The field for the value of the semi-minor axis in the SRS settings dialog may be too short, truncating the leading digit. The value is in fact correct.
Update error after defining a user SRS
After entering a user SRS definition and clicking “Finish”, the following error message appears: “Error updating user DB. Probably it is locked by another process”. This is because you need write access to the directory “org.gvsig.crs” (in your gvSIG extensions directory) and the file “usr.script” contained therein. If you don't have write access, then you won't be able to create a new user-defined SRS.
Consult the gvSIG Installation Manual on how to move your SRS definitions database to a more appropriate location where such problems are less likely to occur.
Zoom to layer no longer working for reprojected data
It seems that the data extent is not always correctly updated after a reprojection. In those cases, “Zoom to layer” will fail and display a wrong region. Use the manual zooming and panning tools to get the proper view. If you wish to work more efficiently with a reprojected layer, use the Reproject tool (part of the Geoprocessing Tools) to permanently reproject a layer into a new shapefile.
Remote Sensing Tools
Remote sensing tools unstable and trouble saving output
The Remote Sensing Tools are still somewhat experimental in this release. They include the following tools available from the Raster Tools menu:
Note that most of the remote sensing tools have been designed to work on three-channel (RGB) input images and are likely to throw an error if you attempt to feed them a single-channel (including greyscale) raster layer.
Image Fusion tool throws an error (Brovey, IHS and A Trous)
The Brovey, IHS and A Trous Wavelet fusion modes work on three-channel, RGB raster layers only. Applying them to single-channel, greyscale layers will result in an error message.
Profile tool throws an error
The Profile tool is meant to be used on RGB image layers only. For other types of layers, use the profiling tools in SEXTANTE.
Transformation tool throws “Out of Bounds” error
When applied to a raster layer that is part of a group, the following error is generated:
java.lang.IllegalArgumentException: setSelectedIndex: 0 out of bounds
Solution: move the layer out of any layer group before running the transformation tool on it.
GRASS interface: ERROR: Unable to create table.
If a GRASS module that processes vector data aborts with an "ERROR: Unable to create table" message, then one of the input vector layers contains an attribute field "cat_". You must delete this field from the attribute table before you can process the layer with GRASS.
Background: GRASS automatically creates a numeric field "cat" that acts as an index for the layer's geometries. This field will be preserved in the output layer. If the field "cat" already exists in an imported vector layer, then GRASS will create "cat_", but if that also exists, it will throw an error. So if you repeatedly feed GRASS vector output into another GRASS module, then you are likely to run into this problem.
GRASS interface: Some modules always abort with an error
If a GRASS module consistently aborts with a generic error message, and you have checked all options to be correct, open the SEXTANTE History window and switch to the "GRASS output" tab. This contains the detailed status information and any more verbose error message that may have been produced by the module.Make sure there are no spaces, accent characters etc. in any of the input file names. This can break things easily.
Missing manual pages
SEXTANTE comes with a lot of manual pages that can be read using the built-in help browser. If they are unavailable, then that is probably due to your operating system running in a language other than English.
To fix this, locate the folder “extensiones/es.unex.sextante/sextante_help” within your gvSIG installation folder. It contains a subfolder “en” with the English manual pages. Rename (or copy) that folder to the locale of your operating system. If you do not know the two-letter code for your locale, then you can look it up here: http://www.loc.gov/standards/iso639-2/php/code_list.php (under “ISO 639-1 Code”).
Missing layers in dialogues
If layers are not showing up in a SEXTANTE dialog, even though they have been loaded into the project, then they are most likely not activated (turned visible) in the View's layer list (TOC). SEXTANTE can process inactive layers, but because of some limitations of the current gvSIG raster interface, it has been necessary to allow only active layers to be processed. Hopefully, this will be remedied in a future update of the software.
Null pointer error (out of memory)
The 32 bit version of SEXTANTE has some severe memory limits. In particular, operations on large raster layers can easily run out of memory. We recommend you use the GRASS modules available via SEXTANTE to process large raster datasets.
SEXTANTE tools not showing up in gvSIG' s icon bar
This is most likely caused by files of an older version of SEXTANTE conflicting with the currently installed version. Before installing gvSIG and the SEXTANTE extension, make sure that the installation directory is completely empty. The uninstaller program sometimes fails at removing all installed files (e.g. if there were intermediate updates or modifications).
Spatial reference systems
Dialog for User-defined SRS not working correctly
The “Next” button does not show up on the second settings page (“Datum”).
Swiss national grid system no working
Attempting to set the projection to EPSG 21781 results in error: "java.lang.Exception: In proj4 Projection Oblique Mercator not admit azimut close to 90" (on another machine "java.lang. Exception: Invalid PROJ.4 setting: Oblique Mercator cannot set azimuth close to 90").
Solution: follow these instructions to create a custom SRS:
Note that a working definition of this SRS is already included as part of the default user settings in gvSIG OADE 2010.
Symbology and labels
“Expression” type symbology not available for joined fields
Expression type symbology does not work for joined fields and will never in version 1.9 of gvSIG.
“Interval” type symbology: some features fo not display after applying settings
It seems that attribute table value outliers (extremely small or large values) sometimes mess up the calculation of interval classes. The result is that some features no longer fall into any class and will not be displayed. Also, attempting to open the Properties for such a vector layer after applying the faulty symbology will result in: “java.lang.ArrayIndexOutOfBoundsException: ”.
First, when setting an interval type legend, click “Apply” to test it. If some features do not display, tick the “Other values” option and choose an easy to recognize colour. Then click “Apply” again to see which features are not being classified correctly.
“Interval” type symbology: style for "other values" not displayedcCorrectly
After changing the “Other values” symbol, the display on the “Symbology” tab is not updated correctly. Switch to another tab and then back to update it and show the correct, current settings for “Other values”.
Label fields shifting
When deleting fields from a attribute table that is used for labelling, then the labelling field may switch unwantedly to another field.
SVG symbols support
SVG symbols with embedded text are currently not supported. They will throw an error.
Trying to change the symbol style for a vector layer throws “Null Pointer Error”
Go into the program Preferences, open the “Symbology” page and make sure the “Symbol images directory” setting points to a valid folder on your system.
Tables and DBMS
Attribute table editing
When editing a cell in the table view you need to change the entire value for it to be updated.
Attribute table export
Problem: long text fields may get truncated when exporting a table to a DBase format file (“Table->Export to”).
Integer fields get switched to double fields (DBase tables)
Sometimes, newly created fields of type integer in a DBase (attribute) table are switched to floating point after stopping the editing mode. The reason for this is a limitation in the DBase format that can cause some headaches.
The DBase format does not specify an explicit encoding for integer type fields. Instead, it has a type Numeric which is ambiguous as it can store integer and floating point values. To guess which one it is, gvSIG checks whether the field (a) is declared with any decimal places, and (b) is longer than 9 digits. If either of the two is true, then type floating point is assumed.
So when creating a new integer field, make sure that its length is set to no more than 9. This is the default for new integer fields, but it is possible to set it higher (as other DBMS do not suffer from the same limitation), so beware.
The prefixes for both the source and target table fields will be updated with the last setting for every join operation. This means that there can be problems in multiple join operations (joining from more than one table to the same table), if the the tables to join have fields with identical name.
GvSIG does attempt to adjust field names by prefixing them with "J", but this will only work for the second join. After that, name collisions are unavoidable. The only practical solution is to make sure that all tables you wish to join fields from have unique field names.
ODBC connection asks for host settings
The ODBC connection GUI requires the user to fill in host name and port settings, even though these are not required for an ODBC connection. Just enter any dummy values to be able to continue.
Oracle table selection throws NullPointerException error
Symptom: When connecting to an Oracle spatial database, the list of tables is retrieved correctly, but clicking on any of them will result in a "java.lang.NullPointerException" error.
Solution: Please download this file and copy it into the "bin/gvSIG/extensiones/com.iver.cit.gvsig/lib" folder of your gvSIG OADE installation directory. Overwrite the existing file. After a restart of gvSIG, the error should no longer occur.
Cannot create a new Oracle table in gvSIG
There is a problem with the Oracle (closed source) Java driver and Java 1.6 that has been noticed two years ago, but Oracle has failed to act on so far (see here). The only viable solution seems to add the option “-Xss96” to the Java launching code (in gvSIG.ini on Windows, gvSIG.sh/Info.plist on Mac OS X or gvSIG.sh on Linux). This reduces Java's stacksize which is quite a sensitive thing for Java performance. We cannot guarantee that it will have no other bad side-effects.
Sorry, but that's what happens if proprietary software vendors lose interest in a product. We recommend you upgrade your database system to PostgreSQL, for which the Java interface is actively developed and well suppport by the open source community.
PostGIS driver character encoding
Character encoding problems: Error message "Can`t initialize writer: POSTGIS Writer" pops up when trying to create a new PostGIS layer. Solution: use UTF-8 encoding for your PostgreSQL database. Other encodings do not seem to be supported at this moment (and really: what for? Any software that cannot handle UTF-8 should be considered a candidate for replacement as soon as possible).
Topology tests not working/Default values for new topology
While you can enter "0" as a default value for the cluster tolerance option, you must enter at least "1" as the minimum number of allowed errors, otherwise the tests will fail with empty reults.
No undo/redo in CAD editor
Undo/redo and command history do not work when editing a layer that is part of a topology group.
Adding a vector layer to a view throws “Index out of bounds”
There seems to be a problem with some combination(s) of settings for the “layer ordering manager”, a tool that tries to arrange newly added layers automatically in a clever way. The settings are in “View->Layer loading order->Smart order” of the gvSIG “Preferences” dialog. Try changing them to something simpler.
Attempting to create a new Shapefile crashes
This happens if you directly type in a file name on the last page of the “New layer” dialog and you do not provide a full path or a file of that name already exists in the path given. Use the file selection dialog (button [...]) to pick a path and filename. It works better.
Vector data formats
KML geometries do not display
The KML parser that gvSIG uses can be somewhat restrictive regarding the KML version. It really only seems to accept Google Earth generated KML 2.1. This means that sometimes it will just skip perfectly valid geometries in a KML file and not display them, just because they are declared, e.g. as KML 2.0 or 2.2. To fix this, simply open the KML file in a text editor and change the XML provider tag (usually the second line in the file, right after the XML version tag). Delete the existing tag and replace it with simply this one:
In addition, there are some KML 2.2 features which make the parser fail. In particular, the and tags. If you have any of those in your KML file, make sure to delete them.
You can safely ignore any warning about multiple layers. This warning message will always appear, as a precaution.
Quirks in the user interface
In principle, WFS connections work well, but the user interface may not behave as expected.
Geometry types for layers not shown: Click once on a layer entry. This will retrieve the geometry type for the selected layer and display it.
Cannot select/deselect fields for import: After selecting a layer, press “Next” to go to the field selection. Here, you should be able to select/deselect individual attribute table fields. In our tests (Linux) this did not work at all. Just press “Next” again to import all fields.
Cannot access attribute table for WFS layer from contect Menu: It is still possible to open the attribute table by activating the layer, then clicking on “Layer->Show attribute table” in the main menu, or by just pressing CTRL+T.