-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use g.region to focus on core area #37
Comments
Note the differences between g.region and r.mask, e.g. see here: >link<. The set-up of a location and mapset with certain region settings is a matter of GRASS pre-processing that needs to be done by the user before running lumpR. The employed masks only ensure that raster calculations are limited to a specific area of interest to avoid holes, e.g. when after some processing steps the resulting catchment is slightly smaller than it was before (especially in lump_grass_prep() which is why 'mask_corr' was introduced). I think the current workflow is as consistent in that regard as it can be. The user only needs to take some care not to get confused with his/her data, especially when working on several mapsets at the same time (which should be avoided but this is a matter of GRASS and not lumpR). |
OK, then we should try to mention defining the region in some guideline before (if we haven't done this yet). Something like the command collection dataimport.sh that used to exist. |
Indeed, as it seems a lumpR tutorial should also contain a GRASS and a Database tutorial. There are just not enough people aroung being experienced with GRASS or databases (or having enough time to learn it). But from this point of view, one would have to re-code all internally used GRASS algorithms and also avoid the database operations. This is possible but I guess nobody wants to spent money for that. |
OK, setting region has been corrected in dataimport.sh in branch svc_issues. |
Currently, we mainly employ the MASK to define the area of interest.
g.region is used only once in lump_grass_prep.R to define the region, but I assume it would be better to save the region with a specific name and set this region explicitly any of the subsequent steps. This would ensure more consistent behaviour when resuming the workflow inbetween:
g.region --overwrite zoom=MASK save=saved_region #creates region from MASK
g.region region=saved_region #recalls saved region
The text was updated successfully, but these errors were encountered: