Re: [GRASS-dev] trying to update column with another text column

[Moritz Lennert]

On 04/04/12 08:02, Michael Barton wrote:

I want to update a column with the value of another column. I am using
v.db.update.

The docs say that I can update a column with the value of another column
by specifying that column in the value field. In fact, if I put the
names of numeric columns, this works fine (e.g., v.db.update
map=myvector layer=1 column=summary value=col3 + col4).

But if I do something like this for a string column, I simply get the
string of the name of the column (e.g., v.db.update map=myvector layer=1
column=summary value=col5 put "col5" into the summary column, NOT the
strings that are STORED in col5).

Are the docs wrong or is this a bug?


When the column to update is a string column, the script surrounds the 
value given with the value= parameter with quotes. It could check 
whether the given value is a column name and then not quote it but then 
again, how can we know that the person does not what to just fill a 
column with a string that corresponds to the name of another column ?


Try using the qcolumn parameter.

So docs should be updated to reflect that.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] v.dissolve not working with string column

[Moritz Lennert]

On 04/04/12 07:56, Michael Barton wrote:

I'm trying to do a dissolve but keep getting an error saying that it
only works with integer or string columns. But the column I'm using for
the dissolve IS string.

GRASS 7.0.svn (Spain_utm_wgs84z30):~ > db.describe table=muro_temp
table:muro_temp
description:
insert:?
delete:?
ncols:4
nrows:177

column:cat
description:
type:INTEGER
len:20
scale:0
precision:0
default:
nullok:yes
select:?
update:?

column:Subsector
description:
type:TEXT
len:1000
scale:0
precision:0
default:
nullok:yes
select:?
update:?

column:valley
description:
type:TEXT
len:1000
scale:0
precision:0
default:
nullok:yes
select:?
update:?

column:sector
description:
type:TEXT
len:1000
scale:0
precision:0
default:
nullok:yes
select:?
update:?


GRASS 7.0.svn (Spain_utm_wgs84z30):~ > v.dissolve input=muro_temp
column=sector output=muro_sectors3
ERROR: Key column must be of type integer or string
GRASS 7.0.svn (Spain_utm_wgs84z30):~ >


Note above that the column "sector" IS text.

So what is wrong?


v.dissolve checks for integer and character, but not for text.

Try this simple patch:

--- v.dissolve.py   2011-08-17 13:49:29.0 +0200
+++ v.dissolve.new.py   2012-04-04 08:04:00.0 +0200
@@ -66,7 +66,7 @@
 except KeyError:
 grass.fatal(_('Column <%s> not found') % column)

-   if coltype['type'] not in ('INTEGER', 'CHARACTER'):
+   if coltype['type'] not in ('INTEGER', 'CHARACTER', 'TEXT'):
grass.fatal(_("Key column must be of type integer or string"))

 f = grass.vector_layer_db(input, layer)


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] trying to update column with another text column

[Michael Barton]

I want to update a column with the value of another column. I am using 
v.db.update.

The docs say that I can update a column with the value of another column by 
specifying that column in the value field. In fact, if I put the names of 
numeric columns, this works fine (e.g., v.db.update map=myvector layer=1 
column=summary value=col3 + col4).

But if I do something like this for a string column, I simply get the string of 
the name of the column (e.g., v.db.update map=myvector layer=1 column=summary 
value=col5 put "col5" into the summary column, NOT the strings that are STORED 
in col5).

Are the docs wrong or is this a bug?

I'm working with GRASS 7

Michael
_
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, 
http://csdc.asu.edu





___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] v.dissolve not working with string column

[Michael Barton]

I'm trying to do a dissolve but keep getting an error saying that it only works 
with integer or string columns. But the column I'm using for the dissolve IS 
string.

GRASS 7.0.svn (Spain_utm_wgs84z30):~ > db.describe table=muro_temp
table:muro_temp
description:
insert:?
delete:?
ncols:4
nrows:177

