Re: [GRASS-user] Display thematic vector map - WinGRASS 6.3 (Vista)
Michael Barton wrote: The problem is that winGRASS does not support X or PNG monitors. GRASS does support PNG monitors in winGRASS (or the TclTk canvas wouldn't work). WinGRASS supports direct rendering through the PNG and other drivers. It doesn't support any form of monitor, including PNG. You can't use d.mon, d.save, d.frame, or d.font. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Finding Nearest Intersection (point) on Road Network
On 05/01/09 20:44, Ryan Rosario wrote: Moritz Lennert wrote: Thanks for the reply. Sorry for the delay...out of town. On Wed, December 24, 2008 05:55, Ryan R. Rosario wrote: GRASS simply returns the same point back, since the closest node to A is A. In grass6.4 you have the dmin option to avoid that. That is good to know. Apparently it is not in the tcl/tk GUI. That is odd, as the GUI should automatically be created from the module (and dmin is in 6.4 - just checked). What does v.distance --help give you ? Are you sure you are using 6.4 ? From when ? The feature was added mid-August. [...] Note that currently the v.net.* modules in GRASS do not work very well, and hardly at all once the network becomes too big. Rewriting these modules to be more scalable and reliable would be a nice Google Summer of Code project for next year. That would be excellent. Now that I know this, I might take a look at the code, as what I am trying to do relates to my dissertation. As Markus said, this seems to be mostly related to the cache bug (http://trac.osgeo.org/grass/ticket/224), but there have also been discussions about underlying algorithms (see the dglib vs dgtables in the threads referenced in the bug report). I guess the best thing would be to fix the cache bug to then finally be able to test the networking modules in more real life heavyload applications than possible now. I know of quite a few people who would willingly switch over to GRASS if the networking stuff was top of the line. But it might be interesting to look at some recent literature on network /graph issues. I'm no expert, but have the feeling that a lot has been going on there... Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.centroids and cat values
On 03/01/09 17:29, Micha Silver wrote: I'd like to better understand the way cat values are assigned to centroids when using v.centroids. I came across a problem when I created a new vector and digitized boundaries (v.digit -n) . Before beginning to digitize, I added some columns to the attribute table within v.digit, so that on completing each feature, I could fill in the values for that feature. I had one column for the label, and one column, GRASSRGB for coloring. I did not bother to digitize centroids, but rather, after completing the boundaries, and exiting v.digit, I ran v.centroids. I was surprised to see that the cat value assigned to each centroid *does not correspond* to the cat values of the surrounding boundary. This has the unfortunate effect of showing incorrect labels when running d.vect with the display=shape,attr option, since the attribute is taken from centroid, and not from its surrounding boundary. In addition, when coloring with the d.vect -a option, the boundaries get the correct color from the GRASSRGB column, but the fill color is also wrong, since the fill color is again taken from the attributes of the centroid. And the centroid, with a different cat value, goes to the wrong row of the attached attribute table. This behavior is certainly undesirable, unless I'm missing something basic?? My workaround was to delete all centroids, then go back into v.digit, and digitize each centroid, while being careful to choose it's cat value manually, and set each one to the correct cat of the surrounding boundary by choosing Manual Entry instead of Next not used mode for categories. So, is there some way to create centroids, such that they automatically get the same cat value as the boundary? Normally, the best practice is to digitize boundaries without category values (unless you specifically want information concerning the boundary, not the area it contains) and then digitize the centroids with category values and relevant attribute data. In your case, the easiest way out would seem to be v.distance, i.e.: - v.centroid in=YourBoundaries out=YourMap - v.db.addcol YourMap column=b_cat int - v.distance from=YourMap from_type=centroid to=YourMap to_type=boundary upload=cat column=b_cat #this should find the nearest boundary for each centroid - v.category in=YourMap out=YourMap2 option=del type=boundary - v.reclass in=YourMap2 out=YourMap3 type=centroid column=b_cat - db.copy from_table=YourMap2 to_table=YourMap3 - db.dropcol YourMap3 col=b_cat - Now you should have a YourMap3 with centroids that are linked to the correct attributes. If this is the case, you can safely do the next step: - g.remove vect=YourMap,YourMap2 This should be quite easy to make into a script module, or maybe extend v.centroids to optionally do this for you. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Help with reprojection
On 02/01/09 20:04, Alex Bernstein wrote: Finally, when I try reprojection I get Input raster map is outside current region error: Use v.in.region and v.proj first. See the Notes section in the manual page of r.proj. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Display thematic vector map - WinGRASS 6.3 (Vista)
Thanks for the correction. WinGRASS supports PNG output, not a monitor. d.vect.thematic was rewritten to use direct rendering through PNG, so it should work on Windows. Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Jan 6, 2009, at 6:05 AM, Glynn Clements wrote: Michael Barton wrote: The problem is that winGRASS does not support X or PNG monitors. GRASS does support PNG monitors in winGRASS (or the TclTk canvas wouldn't work). WinGRASS supports direct rendering through the PNG and other drivers. It doesn't support any form of monitor, including PNG. You can't use d.mon, d.save, d.frame, or d.font. -- Glynn Clements gl...@gclements.plus.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.centroids and cat values
On Jan 6, 2009, at 10:00 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Tue, 06 Jan 2009 17:19:58 +0100 From: Moritz Lennert mlenn...@club.worldonline.be Subject: Re: [GRASS-user] v.centroids and cat values To: Micha Silver mi...@arava.co.il Cc: GRASS user list grass-user@lists.osgeo.org Message-ID: 496384ae.4000...@club.worldonline.be Content-Type: text/plain; charset=UTF-8; format=flowed On 03/01/09 17:29, Micha Silver wrote: I'd like to better understand the way cat values are assigned to centroids when using v.centroids. I came across a problem when I created a new vector and digitized boundaries (v.digit -n) . Before beginning to digitize, I added some columns to the attribute table within v.digit, so that on completing each feature, I could fill in the values for that feature. I had one column for the label, and one column, GRASSRGB for coloring. I did not bother to digitize centroids, but rather, after completing the boundaries, and exiting v.digit, I ran v.centroids. I was surprised to see that the cat value assigned to each centroid *does not correspond* to the cat values of the surrounding boundary. This has the unfortunate effect of showing incorrect labels when running d.vect with the display=shape,attr option, since the attribute is taken from centroid, and not from its surrounding boundary. In addition, when coloring with the d.vect -a option, the boundaries get the correct color from the GRASSRGB column, but the fill color is also wrong, since the fill color is again taken from the attributes of the centroid. And the centroid, with a different cat value, goes to the wrong row of the attached attribute table. This behavior is certainly undesirable, unless I'm missing something basic?? My workaround was to delete all centroids, then go back into v.digit, and digitize each centroid, while being careful to choose it's cat value manually, and set each one to the correct cat of the surrounding boundary by choosing Manual Entry instead of Next not used mode for categories. So, is there some way to create centroids, such that they automatically get the same cat value as the boundary? Normally, the best practice is to digitize boundaries without category values (unless you specifically want information concerning the boundary, not the area it contains) and then digitize the centroids with category values and relevant attribute data. In your case, the easiest way out would seem to be v.distance, i.e.: - v.centroid in=YourBoundaries out=YourMap - v.db.addcol YourMap column=b_cat int - v.distance from=YourMap from_type=centroid to=YourMap to_type=boundary upload=cat column=b_cat #this should find the nearest boundary for each centroid - v.category in=YourMap out=YourMap2 option=del type=boundary - v.reclass in=YourMap2 out=YourMap3 type=centroid column=b_cat - db.copy from_table=YourMap2 to_table=YourMap3 - db.dropcol YourMap3 col=b_cat - Now you should have a YourMap3 with centroids that are linked to the correct attributes. If this is the case, you can safely do the next step: - g.remove vect=YourMap,YourMap2 This should be quite easy to make into a script module, or maybe extend v.centroids to optionally do this for you. I still think that when an area is created, a centroid should automatically be placed at some standard and logical place for each area. Area centroids should be an integral component of area topology, not a separate point that must be manually placed and manipulated. Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Display thematic vector map - WinGRASS 6.3 (Vista)
On 06/01/09 17:51, Michael Barton wrote: Thanks for the correction. WinGRASS supports PNG output, not a monitor. d.vect.thematic was rewritten to use direct rendering through PNG, so it should work on Windows. This was done in 6.4, so it is not available in winGRASS, yet, which is based on 6.3. Just replacing the script doesn't work, either as it use the fs= parameter of v.db.connect which wasn't introduced until 6.4. So, another strident call for the a 6.4 winGRASS. Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass' build problem with libtoolize
I am using Mandriva 2009.0 and have no problems. But libtool isn't used/usable for GRASS, probably that's the source of the problem. We need to know more specifically what you plan to do. Here is my spec file - http://pastebin.mandriva.com/5551 It is based on the latest available on mandriva's contrib, I've not done much modifications except cleaning the rust and add the correct dependencies for the new gui. The spec file in the tarball you mentioned is an older version. I want to submit a newer grass' package since I need it to submit qgis 1.0 and also because the actual one on cooker's svn is nearly one year old, conflicts over libavcodec due to wrong include's path, etc. The libtool thingy is set to be used by default in mandriva's rpmbuild. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.centroids and cat values
Right! Michael On Jan 6, 2009, at 11:06 AM, Patton, Eric wrote: I still think that when an area is created, a centroid should automatically be placed at some standard and logical place for each area. Area centroids should be an integral component of area topology, not a separate point that must be manually placed and manipulated. Michael I agree. If the user just wants to digitize a boundary without areas, then they could just digitize linework and snap the vertices, couldn't they? ~ Eric. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.centroids and cat values
GRASS modules that create area type features should already be generating centroids and adding categories to them automatically, shouldn't they? As far as I am aware, e.g., v.in.ogr does this, so we are talking mainly about adding centroid generation to the interactive digitizing tool, aren't we? The GRASS Vector lib API should have a function that finds a good centroid automatically. Or am I misled here (guess I am getting a bit confused myself, now)? To be quite honest, I have always been a bit bewildered about the choice of using a centroid point for linking attributes to area features. Could anyone here fill me in on what advantage that has? Cheers (and a good New Year, btw.), Ben Michael Barton wrote: On Jan 6, 2009, at 10:00 AM, grass-user-requ...@lists.osgeo.org wrote: Date: Tue, 06 Jan 2009 17:19:58 +0100 From: Moritz Lennert mlenn...@club.worldonline.be Subject: Re: [GRASS-user] v.centroids and cat values To: Micha Silver mi...@arava.co.il Cc: GRASS user list grass-user@lists.osgeo.org Message-ID: 496384ae.4000...@club.worldonline.be Content-Type: text/plain; charset=UTF-8; format=flowed On 03/01/09 17:29, Micha Silver wrote: I'd like to better understand the way cat values are assigned to centroids when using v.centroids. I came across a problem when I created a new vector and digitized boundaries (v.digit -n) . Before beginning to digitize, I added some columns to the attribute table within v.digit, so that on completing each feature, I could fill in the values for that feature. I had one column for the label, and one column, GRASSRGB for coloring. I did not bother to digitize centroids, but rather, after completing the boundaries, and exiting v.digit, I ran v.centroids. I was surprised to see that the cat value assigned to each centroid *does not correspond* to the cat values of the surrounding boundary. This has the unfortunate effect of showing incorrect labels when running d.vect with the display=shape,attr option, since the attribute is taken from centroid, and not from its surrounding boundary. In addition, when coloring with the d.vect -a option, the boundaries get the correct color from the GRASSRGB column, but the fill color is also wrong, since the fill color is again taken from the attributes of the centroid. And the centroid, with a different cat value, goes to the wrong row of the attached attribute table. This behavior is certainly undesirable, unless I'm missing something basic?? My workaround was to delete all centroids, then go back into v.digit, and digitize each centroid, while being careful to choose it's cat value manually, and set each one to the correct cat of the surrounding boundary by choosing Manual Entry instead of Next not used mode for categories. So, is there some way to create centroids, such that they automatically get the same cat value as the boundary? Normally, the best practice is to digitize boundaries without category values (unless you specifically want information concerning the boundary, not the area it contains) and then digitize the centroids with category values and relevant attribute data. In your case, the easiest way out would seem to be v.distance, i.e.: - v.centroid in=YourBoundaries out=YourMap - v.db.addcol YourMap column=b_cat int - v.distance from=YourMap from_type=centroid to=YourMap to_type=boundary upload=cat column=b_cat #this should find the nearest boundary for each centroid - v.category in=YourMap out=YourMap2 option=del type=boundary - v.reclass in=YourMap2 out=YourMap3 type=centroid column=b_cat - db.copy from_table=YourMap2 to_table=YourMap3 - db.dropcol YourMap3 col=b_cat - Now you should have a YourMap3 with centroids that are linked to the correct attributes. If this is the case, you can safely do the next step: - g.remove vect=YourMap,YourMap2 This should be quite easy to make into a script module, or maybe extend v.centroids to optionally do this for you. I still think that when an area is created, a centroid should automatically be placed at some standard and logical place for each area. Area centroids should be an integral component of area topology, not a separate point that must be manually placed and manipulated. Michael ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Benjamin Ducke Senior Applications Support and Development Officer Oxford Archaeological Unit Limited Janus House Osney Mead OX2 0ES Oxford, U.K. Tel.: ++44 (0)1865 263 800 benjamin.du...@oxfordarch.co.uk -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] interpolating with a covariate - v.vol.rst
Hi, For some crazy reason I was under the impression that it is possible to do interpolation with a covariate with v.vol.rst. Are there any examples on how to parameterize this module, when a 2D surface is requested, rather than a 3D volume. I noticed the 'cellinp' argument for a cross-section, but this is not quite what I am after. I am looking to do something very similar to interpolation of rainfall data, taking into account the orographic effect of terrain. I would be happy to add an example or two to the man pages. Cheers, Dylan -- Dylan Beaudette Soil Resource Laboratory http://casoilresource.lawr.ucdavis.edu/ University of California at Davis 530.754.7341 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass' build problem with libtoolize
Markus Neteler wrote: Found a workaround: replace %configure with ./configure and libtoolize is no longer used. Two fixes are necessary, then it compiles (running here now). I'll send you the SPEC file. Markus Thank you for the tips ! Older version yes, but with updates to 2009.x yes but actually in cooker you can't even install it because of a dependency's conflict so a new grass rpm is really needed here. Thanks again ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] interpolating with a covariate - v.vol.rst
Dylan, On Tue, Jan 6, 2009 at 10:01 PM, Dylan Beaudette debeaude...@ucdavis.edu wrote: Hi, For some crazy reason I was under the impression that it is possible to do interpolation with a covariate with v.vol.rst. Are there any examples on how to parameterize this module, when a 2D surface is requested, rather than a 3D volume. I noticed the 'cellinp' argument for a cross-section, but this is not quite what I am after. I am looking to do something very similar to interpolation of rainfall data, taking into account the orographic effect of terrain. This was my main business (say, of our cluster) over the last months :) You can do that. I am using the elevation model as auxiliary variable: # something like this: v.vol.rst in=vectpoints cellinp=dem wcolumn=pointval cellout=rst2d cellout delivers the 2D map, extracted from the volume along the dem map. Hope this helps Markus PS: If you are interested, I have a patch of v.vol.rst which reduces the computational time to roughly 30%. Done by a friend of mine (mathematician) who removed unneeded function calls from the code. Needs more testing... ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] mosaicing classified images
Hi, I have a series of classified rasters from different landsat images (various dates). I want to moasic/stitch them to a one raster. The problem is there are subtle differences in the classified output. Any advise in mosaicing them? -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
