[GRASS-user] working on a mounted external disk
Hello, has anybody ever had problems accessing a gisdbase located on an external disk ? In my case, I can open a grass session in a distant location/mapset : grass65 /mnt/path_to_my_disk/my_location/topo From within this place, everything works well, OK. If I start grass from my home directory and try to reproject data from the distant directory : grass65 /home/vincent/my_gisdbase/my_location/my_mapset r.proj input=dem50 location=/mnt/path_to_my_disk/my_location mapset=topo output=dem50 Then an error occurs : ERREUR :Mapset topo in input location /mnt/path_to_my_disk/my_location/ - not found whereas the disk is properly mounted there and accessible... Any idea on why grass seems not to see the mounted directory ? Thank you Vincent ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] working on a mounted external disk
On 08/04/09 10:31, Vincent Bain wrote: Hello, has anybody ever had problems accessing a gisdbase located on an external disk ? In my case, I can open a grass session in a distant location/mapset : grass65 /mnt/path_to_my_disk/my_location/topo From within this place, everything works well, OK. If I start grass from my home directory and try to reproject data from the distant directory : grass65 /home/vincent/my_gisdbase/my_location/my_mapset r.proj input=dem50 location=/mnt/path_to_my_disk/my_location mapset=topo output=dem50 Then an error occurs : ERREUR :Mapset topo in input location /mnt/path_to_my_disk/my_location/ - not found whereas the disk is properly mounted there and accessible... Any idea on why grass seems not to see the mounted directory ? You need to use the dbase= option of r.proj to direct it to another database. In your case it is looking for a location called /mnt/path_to_my_disk/my_location/ in your current gisdatabase. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] launching a gui
Dear Experts Could somebody explain to me how to launch the Grass GUI ? I am running Grass62 under Cygwin. When I type tcltkgrass , the response that I get is always something like [1] 3528 bash: tcltkgrass: command not found What am I doing wrong? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] working on a mounted external disk
On 08/04/09 11:51, Vincent Bain wrote: Thank you Moritz, I tried to specify the path to the target database location this way : r.proj input=dem50 location=/mnt/path_to_my_disk/my_location mapset=topo dbase=/mnt/path_to_my_disk/ output=dem50 this should be: r.proj input=dem50 location=my_location mapset=topo dbase=/mnt/path_to_my_disk/ output=dem50 If you give it location=/mnt/path_to_my_disk/my_location it thinks that the location is called /mnt/path_to_my_disk/my_location as the error message indicates: ERREUR :Mapset topo in input location /mnt/path_to_my_disk/my_location/ - not found Moritz unfortunately it still returns the same error. Well, maybe I should change the title of this post, because I notice now that the problem is the same with resident paths on the machine (apparently nothing to deal with mounted directory). Vincent Le mercredi 08 avril 2009 à 10:48 +0200, Moritz Lennert a écrit : You need to use the dbase= option of r.proj to direct it to another database. In your case it is looking for a location called /mnt/path_to_my_disk/my_location/ in your current gisdatabase. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] launching a gui
On 08/04/09 13:33, Chris Heys wrote: Dear Experts Could somebody explain to me how to launch the Grass GUI ? I am running Grass62 under Cygwin. When I type tcltkgrass , the response that I get is always something like [1] 3528 bash: tcltkgrass: command not found What am I doing wrong? tcltkgrass is deprecated, use 'gis.m'. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Moving GISBASE box2box
On 08/04/09 13:58, Cassiel wrote: Hi you all, I am having troubles in moving my GISBASE dir between two linux boxes. At grass startup, once I select the gisbase dir, every mapset I try to access results in this error message this is not a valid mapset. I would guess that this might be a permissions issue. How did you move your dirs ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Moving GISBASE box2box
2009/4/8 Moritz Lennert mlenn...@club.worldonline.be On 08/04/09 13:58, Cassiel wrote: Hi you all, I am having troubles in moving my GISBASE dir between two linux boxes. At grass startup, once I select the gisbase dir, every mapset I try to access results in this error message this is not a valid mapset. I would guess that this might be a permissions issue. How did you move your dirs ? Moritz I moved using a removable hd. Permissions are ok... I also tried a chmod -R 777 (desperate isn't it?) but didn't worked. Could it be a locale mismatch? regards r ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] working on a mounted external disk
OH, that simple ! shame on me :-( Sorry for being so dazed... A detail concerning r.proj in that context of distinct gisdbases : if the distant location has the same name as the current (i.e. in my example both locations are called 'my_location'), then the command returns a comprehensible error : ERROR: You have to use a different location for input than the current It would be nice if the dbase argument was checked /before/ the location argument, in order to admit same location names, not necessarily meaning that we project data in an identical projection system. Vincent Le mercredi 08 avril 2009 à 13:41 +0200, Moritz Lennert a écrit : this should be: r.proj input=dem50 location=my_location mapset=topo dbase=/mnt/path_to_my_disk/ output=dem50 If you give it location=/mnt/path_to_my_disk/my_location it thinks that the location is called /mnt/path_to_my_disk/my_location as the error message indicates: ERREUR :Mapset topo in input location /mnt/path_to_my_disk/my_location/ - not found Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] working on a mounted external disk
Thank you Moritz, I tried to specify the path to the target database location this way : r.proj input=dem50 location=/mnt/path_to_my_disk/my_location mapset=topo dbase=/mnt/path_to_my_disk/ output=dem50 unfortunately it still returns the same error. Well, maybe I should change the title of this post, because I notice now that the problem is the same with resident paths on the machine (apparently nothing to deal with mounted directory). Vincent Le mercredi 08 avril 2009 à 10:48 +0200, Moritz Lennert a écrit : You need to use the dbase= option of r.proj to direct it to another database. In your case it is looking for a location called /mnt/path_to_my_disk/my_location/ in your current gisdatabase. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Moving GISBASE box2box
Hi you all, I am having troubles in moving my GISBASE dir between two linux boxes. At grass startup, once I select the gisbase dir, every mapset I try to access results in this error message this is not a valid mapset. Creating a new location works. Is there any trick to fix this issue? I guess it's something trivial but I don't know what it can be, moreover I did it before and everything worked fine. GRASS 6.3.0.1 from gfoss repos (grass_6.3.0.1~gfossit20090217-1_amd64.deb) The linux boxes are up with debian lenny amd64 (though the one I am migrating to is a quad core intel xeon and the other one a dual core amd64) regards r ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] displaying many thematic maps from one vector dataset
On 08/04/09 02:23, Vishal Mehta wrote: Regarding the segmentation faults: I switched to a different machine to do all this latter work. I havent tried the new scripts on the original machine (my laptop). Both are running 6.4svn. Weird. I can confirm segfaults in 6.5svn (I suppose that this is what you mean by 6.4svn, i.e. the current 6.x development branch), but only when using d.mon, not when using direct rendering (GRASS_RENDER_IMMEDIATE=TRUE). Since I wrote this code on the base of the grass7 tree, and then ported it back to 6.x, it is quite probable that I forgot some adaptations needed for d.mons... (CC'ing to Glynn for any pointer on where I should look). Could you try with direct rendering on the machine where it segfaulted with d.mons ? Regarding legends, I found that I had to play around way too much to get the legend right. Could you tell me which were the major parts that needed adjustment from you ? As you want to use the same legend for all maps, it is obviously easier to create one legend file by hand and to call d.graph on that in each cycle of the loop. However, I tweaked the source code (grass7 for now) just very slightly (changing text size and taking into account the case where the min value of the data is above the lowest break (or the max value below the highest break - see 2010-2030 max values in the example) and then ran the following script (using direct rendering as monitors don't exist anymore): export GRASS_FONT=Vera export GRASS_PNG_READ=TRUE yr=2010 while [ $yr -lt 2105 ] ; do echo yr is $yr export GRASS_PNGFILE=pc$yr.png d.thematic.area map=CA column=pc$yr breaks=20,40,60\ colors=cyan,yellow,red,blue leg=legfile d.text -b text=$yr Population at=50,90 size=4 d.graph in=legfile if [ $yr -eq 2090 ] then yr=$((yr+10)) else yr=$((yr+5)) fi done You can see the resulting animated gif here: http://geog-pc40.ulb.ac.be/popCA.gif I don't find the legends too bad, but obviously it is difficult to create a one-size-fits-all solution for legends. I spent some time trying to find the right algorithm, but it is still very far from perfect. One thing I should probably add is a parameter for the placement of the legend in screen percents. Another is a detection mechanism to see how many significant decimals to keep (There should be some examples, notably in Hamish'es work, I just need to look at those...). I don't know, however, whether the d.graph solution is the best, so feedback is very welcome on that. And even then, there's a yellow color that is not on the legend file, that shows up in the display anyway. Could you show an example of that ? Thank you for your feedback so far. We really have to identify the cause of those segfaults... Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] working on a mounted external disk
On 08/04/09 14:13, Vincent Bain wrote: It would be nice if the dbase argument was checked /before/ the location argument, in order to admit same location names, not necessarily meaning that we project data in an identical projection system. Try this (untested): Index: raster/r.proj/main.c === --- raster/r.proj/main.c(révision 36609) +++ raster/r.proj/main.c(copie de travail) @@ -219,7 +219,7 @@ setname = imapset-answer ? imapset-answer : G_store(G_mapset()); -if (strcmp(inlocation-answer, G_location()) == 0) +if (strcmp(inlocation-answer, G_location()) == 0 (!indbase-answer || strcmp(indbase-answer, G_gisdbase()) == 0)) G_fatal_error(_(You have to use a different location for input than the current)); G_get_window(outcellhd); Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] working on a mounted external disk
In raster/r.proj/main.c, line 208 I wrote : if (strcmp(inlocation-answer, G_location()) == 0 !indbase-answer || strcmp(indbase-answer, G_gisdbase())== 0)) G_fatal_error(_(Input and output locations can not be the same)); G_get_window(outcellhd); Then compiled and installed again, but the error remains, and what's more puzzling to me is that the message string is different from what I have in the modified file (You have to use a different location for input than the current)... What have I done wrong ? VB Le mercredi 08 avril 2009 à 14:32 +0200, Moritz Lennert a écrit : On 08/04/09 14:13, Vincent Bain wrote: It would be nice if the dbase argument was checked /before/ the location argument, in order to admit same location names, not necessarily meaning that we project data in an identical projection system. Try this (untested): Index: raster/r.proj/main.c === --- raster/r.proj/main.c (révision 36609) +++ raster/r.proj/main.c (copie de travail) @@ -219,7 +219,7 @@ setname = imapset-answer ? imapset-answer : G_store(G_mapset()); -if (strcmp(inlocation-answer, G_location()) == 0) +if (strcmp(inlocation-answer, G_location()) == 0 (!indbase-answer || strcmp(indbase-answer, G_gisdbase()) == 0)) G_fatal_error(_(You have to use a different location for input than the current)); G_get_window(outcellhd); Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Help with i.pca output
Dear William, switch to grass6_devel if you can. For all of your questions you'll find plenty of stuff to read in the archive [1]. Perhaps best place is the wiki-page where we attempt to collect information about PCA [2] -- check here directly :-). Kind regards, Nikos --- [1] http://n2.nabble.com/forum/Search.jtp?query=pca +nikossort=datelocal=yforum=1837860 [2] http://grass.osgeo.org/wiki/Principal_Component_Analysis ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] working on a mounted external disk
On 08/04/09 15:37, Vincent Bain wrote: In raster/r.proj/main.c, line 208 I wrote : if (strcmp(inlocation-answer, G_location()) == 0 !indbase-answer || strcmp(indbase-answer, G_gisdbase())== 0)) G_fatal_error(_(Input and output locations can not be the same)); G_get_window(outcellhd); Then compiled and installed again, but the error remains, and what's more puzzling to me is that the message string is different from what I have in the modified file (You have to use a different location for input than the current)... What have I done wrong ? This sounds like you modified and compiled a grass6 version, but are running grass7. Apparently a fix for this issue done by Markus a long time ago in grass6, but this got lost, when (IIUC) r.proj.seg became r.proj in grass7. Markus' fix was this: -if (strcmp(inlocation-answer, G_location()) == 0) - G_fatal_error(_(You have to use a different location for input - than the current)); + if (!indbase-answer strcmp(inlocation-answer, G_location()) == 0) + G_fatal_error(_(Input and output locations can not be the same)); but this was never applied to r.proj.seg. His fix does not take into account the case where someone gives a value for dbase, but this is the same as the current location. Probably highly improbable, but not impossible, so my fix is a bit more complete... So, to make this story short: - You have to figure out which version of grass you are working with. - In grass6.3+ this shouldn't be an issue, but it is in grass6.2 and before and again in grass7. - The message You have to use a different location for input than the current is in grass6.2 and before and in grass7, but was changed to Input and output locations can not be the same in grass6.3+. I'll apply my fix (but using Markus' wording) grass7, but I'll leave devel6 alone as the Markus' fix should handle most cases. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] working on a mounted external disk
Apparently a fix for this issue done by Markus a long time ago in grass6, but this got lost, when (IIUC) r.proj.seg became r.proj in grass7. OK, I've got it : I made changes to raster/r.proj/main.c instead of raster/r.proj.seg/main.c Now it works fine with the right main.c file ! Thank you, Vincent ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Moving GISBASE box2box
Check the WINDOW file, and the owner... Maxi Cassiel wrote: 2009/4/8 Moritz Lennert mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be On 08/04/09 13:58, Cassiel wrote: Hi you all, I am having troubles in moving my GISBASE dir between two linux boxes. At grass startup, once I select the gisbase dir, every mapset I try to access results in this error message this is not a valid mapset. I would guess that this might be a permissions issue. How did you move your dirs ? Moritz I moved using a removable hd. Permissions are ok... I also tried a chmod -R 777 (desperate isn't it?) but didn't worked. Could it be a locale mismatch? regards r ___ 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] displaying many thematic maps from one vector dataset
Hi Moritz, Regarding legends with d.graph, these are the main issues where I found I needed to do too much of trial and error, some of which I think could probably be avoided/improved in a future version... 1. the legend ends up with some strange additions beyond just the range of data: like what are those numbers after each range e.g. in the example below where did | 0 and | 5 come from? It would be nice to not have this automatically displayed. 60 - 80 | 0 80-100 | 5 2. there could be a flag on d.graph, which allows the output to have a minbreak and maxbreak option, so that for cases like the one we are discussing, the legend does not keep changing based on different data ranges. 3. size and position Here, I wanted to get a legend file separately, and save a legend png. To do this I had to play with the size and other parameters extensively to make the symbols and associated text match up. It would be great to be able to do the following with some flags, for the case where the legend alone is displayed: (i) set the overall size of the display within which the legend will be displayed (ii) set the position of the legend within the display with options like lowerleft, upperright, center, etc (iii) set the size of the legend as a fraction/percentage of the display. (iv) make the background transparent (or not) such that the above settings 'automatically' set up the symbol and corresponding text all properly lined up.. I am aware that if I was just better at this I could do it quickly enough..but the above functionality would make it easier for less-than-expert people like myself, who try to use open-source as much as possible despite the handicap of having been groomed on Windows... I will write back when i've had a chance to look up the segfaults on my laptop.. And oh, the mismatch of color between display and legend was entirely my fault - i was displaying with one set of colors but had tweaked the legend file separately with a different set of colors.. Thanks for all your help, Vishal On Wed, Apr 8, 2009 at 4:58 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 08/04/09 02:23, Vishal Mehta wrote: Regarding the segmentation faults: I switched to a different machine to do all this latter work. I havent tried the new scripts on the original machine (my laptop). Both are running 6.4svn. Weird. I can confirm segfaults in 6.5svn (I suppose that this is what you mean by 6.4svn, i.e. the current 6.x development branch), but only when using d.mon, not when using direct rendering (GRASS_RENDER_IMMEDIATE=TRUE). Since I wrote this code on the base of the grass7 tree, and then ported it back to 6.x, it is quite probable that I forgot some adaptations needed for d.mons... (CC'ing to Glynn for any pointer on where I should look). Could you try with direct rendering on the machine where it segfaulted with d.mons ? Regarding legends, I found that I had to play around way too much to get the legend right. Could you tell me which were the major parts that needed adjustment from you ? As you want to use the same legend for all maps, it is obviously easier to create one legend file by hand and to call d.graph on that in each cycle of the loop. However, I tweaked the source code (grass7 for now) just very slightly (changing text size and taking into account the case where the min value of the data is above the lowest break (or the max value below the highest break - see 2010-2030 max values in the example) and then ran the following script (using direct rendering as monitors don't exist anymore): export GRASS_FONT=Vera export GRASS_PNG_READ=TRUE yr=2010 while [ $yr -lt 2105 ] ; do echo yr is $yr export GRASS_PNGFILE=pc$yr.png d.thematic.area map=CA column=pc$yr breaks=20,40,60\ colors=cyan,yellow,red,blue leg=legfile d.text -b text=$yr Population at=50,90 size=4 d.graph in=legfile if [ $yr -eq 2090 ] then yr=$((yr+10)) else yr=$((yr+5)) fi done You can see the resulting animated gif here: http://geog-pc40.ulb.ac.be/popCA.gif I don't find the legends too bad, but obviously it is difficult to create a one-size-fits-all solution for legends. I spent some time trying to find the right algorithm, but it is still very far from perfect. One thing I should probably add is a parameter for the placement of the legend in screen percents. Another is a detection mechanism to see how many significant decimals to keep (There should be some examples, notably in Hamish'es work, I just need to look at those...). I don't know, however, whether the d.graph solution is the best, so feedback is very welcome on that. And even then, there's a yellow color that is not on the legend file, that shows up in the display anyway. Could you show an example of that ? Thank you for your feedback so far. We really have to identify the cause of those segfaults... Moritz -- Vishal K. Mehta, PhD Scientist
Re: [GRASS-user] displaying many thematic maps from one vector dataset
And one more for the wish list on legends: - a flag to strip off decimal places if the data happens to be float.. On Wed, Apr 8, 2009 at 9:48 AM, Vishal Mehta vishalm1...@gmail.com wrote: Hi Moritz, Regarding legends with d.graph, these are the main issues where I found I needed to do too much of trial and error, some of which I think could probably be avoided/improved in a future version... 1. the legend ends up with some strange additions beyond just the range of data: like what are those numbers after each range e.g. in the example below where did | 0 and | 5 come from? It would be nice to not have this automatically displayed. 60 - 80 | 0 80-100 | 5 2. there could be a flag on d.graph, which allows the output to have a minbreak and maxbreak option, so that for cases like the one we are discussing, the legend does not keep changing based on different data ranges. 3. size and position Here, I wanted to get a legend file separately, and save a legend png. To do this I had to play with the size and other parameters extensively to make the symbols and associated text match up. It would be great to be able to do the following with some flags, for the case where the legend alone is displayed: (i) set the overall size of the display within which the legend will be displayed (ii) set the position of the legend within the display with options like lowerleft, upperright, center, etc (iii) set the size of the legend as a fraction/percentage of the display. (iv) make the background transparent (or not) such that the above settings 'automatically' set up the symbol and corresponding text all properly lined up.. I am aware that if I was just better at this I could do it quickly enough..but the above functionality would make it easier for less-than-expert people like myself, who try to use open-source as much as possible despite the handicap of having been groomed on Windows... I will write back when i've had a chance to look up the segfaults on my laptop.. And oh, the mismatch of color between display and legend was entirely my fault - i was displaying with one set of colors but had tweaked the legend file separately with a different set of colors.. Thanks for all your help, Vishal On Wed, Apr 8, 2009 at 4:58 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 08/04/09 02:23, Vishal Mehta wrote: Regarding the segmentation faults: I switched to a different machine to do all this latter work. I havent tried the new scripts on the original machine (my laptop). Both are running 6.4svn. Weird. I can confirm segfaults in 6.5svn (I suppose that this is what you mean by 6.4svn, i.e. the current 6.x development branch), but only when using d.mon, not when using direct rendering (GRASS_RENDER_IMMEDIATE=TRUE). Since I wrote this code on the base of the grass7 tree, and then ported it back to 6.x, it is quite probable that I forgot some adaptations needed for d.mons... (CC'ing to Glynn for any pointer on where I should look). Could you try with direct rendering on the machine where it segfaulted with d.mons ? Regarding legends, I found that I had to play around way too much to get the legend right. Could you tell me which were the major parts that needed adjustment from you ? As you want to use the same legend for all maps, it is obviously easier to create one legend file by hand and to call d.graph on that in each cycle of the loop. However, I tweaked the source code (grass7 for now) just very slightly (changing text size and taking into account the case where the min value of the data is above the lowest break (or the max value below the highest break - see 2010-2030 max values in the example) and then ran the following script (using direct rendering as monitors don't exist anymore): export GRASS_FONT=Vera export GRASS_PNG_READ=TRUE yr=2010 while [ $yr -lt 2105 ] ; do echo yr is $yr export GRASS_PNGFILE=pc$yr.png d.thematic.area map=CA column=pc$yr breaks=20,40,60\ colors=cyan,yellow,red,blue leg=legfile d.text -b text=$yr Population at=50,90 size=4 d.graph in=legfile if [ $yr -eq 2090 ] then yr=$((yr+10)) else yr=$((yr+5)) fi done You can see the resulting animated gif here: http://geog-pc40.ulb.ac.be/popCA.gif I don't find the legends too bad, but obviously it is difficult to create a one-size-fits-all solution for legends. I spent some time trying to find the right algorithm, but it is still very far from perfect. One thing I should probably add is a parameter for the placement of the legend in screen percents. Another is a detection mechanism to see how many significant decimals to keep (There should be some examples, notably in Hamish'es work, I just need to look at those...). I don't know, however, whether the d.graph solution is the best, so feedback is very welcome on that. And even then, there's a yellow color that is not on the legend
Re: [GRASS-user] Help with i.pca output
Markus: It is available from GRASS Addons SVN: http://grass.osgeo.org/wiki/GRASS_AddOns#m.eigensystem Since it is increasingly used, maybe we need to add it to 6.5/7? +1 Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] general v.digit help? Enduring thanks
Hello, Thanks to anyone who can help. I usually work with raster data, but I've been venturing into the world of vector data because I can make good masks. What I've been doing is using r.contour to extract a shoreline on a beach, and then I've been digitizing an almost rectangular area using v.digit where one side of the rectangle is the extracted shoreline. Then I convert that area to a mask and perform raster operations from there. r.digit is a poor sub for v.digit with a derived shoreline in my case. So, some of the literature seems a little sparse, so I've been using a lot of trial and error unfortunately. Here is my work flow, I open the contour line in v.digit and connect the ends to make a boundary. I add a centroid to make it an official area. I make sure all of the nodes are green. I don't really know why, it just works that way. So that would be my first question, what is the difference between green and red nodes/vertices? I do this by using the split lines tool and essentially cutting out red nodes and reconnecting the lines until they turn green. Again, I'm having a little bit of trouble interpreting what yellow lines mean when using the split line tool. Then, (once again because it just seems to work, sometimes) I use v.type input=vec1 output=vec2 type=line,boundary followed by v.to.rast input=vec2 output=vec3 use=val type=point,line,area layer=1 value=1 rows=4096. And sometimes it works and sometimes it doesn't, but I don't know why. Also, when converting between vector types using v.type, I notice the output will say something like: Number of nodes : 12 Number of primitives: 16 Number of points: 0 Number of lines : 0 Number of boundaries: 15 Number of centroids : 1 Number of areas : 0 Number of isles : 0 Number of incorrect boundaries : 15 Number of centroids outside area : 1 I have difficulties trouble shooting the problem from this output. So, I've tried to read man pages and work my way through tutorials to no avail. If anyone knows the answer to these questions, or knows of a tutorial or resource that can help me, I will be eternally grateful. Thanks, Eric -- View this message in context: http://n2.nabble.com/general-v.digit-help--Enduring-thanks-tp2608889p2608889.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
