[GRASS-dev] 6.4.0 blocker bugs

[hellik]

[...]
  On Wed, Aug 18, 2010 at 5:26 AM, Hamish <[hamish_b at yahoo.com]> wrote:
...

Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with
~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with
the wxGUI.

At this point we should do it for the rest of the users, too. I'd
really like to avoid to
be flooded with messages of "where is the new GUI??" content since the
standard Linux distros will package whatever is set in the software.

Markus

there was so much effort to create a new and working gui (wxgui) which will be the next generation
user interface.

IMHO this should be honored a lot and the wxgui should be considered as the default in the upcoming grass64-release,
mainly to get feedback and being able to improve this interface.

on windows - I've played a lot with grass64/65/70-versions - I've almost never used the tcltk-gui.

so I vote for wxgui as the default for all os-platforms.

best regards
Helmut
___________________________________________________________
Neu: WEB.DE De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: https://produkte.web.de/go/demail02

[martinl]

Hi,

2010/8/23 Helmut Kudrnovsky <hellik@web.de>:

Finally, for the FOSS4G 2010 OSGeo Live GIS disc I have packaged it with
~/.grassrc6 containing GRASS_GUI=wxpython, so there Linux starts with
the wxGUI.

At this point we should do it for the rest of the users, too. I'd
really like to avoid to
be flooded with messages of "where is the new GUI??" content since the
standard Linux distros will package whatever is set in the software.

Markus

there was so much effort to create a new and working gui (wxgui) which will be the next generation
user interface.

