[Gvsig_english] Export Shapefile behaviour with Joined Tables

[Benjamin Ducke]

May get complex, though.
Because names prefixed with "j_" can still collide with existing
field names (imagine someone importing a Shapefile with fields
that already have that prefix). And then we will have to think
of some really clever ways to avoid name collisions.

My suggestion:

1. When exporting a shapefile, check if the are any duplicates
   in the (truncated) output field names
2. If no:  just export, do not add any prefixes
3. If yes: give the user a choice to Cancel and fix names
   manually or drop the duplicate fields on export

(the same may need to be applied for saving plain DBF tables,
so these logics should go into the DBF table handling, not
the shapefile export functions)

Btw.: if all this DBF mess gets too much, how about migrating
the project to a proper PostGIS DBMS?

Ben


----- Original Message -----
From: "Juan Ignacio Varela García (Nacho Uve)" <nvarela at cartolab.es>
To: "Users and Developers mailing list" <gvsig_internacional at listserv.gva.es>
Sent: Wednesday, December 23, 2009 1:19:36 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [Gvsig_english] Export Shapefile behaviour with Joined Tables


+1 


2009/12/22 Simon Cropper (Botanicus Australia Pty Ltd) < scropper at botanicusaustralia.com.au > 


Hi, 

This is another - "it would be better" issues. 

When you join two tables and then export the shapefile to "hard code" 
the information so to speak. Despite having unique names the resulting 
attribute table to the exported shapefile has "j_" in front of all the 
field names. This is frustrating because if you have a field name, like 
I did, Active2005, Active2007 and Active2009 once this prefix is added 
the resulting table has tree fields called "J_ACTIVE20" as the fields 
are truncated to 10 characters. 

I suppose I could understand this behaviour if you have duplicate fields 
in the original joined table (i.e. the use of a prefix) but the creation 
of a table that has duplicate field names is a violation of the rules 
around DBFs (i.e. you can't have two fields the same). 

The export facility should review the output file's attribute table 
names and confirm that duplicate names have not been generated. 

Personally, I think that if you have a joined table and no fields have 
the same name then the exported table should just be a reflection of 
this - i.e. the "J_" should not be inserted. 
-- 

Cheers Simon 

Simon Cropper 
Botanicus Australia Pty Ltd 
PO Box 160, Sunshine, Victoria 3020. 
P: 9311 5822. M: 041 830 3437. 
mailto: scropper at botanicusaustralia.com.au 
<mailto: scropper at botanicusaustralia.com.au > 
web: www.botanicusaustralia.com.au < http://www.botanicusaustralia.com.au > 

_______________________________________________ 
Gvsig_internacional mailing list 
Gvsig_internacional at listserv.gva.es 
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional 



-- 
Juan Ignacio Varela García (Nacho Uve) 
Coordinador Grupo de Desarrollo 
Cartolab - Laboratorio de Ingeniería Cartográfica 
http://www.cartolab.es 

ETS Ingeniería de Caminos, Canales y Puertos 
Universidade da Coruña 
Campus de Elviña - 15071 A Coruña (España) 
(34)981167000 ext. 5493 

_______________________________________________
Gvsig_internacional mailing list
Gvsig_internacional at listserv.gva.es
http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional


------
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.