[GRASS-dev] Re: vdigit working on Mac mostly
Hi, 2008/10/9 Michael Barton [EMAIL PROTECTED]: There used to be a combo box on the left of the digitizer tool bar that allowed selection of the map to digitize (or to create a new map). This has disappeared. Has it been removed or is it just not showing up? There was an earlier problem with combo boxes in Mac toolbars. I thought it was fixed, but maybe it's back. There is a workaround (used for the combo box in the main display toolbar). no, the combobox in vdigit toolbar hasn't been removed. Seems to be a bug in Mac wxPython. Can you see combobox in map toolbar? 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
[GRASS-dev] Re: vdigit working on Mac mostly
On Oct 8, 2008, at 11:08 PM, Martin Landa wrote: Hi, 2008/10/9 Michael Barton [EMAIL PROTECTED]: There used to be a combo box on the left of the digitizer tool bar that allowed selection of the map to digitize (or to create a new map). This has disappeared. Has it been removed or is it just not showing up? There was an earlier problem with combo boxes in Mac toolbars. I thought it was fixed, but maybe it's back. There is a workaround (used for the combo box in the main display toolbar). no, the combobox in vdigit toolbar hasn't been removed. Seems to be a bug in Mac wxPython. Can you see combobox in map toolbar? I went ahead and applied the Mac fix for the missing combo box to develbranch_6. Could you check to see if it works OK for you? Thanks. Back to work. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #324: Ability to handle subgroups with general commands as all other datatypes
#324: Ability to handle subgroups with general commands as all other datatypes --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: subgroup, general commands Platform: All | Cpu: Unspecified --+- Changes (by neteler): * type: defect = enhancement -- Ticket URL: http://trac.osgeo.org/grass/ticket/324#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] Re: [GRASS-SVN] r33717 - grass/trunk/lib/gis
On Thu, Oct 9, 2008 at 12:38 AM, Hamish [EMAIL PROTECTED] wrote: Markus Neteler wrote: Glynn: Make G_is_[fd]_null_value() check for any NaN, not just all-ones fwiw, I consider this a rare, but potentially very important change to the raster engine. Markus: /me backport this? Glynn: Maybe. Unless there are modules which genuinely need to distinguish GRASS nulls from other NaNs, Hamish: It can help in tracking down bugs, e.g. see the BUGS section of the r.in.xyz man page. Markus: OK, backported: r33752 We are still in 6.4-devel mode. um, I meant that as a reason NOT to backport it. Now it is less obvious when nans are introduced by mistake. Ah! Feel free to revert. I am unable to judge this... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Problem with R on cluster (HPC)
Rainer, On Wed, Oct 8, 2008 at 7:25 PM, Rainer M Krug [EMAIL PROTECTED] wrote: Hi I am trying to run a simulation on an HPC (high performance cluster). To simulate, I have to start GRASS on each node and execute a script. I wrote the script into .grass.bashrc in my home directory, which is available on all nodes. The .grass.bashrc is as follow: AFAIK this is just the wrong place. http://grass.osgeo.org/grass64/manuals/html64_user/variables.html To get personal BASH shell definitions (aliases, color listing option, ...) into GRASS, store them in: $HOME/.grass.bashrc Did you take a look at http://grass.osgeo.org/wiki/Parallel_GRASS_jobs ? Maybe that helps how to set it up. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: vdigit working on Mac mostly
Hi, 2008/10/9 Michael Barton [EMAIL PROTECTED]: [...] no, the combobox in vdigit toolbar hasn't been removed. Seems to be a bug in Mac wxPython. Can you see combobox in map toolbar? I went ahead and applied the Mac fix for the missing combo box to develbranch_6. Could you check to see if it works OK for you? Thanks. Seems to work here (backpored to trunk). 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
[GRASS-dev] [GRASS GIS] #326: g.findfile element=colr2
#326: g.findfile element=colr2
+---
Reporter: martinl | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-develbranch6
Keywords: colr2, color table |Platform: All
Cpu: All |
+---
Module g.findfile doesn't support 'colr2' element. The attached patch adds
this support. 'colr2' element can be searched only in the current mapset
and file needs to be given as fully qualified, e.g.
{{{
g.findfile element=colr2 [EMAIL PROTECTED]
name='[EMAIL PROTECTED]'
mapset='landa'
fullname='[EMAIL PROTECTED]'
file='/home/martin/grassdata/zod/landa/colr2/PERMANENT/tm1'
}}}
Martin
--
Ticket URL: http://trac.osgeo.org/grass/ticket/326
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] Problem with R on cluster (HPC)
On Thu, Oct 9, 2008 at 9:51 AM, Markus Neteler [EMAIL PROTECTED] wrote: Rainer, On Wed, Oct 8, 2008 at 7:25 PM, Rainer M Krug [EMAIL PROTECTED] wrote: Hi I am trying to run a simulation on an HPC (high performance cluster). To simulate, I have to start GRASS on each node and execute a script. I wrote the script into .grass.bashrc in my home directory, which is available on all nodes. The .grass.bashrc is as follow: AFAIK this is just the wrong place. Right - I realized this morning the environmental variable GRASS_BATCH_JOB: it is doing exactly what I need. It is working now. http://grass.osgeo.org/grass64/manuals/html64_user/variables.html To get personal BASH shell definitions (aliases, color listing option, ...) into GRASS, store them in: $HOME/.grass.bashrc Did you take a look at http://grass.osgeo.org/wiki/Parallel_GRASS_jobs ? Maybe that helps how to set it up. Thanks - that one pointed out GRASS_BATCH_JOB as well. Thanks, Rainer Markus -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Faculty of Science Natural Sciences Building Private Bag X1 University of Stellenbosch Matieland 7602 South Africa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-stats] Re: [R-sig-Geo] writing shapefiles / DBF files when input data contains NA
On Tue, 7 Oct 2008, Dylan Beaudette wrote:
On Tue, Oct 7, 2008 at 6:26 PM, Hamish [EMAIL PROTECTED] wrote:
Dylan:
It looks like the limiting factor in this equation is the
code used in v.out.ogr.
Following Dylan's posting on the GDAL list, and Frank's response, I
suggest the following simple patch to vector/v.out.ogr/main.c (here 6.3):
$ diff -u main.c_old main.c
--- main.c_old 2008-10-09 10:54:19.0 +0200
+++ main.c 2008-10-09 11:30:34.0 +0200
@@ -625,7 +625,9 @@
colsqltype = db_get_column_sqltype(Column);
colctype = db_sqltype_to_Ctype ( colsqltype );
G_debug (2, colctype = %d, colctype );
- switch ( colctype ) {
+/* RSB 081009 emit unset fields */
+if (!db_test_value_isnull(Value)) {
+ switch ( colctype ) {
case DB_C_TYPE_INT:
OGR_F_SetFieldInteger( Ogr_feature, j, db_get_va
lue_int(Value) );
break;
@@ -639,7 +641,8 @@
db_convert_column_value_to_string (Column,
dbst
ring);
OGR_F_SetFieldString( Ogr_feature, j, db_get_str
ing (dbstring) );
break;
- }
+ }
+} /* RSB */
}
}
}
In 6.4 this is after line 717. Essentially it just uses
db_test_value_isnull() not to set values in OGR fields if the DB field
value is NULL, and follows Frank's suggestion.
This matches code near line 939 in OGRGRASSLayer::SetAttributes()
gdal/ogr/ogr_frmts/grass/ogrgrasslayer.cpp in the vector plugin, which
uses:
if ( !db_test_value_isnull(value) )
I'm sure the patch needs checking, but with changes in the R rgdal package
to support vector null data correctly, it ought to improve the interface.
Best wishes,
Roger
maybe a silly question, but is a 3rd party format even needed here?
$ ogrinfo --formats | grep -i grass
- GRASS (readonly)
at least in the one direction.
Excellent question. I had also wondered about this. It looks like
there is a new argument in readVECT():
# read in directly with GDAL/OGR -- no intermediate file:
x - readVECT6('xxx', plugin=TRUE)
This is quite fast and depends on the GDAL-GRASS plugin... However,
NULL data in a GRASS table is not imported correctly-- character
fields are imported as '', and numeric fields as 0.
So... Is the error in GDAL itself?
I tried inspecting a vector from GRASS with NULL data in some of the
columns from the table, using ogrinfo -al
location/mapset/vector/xxx/head
OGRFeature(1):23
cat (Integer) = 24
cat_ (Integer) = 24
str1 (String) = (null)
xyz (Real) = (null)
abc (Integer) = (null)
POINT (591583 4925280 0)
... which seems to correctly report the NULL values.
This leads me to suspect that something in readOGR() and writeOGR are
at fault in handling of NULL values.
Unfortunately looking at the rgdal source code wasn't very productive
(my fault).
Cheers,
Dylan
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: [EMAIL PROTECTED]
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation success
On Oct 9, 2008, at 4:38 AM, Glynn Clements wrote: Michael Barton wrote: With William's recent fix, I got farther tonight on getting a working wxPython nviz than ever before. I still have to remove render.c, but otherwise compilation goes well. When I select nviz from the map display, I now get a message box saying Please wait, loading data... and I get a partial nviz toolbar (color picker and exit door). Then it sits. In the layer manager output window, I get the following error. File /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc /wxpython/gui_modules/nviz_tools.py, line 1308, in CreateControl size=sizeW) C++ assertion !(style wxSL_VERTICAL) || !(style wxSL_HORIZONTAL) failed at ../src/mac/carbon/slider.cpp(98) in Create(): incompatible slider direction and orientation The style parameter is set thus: if sliderHor: style = wx.SL_HORIZONTAL | wx.SL_AUTOTICKS | \ wx.SL_BOTTOM sizeW = (size, -1) else: style = wx.SL_VERTICAL | wx.SL_AUTOTICKS | \ wx.SL_BOTTOM | wx.SL_INVERSE sizeW = (-1, size) Although it doesn't explicitly say so in the documentation, I believe that SL_BOTTOM is only valid in conjunction with SL_HORIZONTAL. AFAICT, for SL_VERTICAL, you have to choose either SL_LEFT or SL_RIGHT. -- Glynn Clements [EMAIL PROTECTED] - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation success
On Oct 9, 2008, at 4:27 AM, Glynn Clements wrote: To be honest, I'm not particularly confident of the OSX-specific rule for building the module: ifeq ($(findstring darwin,$(ARCH)),darwin) $(CXX) -o $@ $(LDFLAGS) $^ $(EXTRA_LIBS) else I would expect that command to try to build an executable. This works because there is also a conditional on setting EXTRA_LIBS, so that it will build a module (-bundle), which is a little different than a library on OSX. We don't want SHLIB_LD because it has the - dynamiclib flag hardwired into it. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The equator is so long, it could encircle the earth completely once. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation success
Michael Barton wrote: Does init_grass6_wxnviz (or anything similar) show up in the output from: nm -D OBJ.*/_grass6_wxnviz.so ? I'm not sure I understand what you're asking. But here is a result. cmb-MBP-2:~ cmbarton$ cd /Applications/Grass/GRASS-6.4.app/Contents/ MacOS/etc/wxpython/nviz cmb-MBP-2:nviz cmbarton$ nm -D OBJ.*/_grass6_wxnviz.so nm: invalid argument -D Usage: nm [-agnoprumxjlfAP[s segname sectname] [-] [-t format] [[-arch arch_flag] ...] [file ...] Okay; try it without -D. Also try it on OBJ.*/grass7_wxnviz_wrap.o. To be honest, I'm not particularly confident of the OSX-specific rule for building the module: ifeq ($(findstring darwin,$(ARCH)),darwin) $(CXX) -o $@ $(LDFLAGS) $^ $(EXTRA_LIBS) else I would expect that command to try to build an executable. What does file say about the resulting .so file? Is it comparable to the result of any of the binary modules which are part of the standard Python distribution? -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] nviz works!!!
On Oct 9, 2008, at 2:38 AM, Glynn Clements wrote: Michael Barton wrote: With William's recent fix, I got farther tonight on getting a working wxPython nviz than ever before. I still have to remove render.c, but otherwise compilation goes well. When I select nviz from the map display, I now get a message box saying Please wait, loading data... and I get a partial nviz toolbar (color picker and exit door). Then it sits. In the layer manager output window, I get the following error. File /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc /wxpython/gui_modules/nviz_tools.py, line 1308, in CreateControl size=sizeW) C++ assertion !(style wxSL_VERTICAL) || !(style wxSL_HORIZONTAL) failed at ../src/mac/carbon/slider.cpp(98) in Create(): incompatible slider direction and orientation The style parameter is set thus: if sliderHor: style = wx.SL_HORIZONTAL | wx.SL_AUTOTICKS | \ wx.SL_BOTTOM sizeW = (size, -1) else: style = wx.SL_VERTICAL | wx.SL_AUTOTICKS | \ wx.SL_BOTTOM | wx.SL_INVERSE sizeW = (-1, size) Although it doesn't explicitly say so in the documentation, I believe that SL_BOTTOM is only valid in conjunction with SL_HORIZONTAL. AFAICT, for SL_VERTICAL, you have to choose either SL_LEFT or SL_RIGHT. I just deleted the wx.SL_BOTTOM style and nviz works on the Mac!!! Really cool! I committed to develbranch_6. Could someone else test to make sure that this doesn't cause a problem somewhere else? I have to head to class. Thanks for the guidance on this, and the efforts of all of you working together. Cheers Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] nasty export of doubles
Hamish wrote:
{f,s}scanf(, %lf, ) is ok, yes?
Yes.
--
Glynn Clements [EMAIL PROTECTED]
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation success
Michael Barton wrote: With William's recent fix, I got farther tonight on getting a working wxPython nviz than ever before. I still have to remove render.c, but otherwise compilation goes well. When I select nviz from the map display, I now get a message box saying Please wait, loading data... and I get a partial nviz toolbar (color picker and exit door). Then it sits. In the layer manager output window, I get the following error. File /Applications/Grass/GRASS-6.4.app/Contents/MacOS/etc /wxpython/gui_modules/nviz_tools.py, line 1308, in CreateControl size=sizeW) C++ assertion !(style wxSL_VERTICAL) || !(style wxSL_HORIZONTAL) failed at ../src/mac/carbon/slider.cpp(98) in Create(): incompatible slider direction and orientation The style parameter is set thus: if sliderHor: style = wx.SL_HORIZONTAL | wx.SL_AUTOTICKS | \ wx.SL_BOTTOM sizeW = (size, -1) else: style = wx.SL_VERTICAL | wx.SL_AUTOTICKS | \ wx.SL_BOTTOM | wx.SL_INVERSE sizeW = (-1, size) Although it doesn't explicitly say so in the documentation, I believe that SL_BOTTOM is only valid in conjunction with SL_HORIZONTAL. AFAICT, for SL_VERTICAL, you have to choose either SL_LEFT or SL_RIGHT. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #327: v.out.ogr does not export features when 'dsn' AND 'layer' options are given
#327: v.out.ogr does not export features when 'dsn' AND 'layer' options are given ---+ Reporter: dylan | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: major | Milestone: 6.4.0 Component: Vector | Version: svn-develbranch6 Keywords: v.out.ogr |Platform: Linux Cpu: x86-32 | ---+ # does not export any features, # complaining that they don't have categories v.out.ogr -c in=bugsites dsn=some_folder layer=new_shpfile # exported expected features v.out.ogr -c in=bugsites dsn=new_shpfile This must be related to some magic associated with flag/option parsing. -- Ticket URL: http://trac.osgeo.org/grass/ticket/327 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-stats] Re: [R-sig-Geo] writing shapefiles / DBF files when input data contains NA
On Thursday 09 October 2008, Roger Bivand wrote:
On Tue, 7 Oct 2008, Dylan Beaudette wrote:
On Tue, Oct 7, 2008 at 6:26 PM, Hamish [EMAIL PROTECTED] wrote:
Dylan:
It looks like the limiting factor in this equation is the
code used in v.out.ogr.
Following Dylan's posting on the GDAL list, and Frank's response, I
suggest the following simple patch to vector/v.out.ogr/main.c (here 6.3):
$ diff -u main.c_old main.c
--- main.c_old 2008-10-09 10:54:19.0 +0200
+++ main.c 2008-10-09 11:30:34.0 +0200
@@ -625,7 +625,9 @@
colsqltype = db_get_column_sqltype(Column);
colctype = db_sqltype_to_Ctype ( colsqltype );
G_debug (2, colctype = %d, colctype );
- switch ( colctype ) {
+/* RSB 081009 emit unset fields */
+if (!db_test_value_isnull(Value)) {
+ switch ( colctype ) {
case DB_C_TYPE_INT:
OGR_F_SetFieldInteger( Ogr_feature, j,
db_get_va lue_int(Value) );
break;
@@ -639,7 +641,8 @@
db_convert_column_value_to_string (Column,
dbst
ring);
OGR_F_SetFieldString( Ogr_feature, j,
db_get_str ing (dbstring) );
break;
- }
+ }
+} /* RSB */
}
}
}
In 6.4 this is after line 717. Essentially it just uses
db_test_value_isnull() not to set values in OGR fields if the DB field
value is NULL, and follows Frank's suggestion.
OK-- I am using GRASS 6.4 SVN. Since this is the current (stable) developer
release it might be good to stick with it. I am using r33792 .
Before making the suggested changes, I have tried exporting some point data
with v.out.ogr:
# known working GRASS file with categories
v.out.ogr -e -c in=a_temp dsn=v.out.ogr_example layer=a_temp type=point
Exporting 25 points/lines...
100%
0 features written
WARNING: 25 features found without category skip
^^^
This looks like a new problem (?)... I know that these points have categories,
why is v.out.ogr ignoring them?
Do these lines have anything to do with this:
v.out.ogr:434
Vect_cat_get(Cats, field, cat);
if (cat 0 !donocat) { /* Do not export not labeled */
nocatskip++;
continue;
}
NO!
There is some kind of logic-related bug:
# does not export any features,
# complaining that they don't have categories
v.out.ogr -c in=xxx dsn=some_folder layer=new_shpfile
# exported expected features
v.out.ogr -c in=xxx dsn=new_shpfile
OK- posted here:
http://trac.osgeo.org/grass/ticket/327
The suggested fix appears to result in the creation of a DBF file (in the case
of shapefile) with properly encoded NULL.
Attached is a patch that applies this change to the develbranch-64 tree.
Should I make a ticket for this patch?
Cheers,
Dylan
This matches code near line 939 in OGRGRASSLayer::SetAttributes()
gdal/ogr/ogr_frmts/grass/ogrgrasslayer.cpp in the vector plugin, which
uses:
if ( !db_test_value_isnull(value) )
I'm sure the patch needs checking, but with changes in the R rgdal package
to support vector null data correctly, it ought to improve the interface.
Best wishes,
Roger
maybe a silly question, but is a 3rd party format even needed here?
$ ogrinfo --formats | grep -i grass
- GRASS (readonly)
at least in the one direction.
Excellent question. I had also wondered about this. It looks like
there is a new argument in readVECT():
# read in directly with GDAL/OGR -- no intermediate file:
x - readVECT6('xxx', plugin=TRUE)
This is quite fast and depends on the GDAL-GRASS plugin... However,
NULL data in a GRASS table is not imported correctly-- character
fields are imported as '', and numeric fields as 0.
So... Is the error in GDAL itself?
I tried inspecting a vector from GRASS with NULL data in some of the
columns from the table, using ogrinfo -al
location/mapset/vector/xxx/head
OGRFeature(1):23
cat (Integer) = 24
cat_ (Integer) = 24
str1 (String) = (null)
xyz (Real) = (null)
abc (Integer) = (null)
POINT (591583 4925280 0)
... which seems to correctly report the NULL values.
This leads me to suspect that something in readOGR() and writeOGR are
at fault in handling of NULL values.
Unfortunately looking at the rgdal source code wasn't very productive
(my fault).
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
Index: main.c
===
--- main.c (revision 33793)
+++ main.c (working copy)
@@
[GRASS-dev] Re: more translation - manual pages
Hi Maxim, (discussion how to translate the manual pages) On Thu, Oct 9, 2008 at 4:53 PM, Maxim Dubinin [EMAIL PROTECTED] wrote: ... We can simply take all the *.htmls and start translating, but I was thinking, that if we know how they are generated automatically, well... what's happening: 1. compiler does its work and generates binary of a module; 2. module is immediately run in a fake session, it prints the header of the man page (try: d.rast --html-description) This is done the language to what the computer was set (so, the .po files are used if present); 3. the description.html file of the module (English) is attached to that; 4. the now complete man page is moved into the right place. Missing: - store translated description.html somewhere - Makefile should pick the right description.html for a non-english language if .po file is present we can tweak the process to save some work for us, like for example make word substitution for repeating phrases or export not in html but in rtf etc. I would suggest to to RFT/whatever format from the resulting manual page. HTML is for many years the best format to deal with module documentation in GRASS as it can be edited with an ASCII editor (less so with RTF). Also svn diff works on HTML but not reasonably on RTF. There are many converters to make an RTF from HTML. Finally looked in the source... so each module has a description file, from which the html is generated during compilation. Do I understand right, that these description files are maintained by the module authors and not stored centrally somewhere? They are stored centrally along with the source code. Maintainers are the module authors in the first place (if still around) or any other developer or power user, or our documentation manager (Eric). ... -- Maxim mailto:[EMAIL PROTECTED] Action item for us: - understand how to support multi-language manual pages. this is a request which is on the plate for years meanwhile... Cannot be so hard! Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-stats] Re: [R-sig-Geo] writing shapefiles / DBF files when input data contains NA
On Thursday 09 October 2008, Roger Bivand wrote:
On Tue, 7 Oct 2008, Dylan Beaudette wrote:
On Tue, Oct 7, 2008 at 6:26 PM, Hamish [EMAIL PROTECTED] wrote:
Dylan:
It looks like the limiting factor in this equation is the
code used in v.out.ogr.
Following Dylan's posting on the GDAL list, and Frank's response, I
suggest the following simple patch to vector/v.out.ogr/main.c (here 6.3):
$ diff -u main.c_old main.c
--- main.c_old 2008-10-09 10:54:19.0 +0200
+++ main.c 2008-10-09 11:30:34.0 +0200
@@ -625,7 +625,9 @@
colsqltype = db_get_column_sqltype(Column);
colctype = db_sqltype_to_Ctype ( colsqltype );
G_debug (2, colctype = %d, colctype );
- switch ( colctype ) {
+/* RSB 081009 emit unset fields */
+if (!db_test_value_isnull(Value)) {
+ switch ( colctype ) {
case DB_C_TYPE_INT:
OGR_F_SetFieldInteger( Ogr_feature, j,
db_get_va lue_int(Value) );
break;
@@ -639,7 +641,8 @@
db_convert_column_value_to_string (Column,
dbst
ring);
OGR_F_SetFieldString( Ogr_feature, j,
db_get_str ing (dbstring) );
break;
- }
+ }
+} /* RSB */
}
}
}
In 6.4 this is after line 717. Essentially it just uses
db_test_value_isnull() not to set values in OGR fields if the DB field
value is NULL, and follows Frank's suggestion.
OK-- I am using GRASS 6.4 SVN. Since this is the current (stable) developer
release it might be good to stick with it. I am using r33792 .
Before making the suggested changes, I have tried exporting some point data
with v.out.ogr:
# known working GRASS file with categories
v.out.ogr -e -c in=a_temp dsn=v.out.ogr_example layer=a_temp type=point
Exporting 25 points/lines...
100%
0 features written
WARNING: 25 features found without category skip
^^^
This looks like a new problem (?)... I know that these points have categories,
why is v.out.ogr ignoring them?
Do these lines have anything to do with this:
v.out.ogr:434
Vect_cat_get(Cats, field, cat);
if (cat 0 !donocat) { /* Do not export not labeled */
nocatskip++;
continue;
}
NO!
There is some kind of logic-related bug:
# does not export any features,
# complaining that they don't have categories
v.out.ogr -c in=xxx dsn=some_folder layer=new_shpfile
# exported expected features
v.out.ogr -c in=xxx dsn=new_shpfile
OK- posted here:
http://trac.osgeo.org/grass/ticket/327
The suggested fix appears to result in the creation of a DBF file (in the case
of shapefile) with properly encoded NULL.
Attached is a patch that applies this change to the develbranch-64 tree.
Should I make a ticket for this patch?
Cheers,
Dylan
This matches code near line 939 in OGRGRASSLayer::SetAttributes()
gdal/ogr/ogr_frmts/grass/ogrgrasslayer.cpp in the vector plugin, which
uses:
if ( !db_test_value_isnull(value) )
I'm sure the patch needs checking, but with changes in the R rgdal package
to support vector null data correctly, it ought to improve the interface.
Best wishes,
Roger
maybe a silly question, but is a 3rd party format even needed here?
$ ogrinfo --formats | grep -i grass
- GRASS (readonly)
at least in the one direction.
Excellent question. I had also wondered about this. It looks like
there is a new argument in readVECT():
# read in directly with GDAL/OGR -- no intermediate file:
x - readVECT6('xxx', plugin=TRUE)
This is quite fast and depends on the GDAL-GRASS plugin... However,
NULL data in a GRASS table is not imported correctly-- character
fields are imported as '', and numeric fields as 0.
So... Is the error in GDAL itself?
I tried inspecting a vector from GRASS with NULL data in some of the
columns from the table, using ogrinfo -al
location/mapset/vector/xxx/head
OGRFeature(1):23
cat (Integer) = 24
cat_ (Integer) = 24
str1 (String) = (null)
xyz (Real) = (null)
abc (Integer) = (null)
POINT (591583 4925280 0)
... which seems to correctly report the NULL values.
This leads me to suspect that something in readOGR() and writeOGR are
at fault in handling of NULL values.
Unfortunately looking at the rgdal source code wasn't very productive
(my fault).
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
Index: main.c
===
--- main.c (revision 33793)
+++ main.c (working copy)
@@
[GRASS-dev] Fwd: [GRASS-user] Re: grass-user Digest, Vol 30, Issue 22
Below is a recent exchange between Markus (Neteler) and me about the new r.watershed.fast. The gist is the question: is it ready to go into the develbranch_6 and trunk (7) svn or does it need more testing. I thought it was already in the main svn, but Markus pointed out that it is still in Addons. Michael Begin forwarded message: From: Markus Neteler [EMAIL PROTECTED] Date: October 9, 2008 1:38:37 PM GMT-07:00 To: Michael Barton [EMAIL PROTECTED] Subject: Re: [GRASS-user] Re: grass-user Digest, Vol 30, Issue 22 Please post it to the list, too. :) On Thu, Oct 9, 2008 at 10:22 PM, Michael Barton [EMAIL PROTECTED] wrote: We're almost at a point of recompiling GRASS on our main modeling box. When we do that, we will certainly test the new r.watershed.fast. However, if others test and want to include this in the svn, it's fine by me to go ahead and replace the old module. Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Oct 9, 2008, at 1:04 PM, Markus Neteler wrote: On Thu, Oct 9, 2008 at 9:39 PM, Michael Barton [EMAIL PROTECTED] wrote: Ah. But I did think that it was tested last summer, that it worked well, and the commentators on the list thought that it should be moved into the main svn. Do you think we need more testing? If so, I'll try to have some done here. I am fine with all - if results are identical to old r.watershed and the paramters/flags are compliant, we can replace it even in 6.4. If not, put into 7. I am out of time to do tests unfortunately. Markus -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] default for r.walk
In the module r.walk, it seems that the default value for lambda should be 0. Is this correct? If so, can it be set as the default so that new users wouldn't constantly need to look it up and put 0 in this field? Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] r.watershed.fast new version
Dylan Beaudette wrote: Fantastic news. This should be integrated back into GRASS given that the output now exactly matches the original. Hi, a thought I've had for a while- should we have some r.compare script to test if two raster maps are the same. Currently I use r.univar and check sum= and others match, which is slightly unsatisfactory, as is r.mapcalc diff=map1-map2 + 'r.univar map=diff'. My idea is cell data equality, not metadata (timestamps etc). a flag could have it output a checksum/md5sum too. Should it base the exit code on the yes/no answer? I guess a v.compare could simply run `diff` on the two folders in $MAPSET/vector/ (with g.findfile adjusting for @otherMapset as needed) thoughts? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #324: Ability to handle subgroups with general commands as all other datatypes
#324: Ability to handle subgroups with general commands as all other datatypes --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: subgroup, general commands Platform: All | Cpu: Unspecified --+- Comment (by nikos): Glynn, thank you for the explanation. Perhaps adding such functions in i.group would make sense (?) example: i.group group=pca -s # -s: list subgroups and not individual maps added in the group I'll try to make my point: I have lots of principal components that came from different band combinations, why should I need to create as much groups as the combinations from which they came from (in order to have an easy overview for later classification tasks for example). I only have one group called pca and in it lots of subgroups depending on the initial band combination used to produce these components. Then I can apply a classification using the same training set upon the different subgroups. It takes less effort to invent names for groups/subgroups and gives me the feel that its easier to review/check the data (=groups/subgroups). This is how I thought/think that subgroups are meaningful. Would you recomment another best practice of GRASS groups/subgroups handling? -- Ticket URL: http://trac.osgeo.org/grass/ticket/324#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] [GRASS GIS] #328: Add -e switch (=extend location extents based on reprojected map) in r.proj
#328: Add -e switch (=extend location extents based on reprojected map) in r.proj -+-- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.4.0 Component: default | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- Well, the title speaks itself :-) Would it hurt to have this when reprojecting for example simple study area boundaries or similar? What speaks against it? Also, I read in the manual of r.proj (section NOTES) To avoid excessive time consumption when reprojecting a map the region and resolution of the target location should be set appropriately beforehand. but it's not clear to me why this can't be accomplished automatically. -- Ticket URL: http://trac.osgeo.org/grass/ticket/328 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] #123: r.in.xyz: import bug when using scanned extent
#123: r.in.xyz: import bug when using scanned extent --+- Reporter: neteler | Owner: hamish Type: defect | Status: assigned Priority: major| Milestone: 6.4.0 Component: default | Version: svn-trunk Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Changes (by hamish): * platform: = Unspecified * cpu: = Unspecified Comment: I'll have a look at r.in.xyz to see if we can change the to = ''if we are on the last pass block'' without harming module speed much. If we do it for all passes there will be duplicated cells for points which fall exactly on pass block borders. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/123#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] #328: Add -e switch (=extend location extents based on reprojected map) in r.proj
#328: Add -e switch (=extend location extents based on reprojected map) in r.proj --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by hamish): Replying to [ticket:328 nikos]: Well, the title speaks itself :-) Would it hurt to have this when reprojecting for example simple study area boundaries or similar? What speaks against it? It violates the axiom of do one thing well. The purpose of the module is to reproject maps, not to mess with the region. g.region should always be used for that. It is the GUI's job to tie those tasks together for the user in a nice wizard or menu order, not the individual number crunching modules' job to do all-in-one tasks. see also trac wishes #37 and #123 (re. r.in.xyz) similar arguments there. Also, I read in the manual of r.proj (section NOTES) To avoid excessive time consumption when reprojecting a map the region and resolution of the target location should be set appropriately beforehand. but it's not clear to me why this can't be accomplished automatically. because the user's intentions are unknowable to the program. Another way of saying the above is that r.proj observes the current region settings. e.g. if reprojecting from lat/lon WGS84 to UTM, how big should the resolution size be? ? My usual method around this is in the source location to do g.region rast=map v.in.region out=map_box then in the target location v.proj map_box loc=source g.region vect=map_box d.vect map_box # (observe amount of rotation) g.region res=... -a g.region -p # repeat until rows x cols are slightly bigger than source, # resolution is a nice round number, AND!! taking into # account more rows+cols needed as the map is more rotated #finally: r.proj map loc=source the code in i.rectify tries, but doesn't take into account rotation, so resolution is lost with rotated maps. see old RC bug #3926 http://intevation.de/rt/webrt?serial_num=3296 also http://intevation.de/rt/webrt?serial_num=3052 http://intevation.de/rt/webrt?serial_num=3166 (we Badly need to back up the two old bug trackers!) Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/328#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] #328: Add -e switch (=extend location extents based on reprojected map) in r.proj
#328: Add -e switch (=extend location extents based on reprojected map) in r.proj --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by hamish): Replying to [comment:1 hamish]: I meant what I said in the last post, but that may have come out a bit harsher than I intended. The resolution setting is really critical for r.in.xyz; for r.proj the user will have something to compare it to, so more of an idea that the output looks like crap vs original and that something has been set incorrectly. Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/328#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] [GRASS GIS] #329: Typo in i.oif.html and wording
#329: Typo in i.oif.html and wording -+-- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.4.0 Component: Docs | Version: unspecified Keywords: |Platform: Unspecified Cpu: Unspecified | -+-- A Typo in the Notes section: Colour Composits -- Colour Composites I suggest to introduce in the manual the term False Colour Composites. Maybe it helps beginners/students to understand easier the RGB vs. various band combinations (123, 742, etc.) concept. -- Ticket URL: http://trac.osgeo.org/grass/ticket/329 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] compilation success
William Kyngesburye wrote: To be honest, I'm not particularly confident of the OSX-specific rule for building the module: ifeq ($(findstring darwin,$(ARCH)),darwin) $(CXX) -o $@ $(LDFLAGS) $^ $(EXTRA_LIBS) else I would expect that command to try to build an executable. This works because there is also a conditional on setting EXTRA_LIBS, Where? -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: more translation - manual pages
Markus Neteler wrote: Action item for us: - understand how to support multi-language manual pages. this is a request which is on the plate for years meanwhile... Cannot be so hard! Making them in the first place isn't hard. Ensuring that the translations get updated whenever the original is updated may be harder to achieve. In terms of technical changes, the main problem is that you can't have multiple wildcards (%) in a pattern rule, and the wildcard is already being used for the module name, so we would need to repeat the HTML-related Makefile rules for each locale. This could be done using $(foreach ... $(eval $(call ...))), but that can be quite hard to read (see include/Make/Multi.make or locale/Makefile for examples). It can be simplified if you only want to generate a single language from each run (although package maintainers won't be very happy with this), by just adding $(LANG) to the rules, e.g.: -$(HTMLDIR)/%.html: %.html %.tmp.html $(HTMLSRC) +$(HTMLDIR)/$(LANG)/%.html: %.$(LANG).html %.$(LANG).tmp.html $(HTMLSRC) Even so, you'll probably still need at least two rules, one for the untranslated (i.e. English) version and one for the translated version, unless you're assuming that all translations will be complete (i.e. every file will have a translated version), rather than having only the most important pages translated. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: more translation - manual pages
(discussion how to translate the manual pages) there is also this idea on how to do live online translations: http://grass.osgeo.org/wiki/Updating_GRASS_Documentation#Translations + always current + prototype already functional - tied to internet - tied to 3rd party - automatic translations often creative - inflexible Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #324: Ability to handle subgroups with general commands as all other datatypes
#324: Ability to handle subgroups with general commands as all other datatypes
--+-
Reporter: nikos| Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: major| Milestone: 6.4.0
Component: default | Version: unspecified
Resolution: |Keywords: subgroup, general commands
Platform: All | Cpu: Unspecified
--+-
Comment (by glynn):
Replying to [comment:3 nikos]:
Glynn, thank you for the explanation. Perhaps adding such functions in
i.group would make sense (?)
i.group (or another i.* module) would be the right place for anything
related to groups.
example: i.group group=pca -s # -s: list subgroups and not individual
maps added in the group
That would probably be useful.
I'll try to make my point:
[snip]
This is how I thought/think that subgroups are meaningful. Would you
recomment another best practice of GRASS groups/subgroups handling?
The issue isn't about how to use groups/subgroups, but about where the
code required to do so belongs.
g.{list,copy,rename,remove} don't contain any knowledge about the various
entity types beyond what is contained in etc/element_list (other than a
special case for vectors, and one for the colr2 directory for rasters).
They just read the etc/element_list file to discover which files make up
the element, then list, copy, rename or remove the corresponding files.
Even the set of command-line options is built from the contents of the
element_list file.
If you want similar features for imagery subgroups, it would be better to
have something like:
{{{
i.subgroup [-l] group=... [remove=...] [copy=...] [rename=...]
}}}
The amount of code involved would be less (maybe significantly less) than
if the same features were added to the g.* commands, as you wouldn't need
code to override the generic behaviour of the g.* commands (e.g. when
g.remove sees group=..., it will delete those groups, so you would have
to explicitly prevent that).
--
Ticket URL: http://trac.osgeo.org/grass/ticket/324#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] Re: [GRASS GIS] #328: Add -e switch (=extend location extents based on reprojected map) in r.proj
#328: Add -e switch (=extend location extents based on reprojected map) in r.proj --+- Reporter: nikos| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.4.0 Component: default | Version: unspecified Resolution: |Keywords: Platform: Unspecified | Cpu: Unspecified --+- Comment (by glynn): Replying to [comment:1 hamish]: Well, the title speaks itself :-) Would it hurt to have this when reprojecting for example simple study area boundaries or similar? What speaks against it? It violates the axiom of do one thing well. The purpose of the module is to reproject maps, not to mess with the region. g.region should always be used for that. FWIW, I took the request as meaning setting the map's bounds (not the current region) to contain the entire projected map. This isn't something that can readily be done with g.region, as r.proj is the only place where the relevant information is available (from the bordwalk() calculation). Currently, r.proj reverse-projects the current region borders into the source projection, and only reads the needed portion of the source map into memory (for 6.4 r.proj) or into the temporary file (for 6.4 r.proj.seg and 7.0 r.proj). It then forward-projects that region into the target projection, and sets the map's bounds accordingly (so the map's bounds may be smaller than the current region). It wouldn't be that hard to skip the first step and perform the second, so that the (internal) region, and thus the output map's bounds, was expanded to cover the projected boundary of the source map. You would still need to use g.region rast=outmap to see all of the new map. -- Ticket URL: http://trac.osgeo.org/grass/ticket/328#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
