Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
Hamish wrote: > [snip] to the end-user will the > upgrade be invisible except that it runs a lot faster now? As I said, v.rast.stats2 is meant to be a replacement for v.rast.stats: yes. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
Hamish: > > how do the two compare performance wise? are the options/ > > flags 100% backwards compatible? give identical results? Markus Metz: > We (you and me and others) had this exact discussion > previously. > Excerpts from the previous discussion: > > v.rast.stats does not scale at all, for e.g. 1 areas it > is completely useless whereas v.rast.stats2 is 1x faster, ok, thanks for the refresher. Mainly I am interested to know if the replacement preserves backwards compatibility both in terms of CLI and (meaingful) numerical results, and if it doesn't, what work is needed so that it does. i.e. to the end-user will the upgrade be invisible except that it runs a lot faster now? cheers, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
I added an extra warning in r48072 to tcl/tk startup screen [1] as it seems to not be possible to get GRASS running on Windows if user name contains non-latin letters. I strongly suggest to add extra error checking and implement a similar error message in wxgui startup screen too and close #995 as CANTFIX MS-WINDOWS BROKEN BY DESIGN [2]. Maris. PS. I would like to see r44890 in 6.4.2, as it has been doing just fine in 6.5 and waiting in backport queue for long time (8 months). 1. http://trac.osgeo.org/grass/changeset/48072 2. http://lists.osgeo.org/pipermail/grass-dev/2011-March/053874.html 2011/8/31 Markus Metz : > Hi all, > > the list of blocker and critical tickets for 6.4.2 is reassuringly short: > > #995 WxGUI startup screen fails if GISDBASE path contains non-latin > characters > --> needs testing with current svn > > > Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Fri, Sep 2, 2011 at 9:20 AM, Moritz Lennert wrote: > On 01/09/11 19:55, Markus Neteler wrote: >> >> On Thu, Sep 1, 2011 at 5:29 PM, Markus Metz >>> >>> v.rast.stats does not scale at all, for e.g. 1 areas it is >>> completely useless whereas v.rast.stats2 is 1x faster, e.g. 20 sec >>> vs 55 hours. That's the reason for the existence of v.rast.stats2 >>> making use of zonal statistics in r.univar, it's meant to be a >>> replacement, not something new. More details in the ML archives. >> >> +1 for update. > > For whatever its worth: +1 from me, too. > > I hardly dare propose using v.rast.stats to students in its current state, > unless they are working on really small numbers of areas, and I consider > this functionality to be such a basic function of a GIS that I really would > like to see it work. > Done in r48057-8, 6.4 and 6.5, respectively. 7.0 already uses a fast python version for some time. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On 01/09/11 19:55, Markus Neteler wrote: On Thu, Sep 1, 2011 at 5:29 PM, Markus Metz v.rast.stats does not scale at all, for e.g. 1 areas it is completely useless whereas v.rast.stats2 is 1x faster, e.g. 20 sec vs 55 hours. That's the reason for the existence of v.rast.stats2 making use of zonal statistics in r.univar, it's meant to be a replacement, not something new. More details in the ML archives. +1 for update. For whatever its worth: +1 from me, too. I hardly dare propose using v.rast.stats to students in its current state, unless they are working on really small numbers of areas, and I consider this functionality to be such a basic function of a GIS that I really would like to see it work. Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Thu, Sep 1, 2011 at 5:29 PM, Markus Metz wrote: > Hamish wrote: >>> >#1110 v.rast.stats locks up on wingrass >>> > --> I would suggest to replace v.rast.stats with >>> > v.rast.stats2 from addons with has enjoyed more >>> > maintenance and testing in the last months. >> >> devil's advocate: not more than the script itself :) > > No, as much as the script itself, plus recent bug fixes and enhancements. Hamish: it renders it from unusable to usable. >> how do the two compare performance wise? are the options/flags >> 100% backwards compatible? give identical results? >> > We (you and me and others) had this exact discussion previously. > Excerpts from the previous discussion: > > v.rast.stats does not scale at all, for e.g. 1 areas it is > completely useless whereas v.rast.stats2 is 1x faster, e.g. 20 sec > vs 55 hours. That's the reason for the existence of v.rast.stats2 > making use of zonal statistics in r.univar, it's meant to be a > replacement, not something new. More details in the ML archives. +1 for update. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
Hamish wrote: >> >#1110 v.rast.stats locks up on wingrass >> > --> I would suggest to replace v.rast.stats with >> > v.rast.stats2 from addons with has enjoyed more >> > maintenance and testing in the last months. > > devil's advocate: not more than the script itself :) No, as much as the script itself, plus recent bug fixes and enhancements. > > how do the two compare performance wise? are the options/flags > 100% backwards compatible? give identical results? > We (you and me and others) had this exact discussion previously. Excerpts from the previous discussion: v.rast.stats does not scale at all, for e.g. 1 areas it is completely useless whereas v.rast.stats2 is 1x faster, e.g. 20 sec vs 55 hours. That's the reason for the existence of v.rast.stats2 making use of zonal statistics in r.univar, it's meant to be a replacement, not something new. More details in the ML archives. >> > Or port some fixes from v.rast.stats2 to v.rast.stats, >> > particularly r43910. > > no opinion pending review. Pending for 11 months by now. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Wed, Aug 31, 2011 at 3:20 PM, Markus Metz wrote: > the list of blocker and critical tickets for 6.4.2 is reassuringly short: not to forget the list of backport candidates: http://trac.osgeo.org/grass/wiki/Grass6Planning Some may be interesting and have hopefully received enough testing in 6.5 (= devbr6). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
> >#1110 v.rast.stats locks up on wingrass > > --> I would suggest to replace v.rast.stats with > > v.rast.stats2 from addons with has enjoyed more > > maintenance and testing in the last months. devil's advocate: not more than the script itself :) how do the two compare performance wise? are the options/flags 100% backwards compatible? give identical results? > > Or port some fixes from v.rast.stats2 to v.rast.stats, > > particularly r43910. no opinion pending review. Helmut wrote: > see > http://trac.osgeo.org/grass/ticket/1110#comment:11 > http://trac.osgeo.org/grass/ticket/1110#comment:16 > > I've committed patches for grass64, grass65, grass79 for > the path issue and tested an a few win-boxes. work here, > but a little more testing is welcomed. I strongly suspect that Helmut's fix there will also solve a whole bunch of weird problems that people may have been experiencing with wingrass, both reported and not. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Wed, Aug 31, 2011 at 9:48 PM, Michael Barton wrote: > I'll test. This is 6.4 svn, 6.5, or 7? devbr6, so 6.5.svn. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
I'll test. This is 6.4 svn, 6.5, or 7? Michael __ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Aug 31, 2011, at 12:29 PM, Martin Landa wrote: > 2011/8/31 Martin Landa : >> 2011/8/31 Markus Neteler : >>> On Wed, Aug 31, 2011 at 7:20 PM, Markus Metz >>> wrote: Regarding the import/link dialogs, I had a look at GdalImportDialog in gdialogs.py. Maybe the easiest would be to replace the format selector with a simple text field where the user can enter a file extension which will then be used to filter files, plus a button to apply the filter. >> >> I would not replace format selector, we can just add textctrl where >> user can type alternative extension. Will do it. > > please try r48008 (devbr6). > > * choose directory mode > * set directory name > * set format > * change extension, list of layer updated > > Martin > > -- > Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Wed, Aug 31, 2011 at 9:29 PM, Martin Landa wrote: > 2011/8/31 Martin Landa : >> 2011/8/31 Markus Neteler : >>> On Wed, Aug 31, 2011 at 7:20 PM, Markus Metz >>> wrote: Regarding the import/link dialogs, I had a look at GdalImportDialog in gdialogs.py. Maybe the easiest would be to replace the format selector with a simple text field where the user can enter a file extension which will then be used to filter files, plus a button to apply the filter. >> >> I would not replace format selector, we can just add textctrl where >> user can type alternative extension. Will do it. > > please try r48008 (devbr6). > > * choose directory mode > * set directory name > * set format > * change extension, list of layer updated Cool. I backported both r48007 and r48008 to my local 6.4 and it works for me. Small obstacle: some (many?) formats come with predefined extension, others not. If that could be completely populated to have one default extension per format, that would be perfect. I can help to populate the list. Or just do that for those extensions not being delivered from GDAL? I am not sure why some have a default extension and others not. The list of default GDAL raster extensions is coded here: grep GDAL_DMD_EXTENSION frmts/*/*.cpp frmts/aaigrid/aaigriddataset.cpp:poDriver->SetMetadataItem( GDAL_DMD_EXTENSION, "asc" ); frmts/adrg/adrgdataset.cpp:poDriver->SetMetadataItem( GDAL_DMD_EXTENSION, "gen" ); frmts/adrg/srpdataset.cpp:poDriver->SetMetadataItem( GDAL_DMD_EXTENSION, "img" ); ... and for OGR: grep CPLGetExtension ogr/ogrsf_frmts/*/*.cpp | grep pszFilename ogr/ogrsf_frmts/aeronavfaa/ograeronavfaadatasource.cpp: !EQUAL(CPLGetExtension(pszFilename), "dat") ) ogr/ogrsf_frmts/bna/ogrbnadatasource.cpp:if( !(EQUAL( CPLGetExtension(pszFilename), "bna" ) ogr/ogrsf_frmts/dwg/ogrdwgdatasource.cpp:if( !EQUAL(CPLGetExtension(pszFilename),"dwg") ) ... Maybe not really helpful but to populate/check the list. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
2011/8/31 Martin Landa : > 2011/8/31 Markus Neteler : >> On Wed, Aug 31, 2011 at 7:20 PM, Markus Metz >> wrote: >>> Regarding the import/link dialogs, I had a look at GdalImportDialog in >>> gdialogs.py. Maybe the easiest would be to replace the format selector >>> with a simple text field where the user can enter a file extension >>> which will then be used to filter files, plus a button to apply the >>> filter. > > I would not replace format selector, we can just add textctrl where > user can type alternative extension. Will do it. please try r48008 (devbr6). * choose directory mode * set directory name * set format * change extension, list of layer updated Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
2011/8/31 Markus Neteler : > On Wed, Aug 31, 2011 at 7:20 PM, Markus Metz > wrote: >> Regarding the import/link dialogs, I had a look at GdalImportDialog in >> gdialogs.py. Maybe the easiest would be to replace the format selector >> with a simple text field where the user can enter a file extension >> which will then be used to filter files, plus a button to apply the >> filter. I would not replace format selector, we can just add textctrl where user can type alternative extension. Will do it. Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
2011/8/31 Markus Neteler : > * raster importer: when changing format, the selected directory is > cleared but should remain > --> open I cannot reproduce it with 6.4.2, when changing format selected directory is not changed or cleared. Anyway I found another bug, when changing format list of layers should be reloaded respectively. It should be fixed in devbr6 (r48007). Please test it, then it could be backported to relbr64. I have created ticket for this issue [1]. Martin [1] http://trac.osgeo.org/grass/ticket/1432 -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Wed, Aug 31, 2011 at 7:20 PM, Markus Metz wrote: > Regarding the import/link dialogs, I had a look at GdalImportDialog in > gdialogs.py. Maybe the easiest would be to replace the format selector > with a simple text field where the user can enter a file extension > which will then be used to filter files, plus a button to apply the > filter. Yes, something like in the "downloadthemAll" Firefox extension would be neat. > Otherwise the import dialog must come up with a list of all possible > file name extensions associated to a GDAL/OGR format. ... which are sometimes hard to guess since people invent all kind of unusual extensions for regular formats... > Bearing in mind > that e.g. Linux does not need any file name extensions and extensions > can be completely arbitrary, the import dialog can not possibly be > clever enough to cater for all possibilities. > > Just a suggestion, A nice one. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
2011/8/31 Michael Barton : > PS. When I tried to work it out in 7, there *seemed* to be a number of bugs > with lines not connecting, shapes not appearing, buttons not responding. But > sometimes it worked and sometimes not. If I can figure out how it is supposed > to work it will be easier to ID bugs to fix. I'll try it more this week and > weekend and see how it goes. usually you don't need to define relations manually, they are defined automatically by actions. Please report concrete bugs on trac. Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Aug 31, 2011, at 10:09 AM, Martin Landa wrote: > 2011/8/31 Michael Barton : >> If raster importer and graphical modeler are removed, then it seems from >> other posts that all blocker items are resolved. We we want to consider >> keeping either of these, it sounds from the error report that the raster >> importer bug may be relatively easy to fix. The modeler is very cool but >> still in > > better fix then remove... Well, reported issue about modeler is wish, not bug. > >> development AFAICT. I'll try some more testing. In any case, the modeler >> must have docs before any real release. > > Feel free to extent the documentation... BTW, there is not only > modeler with incomplete docs... > > Martin > > -- > Martin Landa * http://geo.fsv.cvut.cz/~landa PS. When I tried to work it out in 7, there *seemed* to be a number of bugs with lines not connecting, shapes not appearing, buttons not responding. But sometimes it worked and sometimes not. If I can figure out how it is supposed to work it will be easier to ID bugs to fix. I'll try it more this week and weekend and see how it goes. Michael___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
I have to know how it works to write the docs. If I have a chance to work it out I can add to them. Michael __ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www:http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Aug 31, 2011, at 10:09 AM, Martin Landa wrote: > 2011/8/31 Michael Barton : >> If raster importer and graphical modeler are removed, then it seems from >> other posts that all blocker items are resolved. We we want to consider >> keeping either of these, it sounds from the error report that the raster >> importer bug may be relatively easy to fix. The modeler is very cool but >> still in > > better fix then remove... Well, reported issue about modeler is wish, not bug. > >> development AFAICT. I'll try some more testing. In any case, the modeler >> must have docs before any real release. > > Feel free to extent the documentation... BTW, there is not only > modeler with incomplete docs... > > Martin > > -- > Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Wed, Aug 31, 2011 at 7:09 PM, Martin Landa wrote: > 2011/8/31 Michael Barton : >> If raster importer and graphical modeler are removed, then it seems from >> other posts that all blocker items are resolved. We we want to consider >> keeping either of these, it sounds from the error report that the raster >> importer bug may be relatively easy to fix. The modeler is very cool but >> still in > > better fix then remove... Well, reported issue about modeler is wish, not bug. Regarding the import/link dialogs, I had a look at GdalImportDialog in gdialogs.py. Maybe the easiest would be to replace the format selector with a simple text field where the user can enter a file extension which will then be used to filter files, plus a button to apply the filter. Otherwise the import dialog must come up with a list of all possible file name extensions associated to a GDAL/OGR format. Bearing in mind that e.g. Linux does not need any file name extensions and extensions can be completely arbitrary, the import dialog can not possibly be clever enough to cater for all possibilities. Just a suggestion, Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
2011/8/31 Michael Barton : > If raster importer and graphical modeler are removed, then it seems from > other posts that all blocker items are resolved. We we want to consider > keeping either of these, it sounds from the error report that the raster > importer bug may be relatively easy to fix. The modeler is very cool but > still in better fix then remove... Well, reported issue about modeler is wish, not bug. > development AFAICT. I'll try some more testing. In any case, the modeler must > have docs before any real release. Feel free to extent the documentation... BTW, there is not only modeler with incomplete docs... Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Aug 31, 2011, at 8:05 PM, grass-dev-requ...@lists.osgeo.org wrote: > Date: Wed, 31 Aug 2011 16:59:04 +0200 > From: Markus Metz > Subject: Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release > To: GRASS developers list > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Aug 31, 2011 at 4:32 PM, Markus Neteler wrote: >> On Wed, Aug 31, 2011 at 3:20 PM, Markus Metz >> wrote: >>> Hi all, >>> >>> the list of blocker and critical tickets for 6.4.2 is reassuringly short: >> >> Here some more issues (GRASS 6.4 bugs and wishes from Geostat2011): >> > Some of the new wxGUI features are experimental. If we decide on > feature freeze, these features must be removed. If we decide on > keeping and fixing them, this will delay the 6.4.2 release because the > time needed to fix them is a function of the number of devs looking at > these features x the time these devs have x the complexity of these > features. > > New features in the wxGUI are often applied to all branches at once > and haven't enjoyed a lot of testing. IMHO this is a question of > keeping this door to 6.4.2 open or close it. >> >> *. hard-coded file extensions in wxGUI raster import, breaks with >> non-standard suffix + raster importer: .asc is not supported for >> ArcINFO ASCII files when using directory bulk import >> --> we would need a list of allowed extensions per format (see >> gui/wxpython/gui_modules/gselect.py) >> > The new raster importer is fairly new and experimental and somehow > sneaked into 6.4.2 > >> * raster importer: when changing format, the selected directory is >> cleared but should remain >> --> open > The new raster importer is fairly new and experimental and somehow > sneaked into 6.4.2 > The standard r.in.gdal GUI works fine. >> >> * graphical modeler: dynamically read in module list + path >> --> the locally installed Addons are not shown in the list. >> ==> right, addons are also not shown in the search tree or the menu, >> please report it on trac >> Reported as: http://trac.osgeo.org/grass/ticket/1420 >> --> open > The new graphical modeler is fairly new and experimental and somehow > sneaked into 6.4.2 >> >> * display of attrcol in windows wxGUI crashes (d.vect) >> --> open > This is #1184, right? Should be fixed together with #1158, to be confirmed. >> >> * wxGUI windows: manuals tab: bind arrow keys / pgup / pgdown to >> scrolling for easier navigation >> - ML: it's working for me, you just need to click on the manual for >> the focus. Do you mean to set the focus automatically when the page is >> entered? >> - MM: this focus thing is a bit difficult, and dangerous to fiddle >> around with because MS Windows has different focus ?handling than >> Linux/Mac --> preserve portability >> --> open > I tend to say --> won't fix or worksforme because in MS Windows you > have to set the focus manually to a window before you can use arrow > keys / pgup / pgdown / tab to navigate between fields within that > window. If that is changed, the default OS behaviour is changed which > is probably causing confusion and trouble. > > Markus M If raster importer and graphical modeler are removed, then it seems from other posts that all blocker items are resolved. We we want to consider keeping either of these, it sounds from the error report that the raster importer bug may be relatively easy to fix. The modeler is very cool but still in development AFAICT. I'll try some more testing. In any case, the modeler must have docs before any real release. Michael___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
2011/8/31 Markus Metz : > #1132 wxNviz and wxVdigit missing from 6.4svn > --> is this really critical for 6.4.2? nviz and v.digit are working AFAIK closed as 'wontfix' Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
Hi, 2011/8/31 Markus Metz : > #1132 wxNviz and wxVdigit missing from 6.4svn > --> is this really critical for 6.4.2? nviz and v.digit are working AFAIK critical is only wxVdigit which was planned for 6.4.2... Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
Hi, 2011/8/31 Markus Neteler : > * WX-GUI table view: selection by attribute crashes when the datatype > of the column doesn't match the datatype of the query condition. This > happens when quotes are used with a numeric column type, or when no > quotes are used with a character type. > try r47334 (trunk), backported to devbr6 in r47335 > --> to be tested and backported to 6.4 bug-fix, backport for 6.4.2 should be done. > * v.digit, when creating a new map, bring immediately the att table > manager up for definition of new table > try r47337 (trunk), backported to devbr6 in r47338 > --> to be tested and backported to 6.4 enhancement, I would in incline to backport for 6.4.2. For any case digitizer is quite unstable (please test it, report bugs or wished on trac). Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
Hi, 2011/8/31 Markus Metz : > New features in the wxGUI are often applied to all branches at once > and haven't enjoyed a lot of testing. IMHO this is a question of > keeping this door to 6.4.2 open or close it. to correct a bit: I am applying patches in all active branches only in the first half of release circle, ie. 2(3) months after 6.4.1 has been released (April). Since July only bug-fixes should go to relbr64. For features which have been introduced in April/May/June you have at least 3 months for testing. Martin -- Martin Landa * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Wed, Aug 31, 2011 at 4:32 PM, Markus Neteler wrote: > On Wed, Aug 31, 2011 at 3:20 PM, Markus Metz > wrote: >> Hi all, >> >> the list of blocker and critical tickets for 6.4.2 is reassuringly short: > > Here some more issues (GRASS 6.4 bugs and wishes from Geostat2011): > Some of the new wxGUI features are experimental. If we decide on feature freeze, these features must be removed. If we decide on keeping and fixing them, this will delay the 6.4.2 release because the time needed to fix them is a function of the number of devs looking at these features x the time these devs have x the complexity of these features. New features in the wxGUI are often applied to all branches at once and haven't enjoyed a lot of testing. IMHO this is a question of keeping this door to 6.4.2 open or close it. > > *. hard-coded file extensions in wxGUI raster import, breaks with > non-standard suffix + raster importer: .asc is not supported for > ArcINFO ASCII files when using directory bulk import > --> we would need a list of allowed extensions per format (see > gui/wxpython/gui_modules/gselect.py) > The new raster importer is fairly new and experimental and somehow sneaked into 6.4.2 > * raster importer: when changing format, the selected directory is > cleared but should remain > --> open The new raster importer is fairly new and experimental and somehow sneaked into 6.4.2 The standard r.in.gdal GUI works fine. > > * graphical modeler: dynamically read in module list + path > --> the locally installed Addons are not shown in the list. > ==> right, addons are also not shown in the search tree or the menu, > please report it on trac > Reported as: http://trac.osgeo.org/grass/ticket/1420 > --> open The new graphical modeler is fairly new and experimental and somehow sneaked into 6.4.2 > > * display of attrcol in windows wxGUI crashes (d.vect) > --> open This is #1184, right? Should be fixed together with #1158, to be confirmed. > > * wxGUI windows: manuals tab: bind arrow keys / pgup / pgdown to > scrolling for easier navigation > - ML: it's working for me, you just need to click on the manual for > the focus. Do you mean to set the focus automatically when the page is > entered? > - MM: this focus thing is a bit difficult, and dangerous to fiddle > around with because MS Windows has different focus handling than > Linux/Mac --> preserve portability > --> open I tend to say --> won't fix or worksforme because in MS Windows you have to set the focus manually to a window before you can use arrow keys / pgup / pgdown / tab to navigate between fields within that window. If that is changed, the default OS behaviour is changed which is probably causing confusion and trouble. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] tickets to solve for GRASS 6.4.2 release
On Wed, Aug 31, 2011 at 3:20 PM, Markus Metz wrote: > Hi all, > > the list of blocker and critical tickets for 6.4.2 is reassuringly short: Here some more issues (GRASS 6.4 bugs and wishes from Geostat2011): * WX-GUI table view: selection by attribute crashes when the datatype of the column doesn't match the datatype of the query condition. This happens when quotes are used with a numeric column type, or when no quotes are used with a character type. try r47334 (trunk), backported to devbr6 in r47335 --> to be tested and backported to 6.4 *. hard-coded file extensions in wxGUI raster import, breaks with non-standard suffix + raster importer: .asc is not supported for ArcINFO ASCII files when using directory bulk import --> we would need a list of allowed extensions per format (see gui/wxpython/gui_modules/gselect.py) * raster importer: when changing format, the selected directory is cleared but should remain --> open * graphical modeler: dynamically read in module list + path --> the locally installed Addons are not shown in the list. ==> right, addons are also not shown in the search tree or the menu, please report it on trac Reported as: http://trac.osgeo.org/grass/ticket/1420 --> open * v.digit, when creating a new map, bring immediately the att table manager up for definition of new table try r47337 (trunk), backported to devbr6 in r47338 --> to be tested and backported to 6.4 * display of attrcol in windows wxGUI crashes (d.vect) --> open * wxGUI windows: manuals tab: bind arrow keys / pgup / pgdown to scrolling for easier navigation - ML: it's working for me, you just need to click on the manual for the focus. Do you mean to set the focus automatically when the page is entered? - MM: this focus thing is a bit difficult, and dangerous to fiddle around with because MS Windows has different focus handling than Linux/Mac --> preserve portability --> open Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] tickets to solve for GRASS 6.4.2 release
>#1110 v.rast.stats locks up on wingrass > --> I would suggest to replace v.rast.stats with v.rast.stats2 from >addons with has enjoyed more maintenance and testing in the last >months. Or port some fixes from v.rast.stats2 to v.rast.stats, >particularly r43910. see http://trac.osgeo.org/grass/ticket/1110#comment:11 http://trac.osgeo.org/grass/ticket/1110#comment:16 I've committed patches for grass64, grass65, grass79 for the path issue and tested an a few win-boxes. work here, but a little more testing is welcomed. Helmut -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/tickets-to-solve-for-GRASS-6-4-2-release-tp6746494p6746713.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
[GRASS-dev] tickets to solve for GRASS 6.4.2 release
Hi all, the list of blocker and critical tickets for 6.4.2 is reassuringly short: #1158 Removing vector map in Windows fails with "Unable to delete vector map" --> fixed, awaits confirmation #1380 GRASS6.4.1 WX-Python GUI, menu does not work at all --> probably fixed, awaits confirmation #995WxGUI startup screen fails if GISDBASE path contains non-latin characters --> needs testing with current svn #1110 v.rast.stats locks up on wingrass --> I would suggest to replace v.rast.stats with v.rast.stats2 from addons with has enjoyed more maintenance and testing in the last months. Or port some fixes from v.rast.stats2 to v.rast.stats, particularly r43910. #1132 wxNviz and wxVdigit missing from 6.4svn --> is this really critical for 6.4.2? nviz and v.digit are working AFAIK #1184 "d.vect display=attr" imply grass open process but doesn't close them. --> most probably fixed together with #1158 because it is the same problem of the DBMI driver not shutting down #1358 WinGRASS 6.4.1: SQLite driver errors: `Unable to open database' --> needs testing with current svn #1388 r3.univar gives bad results for cell counts --> fixed in June 2011 in all branches, awaits confirmation 2 are open: #995, #1358, one ticket (#1132) may need re-evaluation of the priority, the remaining tickets are fixed, awaiting confirmation. The only blocker is #1380 because #1158 is fixed. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