from my point of view is unacceptable to change the default GUI
(DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e. before
releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0.

IMHO this should be honored a lot and the wxgui should be considered as the default in the upcoming grass64-release,
mainly to get feedback and being able to improve this interface.

on windows - I've played a lot with grass64/65/70-versions - I've almost never used the tcltk-gui.

so I vote for wxgui as the default for all os-platforms.

As a wxGUI developer I cannot judge which GUI should be default.

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[Hamish]

Martin wrote:

from my point of view is unacceptable to change the default
GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e.
before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0.

I don't think it harms backwards compatibility too badly to
adjust GUI things (scripts+code will still work), but y'all
make a good point that tutorials and screenshot guides will
suffer in this case. We can get around the "don't make big
policy changes right before release" rule by shipping one last
RC; I would hope the the final 6.4.0 could go out after that
rather quickly (maybe a week?). So RC7 in the next 24 hrs and
6.4.0 some time before Helena's plenary session on Sept 8th?
(as long as no problems are found within that time..)

(comments? objections? better ideas?)

I think we all agree that by 6.4.1 wx should be the default,
and that big changes are bad within a stable release. Since
we have had so many RCs wx is now in good shape in the stable
branch, ready for more eyeballs. so ok with me to be the default,
so long as that change gets tested.

I would note that besides init.sh there is also line 83 of
g.gui/main.c to change in relbr64 to alter the default GUI
(which GUI to start if "GRASS_GUI=text"), and a grep of the
docs/announcements.

We would have to check that it fail-overs back to tcltk if
tcl is there but wx is not. (I have a Debian/etch machine sitting
around I can test that on)

fwiw, changing it manually is not /too/ hard to find:
  Config -> GRASS working enivronment -> Change default GUI
... but you have to know about it before you'd ever think to look.

As for ctypes backports, AFAICT that is not well tested in 6.5
yet, so I'm a bit worried to put it into 6.4 yet. Is it just
copying in lib/python/ctypes/, or are other structural changes
that need to be coordinated with that? As AFAIK it is "only" a
new feature, and not really a policy change or bugfix, so I see
no problem to wait for 6.4.1, 4 weeks or so after the main
release.

cheers,
Hamish

ps- I wonder if we should really expose g.mapset in the GUI
menu? Some "Advanced" features are best hidden from new users..
(& I take it that works well from the now?) or at least only
let them change mapset from there, to limit damage/confusion.
(??)

[martinl]

Hi,

2010/8/24 Hamish <hamish_b@yahoo.com>:

from my point of view is unacceptable to change the default
GUI (DEFAULT_GUI in init.sh) within 6.4.x. Change it now (i.e.
before releasing 6.4.0) or leave it for 6.5 (6.6) or 7.0.

I don't think it harms backwards compatibility too badly to
adjust GUI things (scripts+code will still work), but y'all
make a good point that tutorials and screenshot guides will
suffer in this case. We can get around the "don't make big
policy changes right before release" rule by shipping one last
RC; I would hope the the final 6.4.0 could go out after that
rather quickly (maybe a week?). So RC7 in the next 24 hrs and
6.4.0 some time before Helena's plenary session on Sept 8th?
(as long as no problems are found within that time..)

(comments? objections? better ideas?)

I think we all agree that by 6.4.1 wx should be the default,
and that big changes are bad within a stable release. Since
we have had so many RCs wx is now in good shape in the stable
branch, ready for more eyeballs. so ok with me to be the default,
so long as that change gets tested.

I would note that besides init.sh there is also line 83 of
g.gui/main.c to change in relbr64 to alter the default GUI
(which GUI to start if "GRASS_GUI=text"), and a grep of the
docs/announcements.

We would have to check that it fail-overs back to tcltk if
tcl is there but wx is not. (I have a Debian/etch machine sitting
around I can test that on)

fwiw, changing it manually is not /too/ hard to find:
Config -> GRASS working enivronment -> Change default GUI
... but you have to know about it before you'd ever think to look.

OK, if I understand well, you are suggesting to change the default GUI
to wxpython, release today/tomorrow RC7 and within one week to release
6.4.0, is it right? If so, I agree.

As for ctypes backports, AFAICT that is not well tested in 6.5
yet, so I'm a bit worried to put it into 6.4 yet. Is it just
copying in lib/python/ctypes/, or are other structural changes
that need to be coordinated with that? As AFAIK it is "only" a
new feature, and not really a policy change or bugfix, so I see
no problem to wait for 6.4.1, 4 weeks or so after the main
release.

OK, ctypes is quite advance feature and will be used by wxNviz and
wxVdigit (not ready). So it can wait for 6.4.1. It's just not a
standard approach to add new features within x.y.z. On the other hand,
1.5 year for RCs is also not standard

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[neteler]

On Tue, Aug 24, 2010 at 11:28 AM, Hamish <hamish_b@yahoo.com> wrote:

We can get around the "don't make big
policy changes right before release" rule by shipping one last
RC; I would hope the the final 6.4.0 could go out after that
rather quickly (maybe a week?). So RC7 in the next 24 hrs and
6.4.0 some time before Helena's plenary session on Sept 8th?

Yes.

Please change the default GUI and I'll prepare RC7 then immediately.

Markus

[Hamish]

Markus wrote:

Please change the default GUI and I'll prepare RC7 then
immediately.

the change is now done.

Hamish

[Hamish]

Markus wrote:

Please change the default GUI and I'll prepare RC7 then
immediately.

release summary now prepared from svn log:
  https://trac.osgeo.org/grass/wiki/Release/6.4.0RC7-News

(except for final details of course..)

clean as needed, enjoy the new trac wiki edit-by-section, just
click on the hidden [edit] to the right of each section heading.

e.g. I'm sure
"r.watershed: upgraded to improved version"
and r.out.gdal improvements could be better explained.

Hamish

[martinl]

Hi,

2010/8/24 Hamish <hamish_b@yahoo.com>:

Please change the default GUI and I'll prepare RC7 then
immediately.

winGRASS for quick testing is available at

http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r43230-1-Setup.exe

Martin

--
Martin Landa <landa.martin gmail.com> * http://gama.fsv.cvut.cz/~landa

[William_Kyngesburye]

On Aug 24, 2010, at 7:55 AM, Hamish wrote:

Markus wrote:

Please change the default GUI and I'll prepare RC7 then
immediately.

release summary now prepared from svn log:
https://trac.osgeo.org/grass/wiki/Release/6.4.0RC7-News

(except for final details of course..)

clean as needed, enjoy the new trac wiki edit-by-section, just
click on the hidden [edit] to the right of each section heading.

e.g. I'm sure
"r.watershed: upgraded to improved version"
and r.out.gdal improvements could be better explained.

Hamish

I updated the Mac startup so it should let init.sh set the default.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war

[Helena_Mitasova]

Has anybody tried to run r.in.poly with lat/long data in GRASS64 - it appears to be broken.
It creates a raster map with NULLs on my Mac RC6 version and apparently on linux as well -
see the message below. My colleagues at the Climate Center had to switch to GRASS63 to get their
Mapserver/OpenLayers application run with GRASS. I checked the repository and no changes were
made for past 21 months except for input=- option so I am not sure whether this is a bug or
we are just doing something wrong.

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/r.in.poly

Below is the test example and the related nc_ll LOCATION, but it would be good to try it on some other data.
If this is a bug I would consider it critical because many people are trying to run GRASS with WebGIS
and drawing a polygon and then getting a report on what is inside that polygon or running some more complex
analysis on it is among the most common tasks that people try to do that I have seen.

thanks for looking into this (we really don't want people to go back to 6.3),

Helena

So for r.in.poly, we needed to use lat/lon coordinates (i.e. didn't use coordinates in meters like you tested out) -- not only because the Mapserver/Open Layers stuff we created was giving the coordinates in lat/lon, but also because our projection was in lat/lon. That file looked like this:

A
-78.254 35.82
-78.005 36.201
-77.707 36.135
-77.84 35.853
-78.196 35.721
= 1 coord

So when we ran the r.in.poly function, no errors were output -- it appeared as though the layer had been created properly. But when we tried to actually display the layer with the polygon, we found that no actual polygon with those lat/lon coordinates as vertices was ever created.
Another co-worker in my office had GRASS 6.3 on his Linux machine, and when we tried running the r.in.poly function with lat/lon coordinates on his machine, it worked beautifully. That prompted us to put GRASS 6.3 on the other machines we had been using and take off the 6.4 RC versions -- and with 6.3, everything worked as expected.

http://courses.ncsu.edu/mea582/common/media/01/nc_ll.zip

[neteler]

On Thu, Aug 26, 2010 at 5:32 PM, Helena Mitasova <hmitaso@unity.ncsu.edu> wrote:

Has anybody tried to run r.in.poly with lat/long data in GRASS64 - it appears to be broken.

r.in.poly in=gg.txt out=gg
g.region rast=gg
r.univar gg

g.region n=36.201 s=35.721 e=-77.707 w=-77.84 -g res=1
r.in.poly in=gg.txt out=gg --o
r.univar gg
-> nan

I can confirm that the imported polygon is not generated (nor an error).
Using 6.4.svn on 64bit Linux.

Markus

It creates a raster map with NULLs on my Mac RC6 version and apparently on linux as well -
see the message below. My colleagues at the Climate Center had to switch to GRASS63 to get their
Mapserver/OpenLayers application run with GRASS. I checked the repository and no changes were
made for past 21 months except for input=- option so I am not sure whether this is a bug or
we are just doing something wrong.

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/r.in.poly

Below is the test example and the related nc_ll LOCATION, but it would be good to try it on some other data.
If this is a bug I would consider it critical because many people are trying to run GRASS with WebGIS
and drawing a polygon and then getting a report on what is inside that polygon or running some more complex
analysis on it is among the most common tasks that people try to do that I have seen.

thanks for looking into this (we really don't want people to go back to 6.3),

Helena

So for r.in.poly, we needed to use lat/lon coordinates (i.e. didn't use coordinates in meters like you tested out) -- not only because the Mapserver/Open Layers stuff we created was giving the coordinates in lat/lon, but also because our projection was in lat/lon. That file looked like this:

A
-78.254 35.82
-78.005 36.201
-77.707 36.135
-77.84 35.853
-78.196 35.721
= 1 coord

So when we ran the r.in.poly function, no errors were output -- it appeared as though the layer had been created properly. But when we tried to actually display the layer with the polygon, we found that no actual polygon with those lat/lon coordinates as vertices was ever created.
Another co-worker in my office had GRASS 6.3 on his Linux machine, and when we tried running the r.in.poly function with lat/lon coordinates on his machine, it worked beautifully. That prompted us to put GRASS 6.3 on the other machines we had been using and take off the 6.4 RC versions -- and with 6.3, everything worked as expected.

http://courses.ncsu.edu/mea582/common/media/01/nc_ll.zip

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[marisn]

I'm sorry to dissapoint both of You, provided example works just fine
with current 6.4 SVN on 64bit Linux (Gentoo ~AMD64). Could this be
related to input file formating?

Please open an ticket and attach sample input file and exact commands to use.

Maris.

2010/8/26, Markus Neteler <neteler@osgeo.org>:

On Thu, Aug 26, 2010 at 5:32 PM, Helena Mitasova <hmitaso@unity.ncsu.edu>
wrote:

Has anybody tried to run r.in.poly with lat/long data in GRASS64 - it
appears to be broken.

r.in.poly in=gg.txt out=gg
g.region rast=gg
r.univar gg

g.region n=36.201 s=35.721 e=-77.707 w=-77.84 -g res=1
r.in.poly in=gg.txt out=gg --o
r.univar gg
-> nan

I can confirm that the imported polygon is not generated (nor an error).
Using 6.4.svn on 64bit Linux.

Markus

It creates a raster map with NULLs on my Mac RC6 version and apparently on
linux as well -
see the message below. My colleagues at the Climate Center had to switch
to GRASS63 to get their
Mapserver/OpenLayers application run with GRASS. I checked the repository
and no changes were
made for past 21 months except for input=- option so I am not sure whether
this is a bug or
we are just doing something wrong.

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/r.in.poly

Below is the test example and the related nc_ll LOCATION, but it would be
good to try it on some other data.
If this is a bug I would consider it critical because many people are
trying to run GRASS with WebGIS
and drawing a polygon and then getting a report on what is inside that
polygon or running some more complex
analysis on it is among the most common tasks that people try to do that I
have seen.

thanks for looking into this (we really don't want people to go back to
6.3),

Helena

So for r.in.poly, we needed to use lat/lon coordinates (i.e. didn't use
coordinates in meters like you tested out) -- not only because the
Mapserver/Open Layers stuff we created was giving the coordinates in
lat/lon, but also because our projection was in lat/lon. That file looked
like this:

A
-78.254 35.82
-78.005 36.201
-77.707 36.135
-77.84 35.853
-78.196 35.721
= 1 coord

So when we ran the r.in.poly function, no errors were output -- it
appeared as though the layer had been created properly. But when we tried
to actually display the layer with the polygon, we found that no actual
polygon with those lat/lon coordinates as vertices was ever created.
Another co-worker in my office had GRASS 6.3 on his Linux machine, and
when we tried running the r.in.poly function with lat/lon coordinates on
his machine, it worked beautifully. That prompted us to put GRASS 6.3 on
the other machines we had been using and take off the 6.4 RC versions --
and with 6.3, everything worked as expected.

http://courses.ncsu.edu/mea582/common/media/01/nc_ll.zip

_______________________________________________
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

[Helena_Mitasova]

yes, it works - it was my mistake, I already posted an explanation into bugtracker,

sorry for the noise, Helena

On Aug 27, 2010, at 3:52 AM, Maris Nartiss wrote:

I'm sorry to dissapoint both of You, provided example works just fine
with current 6.4 SVN on 64bit Linux (Gentoo ~AMD64). Could this be
related to input file formating?

Please open an ticket and attach sample input file and exact commands to use.

Maris.

2010/8/26, Markus Neteler <neteler@osgeo.org>:

On Thu, Aug 26, 2010 at 5:32 PM, Helena Mitasova <hmitaso@unity.ncsu.edu>
wrote:

Has anybody tried to run r.in.poly with lat/long data in GRASS64 - it
appears to be broken.

r.in.poly in=gg.txt out=gg
g.region rast=gg
r.univar gg

g.region n=36.201 s=35.721 e=-77.707 w=-77.84 -g res=1
r.in.poly in=gg.txt out=gg --o
r.univar gg
-> nan

I can confirm that the imported polygon is not generated (nor an error).
Using 6.4.svn on 64bit Linux.

Markus

It creates a raster map with NULLs on my Mac RC6 version and apparently on
linux as well -
see the message below. My colleagues at the Climate Center had to switch
to GRASS63 to get their
Mapserver/OpenLayers application run with GRASS. I checked the repository
and no changes were
made for past 21 months except for input=- option so I am not sure whether
this is a bug or
we are just doing something wrong.

http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/raster/r.in.poly

Below is the test example and the related nc_ll LOCATION, but it would be
good to try it on some other data.
If this is a bug I would consider it critical because many people are
trying to run GRASS with WebGIS
and drawing a polygon and then getting a report on what is inside that
polygon or running some more complex
analysis on it is among the most common tasks that people try to do that I
have seen.

thanks for looking into this (we really don't want people to go back to
6.3),

Helena

So for r.in.poly, we needed to use lat/lon coordinates (i.e. didn't use
coordinates in meters like you tested out) -- not only because the
Mapserver/Open Layers stuff we created was giving the coordinates in
lat/lon, but also because our projection was in lat/lon. That file looked
like this:

A
-78.254 35.82
-78.005 36.201
-77.707 36.135
-77.84 35.853
-78.196 35.721
= 1 coord

So when we ran the r.in.poly function, no errors were output -- it
appeared as though the layer had been created properly. But when we tried
to actually display the layer with the polygon, we found that no actual
polygon with those lat/lon coordinates as vertices was ever created.
Another co-worker in my office had GRASS 6.3 on his Linux machine, and
when we tried running the r.in.poly function with lat/lon coordinates on
his machine, it worked beautifully. That prompted us to put GRASS 6.3 on
the other machines we had been using and take off the 6.4 RC versions --
and with 6.3, everything worked as expected.

http://courses.ncsu.edu/mea582/common/media/01/nc_ll.zip

_______________________________________________
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

[neteler]

Hi,

(using this to hide the info

we seem to be ready for the public announcement, no complaints so far
and a large number of binaries are meanwhile online.

Martin and me (and others) are here in Barcelona at the FOSS4G2010,
so we will send out the announcement in a few hours if there aren't any
objections.

cheers
Markus