[GRASS-dev] cache in i.atcorr and background run
Hi, I would like to run i.atcorr on several bands simultaneously. Is the cache privately allocated to each run? Thank you, Yann -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1442: GRASS 7: d.grid layout suboptimal
#1442: GRASS 7: d.grid layout suboptimal -+-- Reporter: neteler | Owner: hamish Type: defect | Status: assigned Priority: normal | Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.grid |Platform: Linux Cpu: x86-64 | -+-- Changes (by hamish): * cc: grass-dev@… (added) * keywords: = d.grid * status: new = assigned * owner: grass-dev@… = hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1442#comment:2 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] #1410: scalebar displays multiples north arrows
#1410: scalebar displays multiples north arrows
-+--
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Display | Version: svn-trunk
Keywords: d.barscale, ll, north arrow |Platform: All
Cpu: Unspecified |
-+--
Comment(by hamish):
the triplicate symbols in d.barscale still happens in lat/lon locations
with the new version of the module. The infill problem is fixed now.
it seems to be during this code of D_symbol():
{{{
case S_POLYGON:
...
/* again, to draw the lines */
...
D_begin();
for (k = 0; k chain-scount; k++) {
xp = x0 + sx * chain-sx[k];
yp = y0 - sy * chain-sy[k];
if (k == 0)
D_move_abs(xp, yp);
else
D_cont_abs(xp, yp);
}
D_end();
D_stroke();
}}}
which is called only once.
adding a printf() in the loop shows the xp and yp display coords look ok:
{{{
xp=50.40 yp=368.00
xp=33.40 yp=386.00
xp=50.40 yp=316.00
xp=68.40 yp=386.00
xp=50.40 yp=368.00
xp=50.40 yp=368.00
}}}
I tried throwing in a D_close() before the D_end(), no change.
- It is unclear to me what D_end() does now, it appears to be a no-op?
trying the different north_arrow= symbol options shows the problem
manifesting itself differently through a couple different scenarios.
My first guess would be a missing D_stroke(), but it's right there...
so my next guess is some D_move_*() or D_pos_*() function error. It's a
bit unclear to me when to use D_pos_*(), I tried to add some more header
comments with what I understand about them, but some clarification would
be appreciated as I fear spreading misinformation.
??
thanks,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/1410#comment:6
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] #1618: d.rast.arrow displaying incorrectly in GRASS 7
#1618: d.rast.arrow displaying incorrectly in GRASS 7 --+- Reporter: cmbarton | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.0 Component: Display | Version: svn-trunk Keywords: d.rast.arrow |Platform: Unspecified Cpu: Unspecified | --+- Comment(by hamish): looks ok for me now in spearfish. do you still see it? maybe only in a lat/lon location like the d.barscale bug? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1618#comment:3 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] #1324: DebCheck QA: Undefined behaviour- variable is used wrong in call to sprintf or snprintf
#1324: DebCheck QA: Undefined behaviour- variable is used wrong in call to sprintf or snprintf -+ Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.2 Component: Compiling | Version: 6.4.0 Keywords: d.barscale, d.text.new, d.vect, d.zoom, lib/symbol/read.c, lib/vector/Vlib/dbcolumns.c, v.external |Platform: Linux Cpu: Unspecified | -+ Comment(by hamish): d.barscale fixed in devbr6 with r56877. n/a to trunk's d.barscale. -- Ticket URL: https://trac.osgeo.org/grass/ticket/1324#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GSOC wk1 checkin
Tim Bailey Horizon Based Interpolation module for GRASS Google Summer of Code Week 1 check in Friday, June 21 2013 Hi everyone, During this first week of coding I have been working on input specifications for the horizon descriptions interpolation module. Several early technical challenges emerged. The process for importing horzons turns out to be a bit confounding. Generating input from horizon databases turns out to be non-trivial task. I have done an informal survey of every geologist and soil scientist that I know concerning how they store horizon datasets. In addition I have inspected the storage specifications for several public soils database formats. In parallel to the programming project I have been building three sandboxes to test the methods developed in this project. One is a site level wetland delineation. Another is a database of geotechnical borehole logs that Bob Moskovitz of the California Geologic Survey provided. The third is a random Natural Resources Conservation Service survey subset. My work product next week is going to focus on the interpolation module. The abstract workflow for the module as whole is as follows *Process for generation of r3 voxel grid from a population of xy located 1 dimensional horizon descriptions* 1. *Import of database horizon descriptions* 2. *Generation of line vector representing the path of the horizon description in xyz* 3. *Segmentation of the line vector into n number xyz points* 4. *query of attribute values to points from attribute database* 5. *Generation of r3 region * 6. *Interpolation of point attribute values through geostatistical and/or logical operators onto voxel grid locations* After extensive consultation with my programming mentor Ben Ducke, I am now moving on to the interpolation of vector attributes to voxel cells. One point that Ben articulated was that the interpolation assignment needs to be capable of operating on integer data so that it can work on Best wishes on this first day of summer. Tim Bailey ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GSOC wk1 checkin
Hi Tim, thanks for your report. Just small reminder that this report should be sent in copy also to `s...@lists.osgeo.org` ML. Martin ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by glynn): Replying to [comment:24 wenzeslaus]: I've committed the small fix for r56867 in r56869 (Python says ''can only concatenate list (not tuple) to list''). Er, right. There is except without OSError, mentioned before, is there any reason for this? Nothing particular. It's mainly a case of determining works versus doesn't work without caring about the reasons for the latter. If other errors are possible, should the caller be concerned with them? I.e. should we just allow exceptions other than `OSError` to propagate up to the caller? In any case, it should probably be restricted at least to either `StandardError` or `Exception`, so that it doesn't catch `KeyboardInterrupt`. I was about to commit the special case for the `explorer` cmd on MS Win. However, there is also a special case for `xdg-open`, I'm not sure why. I think that the browser != 'xdg-open' check is just because xdg-open returns a non-zero exit code when run without arguments. Moreover, I tested also other command and e.g. `firefox` blocks the g.manual (it also blocks the cmd line when launched without ). I don't think that find_program() is appropriate for GUI applications. E.g. on Windows, many of them will spawn a GUI regardless of any arguments given. More generally, there should probably be separate functions for opening a file or URL in the user's desktop environment. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:28 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] Unexpected EVI range from i.vi
On Fri, Jun 21, 2013 at 10:04 PM, Nikos Alexandris n...@nikosalexandris.net wrote: Markus Metz wrote: I think I figured it out: The EVI formula in i.vi is for MODIS. Nikos A: That's precise, EVI is MODIS specific. We should clearly describe this in the manual (I will try to alter the respective text). MM: From the literature, I gor the impression that EVI can be calculated from other sensors as well, as long as you get the coefficients right. Yes, but this is not an easy job, is it? This is (also) why, I think, they (MODIS science team) developed the EVI2, which is cross-sensor. I am pretty sure that the EVI2 formula in i.vi is not cross-sensor, but also tailored to unscaled MODIS input bands: EVI2 = G * ( nir - red) / (nir + C1 * red + L) again, L needs to be adjusted to the actual input scale. AFAIU, both EVI and EVI2 can be applied to different sensors, given that the required bands are available and that the coefficients are adjusted if need be. The generic formula is G * ( nir - red) / (nir + C1 * red - C2 * blue + L) where G is a gain factor, C1, C2 are coefficients to correct for aerosol influences in the red band using the blue band and L is the canopy background adjustment that addresses non-linear, differential NIR and red radiant transfer through a canopy. Assuming that the input to i.vi should be properly preprocessed bands with a theoretically maximum range of [0, 1], you could set L to 0.0001 and would get reasonable EVI values, sensor-independent. This reminds, if I am not wrong (didn't check) the scale factor for MOD09 surface reflectance products. Makes sense. I suggested L = 0.0001 exactly because this is the MODIS scale factor. BTW, the satellite data you mentioned are ETM, not MODIS, thus applying the EVI formula developed for MODIS to ETM bands is a bit adventurous. In any case, EVI was developed for tropical rain forests because NDVI can saturate there. The Landsat scene you mentioned has only ocean and desert, no forest of any kind. NDVI should be just fine in this area. I would suggest to test the EVI(2) formulas in i.vi with a MODIS NDVI product which also includes the required input bands. All bands in the MODIS NDVI product would need to be scaled according to the documentation prior to feeding them to i.vi, or r.mapcalc with adjusted formulas. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by wenzeslaus): Replying to [comment:28 glynn]: Replying to [comment:24 wenzeslaus]: I was about to commit the special case for the `explorer` cmd on MS Win. However, there is also a special case for `xdg-open`, I'm not sure why. I think that the browser != 'xdg-open' check is just because xdg-open returns a non-zero exit code when run without arguments. Moreover, I tested also other command and e.g. `firefox` blocks the g.manual (it also blocks the cmd line when launched without ). I don't think that find_program() is appropriate for GUI applications. E.g. on Windows, many of them will spawn a GUI regardless of any arguments given. Yes, this would lead to conservative `shutil.which` which just looks. More generally, there should probably be separate functions for opening a file or URL in the user's desktop environment. Sorry, I don't get your last point. Would you like to have `open_something` function in GRASS or do you expect this function to be available from system or something else? Anyway, in r56880 I have deleted the test in g.manual since I don't see any reason for it. The `execlp` function tests it sufficiently without consequences and moreover it is Pythonic EAFP. Considering r56880, we don't need the `shutil.which` now, but we may add it for/in the future. Diverging from the original ticked topic, the `GRASS_HTML_BROWSER=firefox` blocks the command line even after r56880 when no firefox session is running. However, this is expected and I think there is no way how to avoid this when we want (probably because of cmd line web browsers) to use `execlp`. == Ticked summary == In r56880, g.manual is not using find_program or any other test function. Some special apps (especially those with GUI) may require `shutil.which` to avoid strange situations. It could be convenient (for both the interface and implementation) to have special function to test presents of GRASS modules. The interface to of `find_program` was changed to be less error-prone in r56867 (and r56869). ...other things were invalid, if not or if I miss something please add. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2008#comment:29 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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by hamish): Replying to [comment:29 wenzeslaus]: Anyway, in r56880 I have deleted the test in g.manual since I don't see any reason for it. In r56882 I have put it back. It is nice to have the clearer error message on Linux (where the error could come up a lot), and in cases where GRASS_HTML_BROWSER is either unset of malformed. It may need to be improved or fixed, but it should be there. No idea about the reasoning for special xdg-open tests. But not understanding is a reason to keep it there, not to delete it. Glynn: I don't think that find_program() is appropriate for GUI applications. mmmph, it either works or it doesn't. The use case shouldn't matter. e.g. the r.in.wms wxPython wrapper in GRASS 6 needs the `xml2` program to be present, and needs to gracefully fail out with a suggestion to run the module from the command line if it isn't there. wenzeslaus: Diverging from the original ticked topic, the `GRASS_HTML_BROWSER=firefox` blocks the command line even after r56880 when no firefox session is running. there was another ticket for that (probably several over the years), closed as invalid AFAIU. To mitigate the problem I guess we could white- list some known GUI browser names and selectively background them? However, this is expected and I think there is no way how to avoid this when we want (probably because of cmd line web browsers) to use `execlp`. exactly, mainly for links lynx; although I suppose some rare but possible scripted html2txt/html2tex variants could exist. regards, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:30 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] #2008: grass.script's find_program() can't find modules
#2008: grass.script's find_program() can't find modules ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: critical | Milestone: 6.4.4 Component: Python| Version: svn-releasebranch64 Resolution:|Keywords: find_program() Platform: All | Cpu: x86-64 ---+ Comment(by hamish): Replying to [comment:29 wenzeslaus]: It could be convenient (for both the interface and implementation) to have special function to test presents of GRASS modules. just to note that the last version of that I saw failed to pick up Addon modules. (installed in either the GRASS_ADDON_PATH(s) /or ~/bin/) regards, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2008#comment:31 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] pyGRASS problem with r.sun
Hi, (svn trunk) r.sun in pyGRASS is somehow confused with data type for time option. Time option does work well as a float input directly in the shell. from pyGRASS it expects an integer. time=10.3321830777 Traceback (most recent call last): File ./python-pygrass.py, line 293, in module r.sun(elevin=dem,albedo=b_albedo,glob_rad=b_rnet,lin=3.0,day=b_doy,time=float(local_time),quiet=QIET,overwrite=OVR) File /usr/local/grass-7.0.svn/etc/python/grass/pygrass/modules/interface/module.py, line 183, in __call__ self.inputs[key].value = val File /usr/local/grass-7.0.svn/etc/python/grass/pygrass/modules/interface/parameter.py, line 98, in _set_value (self.name, self.values)) ValueError: The Parameter time, must be one of: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24] -- ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
