Re: [GRASS-dev] r.stats area question
Eric Goddard wrote: My coordinate system is in U.S. Feet (I know, I know...we're still in the dark ages). The numbers do appear to be meters, but I just wanted to confirm that the output isn't in feet because of the assuming the map's coordinate system is in meters part. Areas are always in square metres, provided that sufficient information is available to perform conversion. For lat-lon locations, the conversion is based upon the ellipsoid parameters and the cell's latitude. For projected locations, the area per cell is a constant based upon the location's declared units (i.e. the meters= value in the ouput of g.proj -g). This has been the case since at least the oldest version in the repository (~14 years ago). AFAICT, the only situation where you could get output in map units is for an X-Y location or a projected location which lacks a PROJ_UNITS file. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Using a multi-${GIS_OPT_X} input in a shell for loop
Vaclav Petras wrote: I remember that we had this conversation recently. What about putting some (ba)sh(ell) primer into the manual? Users aren't required to use bash. Windows users (if they ever leave the GUI) will typically use cmd.exe, Unix users might use csh, ksh or zsh. IMNSHO, the correct place for information on using bash is the bash(1) manual page, not in the manual pages of every command which could conceivably be run from bash. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Using a multi-${GIS_OPT_X} input in a shell for loop
Vaclav Petras wrote: And about Bash versus Python, I agree, I feel it the same, but at the end, I always ends with Python. By the way, there is actually one thing which is sometimes used and that is generation of bash code/script in Python and then running it using bash command. Bit strange but powerful. And dangerous (which is why the use of system() and popen() has been eradicated in 7.0). And non-portable; for 7.0, Windows users shouldn't need to have bash (or any Unix tools) installed. -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Understanding g.tempfile and resolving Illegal filename issues
I don't understand how to use g.tempfile. The manual simply refers to (for bash): temp1=`g.tempfile pid=$$` My attempts to use it like that, end up with: Illegal filename. Character / not allowed. Checking if the map's filename exists, returns for example: --%--- ERROR: Raster map /mnemosyne/geo/grassdb/nc_spm_08/landsat/.tmp/Resilience/26834.0 not found in current mapset ---%-- I have been through the mailing list and have found past references to the same problem. For example http://lists.osgeo.org/pipermail/grass-user/2012-March/063977.html. However, I can't get past the problem. I tried to use naming conventions such as i.fusion.hpf.tmp.$$ but I still have some problems. I would like to use g.tempfile as it seems to be a cleaner way(?). Thank you, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)
The script does not seem to work as posted. Working on it... (trying to understand g.tempfile above all right now). Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Understanding g.tempfile and resolving Illegal filename issues
This creates confusion all the time. For normal files, you use system tools (posix tools) for temporary files, e.g. mktemp. For large files (large means large as a map), use g.tempfile which does not work so well as posix tools in terms of safety but it uses grass database because there is an assumption that there should be enough space. For temporary maps there are two way. You can create temporary vector map in C (and in Python using C types). You cannot do this for rasters. The universal method is to use unique (enough) map name. Function for this should be placed to Python library, so we have the standardized method. It should be noted that `g.tempfile -d` is not usable for this. I hope that this helps and that it is correct. Vaclav On Thu, Nov 14, 2013 at 12:05 PM, Nikos Alexandris n...@nikosalexandris.netwrote: I don't understand how to use g.tempfile. The manual simply refers to (for bash): temp1=`g.tempfile pid=$$` My attempts to use it like that, end up with: Illegal filename. Character / not allowed. Checking if the map's filename exists, returns for example: --%--- ERROR: Raster map /mnemosyne/geo/grassdb/nc_spm_08/landsat/.tmp/Resilience/26834.0 not found in current mapset ---%-- I have been through the mailing list and have found past references to the same problem. For example http://lists.osgeo.org/pipermail/grass-user/2012-March/063977.html. However, I can't get past the problem. I tried to use naming conventions such as i.fusion.hpf.tmp.$$ but I still have some problems. I would like to use g.tempfile as it seems to be a cleaner way(?). Thank you, Nikos ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #789: g.region option to expand the computational region of about some pixels?
#789: g.region option to expand the computational region of about some pixels? ---+ Reporter: nikos | Owner: grass-dev@… Type: enhancement| Status: new Priority: normal | Milestone: 7.0.0 Component: Default| Version: unspecified Keywords: g.region, expand computational region |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by nikosa): Replying to [comment:9 hamish]: Replying to [comment:8 hamish]: does the g.region.point addons script help? http://grass.osgeo.org/wiki/AddOns#g.region.point First guess is no. How would `g.region.point` help in setting the region so as to cover/match the extent of a point vector map and be a bit larger so as to include its points in the `v.what.rast` process? `g.region.point` sets the region around a pair of coordinates. Is the idea behind to loop over all points in a map? I guess not -- this would be a killer for loop. -- Ticket URL: http://trac.osgeo.org/grass/ticket/789#comment:10 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #789: g.region option to expand the computational region of about some pixels?
#789: g.region option to expand the computational region of about some pixels? ---+ Reporter: nikos | Owner: grass-dev@… Type: enhancement| Status: new Priority: normal | Milestone: 7.0.0 Component: Default| Version: unspecified Keywords: g.region, expand computational region |Platform: Unspecified Cpu: Unspecified| ---+ Comment(by hamish): Replying to [comment:10 nikosa]: How would `g.region.point` help in setting the region so as to cover/match the extent of a point vector map and be a bit larger so as to include its points in the `v.what.rast` process? your initial idea of g.region -a vect= res= solves it. Set the resolution to 1000 there (or whatever) and the -a flag will ''always'' grow outwards in all 4 directions. So you run the above, then run g.region a second time with your finer resolution. If your second finer-resolution fits evenly in the initial coarser one, you now have a grown region with bounds rounded to nice whole numbers, a bit bigger than your points map so catching them all! Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/789#comment:11 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Understanding g.tempfile and resolving Illegal filename issues
Nikos wrote: I don't understand how to use g.tempfile. The manual simply refers to (for bash): temp1=`g.tempfile pid=$$` My attempts to use it like that, end up with: Illegal filename. Character / not allowed. Checking if the map's filename exists, returns for example: --%--- ERROR: Raster map /mnemosyne/geo/grassdb/nc_spm_08/landsat/.tmp/Resilience/26834.0 not found in current mapset ---%-- I have been through the mailing list and have found past references to the same problem. For example http://lists.osgeo.org/pipermail/grass-user/2012-March/063977.html. However, I can't get past the problem. I tried to use naming conventions such as i.fusion.hpf.tmp.$$ but I still have some problems. I would like to use g.tempfile as it seems to be a cleaner way(?). g.tempfile is for actual files like ascii text files, not for map names. the convention used in the grass scripts for temporary map names is arbitrary, but e.g. the g.module command might make one called: tmp_gmodule.$$.elev, for vector maps replace '.' with '_' and bring out your curly brackets. :) then cleanup is as simple as g.mremove 'tmp_gmodule.$$.*', and if maps are left behind it's obvious later that they are temporary and where they came from. there's no automatic handling, but I don't see where that would save any time. what problems did you have with i.fusion.hpf.tmp.$$ ? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Implementation of the High Pass Filter Additive Fusion technique (i.fusion.hpf)
Here it goes, as Nikos Ves (depending on free time) works on the Python version (and I'll try to help), the bash proof of concept works. Attached here. After some initial testing, we think that GRASS' results are just slightly more smooth for when applying the exact same parameters to get the HPFA Pan-Sharpened material. To run a test, get the attached tarred file, untar, compile as a grass-addon against G64. Then, the simplest execution form will be: # note, the *algorithm* processes each low resolution image separately i.fusion.hpf pan=lsat7_2000_80 msx=lsat7_2000_10 # or, let's get the usual landsat bands 1, 2 and 3 i.fusion.hpf pan=lsat7_2000_80 msx=lsat7_2000_10,lsat7_2000_20,lsat7_2000_30 # some manual work to rebalance colors (required) i.landsat.rgb r=hpf_lsat7_2000_30 g=hpf_lsat7_2000_20 b=hpf_lsat7_2000_10 d.mon x0 d.rgb r=hpf_lsat7_2000_30 g=hpf_lsat7_2000_20 b=hpf_lsat7_2000_10 # increase crispness (not very obvious) i.fusion.hpf pan=lsat7_2000_80 msx=lsat7_2000_10,lsat7_2000_20,lsat7_2000_30 --o modulator=max i.landsat.rgb r=hpf_lsat7_2000_30 g=hpf_lsat7_2000_20 b=hpf_lsat7_2000_10 d.mon x1 d.rgb r=hpf_lsat7_2000_30 g=hpf_lsat7_2000_20 b=hpf_lsat7_2000_10 # hmmm... let's override the algorithms ratio computation i.fusion.hpf pan=lsat7_2000_80 msx=lsat7_2000_10,lsat7_2000_20,lsat7_2000_30 --o modulator=max ratio=6 i.landsat.rgb r=hpf_lsat7_2000_30 g=hpf_lsat7_2000_20 b=hpf_lsat7_2000_10 d.mon x2 d.rgb r=hpf_lsat7_2000_30 g=hpf_lsat7_2000_20 b=hpf_lsat7_2000_10 BTW, it works really great with QuickBird imagery. Will upload in the next days screenshots with freely available HR imagery (i.e. QB2, IKONOS) and Landsat5, 7 and 8. Just a few Landsat 8 screenshots uploaded in the Wiki: http://grasswiki.osgeo.org/wiki/File:Bengkalis_Island_Landsat8_RGB_Red_NIR_Blue.jpg http://grasswiki.osgeo.org/wiki/File:Bengkalis_Island_Landsat8_Panchromatic.jpg http://grasswiki.osgeo.org/wiki/File:Bengkalis_Island_Landsat8_HPFA_Sharpened_RGB_Red_NI R_Blue_Default_Parameters.jpg http://grasswiki.osgeo.org/wiki/File:Bengkalis_Island_Landsat8_HPFA_Sharpened_RGB_Red_NI R_Blue_Max_Crispness.jpg Nikos i.fusion.tar.gz Description: application/compressed-tar ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Understanding g.tempfile and resolving Illegal filename issues
Hamish: what problems did you have with i.fusion.hpf.tmp.$$ ? Nikos: I think the problem was (among my misunderstanding) that $$ was the same for a bunch of names fed as variables here and there. '$$' gets replaced with the PID of the calling process, so within a single script it will be consistent, and it should be unique among processes currently running on the system. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
