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 : > > 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
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] 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 : > > 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
[GRASS-user] troubles retaining color tables upon export
hello - I am working with a 1 band greyscale raster, FCELL. In GRASS, I have opened it and assigned it a specific color table. However, if I simulate sending this file to someone else (export it, then re-import it), the color table that existed upon export no longer exists. I have tried exporting the color table as a txt file in GRASS before the export, but that does not seem to do anything. I have exported/imported as both geotif and .img - both have the same issue. While the color table can be re-made, it is a complex classfication system that I would rather retain. Any ideas what I can look into? Might be that I am missing something, I am still recent to GRASS. thanks! -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/troubles-retaining-color-tables-upon-export-tp6915254p6915254.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
[GRASS-user] troubles retaining color tables when upon export
hello - I am working with a 1 band greyscale raster, FCELL. In GRASS, I have opened it and assigned it a specific color table. However, if I simulate sending this file to someone else (export it, then re-import it), the color table that existed upon export no longer exists. I have tried exporting the color table as a txt file in GRASS before the export, but that does not seem to do anything. I have exported/imported as both geotif and .img - both have the same issue. While the color table can be re-made, it is a complex classfication system that I would rather retain. Any ideas what I can look into? Might be that I am missing something, I am still recent to GRASS. thanks! ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Using r.reclass.area with an NDVI map
Greetings I have an NDVI map but it's not continuous: i mean, I have a few patches with values and areas in my raster map without values. I want to apply r.reclass.area in order to eliminate patches with less than 2ha. My question is: shall I convert NDVI pixels to 1 (creating a mask of valid pixels) or can I just use as it is (with values ranging from -1 to 1)? Because if r.reclass.area uses r.clump 2 pixels with different NDVI values are not "categorized toghetter. Right? THanks Antonio __ Information from ESET NOD32 Antivirus, version of virus signature database 6561 (20111020) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] resampling question
On Thursday, October 20, 2011, Kirk Wythers wrote: > On Oct 20, 2011, at 9:22 AM, Dylan Beaudette wrote: > > > The neat thing about GRASS and other OSS, you can always take a peak at the > > source code. From my basic understanding of C, I don't think that there is > > anything here that would accommodate ties-- so the result of > > mode(4,4,4,4,5,5,5,5) would probably be 4 -- as it comes first. This is the > > behavior in R when using something like which.max(table(x)). > > Thanks for the reply Dylan. As I read through the code you pasted, it looks to me that as the variable 'values' gets counted, then in the case of a tie, such as this 2 x 2 matrix > > _ > | 4 | 5 | > _ > | 4 | 5 | > _ > > would yield a mode result of 4 with the logic that the tie goes to the smallest value in sorted list of values? In this case... 4 4 5 5 = mode of 4, where as a sorted list such as 1 2 3 4 would yield a mode of 1? > > Is that right? > That is my interpretation of the code. Perhaps Glynn or someone else more familiar with the raster library can comment further. Also- why not try a simple experiment. You can create fake raster data with a text editor and read it in via r.in.ascii. put the following in a text file called 'fake.rast' : -- north: 4 south: 0 east: 4 west: 0 rows: 4 cols: 4 4 4 4 4 4 4 4 4 5 5 5 5 5 5 5 5 # import r.in.ascii in=fake.raster out=f g.region rast=f -p # check d.mon wx0 d.rast.num f # aggregate g.region res=4 -p r.resamp.stats --o in=f out=f.mode method=mode # check d.erase d.rast.num f.mode ... which shows that our interpretation is correct. An interesting side-note: # region is still set to a resolution of 4x4 units = 1 cell # NN-resampling of the original data gives us 5... r.out.ascii --q -h f 5 # aggregated (mode) gives us 4... r.out.ascii --q -h f.mode 4 Fun! -- Dylan E. Beaudette USDA-NRCS Soil Scientist California Soil Resource Lab http://casoilresource.lawr.ucdavis.edu/ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] resampling question
Kirk Wythers wrote: > the tie goes to the > smallest value in sorted list of values? In this case... 4 4 5 5 = > mode of 4, where as a sorted list such as 1 2 3 4 would yield a mode of > 1? > > Is that right? Yes. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] resampling question
On Oct 20, 2011, at 9:22 AM, Dylan Beaudette wrote: > The neat thing about GRASS and other OSS, you can always take a peak at the > source code. From my basic understanding of C, I don't think that there is > anything here that would accommodate ties-- so the result of > mode(4,4,4,4,5,5,5,5) would probably be 4 -- as it comes first. This is the > behavior in R when using something like which.max(table(x)). Thanks for the reply Dylan. As I read through the code you pasted, it looks to me that as the variable 'values' gets counted, then in the case of a tie, such as this 2 x 2 matrix _ | 4 | 5 | _ | 4 | 5 | _ would yield a mode result of 4 with the logic that the tie goes to the smallest value in sorted list of values? In this case... 4 4 5 5 = mode of 4, where as a sorted list such as 1 2 3 4 would yield a mode of 1? Is that right? ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] resampling question
On Thursday, October 20, 2011, Kirk Wythers wrote:
> I am curious how the r.resamp.stats function (when used to aggregate with
the "method=mode" switch) handles an equal number of different cell scores?
For example, lets say that aggregating 16 cells to 1cell yields 8 cells with a
value of 4, and 8 cells with a value of 5. In this case what would
r.resamp.stats report as the mode? And what method would it use to determine
that value?
The neat thing about GRASS and other OSS, you can always take a peak at the
source code. From my basic understanding of C, I don't think that there is
anything here that would accommodate ties-- so the result of
mode(4,4,4,4,5,5,5,5) would probably be 4 -- as it comes first. This is the
behavior in R when using something like which.max(table(x)).
Here is what I found in: lib/stats/c_mode.c
--
void c_mode(DCELL * result, DCELL * values, int n, const void *closure)
{
DCELL mode;
int max;
DCELL prev;
int count;
int i;
n = sort_cell(values, n);
max = 0;
count = 0;
for (i = 0; i < n; i++) {
if (max == 0 || values[i] != prev) {
prev = values[i];
count = 0;
}
count++;
if (count > max) {
max = count;
mode = prev;
}
}
if (max == 0)
Rast_set_d_null_value(result, 1);
else
*result = mode;
}
--
--
Dylan E. Beaudette
USDA-NRCS Soil Scientist
California Soil Resource Lab
http://casoilresource.lawr.ucdavis.edu/
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] resampling question
I am curious how the r.resamp.stats function (when used to aggregate with the "method=mode" switch) handles an equal number of different cell scores? For example, lets say that aggregating 16 cells to 1cell yields 8 cells with a value of 4, and 8 cells with a value of 5. In this case what would r.resamp.stats report as the mode? And what method would it use to determine that value? Thanks in advance.___ 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
Hi, 2011/10/20 Shane Litherland : > 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"? BTW, you can also click on icon in the toolbar. Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] map query tool in 6.4.2RC1 ???
Hi, 2011/10/20 Shane Litherland : > 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... right, querying options has been simplified. For vector maps it's shown wxGUI dialog with results, querying raster maps is still redirected to command output window. > 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 -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] d.vect colour wheel not active wxGUI 6.4.2RC1
Hi, 2011/10/20 Shane Litherland : > 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 -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Smoothing unclosed contour
Hi list, Help me please! I have a set of unclosed contours, which are created from raster cropped by the mask. After smoothing with "v.generalize method=boyle look_ahead=5" I have obtained smooth, but duplicated contours. How can I fix it? If it necessary I can send a screenshot. -- Best regards, Dmitriy ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Landsat SLC-Off gap filling
(back to an old discussion) On Mon, Oct 20, 2008 at 8:11 AM, Ned Horning wrote: > Hi - Is there anyone out there who has worked on an algorithm to fill gaps in > Landsat ETM+ SLC-Off data? Now that the Landsat 7 archive is freely available > I am looking for an open source approach to fill the gaps in the SLC-Off data > and GRASS seems like a good option. I'm most interested in multi-date > approaches > but at this stage I'm looking at single-date approaches as well. Any ideas? This is an interesting reading: http://landsat.usgs.gov/documents/SLC_Gap_Fill_Methodology.pdf Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Getting Gridded Population of the World (GPW) data into GRASS
On Thu, Oct 20, 2011 at 3:43 AM, Ben Madin wrote: > G'day all, > > I have tried to search for this, but the only chain I found included some > off-list component, and I'm not sure what actually happened. > > I have not been able to import GPW data into GRASS successfully. I can confirm that, unfortunately. > I am downloading data from http://sedac.ciesin.columbia.edu/gpw/global.jsp > > I have downloaded the .bil, the ascii grid and the ESRI GRID data types for > population count and population density ... > for example > >> r.in.gdal -o >> input=/Users/benmadin/Spatial/raster/gl_gpwfe_pcount_10_bil_25/glp10ag.bil >> output=glp10ag > WARNING: Over-riding projection check > 100% > r.in.gdal complete. Raster map created. Now you first have to set the computational region to the map, otherwise r.* will not compute reasonable results (unless you want to work on a subregion). But: gdalinfo glp15ag ... GEOGCS["WGS 84", ... Upper Left (-180.000, 85.000) (180d 0'0.00"W, 85d 0'0.00"N) Lower Left (-180.000, -58.000) (180d 0'0.00"W, 58d 0'0.00"S) Upper Right ( 180.000, 85.000) (180d 0'0.00"E, 85d 0'0.00"N) Lower Right ( 180.000, -58.000) (180d 0'0.00"E, 58d 0'0.00"S) Center ( 0.000, 13.500) ( 0d 0'0.00"E, 13d30'0.00"N) Band 1 Block=8640x1 Type=Float32, ColorInterp=Gray this looks ok to me. However, neighter GRASS 6 nor 7 can import it correctly, some epsilon issue: # note that -l doesn't change anything: r.in.gdal glp15ag out=population_2015 -l r.info population_2015 ... | Rows: 3432 | | Columns: 8640 | | Total Cells: 29652480 | |Projection: Latitude-Longitude | |N:85NS:58S Res: 0:02:30 | |E: 179:59:59.99WW: 180W Res: 0 | | Range of data:min = 0 max = 1870454 | ... g.region rast=population_2015 -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: a=6378137 es=0.00669438 north: 85N south: 58S west: 180W east: 179:59:59.99W<<--- !!! nsres: 0:02:30 ewres: 0 rows: 3432 cols: 8640 cells: 29652480 d.rast.leg population_2015 ERROR: region for current mapset is invalid line 9: run "g.region" ERROR: region for current mapset is invalid line 9: run "g.region" We need to add something more in lib/gis/adj_cellhd.c in function G_adjust_Cell_head(). Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
