[Gvsig_english] JOIN

Wed Feb 4 15:25:32 CET 2009

Switch to the "Tables" section in the project manager.
There should be an item "Start editing" in the "Tables" menu now.

You can then use "Manage fields" to edit the table structure.

To set/calculate the value of a field, click on the field heading
in the table view first, then choose "Field->Expression".

Take a look at the OA Digital Quickstart Guide which should have
come with your installation of gvSIG ...

Ben

Kai-Christian Bruhn wrote:
> Step 1 refers to one of my initial questions: How to start editing of 
> imported tables?
> 
> Benjamin Ducke schrieb:
>> CSV import is currently too limited to be really useful, I think.
>> For the time being, the preferred way to import simple tables is
>> via DBF.
>>
>> However, you can make data imported from a CSV file more useful
>> in gvSIG: use the Field Calculator.
>>
>> E.g.to convert a key field for joins from text to numeric:
>>
>> 1. Start editing the imported table
>>
>> 2. Create a new, numeric field for the key
>>
>> 3. Use the "toNumber" function in the field calculator to
>> create numeric values from the original text type key field
>>
>> 4. delete the old field
>>
>> Again, an extra step, but at least can be done in gvSIG itself.
>>
>> Ben
>>
>> Kai-Christian Bruhn wrote:
>>> Hi Ben,
>>>
>>> thanks a lot!
>>>
>>> Good to know about the limitations of the csv-import. So what is it 
>>> actually good for? Comma Separated Values as strings in a GIS?
>>>
>>> The dbf-import works fine. I'm preparing some manuals for basic 
>>> editing and would have loved to omit another step (csv2dbf) before 
>>> joining in gvSIG.
>>>
>>> Anyway, I conclude that csv-import is dubious and that there is no 
>>> gvSIG-internal solution for editing plain table data. Agree?
>>>
>>> Kai
>>>
>>> Benjamin Ducke schrieb:
>>>> The CSV import in 1.1.2 is weak in that it imports all table fields
>>>> as type "text". Unfortunately, you cannot use a field of that type
>>>> as a key field in a join operation. The key field needs to be type
>>>> "integer". Instead of joining data from a CSV file, save your data
>>>> as DBF (Open Office Calc does that just fine, but so should Excel --
>>>> with some added quirks, I suspect). Make sure to set the field type
>>>> to numeric with zero decimal places in your spreadsheet.
>>>> Then join the DBF table to your Shapefile.
>>>>
>>>> Ben
>>>>
>>>> Kai-Christian Bruhn wrote:
>>>>> Dear list,
>>>>>
>>>>> this and the related thread starts to convince me that I'm the 
>>>>> problem in joining attribute tables and not gvSIG. Nevertheless, I 
>>>>> tried several times to join an imported csv-file with a 
>>>>> shape-dbf-file - and failed. So please dwell a little more on that 
>>>>> subject.
>>>>> The details:
>>>>> gvSIG OA Digital Edition with Java 1.6.0_07 on XP Professional
>>>>> A shapefile with 2D-points, an integer attribute fo_id and more string
>>>>> type attribute fields.
>>>>> A csv-file like this:
>>>>> fo_id;type
>>>>> 1;burial
>>>>> 2;single finding
>>>>> 3;burial
>>>>> 4;pit
>>>>> etc...
>>>>> Both tables are in the project manager table view but join wouldn't
>>>>> work. I guess the problem emerges already during the import
>>>>> of the csv, as it seems to take the fo_id as a string type, not as
>>>>> integer. So when trying to join fo_id from the shape-dbf the 
>>>>> dropdown of
>>>>> the last dialogue where to choose the field from the csv for 
>>>>> joining is
>>>>> empty. For testing I went the other way around, calling the 
>>>>> imported csv
>>>>> first and the shape-dbf second. The last dropdown then offers only the
>>>>> string-type fields from the attribute table of the shape-dbf.
>>>>>
>>>>> Is there any way to edit plain table data in gvsig?
>>>>> Is there a way to assign types to imported table fields?
>>>>> Does it need a csvt-file as in ogr2ogr csv-handling to assign types 
>>>>> to data?
>>>>>
>>>>> Or am I simply incapable?
>>>>>
>>>>> Cheers
>>>>>
>>>>> Kai
>>>>>
>>>>> John Ladd schrieb:
>>>>>> With a little help from Benjamin Ducke I determined what I was doing
>>>>>> wrong re the JOIN function.  I was not paying attention to the 
>>>>>> buttons
>>>>>> on the first of the four screens and was then making wrong 
>>>>>> assumptions
>>>>>> re buttons on successive screens where the buttons were not clearly
>>>>>> labelled.  In hindsight this sounds just careless on my part, but it
>>>>>> underscores the problems faced by new users.  Somewhere long ago I
>>>>>> read that in the process of developing software for third party use
>>>>>> ~20% of the effort is generating software that works for the 
>>>>>> developer
>>>>>> and ~80% of the effort is packaging the software so that the third
>>>>>> party can use it.
>>>>>>
>>>>>> thank you for your patience.
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Gvsig_internacional mailing list
>>>>> Gvsig_internacional at runas.cap.gva.es
>>>>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Gvsig_internacional mailing list
>>> Gvsig_internacional at runas.cap.gva.es
>>> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
>>>
>>>
>>
>>
> 
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_internacional
> 
> 

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