[GRASS-user] Re: grass-user Digest, Vol 70, Issue 7
Hi Aldo, Martin In last week I to did some work with adding scale/north to a map. using 6.4.svn (a couple of days behind update at time of post). With python wx GUI Found similar to Aldo, where adding scalebar seemed to be a 'once-off' option, couldn't click on it etc to edit. using icon on toolbar to open 'add scalebar' again didn't seem to help, I may have even crashed the display/GRASS at one point by clicking around too much on that... but at time was busy to print the map so did what I had to do to get job done and continued. Other bits I noticed, was if I chose to use print icon, and sent to pdf, much of the map was a black box, with scalebar in top-left of black box but positioned on right place of map. Black box though seemed to be this huge bit of extra space associated with scalebar. printing/exporting to .png image did not result in this black box. Also, if I made a scalebar but then zoomed map in/out, the scalebar stayed the same size and in the same position within the display window, not in the same position relative to the map. So whatever calculates the scalebar does not refresh if zoom is used after creation of the scalebar. Have not tried any of this back in tcltk GUI Any aspects here worth verifying and adding to a bug report, or putting in as their own bugs? Aldo - let me know what bug # you have for putting yours in. regards, shane. -- Message: 3 Date: Sat, 4 Feb 2012 12:09:47 +0100 From: Aldo Clerici aldo.cler...@unipr.it Subject: [GRASS-user] Problems with histogram and scalebar in wxpython GUI (GRASS6.4.2RC3) To: grass-user@lists.osgeo.org Message-ID: 059f01cce32d$81c6e1b0$8554a510$@cler...@unipr.it Content-Type: text/plain; charset=us-ascii Dear GRASSusers and developers, I'm using GRASS6.4.2RC3 under Fedora 16 and I'm having problems with the wxpython GUI. 1) In the 'Create histogram of raster map' function, the style pie and the Color for text and axes options are not working. The options run fine on the tcltk GUI and in command line mode. 2) In the 'Add scalebar and north arrow', the scale can be modified only once and the option can't be re-entered nor the scale can't be deleted. Also in this case there are no problems with the tcltk GUI. Bugs or something wrong in my Python? Many thanks in advance A. Clerici Parma University -- next part -- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20120204/a55a85be/attachment-0001.html -- Message: 4 Date: Sat, 4 Feb 2012 12:44:23 +0100 From: Aldo Clerici aldo.cler...@unipr.it Subject: [GRASS-user] Problems with histogram and scalebar in wxpython GUI (GRASS6.4.2RC3) (supplement) To: grass-user@lists.osgeo.org Message-ID: 05aa01cce332$574b62d0$05e22870$@cler...@unipr.it Content-Type: text/plain; charset=us-ascii In GRASS6.4.0 USB version I have the same problems with the histogram, but add scalebar works fine. A. Clerici -- next part -- An HTML attachment was scrubbed... URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20120204/03696e42/attachment-0001.html -- Message: 5 Date: Sat, 4 Feb 2012 13:36:48 +0100 From: Martin Landa landa.mar...@gmail.com Subject: Re: [GRASS-user] Problems with histogram and scalebar in wxpython GUI(GRASS6.4.2RC3) To: Aldo Clerici aldo.cler...@unipr.it Cc: grass-user@lists.osgeo.org Message-ID: ca+ei1oe25coqmckglqfaqxilbfj-07ey-7sbo8b14r072k8...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, 2012/2/4 Aldo Clerici aldo.cler...@unipr.it: 1) In the 'Create histogram of raster map' function, the style pie and the Color for text and axes options are not working. right, wxGUI histogramming tool happily ignores any d.histogram settings expect map name, see [1]. Please fill a bug report, I would assume that this bug will be fixed for 6.4.3 (where wxGUI code base will change). Martin [1] http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/gui/wxpython/gui_modules/histogram.py#L341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] how to report/measure a vector area?
Thanks Micha, I've used v.to.db a bit, just not recently enough to remember that was my answer! Thanks for your tips/reminder, I should be OK in getting it to happen for me now :-) If you don't hear from me again on this, I've succeeded. regards, shane. On Mon, 2012-01-30 at 10:01 +0200, Micha Silver wrote: On 30/01/2012 09:52, Shane Litherland wrote: Hi all, I'm lost. I have looked around in GRASS for how to report the area (e.g. in hectares) for a vector map that, yes, has area (i.e. centroids and boundaries). I cannot find a way to do this. A bit of web searching, even gave some suggestions this basic facility may not be available in GRASS?? surely there's something tucked away to do it? I'm sure I've done something in the past to view vector area data, though it may have been area data that was already in a table. When I use the query tool in map display, it tells me 'nothing'. Seems that is because my vector is not connected to an attribute table. For the purpose of my exercise I did not need cats for the boundaries/centroids so I didn't bother with a table connection either. Maybe this is where I've gone wrong? I did try vector to raster to try and report on how many raster cells/area... no luck there either. I also tried the 'measure' tool in the map display, but it only gives distance. I could go and learn more about PostGIS for sending the vector data to a postgres geometry table and figure it out that way... I was hoping to find a way to do it in GRASS in a matter of minutes, not via a database and a couple of days/weeks of learning how... What tool/command should I be using? v.to.db is what you need. From the man page: Upload polygon areas to corresponding centroid record in the attribute table: v.to.db map=soils type=centroid option=area col=area_size unit=h You'll need to start by adding a database connection and a column for area. Again in the man page there's a sample you can follow- just use option=area instead of option=sides: Upload category numbers of left and right area, to an attribute table of boundaries common for the areas: # add categories for boundaries of the input vector map, in layer 2: v.category soils out=mysoils layer=2 type=boundary option=add # add a table with columns named left and right to layer 2 of the input # vector map: v.db.addtable mysoils layer=2 col=left integer,right integer # upload categories of left and right areas: v.to.db mysoils option=sides col=left,right layer=2 # display the result: v.db.select mysoils layer=2 regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user This mail was received via Mail-SeCure System. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: GRASS-user] how to report/measure a vector area?
Hi all, yes,yesYES thank you for your inputs :-) it was a simple case of me not having a table with the info in to start with, so once i remedied that with v.to.db (hello old friend, where have you been hiding?) reports and map queries were a breeze, as well as easy calculations directly on the table in sql (in pgadmin) to answer the number-crunching I desired. A happy chappy :-) and although I noted a coupla odd things in the digitiser (which I'm still to check in north carolina dataset and give feedback on) i managed to NOT do any bad combination of mouse-clicks and ruin the vector in question ;-) soon i'll earn the badge of guru-beginner ;-) -shane. On Mon, 2012-01-30 at 12:53 -0800, Hamish wrote: Michael wrote: v.report Ismael wrote: v.to.db Michael: Yes. The cool (and sometimes confusing) thing about GRASS is that often there are several ways of getting the result you want. n.b. in this case v.report is just a more obvious wrapper-frontend to v.to.db. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] RE: Hidrological network (ALT SHN)
Hi Andr, You mention that you have streams of different 'order', does that mean you have a table connected with a column containing a value for each bit of stream (e.g. the river and tributaries are a combination of vector lines, and each line between one stream junction and the next has a 'stream order' number)? If so, could you do something as simple as putting a sql query in the 'where' box of the properties dialog (on the 'selection' tab)? e.g. (where) stream_order_column4 ? This has worked for me when viewing a stream-order vector map with appropriate values. (this properties tab is the gui for d.vect, if you're looking for it by other means) I am not sure if, after that stage, you may be able to save a copy of that vector with the same 'where' criteria applied during the copy process, to then have a smaller vector file for your own use. Or copy the entire vector then delete/drop the vectors (and attributes from table) for the higher-order streams you don't want? Any other thoughts on this one people? or am I paddling up the wrong stream, so to speak? -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: setting up GRASS svn
Hi Markus, Thanks for confirming why my initial fumbling didn't appear successful :-) Note that my final outcome was a fresh setup so the hurdles I had along the way aren't residing in my current GRASS now. couple of other notes in context below: On Sat, 2012-01-21 at 21:24 +0100, Markus Neteler wrote: On Sat, Jan 21, 2012 at 5:44 AM, Shane Litherland litherland-f...@bigpond.com wrote: Hi Markus and mailing list; I tackled the svn setup today. after several hrs of web browsing, uninstalling old versions, and trying a few approaches to svn commands, I think I have succeeded. the 'info' under GRASS HELPABOUT GRASS GIS now shows I have 'GRASS GIS 6.4.2svn50340 (2012) Excellent, congrats. A couple of hurdles I had on the way... simply following your initial instruction of: If you compile yourself, consider to switch to the 6.4.x release branch version (stable), which continuously receives bugfixes, using the command: svn checkout https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 grass64_release did something in a terminal, It downloads the source code to your local disk. good to know what happened :-) (note for later explanations) seemed to indicate there were a lot of bits to update to my existing 6.4.2RC2. But I don't think that command by itself did anything to my GRASS version? You needed to execute it in a fresh/empty directory. If you did so in an existing tree, you have a source code version mixture now. Better to fetch it again. this is a good tip to include with INSTALL/Wiki (continued below) I tried running above, then doing 'configure' (with several custom settings) and 'make' and 'checkinstall' which kept the computer busy for awhile, Yes, make does the compilation, i.e. convert the source code into a binary code which is machine readable. but still didn't seem to change my GRASS install... still 6.4.2RC2 (2011) but not a svn version and not 2012?? Yes, because you likely missed the installation step: make install I used checkinstall in preference to make install because (at least on ubuntu) it makes a .deb package for easy uninstall later on (I've found that handy for spring-cleaning). Also use sudo. My problem here would have been a result of not doing it in a clean/empty directory as you noted above. Use of checkinstall came straight from http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu (this page has been quite useful for several occasions of me installing GRASS, thanks!) Note that this may require administrator (root) password or you have to do (depends on your distro): sudo make install After doing this, re-running 'svn update' suggested it was current, but the GRASS program itself told me something else?? Yes (see above). I ended up following tips from http://grass.osgeo.org/wiki/Working_with_SVN i.e. first downloading and installing an svn snapshot. This web page was the only place I found that gave any clear info on how to start off with svn versions. Please tell us which places are *not* clear so that we can fix them. The downloads page http://grass.osgeo.org/download/software.php#g64x would be the starting point - either on this page or on the pages that can be opened from here that relate to svn e.g. on this page http://grass.osgeo.org/devel/svn.php you could provide a link 'how to (start to) use GRASS svn' to http://grass.osgeo.org/wiki/Working_with_SVN and/or http://grass.osgeo.org/wiki/Compile_and_Install (or would both these pages be better condensed into one?) The same link/s could be done for http://trac.osgeo.org/grass/wiki/DownloadSource Note that 'Working with SVN' page could do with some correction at the end of the 'first time' section - it goes as far as explaining 'svn update' but doesn't state one must continue with ./configure, make and make install (the reader can infer this from the next bit of info on updating, but it doesn't need to be left up to inference;-) ) Markus, your tips above could be added to that 'Working with SVN' page, in the Setting it up first time section, particularly if the 'svn checkout' is an alternative to downloading, unpacking and updating a snapshot as is currently described. It would also help to give a short explanation on why 'svn checkout' or 'wget - tar - svn update' can both achieve the same outcome (if in fact they do?) or, simply remove the latter steps and put the 'checkout' instructions there. Possibly a condensed note in the INSTALL file from line 39 (or from line 50): source code or svn/snapshots should be downloaded and uncompressed to clean/empty directories prior to compilation. Do not try to upgrade existing versions or move an (official) release to svn by unpacking in an existing GRASS directory. For more info see website (the 'Working with svn' page I suggested above could replace the current address, or leave as is if the extra links I suggested get added). Hope my comments
[GRASS-user] d.vect struggles on Map.Render() for 'larger' vectors
Hi GRASSers, I've just clarified something for myself, that I've only occasionally noticed before because most of my work is with small vector files. Starting to play with the North Carolina dataset highlighted this issue for me again, as it has some 'larger' files in there (not that I'd consider 300KB coor file large!). I've got 6.4.2svn updated 21-01-12, on Ubuntu 10.04. The steps I've used: 1. open GRASS, in NC mapset, PERMANENT 2. click 'add vector' 3. in d.vect, choose a vector e.g. bridges 4. hit OK, and GRASS greys out for over 10 minutes, while things are computed. There seems to be a few pauses in terminal output, GUI D3/5: Layer.SetCmd(): cmd='d.vect map=bridges@PERMANENT' (the next line after about 2 minutes was GUI D4/5: LayerTree.ReorderLayers(): items=bridges@PERMANENT, ) but the longest (around 10 minutes) was after: GUI D3/5: utils.GetVectorNumberOfLayers(): vector=bridges@PERMANENT - 1 The next line after this when output resumes in the terminal is: GUI D3/5: Map.Render() type=vector, layer=bridges@PERMANENT Nothing showed in map display, so; 5. click 'zoom to selected layer' tool and again it greys out for several minutes, again the delay is at the Map.Render() step. 6. right-click vector in Layer Manager, choose 'Properties' to bring up d.vect dialog 7. click 'Selection' tab, (it greys out again for several seconds), then deselecting all but one Feature Type and hitting OK (starting with points and working my way through each type) -I tried points, then lines, but with each of them taking around ten minutes I could not afford the time to continue through each type like that! I'd also tried reducing resolution - halving column/row numbers essentially. No discernable improvement. This issue is barely noticeable on very small files (e.g busroute1 in NC dataset). I've also tried a statewide 'soils' map I have in my own system, coor file is 1.1MB. It it sluggish, but still loads much faster than the NC bridges vector (which is a third the coor filesize). It loads significantly faster (maybe 10-15 seconds?) if I deselect the 'area' option on the 'Selection' tab. So it would appear that it's not just the size of the vector file that causes the delay? Am I just asking too much from my computer, or is there some way to cut down on the computing that takes place in GRASS? Should/could I tweak certain settings for my GRASS or computer setup to improve performance? If I can't get the NC maps to work faster than this, it's going to limit how much I can use them to check/replicate glitches I find when doing my own digitising etc... just this experience has chewed up about 5 hrs of my afternoon... :-/ -shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: setting up GRASS svn
Hi Markus and mailing list; I tackled the svn setup today. after several hrs of web browsing, uninstalling old versions, and trying a few approaches to svn commands, I think I have succeeded. the 'info' under GRASS HELPABOUT GRASS GIS now shows I have 'GRASS GIS 6.4.2svn50340 (2012) A couple of hurdles I had on the way... simply following your initial instruction of: If you compile yourself, consider to switch to the 6.4.x release branch version (stable), which continuously receives bugfixes, using the command: svn checkout https://svn.osgeo.org/grass/grass/branches/releasebranch_6_4 grass64_release did something in a terminal, seemed to indicate there were a lot of bits to update to my existing 6.4.2RC2. But I don't think that command by itself did anything to my GRASS version? I tried running above, then doing 'configure' (with several custom settings) and 'make' and 'checkinstall' which kept the computer busy for awhile, but still didn't seem to change my GRASS install... still 6.4.2RC2 (2011) but not a svn version and not 2012?? After doing this, re-running 'svn update' suggested it was current, but the GRASS program itself told me something else?? I ended up following tips from http://grass.osgeo.org/wiki/Working_with_SVN i.e. first downloading and installing an svn snapshot. This web page was the only place I found that gave any clear info on how to start off with svn versions. I noted in the INSTALL files the process of updating svn was more similar to this website than to Markus' tip above... but the install file is dated July 2010. Is 'svn checkout' a newer option? It now seems I'm on track. Were my initial blunders actually working without me knowing, or was the latter approach the correct thing to do, and Markus' tip is what is used for subsequent updates of an existing svn version of GRASS? Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] tabbing between multiple displays in manager
Hi Anna, Thanks for that note :-) It's not something I'm desperately needing, so I won't jump up to 6.5 or 7, I'll stay with the 6.4.x's for now (as i'm more a novice user than developer) and it will be something to appreciate when 7 gets to release stage :-) Or a nice surprise if it gets backported to the 6.4's. -shane On Wed, 2011-12-28 at 17:10 +0100, Anna Kratochvílová wrote: Hi, On Fri, Dec 23, 2011 at 11:50 PM, Shane Litherland litherland-f...@bigpond.com wrote: passing thought - is there a way to rename the display tabs (currently just 'display 1', 'display 2' etc)? could be handy where one has several display tabs and can't remember what's on each one... e.g. can I name them to be 'weeds', 'catchments', 'cadastre data' and so forth? It should work now (in G65 and 7) by right click on the tab (menu appears). Anna Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ 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
Hi Martin, Markus; appreciate this guidance, I probably glossed over this tip somewhere in the manuals, you've saved me a bit of study time. Now for me to put it to use to help save you some time when it comes to deciphering my problematic posts ;-) Bear with me, I've got several paddocks worth of weeds to digitise from the last week or two, then I have to implement your debug suggestion, along with North Carolina sample mapset for testing my problems, and move to svn versions of 6.4.x... then I'll post back on the few issues I noted over xmas/NY. regards, shane. On Tue, 2011-12-27 at 01:39 +0100, Martin Landa wrote: Hi, 2011/12/27 Markus Neteler nete...@osgeo.org: [...] @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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] erroneous creation of single-point boundary
Hi again, I mentioned in an earlier post when GRASS crashed, that I eventually fixed via tcltk instead of wxgui, and found in the process a single-point boundary in the area I'd been digitising prior to a crash. I've found a few more times, that a single-point boundary gets incorrectly created, it seems to be when I am trying to do a small boundary and maybe the snapping process is interfering with it? I can, for example, have an existing boundary (say, one that will be a common boundary between two areas when I'm finished). I might activate the boundary tool, left click on one end of the existing boundary to start another boundary, go out a short distance, left click again to create a vertex, then left click at other end of existing boundary and right click to finish. prior to the final right click, there is a yellow dotted line and vertices to show my new boundary will form a triangle beside the existing boundary. After the right click, I cannot see anything where this triangle should be. Upon closer inspection, I find a single-point boundary where I did the first click to start the boundary (usually obscured by the node/vertex of the existing boundary). On one or two occasions, rather than it 'reverting' to a single point, it has 'reverted' to a boundary between the first and second vertex, i.e. an unclosed boundary, it seemed to 'lose' the third vertex that should have closed the new boundary to the existing one. when these glitches occurred, I tried a few times to delete the faulty boundary and do it again, but the same error happened. I found I had to zoom in on the map, so that my new boundary / mouse-clicks were further apart?? this is why I suspected the snapping setting might be 'interfering', even though whilst drawing the boundary it appeared to be snapping to the nodes I intended. can anyone else repeat this scenario? i'm on wxgui 6.4.2RC2 ubuntu 10.04. If anyone else can validate my experience I'll follow it up in the bug tracking. -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 GRT11_12@Lacebark 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
[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] 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] 6.4.2RC2 on ubuntu 10.04
Hi all, been busy away from computer last several weeks. Last I posted, was playing with ~RC1, and noting several little glitches, at least one of which I was supposed to file a bug report on... :-/ Have dusted off my login etc for doing that, and just installed the ~RC2 OK it seems, from source. used the advice on http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu as I'd done for ~RC1, and seemed to do the trick. Before I continue putting in bug reports I'm checking whether the glitches I had in ~RC1 are (or are not) still there in ~RC2. I have so far noted one small one regarding displaying of layers in wxgui (ticket #1519). Next on list is to check if issue that Moritz advised me on is still there (as per email 22/11/11) FYI, I used the following for the install: sudo CFLAGS=-g -Wall ./configure \ --prefix=/usr \ --enable-64bit \ --with-libs=/usr/lib64 \ --with-cxx \ --with-postgres \ --with-odbc \ --with-gdal=/usr/bin/gdal-config \ --with-python=/usr/bin/python2.6-config \ --with-wxwidgets=/usr/bin/wx-config \ --with-geos=/usr/bin/geos-config \ --with-postgres-libs=/usr/include/postgresql/libpq \ --with-postgres-includes=/usr/include/postgresql \ --enable-largefile=yes \ --with-includes=/usr/include \ --with-proj-share=/usr/share/proj \ --with-tcltk-includes=/usr/include/tcl8.4 briefly saw a few 'syntax error' messages fly by in the terminal during install, but in the end there were zero errors reported and GRASS opens up OK. One thing I did note, is that the INSTALL file that comes with the ~RC2 file, had a note about compiling for 64 bit (which I have) and referred to correctly configuring the FFTW2 with a -fPIC flag... as per the info on above website, I have already apt-get a newer version (3.0 or 3.+?) and I assume the apt-get would have done the 64-bit configuring... I haven't seen any issues so far in operating GRASS anyhow. Though I haven't done any number crunching that might employ FFTW. The note in the install file may be worth updating though, if version 3+ is now available and maybe it doesn't need specifically configuring for 64-bit with the -fPIC flag? Hope those comments are useful :-) -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] digitising area crashes GRASS in wx GUI
Hi all, this seems to be a serious thing! wxGUI, ubuntu 10.04, GRASS 6.4.2RC2; I created a new vector 'testing_vectors' for troubleshooting. obviously it was empty to start with. I chose 'digitize' from the listbox on top-right of map display window, then selected the vector from listbox that appears with digitizing tools. I proceeded to select 'area' tool, and draw an area. when I used the right-mouse click to finish/close the area, GRASS crashed (as in all windows shut down, disappeared, only the terminal that I used to start GRASS was still there, no messages or anything in it). I restarted GRASS, opened the workspace, same steps above to digitize the vector again. after selecting it, I got a Topology missing dialog that stated: Topology for vector map testing_vectors is not available. Topology is required by digitizer. Do you want to rebuild topology (takes some time) and open the vector map for editing? . I clicked yes, and it seemed to go OK, let me continue to digitize and it showed the vector i'd digitized prior to the crash. BUT IT WAS ONLY A BOUNDARY, NO CENTROID. I chose the 'area' tool again, and same result (crash on completion; rebuild topology on opening it again). AGAIN, SECOND 'AREA' TURNED OUT TO BE BOUNDARY, NO CENTROID. In the same vector, I could draw a boundary and complete it with no crash. I could add centroids to the boundary I drew, and to the previous boundaries that were the result of the crashed 'area' tool. So is there something wrong with the area tool in the process of it adding a centroid? I did not change any of the digitising settings, they were all at default I believe. (The 'add new record to table' was unchecked, maybe I had changed that option?) ??? -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] RE: query tool in wxGUI doesn't work on multiple table connections
I found another case where the tool seems to not function fully: A different vector to my earlier post, has for a given centroid: layer 1: cats 4,5 and 107 layer 2: cat 40 I checked the connection to this info is fine within the wx digitiser using the attributes tool there. the query tool in general view though, only reports the data for this point to match layer 1, cat 107. none of the other cats have a tab showing their data. elsewhere in that same vector, i found a centroid where I got same error messages as earlier reported, the layer/cat details for that were: layer 1, cats 1 and 2 layer 2, cat 39 a third centroid was OK, with layer 1, cats 76 - 81, but the query tool only showed data for cat 81. a fourth centroid, only layer 1, cat 33, was reported OK by the query tool. a fifth centroid, layer 1, cat 2 and layer 2 cat 39, gave an error with the query tool. I noted that the cases that the query tool gave an error, at least one of the entries for layer one had a 'null' value for the 'notes' column in my table. however, with the fifth centroid example above, which had a blank notes field, I entered a note, but that did not stop the query tool giving an error message. I went back to the first centroid which for some reason did not report an error despite having multiple connections on layer one and one connection on layer two, compared to example two which had a very similar setup but gave the errors: I could not see any difference in the details for the relevant entries in the table/column that gave an error in the latter. The only thing I could figure out is that the centroid that the query tool partly worked for had layer 1, cat 107 data returned which just happened to be a different date (in relevant table column) to the data on layer 2, whereas the centroid that gave an error had the same date for the data on both layers. This does not explain anything to me though because I have not got any connections/joins etc between these tables based on a date field (unless table conditions that I set up in PostgreSQL have any bearing on GRASS??) Does this make the problem any clearer to anybody else? I don't understand enough about the query tool to eliminate possible sources of the error despite this testing. -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] how to use 'copy cats' tool in wx digitiser
Another little query, am I using the 'copy categories' tool the wrong way... instructions when selecting that tool say 'left click =select; ctrl+left = unselect, right click=confirm' I have tried several combos of left and right, e.g. select/confirm source, select/confirm target; or select source, select/confirm target; select source, confirm target; but cannot seem to successfully copy cats from one centroid to another. from recollection, the old v.digit tool for this process had a 'click source - click target - confirm click' i.e. three stages whereas the current tool seems to only have two... does it need three? regards, shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] category number incrementing when digitising
Hi Moritz et al, Thanks for your patient description. I have been using cats and tables for a while now, and think I understand enough about how they work, your explanation seems similar to what I'd read in the GRASS docs. My concern here is not how to use them, but that the check/list boxes in the dialog appear to increment the cat numbers without them actually being used. e.g. If I click on 'next to use' in the listbox ten times, the cat that will be used next goes from 320 to 330, before I have digitised anything to even give a cat to. A couple of other odd things like this in wx dialogs/gui seem to have come down to what version of wx/python/GRASS is being run together, so I was wondering if anyone else can repeat this event in their dialog, and if not, why (maybe newer wx/python?) Too late at night for me to dig up my system specs... tonight got wasted with other dramas on GRASS and a bunch of lost data... but if you want them, I can get them regards, shane. On Fri, 2011-11-18 at 11:19 +0100, Moritz Lennert wrote: On 16/11/11 07:12, Shane Litherland wrote: Hi all, 6.4.2RC1 on ubuntu 10.04.3, using wxgui when digitising new vector, in 'digitisation settings' on 'attributes' tab, I can play around with settings to add record to table, auto or manual cat etc. Noted that when cat mode is 'next to use' clicking the checkbox on/off for 'add new record into table', the number keeps going up by one for each click. same happens for the listbox for category mode if i keep clicking on the 'next to use' Assigning category numbers to a geometrical object is independent from the fact whether you add a record to a table or not. Category numbers are identifiers you can assign to objects. If you wish you can link a specific layer to a table and then those objects whose category number appears in a specified key column in that table have attribute information in the table, others don't. So, if you use 'next to use' mode, but check off 'add new record into table', you assign a category value to the objects you will digitize, but no corresponding entry is added to the category table. This can be very useful when all you need is categories and not other attributes (e.g. you use specific integer codes for land use classes and just assign each polygon the relevant land use class code as category value without creating an attribute table). I'm not sure, but I have the feeling that the above explanation might also respond to all your other issues. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] digitising area crashed GRASS
Hi Martin, the wxGUI digitiser. I've been brave lately and given it some workouts ;-) alas, tonight, i've had more dramas with it... Trying to use the 'digitise area' tool for a separate vector has crashed grass for a second (third, fourth, fifth..) time in a few days. it made the boundary but not the centroid (I determined that upon re-opening) and lost topology but seemed to rebuild ok. tried tool again, just the same way, and it worked with no crash to digitise two more areas, then crashed on the third. The next time I opened GRASS to do same process, it crashed on first area again. digitising a boundary and manually adding a centroid doesn't seem to cause me this grief. Any more sleuthing required at my end? regards, shane. On Fri, 2011-11-18 at 11:23 +0100, Martin Landa wrote: 2011/11/16 Shane Litherland litherland-f...@bigpond.com: 6.4.2RC1 ubuntu 10.04.3 wxgui Not as bad as it sounds though...only happened once so far. At first, I thought it was because I may have had the 'no category' or 'don't save to table' settings ( a hangover from whatever I'd just done), and when I used the area tool upon completion of a boundary by right-click, GRASS crashed/closed. Did a restart, the boundary was there, topology had to be rebuilt for the vector layer, easily added the missing centroid. didn't seem to affect other existing parts of vector. have tried area tool again, with several combos of 'add/don't add to table', and 'manual, next, no cats' without any crashes. The area tool even worked with 'no cats' just made a centroid with no cat. so dunno what happened. if it does again, will try and note more detail. are you speaking about v.digit of wxGUI digitizer? Martin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] wx digitiser destroyed my vector again
Hi all, just had an unsavoury experience for the second time since using wxgui in 6.4.2RC1 when digitising a vector that consisted of boundaries and centroids, I was attempting to split a boundary to add more adjacent boundaries/centroids. somewhere in process of trying/learning to get the break/split/similar tools to work, then moving boundary segments to tidy up mistakes and/or using undo button, everything in the vector except for a handful of boundaries that were in view of the gui vanished. It seemed to become apparent at the point of hitting the 'undo' button. I didn't save anything just quit GRASS and reopened, but that's how it stayed. had to restore vector file from a backup and re-do any recent stuff I'd lost. am i using some of these tools wrong or does GRASS wx digitiser have some serious issues when it comes to data integrity? i thought i'd figured enough out to safely use the wx digitiser but if i have to keep restoring from backups every couple of weeks i might be better off going back to the v.digit option...?? a bit further into things, i've now had GRASS crash when trying to split and delete centroids or boundary vertices. I re-opened GRASS with relevant vector, went to digitise and got 'topology needs to be rebuilt' message but when I chose to rebuild it crashed GRASS again. I have now re-opened GRASS four times and tried to rebuild topology from the message and it keeps crashing. I tried rebuilding with v.build and it seemed to work but told me I had more boundaries with errors than i expected, then tried to open up vector to digitise (wxgui) and it still crashed. I had to re-recover the vector from my backup, and use v.digit (tcl/tk) digitiser to check over things. only when i'd removed the aberrant boundaries (in tcl/tk) that had resulted from me splitting/moving sections, could I get it to build without reporting any boundaries with errors, and not crashing in the wxgui digitiser. I later found two tables connected to this vector had been deleted from postgresql! I did a force remove (using wxgui) of the faulty vector before restoring from my backup, but i have used force remove many times prior to 6.4.2RC1 without it deleting tables... so has something changed here, or did the tables get deleted somewhere in the mess that resulted with the wx digitiser...??? This kind of stuff is bloody annoying... what was 15 minutes work has now taken me 3 or more hours up late fixing the mistakes/errors... If i'm doing something wrong i'd be most appreciative of being corrected, if GRASS is misbehaving then i'd appreciate suggestions on what part of my experience to document in a bug report. in the meantime, looks like i'll go back to using the tcltk digitiser even though the wx one is a bit fancier... i'd prefer stable data over latest fashions any day! too tired tonight to dig up specs on my wx, python, etc but using ubuntu 10.04.3 mostly from standard repositories for updates etc. can get more info if required. -shane. regards, shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] RE: more on misaligned rasters vs vectors
hi all, I had a similar oddity with two rasters that were in Albers Equal Area, which should have overlapped but appeared to be about 1.5 hemispheres apart... At first I thought the metadata may have been erroneous but maybe there's something else afoot. I got around it by opening them in separate Albers locations/mapsets, then from there into one latlong location/mapset where they did align as I initially expected them to in the Albers projection. Anyone wanting to check this out first hand to see if it's a GRASS thing or the original data, can freely download from the following site: http://dds.information.qld.gov.au/dds/search.aspx and just look up these two files in the search option at bottom Digital Elevation Model (25m) South East Queensland (Data Package) Landsat Imagery Mosaic 2006 Queensland It may shed some more light on Kirk's issue? -regards, shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] digitising area crashed GRASS
6.4.2RC1 ubuntu 10.04.3 wxgui Not as bad as it sounds though...only happened once so far. At first, I thought it was because I may have had the 'no category' or 'don't save to table' settings ( a hangover from whatever I'd just done), and when I used the area tool upon completion of a boundary by right-click, GRASS crashed/closed. Did a restart, the boundary was there, topology had to be rebuilt for the vector layer, easily added the missing centroid. didn't seem to affect other existing parts of vector. have tried area tool again, with several combos of 'add/don't add to table', and 'manual, next, no cats' without any crashes. The area tool even worked with 'no cats' just made a centroid with no cat. so dunno what happened. if it does again, will try and note more detail. -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] category number incrementing when digitising
Hi all, 6.4.2RC1 on ubuntu 10.04.3, using wxgui when digitising new vector, in 'digitisation settings' on 'attributes' tab, I can play around with settings to add record to table, auto or manual cat etc. Noted that when cat mode is 'next to use' clicking the checkbox on/off for 'add new record into table', the number keeps going up by one for each click. same happens for the listbox for category mode if i keep clicking on the 'next to use' result seems to be some cat numbers get skipped when actually doing entries. thought i could work around it by doing manual cat number to bring 'next number' back to where it should be, which will happen if i go through digitising a new centroid. If I just change 'manual' and apply, then continue playing with settings without digitising something, each time I return to the 'next number' option it remembers the number generated from the previous bout of clicking the checkbox/listbox as per above. Anyone else noticed this and/or can repeat this? Something else in the process: noticed if i make a centroid and the 'next number' is not what I wanted as the next number, I can change the cat number of the centroid OK. But if there's no entry in the table for that cat because it was skipped earlier in the digitising stage, the attributes tool comes up blank. kinda makes sense to me but i was hoping the attributes dialog would still open up showing blank fields for each table column and then I could add the info. currently have to first add record (or at least a partial record with relevant cat) to the table (e.g. using PGadmin to access the postgres table) also found if I change digitisation settings for attributes, but don't hit the 'apply' button, the digitiser window still responds to whatever the earlier settings were. -could the settings automatically update/apply whenever a change is made to one of the options in this dialog? furthermore, it seems that cat increments within the digitising window don't fully obey the dialog settings e.g. I've used manual cat to do a centroid #752. back to dialog and set cat to 'next to use' and it shows #753 (yay). click apply, go to digitise next centroid, dialog to enter table data pops up but it's for cat #754...?!? If I hit cancel, delete the cat, and try again, the next dialog comes up with #755. All the while the settings dialog shows next to use should be #753 still...?? Should it be reported as a bug or could it be result of my end (have had other small anomalies that appear to be based in what versions of python and wx I have)? regards, shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] better way to add layer categories?
Hi all, I have a vector, with three layers each connected to a different table. I heard about v.db.join and thought that would be a great tool, which it is but it doesn't satisfy me for this purpose, as it seems to result in the joined info displaying like one big table with all data from joined tables together. I would prefer to keep the info from each table on separate layers just so I can do things a particular way. Currently when I digitise an area, I add the cat for each layer. Is there a better way to do it, a bit like an update query? Because I could digitise the areas and do the cats for the first layer, then the other layers share a common value in a 'date' field which could join them. or a partly-automated, partly-manual approach where I tell GRASS to add to vector layer 2, a cat value of x, when the date (of layer one) =y I have spent some time going through GRASS manual for various things, but so far haven't had anything hit me in the face as being an answer to this... maybe I need glasses... ;-) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.vect colour wheel not active wxGUI 6.4.2RC1
Hi Martin, python 2.6.5 is what comes from the repositories for my ubuntu 10.04 64 bit. I read elsewhere that there's a fair bit of fixes in 2.6.6, but also saw a few forums/bug reports about upgrade issues in ubuntu so as it's a small issue I'll wait until there's a 'proper' package available for my system. wx is 2.8.10.1 so that is same as what you have. Cheers, Shane. On Thu, 2011-10-20 at 12:18 +0200, Martin Landa wrote: Hi, 2011/10/20 Shane Litherland litherland-f...@bigpond.com: any others find this too? ubuntu 10.04.3 64 bit, wxGUI python 2.6 seems to work for me. Debian GNU/Linux unstable, python 2.6.7, wx 2.8.10.1 Martin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.vect colour wheel not active wxGUI 6.4.2RC1
Hi Martin, Thanks for comment. will look into it further, including checking versions etc. -shane. On Thu, 2011-10-20 at 12:18 +0200, Martin Landa wrote: Hi, 2011/10/20 Shane Litherland litherland-f...@bigpond.com: any others find this too? ubuntu 10.04.3 64 bit, wxGUI python 2.6 seems to work for me. Debian GNU/Linux unstable, python 2.6.7, wx 2.8.10.1 Martin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] map query tool in 6.4.2RC1 ???
Hi Martin, thanks for confirmation on query tool operation :-) Further on the other issue (below): A problem I find, is that some things I click on don't give results, I get this sort of error: Traceback (most recent call last): File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/mapdisp _window.py, line 1017, in MouseActions self.OnLeftUp(event) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/mapdisp _window.py, line 1207, in OnLeftUp self.parent.QueryVector(self.mouse['begin'][0], self.mouse['begin'][1]) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/mapdisp.py, line 1382, in QueryVector action = mode) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/dbm_dia logs.py, line 104, in __init__ self.UpdateDialog(query = query, cats = cats) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/dbm_dia logs.py, line 362, in UpdateDialog query[1]) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/dbm_base.py, line 109, in SelectByPoint if self.tables[table][key]['ctype'] != types.StringType: KeyError : 'grthrs_pax' ... I get similar message with different last line for different vectors I query, but it seems to be having an issue with certain columns from connected tables? for one vector as above, it is the last column of the table connected on layer 3. column is character varying(20) On another vector, I get similar message and it is the last column of the table connected on layer 2, format integer Yet I can go to another vector, that has integer double precision and character and the edit dialog box will pop up when I click on the map. could you send `v.db.connect -g` and `v.info -c` output for problematic sample vector map? Martin Here's output from a vector that query tool did work on: v.db.connect -g map=VIP_transects@Lacebark 1 public.VIP_transects cat gisdb pg v.info -c map=VIP_transects@Lacebark INTEGER|cat INTEGER|vip INTEGER|transect DOUBLE PRECISION|startx DOUBLE PRECISION|starty DOUBLE PRECISION|endx DOUBLE PRECISION|endy CHARACTER|notes Displaying column types/names for database connection of layer 1: Below is output for a vector that it gave error on, but whilst I was checking this problem, I found that the query tool did work for a couple of centroids that ONLY had data in a connection with table one (happens to be vectors I am still updating info for other layers) So that may help narrow down the possibilities i.e. it may not be the entire vector that causes error, but maybe only when querying something which should return info for 1 table connections. Note I also have multiple entries within each layer for a given centroid, I don't think I can confirm if that is or isn't an issue whilst the current error stops me from getting any query result for such attributes. v.db.connect -g map=GRT10_11@Lacebark 1 GRT_prevalence cat gisdb pg 2 chemical_use cat gisdb pg 3 grt_hours cat gisdb pg v.info -c map=GRT10_11@Lacebark INTEGER|cat DATE|grt_date INTEGER|plant_rank INTEGER|seed_rank CHARACTER|treatment CHARACTER|notes DOUBLE PRECISION|grt_score CHARACTER|grassrgb Displaying column types/names for database connection of layer 1: v.info -c map=GRT10_11@Lacebark layer=2 INTEGER|cat DATE|chem_date CHARACTER|chemical DOUBLE PRECISION|chem_vol CHARACTER|additives DOUBLE PRECISION|mix_vol CHARACTER|method CHARACTER|area CHARACTER|target DOUBLE PRECISION|hours CHARACTER|chem_notes INTEGER|chem_conc Displaying column types/names for database connection of layer 2: v.info -c map=GRT10_11@Lacebark layer=3 INTEGER|cat DATE|grthrs_date DOUBLE PRECISION|grt_hrs CHARACTER|grthrs_notes CHARACTER|grthrs_pax Displaying column types/names for database connection of layer 3: Let me know if any more sleuthing required at this end :-) -shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.digit options in 6.4.2RC1
On Thu, 2011-10-20 at 12:47 +0200, Martin Landa wrote: Hi, 2011/10/20 Shane Litherland litherland-f...@bigpond.com: At first these three different ways to get to v.digit seemed a bit there is only one way how to start v.digit (Tcl/Tk, from the menu) and three ways how to reach wxGUI vector digitizer (which is not called v.digit to avoid mess). messy/unprofessional, but after using it a bit more, I can see some benefits in current layout... but thought I'd comment in case the various ways to get there weren't actually intentional? More ways how to reach a goal seems to you as messy/unprofessional? No, no! :-) just that _initially_, given their variations in getting there, i felt that.. or maybe more accurate adjective would have been confusing, thinking from angle of newcomers being bamboozled by finding too many ways to get something done... sometimes people like just one option, keep it simple, don't scare them ;-) Mind you, such people probably would never agree which 'one' avenue was 'the one'. But I'm all good with the options, now that I've given them a bit more exercise. Thanks for clarifying v.digit vs wxGUI too :-) -shane. BTW, you can also click on icon in the toolbar. Martin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.db.join - am I using it right?
Hi all, On 6.4.2RC1, I have just played with v.db.join after seeing it suggested for a use I thought would benefit me (I'd briefly looked at it on 6.4.1 before upgrade, had similar 'errors' there too). when I open the dialog box for it (using wxpython GUI), from the listbox I can select vector map. I can then select 'join column in map table'. Then when I select 'other table name' the 'join column in map table' field goes blank (looking at command-line at bottom of dialog box shows column=required). I can go back to 'join column' listbox and reselect what I wanted and it seems to recognise it again, but if I change the 'other table' it will blank the 'join column' listbox each time. Then on going to last listbox 'join column in other table' it lists the column names for the map table, when it should list the columns for the other table! So I just cheated and typed in the column name I knew I wanted for 'other table'. This was what I ended up with: v.db.join --verbose map=camphors@Lacebark column=chem_cat otable=public.chemical_use ocolumn=cat DBMI-Postgres driver error: Cannot execute: ALTER TABLE camphors ADD COLUMN cat INTEGER ERROR: column cat of relation camphors already exists ERROR: Error while executing: 'ALTER TABLE camphors ADD COLUMN cat INTEGER ' ERROR: Cannot continue (problem adding column). ERROR: Cannot continue. .. I tried again, using different columns because I thought choosing a 'cat' column might have mucked things up. this case, I tried joining on two date columns: v.db.join map=camphors@Lacebark column=camphor_date otable=public.chemical_use ocolumn=chem_date DBMI-Postgres driver error: Cannot execute: ALTER TABLE camphors ADD COLUMN cat INTEGER ERROR: column cat of relation camphors already exists ERROR: Error while executing: 'ALTER TABLE camphors ADD COLUMN cat INTEGER ' ERROR: Cannot continue (problem adding column). ERROR: Cannot continue. So it isn't the choice of columns... it's still trying to add another 'cat' column... why...? This confused me. Why does v.db.join submit and ADD COLUMN command? I expected a 'join' process to simply do that - join two tables based on an existing column from each table; then display the data from both. The info and examples in GRASS help for v.db.join show this is what should happen with the Spearfish soils example. So I thought I'd look at the vector map to see what, if anything, had happened. Just in case these error messages were not-quite-relevant. But ran into problem with query tool in map display as per separate post. So I ran v.db.select on the table I'd just ran v.db.join on, it returned the data from table one only (when having the layer selected that I'd tried running v.db.join on) i.e. join not successful. So I guess error message in this case was relevant. Have I missed something elementary, or is the v.db.join passing the wrong sort of SQL to db.execute or wherever it goes...?? What can I do about it? Regards, Shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.vect colour wheel not active wxGUI 6.4.2RC1
Hi all, in d.vect dialog, going to select colour for lines/fill, the colour wheel can be moved around with mouse, but the colour chosen on the wheel isn't recognised to start with by the dialog. I found I had to click on the eye-dropper icon, then click the colour wheel with the eye-dropper tool. then the colour showed in bar at bottom as the new colour, and I could continue to move the wheel around and the new colour would display accordingly. I'm fairly sure in 6.4.1 I could just select a colour on the wheel with the mouse and 'OK' and it would be the new colour for the vector line/fill. Don't remember ever having to use the eye-dropper tool within the dialog itself. any others find this too? ubuntu 10.04.3 64 bit, wxGUI python 2.6 cheers, shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] map display in 6.4.2RC1 incorrect on startup
Hi all, I have started grass wxGUI from a terminal, then open a saved workspace. that workspace has, vector 1 vector 2 vector 3 raster 1 in that order in layer manager. vectors are some lines/boundaries/centroids/points, raster is a fairly high-res aerial photograph. All of these layers are marked as 'visible'. Once I've chosen to open this workspace, I see in the map display the vectors appear, then a pause as raster loads (I'm used to a pause because of file size on my old computer), but then once raster loads, the vectors which should actually be showing over top of it, aren't. as if the last thing to finish loading ends up as top layer in the display. Clicking on the 'display map' or 'render map' icons doesn't seem to re-draw it and sort things out. Neither does zooming in/out. raster map continues to be only visible layer. If i go to the layer manager though, and deselect 'visible' checkbox for any of the vectors, the whole thing sorts itself out and appears as expected, and continues to do so if i re-select 'visible' for any layers. i.e. if i deselect vector 2, the map display refreshes showing vectors 1 and 3 over top of raster 1. Anyone else notice this? regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] map query tool in 6.4.2RC1 ???
Hi again all, In 6.4.1 wxGUI, I noticed that the query tool icon in map display gave user an option to query (display mode) or query (edit mode) - the former showed details in output window, the latter opened a dialog box allowing view/edit of data in connected table. now in 6.4.2RC1, there does not seem to be an option to choose - I click the tool, then clicking on the map does the 'edit' option of opening dialog to view/edit data in table if/when it works that is... A problem I find, is that some things I click on don't give results, I get this sort of error: Traceback (most recent call last): File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/mapdisp _window.py, line 1017, in MouseActions self.OnLeftUp(event) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/mapdisp _window.py, line 1207, in OnLeftUp self.parent.QueryVector(self.mouse['begin'][0], self.mouse['begin'][1]) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/mapdisp.py, line 1382, in QueryVector action = mode) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/dbm_dia logs.py, line 104, in __init__ self.UpdateDialog(query = query, cats = cats) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/dbm_dia logs.py, line 362, in UpdateDialog query[1]) File /usr/grass-6.4.2RC1/etc/wxpython/gui_modules/dbm_base.py, line 109, in SelectByPoint if self.tables[table][key]['ctype'] != types.StringType: KeyError : 'grthrs_pax' ... I get similar message with different last line for different vectors I query, but it seems to be having an issue with certain columns from connected tables? for one vector as above, it is the last column of the table connected on layer 3. column is character varying(20) On another vector, I get similar message and it is the last column of the table connected on layer 2, format integer Yet I can go to another vector, that has integer double precision and character and the edit dialog box will pop up when I click on the map. I am using Postgres db. Any hints? Also, if it's something serious, should I head over to reporting it as a bug and/or posting to the dev mailing list? -Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.digit options in 6.4.2RC1
Hi all, the wxGUI v.digit seems nice! a few things different to tcltk digitiser to get used to but overall seems to have more versatility. I have noticed that if I go to vector menu in main window, the option there is for editing a vector with tcltk. To use the wx option, one has to either right-click start editing on a vector in the layer manager, or in map viewer, choose 'digitise' from listbox in top-right corner. If I use the former option, then the vector highlighted in layer manager is opened for editing. If I choose the latter, no layer is chosen by default, not even if one is highlighted in layer manager, I have to select which one I want to edit from a listbox on left side. At first these three different ways to get to v.digit seemed a bit messy/unprofessional, but after using it a bit more, I can see some benefits in current layout... but thought I'd comment in case the various ways to get there weren't actually intentional? Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.digit in 6.4.2RC1 wxGUI destroyed my vectors, OK second attempt.
Hi again, last night I was playing with the wxGUI digitiser, first time I've used it (was not available in 6.4.1?) In figuring out how select/commit worked a little different with mouse, and how the display showed 'live' movements, I used the move/add/remove vertex tools, the edit line/boundary, move features, and delete features. Somewhere in my experimenting, the whole thing went weird on me. Started showing random lines from corner of window to my (moving) mouse cursor, duplicated boundaries when I chose to move a single point, refused to close after clicking on the 'exit digitising' button and choosing 'no-don't save'. Eventually, ended up with most of the vector layer gone (it was composed of boundaries and centroids), topology obviously stuffed, one boundary I hadn't gone near still showed on the map and the last half-dozen 'moves' of another boundary showed as half-dozen overlapping boundaries, each with one of the vertices (whichever I'd moved in that step) in a different position. Got a whole heap of error messages in output and also topology errors in terminal from where I ran GRASS. Can post them if anyone interested. Had to dig out a backup of that vector and restore it to the GRASS folder. Have tried, much more carefully, to repeat process this morning. Adding vertex, moving boundary/centroid, moving vertices, seems to be OK. So far, only thing I can find again, is when choosing 'exit' and 'no', the changes I just did ARE saved (e.g. i'd opened digitiser, moved a boundary, exit-nosave, but boundary shows where I'd moved it to, not where it was previously). Doesn't seem right to me - I know the tcltk digitiser saved things as they were done, does the wxGUI in fact do the same thing, in which case why the yes/no option to save when quitting digitiser? Tried a couple of tools from 'additional tools' icon/menu; some like 'split line/boundary' I've used before, and can find a v.split page in GRASS help, whereas others like merge, connect, even snap, seem to be new options or modifications of older techniques, which didn't do what I expected initially, and couldn't find something in GRASS help where I expected to, e.g. v.connect, v.merge, etc... Any pointers on where to look for info on the 'additional tools' would be appreciated. I've got enough grasp of the main tools in digitiser that have their own icons already. As for repeating my destruction of a vector layer, who knows? maybe clicking left mouse button to select, then again to where I wanted to move/add a vertex when I shoulda used right button (that was how old tcltk worked - left select, left new spot, right commit - old habits!) confused it before I finally clicked right button. Or clicking on a centroid with 'move vertex' tool (no move happened, but centroid did momentarily disappear until i right-clicked again)... or when the 'exit digitiser' seemed to partly return the map display to 2d view but still left the digitising toolbar showing, and I then re-opened the vector to digitise some more... I think I was a fair way into playing before I started noting odd things and recording the error messages. -Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 6.4.2RC1 breaks libgdal1-1.8.0-grass package on ubuntu 10.04
hi all, since successful compile of ~RC1, have noted in synaptic package manager that it thinks libgdal1-1.8.0-grass is a broken package. Note, this wouldn't have arisen if I had 6.4.1 AND the newer version, I suppose? But having only 6.4.2RC1 is why the system is having a hissy fit ;-) the package has a depends on grass6.4.1 I foolishly took its advice at first, and asked for it to clean/update/fix etc... it's idea of fixing was deleting it. Took me ages to figure out how to get it back - I had to download the .deb file (and associated files?) from where the package was at the ubuntugis-unstable ppa, then use dpkg --ignore-depends=grass641 to get it back on my system. Now it's back, but synaptic is complaining again, as far as i can tell i won't be able to do any updates until i 'fix' this broken package. It seems getting synaptic to ignore broken packages and get on with life is basically like telling it you have revoked its sole purpose of existing... I was looking into ways to convince synaptic that this dependency wasn't there, or that the broken package wasn't there, but that was getting a bit technical for me to figure out, diving into /var/lib/dpkg/status where it didn't actually list grass6.4.1 as one of the dependencies anyway... I guess I could have edited something in the .tar.gz archive that was with the .deb archive, and repackaged that to a .deb without the dependency and installed that??? like I said, getting a bit outta my comfort zone... I'm OK with ignoring synaptic and its tantrum for now. Maybe the package in question can have the depends=grass6.4.1 updated and when that's done I can let synaptic go back and sort its silly dramas out ;-) So heads up for anyone else seeing that error on ubuntu - I suggest ignoring it for awhile, and see if the relevant package can be tweaked to accommodate ~RC1. It may be that this dependency will exist in the corresponding packages for the other distro versions of ubuntu too.\ Trust that's beneficial feedback :-) -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 6.4.2RC1 on ubuntu 10.04 - successful
Hi all, Still early days in test-driving it, but I managed to swim the deep waters of compiling from source and I figured I have been successful because I can type 'grass64' in a terminal and things happen :-) FYI, below is what I did to 'build/configure/whatever-the-right-term-is' on ubuntu 10.04.3 64bit, with a previous version of grass 6.4.1. I had hoped that I'd do it in such a way as the new version would take the place of the old, but it appears that the new one has set up in /usr/grass-6.4.2RC1 whereas the previous version (done from ubuntugis unstable repo's) put it in... somewhere else.. i think because i did 'make distclean' before the new install, it tidied all that up (i.e. gone). anyway, that doesn't seem to affect it operating. just slightly out of line with where ubuntu would normally have put it. I think it would have been /usr/share as that is where all my other programs seem to be. ... #ran this batch of apt-get, as per website #http://grass.osgeo.org/wiki/Compile_and_Install_Ubuntu sudo apt-get install \ build-essential \ make flex bison gcc libgcc1 g++ cmake ccache \ swig swig1.3 \ python python-dev python-qt4 python-qt4-dev \ sip4 python-sip4 python-sip4-dev python-opengl \ python-wxversion python-wxtools python-wxgtk2.8 \ libgsl0-dev \ wx2.8-headers wx-common libwxgtk2.8-dev libwxgtk2.8-dbg \ libwxbase2.8-dev libwxbase2.8-dbg \ libncurses5-dev \ zlib1g-dev gettext \ libjpeg62-dev libtiff4-dev libpngwriter-dev \ tcl8.4-dev tk8.4-dev \ libcairo libcairo-dev \ sqlite3 libsqlite3-dev \ libpq-dev \ libreadline5 libreadline5-dev libfreetype6-dev \ txt2tags \ fftw3 fftw3-dev \ libqt4-core libqt4-dbg libqt4-dev libqt4-gui libqt4-sql libqt4-qt3support \ lsb-qt4 qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig \ libapt-pkg-perl resolvconf \ libjasper-dev \ ruby \ subversion \ ffmpeg ffmpeg2theora \ libffmpegthumbnailer-dev \ libavcodec-dev \ libxmu-dev \ libavformat-dev libswscale-dev \ checkinstall ##note my system already had a lot of what was in this list, either ##from default ubuntu installs or from me ##reading through grass-compiling info and manually adding bits ##prior to just pasting this whole thing into a terminal #and this specifically for ubuntu 10.04 again from website sudo apt-get install libhdf4-alt-dev libhdf4-0-alt ## next steps #note had to instal libgdal1-dev from ubuntu repo's #in order to get /usr/bin/gdal-config #also wx-common, libwxbase2.8-dev and/or libwxgtk2.8-dev #and/or wx2.8-headers #in order to get wx-config to enable wxwidgets #(may also have been included in ~-dbg of #these files instead of ~-dev, as per info obtained from terminal). #then as per website instructions do a make distclean sudo make distclean ##my idea for configure parameters: sudo CFLAGS=-g -Wall ./configure \ --prefix=/usr \ --enable-64bit \ --with-libs=/usr/lib64 \ --with-cxx \ --with-postgres \ --with-odbc \ --with-gdal=/usr/bin/gdal-config \ --with-python=/usr/bin/python2.6-config \ --with-wxwidgets=/usr/bin/wx-config \ --with-geos=/usr/bin/geos-config \ --with-postgres-libs=/usr/include/postgresql/libpq \ --with-postgres-includes=/usr/include/postgresql \ --enable-largefile=yes \ --with-includes=/usr/include \ --with-proj-share=/usr/share/proj \ --with-tcltk-includes=/usr/include/tcl8.4 #configured ok, then from website instructions do this #but I had to add 'sudo' before make sudo make -j2 sudo checkinstall sudo ldconfig .. That's what worked :-) a couple of basic questions showed in terminal as I finished the process but they went straightforward. One small thing, is that I now have to type 'grass64' from the terminal, on previous version/s I had the option to just type 'grass' (possibly the ubuntu install just make a link in the relevant ./bin file from 'grass' to 'grass 6.x') I used 'locate' and 'whereis' in a terminal to check if 'grass' still existed, it seems not. Trivial issue though :-) Overall, am pleased that I managed to A) get it working and B) not have the old version hanging around to confuse me or the computer! I will post feedback on usage, particularly regarding recent problems I reported, in separate emails. Regards, and a pat on back to the GRASS collective :-) -Shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.vect anomalies 'fixed' in 6.4.2RC1
Hi all, over last couple of weeks, wrote about problems with the GUI for d.vect in wxpython. Basically, tweaking properties for vectors caused GRASS to freeze after a few operations of d.vect dialog. I have just been playing with d.vect in wxGUI and it seems to be working well :-) I've done 3-4 times more changes using the d.vect dialog than what I'd achieve previously before a crash - changing colours, displaying different layers, display cats/topology for vectors, change what features (line/area/etc) are displayed, even putting SQL 'where' clauses in that worked correctly... So I think the problems I faced, have been dealt with in this version. Fabulous! Will continue to use wxGUI now, if other things arise will note them. -Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] i.ortho.photo questions -testing in 6.4.2RC1
Hi again all, I'm trying i.ortho.photo from wxGUI to assess an earlier problem. So far I have hit a similar error message when zooming after a few GCP's are present, but I am wondering if I have done some things wrong in earlier steps. For entering camera position at step 6 for omega/phi/kappa, I read the help/instructions in GRASS, and based on having the camera pointing straight down from the plane, I put the angles for both of these at 0. The instructions state that I don't need this step when using vertical images anyway, but for the sake of me understanding how this whole process works I wanted to enter the values (and can just leave 'use at run-time' set to 0). Should I actually have used 90? My interpretation of the instructions may have been wrong in assuming zero is when camera view is perpendicular to ground in the x and y planes. Is camera angle for these values measured from horizontal? Then, if there is roll or pitch, do either of these have a positive/negative or clockwise/counterclockwise format? the instructions explain yaw is measure in degrees from north, clockwise being positive (but not full 360; goes to +180 or -180)? Another key thing I may have shot myself in the foot with, is editing original image. It was too big to use in entirety, so I cropped out the section I wanted in the middle. I also increased resolution of this cropped bit to give a clearer picture. So whilst dimensions have changed, it is not the extent of image that is indicated by original camera specs e.g. focal length, width/height, pixel dimensions will be different. Does this mean the use of orth-photo rectification is voided for me? Or can I employ some trigonometry and basic maths to calculate parameters for the cropped image from the parameters of the original image and then feed those into i.ortho.photo? Comments appreciated. Regards, Shane. PS, on similar note, another poster asked about using ortho-photo rectification of satellite images, to which the advice was 'you can't'. I would have thought a satellite image is akin to an aerial image taken just a little higher off the ground...?? or do sat images span too much curvature of the earth to rectify well in i.ortho.photo? or do they lack the parameters required such as camera angles, focal lenghts/points, etc? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: d.vect dialog issues, and query tool issues (previously: GRASS GUI issues)
Hi Martin, excuse slight delay in reply, busy elsewhere.. yeah, i think i put specs in earlier posts but they're _days_ old now ;-) and longwinded. 6.4.1 from 'unstable' ubuntu-gis repositories, as per info on grass download site. ubuntu 10.04.3 64 bit uname -a output: Linux [my-computer-name] 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:39:17 UTC 2011 x86_64 GNU/Linux If you want to see how to 'reproduce' the problems I have, refer back to earlier post/s. Thanks :-) shane. On Tue, 2011-10-11 at 12:07 +0200, Martin Landa wrote: Hi, 2011/10/11 Shane Litherland litherland-f...@bigpond.com: so if those error messages aren't relevant, and the wxGUI should be working with python 2.6... any suggestions on what else I should be looking into to figure out the d.vect freeze issue, and/or the lack of output from query tool in display mode? which version of GRASS? (on Ubuntu right?) Martin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] RE: Connect two tables in vector data
Hi Sebastian et al., I gathered from the original post, that you did manage to connect each table, separately to the vector, using different layers, which I have done myself several times. I then gathered that this was not what you ideally wanted, and you then proceeded to play with connection settings and got some errors about GRASS not recognising a column for key/cat/Schluessel? It could be that the column, though appearing to have numbers in it, wasn't actually numeric (that was the kind of error message I'd expect for such a situation). I've seen this sort of thing happen if, for example, the tables are being imported from other formats such as .csv without the column type as 'integer', 'serial' etc. Or the imported data (associated with your .shp file) did have valid column formats but those formats were not recognised by dbf. In the past, this has happened to me with a couple of number/date formats. For that particular situation where you had that error, you might be able to check/change the column format in the database... but if you are using the inbuilt dbf database, well, I found it too limiting for my purposes when playing with tables and SQL queries and moved to PostgreSQL. As another post suggested, you could move to something like this or SQlite, MySQL, or others(?) for better table/database versatility. Another issue you mentioned related to querying the vector, and not getting info back for all the layers/connections... I have recently had similar issues with the query tool in the wxGUI (python) that I've noted in a couple of posts over the last week or two. So that issue may have been separate to how you were connecting the tables (more a problem with the GUI), but I can see how you could interpret it as being a problem with the tables/connections. I'm not sure what the verdict is on this query tool issue at moment. Getting back to your original question though...I reckon Moritz' answer might have solved your original question.. I haven't yet played with v.db.join myself, thanks to Moritz for mentioning its use for this application, it might be useful for me too :-) There may also be another approach to 'joining' the tables for connecting to GRASS, if you are working in a database. You may be able to make a 'view' (akin to a temporary new table or a select statement) from both tables of interest and connect to the 'view' from GRASS... I know in PostgreSQL, a view is considered much the same as a table and a quick check in GRASS shows I can connect to a 'view', but being a view it's not actually the original data so adding/editing I don't think is possible. That in some situations might actually be a benefit though? i.e. no unanticipated data changes whilst in GRASS. safe for punters to use... ;-) Anyway, was really just throwing in my basic experiences for your info. Hope it might help you understand some of the hurdles you've come to! Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] 'Show attribute data' icon gives db.select error
Hi all, I've known about this for awhile but worked around it. Maybe it's already been reported, it's a small thing. Using tcltk GUI (ver. 6.4.1), when I have a vector layer, some options for settings include two icons to show table info - one prints column names in the output, the other is supposed to print table data. what that latter button does for me connected to postgres database, is submit this command to the output: db.select table=weeds database=/home/my_home_directory/gisdb driver=pg When what it should be is: db.select table=weeds database=gisdb driver=pg I know this because I copy the 'bad' command to the 'terminal' at bottom of the output monitor, delete the /home/my_home_directory/ and re-run successfully. I suspect the /path/to/local/directory part of this db.select is relevant if one is still connecting to a dbf within GRASS or a local SQLite database, but it seems for postgres (all server db's?) GRASS already knows how to locate the postgres server, it doesn't need a directory path. it only needs the database name. Anyone know if this has been rectified? Like I said I've known about it awhile, many months even, but such an easy workaround was quicker than writing this email about the problem! Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: d.vect dialog issues, and query tool issues (previously: GRASS GUI issues)
Hi all, and Martin FYI, I see there's a 6.4.2RC release hot off the press. I've had a quick look at info about it, there's a sizeable amount of things been done around wxGUI/python, some of the stuff might still be on the wishlist for backporting etc, but I'll try and install a separate GRASS of this RC, and test if the previous issues I wrote about have been fixed. Will take me a week or so to fit it in with other tasks. Have to brush up on how to install multiple versions, let alone how to compile...!! will report back when I've played with the new toy :-) -shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Multiple installs of GRASS?
Hi all, So, I know one can have a 'working' GRASS and a 'try-if-you-dare' GRASS on the one computer... a quick web search on how to do multiple grass installs gave me more info on laying turf than on computing though! The GRASS wiki has good info on compiling from source, but didn't see anything clear about how to set up a testing GRASS without it interfering with my existing, functional one. Any tips on where/what to read to get this right? am on ubuntu 10.04, working with GRASS 6.4.1, want to try the 6.4.2RC to check if a few glitches I am aware of have been sorted out. I probably read info about this months/years ago but need to update myself before I blunder on into compiling from source-code! Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Multiple installs of GRASS?
Thanks Paulo, I suspected that was the 'right' way to approach it but was vague on the locations/config. See how I go with it (a weekend project I think). -shane. On Thu, 2011-10-13 at 14:49 +0200, Paulo van Breugel wrote: You can compile your ' working' GRASS in e.g., /usr/local/grass64 and your 'try-out' GRASS in /usr/local/grass70. You do this setting the --prefix option when configuring (e.g., ./configure --prefix=/usr/local/grass64 ...). To be able to run the working and try-out versions by typing respectively grass64 and grass70 on the command line, you copy their executables to the /usr/bin, like below; ln -s /usr/local/grass64/bin/grass64 /usr/bin/ ls -s /usr/local/grass70/bin/grass70 /usr/bin/ Just realized you already have a functional one installed. In that case, just install the try-out version as described above, it should not interfere with the existing one. Cheers, Paulo On Thu, Oct 13, 2011 at 2:33 PM, Shane Litherland litherland-f...@bigpond.com wrote: Hi all, So, I know one can have a 'working' GRASS and a 'try-if-you-dare' GRASS on the one computer... a quick web search on how to do multiple grass installs gave me more info on laying turf than on computing though! The GRASS wiki has good info on compiling from source, but didn't see anything clear about how to set up a testing GRASS without it interfering with my existing, functional one. Any tips on where/what to read to get this right? am on ubuntu 10.04, working with GRASS 6.4.1, want to try the 6.4.2RC to check if a few glitches I am aware of have been sorted out. I probably read info about this months/years ago but need to update myself before I blunder on into compiling from source-code! Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Multiple installs of GRASS?
Hi Sylvain, thanks it must be too late at night... I'd had a quick look at that site before but missed the attention dummy, this will work for you I was hoping to see in relation to two installs ;-) -Mind you, after getting a coupla good tips for this, one suggested I need not bother with 2 versions if merely going from 6.4.1 to 6.4.2RC... just upgrade. But maybe it's time I lived on the edge and had a 7.x to tinker with as well... :-) -shane. On Thu, 2011-10-13 at 15:40 +0200, Sylvain Maillard wrote: Hi, in fact it's pretty easy to have multiple grass install on your computer: you just need to follow the instructions on http://grass.osgeo.org/wiki/Compile_and_Install#Ubuntu, and use the --prefix=/opt/grass64 (or whatever you want) on my gentoo box, i have a regular grass-6.4.1, and a compiled 6.4-svn, grass-6.5, and grass-7 without any trouble! cheers, Sylvain 2011/10/13 Shane Litherland litherland-f...@bigpond.com Hi all, So, I know one can have a 'working' GRASS and a 'try-if-you-dare' GRASS on the one computer... a quick web search on how to do multiple grass installs gave me more info on laying turf than on computing though! The GRASS wiki has good info on compiling from source, but didn't see anything clear about how to set up a testing GRASS without it interfering with my existing, functional one. Any tips on where/what to read to get this right? am on ubuntu 10.04, working with GRASS 6.4.1, want to try the 6.4.2RC to check if a few glitches I am aware of have been sorted out. I probably read info about this months/years ago but need to update myself before I blunder on into compiling from source-code! Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] orthophoto georeferencing stops working when adding points
Hi all, GRASS 6.4.1 on ubuntu 10.04 64 bit, tcltk GUI (because of other wxpython probs previously reported) Have been trying my hand at orthophoto georeferencing. I started with a digital image that was taken with a digital aerial camera. Has most of the camera settings required for the orthophoto parameters asked for in the steps. As the image is direct from the camera I didn't have a fudicial marks etc to do one of the steps but that didn't seem to be a problem. Seemed to be going OK, putting in parameters etc. Got up to option 7 (as per what shows in a terminal after i.ortho.photo is run from the GUI menu I have put in 4 control points using the monitor. For each one, i used zoom-box to get up closer before positioning point, and using keyboard to enter GCP co-ords. I then did a fifth point. it seemed to work OK, but then when trying to do zoom for another point, get messages: WARNING: Unable to find raster_i_am_georeferencing (click mouse to continue) [so i click mouse, then second message] WARNING: Unable to open raster map ditto (click mouse to continue) [click mouse again, options along bottom of screen come back, so I quit] I have tried repeatedly with fresh sessions of GRASS, to add more points without luck. Also noted that only four GCP's are saved. each time I start it up, I can apparently add GCP #5, and then get warnings after that, but that #5 point isn't being saved to the control points file. I tried a workaround: open up the GCP monitor/terminal, zoom and click a point, then go and open up the control-points text file and manually enter in that point co-ords and matching control co-ords. Go back to the monitor/terminal and hit 'enter' to blank out the point I'd just clicked on. Then tried zooming on another spot of the map, still got the errors. Opened up a fresh monitor/terminal, and noted that the point I'd manually added to text file was displayed correctly. Did a zoom box, actually missed where I wanted so then used zoom-point option to try and reposition the zoomed view, got the warning messages again. Dunno if it is part of same thing, but notice when I hit 'analyse' that the errors for east and north are up around 657900 and -6603200 respectively, using UTM 56J wgs84 (i.e. metres). target points are around 476900 and 7096500. It's a while since I've done some georeferencing, but these figures just seem too wrong. or does the error get calculated at the next stage and these are really just dummy/filler numbers? I tried another work around - run the 'georectify' tool from GUI menu, as far as the i.points part I think? i.e. enough to put one example point into the points text file. Then I copied the points from 'control points' text file for ortho-photo process, over to the points file for the regular process, noting the spaces, elevation etc that wasn't relevant for the points file. I could open that up in the georectify monitor, and the error shown for each of the points was more along the lines of 0.7 - 26 forward error and 5 - 125 backwards error (1st order rectification). That's hugely different from what I reported above in ortho-photo analyse. What have I done, that it was happy to input 4 points and after that I can't work it? If I have to manually add points to the text file, one at a time and restart i.ortho.photo each time, I will eventually achieve what I want. but that's time consuming, and absolutely not what the program was designed for, right? :-\ On the other hand, I could go back to what I've done before with the 'basic' georectify (i.points etc) but that won't let me add elevation data to an image like orthophoto does?? Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: d.vect dialog issues, and query tool issues (previously: GRASS GUI issues)
Hi Martin, so if those error messages aren't relevant, and the wxGUI should be working with python 2.6... any suggestions on what else I should be looking into to figure out the d.vect freeze issue, and/or the lack of output from query tool in display mode? Regards, Shane. On Mon, 2011-10-10 at 15:40 +0200, Martin Landa wrote: 2011/10/10 Shane Litherland litherland-f...@bigpond.com: Anyone know if newer versions of GRASS use python 2.6 or higher? GRASS (wxGUI) should work with python2.4+ (including 2.6 or 2.7). Python 3 is not supported. Martin ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: d.vect dialog issues, and query tool issues (previously: GRASS GUI issues)
I just came across something more in regards to python misbehaviour - it may well be that GRASS 6.4.1 needs python 2.5 and ubuntu 10.04 has 2.6. One website that outlined their success with GRASS after getting the 2.5 python version is http://dipeshbhattarai.com/?p=57 (note they were using windows7 and it too had python 2.6) more searching finds other sites with ppa's etc for this 2.5 version. https://launchpad.net/~fkrull/+archive/deadsnakes http://welcometoubuntu.blogspot.com/2010/05/howto-install-python-255-on-ubuntu-1004.html I am yet to try it... a bit hesitant in whether I'll break something on my system... ;-) Anyone know if newer versions of GRASS use python 2.6 or higher? Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] d.vect dialog issues, and query tool issues (previously: GRASS GUI issues)
Hi all, With all quiet on the users emails on my subject, I went web-searching and found some leads: The ubuntu desktop themes seemed to have an issue reported for a range of programs that the GNOME/gtk settings needed hacking/tweaking, see http://thehacklist.blogspot.com/2010/06/resolving-murrinestyledrawbox-assertion.html http://rakitha.wordpress.com/2011/05/08/fixing-the-gtk-error-critical-murrine_style_draw_box-assertion-height-1-failed-in-ubuntu/ I followed the info therein, and have just run GRASS again with wxpython GUI. The outcome is partially successful in that when choosing the query tool in map display, I can click on the map and not get the previously posted error in the terminal (I launch grass from terminal / command line). But I am only partly getting what I expected from the query tool. When I choose the option for display mode and click on a point in active layer, the 'Abort Command' button in Command Console tab briefly activates then returns to being inactive but nothing actually happens/shows in the console. When I choose the edit mode for the query tool and click on a point/line/etc that I know has a db connection ONLY for layer one, it brings up a dialog box with details from the relevant table that the point/line/etc is linked to. If I click on something that I know has connections for both layer one and layer two, the query tool even in edit mode doesn't return anything. If I change The more serious issue of GRASS freezing if I use the d.vect dialog is still happening. several examples of what happens: -open GRASS from terminal then open a saved workspace (OK) -right-click on any vector layer in 'Map Layers' tab, choose properties, and the d.vect dialog box shows (OK) -if I do not change any settings in the dialog box, I can continue to right-click and display the d.vect dialog for any of the vector layers, as many times as I like without causing a freeze (OK) -I then started working my way down the vectors listed in 'map layers' dialog; -first vector, changed 'Selection - Layer number' to '2', hit OK button, and map display window updates accordingly to show only the points with db entries for layer 2 (OK) -second vector, changed 'Colours - line colour' (OK) -third vector, changed 'Selection - feature type' and unchecked 'centroid' (OK) -returned to second vector, changed colour again (OK) -returned to third vector, and right-clickproperties results in the d.vect dialog opening with a blank window instead of all the tabs and settings. Clicking on the close icon then gives the 'system busy' msg and I have to force-quit which closes all the GRASS GUI's. -in a fresh start of the GUI, I repeated this and did not get a freeze on the last step above, I could change the 'feature type' to re-display centroids. -I then continued and went back to vector two, changed colour again (OK) -back to vector 3, unchecked 'centroids' again (OK) -back to vector 3, try to re-check 'centroids' but got blank d.vect dialog another fresh start and I did this: -vector one, change layers to 2 (OK) -vector two, change colour (OK) -click on all vectors numerous times to view d.vect but close dialog each time with no changes (OK) -vector three, deselect 'centroids' (OK) -vector one, change layers to -1 (OK) -vector one, change layers to 2 (OK) -vector one, change layers back again to -1 (OK) -vector two, change colour again (OK) -vector two, try to change colour yet again, get blank d.vect dialog another fresh start; -vector two, change colour (OK) -vector three, deselect centroids (OK) -vector two, change colour again(OK) -vector three, select centroids again (OK) -vector three, change line colour (OK) -vector three, change line colour back again (OK) -vector one, add cat criteria '10' (OK) -vector one, add cat criteria '5' (OK) -vector one, remove cat critera and 'apply', change layers to 2 and 'apply, then change fill colour and 'OK' (i.e. closes dialog) (OK) -vector one, view the d.vect dialog but just close it again no changes (OK) -vector two, change colour (OK) -vector two, view d.vect dialog but close no changes (OK) -vector three, d.vect opens with blank dialog. upon force-closing after this example, the terminal had the message: . (office:5204): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion `index = 0 index = layout-length' failed (office:5204): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion `index = 0 index = layout-length' failed ... a shorter scenario from fresh start: -vector three, deselect centroids (OK) -vector one, select layer two (OK) -vector three, re-select centroids (OK) -vector one, get blank d.vect repeating this scenario, I only got to the third point where the GUI closed again and gave terminal message: (office:5675): Gdk-WARNING **: XID collision, trouble ahead (office:5675): Gdk-WARNING **: XID collision, trouble ahead (office:5675): Gdk-WARNING **: XID collision, trouble ahead office: Fatal IO error 0 (Success) on X server
[GRASS-user] Re: Pango error, still relevant?
Hi all, in digging around for answers in regards to my 'd.vect problems I found a post by Antonio from 14 April 2010: . Hi I'm using GRASS6.4svn in an Ubuntu Machine and, when I start GRASS I get this warning at command line: (python:3305): Pango-CRITICAL **: pango_layout_get_cursor_pos: assertion `index = 0 index = layout-length' failed What might be causing this? and what are the consequences of this? Thanks Best regards Antonio . -Antonio, did you solve your problem I wonder? -Given this message showed up in my d.vect trials, is that consistent with Antonio's problem? -Given Antonio reported this over a year ago and I've still struck it with 6.4.1 also on an ubuntu box, is there still something to be dealt with in ubuntu, or in GRASS? Anyone wanting more on where I got the message, see my other post re: d.vect etc... Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.mapcalc appears to have changed behavior
Nice to know I can remove one possibility from my list of computing worries :-) regards, shane. On Sat, 2011-10-01 at 00:51 -0700, Michael Barton wrote: Fortunately, upgrading GRASS should have no effect on the region settings for maps. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice:480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Sep 30, 2011, at 11:35 PM, Shane Litherland wrote: Jim, et al., I am not an authority on GRASS, but it may not have been you that 'did that' - if you were using an earlier version and did a significant upgrade or a fresh install of a newer version of GRASS, some fine details like this might end up with new default values (?) I recall doing a few re-installs/upgrades and having to keep a close eye on user settings, mapset locations, etc when starting up a newer GRASS. May not be what happened in your case, but worth keeping in mind if/when you are moving around GRASS versions or using it on other computers etc, check up on some of the environment variables as you go. Help docs have info on how to find the gory detail :-) From: Jim Mochel jim.mochel.hi...@gmail.com Subject: Re: [GRASS-user] r.mapcalc appears to have changed behavior To: Michael Barton michael.bar...@asu.edu Cc: grass-user grass-user grass-user@lists.osgeo.org Message-ID: CAE=y9-tfacpyg_csap9w_5u47mdcu_phuxmaywurw2kevz0...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Thank you. ! I am not sure how I did that but I am sure it seemed like a good idea at the time :-) Jim ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] RE: GRASS GUI issues
Hi again all, Took a break from computer, had a brilliant idea... ;-) Tried running GRASS in good old skool tcltk GUI - it happily let me query the map display, it happily accepted the sql 'where' clauses for layer that the python gui ignored, and it happily let me change numerous times, the settings for a layer... So, would seem the issue is not with GRASS in essence, nor with me, but with the python GUI. Whether it's from my O/S side or GRASS side on that aspect is beyond my computing knowledge. Should this be added to bugs now that I have a clearer understanding of what did and didn't work? Or should I be looking to add/update my O/S with certain python packages? -Regards Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.mapcalc appears to have changed behavior
Jim, et al., I am not an authority on GRASS, but it may not have been you that 'did that' - if you were using an earlier version and did a significant upgrade or a fresh install of a newer version of GRASS, some fine details like this might end up with new default values (?) I recall doing a few re-installs/upgrades and having to keep a close eye on user settings, mapset locations, etc when starting up a newer GRASS. May not be what happened in your case, but worth keeping in mind if/when you are moving around GRASS versions or using it on other computers etc, check up on some of the environment variables as you go. Help docs have info on how to find the gory detail :-) From: Jim Mochel jim.mochel.hi...@gmail.com Subject: Re: [GRASS-user] r.mapcalc appears to have changed behavior To: Michael Barton michael.bar...@asu.edu Cc: grass-user grass-user grass-user@lists.osgeo.org Message-ID: CAE=y9-tfacpyg_csap9w_5u47mdcu_phuxmaywurw2kevz0...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Thank you. ! I am not sure how I did that but I am sure it seemed like a good idea at the time :-) Jim ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS GUI issues
Hi all, I had GRASS 6.4.0 from stable rep's for ubuntu lucid 64-bit, and it was freezing when I opened the properties dialog for a vector layer. Worked OK the first time I used it for a layer, but if I tried going back to change things, everything just 'greyed out' and even after leaving it for a cup of tea, it was still stuck. Tried to close the offending box (d.vect dialog), got msg that it was busy etc, chose to force quit which closed GRASS entirely. So I checked what was currently stable on the GRASS site, i.e. 6.4.1 (available from the unstable ubuntu rep's) It may have gotten rid of the freezing issue, I'm still checking it out. But in the process of checking it out, I tried to change to the command tab in main window and each time I click on the tab, the following message came up in the terminal: (python:1736): CRITICAL **: murrine_style_draw_box: assertion `height = -1' failed Nothing seemed to show in the GRASS command tab. I noted on re-starting GRASS, I was getting same msg but different python: number at start. Also got same msg if I went to the map display and chose the 'query' tool. when I clicked on the map, above msg occured multiple times (possibly same multiples as object had connections to db tables?) On top of this, the original problem of d.vect dialog freezing, is still happening. e.g. first time I opened it to type in a criteria in 'where' box, seemed OK (apart from the map display not showing anything and I'm fairly sure my sql was OK). Second time opening it to try removing the sql, it froze. Before I venture into the world of bug reporting for GRASS, thought I'd check with user group in case it's something I've mucked up...? or something already known about? Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] leftover node in v.digit
trust me to do something strange with otherwise healthy software ;-) ... that dangerous stage where I think I know enough to use it but don't really (i.e. brashly clicking on tool icons without checking what tool i've clicked on...) Regards, Shane. On Sun, 2011-01-09 at 20:00 +0200, Maris Nartiss wrote: Hello Maciek, it wouldn't change a lot, as this bug is also present in 6.5. It's just a corner case. Nobody has been doing such strange thing before and thus it has went unnoticed for years. Shane, thanks for report. I will fix it someday (hopefully for 6.4.2). Maris. 2011/1/9, Maciej Sieczka msiec...@sieczka.org: W dniu 08.01.2011 06:01, Shane Litherland pisze: Hi Maris, Have braved my first attempt at filing a bug report, and appear to have put enough together to generate a ticket Ticket #1256 leftover node when deleting boundaries vertex-by-vertex hope it's of help... :-) Shane, 6.4.0 RC6 is several months old. Please try installing and veryfing your issues against the newest stable release candidate - http://grass.osgeo.org/grass64/binary/linux/snapshot/. If impossible, please at least try the 6.4.0 final Ubuntu package from https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable/. Maciek -shane. On Fri, 2011-01-07 at 12:49 +0200, Maris Nartiss wrote: Open a bug report with exact step-by-step how to reproduce this issue. http://trac.osgeo.org/grass Maris. 2011/1/7, Shane Litherlandlitherland-f...@bigpond.com: Hi again, another little thing I found by accident, If digitising boundaries, then using 'remove vertex' to delete some of a boundary, vertex-by-vertex... If I kept going and removed all the vertexes (instead of the correct way of using 'delete point/line/boundary'), it was possible to end up with some leftovers.. I could see a lone red cross on the v.digit screen (meaning, node(1 line) ) that I could not select to move, add, delete, anything... no matter what my zoom. This errant node did not show in the GRASS map view of the vector in question, only in v.digit. Using v.clean 'found' and removed this errant node (using the rmline option) and I checked the vector info of the 'dirty' versus 'clean' vectors to see nothing else had been upset. It was an accident, I thought I'd selected the 'delete' tool... but interesting, nonetheless ;-) regards, shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Maciej Sieczka http://www.sieczka.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] leftover node in v.digit
Hi Maciek, Just looking into newer version/s. Appreciate comment. I check the standard ubuntu stable reps for versions, RC6 has been hanging in there for a while... I generally have stuck with those ubuntu-reps versions for ease-of-use etc, but will see what I can get from 'unstable' (seems 6.4.0-2 is an option) or, manually upgrade GRASS to on my box. Alas, when I set this box up early 2010, the consensus seemed to be to stick with 32-bit unless I really needed 64-bit... now GRASS 6.4.1 is only (?) in 64-bit on the link you gave, so I'll either resort to the next-best 32-bit that I can find... or tackle the small drama of reinstalling 64-bit on my box... at the moment, the former is easier, but I know, I know, at some point I'll have to be dragged kicking and screaming to 64-bit ;-) ... I could probably wade through compiling from source to get 6.4.1 as 32-bit if it's available but i'd be stretching my computing skills there too.. Regards, Shane. On Sun, 2011-01-09 at 20:39 +0100, Maciej Sieczka wrote: W dniu 08.01.2011 06:01, Shane Litherland pisze: Hi Maris, Have braved my first attempt at filing a bug report, and appear to have put enough together to generate a ticket Ticket #1256 leftover node when deleting boundaries vertex-by-vertex hope it's of help... :-) 2011/1/9, Maciej Sieczka msiec...@sieczka.org: Shane, 6.4.0 RC6 is several months old. Please try installing and veryfing your issues against the newest stable release candidate - http://grass.osgeo.org/grass64/binary/linux/snapshot/. If impossible, please at least try the 6.4.0 final Ubuntu package from https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable/. W dniu 09.01.2011 19:00, Maris Nartiss pisze: Hello Maciek, it wouldn't change a lot, as this bug is also present in 6.5. It's just a corner case. Nobody has been doing such strange thing before and thus it has went unnoticed for years. Shane, thanks for report. I will fix it someday (hopefully for 6.4.2). Shane, FWIW - I was referring to reporting an testing habbits in general :). Maciek ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.digit 'next not used' cat error
Hi again fellow GRASSers, Just noticed this little issue (GRASS 6.4 on ubuntu 10.04) I am digitising boundaries, using 'no category' option, then I digitise centroids with 'next not used' and 'add to table', where I enter relevant info for my postgres db table. That's all fine. I then had a couple of existing centroids where I used the 'display categories' icon to view, and then add, an additional category to that centroid, choosing 'add to table' option. I could then 'view attributes' for the new second cat number, and add/edit data fields. Thereby, ending up with two bits of data from my table, for one centroid. Again, that is all fine. When I returned to making new centroids, I noticed the 'next not used' number that GRASS 'remembered' was the last cat number used when digitising a new centroid, it did NOT recognise that I had added cat(s) by another means to the table, and therefore should have increased the 'next not used' to suit. Instead, if I continued to just digitise the centroid, it gave a message 'that category already exists in table' etc and shows data for that existing cat. I easily deleted that existing cat connection and added a new one in the same way I added a second cat as outlined above, so it didn't affect my db/table data at all, just a longer way of getting to the end result. Even then though, the 'next not used' cat number had only incremented itself by one, so if i blindly continued to digitise centroids, I would continue to get simliar 'record exists' issue and have to manually change/enter correct new cat and data. To get 'next not used' to catch up, I had to use 'manual entry' for at least one new centroid cat, then the counter for 'next not used' was happy again. It seems that the counter for this aspect must look up the cat numbers in the table when starting v.digit, then increment when the 'next not used' option is chosen whilst digitising, but it does not check repeatedly with the db for the REAL 'next not used' cat in the db that (as I found) can be increased by adding cats by other means. May this have been addressed since the version of GRASS i'm using?? Or is it something still of relevance for addressing? Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] leftover node in v.digit
Hi again, another little thing I found by accident, If digitising boundaries, then using 'remove vertex' to delete some of a boundary, vertex-by-vertex... If I kept going and removed all the vertexes (instead of the correct way of using 'delete point/line/boundary'), it was possible to end up with some leftovers.. I could see a lone red cross on the v.digit screen (meaning, node(1 line) ) that I could not select to move, add, delete, anything... no matter what my zoom. This errant node did not show in the GRASS map view of the vector in question, only in v.digit. Using v.clean 'found' and removed this errant node (using the rmline option) and I checked the vector info of the 'dirty' versus 'clean' vectors to see nothing else had been upset. It was an accident, I thought I'd selected the 'delete' tool... but interesting, nonetheless ;-) regards, shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.digit doesn't like mouse-wheel
while i'm on a roll with my complaining... i've known about this one for a while, so probably others do too. in the main v.digit monitor, or some of the GUI bits like 'attributes', if I try to use the mouse scroll up/down wheel, i get an error pop up, (or, if i wheel for more than one 'notch' of the wheel, the error repeats for said number of notches). ERROR: can't read bind_scroll_list: no such variable can't read bind_scroll_list: no such variable while executing lsearch -exact $bind_scroll_list $window (procedure handle_scroll line 5) invoked from within handle_scroll 1 .screen.canvas (command bound to event) . Again, FYI, GRASS 6.4.0RC6 on ubuntu 10.04 I believe the GUI is default tcltk -shane :-) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] leftover node in v.digit
Hi Maris, Have braved my first attempt at filing a bug report, and appear to have put enough together to generate a ticket Ticket #1256 leftover node when deleting boundaries vertex-by-vertex hope it's of help... :-) -shane. On Fri, 2011-01-07 at 12:49 +0200, Maris Nartiss wrote: Open a bug report with exact step-by-step how to reproduce this issue. http://trac.osgeo.org/grass Maris. 2011/1/7, Shane Litherland litherland-f...@bigpond.com: Hi again, another little thing I found by accident, If digitising boundaries, then using 'remove vertex' to delete some of a boundary, vertex-by-vertex... If I kept going and removed all the vertexes (instead of the correct way of using 'delete point/line/boundary'), it was possible to end up with some leftovers.. I could see a lone red cross on the v.digit screen (meaning, node(1 line) ) that I could not select to move, add, delete, anything... no matter what my zoom. This errant node did not show in the GRASS map view of the vector in question, only in v.digit. Using v.clean 'found' and removed this errant node (using the rmline option) and I checked the vector info of the 'dirty' versus 'clean' vectors to see nothing else had been upset. It was an accident, I thought I'd selected the 'delete' tool... but interesting, nonetheless ;-) regards, shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: Assign attributes of start and enpoints to connecting lines
Hi Hanlie, I am getting out of my depth here, and might be leading you astray... But I had a little challenge a few months ago, wanting to generate points along a line to then use to create other tangent lines (in science terms, generating belt-transects across a gully, at randomly defined distances from start of gully)... sounds vaguely like a simpler version of what you're doing. I used a combo of v.segment, v.type_wrapper.sh,... and some beginner fumbling... from your initial post, I'm guessing you've already got these under your belt? If your current hurdle is getting a new column into the table for the river segments layer, from info in the points layer, could you achieve this by working directly with the tables (database)? rather than a GRASS command?? Do you have some linking field between the points and the segments layers (e.g. segment_cat)? if you do, or can make one, could you e.g.: SELECT (start_node_name\ end_node_name) AS segment_name FROM points_layer_table and update this to the river segment table?? UPDATE river_segment_table SET new_column_for_label=segment_name WHERE river_segment_table.segment_cat=points_layer.segment_cat ##note this isn't gramatically correct SQL... just an idea.. Please excuse crude SQL example, I'm still dusting off my old MSACCESS knowledge and 'converting' it to Postgresql... You can probably get a select/update process in one easy step with the right SQL sweet-talking? If i'm off track, apologies for misleading you ;-) if you get something out of it, i might promote myself from complete novice at sql to someone that knows just enough to break things Regards, Shane. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] RE: Where the grassdata base resides
Hiya, I have no probs with my GRASS having been set up (on Ubuntu) at /home/my-home/GIS/GRASSdata, which, for you, might be equivalent to c:/users/path-to-your-folders/GIS... (sorry, haven't used that OS for awhile)... I'd also recently installed it on a colleagues laptop, I think they were running Vista or 7... I think I put the GRASSdata somewhere on their user's desktop... I was in a rush, and struggling to remember my way around windows so unfortunately can't recall much of the detail to help you. But the program did work fine. I was already aware that whitespace in folder/directory names is a bad practice (at least in my experiences.. even though i think windows still works ok with them, your GRASS installation, having been born from another family, still might not like them) so in my previous example I know I actively avoided that. if_you_insist_on_spaces,...be\ prepared\ to\ possibly\ do\things\ differently... :-) Did you install GRASS, then try moving the folder location? that may have confused some of the startup settings and cause your crash?? not sure if/how to edit startup stuff if this is your case, might be best to try clean install to your desired location.. unless you've already tried this. Maybe, if you don't get it solved 'neatly', a sym-link from C: to where you prefer to keep GRASS?? my two cents ;-) -shane ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.in-out quirks
Hi Micha, yes, by all means, wiki away :-) I haven't yet educated myself on how to contribute to wikis and bugzillas and the likes, so if you want to take that task off my hands you're welcome :-) Somewhat pleased that my verbosity had some elements of usefulness therein! now, to spend a bit more time in GRASS and come up with my next 'victim'.. I reckon I can give v.digit and its friends a good workout! Regards, Shane. On Tue, 2010-12-07 at 12:03 +0200, Micha Silver wrote: Shane Litherland wrote: (my first-ever reply to the list...hope I get the cc / subject stuff right!) Seems to be OK (also FYI - GRASS 6.4.0RC, Ubuntu 10.04LTS (most of my sys/progs from synaptic package manager) AND a GARMIN GPS60) Micha - your suggestion much appreciated :-) I had used v.in.ascii a while back, had forgotten how versatile it could be! I used a slight adjustment to your suggestion - I still like having another copy of my gps data, so did it in the two steps rather than piping, i.e. gpsbabel (gebabbel GUI) to save a unicsv format file from the garmin handset, then the v.in.ascii (GRASS GUI) to get the unicsv format into grass. May I take take your suggestions to add to the GRASS wki? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Re: v.in-out quirks
(my first-ever reply to the list...hope I get the cc / subject stuff right!) (also FYI - GRASS 6.4.0RC, Ubuntu 10.04LTS (most of my sys/progs from synaptic package manager) AND a GARMIN GPS60) Micha - your suggestion much appreciated :-) I had used v.in.ascii a while back, had forgotten how versatile it could be! I used a slight adjustment to your suggestion - I still like having another copy of my gps data, so did it in the two steps rather than piping, i.e. gpsbabel (gebabbel GUI) to save a unicsv format file from the garmin handset, then the v.in.ascii (GRASS GUI) to get the unicsv format into grass. Having the csv file also meant I could 'clean' it up (remove a few from around text/numbers) so it went into a Postgres table much neater when i ran v.in.ascii I played with a few other format options in gpsbabel; garmin_txt and openoffice formats 'found' all the data though the txt files probably needed cleaning up (excess empty fields) before taking into GRASS/Postgres. In a nutshell, it seems my 'lost info problem' may lie with my GPS and GPSBABEL - my model records the date/time for a waypoint as a 'note' (e.g. 06-DEC-10 20:15:40), hence gpsbabel finds it as text/description. Looking at some of the source styles and other C-source-code files of gpsbabel, it seems this type of date/time/note doesn't match what gpsbabel would expect as a proper date/time. Thought I'd try and streamline my tasks with my own style code, got the waypoint 'names' recognised, but hit a wall with the 'strptime'-based date/time formatting options... something to take up on a gpsbabel forum.. So for now I stick with the workaround :-) Also - Using Postgres as db, I had the option of choosing a date-time field as timestamp without time zone which is an option that didn't seem available in the default dbf... so it can convert the date/time string to a proper date and time - which means I can get away with having gpsbabel output the date/time as one text field... I like Postgres :-) v.in.garmin: I think the reason I could not get v.in.garmin to work, is that it uses GPSTRANS (or GARDUMP) as the means to download the data from the gps in the first steps. So the issue there, is more with gpstrans than v.in.garmin. From all my reading and experimenting, it seems these programs are geared at communicating with a serial or usb-to-serial gps unit. My unit is 'proper' usb (i.e. no /dev/tyyUSB0 etc, 'lsusb' in terminal shows it connects to /dev/bus/usb/) but despite my experimenting, i could not get gpstrans to find the usb ports. Didn't try gardump yet. The above workaround is easier than fiddling with more unfamilar software ;-) From what I read, both these have been around a while, and not so much has happened with them of late?? maybe v.in.garmin could be rolled into v.in.gpsbabel, with gpstrans and gardump as second or third options to gpsbabel... if it's not something that's already been improved since my 6.4 version! v.in.gpsbabel: If I edited a csv file, to change field names, edit date/time to correct format etc, and ran this into v.in.gpsbabel, I got all the right info out the other side (i.e. vector points and data in db table). So, similar to above, it seems that the fields/format that gpsbabel attaches to my gps data, don't get recognised accurately when being used by v.in.gpsbabel. i.e. the issue is not really with GRASS. But If anyone is interested in following this gps-connection stuff, to improve v.in.garmin or v.in.gpsbabel, I have had success communicating with my usb-gps in other programs (e.g. Viking, Prune) so there may be ideas to get from there... Short of taking 'garmin_gps' off the modprobe 'blacklist', I have NOT had any luck getting my gps to connect to gpstrans, gpsman or QlandkarteGT 0.17.1 from ubuntu rep's (yet to try latest QlandkarteGT which apparently had work done on garmin issues). So no tips to offer from there :-/ v.in.ogr: - done a bit more experimenting... still doing more... there might be something to check in regards to v.in.ogr using 'desc' as a field name and causing the database (Postgres in my case) to be upset by a reserved word being used as a field/column name.. if I get a chance to look at the source code (have figured out I can do that from source downloads, yay!) I'll see if I can narrow this one down too.. Hope someone finds a bit of useful stuff in all that rambling! regards, shane. On Fri, 2010-12-03 at 14:07 +0200, Micha Silver wrote: On 12/02/2010 02:01 PM, Shane Litherland wrote: hi all you GRASSers ;-) not sure what happened when i first tried to join the mailing list a few months ago, but i got my user/subscription sorted now :-) I have been using GRASS for a couple years now, more consistently in the last 12 months after a steady learning process. So hopefully as I come across 'things' there's less likelihood it's just me being a silly novice (less, but not a surety..) my latest fiddling has been with import of GPS data by a few different
[GRASS-user] v.in-out quirks
hi all you GRASSers ;-)
not sure what happened when i first tried to join the mailing list a few
months ago, but i got my user/subscription sorted now :-)
I have been using GRASS for a couple years now, more consistently in the
last 12 months after a steady learning process. So hopefully as I come
across 'things' there's less likelihood it's just me being a silly
novice (less, but not a surety..)
my latest fiddling has been with import of GPS data by a few different
means, and some issues I struck.
my methods:
GPS to .gpx file using GEBABBEL (GUI for gpsbabel);
.gpx file has:
wpt (waypoints co-ords lat-long)
ele (elevation)
name (the name/number I gave each waypoint when I marked them)
cmt (supposedly a comment, it is the date/time)
desc (date/time again)
sym (name of symbol used in gps)
v.in.ogr to import gpx file to GRASS;
using Postgres as database;
specifying just one layer (e.g. waypoints);
... get an error when v.in.ogr tries to create table in postgres -
doesn't like 'desc' as a column name (one of those special db words).
...OK, so I can change the column names with cnames, but then it was
upset by 'time datetime' that corresponded to what should be 'name
varchar' in the .gpx file.
... or change 'desc' to 'description' in the .gpx file- but no, the
error still happens, seems the 'desc' cname is built into the v.in.ogr,
it's not checking any of the cnames with the input file
...but I also note in the output that the columns generated by the
v.in.ogr are way more than I have in the .gpx file, and the column
formats for the first few columns don't all match the formats for the
data they'd 'find' in the .gpx file.
... was wondering how then, I might get to the part of the v.in.ogr
module(?) that has all these columns to edit it...?? I did try in the
cnames, including 'name format' like i'd do when making a table, but
that confused the poor v.in.ogr (showed 'name format format' in the
output and didn't like making a table that way!)
... can check the box to 'not create attribute table' and import it OK
but of course, any waypoint name/info doesn't make it into GRASS /
postgres.
...OK, so v.in.ogr might not be the way to get .gpx stuff into grass
anyway, but i'm trying things out here!
my next approach-
v.in.gpsbabel;
using .gpx format;
... it runs OK, but generates a table with:
cat (added for the db)
x (lat)
y (long)
altitude (elevation)
gmt_date (blank - zero string length when table created)
gmt_time (blank - ditto)
comments (obvious)
when what was in the .gpx file was really
(cat - to be added for the db)
x
y
ele
name
cmt ('comment' actually datetime)
description (also datetime)
sym (name of symbol used in gps)
... so, whilst the v.in.gpsbabel got the waypoints in, it too 'lost' the
name of each waypoint and mucked up the date/time field/format when
populating the table.
I have not tried creating a db table directly (i.e. in postgres) and
then creating vector in GRASS and connecting them, as I figure the only
field i could safely link them on would be the datetime, because cats
generated during vector import probably wouldn't match the cats I made
manually in the table... and if the datetime was mucked up in its format
(e.g. as varchar instead) ... well, I just reckon that option could be
rather messy ;-)
Of course, I seem to have 'missed' the obvious option of directly
importing from the GPS unit to GRASS... well, I tried, but had to go and
figure out how the GPS connected to my computer (in Ubuntu 10.04, the
default connection shown in v.in.garmin of /dev/gps wasn't found)
...after getting fresh batteries for my gps, I tried connecting via:
/dev/usb
/dev/usbmon0 (thru to mon7)
/dev/ttyS0
/dev/USB0
/dev/tty0
usb:
...these 'ideas' from bits I saw in other GUI's and/or on the web, but
to no avail - the receiver did not respond on any of these ports.
I know gpsbabel (gebabbel GUI) connected to the unit with the usb:
setting because that's how I made my .gpx file in the first place.
I know of other 'workarounds' e.g. I have (a while ago) run the old
Mapsource in Wine, and then get the waypoints/tracks etc into a format
for GRASS, had also played with gpsman and some other bits. But I'm not
elaborating on those workarounds, at the moment it's more about sharing
my experience on how the more direct options didn't-quite-work ;-)
At the end of all that, I guess if I knew how to edit the v.in.ogr /
v.in.garmin / etc, I could tweak the bits to work..? but (I find this
bemusing still) these are .bin files, so despite them being part of an
open-source software, they are, from my perspective, still 'closed' as
far as being able to know what's going on in there ;-) and i'm not sure
i'm quite skilled enough to play too much with those binary-readers... i
could do something wrong and break things...
That's my 'quirk of the month' session done :-) I hear the sighs of
relief!
As an aside, I've been considering putting in bits for manuals/tutorials
along the way - my use of GRASS is more-or-less from