column:cat
description:
type:INTEGER
len:20
scale:0
precision:0
default:
nullok:yes
select:?
update:?

column:Subsector
description:
type:TEXT
len:1000
scale:0
precision:0
default:
nullok:yes
select:?
update:?

column:valley
description:
type:TEXT
len:1000
scale:0
precision:0
default:
nullok:yes
select:?
update:?

column:sector
description:
type:TEXT
len:1000
scale:0
precision:0
default:
nullok:yes
select:?
update:?


GRASS 7.0.svn (Spain_utm_wgs84z30):~ > v.dissolve input=muro_temp column=sector 
output=muro_sectors3
ERROR: Key column must be of type integer or string
GRASS 7.0.svn (Spain_utm_wgs84z30):~ >


Note above that the column "sector" IS text.

So what is wrong?
_
C. Michael Barton
Visiting Scientist, Integrated Science Program
National Center for Atmospheric Research &
University Consortium for Atmospheric Research
303-497-2889 (voice)

Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Arizona State University
www: http://www.public.asu.edu/~cmbarton, 
http://csdc.asu.edu





___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction and GSoC

[Eric Momsen]

On Tue, Apr 3, 2012 at 9:57 AM, Moritz Lennert
 wrote:
> I personally am a bit weary of increasing dependencies between packages, but
> at the same time, why re-invent the wheel. Integrating the OTB algorithms
> into GRASS would definitely be a great plus.
>
> This said, several FOSS4G programs out there already play the role of
> integrators (e.g. QGIS, gvSIG) and I'm not sure that GRASS should try to go
> the same direction. Generally, I'd say: let GRASS do really well what it
> does, and not try to integrate everything.
>

This does sound critical to me.  Being "new" to GIS, I have been
struggling to figure out what the differences (strength/weakness/etc)
are between GRASS, QGIS, etc.  I started with GRASS and R and haven't
had time to try out the other programs, so am only comparing based on
what each website describes.  I haven't found any feature comparison
table.  So I am interested to hear what everyone has to say about what
packages should (or should not) be integrated into GRASS vs. what
packages GRASS is integrated into...but I suspect it is a bigger issue
than can be answered in a GSoC project. :)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] PostGIS manager for GRASS GIS

[Mohit Kumar]

Hello Martin,
Sorry couldn't reply earlier as I was stuck with some college work.

On Mon, 2 Apr 2012 21:00:51 +0200, Martin Landa wrote:

Hi,

2012/4/2 Mohit Kumar :
I am interested in making a PostGIS manager in GRASS as a GSoc 
2012 task.
PyGreSQL is a python module that allows easy use of database 
operation

API
from a pyhton script. So it will be like a wrapper over
the database. This can be done using wxPython and will be OS 
independent.
Sorry to bug you all, but I am very much interested in developing 
for

GRASS.


[...]

there is new development ongoing for this in GRASS 7, perhaps a 
good

moment to integrate a manager. Maybe Martin has some insights for
us over the next days.


Its good to know that development is ongoing for this in GRASS, I 
sincerely

want to work on this as my GSoc task.


the current PostGIS-related development in G7 is not much related to
this idea. The vector engine in G7 is currently able to read PostGIS
geometry data natively without any abstract level (like 
OGR-PostgreSQL
driver). Also write support has been recently implemented. The 
current

implementation is focused on simple feature access, GRASS builds a
pseudo-like topology as for OGR links (see v.external). At this 
moment

I am working on PostGIS topology support in GRASS.

I have made a brief idea for the manager. The following are the 
various

modules of the manager
1. Setup connection : This module will set up the connection with 
the remote
database. It will take the input parameters from user and pass them 
to a
connection string. After the connection has been established, the 
user will
be shown the various tables(maps) that are stored and other 
information

about the database and the connection


This is already available in wxGUI [1]. Of course there is always a
space for any kind of improvements. But basically it's already there,
to add widgets for entering username and password is quite easy task.

2. View and edit data : This will display the data of the table in a 
window
frame. One can view the map and modify the table values or the 
attributes.


