Re: [GRASS-user] GRASS GIS 7.8.5 r.water.outlet
Hi Kelesy, In addition to Michas very good suggestions you can try the table module in pygrass: https://grass.osgeo.org/grass78/manuals/libpython/pygrass.vector.html?highlight=table#module-pygrass.vector.table Or the db_select module from the scripting library: https://grass.osgeo.org/grass78/manuals/libpython/script.html?highlight=select#script.db.db_select for all kind of tables Or the vector_db_select module: https://grass.osgeo.org/grass78/manuals/libpython/script.html?highlight=select#script.vector.vector_db_select for tables connected to vector maps To get the coordinates in Python... Cheers Stefan -Original Message- From: grass-user On Behalf Of Kelsey Wong Sent: onsdag 19. mai 2021 20:52 To: grass-user@lists.osgeo.org Subject: [GRASS-user] GRASS GIS 7.8.5 r.water.outlet Hi, I am trying to use the r.water.outlet function in a python script in GRASS. For the 'coordinates' parameter my x,y coordinate values are stored in two columns in the attribute table of another layer. Is there a way to access these values from the attribute table directly? Thanks, Kelsey ___ grass-user mailing list grass-user@lists.osgeo.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgrass-userdata=04%7C01%7C%7Cd2729cbc538a4733864908d91af73bb6%7C6cef373021314901831055b3abf02c73%7C0%7C0%7C637570471438665050%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=OrVazRa4Mkas0DxUkYtb8i0lfHwFul06zoYFzxO0Dhs%3Dreserved=0 ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] GRASS GIS 7.8.5 r.water.outlet
On 5/19/21 9:52 PM, Kelsey Wong wrote:
Hi,
I am trying to use the r.water.outlet function in a python script in GRASS. For
the ‘coordinates’ parameter my x,y coordinate values are stored in two columns
in the attribute table of another layer. Is there a way to access these values
from the attribute table directly?
The grass.script command 'parse_command' returns the module output as a
python dict, so something like:
import grass.script as gscript
xy = gscript.parse_command('v.db.select', map_="another_table",
columns=['x_coord'_column, 'y_coord_column'], separator="comma")
will probably get you on the right track. If you have multiple points in
the "another_table", then you'll have to loop thru the list, and run
r.water.outlet on each pair separately.
The addon `r.streams.basins`, on the other hand, can deal with a list of
coordinate pairs. So if you convert the output of v.db.select into a
comma separated list like: x1,y1,x2,y2, x3,y3... then you can get all
basins in one go. What's more, this addon can accept a point vector of
drainage outlet points, and prepare basins for each. So if your
"another_table" is indeed a point vector, and the two columns in the
attribute table are the point coordinates, then no need to extract
coordinate from the attrib table. just feed the point vector to the
`points` parameter of `r.streams.basins`.
Thanks,
Kelsey
___
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] GRASS GIS 7.8.5 r.water.outlet
Hi, I am trying to use the r.water.outlet function in a python script in GRASS. For the ‘coordinates’ parameter my x,y coordinate values are stored in two columns in the attribute table of another layer. Is there a way to access these values from the attribute table directly? Thanks, Kelsey ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.rast.stats error: "Unable to seek"
Hi On Wed, May 19, 2021 at 10:16 AM Luís Moreira de Sousa wrote: > > Hi Markus, > > I tried compiling GRASS with the -ftrapv flag, but it was failing (can't > remember now why). Just post the error message when you come back to this. > I was also supposed to create a replicating procedure, but other things came > up in the meantime. However, it looks like for rasters larger than a certain > size none of the modules depending on v.to.rast function correctly. GRASS GIS 7 supports the off_t type, hence it can address an enormous amount of raster data (like 1e+18 pixels or more), see https://grasswiki.osgeo.org/wiki/GRASS_GIS_Performance#Large_raster_data_processing Bugs and limitations are always possible but there is interest in fixing them wherever possible. > I will try to have a look again at an agnostic replication procedure. Alright. Best Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.select disjoint operation. Grass 7.8.2
Hi Markus, Thanks for your response. I note that another user recently had a similar error with a similar (but not the same) module. I am currently splitting my input data into smaller sized files, each for input separately to the v.select module, to see if this resolves the issue. I will let you know on progress. If the failure continues then I will supply you with a reproducible example using the NC data as you indicate. Many thanks. Best wishes, ChrisOn Tuesday, 18 May 2021, 22:01:58 BST, Markus Neteler wrote: Hi, Is there a chance to receive the dataset for testing (or, ideally, a reproducible example with the North Carolina sample dataset from https://grass.osgeo.org/download/data/)? thanks, Markus On Wed, May 12, 2021 at 1:14 PM Christopher Lloyd via grass-user wrote: > > Hi, I am running Grass 7.8.2 on a HPC (linux) to utilise memory not available > to me via my local machine. > > It is running using proj 6.3, gdal 3.0.4, geos 3.8, python 3 > > I am trying to perform the v.select disjoint operation, which I have used > successfully before on a similar setup and similar data using the same > version of Grass (I suspect only the supporting modules and input data have > changed). My code is: > > g.region n=5.4715700149536133 e=31.4501590728759766 s=-13.5662746429443359 > w=12.1540479660034180 -p > > ## Input and clean topology > v.in.ogr -e -o input=file.json output=filev2 snap=-1 --verbose --overwrite > v.in.ogr -e -o input=file2.gpkg output=file2 snap=-1 --verbose --overwrite > encoding=UTF-8 > > ## Extract all categories for each dataset so as to maintain polygon > (building) contiguity where polygons overlap other polygons within each > dataset > v.extract -d input=filev2 layer=1 type=centroid,area output=buildingsdiss > --verbose --overwrite > v.extract -d input=file2 layer=1 type=centroid,area output=file2diss1 > where="cat < 601" --verbose --overwrite > > ## Perform disjoint operation to find buildings that do not intersect > buildings in primary dataset > v.select ainput=file2diss1 alayer=file2diss1 binput=buildingsdiss > blayer=buildingsdiss output=DISJOINT1 operator=disjoint --verbose --overwrite > > ## Output disjoint building layer and cleaned primary dataset > v.out.ogr -m input=DISJOINT1 output=DISJOINT1.gpkg --verbose --overwrite > v.out.ogr -m input=filev2 output=filev2.gpkg --verbose --overwrite > > Having input the topologies and extracted the categories I persistently get > the following error using various data when trying to run the disjoint > operation: > > projection: 3 (Latitude-Longitude) > zone: 0 > datum: wgs84 > ellipsoid: wgs84 > north: 5:28:17.649311N > south: 13:33:58.588333S > west: 8:09:27.521013W > east: 51:45:42.670764E > nsres: 1:00:07.170402 > ewres: 1:00:56.104945 > rows: 19 > cols: 59 > cells: 1121 > NS and EW resolutions are different > Processing features... > 0%..100% > Processing areas... > 0% ERROR: Unable to seek: Invalid argument > NS and EW resolutions are different > > Any advice appreciated on getting v.select to run. Thanks > > Best wishes, Chris > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-user -- Markus Neteler, PhD https://www.mundialis.de - free data with free software https://grass.osgeo.org https://courses.neteler.org/blog ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.rast.stats error: "Unable to seek"
Hi Markus, I tried compiling GRASS with the -ftrapv flag, but it was failing (can't remember now why). I was also supposed to create a replicating procedure, but other things came up in the meantime. However, it looks like for rasters larger than a certain size none of the modules depending on v.to.rast function correctly. I will try to have a look again at an agnostic replication procedure. Cheers. -- Luís Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, May 18, 2021 10:56 PM, Markus Neteler wrote: > Hi Luís, > > Did you get any insights? > > Best, > Markus > > On Fri, Feb 5, 2021 at 4:17 PM Luís Moreira de Sousa > luis.de.so...@protonmail.ch wrote: > > > Hi Maris, > > thank you for the details. I can try compiling with the flag you suggest, > > but I need a bit more time. Will let you know if I succeed. > > Regards. > > -- > > Luís Moreira de Sousa > > Pastoor Bruggemanlaan 21 > > 6861 GR Oosterbeek > > The Netherlands > > Phone: +31 628 544 755 > > Email: luis.de.so...@protonmail.ch > > Mastodon: @luis_de_sousa@mastodon.social > > URL: https://ldesousa.codeberg.page > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Thursday, February 4, 2021 10:21 AM, Maris Nartiss maris@gmail.com > > wrote: > > > > > Don't want to bring bad news, but it looks more like an offset > > > overflow. You will not catch it with valgrind. Although it might catch > > > a bug leading to offset value explosion, most likely the main cause is > > > just code written for handling of small/medium datasets and not > > > large/huge ones (=imperfect logic => can't catch that with valgrind). > > > My suggestion: recompile GRASS with -ftrapv. If it is an integer > > > overflow, at least it will become clearly obvious. > > > https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html > > > The bad thing is G_fseek calling G_fatal_error without knowing actual > > > file name (lets put pipes aside) and thus it is impossible to tell > > > where exactly the error originated from the error message alone. > > > Better would be to bubble up error to main program and let it deal > > > with it in a clean way. Of course, as GRASS is designed around current > > > idioms (handling failure is responsibility of a library making module > > > development really easy), this will not happen in a foreseeable > > > future. > > > One thing you could do – drasticly reduce size of computational region. > > > Māris. > > -- > > Markus Neteler, PhD > https://www.mundialis.de - free data with free software > https://grass.osgeo.org > https://courses.neteler.org/blog ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
