#843 v.digit broken on new WinGrass release
- apparently working in 6.5, awaits backport to 6.4
#580 WinGRASS: $GISBASE/etc/gui/scripts/ require something like $(EXE) to run
- apparently fixed in all branches, awaiting next wingrass
build for final testing
#72 PNG driver: boundary rendering is off by one pixel
- not a blocker
#759 r.patch non-functional in WinGRASS 6.4 svn on Vista
- not a blocker: no solution, but work-around added to
the wingrass release notes
#461 v.to.db crashes on a shapefile connected with v.external
- not a blocker: figuring out how to make it come back with
a fatal error instead of a segfault would be nice though.
#809 v.db.addtable consistently fails in winGrass
- apparently fixed in all branches, awaiting next wingrass
build for final testing
#384 wxGUI: vdigit crashes on a big map
- not a blocker: corner case/general resource issue
#842 wx location wizard: spincontrol busted for UTM zone
- fixed in 6.4, awaits merging into 6.5 and trunk
#860 wxGUI: About Copyright missing its middle
- Blocker: missing license info
#? r.proj: still dies on wingrass.
- needs verification
So AFAIK it is just #843 (v.digit backport) and #860 (wx About)
left before we are ready to do RC6.
Hi, I had tested these on OsGeo4W RC7, wxgui, windows 7:
> #843 v.digit broken on new WinGrass release
>- apparently working in 6.5, awaits backport to 6.4
>... the backport state is unclear to me.
v.digit called from wx works fine.
>#962: wxGUI crash when moving an undocked map display toolbox
>"Unable to reproduce it." - lacking feedback
Dock, undock, move, etc. Works.
>#995: WxGUI startup screen fails if GISDBASE path contains non-latin characters
>"Location Wizard still fails in Windows Vista"
Wich characters are non-latin? Tryed with á à â characters and works.
Location Wizard works on Win7.
#1020: Display of vector maps fails
... open issue on Windows7.
Vectors are displaying very well and incredibly fast.
> #72 PNG driver: boundary rendering is off by one pixel
.. critical, no blocker. Unsolvable?
Not worth the effort. AFAIK, fixing the current issue would require
modifying either the polygon-filling code or the horizontal case of
the line-drawing code, so that the two match. Even then, there's a
limit to what you can do when code typically tries to draw lines
exactly along the boundary between pixels and you're using integer
coordinates.
#995: WxGUI startup screen fails if GISDBASE path contains non-latin characters
"Location Wizard still fails in Windows Vista"
There's a limit to what can be achieved on Windows. We should be able
to handle characters which are in the current codepage, but supporting
filenames which contain characters outside of the current codepage is
probably out of the question (we would need to wrap every open(),
fopen(), rename(), remove() etc).
Can I suggest that lib/python is sync'd to the latest 6.x version. In
6.4.0-RC6, g.parser has been updated to the latest version (with the
-s flag), but lib/python/core.py hasn't been updated to use it. It's
still using the old (and unreliable) method of re-invoking the script.
> #843 v.digit broken on new WinGrass release
> - apparently working in 6.5, awaits backport to 6.4
... the backport state is unclear to me.
it *seems* to work ok now, but when you exit you get an error
message that it could not build support for vector map <(null)>.
So something is still wrong, and without knowing what that is
I can not rule out data-loss/corruption & therefore release-
blocking bug status.
Hamish
ps- sorry if I'm kept away by other things these days and can't
read every email; try to (repeatedly) ping my work email if you
need a quickish reply. I'm not ignoring anybody, I just can't
keep up with the volume.
> #72 PNG driver: boundary rendering is off by one pixel
> .. critical, no blocker. Unsolvable?
Glynn wrote:
Not worth the effort. AFAIK, fixing the current issue would
require modifying either the polygon-filling code or the
horizontal case of the line-drawing code, so that the two
match. Even then, there's a limit to what you can do when
code typically tries to draw lines exactly along the boundary
between pixels and you're using integer coordinates.
I left it as critical because IMO it is worth (mine, if no one
else's) effort- for 6.x the suggested way to export graphics
for presentations or the web* is d.out.file (PNG driver
frontend). And currently that means slivers and misaligned
polygons. Perhaps I am more "detail oriented" than other people,
but to me this really sticks out is a real embarassment that
"we can't even get that right". So currently to do this task
I wrote a little shell script using xwd|xwdtopnm to take a
screenshot of the Xmonitor, which is fine for me and for things
smaller than the biggest monitor I can find.
[*] (or for reports if you don't mind uglified rasterized plots
and ps.map doesn't do it for you)
If this was not the primary means of exporting visual images
from GRASS I wouldn't be concerned. If I ever find the time
I'll work on it, if not I guess it languishes.
On Wed, Apr 7, 2010 at 7:58 AM, Glynn Clements <glynn@gclements.plus.com> wrote:
Markus Neteler wrote:
I think that we need to get out 6.4.0final.
Can I suggest that lib/python is sync'd to the latest 6.x version. In
6.4.0-RC6, g.parser has been updated to the latest version (with the
-s flag), but lib/python/core.py hasn't been updated to use it. It's
still using the old (and unreliable) method of re-invoking the script.
Is "latest version" 6.5 or 7? Since it isn't really my area, I am not sure
what to sync (have sync'ed the file-internal documentation now).
>> I think that we need to get out 6.4.0final.
>
> Can I suggest that lib/python is sync'd to the latest 6.x version. In
> 6.4.0-RC6, g.parser has been updated to the latest version (with the
> -s flag), but lib/python/core.py hasn't been updated to use it. It's
> still using the old (and unreliable) method of re-invoking the script.
Is "latest version" 6.5 or 7? Since it isn't really my area, I am not sure
what to sync (have sync'ed the file-internal documentation now).
6.4.0 should be sync'd to 6.5. Maybe 6.5 should be sync'd to 7.0
first, with one exception: the 7.0 version of grass.script.mapcalc()
relies upon r.mapcalc using G_parser(), which won't work in 6.x.
Although, there isn't any fundamental reason why the 6.x version won't
work in 7.0.
6.4.0 should be sync'd to 6.5. Maybe 6.5 should be sync'd to 7.0
first, with one exception: the 7.0 version of grass.script.mapcalc()
6.5 sync'ed with 7.0 in r41773, after some testing can be backported to 6.4.
I have tried to generate a new vector map with the new digitizer, but it fails:
----------
Unable to initialize display driver of vector digitizer. See 'Command
output' for details.
Reason: <unprintable DigitError object>
Traceback (most recent call last):
File "/home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/toolbars.py",
line 1123, in StartEditing
message=_("Unable to initialize display driver of vector "
DigitError: <unprintable DigitError object>
----------
wxNVIZ starts correectly in 6.5.
===============
Attached the derived 6.4 backport from r41773 with a full sync of
core.py (not sure
if that's right). Testing that, also a (different) Python problem when
generating
a new vector map in the digitizer:
----------
Unable to initialize display driver of vector digitizer. See 'Command
output' for details.
Details: 'NoneType' object has no attribute 'OpenMap' ()
----------
Also wxNVIZ does not start here, so the attached backport isn't ok yet.
On Sun, Apr 18, 2010 at 10:44 AM, Markus Neteler <neteler@osgeo.org> wrote:
I have tried to generate a new vector map with the new digitizer, but it fails:
This is still the case.
GRASS 6.4: A Python problem appears when generating a new vector map in
the digitizer (Start digitizer, new map, enter name, OK):
----------
Unable to initialize display driver of vector digitizer. See 'Command
output' for details.
Details: 'NoneType' object has no attribute 'OpenMap' ()
----------
GRASS 6.5: A different Python problem appears when generating a new vector map
in the digitizer (Start digitizer, new map, enter name, OK):
----------
Unable to initialize display driver of vector digitizer. See 'Command
output' for details.
Reason: message=_("Unable to initialize display driver of vector "
Traceback (most recent call last):
File "/home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/toolbars.py",
line 1123, in StartEditing
message=_("Unable to initialize display driver of vector "
DigitError: <unprintable DigitError object>
both issues are related to the same thing - bloody swig you are using
for compiling vdigit extension compared to the swig version used for
wxpython packaging. On my system everything works with swig 1.3.36.
Not sure when it will be fixed (me - not first item in my TODO list /
nobody else probably interested to fix it). Anyway there is chance for
6.4.1.
On Fri, May 14, 2010 at 4:12 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2010/5/14 Markus Neteler <neteler@osgeo.org>:
On Sun, Apr 18, 2010 at 10:44 AM, Markus Neteler <neteler@osgeo.org> wrote:
I have tried to generate a new vector map with the new digitizer, but it fails:
This is still the case.
GRASS 6.4: A Python problem appears when generating a new vector map in
the digitizer (Start digitizer, new map, enter name, OK):
----------
Unable to initialize display driver of vector digitizer. See 'Command
output' for details.
Details: 'NoneType' object has no attribute 'OpenMap' ()
----------
GRASS 6.5: A different Python problem appears when generating a new vector map
in the digitizer (Start digitizer, new map, enter name, OK):
----------
Unable to initialize display driver of vector digitizer. See 'Command
output' for details.
Reason: message=_("Unable to initialize display driver of vector "
Traceback (most recent call last):
File "/home/neteler/grass65/dist.x86_64-unknown-linux-gnu/etc/wxpython/gui_modules/toolbars.py",
line 1123, in StartEditing
message=_("Unable to initialize display driver of vector "
DigitError: <unprintable DigitError object>
both issues are related to the same thing - bloody swig you are using
for compiling vdigit extension compared to the swig version used for
wxpython packaging. On my system everything works with swig 1.3.36.
I am not sure about this. It worked till recently without problems and I am
not aware of any changes in my swig or wxpython installation.
Not sure when it will be fixed (me - not first item in my TODO list /
nobody else probably interested to fix it). Anyway there is chance for
6.4.1.
Mhh, shipping 6.4 with broken digitizer.. am I the only one having this problem?
If yes then who cares
both issues are related to the same thing - bloody swig you are using
for compiling vdigit extension compared to the swig version used for
wxpython packaging. On my system everything works with swig 1.3.36.
I am not sure about this. It worked till recently without problems and I am
not aware of any changes in my swig or wxpython installation.
when I use swig 1.3.40 -- the same errors, with swig 1.3.36 everything works.
Not sure when it will be fixed (me - not first item in my TODO list /
nobody else probably interested to fix it). Anyway there is chance for
6.4.1.
Mhh, shipping 6.4 with broken digitizer.. am I the only one having this problem?
If yes then who cares
No you are not definitely alone, anyway wxGUI is not default GUI for
6.4.0, moreover there is still v.digit. I would like to have enough
time to fix all major issues related to wxGUI digitizer...
Before a release, GRASS CRS support files need an update, per bugs "ETRS89-based CRSs missing datum definition?" [1] and "lacking towgs84 for Pulkovo 1942(58), Poland".
OK now, so this was actually a revert of a massive update which broke
things.
Anyway, my point is that gcs.csv as it is now in all GRASS SVN branches
lacks towgs84 definition for Pulkovo 1942(58) datum, which results in
locations created from EPSG codes [4] lacking it too. The towgs84 should
be as in [5].
@Markus, Paul
Do I simply modify gcs.csv alone or should this be a somewhat bigger change?
