Re: [GRASS-dev] [GRASS GIS] #2403: cairo driver fails to create surface
#2403: cairo driver fails to create surface
--+-
Reporter: martinl | Owner: martinl
Type: defect | Status: closed
Priority: major| Milestone: 7.0.0
Component: Display | Version: unspecified
Resolution: fixed|Keywords: cairo, resolution, surface
Platform: Linux| Cpu: x86-64
--+-
Comment(by glynn):
Replying to [comment:11 neteler]:
{{{
GRASS 7.0.0svn (eu_laea):~ time -p d.rast lst_2014_03_minimum
# comparison to see how long data reading itself takes:
GRASS 7.0.0svn (eu_laea):~ time -p r.stats lst_2014_03_minimum
}}}
FWIW, the comparison isn't particularly meaningful, as d.rast now only
needs to read the rows which are actually rendered, while r.stats needs to
read the entire map.
Beyond the need to uncompress entire rows, the rendering time should be
dictated by the output width, not the input width. However, d.rast's
values= feature adds overhead proportional to the input width.
Can you try commenting out the mask_raster_array() call at line 71 of
display/d.rast/display.c? If that has a significant impact, we should try
to skip that call altogether when values= isn't being used.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2403#comment:12
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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by neteler): Many more updates related to the new element name changes, I tried to catch all: * r63628 + r63629 update g.region/g.rename calls to use new element names * r63630 + r63631 update g.region/g.rename calls to use new element names While I was at it: * r63634 + r63635: some shell test scripts updated Now eagerly waiting for the nightly run of the testsuite at http://fatra.cnr.ncsu.edu/grassgistests/summary_report/index.html -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:144 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] #2403: cairo driver fails to create surface
#2403: cairo driver fails to create surface
--+-
Reporter: martinl | Owner: martinl
Type: defect | Status: closed
Priority: major| Milestone: 7.0.0
Component: Display | Version: unspecified
Resolution: fixed|Keywords: cairo, resolution, surface
Platform: Linux| Cpu: x86-64
--+-
Comment(by neteler):
Replying to [comment:12 glynn]:
Can you try commenting out the mask_raster_array() call at line 71 of
display/d.rast/display.c? If that has a significant impact, we should try
to skip that call altogether when values= isn't being used.
Sure. Test setting: connected from home via ssh/tsocks tunnel over ADSL
connection. Opening GRASS 7.0.svn (r63585) remotely, tunnelling wx0 over
network:
{{{
rows: 18711
cols: 22195
cells: 415290645
# original
d.mon wx0
time -p d.rast europe_altitude_map.shade
100%
real 4.64
user 0.93
sys 0.03
# with commented line of mask_raster_array() call
d.mon wx0 # ... previously opened monitor closed
time -p d.rast europe_altitude_map.shade
100%
real 0.92
user 0.91
sys 0.01
}}}
Probably that's significant.
Note: This is the time when d.rast finishes and returns to the command
line. The display in d.mon wx0 comes many seconds later but that's of
course a different issue.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2403#comment:13
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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by glynn): Replying to [comment:137 hcho]: No, not the last word of the option name. You cannot skip any words separated by an underscore. rm= is not ambiguous in this case because the shortest option name that matches rm= is raster_map=. If one wants raster_map2=, use rmap2=, not rm2= (no abbreviation inside a word). I mean the shortest option name with no more following underscores. 'r' for raster, 'm' for map, and no more underscores after 'raster_map'. This still has a couple of problems: 1. match_option() now needs to return the strength of a match, and the code which calls it (two places: once for option names, once for opt-options values) needs to consider this when determining whether a match is ambiguous. 2. match_option() now has to try to find a stronger match if there is one. E.g given an option named ab_b and an argument ab, the b can match the second letter of the first word or the first letter of the second word. Currently, it will find the first case and return. The change would require that it finds the first, but keeps searching for a stronger match in case an ambiguity subsequently needs to be resolved. The prefix rule suggested in [comment:101] also requires complicating the calling code, although it doesn't require changes to match_option() itself. Specifically, it needs to record all of the options which matched; it can't be reduced to finite state. But keeping track of which options matched would allow us to provide a more informative error message in the event that the given name is ambiguous (i.e. the error message could list all of the matches). The strength approach is perhaps a bit simpler to implement for the caller, in that it doesn't need to track which options matched, only the count and strength. If an option provides a strong match, and all prior matches are weak, it sets the match counter to one (discarding any number of weak matches). Once at least one strong match has been found, any weak matches will be ignored. At the end, a match is unambiguous if the count is one (i.e. one weak match and no strong matches, or one strong match and any number of weak matches). OTOH, it's also a bit less convenient, as the user has to provide some part of each word, even when this doesn't reduce the set of candidates. It's also possibly less clear to the user exactly what they should type to avoid the ambiguity. To be honest, the last point is my objection. I'd be less concerned about the increased complexity of match_option() if the result was an unambiguously better user experience (although I am slightly concerned about the possibility that match_option_1() might go from having exponential complexity in theory to actually having exponential complexity in practice). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:145 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation
--+-
Reporter: martinl | Owner: grass-dev@…
Type: task | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: unspecified
Keywords: standardized options |Platform: Unspecified
Cpu: Unspecified |
--+-
Comment(by neteler):
A question related to the match_option. It concerns the change with
potentially most impact in the next weeks regarding the users:
{{{
g.region rast=rastermap -p
ERROR: g.region: Sorry, rast= is ambiguous
# as it should now be
# g.region raster=rastermap -p
}}}
It would be very helpful to advertise the candidates here, like:
{{{
g.region rast=rastermap -p
ERROR: g.region: Sorry, rast= is ambiguous. Choices: raster,
raster_3d
}}}
Could that be implemented?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:146
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] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: reopened Priority: blocker | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Resolution:|Keywords: wingrass Platform: MSWindows XP | Cpu: Unspecified ---+ Comment(by martinl): Replying to [comment:63 martinl]: r62055 produces for GUI scripts (`d.rast3d` and `d.wms`) the BAT files. But when adding a new 3D raster map to the GUI it seems that instead of BAT file is launched PY file. I removed PY from PATHEXT in r63160, but it had no effect. Is there any way how to force launching BAT wrappers instead of PY scripts? Or it must be placed in different directories? any idea how to solve this issue? seems to be solved by r63592 (already backported to relbr70 as r63605). Since it's the last issue of this ticket I am taking liberty to close this ticket. Feel free to re-open if needed. -- Ticket URL: http://trac.osgeo.org/grass/ticket/580#comment:64 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] #580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
#580: WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run ---+ Reporter: hamish| Owner: grass-dev@… Type: defect| Status: closed Priority: blocker | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Resolution: fixed |Keywords: wingrass Platform: MSWindows XP | Cpu: Unspecified ---+ Changes (by martinl): * status: reopened = closed * resolution: = fixed -- Ticket URL: http://trac.osgeo.org/grass/ticket/580#comment:65 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:143 martinl]: Replying to [comment:142 neteler]: I suppose that view3d can be removed and region3d -- region_3d? AFAIS we don't need `region3d`? Region settings contains 3D info by default. since `G_ELEMENT_3DVIEW` and `G_ELEMENT_REGION3D` are not used in the code I took liberty to remove them in r63639. If no objection I will do backport to relbr70. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:147 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by neteler): Replying to [comment:147 martinl]: Replying to [comment:143 martinl]: Replying to [comment:142 neteler]: I suppose that view3d can be removed and region3d -- region_3d? AFAIS we don't need `region3d`? Region settings contains 3D info by default. since `G_ELEMENT_3DVIEW` and `G_ELEMENT_REGION3D` are not used in the code I took liberty to remove them in r63639. But also the code indicated in comment:142 should be cleaned at the same time. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:148 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] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by martinl): Replying to [comment:148 neteler]: since `G_ELEMENT_3DVIEW` and `G_ELEMENT_REGION3D` are not used in the code I took liberty to remove them in r63639. But also the code indicated in comment:142 should be cleaned at the same time. sure, done in r63642. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:149 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] #222: v.in gns broken in grass 7.0 trunk
#222: v.in gns broken in grass 7.0 trunk --+- Reporter: gisix| Owner: gisix Type: defect | Status: closed Priority: blocker | Milestone: 7.0.0 Component: Vector | Version: svn-trunk Resolution: fixed|Keywords: v.in.gns Platform: Linux| Cpu: x86-32 --+- Comment(by neteler): Replying to [comment:10 lucadelu]: I also moves the script to addons r62902 (it is possible to install it using g.extension). Since it is a functional addon now, removed from relbranch70 in r63648. -- Ticket URL: http://trac.osgeo.org/grass/ticket/222#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] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by neteler): Replying to [comment:144 neteler]: Many more updates related to the new element name changes, I tried to catch all: * still found more, especially in the test scripts. Fixed in r63644 + r63649. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:150 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] How to calculate log() in v.db.update with SQLite backend?
Markus Neteler wrote Works. Submitted to trunk in r63238. Please test (tomorrow) also on Windows if possible (the name will be something like libsqlitefunctions.dll which you need to provide to v.db.select). any idea where to find/to get libsqlitefunctions.dll for testing? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/How-to-calculate-log-in-v-db-update-with-SQLite-backend-tp5173670p5178691.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2409: last call for options keys consolidation
#2409: last call for options keys consolidation --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: blocker | Milestone: 7.0.0 Component: Default | Version: unspecified Keywords: standardized options |Platform: Unspecified Cpu: Unspecified | --+- Comment(by neteler): Updated temporal: renamed parameters extrdir/workdir - directory for consistency (as earlier done for other t.* modules) in r63650 + r63651 -- Ticket URL: http://trac.osgeo.org/grass/ticket/2409#comment:151 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] testsuite error messages analysed: some issues remaining
Hi devs,
I spent some time today to check all failing test in the test suite:
http://fatra.cnr.ncsu.edu/grassgistests/summary_report/index.html
DISCLAIMER:
== Important, only tomorrow, 21th, the testsuite on Vaclav's server
will run better since I submitted many fixes today ===
This understood, some results below.
I found a series of issues (those related to the element name changes
I fixed now) which I cannot solve myself:
### CTYPES PROBLEM:
In many tests I see this Deprecation Warning, can it be fixed?:
etc/python/grass/lib/gis.py:807: DeprecationWarning: classic int division
('__val', c_ulong * (1024 / (8 * sizeof(c_ulong,
Python/definition problems
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/gis/test_doctests/index.html
-- AttributeError: 'module' object has no attribute 'region'
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/lib/python/pygrass/shell/test_doctests/index.html
-- AttributeError: 'module' object has no attribute 'conversion'
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/lib/python/pygrass/test_doctests/index.html
-- NameError: name 'Region' is not defined
-- NameError: name 'reg' is not defined
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/lib/python/pygrass/raster/test_history/index.html
-- ?
NO IDEA problem
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/raster/r.profile/test_profile_ncspm/index.html
-- I don't know that the issue is
## JUNK REMAINED issue:
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/raster/r.in.poly/test_rinpoly/index.html
-- ERROR: option output: test_rinpoly exists.
Some overwrite flag needed?
But when I run it locally here:
Traceback (most recent call last):
File raster/r.in.poly/testsuite/test_rinpoly.py, line 107, in testLabels
msg=Labels do not match)
AssertionError: Labels do not match
'-8\t\n3\tlabel2\n10.01\tlabel1' != '-8\t\n3\tlabel2\n10.01'
## MISSING MAPS problems (in the piemonte location the names
differ, so they should be locally renamed):
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/vector/test_geometry/index.html
-- roadmajor does not exist in the server dataset
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/vector/test_vector/index.html
-- OpenError: Map points_of_interest not found.
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/lib/python/pygrass/vector/test_doctests/index.html
-- WARNING: census not found
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/vector/v.what/test_vwhat_ncspm/index.html
-- ERROR: Vector map bridges not found
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/raster/r.profile/test_profile_ncspm/index.html
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/raster/r.slope.aspect/test_r_slope_aspect/index.html
-- ERROR: Raster map elevation not found
etc.
## MISSING MAPS problems NC dataset:
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/lib/python/pygrass/vector/test_vector/index.html
-- OpenError: Map points_of_interest not found.
http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-12-20-08-00/report_for_nc_spm_08_grass7_nc/lib/python/pygrass/vector/test_doctests/index.html
-- WARNING: census not found
## Result is different problem
cd raster3d/r3.flow/testsuite/
python r3flow_test.py
mismatch values(key, reference, actual): [('coeff_var',
178.097935490306, 177.119169754436), ('max', 91, 89), ('range', 91,
89), ('stddev', 11.3685848821312, 11.3061070026581), ('variance',
129.2447, 127.82805556)]
command: r3.univar map=test_flowaccum percentile=90.0 separator== -g
{'map': 'test_flowaccum', 'separator': '=', 'flags': 'g'}
cd lib/python/pygrass/testsuite
python test_doctests.py
-- lot of issues
### DESIGN wish:
Each test page contains a title like this:
./vector/v.what – test_vwhat_layers
Could please the path to the file be added as
Testsuite: vector/v.what/testsuite/test_vwhat_layers.py
for easy copy-pasting in the local computer? Would be more joy for
fixing tests... thanks.
All fixes I have backported as well.
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
[GRASS-dev] On integrating i.fusion.hpf into i.pansharpen
Dear all, I want to integrate the AHPF fusion algorithm, i.fusion.hpf [0], into i.pansharpen [1]. And I need some assistance. 1. i.pansharpen has the following, simple, interface: i.pansharpen [-sl] red=name green=name blue=name pan=name output=basename method=value [--overwrite] [--help] [--verbose] [--quiet] [--ui] plus Flags: -s Serial processing rather than parallel processing -l Rebalance blue channel for LANDSAT while the HPF implementation looks like: i.fusion.hpf [-l2c] pan=filename msx=filename(s)[,filename(s),...] outputsuffix=suffix string [ratio=rational number] [center=string] [center2=string] [modulation=string] [modulation2=string] [trim=rational number] [--overwrite] [--help] [--verbose] [--quiet] [--ui] plus Flags: -l Linearly match histogram of Pan-sharpened output to Multi-Spectral input -2 2-Pass Processing (recommended) for large resolution ratio (=5.5) -c Match color table of Pan-Sharpened output to Multi-Spectral input While the first module appears to be simple and straightforward, it has its limitations (rgb required, underlying ihs method restricted to 8-bit data). The second module appears complex, but it works right away by simply feeding a pan and a multi-spectral band (or bands) and, offers many fine-tuning options. 2. i.pansharpen has the R-G-B logic hardcoded (one pan and three multi-spectral bands required), while i.fusion.hpf will work simply with a pan and only one or any number of multiple low-resolution bands. If all of the fine-tuning options for HPF will be merged into i.pansharpen, it'll get heavy and complex. I am asking for help to design the integration (not for the actual coding). Any ideas? Thank you, Nikos -- [0] https://github.com/NikosAlexandris/i.fusion.hpf [1] http://grass.osgeo.org/grass70/manuals/i.pansharpen.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
