Re: [GRASS-dev] wingrass7 nightly builds broken
2013/7/3 Jürgen E. j...@norbit.de: Hi Markus, On Wed, 03. Jul 2013 at 20:17:46 +0200, Markus Metz wrote: I guess some osgeo4w update moved or removed regex? AFAICT no. apps/msys/include/regex.h is in still in msys-1.0.11-13 (and that's from Apr 13th). Then it seems to be a problem on the server creating the nightly builds. Actually it affects all branches. Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1742: WXGUI layer manager window doesn't show all menubar entries
#1742: WXGUI layer manager window doesn't show all menubar entries -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI| Version: svn-releasebranch64 Keywords: |Platform: Linux Cpu: Unspecified | -+-- Comment(by wenzeslaus): Replying to [comment:11 hamish]: abbreviations... Unity... Agreed. (missing tabs in module guis is another related issue, the filled triangle is hard to see) This is reported in #306 and should be improved (or even fixed) by r52927, maybe we need to change the default settings now. my vote for a quick fix is to start by making the layer manager starting width a bit bigger. it's important. we should make it work on all languages. Unfortunately, there is always some language with extreme word-length. But yes, we can try to set the width e.g., for German, but, as I noted earlier, I'm afraid that this will create too big layer manager window (I think I've already tried). -- Ticket URL: https://trac.osgeo.org/grass/ticket/1742#comment:12 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] i.segment on panchromatic band of Worldview 2 scene: what resources are necessary to complete segmentation ?
Hello, In parallel to the discussion going on in another thread, I have a question concering the segmentation of another Worldview 2 scene: I first used all 8 multispectral bands and managed to get a series of results with increasing thresholds in very reasonable running times. The region was as follows: g.region -p projection: 1 (UTM) zone: -36 datum: wgs84 ellipsoid: wgs84 north: 7251172 south: 7234772 west: 333792 east: 350192 nsres: 2 ewres: 2 rows: 8200 cols: 8200 cells: 6724 and the command line: i.segment group=xs out=seg_xs minsize=2 memory=3072 threshold=0.05 (and thresh=0.1 and 0.2 in successive runs using the results of the previous run as seeds). Now, I would like to test segmentation of just the panchromatic band. This means the following region settings: projection: 1 (UTM) zone: -36 datum: wgs84 ellipsoid: wgs84 north: 7251172 south: 7234772 west: 333792 east: 350192 nsres: 0.5 ewres: 0.5 rows: 32800 cols: 32800 cells: 107584 Trying to run with the following command line on my i3, 8GB RAM machine: i.segment group=pan out=seg_pan_005 threshold=0.05 memory=3072 had the process running for almost 13 hours with it then becoming apparently stuck in the fourth pass at 10%. At that point the percent didn't change for over an hour, so I decided to kill the process. Can I assume that I'm here above the capacities of my machine ? Is there anything (besides working on a smaller subsample of the image) that I can do to make it work ? What kind of resources would I need to be able to run such a segmentation? I guess I'll have to move these kinds of treatments to our university supercomputer, but I first have to get them to install GRASS... Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #306: hidden tabs are hard to spot in wxGUI module windows
#306: hidden tabs are hard to spot in wxGUI module windows
-+--
Reporter: msieczka | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: major| Milestone: 7.0.0
Component: wxGUI| Version: svn-develbranch6
Keywords: tabs |Platform: All
Cpu: All |
-+--
Changes (by wenzeslaus):
* milestone: 6.4.4 = 7.0.0
Comment:
There is a new option in settings (''Appearance'' tab) to change the style
of notebook (tabs) for generated module dialogs (r52927, see an old [http
://osgeo-org.1560.x6.nabble.com/command-dialog-notebook-styles-
td4997929.html announcement on ML]). Some of the styles are using native
notebook (tabs). Usually, the problem with too many tabs is solved in
better way than the fancy green notebook solves it.
Maybe, we need to change the default settings now to the most standard
system style.
Minor issue is what to do with icons in the tabs. It seems that is it good
only for vertical style. Moreover, it is not clear if there are some
symbols to describe the tabs.
For GRASS 6 it is wontfix, it is not possible to backport it easily,
changing milestone to 7.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/306#comment:24
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] A few additional questions about i.segment
As you might have gathered from my other messages on the list, we are currently running tests of i.segment in our department. A few questions came up (with my attempts at answers). *** I had a look at the results, they are interesting. Maybe you could also try a combination of panchromatic, red and near-infrared bands and leave the other bands out. If it is possible to give different weights to the bands, then maybe 2 for the pan, 1 for red and 1 for NIR. I think that is possible, but I have to check how. I imagine you would work at the resolution of the pan for this... Regarding the size of the segments, we generally combine different segmentations, fine and coarse, depending on the type of objects that we have to classify. We also combine different segmentations because then we can use the classification of a fine segmentation as attribute for classifying a coarse segmentation (e.g. counting trees or houses in a large segment). Here we have very small segments and also very large ones together in the results, it is a bit different. So to be able to do what you do now, you would need homogenous segment sizes, i.e. not only a minsize (which I set fairly low in this first trial: 2 pixels), but also the equivalent of a maxsize. Then, if you set the two fairly close to each other (i.e. minsize=900 and maxsize=1100 to get segments of +/- 1000 pixels). I'll see how that can be achieved with the currently implemented module. *** Any hints on possible answers to these issues ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] A few additional questions about i.segment
On Thu, Jul 4, 2013 at 11:13 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: As you might have gathered from my other messages on the list, we are currently running tests of i.segment in our department. A few questions came up (with my attempts at answers). *** I had a look at the results, they are interesting. Maybe you could also try a combination of panchromatic, red and near-infrared bands and leave the other bands out. If it is possible to give different weights to the bands, then maybe 2 for the pan, 1 for red and 1 for NIR. I think that is possible, but I have to check how. I imagine you would work at the resolution of the pan for this... You could first resample the pan band to the resolution of the other bands, then r.mapcalc - multiply the pan band with 2 and use i.segment -w. Regarding the size of the segments, we generally combine different segmentations, fine and coarse, depending on the type of objects that we have to classify. We also combine different segmentations because then we can use the classification of a fine segmentation as attribute for classifying a coarse segmentation (e.g. counting trees or houses in a large segment). Here we have very small segments and also very large ones together in the results, it is a bit different. So to be able to do what you do now, you would need homogenous segment sizes, i.e. not only a minsize (which I set fairly low in this first trial: 2 pixels), but also the equivalent of a maxsize. Then, if you set the two fairly close to each other (i.e. minsize=900 and maxsize=1100 to get segments of +/- 1000 pixels). This is currently controlled with the threshold value. I am not sure if a max size makes sense. There might be homogenous objects with identical pixel values (difference = 0) that are larger than a given max size. Splitting such objects to respect a max size would be arbitrary. I would rather try to find a good combination of threshold and minsize, and do hierachical segmentation using the output of the previous run as input for the next run with increasing threshold. Technically, a maxsize option is possible for i.segment. Markus M I'll see how that can be achieved with the currently implemented module. *** Any hints on possible answers to these issues ? Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS 7: d.vect layer-option not allways recognised in wxGUI
Hi In GRASS 7 in the d.vect GUI the layer option is only recognised if typed in manually (not from the dropdown-list). When changing to other tabs, it is lost again. The result is that the layer is not displayed when where option is used. I am working on Ubuntu 12.04 LTS 64bit. Anyone who can confirm? Cheers Stefan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7: d.vect layer-option not allways recognised in wxGUI
Stefan wrote: In GRASS 7 in the d.vect GUI the layer option is only recognised if typed in manually (not from the dropdown- list). When changing to other tabs, it is lost again. The result is that the layer is not displayed when where option is used. I am working on Ubuntu 12.04 LTS 64bit. Anyone who can confirm? sounds related: https://trac.osgeo.org/grass/ticket/2012 Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 7: d.vect layer-option not allways recognised in wxGUI
Stefan wrote: In GRASS 7 in the d.vect GUI the layer option is only recognised if typed in manually (not from the dropdown- list). When changing to other tabs, it is lost again. The result is that the layer is not displayed when where option is used. I am working on Ubuntu 12.04 LTS 64bit. Anyone who can confirm? sounds related: https://trac.osgeo.org/grass/ticket/2012 Hamish Yes definitely. Thanks Stefan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1893: d.vect on re-opening switches to default layer
#1893: d.vect on re-opening switches to default layer -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: major| Milestone: 6.4.3 Component: wxGUI| Version: svn-releasebranch64 Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- Comment(by annakrat): This could be related also to #2012. The dialog now is not updated when shown. Can we close this ticket or is there something else? -- Ticket URL: https://trac.osgeo.org/grass/ticket/1893#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets column names
#2012: d.vect wx module GUI forgets column names +--- Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.4 Component: wxGUI | Version: svn-trunk Keywords: d.vect |Platform: Linux Cpu: x86-64 | +--- Comment(by annakrat): Please test again, the column problem should be fixed. Please be more specific about the other problems, include the traceback error. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2012#comment:1 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wingrass7 nightly builds broken
Hi, 2013/7/4 Markus Metz markus.metz.gisw...@gmail.com: I guess some osgeo4w update moved or removed regex? AFAICT no. apps/msys/include/regex.h is in still in msys-1.0.11-13 (and that's from Apr 13th). Then it seems to be a problem on the server creating the nightly builds. Actually it affects all branches. hm, there must be some change in osgeo4w framework. Last build is three days old. I will try to fix it ASAP. 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
Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets column names
Hi
I just downloaded the newest GRASS (7) version from svn in order to test the
issue.
In the build process I get an error message:
Errors in:
/data/src/grass70svn/man
make in the man directory says:
make[2]:
`/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.gmodeler.1'
is up to date.
VERSION_NUMBER=7.0.svn
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/tools/g.html2man.py
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/html/wxGUI.html
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.1
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/html/wxGUI.html:643:0:
Error (IndexError('pop from empty list',)): a
href=wxGUI.components.htmlwxGUI components/abr/
make[2]: ***
[/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.1]
Error 1
make[2]: Leaving directory `/data/src/grass70svn/man'
make[1]: *** [manpages] Error 2
make[1]: Leaving directory `/data/src/grass70svn/man'
make: *** [default] Error 2
Any ideas?
Cheers
Stefan
-Original Message-
From: grass-dev-boun...@lists.osgeo.org
[mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of GRASS GIS
Sent: 4. juli 2013 13:25
Subject: Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets column
names
#2012: d.vect wx module GUI forgets column names
+---
+
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: wxGUI | Version: svn-trunk
Keywords: d.vect |Platform: Linux
Cpu: x86-64 |
+---
+
Comment(by annakrat):
Please test again, the column problem should be fixed. Please be more
specific about the other problems, include the traceback error.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2012#comment:1
GRASS GIS http://grass.osgeo.org
___
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
Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets column names
On Thu, Jul 4, 2013 at 2:23 PM, Blumentrath, Stefan
stefan.blumentr...@nina.no wrote:
Hi
I just downloaded the newest GRASS (7) version from svn in order to test
the issue.
In the build process I get an error message:
Errors in:
/data/src/grass70svn/man
make in the man directory says:
make[2]:
`/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.gmodeler.1'
is up to date.
VERSION_NUMBER=7.0.svn
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/tools/g.html2man.py/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/html/wxGUI.html
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.1
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/html/wxGUI.html:643:0:
Error (IndexError('pop from empty list',)): a
href=wxGUI.components.htmlwxGUI components/abr/
make[2]: ***
[/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.1]
Error 1
make[2]: Leaving directory `/data/src/grass70svn/man'
make[1]: *** [manpages] Error 2
make[1]: Leaving directory `/data/src/grass70svn/man'
make: *** [default] Error 2
Any ideas?
sorry, please try to update and compile again (r57012)
Anna
Cheers
Stefan
-Original Message-
From: grass-dev-boun...@lists.osgeo.org [mailto:
grass-dev-boun...@lists.osgeo.org] On Behalf Of GRASS GIS
Sent: 4. juli 2013 13:25
Subject: Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets
column names
#2012: d.vect wx module GUI forgets column names
+---
+
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: wxGUI | Version: svn-trunk
Keywords: d.vect |Platform: Linux
Cpu: x86-64 |
+---
+
Comment(by annakrat):
Please test again, the column problem should be fixed. Please be more
specific about the other problems, include the traceback error.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2012#comment:1
GRASS GIS http://grass.osgeo.org
___
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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets column names
Geat!
Now both compiling and d.vect in the wxGUI work (I mean I can choose the layers
from the drop-down list and switch forth and back in the tabs and the layers
option remains as I set it)!
Thanks!
Just to make sure that it happened on purpose:
The layers-option -1 is now neither available in the drop-down list nor the
default setting for the layers-option in d.vect...
Stefan
From: Anna Petrášová [mailto:kratocha...@gmail.com]
Sent: 4. juli 2013 14:50
To: Blumentrath, Stefan
Cc: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets column
names
On Thu, Jul 4, 2013 at 2:23 PM, Blumentrath, Stefan
stefan.blumentr...@nina.nomailto:stefan.blumentr...@nina.no wrote:
Hi
I just downloaded the newest GRASS (7) version from svn in order to test the
issue.
In the build process I get an error message:
Errors in:
/data/src/grass70svn/man
make in the man directory says:
make[2]:
`/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.gmodeler.1'
is up to date.
VERSION_NUMBER=7.0.svn
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/tools/g.html2man.pyhttp://g.html2man.py
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/html/wxGUI.html
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.1
/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/html/wxGUI.html:643:0:
Error (IndexError('pop from empty list',)): a
href=wxGUI.components.htmlwxGUI components/abr/
make[2]: ***
[/data/src/grass70svn/dist.x86_64-unknown-linux-gnu/docs/man/man1/wxGUI.1]
Error 1
make[2]: Leaving directory `/data/src/grass70svn/man'
make[1]: *** [manpages] Error 2
make[1]: Leaving directory `/data/src/grass70svn/man'
make: *** [default] Error 2
Any ideas?
sorry, please try to update and compile again (r57012)
Anna
Cheers
Stefan
-Original Message-
From:
grass-dev-boun...@lists.osgeo.orgmailto:grass-dev-boun...@lists.osgeo.org
[mailto:grass-dev-boun...@lists.osgeo.orgmailto:grass-dev-boun...@lists.osgeo.org]
On Behalf Of GRASS GIS
Sent: 4. juli 2013 13:25
Subject: Re: [GRASS-dev] [GRASS GIS] #2012: d.vect wx module GUI forgets column
names
#2012: d.vect wx module GUI forgets column names
+---
+
Reporter: hamish | Owner: grass-dev@...
Type: defect | Status: new
Priority: normal | Milestone: 6.4.4
Component: wxGUI | Version: svn-trunk
Keywords: d.vect |Platform: Linux
Cpu: x86-64 |
+---
+
Comment(by annakrat):
Please test again, the column problem should be fixed. Please be more
specific about the other problems, include the traceback error.
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2012#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.orgmailto: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
Re: [GRASS-dev] wingrass7 nightly builds broken
Hi, 2013/7/4 Martin Landa landa.mar...@gmail.com: I guess some osgeo4w update moved or removed regex? AFAICT no. apps/msys/include/regex.h is in still in msys-1.0.11-13 (and that's from Apr 13th). Then it seems to be a problem on the server creating the nightly builds. Actually it affects all branches. hm, there must be some change in osgeo4w framework. Last build is three days old. I will try to fix it ASAP. should be OK now. I found out problem on the server side. When I was working on the new version of msys package I have installed mingw which caused this problem. Sorry for inconvenience, 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
Re: [GRASS-dev] GRASS 6.4.3 release planning
On Tue, Jul 2, 2013 at 8:57 PM, Anna Petrášová kratocha...@gmail.comwrote: Hi, On Fri, Jun 28, 2013 at 2:29 AM, Helena Mitasova hmit...@ncsu.edu wrote: regarding the r.mapcalc issue in command console on wingrass - (sorry I did not make it clear it was for wingrass - it always worked well on Mac and linux) It is not critical, windows users can still use the mapcalculator GUI where it runs OK, but the r.mapcalc in the command console still does not seem to work - tried by a student using June 26 snapshot this is what she says: Here are examples of the commands run and the errors received: r.mapcalc urban2_30m=if(landuse96_28m==1 || landuse96_28m==2,landuse96_28m,null()) syntax error, unexpected $end, expecting ')' Parse error 'landuse96_28m' is not recognized as an internal or external command, operable program or batch file. r.mapcalc MASK=if((elevation100 elevation60) (landuse96_28m==1 || landuse96_28m==2),1,null()) 1 was unexpected at this time. This is the same we were getting in GRASS6.4.3RC2 and apparently the proposed solutions did not work http://lists.osgeo.org/pipermail/grass-dev/2013-February/062047.html http://lists.osgeo.org/pipermail/grass-dev/2013-March/062607.html I had the opportunity to test Glynn's patch (the second link above) on Windows and it seems to solve the problems. From the discussion I can see that Markus already tested it but he was not successful, so I applied the patch to 6.5 first. All the commands causing problems are now working with both (, ') quotes and without, only the command with || requires quotes. Anna Seems to work, I applied it to all branches, please test (using e.g. the commands above). Anna if I get this confirmed I will file a bug report (I thought I already did, but it is not there). If it is not fixable it should be at least mentioned on the known issues web page http://grasswiki.osgeo.org/wiki/WinGRASS_Current_Status#Raster_modules Helena Helena: I am also wondering whether the r.mapcalc expressions with || (or) now run from the wxGUI command console. I just tried on linux 6.4.3svn wxGUI command console: r.mapcalc either = 0 || 1 and it worked. In general I wouldn't be surprised if full command line quoting took years and huge amounts of effort to (re)perfect. And even then, does it try to follow Bash conventions, or python, or DOS, or some mix of all those? How much do we try to (re)teach about command line techniques in our own docs? Will unquoted input=C:\Users\files\data.txt always be parsed to input=C:Usersfilesdata.txt (literal \U, \f, \d) in the command console in that case? best, Hamish ___ 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 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2010: r.in.wms2 fails to install on 6.x
to add .decode('utf8') somewhere?
http://washort.twistedmatrix.com/2010/11/unicode-in-python-and-how-to-prevent-it.html
thanks,
Hamish
I wrote:
Also, I'm seeing a unicode error vs. layer Title string in the
6.4.3svn's
r.in.wms1's wxGUI wrapper. It's not to do with r.in.wms2.py, so
I'll
post that to the -dev ML.
details on..
the WMS/WFS I'm using to test with:
http://wiki.openstreetmap.org/wiki/New_Zealand/Imagery
In 6.4.3svn wxGUI File - import raster - r.in.wms (wrapper) I'm
getting the following error when the parsed list of WMS layer Titles contains
a
non-ascii char, in this case on of them contains a long -- hyphen.
Any ideas on a quick fix? It didn't like , unicode = True where
I put it.
All's well in trunk.
Traceback (most recent call last):
File /home/hamish/src/grass/svn/grass65/dist.x86_64
-unknown-linux-gnu/etc/wxpython/modules/ogc_services.py,
line 216, in OnConnect
self.list.LoadData(layers)
File /home/hamish/src/grass/svn/grass65/dist.x86_64
-unknown-linux-gnu/etc/wxpython/modules/ogc_services.py,
line 273, in LoadData
self.SetItemText(lchild, title, 1)
File /usr/lib64/python2.6/dist-
packages/wx-2.8-gtk2-unicode/wx/gizmos.py, line 647, in
SetItemText
return _gizmos.TreeListCtrl_SetItemText(*args, **kwargs)
UnicodeDecodeError
:
'ascii' codec can't decode byte 0xe2 in position 36: ordinal
not in range(128)
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