Also possible in current wxGUI [2]. You just create a link using
`v.external` and display the map in the map canvas as normal GRASS
vector map. Also direct OGR access [3] is possible (no links,
pseudo-topology built on the fly)

3. Import to GRASS Data : This gives the user an option to save the 
data in
Grass format for further processing/analysis of the data. This also 
gives

user an option to discard the data which is of no use.


Possible with `v.in.ogr`. Simple wrapper based `v.in.ogr` for
importing PostGIS is already there [4].

4. Execute PostGis functions (geometry processing)on database and 
save

output in grass data format.


This could be improvement.

5. SQL interface : This provides the advanced user to modify the 
database by

use of direct SQL commands on the database.



6. Export GRASS data to PostGIS data : Convert the Grass Data to SQL
database. First convert the Grass data to Esri Shapefile(.shp) using 
OGR and

then converting that data to SQL database (shape2sql).


Why?? You can export data directly using `v.out.ogr` [5]. No need for
Shapefiles, that's bad idea.

7. Projection support : I was also thinking of adding projection 
support to

the manager.


In which sense, do you mean on-the fly re-projection (ST_transform)?

Martin

[1]

http://grass.osgeo.org/wiki/Working_with_external_data_in_GRASS_7#Using_wxGUI
[2]

http://grass.osgeo.org/wiki/Working_with_external_data_in_GRASS_7#Digitize_OGR_layer_using_wxGUI
[3]

http://grass.osgeo.org/wiki/Working_with_external_data_in_GRASS_7#Direct_access_to_external_data
[4] http://grass.osgeo.org/wiki/PostGIS#Import_into_GRASS
[5] http://grass.osgeo.org/wiki/PostGIS#Export_to_PostGIS


Thanks for your feedback.
I know that various modules are possible in GRASS wxGUI. I want to 
integrate them all and provide a direct interface for them. Regarding 
data Export I was thinking about 'v.out.ogr' only.
And I was talking about on-the fly re-projection. The projection tables 
can be stored in which ever way the user wants.
What more would you like to add to the current idea to make it worth 
for a GSOC proposal?

Looking forward to your support.

Regards,
Mohit Kumar (mohitkharb on irc)
Lab For Spatial Informatics
International Institute of Information and Technology
Hyderabad, India
+91-970-3840-175
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Vector network analysis in WxGUI proposal for GSoC

[Luca Delucchi]

2012/4/3 stepan.turek :
> Hello,
>
> another interesting topic for GSoC  could be integration of vector network
> analysis (modules with prefix v.net) into WxGUI.
>
> This could make this tools accessible for less experienced users, because
> running of these modules from command line requires pretty good knowledge of
> GRASS vector data model (e.g. maps vs. layers... ) and modules are not
> interactive (except d.path).
>
> Module d.path is dependent on x-monitors, so first task would be porting of
> this module into GRASS 7.
>
> Development could also include improving of Attribute Table Manager of
> capability of field calculator  (e. g. to calculate cost values for network
> segments).
>
> Could be this topic suitable for GSoC? I would be grateful for any feedback!
>

yes, for my point of view this proposal could be very interesting topic

> Thanks,
> Stepan
>


-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Vector network analysis in WxGUI proposal for GSoC

[stepan.turek]

Hello,



another interesting topic for GSoC  could be integration of vector network
analysis (modules with prefix v.net) into WxGUI.




This could make this tools accessible for less experienced users, because
running of these modules from command line requires pretty good knowledge of
GRASS vector data model (e.g. maps vs. layers... ) and modules are not
interactive (except d.path).






Module d.path is dependent on x-monitors, so first task would be porting of
this module into GRASS 7.






Development could also include improving of Attribute Table Manager of
capability of field calculator  (e. g. to calculate cost values for network
segments). 




Could be this topic suitable for GSoC? I would be grateful for any feedback!




Thanks,

Stepan









































___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction and GSoC

[Moritz Lennert]

