Re: [GRASS-dev] Community meeting plans
Thanks,
Luca,
I'll be
sure to keep you updated on the progress. Both during and
after the meeting.
On 17/04/2023 23:19, Luca Delucchi
wrote:
Il gio 6 apr 2023, 11:34
Micha Silver <tsvi...@gmail.com>
ha scritto:
Hello all:
Hi Micha
I intend to participate in the
upcoming community meeting in Prague. I hope to
work on a GRASS addon to implement the OPTRAM
model [1] for determining soil moisture from
Sentinel 2 imagery. Has anyone done anything along
this line? If you have an interest in such an
addon, let me know.
I could be interested but no idea about how much
time I'll have during code sprint
Best regards,
Micha
Best
Luca
--
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Community meeting plans
Hello all: I intend to participate in the upcoming community meeting in Prague. I hope to work on a GRASS addon to implement the OPTRAM model [1] for determining soil moisture from Sentinel 2 imagery. Has anyone done anything along this line? If you have an interest in such an addon, let me know. Best regards, Micha [1] Sadeghi, Morteza, Ebrahim Babaeian, Markus Tuller, and Scott B. Jones. “The Optical Trapezoid Model: A Novel Approach to Remote Sensing of Soil Moisture Applied to Sentinel-2 and Landsat-8 Observations.” Remote Sensing of Environment 198 (September 1, 2017): 52–68. https://doi.org/10.1016/j.rse.2017.05.041. -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] compare a DCELL and FCELL question
> | > | > | > | Comments: > | > |r.stats.zonal --overwrite base="str_r" cover="cat1_acc_riv" method="\ > | > |min" output="cat1_minacc" > | > | > | > > ++ > (Sun Jan 24 04:46:50 2021) Command finished (0 sec) > > Thanks > Ming > > > Micha Silver 于2021年1月24日周日 上午3:29写道： >> >> Is there some reason that you expect the rasters to be the same? Maybe >> begin by posting the outputs of `r.info` for both rasters, and what >> command you used to compare them? >> >> On Sun, Jan 24, 2021 at 6:13 AM ming han wrote: >> > >> > Hi Everyone >> > >> > I tried to compare if grids in two rasters are the same, one raster is >> > FCELL and another raster is DCELL. I got different result when I int both >> > raster first before comparing them; and when I float() both raster first >> > before I comparing them >> > >> > Is there any reason for this? >> > >> > Thanks >> > Ming >> > ___ >> > grass-user mailing list >> > grass-u...@lists.osgeo.org >> > https://lists.osgeo.org/mailman/listinfo/grass-user >> >> >> >> -- >> Micha Silver >> Ben Gurion Univ >> Sde-Boker Remote Sensing Lab >> cell: +972 (52) 3665918 -- Micha Silver Ben Gurion Univ Sde-Boker Remote Sensing Lab cell: +972 (52) 3665918 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] compare a DCELL and FCELL question
Is there some reason that you expect the rasters to be the same? Maybe begin by posting the outputs of `r.info` for both rasters, and what command you used to compare them? On Sun, Jan 24, 2021 at 6:13 AM ming han wrote: > > Hi Everyone > > I tried to compare if grids in two rasters are the same, one raster is > FCELL and another raster is DCELL. I got different result when I int both > raster first before comparing them; and when I float() both raster first > before I comparing them > > Is there any reason for this? > > Thanks > Ming > ___ > grass-user mailing list > grass-u...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user -- Micha Silver Ben Gurion Univ Sde-Boker Remote Sensing Lab cell: +972 (52) 3665918 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] r.covar vs layerStats in R
On 11/19/18 12:41 PM, Markus Neteler wrote: On Sun, Nov 18, 2018 at 10:32 PM Micha Silver wrote: I am preparing a correlation matrix for 7 raster layers. The results using the r.covar module are different from the R layerStats function. I suspect this is due to handling of null cells. The R function has a parameter to remove NA cells, but the GRASS module, I think, just loops over all cells, including no value. Can anyone confirm that GRASS does not deal with null cells, and that this would cause the difference in correlation results? Here how r.covar treats NULL cells: https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.covar/main.c#L93 Looking at lines 94 - 100, it seems that the count variable is incremented even when a cell value is null. Please correct me if I'm wrong. Since count is used in the calculation of covariance and correlation (lines 118-132) shouldn't it contain the number only of cells with value? Thanks Markus -- Micha Silver Ben Gurion Univ. Sde Boker, Remote Sensing Lab cell: +972-523-665918 ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] Results of GRASS-GIS' PSC-2016 Election
Congrads to the members of the new PSC. The community as a whole can rest assured that further development of GRASS will stay on track. -- Original Message -- Subject: [GRASS-user] Results of GRASS-GIS' PSC-2016 Election Date: Mon, 29 Aug 2016 17:26:23 +0200 To: Grass-psc, Grass-user, Grass-dev From: Nikos Alexandris Dear GRASS GIS community, the new Project Steering Committee is composed by the following nine members: 1 Markus Neteler62 2 Helena Mitasova 53 3 Martin Landa 52 4 Anna Petrasova45 5 Moritz Lennert41 6 Margherita Di Leo 39 7 Michael Barton35 8 Peter Löwe33 9 Vaclav Petras 31 Congratulations! A warm Thank You for their candidacy, and dedication to the project, goes to: - Helmut Kurdnovsky 30 - Yann Chemin 29 - Veronica Andreo 28 - Micha Silver 20 To keep track and for the sake of completeness, all relevant communications will be published in one wiki-page (in trac). Details * The election URL: https://vote.heliosvoting.org/helios/e/GRASS-GIS-PSC-2016 * Election Fingerprint: es9DDU1oPIxtyV9DE/cl402ctbm5PwaFhmLrruzsAJU Remember, the entire election process was/is encrypted. The CRO, being the administrator of this "private" election, could only verify which of the invited members did vote. That and nothing more. *Ballots* Helios' voting system features "Audited Ballots". More information at: https://vote.heliosvoting.org/helios/elections/397c5ce0-67c2-11e6-8e87-3e719e3f8c36/audited-ballots/. *Election tally* Even more, anyone should be able to verify the election tally at "Helios Election Verifier": https://vote.heliosvoting.org/verifier/verify.html?election_url=/helios/elections/397c5ce0-67c2-11e6-8e87-3e719e3f8c36. *Trustee* The trustee for this election was: Trustee #1: Helios Voting Administrator Public Key Fingerprint: 0mYM9DB3TVWlbURGBXiMnCb12Vsf4OJoFXBODOPl9os Trustees are responsible for decrypting the election result. Each trustee generates a keypair and submits the public portion to Helios. When it's time to decrypt, each trustee needs to provide their secret key. For this election, however, the automcatically selected, by the system, trustee was selected and no other persons where involved in this process. *Broken Links?* If any of the links do not lead anywhere, please contact the CRO publicly, in example by responding to this post. Voters who casted a ballot, will receive another message sent via Helios' directly. For more, there is a FAQ: https://vote.heliosvoting.org/faq Final words As a CRO, I tried to serve this role as best possible. Looking back on the last few weeks, and having various off-list discussions, while at Bonn last week, I identify and reflect on mistakes and things I could have done better. In time, I will try to collect some of the experiences and compose a wiki-page (in trac). However, I'd like to stress the following: I feel and think that I did not insist as much as I should, to assist in profiling better the candidates. There is this important question, asked by Micha Silver end of July (see https://lists.osgeo.org/pipermail/grass-user/2016-July/074529.html), "what we should expect from PSC members?" Some of the candidates went a bit deeper in presenting themselves. Others were less lengthy in their writing. All good. However, I propose herewith, for the next PSC election, the following: set as a requirement, for each candidate, to answer this very question as being asked from the community: "What should the community expect from your PSC membership?". Thank you. GRASS-GIS' CRO As Nikos, thank you to the previous PSC for accepting me as the CRO this year. ___ grass-user mailing list grass-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] PSC election 2016
Hi Nikos: -- Original Message -- Subject: [GRASS-user] PSC election 2016 Date: Thu, 21 Jul 2016 14:16:44 +0200 To: Grass-announce, Grass-psc, Grass-user, Grass-dev From: Nikos Alexandris Dear GRASS-GIS community, Herewith the official schedule for the PSC election 2016 is announced. - Starting on this Sunday (24. 07. 2016), the process ends on Monday the 29th of August 2016. - The new committee will be formed by nine (9) members. This is in accordance with the current PSC chair and the original planning when constituting the PSC. Thanks,for taking the initiative. Perhaps you could add some details (or link to details) of what we should expect from PSC members? Micha ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-user] data catalog question
Hi
Anna:
I can think of at least two configuration policies that
could (should?) be different on a single user
installation vs. a multi user system: Both mapset
access, and installation of extensions -
SIngle user: unlimited access to all mapsets as you
mention in the data catalog, and installation of
extensions in the user's .grassrc directory (as is now
the case)
Multi-user setup: maintain the current "access to owner
only" policy, *but* allow installation of extensions to
some system directory so everyone can use all
extensions. Installing extensions with sudo doesn't work
unless root has a full GRASSDBASE directory setup. How can
that be overcome so that the GRASS admin can easily
install extensions system-wide?
Thanks,
Micha
-- Original Message --
Subject: [GRASS-user] data catalog question
Date: Sat, 9 Apr 2016 23:00:47 -0400
To: Grass-dev, Grass User List
From: Anna Petrášová
On 10/04/2016 06:00, Anna Petrášová
wrote:
Hi,
I was wondering what is the opinion about the new data catalog (in
trunk), specifically, whether users should be able to modify (copy,
rename, delete) maps from other mapsets and locations than the current
ones. I find it very useful to edit any mapsets, but it goes against
the traditional GRASS approach. I have this (edit anything behavior)
implemented locally, but wanted to know before committing if people
agree with that.
Thanks,
Anna
___
grass-user mailing list
grass-u...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
This mail was received via Mail-SeCure System.
Micha Silver
Arava Drainage Authority
+972-523-665918
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compiling 7.0 on MacOS 10.9
, works fine.
** command like g.region, r.mask and others do not lunch
a gui dialog when type their name in the grass shell.
Massimo.
On Apr 2, 2014, at 9:48 AM, Micha Silver <mi...@arava.co.il>
wrote:
Has anyone compiled GRASS 7.0 on MacOS
Mavricks? Any tips?
Thanks,
--
Micha Silver
GIS Consulting
052-3665918
http://www.surfaces.co.il
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
This mail was received via Mail-SeCure System.
=
--
Micha Silver
GIS Consulting
052-3665918
http://www.surfaces.co.il
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] compiling 7.0 on MacOS 10.9
Has anyone compiled GRASS 7.0 on MacOS Mavricks? Any tips? Thanks, -- Micha Silver GIS Consulting 052-3665918 http://www.surfaces.co.il ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] Re: Importing of raster data doesn't seem to work through GUI
On 12/07/2010 04:08 PM, Martin Landa wrote: Hi, 2010/12/6 Micha Silver: I think I have an idea why the GUI isn't working. I noticed in your first post that the LandSAT tif files are named with CAPS in the filename extension, i.e. 171146051_05122001402_B10.TIF. It looks to me that the GUI ignores files name *.TIF and only "sees" *.tif. this bug hopefully fixed by r44554. Great. Thanks, Martin. Martin -- Micha Silver Arava Development Co. +972-52-3665918 http://www.surfaces.co.il ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] Re: Importing of raster data doesn't seem to work through GUI
On 06/12/2010 13:37, Chethan S. wrote: Unfortunately, that does not work for me. As you said the *.tif files appear grayed out in that particular folder. But the next outcome is not the one you get. Also after a recent update of GRASS 6.4.1 SVN there is no option "Bulk Import of Raster data". Its only "import raster data". I select directory option there. For using the individual file import option like before I used "Command Dialog" option as shown below. I should also mention that I use GRASS 6.4.0 version from Ubuntu repository at my college but again face the same problem. http://osgeo-org.1803224.n2.nabble.com/file/n5807453/Selection_022.png Regards, Chethan S. I think I have an idea why the GUI isn't working. I noticed in your first post that the LandSAT tif files are named with CAPS in the filename extension, i.e. 171146051_05122001402_B10.TIF. It looks to me that the GUI ignores files name *.TIF and only "sees" *.tif. You can do a bulk rename of all the files (from the command line...) with for f in *.TIF; do mv $f `basename $f .TIF`.tif; done Then open the GUI and check if those files are added to the import list. Regards, Micha -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS-user] v.db.join script
Moritz Lennert wrote: On 13/10/10 22:23, Micha Silver wrote: One line from the v.db.join script uses grep and cut to get the column names and the next line gets the column types like so: db.describe -c bike_rides2 | grep '^Column' | cut -d ':' -f 3 INTEGER CHARACTER INTEGER CHARACTER CHARACTER CHARACTER CHARACTER So the column size is actually ignored. Next, in the script the above output is used by v.db.addcol to create the new columns in the joined vector. So all new character columns are created as a single char and the actual length is never used. Questions: Is the db.describe output the same for all db drivers? Any suggestions how to fix this as a script? Why not use an SQL join, i.e. something like the following ? 1) CREATE TABLE temp AS (SELECT * FROM $maptable JOIN $otable ON $column=$ocolumn) 2) rename table $maptable to something else 3) rename table temp to $maptable 4) if this works, remove the original $maptable Interesting. So your suggestion is to run the above sql commands thru db.execute to create a new attribute table for an existing vector? Not tested, but might be a more elegant solution ? Moritz This mail was received via Mail-SeCure System. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] v.db.join script
On 10/12/2010 12:01 PM, Jon Eiriksson wrote: Hi, I have a truncation problem with v.db.join. This has been raised before - ([GRASS-user] Re: grass v.db.join Gary Nobles Fri, 12 Mar 2010 11:11:26 -0800) - but I have not seen a solution. I have tried my own data, the spearfish60 example data, and the example in Neteler and Mitasova's book. The new data columns are apparently defined as 1 character long, and the data become truncated accordingly, much against my intention. I use mysql. I can see why this is happening. But I'm not sure what the correct solution might be. v.db.join is a wrapper around db.describe and v.db.addcol. When I query an sqlite database connection here's what the output looks like: db.describe -c bike_rides2 ncols: 8 nrows: 17 Column 1: cat:INTEGER:20 Column 2: name:CHARACTER:80 Column 3: number:INTEGER:20 Column 4: comment:CHARACTER:80 Column 5: descriptio:CHARACTER:80 Column 6: source:CHARACTER:80 Column 7: url:CHARACTER:80 The output format is obviously: "Column num:column name:column type:column size". One line from the v.db.join script uses grep and cut to get the column names and the next line gets the column types like so: db.describe -c bike_rides2 | grep '^Column' | cut -d ':' -f 3 INTEGER CHARACTER INTEGER CHARACTER CHARACTER CHARACTER CHARACTER So the column size is actually ignored. Next, in the script the above output is used by v.db.addcol to create the new columns in the joined vector. So all new character columns are created as a single char and the actual length is never used. Questions: Is the db.describe output the same for all db drivers? Any suggestions how to fix this as a script? Or better, just convert to python? Thanks, Micha -- Micha Silver Arava Development Co. +972-52-3665918 http://www.surfaces.co.il ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [Qgis-developer] Re: [GRASS-dev] new GRASS 6.4 modules
On 26/09/2010 09:31, Hamish wrote:
Micha wrote:
How about color coding the rows like the DebianGIS
"thermometer". (If this idea is acceptable, I'm willing to
do the wiki formatting.)
closer example, using {{templates}}, which may look slightly
familiar :-)
Great idea.
So I would need to create a wiki {{template}} with, i.e.
Present
Should be added
Should be removed (is this category really necessary??)
Not relevant
Not possible
??
--
Micha
http://wiki.osgeo.org/wiki/Live_GIS_Disc_Testing#Package_testing_matrix
http://wiki.osgeo.org/wiki/Template:Pass
http://wiki.osgeo.org/wiki/Template:Issues
http://wiki.osgeo.org/wiki/Template:Fail
Hamish
This mail was received via Mail-SeCure System.
--
Micha Silver
http://www.surfaces.co.il/
Arava Development Co. +972-52-3665918
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [Qgis-developer] Re: [GRASS-dev] new GRASS 6.4 modules
On 09/25/2010 06:33 PM, Paolo Cavallini wrote: Il 23/09/2010 07:32, Hamish ha scritto: http://www.qgis.org/wiki/Adding_New_Tools_to_the_GRASS_Toolbox see at the end of the page. to help I made a wiki table with all grass 6.4 modules: http://grass.osgeo.org/wiki/GRASS-QGIS_relevant_module_list Hi Paulo: Two questions about the table - Do you think it's necessary/desirable to have a separate column for each release of QGIS? How about color coding the rows like the DebianGIS "thermometer". (If this idea is acceptable, I'm willing to do the wiki formatting.) -- Micha -- Micha Silver Arava Development Co. +972-52-3665918 http://www.surfaces.co.il ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.sim.water options
I have two questions regarding r.sim.water. First, what are "walkers". How does the nwalk parameter affect the analysis? It seems that with a region larger than a few million cells, the module fails, regardless of the nwalk parameter. (I have a region of just over 8 M cells, and even with nwalk=1, it fails with ERROR: nwalk (701) > maxw (700)! ) But when I reduce the region to < 7M cells then the nwalk parameter helps, and the analysis succeeds. Next (asked on the grass-user list, but no response yet): Is there a way to create a surface flow model where the rainfall stops after a specified time, and the model continues to run, and creates depth and discharge rasters after the actual rainfall has stopped? i.e. in the case of a short thunderstorm, I want to try to predict the extent of a flash flood that rises, then subsides some time after the rain has ended. Thanks, Micha -- Micha Silver http://www.surfaces.co.il/ Arava Development Co. +972-52-3665918 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
