Re: [GRASS-user] GRASS 6.4.2RC2 crashing during digitising
Hi, 2011/12/27 Markus Neteler : [...] > @devs: Since you wrote that all windows disappeared, I wonder if the crash > log could be saved anywhere for inspection? if you enable WX_DEBUG or DEBUG messages then any error messages are redirected to the terminal. Debug messages `g.gisenv set=DEBUG=5` would help to understand what is wrong with digitizer. Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS 6.4.2RC2 crashing during digitising
On Mon, Dec 26, 2011 at 4:32 AM, Shane Litherland wrote: > Hi all, > > Note this is in the WXPYTHON GUI > > I have been digitising vectors, using tools including add new boundary > or centroid, move vertex, delete vertex, split line, probably a few > others too. > > Most of the time no problems, but I just had GRASS crash (all windows > disappeared, only the 'terminal' I started it from still open) after > using the split tool, then using the 'delete vertex' tool. I selected a > boundary vertex to delete (left-mouse click), then on right-click to > confirm, it all crashed. Please post the error messages which you can find in the wxGUI console. Then it will be way easier to figure out the problem. @devs: Since you wrote that all windows disappeared, I wonder if the crash log could be saved anywhere for inspection? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] no v.overlay with empty map: bug or feature?
Hello, With grass 6.4 I could do a v.overlay with an empty map. That was in a loop to overlay different maps, so I thought I could start from an empty map, and then overlay tables one at a time and process the result to remove unneeded columns and rename them. With grass 7 (svn from yesterday) it doesn't seem to work anymore: v.in.ascii -e output=empty_map input=- v.in.region output=other_map v.overlay ainput=empty_map binput=other_map output=maps_overlay operator=or Copying vector features from ... ERROR :No area features found in vector map . Verify 'atype' parameter. I can try the other way around, after adding a table to other_map, same error: v.db.addtable other_map v.overlay ainput=other_map binput=empty_map output=maps_overlay operator=or Copying vector features from ... 100% Copying vector features from ... ERROR :No area features found in vector map . Verify 'btype' parameter. I already have a workaround, and I can see the point of the error message. Yet, I am not completly sure that overlaying with an empty map should never be possible. Is it a bug, or is it on purpose? If it is a bug I will report it in the tracker, but I am not sure it is indeed a bug. -- Pat ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 'v.distance'
Dear List, I have a points vector file, which I use as input in 'v.distance' to create a new vector file of lines (showing the minimum distance to the coast). The output is naturally a vector file that contains lines between each point and the sea. However, I realize that the output map cannot be queried. Even if I have GRASS connect the new (lines) vector file with the points as the second layer, querying of the lines does not return results. What I want to do is to assign CAT numbers to each line (it can be same with the CAT# of its point of origin) so that I can display lines individually in the new lines vector file for further analyses. Thank you for your help! Bulent ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.vect.thematic in wxgui
Hi again, here's some of my experience with the d.vect.thematic in 6.4.2RC2 wxgui: I tried doing a basic process through the dialog i.e. select a map, feature type=area, pick a column, 5 intervals, most of other settings were default. I ran it, and it showed the vector in thematic colouring, as a new layer in the existing display. It was listed as a layer in the layer manager too. Right-clicking on it in the manager and choosing properties, brought up the d.vect.thematic dialog again, not the d.vect properties dialog that other 'normal' vector layers showed. Seemed right to me. Trying to use the query tool on the layer in the display window repeatedly gave me a message that: "no map layer selected for querying" I checked it was the active layer in manager, and tried several places on the thematic as I could see it in the display, with same result. I tried zooming in/out to see if I could select a spot better (maybe I wasn't getting the mouse click over the middle of the area, or over where the centroid should be?..) and had a strange result. The display did zoom, but the thematic was redrawn at the new scale whilst the previous draw remained in place. even using the display/render map tools in the display window did not 'clear' it up. So after three or four zooms, I had a very colourful tessellation of my thematic vector layer at multiple scales, but it was not very useful for data analysis :-} the panning tool at first seemed to be dragging the thematics and background around in the display window, but upon releasing the mouse, the background was redrawn in the new position but the thematics 'snapped' back to the same position they were relative to the display window. i.e. if I had some thematic areas coloured lower-left of screen, and I panned the display so they and background seemed to be centred, the background would redraw with my new 'centre' but the thematic that was lower-left still showed in lower-left. So it was no longer over the same bit of ground, in effect. Is this tool still a 'work in progress' to be fully functional in wxgui? Or should it be working but I have found a bug? A coupla questions moving past the issue of whether it works or not: Can I use SQL or v.class or mathematical combos of columns for the 'column' input (similar to use in v.class or d.thematic.area)? It seems I have to select a column from the table, looking at the dialog box for this tool. In my situation, I want to use column_3 x (column_4 squared) as the value input for the 'column' part of the command. I can easily create this value in the table with a bit of SQL but if I can implement this step in GRASS it would keep the table smaller and be more versatile for use. I wanted to use the query tool as mentioned above, to check what values the thematic had chosen... I'd previously used a thematic tool in tcltk in earlier GRASS versions and noted that for a vector layer with numerous cats for each centroid, the value chosen for the thematic corresponded to the entry with the highest cat (generally the most recent entry). I actually wanted to display the highest value from the column in question for all of the entries... Does anyone know if d.vect.thematic can be manipulated to define what values it uses for a given area/point/etc if multiple values exist for that area/point? in some cases, maybe I do want to display the value from the most recent event, other times I might want to see the max or min value at that point from all the values for that area/point. I am OK at doing bits like this in SQL, but am somewhat lost as to how I'd cover the geospatial aspect if GRASS itself can't do it. I am wondering if using PostGIS to put a geometry column to the table in question might be what I should pursue? Then I could do all the selecting/filtering in SQL feed a 'view' (as a 'table') to GRASS to do the d.vect.thematic on? Hope the comments above are useful; hope someone has feedback on my latter questions :-) -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.area.thematic ? and other d. in wxgui
Fellow GRASSers, I have been playing/reading through vector classification, in the help files under v.class, there is reference to d.area.thematic which actually opens up a help page for d.thematic.area. I was also looking via the wxgui search module, for either combination of these tools, didn't seem to come up in the menu tree. I tried typing either of these into the command console, the latter gave a message that it's not yet implemented in wxgui, the former had no match. So it seems the reference to d.area.thematic in the help files (at least on the v.class page) is merely a typo? Whilst looking around, I happened to type d.vect.. in the command console, and found there was a d.vect.thematic tool. It opened up a dialog for me to play with. Yet using the search module, I could not find where d.vect.thematic was in the menu tree. In fact, I had trouble finding where many d. commands are in the wxgui, I tried entering a few in the command console from the several that came up for auto-fill, often got a message about 'not yet in wxgui' so are most d. commands still a work in progress to activate in wxgui? I have more question/comments regarding d.vect.thematic, a tool which I found in wxgui that seems to do a similar task to d.thematic.area, in a separate post. -shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS 6.4.2RC2 crashing during digitising
Hi all, Note this is in the WXPYTHON GUI I have been digitising vectors, using tools including add new boundary or centroid, move vertex, delete vertex, split line, probably a few others too. Most of the time no problems, but I just had GRASS crash (all windows disappeared, only the 'terminal' I started it from still open) after using the split tool, then using the 'delete vertex' tool. I selected a boundary vertex to delete (left-mouse click), then on right-click to confirm, it all crashed. When I have just started up GRASS again, I found that vector had boundaries and centroids, but the areas were not shaded. when I started the digitiser mode, it gave me the 'no topology' message. I clicked OK to rebuild, and it crashed again, though in the terminal I noted the usual output from when topology is rebuilt (e.g. number of boundaries, centroids, number of areas without centroids, etc). Upon starting GRASS a third time, I found that vector still did not have topology. I used the v.build (rather than just asking it to rebuild prior to digitising). This seemed to recover my vector correctly, and did not cause a GRASS crash. I found one area that seemed to have 'lost' its centroid though. I was checking the data (in digitising mode) for the areas I'd digitised before the crash, they seemed in order, then I used the pan tool (about the third time I'd used it whilst in this digitising session) to move towards the part of the map where I'd been working at the time of the initial crash, and GRASS crashed again! Upon starting up GRASS AGAIN! I found that vector had lost topology AGAIN. run v.build again, seemed to correct the problems, tried to open up digitiser mode and it crashed AGAIN. Did a shut-down and restart of my computer. Another GRASS session - had to do v.build again, then it crashed when I tried to enter digitiser mode and select that vector layer. Went back to running GRASS in tcltk. Had to do v.build on the vector in question, but could open it for editing with v.digit. I got a message upon running v.digit that "Coor files of vector map is larger than it should be (1113 bytes excess)" Which I understand as I've come across this sort of message before when vectors have been corrupted or there's erroneous boundaries/centroids etc floating around from a job part-done before a crash. Why though, has this occurred in the first place (i.e. the initial crash and loss of topology when using 'move vertex' tool in digitiser)? It seems all the crashes that followed in wxgui when I tried to get back to the vector to correct/digitise may have been caused by this coor file error, but the wxgui didn't tell me that, it just crashed repeatedly. at least the tcltk gui has told me of this problem, so now I could get on to fixing it with v.digit. I tidied up the boundaries/centroids where I'd had the crash, found a single-point boundary in existence under one of the vertices of a 'proper' boundary, not sure how or when this could/would have been created. But along with some unclosed boundaries and centroids in these unclosed areas, I got it tidy, and tried wxgui again. HOORAY! I can digitise again in wxgui, it didn't crash! Now, this experience is currently too longwinded to report as a bug, does anyone else have some suggestions on what parts would be the relevant bits if I was to report this as a bug? do I need to run GRASS and replicate the problem with 'debug' mode or something to get more useful output on what's happening? Feedback appreciated. As a footnote - I don't mind persevering with 'newer' GRASS versions to help figure out glitches etc, but it is frustrating when the glitches I find cause substantial loss or corruption of my data. I do have irregular manual backups, but even losing half-an-hour's worth of work between backups, and taking twice as long to check/restore/redo it all is precious wasted time for me. Does anyone else have a protocol (maybe an auto-save to 'filename-dateextension') to reduce their data loss / downtime when testing out newer GRASS setups on their system? -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
