[Gvsig_english] Re: setup development environment

[Benjamin Ducke]

I found some more bugs in my notes that I forgot to include in the last
message:

---

When attempting to save a project, the Spanish error message:
"Fallo guardando el Proyecto en : 
com.iver.cit.gvsig.project.documents.table.ProjectTable"
appears.
This happens if the structure of any table in the Table
section gets changed, e.g. as a result of an editing operation OR
if that table gets moved to another location in the file system
without the Table manager knowing about it.
Deleting all manipulated tables from the Table section of the Project
manager, then saving again will work.
I have also had this problem
with an external DBF table in the Table section open, from which I had
joined fields to one of the attribute tables.
I think a better behaviour for the program would be to kick faulty
tables out of the Table section (warning the user about it first,
of course), rather than refusing to save the project which can be
a really frightening experience for users!

When attempting to save a project, the Spanish error message:
"Error guardando el proyecto" appears. This seems to happen when adding
the same Shapefile as more than one layer. In my case, the .GVP project
file got corrupted (zero'd) afterwards once!

SEXTANTE aborts with an unspecific "User error" when trying to open the
toolbox. This can happen if one of the layers in the active data view is 
invalid. SEXTANTE needs to query all layers for their type (raster,
vector, ...) upon start-up and it will fail if one of the layers is
faulty. This may happen if e.g. one of the layer's DBF file is missing
or damaged. I think better behaviour for SEXTANTE in this case would be
to output an error message about the defective layer, so the user can
have a chance to either fix or remove it from the project.

Layers become inactive, display incompletely and cannot be deleted.
This regularly happens, if the connection with the attribute table 
breaks. This can easily happen if DBF or other database tables or
edited in an external application. If you e.g. rename a field and
one of the layers depends on it for labelling or thematic display, then 
the connection will break!
I think the "Reload" function for broken layers will have to check
whether fields used for labelling or symbology still exist and disable
those settings if necessary (warning the user about it).
Even worse would be a situation where a user deletes or adds table rows
in an external application without gvSIG knowing about it. But even in
this case, there should at least be an error message telling the user
that a manipulation of the database structure is the source of the
problem.

---

Cheers and thanks for all the hard work,

Ben


Cesar Martinez Izquierdo wrote:
> Hi Benjamin,
> 
> Thank you very much for elaborating this detailed list of bugs.
> We will try to solve as much of these problems as possible, before 
> releasing version 2.0.
> 
> Regards,
> 
> Benjamin Ducke escribió:
>> Hi Jorge,
>>
>>>
>>> You'll need experience with previous versions of gvSIG in order to 
>>> work directly to the SVN. I'm preparing those notes right now.
>>
>> Yes. We will just send in patch files until that level of experience has
>> been gained. Thanks for preparing those notes. They will be very
>> welcome.
>>
>>>
>>> Can you send us a brief summary of those problems you experienced? 
>>> I'm not talking about lacking features but real bugs or inappropriate 
>>> behaviors.
>>
>> All my observations relate to version 1.1.2. I have listed them below.
>> You will see that DBMS and table management is what gives us most
>> problems right now, possibly because we work with fairly extensive
>> external database structures.
>>
>>
>> Cheers,
>>
>> Ben
>>
>>
>> ===========
>> BUGS
>> ===========
>>
>> * DBMS AND TABLE MANAGEMENT *
>>
>> Information about Database active database connections gets stored as 
>> plain, readable text strings in the XML project file. This includes 
>> the password(!)
>>
>> Case sensitivity: when editing field names in the attribute table, 
>> “NAME” and “name” are treated as though they were the same field name. 
>> Thus, if you want to rename “Label” to “LABEL”, you get an error message.
>>
>> Case sensitivity: in PostGIS connections (and perhaps other places?), 
>> table names are converted to all lower case before comparisons. Thus, 
>> a table named “myTable” cannot be linked to, even though it exists but
>> “mytable” will work. This is not proper behaviour, as SQL is case
>> sensitive.
>>
>> PostGIS: gvSIG cannot connect to tables with geometries created in 
>> QuantumGIS, but it works OK the other way around. There seems to be 
>> something that QGIS tolerates but gvSIG does not.
>>
>> Deleting features based on selected rows in the attribute table: 
>> opening a layer for editing, then using the “Delete row” function in 
>> that layer's attribute table menu seems to not work. Instead, select 
>> the row(s) linked to the features to be deleted. Features will be 
>> selected. Now activate the editing window again and delete all 
>> selected features (DEL key). Small annoyance here: the attribute table 
>> view does not get refreshed properly and it may look as though the 
>> operation failed. Just hit ESC to refresh the view on the currently 
>> selected field.
>>
>> In the "Join" wizards, the buttons after the first step become so 
>> small that their labels cannot be read.
>>
>> "Table -> Link": Dialog box says "Select origin table of the join" 
>> (instead of "link"). Anyway, it should be called the "target" table, 
>> really! Or: "Table to join/link records to"/"Table to join/link 
>> records from".
>>
>> Joining an ODBC table to a table ("external" or attribute) in the 
>> "Table" list works. However, the fields are prefixed "link_" instead 
>> of join. "Table" menu shows "Remove joins" option correctly.
>>
>> Linking an ODBC table to a table in the "Table" list silently fails 
>> (no additional records in the table). However, the "Table" menu shows 
>> "Remove links" option correctly. Perhaps it is a 1:1 only mapping 
>> which requires exactly one record with the same primary key in both 
>> tables? In that case, there should be a proper error message.
>>
>> GvSIG will happily load Shapefiles with missing DBF files. These files 
>> must really be considered broken and troubles will start sooner or 
>> later. Although they show up in the layer list, they will be marked as 
>> faulty, activating them will throw an error “Reload” will not work and 
>> Sextante will crash in any case (as it goes through all layers in the 
>> project checking their types to see which tools should be made 
>> available). It would be better for gvSIG to refuse loading incomplete 
>> Shapefiles altogether.
>>
>> * LAYER MANAGEMENT *
>>
>> After adding groups, saving a project fails with "Fallo guarando el 
>> Proyecto en: com.iver.cit.gvsig.project.documents.table.ProjectTable". 
>> HOWEVER, exiting and then confirming to save the resources saves 
>> everything!
>>
>> Layers that are part of groups cannot be selected individually in the 
>> “Selection by layer” dialog and perhaps in other places, as well. Bug 
>> or feature?
>>
>> Layer styles cannot be saved and loaded into a new layer, if it has 
>> the exact same attributes. This is a known bug that will be fixed in 
>> gvSIG 2.0 (it appears to work after a restart of gvSIG, though).
>>
>> Sometimes, a layer will disappear when selecting records in the 
>> associated attribute table. Select “Reload” from the layer context 
>> menu to restore it. However, sometimes that does not work either. The 
>> problem is frequent with layers that have external table data joined 
>> in. It gets when restoring a project with such layers in it.
>>
>> Symbols: choosing different "Begin" and "End" colors does not result 
>> in any changes until "Computer intervals" is pressed.
>>
>> * GEOPROCESSING TOOLS *
>>
>> Merging layers with integer attributes results in the merged attribute 
>> being of type double (??).
>>
>> Creating more than one buffer zone using the “Buffer” geoprocess does 
>> not work. You get only one buffer that is the size of all the buffers 
>> requested plus some spurious geometries.
>>
>> * GEOMETRY EDITING *
>>
>> "Finish edition" always asks about saving changes to tables and 
>> shapes, even if none were made.
>>
>> Stepping through the editing command console history using CURSOR 
>> UP/DOWN gives: “java.lang.StringIndexOutOfBoundsException: String 
>> index out of range: 2993”.
>>
>> * ANNOTATION LAYERS *
>>
>> GvSIG thrashes the disk when cancelling the annotation dialog.
>>
>> Attempting to open the “Properties” of an annotation layers results in 
>> the following error message: “java.lang.ClassCastException: 
>> com.iver.cit.gvsig.fmap.rendering.Annotation_Legend cannot be cast to 
>> com.iver.cit.gvsig.fmap.rendering.SingleSymbolLegend”
>>
>> Many problems with current labelling functions. Fonts changing size 
>> when rotation applied. Annotation layers not printing or being 
>> exported to PDF ...
>>
>> Attribute tables of annotation layers: cannot query or sort by any 
>> field if added to the Table view by using the "Show table of 
>> attributes" function, but if added as an external dbf table, all is OK!
>>
>> * EVENT LAYERS *
>>
>> In the “Add event layer” dialog, the input fields for northing and 
>> easting are both labelled “null”. Sometimes they do get displayed, but 
>> in the wrong order: “X:” is really the Northing, “Y:” the field for 
>> the Easting!
>>
>> * PROJECTIONS *
>>
>> Projection definition for ESRI:54004 does not work.
>>
>> * USER INTERFACE ANNOYANCES *
>>
>> Some dialogs are not resizable, which is bad because there is too much 
>> information to fit into them (e.g. the list view in the dialog for 
>> choosing a projection system.
>>
>> When detaching a group of icons from the main toolbar, it is 
>> impossible to drop them back off anywhere but at the right-most 
>> position in the toolbar. However, after a program restart, everything 
>> get reset to defaults, anyway.
>>
>> Since the link and join functions are only accessible when activating 
>> a table, they should be executed by default on the currently active 
>> table. A single dialog would then be much simpler then the current 
>> wizard interfaces.
>>
>> There are no useful error messages in the case when an ODBC connection 
>> fails.
>>
>> It seems strange that layers in a View cannot directly be added to the 
>> locator map.
>>
>> Grouping layers would be easier if it was possible to select 
>> non-adjacent layers using CTRL + left click
>>
>> Layers cannot always be moved to the place wanted, because the layer 
>> list does not autoscroll during drag operations. There is no good 
>> visual indication (like a horizontal line) to show where a layer that 
>> is being dragged will end up. Worse: if all layers are part of a 
>> group, there is
>> no possibility to drag a layer to the outside of any group. The only
>> work around is to add another layer to the layer list, thus creating
>> a "drop target".
>>
>> When creating a new group, the default name should be marked for 
>> overwrite, so the user does not have to delete it every time before 
>> entering a new name.
>>
>> Editing commmands: the tool names are too long! There need to be 
>> abbreviations, like "rect" instead of "rectangle" (or even just "R"), 
>> otherwise the user will wast too much time.
>>
>> Editing mode has its own selection tools, but the other selection 
>> tools are still available, which can be confusing at times.
>>
>> There should be a warning if the user edits a shapefile layer that has 
>> a different SRS then the current view.
>>
>> * MAP LAYOUT AND PRINTING *
>>
>> Map layout and printing have been reported as being broken by many of
>> our users. I have not yet the time to make a detailed list of all
>> problems encountered, or check whether they are really user errors, but
>> they include:
>>
>> - unable to set line thickness < 1.0
>> - wrong margins
>> - unfilled polygons come out filled anyway on print-outs
>> - problems with font scaling in scale bar display
>> - contents of locator map not aligned properly to its graphic frame
>> - wrong margins
>>
>>
> 
> 


-- 
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeology Ltd
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke at oxfordarch.co.uk




------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.