On 03/04/12 16:12, Eric Momsen wrote:

Thanks for the input!  I added some more questions below.

Also, later today I will probably post to R-Sig-Geo (or some other
list?) to ask what tools people currently use, and what areas they
would find most helpful to be integrated into GRASS.  That might help
focus where I should spend the time.

On Mon, Apr 2, 2012 at 6:42 AM, Moritz Lennert
  wrote:

On 30/03/12 23:56, Eric Momsen wrote:


I am reading more about image classification (from
http://grass.osgeo.org/wiki/GRASS_SoC_Ideas ):

4. Implement image segmentation algorithms and tools
5. Implement region-based classification
6. Implement hierarchical classification tools (e.g. being able to
create a large class "forest", with subclasses of different types of
forests)


...

Concerning the ideas:

4. Currently GRASS does not provide any image segmentation as such. i.smap
contains image segmentation in its process, but the user cannot get
segmented outputs. Many algorithms exist and its an ongoing field of
research. FLOSS software that provide such algorithms include Orfeo Toolbox
(OTB), SAGA, R, Sextante (?) and probably a whole series of others. I think
the implementation of a series of such algorithms could be a project on its
own.


Does it make more sense to implement the algorithms again, or pick the
most useful that are implemented in some other FLOSS and provide an
easy integration to access them from the GRASS front end?  (I'm
thinking of v.krige which uses existing R packages to do the
processing work.)

Has Sextante or OTB been tied into GRASS in this manner?


I personally am a bit weary of increasing dependencies between packages, 
but at the same time, why re-invent the wheel. Integrating the OTB 
algorithms into GRASS would definitely be a great plus.


This said, several FOSS4G programs out there already play the role of 
integrators (e.g. QGIS, gvSIG) and I'm not sure that GRASS should try to 
go the same direction. Generally, I'd say: let GRASS do really well what 
it does, and not try to integrate everything.


So, the discussion boils down to: what do we think should be integral 
part of GRASS (the same question is true for the proposal concerning a 
PostGIS manager).





5. One of the main applications of image segmentation today is in
region-based classification of very high resolution imagery. As with current
resolutions individual objects are composed of many pixels, it is often more
efficient to first identify "objects" or homogeneous multi-pixel regions in
the image through segmentation and then to classify these regions. OTB
provides this I think, but I don't know if any other FLOSS software does. 5
depends on 4, so it is only possible if 4. is limited to the strict minimum
in terms of segmentation algorithms and then focus is put on 5. Maybe a bit
too ambitious.


If I can use the OTB implementation from GRASS, then I will include
this as a stretch goal if time remains at the end of the summer.


As always, we should check how much integrating OTB means in terms of 
added dependencies for GRASS. Also, OTB is C++ which AFAICT tell often 
spells trouble. Then again, there is a Python wrapper which you could use.


Don't know what others think of all this.

Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction and GSoC

[Eric Momsen]

Thanks for the input!  I added some more questions below.

Also, later today I will probably post to R-Sig-Geo (or some other
list?) to ask what tools people currently use, and what areas they
would find most helpful to be integrated into GRASS.  That might help
focus where I should spend the time.

On Mon, Apr 2, 2012 at 6:42 AM, Moritz Lennert
 wrote:
> On 30/03/12 23:56, Eric Momsen wrote:
>>
>> I am reading more about image classification (from
>> http://grass.osgeo.org/wiki/GRASS_SoC_Ideas ):
>>
>> 4. Implement image segmentation algorithms and tools
>> 5. Implement region-based classification
>> 6. Implement hierarchical classification tools (e.g. being able to
>> create a large class "forest", with subclasses of different types of
>> forests)
>>
...
> Concerning the ideas:
>
> 4. Currently GRASS does not provide any image segmentation as such. i.smap
> contains image segmentation in its process, but the user cannot get
> segmented outputs. Many algorithms exist and its an ongoing field of
> research. FLOSS software that provide such algorithms include Orfeo Toolbox
> (OTB), SAGA, R, Sextante (?) and probably a whole series of others. I think
> the implementation of a series of such algorithms could be a project on its
> own.

Does it make more sense to implement the algorithms again, or pick the
most useful that are implemented in some other FLOSS and provide an
easy integration to access them from the GRASS front end?  (I'm
thinking of v.krige which uses existing R packages to do the
processing work.)

Has Sextante or OTB been tied into GRASS in this manner?

>
> 5. One of the main applications of image segmentation today is in
> region-based classification of very high resolution imagery. As with current
> resolutions individual objects are composed of many pixels, it is often more
> efficient to first identify "objects" or homogeneous multi-pixel regions in
> the image through segmentation and then to classify these regions. OTB
> provides this I think, but I don't know if any other FLOSS software does. 5
> depends on 4, so it is only possible if 4. is limited to the strict minimum
> in terms of segmentation algorithms and then focus is put on 5. Maybe a bit
> too ambitious.

If I can use the OTB implementation from GRASS, then I will include
this as a stretch goal if time remains at the end of the summer.

>
> 6. In the current classification algorithms in GRASS each designated class
> of pixels is on the same hierarchical level as others. However, it is often
> interesting to provide the option to classify an image first in a rough
> manner into a series of base classes (built-up, vegetation, naked soils) and
> then to refine classification within each of these classes (e.g. built-up
> into high-density / low-density, vegetation into forest, grasslands, etc),
> but to keep the hierarchy, i.e. to allow extracting an image (and a legend)
> of the classification at each level.
>

This sounds interesting as well.  It seems I should propose either 4/5
or 6 for the summer work.

> Hope this helps and maybe motivates others to join-in as mentors.
>
> Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GsoC2012: High level map interaction with python

[Luca Delucchi]

2012/4/1 Pietro :
> Hi everyone!
>

Ciao Pietro

>
> Any suggestions and criticism are more than welcome!
>

I like the idea, I have no suggestions or criticism about your proposal.
I could be the co-mentor or the mentor, if anyone with more
experiences propose his self us mentor. I don't know very well ctypes
but I can study it

> Pietro
>

-- 
ciao
Luca

http://gis.cri.fmach.it/delucchi/
www.lucadelu.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction and GSoC

[Moritz Lennert]

On 03/04/12 10:23, Moritz Lennert wrote:

On 02/04/12 22:03, Markus Neteler wrote:

On Mon, Apr 2, 2012 at 1:42 PM, Moritz Lennert
 wrote:
...

4. Currently GRASS does not provide any image segmentation as such.
i.smap
contains image segmentation in its process, but the user cannot get
segmented outputs.


Just a small comment - even not this one?
http://grass.osgeo.org/wiki/GRASS_AddOns#r.seg
r.seg performs image segmentation and discontinuity detection (based on
the Mumford-Shah variational model).


Ah, another GRASS module I didn't know about. ;-)



Perhaps it could be extended?


I'll have a look at it.


I did a rapid test with a landsat image:

for lambda in 0.01 0.1 1 10 100
  do
for alpha in 0.01 0.1 1 10 100
  do
 r.seg in_g=L72199024_02420020729_B80@PERMANENT 
out_u=test_seg_$lambda\_$alpha out_z=test_seg_dis_$lambda\_$alpha 
lambda=$lambda alpha=$alpha --o

 r.colors -e map=test_seg_$lambda\_$alpha color=grey
 r.colors -e map=test_seg_dis_$lambda\_$alpha color=grey
  done
  done

The lamba=100 and alpha=100 seems to give visually me roughly what I was 
thinking of, i.e. a series of regions. However, each pixel still has a 
different value and so I would have to go through more steps before I 
could try to delineate actual polygons which I could then classify.


AFAIU (and this is still a bit limited) r.seg seems to be more oriented 
towards visualisation than towards further treatment of identified 
"segments".


Moritz
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] GSOC 2012 WXGUI GRASS

[Sudeep Singh]

Hi,

My name is sudeep. I am final year undergraduate student in computer
science at Indian Institute of Technology, Kharagpur . I am interested to
apply for the project with GRASS WXGUI. I am interested in the following
projects
1. windows-flooding
2. Develop GUI support in wxPython for visualy analyzing series of raster
map layers

I last year worked with Grass in GSOC, 2011 and implemented WMS support for
WXGUI.

Kindly let me know how shall I proceed with the proposal.

Thanks
Sudeep
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Introduction and GSoC

[Moritz Lennert]

On 02/04/12 22:03, Markus Neteler wrote:

On Mon, Apr 2, 2012 at 1:42 PM, Moritz Lennert
  wrote:
...

4. Currently GRASS does not provide any image segmentation as such. i.smap
contains image segmentation in its process, but the user cannot get
segmented outputs.


Just a small comment - even not this one?
http://grass.osgeo.org/wiki/GRASS_AddOns#r.seg
r.seg performs image segmentation and discontinuity detection (based on
the Mumford-Shah variational model).


Ah, another GRASS module I didn't know about. ;-)



Perhaps it could be extended?


I'll have a look at it.

Moritz

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #1633: Unable to display shapefile attribute table due to pipe characters in dbf field

[GRASS GIS]

#1633: Unable to display shapefile attribute table due to pipe characters in dbf
field
-+--
 Reporter:  richardc |   Owner:  grass-dev@…  
 Type:  defect   |  Status:  new  
 Priority:  critical |   Milestone:  6.4.3
Component:  Display  | Version:  6.4.1
 Keywords:   |Platform:  Linux
  Cpu:  Unspecified  |  
-+--
 Hi,

 I'm receiving the following error on attempting to view the attribute
 table of shapefiles in GRASS 6.4.1.2 (on Ubuntu Lucid):


 item = layer, log = self.goutput)
   File "/usr/lib/grass64/etc/wxpython/gui_modules/dbm.py",
 line 653, in __init__

 self.__createBrowsePage()
   File "/usr/lib/grass64/etc/wxpython/gui_modules/dbm.py",
 line 698, in __createBrowsePage

 self.mapDBInfo, layer)
   File "/usr/lib/grass64/etc/wxpython/gui_modules/dbm.py",
 line 95, in __init__

 keyColumn = self.LoadData(layer)
   File "/usr/lib/grass64/etc/wxpython/gui_modules/dbm.py",
 line 247, in LoadData

 self.AddDataRow(i, record, columns, keyId)
   File "/usr/lib/grass64/etc/wxpython/gui_modules/dbm.py",
 line 286, in AddDataRow

 if self.columns[columns[j]]['ctype'] != types.StringType:
 IndexError
 :
 list index out of range

 '''Method:'''
 I import the shapefile as follows:

 Layer Manager > File > Import vector data > Common import formats > Select
 ESRI shapefile > Browse and select file > Import

 And then select the layer in 'Layer Manager', and click on the 'Show
 attribute table' icon. Then the error results

 'Please wait loading attribute data..' with the following in the command
 console -

 if self.columns[columns[j]]['ctype'] != types.StringType:
 IndexError
 :
 list index out of range


 On closer inspection of the dbf file, some of the fields contain pipe
 (i.e., '|') characters. On removing these the attribute table can be
 displayed.

 QGIS is able to display all data in the attribute table, including 'pipe'
 characters.

 Example of problem fields in single column named 'VARNAME_1,C,150':

 VARNAME_1,C,150

 Bangkok|Krung Thep|Krung Thep Maha Nakhon|Phra Nakhon-Thonburi
 Buri Rum
 Chaxerngsao|Pad Rew|Paed Riu|Petrieu|Shajeun Dhrao
 Chainat
 Chantaburi|Muang Chan

 NOTE: issue posted originally at http://osgeo-org.1560.n6.nabble.com
 /Index-error-Unable-to-show-attribute-table-of-shapefile-
 tp4678952p4678952.html

-- 
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev