[GRASS-user] GRASS GIS Unable to load GDAL library
Hi everyone I installed the GRASS GIS and the QGIS at here [image: image.png] I use all default options and when I tried to use GRASS GIS,I got the following error. GRASS_INFO_ERROR(17904,1): Unable to load GDAL library GRASS_INFO_END(17904,1) Would you please let me know if you have any idea to solve this problem? Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] db.in.ogr permissionerror: [winerror 5] access is denied
Hi everyone I use GRASS within the OSGEO4W enviroments. All GRASS GIS function works perfectly. I can read and write in the grass location. But when I came to use '' db.in.ogr", I got the following error: "permission error: [winerror 5] access is denied" Is there anyway to fix this Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed identify inland watershed
Hi Micha I understand what you mean. But it requires another step to manually identify depressions from these pre-conditioned DEM. Cheers Ming Micha Silver 于2021年4月3日周六 下午12:43写道： > > On 4/2/21 5:37 PM, ming han wrote: > > Maybe I am the only one who has this demand. Following is just a > > recommendation to GRASS r.watershed function. > > Maybe it is worth having an option to avoid r.watershed overcome > > depressions. > > The reasons are 1) there are many hydrologically pre condition DEM > > data available globally, such as:HydroSHEDS, MERIT > > 2) the depression in these DEM are real > > depressions, overcome these depressions will make the entire drainage > > system > > > Regarding Hydrosheds, the documentation[1] in section 3.4 explains how > they overcame the problem of sinks. They performed a regular "fill > sinks" operation on areas that were SRTM artifacts. True natural > depressions were identified manually, then another manual procedure of > carving rivers was done to force flow thru these depressions and produce > hydrologically correct streams and basins. So pre-conditioning to > overcome depressions is not a magic bullet... > > > In my opinion, the best results are obtained when true depressions > (pits, salt playas or karst regions) are identified, and set to NULL in > the elevation raster. That will allow r.watershed to stop routing at > those locations, and produce correct stream and basin layers. > > > [1]https://hydrosheds.org/images/inpages/HydroSHEDS_TechDoc_v1_2.pdf > > > > incorrectly. > > > > I understand GRASS has other functions to solve this problem, but just > > a user recommendation. I use GRASS a lot. > > > > Thanks > > Ming > > > > ming han mailto:dustm...@gmail.com>> > > 于2021年3月30日周二 上午8:06写道： > > > > Got it, thanks everyone~ > > Ming > > > > Micha Silver mailto:tsvi...@gmail.com>> > > 于2021年3月29日周一 下午2:40写道： > > > > Hello: > > > > You might try `r.param.scale`, or even better `r.geomorphons` > > modules to > > identify geomorphology features, then filter out all pixels > > identified > > as pits. > > > > > > r.watershed is purposely designed to overcome depressions, and > > find flow > > routing thru these spots. So I don't think you can use that > > module to > > identify depressions. > > > > > > On 3/27/21 8:49 PM, ming han wrote: > > > Hi Everyone > > > > > > When I do watershed delineation using r.watershed for > > great salt > > > lake watershed. I found r.watershed always tried to assign > > an outlet > > > for a great salt lake, which does actually not exist because > > it is an > > > inland lake and the great salt lake has no watershed outlet > > at all. > > > > > > I noticed that there is a depression option. But is > > there any > > > way that r.watershed can automatically identify depressions > > while > > > defining flow accumulation and stream network? > > > > > > Thanks > > > Ming > > > > > > ___ > > > grass-user mailing list > > > grass-user@lists.osgeo.org <mailto:grass-user@lists.osgeo.org> > > > https://lists.osgeo.org/mailman/listinfo/grass-user > > <https://lists.osgeo.org/mailman/listinfo/grass-user> > > > > -- > > Micha Silver > > Ben Gurion Univ. > > Sde Boker, Remote Sensing Lab > > cell: +972-523-665918 > > > -- > Micha Silver > Ben Gurion Univ. > Sde Boker, Remote Sensing Lab > cell: +972-523-665918 > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed identify inland watershed
Maybe I am the only one who has this demand. Following is just a recommendation to GRASS r.watershed function. Maybe it is worth having an option to avoid r.watershed overcome depressions. The reasons are 1) there are many hydrologically pre condition DEM data available globally, such as:HydroSHEDS, MERIT 2) the depression in these DEM are real depressions, overcome these depressions will make the entire drainage system incorrectly. I understand GRASS has other functions to solve this problem, but just a user recommendation. I use GRASS a lot. Thanks Ming ming han 于2021年3月30日周二 上午8:06写道： > Got it, thanks everyone~ > Ming > > Micha Silver 于2021年3月29日周一 下午2:40写道： > >> Hello: >> >> You might try `r.param.scale`, or even better `r.geomorphons` modules to >> identify geomorphology features, then filter out all pixels identified >> as pits. >> >> >> r.watershed is purposely designed to overcome depressions, and find flow >> routing thru these spots. So I don't think you can use that module to >> identify depressions. >> >> >> On 3/27/21 8:49 PM, ming han wrote: >> > Hi Everyone >> > >> > When I do watershed delineation using r.watershed for great salt >> > lake watershed. I found r.watershed always tried to assign an outlet >> > for a great salt lake, which does actually not exist because it is an >> > inland lake and the great salt lake has no watershed outlet at all. >> > >> > I noticed that there is a depression option. But is there any >> > way that r.watershed can automatically identify depressions while >> > defining flow accumulation and stream network? >> > >> > Thanks >> > Ming >> > >> > ___ >> > grass-user mailing list >> > grass-user@lists.osgeo.org >> > https://lists.osgeo.org/mailman/listinfo/grass-user >> >> -- >> Micha Silver >> Ben Gurion Univ. >> Sde Boker, Remote Sensing Lab >> cell: +972-523-665918 >> >> ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed identify inland watershed
Got it, thanks everyone~ Ming Micha Silver 于2021年3月29日周一 下午2:40写道： > Hello: > > You might try `r.param.scale`, or even better `r.geomorphons` modules to > identify geomorphology features, then filter out all pixels identified > as pits. > > > r.watershed is purposely designed to overcome depressions, and find flow > routing thru these spots. So I don't think you can use that module to > identify depressions. > > > On 3/27/21 8:49 PM, ming han wrote: > > Hi Everyone > > > > When I do watershed delineation using r.watershed for great salt > > lake watershed. I found r.watershed always tried to assign an outlet > > for a great salt lake, which does actually not exist because it is an > > inland lake and the great salt lake has no watershed outlet at all. > > > > I noticed that there is a depression option. But is there any > > way that r.watershed can automatically identify depressions while > > defining flow accumulation and stream network? > > > > Thanks > > Ming > > > > ___ > > grass-user mailing list > > grass-user@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/grass-user > > -- > Micha Silver > Ben Gurion Univ. > Sde Boker, Remote Sensing Lab > cell: +972-523-665918 > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Dates when g.extension not working
Hi Everyone Are there any scheduled dates for g.extension not working? I will ask several people to install grass and some grass addons, just need to let them know when the g.extension won't work. Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.watershed identify inland watershed
Hi Everyone When I do watershed delineation using r.watershed for great salt lake watershed. I found r.watershed always tried to assign an outlet for a great salt lake, which does actually not exist because it is an inland lake and the great salt lake has no watershed outlet at all. I noticed that there is a depression option. But is there any way that r.watershed can automatically identify depressions while defining flow accumulation and stream network? Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.stats.zonal output raster type
Hi everyone I just notice that r.statistics is not in grass add on, how to install it? 于2021年1月24日周日 下午2:51写道： > Try with `r.statistics`. Unfortunately, there are a few modules with > similar functionality, yet they work on different raster data types. > > > Nikos > --- > > > > On 2021-01-24 21:25, ming han wrote: > > Hi everyone > > Is it possible to let r.stats.zonal output raster to be CELL? > > Thanks > Ming > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.stats.zonal output raster type
Got it, many thanks. 于2021年1月24日周日 下午2:51写道： > Try with `r.statistics`. Unfortunately, there are a few modules with > similar functionality, yet they work on different raster data types. > > > Nikos > --- > > > > On 2021-01-24 21:25, ming han wrote: > > Hi everyone > > Is it possible to let r.stats.zonal output raster to be CELL? > > Thanks > Ming > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.stats.zonal output raster type
Hi everyone Is it possible to let r.stats.zonal output raster to be CELL? Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] use grass within anaconda
Hi Everyone Is there a way to use grass within anaconda? Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] compare a DCELL and FCELL question
Hi Everyone Many thanks for your help. Is if(fabs(map_A - map_B) <= 1.0e-15, ... ) approach may increase the runtime compare to '==' way? Thanks Ming Markus Metz 于2021年1月24日周日 上午10:57写道： > Trying to answer the original question: with a DCELL map "cat1_acc_riv" > and a FCELL map "cat1_minacc", why is "float(cat1_acc_riv) == > float(cat1_minacc)" not equal to "int(cat1_acc_riv) == int(cat1_minacc)" ? > > int truncates to integer while float converts to single precision floating > point. E.g. with cat1_acc_riv = 1.1 and cat1_minacc = 1.9, > "float(cat1_acc_riv) == float(cat1_minacc)" becomes "1.1 == 1.9" whereas > "int(cat1_acc_riv) == int(cat1_minacc)" becomes "1 == 1", thus the results > are different. > > Another reason for possible differences is that float can only represent > max 7 decimal digits. E.g. float(194320567) becomes 194320560 but > int(194320567) preserves the value 194320567. > > Thus the safest is to cast everything to the type with the highest > precision. In this case with FCELL and DCELL, use "double(cat1_acc_riv) == > double(cat1_minacc)" or even better the suggestion of Markus N. > > Markus M > > > On Sun, Jan 24, 2021 at 3:51 PM ming han wrote: > > > > Hi Markus and Micha > > > > I am just trying to find grids have the same values in these two > rasters, I will try the threshold approach. > > > > Thanks > > Ming > > > > Markus Neteler 于2021年1月24日周日 上午6:58写道： > >> > >> Hi Ming, > >> > >> On Sun, Jan 24, 2021 at 10:49 AM ming han wrote: > >> > > >> > Hi Micha > >> > > >> > Many thanks for your reply. > >> > Here is the command I am using: > >> > > >> > if(float(cat1_acc_riv) == float(cat1_minacc), str_r, null()) > >> > > >> > The str_r is a CELL raster. the result is different when I > change it to: > >> >if(int(cat1_acc_riv) == int(cat1_minacc), str_r, null()) > >> > >> Note that numerical "equality" is better tested with a threshold test > >> against the map pixel difference. > >> As the threshold, we use GRASS_EPSILON which is defined as 1.0e-15. > >> > >> Hence the test needs to be implemented in a different way, i.e. by > >> using an epsilon. > >> Essentially something like this: > >> > >> if(fabs(map_A - map_B) <= 1.0e-15, ... ) > >> > >> In your case (untested): > >> r.mapcalc diffepsilon = if( abs( map_A - map_B) <= 1.0e-15, str_r , > null()) > >> > >> See related discussions here: [1], [2] and elsewhere. > >> > >> [1] Comment by Glynn: > https://trac.osgeo.org/grass/ticket/2854#comment:9 > >> [2] Comment by Glynn: > >> https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html > >> > >> Best, > >> Markus > > > > ___ > > grass-dev mailing list > > grass-...@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] compare a DCELL and FCELL question
Hi Markus and Micha I am just trying to find grids have the same values in these two rasters, I will try the threshold approach. Thanks Ming Markus Neteler 于2021年1月24日周日 上午6:58写道： > Hi Ming, > > On Sun, Jan 24, 2021 at 10:49 AM ming han wrote: > > > > Hi Micha > > > > Many thanks for your reply. > > Here is the command I am using: > > > > if(float(cat1_acc_riv) == float(cat1_minacc), str_r, null()) > > > > The str_r is a CELL raster. the result is different when I change > it to: > >if(int(cat1_acc_riv) == int(cat1_minacc), str_r, null()) > > Note that numerical "equality" is better tested with a threshold test > against the map pixel difference. > As the threshold, we use GRASS_EPSILON which is defined as 1.0e-15. > > Hence the test needs to be implemented in a different way, i.e. by > using an epsilon. > Essentially something like this: > > if(fabs(map_A - map_B) <= 1.0e-15, ... ) > > In your case (untested): > r.mapcalc diffepsilon = if( abs( map_A - map_B) <= 1.0e-15, str_r , null()) > > See related discussions here: [1], [2] and elsewhere. > > [1] Comment by Glynn: https://trac.osgeo.org/grass/ticket/2854#comment:9 > [2] Comment by Glynn: > https://lists.osgeo.org/pipermail/grass-user/2015-October/073200.html > > Best, > Markus > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] compare a DCELL and FCELL question
Hi Micha Many thanks for your reply. Here is the command I am using: if(float(cat1_acc_riv) == float(cat1_minacc), str_r, null()) The str_r is a CELL raster. the result is different when I change it to: if(int(cat1_acc_riv) == int(cat1_minacc), str_r, null()) Here is output of r.info for first DCELL raster ++ | Map: cat1_acc_riv@PERMANENT Date: Sat Jan 23 22:58:42 2021 | | Mapset: PERMANENT Login of Creator: m43han | | Location: main_working_location | | DataBase: C:\Users\m43han\Documents\Routing_Prod\Prod01\grassdb | | Title:cat1_acc_riv | | Timestamp: none | || | | | Type of Map: raster Number of Categories: 19432056 | | Data Type:DCELL | | Rows: 4239 | | Columns: 9254 | | Total Cells: 39227706 | |Projection: Latitude-Longitude | |N: 50:52:39NS: 40:16:48N Res: 0:00:09 | |E: 70:10:39WW: 93:18:45W Res: 0:00:09 | | Range of data:min = 250752 max = 19432056 | | | | Data Description: | |generated by r.mapcalc | | | | Comments: | |if(isnull(str_r), null(), acc) | | | ++ (Sun Jan 24 04:45:38 2021) Command finished (0 sec) Here is r.info output for second raster ++ | Map: cat1_minacc@PERMANENT Date: Sat Jan 23 22:58:48 2021 | | Mapset: PERMANENT Login of Creator: m43han | | Location: main_working_location | | DataBase: C:\Users\m43han\Documents\Routing_Prod\Prod01\grassdb | | Title:cat1_minacc | | Timestamp: none | || | | | Type of Map: raster Number of Categories: 0 | | Data Type:FCELL | | Rows: 4239 | | Columns: 9254 | | Total Cells: 39227706 | |Projection: Latitude-Longitude | |N: 50:52:39NS: 40:16:48N Res: 0:00:09 | |E: 70:10:39WW: 93:18:45W Res: 0:00:09 | | Range of data:min = 250752 max = 1.817303e+007 | | | | Data Description: | |generated by r.stats.zonal | | | | 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-user@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-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] compare a DCELL and FCELL question
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-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] can not add addon
Hi Everyone Hope this email find you well, Is there anyway to avoid this error? I am working in windows system. g.extension extension=r.clip operation=add WARNING: Extension already installed. Re-installing... Downloading precompiled GRASS Addons ... ERROR: Cannot open URL: http://wingrass.fsv.cvut.cz/grass78/x86_64/addons/grass-7.8.2/r.clip.zip (Thu Nov 26 08:25:58 2020) Command finished (3 sec) Cheers Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] Bugs in r.stream.extract
Hi Ken Many thanks for your reply. your time and effort are much appreciated. I use -a option to ensure positive flow accumulations and using SFD, but still got different results. The reason why needs to change flow direction is that the DEM imperfect, especially when there is a lot of lakes in the watershed. Without change flow direction, the lake will be divided into different subbasins. And the reason why I want to start from flow direction instead of DEM is that there are several hydrological pre-conditioned datasets, the flow direction in this dataset already adjusted for most of the lakes. Some personal suggestions I find a solution for my work, but based on this experience feels like divide functions like r.stream.extract into four functions might provide user more feasibility: such as a function that defines flow direction DEM, a function define flow accumulation from flow direction, a function define streams from flow accumulation and a function define subbasin based on flow direction and stream network. These are just personal suggestions. Cheers Ming Ken Mankoff 于2020年11月25日周三 下午6:01写道： > > On 2020-11-25 at 04:17 -08, ming han wrote... > > And another problem I got is that the flow accumulation I got from > > r.accumulate and r.watershed is different when r.accumulate using flow > > direction from r.watershed. Again is there anyway r.watershed supports > > using flow direction, so we can get the consistent result. > > There may be reasons for these differences? For example, if SFD v. MFD, or > the "-a" flag to r.watershed? > > > We need this when we need to adjust the flow direction from > > r.watershed or r.stream.extract. and then we need to determine new > > flow accumulation with an adjusted flow direction dataset. If the > > result is inconsistent, not sure what is the solution is. > > It isn't clear why you are adjusting the flow direction. Is this required? > > >> But, If I only want to use flow direction to drive streams, which > >> function I should use? > > https://grass.osgeo.org/grass78/manuals/r.water.outlet.html but this only > works for 1 outlet. > > -k. > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] Bugs in r.stream.extract
And another problem I got is that the flow accumulation I got from r.accumulate and r.watershed is different when r.accumulate using flow direction from r.watershed. Again is there anyway r.watershed supports using flow direction, so we can get the consistent result. We need this when we need to adjust the flow direction from r.watershed or r.stream.extract. and then we need to determine new flow accumulation with an adjusted flow direction dataset. If the result is inconsistent, not sure what is the solution is. Cheers Ming ming han 于2020年11月25日周三 上午6:38写道： > Hi Ken > >Many thanks for your reply, I think I made a mistake, the flow > accumulation I provided to r.stream.extract did not match the DEM I > provided in r.stream.extract. The streamline seems based on flow > accumulation derived from the provided DEM. > >But, If I only want to use flow direction to drive streams, which > function I should use? > >Is there any chance that r.stream.extract can use flow direction as > inputs without DEM? > > Thanks > Ming > > > Ken Mankoff 于2020年11月24日周二 上午7:07写道： > >> Hi Ming, >> >> On 2020-11-23 at 09:05 -08, ming han wrote... >> > Hope this email finds you well. I got a weird result when using >> > r.stream.extract, as shown in the following figure. The back grids is >> > the flow accumulation layer with a flow accumulation threshold larger >> > than 1000. while the blue line is the stream generated by >> > r.stream.extract. Why the stream from r.stream.extract did not follow >> > flow accumulation results? And how to fix this problem? >> >> Is there any chance you can share the raster that includes this region so >> I can examine it? And the exact command you ran? >> >> -k. >> >> ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-dev] Bugs in r.stream.extract
Hi Ken Many thanks for your reply, I think I made a mistake, the flow accumulation I provided to r.stream.extract did not match the DEM I provided in r.stream.extract. The streamline seems based on flow accumulation derived from the provided DEM. But, If I only want to use flow direction to drive streams, which function I should use? Is there any chance that r.stream.extract can use flow direction as inputs without DEM? Thanks Ming Ken Mankoff 于2020年11月24日周二 上午7:07写道： > Hi Ming, > > On 2020-11-23 at 09:05 -08, ming han wrote... > > Hope this email finds you well. I got a weird result when using > > r.stream.extract, as shown in the following figure. The back grids is > > the flow accumulation layer with a flow accumulation threshold larger > > than 1000. while the blue line is the stream generated by > > r.stream.extract. Why the stream from r.stream.extract did not follow > > flow accumulation results? And how to fix this problem? > > Is there any chance you can share the raster that includes this region so > I can examine it? And the exact command you ran? > > -k. > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Bugs in r.stream.extract
Hi Everyone Hope this email finds you well. I got a weird result when using r.stream.extract, as shown in the following figure. The back grids is the flow accumulation layer with a flow accumulation threshold larger than 1000. while the blue line is the stream generated by r.stream.extract. Why the stream from r.stream.extract did not follow flow accumulation results? And how to fix this problem? [image: image.png] Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass python problem
Hi Everyone
Thanks for your response, for some reason it works now.
Thanks
Ming
Micha Silver 于2020年11月17日周二 上午10:44写道：
>
> On 11/17/20 6:03 AM, ming han wrote:
>
> Hi Everyone
>
> Hope this email finds you well.
> I can run r.cross in console with following command:
> "r.cross -z --overwrite --quiet input=Connect_Lake@PERMANENT
> ,str_grass_r@PERMANENT output=test"
>
> But I got error by run r.cross in python with following command:
> grass.run_command('r.cross', input = ['str_grass_r@PERMANENT
> ','Connect_Lake@PERMANENT'],output = 'test', quiet = True)
>
> What is the correct format to use r.cross function in Python? and how
> to obtain the output table generated by r.cross?
>
>
> This worked fine for me also, using GRASS 7.8.4 in the nc_basin_spm
> LOCATION:
>
>
> In [2]: import grass.script as gscript
>
> In [3]: gscript.run_command("r.cross", input=["landuse@PERMANENT
> ","basins@PERMANENT"], output="lu_bas", overwrite=True)
> r.cross: STEP 1 ...
> 100%
> r.cross: STEP 2 ...
> r.cross: STEP 3 ...
> 100%
> Creating support files for ...
> 89 categories
> Out[3]: 0
>
>
> Just to be clear, you do not get a table output, rather a raster. In your
> case you should see a new raster "test".
>
>
>
> Thanks
> Ming
>
> ___
> grass-user mailing
> listgrass-user@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/grass-user
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] grass python problem
Hi Everyone
Hope this email finds you well.
I can run r.cross in console with following command:
"r.cross -z --overwrite --quiet input=Connect_Lake@PERMANENT
,str_grass_r@PERMANENT output=test"
But I got error by run r.cross in python with following command:
grass.run_command('r.cross', input = ['str_grass_r@PERMANENT
','Connect_Lake@PERMANENT'],output = 'test', quiet = True)
What is the correct format to use r.cross function in Python? and how
to obtain the output table generated by r.cross?
Thanks
Ming
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Watershed delineation result problem
Hi Rich Thanks for sharing, I see, I will continue with GRASS version I guess. Cheers Ming Rich Shepard 于2020年10月7日周三 下午1:42写道： > On Wed, 7 Oct 2020, ming han wrote: > > > Hope this email find you safe and healthy > > > > I tried watershed delineation with both ArcGIS and GRASS. but I got > > different results. > > > > I was using D8 flow direction method in both ArcGIS and GRASS. My study > > area is very flat. Is there any tool in GRASS will generate the same > result > > with ArcGIS > > Ming, > > I did wetland determinations and delineations for almost a decade but > dropped it when it became a commodity. I offer two points for your > consideration: > > 1) The ArcGIS may not be any more 'accurate' than the GRASS results. Never > having used the former I cannot comment on how they do this. > > 2) Of greater importance is that you can pick either one; it doesn't matter > in the real world. In 1994 I was the first environmental consultant > authorized by Oregon's Department of State Lands to use GPS receivers to > delineate wetland boundaries. They had insisted that only professional land > surveyors could do this and they set a 2cm accuracy standard. Really? > Wetland boundaries are transistion zones that can be several meters wide, > depending on topography, soils, and antecedent precipitation conditions > when > the boundary is flagged. A stream bank is an exception to this broad > transition area. When I made the case that there is no sharp line of > demarkation between wetland and upland they accepted my delineations. > > Of similar disconnect between engineering and natural ecosystems, I worked > for a brief time for a water management district in the 1980s. They decided > to digitize the 7.5 min (1:24000) topographic maps covering the District's > area and contracted with a company in India to do the work. The contract > specified that the digitized lines had to aline withine 1/2 the width of > roads and other boundaries on the maps. When I pointed out to my Division > Director that the maps themselves said "this map is accurate to +/- 24 > feet" > so they were trying to be more accurate than the maps themselves it was not > well received. :-) (That's one reason I left a government position.) > > Anyway, draw your boundary and in most cases you'll be within that > transition zone. > > HTH, > > Rich > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Watershed delineation result problem
Hi Everyone Hope this email find you safe and healthy I tried watershed delineation with both ArcGIS and GRASS. but I got different results. I was using D8 flow direction method in both ArcGIS and GRASS. My study area is very flat. Is there any tool in GRASS will generate the same result with ArcGIS Thanks Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Compile grass addon
Hi Everyone Hope this email finds you well. I can generate GRASS addon executable by commands in the following sections. But when I load it in GRASS, it reports the following error. at the sametime I can successfully load other GRASS executable like r.what "dyld: Library not loaded: @rpath/libgrass_gis.dylib Referenced from: /Applications/QGIS3.14.app/Contents/MacOS/grass/bin/r.stream.basins Reason: image not found Abort trap: 6" Thanks Ming -- gcc -g -O2 -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -I/Library/Frameworks/GDAL.framework/Versions/3.1/Headers -I/Library/Frameworks/GEOS.framework/Versions/3C/unix/include -DPACKAGE=\""grassmods"\" -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -DRELDIR=\"grass_addon/raster/r.stream.basins\" -o basins_fill.o -c basins_fill.c gcc -g -O2 -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -I/Library/Frameworks/GDAL.framework/Versions/3.1/Headers -I/Library/Frameworks/GEOS.framework/Versions/3C/unix/include -DPACKAGE=\""grassmods"\" -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -DRELDIR=\"grass_addon/raster/r.stream.basins\" -o basins_inputs.o -c basins_inputs.c gcc -g -O2 -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -I/Library/Frameworks/GDAL.framework/Versions/3.1/Headers -I/Library/Frameworks/GEOS.framework/Versions/3C/unix/include -DPACKAGE=\""grassmods"\" -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -DRELDIR=\"grass_addon/raster/r.stream.basins\" -o io.o -c io.c gcc -g -O2 -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -I/Library/Frameworks/GDAL.framework/Versions/3.1/Headers -I/Library/Frameworks/GEOS.framework/Versions/3C/unix/include -DPACKAGE=\""grassmods"\" -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -I/Applications/QGIS3.14.app/Contents/MacOS/grass/include -DRELDIR=\"grass_addon/raster/r.stream.basins\" -o main.o -c main.c gcc -L/Applications/QGIS3.14.app/Contents/MacOS/grass/lib -o /Applications/QGIS3.14.app/Contents/MacOS/grass/bin/r.stream.basins ./basins_fill.o ./basins_inputs.o ./io.o ./main.o-lgrass_gis.7.8 -lgrass_raster.7.8 -lgrass_segment.7.8 -lgrass_vector.7.8 -lgrass_dbmiclient.7.8 -lgrass_dbmibase.7.8 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Grass development package on MacOS
Hi everyone Hope this email finds you well. I installed a QGIS that includes GRASS from here [ https://www.kyngchaos.com/software/qgis/]. The GRASS does not contain a g.extension to install grass addon. When I copy a g.extension from other grass installation. It complains "Please install GRASS development package". So my questions are: 1) How to install GRASS addon without g.extension on MacOS 2) How to install GRASS development packages on MacOS. Many thanks for your help Looking forward to hearing from you soon Best regards Ming ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
