[GRASS-dev] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass --+- Reporter: JonBall | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: |Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 --+- Comment (by mmetz): Replying to [comment:11 hamish]: stuff to audit, both for spaces in path names and for correct column parsing when fs=':' and a path like C:\Documents and Settings is being parsed. I had a look at the vector lib routines for reading/writing database connections (dblinks in the vector libs). The database is written to dbln without parsing any variables in it; that makes it possible to copy entire locations or provide sample datasets with vectors and attribute tables. Any variables in the database info are parsed by Vect_get_dblink() which calls Vect_subst_var(). v.db.addtable calls v.db.connect which calls Vect_get_dblink() - any variables like $GISDBASE/$LOCATION_NAME/$MAPSET are already substituted. The only way I see to get the database used by an existing layer *without* parsing any variables is raw parsing of the dbln file. AFAICT, vector modules use default database connection settings when adding a new table, also when e.g. adding a table for layer 2 and there is already a table connected to layer 1. Therefore it would not be unusual behaviour if v.db.addtable also always uses the default database connections. Markus M -- Ticket URL: https://trac.osgeo.org/grass/ticket/809#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] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass --+- Reporter: JonBall | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: |Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 --+- Comment (by hamish): Replying to [comment:11 hamish]: stuff to audit, both for spaces in path names and for correct column parsing when fs=':' and a path like C:\Documents and Settings is being parsed. Replying to [comment:12 mmetz]: I had a look at the vector lib routines for reading/writing database connections (dblinks in the vector libs). The database is written to dbln without parsing any variables in it; that makes it possible to copy entire locations or provide sample datasets with vectors and attribute tables. Any variables in the database info are parsed by Vect_get_dblink() which calls Vect_subst_var(). However, there is no reason to assume that the user has not manually connected the vector to a real pathname. And in those cases any code which reads the dbln file will need to be able to deal with databases with spaces in the path name. suggestion: This is really a failure of the dbln file format. In grass 7 change the dbln file format to use '|' as the field sep. Include code in both the g7 and g6.5 the library functions to quietly read either during the transition period. We have done something similar for the color table format which used to be value red green blue but is now value red:green:blue. v.db.addtable calls v.db.connect which calls Vect_get_dblink() - any variables like $GISDBASE/$LOCATION_NAME/$MAPSET are already substituted. The only way I see to get the database used by an existing layer *without* parsing any variables is raw parsing of the dbln file. I came to the same conclusion and checked in that exact fix to svn a couple of hours ago. AFAICT, vector modules use default database connection settings when adding a new table, also when e.g. adding a table for layer 2 and there is already a table connected to layer 1. Therefore it would not be unusual behaviour if v.db.addtable also always uses the default database connections. For now I have followed the path of least change and left it using what the map is already using. One thing I see in favor of having it use the mapset's VAR setting instead is that you can control the VAR setting. You can't control what the map already has in it unless you rebuild the map (which is perhaps not what you want). Another plausible possibility is to add database= and driver= options to v.db.addtable. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/809#comment:13 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] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass --+- Reporter: JonBall | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: |Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 --+- Comment (by hamish): Replying to [comment:13 hamish]: Another plausible possibility is to add database= and driver= options to v.db.addtable. fwiw if it is to change I prefer the VAR option as it keeps v.db.addtable simple. -- Ticket URL: https://trac.osgeo.org/grass/ticket/809#comment:14 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] [GRASS GIS] #858: Display command from the Output window not working
#858: Display command from the Output window not working -+-- Reporter: clerici | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.0 Component: Tcl | Version: unspecified Keywords: |Platform: Linux Cpu: Unspecified | -+-- I tried to run commands from the lower part of the Output window in gis.m GUI. The command with results listed in the Output window (as g.list rast) run well. I opened a Monitor with: d.mon x0 and Run button. The Monitor was opened. Then I deleted the command d.mon x0 and I wrote the command to display the raster map geology (spearfish): d.rast geology and Run (background) button but nothing was displayed in the monitor (same result with d.vect). This with: GRASS6.3, GRASS6.4, GRASS6.5. With GRASS6.2 everything run well. A. Clerici -- Ticket URL: http://trac.osgeo.org/grass/ticket/858 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] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass --+- Reporter: JonBall | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: |Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 --+- Comment (by mmetz): Replying to [comment:13 hamish]: Replying to [comment:12 mmetz]: I had a look at the vector lib routines for reading/writing database connections (dblinks in the vector libs). The database is written to dbln without parsing any variables in it; that makes it possible to copy entire locations or provide sample datasets with vectors and attribute tables. Any variables in the database info are parsed by Vect_get_dblink() which calls Vect_subst_var(). However, there is no reason to assume that the user has not manually connected the vector to a real pathname. And in those cases any code which reads the dbln file will need to be able to deal with databases with spaces in the path name. Right, and it should also be broken on Linux if there are whitespaces in the path name when manually connecting a table. A mystery that no one discovered that yet... suggestion: This is really a failure of the dbln file format. In grass 7 change the dbln file format to use '|' as the field sep. Include code in both the g7 and g6.5 the library functions to quietly read either during the transition period. We have done something similar for the color table format which used to be value red green blue but is now value red:green:blue. OK. And use G_tokenize() I assume. You can't control what the map already has in it unless you rebuild the map (which is perhaps not what you want). Another plausible possibility is to add database= and driver= options to v.db.addtable. Makes sense, and should not make the code too complicated. Something for g7? Markus M -- Ticket URL: https://trac.osgeo.org/grass/ticket/809#comment:15 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] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass --+- Reporter: JonBall | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: |Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 --+- Comment (by hamish): I've just attached to this ticket a patch against 6.5 which allows spaces in pathnames for hardcoded database paths using G_tokenize(). please review. previously there was behavior in Vect_read_dblinks() which allowed the dbln file to only contain the layer number and table name if you'd already defined the others in previous layer links. I've tried to preserve that, but if the path has spaces I don't think it is possible to distinguish between if the last entry is supposed to be the driver or the end of the path name. Therefore we lose a tiny bit of functionality here, but I don't think anyone knew about or was using that trick anyway. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/809#comment:16 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] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass --+- Reporter: JonBall | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: |Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 --+- Comment (by hamish): Replying to [comment:15 mmetz]: Right, and it should also be broken on Linux if there are whitespaces in the path name when manually connecting a table. I just tested, it is. A mystery that no one discovered that yet... I suspect they probably have, we've just never put all the pieces together before. Especially Mac users who are more likely to see spaces in path names. suggestion: This is really a failure of the dbln file format. In grass 7 change the dbln file format to use '|' as the field sep. Include code in both the g7 and g6.5 the library functions to quietly read either during the transition period. ... OK. And use G_tokenize() I assume. in G_parser() is a G_tokenize() call which defines the sep as a two- character array, which would be an easy way to temporarily allow either | oras the sep. You can't control what the map already has in it unless you rebuild the map (which is perhaps not what you want). Another plausible possibility is to add database= and driver= options to v.db.addtable. Makes sense, and should not make the code too complicated. Something for g7? or now or 6.4.1, if it is decided that inability to set a different DB for new tables with v.db.addtable is actually a bug. (I guess you can already adjust it to the desired value v.db.connect after creation, but that's a bit ugly) Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/809#comment:17 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] Re: [GRASS GIS] #858: Display command from the Output window not working
#858: Display command from the Output window not working --+- Reporter: clerici | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: normal | Milestone: 6.4.0 Component: Tcl | Version: unspecified Resolution: wontfix |Keywords: Platform: Linux| Cpu: Unspecified --+- Changes (by hamish): * status: new = closed * resolution: = wontfix Comment: It is not designed or supposed to work from the new gis.m GUI, so this is not surprising. well, you can launch one from that command line, and d.mon -L reports it as selected, but d.rast shows nothing and d.where goes nuts. d.info reports the correct initial window size but doesn't update if you change it by hand. You can work the xmon from the real terminal command line, but you might as well launch it from there as well. Interestingly (or not, DOYPOV) if you run a Xterm from the gis.m output window, after setting LD_LIBRARY_PATH it still didn't work for me, but it would write to $GRASS_PNG_FILE which I could look at in an image viewing program. I expect that's just a useless curiosity though. If you want to work with d.* commands + a gui you have to use the old tcl/tk GUI (d.m). you can still do that with any 6.x GRASS by entering d.m or g.gui oldtcktk on the (real) terminal's command line. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/858#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] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map
#384: wxGUI: vdigit crashes on a big map
---+
Reporter: msieczka | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution:|Keywords: vdigit
Platform: Linux | Cpu: x86-64
---+
Changes (by hamish):
* keywords: = vdigit
Comment:
is there a way to count number of vertices? that is masked in the v.info
-t output. So I'm not sure how it compares, but here I tried:
{{{
g.region rast=elevation.dem
r.to.vect in=elevation.dem out=elev_dem feature=area -s -v
v.info -t elev_dem
nodes=523820
points=0
lines=0
boundaries=523819
centroids=246961
areas=246961
islands=1
faces=0
kernels=0
primitives=770780
map3d=0
du -sh vector/elev_dem
50M
}}}
it was slow used a huge amount of memory, but it didn't crash.
(g65, amd64, debian/lenny)
some wxVdigit notes:
- chosen map name box on left not wide enough
- digitize points and move vertex buttons remain depressed.
after clicking on extra tools menu, that button stays depressed as
well.
- memory from top: VIRT 1775m, RES 1.3g, SHR 28m python
- it is slow but functional when zoomed in.
when zoomed to full extent of map it pegs my local eth0, CPU (Xorg +
ssh) near 100% for 10 minutes ( counting) while it attempts to redraw.
(session tunneled over ssh to the machine down the hall with 8gig RAM)
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/384#comment:2
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] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map
#384: wxGUI: vdigit crashes on a big map ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution:|Keywords: vdigit Platform: Linux | Cpu: x86-64 ---+ Comment (by hamish): Replying to [comment:2 hamish]: - digitize points and move vertex buttons remain depressed. after clicking on extra tools menu, that button stays depressed as well. ie they do not act like radio buttons. pressing one does not release another. I can select them all until every button is depressed except for the 3 on the right: undo config exit. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/384#comment:3 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] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map
#384: wxGUI: vdigit crashes on a big map ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution:|Keywords: vdigit Platform: Linux | Cpu: x86-64 ---+ Comment (by martinl): Replying to [comment:2 hamish]: - digitize points and move vertex buttons remain depressed. after clicking on extra tools menu, that button stays depressed as well. fixed in r40316. Martin -- Ticket URL: https://trac.osgeo.org/grass/ticket/384#comment:4 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] [GRASS GIS] #859: v.patch: category abuse
#859: v.patch: category abuse
-+--
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: normal | Milestone: 6.4.1
Component: Vector | Version: svn-develbranch6
Keywords: v.digit |Platform: Linux
Cpu: x86-64 |
-+--
Hi,
I am trying to patch together a couple hundred individual lines into a
single map. Each line has been given a unique category number so that when
their (identical) tables are merged they will not conflict.
after creating an empty vector with v.in.ascii and creating a matching
table for it, the patch loop looks like this:
{{{
for MAP in `g.mlist vect pattern=track_*` ; do
v.patch -a -e in=$MAP out=tracks --overwrite --quiet
done
}}}
g.mlist+v.db.select for some input maps:
{{{
cat|filename
10101|M02-001-0101
10224|M02-001-0224
10346|M02-001-0346
12305|M02-001-2305
20044|M02-002-0044
20209|M02-002-0209
20333|M02-002-0333
20458|M02-002-0458
20650|M02-002-0650
20813|M02-002-0813
20944|M02-002-0944
21112|M02-002-1112
21253|M02-002-1253
21434|M03-002-1434
21557|M03-002-1557
21721|M03-002-1721
21854|M03-002-1854
}}}
v.db.select for v.patch output:
{{{
cat|filename
10102|M02-001-0101
20327|M02-001-0224
30674|M02-001-0346
42980|M02-001-2305
63025|M02-002-0044
83235|M02-002-0209
103569|M02-002-0333
124028|M02-002-0458
144679|M02-002-0650
165493|M02-002-0813
186438|M02-002-0944
207551|M02-002-1112
228805|M02-002-1253
250240|M03-002-1434
271798|M03-002-1557
293520|M03-002-1721
315375|M03-002-1854
}}}
you can see that the category value in the output patch becomes:
{{{
1 + map1
1 + map1 + 1 + map2
1 + map1 + 1 + map2 + 1 + map3
.
.
.
}}}
how to make max_cat() or what ever is doing it stop?
* I cannot guarantee that input maps arrive sorted by cat, smallest to
largest.
* It has to check if the cat is already used, if so it has to decide what
to do with existing database attributes. Probably exit with a fatal error.
* I suppose this needs a flag: you either care to preserve the cat but
accept fatal errors and a small time penalty; or you don't mind
reassigning cats to avoid fatal errors.
thanks,
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/859
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] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map
#384: wxGUI: vdigit crashes on a big map ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution:|Keywords: vdigit Platform: Linux | Cpu: x86-64 ---+ Comment (by hamish): Replying to [comment:4 martinl]: Replying to [comment:2 hamish]: - digitize points and move vertex buttons remain depressed. after clicking on extra tools menu, that button stays depressed as well. fixed in r40316. Martin excellent; thanks. I notice that the menu buttons on the right still stay depressed until you click something new instead of raising themselves as soon as the menu is gone. a minor thing, but a bit weird. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/384#comment:5 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] Re: [GRASS GIS] #859: v.patch: category abuse
#859: v.patch: category abuse -+-- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: normal | Milestone: 6.4.1 Component: Vector | Version: svn-develbranch6 Resolution: |Keywords: v.digit Platform: Linux | Cpu: x86-64 -+-- Comment (by hamish): if the attribute table is ''not'' being copied (the -e flag is not used) then allowing duplicate cats is in fact wanted. again a flag could be used to avoid duplicates if that's what the user wants. -- Ticket URL: https://trac.osgeo.org/grass/ticket/859#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] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map
#384: wxGUI: vdigit crashes on a big map ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution:|Keywords: vdigit Platform: Linux | Cpu: x86-64 ---+ Comment (by martinl): Replying to [comment:5 hamish]: excellent; thanks. I notice that the menu buttons on the right still stay depressed until you click something new instead of raising themselves as soon as the menu is gone. a minor thing, but a bit weird. I think it's desired features, it shows that some tool from additional tools is selected. Martin -- Ticket URL: https://trac.osgeo.org/grass/ticket/384#comment:6 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] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map
#384: wxGUI: vdigit crashes on a big map ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution:|Keywords: vdigit Platform: Linux | Cpu: x86-64 ---+ Comment (by hamish): Replying to [comment:6 martinl]: I think it's desired features, it shows that some tool from additional tools is selected. good point. -- Ticket URL: https://trac.osgeo.org/grass/ticket/384#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
[GRASS-dev] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map
#384: wxGUI: vdigit crashes on a big map ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution:|Keywords: vdigit Platform: Linux | Cpu: x86-64 ---+ Comment (by martinl): Replying to [comment:2 hamish]: - chosen map name box on left not wide enough enlarged r40320. -- Ticket URL: https://trac.osgeo.org/grass/ticket/384#comment:8 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] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass
--+-
Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: |Keywords: v.db.addtable, wingrass
Platform: MSWindows Vista | Cpu: x86-64
--+-
Comment (by mmetz):
Replying to [comment:16 hamish]:
I've just attached to this ticket a patch against 6.5 which allows
spaces in pathnames for hardcoded database paths using G_tokenize().
please review.
Tested, works fine. One minor bug though: in the new v.db.addtable line
129
{{{
eval `g.findfile elem=vector/$GIS_OPT_MAP file=dbln`
}}}
does not work with a fully qualified name, the default settings in
$MAPSET/VAR are used. Maybe something like
{{{
eval `g.findfile elem=vector file=$GIS_OPT_MAP`
eval `g.findfile elem=vector/$name file=dbln mapset=$mapset`
}}}
?
previously there was behavior in Vect_read_dblinks() which allowed the
dbln file to only contain the layer number and table name if you'd already
defined the others in previous layer links.
I've tried to preserve that, but if the path has spaces I don't think it
is possible to distinguish between if the last entry is supposed to be the
driver or the end of the path name. Therefore we lose a tiny bit of
functionality here, but I don't think anyone knew about or was using that
trick anyway.
In grass64+, Vect_write_dblinks() always writes the full connection
definition, so I would not worry too much. I have not looked at previous
versions though to see if for layers 1, only layer number and table name
were written if the rest was identical to layer 1.
For grass7, I would suggest to use fs=| as default (anything but
whitespace) whenever dblinks are written or printed, e.g.
Vect_write_dblinks() and v.db.connect -p
Markus M
--
Ticket URL: https://trac.osgeo.org/grass/ticket/809#comment:18
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] Re: [GRASS GIS] #384: wxGUI: vdigit crashes on a big map
#384: wxGUI: vdigit crashes on a big map ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution:|Keywords: vdigit Platform: Linux | Cpu: x86-64 ---+ Comment (by mmetz): Replying to [comment:2 hamish]: is there a way to count number of vertices? that is masked in the v.info -t output. Only through v.build (XXX vertices registered) because the number of vertices is not stored in topo and every primitive must be read. So I'm not sure how it compares, but here I tried: [snip] it was slow used a huge amount of memory, but it didn't crash. It's partially slow and needs a huge amount of memory because topo keeps a list of updated features when opening a vector in update mode. This is unused and disabled in grass7, one effect is that vdigit in grass7 is a bit faster and uses less memory than in grass6. Markus M -- Ticket URL: https://trac.osgeo.org/grass/ticket/384#comment:9 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] Re: [GRASS GIS] #842: wx location wizard: spincontrol busted for UTM zone
#842: wx location wizard: spincontrol busted for UTM zone ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: wxGUI | Version: svn-develbranch6 Resolution:|Keywords: location wizard, utm Platform: Linux | Cpu: x86-64 ---+ Comment (by cmbarton): I've changed the UTM Zone entry widget to a simple text widget with validation to keep it within the 1-60 range. I've added a new patch here: location_wizard.patch3. Please test. Michael -- Ticket URL: http://trac.osgeo.org/grass/ticket/842#comment:17 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] Re: [GRASS GIS] #843: v.digit broken on new WinGrass release
#843: v.digit broken on new WinGrass release
---+
Reporter: cnielsen | Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: blocker | Milestone: 6.4.0
Component: Vector| Version: unspecified
Resolution:|Keywords: wingrass,v.digit
Platform: MSWindows XP | Cpu: x86-64
---+
Comment (by hellik):
Replying to [comment:18 hamish]:
this is a blocker as 2 of 2 vector digitizers are now broken in current
6.4 wingrass. Fortunately the solution for the tcl one seems well in hand
forthcoming. Will backport revert then sync solution to the 6.4 branch
as soon as it is tested confirmed in 6.5.
from dev-ml:
{{{
Hamish wrote:
* 843 v.digit broken on new WinGrass release
- contains a suggestion
Maris and Glynn are working to resolve this. Seems plausible that it
will be backported and ready for final testing by next week.
FWIW, I've changed 6.5 as I consider appropriate, i.e. removed
$(FORMLIB) and sync'd generate.c to lib/form's version.
}}}
tested on a fresh build of grass65 on WinVista32:
= v.digit is working
Helmut
--
Ticket URL: http://trac.osgeo.org/grass/ticket/843#comment:19
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] Re: [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista
#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
--+-
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: |Keywords: r.patch, wingrass
Platform: MSWindows Vista | Cpu: Unspecified
--+-
Comment (by hellik):
Replying to [comment:6 hellik]:
[...]
{{{
r.patch.exe - Komponente nicht gefunden - component not found
---
Die Anwendung konnte nicht gestartet werden, weil
libgrass_gis.6.4.0svn.dll nicht gefunden wurde. Neuinstallation der
Anwendung könnte das Problem beheben. - ''The application could not be
started, because libgrass_gis.6.4.0svn.dll could not be found.''
}}}
and afterwards r.patch crashes
Helmut
and in the wx-gui-command-output:
{{{
Traceback (most recent call last):
File c:/OSGeo4W/apps/grass/grass-6.4.0svn/etc/wxpython/wx
gui.py, line 466, in OnRunCmd
self.goutput.RunCmd(cmd, switchPage=False)
File c:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\goutput.py, line 352, in RunCmd
menuform.GUI().ParseCommand(cmdlist, parentframe=self)
File c:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py, line 1818, in ParseCommand
xml.sax.parseString(getInterfaceDescription(cmd[0]).decode(e
nc).encode(utf-8),
File c:\OSGeo4W\apps\grass\grass-6.4.0svn\etc\wxpython\gu
i_modules\menuform.py, line 1757, in
getInterfaceDescription
raise IOError, _(Unable to fetch interface description for
command '%s'.) % cmd
IOError
:
Unable to fetch interface description for command 'r.patch'.
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/759#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
[GRASS-dev] Re: [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista
#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
--+-
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: |Keywords: r.patch, wingrass
Platform: MSWindows Vista | Cpu: Unspecified
--+-
Comment (by hellik):
Replying to [comment:7 hellik]:
from the dev-ml
{{{
Has anyone considered that patch might be triggering an anti-virus
rule?
}}}
related(?) information in following link:
http://news.softpedia.com/news/Program-Names-Intimately-Connected-with-
Administrator-Rights-in-Windows-Vista-52813.shtml
= Program Names Intimately Connected with Administrator Rights in Windows
Vista
--
Ticket URL: http://trac.osgeo.org/grass/ticket/759#comment:8
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] Re: [GRASS GIS] #707: wxGUI: v.digit broken for new maps: No vector map selected for editing. although selected
#707: wxGUI: v.digit broken for new maps: No vector map selected for editing. although selected --+- Reporter: neteler | Owner: martinl Type: defect | Status: reopened Priority: blocker | Milestone: 6.4.0 Component: wxGUI| Version: 6.4.0 RCs Resolution: |Keywords: vector digitizer, vdigit Platform: Linux| Cpu: All --+- Changes (by micha): * status: closed = reopened * resolution: fixed = Comment: Even tho' this ticket was closed, I seem to have stumbled over the same problem on a new install. I'm setting up a Fedora 12 machine (i686). Finished compiling GRASS 6.4R5 successfully. I haven't done any real work yet, but everything looks OK, except for the digitizer in wxGUI. (v.digit in the tck/tk interface works fine). Here's the backtrace when I try to select a vector map for digitizing: Traceback (most recent call last): File /usr/local/grass-6.4/grass-6.4.0RC5/etc/wxpython/gui_modules/toolbars.py, line 1071, in OnSelectMap self.StartEditing(self.layers[selection]) File /usr/local/grass-6.4/grass-6.4.0RC5/etc/wxpython/gui_modules/toolbars.py, line 1103, in StartEditing self.parent.digit = Digit(mapwindow=self.parent.MapWindow) File /usr/local/grass-6.4/grass-6.4.0RC5/etc/wxpython/gui_modules/vdigit.py, line 685, in __init__ VDigit.__init__(self, mapwindow) File /usr/local/grass-6.4/grass-6.4.0RC5/etc/wxpython/gui_modules/vdigit.py, line 223, in __init__ mapwindow) File /usr/local/grass-6.4/grass-6.4.0RC5/etc/wxpython/vdigit/grass6_wxvdigit.py, line 333, in __init__ this = _grass6_wxvdigit.new_Digit(*args) TypeError: in method 'new_Digit', argument 2 of type 'wxWindow *' wxxPython version is: wxPython-devel-2.8.9.2-3.fc12.i686 wxPython-2.8.9.2-3.fc12.i686 Regards and thanks for any tips, Micha -- Ticket URL: http://trac.osgeo.org/grass/ticket/707#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
[GRASS-dev] Re: [GRASS GIS] #707: wxGUI: v.digit broken for new maps: No vector map selected for editing. although selected
#707: wxGUI: v.digit broken for new maps: No vector map selected for editing. although selected +--- Reporter: neteler| Owner: martinl Type: defect | Status: closed Priority: blocker| Milestone: 6.4.0 Component: wxGUI | Version: 6.4.0 RCs Resolution: duplicate |Keywords: vector digitizer, vdigit Platform: Linux | Cpu: All +--- Changes (by martinl): * status: reopened = closed * resolution: = duplicate Comment: Replying to [comment:7 micha]: this = _grass6_wxvdigit.new_Digit(*args) TypeError: in method 'new_Digit', argument 2 of type 'wxWindow *' this is know problem, see #782. Downgrade your version of swig e.g. to 1.3.36. -- Ticket URL: http://trac.osgeo.org/grass/ticket/707#comment:8 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
FW: [GRASS-dev] Connection failure from v.krige to R (Win XP)
after invoking the Kriging module a system message appears: 'Are you sure you want to add the information in RHOME to the registry?'. When Yes button is pressed, another message appears: 'Cannot import RHOME. Error opening the file. There may be a disk or file system error.' I can't get rid of this (probably some .reg file is being executed), but this is not the reason of... Loading continues, but important buttons in the Kriging dialog are disabled. ... as I've just found it works properly if valid data set is chosen. If no 'Numeric column' is present, buttons Plot/Refresh Variogram or Run are disabled. My fault. When entering the Kriging dialog when a vector map was selected before this action via menu, I am getting the following error and execution is stopped (no dialog appears) v.krige input=isoli...@honza ERROR: Required parameter column was not set: ... It seems to be a default behaviour when a vector map is selected. This message is related to the previous one (if Kriging is performed on a vector layer with no proper column data). But in such case maybe any Warning dialog would be better than a message in the command line output... I tried a better data set and although I got the correct variogram plot, later I encountered ImageMagick! Exception: import.exe: unable to open X server `' @ import.c/ImportImageCommand/367 [No such file or directory]. Is it necessary to setup something else? BTW, there is enclosed a screenshot in this e-mail with the current appearance of the Krige command output tab. That horizontal thin white line is a textbox with output messages... It could be improved a bit. Regards, Jan krige_output.png Description: Binary data ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: FW: [GRASS-dev] Connection failure from v.krige to R (Win XP)
Zdravim, 2010/1/8 Jan Tošovský j.tosov...@tiscali.cz: BTW, there is enclosed a screenshot in this e-mail with the current appearance of the Krige command output tab. That horizontal thin white line is a textbox with output messages... It could be improved a bit. try the latest revision, it should be already fixed. Martin -- Martin Landa landa.martin gmail.com * http://gama.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: FW: [GRASS-dev] Connection failure from v.krige to R (Win XP)
On Fri, 2010-01-08 at 22:06 +0100, Jan Tošovský wrote: after invoking the Kriging module a system message appears: 'Are you sure you want to add the information in RHOME to the registry?'. When Yes button is pressed, another message appears: 'Cannot import RHOME. Error opening the file. There may be a disk or file system error.' I can't get rid of this (probably some .reg file is being executed), but this is not the reason of... Hi Jan, thanks for report. Unfortunately I have little time to look at this in the next days, but will keep it in the todo list. When entering the Kriging dialog when a vector map was selected before this action via menu, I am getting the following error and execution is stopped (no dialog appears) v.krige input=isoli...@honza ERROR: Required parameter column was not set: ... It seems to be a default behaviour when a vector map is selected. This message is related to the previous one (if Kriging is performed on a vector layer with no proper column data). But in such case maybe any Warning dialog would be better than a message in the command line output... Raising an error is consistent when the line you pasted above is typed in the shell. I don't know if setting this parameter is an expected behaviour, in any case raise a warning is surely not enough, as the procedure will miss mandatory arguments. I'll try to reproduce this asap. I tried a better data set and although I got the correct variogram plot, later I encountered ImageMagick! Exception: import.exe: unable to open X server `' @ import.c/ImportImageCommand/367 [No such file or directory]. Is it necessary to setup something else? No, ImageMagick is not an explicit dependency of v.krige. I'll dig into this. BTW, there is enclosed a screenshot in this e-mail with the current appearance of the Krige command output tab. That horizontal thin white line is a textbox with output messages... It could be improved a bit. Hm looks like the GRASS trunk's wxGUI behaviour some revisions ago. It's fixed for sure in head. Hope this helps for now, and thanks again for report. all the best, Anne Regards, Jan ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev signature.asc Description: This is a digitally signed message part ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista
#759: r.patch non-functional in WinGRASS 6.4 svn on Vista --+- Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: 6.4.0 RCs Resolution: |Keywords: r.patch, wingrass Platform: MSWindows Vista | Cpu: Unspecified --+- Comment (by hamish): does it happen on 64bit? the article seems to indicate this smarts is only reserved for the 32bit editions. ( ?!) -- Ticket URL: https://trac.osgeo.org/grass/ticket/759#comment:10 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] Re: [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista
#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
--+-
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: |Keywords: r.patch, wingrass
Platform: MSWindows Vista | Cpu: Unspecified
--+-
Comment (by hellik):
Replying to [comment:9 hamish]:
so if you copy/rename r.patch.exe to r.fred.exe, does it then
magically work on Vista?
?!
if so, would a r.patch.bat wrapper script suffer the same fate?
How that would end up with a Bad file number error I have no idea.
(does that mean bad a FID? or stderr/stdout not existing, or..?)
Hamish
WinGrass65 WinVista32
r.patch.exe renamed to r.helli.exe and started from the msys-shell and the
wx-gui-commandline:
{{{
GRASS 6.5.svn (nc_spm_08):c:/Users/syringia r.helli input=extr1,extr2
output
=testpatch2
100%
Erstelle Supportdateien für die Rasterkarte testpatch2.
}}}
everything is working, the two rasters were patched. so it's really the
name that causes the problems. what's about a batch-file, i don't know.
i see also in the windows-file-explorer that both r.patch.exe and
v.patch.exe are marked by WinVista with a win-symbol, so Vista really
recognize only by the file-name that there could something
important/dangerous for the system and activates the UAC.
Helmut
--
Ticket URL: https://trac.osgeo.org/grass/ticket/759#comment:11
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] Re: [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista
#759: r.patch non-functional in WinGRASS 6.4 svn on Vista --+- Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: 6.4.0 RCs Resolution: |Keywords: r.patch, wingrass Platform: MSWindows Vista | Cpu: Unspecified --+- Comment (by hamish): Replying to [comment:11 hellik]: r.patch.exe renamed to r.helli.exe and started from the msys-shell and the wx-gui-commandline: ... everything is working, the two rasters were patched. so it's really the name that causes the problems. ... i see also in the windows-file-explorer that both r.patch.exe and v.patch.exe are marked by WinVista with a win-symbol, so Vista really recognize only by the file-name that there could something important/dangerous for the system and activates the UAC. sigh. what a complete pile of poo. -- Ticket URL: https://trac.osgeo.org/grass/ticket/759#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] Re: [GRASS GIS] #629: WinGRASS: spaces in pathnames
#629: WinGRASS: spaces in pathnames ---+ Reporter: hamish| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: normal| Milestone: 6.4.0 Component: Installation | Version: 6.4.0 RCs Resolution:|Keywords: wingrass, msys Platform: MSWindows XP | Cpu: x86-32 ---+ Comment (by hamish): see also #809 -- Ticket URL: https://trac.osgeo.org/grass/ticket/629#comment:34 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] Re: [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista
#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
--+-
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: |Keywords: r.patch, wingrass
Platform: MSWindows Vista | Cpu: Unspecified
--+-
Comment (by glynn):
Replying to [comment:12 hamish]:
sigh. what a complete pile of poo.
+1
For the record, I'll include a copy of the referenced MSDN article:
[http://msdn.microsoft.com/en-us/library/aa905330.aspx]
Someone who cares about Windows (my caring about Windows level just
dropped by a large margin after finding out about this) might want to look
into how to create a manifest and whether this actually solves the
problem.
Also:
1. Is this caused (in whole or in part) by GRASS being installed somewhere
other than the Program Files directory? If it is, then I care even less.
If there are still problems with spaces in $GISBASE, we should fix them,
rather than expecting GRASS to be installed somewhere else.
2. Is this relevant:
{{{
Note The User Account Control: Detect application installations and
prompt for
elevation setting must be enabled for installer detection to detect
installation
programs. This setting is enabled by default and can be configured using
the
Security Policy Manager snap-in (secpol.msc) or with Group Policy
(gpedit.msc).
}}}
I.e. if you disable that setting, does the problem go away?
If it does, then problem solved, IMNSHO.
--
Ticket URL: http://trac.osgeo.org/grass/ticket/759#comment:13
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] Re: [GRASS GIS] #842: wx location wizard: spincontrol busted for UTM zone
#842: wx location wizard: spincontrol busted for UTM zone
---+
Reporter: hamish| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution:|Keywords: location wizard, utm
Platform: Linux | Cpu: x86-64
---+
Comment (by hamish):
Replying to [comment:17 cmbarton]:
I've changed the UTM Zone entry widget to a simple text widget
with validation to keep it within the 1-60 range. I've added a
new patch here: location_wizard.patch3. Please test.
Yes it works if you type in zone=1-60.
I'm seeing that +lon_0=-183 again though and I figured out how to
reproduce it. If you enter 0 or 99 for the zone it automatically
resets to zone 1 or 60, respectively. Apparently this is only visually. If
you proceed to the summary page in the location wizard instead of +zone=23
you will see +proj=tmerc +lon_0=411 etc. ...
{{{
-PROJ_INFO-
name : Transverse Mercator
proj : tmerc
datum : wgs84
ellps : wgs84
lat_0 : 0
lon_0 : -183
k : 0.9996
x_0: 50
y_0: 0
no_defs: defined
-PROJ_UNITS
unit : Meter
units : Meters
meters : 1
}}}
fwiw1: I notice that PROJ_UNITS is uppercased, which seems different to
how I always seem to have remembered it there.
fwiw2: I notice this patch no longer has the try: row/column stuff.
(different things should go into 2 different commits I guess)
Hamish
--
Ticket URL: http://trac.osgeo.org/grass/ticket/842#comment:18
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] Re: [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista
#759: r.patch non-functional in WinGRASS 6.4 svn on Vista --+- Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Raster | Version: 6.4.0 RCs Resolution: |Keywords: r.patch, wingrass Platform: MSWindows Vista | Cpu: Unspecified --+- Comment (by hamish): Replying to [comment:13 glynn]: [http://msdn.microsoft.com/en-us/library/aa905330.aspx] if it is only for 32bit Vista, that will go away soon. Any Windows 7 and/or 64 bit users around to test? Also: 1. Is this caused (in whole or in part) by GRASS being installed somewhere other than the Program Files directory? If it is, then I care even less. If there are still problems with spaces in $GISBASE, we should fix them, rather than expecting GRASS to be installed somewhere else. I'm not sure if this is relevant at run time or only at build time, but fwiw the MSys devs seem completely uninterested in fixing spaces in pathnames issues. They've thrown that class of bugs in the too hard, won't even try pile. I've had a patch in their tracker for 6 months with no action and 2 of 3 commenting devs recommending wontfix. see #629 and, https://sourceforge.net/tracker/index.php?func=detailaid=2808978group_id=2435atid=102435 https://sourceforge.net/tracker/?func=detailatid=102435aid=1511614group_id=2435 for now I have posted the r.patch work-around solution on the Errata section of the CompileOnWindows trac wiki page. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/759#comment:14 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] Re: [GRASS GIS] #759: r.patch non-functional in WinGRASS 6.4 svn on Vista
#759: r.patch non-functional in WinGRASS 6.4 svn on Vista
--+-
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: |Keywords: r.patch, wingrass
Platform: MSWindows Vista | Cpu: Unspecified
--+-
Comment (by hellik):
Replying to [comment:13 glynn]:
Replying to [comment:12 hamish]:
sigh. what a complete pile of poo.
+1
+1
For the record, I'll include a copy of the referenced MSDN article:
[http://msdn.microsoft.com/en-us/library/aa905330.aspx]
Someone who cares about Windows (my caring about Windows level just
dropped by a large margin after finding out about this) might want to look
into how to create a manifest and whether this actually solves the
problem.
Also:
1. Is this caused (in whole or in part) by GRASS being installed
somewhere other than the Program Files directory? If it is, then I care
even less. If there are still problems with spaces in $GISBASE, we should
fix them, rather than expecting GRASS to be installed somewhere else.
in my case (i don't anything about the original report), i don't install
the WinGrass-installer, i'm building WinGrass in the osgeo4w-stack which
is installed in C:\OSGeo4W. this path is proposed by the osgeo4w-
installer.
2. Is this relevant:
{{{
Note The User Account Control: Detect application installations and
prompt for
elevation setting must be enabled for installer detection to detect
installation
programs. This setting is enabled by default and can be configured
using the
Security Policy Manager snap-in (secpol.msc) or with Group Policy
(gpedit.msc).
}}}
I.e. if you disable that setting, does the problem go away?
If it does, then problem solved, IMNSHO.
i've disabled this option, but there is no difference, the problem
resists.
the actual WinGrass-Installer proposes to install WinGrass to c:\Grass. So
maybe, like mentionend in the ms-document that c:\Program Files is a
safe site, the WinGrass-Installer should be changed to install the
application into c:\Program Files\Grass to exclude this possible source of
problems? Maybe this should be tested before Grass64-release?
Helmut
--
Ticket URL: http://trac.osgeo.org/grass/ticket/759#comment:15
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] Re: [GRASS GIS] #461: v.to.db crashes on a shapefile connected with v.external
#461: v.to.db crashes on a shapefile connected with v.external ---+ Reporter: msieczka | Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: critical | Milestone: 6.4.0 Component: Vector| Version: svn-develbranch6 Resolution:|Keywords: Platform: Linux | Cpu: x86-64 ---+ Comment (by hamish): [copied from the ML] - still valid? Markus Metz wrote: I think so because attribute queries are not possible on OGR vectors connected with v.external (most OGR vector layers don't have a grass-like key column). I think Martin L fixed that in grass7. ... Attribute table operations (query, upload values) are still not possible in grass7 for OGR vector layers that don't have a key column, i.e. for most OGR-supported formats. Still valid for both v.external and direct OGR link. We may not be able to add the requested functionality for the next release, but can we do anything about replacing the segfault with a G_fatal_error()? Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/461#comment:5 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] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass --+- Reporter: JonBall | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: critical | Milestone: 6.4.0 Component: Vector | Version: svn-releasebranch64 Resolution: |Keywords: v.db.addtable, wingrass Platform: MSWindows Vista | Cpu: x86-64 --+- Comment (by hamish): Replying to [comment:18 mmetz]: Replying to [comment:16 hamish]: I've just attached to this ticket a patch against 6.5 which allows spaces in pathnames ... Tested, works fine. committed in 6.5svn and trunk. One minor bug though: in the new v.db.addtable line 129 [g.findfile] does not work with a fully qualified name, interestingly it pretty much works if you just chop off the @mapset part because g.findfile searches the full mapset path as a module would. Anyway, I've ripped this code out now in favor of using the VAR file's default DB settings for the mapset. So you are able to now control it instead of being locked to what the map was already using. Committed in 6.5svn and trunk. For grass7, I would suggest to use fs=| as default (anything but whitespace) whenever dblinks are written or printed, e.g. Vect_write_dblinks() and v.db.connect -p Done and done. I'm sure we'll hear about it if there are any problems, but after some light testing it seems to work ok. the only thing left to decide is when to backport this stuff to 6.4. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/809#comment:19 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] Re: [GRASS GIS] #809: v.db.addtable consistently fails in winGrass
#809: v.db.addtable consistently fails in winGrass
--+-
Reporter: JonBall | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: critical | Milestone: 6.4.0
Component: Vector | Version: svn-releasebranch64
Resolution: |Keywords: v.db.addtable, wingrass
Platform: MSWindows Vista | Cpu: x86-64
--+-
Comment (by hamish):
Replying to [comment:11 hamish]:
stuff to audit:
{{{
lib/db/
dbmi_base/login.c: ret = sscanf(buf, %[^ ] %[^ ] %[^ ] %[^ ], dr,
db, usr, pwd);
dbmi_base/dbmscap.c:if (sscanf(buf, %[^:]:%[^:]:%[^:\n], name,
startup, comment) == 3)
dbmi_base/dbmscap.c:else if (sscanf(buf, %[^:]:%[^:\n], name,
startup) == 2)
}}}
(still needs to be done)
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/809#comment:20
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] Re: [GRASS GIS] #842: wx location wizard: spincontrol busted for UTM zone
#842: wx location wizard: spincontrol busted for UTM zone
---+
Reporter: hamish| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: critical | Milestone: 6.4.0
Component: wxGUI | Version: svn-develbranch6
Resolution:|Keywords: location wizard, utm
Platform: Linux | Cpu: x86-64
---+
Comment (by cmbarton):
Replying to [comment:18 hamish]:
Replying to [comment:17 cmbarton]:
I've changed the UTM Zone entry widget to a simple text widget
with validation to keep it within the 1-60 range. I've added a
new patch here: location_wizard.patch3. Please test.
Yes it works if you type in zone=1-60.
I'm seeing that +lon_0=-183 again though and I figured out how to
reproduce it. If you enter 0 or 99 for the zone it automatically
resets to zone 1 or 60, respectively. Apparently this is only visually. If
you proceed to the summary page in the location wizard instead of +zone=23
you will see +proj=tmerc +lon_0=411 etc. ...
{{{
-PROJ_INFO-
name : Transverse Mercator
proj : tmerc
datum : wgs84
ellps : wgs84
lat_0 : 0
lon_0 : -183
k : 0.9996
x_0: 50
y_0: 0
no_defs: defined
-PROJ_UNITS
unit : Meter
units : Meters
meters : 1
}}}
This is all fixed and now committed. I'll try to port this to to 6.5 and 7
after it's had a few more tests--and will then mark this resolved. Thanks
for all your help in getting this worked out. The bindings and events
generated by the spinctrl were byzantine. This works much better.
fwiw1: I notice that PROJ_UNITS is uppercased, which seems different to
how I always seem to have remembered it there.
I don't understand what you're referring to. There is no upper() function
in the module and nothing named proj_units that I could find. The location
wizard does not set the proj units. This is done by g.proj when the proj4
parameters are sent to it. I use the lower() function to make searching
more rewarding regardless of case.
fwiw2: I notice this patch no longer has the try: row/column stuff.
(different things should go into 2 different commits I guess)
I had just archived this aside until I got the spin box fixed. It is in
the bugfix commit.
Michael
Hamish
--
Ticket URL: http://trac.osgeo.org/grass/ticket/842#comment:20
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] Re: [GRASS GIS] #7: Location wizard: should predefine DB connection for new location
#7: Location wizard: should predefine DB connection for new location --+- Reporter: neteler | Owner: hamish Type: defect | Status: closed Priority: major| Milestone: 6.4.0 Component: default | Version: svn-trunk Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by hamish): * status: assigned = closed * platform: = Unspecified * resolution: = fixed * cpu: = Unspecified Comment: everything seems to run smoothly enough now. closing bug, noise all. -- Ticket URL: https://trac.osgeo.org/grass/ticket/7#comment:15 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] Re: [GRASS GIS] #455: d.what.rast segfault
#455: d.what.rast segfault --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: closed Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: fixed|Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by hamish): * status: new = closed * resolution: = fixed Comment: appears to be fixed. -- Ticket URL: https://trac.osgeo.org/grass/ticket/455#comment:2 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
