[GRASS-dev] [GRASS GIS] #1633: Unable to display shapefile attribute table due to pipe characters in dbf field
#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: http://trac.osgeo.org/grass/ticket/1633 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Introduction and GSoC
On 02/04/12 22:03, Markus Neteler wrote: On Mon, Apr 2, 2012 at 1:42 PM, Moritz Lennert mlenn...@club.worldonline.be 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] GSOC 2012 WXGUI GRASS
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] GsoC2012: High level map interaction with python
2012/4/1 Pietro peter.z...@gmail.com: 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
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 mlenn...@club.worldonline.be 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
[GRASS-dev] Vector network analysis in WxGUI proposal for GSoC
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] Vector network analysis in WxGUI proposal for GSoC
2012/4/3 stepan.turek stepan.tu...@seznam.cz: 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
Re: [GRASS-dev] PostGIS manager for GRASS GIS
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 mohit.kumaru...@students.iiit.ac.in: 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] Introduction and GSoC
On Tue, Apr 3, 2012 at 9:57 AM, Moritz Lennert mlenn...@club.worldonline.be 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
