Here's a way that the seems to work. You need to export the UUID variable on the same command line as starting grass. Then within the batch job script the variable $UUID is available in the enviroment,
micha@TP480:tmp$ cat << EOF > test_args.sh
> echo "$UUID"
> g.region -p
micha@TP480:tmp$ chmod u+x test_args.sh
Based on this grasswiki-article setting the operating system environment variable GISBASE to the GRASS installation folder might fix the issue (e.g. C:\OSGeo4W\apps\grass\grass76).
QGIS 3.8 processing options still doesn't contain an option for the GRASS folder.
I refer to Windows operating system and QGIS 3.8 / GRASS 7.6.
QGIS is out, it doesn't support raster attribute tables at all.
I don't know about GRASS.
GDAL would require you to (manually or in python code) handcraft VRTs with lookup tables from the attribute table fields for each "band", then composite the VRTs.
In ArcGIS, you can only use Lookup and Composite Bands. However, look at the versions of those functions ...
Both the GRASS GIS Addons i.landsat.dehaze and i.landsat.trim still have not been rewritten in Python which is a requirement to become part of the GRASS GIS 7 Addons section.
The original Shell code is here:
A few comments might help:
The -c flag is used to create a new Location using a georefenced file or EPSG code. You should not put the path to your GRASS Location as the value for -c.
FAQ #0: Always set the GRASS computational region before you do any raster processing. So before r.null do:
g.region -ap raster=dummy_img
Instead of starting up GRASS 6 times, ...
By looking at the error message the failure occurs when GRASS (or GDAL/OGR) is trying to create a SQLite table. The SQL create table statement is included in the message, and the error is pointed to happen somewhere near to "from".
The case can be simplified into
CREATE TABLE foo (from);
The command will fail and throw the error message near "from": ...
You are using a very old GRASS GIS version (6.4.4 from 2014!) which does not offer v.import as it was developed later.
Please change to GRASS GIS 7.x which is also available for CentoOS7. For this, see https://grass.osgeo.org/download/software/linux/
I found the solution myself eventually. I did the following things, although it is possible that some of them actually had no effect, but I am writing them all anyway in case they are indeed important:
I changed the image from a geographic CRS to a projected CRS. I doubt this did anything to change it but I know sometimes some algorithms don't play nice ...
If you raster's projection unit is meter, then the output unit of the proximity raster will be meters if you specify georeferenced units. In case your raster's projection unit is not meter (e.g. is degree because it is on WGS84), you'll want to reproject your raster to another coordinate system (such as UTM, for example).
Here is one solution using ArcGIS:
1) Resample your 30-meter DEM using the Resample Tool. In the Output Cell Size you can write the path to your 8-meter resolution DEM. For the Resampling Technique choose either Bilinear or Cubic, as they are appropiate for continuous data. Also, before running the tool, click on the Environments... button and click on ...
After your comment, I double checked, and this is what I worked out. I start with a multipolygon multi with three areas and two attrib columns cat (value 1) and label (value "one").
# The initial multi_polygon
GRASS 7.6.0 (WGS84):/tmp > v.info -t multi
In order to do any processing on rasters from different CRS's you'll have to reproject to a common CRS. The common CRS in your case might be UTM 33 since that's the projection of the DEM. However does your DEM, in UTM 33, cover the area of UTM31 - UTM 34 ??. I'm not sure that reprojecting from UTM 31 to UTM 33 would be appropriate - you'll get some visible ...
The way to do this in GRASS uses a reclass of the vector layer, then when you update the database of this reclass vector with i.e. area, the total of the reclassed features will be calculated. See: v.reclass man page
If you have a buildings polygon with a integer or text field building_num, then:
v.reclass input=buildings output=buildings_by_num column=...
The modules.xml file is located here: https://grass.osgeo.org/addons/grass7/modules.xml
For example metadata for d.explanation.plot
<description>Draw a plot of multiple rasters to explain a raster operation for example a + b = c</description>
Have you installed the development libraries for C and for grass?
The extension needs to be compiled so you need both a compiler (which is giving you an error so it is installed), and the relevant header files.
It can't find stdio.h which is part of the base C library. You would probably get the same error if you tried to compile anything in C.
This is due to the server url being different to the one hardcoded in grass. See this ticket for some details, https://trac.osgeo.org/grass/ticket/3455 and also this question GRASS GIS addon "extension not found"; could the problem be with the GRASS Addons server?.
A workaround is to locate the g.extension.py script, copy and rename it and modify ...
The windows repository seems to be hardcoded to http://wingrass.fsv.cvut.cz/grass74/x86_64/addons/grass-7.4.4/ (in grass 7.4 at least).
The files are actually located at http://wingrass.fsv.cvut.cz/grass74/x86_64/addons/grass-7.4.svn/
The windows precompiled versions of the addons don't appear to be located in the main repository at the moment (now at https://github.com/OSGeo/grass-addons), but at http://wingrass.fsv.cvut.cz. The problem seems to be that the (incorrect) url is hardcoded in grass.
There is a ticket for this: https://trac.osgeo.org/grass/ticket/3455
Python scripts can be ...
I had the same problem some months ago, and overcame it used shapely and geopandas, here is my solution on github
It's a simple python Class that gets for every vertex the closest one in a distance you can define, if no vertex is within that distance it creates a new one and snap to it. You can execute with :
python auto_snap.py "path/to/layer.shp" ...
First of all many thanks for your answers.
@Cyril I indeed do this to fill the gaps
@RGfromRWBJV I also use this tool to clean the layer
@markusN I also used this solution to clean the layer
There is no simple solution on this. Despite these functions, none of them are perfect.
Therefore the simplest way to do this is :
- the snapping option from the ...