[GRASS-user] v.rast.stats error: "Unable to seek"
Dear all, I am getting the error "Unable to seek" with v.stats.error. There is not much information that could point the cause, just a warning saying that some data base files are not found. I checked the database connection and everything looks in order (see below). Any hints on what may be causing this error? Thank you. > v.rast.stats map=PSU raster=MAL_Mode_5x5 method=number column_prefix=mal ERROR: Unable to seek: Invalid argument ERROR: An error occurred while converting vector to raster WARNING: No data base element files found > db.connect -p driver: pg database: s4a schema: mal group: > psql -d s4a -p 5434 psql (12.5 (Ubuntu 12.5-0ubuntu0.20.04.1)) Type "help" for help. s4a=# \dt mal.* List of relations Schema | Name | Type | Owner +--+---+-- mal | psu | table | duque004 (1 rows) s4a=# select count(*) from mal.psu; count -- 19468516 (1 row) -- Luís___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] increase efficiency of analysis with r.grow.distance aka Euclidean allocation
Am 29. Januar 2021 01:30:03 GMT+00:00 schrieb karsten : >Hi All, > >I am working on a project that requires to find the middle boundary between >raster regions (of the same value) using a maximum buffer distance. The >raster input I am using is quite large like 5m resolution and 10 by >10 cells. One approach I took was to fill all cells in areas outside the >raster regions in question which I will need to buffer to NULL >and then using the r.grow.distance in GRASS (similar to the Tool Euclidean >allocation in ArcGIS). > >This works with smaller files but with a big input like the one above >calculation time is very long or might crash even on a fast PC. The only >remedy I found (apart from throwing larger RAM or hardware at the task) >so far was cutting up the raster file in tiles and running the analysis on >each tile and putting the results back afterwards to get to final result >layer. > >Would anyone have hints if there are other approaches that I could increase >the efficiency of this analysis in GRASS or have any knowledge of other tool >sets such as R or python scripts that are already available for something >like this ? Working tile by tile allows you to parallelize the processes, and so treat several tiles at once. Obviously tiling does raise the issue of the border regions, so sufficient overlap will be necessary. Moritz Moritz ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS GIS Addons: status update
Dear all, We have recently done a clean-up of long time unmaintained addons (to avoid confusion): Moved to GRASS-core (most already years ago): - i.fusion.brovey: replaced by "i.pansharpen" - r.fill.gaps: ported to core as "r.fill.stats" - r.geomorphon: same name - r.grow.shrink: continued as "r.grow.distance" and its Python wrapper "r.grow" - v.clip: same name - v.profile: same name Removal of outdated addons: - r.in.arc: replaced by "r.in.gdal" / "r.import" - r.lfp: replaced by "r.accumulate" - r.los: replaced by "r.viewshed" - r.modis: renamed to "i.modis" - r.out.arc: : please use "r.out.gdal" - r.sentinel: renamed to "i.sentinel" Find the list of addons here: https://grass.osgeo.org/grass7/manuals/addons/ Best regards, Markus ___ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
