[GRASS-user] Elevation above a river
Hi All, Does anyone know is it possible to calculate the elevation above a river channel (actual river network that was digitised as opposed to being extracted from a DTM) from a DTM and create a polygon from it. I need to calculate heights of 1m and 3m above a river channel on both sides of the channel and create a polygon from it. Thanks all. Le gach dea ghui, *Shane Carey* *GIS and Data Solutions Consultant* ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] grass-user Digest, Vol 149, Issue 15
hi Helmut,
thanks a lot i applied the changes you recommended to the .py file and it
worked.
cheers
Nick
On Wed, Sep 12, 2018 at 8:01 PM wrote:
> Send grass-user mailing list submissions to
> grass-user@lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osgeo.org/mailman/listinfo/grass-user
> or, via email, send a message with subject or body 'help' to
> grass-user-requ...@lists.osgeo.org
>
> You can reach the person managing the list at
> grass-user-ow...@lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of grass-user digest..."
>
>
> Today's Topics:
>
>1. Re: Help with r.landscape.evol (Helmut Kudrnovsky)
>2. Re: Help with r.landscape.evol (Helmut Kudrnovsky)
>
>
> --
>
> Message: 1
> Date: Wed, 12 Sep 2018 10:23:07 -0700 (MST)
> From: Helmut Kudrnovsky
> To: grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Help with r.landscape.evol
> Message-ID: <1536772987490-0.p...@n6.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Nicholas Uwadia wrote
> > Thanks makus for your reply, i have added more details as required and
> > also
> > the error experienced.
> > operating system :windows 10
> > GRASS GIS: 7.4
>
> tested here with OSGeo4W-winGRASS 7.4.1
>
> -
> r.landscape.evol --verbose elev=elevation@PERMANENT initbdrk=bedrock@user1
> smoothing=no prefx=levol_ outdem=elevation outsoil=soildepth number=1
> statsout=D:\temp\testadd\test.txt
>
> ##
> ##
>
> STARTING SIMULATION
>
> Beginning iteration sequence. This may take some time.
> Process is not finished until you see the message: 'Done with everything'
> _
> _
> Total number of iterations to be run is 1
> Iteration = 1
>
> ##
>
> *
> Iteration 1 -- step 1: calculating slope
> *
>
> *
> Iteration 1 -- step 2: calculating accumulated flow depths
> *
> Calculating runoff excess rates (uplsope accumulated cells scaled to
> "flowcontrib" map
>
> *
> Iteration 1 -- step 3: calculating sediment transport rates (units variable
> depending upon process)
> *
>
> *
> Iteration 1 -- step 4: calculating divergence/difference of sediment
> transport for each process and the actual amount of erosion or deposition
> in
> vertical meters/cell/year
> *
>
> Running soft-knee smoothing filter...
> No additional modal smoothing was requested...
> ERROR: Unable to load rules file
>
> Traceback (most recent call last):
> File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
> /r.landscape.evol.py", line 681, in
> main(x, (x + 1), prefx, statsout, region1['nsres'],
> masterlist);
> File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
> /r.landscape.evol.py", line 509, in main
> grass.run_command('r.colors', quiet = "True", map =
> netchange, rules = nccolors.name)
> File "C:\OSGEO4~1\apps\grass\grass-7.4.1\etc\python\grass\
> script\core.py", line 421, in run_command
> return handle_errors(returncode, returncode, args,
> kwargs)
> File "C:\OSGEO4~1\apps\grass\grass-7.4.1\etc\python\grass\
> script\core.py", line 332, in handle_errors
> returncode=returncode)
> grass.exceptions.CalledModuleError: Module run None
> ['r.colors', '--q', 'rules=c:\\users\\hkmyr\\appdata\\local\
> \temp\\grass7-hkmyr-8260\\tmp3ykzyr', 'map=levol_ED_rate']
> ended with error
> Process ended with non-zero return code 1. See errors in the
> (error) output.
>
>
> confirmed
>
> it seems there is an issue with r.colors reading a temporary color rules
> file.
>
>
>
> -
> best regards
> Helmut
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Users-f3884509.html
>
>
> --
>
> Message: 2
> Date: Wed, 12 Sep 2018 11:20:53 -0700 (MST)
> From: Helmut Kudrnovsky
> To: grass-user@lists.osgeo.org
> Subject: Re: [GRASS-user] Help with r.landscape.evol
> Message-ID: <1536776453399-0.p...@n6.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Helmut Kudrnovsky wrote
> > File "C:\Users\hkmyr\AppData\Roaming\GRASS7\addons/scripts
> > /r.landscape.evol.py", line 509, in main
> > grass.run_command('r.colors', quiet = "True", map =
> > netchange, rules = nccolors.name)
> > File "C:\OSGEO4~1\apps\grass\grass-7.4.1\etc\python\grass\
> > script\core.py", line 421, in run_command
> > return handle_errors(returncode, returncode, args,
> > kwargs)
> > File
Re: [GRASS-user] compiling GRASS with Cygwin and Windows 10
dear GRASS users, just want to let you know that the problem was finally solved with the latest Cygwin update. Now GRASS GIS can be compiled and used in Cygwin, again. Massi Il giorno gio 15 mar 2018 alle ore 10:52 Massi Alvioli ha scritto: > > > Hi Markus, > > thanks for your answer. That was also one of my concerns, but I have no > handle on that other than > using the 64bit installation utility for cygwin. The package containing > cygSDL (which seems to be > the problem, here) does not bear any reference to 32/64 bit .. and google > does not help on that > "Win32 error 1114" alone or in conjunction with cygwin, cygSDL or python. I > guess I'll have to > wait for the next major cygwin upgrade, if nobody else comes up with some > idea. > > Massi > > 2018-03-14 20:05 GMT+01:00 Markus Neteler : >> >> Hi, >> >> On Tue, Mar 13, 2018 at 11:21 PM, Massi Alvioli wrote: >> > Hi all, >> > >> > I need a bit of help with this Cygwin problem. Since the last Cygwin update >> > my GRASS 7.2 gui stopped working with a cryptical Cygwin-related error >> > message: >> > - --- -- - >> > GRASS 7.2.0 (italia):~ > g.gui >> > Launching GUI in the background, please wait... >> > 0 [main] python2.7 13544 child_info_fork::abort: unable to map >> > C:\cygwin64\bin\cygSDL2-2-0-0.dll, Win32 error 1114 >> >> --> confusingly it shows a Win32 error while being in cygwin64\ ? >> >> Your configuration is also >> >> ./configure \ >> --prefix=/home/alvioli/macs/local/grass74_inst \ >> --host='x86_64-pc-cygwin' \ >> ... >> >> Was the cygwin update mixing up 32bit and 64bit (just guessing)? >> >> Markus > > > ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Not matching categories/line IDs
Apparently the count in v.category option=report is the total number of
categories per type and layer. If you have e.g. two lines with categories
line1: 1
line2: 1,2
there are two lines and three categories. This needs to be explained in the
manual.
Markus M
On Fri, Sep 14, 2018 at 8:53 AM Johannes Radinger <
johannesradin...@gmail.com> wrote:
> Hi Markus,
> Hi all,
>
> I created a zipped version of a test location including one PERMANENT
> mapset that includes the vector map that causes these inconsistencies
> (Ebro_river_vector_poly_clean_tmp). The test location can be downloaded
> from here: https://we.tl/t-eSUZqfP0TQ. I also included the initial vector
> map before running the v.clean tool (Ebro_river_vector_poly_tmp). More
> specifically, I am using following code:
>
> grass.run_command("v.clean",
> overwrite=True,
> flags="c",
> input="Ebro_river_vector_poly_tmp",
> output="Ebro_river_vector_poly_clean_tmp",
> tool="break,rmdupl,rmline,rmsa,rmdangle",
> threshold="0,0,0,0,0.001")
>
> Maybe this helps to find out what happens here.
>
> /Johannes
>
> On Thu, Sep 13, 2018 at 10:26 PM Markus Metz <
> markus.metz.gisw...@gmail.com> wrote:
>
>>
>>
>> On Thu, Sep 13, 2018 at 10:50 AM Johannes Radinger <
>> johannesradin...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > I am a little bit puzzled about the actual number of lines/categories
>> of a specific vector map (river network). As discussed yesterday, the
>> output of v.category with the report option provides a column 'count' which
>> is a feature count. Running v.category option=report on my vector provides
>> me following:
>> >
>> > v.category input=Ebro_river_vector_poly_clean_tmp@Ebro2_alien_spread
>> option=report
>> > Layer/table: 1/Ebro_river_vector_poly_clean_tmp
>> > type countminmax
>> > point 0 0 0
>> > line 804 1 1053
>> >
>> >
>> > This would indicate that I have 804 line features. However, using the
>> tool v.info on the same vector I get following different result
>> regarding the number of lines:
>> > v.info map=Ebro_river_vector_poly_clean_tmp@Ebro2_alien_spread
>>
>> >
>>
>> ++
>> > | Name:Ebro_river_vector_poly_clean_tmp
>>|
>> > ...
>> > | Number of points: 0 Number of centroids: 0
>>|
>> > | Number of lines:799 Number of boundaries: 0
>>|
>> > ...
>> >
>> > And even more puzzling, I then added a table to this vector map and the
>> output of v.db.addtable is:
>> > v.db.addtable map=Ebro_river_vector_poly_clean_tmp@Ebro2_alien_spread
>>
>> > Reading features...
>> > Updating database...
>> > 803 categories read from vector map (layer 1)
>> > 803 categories read from vector map don't exist in selection from table
>> > 803 records updated/inserted (layer 1)
>>
>> If there are 804 features, 2 features must have the same category value,
>> resulting in 803 updates to the database
>> >
>> > So, is it 804,799 or 803??
>>
>> The output of v.info and v.category option=report must be identical with
>> regard to the count of features.
>> >
>> > The map I am using is a polyline river network (cat=first) that has
>> gone trough the tool v.clean with the options:
>> break,rmdupl,rmline,rmsa,rmdangle. The number of lines and cats before the
>> cleaning tool is 805 (consistent output among all tools).
>> >
>> > So I am wondering what happens during cleaning and how to get a clean
>> map with a corresponding table that has entries for each cat, and were each
>> cat represents one line feature (i.e. that the number of cats/line features
>> is consistent over the multiple tools).
>> >
>> > Please let me know if I should share the vector map (and how, which
>> format).
>>
>> Ideal would be a stripped down GRASS mapset with only this vector
>> Ebro_river_vector_poly_clean_tmp. Exporting the vector would change the
>> geometry representation and it would no longer be possible to reproduce the
>> problem.
>>
>> Markus M
>>
>>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Not matching categories/line IDs
Hi Markus,
Hi all,
I created a zipped version of a test location including one PERMANENT
mapset that includes the vector map that causes these inconsistencies
(Ebro_river_vector_poly_clean_tmp). The test location can be downloaded
from here: https://we.tl/t-eSUZqfP0TQ. I also included the initial vector
map before running the v.clean tool (Ebro_river_vector_poly_tmp). More
specifically, I am using following code:
grass.run_command("v.clean",
overwrite=True,
flags="c",
input="Ebro_river_vector_poly_tmp",
output="Ebro_river_vector_poly_clean_tmp",
tool="break,rmdupl,rmline,rmsa,rmdangle",
threshold="0,0,0,0,0.001")
Maybe this helps to find out what happens here.
/Johannes
On Thu, Sep 13, 2018 at 10:26 PM Markus Metz
wrote:
>
>
> On Thu, Sep 13, 2018 at 10:50 AM Johannes Radinger <
> johannesradin...@gmail.com> wrote:
> >
> > Hi all,
> >
> > I am a little bit puzzled about the actual number of lines/categories of
> a specific vector map (river network). As discussed yesterday, the output
> of v.category with the report option provides a column 'count' which is a
> feature count. Running v.category option=report on my vector provides me
> following:
> >
> > v.category input=Ebro_river_vector_poly_clean_tmp@Ebro2_alien_spread
> option=report
> > Layer/table: 1/Ebro_river_vector_poly_clean_tmp
> > type countminmax
> > point 0 0 0
> > line 804 1 1053
> >
> >
> > This would indicate that I have 804 line features. However, using the
> tool v.info on the same vector I get following different result regarding
> the number of lines:
> > v.info map=Ebro_river_vector_poly_clean_tmp@Ebro2_alien_spread
>
> >
>
> ++
> > | Name:Ebro_river_vector_poly_clean_tmp
> |
> > ...
> > | Number of points: 0 Number of centroids: 0
> |
> > | Number of lines:799 Number of boundaries: 0
> |
> > ...
> >
> > And even more puzzling, I then added a table to this vector map and the
> output of v.db.addtable is:
> > v.db.addtable map=Ebro_river_vector_poly_clean_tmp@Ebro2_alien_spread
>
> > Reading features...
> > Updating database...
> > 803 categories read from vector map (layer 1)
> > 803 categories read from vector map don't exist in selection from table
> > 803 records updated/inserted (layer 1)
>
> If there are 804 features, 2 features must have the same category value,
> resulting in 803 updates to the database
> >
> > So, is it 804,799 or 803??
>
> The output of v.info and v.category option=report must be identical with
> regard to the count of features.
> >
> > The map I am using is a polyline river network (cat=first) that has gone
> trough the tool v.clean with the options:
> break,rmdupl,rmline,rmsa,rmdangle. The number of lines and cats before the
> cleaning tool is 805 (consistent output among all tools).
> >
> > So I am wondering what happens during cleaning and how to get a clean
> map with a corresponding table that has entries for each cat, and were each
> cat represents one line feature (i.e. that the number of cats/line features
> is consistent over the multiple tools).
> >
> > Please let me know if I should share the vector map (and how, which
> format).
>
> Ideal would be a stripped down GRASS mapset with only this vector
> Ebro_river_vector_poly_clean_tmp. Exporting the vector would change the
> geometry representation and it would no longer be possible to reproduce the
> problem.
>
> Markus M
>
>
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
