Hi all,
time to think about 6.4.1RC2 I think... any opinions what's missing to
release it asap?
Markus
Hi,
2011/1/26 Markus Neteler <neteler@osgeo.org>:
time to think about 6.4.1RC2 I think... any opinions what's missing to
release it asap?
+1 for RC2, no blockers from my side.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
I don't see any issues either - it would be great to get some of the fixes out.
Here are some comments on problems that we have seen on Win7
and that I mentioned already - they are more on the user side and perhaps
a GUI design rather than blockers.
d.legend - I have seen couple people having troubles (e.g., cannot get it display)
but I was unable to reproduce any of it, it is probably more the GUI design issue that lets users
do things that do not make sense and then get stuck. That is something to look into
for future releases - I will be keeping some notes on the users problems and hopefully
not much will be needed to make it easier to use in future
As for the r.mapcalc issue - it was for older version in 6.5 when r.mapcalc GUI would not open after
typing the command and Enter in command console - it works in 6.4.1 for me.
The most serious issue was with import and export,
there was a lot of trouble with v.in.ogr, v.out.ogr running through GUI mostly due to lack of updates in my
instructions but also this ticket was mentioned
Ticket #1022
is this still an issue? - the ticket is still open
apparently this works in windows also from GUI, if the path is defined properly and user has the right permissions
v.out.ogr precip_30ynormals dsn=c:\temp\precipitation.kml format=KML type=point
but many reported that they were not able to export the data (neither raster nor vector) -
I am guessing that it is a permissions issue and/or perhaps a few windows specific examples could be added
to the manual because it is such an important command.
There is a related #1018 for v.in.ogr, but it worked OK for me on win7 - perhaps it could be closed?
Milena if you are on this list - does it work for you?
The examples that the students had the trouble with are at the bottom
of this assignment, in case somebody with win7 wants to check it out
(I will update the instructions because what I have there is clearly confusing for new users)
http://courses.ncsu.edu/mea582/common/GIS_anal_grass/GIS_Anal_grdataS2.html
thanks a lot, Helena
Helena Mitasova
Associate Professor
Department of Marine, Earth, and Atmospheric Sciences
2800 Faucette Drive, Rm. 1125 Jordan Hall
North Carolina State University
Raleigh, NC 27695-8208
hmitaso@unity.ncsu.edu
On Jan 26, 2011, at 6:06 PM, Martin Landa wrote:
Hi,
2011/1/26 Markus Neteler <neteler@osgeo.org>:
time to think about 6.4.1RC2 I think... any opinions what's missing to
release it asap?+1 for RC2, no blockers from my side.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 26/01/11 23:44, Markus Neteler wrote:
Hi all,
time to think about 6.4.1RC2 I think... any opinions what's missing to
release it asap?
I consider http://trac.osgeo.org/grass/ticket/699#comment:7 to be a serious show-stopper. As Hamish said, v.buffer should just work(tm).
Maybe the problem mentioned in this comment should be extracted to an new bug report ?
Moritz
Hi,
2011/1/27 Moritz Lennert <mlennert@club.worldonline.be>:
time to think about 6.4.1RC2 I think... any opinions what's missing to
release it asap?I consider http://trac.osgeo.org/grass/ticket/699#comment:7 to be a serious
show-stopper. As Hamish said, v.buffer should just work(tm).
I am afraid it's issue for 6.4.2 in the best case. Release 6.4.1 asap,
don't keep relbr64 in RC stage too long.
Maybe the problem mentioned in this comment should be extracted to an new
bug report ?
Probably yes.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Thu, Jan 27, 2011 at 11:40 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2011/1/27 Moritz Lennert <mlennert@club.worldonline.be>:
time to think about 6.4.1RC2 I think... any opinions what's missing to
release it asap?I consider http://trac.osgeo.org/grass/ticket/699#comment:7 to be a serious
show-stopper. As Hamish said, v.buffer should just work(tm).
This particular bug should be fixed by now (r45221), but because there
are still lots of compiler warnings for lib/vector/Vlib/buffer2.c,
there may be more, undiscovered bugs.
Markus M
How about fixes for #1256 #1255 and #638? Code changes are minor and
they would allow v.digit to suck less.
(r44914 r44920 r44921 r44928 r44982)
Maris.
2011/1/27, Markus Metz <markus.metz.giswork@googlemail.com>:
On Thu, Jan 27, 2011 at 11:40 AM, Martin Landa <landa.martin@gmail.com>
wrote:Hi,
2011/1/27 Moritz Lennert <mlennert@club.worldonline.be>:
time to think about 6.4.1RC2 I think... any opinions what's missing to
release it asap?I consider http://trac.osgeo.org/grass/ticket/699#comment:7 to be a
serious
show-stopper. As Hamish said, v.buffer should just work(tm).This particular bug should be fixed by now (r45221), but because there
are still lots of compiler warnings for lib/vector/Vlib/buffer2.c,
there may be more, undiscovered bugs.Markus M
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
regarding the troubles with import/export, one of the issues that put users on dead path was the default setting on the
Import vector data>common formats
By default the File button is switched on but when you go to the directory where the shape files are,
they are all grayed out and .shp file cannot be selected.
going back and switching the Directory button on and then selecting the directory where the shape file is works,
so I am wondering whether the Directory button should be switched on by default,
or if the File option is preferable perhaps there is bug that does not allow to select the file?
Helena
On Thu, Jan 27, 2011 at 8:18 PM, Maris Nartiss <maris.gis@gmail.com> wrote:
How about fixes for #1256 #1255 and #638? Code changes are minor and
they would allow v.digit to suck less.
(r44914 r44920 r44921 r44928 r44982)
I would say yes. In the worst case we revert for the final version.
It will likely get more testing in RC2.
Markus
Hi,
2011/1/27 Helena Mitasova <hmitaso@unity.ncsu.edu>:
...
There is a related #1018 for v.in.ogr, but it worked OK for me on win7 - perhaps it could be closed?
Milena if you are on this list - does it work for you?
Closed the ticket as it works now.
(and found the way to keep an eye on tickets reported by me 
Thanks,
Milena
--
Milena Nowotarska
http://wiki.osgeo.org/wiki/Milena_Nowotarska
http://quantum-gis.pl/ || http://grass-gis.pl/
One more issue (maybe fixed already?)
In Create histogram - if the name of the raster is typed in - it automatically adds @currentmapset
instead of the mapset where the raster actually is (in my case PERMANENT) and then it stalls -
there is just empty window saying Histogramming
Also I noticed that couple of d.* commands now rus from command console which is really nice,
I tried these and they work OK:
Running d.* commands from the console
d.rast map=elevation
d.vect map=schools_wake
d.his h_map=elevation i_map=elevation_shade
d.rgb b=lsat7_2002_10 g=lsat7_2002_20 r=lsat7_2002_30
d.grid size=5000 col=brown
but
d.legend starts the completion bar in map display but stalls
one has to remove a no-name layer from Map layers to get rid of the stall
reason, exception),
TypeError
:
unsupported operand type(s) for +: 'GException' and
'unicode'
For those that are not implemented it suggests to add it as command layer - do we still have command layer?
do we need to change the suggestion - just say "not implemented"?
and for
d.barscale : - not implemented yet, try add it as command layer instead
it may be "try add it as Add map elements"
Helena
Hi,
2011/1/28 Helena Mitasova <hmitaso@unity.ncsu.edu>:
In Create histogram - if the name of the raster is typed in - it automatically adds @currentmapset
instead of the mapset where the raster actually is (in my case PERMANENT) and then it stalls -
there is just empty window saying Histogramming
please try out r45230.
[...]
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Hi,
2011/1/28 Helena Mitasova <hmitaso@unity.ncsu.edu>:
but
d.legend starts the completion bar in map display but stalls
one has to remove a no-name layer from Map layers to get rid of the stall
reason, exception),
TypeError
:
unsupported operand type(s) for +: 'GException' and
'unicode'For those that are not implemented it suggests to add it as command layer - do we still have command layer?
do we need to change the suggestion - just say "not implemented"?
and for
d.barscale : - not implemented yet, try add it as command layer instead
it may be "try add it as Add map elements"
now should be OK for d.legend and d.barscale - please check out r45237.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa