[GRASS-dev] tickets to solve for GRASS 6.4.2 release

Markus_GRASS · August 31, 2011, 1:20pm

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

#995 WxGUI 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

hellik · August 31, 2011, 2:17pm

#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.

neteler · August 31, 2011, 2:32pm

On Wed, Aug 31, 2011 at 3:20 PM, Markus Metz
<markus.metz.giswork@googlemail.com> 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

Markus_GRASS · August 31, 2011, 2:59pm

On Wed, Aug 31, 2011 at 4:32 PM, Markus Neteler <neteler@osgeo.org> wrote:

On Wed, Aug 31, 2011 at 3:20 PM, Markus Metz
<markus.metz.giswork@googlemail.com> 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

martinl · August 31, 2011, 3:23pm

Hi,

2011/8/31 Markus Metz <markus.metz.giswork@googlemail.com>:

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 <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · August 31, 2011, 3:32pm

Hi,

2011/8/31 Markus Neteler <neteler@osgeo.org>:

* 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 <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · August 31, 2011, 3:33pm

Hi,

2011/8/31 Markus Metz <markus.metz.giswork@googlemail.com>:

#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 <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · August 31, 2011, 3:38pm

2011/8/31 Markus Metz <markus.metz.giswork@googlemail.com>:

#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 <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

martinl · August 31, 2011, 6:45pm

2011/8/31 Markus Neteler <neteler@osgeo.org>:

* 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 <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa

Hamish · August 31, 2011, 8:35pm

>#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

neteler · August 31, 2011, 9:24pm

On Wed, Aug 31, 2011 at 3:20 PM, Markus Metz
<markus.metz.giswork@googlemail.com> 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

Markus_GRASS · September 1, 2011, 3:29pm

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. 10000 areas it is
completely useless whereas v.rast.stats2 is 10000x 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

neteler · September 1, 2011, 5:55pm

On Thu, Sep 1, 2011 at 5:29 PM, Markus Metz
<markus.metz.giswork@googlemail.com> 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. 10000 areas it is
completely useless whereas v.rast.stats2 is 10000x 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

mlennert · September 2, 2011, 7:20am

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. 10000 areas it is
completely useless whereas v.rast.stats2 is 10000x 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

Markus_GRASS · September 2, 2011, 9:04am

On Fri, Sep 2, 2011 at 9:20 AM, Moritz Lennert
<mlennert@club.worldonline.be> 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. 10000 areas it is
completely useless whereas v.rast.stats2 is 10000x 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

marisn · September 2, 2011, 3:32pm

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 <markus.metz.giswork@googlemail.com>:

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

Hamish · September 3, 2011, 8:18am

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. 10000 areas it
is completely useless whereas v.rast.stats2 is 10000x 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

Markus_GRASS · September 5, 2011, 6:01am

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