From glynn at gclements.plus.com  Sun Oct  1 04:56:59 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Oct  1 04:57:15 2006
Subject: [GRASS-dev] Need to update g.setproj
In-Reply-To: <C142AFC1.251D9%michael.barton@asu.edu>
References: <17693.22970.168317.560641@cerise.gclements.plus.com>
	<C142AFC1.251D9%michael.barton@asu.edu>
Message-ID: <17695.11899.407457.43545@cerise.gclements.plus.com>


Michael Barton wrote:

> > Is there any real reason why GRASS needs to comprehend the projection
> > parameters, i.e. to have lib/gis/geo_init.c or all of that boilerplate
> > in g.setproj?
> > 
> > IOW, can projection parameters not be treated as opaque key/value
> > pairs which are simply passed straight through to PROJ, with any UI
> > consisting of generic code using an external database[1] of projection
> > parameters?
> > 
> > [1] By which, I mean a text file in an easy-to-parse format.
> > 
> > It seems to me that all of that boilerplate could be replaced by a
> > list of projections (+proj= name, description), a database of
> > parameters (+<opt>= name, description, bool/int/float), and a matrix
> > of "projection X accepts/requires parameter Y with default value Z".
> 
> This seems like it would be a big help in designing a GUI wrapper for these
> functions.

Converting lib/gis/geo_init.c and g.setproj/main.c to text files was
simple enough; those are attached.

AFAICT, it should be straightforward to replace the boilerplate in
g.setproj with code which uses the tables.

In the process, I noticed this in g.setproj/main.c:

	case LAT3:
		sprintf(tmp_buff, "%.10f", LLSTUFF[i]);
		G_set_key_value("lat_2", tmp_buff, out_proj_keys);
		                 ^^^^^

-- 
Glynn Clements <glynn@gclements.plus.com>

-------------- next part --------------
ALPHA:alpha:Azimuth angle at Cartesian Origin
AZIM:azi:Azimuth Angle of Tilt in Decimal degrees
HEIGH:h:Height of Viewing Point in Meters
KFACT:k_0:Scale Factor at the Central Meridian
LAT0:lat_0:Central Parallel
LAT1:lat_1:First Standard Parallel
LAT2:lat_2:Second Standard Parallel
LAT3:lat_3:Third Standard Parallel
LATB:lat_b:Angular Distance from Tangency Point
LATTS:lat_ts:Latitude of True Scale
LON0:lon_0:Central Meridian
LON1:lon_1:First Standard Meridian
LON2:lon_2:Second Standard Meridian
LON3:lon_3:Third Standard Meridian
LONC:lon_c:Longitude of Cartesian Origin
LOTSA:lotsa:LOTSA
MFACT:m:m factor
MSFACT:M:M factor
NFACT:n:n factor
NOCUT:no_cut:Both Hemispheres
NOROT:no_rot:Suppress Rotation
NOSKEW:ns:Suppress Skew
NOUOFF:no_uoff:Suppress Offset from Pre-Rotated Axis
OLATP:o_lat_p:Latitude of New Pole
OLONP:o_lon_p:Longitude of New Pole
QFACT:q:q factor
ROTCONV:rot_conv:Origin Convergence Angle
SNUM:lsat:Satellite Number
SOUTH:south:South Hemisphere
SPATH:path:Satellite Path Number
THETA:theta:Theta Angle
TILT:tilt:Tilt Angle in Decimal Degrees
WFACT:W:W factor
X0:x_0:False Easting
Y0:y_0:False Northing
ZONE:zone:Projection Zone
-------------- next part --------------
AEA:lat_0=ask,23.0;lat_1=ask,29.5;lat_2=ask,45.5;lon_0=ask,-96.0;x_0=ask,0.0;y_0=ask,0.0
AEQD:lat_0=ask,0.0;lon_0=ask,20.0
AIRY:lat_0=ask,0.0;lat_b=ask,90.0;lon_0=ask,20.0;no_cut=ask,nodfl
AITOFF:lat_0=ask,0.0;lon_0=ask,20.0
ALSK:lat_0=noask,64.0;lon_0=noask,-152.0
APIAN:lat_0=ask,0.0;lon_0=ask,20.0
AUGUST:lat_0=ask,0.0;lon_0=ask,20.0
BACON:lat_0=ask,0.0;lon_0=ask,20.0
BIPC:lat_0=ask,0.0;lon_0=ask,-90.0;ns=ask,nodfl
BOGGS:lat_0=ask,0.0;lon_0=ask,20.0
BONNE:lat_1=ask,40.0;lon_0=ask,20.0
CASS:lat_0=ask,0.0;lon_0=ask,20.0
CC:lat_0=ask,0.0;lon_0=ask,20.0
CEA:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
CHAMB:lat_0=ask,55.0;lat_1=ask,40.0;lat_2=ask,20.0;lat_3=ask,35.0;lon_0=ask,20.0;lon_1=ask,5.0;lon_2=ask,55.0;lon_3=ask,65.0
COLLG:lat_0=ask,0.0;lon_0=ask,20.0
CRAST:lat_0=ask,0.0;lon_0=ask,20.0
DENOY:lat_0=ask,0.0;lon_0=ask,20.0
ECK1:lat_0=ask,0.0;lon_0=ask,20.0
ECK2:lat_0=ask,0.0;lon_0=ask,20.0
ECK3:lat_0=ask,0.0;lon_0=ask,20.0
ECK4:lat_0=ask,0.0;lon_0=ask,20.0
ECK5:lat_0=ask,0.0;lon_0=ask,20.0
ECK6:lat_0=ask,0.0;lon_0=ask,20.0
EQC:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,0.0
EQDC:lat_0=ask,40.0;lat_1=ask,20.0;lat_2=ask,60.0;lon_0=ask,20.0
EULER:lat_0=ask,55.0;lat_1=ask,45.0;lat_2=ask,65.0;lon_0=ask,20.0
FAHEY:lat_0=ask,0.0;lon_0=ask,20.0
FOUC:lat_0=ask,0.0;lon_0=ask,20.0
FOUC_S:lat_0=ask,0.0;lon_0=ask,20.0
GALL:lat_0=ask,0.0;lon_0=ask,20.0
GINS8:lat_0=ask,0.0;lon_0=ask,20.0
GNOM:lat_0=ask,0.0;lon_0=ask,20.0
GN_SINU:lat_0=ask,0.0;lon_0=ask,20.0;m=ask,1.0;n=ask,1.0
GOODE:lat_0=ask,0.0;lon_0=ask,20.0
GS48:lat_0=noask,45.0;lon_0=noask,-120.0
GS50:lat_0=noask,45.0;lon_0=noask,-120.0
HAMMER:M=ask,1.0;W=ask,0.5;lat_0=ask,0.0;lon_0=ask,20.0
HATANO:lat_0=ask,0.0;lon_0=ask,20.0
IMW_P:lat_0=ask,0.0;lat_1=ask,20.0;lat_2=ask,60.0;lon_0=ask,20.0;lon_1=ask,20.0
KAV5:lat_0=ask,0.0;lon_0=ask,20.0
KAV7:lat_0=ask,0.0;lon_0=ask,20.0
LABRD:azi=noask,18.9;k_0=noask,0.9995;lat_0=noask,18.9;lon_0=noask,46.437208333;x_0=noask,400000.0;y_0=noask,800000.0
LAEA:lat_0=ask,55.0;lon_0=ask,20.0;x_0=ask,0.0;y_0=ask,0.0
LAGRNG:W=ask,2.0;lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0
LARR:lat_0=ask,0.0;lon_0=ask,20.0
LASK:lat_0=ask,0.0;lon_0=ask,20.0
LCC:lat_0=ask,23.0;lat_1=ask,33.0;lat_2=ask,45.0;lon_0=ask,-96.0;x_0=ask,0.0;y_0=ask,0.0
LEAC:lat_0=ask,55.0;lat_1=ask,0.0;lon_0=ask,20.0;south=ask,nodfl
LEE_OS:lat_0=noask,-10.0;lon_0=noask,-165.0
LOXIM:lat_0=ask,0.0;lat_1=ask,45.0;lon_0=ask,20.0
LSAT:lat_0=ask,0.0;lon_0=ask,20.0;lsat=ask,1;path=ask,1
MBTFPP:lat_0=ask,0.0;lon_0=ask,20.0
MBTFPQ:lat_0=ask,0.0;lon_0=ask,20.0
MBTFPS:lat_0=ask,0.0;lon_0=ask,20.0
MBT_FPS:lat_0=ask,0.0;lon_0=ask,20.0
MBT_S:lat_0=ask,0.0;lon_0=ask,20.0
MERC:k_0=ask,1.0;lat_ts=ask,0.;lon_0=ask,-96.0
MILL:lat_0=ask,0.0;lon_0=ask,20.0
MIL_OS:lat_0=noask,18.0;lon_0=noask,20.0
MOLL:lat_0=ask,0.0;lon_0=ask,20.0
MPOLY:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0;lotsa=ask,nodfl
MURD1:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
MURD2:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
MURD3:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
NELL:lat_0=ask,0.0;lon_0=ask,20.0
NELL_H:lat_0=ask,0.0;lon_0=ask,20.0
NICOL:lat_0=ask,0.0;lon_0=ask,20.0
NSPER:h=ask,50000000.0;lat_0=ask,55.0;lon_0=ask,20.0
NZMG:lat_0=noask,-41.0;lon_0=noask,173.0;x_0=noask,2510000.0;y_0=noask,6023150.0
OB_TRAN:lat_0=ask,0.0;lon_0=ask,0.0;o_lat_p=ask,90.0;o_lon_p=ask,0.0
OCEA:lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;lon_1=ask,-20.0;lon_2=ask,60.0
OEA:lat_0=ask,0.0;lon_0=ask,20.0;m=ask,1.0;n=ask,1.0;theta=ask,0.0
OMERC:k_0=ask,1.0;lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;lon_1=ask,-40.0;lon_2=ask,40.0;no_rot=ask,nodfl;no_uoff=ask,nodfl;rot_conv=ask,nodfl
ORTEL:lat_0=ask,0.0;lon_0=ask,20.0
ORTHO:lat_0=ask,0.0;lon_0=ask,20.0
PCONIC:lat_0=ask,0.0;lat_1=ask,33.0;lat_2=ask,45.0;lon_0=ask,20.0
POLY:lat_0=ask,0.0;lon_0=ask,-90.0
PUTP1:lat_0=ask,0.0;lon_0=ask,20.0
PUTP2:lat_0=ask,0.0;lon_0=ask,20.0
PUTP3:lat_0=ask,0.0;lon_0=ask,20.0
PUTP3P:lat_0=ask,0.0;lon_0=ask,20.0
PUTP4P:lat_0=ask,0.0;lon_0=ask,20.0
PUTP5:lat_0=ask,0.0;lon_0=ask,20.0
PUTP5P:lat_0=ask,0.0;lon_0=ask,20.0
PUTP6:lat_0=ask,0.0;lon_0=ask,20.0
PUTP6P:lat_0=ask,0.0;lon_0=ask,20.0
QUA_AUT:lat_0=ask,0.0;lon_0=ask,20.0
ROBIN:lat_0=ask,0.0;lon_0=ask,20.0
RPOLY:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
SINU:lat_0=ask,0.0;lon_0=ask,20.0
SOMERC:k_0=noask,1.0;lat_0=noask,46.952405556;lon_0=noask,7.4395833333;x_0=noask,600000.0;y_0=noask,200000.0
STERE:k_0=ask,1.0;lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
TCC:lat_0=ask,0.0;lon_0=ask,20.0
TCEA:k_0=ask,1.0;lat_0=ask,0.0;lon_0=ask,20.0
TISSOT:lat_0=ask,0.0;lat_1=ask,-30.0;lat_2=ask,45.0;lon_0=ask,20.0
TMERC:k_0=ask,1.0;lat_0=ask,23.0;lon_0=ask,-96.0;x_0=ask,0.0;y_0=ask,0.0
TPEQD:lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;lon_1=ask,-20.0;lon_2=ask,60.0
TPERS:azi=ask,0.0;h=ask,10000.0;lat_0=ask,0.0;lon_0=ask,20.0;tilt=ask,0.0
UPS:south=ask,nodfl
URM5:alpha=ask,0.0;lat_0=ask,0.0;lon_0=ask,20.0;n=ask,1.0;q=ask,1.0
URMFPS:lat_0=ask,0.0;lon_0=ask,20.0;n=ask,1.0
UTM:south=ask,nodfl;zone=ask,nodfl
VANDG:lat_0=ask,0.0;lon_0=ask,20.0
VANDG2:lat_0=ask,0.0;lon_0=ask,20.0
VANDG3:lat_0=ask,0.0;lon_0=ask,20.0
VANDG4:lat_0=ask,0.0;lon_0=ask,20.0
WAG1:lat_0=ask,0.0;lon_0=ask,20.0
WAG2:lat_0=ask,0.0;lon_0=ask,20.0
WAG3:lat_0=ask,0.0;lon_0=ask,20.0
WAG4:lat_0=ask,0.0;lon_0=ask,20.0
WAG5:lat_0=ask,0.0;lon_0=ask,20.0
WAG6:lat_0=ask,0.0;lon_0=ask,20.0
WAG7:lat_0=ask,0.0;lon_0=ask,20.0
WEREN:lat_0=ask,0.0;lon_0=ask,20.0
WINK1:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
WINK2:lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0
WINTRI:lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0
From hamish_nospam at yahoo.com  Sun Oct  1 06:47:32 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 06:47:46 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <17693.23749.809989.644246@cerise.gclements.plus.com>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>
	<451BCED1.4050509@itc.it>
	<200609282336.08350.jan-oliver.wagner@intevation.de>
	<200609291223.52840.bernhard@intevation.de>
	<17693.23749.809989.644246@cerise.gclements.plus.com>
Message-ID: <20061001174732.67be5a72.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> Bernhard Reiter wrote:
> > > > > Anybody knows if 
> > > > > Trac has such thing?
> > > >
> > > > I think that this is the key - being able to delete individual
> > > > posts to a bug
> > > > report. Given that, we could keep it open as before.
> > 
> > I do not think this is feasabl; humans cannot beat robots that fill
> > out  webforms.
> 
> Can we add a captcha to the form? This would only be required for
> guest users.


An easy implementation I've seen was a simple auto-generated web page
that asked a randomly generated simple math question in english. e.g.
"What's [nine] [minus] [four]?" _________ [Submit]

We're not Hotmail or Yahoo! Mail, so I doubt we have to bother with
"spot the word in the noise" tricks. Beating a custom app from
relatively small projects like ours just isn't worth the spammer's
time (by definition they're trying to take the lazy route to success).


Hamish

From hamish_nospam at yahoo.com  Sun Oct  1 07:09:13 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 07:09:23 2006
Subject: [GRASS-dev] r.le--after some fixes still needs work
In-Reply-To: <17693.21614.198859.287501@cerise.gclements.plus.com>
References: <1159384723.3333.8.camel@bakercomp.uwyo.edu>
	<20060928201747.1cc5abf4.hamish_nospam@yahoo.com>
	<17692.707.263248.73639@cerise.gclements.plus.com>
	<1159480588.4744.13.camel@bakercomp.uwyo.edu>
	<20060929135736.5510f2e1.hamish_nospam@yahoo.com>
	<17693.21614.198859.287501@cerise.gclements.plus.com>
Message-ID: <20061001180913.0d9c13bf.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> BTW, r.le.setup shouldn't be calling R_*/D_*/D* functions. Modules
> which use the display are supposed to be called d.<something> (e.g. 
> d.le.setup), not r.<something>.

As a rule, probably not, but it does have 5+ years history using that
name and GRASS 6.0 was released with it being called that..

others modules that fall afoul: r.digit, v.digit, i.points, ...


Hamish

From hamish_nospam at yahoo.com  Sun Oct  1 07:23:04 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 07:24:10 2006
Subject: [GRASS-dev] Need to update g.setproj
In-Reply-To: <17693.22970.168317.560641@cerise.gclements.plus.com>
References: <C140A257.F205%michael.barton@asu.edu>
	<451B7F65.4030707@stjohnspoint.co.uk>
	<17691.60341.395076.267565@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0609281718060.2035@agrippa.ukshells.co.uk>
	<17693.22970.168317.560641@cerise.gclements.plus.com>
Message-ID: <20061001182304.3b72fcb9.hamish_nospam@yahoo.com>

> > Are you suggesting this prompting be the responsibility of the GUI
> > before  it runs the module? Would it not then need to be cloned for
> > every  different GUI? And make prior knowledge of all the parameters
> > for the  datum etc. a pre-requisite for using the module from the
> > command-line?

Glynn:
> I'm proposing that GRASS should be scriptable using something other
> than "expect", for the case where a user simply isn't available, e.g. 
> CGI scripts or cron jobs.
>
> IOW, I'm arguing about the fundamental concept of "interacting" with a
> user, not with the mechanism.
> 
> In that situation, we need something that accepts all necessary
> parameters from the command line (and/or files, environment variables
> etc), and either succeeds or fails.


what if g.setproj could take a text file as input. This text file would
be identical in format to PROJ_INFO and all the module would do would be
to test that all values are legal and that nothing manditory (e.g.
proj:) was missing, then populate the dir structure. UNITS and
DEFAULT_WIND could default to meters/degrees and [0,1][0,1][1].
(sort of like new region from r.in.gdal WKT or EPSG code works now?)

Slighly more intelligent than just "mkdir PERMANENT && cp input.tmp
PERMANENT/PROJ_INFO", but nothing too fancy.

Then it's up to the GUI wizard to create pull-down menus for available
options... this of course would need proj.4 or GRASS to provide such
info for parsing (like "gdalinfo --formats"); but to me this is the
primary approach that could make Michael, Glynn, Paul, Frank, etc all
happy, so could be worth the trouble to add to proj4?


Hamish

From Michael.Barton at asu.edu  Sun Oct  1 07:46:22 2006
From: Michael.Barton at asu.edu (Michael Barton)
Date: Sun Oct  1 07:47:51 2006
Subject: [GRASS-dev] Need to update g.setproj
In-Reply-To: <17695.11899.407457.43545@cerise.gclements.plus.com>
Message-ID: <C144A43E.F3F8%michael.barton@asu.edu>

Either this or Hamish's suggestion would work from my vantage--whichever is
easier to do with the g.setproj code.

There would need to be some tables with user-readable names from which to
parse correct values. But, as you show below, that should be quite doable.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Glynn Clements <glynn@gclements.plus.com>
> Date: Sun, 1 Oct 2006 03:56:59 +0100
> To: Michael Barton <michael.barton@asu.edu>
> Cc: Paul Kelly <paul-grass@stjohnspoint.co.uk>, GRASS-DEV
> <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] Need to update g.setproj
> 
> 
> Michael Barton wrote:
> 
>>> Is there any real reason why GRASS needs to comprehend the projection
>>> parameters, i.e. to have lib/gis/geo_init.c or all of that boilerplate
>>> in g.setproj?
>>> 
>>> IOW, can projection parameters not be treated as opaque key/value
>>> pairs which are simply passed straight through to PROJ, with any UI
>>> consisting of generic code using an external database[1] of projection
>>> parameters?
>>> 
>>> [1] By which, I mean a text file in an easy-to-parse format.
>>> 
>>> It seems to me that all of that boilerplate could be replaced by a
>>> list of projections (+proj= name, description), a database of
>>> parameters (+<opt>= name, description, bool/int/float), and a matrix
>>> of "projection X accepts/requires parameter Y with default value Z".
>> 
>> This seems like it would be a big help in designing a GUI wrapper for these
>> functions.
> 
> Converting lib/gis/geo_init.c and g.setproj/main.c to text files was
> simple enough; those are attached.
> 
> AFAICT, it should be straightforward to replace the boilerplate in
> g.setproj with code which uses the tables.
> 
> In the process, I noticed this in g.setproj/main.c:
> 
> case LAT3:
> sprintf(tmp_buff, "%.10f", LLSTUFF[i]);
> G_set_key_value("lat_2", tmp_buff, out_proj_keys);
>                 ^^^^^
> 
> -- 
> Glynn Clements <glynn@gclements.plus.com>
> 
> ALPHA:alpha:Azimuth angle at Cartesian Origin
> AZIM:azi:Azimuth Angle of Tilt in Decimal degrees
> HEIGH:h:Height of Viewing Point in Meters
> KFACT:k_0:Scale Factor at the Central Meridian
> LAT0:lat_0:Central Parallel
> LAT1:lat_1:First Standard Parallel
> LAT2:lat_2:Second Standard Parallel
> LAT3:lat_3:Third Standard Parallel
> LATB:lat_b:Angular Distance from Tangency Point
> LATTS:lat_ts:Latitude of True Scale
> LON0:lon_0:Central Meridian
> LON1:lon_1:First Standard Meridian
> LON2:lon_2:Second Standard Meridian
> LON3:lon_3:Third Standard Meridian
> LONC:lon_c:Longitude of Cartesian Origin
> LOTSA:lotsa:LOTSA
> MFACT:m:m factor
> MSFACT:M:M factor
> NFACT:n:n factor
> NOCUT:no_cut:Both Hemispheres
> NOROT:no_rot:Suppress Rotation
> NOSKEW:ns:Suppress Skew
> NOUOFF:no_uoff:Suppress Offset from Pre-Rotated Axis
> OLATP:o_lat_p:Latitude of New Pole
> OLONP:o_lon_p:Longitude of New Pole
> QFACT:q:q factor
> ROTCONV:rot_conv:Origin Convergence Angle
> SNUM:lsat:Satellite Number
> SOUTH:south:South Hemisphere
> SPATH:path:Satellite Path Number
> THETA:theta:Theta Angle
> TILT:tilt:Tilt Angle in Decimal Degrees
> WFACT:W:W factor
> X0:x_0:False Easting
> Y0:y_0:False Northing
> ZONE:zone:Projection Zone
> AEA:lat_0=ask,23.0;lat_1=ask,29.5;lat_2=ask,45.5;lon_0=ask,-96.0;x_0=ask,0.0;y
> _0=ask,0.0
> AEQD:lat_0=ask,0.0;lon_0=ask,20.0
> AIRY:lat_0=ask,0.0;lat_b=ask,90.0;lon_0=ask,20.0;no_cut=ask,nodfl
> AITOFF:lat_0=ask,0.0;lon_0=ask,20.0
> ALSK:lat_0=noask,64.0;lon_0=noask,-152.0
> APIAN:lat_0=ask,0.0;lon_0=ask,20.0
> AUGUST:lat_0=ask,0.0;lon_0=ask,20.0
> BACON:lat_0=ask,0.0;lon_0=ask,20.0
> BIPC:lat_0=ask,0.0;lon_0=ask,-90.0;ns=ask,nodfl
> BOGGS:lat_0=ask,0.0;lon_0=ask,20.0
> BONNE:lat_1=ask,40.0;lon_0=ask,20.0
> CASS:lat_0=ask,0.0;lon_0=ask,20.0
> CC:lat_0=ask,0.0;lon_0=ask,20.0
> CEA:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
> CHAMB:lat_0=ask,55.0;lat_1=ask,40.0;lat_2=ask,20.0;lat_3=ask,35.0;lon_0=ask,20
> .0;lon_1=ask,5.0;lon_2=ask,55.0;lon_3=ask,65.0
> COLLG:lat_0=ask,0.0;lon_0=ask,20.0
> CRAST:lat_0=ask,0.0;lon_0=ask,20.0
> DENOY:lat_0=ask,0.0;lon_0=ask,20.0
> ECK1:lat_0=ask,0.0;lon_0=ask,20.0
> ECK2:lat_0=ask,0.0;lon_0=ask,20.0
> ECK3:lat_0=ask,0.0;lon_0=ask,20.0
> ECK4:lat_0=ask,0.0;lon_0=ask,20.0
> ECK5:lat_0=ask,0.0;lon_0=ask,20.0
> ECK6:lat_0=ask,0.0;lon_0=ask,20.0
> EQC:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,0.0
> EQDC:lat_0=ask,40.0;lat_1=ask,20.0;lat_2=ask,60.0;lon_0=ask,20.0
> EULER:lat_0=ask,55.0;lat_1=ask,45.0;lat_2=ask,65.0;lon_0=ask,20.0
> FAHEY:lat_0=ask,0.0;lon_0=ask,20.0
> FOUC:lat_0=ask,0.0;lon_0=ask,20.0
> FOUC_S:lat_0=ask,0.0;lon_0=ask,20.0
> GALL:lat_0=ask,0.0;lon_0=ask,20.0
> GINS8:lat_0=ask,0.0;lon_0=ask,20.0
> GNOM:lat_0=ask,0.0;lon_0=ask,20.0
> GN_SINU:lat_0=ask,0.0;lon_0=ask,20.0;m=ask,1.0;n=ask,1.0
> GOODE:lat_0=ask,0.0;lon_0=ask,20.0
> GS48:lat_0=noask,45.0;lon_0=noask,-120.0
> GS50:lat_0=noask,45.0;lon_0=noask,-120.0
> HAMMER:M=ask,1.0;W=ask,0.5;lat_0=ask,0.0;lon_0=ask,20.0
> HATANO:lat_0=ask,0.0;lon_0=ask,20.0
> 
IMW_P:lat_0=ask,0.0;lat_1=ask,20.0;lat_2=ask,60.0;lon_0=ask,20.0;lon_1=ask,20.>
0
> KAV5:lat_0=ask,0.0;lon_0=ask,20.0
> KAV7:lat_0=ask,0.0;lon_0=ask,20.0
> LABRD:azi=noask,18.9;k_0=noask,0.9995;lat_0=noask,18.9;lon_0=noask,46.43720833
> 3;x_0=noask,400000.0;y_0=noask,800000.0
> LAEA:lat_0=ask,55.0;lon_0=ask,20.0;x_0=ask,0.0;y_0=ask,0.0
> LAGRNG:W=ask,2.0;lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0
> LARR:lat_0=ask,0.0;lon_0=ask,20.0
> LASK:lat_0=ask,0.0;lon_0=ask,20.0
> LCC:lat_0=ask,23.0;lat_1=ask,33.0;lat_2=ask,45.0;lon_0=ask,-96.0;x_0=ask,0.0;y
> _0=ask,0.0
> LEAC:lat_0=ask,55.0;lat_1=ask,0.0;lon_0=ask,20.0;south=ask,nodfl
> LEE_OS:lat_0=noask,-10.0;lon_0=noask,-165.0
> LOXIM:lat_0=ask,0.0;lat_1=ask,45.0;lon_0=ask,20.0
> LSAT:lat_0=ask,0.0;lon_0=ask,20.0;lsat=ask,1;path=ask,1
> MBTFPP:lat_0=ask,0.0;lon_0=ask,20.0
> MBTFPQ:lat_0=ask,0.0;lon_0=ask,20.0
> MBTFPS:lat_0=ask,0.0;lon_0=ask,20.0
> MBT_FPS:lat_0=ask,0.0;lon_0=ask,20.0
> MBT_S:lat_0=ask,0.0;lon_0=ask,20.0
> MERC:k_0=ask,1.0;lat_ts=ask,0.;lon_0=ask,-96.0
> MILL:lat_0=ask,0.0;lon_0=ask,20.0
> MIL_OS:lat_0=noask,18.0;lon_0=noask,20.0
> MOLL:lat_0=ask,0.0;lon_0=ask,20.0
> MPOLY:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0;lotsa=ask,no
> dfl
> MURD1:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
> MURD2:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
> MURD3:lat_0=ask,0.0;lat_1=ask,-20.0;lat_2=ask,20.0;lon_0=ask,20.0
> NELL:lat_0=ask,0.0;lon_0=ask,20.0
> NELL_H:lat_0=ask,0.0;lon_0=ask,20.0
> NICOL:lat_0=ask,0.0;lon_0=ask,20.0
> NSPER:h=ask,50000000.0;lat_0=ask,55.0;lon_0=ask,20.0
> NZMG:lat_0=noask,-41.0;lon_0=noask,173.0;x_0=noask,2510000.0;y_0=noask,6023150
> .0
> OB_TRAN:lat_0=ask,0.0;lon_0=ask,0.0;o_lat_p=ask,90.0;o_lon_p=ask,0.0
> OCEA:lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;lon_1=ask,-20
> .0;lon_2=ask,60.0
> OEA:lat_0=ask,0.0;lon_0=ask,20.0;m=ask,1.0;n=ask,1.0;theta=ask,0.0
> OMERC:k_0=ask,1.0;lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;
> lon_1=ask,-40.0;lon_2=ask,40.0;no_rot=ask,nodfl;no_uoff=ask,nodfl;rot_conv=ask
> ,nodfl
> ORTEL:lat_0=ask,0.0;lon_0=ask,20.0
> ORTHO:lat_0=ask,0.0;lon_0=ask,20.0
> PCONIC:lat_0=ask,0.0;lat_1=ask,33.0;lat_2=ask,45.0;lon_0=ask,20.0
> POLY:lat_0=ask,0.0;lon_0=ask,-90.0
> PUTP1:lat_0=ask,0.0;lon_0=ask,20.0
> PUTP2:lat_0=ask,0.0;lon_0=ask,20.0
> PUTP3:lat_0=ask,0.0;lon_0=ask,20.0
> PUTP3P:lat_0=ask,0.0;lon_0=ask,20.0
> PUTP4P:lat_0=ask,0.0;lon_0=ask,20.0
> PUTP5:lat_0=ask,0.0;lon_0=ask,20.0
> PUTP5P:lat_0=ask,0.0;lon_0=ask,20.0
> PUTP6:lat_0=ask,0.0;lon_0=ask,20.0
> PUTP6P:lat_0=ask,0.0;lon_0=ask,20.0
> QUA_AUT:lat_0=ask,0.0;lon_0=ask,20.0
> ROBIN:lat_0=ask,0.0;lon_0=ask,20.0
> RPOLY:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
> SINU:lat_0=ask,0.0;lon_0=ask,20.0
> SOMERC:k_0=noask,1.0;lat_0=noask,46.952405556;lon_0=noask,7.4395833333;x_0=noa
> sk,600000.0;y_0=noask,200000.0
> STERE:k_0=ask,1.0;lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
> TCC:lat_0=ask,0.0;lon_0=ask,20.0
> TCEA:k_0=ask,1.0;lat_0=ask,0.0;lon_0=ask,20.0
> TISSOT:lat_0=ask,0.0;lat_1=ask,-30.0;lat_2=ask,45.0;lon_0=ask,20.0
> TMERC:k_0=ask,1.0;lat_0=ask,23.0;lon_0=ask,-96.0;x_0=ask,0.0;y_0=ask,0.0
> TPEQD:lat_0=ask,0.0;lat_1=ask,-45.0;lat_2=ask,45.0;lon_0=ask,20.0;lon_1=ask,-2
> 0.0;lon_2=ask,60.0
> TPERS:azi=ask,0.0;h=ask,10000.0;lat_0=ask,0.0;lon_0=ask,20.0;tilt=ask,0.0
> UPS:south=ask,nodfl
> URM5:alpha=ask,0.0;lat_0=ask,0.0;lon_0=ask,20.0;n=ask,1.0;q=ask,1.0
> URMFPS:lat_0=ask,0.0;lon_0=ask,20.0;n=ask,1.0
> UTM:south=ask,nodfl;zone=ask,nodfl
> VANDG:lat_0=ask,0.0;lon_0=ask,20.0
> VANDG2:lat_0=ask,0.0;lon_0=ask,20.0
> VANDG3:lat_0=ask,0.0;lon_0=ask,20.0
> VANDG4:lat_0=ask,0.0;lon_0=ask,20.0
> WAG1:lat_0=ask,0.0;lon_0=ask,20.0
> WAG2:lat_0=ask,0.0;lon_0=ask,20.0
> WAG3:lat_0=ask,0.0;lon_0=ask,20.0
> WAG4:lat_0=ask,0.0;lon_0=ask,20.0
> WAG5:lat_0=ask,0.0;lon_0=ask,20.0
> WAG6:lat_0=ask,0.0;lon_0=ask,20.0
> WAG7:lat_0=ask,0.0;lon_0=ask,20.0
> WEREN:lat_0=ask,0.0;lon_0=ask,20.0
> WINK1:lat_0=ask,0.0;lat_ts=ask,0.0;lon_0=ask,20.0
> WINK2:lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0
> WINTRI:lat_0=ask,0.0;lat_1=ask,0.0;lon_0=ask,20.0


From michael.barton at asu.edu  Sun Oct  1 08:25:18 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  1 08:26:03 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
Message-ID: <C144AD5E.F3FA%michael.barton@asu.edu>

Zooming in with a zoom box is pretty straight forward. But zooming out is
conceptually and computationally somewhat more complex, and is done in
various ways (or not at all) in other graphics/GIS programs.

After working off list on various approaches to zooming out with a zoom box,
I want to give you all several alternative proposals and let you vote on
them. It gives us a chance to try out the voting procedure. I think that
we?d said that we?d have 2 or 3 days. Since it?s the weekend, I?ll take
votes through Tuesday Arizona time (Markus, if this is too short a time,
please let me know and I?ll extend it.). I?ll try to get this in the cvs as
soon as possible after Tuesday.

Vote for options (I?m willing to do either 1a/b or 2a/b, and personally
favor variants 1a or 2a):

1a: 1+
1b: 0+
2a: 1+
2b: 0+
3:  1-

.....................

Here is an explanation of the options:

1a. The current region is fit into the zoom box where the zoom box is drawn:

1b. The current region is fit into the zoom box and centered in the display:

Issues: This is the easiest to explain and the most directly opposite of a
zoom in box (where the box defines the new region extents). The box defines
the amount of zoom in (i.e., new region extents) in both dimensions. The
main drawback is that the resulting region geometry (aspect ratio) is the
inverse of the box geometry. Because the smaller the box, the more the
region is extended (to make the original region appear smaller in the
display). This means that a tall, narrow box will extend the region a lot in
the E-W dimension and less in the N-S dimension, producing a short, wide
region. If we go to this, kind of zoom out, I like 1a because it gives the
user even more control over zooming (kind of zooming and panning in one fell
swoop), though is more complicated. However, if 1b gets more votes, I?ll go
with that instead.

2a. The box directly defines the geometry of the new region and the box?s
longest dimension determines the amount zoomed out (how much the region is
extended to make the current map appear smaller). The new region is centered
in the display. That is, a long, short box will produce a long, short region
that is larger than the original region (making the map appear to be
smaller).

2b. The box directly defines the geometry of the new region and the box?s
shortest dimension determines the amount zoomed out. The new region is
centered in the display.

Issues: Unlike zooming in, the zoom out is controlled only by a single box
dimension, giving the user less control. However, the resulting region
matches the geometry of the zoom box, with might be more what a user has in
mind. To my mine, 2b zooms out too fast, which is why I prefer 2a. For
example, a long, narrow zoom out box will produce a slightly zoomed out,
long, narrow region with 2a, but a very zoomed out, long, narrow region with
2b.

3. The box causes the the display to zoom out, but either does not control
the amount of zoom out (e.g., region is extended by some set amount) or
doesn?t control the region geometry (e.g., the display window controls the
geometry regardless of the shape of the zoom out box).

Issues: I see no point in going to the trouble of coding a zoom box if it
doesn?t give a user control over the region extents (i.e., both the amount
of zoom and the resulting region geometry). We already have a nice quick,
1-click zoom in and zoom out that I?ve cleaned up a bit more over what is
now in the cvs.

...................

In all cases, drawing a zoom out box outside the region extents or a zoom
out box whose geometry is very different from the existing region geometry
may produce visual results that are a little odd, even when the zooming is
following the rules correctly. I can put in some traps for this depending on
the algorithm used. However, in any case, it *will* zoom out, allowing the
user to see more of the map than before and other tools (quick 1-click
zooming or zoom in box) can be used for fine tuning if needed.

So let the voting begin

Enjoy
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



From hamish_nospam at yahoo.com  Sun Oct  1 08:28:58 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 08:29:03 2006
Subject: [GRASS-dev] Re: [bug #4352] (grass) v.to.db: segfault on layer > 1
In-Reply-To: <20060929222827.DB3291005CE@lists.intevation.de>
References: <20060929222827.DB3291005CE@lists.intevation.de>
Message-ID: <20061001192858.4b6c07c5.hamish_nospam@yahoo.com>

>> http://intevation.de/rt/webrt?serial_num=4352

> is that bug fixed for you too?

I have tried just now in 6.3 and 6.1.0, and it worked:
  v.db.addtable swath_area layer=3

I don't know what's different now, I don't see any change in
lib/vector/Vlib/cindex.c since then.

(no patch for this bug from 2 days ago has been applied)
 Re: [GRASS-dev] Re: bug in Vect_cidx_find_next() ?


shrug, maybe just a local glitch. It was reproducable at the time.


Hamish

From hamish_nospam at yahoo.com  Sun Oct  1 08:34:37 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 08:34:42 2006
Subject: [GRASS-dev] [bug #5175] (grass) v.to.db: 'option=cat' not
	updating	columns other than 'cat'
In-Reply-To: <20060929224338.979431005CF@lists.intevation.de>
References: <20060929224338.979431005CF@lists.intevation.de>
Message-ID: <20061001193437.1d7a2488.hamish_nospam@yahoo.com>

Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5175
> ---------------------------------------------------------------------
> 
> Subject: v.to.db: 'option=cat' not updating columns other than 'cat'
> 
> Even if I specify a valid integer output 'column' for 'option=cat':
> 
>     v.to.db -s map=huha2 type=point layer=2 option=cat column=gimme
> 
> v.to.db ignores it and updates the column "cat" instead:
> 
>     Updating database ...
>     insert into huha2_2 ( cat ) values  ( 1 )
>     insert into huha2_2 ( cat ) values  ( 2 )
>     insert into huha2_2 ( cat ) values  ( 3 )
> 
> ... and so forth.
> 
> The column "gimme" is there:
> 
>     $ v.info -c huha2
>     Displaying column types/names for database connection of layer 1:
>     INTEGER|cat
>     INTEGER|gimme
> 
> Why does v.to.db ignore it? I thought I could use any integer column
> for storing categories...

what if 'v.reclass column=gimmie' is done first. i.e. is it hard-coded
to "cat" or is it hard-coded to the category key?


Hamish

From grass-bugs at intevation.de  Sun Oct  1 08:38:30 2006
From: grass-bugs at intevation.de (Harmish Bowman via RT)
Date: Sun Oct  1 08:38:32 2006
Subject: [GRASS-dev] [bug #3323] (grass) r.le.setup does not work properly
Message-ID: <20061001063830.70F651006A6@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=3323

Request number 3323 was commented on by 'hbowman' (Harmish Bowman). 
Responding to this message will send mail to the requestor.
			
			Request Tracker
			rt@intevation.de

--------------------------------------------------------------
Cc: grass-dev@grass.itc.it

Ctrl-C bug fixed in CVS. The sites option was optional graphical overlay, not
mandatory, so I've removed it.

r.le.setup still has some problems, but I guess this bug can be resolved now.


I don't know about the r.fragstats stuff though, so I'll let someone else
comment on that before closing the bug.


Hamish



-------------------------------------------- Managed by Request Tracker

From hamish_nospam at yahoo.com  Sun Oct  1 08:51:19 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 08:51:26 2006
Subject: [GRASS-dev] r.le bugs--list needed
In-Reply-To: <451D1123.9020206@o2.pl>
References: <45184148.1040003@uwyo.edu>
	<20060927184857.1628e245.hamish_nospam@yahoo.com>
	<451D1123.9020206@o2.pl>
Message-ID: <20061001195119.424f083e.hamish_nospam@yahoo.com>

> >> 2. r.le.setup does not display properly in the display window
..
> > fixed in CVS HEAD + 6.2 branch
> >   - it was hanging on G_system(" d.frame -e");
> >     changed to use D_setup(1) to clear the screen
> 
> Does it resolve the 2 issues reported in
> http://intevation.de/rt/webrt?serial_num=3323?

yes, I think. I don't know about r.fragstats comments. see report.


> >> 4. r.le.pixel crashes with a memory problem
..
> For the record - there is bug report for about that:
> http://intevation.de/rt/webrt?serial_num=3084

no, that sounds like a slow memory leak not a malloc mistake.

probably the segmentation suggestion is the solution/cause of #3084.


> >> 5. no r.le.dist program
> 
> Other folks are missing it too:
> http://intevation.de/rt/webrt?serial_num=3040

fyi, this wish was spam-bombed 4 days ago.


> > I notice that the GRASS 5 r.le man pages were not ported into GRASS
> > 6 description.html files. That's easy to do and should be done.
> 
> I'm sorry but I can't offer any help with documenation. No time.

hopefully someone can, it's just cut & paste stuff.


WRT r.li, I think it'll be great to have that done and agree that all
major development effort probably belongs there. But if we can fix a few
bugs in a few hours to make r.le useful again, I don't think that hurts
any. At least we will have put r.le to rest in a comfortable state.


Hamish

From rez at touchofmadness.com  Sun Oct  1 08:52:21 2006
From: rez at touchofmadness.com (Brad Douglas)
Date: Sun Oct  1 08:52:27 2006
Subject: [GRASS-dev] r.le--after some fixes still needs work
In-Reply-To: <20061001180913.0d9c13bf.hamish_nospam@yahoo.com>
References: <1159384723.3333.8.camel@bakercomp.uwyo.edu>
	<20060928201747.1cc5abf4.hamish_nospam@yahoo.com>
	<17692.707.263248.73639@cerise.gclements.plus.com>
	<1159480588.4744.13.camel@bakercomp.uwyo.edu>
	<20060929135736.5510f2e1.hamish_nospam@yahoo.com>
	<17693.21614.198859.287501@cerise.gclements.plus.com>
	<20061001180913.0d9c13bf.hamish_nospam@yahoo.com>
Message-ID: <1159685541.17334.47.camel@devel>

On Sun, 2006-10-01 at 18:09 +1300, Hamish wrote:
> Glynn Clements wrote:
> > BTW, r.le.setup shouldn't be calling R_*/D_*/D* functions. Modules
> > which use the display are supposed to be called d.<something> (e.g. 
> > d.le.setup), not r.<something>.
> 
> As a rule, probably not, but it does have 5+ years history using that
> name and GRASS 6.0 was released with it being called that..
> 
> others modules that fall afoul: r.digit, v.digit, i.points, ...

This is why r.support is being rewritten as well...


-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785

From hamish_nospam at yahoo.com  Sun Oct  1 09:19:56 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 09:21:21 2006
Subject: [GRASS-dev] [bug #5161] v.digit: no toolbox if Grass 6.3 built
	with tcl/tk 8.3
In-Reply-To: <C14280D2.F310%michael.barton@asu.edu>
References: <20060929223359.083fe269.hamish_nospam@yahoo.com>
	<C14280D2.F310%michael.barton@asu.edu>
Message-ID: <20061001201956.205dc830.hamish_nospam@yahoo.com>

Hamish wrote:
> For the sake of 1 lousy function call in v.digit, we should figure out
> a way to keep GRASS compatible with TclTk 8.3. 

[if I knew more tcl I would have just fixed this instead of complaining
to all of you]


Michael Barton wrote:
> Bwidget LabelFrame (note capitalization) might work as a substitute.
> There has to be some kind of bwidget sourcing to make it work. If it's
> just one function call, it would be easy. But from past reports, it's
> not just one call in nviz, but includes other things as well.

For v.digit, it seems to be just that one line. (infact all of GRASS,
AFAIK)

labelframe is not used in NVIZ, and I'm not aware of any TclTk 8.3
problems with NVIZ (I've been away, could have missed something; were
your NVIZ beautification changes 8.3 incompatible and applied in CVS?).
NVIZ starts up of for me when built with 8.3 anyhow.

I think the other 8.3 incompatibilites that cropped up were fixed?


> For me at least, it quite a bit of work to try and track down what has
> changed since 8.4 was released 3.5 years ago and find some workaround
> for each one. I'm not trying to be a pain, I just don't have time to
> do that, fix current bugs, fulfill new wishes, and work on the new
> wxPython interface too. I'm pretty much the only person doing this,
> and so have to draw the line somewhere since I'm already
> overcommitted. And like the rest of the developers, I do have a day
> job too that keeps me pretty busy. Sorry.

Don't be sorry, you give what time you can, we all do. No one expects
you to know everything about all versions of Tcl, GRASS, etc., do all
the tcl programming, and audit all the tcl code. New code is committed
as best as we can write it, and if there's a problem the users let us
know soon enough ;). I didn't mean to be demanding of you, just the
code.

I agree that the sooner we move to wxPython the better. More exciting
development by lots more developers with less headaches. (I can hope)


Maciek:
> I would lean towards Michael's attitude to drop 8.3 support and
> reqquire 8.4. This will make things easier for devs, and will do no
> harm for users.

I don't agree with the last statement, limiting choice always hurts
users. Who said they were using a modern Linux distro or are allowed to
upgrade the software already installed on their outfit's 4 yr old big
iron? Especially when it's a small matter to stay compatible.

> It only has to be made clear and obvious - update the docs and build
> procedure.

If the only thing in 6.2 that is 8.3 incompatible is the new gis.m geo-
rectifier, we can put something in the release notes and those users can
use i.points & friends instead. On the other side, v.digit is a core
module and there is no alternate route available (without going to
external software like qgis).


Glynn:
> Does Tcl/Tk 8.4 work with NVIZ on all platforms yet?

On debian it seems to be better thanks to everyone's fixes.
The best answer I can give is "don't know, but I hope so."



Hamish

From hamish_nospam at yahoo.com  Sun Oct  1 10:21:25 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 10:21:34 2006
Subject: [GRASS-dev] r.le--after some fixes still needs work
In-Reply-To: <451D5C4B.2040403@uwyo.edu>
References: <1159384723.3333.8.camel@bakercomp.uwyo.edu>
	<20060928201747.1cc5abf4.hamish_nospam@yahoo.com>
	<17692.707.263248.73639@cerise.gclements.plus.com>
	<1159480588.4744.13.camel@bakercomp.uwyo.edu>
	<20060929134917.616525ef.hamish_nospam@yahoo.com>
	<451D5C4B.2040403@uwyo.edu>
Message-ID: <20061001212125.44d497d3.hamish_nospam@yahoo.com>

William wrote:
> Hamish, as to r.le.setup, at the CHOOSE THE SETUP OPTION step, I choose
> Setup sampling units, then Use keyboard to enter sampling unit
> dimensions, then 1 for for How many different SCALES, then 1 for Random
> nonoverlapping, then "y" for Do you want to sample using rectangles,
> then "1.0" for Sampling unit SHAPE, then 144 for Recommended maximum
> SIZE followed by "y" it's OK, then 20
> sampling units. At that point, the program should draw the sampling
> units in red on the monitor, but nothing is displayed. Not sure where
> the communication problem is...

[...]

William L. Baker wrote:
> Remaining problem just in r.le.setup. All of r.le.setup seems to work
> except Setup sampling units.
> 
> When setting up sampling units, you are right the problem is likely in
> calc_unit_loc in filling the uy array, which holds the y values for
> displaying the units on the screen. I have looked through that code
> and don't see anything obvious that is wrong, so I will have to insert
> some print statements and see what is going on. Other displays of
> sampling areas on screen work fine (e.g., in setup for moving window).
> Seems strange, since this worked fine under GRASS 5.X and I can't see
> what might have changed to affect this. Will work more on this in next
> few days, I hope.


Hi, I had another look. in sample.c, mx[0], and mx[1] are not getting
passed correctly to the calc_unit_loc() fn.


this change makes it get a little further:   (taken from the fn)

Index: setup.h
===================================================================
RCS file: /home/grass/grassrepository/grass6/raster/r.le/r.le.setup/setup.h,v
retrieving revision 2.1
diff -u -r2.1 setup.h
--- setup.h     9 Feb 2006 03:09:01 -0000       2.1
+++ setup.h     1 Oct 2006 08:10:46 -0000
@@ -78,7 +78,9 @@
 void  sample();
 void  man_unit();
 void  draw_grid();
-int   calc_unit_loc();
+int   calc_unit_loc(double, int, int, int, int, double, int, int, int,
+                   double, int, int, int, double *, double *, int *,
+                   double, int, int, double, double, double);
 void  get_rd();
 void  f();
 int   overlap();



these warnings are then given:

sample.c: In function `man_unit':
sample.c:564: warning: passing arg 14 of `calc_unit_loc' from incompatible pointer type
sample.c:564: warning: passing arg 15 of `calc_unit_loc' from incompatible pointer type

(that's ux and uy)


as it is called:

/* calculate the upper left corner of sampling
   units and store them in arrays ux and uy */

        if (!calc_unit_loc(radius, t, b, l, r, ratio, u_w, u_l, method, intv, num, h_d,
           v_d, ux, uy, &sites, (int)(start[1]), (int)(start[0]), fmask, nx,
           mx[0], mx[1]))
           goto last;




and as defined in the fn:

/* CALCULATE THE COORDINATES OF THE TOP LEFT CORNER OF THE SAMPLING UNITS */
int calc_unit_loc (double radius, int top, int bot, int left, int right,
                   double ratio, int u_w, int u_l, int method, double intv,
                   int num, int h_d, int v_d, double *ux, double *uy,
                   int *sites, double startx, int starty, int fmask,
                   double nx, double x, double y)
{



Then, after the random quadrat boxes draw correctly, if you hit [y] you
still get a segfault, but again, one bug at a time.


Hamish

From hamish_nospam at yahoo.com  Sun Oct  1 10:58:56 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  1 10:59:53 2006
Subject: [GRASS-dev] Re: [GRASS-user] [bug #2765] v.buffer bug??
In-Reply-To: <44F46348.2010304@o2.pl>
References: <5B025B1F39D6D4119F5700508BEEEC6603DE41C9@srsofaioi4546.ktso.ch>
	<20060825151941.48445d86.hamish_nospam@yahoo.com>
	<44F46348.2010304@o2.pl>
Message-ID: <20061001215856.10c42969.hamish_nospam@yahoo.com>

Bug log:
> http://intevation.de/rt/webrt?serial_num=2765

Hi,

I have a patch I think gets around the famous v.buffer bug (attached),
please test.

I say "gets around" the bug more than solves it, as while I know that
the bug happens when the "sa" segment loops back to "0" and then the
total number of points is set by the final segment number(+2), I don't
really know why, or if this is the problem or the problem is the setting
of npn (total number of points) directly from the seg ID number.
[ lib/vector/Vlib/buffer.c  clean_parallel() ]

So this patch just makes sure that we don't set npn from a smaller "sa"
value than was found in the data.

This fixes the buffer for the test polygon found in the bug log.
I don't know if it fixes the hole-gets-filled-in area problem.


Hamish
-------------- next part --------------
Index: lib/vector/Vlib/buffer.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/vector/Vlib/buffer.c,v
retrieving revision 1.7
diff -u -r1.7 buffer.c
--- lib/vector/Vlib/buffer.c	11 Sep 2006 04:35:07 -0000	1.7
+++ lib/vector/Vlib/buffer.c	1 Oct 2006 08:43:52 -0000
@@ -117,6 +117,7 @@
 void clean_parallel ( struct line_pnts *Points, struct line_pnts *origPoints, double d , int rm_end )
 {
     int i, j, np, npn, sa, sb;
+    int sa_max = 0;
     int first=0, current, last, lcount;
     double *x, *y, px, py, ix, iy;
     static struct line_pnts *sPoints = NULL;
@@ -148,6 +149,10 @@
             G_debug (5, "  current = %d, last = %d, lcount = %d", current, last, lcount);
 	}
 	if ( lcount == 0 ) { break; }   /* loop not found */
+
+	/* ensure sa is monotonically increasing, so npn doesn't reset low */
+	if (sa > sa_max ) sa_max = sa;
+	if (sa < sa_max ) break;
 
 	/* remove loop if in buffer */
 	if ( (sb-sa) == 1 ){ /* neighbouring lines overlap */
From ychemin at gmail.com  Sun Oct  1 12:33:37 2006
From: ychemin at gmail.com (Yann Chemin)
Date: Sun Oct  1 12:33:39 2006
Subject: [GRASS-dev] r.uslek calculating k factor from soil texture maps
Message-ID: <6278879c0610010333l2e1bc7c9v4555f96bb63a088a@mail.gmail.com>

Hello list,
here is a small GRASS module for calculating USLE K factor from input
files: sand, clay, silt and organic matter in range [0.0-1.0].
Developed and worked on this week's cvs branch.
Yann
-------------- next part --------------
A non-text attachment was scrubbed...
Name: r.uslek.tar.gz
Type: application/x-gzip
Size: 19831 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061001/3fb9689d/r.uslek.tar-0001.gz
From tutey at o2.pl  Sun Oct  1 13:12:22 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sun Oct  1 13:12:25 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <20061001174732.67be5a72.hamish_nospam@yahoo.com>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>	<451BCED1.4050509@itc.it>	<200609282336.08350.jan-oliver.wagner@intevation.de>	<200609291223.52840.bernhard@intevation.de>	<17693.23749.809989.644246@cerise.gclements.plus.com>
	<20061001174732.67be5a72.hamish_nospam@yahoo.com>
Message-ID: <451FA296.1050409@o2.pl>

Hamish wrote:
> Glynn Clements wrote:
>> Bernhard Reiter wrote:

>>>>>> Anybody knows if 
>>>>>> Trac has such thing?
>>>>> I think that this is the key - being able to delete individual
>>>>> posts to a bug
>>>>> report. Given that, we could keep it open as before.

>>> I do not think this is feasabl; humans cannot beat robots that fill
>>> out  webforms.

For the time being we've been able to remove all the spam BT tickets
manually.

Also considering that the spam is currently being added manually to the
existing tickets in our BT, I think we could also remove that manually,
if it was technically possible. Only that the person in charge should
be informed about each new BT modification by email (that's currently
impossible in our BT as I was told; would Gforge tracker provide such
option?). I woulnd't mind to be that person.

Only if there is nobody willing to take care of spam in BT (eg. I quit
in future) or if the amount of spam making through is beyond a few
minutes work a day, the anonymous access should be limited. Otherwise
we should keep the BT system open for anyone if possible.

Maciek

From grass-bugs at intevation.de  Sun Oct  1 13:48:58 2006
From: grass-bugs at intevation.de (Maciek Sieczka via RT)
Date: Sun Oct  1 13:49:00 2006
Subject: [GRASS-dev] [bug #5175] (grass) v.to.db: 'option=cat' not updating
	columns other than 'cat'
Message-ID: <20061001114858.C593B1006A6@lists.intevation.de>

hamish_nospam@yahoo.com wrote (Sun, Oct 1 2006 08:34:45):

> is it hard-coded to "cat" or is it hard-coded to the category key?

Hamish,

Thanks for the hint. It is hard-coded to the category key it shows.

I have connected a table using column 'gimme' for key:

   $ v.db.connect -p huha_rcl
   Vector map <huha_rcl> is connected by:
   layer <1> table <huha_rcl> in database
   </home/grassdata/spearfish60/sieczka/dbf/> through driver <dbf> with key  
   <gimme>

and now v.to.db wants to populate the 'gimme' no matter what column I specify:

   $v.to.db -s map=huha_rcl type=point option=cat column=cat

    Updating database ...
    insert into huha_rcl ( gimme ) values  ( 1 )
    insert into huha_rcl ( gimme ) values  ( 2 )
    insert into huha_rcl ( gimme ) values  ( 3 )
    ...

Maciek


-------------------------------------------- Managed by Request Tracker

From grass-bugs at intevation.de  Sun Oct  1 13:51:40 2006
From: grass-bugs at intevation.de (Maciek Sieczka via RT)
Date: Sun Oct  1 13:51:40 2006
Subject: [GRASS-dev] [bug #4352] (grass) v.to.db: segfault on layer > 1
Message-ID: <20061001115140.12B881006A6@lists.intevation.de>

Thanks, closing it then. Re-open if needed.

Maciek


-------------------------------------------- Managed by Request Tracker

From morten at untamo.net  Sun Oct  1 15:46:21 2006
From: morten at untamo.net (Morten Hulden)
Date: Sun Oct  1 15:46:25 2006
Subject: [GRASS-dev] Need to update g.setproj
In-Reply-To: <17695.11899.407457.43545@cerise.gclements.plus.com>
References: <17693.22970.168317.560641@cerise.gclements.plus.com>	<C142AFC1.251D9%michael.barton@asu.edu>
	<17695.11899.407457.43545@cerise.gclements.plus.com>
Message-ID: <451FC6AD.2040702@untamo.net>

Glynn Clements wrote:

> Converting lib/gis/geo_init.c and g.setproj/main.c to text files was
> simple enough; those are attached.

geo_init.c and g.setproj/main lack support for these (later additions to 
proj):

geos : Geostationary Satellite View
krovak : Krovak
lcca : Lambert Conformal Conic Alternative
sterea : Oblique Stereographic Alternative
vitk1 : Vitkovsky I

Since newer proj has separate projections for alternative lcc and stere, 
adding these to grass would solve at least one problem mentioned in this 
thread.

Morten

From grass-bugs at intevation.de  Sun Oct  1 16:01:31 2006
From: grass-bugs at intevation.de (Markus Neteler via RT)
Date: Sun Oct  1 16:01:33 2006
Subject: [GRASS-dev] [bug #5168] (grass) v.in.ogr: undefined symbol
	OGRRegisterAll
Message-ID: <20061001140131.DF66B1006A4@lists.intevation.de>

> ogr2ogr -f "ESRI Shapefile" adm.shp adm.e00

does not work because input and output are to be reverse!
The odd order in ogr2ogr is:

ogr2ogr -f "ESRI Shapefile" outfile infile

So, if you have a recent GDAL/OGR, I think from CVS
since 1.3.2 doesn't contain E00 support yet, this
may work:

ogr2ogr -f "ESRI Shapefile" adm.e00 adm.shp

Likewise, if a GDAL/OGR from CVS is present, also v.in.ogr
will accept E00. But I think that v.in.e00 with a recent
AVCTOOLS (http://avce00.maptools.org/) installed will
probably still works better (I darkly remember a bug report
in OGR for E00, but cannot find it).

Markus

-------------------------------------------- Managed by Request Tracker

From neteler at itc.it  Sun Oct  1 16:16:06 2006
From: neteler at itc.it (Markus Neteler)
Date: Sun Oct  1 16:16:07 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <200609291223.52840.bernhard@intevation.de>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>
	<451BCED1.4050509@itc.it>
	<200609282336.08350.jan-oliver.wagner@intevation.de>
	<200609291223.52840.bernhard@intevation.de>
Message-ID: <20061001141606.GA11899@bartok.itc.it>

On Fri, Sep 29, 2006 at 12:23:47PM +0200, Bernhard Reiter wrote:
> On Thursday 28 September 2006 23:36, Jan-Oliver Wagner wrote:
> > On Thursday 28 September 2006 15:32, Markus Neteler wrote:
> > > Maciej Sieczka wrote on 09/28/2006 02:52 PM:
> > > > But I hope that the new bugtracker that Grass some-day will have, will
> > > > provide a possibility to delete or modify single past records in the
> > > > given ticket, not only to kill the whole bogus ticket. 
> 
> The administrator can do this in request-tracker already
> and manipulate the database.

... but: we don't have an admin outside of Intevation AFAIK...
(who could also change Harmish to Hamish in RT).

I feel that GRASS folks would love to switch the BT now,
what does Intevation think? Besides the spam problem, we
basically have the missing patch management problem in RT.

Markus

From mlennert at club.worldonline.be  Sun Oct  1 16:36:00 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sun Oct  1 16:35:46 2006
Subject: [GRASS-dev] adding 'desc' to dbf sql driver
In-Reply-To: <1a486f560609271831m747f3495sa6d8495273c107d4@mail.gmail.com>
References: <4513A84E.8090807@club.worldonline.be>
	<1a486f560609271831m747f3495sa6d8495273c107d4@mail.gmail.com>
Message-ID: <32962.85.10.67.148.1159713360.squirrel@geog-pc40.ulb.ac.be>

On Thu, September 28, 2006 03:31, Daniel Calvelo wrote:
> Hi Moritz. See below

Thanks Daniel. As soon as I find the time, I'll try to translate your
recipe into code...

Moritz

>
> On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:
>> Hi,
>>
>> Reworking on d.vect.chart I need to be able to sort the reults of a
>> select in descending order. As the dbf driver doesn't allow this, I have
>> been trying to see how to extend the driver.
>>
>> IIUC, it's "just" a question of conditionalising the qsort call on line
>> 566 of db/drivers/dbf/dbfexe.c, and (would this be enough ?) use
>>
>> qsort(set, nset, sizeof(int), -cmp_row);
>
> That might work. Although it would be much nicer to use an expression
> as sorting order.
>
>> if the desc keyword is present.
>>
>> However, I have some trouble understanding the parsing of the sql
>> statement.
>>
>> If I understand correctly, we would need to extent the SQLPSTMT
>> structure in include/sqlp.h to include a flag for 'desc' (and possible
>> 'asc') and the parser to identify and set that flag.
>>
>> But this is as far as I get. Could someone help me with this ?
>
> Quick shot: you need to
>
> - change SQLPSTMT to have an "order"/"direction"/"sort_order"  element
>
> - add ASC and DESC in lex.l as tokens
>
> - change yac.y to stg like:
>
> y_order: y_order_asc | y_order_desc ;
> y_order_asc:
>        NAME ASC { sqpOrderColumn( $1 ); sqpOrderDirection( 1 ); }
> ;
> y_order_desc:
>       NAME DESC { sqpOrderColumn( $1 );sqpOrderDirection( 2 );}
> ;
>
> - add in sql.c a sqpOrderDirection() function that sets the element
> you added to SQLPSTMT
>
> (Alternatively, you can change sqpOrderColumn() to receive two
> arguments, one being the sorting direction. I'd also rather #define
> SORT_ASC and SORT_DESC instead of using magic numbers as above.)
>
> - use that value in dbfexe.c to test the sorting direction.
>
> HTH,
>
> Daniel.
>
>> Thanks,
>>
>> Moritz
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>>
>
>
> --
> -- Daniel Calvelo Aros
>


From mlennert at club.worldonline.be  Sun Oct  1 16:44:34 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sun Oct  1 16:44:19 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <C144AD5E.F3FA%michael.barton@asu.edu>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
Message-ID: <42113.85.10.67.148.1159713874.squirrel@geog-pc40.ulb.ac.be>

On Sun, October 1, 2006 08:25, Michael Barton wrote:

>
> 2a. The box directly defines the geometry of the new region and the box?s
> longest dimension determines the amount zoomed out (how much the region is
> extended to make the current map appear smaller). The new region is
> centered
> in the display. That is, a long, short box will produce a long, short
> region
> that is larger than the original region (making the map appear to be
> smaller).
>

2a: +1

Moritz

From tutey at o2.pl  Sun Oct  1 16:48:38 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sun Oct  1 16:48:45 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <20061001141606.GA11899@bartok.itc.it>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>	<451BCED1.4050509@itc.it>	<200609282336.08350.jan-oliver.wagner@intevation.de>	<200609291223.52840.bernhard@intevation.de>
	<20061001141606.GA11899@bartok.itc.it>
Message-ID: <451FD546.2090206@o2.pl>

Markus Neteler wrote:
> On Fri, Sep 29, 2006 at 12:23:47PM +0200, Bernhard Reiter wrote:
>> On Thursday 28 September 2006 23:36, Jan-Oliver Wagner wrote:
>>> On Thursday 28 September 2006 15:32, Markus Neteler wrote:
>>>> Maciej Sieczka wrote on 09/28/2006 02:52 PM:
>>>>> But I hope that the new bugtracker that Grass some-day will have, will
>>>>> provide a possibility to delete or modify single past records in the
>>>>> given ticket, not only to kill the whole bogus ticket. 
>> The administrator can do this in request-tracker already
>> and manipulate the database.
> 
> .. but: we don't have an admin outside of Intevation AFAIK...
> (who could also change Harmish to Hamish in RT).

Markus,

Aren't you an admin?

https://intevation.de/rt/admin-webrt?display=Modify+the+User+called&user_id=mneteler

Maciek

From Michael.Barton at asu.edu  Sun Oct  1 17:23:15 2006
From: Michael.Barton at asu.edu (Michael Barton)
Date: Sun Oct  1 17:25:04 2006
Subject: [GRASS-dev] r.uslek calculating k factor from soil texture maps
In-Reply-To: <6278879c0610010333l2e1bc7c9v4555f96bb63a088a@mail.gmail.com>
Message-ID: <C1452B73.F413%michael.barton@asu.edu>

One of my students was planning to do something like this to go with the
r.usped surface process modeling we have under development. This saves us
some work. Thanks much.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Yann Chemin <ychemin@gmail.com>
> Date: Sun, 1 Oct 2006 15:33:37 +0500
> To: GRASS developers list <grass-dev@grass.itc.it>
> Cc: <ychemin@gmail.com>
> Subject: [GRASS-dev] r.uslek calculating k factor from soil texture maps
> 
> Hello list,
> here is a small GRASS module for calculating USLE K factor from input
> files: sand, clay, silt and organic matter in range [0.0-1.0].
> Developed and worked on this week's cvs branch.
> Yann


From dylan.beaudette at gmail.com  Sun Oct  1 22:27:02 2006
From: dylan.beaudette at gmail.com (Dylan Beaudette)
Date: Sun Oct  1 22:27:05 2006
Subject: [GRASS-dev] Re: [GRASS-user] [bug #2765] v.buffer bug??
In-Reply-To: <20061001215856.10c42969.hamish_nospam@yahoo.com>
References: <5B025B1F39D6D4119F5700508BEEEC6603DE41C9@srsofaioi4546.ktso.ch>
	<20060825151941.48445d86.hamish_nospam@yahoo.com>
	<44F46348.2010304@o2.pl>
	<20061001215856.10c42969.hamish_nospam@yahoo.com>
Message-ID: <3c5546140610011327l42eb1662w5eed705085ab35b5@mail.gmail.com>

thanks hamish,

will try it out on the latest CVS,

PS: pardon my stupidity, but how would i apply this patch (forgot!)

Dylan

On 10/1/06, Hamish <hamish_nospam@yahoo.com> wrote:
> Bug log:
> > http://intevation.de/rt/webrt?serial_num=2765
>
> Hi,
>
> I have a patch I think gets around the famous v.buffer bug (attached),
> please test.
>
> I say "gets around" the bug more than solves it, as while I know that
> the bug happens when the "sa" segment loops back to "0" and then the
> total number of points is set by the final segment number(+2), I don't
> really know why, or if this is the problem or the problem is the setting
> of npn (total number of points) directly from the seg ID number.
> [ lib/vector/Vlib/buffer.c  clean_parallel() ]
>
> So this patch just makes sure that we don't set npn from a smaller "sa"
> value than was found in the data.
>
> This fixes the buffer for the test polygon found in the bug log.
> I don't know if it fixes the hole-gets-filled-in area problem.
>
>
> Hamish
>
>
> _______________________________________________
> grassuser mailing list
> grassuser@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser
>
>
>
>

From werchowyna at epf.pl  Sun Oct  1 23:14:52 2006
From: werchowyna at epf.pl (Maciej Sieczka)
Date: Sun Oct  1 23:15:01 2006
Subject: [GRASS-dev] v.clean: dangles removed but nothing cahnged (?)
Message-ID: <45202FCC.5050506@epf.pl>

Hi,

Although v.clean often prints "Removed dangles:   177", nothing
actually changes in the output compred to input. What does that message
actually mean?

in spearfish:

$ v.clean in=roads out=roads_nodang tool=rmdangle

| Remove dangles                  |  Building topology ...
825 primitives registered
Topology was built.
Number of nodes     :   676
Number of primitives:   825
Number of points    :   0
Number of lines     :   825
Number of boundaries:   0
Number of centroids :   0
Number of areas     :   -
Number of isles     :   -
Removed dangles:   177  removed lines:     0
Building topology ...
825 primitives registered
0 areas built
0 isles built
Attaching islands:
Attaching centroids: Topology was built.
Number of nodes     :   676
Number of primitives:   825
Number of points    :   0
Number of lines     :   825
Number of boundaries:   0
Number of centroids :   0
Number of areas     :   0
Number of isles     :   0

Now run the same command on the previous output - the same information
about 177 removed dangles pops up. Why?

$ v.clean in=roads_nodang out=roads_nodang2 tool=rmdangle
| Remove dangles                  |  Building topology ...
825 primitives registered
Topology was built.
Number of nodes     :   676
Number of primitives:   825
Number of points    :   0
Number of lines     :   825
Number of boundaries:   0
Number of centroids :   0
Number of areas     :   -
Number of isles     :   -
Removed dangles:   177  removed lines:     0
Building topology ...
825 primitives registered
0 areas built
0 isles built
Attaching islands:
Attaching centroids: Topology was built.
Number of nodes     :   676
Number of primitives:   825
Number of points    :   0
Number of lines     :   825
Number of boundaries:   0
Number of centroids :   0
Number of areas     :   0
Number of isles     :   0

There is no difference between roads_nodang and roads_nodang2:

$ v.build roads_nodang option=dump > roads_nodang.dump
$ v.build roads_nodang2 option=dump > roads_nodang2.dump
$ diff roads_nodang2.dump roads_nodang.dump
(nothing printed)

so the data was not modified, despite "Removed dangles:   177". Or was it?

Maciek

---------------------
Panorama Internetu - prognoza pogody, poczta e-mail z najwi?kszym za??cznikiem, SMS, wyszukiwarki: Gooru, Anonser, serwisy: randki, og?oszenia, wakacje, program TV, Kina, muzyka, DVD, newsy, inne.
http://www.panoramainternetu.pl/ (http://www.epf.pl/)

From glynn at gclements.plus.com  Sun Oct  1 23:21:08 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Oct  1 23:21:58 2006
Subject: [GRASS-dev] Need to update g.setproj
In-Reply-To: <17695.11899.407457.43545@cerise.gclements.plus.com>
References: <17693.22970.168317.560641@cerise.gclements.plus.com>
	<C142AFC1.251D9%michael.barton@asu.edu>
	<17695.11899.407457.43545@cerise.gclements.plus.com>
Message-ID: <17696.12612.397625.235766@cerise.gclements.plus.com>


Glynn Clements wrote:

> > > Is there any real reason why GRASS needs to comprehend the projection
> > > parameters, i.e. to have lib/gis/geo_init.c or all of that boilerplate
> > > in g.setproj?
> > > 
> > > IOW, can projection parameters not be treated as opaque key/value
> > > pairs which are simply passed straight through to PROJ, with any UI
> > > consisting of generic code using an external database[1] of projection
> > > parameters?
> > > 
> > > [1] By which, I mean a text file in an easy-to-parse format.
> > > 
> > > It seems to me that all of that boilerplate could be replaced by a
> > > list of projections (+proj= name, description), a database of
> > > parameters (+<opt>= name, description, bool/int/float), and a matrix
> > > of "projection X accepts/requires parameter Y with default value Z".
> > 
> > This seems like it would be a big help in designing a GUI wrapper for these
> > functions.
> 
> Converting lib/gis/geo_init.c and g.setproj/main.c to text files was
> simple enough; those are attached.
> 
> AFAICT, it should be straightforward to replace the boilerplate in
> g.setproj with code which uses the tables.

I've modified g.setproj to use text files rather than hardcoded
settings. lib/gis/geo_init.c and include/geo.h have been removed, as
g.setproj no longer uses them (and nothing else used them).

This shouldn't noticably change the behaviour of g.setproj; it is
still interactive. However, any future modifications should be more
straightforward.

-- 
Glynn Clements <glynn@gclements.plus.com>

From michael.barton at asu.edu  Sun Oct  1 23:25:44 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  1 23:25:53 2006
Subject: [GRASS-dev] Need to update g.setproj
In-Reply-To: <17696.12612.397625.235766@cerise.gclements.plus.com>
Message-ID: <C1458068.F42E%michael.barton@asu.edu>

Thanks very much for getting this important update started.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Glynn Clements <glynn@gclements.plus.com>
> Date: Sun, 1 Oct 2006 22:21:08 +0100
> To: Michael Barton <michael.barton@asu.edu>, Paul Kelly
> <paul-grass@stjohnspoint.co.uk>, GRASS-DEV <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] Need to update g.setproj
> 
> 
> Glynn Clements wrote:
> 
>>>> Is there any real reason why GRASS needs to comprehend the projection
>>>> parameters, i.e. to have lib/gis/geo_init.c or all of that boilerplate
>>>> in g.setproj?
>>>> 
>>>> IOW, can projection parameters not be treated as opaque key/value
>>>> pairs which are simply passed straight through to PROJ, with any UI
>>>> consisting of generic code using an external database[1] of projection
>>>> parameters?
>>>> 
>>>> [1] By which, I mean a text file in an easy-to-parse format.
>>>> 
>>>> It seems to me that all of that boilerplate could be replaced by a
>>>> list of projections (+proj= name, description), a database of
>>>> parameters (+<opt>= name, description, bool/int/float), and a matrix
>>>> of "projection X accepts/requires parameter Y with default value Z".
>>> 
>>> This seems like it would be a big help in designing a GUI wrapper for these
>>> functions.
>> 
>> Converting lib/gis/geo_init.c and g.setproj/main.c to text files was
>> simple enough; those are attached.
>> 
>> AFAICT, it should be straightforward to replace the boilerplate in
>> g.setproj with code which uses the tables.
> 
> I've modified g.setproj to use text files rather than hardcoded
> settings. lib/gis/geo_init.c and include/geo.h have been removed, as
> g.setproj no longer uses them (and nothing else used them).
> 
> This shouldn't noticably change the behaviour of g.setproj; it is
> still interactive. However, any future modifications should be more
> straightforward.
> 
> -- 
> Glynn Clements <glynn@gclements.plus.com>

From tutey at o2.pl  Sun Oct  1 23:56:51 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sun Oct  1 23:56:56 2006
Subject: [GRASS-dev] v.clean: dangles removed but nothing cahnged (?)
In-Reply-To: <45202FCC.5050506@epf.pl>
References: <45202FCC.5050506@epf.pl>
Message-ID: <452039A3.4020901@o2.pl>

Shoot, I sent it from a wrong address. Please reply to tutey at o2.pl
only. I almost don't use that @epf.pl at all anymore. Sorry for the mess.

Maciek

From grass-bugs at intevation.de  Mon Oct  2 00:37:29 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Mon Oct  2 00:37:31 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full path
	to dsn is missing
Message-ID: <20061001223729.C4D391005D8@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5176
-------------------------------------------------------------------------

Subject: v.in.ogr: segfault when a full path to dsn is missing

Uisng current CVS on x86 Linux. Built from source.

I have a shapefile in:



$ ls $HOME/force_lrconnect_cl_onlycat139
force_lrconnect_cl_onlycat139.dbf  force_lrconnect_cl_onlycat139.shp
force_lrconnect_cl_onlycat139.prj  force_lrconnect_cl_onlycat139.shx



v.in.ogr segfaults if I specify dsn as "force_lrconnect_cl_onlycat139/":



$ v.in.ogr dsn=force_lrconnect_cl_onlycat139/
output=force_lrconnect_cl_onlycat139_import
layer=force_lrconnect_cl_onlycat139 min_area=0.0001 snap=-1 --o
WARNING: The vector 'force_lrconnect_cl_onlycat139_import' already exists
         and will be overwritten.
A datum name wgs84 (WGS_1984) was specified without transformation parameters.
Note that the GRASS default for wgs84 is towgs84=0.000,0.000,0.000.
Projection of input dataset and current location appear to match.
Proceeding with import...
WARNING: The vector 'force_lrconnect_cl_onlycat139_import' already exists
         and will be overwritten.
WARNING: Table 'force_lrconnect_cl_onlycat139_import' linked to vector did
         not exist.
Layer: force_lrconnect_cl_onlycat139
WARNING: Column name changed: 'cat' -> 'cat_'
Segmentation fault



If I specify a full path /home/shoofi/orce_lrconnect_cl_onlycat139/ then it
works OK.

Maciek


-------------------------------------------- Managed by Request Tracker

From hamish_nospam at yahoo.com  Mon Oct  2 01:19:17 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 01:19:26 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <451FD546.2090206@o2.pl>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>
	<451BCED1.4050509@itc.it>
	<200609282336.08350.jan-oliver.wagner@intevation.de>
	<200609291223.52840.bernhard@intevation.de>
	<20061001141606.GA11899@bartok.itc.it> <451FD546.2090206@o2.pl>
Message-ID: <20061002121917.30491a66.hamish_nospam@yahoo.com>

>>> But I hope that the new bugtracker that Grass some-day will
>>> have, will provide a possibility to delete or modify single past
>>> records in the given ticket, not only to kill the whole bogus
>>> ticket.
>> The administrator can do this in request-tracker already
>> and manipulate the database.

MN:
> .. but: we don't have an admin outside of Intevation AFAIK...
> (who could also change Harmish to Hamish in RT).

I dunno, I always get a chuckle out of that. It reflects on how bad a C
programmer I am.

MS:
> Markus,
> 
> Aren't you an admin?
> 
> https://intevation.de/rt/admin-webrt?display=Modify+the+User+called&user_id=mneteler


Hey, I hadn't seen that before. After logging in as myself, I have now
changed my own name to the more common spelling.

fyi, for me it says-

Access Control

grass: Manipulate
thuban: Display
etc.

MN:
> Besides the spam problem, we basically have the missing patch
> management problem in RT.

Indeed.


Hamish

From hamish_nospam at yahoo.com  Mon Oct  2 01:30:10 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 01:30:15 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full
	path	to dsn is missing
In-Reply-To: <20061001223729.C4D391005D8@lists.intevation.de>
References: <20061001223729.C4D391005D8@lists.intevation.de>
Message-ID: <20061002123010.159ebd4f.hamish_nospam@yahoo.com>

Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5176
> -------------------------------------------------------------------------
> 
> Subject: v.in.ogr: segfault when a full path to dsn is missing
> 
> Uisng current CVS on x86 Linux. Built from source.
> 
> I have a shapefile in:
> 
> $ ls $HOME/force_lrconnect_cl_onlycat139
> force_lrconnect_cl_onlycat139.dbf  force_lrconnect_cl_onlycat139.shp
> force_lrconnect_cl_onlycat139.prj  force_lrconnect_cl_onlycat139.shx
> 
> v.in.ogr segfaults if I specify dsn as "force_lrconnect_cl_onlycat139/":
> 
> $ v.in.ogr dsn=force_lrconnect_cl_onlycat139/  \
>      output=force_lrconnect_cl_onlycat139_import \
>      layer=force_lrconnect_cl_onlycat139 min_area=0.0001 snap=-1 --o
>
> WARNING: The vector 'force_lrconnect_cl_onlycat139_import' already exists
>          and will be overwritten.
> A datum name wgs84 (WGS_1984) was specified without transformation parameters.
> Note that the GRASS default for wgs84 is towgs84=0.000,0.000,0.000.
> Projection of input dataset and current location appear to match.
> Proceeding with import...
> WARNING: The vector 'force_lrconnect_cl_onlycat139_import' already exists
>          and will be overwritten.
> WARNING: Table 'force_lrconnect_cl_onlycat139_import' linked to vector did
>          not exist.
> Layer: force_lrconnect_cl_onlycat139
> WARNING: Column name changed: 'cat' -> 'cat_'
> Segmentation fault
>
> If I specify a full path /home/shoofi/orce_lrconnect_cl_onlycat139/ then it
> works OK.


(undocumented?) tip:

v.in.ogr dsn=force_lrconnect_cl_onlycat139.shp

does it work then?
what if you change the dir name to something not the same as the filename?

Hamish

From epatton at nrcan.gc.ca  Mon Oct  2 03:19:23 2006
From: epatton at nrcan.gc.ca (Patton, Eric)
Date: Mon Oct  2 03:19:27 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55BB3@s5-dar-r1.nrn.nrcan.gc.ca>

2a +1

~ Eric. 

-----Original Message-----
From: grass-dev-bounces@grass.itc.it
To: Michael Barton
Cc: GRASS-DEV
Sent: 10/1/2006 10:44 AM
Subject: Re: [GRASS-dev] Vote for your favorite zoom out

On Sun, October 1, 2006 08:25, Michael Barton wrote:

>
> 2a. The box directly defines the geometry of the new region and the
box?s
> longest dimension determines the amount zoomed out (how much the
region is
> extended to make the current map appear smaller). The new region is
> centered
> in the display. That is, a long, short box will produce a long, short
> region
> that is larger than the original region (making the map appear to be
> smaller).
>

2a: +1

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

From hamish_nospam at yahoo.com  Mon Oct  2 03:23:35 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 03:23:56 2006
Subject: [GRASS-dev] Re: [GRASS-user] [bug #2765] v.buffer bug??
In-Reply-To: <3c5546140610011327l42eb1662w5eed705085ab35b5@mail.gmail.com>
References: <5B025B1F39D6D4119F5700508BEEEC6603DE41C9@srsofaioi4546.ktso.ch>
	<20060825151941.48445d86.hamish_nospam@yahoo.com>
	<44F46348.2010304@o2.pl>
	<20061001215856.10c42969.hamish_nospam@yahoo.com>
	<3c5546140610011327l42eb1662w5eed705085ab35b5@mail.gmail.com>
Message-ID: <20061002142335.63636ffe.hamish_nospam@yahoo.com>

Dylan Beaudette wrote:

> > > http://intevation.de/rt/webrt?serial_num=2765
> >
> > Hi,
> >
> > I have a patch I think gets around the famous v.buffer bug
> > (attached), please test.
..
> will try it out on the latest CVS,
> 
> PS: pardon my stupidity, but how would i apply this patch (forgot!)

cd /where/grass/is/
patch -p0 < patch.diff
cd lib/vector/Vlib/
make


or if that doesn't work and it's small patch like this one, just make
the changes by hand.


Hamish

From hamish_nospam at yahoo.com  Mon Oct  2 03:55:09 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 03:55:20 2006
Subject: [GRASS-dev] r.resamp.aggregate, trimmed means
Message-ID: <20061002145509.32d9bab8.hamish_nospam@yahoo.com>

[r.resamp.stats]

> > > Can we make a decision as to the official name of this module?
> > 
> > how about r.resamp.bin? (as in binning, not binary)
> > 
> > If r.resamp.aggregate is used, I'd vote for using the full word.
> > I don't think "aggregate" abreviates well.
> >
> > by the way, what is this module?
>
> It's a resampling module where the value of the output cell is an
> aggregate (mean, median, mode, min, max etc) of the values from all of
> the input cells whose centres lie within the bounds of the output
> cell.

Hey, that is pretty neat. I can see it being useful for sub-sampling
noisy imagery data with low signal:noise (but > 50%) using a median
filter.

Do we have a way to do a trimmed mean? (eg mean of values between perc10
and perc90; replace 10% with 5% or x%, or 2 Stdevs, etc..) I've always
liked it as a nice compromise between the outlier-discarding ability of
the median and the less arbitrary nature of the mean.
I'd like to have this in r.univar and r.series* too... :)

[*] only useful with many input maps of course


Hamish

From hamish_nospam at yahoo.com  Mon Oct  2 04:08:49 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 04:14:30 2006
Subject: [GRASS-dev] interferring ovewrite flags [was: [bug #5167]
	(grass) v.patch: -a(ppend) issues]
In-Reply-To: <C13D4032.EFF4%michael.barton@asu.edu>
References: <4517A735.2000208@o2.pl>
	<C13D4032.EFF4%michael.barton@asu.edu>
Message-ID: <20061002150849.4f7d3e37.hamish_nospam@yahoo.com>

Michael Barton wrote:
> 
> Is having both -o and --o a problem?
> 
> The reason I ask is that --o, by design, doesn't show up in the
> module/script GUI. For r.mask, much of the time, the user will simply
> want to overwrite the existing MASK file, to avoid the annoyance of
> having to run g.remove each time (note the MASK file created by r.mask
> is a reclass of a real raster file, so there is little loss if it is
> deleted).
> 
> So in this case, I'd prefer to have an overwrite option easily
> accessible to a user. How best to do this?


be careful with using r.mask or r.mapcalc to overwrite a MASK. If the
old mask is still present when the new one is created, it will be an
additive replacement, not a full replacement. This can be very useful
for "building up" a MASK map, but also cause lots of problems if you
aren't expecting it.

I'm not exactly sure how r.reclass works (thus r.mask script too), but
it will work like this if it reads raster data row by row.


Hamish

From michael.barton at asu.edu  Mon Oct  2 04:24:22 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Oct  2 04:24:28 2006
Subject: [GRASS-dev] interferring ovewrite flags [was: [bug #5167]
	(grass) v.patch: -a(ppend) issues]
In-Reply-To: <20061002150849.4f7d3e37.hamish_nospam@yahoo.com>
Message-ID: <C145C666.F43E%michael.barton@asu.edu>

This is interesting.

I don't *think* that r.reclass will work additively because it just makes a
new copy of the tables in cellhd and cats for the same map. I've never
noticed it when making masks.

But I haven't tested it for this specific "feature".

How can you make a mask additive with r.mapcalc? This could be useful
sometime.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam@yahoo.com>
> Date: Mon, 2 Oct 2006 15:08:49 +1300
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <tutey@o2.pl>, <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] interferring ovewrite flags [was: [bug #5167] (grass)
> v.patch: -a(ppend) issues]
> 
> Michael Barton wrote:
>> 
>> Is having both -o and --o a problem?
>> 
>> The reason I ask is that --o, by design, doesn't show up in the
>> module/script GUI. For r.mask, much of the time, the user will simply
>> want to overwrite the existing MASK file, to avoid the annoyance of
>> having to run g.remove each time (note the MASK file created by r.mask
>> is a reclass of a real raster file, so there is little loss if it is
>> deleted).
>> 
>> So in this case, I'd prefer to have an overwrite option easily
>> accessible to a user. How best to do this?
> 
> 
> be careful with using r.mask or r.mapcalc to overwrite a MASK. If the
> old mask is still present when the new one is created, it will be an
> additive replacement, not a full replacement. This can be very useful
> for "building up" a MASK map, but also cause lots of problems if you
> aren't expecting it.
> 
> I'm not exactly sure how r.reclass works (thus r.mask script too), but
> it will work like this if it reads raster data row by row.
> 
> 
> Hamish

From hamish_nospam at yahoo.com  Mon Oct  2 04:26:50 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 04:26:59 2006
Subject: [GRASS-dev] GIF -> PNG
In-Reply-To: <20060929210435.GA7926@bartok.itc.it>
References: <340505ef0609220525g7dc366e0re2a6ca623f83b0ec@mail.gmail.com>
	<20060922150853.GA6624@bartok.itc.it>
	<20060927223608.4ee9269d.hamish_nospam@yahoo.com>
	<451A9CF5.4020001@itc.it> <20060929210435.GA7926@bartok.itc.it>
Message-ID: <20061002152650.2623993a.hamish_nospam@yahoo.com>

> > > For the record, TclTk doesn't like PNG. e.g. the NVIZ help browser
> > > won't load PNG help graphics in the nviz man pages.
> >
> > Cool :-(
> > We should change the NVIZ help browser to the standard HTML browser.
> > The limited tcltk based browser isn't that fancy at all.
..
> Done (startup GUI) & done (nviz). Also for 6.2-release branch.
> Any other places?

$ grep -rI help.tcl * | grep -v locale/po | cut -f1 -d: | uniq

No, only those two used it.

If we remove GRASS's visualization/nviz/html/help.tcl web browser,
that's 120k less source to distribute!


> Please test...

with this set in ~/.grass.bashrc:
  export GRASS_HTML_BROWSER=dillo
it works fine from NVIZ, but the startup GUI defaults to using klunky
old mozilla as .grass.bashrc hasn't been sourced yet(?). Also is there
any way to get rid of or minimize the residual xterm window?


Hamish

From hamish_nospam at yahoo.com  Mon Oct  2 07:38:36 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 07:38:44 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55B86@s5-dar-r1.nrn.nrcan.gc.ca>
References: <0E5A77B55A57D511BB3F0002A537C26208C55B86@s5-dar-r1.nrn.nrcan.gc.ca>
Message-ID: <20061002183836.1f3596c6.hamish_nospam@yahoo.com>

Eric wrote:

> Borrowing heavily from my conversations with Maciek, I have written a
> step-by-step how-to for improving Grass documentation, specifically
> man pages. I welcome any feedback and suggestions for improvement. My
> knowledge of html is pretty basic, hopefully there aren't too many
> errors. It looks OK to me in Firefox. I was thinking perhaps this page
> could be linked/inserted into the main Grass GDP page, so it can be
> easily found for those who are interested in improving the
> documentation. 


Glad to see this, sometimes with GRASS development I think (like GIS)
often the answers are simple to find & easy to enact, *if you know where
to look* before you start looking. This sort of tutorial goes a long way
to fixing that problem. Can you put this up on the wiki? (probably in
the development section) The sooner the GDP is migrated out of the web
site CVS and into the wiki and truely group maintained the better for
everyone IMO.  [ps. -- is the wiki being backed up? available as .zip
for burning to a CD for access to help when in the field?]

> Let me know what you think,

Add a link to help page translation efforts?

> To begin, you must obtain the latest Grass source code from the CVS
> repositories.

link to the CVS web interface, or write a script to pluck the latest
description.html file for any given module. (aim for really low barrier
to entry) Little html experience is needed.

Note how to add images. (r.terraflow, v.voronoi,...)
see doc/html_documentation.txt

> Once you have downloaded the CVS source code, open a terminal and
> change directory to /your_cvs_directory/grass6/vector/v.in.ascii. You
> have to make your edits/corrections to the original copy of the
> module's description.html page within grass6/vector/v.in.ascii, not a
> copy of this page.
> Open a text editor and make your edits to description.html. Depending
> on where your cvs source is on disk, you may have to do so as root
> (Ex: sudo gedit description.html). Save your edits by overwriting the
> original description.html.

There's no reason you can't make a copy and work from that, and no
reason you have to be root. The CVS source doesn't need to have any
superuser access, it's proably very good advice that it isn't given such
rights. "cvs diff" may no longer work, but that's not the end of the
world if you hung on to the original.

If editing in the source tree is a problem, just make a copy of the file
and:

diff -u /usr/src/grass/.../description.html description.html.NEW



thanks,
Hamish

From woklist at kyngchaos.com  Mon Oct  2 09:39:31 2006
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Mon Oct  2 09:40:00 2006
Subject: [GRASS-dev] r.random still broken on Mac
In-Reply-To: <17693.23534.45307.786393@cerise.gclements.plus.com>
References: <C1403A8C.25012%michael.barton@asu.edu>
	<17692.1097.409484.178701@cerise.gclements.plus.com>
	<A3DEEFA8-1BC5-4C6E-B6B7-AD3A0E2135B0@kyngchaos.com>
	<9560F255-7A6B-43DA-8B3C-CE3C8199BB54@kyngchaos.com>
	<17693.23534.45307.786393@cerise.gclements.plus.com>
Message-ID: <79F72A99-AFC5-4963-8668-AFBA7F3E3A2E@kyngchaos.com>

On Sep 30, 2006, at 2:46 AM, Glynn Clements wrote:

>
> William Kyngesburye wrote:
>
>> I just did a quick test - removed __APPLE__ from r.random, so it uses
>> the extern lrand48.  I now get a random distribution.
>
> So it's the fake lrand48() that's causing problems?
>
> Doh.
>
...

> Can you try this instead:
>
> #define lrand48() (((long) rand() ^ ((long) rand() << 16)) &  
> 0x7FFFFFFF)
>
That works.

So, was there some other reason to use the fake lrand48() on OS X,  
since the real one seems to work?

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"Mon Dieu! but they are all alike.  Cheating, murdering, lying,  
fighting, and all for things that the beasts of the jungle would not  
deign to possess - money to purchase the effeminate pleasures of  
weaklings.  And yet withal bound down by silly customs that make them  
slaves to their unhappy lot while firm in the belief that they be the  
lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan


-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061002/eac1a8cc/attachment.html
From bernhard at intevation.de  Mon Oct  2 10:16:52 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon Oct  2 10:17:01 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <20061001174732.67be5a72.hamish_nospam@yahoo.com>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>
	<17693.23749.809989.644246@cerise.gclements.plus.com>
	<20061001174732.67be5a72.hamish_nospam@yahoo.com>
Message-ID: <200610021016.56298.bernhard@intevation.de>

On Sunday 01 October 2006 06:47, Hamish wrote:
> Glynn Clements wrote:
> > Bernhard Reiter wrote:

> > > I do not think this is feasable; humans cannot beat robots that fill
> > > out  webforms.
> >
> > Can we add a captcha to the form? This would only be required for
> > guest users.

Sure, we can. This would need to be our own implementation
as you already found out. Do not underestimate this as it is a source
for new problems.

> An easy implementation I've seen was a simple auto-generated web page
> that asked a randomly generated simple math question in english. e.g.
> "What's [nine] [minus] [four]?" _________ [Submit]
>
> We're not Hotmail or Yahoo! Mail, so I doubt we have to bother with
> "spot the word in the noise" tricks. Beating a custom app from
> relatively small projects like ours just isn't worth the spammer's
> time (by definition they're trying to take the lazy route to success).

I agree.
If you want to start coding this one, 
I suggest to take the current gforge code and add it (www.gforge.org).

Bernhard


-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061002/51142b07/attachment.bin
From bernhard at intevation.de  Mon Oct  2 10:22:14 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon Oct  2 10:22:18 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <451FA296.1050409@o2.pl>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>
	<20061001174732.67be5a72.hamish_nospam@yahoo.com>
	<451FA296.1050409@o2.pl>
Message-ID: <200610021022.15340.bernhard@intevation.de>

On Sunday 01 October 2006 13:12, Maciej Sieczka wrote:
> >>> I do not think this is feasabl; humans cannot beat robots that fill
> >>> out ?webforms.
>
> For the time being we've been able to remove all the spam BT tickets
> manually.
>
> Also considering that the spam is currently being added manually to the
> existing tickets in our BT,

This has changed. Last week we had a scripted attack on our current tracker.
We are still doing some last cleanups. 
When we got more spam emails, we needed to close the ability to comment on
some issue, now we just closed the ability for a guest to add comments over 
the web. :(

> I think we could also remove that manually, 
> if it was technically possible. Only that the person in charge should
> be informed about each new BT modification by email (that's currently
> impossible in our BT as I was told;

It is possible to get a notification for each transaction for the current 
tracker. I did not consider it a good compromisse so far and advised against 
it. Currently you cannot remove single entries.

> would Gforge tracker provide such option?).

Yes, just as does RequestTracker. 

> I woulnd't mind to be that person. 
>
> Only if there is nobody willing to take care of spam in BT (eg. I quit
> in future) or if the amount of spam making through is beyond a few
> minutes work a day, the anonymous access should be limited. Otherwise
> we should keep the BT system open for anyone if possible.

My fear is that it the situation "it takes a few minutes" will be changing 
rapidly. If someone wants to make a contribution, it will not be asked too 
much to have them register, though I would prefer the other solution.
Your few minutes could be spend on more worthwhile tasks in my opinion.

Bernhard

-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061002/fac3b351/attachment.bin
From bernhard at intevation.de  Mon Oct  2 10:28:04 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon Oct  2 10:28:10 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <20061001141606.GA11899@bartok.itc.it>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>
	<200609291223.52840.bernhard@intevation.de>
	<20061001141606.GA11899@bartok.itc.it>
Message-ID: <200610021028.06050.bernhard@intevation.de>

On Sunday 01 October 2006 16:16, Markus Neteler wrote:
> ... but: we don't have an admin outside of Intevation AFAIK...

True, I have meant superuser rights on the machine.

> (who could also change Harmish to Hamish in RT).

You or Hamish can do that as far as I know.

> I feel that GRASS folks would love to switch the BT now,
> what does Intevation think? Besides the spam problem, we
> basically have the missing patch management problem in RT.

It is fine to start using the Gforge Tracker of wald.intevation.org now
for GRASS. We need a migration policy of course.
And the decision how many project for GRASS we want to register on wald.
Should we seperate grass-windows or grass-doc or not?
My feeling is: We do not want to seperate, yet.

For phase a) we would only enter new issues in the gforge tracker 
and keep the old tracker. 
Also possible: If an issue is acted upon, transfer if to the tracker.

Next we need a script to transfer the 500 open issues to the new tracker.
Also there is the decision of where to archive the handled issues.
My suggestion would be to keep the request-tracker running for documentation
purposes.

Bernhard


-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061002/c9fad196/attachment.bin
From bernhard at intevation.de  Mon Oct  2 10:32:03 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Mon Oct  2 10:32:08 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <20060928202701.17c4ac7e.hamish_nospam@yahoo.com>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>
	<20060928070904.GA29414@bartok.itc.it>
	<20060928202701.17c4ac7e.hamish_nospam@yahoo.com>
Message-ID: <200610021032.04703.bernhard@intevation.de>

On Thursday 28 September 2006 10:27, Hamish wrote:
> I guess the sooner we migrate to the new bug tracker the better then.
> After that we can start on CVS->SVN 

As said before: Intevation offers the wald.intevation.org infrastructure
which is a gforge software and has SVN. 
We just need to plan and execute the 

> and OSGeo migrations ;) 

I have not been following all of their decisions.
My suggestion for GRASS would be to stay on its own infrastructure
and own legal entities as GRASS is big enough to actually profit
from it.

Bernhard

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061002/660ffb76/attachment.bin
From hamish_nospam at yahoo.com  Mon Oct  2 10:37:04 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 10:38:01 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <C144AD5E.F3FA%michael.barton@asu.edu>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
Message-ID: <20061002213704.64212af2.hamish_nospam@yahoo.com>

Michael Barton wrote:
> Zooming in with a zoom box is pretty straight forward. But zooming out
> is conceptually and computationally somewhat more complex, and is done
> in various ways (or not at all) in other graphics/GIS programs.
> 
> After working off list on various approaches to zooming out with a
> zoom box, I want to give you all several alternative proposals and let
> you vote on them. It gives us a chance to try out the voting
> procedure. I think that we?d said that we?d have 2 or 3 days. Since
> it?s the weekend, I?ll take votes through Tuesday Arizona time

two points re voting. a) IMO 2-3 days is too short, 4-5 days is a better
compromise between non-stalling & inclusiveness b) I really hope that
any formal voting proceedure doesn't stop anyone who doesn't vote from
speaking up if they have an opinion or new idea.


> Vote for options (I?m willing to do either 1a/b or 2a/b, and
> personally favor variants 1a or 2a):
> 
> 1a: 1+
> 1b: 0+
> 2a: 1+
> 2b: 0+
> 3:  1-


write in vote: option 4.   (call it 3b if you want)


> 3. The box causes the the display to zoom out, but either does not
> control the amount of zoom out (e.g., region is extended by some set
> amount) or doesn?t control the region geometry (e.g., the display
> window controls the geometry regardless of the shape of the zoom out
> box).
> 
> Issues: I see no point in going to the trouble of coding a zoom box if
> it doesn?t give a user control over the region extents (i.e., both the
> amount of zoom and the resulting region geometry). We already have a
> nice quick, 1-click zoom in and zoom out that I?ve cleaned up a bit
> more over what is now in the cvs.


4. No zoom out by box. Zoom out click (right click from zoom-in?)
zooms out by a factor of 2 or sqrt(2) [or something in between].
New region is centered on location of the click. bounds change but
resolution is preserved.


A couple problems with zoom out by box:

 - it's friggin confusing for us to decide what it means, think of how
the user will cope.

 - it's easy to try and single-click to zoom out, but actually draw a
1x1 pixel box, and zoom out like mad. I *always* do this when using
software with zoom-out by box and it drives me nuts.

 - conceptually you are drawing a box on the window glass, and ignoring
what's behind the glass [ie imagine what the new map will look like in
real time, then draw your box on that mental projection after rescaling
and placing the current display map in your head...]. This is a totally
different place to put your brain vs. zooming in where you are using a
direct god's eye view. When quickly zooming in+out to get just the right
area this duality makes your head spin, or at least slow you down when
you jump the groove.


I can see the advantage of using a zoom-out box if you want to ever so
slightly zoom out, but the click to zoom-out by sqrt(2), and redoing a
zoom-in box ain't so bad.


I argue for the right click to unzoom when in zoom-in mode for speed
to final result. (probably in addition to a formal zoom-out button)

e.g.

- left click zooms in by 2 or sqrt(2) immediately
- left click drag zooms in to box, highlights box but doesn't zoom yet
   (gives you a chance to try again)
- middle click accepts highlighted zoom-in box & redraws
- left or right button click while highlight box is up cancels the box
   and does nothing to the zoom (escape route)
  left click drag draws a new box
- right click zooms out by 2 or sqrt(2)


now you may be thinking this is as confusing as the current xmon
prompts, but those not in the know can still click to zoom in/out.

keyboard click for zoom-out ain't so bad for 1 button applers.
keyboard clicks for zoom-in box is not intuitive for applers, but not
 disabling as single click to zoom still works. but it kinda sucks.
 ("gis requires at least 3 buttons. spend the $10. not long ago GIS
   digitizing pallets were 4-12 buttons")
 Photoshop's authors probably have the same UI nightmares on Mac.


without getting into platform wars, I always saw the single button mac
mouse more as a way to force developers to come up with easy to use
interfaces (like now), but much less useful for a user. We have 5
fingers after all, and know how to use them to do different things.
All users win a lot in the forced good design with a single button mac,
but the power user is slowed down some. This doesn't mean a 3 button
mouse is bad to use!


2c,
Hamish

From hamish_nospam at yahoo.com  Mon Oct  2 10:55:09 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  2 10:55:21 2006
Subject: [GRASS-dev] remove(dir) fails on Windows
In-Reply-To: <340505ef0609220809r28353869s11d0eeb3863e084e@mail.gmail.com>
References: <340505ef0609220809r28353869s11d0eeb3863e084e@mail.gmail.com>
Message-ID: <20061002215509.6dc71f99.hamish_nospam@yahoo.com>

Radim Blazek wrote:
> Hi.
> remove() directory fails on Windows so that vectors cannot be deleted
> without error. Patch for lib/vector/Vlib/map.c is attached.
> IMPORTANT!

done for both HEAD & 6.2.0 branch.



Hamish

From neteler at itc.it  Mon Oct  2 12:03:34 2006
From: neteler at itc.it (Markus Neteler)
Date: Mon Oct  2 12:03:35 2006
Subject: [GRASS-dev] spam in bug tracker
In-Reply-To: <200610021028.06050.bernhard@intevation.de>
References: <mailman.395.1159427020.2649.grass-dev@grass.itc.it>
	<200609291223.52840.bernhard@intevation.de>
	<20061001141606.GA11899@bartok.itc.it>
	<200610021028.06050.bernhard@intevation.de>
Message-ID: <20061002100334.GB18791@bartok.itc.it>

On Mon, Oct 02, 2006 at 10:28:04AM +0200, Bernhard Reiter wrote:
> On Sunday 01 October 2006 16:16, Markus Neteler wrote:
> > ... but: we don't have an admin outside of Intevation AFAIK...
> 
> True, I have meant superuser rights on the machine.
> 
> > (who could also change Harmish to Hamish in RT).
> 
> You or Hamish can do that as far as I know.

I tried, I cannot...
While I am listed as admin, I don't seem to have admin
rights :-) (which is ok).
 
> > I feel that GRASS folks would love to switch the BT now,
> > what does Intevation think? Besides the spam problem, we
> > basically have the missing patch management problem in RT.
> 
> It is fine to start using the Gforge Tracker of wald.intevation.org now
> for GRASS. We need a migration policy of course.
> And the decision how many project for GRASS we want to register on wald.
> Should we seperate grass-windows or grass-doc or not?
> My feeling is: We do not want to seperate, yet.

I agree.

> For phase a) we would only enter new issues in the gforge tracker 
> and keep the old tracker.
> Also possible: If an issue is acted upon, transfer if to the tracker.

This sounds very good to me.

> Next we need a script to transfer the 500 open issues to the new tracker.
> Also there is the decision of where to archive the handled issues.
> My suggestion would be to keep the request-tracker running for documentation
> purposes.

Also agreed.

Markus

From neteler at itc.it  Mon Oct  2 12:07:39 2006
From: neteler at itc.it (Markus Neteler)
Date: Mon Oct  2 12:07:41 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <20061002183836.1f3596c6.hamish_nospam@yahoo.com>
References: <0E5A77B55A57D511BB3F0002A537C26208C55B86@s5-dar-r1.nrn.nrcan.gc.ca>
	<20061002183836.1f3596c6.hamish_nospam@yahoo.com>
Message-ID: <20061002100739.GC18791@bartok.itc.it>

On Mon, Oct 02, 2006 at 06:38:36PM +1300, Hamish wrote:
> Eric wrote:
> 
> > Borrowing heavily from my conversations with Maciek, I have written a
> > step-by-step how-to for improving Grass documentation, specifically
> > man pages. I welcome any feedback and suggestions for improvement. My
> > knowledge of html is pretty basic, hopefully there aren't too many
> > errors. It looks OK to me in Firefox. I was thinking perhaps this page
> > could be linked/inserted into the main Grass GDP page, so it can be
> > easily found for those who are interested in improving the
> > documentation. 
> 
> 
> Glad to see this, sometimes with GRASS development I think (like GIS)
> often the answers are simple to find & easy to enact, *if you know where
> to look* before you start looking. This sort of tutorial goes a long way
> to fixing that problem. Can you put this up on the wiki? (probably in
> the development section)

Yes, please put it onto the Wiki.
The current CVS approach of maintaining the Web pages doesn't scale
up at all.

> The sooner the GDP is migrated out of the web
> site CVS and into the wiki and truely group maintained the better for
> everyone IMO.  [ps. -- is the wiki being backed up?

Yes, backup'ed.

> available as .zip
> for burning to a CD for access to help when in the field?]

Nice to have. How to implement it?

A related consideration:
Should we move to a Content Management System like Drupal or
Joomla? If yes, will folks participate to migrate the Web
site contents? The only major problem is how to feed the
mirror sites (make a static copy overnight and rsync that?).

Markus

From neteler at itc.it  Mon Oct  2 12:08:50 2006
From: neteler at itc.it (Markus Neteler)
Date: Mon Oct  2 12:08:52 2006
Subject: [GRASS-dev] GIF -> PNG
In-Reply-To: <20061002152650.2623993a.hamish_nospam@yahoo.com>
References: <340505ef0609220525g7dc366e0re2a6ca623f83b0ec@mail.gmail.com>
	<20060922150853.GA6624@bartok.itc.it>
	<20060927223608.4ee9269d.hamish_nospam@yahoo.com>
	<451A9CF5.4020001@itc.it> <20060929210435.GA7926@bartok.itc.it>
	<20061002152650.2623993a.hamish_nospam@yahoo.com>
Message-ID: <20061002100850.GD18791@bartok.itc.it>

On Mon, Oct 02, 2006 at 03:26:50PM +1300, Hamish wrote:
> > > > For the record, TclTk doesn't like PNG. e.g. the NVIZ help browser
> > > > won't load PNG help graphics in the nviz man pages.
> > >
> > > Cool :-(
> > > We should change the NVIZ help browser to the standard HTML browser.
> > > The limited tcltk based browser isn't that fancy at all.
> ..
> > Done (startup GUI) & done (nviz). Also for 6.2-release branch.
> > Any other places?
> 
> $ grep -rI help.tcl * | grep -v locale/po | cut -f1 -d: | uniq
> 
> No, only those two used it.
> 
> If we remove GRASS's visualization/nviz/html/help.tcl web browser,
> that's 120k less source to distribute!

please go ahead :-) 
 
> > Please test...
> 
> with this set in ~/.grass.bashrc:
>   export GRASS_HTML_BROWSER=dillo
> it works fine from NVIZ, but the startup GUI defaults to using klunky
> old mozilla as .grass.bashrc hasn't been sourced yet(?). Also is there
> any way to get rid of or minimize the residual xterm window?

I observed the same problem but have no idea.

Markus

From neteler at itc.it  Mon Oct  2 12:11:38 2006
From: neteler at itc.it (Markus Neteler)
Date: Mon Oct  2 12:11:40 2006
Subject: [GRASS-dev] [bug #5161] v.digit: no toolbox if Grass 6.3 built
	with tcl/tk 8.3
In-Reply-To: <20061001201956.205dc830.hamish_nospam@yahoo.com>
References: <20060929223359.083fe269.hamish_nospam@yahoo.com>
	<C14280D2.F310%michael.barton@asu.edu>
	<20061001201956.205dc830.hamish_nospam@yahoo.com>
Message-ID: <20061002101138.GF18791@bartok.itc.it>

On Sun, Oct 01, 2006 at 08:19:56PM +1300, Hamish wrote:
> Michael Barton wrote:
> > Bwidget LabelFrame (note capitalization) might work as a substitute.
> > There has to be some kind of bwidget sourcing to make it work. If it's
> > just one function call, it would be easy. But from past reports, it's
> > not just one call in nviz, but includes other things as well.
> 
> For v.digit, it seems to be just that one line. (infact all of GRASS,
> AFAIK)

Please submit it to CVS, I would like to speed up with the 6.2.0
release (will be away for a while soon).

Markus

From grass-bugs at intevation.de  Mon Oct  2 13:01:21 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Mon Oct  2 13:01:23 2006
Subject: [GRASS-dev] [bug #5179] (grass) d.m: env(GISBASE) - no such variable
Message-ID: <20061002110121.DDB9C1005C3@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5179
-------------------------------------------------------------------------

Subject: d.m: env(GISBASE) - no such variable

6.3 CVS, tcl/tk 8.4, Ubuntu Dapper x86.

Pressing "show attribute columns" or "show data" button in d.m yields an error:


can't read "env(GISBASE)": no such variable
can't read "env(GISBASE)": no such variable
    while executing
"exec $env(GISBASE)/etc/grass-xterm-wrapper -bg $bgcolor -title "$mapname
data"  -geometry 60x40-10+30 -sb -hold -e db.select table=$mapname &"
    (procedure "DmVector::show_data" line 5)
    invoked from within
"DmVector::show_data 1"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Button::_release" line 18)
    invoked from within
"Button::_release .mainframe.frame.pw2.f1.frame.sw.sf.frame.fr.columns.d"
    (command bound to event)

Maciek


-------------------------------------------- Managed by Request Tracker

From tlaronde at polynum.com  Mon Oct  2 13:22:01 2006
From: tlaronde at polynum.com (tlaronde@polynum.com)
Date: Mon Oct  2 13:19:10 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061002213704.64212af2.hamish_nospam@yahoo.com>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
	<20061002213704.64212af2.hamish_nospam@yahoo.com>
Message-ID: <20061002112201.GA912@polynum.com>

[No, I don't vote, but since I'm still reading the mailing
list---usefull at least to compare my options with yours or to pick up
good ideas---I just give the following information]

On Mon, Oct 02, 2006 at 09:37:04PM +1300, Hamish wrote:
> 
> 4. No zoom out by box. Zoom out click (right click from zoom-in?)
> zooms out by a factor of 2 or sqrt(2) [or something in between].
> New region is centered on location of the click. bounds change but
> resolution is preserved.
> 

FWIW, in the original v.digit(1) (and present in the KerGIS version)
was the "widen window" option. It's zooming out by displaying a color
rectangle representing the whole map with a rectangle wire locating the
current window. Then you only select another window knowing both the
whole extend, and where you were before.
It's far more handy, since it's simpler to zoom out loosely, and then
zoom in precisely.

I didn't understand why this was nuked in GPL GRASS version.

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

From grass-bugs at intevation.de  Mon Oct  2 13:22:21 2006
From: grass-bugs at intevation.de (Maciek Sieczka via RT)
Date: Mon Oct  2 13:22:24 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full path
	to dsn is missing
Message-ID: <20061002112221.1D3331005C3@lists.intevation.de>

Hamish wrote:

> v.in.ogr dsn=force_lrconnect_cl_onlycat139.shp
> does it work then?

No. It can't. Because force_lrconnect_cl_onlycat139.shp is in
$HOME/dsn=force_lrconnect_cl_onlycat139

> what if you change the dir name to something not the same as the filename?

Good guess! It works then:

$ mv force_lrconnect_cl_onlycat139 shorter
$ v.in.ogr dsn=shorter/ output=force_lrconnect_cl_onlycat139
layer=force_lrconnect_cl_onlycat139
(no segfault, shape imports fine)

But funny thing is that same command that segfaults in my location:

$ vin.ogr dsn=force_lrconnect_cl_onlycat139/
output=force_lrconnect_cl_onlycat139_import layer=force_lrconnect_cl_onlycat139

works fine in spearfish!, if projection check is -o(verrided) of course.


That made we wonder whether it would also work in my location if I use the -o
flag there as well - but still v.in.ogr segfaults even though. Hmm.

Maciek


-------------------------------------------- Managed by Request Tracker

From tutey at o2.pl  Mon Oct  2 13:43:53 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Mon Oct  2 13:43:58 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full
	path	to dsn is missing
In-Reply-To: <20061002112221.1D3331005C3@lists.intevation.de>
References: <20061002112221.1D3331005C3@lists.intevation.de>
Message-ID: <4520FB79.8000208@o2.pl>

Maciek Sieczka via RT wrote:
> Hamish wrote:

>> v.in.ogr dsn=force_lrconnect_cl_onlycat139.shp
>> does it work then?

> No. It can't. Because force_lrconnect_cl_onlycat139.shp is in
> $HOME/dsn=force_lrconnect_cl_onlycat139

Correction: the last line above should read:

> $HOME/force_lrconnect_cl_onlycat139/

Maciek

From tutey at o2.pl  Mon Oct  2 14:24:22 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Mon Oct  2 14:24:27 2006
Subject: [GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??
In-Reply-To: <20061002012404.885D61005D8@lists.intevation.de>
References: <20061002012404.885D61005D8@lists.intevation.de>
Message-ID: <452104F6.7070101@o2.pl>

Hi Hamish,

Thanks for working on this bug!

I have tried your recent patch you sent.

It improves things a bit, but doesn't solve the bug yet. See the
attached screndumps. These are xcf files, so you extract the v.buffer
syntax used from them.

As you can see the 4m (buf4.xcf) buffer of my ditches looks kindoff
better - there is no single bulge now, but a buffered ditch. The
problems are that the buffer width is not 4m as declared, but circa 1m
and there is a half-bulge on the left side and some artifact at the
top-left.

In case of the 1m buffer (buf1.xcf) there is no change at all when
compared to the previous result.

If you still have the sample Grass location (vbuffer_bugs) I sent you
please try reproducing these.

Maciek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v_buffer_hamishfixes.tar.bz2
Type: application/x-bzip
Size: 10862 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061002/d4575852/v_buffer_hamishfixes.tar-0001.bin
From grass-bugs at intevation.de  Mon Oct  2 14:26:06 2006
From: grass-bugs at intevation.de (Markus Neteler via RT)
Date: Mon Oct  2 14:26:08 2006
Subject: [GRASS-dev] [bug #5179] (grass) d.m: env(GISBASE) - no such variable
Message-ID: <20061002122606.173CD1005C3@lists.intevation.de>

Hi,

I have fixed that in CVS (also for 6.2). Now the results
are shown in the panel (such as for gis.m) and the xterm
wrapper is no longer used here.

Markus

-------------------------------------------- Managed by Request Tracker

From epatton at nrcan.gc.ca  Mon Oct  2 14:49:27 2006
From: epatton at nrcan.gc.ca (Patton, Eric)
Date: Mon Oct  2 14:49:31 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55BB4@s5-dar-r1.nrn.nrcan.gc.ca>

-----Original Message-----
From: Hamish
To: Patton, Eric
Cc: grass-dev@grass.itc.it
Sent: 10/2/2006 1:38 AM
Subject: Re: [GRASS-dev] Grass Documentation How-to html page

Eric wrote:
>> Borrowing heavily from my conversations with Maciek, I have written a
>> step-by-step how-to for improving Grass documentation

Hamish:
>Glad to see this, sometimes with GRASS development I think (like GIS)
>often the answers are simple to find & easy to enact, *if you know where
>to look* before you start looking. This sort of tutorial goes a long way
>to fixing that problem. 

Thanks.

Hmaish:
>Can you put this up on the wiki? (probably in the development section)

Sure.

Hamish:
>Add a link to help page translation efforts?

Sure.

Hamish:
>link to the CVS web interface, or write a script to pluck the latest
>description.html file for any given module. (aim for really low barrier
>to entry) Little html experience is needed.

I thought I had included a link to the CVS how-to :

"To begin, you must obtain the latest Grass source code from the CVS
repositories. Detailed instructions on how to do so can be found <a
href:"http://grass.itc.it/faq/cvs_howto">here.</a>"

But I think I got the formatting wrong, because this link is broken; it just
links back to itself. Actually, all the html links don't work. Can you see
anything obviously wrong?

Hamish:
>Note how to add images. (r.terraflow, v.voronoi,...)
>see doc/html_documentation.txt

Ok, I'll have to brush up on how to do this, as I've never tried it yet.

Eric:
>> Once you have downloaded the CVS source code, open a terminal and
>> change directory to /your_cvs_directory/grass6/vector/v.in.ascii. You
>> have to make your edits/corrections to the original copy of the
>> module's description.html page within grass6/vector/v.in.ascii, not a
>> copy of this page.
>> Open a text editor and make your edits to description.html. Depending
>> on where your cvs source is on disk, you may have to do so as root
>> (Ex: sudo gedit description.html). Save your edits by overwriting the
>> original description.html.

Hamish:
>There's no reason you can't make a copy and work from that, and no
>reason you have to be root. T "cvs diff" may no longer work, but that's not
the end of the
>world if you hung on to the original.

Maciek had advised me to make diffs from the original description html,
because I had tried diffing a copy of a manpage somewhere in /home, and he
had problems applying it to CVS. (?) I'm not sure why it didn't work, just
following suggestions. I'll CC: him on this to see why.

Hamish:
>The CVS source doesn't need to have any superuser access, it's proably very
good advice that >it isn't given such rights.

My cvs source is located in /opt, where my Grass installation folder is
located, so that's probably why I wrote that. I'll modify that to include
your suggestions.

Hamish:
>If editing in the source tree is a problem, just make a copy of the file
>and:

>diff -u /usr/src/grass/.../description.html description.html.NEW

I think this was what I tried originally with Maciek, where we ran into
problems. Not sure. Aanyway, I'll change the how-to to mention that one copy
any description.html into a safe place like /home, make edits, then create a
diff -u against their source description.html - sound good?

Thanks for the feedback,

~ Eric.

From michael.barton at asu.edu  Mon Oct  2 16:32:17 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Oct  2 16:32:21 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061002213704.64212af2.hamish_nospam@yahoo.com>
Message-ID: <C1467101.F469%michael.barton@asu.edu>

This already exists. No need to right click. Just select zoom out tool and
click. The centering is already done and will go into the cvs as soon as the
box algorithm is decided.

People have already talked a lot on zooming and I'm sure they will some
more. The other points you raise about middle and right clicking, for
example, were discussed a lot a few months back and I'm certain they will
come up again. There's no way to restrict such discussion, even if someone
wanted to ;-)

However, the idea of voting (I thought) was to actually make a decision and
move on--at least for the nonce.

I have no trouble about extending the voting, especially for momentous
decisions like this :-). I was just trying to remember what the previous
discussions suggested. Also, I was (selfishly) looking at my personal
schedule to see when I could squeeze in getting this into the cvs.

Let's go through Wednesday.

Cheers
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam@yahoo.com>
> Date: Mon, 2 Oct 2006 21:37:04 +1300
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] Vote for your favorite zoom out
> 
> 4. No zoom out by box. Zoom out click (right click from zoom-in?)
> zooms out by a factor of 2 or sqrt(2) [or something in between].
> New region is centered on location of the click. bounds change but
> resolution is preserved.
> 

From jachym.cepicky at centrum.cz  Mon Oct  2 19:56:11 2006
From: jachym.cepicky at centrum.cz (Jachym Cepicky)
Date: Mon Oct  2 19:56:19 2006
Subject: [GRASS-dev] making g.remove less verbose
In-Reply-To: <17693.21171.547598.902496@cerise.gclements.plus.com>
References: <20060928114622.GA7000@localdomain>
	<C1414A95.250D9%michael.barton@asu.edu>
	<17693.21171.547598.902496@cerise.gclements.plus.com>
Message-ID: <20061002175610.GC11600@localdomain>

hallo,

On Fri, Sep 29, 2006 at 06:06:59PM +0100, Glynn Clements wrote:
> 
> Michael Barton wrote:
> 
> > Relevant to discussions about the r.mask script. Is what Jachym is doing a
> > way to provide a user checkbox in the GUI for overwriting the earlier map
> > but not give confusion with the global --o overwrite flag?
> > 
> > That is, use -f for "force replacement of old mask with new"
> 
> No. The specific issue here is that g.remove currently won't let you
> remove a map which is known to be the base map for one or more reclass
> maps. It prints a warning telling you to remove the reclass maps
> first.
> 
> This is a problem if the reclass maps belong to another user.
> 
> The proposed -f switch to g.remove allows you to override the warning
> and remove the map anyway (with the consequence that the reclass maps
> won't work because they refer to a base map which no longer exists).
> 
> -- 
> Glynn Clements <glynn@gclements.plus.com>

if i understand this well, nobody is really protesting against this
    patch, so i commited it.

g.remove --help

...
    -f Force remove
...

jachym

-- 
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
Department of Geoinformation Technologies 
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL:    http://mapserver.mendelu.cz
Tel.:   +420 545 134 514
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061002/be60f8e8/attachment.bin
From glynn at gclements.plus.com  Mon Oct  2 20:10:39 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  2 20:10:42 2006
Subject: [GRASS-dev] r.resamp.aggregate, trimmed means
In-Reply-To: <20061002145509.32d9bab8.hamish_nospam@yahoo.com>
References: <20061002145509.32d9bab8.hamish_nospam@yahoo.com>
Message-ID: <17697.22047.593840.84908@cerise.gclements.plus.com>


Hamish wrote:

> > > > Can we make a decision as to the official name of this module?
> > > 
> > > how about r.resamp.bin? (as in binning, not binary)
> > > 
> > > If r.resamp.aggregate is used, I'd vote for using the full word.
> > > I don't think "aggregate" abreviates well.
> > >
> > > by the way, what is this module?
> >
> > It's a resampling module where the value of the output cell is an
> > aggregate (mean, median, mode, min, max etc) of the values from all of
> > the input cells whose centres lie within the bounds of the output
> > cell.
> 
> Hey, that is pretty neat. I can see it being useful for sub-sampling
> noisy imagery data with low signal:noise (but > 50%) using a median
> filter.
> 
> Do we have a way to do a trimmed mean? (eg mean of values between perc10
> and perc90; replace 10% with 5% or x%, or 2 Stdevs, etc..) I've always
> liked it as a nice compromise between the outlier-discarding ability of
> the median and the less arbitrary nature of the mean.
> I'd like to have this in r.univar and r.series* too... :)

r.resamp.stats currently supports:

	{c_ave,    "average",   "average (mean) value"},
	{c_median, "median",    "median value"},
	{c_mode,   "mode",      "most frequently occuring value"},
	{c_min,    "minimum",   "lowest value"},
	{c_max,    "maximum",   "highest value"},
	{c_quart1, "quart1",    "first quartile"},
	{c_quart3, "quart3",    "third quartile"},
	{c_perc90, "perc90",    "ninetieth percentile"},

This list is essentially all of the aggregates from lib/stats where
the result is "representative" of the inputs (where the result is a
value within the range covered by the inputs, i.e. not variance,
stddev etc) and which don't depend upon the order of the inputs (e.g. 
the linear regression aggregates).

If additional aggregates are added to lib/stats, it's straightforward
to extend r.resamp.stats and/or r.series to support the new
aggregates.

The design of lib/stats isn't practical for modules which compute
aggregates over a large number of samples (e.g. r.statistics), as the
aggregates require the entire set of values to be passed as a single
array.

The main deficiency at present is that it doesn't support aggregates
with parameters, e.g. you can't have a generic "percentile" aggregate
where the percentile is specified as a parameter.

For more complex aggregates (e.g. a trimmed mean), this is likely to
be a significant deficiency. As it stands, "trimmed mean between 10%
and 90%" would be one aggregate, "trimmed mean between +/- 2 sigma"
would be another, etc.

It would be simple enough to add a "const char *parms" argument to the
aggregates, allowing an arbitrary set of parameters to be passed as a
string (similar to PROJ projection parameters).

A more structured approach, where the aggregates declare their
parameters, would be preferable, as this would allow the library
and/or module to handle validation and parsing. But that needs to be
designed before it can be implemented, and requiring a design for
something usually equates to "kicking it into the long grass"
(grass/GRASS pun not intended, although probably appropriate).

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Oct  2 20:37:26 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  2 20:38:52 2006
Subject: [GRASS-dev] r.random still broken on Mac
In-Reply-To: <79F72A99-AFC5-4963-8668-AFBA7F3E3A2E@kyngchaos.com>
References: <C1403A8C.25012%michael.barton@asu.edu>
	<17692.1097.409484.178701@cerise.gclements.plus.com>
	<A3DEEFA8-1BC5-4C6E-B6B7-AD3A0E2135B0@kyngchaos.com>
	<9560F255-7A6B-43DA-8B3C-CE3C8199BB54@kyngchaos.com>
	<17693.23534.45307.786393@cerise.gclements.plus.com>
	<79F72A99-AFC5-4963-8668-AFBA7F3E3A2E@kyngchaos.com>
Message-ID: <17697.23654.292502.347419@cerise.gclements.plus.com>


William Kyngesburye wrote:

> >> I just did a quick test - removed __APPLE__ from r.random, so it uses
> >> the extern lrand48.  I now get a random distribution.
> >
> > So it's the fake lrand48() that's causing problems?
> >
> > Doh.
> >
> ...
> 
> > Can you try this instead:
> >
> > #define lrand48() (((long) rand() ^ ((long) rand() << 16)) & 0x7FFFFFFF)
> >
> That works.

OK, I'll use that as the fallback.

> So, was there some other reason to use the fake lrand48() on OS X,  
> since the real one seems to work?

Presumably it wasn't always available. It was originally only used for
Cygwin, but OSX was added in:

	revision 1.2
	date: 2000/12/11 13:35:14;  author: markus;  state: Exp;  lines: +1 -1
	added MacOS X/drand sensivity

This was then followed by changes to the name of the macro:

	revision 1.3
	date: 2000/12/12 09:02:19;  author: markus;  state: Exp;  lines: +1 -1
	changed __MAC_OS_X__ to __MAC_OS (next try)

	revision 1.4
	date: 2001/01/26 12:45:43;  author: markus;  state: Exp;  lines: +1 -1
	changed defined(__MAC_OS_X__) to defined(__APPLE__)

Also, note that lrand48() isn't available if you use -ansi unless you
specifically enable it with e.g. -D_SVID_SOURCE or -D_XOPEN_SOURCE. 
This is part of the reason why platform tests should be avoided.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Oct  2 20:53:48 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  2 20:53:50 2006
Subject: [GRASS-dev] GIF -> PNG
In-Reply-To: <20061002152650.2623993a.hamish_nospam@yahoo.com>
References: <340505ef0609220525g7dc366e0re2a6ca623f83b0ec@mail.gmail.com>
	<20060922150853.GA6624@bartok.itc.it>
	<20060927223608.4ee9269d.hamish_nospam@yahoo.com>
	<451A9CF5.4020001@itc.it> <20060929210435.GA7926@bartok.itc.it>
	<20061002152650.2623993a.hamish_nospam@yahoo.com>
Message-ID: <17697.24636.440943.573933@cerise.gclements.plus.com>


Hamish wrote:

> with this set in ~/.grass.bashrc:
>   export GRASS_HTML_BROWSER=dillo
> it works fine from NVIZ, but the startup GUI defaults to using klunky
> old mozilla as .grass.bashrc hasn't been sourced yet(?).

You can always set it in your normal ~/.bash_profile etc.

> Also is there
> any way to get rid of or minimize the residual xterm window?

Yes; just don't use an xterm, i.e. change:

	exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e $env(GRASS_HTML_BROWSER) \
	file://$env(GISBASE)/docs/html/helptext.html >@stdout 2>@stderr &;
to:
	exec -- $env(GRASS_HTML_BROWSER) \
	file://$env(GISBASE)/docs/html/helptext.html >@stdout 2>@stderr &;

I don't see why an xterm should be necessary. If you want to use
lynx/links, you can set GRASS_HTML_BROWSER to a script which starts
lynx/links in an xterm, e.g.:

	#!/bin/sh
	exec xterm -e lynx "$@"

-- 
Glynn Clements <glynn@gclements.plus.com>

From tutey at o2.pl  Mon Oct  2 21:10:05 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Mon Oct  2 21:10:10 2006
Subject: [GRASS-dev] v.clean tool=prune - 'thresh' interpreted wrong?
Message-ID: <4521640D.3030308@o2.pl>

There is a line:

	$ echo "L 4 1
	 10 10
	 20 10
	 30 10
	 40 10
	 1     1" | v.in.ascii -n out=line format=standard


So there are 4 vertices and the distance between each 2 following is
10. Then I don't understand why the:

	$ v.clean input=line output=line_pruned type=line tool=prune
	thresh=1

removes ALL the vertices!:

	$ v.out.ascii line_pruned format=standard
	ORGANIZATION:
	DIGIT DATE:
	DIGIT NAME:   shoofi
	MAP NAME:
	MAP DATE:     Mon Oct  2 20:51:52 2006
	MAP SCALE:    1
	OTHER INFO:
	ZONE:         0
	MAP THRESH:   0.000000
	VERTI:
	L  2 1
	 10           10
	 40           10	   <- WHY ARE THE TWO OTHER GONE ???
	 1     1


I declared thresh=1, the distance between vertices is 10 - so none
should be removed, but all are! And the same happens with all the lower
thresholds until thresh=0.03.

???

v.clean man says: "prune: remove vertices in threshold". Maybe I don't
understand what the threshold means in this case?

Maciek

P.S.

Any clarification will be highly appreciated. I've been writing a
script that uses pruning and I would like to publish it, but this is
puzzling me bad and I don't know whether it's a bug or my mistake. Thanks.

From neteler at itc.it  Mon Oct  2 22:17:13 2006
From: neteler at itc.it (Markus Neteler)
Date: Mon Oct  2 22:17:15 2006
Subject: [GRASS-dev] GIF -> PNG
In-Reply-To: <17697.24636.440943.573933@cerise.gclements.plus.com>
References: <340505ef0609220525g7dc366e0re2a6ca623f83b0ec@mail.gmail.com>
	<20060922150853.GA6624@bartok.itc.it>
	<20060927223608.4ee9269d.hamish_nospam@yahoo.com>
	<451A9CF5.4020001@itc.it> <20060929210435.GA7926@bartok.itc.it>
	<20061002152650.2623993a.hamish_nospam@yahoo.com>
	<17697.24636.440943.573933@cerise.gclements.plus.com>
Message-ID: <20061002201713.GA21531@bartok.itc.it>

On Mon, Oct 02, 2006 at 07:53:48PM +0100, Glynn Clements wrote:
> 
> Hamish wrote:
> 
> > with this set in ~/.grass.bashrc:
> >   export GRASS_HTML_BROWSER=dillo
> > it works fine from NVIZ, but the startup GUI defaults to using klunky
> > old mozilla as .grass.bashrc hasn't been sourced yet(?).
> 
> You can always set it in your normal ~/.bash_profile etc.
> 
> > Also is there
> > any way to get rid of or minimize the residual xterm window?
> 
> Yes; just don't use an xterm, i.e. change:
> 
> 	exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e $env(GRASS_HTML_BROWSER) \
> 	file://$env(GISBASE)/docs/html/helptext.html >@stdout 2>@stderr &;
> to:
> 	exec -- $env(GRASS_HTML_BROWSER) \
> 	file://$env(GISBASE)/docs/html/helptext.html >@stdout 2>@stderr &;

thanks, fixed (also 6.2).

Markus
 

From grass-bugs at intevation.de  Mon Oct  2 22:20:12 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Mon Oct  2 22:20:13 2006
Subject: [GRASS-dev] [bug #5182] (grass) parser: allows for '@' in map names
Message-ID: <20061002202012.07F8E1005CE@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5182
-------------------------------------------------------------------------

Subject: parser: allows for '@' in map names

1. A command that creates a vector map:

$ v.random out=map1@bogus n=10
$ g.list vect
----------------------------------------------
vector files available in mapset breach:
map1@bogus

It works, but it shouldn't. You can't do anything with the vector created, not
even remove it:

$ g.remove vect=map1@bogus
G__open(r): mapset (breach) doesn't match xmapset (bogus)
ERROR: Vector map <map1@bogus> not found



2. A command that creates a vector and a table:

$ v.mkgrid map=map2@bogus grid=1,1 position=region
dbmi: Protocol error
ERROR: Cannot create table: create table map2@bogus ( cat integer, row
       integer, col integer, rown varchar(1), coln varchar(1))

Vector is created though, in error.



3. Creating rasters:

$ r.random.cells dist=1 out=map3@bogus
WARNING: opencell: map3@bogus - bad mapset
ERROR: r.random.cells: unable to open new raster map [map3@bogus]

The map is not created, but the module attempts to create it, only it fails to
in the very end. While it shouldn't even try creating it.

Maciek


-------------------------------------------- Managed by Request Tracker

From dca.gis at gmail.com  Mon Oct  2 22:33:21 2006
From: dca.gis at gmail.com (Daniel Calvelo)
Date: Mon Oct  2 22:33:24 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <C1467101.F469%michael.barton@asu.edu>
References: <20061002213704.64212af2.hamish_nospam@yahoo.com>
	<C1467101.F469%michael.barton@asu.edu>
Message-ID: <1a486f560610021333n62cd209ag538a67513458bfc@mail.gmail.com>

2a: +1, proviso a boxsize threshold, maybe 2px x 2px in order to
prevent the "zoom out to the whole universe" syndrome

Daniel.

-- 
-- Daniel Calvelo Aros

From grass-bugs at intevation.de  Mon Oct  2 23:48:56 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Mon Oct  2 23:48:58 2006
Subject: [GRASS-dev] [bug #5183] (grass) g.region -a: different number of
	rows if using 'res' or 'nsres' and 'ewres' - though
	res=nsres=ewres=10!
Message-ID: <20061002214856.DE2D91005C3@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5183
-------------------------------------------------------------------------

Subject: g.region -a: different number of rows if using 'res' or 'nsres' and 'ewres' - though res=nsres=ewres=10!

Although the n,s,e,w are equal in both cases, and that res=nsres=ewres=10, the
 number of rows in the resulting regions are different:

$ g.region n=5679000 s=5678670 w=599240 e=599880 res=10 -ag
n=5679000
s=5678670
w=599240
e=599880
nsres=10
ewres=10
rows=33    < !!!
cols=64

$ g.region n=5679000 s=5678670 w=599240 e=599880 nsres=10 ewres=10 -ag
n=5679000
s=5678660
w=599240
e=599880
nsres=10
ewres=10
rows=34    < !!!
cols=64

Please please please fix it before 6.2 release.

Maciek


-------------------------------------------- Managed by Request Tracker

From glynn at gclements.plus.com  Tue Oct  3 03:23:13 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue Oct  3 03:23:21 2006
Subject: [GRASS-dev] r.resamp.aggregate
In-Reply-To: <17690.38722.655423.330727@cerise.gclements.plus.com>
References: <17679.57565.712448.383867@cerise.gclements.plus.com>
	<450FE4E1.90905@o2.pl>
	<Pine.LNX.4.62.0609191402550.6386@agrippa.ukshells.co.uk>
	<20060927223053.39473122.hamish_nospam@yahoo.com>
	<17690.38722.655423.330727@cerise.gclements.plus.com>
Message-ID: <17697.48001.337871.723065@cerise.gclements.plus.com>


Glynn Clements wrote:

> > > Can we make a decision as to the official name of this module?
> > 
> > how about r.resamp.bin? (as in binning, not binary)
> > 
> > If r.resamp.aggregate is used, I'd vote for using the full word.
> > I don't think "aggregate" abreviates well.
> > 
> > by the way, what is this module?
> 
> It's a resampling module where the value of the output cell is an
> aggregate (mean, median, mode, min, max etc) of the values from all of
> the input cells whose centres lie within the bounds of the output
> cell.

In case no-one noticed, this is now in CVS, as r.resamp.stats.

Also, I've extended it (and lib/stats) to support aggregates which are
weighted according to the proportion of the source cell which
intersects the output cell. This is slower, but more accurate if the
output grid isn't aligned to the source grid.

-- 
Glynn Clements <glynn@gclements.plus.com>

From hamish_nospam at yahoo.com  Tue Oct  3 04:00:58 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Oct  3 04:01:23 2006
Subject: [GRASS-dev] GIF -> PNG
In-Reply-To: <17697.24636.440943.573933@cerise.gclements.plus.com>
References: <340505ef0609220525g7dc366e0re2a6ca623f83b0ec@mail.gmail.com>
	<20060922150853.GA6624@bartok.itc.it>
	<20060927223608.4ee9269d.hamish_nospam@yahoo.com>
	<451A9CF5.4020001@itc.it> <20060929210435.GA7926@bartok.itc.it>
	<20061002152650.2623993a.hamish_nospam@yahoo.com>
	<17697.24636.440943.573933@cerise.gclements.plus.com>
Message-ID: <20061003150058.4b534982.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> > with this set in ~/.grass.bashrc:
> >   export GRASS_HTML_BROWSER=dillo
> > it works fine from NVIZ, but the startup GUI defaults to using
> > klunky old mozilla as .grass.bashrc hasn't been sourced yet(?).
> 
> You can always set it in your normal ~/.bash_profile etc.


well yes, but that's sloppy. my thought was: should ~/.grass.[*]rc be
processed earlier, perhaps even in bin.i686-pc-linux-gnu/grass63 ?


Hamish

From hamish_nospam at yahoo.com  Tue Oct  3 04:05:18 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Oct  3 04:05:23 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune - 'thresh'
	interpreted wrong?
In-Reply-To: <4521640D.3030308@o2.pl>
References: <4521640D.3030308@o2.pl>
Message-ID: <20061003150518.7e71c9f1.hamish_nospam@yahoo.com>

Maciej Sieczka wrote:
> There is a line:
> 
> 	$ echo "L 4 1
> 	 10 10
> 	 20 10
> 	 30 10
> 	 40 10
> 	 1     1" | v.in.ascii -n out=line format=standard
> 
> 
> So there are 4 vertices and the distance between each 2 following is
> 10. Then I don't understand why the:
> 
> 	$ v.clean input=line output=line_pruned type=line tool=prune
> 	thresh=1
> 
> removes ALL the vertices!:
> 
> 	$ v.out.ascii line_pruned format=standard
> 	ORGANIZATION:
> 	DIGIT DATE:
> 	DIGIT NAME:   shoofi
> 	MAP NAME:
> 	MAP DATE:     Mon Oct  2 20:51:52 2006
> 	MAP SCALE:    1
> 	OTHER INFO:
> 	ZONE:         0
> 	MAP THRESH:   0.000000
> 	VERTI:
> 	L  2 1
> 	 10           10
> 	 40           10	   <- WHY ARE THE TWO OTHER GONE ???
> 	 1     1
> 
> 
> I declared thresh=1, the distance between vertices is 10 - so none
> should be removed, but all are! And the same happens with all the lower
> thresholds until thresh=0.03.
> 
> ???
> 
> v.clean man says: "prune: remove vertices in threshold". Maybe I don't
> understand what the threshold means in this case?


what if there is some angle between the points? e.g.

G6> v.in.ascii -n out=line format=standard << EOF
L 4 1
 10 10
 20 5
 30 7.5
 40 10
 1  1
EOF


Hamish

From hamish_nospam at yahoo.com  Tue Oct  3 04:08:43 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Oct  3 04:08:48 2006
Subject: [GRASS-dev] [bug #5182] (grass) parser: allows for '@' in map
	names
In-Reply-To: <20061002202012.07F8E1005CE@lists.intevation.de>
References: <20061002202012.07F8E1005CE@lists.intevation.de>
Message-ID: <20061003150843.0ba83af7.hamish_nospam@yahoo.com>

Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5182
> ---------------------------------------------------------------------
> 
> Subject: parser: allows for '@' in map names


G_legal_filename() in lib/gis/legal_name.c needs updating.


see Glynn's comments from last month:
  http://thread.gmane.org/gmane.comp.gis.grass.devel/15033/focus=15042



Hamish

From glynn at gclements.plus.com  Tue Oct  3 05:17:44 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue Oct  3 05:17:47 2006
Subject: [GRASS-dev] [bug #5183] (grass) g.region -a: different number of
	rows if using 'res' or 'nsres' and 'ewres' - though
	res=nsres=ewres=10!
In-Reply-To: <20061002214856.DE2D91005C3@lists.intevation.de>
References: <20061002214856.DE2D91005C3@lists.intevation.de>
Message-ID: <17697.54872.185035.357791@cerise.gclements.plus.com>


Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=5183
> -------------------------------------------------------------------------
> 
> Subject: g.region -a: different number of rows if using 'res' or 'nsres' and 'ewres' - though res=nsres=ewres=10!
> 
> Although the n,s,e,w are equal in both cases, and that res=nsres=ewres=10, the
>  number of rows in the resulting regions are different:
> 
> $ g.region n=5679000 s=5678670 w=599240 e=599880 res=10 -ag
> n=5679000
> s=5678670
> w=599240
> e=599880
> nsres=10
> ewres=10
> rows=33    < !!!
> cols=64
> 
> $ g.region n=5679000 s=5678670 w=599240 e=599880 nsres=10 ewres=10 -ag
> n=5679000
> s=5678660
> w=599240
> e=599880
> nsres=10
> ewres=10
> rows=34    < !!!
> cols=64
> 
> Please please please fix it before 6.2 release.

I've changed it in CVS.

Previously, ewres=/nsres= rounded to an even multiple of the
resolution, whereas res= simply rounded to a multiple.

-- 
Glynn Clements <glynn@gclements.plus.com>

From hamish_nospam at yahoo.com  Tue Oct  3 05:35:51 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Oct  3 05:36:46 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <C1467101.F469%michael.barton@asu.edu>
References: <20061002213704.64212af2.hamish_nospam@yahoo.com>
	<C1467101.F469%michael.barton@asu.edu>
Message-ID: <20061003163551.229a9dcb.hamish_nospam@yahoo.com>

Michael Barton wrote:
> This already exists. No need to right click. Just select zoom out tool
> and click.

A point I was trying to make is that selecting another tool is slow when
the task is zooming in & out to get the region "just right". That's why
I wanted right click zoom-out in addition to the formal zoom out tool.
Optional keyboard shortcuts to tools sort of help but are impossible to
remember.


> There's no way to restrict such discussion, even if someone wanted to
> ;-)

nope, but you can happily ignore the noise & get on with the coding.

We used to have a system at the shop I used to work in- the last person
who turned up in the morning got to pick the radio station for the rest
of the day (the radio was near the coat rack). It worked pretty well.


Hamish

From hamish_nospam at yahoo.com  Tue Oct  3 05:42:25 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Oct  3 05:42:33 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55BB4@s5-dar-r1.nrn.nrcan.gc.ca>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BB4@s5-dar-r1.nrn.nrcan.gc.ca>
Message-ID: <20061003164225.71b4d9fd.hamish_nospam@yahoo.com>

Patton, Eric wrote:
> Maciek had advised me to make diffs from the original description
> html, because I had tried diffing a copy of a manpage somewhere in
> /home, and he had problems applying it to CVS. (?) I'm not sure why it
> didn't work, just following suggestions. I'll CC: him on this to see
> why.

Guess: there are 355 or so files called description.html in the grass
source code. If you move the file out of the module's directory it is
hard for the CVS to know where to put it. Run diff from the top
directory of the source code and then the directory structure (and
module name) are preserved.

My point was more along the lines of the grass source code tree &
compiling can and should be done as a regular user. Only jump to the
superuser to install the finished product. If a script goes wrong during
the compile process much less damage will be done to your system that
way.


Hamish

From michael.barton at asu.edu  Tue Oct  3 05:44:33 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Oct  3 05:44:40 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061003163551.229a9dcb.hamish_nospam@yahoo.com>
Message-ID: <C1472AB1.F530%michael.barton@asu.edu>


> From: Hamish <hamish_nospam@yahoo.com>
> Date: Tue, 3 Oct 2006 16:35:51 +1300
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] Vote for your favorite zoom out
> 
> Michael Barton wrote:
>> This already exists. No need to right click. Just select zoom out tool
>> and click.
> 
> A point I was trying to make is that selecting another tool is slow when
> the task is zooming in & out to get the region "just right". That's why
> I wanted right click zoom-out in addition to the formal zoom out tool.
> Optional keyboard shortcuts to tools sort of help but are impossible to
> remember.
> 

Agreed. If you already know this and meant something else, please just
disregard. What I meant to say is that it's the same tool. Click and drag to
draw a zoom box. Just click and it simply zooms out by a set amount. No need
to change tools.

> 
>> There's no way to restrict such discussion, even if someone wanted to
>> ;-)
> 
> nope, but you can happily ignore the noise & get on with the coding.
> 
> We used to have a system at the shop I used to work in- the last person
> who turned up in the morning got to pick the radio station for the rest
> of the day (the radio was near the coat rack). It worked pretty well.
> 

I like that. Now if I could just get the first person in the lab to make the
coffee....

Cheers
Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



From hamish_nospam at yahoo.com  Tue Oct  3 05:47:06 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Oct  3 05:47:11 2006
Subject: [GRASS-dev] Re: [bug #5176] (grass) v.in.ogr: segfault when a full
 path to dsn is missing
In-Reply-To: <20061002112221.1D3331005C3@lists.intevation.de>
References: <20061002112221.1D3331005C3@lists.intevation.de>
Message-ID: <20061003164706.29024fa6.hamish_nospam@yahoo.com>

Maciek Sieczka via RT wrote:
> $ v.in.ogr dsn=shorter/ 


what if you leave off the trailing "/" in the dsn?


Hamish

From hamish_nospam at yahoo.com  Tue Oct  3 05:52:11 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Oct  3 05:52:16 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061002112201.GA912@polynum.com>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
	<20061002213704.64212af2.hamish_nospam@yahoo.com>
	<20061002112201.GA912@polynum.com>
Message-ID: <20061003165211.5bba21fb.hamish_nospam@yahoo.com>

Thierry Laronde wrote:
> FWIW, in the original v.digit(1) (and present in the KerGIS version)
> was the "widen window" option. It's zooming out by displaying a color
> rectangle representing the whole map with a rectangle wire locating
> the current window. Then you only select another window knowing both
> the whole extend, and where you were before.
> It's far more handy, since it's simpler to zoom out loosely, and then
> zoom in precisely.
> 
> I didn't understand why this was nuked in GPL GRASS version.


do you mean the mode present in GRASS 5's v.digit, or was there
something else present in the pre-GPL days?

(then "nuked in the GRASS 6 version of v.digit", nothing to do with GPL
adoption with version 5.0)


Hamish

From hamish_nospam at yahoo.com  Tue Oct  3 05:53:09 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue Oct  3 05:53:14 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061002112201.GA912@polynum.com>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
	<20061002213704.64212af2.hamish_nospam@yahoo.com>
	<20061002112201.GA912@polynum.com>
Message-ID: <20061003165309.395f40c2.hamish_nospam@yahoo.com>

tlaronde@polynum.com wrote:
> 
> FWIW, in the original v.digit(1) (and present in the KerGIS version)
> was the "widen window" option. It's zooming out by displaying a color
> rectangle representing the whole map with a rectangle wire locating
> the current window. Then you only select another window knowing both
> the whole extend, and where you were before.
> It's far more handy, since it's simpler to zoom out loosely, and then
> zoom in precisely.
> 
> I didn't understand why this was nuked in GPL GRASS version.


or how i.points does it?


Hamish

From glynn at gclements.plus.com  Tue Oct  3 06:31:48 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue Oct  3 06:31:50 2006
Subject: [GRASS-dev] GIF -> PNG
In-Reply-To: <20061003150058.4b534982.hamish_nospam@yahoo.com>
References: <340505ef0609220525g7dc366e0re2a6ca623f83b0ec@mail.gmail.com>
	<20060922150853.GA6624@bartok.itc.it>
	<20060927223608.4ee9269d.hamish_nospam@yahoo.com>
	<451A9CF5.4020001@itc.it> <20060929210435.GA7926@bartok.itc.it>
	<20061002152650.2623993a.hamish_nospam@yahoo.com>
	<17697.24636.440943.573933@cerise.gclements.plus.com>
	<20061003150058.4b534982.hamish_nospam@yahoo.com>
Message-ID: <17697.59316.560129.123116@cerise.gclements.plus.com>


Hamish wrote:

> > > with this set in ~/.grass.bashrc:
> > >   export GRASS_HTML_BROWSER=dillo
> > > it works fine from NVIZ, but the startup GUI defaults to using
> > > klunky old mozilla as .grass.bashrc hasn't been sourced yet(?).
> > 
> > You can always set it in your normal ~/.bash_profile etc.
> 
> well yes, but that's sloppy. my thought was: should ~/.grass.[*]rc be
> processed earlier,

~/.grass.*rc are sourced into the interactive session shell. If your
$SHELL is e.g. csh, you probably aren't going to have a
~/.grass.bashrc, and you aren't going to be able to source a
~/.grass.cshrc into a bash script such as Init.sh.

Even if your $SHELL is bash, ~/.grass.bashrc may contain commands
which don't make sense outside of an interactive shell.

> perhaps even in bin.i686-pc-linux-gnu/grass63 ?

There wouldn't be any point. The grass63 script sets $GISBASE then
runs Init.sh; anything useful that could be done in grass63 can be
done equally well in Init.sh.

-- 
Glynn Clements <glynn@gclements.plus.com>

From michael.barton at asu.edu  Tue Oct  3 06:50:08 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Oct  3 06:50:19 2006
Subject: [GRASS-dev] r.resamp.aggregate
In-Reply-To: <17697.48001.337871.723065@cerise.gclements.plus.com>
Message-ID: <C1473A10.F53F%michael.barton@asu.edu>

Thanks for doing this Glynn and others.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Glynn Clements <glynn@gclements.plus.com>
> Date: Tue, 3 Oct 2006 02:23:13 +0100
> To: <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] r.resamp.aggregate
> 
> 
> Glynn Clements wrote:
> 
>>>> Can we make a decision as to the official name of this module?
>>> 
>>> how about r.resamp.bin? (as in binning, not binary)
>>> 
>>> If r.resamp.aggregate is used, I'd vote for using the full word.
>>> I don't think "aggregate" abreviates well.
>>> 
>>> by the way, what is this module?
>> 
>> It's a resampling module where the value of the output cell is an
>> aggregate (mean, median, mode, min, max etc) of the values from all of
>> the input cells whose centres lie within the bounds of the output
>> cell.
> 
> In case no-one noticed, this is now in CVS, as r.resamp.stats.
> 
> Also, I've extended it (and lib/stats) to support aggregates which are
> weighted according to the proportion of the source cell which
> intersects the output cell. This is slower, but more accurate if the
> output grid isn't aligned to the source grid.
> 
> -- 
> Glynn Clements <glynn@gclements.plus.com>
> 
> 

From joel.pitt at gmail.com  Tue Oct  3 07:32:17 2006
From: joel.pitt at gmail.com (Joel Pitt)
Date: Tue Oct  3 07:32:19 2006
Subject: [GRASS-dev] request tracker r.null -n bug
Message-ID: <d7e54a6c0610022232u78e971f1v9163226763f3e53d@mail.gmail.com>

How are we meant to submit bugs at the current time?

Request tracker via the website and via email tells me I don't have
permission to submit to the queue (frustratingly it only mentions this
after submitting the bug.

In the meantime, here is the bug report:

Platform: GNU/Linux/x86_64
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: GRASS 6.1.cvs (2006)

the -n option is supposed to only do work (ie create a null bitmap) if
the null bitmap doesn't already exist. Currently always does it.

only_null is the flag option and is only referred to in null.c in the
following if statement:


if(only_null && !G_find_file(element, "null", mapset))
{
     sprintf (buf, "%s doesn't have null bitmap file! Exiting", name);
     G_warning(buf);
     exit(0);
}

It should probably be:

if(!only_null && !G_find_file(element, "null", mapset))
{
     sprintf (buf, "%s doesn't have null bitmap file! Exiting", name);
     G_warning(buf);
     exit(0);
}

and have another test for checking whether the file does exist and -n
is set. i.e.

if(only_null && G_find_file(element, "null", mapset))
{
     exit(0);
}

-- 
-Joel

"Wish not to seem, but to be, the best."
                -- Aeschylus

From benjamin.ducke at ufg.uni-kiel.de  Tue Oct  3 10:54:20 2006
From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke)
Date: Tue Oct  3 10:42:27 2006
Subject: [GRASS-dev] WinGRASS file locking
Message-ID: <4522253C.7000608@ufg.uni-kiel.de>

Hi all,

I remember a few messages being posted on this list a while
ago that refered to troubles with the Windows file locking
mechanism and the native version of GRASS for Windows.

Apparently, there is a whole bunch of Windows tools around
that target exactly this problem. The best one seems to
be Unlocker:

http://ccollomb.free.fr/unlocker/

It's freeware and unfortunately I could not find any source code
on the webpage, but maybe the author would be willing to share
some expertise?
The program's webpage also lists many other Windows programs
that deal with the same problem, maybe one of them will be
available as source code?

Best,

Benjamin

-- 
Benjamin Ducke, M.A.
Arch?oinformatik
(Archaeoinformation Science)
Institut f?r Ur- und Fr?hgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universit?t zu Kiel
Johanna-Mestorf-Stra?e 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

From grass-bugs at intevation.de  Tue Oct  3 11:58:53 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Tue Oct  3 11:58:56 2006
Subject: [GRASS-dev] [bug #5184] (grass) r.null -n: always creates a null
	bitmap - no matter if it already exists
Message-ID: <20061003095853.BDC321005C3@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5184
-------------------------------------------------------------------------

Subject: r.null -n: always creates a null bitmap - no matter if it already exists

(filling a bug report for Benjamin Ducke)

Platform: GNU/Linux/x86_64
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: GRASS 6.1.cvs (2006)

the -n option is supposed to only do work (ie create a null bitmap) if
the null bitmap doesn't already exist. Currently it always does it.

only_null is the flag option and is only referred to in null.c in the
following if statement:


if(only_null && !G_find_file(element, "null", mapset))
{
    sprintf (buf, "%s doesn't have null bitmap file! Exiting", name);
    G_warning(buf);
    exit(0);
}

It should probably be:

if(!only_null && !G_find_file(element, "null", mapset))
{
    sprintf (buf, "%s doesn't have null bitmap file! Exiting", name);
    G_warning(buf);
    exit(0);
}

and have another test for checking whether the file does exist and -n
is set. i.e.

if(only_null && G_find_file(element, "null", mapset))
{
    exit(0);
}


-------------------------------------------- Managed by Request Tracker

From tutey at o2.pl  Tue Oct  3 12:07:31 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Tue Oct  3 12:07:34 2006
Subject: [GRASS-dev] request tracker r.null -n bug
In-Reply-To: <d7e54a6c0610022232u78e971f1v9163226763f3e53d@mail.gmail.com>
References: <d7e54a6c0610022232u78e971f1v9163226763f3e53d@mail.gmail.com>
Message-ID: <45223663.1040700@o2.pl>

Joel Pitt wrote:
> How are we meant to submit bugs at the current time?

As a temporary workaround please email me with all the details - I'll
submit the report for you. Do not hesitate.

You can also ask Bernhard Reiter of Intevation (who host the Grass BT)
to create an account for you.

> Request tracker via the website and via email tells me I don't have
> permission to submit to the queue (frustratingly it only mentions this
> after submitting the bug.

That's true and it's too bad indeed. But there where scripted spam
attacks and in order to block them Intevation cancelled the anonymous
access. See the thread "spam in bug tracker" in gras-dev archive.

Until we switch to some decent BT system (moving to Gforge Tracker of
wald.intevation.org is planned) we have to live with this.

> In the meantime, here is the bug report:

Thanks. I have submitted it:
http://intevation.de/rt/webrt?serial_num=5184

Maciek

From tlaronde at polynum.com  Tue Oct  3 12:27:22 2006
From: tlaronde at polynum.com (tlaronde@polynum.com)
Date: Tue Oct  3 12:24:41 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061003165211.5bba21fb.hamish_nospam@yahoo.com>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
	<20061002213704.64212af2.hamish_nospam@yahoo.com>
	<20061002112201.GA912@polynum.com>
	<20061003165211.5bba21fb.hamish_nospam@yahoo.com>
Message-ID: <20061003102722.GA165@polynum.com>

On Tue, Oct 03, 2006 at 04:52:11PM +1300, Hamish wrote:
> Thierry Laronde wrote:
> > FWIW, in the original v.digit(1) (and present in the KerGIS version)
> > was the "widen window" option. It's zooming out by displaying a color
> > rectangle representing the whole map with a rectangle wire locating
> > the current window. Then you only select another window knowing both
> > the whole extend, and where you were before.
> > It's far more handy, since it's simpler to zoom out loosely, and then
> > zoom in precisely.
> > 
> > I didn't understand why this was nuked in GPL GRASS version.
> 
> 
> do you mean the mode present in GRASS 5's v.digit, or was there
> something else present in the pre-GPL days?

Existing in the pre-GPL days. I first used GRASS in the GPL version 5.0.
It was already not there.

> 
> (then "nuked in the GRASS 6 version of v.digit", nothing to do with GPL
> adoption with version 5.0)
> 
> 
> Hamish

And the "GPL GRASS" mention is not a criticism, nor the claim that this
was nuked because of the licence. It's only for me the standard way to
name the different branches from GRASS (the original public domain), to
GPL GRASS (your version) and BSD GRASS aka KerGIS (my version). Sorry if
it seemed deprecating, it was not the intention.

Since there _are_ main differences between the GPL GRASS and the
original, we (or at least I) feel the need to name exactly what version
I'm referring to.

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

From tlaronde at polynum.com  Tue Oct  3 12:39:14 2006
From: tlaronde at polynum.com (tlaronde@polynum.com)
Date: Tue Oct  3 12:36:33 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061003165309.395f40c2.hamish_nospam@yahoo.com>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
	<20061002213704.64212af2.hamish_nospam@yahoo.com>
	<20061002112201.GA912@polynum.com>
	<20061003165309.395f40c2.hamish_nospam@yahoo.com>
Message-ID: <20061003103914.GB165@polynum.com>

On Tue, Oct 03, 2006 at 04:53:09PM +1300, Hamish wrote:
> 
> or how i.points does it?

No, it's different.

And part of the hard work for me is precisely to put the zooming
functions (based on the DRAWLIB [previously named RASTERLIB] and
CURSESTKLIB [previously named VASKLIB]) into one toolkit lib so that
there is, when possible, one zooming version consistent accross the
different graphical programs.

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

From tutey at o2.pl  Tue Oct  3 12:38:26 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Tue Oct  3 12:38:29 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <20061003164225.71b4d9fd.hamish_nospam@yahoo.com>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BB4@s5-dar-r1.nrn.nrcan.gc.ca>
	<20061003164225.71b4d9fd.hamish_nospam@yahoo.com>
Message-ID: <45223DA2.6060307@o2.pl>

Hamish wrote:
> Patton, Eric wrote:
>> Maciek had advised me to make diffs from the original description
>> html, because I had tried diffing a copy of a manpage somewhere in
>> /home, and he had problems applying it to CVS. (?) I'm not sure why it
>> didn't work, just following suggestions. I'll CC: him on this to see
>> why.

Eric,

I asked you for that, because if the diff header looks like this:

Index: description.html
===================================================================
RCS file:
/home/grass/grassrepository/grass6/vector/v.segment/description.html,v
retrieving revision 1.4
diff -u -r1.4 description.html
--- description.html	2 Jan 2006 14:44:52 -0000	1.4
+++ description.html	26 Sep 2006 19:03:32 -0000

	it is easy to apply to cvs, but if it is like:

--- description.html	2005-11-04 09:39:12.000000000 -0400
+++ v.out.ascii_improved.html	2006-08-29 12:04:27.000000000 -0300

it is not that easy, at least I can't (this might be the main problem
;)) without further manual editing.



There's got be something to it because
http://grass.itc.it/devel/index.php#submission reads:

"In general, please generate differences to the current CVS instead of
sending full files:
cvs diff -u [file.c] > grassdiff"

I realize it might be to cumbersome and discourage many eventuall
commiters, but on the other hand it is also necessary to keep applying
the changes into CVS simple. I'd love to have a compromise solution -
an easy way for creating documentation diffs, which will also be easy
to apply to cvs.

I'm a complete CVS noob and I don't have time to investigate that
further in the momment, so any thoughts are wellcome.

Best,
Maciek

P.S.
Eric, thanks for taking care of this. Your how-to will surely help many
folks to get involved!

From neteler at itc.it  Tue Oct  3 13:20:03 2006
From: neteler at itc.it (Markus Neteler)
Date: Tue Oct  3 13:20:05 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061003103914.GB165@polynum.com>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
	<20061002213704.64212af2.hamish_nospam@yahoo.com>
	<20061002112201.GA912@polynum.com>
	<20061003165309.395f40c2.hamish_nospam@yahoo.com>
	<20061003103914.GB165@polynum.com>
Message-ID: <20061003112003.GC25302@bartok.itc.it>

On Tue, Oct 03, 2006 at 12:39:14PM +0200, tlaronde@polynum.com wrote:
> On Tue, Oct 03, 2006 at 04:53:09PM +1300, Hamish wrote:
> > 
> > or how i.points does it?
> 
> No, it's different.
> 
> And part of the hard work for me is precisely to put the zooming
> functions (based on the DRAWLIB [previously named RASTERLIB] and
> CURSESTKLIB [previously named VASKLIB]) into one toolkit lib so that
> there is, when possible, one zooming version consistent accross the
> different graphical programs.

>From a user's prespective, this sounds very good.

Markus

From grass-bugs at intevation.de  Tue Oct  3 13:32:24 2006
From: grass-bugs at intevation.de (Maciek Sieczka via RT)
Date: Tue Oct  3 13:32:26 2006
Subject: [GRASS-dev] [bug #5183] (grass) g.region -a: different number of
	rows if using 'res' or 'nsres' and 'ewres' - though
	res=nsres=ewres=10!
Message-ID: <20061003113224.74C7B1006A9@lists.intevation.de>

glynn@gclements.plus.com wrote (Tue, Oct 3 2006 05:17:52):

> I've changed it in CVS.
> 
> Previously, ewres=/nsres= rounded to an even multiple of the
> resolution, whereas res= simply rounded to a multiple.

Many many thanks! Works OK now.

Closing the ticket.

Maciek



-------------------------------------------- Managed by Request Tracker

From grass-bugs at intevation.de  Tue Oct  3 13:37:21 2006
From: grass-bugs at intevation.de (Maciek Sieczka via RT)
Date: Tue Oct  3 13:37:23 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full path
	to dsn is missing
Message-ID: <20061003113721.CAC1D1006A9@lists.intevation.de>

hamish_nospam@yahoo.com wrote (Tue, Oct 3 2006 05:47:19):

> Maciek Sieczka via RT wrote:

>> $ v.in.ogr dsn=shorter/ 
 
> what if you leave off the trailing "/" in the dsn?

It doesn't change anything. Still a segfault if
"dsn=force_lrconnect_cl_onlycat139" and no segfault if "dsn=shorter". Looks
like the string length is the key.

Maciek


-------------------------------------------- Managed by Request Tracker

From grass-bugs at intevation.de  Tue Oct  3 13:40:59 2006
From: grass-bugs at intevation.de (Markus Neteler via RT)
Date: Tue Oct  3 13:41:02 2006
Subject: [GRASS-dev] [bug #3224] (grass) r.terraflow does not compile
	(Solaris2.9/Sparc)
Message-ID: <20061003114059.5E38E1006B0@lists.intevation.de>

Report from Harri:

after a very long time, I managed to get back into compiling GRASS on
Solaris2.9/Sparc.

r.terraflow:

Does not compile, complains about:
"direction.h", line 50: Error: Could not open include file<ostream.h>.

Which in Solaris is <iostream.h> (or <iostream> for standard mode
libraries which use namespaces.) The same goes also for
IOStream/include/empq_impl.h
The test present in both these cases about whether the compiler is GNU 3
with subnumber 1 or larger excludes the new GNU 4 compilers, which is
probably not the intention. It also excludes the Solaris CC, and the
system currently recommends using <iostrem> while <iostrem.h> is not
standard and deprecated.

Then, in the main.cc on line 333:
"main.cc", line 333: Error: The function "ctime_r" must have a
prototype."


-------------------------------------------- Managed by Request Tracker

From grass-bugs at intevation.de  Tue Oct  3 13:45:51 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Tue Oct  3 13:45:53 2006
Subject: [GRASS-dev] [bug #5185] (grass) shared libraries problem
	(Solaris2.9/Sparc)
Message-ID: <20061003114551.C11B81006A9@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5185
-------------------------------------------------------------------------

Subject: shared libraries problem (Solaris2.9/Sparc)

In the include/Makefiles/Platform.Make:

LD = /some/path/ld -G ...

which does not work for shared libraries which should be linked with CC
in solaris (from man CC, switch -G) : "Do not use ld -G to build shared
libraries; use CC -G. The CC driver automatically passes several options
to ld that are needed for C++."

[report inserted by MN]

-------------------------------------------- Managed by Request Tracker

From grass-bugs at intevation.de  Tue Oct  3 13:47:34 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Tue Oct  3 13:47:35 2006
Subject: [GRASS-dev] [bug #5186] (grass) diglib compilation problem
	(Solaris2.9/Sparc)
Message-ID: <20061003114734.D41FB1006A9@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5186
-------------------------------------------------------------------------

Subject: diglib compilation problem (Solaris2.9/Sparc)

There is a problem with lib/vector/diglib:

the compiler complains about this with most files in this folder:
"/home/fysop/92/harkiisk/include/ogr_core.h", line 200: warning:
enumerator value overflows INT_MAX (2147483647)"

Which may be the reason that at the end of the compilation I get:

cd OBJ.sparc-sun-solaris2.9;
LD_LIBRARY_PATH=":/home/fysop/92/harkiisk/src/grass6/dist.sparc-sun-solaris2.9/lib"
./test; diff
+./test.tmp ../test.ok
ERROR in read/write portable long, byte_order = 1
  Written: -2147483647
  Read   : 2147483649
ERROR in read/write portable long, byte_order = 1
  Written: -123456789
  Read   : 4171510507

but the module exists.

[report inserted by MN]

-------------------------------------------- Managed by Request Tracker

From neteler at itc.it  Tue Oct  3 13:57:11 2006
From: neteler at itc.it (Markus Neteler)
Date: Tue Oct  3 13:57:13 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full
	path to dsn is missing
In-Reply-To: <20061003113721.CAC1D1006A9@lists.intevation.de>
References: <20061003113721.CAC1D1006A9@lists.intevation.de>
Message-ID: <20061003115711.GE25302@bartok.itc.it>

On Tue, Oct 03, 2006 at 01:37:21PM +0200, Maciek Sieczka via RT wrote:
> hamish_nospam@yahoo.com wrote (Tue, Oct 3 2006 05:47:19):
> 
> > Maciek Sieczka via RT wrote:
> 
> >> $ v.in.ogr dsn=shorter/ 
>  
> > what if you leave off the trailing "/" in the dsn?
> 
> It doesn't change anything. Still a segfault if
> "dsn=force_lrconnect_cl_onlycat139" and no segfault if "dsn=shorter". Looks
> like the string length is the key.

I just made a test:

GRASS 6.3.cvs (spearfish60):~ > v.out.ogr roads dsn=myroads_12345678901234567890_test.shp olayer=roads
Exporting 825 points/lines...
825 features written

GRASS 6.3.cvs (spearfish60):~ > v.in.ogr myroads_12345678901234567890_test.shp out=myroads
A datum name nad27 (North_American_Datum_1927) was specified without transformation parameters.
WARNING: Non-interactive mode: the GRASS default for nad27 is
         towgs84=-22.000,157.000,176.000.
Projection of input dataset and current location appear to match.
Proceeding with import...
Layer: myroads_12345678901234567890_test
WARNING: Column name changed: 'cat' -> 'cat_'
-----------------------------------------------------
Building topology ...
825 primitives registered
...

This works.

Best is to use a debugger. See here how to do that with 'ddd':
http://grass.gdf-hannover.de/wiki/GRASS_Debugging#Using_DDD_.28gdb_graphical_frontend.29

It is fairly easy to handle.

Markus

From tutey at o2.pl  Tue Oct  3 14:08:15 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Tue Oct  3 14:08:20 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune - 'thresh'
	interpreted wrong?
In-Reply-To: <20061003150518.7e71c9f1.hamish_nospam@yahoo.com>
References: <4521640D.3030308@o2.pl>
	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>
Message-ID: <452252AF.5040605@o2.pl>

Hamish wrote:
> Maciej Sieczka wrote:

>> 	$ echo "L 4 1
>> 	 10 10
>> 	 20 10
>> 	 30 10
>> 	 40 10
>> 	 1     1" | v.in.ascii -n out=line format=standard
>>
>>
>> So there are 4 vertices and the distance between each 2 following is
>> 10. Then I don't understand why the:
>>
>> 	$ v.clean input=line output=line_pruned type=line tool=prune
>> 	thresh=1

>> I declared thresh=1, the distance between vertices is 10 - so none
>> should be removed, but all are! And the same happens with all the lower
>> thresholds until thresh=0.03.

> what if there is some angle between the points? e.g.
> 
> v.in.ascii -n out=line format=standard << EOF
> L 4 1
>  10 10
>  20 5
>  30 7.5
>  40 10
>  1  1
> EOF

$ v.clean input=line output=line2_pruned type=line tool=prune thresh=1

$ v.out.ascii line2_pruned format=standard | awk 'NR>10'
L  3 1
 10           10
 20           5
 40           10
 1     1

The thresh=1, but v.clean prunes the 3rd vertex "30 7.5", which as far
from the other 2 vertices as ~10.3! I don't get it.

Any hints Radim?

Maciek

From mlennert at club.worldonline.be  Tue Oct  3 14:21:00 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Oct  3 14:20:45 2006
Subject: [GRASS-dev] Re: [GRASS-user] the installation
In-Reply-To: <cbf2bf3c120b.45212263@shaw.ca>
References: <000601c6e662$3a25d820$df3210ac@timberline.int>
	<cbf2bf3c120b.45212263@shaw.ca>
Message-ID: <452255AC.3070902@club.worldonline.be>

Tyler Mitchell wrote:

> I followed along with what you did and have hit a snag as well.  Hopefully you will get you a step further than I have.  I'm still looking at it...
> 
> But, in a nutshell, I set my "GIS Data Directory" to:
> C:/msys/1.0/local/grass/data
> after creating the data folder manually.  This is where all my GRASS projects data will be stored.
> 
> Then under "Define new location with..." I select "EPSG codes".  This is to initialise the "location" database.  (Location is roughly equivalent to set of data for a project.)
> 
> A dialogue box should appear.  Provide any name you want for the location Name.  The two paths should default properly for you.  Enter in an EPSG projection code number.  You can hit the Browse button to review the very  long list of EPSG codes.  These are a number that represents a specific set of projection parameters.  Here are some examples of EPSG numbers to use that are probably applicable to you:
> 4326 = geographic coordinates
> 3005 = BC Albers NAD83
> 26910 = UTM NAD83 Zone 10
> 26909 = UTM NAD83 Zone 9
> 
> Enter the number into the EPSG box, then select the "Define Location" button.  Command window appears but never leaves. Hmmmm...  
> 
> If I kill the command window I get the errors listed below.  Anyone have any ideas?

Sounds like the problem discussed here:
http://grass.itc.it/pipermail/grass5/2006-September/026112.html

Moritz

> 
> Hope this helps.
> 
> Tyler
> --------------
> A datum name nad83 (North_American_Datum_1983) was specified without transformation parameters.
> 
> Now select Datum Transformation Parameters
> Please think carefully about the area covered by your data
> and the accuracy you require before making your selection.
> 
> Enter 'list' to see the list of available Parameter sets
> Enter the corresponding number, or <RETURN> to cancel request
>> ^Cchild process exited abnormally
> A datum name nad83 (North_American_Datum_1983) was specified without transformation parameters.
> 
> Now select Datum Transformation Parameters
> Please think carefully about the area covered by your data
> and the accuracy you require before making your selection.
> 
> Enter 'list' to see the list of available Parameter sets
> Enter the corresponding number, or <RETURN> to cancel request
>> ^Cchild process exited abnormally
>     while executing
> "exec -- $env(GISBASE)/etc/grass-xterm-wrapper -e $env(GISBASE)/etc/make_location_epsg.sh  $epsg_code $epsgLocation $locpath"
>     invoked from within
> ".optPopup.submit invoke"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel #0 [list $w invoke]"
>     (procedure "tk::ButtonUp" line 24)
>     invoked from within
> "tk::ButtonUp .optPopup.submit
> "
>     (command bound to event)
> 
> 
> 
> 
> 
> ---------
> Ching wrote:
> 
> Hello, everyone:
> 
> I followed the procedures listed on web to install MS-Windows native binary at http://geni.ath.cx/grass.html, the fist three steps were successfully installed. However, the step 4, ?Run C:\msys\1.0\grass.bat to start the GRASS GIS Manager ? when I run this step, it let me to provide Location, Mapset, and Database. I did not know where I should point them to.
> 
>  
> 
> I am newer in this group and first time for installation, anyone can help?
> 
> Thanks lot
> 
> Ching
> 
> _______________________________________________
> grassuser mailing list
> grassuser@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser

From tutey at o2.pl  Tue Oct  3 14:23:06 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Tue Oct  3 14:23:08 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full
	path to dsn is missing
In-Reply-To: <20061003115711.GE25302@bartok.itc.it>
References: <20061003113721.CAC1D1006A9@lists.intevation.de>
	<20061003115711.GE25302@bartok.itc.it>
Message-ID: <4522562A.2060309@o2.pl>

Markus Neteler wrote:

> Best is to use a debugger. See here how to do that with 'ddd':
> http://grass.gdf-hannover.de/wiki/GRASS_Debugging#Using_DDD_.28gdb_graphical_frontend.29

OK, done, but some different way:

$ ulimit -c 3000
$ grass63
$ v.in.ogr dsn=force_lrconnect_cl_onlycat139
output=force_lrconnect_cl_onlycat139_import
layer=force_lrconnect_cl_onlycat139

(segfault)

$ gdb v.in.ogr core

(gdb) bt
#0  0x00010101 in ?? ()
#1  0xb7cb5c2f in OGRSpatialReference::Release ()
   from /usr/local/lib/libgdal.so.1
#2  0xb7cab4e7 in OGRGeometry::~OGRGeometry () from
/usr/local/lib/libgdal.so.1
#3  0xb7ca6810 in OGRCurve::~OGRCurve () from /usr/local/lib/libgdal.so.1
#4  0xb7ca6ad8 in OGRLineString::~OGRLineString ()
   from /usr/local/lib/libgdal.so.1
#5  0xb7caf6ff in OGRFeature::~OGRFeature () from
/usr/local/lib/libgdal.so.1
#6  0xb7caefa5 in OGR_F_Destroy () from /usr/local/lib/libgdal.so.1
#7  0x0804ccfc in main (argc=4, argv=0xbffcb044) at main.c:744
(gdb) q

Any good?

Maciek

From mlennert at club.worldonline.be  Tue Oct  3 14:23:56 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Oct  3 14:23:41 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune - 'thresh'
	interpreted wrong?
In-Reply-To: <452252AF.5040605@o2.pl>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>
	<452252AF.5040605@o2.pl>
Message-ID: <4522565C.5050400@club.worldonline.be>

Maciej Sieczka wrote:
> Hamish wrote:
>> Maciej Sieczka wrote:
> 
>>> 	$ echo "L 4 1
>>> 	 10 10
>>> 	 20 10
>>> 	 30 10
>>> 	 40 10
>>> 	 1     1" | v.in.ascii -n out=line format=standard
>>>
>>>
>>> So there are 4 vertices and the distance between each 2 following is
>>> 10. Then I don't understand why the:
>>>
>>> 	$ v.clean input=line output=line_pruned type=line tool=prune
>>> 	thresh=1
> 
>>> I declared thresh=1, the distance between vertices is 10 - so none
>>> should be removed, but all are! And the same happens with all the lower
>>> thresholds until thresh=0.03.
> 
>> what if there is some angle between the points? e.g.
>>
>> v.in.ascii -n out=line format=standard << EOF
>> L 4 1
>>  10 10
>>  20 5
>>  30 7.5
>>  40 10
>>  1  1
>> EOF
> 
> $ v.clean input=line output=line2_pruned type=line tool=prune thresh=1
> 
> $ v.out.ascii line2_pruned format=standard | awk 'NR>10'
> L  3 1
>  10           10
>  20           5
>  40           10
>  1     1
> 
> The thresh=1, but v.clean prunes the 3rd vertex "30 7.5", which as far
> from the other 2 vertices as ~10.3! I don't get it.


Doesn't

20 5
30 7.5
40 10

Define a straight line ? I would guess that the prune tool prunes all 
"unneccessary" nodes on a straight line, i.e. any node which is not 
necessary to define the line, and this whatever the threshold.

The threshold only applies in cases of change of direction (i.e. angles).

Just another example of the need for much more documentation for 
v.clean, including example diagrams like the one for the rmsa tool.


Moritz

From neteler at itc.it  Tue Oct  3 14:33:16 2006
From: neteler at itc.it (Markus Neteler)
Date: Tue Oct  3 14:33:18 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune - 'thresh'
	interpreted wrong?
In-Reply-To: <4522565C.5050400@club.worldonline.be>
References: <4521640D.3030308@o2.pl>
	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>
	<452252AF.5040605@o2.pl> <4522565C.5050400@club.worldonline.be>
Message-ID: <20061003123316.GF25302@bartok.itc.it>

On Tue, Oct 03, 2006 at 02:23:56PM +0200, Moritz Lennert wrote:
...
> Doesn't
> 
> 20 5
> 30 7.5
> 40 10
> 
> Define a straight line ? I would guess that the prune tool prunes all 
> "unneccessary" nodes on a straight line, i.e. any node which is not 
> necessary to define the line, and this whatever the threshold.
> 
> The threshold only applies in cases of change of direction (i.e. angles).
> 
> Just another example of the need for much more documentation for 
> v.clean, including example diagrams like the one for the rmsa tool.

Fully agreed... but let me reiterate that a different pruning
algorithm might be the best solution (e.g. Douglas-Peucker which
is found as C code on the GMT site). The current one doesn't even work
in LatLong.

Markus

From tutey at o2.pl  Tue Oct  3 14:56:18 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Tue Oct  3 14:56:27 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -
	'thresh'	interpreted wrong?
In-Reply-To: <20061003123316.GF25302@bartok.itc.it>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>
	<4522565C.5050400@club.worldonline.be>
	<20061003123316.GF25302@bartok.itc.it>
Message-ID: <45225DF2.1010802@o2.pl>

Markus Neteler wrote:
> On Tue, Oct 03, 2006 at 02:23:56PM +0200, Moritz Lennert wrote:

>> I would guess that the prune tool prunes all 
>> "unneccessary" nodes on a straight line, i.e. any node which is not 
>> necessary to define the line, and this whatever the threshold.
>>
>> The threshold only applies in cases of change of direction (i.e. angles).
>>
>> Just another example of the need for much more documentation for 
>> v.clean, including example diagrams like the one for the rmsa tool.

> Fully agreed...

Markus,

Agreed regarding what?

Moritz just supposes but he is not sure. And if you look into my
original email you'll that he's wrong:

1. a *straight* line, consisted of 4 vertices, at regular intervals of
   10
2. thresh>0.03 prunes all vertices (besides the nodes of course)
3. thresh<=0.03 prunes none

Then Moritz's idea is wrong.

And I need to know exactly how the thresh in prune works, as I'm using
it for my work. The result will be a script that I'm going to publish.
Please - if anybody knows, tell me. I'd love to update the manual
accordingly.

Maciek

From neteler at itc.it  Tue Oct  3 15:06:41 2006
From: neteler at itc.it (Markus Neteler)
Date: Tue Oct  3 15:06:44 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -
	'thresh'	interpreted wrong?
In-Reply-To: <45225DF2.1010802@o2.pl>
References: <4521640D.3030308@o2.pl>
	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>
	<452252AF.5040605@o2.pl> <4522565C.5050400@club.worldonline.be>
	<20061003123316.GF25302@bartok.itc.it> <45225DF2.1010802@o2.pl>
Message-ID: <20061003130641.GI25302@bartok.itc.it>

On Tue, Oct 03, 2006 at 02:56:18PM +0200, Maciej Sieczka wrote:
> Markus Neteler wrote:
> > On Tue, Oct 03, 2006 at 02:23:56PM +0200, Moritz Lennert wrote:
> 
> >> I would guess that the prune tool prunes all 
> >> "unneccessary" nodes on a straight line, i.e. any node which is not 
> >> necessary to define the line, and this whatever the threshold.
> >>
> >> The threshold only applies in cases of change of direction (i.e. angles).
> >>
> >> Just another example of the need for much more documentation for 
> >> v.clean, including example diagrams like the one for the rmsa tool.
> 
> > Fully agreed...
> 
> Markus,
> 
> Agreed regarding what?

... regarding that more documentation is needed.
 
...
> And I need to know exactly how the thresh in prune works, as I'm using
> it for my work. The result will be a script that I'm going to publish.
> Please - if anybody knows, tell me. I'd love to update the manual
> accordingly.

Apparently it can be only reverse engineered (luckily it's FOSS).
I was not too happy with my attempts to use the prune algorithm,
I don't think that it works reasonable well.

But this is an old story:
http://grass.itc.it/pipermail/grassuser/1995-January/012655.html
http://grass.itc.it/pipermail/grassuser/2006-July/035373.html
http://grass.itc.it/pipermail/grassuser/2006-August/035529.html

The first mail indicates that the problem is known and wasn't
resolved so far. Time to switch to another algorithm :-)

Markus

From mlennert at club.worldonline.be  Tue Oct  3 15:13:39 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Oct  3 15:13:23 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -
	'thresh'	interpreted wrong?
In-Reply-To: <45225DF2.1010802@o2.pl>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>
	<4522565C.5050400@club.worldonline.be>
	<20061003123316.GF25302@bartok.itc.it> <45225DF2.1010802@o2.pl>
Message-ID: <45226203.5070807@club.worldonline.be>

Maciej Sieczka wrote:
> Markus Neteler wrote:
>> On Tue, Oct 03, 2006 at 02:23:56PM +0200, Moritz Lennert wrote:
> 
>>> I would guess that the prune tool prunes all 
>>> "unneccessary" nodes on a straight line, i.e. any node which is not 
>>> necessary to define the line, and this whatever the threshold.
>>>
>>> The threshold only applies in cases of change of direction (i.e. angles).
>>>
>>> Just another example of the need for much more documentation for 
>>> v.clean, including example diagrams like the one for the rmsa tool.
> 
>> Fully agreed...
> 
> Markus,
> 
> Agreed regarding what?

I think Markus responded to my remark on lack of documentation.

> 
> Moritz just supposes but he is not sure. And if you look into my
> original email you'll that he's wrong:
> 
> 1. a *straight* line, consisted of 4 vertices, at regular intervals of
>    10
> 2. thresh>0.03 prunes all vertices (besides the nodes of course)
> 3. thresh<=0.03 prunes none
> 
> Then Moritz's idea is wrong.
> 
> And I need to know exactly how the thresh in prune works, as I'm using
> it for my work. The result will be a script that I'm going to publish.
> Please - if anybody knows, tell me. I'd love to update the manual
> accordingly.

Check

http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/vector/diglib/prune.c?rev=HEAD&content-type=text/vnd.viewcvs-markup

There is an explanation of the algorithm at the beginning.

Moritz

From mlennert at club.worldonline.be  Tue Oct  3 15:21:38 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Oct  3 15:21:22 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune
	-	'thresh'	interpreted wrong?
In-Reply-To: <20061003130641.GI25302@bartok.itc.it>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>
	<4522565C.5050400@club.worldonline.be>	<20061003123316.GF25302@bartok.itc.it>
	<45225DF2.1010802@o2.pl> <20061003130641.GI25302@bartok.itc.it>
Message-ID: <452263E2.4030603@club.worldonline.be>

Markus Neteler wrote:
> On Tue, Oct 03, 2006 at 02:56:18PM +0200, Maciej Sieczka wrote:
>> Markus Neteler wrote:
>>> On Tue, Oct 03, 2006 at 02:23:56PM +0200, Moritz Lennert wrote:
>>>> I would guess that the prune tool prunes all 
>>>> "unneccessary" nodes on a straight line, i.e. any node which is not 
>>>> necessary to define the line, and this whatever the threshold.
>>>>
>>>> The threshold only applies in cases of change of direction (i.e. angles).
>>>>
>>>> Just another example of the need for much more documentation for 
>>>> v.clean, including example diagrams like the one for the rmsa tool.
>>> Fully agreed...
>> Markus,
>>
>> Agreed regarding what?
> 
> ... regarding that more documentation is needed.
>  
> ...
>> And I need to know exactly how the thresh in prune works, as I'm using
>> it for my work. The result will be a script that I'm going to publish.
>> Please - if anybody knows, tell me. I'd love to update the manual
>> accordingly.
> 
> Apparently it can be only reverse engineered (luckily it's FOSS).
> I was not too happy with my attempts to use the prune algorithm,
> I don't think that it works reasonable well.
> 
> But this is an old story:
> http://grass.itc.it/pipermail/grassuser/1995-January/012655.html
> http://grass.itc.it/pipermail/grassuser/2006-July/035373.html
> http://grass.itc.it/pipermail/grassuser/2006-August/035529.html
> 
> The first mail indicates that the problem is known and wasn't
> resolved so far. Time to switch to another algorithm :-)

Michel's changes date from 1998 and were apparently written for 4.2.1, 
so there was change since then. Don't know if that resolved the problem 
though... Nor which algorithm is better.

Moritz

From mlennert at club.worldonline.be  Tue Oct  3 17:20:55 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Oct  3 17:20:39 2006
Subject: [GRASS-dev] [bug report] gis.m: error when launching v.db.connect
 from menu with DEBUG set to 3
Message-ID: <45227FD7.9090700@club.worldonline.be>

After 'g.gisenv set=DEBUG=3' the menu entry corresponding to 
v.db.connect (vector -> vector<->database connection -> set connection) 
provokes an error.

No more error after setting DEBUG back with g.gisenv set=DEBUG.

Don't know if this also concerns other modules.

Moritz

From gordon.whitmore at rogers.com  Tue Oct  3 17:43:18 2006
From: gordon.whitmore at rogers.com (Gordon Whitmore)
Date: Tue Oct  3 17:43:07 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune
	-'thresh'	interpreted wrong?
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl><4522565C.5050400@club.worldonline.be><20061003123316.GF25302@bartok.itc.it>
	<45225DF2.1010802@o2.pl>
Message-ID: <005201c6e702$a669a4d0$6600a8c0@DADDYOH>

How do I stop getting the "GRASS" e-mails.......
Thanks
----- Original Message ----- 
From: "Maciej Sieczka" <tutey@o2.pl>
To: <grassuser@grass.itc.it>; <grass-dev@grass.itc.it>; "Radim Blazek" 
<radim.blazek@gmail.com>
Cc: "Markus Neteler" <neteler@itc.it>; "Moritz Lennert" 
<mlennert@club.worldonline.be>
Sent: Tuesday, October 03, 2006 9:56 AM
Subject: Re: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -'thresh' 
interpreted wrong?


> Markus Neteler wrote:
>> On Tue, Oct 03, 2006 at 02:23:56PM +0200, Moritz Lennert wrote:
>
>>> I would guess that the prune tool prunes all
>>> "unneccessary" nodes on a straight line, i.e. any node which is not
>>> necessary to define the line, and this whatever the threshold.
>>>
>>> The threshold only applies in cases of change of direction (i.e. 
>>> angles).
>>>
>>> Just another example of the need for much more documentation for
>>> v.clean, including example diagrams like the one for the rmsa tool.
>
>> Fully agreed...
>
> Markus,
>
> Agreed regarding what?
>
> Moritz just supposes but he is not sure. And if you look into my
> original email you'll that he's wrong:
>
> 1. a *straight* line, consisted of 4 vertices, at regular intervals of
>   10
> 2. thresh>0.03 prunes all vertices (besides the nodes of course)
> 3. thresh<=0.03 prunes none
>
> Then Moritz's idea is wrong.
>
> And I need to know exactly how the thresh in prune works, as I'm using
> it for my work. The result will be a script that I'm going to publish.
> Please - if anybody knows, tell me. I'd love to update the manual
> accordingly.
>
> Maciek
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev 

From tutey at o2.pl  Tue Oct  3 17:43:12 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Tue Oct  3 17:43:25 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -
	'thresh'	interpreted wrong?
In-Reply-To: <45226203.5070807@club.worldonline.be>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>
	<4522565C.5050400@club.worldonline.be>
	<20061003123316.GF25302@bartok.itc.it> <45225DF2.1010802@o2.pl>
	<45226203.5070807@club.worldonline.be>
Message-ID: <45228510.4080807@o2.pl>

Moritz Lennert wrote:

> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/vector/diglib/prune.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
> 
> There is an explanation of the algorithm at the beginning.

Thanks, I should have looked into the source code first. My only (poor)
excuse is being a non-programmer and "mentally handicapped" due to my
disgraceful pre-Linux/FOSS times ;).

Moritz suggested that maybe "the threshold only applies in cases of
change of direction (i.e. angles)". Please note there is no any
reference to angles or direction in the code or comments. It seems the
threshold refers to distance only.

There is a following comment:

* thresh - the distance that a string must wander from a straight
*          line before another point is selected.

As I understand it, this means that if my vertcices are on a straight
line, at intervals of 10, only a thresh of 10 or more should prune
them. But, as you can see in my original example, any thresh>=0.03
prunes them. Do I missunderstand sthing (I'm not sure what the
"straight line" means here)?

So we have 2 possibilities:

1. If in opposite to my interpretation of the source and manual,
angles/directions DO have something to do with the pruning thresh,
please somebody knowledgeable tell me what is that relation, so I can
fix the part of the manual, that reads "prune: remove vertices in
threshold from lines (...)".

2. If the pruning thresh doesn't depend on angles/directions, how do I
understand the fact that any thresh>=0.03 prunes points which are at
intervals of 10 on a straight line?

Maciek

CCing Mr. Michel Wurtz in case he is still out there under this email,
maybe.

From mlennert at club.worldonline.be  Tue Oct  3 18:26:47 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Tue Oct  3 18:26:34 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -
	'thresh'	interpreted wrong?
In-Reply-To: <45228510.4080807@o2.pl>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>
	<4522565C.5050400@club.worldonline.be>
	<20061003123316.GF25302@bartok.itc.it> <45225DF2.1010802@o2.pl>
	<45226203.5070807@club.worldonline.be> <45228510.4080807@o2.pl>
Message-ID: <45228F47.7070804@club.worldonline.be>

Maciej Sieczka wrote:
> Moritz Lennert wrote:
> 
>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/vector/diglib/prune.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
>>
>> There is an explanation of the algorithm at the beginning.
> 
> Thanks, I should have looked into the source code first. My only (poor)
> excuse is being a non-programmer and "mentally handicapped" due to my
> disgraceful pre-Linux/FOSS times ;).
> 
> Moritz suggested that maybe "the threshold only applies in cases of
> change of direction (i.e. angles)". Please note there is no any
> reference to angles or direction in the code or comments. It seems the
> threshold refers to distance only.
> 
> There is a following comment:
> 
> * thresh - the distance that a string must wander from a straight
> *          line before another point is selected.
> 
> As I understand it, this means that if my vertcices are on a straight
> line, at intervals of 10, only a thresh of 10 or more should prune
> them. But, as you can see in my original example, any thresh>=0.03
> prunes them. Do I missunderstand sthing (I'm not sure what the
> "straight line" means here)?
> 
> So we have 2 possibilities:
> 
> 1. If in opposite to my interpretation of the source and manual,
> angles/directions DO have something to do with the pruning thresh,
> please somebody knowledgeable tell me what is that relation, so I can
> fix the part of the manual, that reads "prune: remove vertices in
> threshold from lines (...)".
> 
> 2. If the pruning thresh doesn't depend on angles/directions, how do I
> understand the fact that any thresh>=0.03 prunes points which are at
> intervals of 10 on a straight line?
> 

To plead in Markus' direction: there is a 3rd possibility:

3. Forget about the current pruning implementation and push the 
integration of another algorithm  (Douglas-Peucker). (I know you are 
working on a script, but could this wait until this is done ? Maybe if 
you push hard enough someone will "just do it" - Dylan mentioned it as a 
potentially "fun" project: 
http://grass.itc.it/pipermail/grassuser/2006-August/035529.html ;-) and 
actually links to an implementation in c++, which actually looks like 
more or less usable C to me).

Markus you mentioned the source code on the GMT site. Could you be more 
precise on where to find it ?

Moritz

From neteler at itc.it  Tue Oct  3 18:35:27 2006
From: neteler at itc.it (Markus Neteler)
Date: Tue Oct  3 18:35:29 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -
	'thresh'	interpreted wrong?
In-Reply-To: <45228F47.7070804@club.worldonline.be>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>
	<4522565C.5050400@club.worldonline.be>
	<20061003123316.GF25302@bartok.itc.it> <45225DF2.1010802@o2.pl>
	<45226203.5070807@club.worldonline.be> <45228510.4080807@o2.pl>
	<45228F47.7070804@club.worldonline.be>
Message-ID: <4522914F.4050205@itc.it>

Moritz Lennert wrote on 10/03/2006 06:26 PM:
> Maciej Sieczka wrote:
>> Moritz Lennert wrote:
>>
>>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/vector/diglib/prune.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
>>>
>>>
>>> There is an explanation of the algorithm at the beginning.
>>
>> Thanks, I should have looked into the source code first. My only (poor)
>> excuse is being a non-programmer and "mentally handicapped" due to my
>> disgraceful pre-Linux/FOSS times ;).
>>
>> Moritz suggested that maybe "the threshold only applies in cases of
>> change of direction (i.e. angles)". Please note there is no any
>> reference to angles or direction in the code or comments. It seems the
>> threshold refers to distance only.
>>
>> There is a following comment:
>>
>> * thresh - the distance that a string must wander from a straight
>> *          line before another point is selected.
>>
>> As I understand it, this means that if my vertcices are on a straight
>> line, at intervals of 10, only a thresh of 10 or more should prune
>> them. But, as you can see in my original example, any thresh>=0.03
>> prunes them. Do I missunderstand sthing (I'm not sure what the
>> "straight line" means here)?
>>
>> So we have 2 possibilities:
>>
>> 1. If in opposite to my interpretation of the source and manual,
>> angles/directions DO have something to do with the pruning thresh,
>> please somebody knowledgeable tell me what is that relation, so I can
>> fix the part of the manual, that reads "prune: remove vertices in
>> threshold from lines (...)".
>>
>> 2. If the pruning thresh doesn't depend on angles/directions, how do I
>> understand the fact that any thresh>=0.03 prunes points which are at
>> intervals of 10 on a straight line?
>>
>
> To plead in Markus' direction: there is a 3rd possibility:
>
> 3. Forget about the current pruning implementation and push the
> integration of another algorithm  (Douglas-Peucker). (I know you are
> working on a script, but could this wait until this is done ? Maybe if
> you push hard enough someone will "just do it" - Dylan mentioned it as
> a potentially "fun" project:
> http://grass.itc.it/pipermail/grassuser/2006-August/035529.html ;-)
> and actually links to an implementation in c++, which actually looks
> like more or less usable C to me).
>
> Markus you mentioned the source code on the GMT site. Could you be
> more precise on where to find it ?
Sure:
http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.3/
-> gshhs_1.5_src.tbz
   -> gshhs/gshhs_dp.c

Markus

PS: Let's reduce CC'ing to the DEV list to not spam hundreds of users
with this (now very detailed) thread.

From tutey at o2.pl  Tue Oct  3 18:41:32 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Tue Oct  3 18:41:38 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -
	'thresh'	interpreted wrong?
In-Reply-To: <45228F47.7070804@club.worldonline.be>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>
	<4522565C.5050400@club.worldonline.be>
	<20061003123316.GF25302@bartok.itc.it> <45225DF2.1010802@o2.pl>
	<45226203.5070807@club.worldonline.be> <45228510.4080807@o2.pl>
	<45228F47.7070804@club.worldonline.be>
Message-ID: <452292BC.4070201@o2.pl>

Moritz Lennert wrote:
> Maciej Sieczka wrote:
>> Moritz Lennert wrote:
>> 
>>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/vector/diglib/prune.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
>>> 
>>> 
>>> 
>>> There is an explanation of the algorithm at the beginning.
>> 
>> Thanks, I should have looked into the source code first. My only
>> (poor) excuse is being a non-programmer and "mentally handicapped"
>> due to my disgraceful pre-Linux/FOSS times ;).
>> 
>> Moritz suggested that maybe "the threshold only applies in cases
>> of change of direction (i.e. angles)". Please note there is no any
>>  reference to angles or direction in the code or comments. It
>> seems the threshold refers to distance only.
>> 
>> There is a following comment:
>> 
>> * thresh - the distance that a string must wander from a straight 
>> *          line before another point is selected.
>> 
>> As I understand it, this means that if my vertcices are on a
>> straight line, at intervals of 10, only a thresh of 10 or more
>> should prune them. But, as you can see in my original example, any
>> thresh>=0.03 prunes them. Do I missunderstand sthing (I'm not sure
>> what the "straight line" means here)?
>> 
>> So we have 2 possibilities:
>> 
>> 1. If in opposite to my interpretation of the source and manual, 
>> angles/directions DO have something to do with the pruning thresh,
>>  please somebody knowledgeable tell me what is that relation, so I
>> can fix the part of the manual, that reads "prune: remove vertices
>> in threshold from lines (...)".
>> 
>> 2. If the pruning thresh doesn't depend on angles/directions, how
>> do I understand the fact that any thresh>=0.03 prunes points which
>> are at intervals of 10 on a straight line?
>> 
> 
> To plead in Markus' direction: there is a 3rd possibility:
> 
> 3. Forget about the current pruning implementation and push the 
> integration of another algorithm  (Douglas-Peucker). (I know you are
>  working on a script, but could this wait until this is done ?

I should have done that script by yesterday :D (no kidding, just laughing).

> Maybe if you push hard enough someone will "just do it" - Dylan
> mentioned it as a potentially "fun" project: 
> http://grass.itc.it/pipermail/grassuser/2006-August/035529.html ;-)
> and actually links to an implementation in c++, which actually looks
> like more or less usable C to me).

Sure it would be a good addition to Grass, but:

1. I need a tool to remove the vertices from a line based on a given
threshold (understood as a distance from one vertex to another).
According to v.clean manual it should be able to do it, but it's not.
(I think I know how to workaround it by v.out.acii | awk | v.in.ascii.
So I should be OK.)

2. This is a bug or a lacking documention, so either should be fixed,
no matter what other pruning algorithm is added to Grass.

3. We can't remove any functionality in Grass 6, only add new.

> Markus you mentioned the source code on the GMT site. Could you be
> more precise on where to find it ?

Maciek

From michael.barton at asu.edu  Tue Oct  3 18:47:15 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Tue Oct  3 18:47:21 2006
Subject: [GRASS-dev] Re: [bug report] gis.m: error when launching
 v.db.connect from menu with DEBUG set to 3
In-Reply-To: <45227FD7.9090700@club.worldonline.be>
Message-ID: <C147E223.2533E%michael.barton@asu.edu>

I'm baffled about this.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Moritz Lennert <mlennert@club.worldonline.be>
> Date: Tue, 03 Oct 2006 17:20:55 +0200
> To: Michael Barton <michael.barton@asu.edu>
> Cc: Grass Developers List <grass-dev@grass.itc.it>
> Subject: [bug report] gis.m: error when launching v.db.connect from menu with
> DEBUG set to 3
> 
> After 'g.gisenv set=DEBUG=3' the menu entry corresponding to
> v.db.connect (vector -> vector<->database connection -> set connection)
> provokes an error.
> 
> No more error after setting DEBUG back with g.gisenv set=DEBUG.
> 
> Don't know if this also concerns other modules.
> 
> Moritz

From glynn at gclements.plus.com  Tue Oct  3 19:35:27 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue Oct  3 19:35:30 2006
Subject: [GRASS-dev] [bug #5184] (grass) r.null -n: always creates a null
	bitmap - no matter if it already exists
In-Reply-To: <20061003095853.BDC321005C3@lists.intevation.de>
References: <20061003095853.BDC321005C3@lists.intevation.de>
Message-ID: <17698.40799.230356.773827@cerise.gclements.plus.com>


Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=5184
> -------------------------------------------------------------------------
> 
> Subject: r.null -n: always creates a null bitmap - no matter if it already exists
> 
> (filling a bug report for Benjamin Ducke)
> 
> Platform: GNU/Linux/x86_64
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> GRASS Version: GRASS 6.1.cvs (2006)
> 
> the -n option is supposed to only do work (ie create a null bitmap) if
> the null bitmap doesn't already exist. Currently it always does it.
> 
> only_null is the flag option and is only referred to in null.c in the
> following if statement:
> 
> 
> if(only_null && !G_find_file(element, "null", mapset))
> {
>     sprintf (buf, "%s doesn't have null bitmap file! Exiting", name);
>     G_warning(buf);
>     exit(0);
> }
> 
> It should probably be:
> 
> if(!only_null && !G_find_file(element, "null", mapset))
> {
>     sprintf (buf, "%s doesn't have null bitmap file! Exiting", name);
>     G_warning(buf);
>     exit(0);
> }

No; according to the flag's description, it should be:

if(only_null && G_find_file(element, "null", mapset))
{
     sprintf (buf, "%s already has a null bitmap file! Exiting", name);
     G_warning(buf);
     exit(0);
}

-- 
Glynn Clements <glynn@gclements.plus.com>

From dylan.beaudette at gmail.com  Tue Oct  3 20:04:44 2006
From: dylan.beaudette at gmail.com (Dylan Beaudette)
Date: Tue Oct  3 19:39:28 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -
	=?iso-8859-2?q?=27thresh=27=09interpreted?= wrong?
In-Reply-To: <4522914F.4050205@itc.it>
References: <4521640D.3030308@o2.pl> <45228F47.7070804@club.worldonline.be>
	<4522914F.4050205@itc.it>
Message-ID: <200610031104.45027.dylan.beaudette@gmail.com>

On Tuesday 03 October 2006 09:35, Markus Neteler wrote:
> Moritz Lennert wrote on 10/03/2006 06:26 PM:
> > Maciej Sieczka wrote:
> >> Moritz Lennert wrote:
> >>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/vector/diglib/prune.c
> >>>?rev=HEAD&content-type=text/vnd.viewcvs-markup
> >>>
> >>>
> >>> There is an explanation of the algorithm at the beginning.
> >>
> >> Thanks, I should have looked into the source code first. My only (poor)
> >> excuse is being a non-programmer and "mentally handicapped" due to my
> >> disgraceful pre-Linux/FOSS times ;).
> >>
> >> Moritz suggested that maybe "the threshold only applies in cases of
> >> change of direction (i.e. angles)". Please note there is no any
> >> reference to angles or direction in the code or comments. It seems the
> >> threshold refers to distance only.
> >>
> >> There is a following comment:
> >>
> >> * thresh - the distance that a string must wander from a straight
> >> *          line before another point is selected.
> >>
> >> As I understand it, this means that if my vertcices are on a straight
> >> line, at intervals of 10, only a thresh of 10 or more should prune
> >> them. But, as you can see in my original example, any thresh>=0.03
> >> prunes them. Do I missunderstand sthing (I'm not sure what the
> >> "straight line" means here)?
> >>
> >> So we have 2 possibilities:
> >>
> >> 1. If in opposite to my interpretation of the source and manual,
> >> angles/directions DO have something to do with the pruning thresh,
> >> please somebody knowledgeable tell me what is that relation, so I can
> >> fix the part of the manual, that reads "prune: remove vertices in
> >> threshold from lines (...)".
> >>
> >> 2. If the pruning thresh doesn't depend on angles/directions, how do I
> >> understand the fact that any thresh>=0.03 prunes points which are at
> >> intervals of 10 on a straight line?
> >
> > To plead in Markus' direction: there is a 3rd possibility:
> >
> > 3. Forget about the current pruning implementation and push the
> > integration of another algorithm  (Douglas-Peucker). (I know you are
> > working on a script, but could this wait until this is done ? Maybe if
> > you push hard enough someone will "just do it" - Dylan mentioned it as
> > a potentially "fun" project:
> > http://grass.itc.it/pipermail/grassuser/2006-August/035529.html ;-)
> > and actually links to an implementation in c++, which actually looks
> > like more or less usable C to me).
> >
> > Markus you mentioned the source code on the GMT site. Could you be
> > more precise on where to find it ?
>
> Sure:
> http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.3/
> -> gshhs_1.5_src.tbz
>    -> gshhs/gshhs_dp.c
>
> Markus
>

Now that doesn't look like to difficult a snippet of code to port to GRASS. 
Only issue would be to make it less dependent on input being in lat/long :

int Douglas_Peucker_i (int x_source[], int y_source[], int n_source, double 
band, int index[])
/* x_source[]: Input coordinates in micro-degrees	*/
/* y_source[]:						*/
/* n_source:	Number of points			*/
/* band:	tolerance in kilometers 		*/
/* index[]:	output co-ordinates indices 		*/

then adapting it to GRASS data types / structs

hmmmm...

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

From epatton at nrcan.gc.ca  Tue Oct  3 21:11:46 2006
From: epatton at nrcan.gc.ca (Patton, Eric)
Date: Tue Oct  3 21:12:00 2006
Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55BBD@s5-dar-r1.nrn.nrcan.gc.ca>

I noticed that the d.histogram tool in gis.m now gives an error because it
uses the -q flag when it calls d.histogram. A few of my own scripts need to
be updated to the quiet/verbose changes in parser as well.

Maybe everyone could keep an eye out for GUI tools that call programs using
the old -q or -v flags?

~ Eric.

From dylan.beaudette at gmail.com  Wed Oct  4 00:43:29 2006
From: dylan.beaudette at gmail.com (Dylan Beaudette)
Date: Wed Oct  4 00:18:22 2006
Subject: [GRASS-dev] Re: [GRASS-user] [bug #2765] v.buffer bug??
In-Reply-To: <20061002142335.63636ffe.hamish_nospam@yahoo.com>
References: <5B025B1F39D6D4119F5700508BEEEC6603DE41C9@srsofaioi4546.ktso.ch>
	<3c5546140610011327l42eb1662w5eed705085ab35b5@mail.gmail.com>
	<20061002142335.63636ffe.hamish_nospam@yahoo.com>
Message-ID: <200610031543.29945.dylan.beaudette@gmail.com>

Thanks Hamish,

I have applied the patch, and run v.buffer on a sample data set, and all seems 
to be well. however my sample data was a set of line segments: and not areas, 
as was the case with Macieck.

Perhaps this test case is known.

Cheers,

Dylan


On Sunday 01 October 2006 18:23, Hamish wrote:
> Dylan Beaudette wrote:
> > > > http://intevation.de/rt/webrt?serial_num=2765
> > >
> > > Hi,
> > >
> > > I have a patch I think gets around the famous v.buffer bug
> > > (attached), please test.
>
> ..
>
> > will try it out on the latest CVS,
> >
> > PS: pardon my stupidity, but how would i apply this patch (forgot!)
>
> cd /where/grass/is/
> patch -p0 < patch.diff
> cd lib/vector/Vlib/
> make
>
>
> or if that doesn't work and it's small patch like this one, just make
> the changes by hand.
>
>
> Hamish

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

From hamish_nospam at yahoo.com  Wed Oct  4 02:59:53 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Oct  4 03:05:46 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <C1472AB1.F530%michael.barton@asu.edu>
References: <20061003163551.229a9dcb.hamish_nospam@yahoo.com>
	<C1472AB1.F530%michael.barton@asu.edu>
Message-ID: <20061004135953.032526f4.hamish_nospam@yahoo.com>

Michael Barton wrote:
> > Michael Barton wrote:
> >> This already exists. No need to right click. Just select zoom out
> >tool > and click.
> > 
> > A point I was trying to make is that selecting another tool is slow
> > when the task is zooming in & out to get the region "just right".
> > That's why I wanted right click zoom-out in addition to the formal
> > zoom out tool. Optional keyboard shortcuts to tools sort of help but
> > are impossible to remember.
> > 
> 
> Agreed. If you already know this and meant something else, please just
> disregard. What I meant to say is that it's the same tool. Click and
> drag to draw a zoom box. Just click and it simply zooms out by a set
> amount. No need to change tools.


I was trying to say: allow zoom *OUT* using a right click when using the
zoom *IN* tool.


Hamish

From hamish_nospam at yahoo.com  Wed Oct  4 03:17:02 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Oct  4 03:17:08 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061003102722.GA165@polynum.com>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
	<20061002213704.64212af2.hamish_nospam@yahoo.com>
	<20061002112201.GA912@polynum.com>
	<20061003165211.5bba21fb.hamish_nospam@yahoo.com>
	<20061003102722.GA165@polynum.com>
Message-ID: <20061004141702.2e6ae98a.hamish_nospam@yahoo.com>

> > Thierry Laronde wrote:
> > > FWIW, in the original v.digit(1) (and present in the KerGIS
> > > version) was the "widen window" option.
..
> > > I didn't understand why this was nuked in GPL GRASS version.
> > 
> > do you mean the mode present in GRASS 5's v.digit, or was there
> > something else present in the pre-GPL days?
> 
> Existing in the pre-GPL days. I first used GRASS in the GPL version
> 5.0. It was already not there.

ok, got it.

I was wondering if you were differentiating between GRASS 4 and 5 or
more generally GPL GRASS (ver5&6) and KerGIS bases.


> And the "GPL GRASS" mention is not a criticism,

not taken as such.

> Since there _are_ main differences between the GPL GRASS and the
> original, we (or at least I) feel the need to name exactly what
> version I'm referring to.

And it's good to do so. I didn't realize the v.digit in GRASS 5 was new
for GRASS 5.


> And part of the hard work for me is precisely to put the zooming
> functions (based on the DRAWLIB [previously named RASTERLIB] and
> CURSESTKLIB [previously named VASKLIB]) into one toolkit lib so that
> there is, when possible, one zooming version consistent accross the
> different graphical programs.

aside: will KerGIS stick with Curses/TclTk for the GUI or switch to
something more "modern"?


Hamish

From hamish_nospam at yahoo.com  Wed Oct  4 03:36:42 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Oct  4 03:36:49 2006
Subject: [GRASS-dev] [bug #3224] (grass) r.terraflow does not compile
	(Solaris2.9/Sparc)
In-Reply-To: <20061003114059.5E38E1006B0@lists.intevation.de>
References: <20061003114059.5E38E1006B0@lists.intevation.de>
Message-ID: <20061004143642.0964bc0c.hamish_nospam@yahoo.com>

Markus Neteler via RT wrote:
> Report from Harri:
> 
> after a very long time, I managed to get back into compiling GRASS on
> Solaris2.9/Sparc.
> 
> r.terraflow:
> 
> Does not compile, complains about:
> "direction.h", line 50: Error: Could not open include file<ostream.h>.
> 
> Which in Solaris is <iostream.h> (or <iostream> for standard mode
> libraries which use namespaces.) The same goes also for
> IOStream/include/empq_impl.h
> The test present in both these cases about whether the compiler is GNU 3
> with subnumber 1 or larger excludes the new GNU 4 compilers, which is
> probably not the intention. It also excludes the Solaris CC, and the
> system currently recommends using <iostrem> while <iostrem.h> is not
> standard and deprecated.
> 
> Then, in the main.cc on line 333:
> "main.cc", line 333: Error: The function "ctime_r" must have a
> prototype."


common.cc starts with:
#include <sys/types.h>
#include <sys/mman.h>
#include <ctype.h>

#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
#include <ostream>
#else
#include <ostream.h>
#endif

#include <iostream>
using namespace std;

#include "common.h"



gcc (g++) 3.0 shipped with headers without the ".h", except for ostream.
all others dropped the ".h" at gcc 2.95?
after gcc 3.1 all ".h" are gone.


maybe we need to extend these tests to be less gcc centric.


"ostream" != "iostream"

$ ll /usr/include/c++/3.3/ | grep stream
-rw-r--r--  1 root root 24834 May 25  2005 fstream
-rw-r--r--  1 root root  3041 May 25  2005 iostream
-rw-r--r--  1 root root 27292 May 25  2005 istream
-rw-r--r--  1 root root 18353 May 25  2005 ostream
-rw-r--r--  1 root root 20575 May 25  2005 sstream
-rw-r--r--  1 root root 31972 May 25  2005 streambuf

but iostream #includes both <istream> and <ostream>



Hamish

From hamish_nospam at yahoo.com  Wed Oct  4 03:52:34 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Oct  4 03:52:42 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune -	'thresh'
	interpreted wrong?
In-Reply-To: <20061003130641.GI25302@bartok.itc.it>
References: <4521640D.3030308@o2.pl>
	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>
	<452252AF.5040605@o2.pl> <4522565C.5050400@club.worldonline.be>
	<20061003123316.GF25302@bartok.itc.it> <45225DF2.1010802@o2.pl>
	<20061003130641.GI25302@bartok.itc.it>
Message-ID: <20061004145234.39c9930b.hamish_nospam@yahoo.com>

Markus Neteler wrote:
> On Tue, Oct 03, 2006 at 02:56:18PM +0200, Maciej Sieczka wrote:
> > Markus Neteler wrote:
> > > On Tue, Oct 03, 2006 at 02:23:56PM +0200, Moritz Lennert wrote:
> > 
> > >> I would guess that the prune tool prunes all 
> > >> "unneccessary" nodes on a straight line, i.e. any node which is
> > >not  > necessary to define the line, and this whatever the
> > >threshold. >
> > >> The threshold only applies in cases of change of direction (i.e.
> > >angles). >
> > >> Just another example of the need for much more documentation for 
> > >> v.clean, including example diagrams like the one for the rmsa
> > >tool.
> > 
> > > Fully agreed...
> > 
> > Markus,
> > 
> > Agreed regarding what?
> 
> ... regarding that more documentation is needed.
>  
> ...
> > And I need to know exactly how the thresh in prune works, as I'm
> > using it for my work. The result will be a script that I'm going to
> > publish. Please - if anybody knows, tell me. I'd love to update the
> > manual accordingly.
> 
> Apparently it can be only reverse engineered (luckily it's FOSS).
> I was not too happy with my attempts to use the prune algorithm,
> I don't think that it works reasonable well.
> 
> But this is an old story:
> http://grass.itc.it/pipermail/grassuser/1995-January/012655.html
> http://grass.itc.it/pipermail/grassuser/2006-July/035373.html
> http://grass.itc.it/pipermail/grassuser/2006-August/035529.html
> 
> The first mail indicates that the problem is known and wasn't
> resolved so far. Time to switch to another algorithm :-)


so the existing tool acts like:
 v.clean tool=simplify_without_geographic_change"
? (removes redundant verticies in a line (angle==0))

and the Douglas-Peucker method could be called tool=generalize  ?

??

to me the meaning of "prune" is ambiguous.

v.clean --help:
  prune: remove vertices in threshold from lines and boundaries, boundary
is pruned only if topology is not damaged (new intersection, changed
attachement of centroid), first and last segment of the boundary is
never changed


this sounds like it is meant do "generalize".

???

need to do some tests & create screen shots (eg v.voronoi help page)
to be sure.


Hamish

From tlaronde at polynum.com  Wed Oct  4 03:57:52 2006
From: tlaronde at polynum.com (tlaronde@polynum.com)
Date: Wed Oct  4 03:55:12 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061004141702.2e6ae98a.hamish_nospam@yahoo.com>
References: <C144AD5E.F3FA%michael.barton@asu.edu>
	<20061002213704.64212af2.hamish_nospam@yahoo.com>
	<20061002112201.GA912@polynum.com>
	<20061003165211.5bba21fb.hamish_nospam@yahoo.com>
	<20061003102722.GA165@polynum.com>
	<20061004141702.2e6ae98a.hamish_nospam@yahoo.com>
Message-ID: <20061004015752.GA1492@polynum.com>

On Wed, Oct 04, 2006 at 02:17:02PM +1300, Hamish wrote:
> 
> aside: will KerGIS stick with Curses/TclTk for the GUI or switch to
> something more "modern"?

KerGIS doesn't use TclTk and won't.
I use the term "tk" for "ToolKit", but this has nothing to do with 
TclTk. This is simply a naming scheme to show that some library is
a tool kit library built upon a more basic set of facilities
(cursestk is the tool kit built upon Curses, and was called VASKLIB).
The basic libraries are found in lib/, and the toolkits in usr/lib.

The aim is to clearly separate processing of data from interfaces.
There will be, finally, 3 versions and, if done correctly, people
wanting another interface could do it easily (when the split is
done) :

Cursestk/Drawlib /* DRAWLIB was RASTERLIB. This one exists */

Athena/Drawlib	/* because Athena is standard with X distribution */

Motif/Drawlib

In fact, using the references for curses and the Athena widget (both are
simple) is a good help to see the common things about the gestion of
windows, and is not a bad idea before going to something more complex.
And I want to stick strictly to C, hence the choices.

The 3 will give exactly the same possibilities (with the same shortcuts)
even if the interfaces are obviously quite different. On working on this
I will see if it is possible to derive the 3 versions from some kind of
common description (I have some very fuzzy ideas at the moment,
experience will tell if it is achievable or not; but the first step is
to separate processing from interface, in v.digit(1) for example).

I don't plan to drop the curses interface: it has its uses, and text
menus (with short cuts) contrary to pixmap buttons are something I 
personnally like (I have a huge experience with CAD programs that I use
almost exclusively with keyboard, whether shortcuts or typing commands
--- Microstation for example; and in fact I want to add a command line
with a basic interpreter to v.digit(1) for example to launch facilities
on the map displayed [or to register the operations for replay or undo]).

The work on the interfaces is planned for after the release of 1.0. (not
for 1.0 that has already been delayed too much).

KerGIS has less requisites than GPL GRASS since it is aimed to run on a
POSIX node, period (I don't care about Windows users: if they want to be
able to run it they have to provide a POSIX environment
and this is their problem, not mine), and since only X Window will be
supported by default (others can port the DRAWLIB to other things if
they want).

But I'm a freak ;)
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

From michael.barton at asu.edu  Wed Oct  4 05:35:08 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Oct  4 05:35:17 2006
Subject: [GRASS-dev] Vote for your favorite zoom out
In-Reply-To: <20061004135953.032526f4.hamish_nospam@yahoo.com>
Message-ID: <C14879FC.F5EB%michael.barton@asu.edu>

OK. Now I understand you. Sorry for being dense.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam@yahoo.com>
> Date: Wed, 4 Oct 2006 13:59:53 +1300
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] Vote for your favorite zoom out
> 
> Michael Barton wrote:
>>> Michael Barton wrote:
>>>> This already exists. No need to right click. Just select zoom out
>>> tool > and click.
>>> 
>>> A point I was trying to make is that selecting another tool is slow
>>> when the task is zooming in & out to get the region "just right".
>>> That's why I wanted right click zoom-out in addition to the formal
>>> zoom out tool. Optional keyboard shortcuts to tools sort of help but
>>> are impossible to remember.
>>> 
>> 
>> Agreed. If you already know this and meant something else, please just
>> disregard. What I meant to say is that it's the same tool. Click and
>> drag to draw a zoom box. Just click and it simply zooms out by a set
>> amount. No need to change tools.
> 
> 
> I was trying to say: allow zoom *OUT* using a right click when using the
> zoom *IN* tool.
> 
> 
> Hamish

From michael.barton at asu.edu  Wed Oct  4 05:58:47 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Wed Oct  4 05:58:55 2006
Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55BBD@s5-dar-r1.nrn.nrcan.gc.ca>
Message-ID: <C1487F87.F5F1%michael.barton@asu.edu>

I found 2 others and want to make sure I need to change them. They are in
v.transform and r.univar.

Do both need to be changed from -q to --q?

I can change them tomorrow if they do.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: "Patton, Eric" <epatton@nrcan.gc.ca>
> Date: Tue, 3 Oct 2006 16:11:46 -0300
> To: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
> Cc: "'grass-dev@grass.itc.it '" <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
> 
> I noticed that the d.histogram tool in gis.m now gives an error because it
> uses the -q flag when it calls d.histogram. A few of my own scripts need to
> be updated to the quiet/verbose changes in parser as well.
> 
> Maybe everyone could keep an eye out for GUI tools that call programs using
> the old -q or -v flags?
> 
> ~ Eric.
> 
> 

From hamish_nospam at yahoo.com  Wed Oct  4 06:22:50 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Oct  4 06:23:13 2006
Subject: [GRASS-dev] [bug #5183] (grass) g.region -a: different number
	of	rows if using 'res' or 'nsres' and 'ewres' -
	though	res=nsres=ewres=10!
In-Reply-To: <17697.54872.185035.357791@cerise.gclements.plus.com>
References: <20061002214856.DE2D91005C3@lists.intevation.de>
	<17697.54872.185035.357791@cerise.gclements.plus.com>
Message-ID: <20061004172250.3211b0ef.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> 
> Previously, ewres=/nsres= rounded to an even multiple of the
> resolution, whereas res= simply rounded to a multiple.

I always wondered why that 2* ... /2  stuff was in there...


Hamish

From jachym.cepicky at centrum.cz  Wed Oct  4 06:54:40 2006
From: jachym.cepicky at centrum.cz (Jachym Cepicky)
Date: Wed Oct  4 06:54:57 2006
Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
In-Reply-To: <C1487F87.F5F1%michael.barton@asu.edu>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BBD@s5-dar-r1.nrn.nrcan.gc.ca>
	<C1487F87.F5F1%michael.barton@asu.edu>
Message-ID: <20061004045440.GA6755@localdomain>

hi,
everybody is welcome to hound after -q/-v flags and fprintf functions.
i'm progressing only slowly.

thank you

jachym

On Tue, Oct 03, 2006 at 08:58:47PM -0700, Michael Barton wrote:
> I found 2 others and want to make sure I need to change them. They are in
> v.transform and r.univar.
> 
> Do both need to be changed from -q to --q?
> 
> I can change them tomorrow if they do.
> 
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
> 
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
> 
> 
> 
> > From: "Patton, Eric" <epatton@nrcan.gc.ca>
> > Date: Tue, 3 Oct 2006 16:11:46 -0300
> > To: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
> > Cc: "'grass-dev@grass.itc.it '" <grass-dev@grass.itc.it>
> > Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
> > 
> > I noticed that the d.histogram tool in gis.m now gives an error because it
> > uses the -q flag when it calls d.histogram. A few of my own scripts need to
> > be updated to the quiet/verbose changes in parser as well.
> > 
> > Maybe everyone could keep an eye out for GUI tools that call programs using
> > the old -q or -v flags?
> > 
> > ~ Eric.
> > 
> > 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-- 
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
Department of Geoinformation Technologies 
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL:    http://mapserver.mendelu.cz
Tel.:   +420 545 134 514
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061004/1fb77808/attachment.bin
From twiens at interbaun.com  Wed Oct  4 06:56:22 2006
From: twiens at interbaun.com (Trevor Wiens)
Date: Wed Oct  4 06:56:44 2006
Subject: [GRASS-dev] Re: [GRASS-user] r.what and d.what.rast
In-Reply-To: <000501c6e63d$ae6695f0$7a4291c1@ceh.cedex.es>
References: <000501c6e63d$ae6695f0$7a4291c1@ceh.cedex.es>
Message-ID: <20061003225622.74b6887f@localhost.localdomain>

On Mon, 2 Oct 2006 18:13:16 +0200
Javier ?lvarez Rodr?guez wrote:

> Hi all,
> My problem is about I'm obtaining different results when using d.what.rast
> and r.what. 
> Using interactively d.what.rast on a map named bas, I obtain these
> results:
> 
> 361421.875(E) 4540953.125(N)
> bas in DATOS, quant   (854)
> bas in DATOS, actual  (854.000000)
> 
> Then I write x and y coordinates in a file named pp3.txt 
> 
> 361421 4540953 (no matter real or integer coordinates)
> 
> and when using r.what
> r.what bas@DATOS < pp3.txt
> result is 860

I'm not sure of the cause, but in doing some tests of the same data
set, it would appear that r.what is probably reporting incorrectly.

I looked at the code briefly and can't see any obvious errors, but I'm
ccing the developers list to see if anyone has seen this bug before.

T
-- 
Trevor Wiens 
twiens@interbaun.com

The significant problems that we face cannot be solved at the same 
level of thinking we were at when we created them. 
(Albert Einstein)

From hamish_nospam at yahoo.com  Wed Oct  4 07:48:27 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Oct  4 07:48:49 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <20061002100739.GC18791@bartok.itc.it>
References: <0E5A77B55A57D511BB3F0002A537C26208C55B86@s5-dar-r1.nrn.nrcan.gc.ca>
	<20061002183836.1f3596c6.hamish_nospam@yahoo.com>
	<20061002100739.GC18791@bartok.itc.it>
Message-ID: <20061004184827.63af7f95.hamish_nospam@yahoo.com>

Markus Neteler wrote:
> > The sooner the GDP is migrated out of the web
> > site CVS and into the wiki and truely group maintained the better
> > for everyone IMO.  [ps. -- is the wiki being backed up?
> 
> Yes, backup'ed.
> 
> > available as .zip
> > for burning to a CD for access to help when in the field?]
> 
> Nice to have. How to implement it?

cron job on the wiki server, downloadable as an attachment from the wiki
server?


> A related consideration:
> Should we move to a Content Management System like Drupal or
> Joomla? If yes, will folks participate to migrate the Web
> site contents? The only major problem is how to feed the
> mirror sites (make a static copy overnight and rsync that?).

what's the advantage over SVN with a wider range of folks with write
access? We want to keep some sort of control over who can edit the core
website pages, but not restrict it to programmers only.


Hamish

From benjamin.ducke at ufg.uni-kiel.de  Wed Oct  4 09:04:22 2006
From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke)
Date: Wed Oct  4 08:52:41 2006
Subject: [GRASS-user] Re: [GRASS-dev] Scripts still using "-q" instead
	of	"--q"
In-Reply-To: <20061004045440.GA6755@localdomain>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BBD@s5-dar-r1.nrn.nrcan.gc.ca>	<C1487F87.F5F1%michael.barton@asu.edu>
	<20061004045440.GA6755@localdomain>
Message-ID: <45235CF6.1090103@ufg.uni-kiel.de>

Sorry, I missed the most important part of this discussion.
What's the problem with the fprintf() functions and
what should they be replaced with?

Jachym Cepicky wrote:
> hi,
> everybody is welcome to hound after -q/-v flags and fprintf functions.
> i'm progressing only slowly.
> 
> thank you
> 
> jachym
> 
> On Tue, Oct 03, 2006 at 08:58:47PM -0700, Michael Barton wrote:
> 
>>I found 2 others and want to make sure I need to change them. They are in
>>v.transform and r.univar.
>>
>>Do both need to be changed from -q to --q?
>>
>>I can change them tomorrow if they do.
>>
>>Michael
>>__________________________________________
>>Michael Barton, Professor of Anthropology
>>School of Human Evolution & Social Change
>>Center for Social Dynamics & Complexity
>>Arizona State University
>>
>>phone: 480-965-6213
>>fax: 480-965-7671
>>www: http://www.public.asu.edu/~cmbarton
>>
>>
>>
>>
>>>From: "Patton, Eric" <epatton@nrcan.gc.ca>
>>>Date: Tue, 3 Oct 2006 16:11:46 -0300
>>>To: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
>>>Cc: "'grass-dev@grass.itc.it '" <grass-dev@grass.itc.it>
>>>Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
>>>
>>>I noticed that the d.histogram tool in gis.m now gives an error because it
>>>uses the -q flag when it calls d.histogram. A few of my own scripts need to
>>>be updated to the quiet/verbose changes in parser as well.
>>>
>>>Maybe everyone could keep an eye out for GUI tools that call programs using
>>>the old -q or -v flags?
>>>
>>>~ Eric.
>>>
>>>
>>
>>_______________________________________________
>>grass-dev mailing list
>>grass-dev@grass.itc.it
>>http://grass.itc.it/mailman/listinfo/grass-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> grassuser mailing list
> grassuser@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser

-- 
Benjamin Ducke, M.A.
Arch?oinformatik
(Archaeoinformation Science)
Institut f?r Ur- und Fr?hgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universit?t zu Kiel
Johanna-Mestorf-Stra?e 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

From hamish_nospam at yahoo.com  Wed Oct  4 08:55:13 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed Oct  4 08:58:25 2006
Subject: [GRASS-dev] [bug report] gis.m: error when launching
	v.db.connect from menu with DEBUG set to 3
In-Reply-To: <45227FD7.9090700@club.worldonline.be>
References: <45227FD7.9090700@club.worldonline.be>
Message-ID: <20061004195513.5eb5a246.hamish_nospam@yahoo.com>

Moritz Lennert wrote:
> 
> After 'g.gisenv set=DEBUG=3' the menu entry corresponding to 
> v.db.connect (vector -> vector<->database connection -> set
> connection)  provokes an error.
> 
> No more error after setting DEBUG back with g.gisenv set=DEBUG.
> 
> Don't know if this also concerns other modules.


could this (again) be a case of a huge flood of stderr messages
overwhelming TclTk?


Hamish

From neteler at itc.it  Wed Oct  4 09:22:30 2006
From: neteler at itc.it (Markus Neteler)
Date: Wed Oct  4 09:22:40 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <20061004184827.63af7f95.hamish_nospam@yahoo.com>
References: <0E5A77B55A57D511BB3F0002A537C26208C55B86@s5-dar-r1.nrn.nrcan.gc.ca>
	<20061002183836.1f3596c6.hamish_nospam@yahoo.com>
	<20061002100739.GC18791@bartok.itc.it>
	<20061004184827.63af7f95.hamish_nospam@yahoo.com>
Message-ID: <20061004072230.GA31410@bartok.itc.it>

On Wed, Oct 04, 2006 at 06:48:27PM +1300, Hamish wrote:
> Markus Neteler wrote:
> > > The sooner the GDP is migrated out of the web
> > > site CVS and into the wiki and truely group maintained the better
> > > for everyone IMO.  [ps. -- is the wiki being backed up?
> > 
> > Yes, backup'ed.
> > 
> > > available as .zip
> > > for burning to a CD for access to help when in the field?]
> > 
> > Nice to have. How to implement it?
> 
> cron job on the wiki server, downloadable as an attachment from the wiki
> server?

You mean the MySQL DB? I would need a pointer how to do that. 
 
> > A related consideration:
> > Should we move to a Content Management System like Drupal or
> > Joomla? If yes, will folks participate to migrate the Web
> > site contents? The only major problem is how to feed the
> > mirror sites (make a static copy overnight and rsync that?).
> 
> what's the advantage over SVN with a wider range of folks with write
> access? We want to keep some sort of control over who can edit the core
> website pages, but not restrict it to programmers only.

After 4-5 years of Web pages in CVS, I don't think that a change
to SVN will make a big change.
Content Management Systems usually come with user roles, so that pages
could be maintained at various levels. But I see, interest in
CMS is also fairly low...

Markus

From benjamin.ducke at ufg.uni-kiel.de  Wed Oct  4 10:34:59 2006
From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke)
Date: Wed Oct  4 10:23:04 2006
Subject: [GRASS-dev] Scripts still using "-q" instead of	"--q"
In-Reply-To: <20061004045440.GA6755@localdomain>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BBD@s5-dar-r1.nrn.nrcan.gc.ca>	<C1487F87.F5F1%michael.barton@asu.edu>
	<20061004045440.GA6755@localdomain>
Message-ID: <45237233.2000209@ufg.uni-kiel.de>

Sorry, I missed the most important part of this discussion.
What's the problem with the fprintf() functions and
what should they be replaced with?

Jachym Cepicky wrote:
> hi,
> everybody is welcome to hound after -q/-v flags and fprintf functions.
> i'm progressing only slowly.
> 
> thank you
> 
> jachym
> 
> On Tue, Oct 03, 2006 at 08:58:47PM -0700, Michael Barton wrote:
> 
>>I found 2 others and want to make sure I need to change them. They are in
>>v.transform and r.univar.
>>
>>Do both need to be changed from -q to --q?
>>
>>I can change them tomorrow if they do.
>>
>>Michael
>>__________________________________________
>>Michael Barton, Professor of Anthropology
>>School of Human Evolution & Social Change
>>Center for Social Dynamics & Complexity
>>Arizona State University
>>
>>phone: 480-965-6213
>>fax: 480-965-7671
>>www: http://www.public.asu.edu/~cmbarton
>>
>>
>>
>>
>>>From: "Patton, Eric" <epatton@nrcan.gc.ca>
>>>Date: Tue, 3 Oct 2006 16:11:46 -0300
>>>To: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
>>>Cc: "'grass-dev@grass.itc.it '" <grass-dev@grass.itc.it>
>>>Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
>>>
>>>I noticed that the d.histogram tool in gis.m now gives an error because it
>>>uses the -q flag when it calls d.histogram. A few of my own scripts need to
>>>be updated to the quiet/verbose changes in parser as well.
>>>
>>>Maybe everyone could keep an eye out for GUI tools that call programs using
>>>the old -q or -v flags?
>>>
>>>~ Eric.
>>>
>>>
>>
>>_______________________________________________
>>grass-dev mailing list
>>grass-dev@grass.itc.it
>>http://grass.itc.it/mailman/listinfo/grass-dev
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> grassuser mailing list
> grassuser@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser

-- 
Benjamin Ducke, M.A.
Arch?oinformatik
(Archaeoinformation Science)
Institut f?r Ur- und Fr?hgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universit?t zu Kiel
Johanna-Mestorf-Stra?e 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg


From mlennert at club.worldonline.be  Wed Oct  4 10:50:12 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Oct  4 10:49:56 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune
	-	'thresh'	interpreted wrong?
In-Reply-To: <452292BC.4070201@o2.pl>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>	<4522565C.5050400@club.worldonline.be>	<20061003123316.GF25302@bartok.itc.it>
	<45225DF2.1010802@o2.pl>	<45226203.5070807@club.worldonline.be>
	<45228510.4080807@o2.pl>	<45228F47.7070804@club.worldonline.be>
	<452292BC.4070201@o2.pl>
Message-ID: <452375C4.9010205@club.worldonline.be>

Maciej Sieczka wrote:
> Moritz Lennert wrote:

>> Maybe if you push hard enough someone will "just do it" - Dylan
>> mentioned it as a potentially "fun" project: 
>> http://grass.itc.it/pipermail/grassuser/2006-August/035529.html ;-)
>> and actually links to an implementation in c++, which actually looks
>> like more or less usable C to me).
> 
> Sure it would be a good addition to Grass, but:
> 
> 1. I need a tool to remove the vertices from a line based on a given
> threshold (understood as a distance from one vertex to another).
> According to v.clean manual it should be able to do it, but it's not.
> (I think I know how to workaround it by v.out.acii | awk | v.in.ascii.
> So I should be OK.)

To echo Hamish' question: Do you need to remove vertices from lines 
without changing the form of the line, or do you want to generalize the 
form of the line (in the way that is shown here: 
http://mpa.itc.it/markus/como2006/img9.html ?


> 2. This is a bug or a lacking documention, so either should be fixed,
> no matter what other pruning algorithm is added to Grass.

It actually also seems to be an ambiguity as to what pruning actually means:

- remove unnecessary nodes, or
- generalize

?

> 
> 3. We can't remove any functionality in Grass 6, only add new.
> 

We cannot change the interface of modules, but we can do what we want in 
terms of algorithms used behind this interface. Especially if the 
current algorithm is buggy.


Moritz

From tutey at o2.pl  Wed Oct  4 11:14:05 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Wed Oct  4 11:14:07 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune
	-	'thresh'	interpreted wrong?
In-Reply-To: <452375C4.9010205@club.worldonline.be>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>	<4522565C.5050400@club.worldonline.be>	<20061003123316.GF25302@bartok.itc.it>
	<45225DF2.1010802@o2.pl>	<45226203.5070807@club.worldonline.be>
	<45228510.4080807@o2.pl>	<45228F47.7070804@club.worldonline.be>
	<452292BC.4070201@o2.pl> <452375C4.9010205@club.worldonline.be>
Message-ID: <45237B5D.9040106@o2.pl>

Moritz Lennert wrote:

> To echo Hamish' question: Do you need to remove vertices from lines
> without changing the form of the line, or do you want to generalize the
> form of the line (in the way that is shown here:
> http://mpa.itc.it/markus/como2006/img9.html ?

The latter. I want to remove all the vertices that are distant from the
line starting node not more than the give thresh. A line:

x--o1-o2-->----o3--x

"x" - node
"o" - vertex
">" - line direction
"-" - 1 length unit

thresh=3 would remove o1, thresh=5 the o1 and o2 and so on

>> 2. This is a bug or a lacking documention, so either should be fixed,
>> no matter what other pruning algorithm is added to Grass.
> 
> It actually also seems to be an ambiguity as to what pruning actually
> means:
>
> - remove unnecessary nodes, or
> - generalize

Using that terminology - according to current Grass documentation
(v.clean manual and the source code comments) v.clean tool=prune means
"generalize".

Maciek

From mlennert at club.worldonline.be  Wed Oct  4 11:26:36 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Wed Oct  4 11:26:20 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune
	-	'thresh'	interpreted wrong?
In-Reply-To: <45237B5D.9040106@o2.pl>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>	<4522565C.5050400@club.worldonline.be>	<20061003123316.GF25302@bartok.itc.it>
	<45225DF2.1010802@o2.pl>	<45226203.5070807@club.worldonline.be>
	<45228510.4080807@o2.pl>	<45228F47.7070804@club.worldonline.be>
	<452292BC.4070201@o2.pl> <452375C4.9010205@club.worldonline.be>
	<45237B5D.9040106@o2.pl>
Message-ID: <45237E4C.50604@club.worldonline.be>

Maciej Sieczka wrote:
> Moritz Lennert wrote:
> 
>> To echo Hamish' question: Do you need to remove vertices from lines
>> without changing the form of the line, or do you want to generalize the
>> form of the line (in the way that is shown here:
>> http://mpa.itc.it/markus/como2006/img9.html ?
> 
> The latter. I want to remove all the vertices that are distant from the
> line starting node not more than the give thresh. A line:
> 
> x--o1-o2-->----o3--x
> 
> "x" - node
> "o" - vertex
> ">" - line direction
> "-" - 1 length unit
> 
> thresh=3 would remove o1, thresh=5 the o1 and o2 and so on

This sounds like something still different, as you make it dependent on 
the starting node. I don't think that the prune tool was ever thought to 
work this way.

Moritz

From jachym.cepicky at centrum.cz  Wed Oct  4 11:39:51 2006
From: jachym.cepicky at centrum.cz (Jachym Cepicky)
Date: Wed Oct  4 11:39:52 2006
Subject: [GRASS-dev] Scripts still using "-q" instead of	"--q"
In-Reply-To: <45237233.2000209@ufg.uni-kiel.de>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BBD@s5-dar-r1.nrn.nrcan.gc.ca>
	<C1487F87.F5F1%michael.barton@asu.edu>
	<20061004045440.GA6755@localdomain>
	<45237233.2000209@ufg.uni-kiel.de>
Message-ID: <20061004093950.GB15753@localdomain>

hi,

On Wed, Oct 04, 2006 at 10:34:59AM +0200, Benjamin Ducke wrote:
> Sorry, I missed the most important part of this discussion.
> What's the problem with the fprintf() functions and
> what should they be replaced with?

sometimes, fprintf is used on places, where G_message or G_warning
should be used, so the user can controll level of verbosity of grass
modules globaly.

for printing results of some calculation, fprintf(stdout,,) should be used

jachym

> 
> Jachym Cepicky wrote:
> >hi,
> >everybody is welcome to hound after -q/-v flags and fprintf functions.
> >i'm progressing only slowly.
> >
> >thank you
> >
> >jachym
> >
> >On Tue, Oct 03, 2006 at 08:58:47PM -0700, Michael Barton wrote:
> >
> >>I found 2 others and want to make sure I need to change them. They are in
> >>v.transform and r.univar.
> >>
> >>Do both need to be changed from -q to --q?
> >>
> >>I can change them tomorrow if they do.
> >>
> >>Michael
> >>__________________________________________
> >>Michael Barton, Professor of Anthropology
> >>School of Human Evolution & Social Change
> >>Center for Social Dynamics & Complexity
> >>Arizona State University
> >>
> >>phone: 480-965-6213
> >>fax: 480-965-7671
> >>www: http://www.public.asu.edu/~cmbarton
> >>
> >>
> >>
> >>
> >>>From: "Patton, Eric" <epatton@nrcan.gc.ca>
> >>>Date: Tue, 3 Oct 2006 16:11:46 -0300
> >>>To: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
> >>>Cc: "'grass-dev@grass.itc.it '" <grass-dev@grass.itc.it>
> >>>Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
> >>>
> >>>I noticed that the d.histogram tool in gis.m now gives an error because 
> >>>it
> >>>uses the -q flag when it calls d.histogram. A few of my own scripts need 
> >>>to
> >>>be updated to the quiet/verbose changes in parser as well.
> >>>
> >>>Maybe everyone could keep an eye out for GUI tools that call programs 
> >>>using
> >>>the old -q or -v flags?
> >>>
> >>>~ Eric.
> >>>
> >>>
> >>
> >>_______________________________________________
> >>grass-dev mailing list
> >>grass-dev@grass.itc.it
> >>http://grass.itc.it/mailman/listinfo/grass-dev
> >
> >
> >
> >------------------------------------------------------------------------
> >
> >_______________________________________________
> >grassuser mailing list
> >grassuser@grass.itc.it
> >http://grass.itc.it/mailman/listinfo/grassuser
> 
> -- 
> Benjamin Ducke, M.A.
> Arch?oinformatik
> (Archaeoinformation Science)
> Institut f?r Ur- und Fr?hgeschichte
> (Inst. of Prehistoric and Historic Archaeology)
> Christian-Albrechts-Universit?t zu Kiel
> Johanna-Mestorf-Stra?e 2-6
> D 24098 Kiel
> Germany
> 
> Tel.: ++49 (0)431 880-3378 / -3379
> Fax : ++49 (0)431 880-7300
> www.uni-kiel.de/ufg
> 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-- 
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
Department of Geoinformation Technologies 
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL:    http://mapserver.mendelu.cz
Tel.:   +420 545 134 514
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061004/198a757d/attachment.bin
From tutey at o2.pl  Wed Oct  4 11:43:16 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Wed Oct  4 11:43:20 2006
Subject: [GRASS-dev] v.split: what is 'vertices' for?
Message-ID: <45238234.9040506@o2.pl>

I haven't found anything relevant in the manual, lists archives, the BT
or the source code, so I'm asking here.

There is a straight line made of only 2 nodes:

$ v.info -t line
nodes=2
points=0
lines=1
boundaries=0
centroids=0
areas=0
islands=0
faces=0
kernels=0
primitives=1
map3d=0

And it has a category assigned:

$ v.category -g line option=report
1 line 1 1 1

I want to add a vertex to it.

According to the manual:

	length=float
	Maximum segment length.

	vertices=integer
	Maximum number of vertices in segment.


There are 2 vertices (nodes) currently. Trying to add a vertex between
them:

$ v.split input=line output=line_split vertices=3

Checking line_split in v.digit proves there are still only 2 vertices -
the nodes themselves; the 3rd vertex in not added.

No matter what is the 'vertices' set to, the outcome is the same. Is
that OK? What am I missing to understand what is the 'vertices' option for?

Maciek

P.S.
Please don't suggest workarounds and stuff. I only want to know what's
 up with v.split.

From tutey at o2.pl  Wed Oct  4 11:53:59 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Wed Oct  4 11:54:03 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune
	-	'thresh'	interpreted wrong?
In-Reply-To: <45237E4C.50604@club.worldonline.be>
References: <4521640D.3030308@o2.pl>	<20061003150518.7e71c9f1.hamish_nospam@yahoo.com>	<452252AF.5040605@o2.pl>	<4522565C.5050400@club.worldonline.be>	<20061003123316.GF25302@bartok.itc.it>
	<45225DF2.1010802@o2.pl>	<45226203.5070807@club.worldonline.be>
	<45228510.4080807@o2.pl>	<45228F47.7070804@club.worldonline.be>
	<452292BC.4070201@o2.pl> <452375C4.9010205@club.worldonline.be>
	<45237B5D.9040106@o2.pl> <45237E4C.50604@club.worldonline.be>
Message-ID: <452384B7.3010801@o2.pl>

Moritz Lennert wrote:

> Maciej Sieczka wrote:

>> Moritz Lennert wrote:

>>> To echo Hamish' question: Do you need to remove vertices from lines
>>> without changing the form of the line, or do you want to generalize the
>>> form of the line (in the way that is shown here:
>>> http://mpa.itc.it/markus/como2006/img9.html ?
>>
>> The latter. I want to remove all the vertices that are distant from the
>> line starting node not more than the give thresh. A line:
>>
>> x--o1-o2-->----o3--x
>>
>> "x" - node
>> "o" - vertex
>> ">" - line direction
>> "-" - 1 length unit
>>
>> thresh=3 would remove o1, thresh=5 the o1 and o2 and so on

> This sounds like something still different, as you make it dependent on
> the starting node.

Still we don't know how the thresh works for pruning.

> I don't think that the prune tool was ever thought to work this way.

You don't know how it works. Then how do you know how it doesn't work :) ?

Getting back to my original post.

The line:

$ echo "L 4 1
	 10 10
	 20 10
	 30 10
	 40 10
	 1     1" | v.in.ascii -n out=line format=standard

Imagine it as:

x-o1-o2-x

"x" - node
"o" - vertex
"-" - 5 length units

$ v.clean input=line output=line_pruned type=line tool=prune thresh=0.04

removes o1,o2. Anything bigger does the same. Anything smaller doensn't
remove any.

Why? Should it be like that or not?

Maciek

From neteler at itc.it  Wed Oct  4 11:58:31 2006
From: neteler at itc.it (Markus Neteler)
Date: Wed Oct  4 11:58:33 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune
	-	'thresh'	interpreted wrong?
In-Reply-To: <452384B7.3010801@o2.pl>
References: <20061003123316.GF25302@bartok.itc.it> <45225DF2.1010802@o2.pl>
	<45226203.5070807@club.worldonline.be> <45228510.4080807@o2.pl>
	<45228F47.7070804@club.worldonline.be> <452292BC.4070201@o2.pl>
	<452375C4.9010205@club.worldonline.be> <45237B5D.9040106@o2.pl>
	<45237E4C.50604@club.worldonline.be> <452384B7.3010801@o2.pl>
Message-ID: <20061004095831.GA32164@bartok.itc.it>

On Wed, Oct 04, 2006 at 11:53:59AM +0200, Maciej Sieczka wrote:
> Moritz Lennert wrote:
...
> > I don't think that the prune tool was ever thought to work this way.
> 
> You don't know how it works. Then how do you know how it doesn't work :) ?

I made numerous tests in the past and it rarely worked as expected.

It also fails completely in LatLong since threshold is literally
taking the degree coords to calculate distances while it should be
the geodetic distance (as -m flag in g.region does).

Markus 

From bernhard at intevation.de  Wed Oct  4 12:59:09 2006
From: bernhard at intevation.de (Bernhard Reiter)
Date: Wed Oct  4 12:59:17 2006
Subject: [GRASS-dev] request tracker r.null -n bug
In-Reply-To: <45223663.1040700@o2.pl>
References: <d7e54a6c0610022232u78e971f1v9163226763f3e53d@mail.gmail.com>
	<45223663.1040700@o2.pl>
Message-ID: <200610041259.11288.bernhard@intevation.de>

On Tuesday 03 October 2006 12:07, Maciej Sieczka wrote:
> Joel Pitt wrote:
> > How are we meant to submit bugs at the current time?
>
> As a temporary workaround please email me with all the details - I'll
> submit the report for you. Do not hesitate.
>
> You can also ask Bernhard Reiter of Intevation (who host the Grass BT)
> to create an account for you.
>
> > Request tracker via the website and via email tells me I don't have
> > permission to submit to the queue (frustratingly it only mentions this
> > after submitting the bug.
>
> That's true and it's too bad indeed. But there where scripted spam
> attacks and in order to block them Intevation cancelled the anonymous
> access. See the thread "spam in bug tracker" in gras-dev archive.

That the report form did not work anymore was a mistake on our side.
We are just trying to reenable to creating of new issues for guest
on the GRASS queue which should solve this problem.
Sascha Wilde is on the task.
Sorry for the inconvenience.


-- 
Managing Director - Owner, www.intevation.net       (Free Software Company)
Germany Coordinator, fsfeurope.org       (Non-Profit Org for Free Software)
www.kolab-konsortium.com   (Email/Groupware Solution, Professional Service)

From neteler at itc.it  Wed Oct  4 13:38:25 2006
From: neteler at itc.it (Markus Neteler)
Date: Wed Oct  4 13:38:26 2006
Subject: [GRASS-dev] r.distance problem: in our out?
Message-ID: <20061004113825.GA1234@bartok.itc.it>

Hi,

for an application I have to calculate the distance between
raster "objects". While this generally works, I have found
that r.distance happily calculates the distance even if
one object is within the other (say, raster pixel over
raster polygon in second map). I would need an indication
somehow that we are *in* (to ignore the distance in this
case).

Spearfish example:

g.region -dp

# extract field #25:
r.mapcalc "myarea=if(fields == 25, 1,null())"

# this archsite falls into field 25:
v.extract archsites out=mypixel list=9
v.to.rast mypixel out=mypixel use=val val=1
r.distance mypixel,myarea 
# -> reports two distant points

# zoom:
g.region n=4926990 s=4925856 w=599850 e=601376 align=myarea
d.mon x0
d.rast myarea
d.vect mypixel col=blue
# visualize distance (d.graph give sometimes random output!):
r.distance mypixel,myarea | awk -F: '{print "move",$4,$5,"\ndraw",$6,$7}' | d.graph -m

# generate points from distance for easier verification:
r.distance mypixel,myarea | awk -F: '{print $4,"|",$5,"\n",$6,"|",$7}' | sed  's+ ++g' | v.in.ascii out=distance
d.vect distance col=yellow

# cleanup:
g.remove rast=myarea,mypixel
g.remove vect=mypixel,distance

###
Problem: There is no indication that we are *within* the area. Maybe a flag is
needed to optionally suppress the result in this case?
Better ideas?

Second problem: The result seems to be underestimated by half a cell
since not the cell edge is taken from the raster polygon boundary 
but the cell center.

Appreciating help,
Markus

From landa.martin at gmail.com  Wed Oct  4 14:23:40 2006
From: landa.martin at gmail.com (Martin Landa)
Date: Wed Oct  4 14:23:45 2006
Subject: [GRASS-user] Re: [GRASS-dev] Scripts still using "-q" instead of
	"--q"
In-Reply-To: <20061004093950.GB15753@localdomain>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BBD@s5-dar-r1.nrn.nrcan.gc.ca>
	<C1487F87.F5F1%michael.barton@asu.edu>
	<20061004045440.GA6755@localdomain> <45237233.2000209@ufg.uni-kiel.de>
	<20061004093950.GB15753@localdomain>
Message-ID: <f8fe65c40610040523t4e8766ffgfac411db0bf2dc65@mail.gmail.com>

Hi,

2006/10/4, Jachym Cepicky <jachym.cepicky@centrum.cz>:

> for printing results of some calculation, fprintf(stdout,,) should be used

nothing new, but anyway it would be nice (?) to replace fprintf
(stdout, ...) function in the source code by a function based on
G_message/G_fatal_error/G_warning ...

Martin

> jachym
>
> >
> > Jachym Cepicky wrote:
> > >hi,
> > >everybody is welcome to hound after -q/-v flags and fprintf functions.
> > >i'm progressing only slowly.
> > >
> > >thank you
> > >
> > >jachym
> > >
> > >On Tue, Oct 03, 2006 at 08:58:47PM -0700, Michael Barton wrote:
> > >
> > >>I found 2 others and want to make sure I need to change them. They are in
> > >>v.transform and r.univar.
> > >>
> > >>Do both need to be changed from -q to --q?
> > >>
> > >>I can change them tomorrow if they do.
> > >>
> > >>Michael
> > >>__________________________________________
> > >>Michael Barton, Professor of Anthropology
> > >>School of Human Evolution & Social Change
> > >>Center for Social Dynamics & Complexity
> > >>Arizona State University
> > >>
> > >>phone: 480-965-6213
> > >>fax: 480-965-7671
> > >>www: http://www.public.asu.edu/~cmbarton
> > >>
> > >>
> > >>
> > >>
> > >>>From: "Patton, Eric" <epatton@nrcan.gc.ca>
> > >>>Date: Tue, 3 Oct 2006 16:11:46 -0300
> > >>>To: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
> > >>>Cc: "'grass-dev@grass.itc.it '" <grass-dev@grass.itc.it>
> > >>>Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
> > >>>
> > >>>I noticed that the d.histogram tool in gis.m now gives an error because
> > >>>it
> > >>>uses the -q flag when it calls d.histogram. A few of my own scripts need
> > >>>to
> > >>>be updated to the quiet/verbose changes in parser as well.
> > >>>
> > >>>Maybe everyone could keep an eye out for GUI tools that call programs
> > >>>using
> > >>>the old -q or -v flags?
> > >>>
> > >>>~ Eric.
> > >>>
> > >>>
> > >>
> > >>_______________________________________________
> > >>grass-dev mailing list
> > >>grass-dev@grass.itc.it
> > >>http://grass.itc.it/mailman/listinfo/grass-dev
> > >
> > >
> > >
> > >------------------------------------------------------------------------
> > >
> > >_______________________________________________
> > >grassuser mailing list
> > >grassuser@grass.itc.it
> > >http://grass.itc.it/mailman/listinfo/grassuser
> >
> > --
> > Benjamin Ducke, M.A.
> > Arch?oinformatik
> > (Archaeoinformation Science)
> > Institut f?r Ur- und Fr?hgeschichte
> > (Inst. of Prehistoric and Historic Archaeology)
> > Christian-Albrechts-Universit?t zu Kiel
> > Johanna-Mestorf-Stra?e 2-6
> > D 24098 Kiel
> > Germany
> >
> > Tel.: ++49 (0)431 880-3378 / -3379
> > Fax : ++49 (0)431 880-7300
> > www.uni-kiel.de/ufg
> >
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev@grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev
>
> --
> Jachym Cepicky
> e-mail: jachym.cepicky@centrum.cz
> URL: http://les-ejk.cz
> GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
> -----------------------------------------
> OFFICE:
> Department of Geoinformation Technologies
> Zemedelska 3
> 613 00, Brno
> Czech Republick
> e-mail: xcepicky@node.mendelu.cz
> URL:    http://mapserver.mendelu.cz
> Tel.:   +420 545 134 514
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2.2 (GNU/Linux)
>
> iD8DBQFFI4FmyKt0uAjU4I8RAomJAJ9MtycA6FGoPSrONJh2js1IyJtd0ACfY3Ir
> M+MONjnxyxf8myruxe7bOqU=
> =xUM8
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> grassuser mailing list
> grassuser@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser
>
>
>


-- 
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

From jachym.cepicky at centrum.cz  Wed Oct  4 14:43:59 2006
From: jachym.cepicky at centrum.cz (Jachym Cepicky)
Date: Wed Oct  4 14:44:04 2006
Subject: [GRASS-user] Re: [GRASS-dev] Scripts still using "-q" instead of
	"--q"
In-Reply-To: <f8fe65c40610040523t4e8766ffgfac411db0bf2dc65@mail.gmail.com>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BBD@s5-dar-r1.nrn.nrcan.gc.ca>
	<C1487F87.F5F1%michael.barton@asu.edu>
	<20061004045440.GA6755@localdomain>
	<45237233.2000209@ufg.uni-kiel.de>
	<20061004093950.GB15753@localdomain>
	<f8fe65c40610040523t4e8766ffgfac411db0bf2dc65@mail.gmail.com>
Message-ID: <20061004124358.GA22287@localdomain>

hi,
i see no reason for this, 

but it's name could be "G_output" and it should *not* put "\n" to the
end of line

jachym

On Wed, Oct 04, 2006 at 02:23:40PM +0200, Martin Landa wrote:
> Hi,
> 
> 2006/10/4, Jachym Cepicky <jachym.cepicky@centrum.cz>:
> 
> >for printing results of some calculation, fprintf(stdout,,) should be used
> 
> nothing new, but anyway it would be nice (?) to replace fprintf
> (stdout, ...) function in the source code by a function based on
> G_message/G_fatal_error/G_warning ...
> 
> Martin
> 
> >jachym
> >
> >>
> >> Jachym Cepicky wrote:
> >> >hi,
> >> >everybody is welcome to hound after -q/-v flags and fprintf functions.
> >> >i'm progressing only slowly.
> >> >
> >> >thank you
> >> >
> >> >jachym
> >> >
> >> >On Tue, Oct 03, 2006 at 08:58:47PM -0700, Michael Barton wrote:
> >> >
> >> >>I found 2 others and want to make sure I need to change them. They are 
> >in
> >> >>v.transform and r.univar.
> >> >>
> >> >>Do both need to be changed from -q to --q?
> >> >>
> >> >>I can change them tomorrow if they do.
> >> >>
> >> >>Michael
> >> >>__________________________________________
> >> >>Michael Barton, Professor of Anthropology
> >> >>School of Human Evolution & Social Change
> >> >>Center for Social Dynamics & Complexity
> >> >>Arizona State University
> >> >>
> >> >>phone: 480-965-6213
> >> >>fax: 480-965-7671
> >> >>www: http://www.public.asu.edu/~cmbarton
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>>From: "Patton, Eric" <epatton@nrcan.gc.ca>
> >> >>>Date: Tue, 3 Oct 2006 16:11:46 -0300
> >> >>>To: "'grassuser@grass.itc.it'" <grassuser@grass.itc.it>
> >> >>>Cc: "'grass-dev@grass.itc.it '" <grass-dev@grass.itc.it>
> >> >>>Subject: [GRASS-dev] Scripts still using "-q" instead of "--q"
> >> >>>
> >> >>>I noticed that the d.histogram tool in gis.m now gives an error 
> >because
> >> >>>it
> >> >>>uses the -q flag when it calls d.histogram. A few of my own scripts 
> >need
> >> >>>to
> >> >>>be updated to the quiet/verbose changes in parser as well.
> >> >>>
> >> >>>Maybe everyone could keep an eye out for GUI tools that call programs
> >> >>>using
> >> >>>the old -q or -v flags?
> >> >>>
> >> >>>~ Eric.
> >> >>>
> >> >>>
> >> >>
> >> >>_______________________________________________
> >> >>grass-dev mailing list
> >> >>grass-dev@grass.itc.it
> >> >>http://grass.itc.it/mailman/listinfo/grass-dev
> >> >
> >> >
> >> >
> >> >------------------------------------------------------------------------
> >> >
> >> >_______________________________________________
> >> >grassuser mailing list
> >> >grassuser@grass.itc.it
> >> >http://grass.itc.it/mailman/listinfo/grassuser
> >>
> >> --
> >> Benjamin Ducke, M.A.
> >> Arch?oinformatik
> >> (Archaeoinformation Science)
> >> Institut f?r Ur- und Fr?hgeschichte
> >> (Inst. of Prehistoric and Historic Archaeology)
> >> Christian-Albrechts-Universit?t zu Kiel
> >> Johanna-Mestorf-Stra?e 2-6
> >> D 24098 Kiel
> >> Germany
> >>
> >> Tel.: ++49 (0)431 880-3378 / -3379
> >> Fax : ++49 (0)431 880-7300
> >> www.uni-kiel.de/ufg
> >>
> >>
> >> _______________________________________________
> >> grass-dev mailing list
> >> grass-dev@grass.itc.it
> >> http://grass.itc.it/mailman/listinfo/grass-dev
> >
> >--
> >Jachym Cepicky
> >e-mail: jachym.cepicky@centrum.cz
> >URL: http://les-ejk.cz
> >GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
> >-----------------------------------------
> >OFFICE:
> >Department of Geoinformation Technologies
> >Zemedelska 3
> >613 00, Brno
> >Czech Republick
> >e-mail: xcepicky@node.mendelu.cz
> >URL:    http://mapserver.mendelu.cz
> >Tel.:   +420 545 134 514
> >
> >
> >-----BEGIN PGP SIGNATURE-----
> >Version: GnuPG v1.4.2.2 (GNU/Linux)
> >
> >iD8DBQFFI4FmyKt0uAjU4I8RAomJAJ9MtycA6FGoPSrONJh2js1IyJtd0ACfY3Ir
> >M+MONjnxyxf8myruxe7bOqU=
> >=xUM8
> >-----END PGP SIGNATURE-----
> >
> >
> >_______________________________________________
> >grassuser mailing list
> >grassuser@grass.itc.it
> >http://grass.itc.it/mailman/listinfo/grassuser
> >
> >
> >
> 
> 
> -- 
> Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

-- 
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
Department of Geoinformation Technologies 
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL:    http://mapserver.mendelu.cz
Tel.:   +420 545 134 514
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061004/cea99d20/attachment.bin
From dylan.beaudette at gmail.com  Wed Oct  4 19:08:07 2006
From: dylan.beaudette at gmail.com (Dylan Beaudette)
Date: Wed Oct  4 18:42:45 2006
Subject: [GRASS-dev] Re: [GRASS-user] v.clean tool=prune
	=?iso-8859-1?q?-=09=27thresh=27=09interpreted?= wrong?
In-Reply-To: <20061004095831.GA32164@bartok.itc.it>
References: <20061003123316.GF25302@bartok.itc.it> <452384B7.3010801@o2.pl>
	<20061004095831.GA32164@bartok.itc.it>
Message-ID: <200610041008.07764.dylan.beaudette@gmail.com>

On Wednesday 04 October 2006 02:58, Markus Neteler wrote:
> On Wed, Oct 04, 2006 at 11:53:59AM +0200, Maciej Sieczka wrote:
> > Moritz Lennert wrote:
>
> ...
>
> > > I don't think that the prune tool was ever thought to work this way.
> >
> > You don't know how it works. Then how do you know how it doesn't work :)
> > ?
>
> I made numerous tests in the past and it rarely worked as expected.
>
> It also fails completely in LatLong since threshold is literally
> taking the degree coords to calculate distances while it should be
> the geodetic distance (as -m flag in g.region does).
>
> Markus
>

This looks like a good opportunity to replace the "prune" option with the DP 
algorithm from the GMT source. As mentioned previously, the actual source 
code is quite compact. From what I can tell it would only require a couple 
things:

1. incorporation of GRASS data types (maybe, as it works with list of 
coordinates)
2. removal of Lat/long -> kilometer conversions  : i.e. generalize and add 
CASE statements for cartesian vs. spherical coordinates
3. testing

Anyone have others to add? 

Quoting Markus, here is the link;
http://www.ngdc.noaa.gov/mgg/shorelines/data/gshhs/version1.3/
-> gshhs_1.5_src.tbz
? ?-> gshhs/gshhs_dp.c


cheers,

-- 
Dylan Beaudette
Soils and Biogeochemistry Graduate Group
University of California at Davis
530.754.7341

From rez at touchofmadness.com  Wed Oct  4 22:08:55 2006
From: rez at touchofmadness.com (Brad Douglas)
Date: Wed Oct  4 22:09:03 2006
Subject: [GRASS-dev] [bug #5182] (grass) parser: allows for '@' in map
	names
In-Reply-To: <20061002202012.07F8E1005CE@lists.intevation.de>
References: <20061002202012.07F8E1005CE@lists.intevation.de>
Message-ID: <1159992535.2593.10.camel@devel>

On Mon, 2006-10-02 at 22:20 +0200, Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5182
> -------------------------------------------------------------------------
> 
> Subject: parser: allows for '@' in map names

Fixed in CVS.


-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785

From rez at touchofmadness.com  Thu Oct  5 05:35:35 2006
From: rez at touchofmadness.com (Brad Douglas)
Date: Thu Oct  5 05:35:49 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full
	path to dsn is missing
In-Reply-To: <20061003113721.CAC1D1006A9@lists.intevation.de>
References: <20061003113721.CAC1D1006A9@lists.intevation.de>
Message-ID: <1160019335.2593.51.camel@devel>

On Tue, 2006-10-03 at 13:37 +0200, Maciek Sieczka via RT wrote:
> hamish_nospam@yahoo.com wrote (Tue, Oct 3 2006 05:47:19):
> 
> > Maciek Sieczka via RT wrote:
> 
> >> $ v.in.ogr dsn=shorter/ 
>  
> > what if you leave off the trailing "/" in the dsn?
> 
> It doesn't change anything. Still a segfault if
> "dsn=force_lrconnect_cl_onlycat139" and no segfault if "dsn=shorter". Looks
> like the string length is the key.

Should be fixed in CVS.


-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785

From hamish_nospam at yahoo.com  Thu Oct  5 08:53:54 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu Oct  5 08:54:00 2006
Subject: [GRASS-dev] v.split: what is 'vertices' for?
In-Reply-To: <45238234.9040506@o2.pl>
References: <45238234.9040506@o2.pl>
Message-ID: <20061005195354.7e09a4fe.hamish_nospam@yahoo.com>

Maciej Sieczka wrote:
> I haven't found anything relevant in the manual, lists archives, the
> BT or the source code, so I'm asking here.
..
> There are 2 vertices (nodes) currently. Trying to add a vertex between
> them:
> 
> $ v.split input=line output=line_split vertices=3
> 
> Checking line_split in v.digit proves there are still only 2 vertices
> - the nodes themselves; the 3rd vertex in not added.
> 
> No matter what is the 'vertices' set to, the outcome is the same. Is
> that OK? What am I missing to understand what is the 'vertices' option
> for?


v.split is acting correctly. As usual, more documentation needed.

The module breaks lines at verticies, it doesn't add verticies.

In Radim's vector TODO there is a bit about v.in.ogr needing v.split
built into it for huge polygons.

e.g., I have a long, high-resolution single boundary line of the
coastline. Some tools take a very long time to process (build) this. By
using v.split to break the same polygon into several connected boundary
lines (green "X" in v.digit) you can speed up processing 1000%.


Hamish

From neteler at itc.it  Thu Oct  5 09:03:46 2006
From: neteler at itc.it (Markus Neteler)
Date: Thu Oct  5 09:03:47 2006
Subject: [GRASS-dev] GRASS 6.2.0RC2 forthcoming
Message-ID: <20061005070346.GB30865@bartok.itc.it>

Hi,

due to traveling I would like to tag GRASS 6.2.0RC2 later today
as last release candidate.

Still an outstanding TODO is the fix v.digit/toolbox.tcl for tcl8.3.
Hamish apparently solved it but we don't know how.

Release details are here:
http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan

After the 18th of October we can then release GRASS 6.2.0.

Markus

From hamish_nospam at yahoo.com  Thu Oct  5 09:19:57 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu Oct  5 09:20:01 2006
Subject: [GRASS-dev] auto-man page creation after KEYWORD support
Message-ID: <20061005201957.0f54d834.hamish_nospam@yahoo.com>

CVS log for grass6/raster/r.le/r.le.setup/description.html

Default branch: MAIN

Revision 1.8, Wed Sep 27 15:00:04 2006 UTC (7 days, 16 hours ago) by
markus
Branch: MAIN
CVS Tags: HEAD
Changes since 1.7: +7 -1 lines
Diff to previous 1.7

DESCIPTION restored (otherwise the documentation system fails)





Hi,

http://grass.ibiblio.org/grass63/manuals/html63_user/raster.html


now contains "KEYWORDS" as part of the module description for the
interactive modules. (eg r.le.*)

does the bit that wants "DESCIPTION" above need to know about "KEYWORDS"
too?


Hamish

From hamish_nospam at yahoo.com  Thu Oct  5 09:27:58 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu Oct  5 09:28:03 2006
Subject: [GRASS-dev] help with r.le.setup bug
Message-ID: <20061005202758.5cada66a.hamish_nospam@yahoo.com>

Hi,

can one of the C gurus have a look at this?

http://thread.gmane.org/gmane.comp.gis.grass.devel/15495/focus=15598


I think it's a simple type mismatch in variables getting passed to a
function. I'd like to have r.le.* all working for 6.2.0 as it will
probably be the final time r.le.* is released.


thanks,
Hamish

From grass-bugs at intevation.de  Thu Oct  5 09:40:08 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Thu Oct  5 09:40:11 2006
Subject: [GRASS-dev] [bug #5187] (grass) Grass bug tracker rejected guest
	issues
Message-ID: <20061005074008.7BCC91005CE@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5187
-------------------------------------------------------------------------

Subject: Grass bug tracker rejected guest issues



The grass bug tracker no longer accepted requests by "guest" user
as generated by mails or the form on
http://www.grass.itc.it/bugtracking/bugreport.html
fixed?

-------------------------------------------- Managed by Request Tracker

From neteler at itc.it  Thu Oct  5 10:06:48 2006
From: neteler at itc.it (Markus Neteler)
Date: Thu Oct  5 10:06:50 2006
Subject: [GRASS-dev] auto-man page creation after KEYWORD support
In-Reply-To: <20061005201957.0f54d834.hamish_nospam@yahoo.com>
References: <20061005201957.0f54d834.hamish_nospam@yahoo.com>
Message-ID: <20061005080648.GA31251@bartok.itc.it>

On Thu, Oct 05, 2006 at 08:19:57PM +1300, Hamish wrote:
> CVS log for grass6/raster/r.le/r.le.setup/description.html
> 
> Default branch: MAIN
> 
> Revision 1.8, Wed Sep 27 15:00:04 2006 UTC (7 days, 16 hours ago) by
> markus
> Branch: MAIN
> CVS Tags: HEAD
> Changes since 1.7: +7 -1 lines
> Diff to previous 1.7
> 
> DESCIPTION restored (otherwise the documentation system fails)
> 
> 
> Hi,
> 
> http://grass.ibiblio.org/grass63/manuals/html63_user/raster.html
> 
> 
> now contains "KEYWORDS" as part of the module description for the
> interactive modules. (eg r.le.*)
> 
> does the bit that wants "DESCIPTION" above need to know about "KEYWORDS"
> too?
> 

The module  r.le.patch, r.le.pixel, r.le.trace are lacking
the definition of:

    module = G_define_module();
    module->keywords = _("...");
    module->description =  _("...");

This is causing the ugly output (also in 6.2).

Markus

From benjamin.ducke at ufg.uni-kiel.de  Thu Oct  5 10:48:22 2006
From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke)
Date: Thu Oct  5 10:36:25 2006
Subject: [GRASS-dev] GRASS 6.2.0RC2 forthcoming
In-Reply-To: <20061005070346.GB30865@bartok.itc.it>
References: <20061005070346.GB30865@bartok.itc.it>
Message-ID: <4524C6D6.3040309@ufg.uni-kiel.de>

So does that mean, that nviz volume support has been
tested on different scale datasets and will work now?
The website still lists that as an open issue.
GRASS has outstanding voxel capabilities and it would
be so nice to have this working in 6.2 ...

Benjamin

Markus Neteler wrote:
> Hi,
> 
> due to traveling I would like to tag GRASS 6.2.0RC2 later today
> as last release candidate.
> 
> Still an outstanding TODO is the fix v.digit/toolbox.tcl for tcl8.3.
> Hamish apparently solved it but we don't know how.
> 
> Release details are here:
> http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan
> 
> After the 18th of October we can then release GRASS 6.2.0.
> 
> Markus
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
> 
> 

-- 
Benjamin Ducke, M.A.
Arch?oinformatik
(Archaeoinformation Science)
Institut f?r Ur- und Fr?hgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universit?t zu Kiel
Johanna-Mestorf-Stra?e 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

From tutey at o2.pl  Thu Oct  5 12:52:36 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Thu Oct  5 12:52:41 2006
Subject: [GRASS-dev] v.split: what is 'vertices' for?
In-Reply-To: <20061005195354.7e09a4fe.hamish_nospam@yahoo.com>
References: <45238234.9040506@o2.pl>
	<20061005195354.7e09a4fe.hamish_nospam@yahoo.com>
Message-ID: <4524E3F4.2020702@o2.pl>

Hamish wrote:
> Maciej Sieczka wrote:
>> I haven't found anything relevant in the manual, lists archives, the
>> BT or the source code, so I'm asking here.
> .
>> There are 2 vertices (nodes) currently. Trying to add a vertex between
>> them:
>>
>> $ v.split input=line output=line_split vertices=3
>>
>> Checking line_split in v.digit proves there are still only 2 vertices
>> - the nodes themselves; the 3rd vertex in not added.
>>
>> No matter what is the 'vertices' set to, the outcome is the same. Is
>> that OK? What am I missing to understand what is the 'vertices' option
>> for?
> 
> 
> v.split is acting correctly.
>
> As usual, more documentation needed.
> 
> The module breaks lines at verticies, it doesn't add verticies.

OK, now I get it. Works as you explained. Thanks!

Maybe if I have time on weekend I'll add and example with pictures.

Maciek

From neteler at itc.it  Thu Oct  5 14:32:48 2006
From: neteler at itc.it (Markus Neteler)
Date: Thu Oct  5 14:32:49 2006
Subject: [GRASS-dev] GRASS 6.2.0RC2 forthcoming
In-Reply-To: <4524C6D6.3040309@ufg.uni-kiel.de>
References: <20061005070346.GB30865@bartok.itc.it>
	<4524C6D6.3040309@ufg.uni-kiel.de>
Message-ID: <4524FB70.7060309@itc.it>

Hi Benjamin,

Benjamin Ducke wrote on 10/05/2006 10:48 AM:
> So does that mean, that nviz volume support has been
> tested on different scale datasets and will work now?
unfortunately not.

> The website still lists that as an open issue.
Right: it is an open issue.

> GRASS has outstanding voxel capabilities and it would
> be so nice to have this working in 6.2 ...
True. Unfortunately it was broken earlier this year and nobody
is able to track it down...

Markus

From smitch at mac.com  Thu Oct  5 15:55:25 2006
From: smitch at mac.com (Scott Mitchell)
Date: Thu Oct  5 15:55:34 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55BA6@s5-dar-r1.nrn.nrcan.gc.ca>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BA6@s5-dar-r1.nrn.nrcan.gc.ca>
Message-ID: <72C13BC4-FC1F-485B-A6A8-2B1BF77D4796@mac.com>

Sorry for the delay in getting to this - a hard drive failure on top  
of regular chaos at this time of year had me way behind.

Notwithstanding the discussion of possible alternatives to CVS that  
have came up, here are some suggested edits to the howto.... this  
comes as a diff -u against the original attachment you sent around -  
sorry I wasn't more timely to make that work more easily.  If you've  
already put this on the WIKI somewhere let me know and I could work  
on a more up to date version.

I took out the sentence about possibly needing to use sudo to edit  
the source code, simply because I couldn't see how that could come  
up.  If someone is using their own account to check out a copy of the  
source, all files would be owned by them and should be writeable.  As  
far as I can tell, some other intervention would be needed to make it  
more complicated, so having that line in there seemed like extra  
possible confusion to me.  Unless, of course, I'm missing some  
obvious possibility.  Ah - I see now that Hamish has addressed that  
too, in a followup post.  He also points out that patches could be  
created and sent in outside of the fully cvs model of how to do  
things, just making copies and using the diff command.  We COULD show  
two alternative ways of doing this - I can help with that if it  
sounds like a good idea.

Cheers,
Scott

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Updating_Docs_How-to.html.patch
Type: application/octet-stream
Size: 3279 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061005/d5f8f32a/Updating_Docs_How-to.html.obj
-------------- next part --------------

On 28 Sep 2006, at 18:46, Patton, Eric wrote:

> Scott,
>
> Thanks for the encouragement. And please be ruthless when you do  
> review it,
> I want Grass document updates to be as _easy_ as possible (subtle  
> hint) for
> newcomers.
>
> Cheers,
>
> ~ Eric.
>
> -----Original Message-----
> From: Scott Mitchell
> To: Patton, Eric
> Cc: 'grass-dev@grass.itc.it '; neteler@grass.itc.it
> Sent: 9/28/2006 2:51 PM
> Subject: Re: [GRASS-dev] Grass Documentation How-to html page
>
> I haven't read the file in detail, but think in principle this is an
> excellent contribution.  I'd love to help by doing a debug run
> through the instructions.  I probably won't be able to get to it
> until the weekend, though.
>
> Cheers,
> Scott
>
> On 26 Sep 2006, at 11:09, Patton, Eric wrote:
>
>>
>> Hi guys,
>>
>> Borrowing heavily from my conversations with Maciek, I have written a
>> step-by-step how-to for improving Grass documentation, specifically
>> man
>> pages. I welcome any feedback and suggestions for improvement. My
>> knowledge
>> of html is pretty basic, hopefully there aren't too many errors. It
>> looks OK
>> to me in Firefox. I was thinking perhaps this page could be linked/
>> inserted
>> into the main Grass GDP page, so it can be easily found for those
>> who are
>> interested in improving the documentation.
>>
>> Let me know what you think,
>>
>> ~ Eric.
>>
>> -----Original Message-----
>> From: grass-dev-bounces@grass.itc.it
>> To: GRASS developers list
>> Cc: pkg-grass-general@lists.alioth.debian.org; grass-
>> announce@grass.itc.it
>> Sent: 9/26/2006 10:29 AM
>> Subject: [GRASS-dev] GRASS 6.2.0RC1 released
>>
>> Hi,
>>
>> I have packaged the GRASS 6.2.0RC1 release:
>> http://grass.itc.it/grass62/source/
>>
>> Fixes:
>>     * d.vect.thematic -s fixes (michael)
>>     * Vietnamese translation (Bui Huu Manh)
>>     * reverted Pbuffer changes in NVIZ (Brad)
>>     * projection codes updated to EPSG 6.11 (Markus)
>>     * g.region zoom= off by one error (Glynn)
>>     * fix hardcoded Helvetica tcl fonts to a single file setting (in
>> $GISBASE/etc/gtcltk/options.tcl) (michael)
>>
>> Thanks to all contributors. Please test rigorously...
>> especially gis.m.
>>
>> Thanks
>> Markus
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>>
>> <Updating_Docs_How-to.html>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev

From neteler at itc.it  Thu Oct  5 17:21:24 2006
From: neteler at itc.it (Markus Neteler)
Date: Thu Oct  5 17:21:50 2006
Subject: [GRASS-dev] Re: [Ffmpeg-devel] Problems with preC99 compilers
In-Reply-To: <1160003465.1963.19.camel@symbol.nonexistent.fi>
References: <200609291237.54233.maris.gis@gmail.com>
	<1160003465.1963.19.camel@symbol.nonexistent.fi>
Message-ID: <20061005152124.GC1745@bartok.itc.it>

For the record, here a followup...

m.

On Thu, Oct 05, 2006 at 02:11:05AM +0300, Uoti Urpala wrote:
> On Fri, 2006-09-29 at 12:37 +0300, M??ris Narti??s wrote:
> > I was compiling recent GRASS GIS version but it failed on ffmpeg includes due 
> > to one line comments. One line comments (//) where introduced in C99, thus 
> > preC99 compilers do not understand them.
> 
> All widely used compilers from the past several years understand them.
> Even the obsolete gcc versions from before any real C99 support
> understood them.
> 
> > gcc version 4.1.2 20060920 (prerelease)
> 
> Supports not only // but most of the more complex features of C99 too.
> 
> > Error message:
> > gcc -I/home/maris/soft/grass-6.2.0RC1/dist.i686-pc-linux-gnu/include  -g -ansi -Wall
> 
> The -ansi switch explicitly sets the standard back to C89 and disables
> support for any features of current C and GNU extensions that were not
> present in C89. Remove that switch and it'll compile.
> 

From michael.barton at asu.edu  Thu Oct  5 18:50:26 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Thu Oct  5 18:50:34 2006
Subject: [GRASS-dev] zooming voting
Message-ID: <C14A85E2.2545C%michael.barton@asu.edu>

The 2a?s won by a large margin.

I committed the updates to zooming in the GUI. 1-click fast zooming zooms in
and out using the display window and centering the map (i.e., region) at the
click point. Zoom-in box zooming works as before. Zoom-out box zooming sets
the zoom ratio with the longest box dimension, creates a new region that
matches the box aspect ratio, and centers the new region in the display.

Thanks to all who voted and offered suggestions.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://grass.itc.it/pipermail/grass-dev/attachments/20061005/9e5566a0/attachment.html
From epatton at nrcan.gc.ca  Thu Oct  5 20:18:41 2006
From: epatton at nrcan.gc.ca (Patton, Eric)
Date: Thu Oct  5 20:18:45 2006
Subject: [GRASS-dev] zooming voting
Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55BC2@s5-dar-r1.nrn.nrcan.gc.ca>

Thanks for these updates, Michael, much appreciated! I update my cvs and try
it out.

~ Eric. 

-----Original Message-----
From: grass-dev-bounces@grass.itc.it
To: Grass Developers List
Sent: 10/5/2006 12:50 PM
Subject: [GRASS-dev] zooming voting

The 2a's won by a large margin. 

I committed the updates to zooming in the GUI. 1-click fast zooming
zooms in and out using the display window and centering the map (i.e.,
region) at the click point. Zoom-in box zooming works as before.
Zoom-out box zooming sets the zoom ratio with the longest box dimension,
creates a new region that matches the box aspect ratio, and centers the
new region in the display.

Thanks to all who voted and offered suggestions.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change    
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
<http://www.public.asu.edu/~cmbarton>  

 <<ATT537122.txt>> 

From jan-oliver.wagner at intevation.de  Thu Oct  5 23:32:57 2006
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Thu Oct  5 23:33:31 2006
Subject: [GRASS-dev] First steps to switch the bug tracker
Message-ID: <200610052333.01123.jan-oliver.wagner@intevation.de>

Hi,

as a follow up of the bug tracker discussions,
I just created a project "GRASS" on our GForge platform: 
http://wald.intevation.org/projects/grass/

First, we need someone to be the project manager. 
Probably Markus or a steering commitee should decide
who. However, it is good to have two.

The managers and anyone submitting or working on
bug entries should create a user account.

Also, you will currently see quite a number of tabs for
the project (forums, mailing lists, tasks, etc).
Actually, we only need the bug tracker (so far).
All others can be switched off. I will do so unless
you want a specific feature to remain.

Next, there are curently some default trackers configured.
These could be deleted, or additionally be created and of course
configured to some extend.

The managers will have the power to do the configurations (as they
can configure everything).
However, they could also create new roles, e.g. for just Managers
of specific parts. And assign users to roles.

Have fun :-)

Best

	Jan
-- 
Jan-Oliver Wagner: www.intevation.de/~jan  | GISpatcher: www.gispatcher.de
Kolab Konsortium : www.kolab-konsortium.de | Thuban    : thuban.intevation.org
Intevation GmbH  : www.intevation.de       | Kolab     : www.kolab.org
FreeGIS          : www.freegis.org         | GAV       : www.grass-verein.de

From glynn at gclements.plus.com  Fri Oct  6 01:00:01 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri Oct  6 01:00:03 2006
Subject: [GRASS-dev] help with r.le.setup bug
In-Reply-To: <20061005202758.5cada66a.hamish_nospam@yahoo.com>
References: <20061005202758.5cada66a.hamish_nospam@yahoo.com>
Message-ID: <17701.36465.481407.663082@cerise.gclements.plus.com>


Hamish wrote:

> can one of the C gurus have a look at this?
> 
> http://thread.gmane.org/gmane.comp.gis.grass.devel/15495/focus=15598
> 
> 
> I think it's a simple type mismatch in variables getting passed to a
> function.

It is. ux/uy are arrays of ints but calc_unit_loc() expects arrays of
doubles.

Try the attached patch.

-- 
Glynn Clements <glynn@gclements.plus.com>

-------------- next part --------------
Index: raster/r.le/r.le.setup/sample.c
===================================================================
RCS file: /grassrepository/grass6/raster/r.le/r.le.setup/sample.c,v
retrieving revision 2.6
diff -u -r2.6 sample.c
--- raster/r.le/r.le.setup/sample.c	28 Sep 2006 07:37:04 -0000	2.6
+++ raster/r.le/r.le.setup/sample.c	5 Oct 2006 22:57:59 -0000
@@ -108,9 +108,10 @@
 {
   int      i, j, dx, dy, w_w, w_l, u_w, u_l,
 	   method, l0, t0, randflag=0, unit_num, num=0, scales,
-	   h_d=1, v_d=1, *ux, *uy, itmp, thick, sites, *row_buf, fr, k,
+	   h_d=1, v_d=1, itmp, thick, sites, *row_buf, fr, k,
 	   count=0, maxsize=0, nx=0, ny=0, numx=0, numy=0,
 	   al=0, ar=0, at=0, ab=0, au_w=0, au_l=0;
+  double *ux, *uy;
   FILE     *fp ;
   double   dtmp, ratio, size, intv=0.0, start[2], cnt=0, radius=0.0;
   char     *sites_mapset;
@@ -547,13 +548,13 @@
 				   units */
 
 	if (method != 5) {
-	   ux = (int *)G_calloc(num+1, sizeof(int));
-           uy = (int *)G_calloc(num+1, sizeof(int));
+	   ux = G_calloc(num+1, sizeof(double));
+           uy = G_calloc(num+1, sizeof(double));
 	}
 
 	else {
-	   ux = (int *)G_calloc(250, sizeof(int));
-           uy = (int *)G_calloc(250, sizeof(int));
+	   ux = G_calloc(250, sizeof(double));
+           uy = G_calloc(250, sizeof(double));
 	}
 
 				/* calculate the upper left corner of sampling
@@ -615,7 +616,7 @@
         radius, (i+1));
 
      for(j = 0; j < num; j++)
-	fprintf(fp, "%10d%10d   left, top of unit[%d]\n", ux[j], uy[j], j+1);
+	fprintf(fp, "%10d%10d   left, top of unit[%d]\n", (int) ux[j], (int) uy[j], j+1);
 
      if (i < scales - 1 && G_yes("\n\n    Refresh the screen?   ", 1)) {
 	paint_map(n1, n2, n3);
From glynn at gclements.plus.com  Fri Oct  6 01:21:00 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri Oct  6 01:21:02 2006
Subject: [GRASS-dev] Re: [Ffmpeg-devel] Problems with preC99 compilers
In-Reply-To: <20061005152124.GC1745@bartok.itc.it>
References: <200609291237.54233.maris.gis@gmail.com>
	<1160003465.1963.19.camel@symbol.nonexistent.fi>
	<20061005152124.GC1745@bartok.itc.it>
Message-ID: <17701.37724.470901.308522@cerise.gclements.plus.com>


Markus Neteler wrote:

> For the record, here a followup...

... which completely misses the point.

> > > I was compiling recent GRASS GIS version but it failed on ffmpeg includes due 
> > > to one line comments. One line comments (//) where introduced in C99, thus 
> > > preC99 compilers do not understand them.
> > 
> > All widely used compilers from the past several years understand them.
> > Even the obsolete gcc versions from before any real C99 support
> > understood them.
> > 
> > > gcc version 4.1.2 20060920 (prerelease)
> > 
> > Supports not only // but most of the more complex features of C99 too.
> > 
> > > Error message:
> > > gcc -I/home/maris/soft/grass-6.2.0RC1/dist.i686-pc-linux-gnu/include  -g -ansi -Wall
> > 
> > The -ansi switch explicitly sets the standard back to C89 and disables
> > support for any features of current C and GNU extensions that were not
> > present in C89. Remove that switch and it'll compile.

Shorter version: "we aren't going to fix it".

It isn't really a problem; ffmpeg itself won't compile on a system
which only supports C89. But as Maris suggests, we might want to
document this issue somewhere.

-- 
Glynn Clements <glynn@gclements.plus.com>

From hamish_nospam at yahoo.com  Fri Oct  6 03:19:14 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri Oct  6 03:19:26 2006
Subject: [GRASS-dev] Re: [Ffmpeg-devel] Problems with preC99 compilers
In-Reply-To: <20061005152124.GC1745@bartok.itc.it>
References: <200609291237.54233.maris.gis@gmail.com>
	<1160003465.1963.19.camel@symbol.nonexistent.fi>
	<20061005152124.GC1745@bartok.itc.it>
Message-ID: <20061006141914.5d8e8689.hamish_nospam@yahoo.com>

> > > I was compiling recent GRASS GIS version but it failed on ffmpeg
> > > includes due  to one line comments. One line comments (//) where
> > > introduced in C99, thus  preC99 compilers do not understand them.
> > 
> > All widely used compilers from the past several years understand
> > them. Even the obsolete gcc versions from before any real C99
> > support understood them.
> > 
> > > gcc version 4.1.2 20060920 (prerelease)
> > 
> > Supports not only // but most of the more complex features of C99
> > too.
> > 
> > > Error message:
> > > gcc
> > > -I/home/maris/soft/grass-6.2.0RC1/dist.i686-pc-linux-gnu/include 
> > > -g -ansi -Wall
> > 
> > The -ansi switch explicitly sets the standard back to C89 and
> > disables support for any features of current C and GNU extensions
> > that were not present in C89. Remove that switch and it'll compile.


The current state:

grass63$ grep -rI '^//' * | grep -v terraflow

swig/python/python_grass6.i://File : python_grass6.i
swig/python/my_typemaps.i://            G_free_list($1);
vector/v.edit/del.c://          Vect_delete_line(Map, id);
vector/v.edit/del.c://          Vect_delete_line(Map, area);
vector/v.edit/del.c://          Vect_delete_line(Map, id);
vector/v.edit/cat.c://    G_message(_("Reading vector: "));
vector/v.edit/cat.c://  G_percent(line, nlines, 1);
vector/v.edit/add.c://          ret = Vect_get_point_in_poly(line, &xc, &yc);
vector/v.edit/main.c://static int error_routine(const char*msg, int fatal);
vector/v.edit/main.c://    G_set_error_routine(error_routine);
vector/v.edit/main.c:// Vect_set_open_level(2);
vector/v.edit/main.c://    Vect_set_category_index_update ( &Map );
vector/v.edit/main.c://    G_unset_error_routine();
vector/v.drape/spearfish.pov://background { color SkyBlue }


(v.edit isn't built by default)



However, currently ffmpeg build is broken on Debian/stable if using
libavcodeccvs from Christian Marillat's unofficial packages.

me:
> nviz: relocation error: /usr/lib/libavcodec.so.0: undefined symbol:
> faacDecOpen

Christian:
> you also need to backport the latest faac and faad packages.


It's fine if using the official libavcodec-dev packages. (?)



Hamish

From hamish_nospam at yahoo.com  Fri Oct  6 03:56:47 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri Oct  6 03:56:52 2006
Subject: [GRASS-dev] what can come before G_gisinit()?
Message-ID: <20061006145647.17f50301.hamish_nospam@yahoo.com>

is it ok to call G_calloc() before G_gisinit()?

(r.le.*/main.c)


thanks,
Hamish

From hamish_nospam at yahoo.com  Fri Oct  6 06:10:53 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri Oct  6 06:11:02 2006
Subject: [GRASS-dev] help with r.le.setup bug
In-Reply-To: <17701.36465.481407.663082@cerise.gclements.plus.com>
References: <20061005202758.5cada66a.hamish_nospam@yahoo.com>
	<17701.36465.481407.663082@cerise.gclements.plus.com>
Message-ID: <20061006171053.6c363735.hamish_nospam@yahoo.com>

Hamish wrote:
> > I think it's a simple type mismatch in variables getting passed to a
> > function.

Glynn wrote:
> It is. ux/uy are arrays of ints but calc_unit_loc() expects arrays of
> doubles.
> 
> Try the attached patch.

[also cast to int for overlap() fn]

yes, thanks.  funny, even with your patch it still messes up the "y"
values of draw_box() unless I add in the fn prototype to setup.h. Oh
well, done that and it's all working now without compiler warnings.
(and the segfault is gone)

I have also ported the r.le.setup help page from GRASS 5, fixed the
module descriptions, and sync'd all r.le changes with HEAD.

So all r.le should now be working & ready for the next release candidate.


Hamish

From glynn at gclements.plus.com  Fri Oct  6 08:48:05 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri Oct  6 08:48:10 2006
Subject: [GRASS-dev] Re: [Ffmpeg-devel] Problems with preC99 compilers
In-Reply-To: <20061006141914.5d8e8689.hamish_nospam@yahoo.com>
References: <200609291237.54233.maris.gis@gmail.com>
	<1160003465.1963.19.camel@symbol.nonexistent.fi>
	<20061005152124.GC1745@bartok.itc.it>
	<20061006141914.5d8e8689.hamish_nospam@yahoo.com>
Message-ID: <17701.64549.389960.824056@cerise.gclements.plus.com>


Hamish wrote:

> > > > I was compiling recent GRASS GIS version but it failed on ffmpeg
> > > > includes due  to one line comments. One line comments (//) where
> > > > introduced in C99, thus  preC99 compilers do not understand them.
> > > 
> > > All widely used compilers from the past several years understand
> > > them. Even the obsolete gcc versions from before any real C99
> > > support understood them.
> > > 
> > > > gcc version 4.1.2 20060920 (prerelease)
> > > 
> > > Supports not only // but most of the more complex features of C99
> > > too.
> > > 
> > > > Error message:
> > > > gcc
> > > > -I/home/maris/soft/grass-6.2.0RC1/dist.i686-pc-linux-gnu/include 
> > > > -g -ansi -Wall
> > > 
> > > The -ansi switch explicitly sets the standard back to C89 and
> > > disables support for any features of current C and GNU extensions
> > > that were not present in C89. Remove that switch and it'll compile.
> 
> 
> The current state:
> 
> grass63$ grep -rI '^//' * | grep -v terraflow
> 
> swig/python/python_grass6.i://File : python_grass6.i
> swig/python/my_typemaps.i://            G_free_list($1);
> vector/v.edit/del.c://          Vect_delete_line(Map, id);
> vector/v.edit/del.c://          Vect_delete_line(Map, area);
> vector/v.edit/del.c://          Vect_delete_line(Map, id);
> vector/v.edit/cat.c://    G_message(_("Reading vector: "));
> vector/v.edit/cat.c://  G_percent(line, nlines, 1);
> vector/v.edit/add.c://          ret = Vect_get_point_in_poly(line, &xc, &yc);
> vector/v.edit/main.c://static int error_routine(const char*msg, int fatal);
> vector/v.edit/main.c://    G_set_error_routine(error_routine);
> vector/v.edit/main.c:// Vect_set_open_level(2);
> vector/v.edit/main.c://    Vect_set_category_index_update ( &Map );
> vector/v.edit/main.c://    G_unset_error_routine();
> vector/v.drape/spearfish.pov://background { color SkyBlue }

IOW, it's just v.edit; the others aren't C files.

> (v.edit isn't built by default)

That would probably explain why no-one has noticed it before; people
do occasionally build with -ansi.

Fixed in CVS.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Fri Oct  6 08:56:15 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri Oct  6 08:56:18 2006
Subject: [GRASS-dev] what can come before G_gisinit()?
In-Reply-To: <20061006145647.17f50301.hamish_nospam@yahoo.com>
References: <20061006145647.17f50301.hamish_nospam@yahoo.com>
Message-ID: <17701.65039.812309.262648@cerise.gclements.plus.com>


Hamish wrote:

> Subject: [GRASS-dev] what can come before G_gisinit()?

Nothing that's part of GRASS.

And ideally, nothing at all. It isn't totally inconceivable that
future versions of G_gisinit() could have side-effects which affect
core ANSI functions (e.g. setting the locale, or installing malloc
hooks).

> is it ok to call G_calloc() before G_gisinit()?

No.

G_calloc() calls G_fatal_error() if calloc() fails. G_fatal_error()
calls G_program_name(), which uses the program name set by
G_gisinit().

Beyond that, just because the current G_gisinit() implementation
doesn't do much, that doesn't mean that future version won't.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Fri Oct  6 09:03:45 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri Oct  6 09:03:49 2006
Subject: [GRASS-dev] help with r.le.setup bug
In-Reply-To: <20061006171053.6c363735.hamish_nospam@yahoo.com>
References: <20061005202758.5cada66a.hamish_nospam@yahoo.com>
	<17701.36465.481407.663082@cerise.gclements.plus.com>
	<20061006171053.6c363735.hamish_nospam@yahoo.com>
Message-ID: <17701.65489.384104.860083@cerise.gclements.plus.com>


Hamish wrote:

> > > I think it's a simple type mismatch in variables getting passed to a
> > > function.
> 
> > It is. ux/uy are arrays of ints but calc_unit_loc() expects arrays of
> > doubles.
> > 
> > Try the attached patch.
> 
> [also cast to int for overlap() fn]
> 
> yes, thanks.  funny, even with your patch it still messes up the "y"
> values of draw_box() unless I add in the fn prototype to setup.h.

Right. overlap() expects "int"s, but some of the values passed are
changed to double by my patch. If a valid prototype is in scope, the
compiler will automatically cast them to int, otherwise it will pass
them as double.

All of those declarations in setup.h should be either fixed or
removed. If the compiler needs a prototype (because the function isn't
already in scope at the point that it's used), it needs the *correct*
prototype.

-- 
Glynn Clements <glynn@gclements.plus.com>

From benjamin.ducke at ufg.uni-kiel.de  Fri Oct  6 10:41:53 2006
From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke)
Date: Fri Oct  6 10:29:54 2006
Subject: [GRASS-dev] Re: [GRASS-user] Basic GIS course ideas
In-Reply-To: <f902f9840610052306k7e665af0g47066876e6cc71ad@mail.gmail.com>
References: <f902f9840610052306k7e665af0g47066876e6cc71ad@mail.gmail.com>
Message-ID: <452616D1.9070104@ufg.uni-kiel.de>

Hi Maning,

I taught a combination of QGIS and GRASS a little while ago
and I think it went alright.
About one third of my students had no idea about GIS at all
and one third had GRASS GIS skills.

So I started by demonstrating some basic mapping, GIS file
format issues, projections, georeferencing etc. using QGIS.

 From there, it was easy to start the GRASS plugin and introduce
students step-by-step to the underlying power of GRASS GIS.

The transition was quite smooth, as many tricky GRASS concepts
(like the region) have direct visual feedback in QGIS via the
plugin and things like data import and export from/to the GRASS
database get quite a lot easier using the GRASS toolbox.

I would recommend using GRASS GIS 6.2 and QGIS compiled natively
for Windows (there are some instructions by Radim Blazek
somewhere on the Wiki site).

For 3D-visualization, I used ParaView and that worked well, too.

For an extended course including things like point patten analysis,
you could also add R.

Best,

Benjamin


maning sambale wrote:
> Hi FOSS GIS users,
> 
> I am a part-time instructor in a college teaching introductory gis
> course.  I have been advocating for the use FOSS GIS (particularly
> GRASS and QGIS ) in our schools for the lab sessions.
> This is the second term I am doing this and have been reflecting on
> how did it go the first time.
> 
> The objective of the course is for students to understand basic gis
> principles as well as practical applications in site planning, land
> use, ecology and business.
> 
> Judging by the previous experience, it is a little bit difficult
> introducing the student FOSS GIS especially the linux way of doing
> things (CLI).  We are using XP machines and most students probably
> know computers as MS windows only.
> 
> Some are more interested in creating cool maps and not on the
> underlying spatial analysis techniques (i.e. r.mapcalc) that were
> used.
> 
> I wrote the list to ask GRASS instructors on any ideas in making the
> course better.  If you have any approaches/techniques/exercises you
> might want to share please do.  I firmly believe using FOSS GIS
> especially in our country is very important.  As a compromise though,
> a suggestion from this list was to also introduce them to propriety
> GIS package.  We have a few arcview 3.2 in the lab so I might give a 1
> or 2 sessions about it.
> 
> Any ideas would be appreciated.
> 
> Cheers,
> 
> Maning
> 

-- 
Benjamin Ducke, M.A.
Arch?oinformatik
(Archaeoinformation Science)
Institut f?r Ur- und Fr?hgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universit?t zu Kiel
Johanna-Mestorf-Stra?e 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

From grass-bugs at intevation.de  Fri Oct  6 11:11:23 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Fri Oct  6 11:11:25 2006
Subject: [GRASS-dev] [bug #5189] (grass) Error in start up script
Message-ID: <20061006091123.CB8301005C1@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5189
-------------------------------------------------------------------------

Subject: Error in start up script

Platform: WindowsNT/2000/XP
grass obtained from: Mirror of Trento site
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: 6.3.cvs (2006)

Hello,

When I open the spearfish sample mapset I get this error:

can't read "parts(n)": no such variable
 while executing 
"MapCanvas::zoom_new $mon $parts(n)$parts(s)$parts(e)$parts(w)$parts(nsres)$parts(ewres)"(procedure "MapCanvas::zoom_gregion" line 11)invoked from within........

When I was installing and I launched 'inst_grass.bat' I obtained an error which said something like: <Connection rejected by peer> so I downloaded the files included in the 'gnuwin32_pkgs' and 'grass_pkgs' variables one by one and unzipped them into 'c:\msys\1.0\local'. After that, I have launched the last lines of the script, modifying it so that it jumps to:

copy \inst_grass\grass.bat \msys\1.0
copy \inst_grass\grass.ico \msys\1.0
\msys\1.0\bin\grep "PATH=.*/mingw/bin" \msys\1.0\etc\profile > nul
if %errorlevel% == 1 \msys\1.0\bin\sed "s/PATH=/PATH=C:\\\\mingw\\\\bin;/" \inst_grass\grass.bat > \msys\1.0\grass.bat
...
...
...

I guess there is something wrong with the installation. I hope I don't have to repeat all the installation, do I? Can you help me, please?

Thank you.
Juan Carlos.







-------------------------------------------- Managed by Request Tracker

From cavallini at faunalia.it  Fri Oct  6 11:51:52 2006
From: cavallini at faunalia.it (Paolo Cavallini)
Date: Fri Oct  6 11:52:25 2006
Subject: [GRASS-dev] bug in v.in.dxf?
Message-ID: <45262738.4080408@faunalia.it>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all.
Importing a dxf:
http://www.faunalia.it/download/boschi_0103_ps.dxf.tar.gz
creates artefacts:
http://www.faunalia.it/download/qgis_dxf.png
islands are connected to outer borders by non-existing lines.
Is that a bug? Should I fill a report?
All the best.
pc
- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy   Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFJic4/NedwLUzIr4RAmAzAJ9chcxkbcvO4VZOZmLyYUo0sEdYzwCeKJB4
ND0R/CAXieFSIEq/8ubnLWY=
=Pspk
-----END PGP SIGNATURE-----

From radim.blazek at gmail.com  Fri Oct  6 14:25:38 2006
From: radim.blazek at gmail.com (Radim Blazek)
Date: Fri Oct  6 14:25:41 2006
Subject: [GRASS-dev] VASKLIB in IMAGERYLIB?
Message-ID: <340505ef0610060525t47c42bewc31702abc6edd83d@mail.gmail.com>

Hi,
adding VASKLIB to IMAGERYLIB breaks compilation of some modules
(r.in.gdal) on windows  or --without-curses. VASKLIB is not used by in modules
which use IMAGERYLIB, IMO VASKLIB should only be used in modules Makefiles
which realy use it.
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/include/Make/Grass.make.in.diff?r1=1.60&r2=1.61

Radim

From michael.barton at asu.edu  Fri Oct  6 17:02:31 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Oct  6 17:02:36 2006
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
In-Reply-To: <20061005070346.GB30865@bartok.itc.it>
Message-ID: <C14BBE17.F729%michael.barton@asu.edu>

I'm just getting to one of my GRASS digests from yesterday (didn't have much
time to look at email). It turns out that bwidget LabelFrame is not just a
drop in replacement for the tk 8.4 labelframe. For one thing, LabelFrame
seems buggy in the version of bwidgets that GRASS uses and the frame border
will not draw with a label there. Second the options are slightly different.

If you want to replace the labelframe statement in toolbox.tcl (ca. Line
223) with the following and see what happens, I guess go ahead. On my Mac,
running x11, it creates the label but does not draw the box, no matter what
I do. This is problematic, but maybe it at least runs on 8.3. Again, I can't
say if there are any other 8.4 features that won't run on 8.3, so I'm not
sure it's worth it anyway.

I don't know what happens on Mac Aqua or Windows. I'm tied up most of the
rest of the day and so can't test further.

LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
    -text [G_msg "mouse button actions (left, right, center)"]

Cheers
Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Markus Neteler <neteler@itc.it>
> Date: Thu, 5 Oct 2006 09:03:46 +0200
> To: GRASS developers list <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] GRASS 6.2.0RC2 forthcoming
> 
> Hi,
> 
> due to traveling I would like to tag GRASS 6.2.0RC2 later today
> as last release candidate.
> 
> Still an outstanding TODO is the fix v.digit/toolbox.tcl for tcl8.3.
> Hamish apparently solved it but we don't know how.
> 
> Release details are here:
> http://grass.gdf-hannover.de/wiki/GRASS_6.2_Feature_Plan
> 
> After the 18th of October we can then release GRASS 6.2.0.
> 
> Markus
> 
> 

From grass-bugs at intevation.de  Fri Oct  6 17:26:06 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Fri Oct  6 17:26:11 2006
Subject: [GRASS-dev] [bug #5191] (grass) GRASS_WISH environment did not
	istall properly 
Message-ID: <20061006152606.9C08C1005C7@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5191
-------------------------------------------------------------------------

Subject: GRASS_WISH environment did not istall properly 

Platform: WindowsNT/2000/XP
grass obtained from: Mirror of Trento site
grass binary for platform: Downloaded precompiled Binaries
GRASS Version: 6.3.x

After running the grass_inst.bat file I opened the grass.bat file and the command window that popped up reported that the Grass_wish environment did not respond as expected... following this window is the classic Location and Mapset command line page, followed by the option to pick your coordinate system. Instead of following this option with the next step, it then asks for a brief one line description, and rejects any response I've tried with an 'incorrect syntax' error message.
 I will try and figure out more about the problem myself, as I realise this is a beta version, and respond with the solution, or at least more details surrounding the problem.

BTW thanks for making a grass binary native to windows, as much as I'd like to switch over to linux full time, I work in Windows, and can't find the time... perhaps it'll be creeping up on Arc soon...

-------------------------------------------- Managed by Request Tracker

From radim.blazek at gmail.com  Fri Oct  6 17:35:29 2006
From: radim.blazek at gmail.com (Radim Blazek)
Date: Fri Oct  6 17:35:32 2006
Subject: [GRASS-dev] tmpfile() -> G_asprintf fails on Win/MinGW
Message-ID: <340505ef0610060835o7b84763cnfc350797915e8477@mail.gmail.com>

Hi,
attached is critical bugfix for G_asprintf(). tmpfile() fails on Windows/MinGW
if user des not have enough permissions on the drive (top dir) where he is
currently working.
Please apply to both HEAD and 6.2 release.

BTW, I dont think G_asprintf should be used in this cases:
  G_asprintf(&datumlongname, "unknown");
  G_asprintf(&ellps, "unnamed");
  G_asprintf( &pszDatumName, pszDatumNameConst );

Radim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asprintf.c.patch1
Type: application/octet-stream
Size: 888 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061006/b5aca48a/asprintf.c.obj
From mlennert at club.worldonline.be  Fri Oct  6 17:42:15 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Oct  6 17:41:56 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect causes
 error :can't
 read "_data(.gronsole.gronsole,9,donecmd)": no such element in array
Message-ID: <45267957.2020505@club.worldonline.be>

Using a where clause in vector display in gis.m causes the following 
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in array
can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"
     (procedure "Gronsole::done_command" line 3)
     invoked from within
"Gronsole::done_command $path $ci"
     (procedure "Gronsole::execout" line 26)
     invoked from within
"Gronsole::execout $path $cmd $ci Gronsole::execwait"
     (procedure "Gronsole::run_wait" line 6)
     invoked from within
"Gronsole::run_wait .gronsole.gronsole {d.vect map=communes@PERMANENT 
color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape 
type=point,line,boundar..."
     ("eval" body line 1)
     invoked from within
"eval Gronsole::$cmd .gronsole.gronsole $args"
     (procedure ".gronsole.gronsole" line 1)
     invoked from within
"$gronsole run_wait $cmd gism"
     (procedure "run_panel" line 4)
     invoked from within
"run_panel $cmd"
     (procedure "GmCommonLayer::display_commands" line 28)
     invoked from within
"GmCommonLayer::display_commands $namespace $id [list $cmd]"
     (procedure "GmCommonLayer::display_command" line 2)
     invoked from within
"GmCommonLayer::display_command [namespace current] $id $cmd"
     (procedure "GmVector::display" line 108)
     invoked from within
"GmVector::display $node $mod"
     ("vector" arm line 2)
     invoked from within
"switch $type {
         group {
             GmGroup::display $node $mod
		}
		raster {
			GmRaster::display $node $mod
		}
		labels {
			GmLabels::disp..."
     (procedure "GmTree::display_node" line 7)
     invoked from within
"GmTree::display_node $n $mod"
     (procedure "GmGroup::display" line 22)
     invoked from within
"GmGroup::display "root" $mod"
     (procedure "MapCanvas::runprograms" line 63)
     invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
     (procedure "MapCanvas::drawmap" line 38)
     invoked from within
"MapCanvas::drawmap $mon"
     (procedure "MapCanvas::display_server" line 9)
     invoked from within
"MapCanvas::display_server"
     ("after" script)

Moritz

From neteler at itc.it  Fri Oct  6 17:43:38 2006
From: neteler at itc.it (Markus Neteler)
Date: Fri Oct  6 17:43:40 2006
Subject: [GRASS-dev] tmpfile() -> G_asprintf fails on Win/MinGW
In-Reply-To: <340505ef0610060835o7b84763cnfc350797915e8477@mail.gmail.com>
References: <340505ef0610060835o7b84763cnfc350797915e8477@mail.gmail.com>
Message-ID: <20061006154338.GP9196@bartok.itc.it>

On Fri, Oct 06, 2006 at 05:35:29PM +0200, Radim Blazek wrote:
> Hi,
> attached is critical bugfix for G_asprintf(). tmpfile() fails on 
> Windows/MinGW
> if user des not have enough permissions on the drive (top dir) where he is
> currently working.
> Please apply to both HEAD and 6.2 release.

Patch applied to both repositories (I have changed the C++ style comment, though).

Markus 

> BTW, I dont think G_asprintf should be used in this cases:
>  G_asprintf(&datumlongname, "unknown");
>  G_asprintf(&ellps, "unnamed");
>  G_asprintf( &pszDatumName, pszDatumNameConst );
> 
> Radim


From mlennert at club.worldonline.be  Fri Oct  6 17:48:43 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Fri Oct  6 17:48:25 2006
Subject: [GRASS-dev] [bug #5189] (grass) Error in start up script
In-Reply-To: <20061006091123.CB8301005C1@lists.intevation.de>
References: <20061006091123.CB8301005C1@lists.intevation.de>
Message-ID: <45267ADB.7090508@club.worldonline.be>

Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5189
> -------------------------------------------------------------------------
> 
> Subject: Error in start up script
> 
> Platform: WindowsNT/2000/XP
> grass obtained from: Mirror of Trento site
> grass binary for platform: Downloaded precompiled Binaries
> GRASS Version: 6.3.cvs (2006)
> 
> Hello,
> 
> When I open the spearfish sample mapset I get this error:
> 
> can't read "parts(n)": no such variable
>  while executing 
> "MapCanvas::zoom_new $mon $parts(n)$parts(s)$parts(e)$parts(w)$parts(nsres)$parts(ewres)"(procedure "MapCanvas::zoom_gregion" line 11)invoked from within........
> 
> When I was installing and I launched 'inst_grass.bat' I obtained an error which said something like: <Connection rejected by peer> so I downloaded the files included in the 'gnuwin32_pkgs' and 'grass_pkgs' variables one by one and unzipped them into 'c:\msys\1.0\local'. After that, I have launched the last lines of the script, modifying it so that it jumps to:
> 
> copy \inst_grass\grass.bat \msys\1.0
> copy \inst_grass\grass.ico \msys\1.0
> \msys\1.0\bin\grep "PATH=.*/mingw/bin" \msys\1.0\etc\profile > nul
> if %errorlevel% == 1 \msys\1.0\bin\sed "s/PATH=/PATH=C:\\\\mingw\\\\bin;/" \inst_grass\grass.bat > \msys\1.0\grass.bat
> ...
> ...
> ...
> 
> I guess there is something wrong with the installation. I hope I don't have to repeat all the installation, do I? Can you help me, please?

Did you install PostgreSQL ? I had such an error when I didn't install 
PostgreSQL, since all modules are compiled with the dependency for 
pg.dll and the above error came from the fact that g.region didn't run 
because of that missing dependency.

Really time to recompile the windows binaries without PostgreSQL 
dependency...

Moritz

> 
> Thank you.
> Juan Carlos.
> 
> 
> 
> 
> 
> 
> 
> -------------------------------------------- Managed by Request Tracker
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

From michael.barton at asu.edu  Fri Oct  6 18:23:13 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Oct  6 18:23:20 2006
Subject: [GRASS-dev] Re: [GRASS-user] Basic GIS course ideas
In-Reply-To: <452616D1.9070104@ufg.uni-kiel.de>
Message-ID: <C14BD101.254E5%michael.barton@asu.edu>

I regularly teach a course in spatial technologies for anthropology grad
students. I have to start with an assumption that people know no GIS and go
from there. But I also want the students to be able to use GIS and related
tools in their research, not just to be able to push buttons and make maps.
This is consistently difficult, of course.

Beginning in 2004, I started to use GRASS in the course. I did both GRASS
and ESRI (both ArcView and ArcGIS in that year) as the software I discussed.
This was overly complicated and I probably will not include ArcGIS next
time. 

In 2005, I did a similar course at the U. Valencia (Spain) with only GRASS.
This past spring, I co-taught a remote sensing course that included GRASS
(along with other software) as recommended tools. (The PDF's are available
on my website and can be used by anyone who wants to).

The one biggest issue in using GRASS has been that most students use MS
Windows and GRASS was difficult to install for them--and consistently had
Windows related problems of access and permissions. This has been magnified
in a lab setting.

GRASS works great for teaching fundamental GIS and image processing
concepts--if you can get it to run on your Windows machine. I also strongly
recommend QGIS for beginners. However, it is more limited for teaching GIS
research concepts--especially on Windows where (at least until recently) the
GRASS plugins were either unavailable or complicated to install.

The new Windows native GRASS will make a HUGE difference in this. One of my
doctoral students just did a 2 afternoon workshop for other grad students on
GRASS and GIS. Huidae Cho and Glynn Clements did the new WinGRASS just in
time and deserve a tremendous thanks. Although it is still an alpha version,
90+% works which is enough to teach with. Everyone used it in the workshop.

I've looked at QGIS 0.8 and it is very nice. With the continuing work, it
should also be an excellent teaching tool. When I next teach spatial
technologies in a year, I will be using 100% GRASS and QGIS. Students can
walk away from the course with full-featured software that they can use for
the rest of their careers--and possibly contribute to improving. This is
wonderful.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Benjamin Ducke <benjamin.ducke@ufg.uni-kiel.de>
> Date: Fri, 06 Oct 2006 10:41:53 +0200
> To: GRASS devel <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] Re: [GRASS-user] Basic GIS course ideas
> 
> Hi Maning,
> 
> I taught a combination of QGIS and GRASS a little while ago
> and I think it went alright.
> About one third of my students had no idea about GIS at all
> and one third had GRASS GIS skills.
> 
> So I started by demonstrating some basic mapping, GIS file
> format issues, projections, georeferencing etc. using QGIS.
> 
>  From there, it was easy to start the GRASS plugin and introduce
> students step-by-step to the underlying power of GRASS GIS.
> 
> The transition was quite smooth, as many tricky GRASS concepts
> (like the region) have direct visual feedback in QGIS via the
> plugin and things like data import and export from/to the GRASS
> database get quite a lot easier using the GRASS toolbox.
> 
> I would recommend using GRASS GIS 6.2 and QGIS compiled natively
> for Windows (there are some instructions by Radim Blazek
> somewhere on the Wiki site).
> 
> For 3D-visualization, I used ParaView and that worked well, too.
> 
> For an extended course including things like point patten analysis,
> you could also add R.
> 
> Best,
> 
> Benjamin
> 
> 
> maning sambale wrote:
>> Hi FOSS GIS users,
>> 
>> I am a part-time instructor in a college teaching introductory gis
>> course.  I have been advocating for the use FOSS GIS (particularly
>> GRASS and QGIS ) in our schools for the lab sessions.
>> This is the second term I am doing this and have been reflecting on
>> how did it go the first time.
>> 
>> The objective of the course is for students to understand basic gis
>> principles as well as practical applications in site planning, land
>> use, ecology and business.
>> 
>> Judging by the previous experience, it is a little bit difficult
>> introducing the student FOSS GIS especially the linux way of doing
>> things (CLI).  We are using XP machines and most students probably
>> know computers as MS windows only.
>> 
>> Some are more interested in creating cool maps and not on the
>> underlying spatial analysis techniques (i.e. r.mapcalc) that were
>> used.
>> 
>> I wrote the list to ask GRASS instructors on any ideas in making the
>> course better.  If you have any approaches/techniques/exercises you
>> might want to share please do.  I firmly believe using FOSS GIS
>> especially in our country is very important.  As a compromise though,
>> a suggestion from this list was to also introduce them to propriety
>> GIS package.  We have a few arcview 3.2 in the lab so I might give a 1
>> or 2 sessions about it.
>> 
>> Any ideas would be appreciated.
>> 
>> Cheers,
>> 
>> Maning
>> 
> 
> -- 
> Benjamin Ducke, M.A.
> Arch?oinformatik
> (Archaeoinformation Science)
> Institut f?r Ur- und Fr?hgeschichte
> (Inst. of Prehistoric and Historic Archaeology)
> Christian-Albrechts-Universit?t zu Kiel
> Johanna-Mestorf-Stra?e 2-6
> D 24098 Kiel
> Germany
> 
> Tel.: ++49 (0)431 880-3378 / -3379
> Fax : ++49 (0)431 880-7300
> www.uni-kiel.de/ufg
> 
> 


From rez at touchofmadness.com  Fri Oct  6 18:56:33 2006
From: rez at touchofmadness.com (Brad Douglas)
Date: Fri Oct  6 18:56:55 2006
Subject: [GRASS-dev] VASKLIB in IMAGERYLIB?
In-Reply-To: <340505ef0610060525t47c42bewc31702abc6edd83d@mail.gmail.com>
References: <340505ef0610060525t47c42bewc31702abc6edd83d@mail.gmail.com>
Message-ID: <1160153793.2382.17.camel@devel>

On Fri, 2006-10-06 at 14:25 +0200, Radim Blazek wrote:
> Hi,
> adding VASKLIB to IMAGERYLIB breaks compilation of some modules
> (r.in.gdal) on windows  or --without-curses. VASKLIB is not used by in modules
> which use IMAGERYLIB, IMO VASKLIB should only be used in modules Makefiles
> which realy use it.
> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/include/Make/Grass.make.in.diff?r1=1.60&r2=1.61

We should be moving away from VASKLIB, too...  Unfortunately, some parts
of IMAGERYLIB still require VASKLIB functions, IIRC. :(


-- 
Brad Douglas <rez touchofmadness com>                      KB8UYR
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785

From JGillette at rfmd.com  Fri Oct  6 20:26:09 2006
From: JGillette at rfmd.com (John Gillette)
Date: Fri Oct  6 20:27:02 2006
Subject: [GRASS-dev] bug in v.in.dxf?
Message-ID: <FAC0796BDBA71C4586096205CE96292102EE87FD@mail.internal.rfmd.com>

Using QCAD 1.5.4 in Linux, I see those artifacts in the dxf file.

John 

> Importing a dxf:
> http://www.faunalia.it/download/boschi_0103_ps.dxf.tar.gz
> creates artefacts:
> http://www.faunalia.it/download/qgis_dxf.png
> islands are connected to outer borders by non-existing lines.
> Is that a bug? Should I fill a report?
> All the best.
> pc

From michael.barton at asu.edu  Fri Oct  6 20:32:54 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Oct  6 20:33:00 2006
Subject: [GRASS-dev] Re: Your post on Grass list: i.group failed in new
	Georectifier
In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55BCA@s5-dar-r1.nrn.nrcan.gc.ca>
Message-ID: <C14BEF66.254F4%michael.barton@asu.edu>

Eric,

I'm completely baffled. It must be some other kinds of changes in GRASS
affecting this. Is the only one that doesn't work? You can grep run_panel
*.tcl in the /etc/gm folder and see what else uses it. You can make a change
with a text editor with no need to recompile.

I have to make a confession that the version I'm working with is a couple
weeks old, but has all current tcltk files. I'm concerned that some other
change in the tcltk parser is creating problems with running some things.
i.group should not be problematic since it doesn't require an xterm to run.

The "run" procedure is used widely. I can think of no reason why "exec --
i.group >& /dev/null" should not work. I notice that you do not have the new
devnull variable that makes this workable in Windows, so you must be running
6.1 or 6.2. I don't know whether that makes a difference or not.

Given all this, I'm forwarding this to the general developer list to see
what's going on.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: "Patton, Eric" <epatton@nrcan.gc.ca>
> Date: Fri, 6 Oct 2006 13:42:51 -0300
> To: 'Michael Barton ' <michael.barton@asu.edu>
> Subject: RE: Your post on Grass list: i.group failed in new Georectifier
> 
> Still no luck. I made your edit (substituting run for run_panel),
> re-complied, and I get a tcl error:
> 
>  child process exited abnormally
> child process exited abnormally
>     while executing
> "exec -- i.group >& /dev/null"
>     ("eval" body line 1)
>     invoked from within
> "eval [list exec -- $cmd] $args >& $devnull"
>     (procedure "run" line 12)
>     invoked from within
> "run $cmd"
>     (procedure "GRMap::group" line 11)
>     invoked from within
> "GRMap::group"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel \#0 $cmd"
>     (procedure "Button::_release" line 18)
>     invoked from within
> "Button::_release .grstart.mf.frame.group.a"
>     (command bound to event)
> 
> The vector group chooser works fine, but then I see that it doesn't call
> i.group either. Actually, I noticed that the i.group call is the only time
> in the whole tcl script that 'run_panel' is used. I thought I could test to
> see if run_panel ran successfully in other instances in georect.tcl.
> 
> ~ Eric.
> 
> 
> -----Original Message-----
> From: Michael Barton
> To: Patton, Eric
> Sent: 10/6/2006 12:02 PM
> Subject: Re: Your post on Grass list: i.group failed in new Georectifier
> 
> Try substituting "run" for "run_panel" in the line that calls i.group
> and
> see what happens. I have no way to test because it works fine for me.
> 
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics and Complexity
> Arizona State University
> 
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
> 
> 
>> From: "Patton, Eric" <epatton@nrcan.gc.ca>
>> Date: Fri, 6 Oct 2006 12:31:31 -0300
>> To: 'Michael Barton ' <michael.barton@asu.edu>
>> Subject: RE: Your post on Grass list: i.group failed in new
> Georectifier
>> 
>> Hm, i.group works fine from both the GUI and comand line; i.group -l
> shows
>> my newly created imagery groups.
>> 
>> It's almost like the georectifying tool is passing i.group a null
> string for
>> the name of the group parameter as soon as button #2 is clicked,
> causing
>> i.group to fail. I take it that clicking button #2 'Create edit group'
> is
>> supposed to launch the GUI version of i.group? It's strange. I can try
> to
>> take a look at georect.tcl and see if anything obvious sticks out,
> although
>> I kow barely any tcl.
>> 
>> I'm using Ubuntu 6.06 on a Dell PC.
>> 
>> ~ Eric. 
>> 
>> -----Original Message-----
>> From: Michael Barton
>> To: Patton, Eric
>> Sent: 10/6/2006 11:06 AM
>> Subject: Re: Your post on Grass list: i.group failed in new
> Georectifier
>> 
>> Have you tried running i.group from the command line and from the
> menu?
>> What
>> happens in both.
>> 
>> I'm running i.group in exactly the same way as other commands are run.
> I
>> can
>> change the procedure, but wonder if this is causing problems with
> other
>> commands too on your system.
>> 
>> BTW, what system are you doing this on?
>> 
>> Michael
>> __________________________________________
>> Michael Barton, Professor of Anthropology
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 
>> 
>>> From: "Patton, Eric" <epatton@nrcan.gc.ca>
>>> Date: Fri, 6 Oct 2006 10:59:58 -0300
>>> To: 'Michael Barton ' <michael.barton@asu.edu>
>>> Subject: RE: Your post on Grass list: i.group failed in new
>> Georectifier
>>> 
>>> Michael,
>>> 
>>> I tried it again after updating to CVS - same thing:
>>> 
>>>  
>>> ERROR: Required parameter <group> not set:
>>>     (Name of imagery group).
>>> 
>>> ~ Eric.
>>> 
>>> 
>>> -----Original Message-----
>>> From: Michael Barton
>>> To: Patton, Eric
>>> Sent: 10/5/2006 5:37 PM
>>> Subject: Re: Your post on Grass list: i.group failed in new
>> Georectifier
>>> 
>>> Probably not. I bet mine went in about 15 minutes later.
>>> 
>>> Michael
>>> __________________________________________
>>> Michael Barton, Professor of Anthropology
>>> School of Human Evolution & Social Change
>>> Center for Social Dynamics and Complexity
>>> Arizona State University
>>> 
>>> phone: 480-965-6213
>>> fax: 480-965-7671
>>> www: http://www.public.asu.edu/~cmbarton
>>> 
>>> 
>>> 
>> 
> 

From radim.blazek at gmail.com  Fri Oct  6 20:38:07 2006
From: radim.blazek at gmail.com (Radim Blazek)
Date: Fri Oct  6 20:38:10 2006
Subject: [GRASS-dev] tmpfile() -> G_asprintf fails on Win/MinGW
In-Reply-To: <20061006154338.GP9196@bartok.itc.it>
References: <340505ef0610060835o7b84763cnfc350797915e8477@mail.gmail.com>
	<20061006154338.GP9196@bartok.itc.it>
Message-ID: <340505ef0610061138o5f47ca6esabdca9c105952db1@mail.gmail.com>

Thanks,
unfortunately I found that it would not work when no mapset is open
(read only access) so I changed it to use Windows native functions to get temp
file. Another patch  is attached.

Radim

On 10/6/06, Markus Neteler <neteler@itc.it> wrote:
> On Fri, Oct 06, 2006 at 05:35:29PM +0200, Radim Blazek wrote:
> > Hi,
> > attached is critical bugfix for G_asprintf(). tmpfile() fails on
> > Windows/MinGW
> > if user des not have enough permissions on the drive (top dir) where he is
> > currently working.
> > Please apply to both HEAD and 6.2 release.
>
> Patch applied to both repositories (I have changed the C++ style comment, though).
>
> Markus
>
> > BTW, I dont think G_asprintf should be used in this cases:
> >  G_asprintf(&datumlongname, "unknown");
> >  G_asprintf(&ellps, "unnamed");
> >  G_asprintf( &pszDatumName, pszDatumNameConst );
> >
> > Radim
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asprintf.c.patch2
Type: application/octet-stream
Size: 1225 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061006/b5daef77/asprintf.c.obj
From radim.blazek at gmail.com  Fri Oct  6 20:42:44 2006
From: radim.blazek at gmail.com (Radim Blazek)
Date: Fri Oct  6 20:42:47 2006
Subject: [GRASS-dev] VASKLIB in IMAGERYLIB?
In-Reply-To: <1160153793.2382.17.camel@devel>
References: <340505ef0610060525t47c42bewc31702abc6edd83d@mail.gmail.com>
	<1160153793.2382.17.camel@devel>
Message-ID: <340505ef0610061142j311a9696lfb1ebb5ebd15122@mail.gmail.com>

On 10/6/06, Brad Douglas <rez@touchofmadness.com> wrote:
> On Fri, 2006-10-06 at 14:25 +0200, Radim Blazek wrote:
> > Hi,
> > adding VASKLIB to IMAGERYLIB breaks compilation of some modules
> > (r.in.gdal) on windows  or --without-curses. VASKLIB is not used by in modules
> > which use IMAGERYLIB, IMO VASKLIB should only be used in modules Makefiles
> > which realy use it.
> > http://freegis.org/cgi-bin/viewcvs.cgi/grass6/include/Make/Grass.make.in.diff?r1=1.60&r2=1.61
>
> We should be moving away from VASKLIB, too...  Unfortunately, some parts
> of IMAGERYLIB still require VASKLIB functions, IIRC. :(

The functions which require VASKLIB are compiled only if HAVE_CURSES_H.

Radim

>
> --
> Brad Douglas <rez touchofmadness com>                      KB8UYR
> Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785
>
>

From neteler at itc.it  Fri Oct  6 21:04:42 2006
From: neteler at itc.it (Markus Neteler)
Date: Fri Oct  6 21:04:44 2006
Subject: [GRASS-dev] tmpfile() -> G_asprintf fails on Win/MinGW
In-Reply-To: <340505ef0610061138o5f47ca6esabdca9c105952db1@mail.gmail.com>
References: <340505ef0610060835o7b84763cnfc350797915e8477@mail.gmail.com>
	<20061006154338.GP9196@bartok.itc.it>
	<340505ef0610061138o5f47ca6esabdca9c105952db1@mail.gmail.com>
Message-ID: <20061006190442.GA23056@bartok.itc.it>

On Fri, Oct 06, 2006 at 08:38:07PM +0200, Radim Blazek wrote:
> Thanks,
> unfortunately I found that it would not work when no mapset is open
> (read only access) so I changed it to use Windows native functions to get 
> temp
> file. Another patch  is attached.
> 
> Radim

Patch applied to 6.3-CVS and 6.2-rel-branch.

Markus

PS: Concerning your re-activation of ssh CVS write access, I
suspect that you may be missing "-1" in $HOME/.ssh2402 
Mine is looking like this:

cat $HOME/.ssh2402
#!/bin/sh
ssh -1 -p 2402 $*

From neteler at itc.it  Fri Oct  6 21:42:03 2006
From: neteler at itc.it (Markus Neteler)
Date: Fri Oct  6 21:42:05 2006
Subject: [GRASS-dev] GRASS 6.2.0RC2 released
Message-ID: <20061006194203.GA23463@bartok.itc.it>

Dear all,

as promised, I have released GRASS 6.2.0RC2 some minutes
ago:
http://grass.itc.it/grass62/

Fixes include:
    * r.random on MacOSX (Glynn)
    * document improvements (various)
    * v.in.ogr: check valid output filename (Brad)
    * various r.le fixes (Hamish)
    * MinGW fix (Radim) 

Please test as much as possible.
This is hopefully the last release candidate.

Thanks to all contributors,
Markus
-- 
Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
ITC-irst -  Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy

From epatton at nrcan.gc.ca  Fri Oct  6 21:44:51 2006
From: epatton at nrcan.gc.ca (Patton, Eric)
Date: Fri Oct  6 21:44:58 2006
Subject: [GRASS-dev] RE: Your post on Grass list: i.group failed in new
	Georectifier
Message-ID: <0E5A77B55A57D511BB3F0002A537C26208C55BCB@s5-dar-r1.nrn.nrcan.gc.ca>

Thanks for looking into this. I'm actually using 6.3, updated the cvs today.

~ Eric. 

-----Original Message-----
From: Michael Barton
To: Patton, Eric
Cc: GRASS devel
Sent: 10/6/2006 2:32 PM
Subject: Re: Your post on Grass list: i.group failed in new Georectifier

Eric,

I'm completely baffled. It must be some other kinds of changes in GRASS
affecting this. Is the only one that doesn't work? You can grep
run_panel
*.tcl in the /etc/gm folder and see what else uses it. You can make a
change
with a text editor with no need to recompile.

I have to make a confession that the version I'm working with is a
couple
weeks old, but has all current tcltk files. I'm concerned that some
other
change in the tcltk parser is creating problems with running some
things.
i.group should not be problematic since it doesn't require an xterm to
run.

The "run" procedure is used widely. I can think of no reason why "exec
--
i.group >& /dev/null" should not work. I notice that you do not have the
new
devnull variable that makes this workable in Windows, so you must be
running
6.1 or 6.2. I don't know whether that makes a difference or not.

Given all this, I'm forwarding this to the general developer list to see
what's going on.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: "Patton, Eric" <epatton@nrcan.gc.ca>
> Date: Fri, 6 Oct 2006 13:42:51 -0300
> To: 'Michael Barton ' <michael.barton@asu.edu>
> Subject: RE: Your post on Grass list: i.group failed in new
Georectifier
> 
> Still no luck. I made your edit (substituting run for run_panel),
> re-complied, and I get a tcl error:
> 
>  child process exited abnormally
> child process exited abnormally
>     while executing
> "exec -- i.group >& /dev/null"
>     ("eval" body line 1)
>     invoked from within
> "eval [list exec -- $cmd] $args >& $devnull"
>     (procedure "run" line 12)
>     invoked from within
> "run $cmd"
>     (procedure "GRMap::group" line 11)
>     invoked from within
> "GRMap::group"
>     ("uplevel" body line 1)
>     invoked from within
> "uplevel \#0 $cmd"
>     (procedure "Button::_release" line 18)
>     invoked from within
> "Button::_release .grstart.mf.frame.group.a"
>     (command bound to event)
> 
> The vector group chooser works fine, but then I see that it doesn't
call
> i.group either. Actually, I noticed that the i.group call is the only
time
> in the whole tcl script that 'run_panel' is used. I thought I could
test to
> see if run_panel ran successfully in other instances in georect.tcl.
> 
> ~ Eric.
> 
> 
> -----Original Message-----
> From: Michael Barton
> To: Patton, Eric
> Sent: 10/6/2006 12:02 PM
> Subject: Re: Your post on Grass list: i.group failed in new
Georectifier
> 
> Try substituting "run" for "run_panel" in the line that calls i.group
> and
> see what happens. I have no way to test because it works fine for me.
> 
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics and Complexity
> Arizona State University
> 
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
> 
> 
>> From: "Patton, Eric" <epatton@nrcan.gc.ca>
>> Date: Fri, 6 Oct 2006 12:31:31 -0300
>> To: 'Michael Barton ' <michael.barton@asu.edu>
>> Subject: RE: Your post on Grass list: i.group failed in new
> Georectifier
>> 
>> Hm, i.group works fine from both the GUI and comand line; i.group -l
> shows
>> my newly created imagery groups.
>> 
>> It's almost like the georectifying tool is passing i.group a null
> string for
>> the name of the group parameter as soon as button #2 is clicked,
> causing
>> i.group to fail. I take it that clicking button #2 'Create edit
group'
> is
>> supposed to launch the GUI version of i.group? It's strange. I can
try
> to
>> take a look at georect.tcl and see if anything obvious sticks out,
> although
>> I kow barely any tcl.
>> 
>> I'm using Ubuntu 6.06 on a Dell PC.
>> 
>> ~ Eric. 
>> 
>> -----Original Message-----
>> From: Michael Barton
>> To: Patton, Eric
>> Sent: 10/6/2006 11:06 AM
>> Subject: Re: Your post on Grass list: i.group failed in new
> Georectifier
>> 
>> Have you tried running i.group from the command line and from the
> menu?
>> What
>> happens in both.
>> 
>> I'm running i.group in exactly the same way as other commands are
run.
> I
>> can
>> change the procedure, but wonder if this is causing problems with
> other
>> commands too on your system.
>> 
>> BTW, what system are you doing this on?
>> 
>> Michael
>> __________________________________________
>> Michael Barton, Professor of Anthropology
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 
>> 
>>> From: "Patton, Eric" <epatton@nrcan.gc.ca>
>>> Date: Fri, 6 Oct 2006 10:59:58 -0300
>>> To: 'Michael Barton ' <michael.barton@asu.edu>
>>> Subject: RE: Your post on Grass list: i.group failed in new
>> Georectifier
>>> 
>>> Michael,
>>> 
>>> I tried it again after updating to CVS - same thing:
>>> 
>>>  
>>> ERROR: Required parameter <group> not set:
>>>     (Name of imagery group).
>>> 
>>> ~ Eric.
>>> 
>>> 
>>> -----Original Message-----
>>> From: Michael Barton
>>> To: Patton, Eric
>>> Sent: 10/5/2006 5:37 PM
>>> Subject: Re: Your post on Grass list: i.group failed in new
>> Georectifier
>>> 
>>> Probably not. I bet mine went in about 15 minutes later.
>>> 
>>> Michael
>>> __________________________________________
>>> Michael Barton, Professor of Anthropology
>>> School of Human Evolution & Social Change
>>> Center for Social Dynamics and Complexity
>>> Arizona State University
>>> 
>>> phone: 480-965-6213
>>> fax: 480-965-7671
>>> www: http://www.public.asu.edu/~cmbarton
>>> 
>>> 
>>> 
>> 
> 

From michael.barton at asu.edu  Fri Oct  6 22:24:54 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Fri Oct  6 22:25:03 2006
Subject: [GRASS-dev] Re: Your post on Grass list: i.group failed in new
	Georectifier
In-Reply-To: <0E5A77B55A57D511BB3F0002A537C26208C55BCB@s5-dar-r1.nrn.nrcan.gc.ca>
Message-ID: <C14C09A6.25503%michael.barton@asu.edu>

If you're using 6.3 there is a problem. The error code below indicates that
it is missing the Windows patches. I'll look into it and see if I can figure
it out.

What is your platform?

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: "Patton, Eric" <epatton@nrcan.gc.ca>
> Date: Fri, 6 Oct 2006 16:44:51 -0300
> To: 'Michael Barton ' <michael.barton@asu.edu>
> Cc: 'GRASS devel ' <grass-dev@grass.itc.it>
> Subject: RE: Your post on Grass list: i.group failed in new Georectifier
> 
> Thanks for looking into this. I'm actually using 6.3, updated the cvs today.
> 
> ~ Eric. 
> 
> -----Original Message-----
> From: Michael Barton
> To: Patton, Eric
> Cc: GRASS devel
> Sent: 10/6/2006 2:32 PM
> Subject: Re: Your post on Grass list: i.group failed in new Georectifier
> 
> Eric,
> 
> I'm completely baffled. It must be some other kinds of changes in GRASS
> affecting this. Is the only one that doesn't work? You can grep
> run_panel
> *.tcl in the /etc/gm folder and see what else uses it. You can make a
> change
> with a text editor with no need to recompile.
> 
> I have to make a confession that the version I'm working with is a
> couple
> weeks old, but has all current tcltk files. I'm concerned that some
> other
> change in the tcltk parser is creating problems with running some
> things.
> i.group should not be problematic since it doesn't require an xterm to
> run.
> 
> The "run" procedure is used widely. I can think of no reason why "exec
> --
> i.group >& /dev/null" should not work. I notice that you do not have the
> new
> devnull variable that makes this workable in Windows, so you must be
> running
> 6.1 or 6.2. I don't know whether that makes a difference or not.
> 
> Given all this, I'm forwarding this to the general developer list to see
> what's going on.
> 
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics and Complexity
> Arizona State University
> 
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
> 
> 
>> From: "Patton, Eric" <epatton@nrcan.gc.ca>
>> Date: Fri, 6 Oct 2006 13:42:51 -0300
>> To: 'Michael Barton ' <michael.barton@asu.edu>
>> Subject: RE: Your post on Grass list: i.group failed in new
> Georectifier
>> 
>> Still no luck. I made your edit (substituting run for run_panel),
>> re-complied, and I get a tcl error:
>> 
>>  child process exited abnormally
>> child process exited abnormally
>>     while executing
>> "exec -- i.group >& /dev/null"
>>     ("eval" body line 1)
>>     invoked from within
>> "eval [list exec -- $cmd] $args >& $devnull"
>>     (procedure "run" line 12)
>>     invoked from within
>> "run $cmd"
>>     (procedure "GRMap::group" line 11)
>>     invoked from within
>> "GRMap::group"
>>     ("uplevel" body line 1)
>>     invoked from within
>> "uplevel \#0 $cmd"
>>     (procedure "Button::_release" line 18)
>>     invoked from within
>> "Button::_release .grstart.mf.frame.group.a"
>>     (command bound to event)
>> 
>> The vector group chooser works fine, but then I see that it doesn't
> call
>> i.group either. Actually, I noticed that the i.group call is the only
> time
>> in the whole tcl script that 'run_panel' is used. I thought I could
> test to
>> see if run_panel ran successfully in other instances in georect.tcl.
>> 
>> ~ Eric.
>> 
>> 
>> -----Original Message-----
>> From: Michael Barton
>> To: Patton, Eric
>> Sent: 10/6/2006 12:02 PM
>> Subject: Re: Your post on Grass list: i.group failed in new
> Georectifier
>> 
>> Try substituting "run" for "run_panel" in the line that calls i.group
>> and
>> see what happens. I have no way to test because it works fine for me.
>> 
>> Michael
>> __________________________________________
>> Michael Barton, Professor of Anthropology
>> School of Human Evolution & Social Change
>> Center for Social Dynamics and Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 
>>> From: "Patton, Eric" <epatton@nrcan.gc.ca>
>>> Date: Fri, 6 Oct 2006 12:31:31 -0300
>>> To: 'Michael Barton ' <michael.barton@asu.edu>
>>> Subject: RE: Your post on Grass list: i.group failed in new
>> Georectifier
>>> 
>>> Hm, i.group works fine from both the GUI and comand line; i.group -l
>> shows
>>> my newly created imagery groups.
>>> 
>>> It's almost like the georectifying tool is passing i.group a null
>> string for
>>> the name of the group parameter as soon as button #2 is clicked,
>> causing
>>> i.group to fail. I take it that clicking button #2 'Create edit
> group'
>> is
>>> supposed to launch the GUI version of i.group? It's strange. I can
> try
>> to
>>> take a look at georect.tcl and see if anything obvious sticks out,
>> although
>>> I kow barely any tcl.
>>> 
>>> I'm using Ubuntu 6.06 on a Dell PC.
>>> 
>>> ~ Eric. 
>>> 
>>> -----Original Message-----
>>> From: Michael Barton
>>> To: Patton, Eric
>>> Sent: 10/6/2006 11:06 AM
>>> Subject: Re: Your post on Grass list: i.group failed in new
>> Georectifier
>>> 
>>> Have you tried running i.group from the command line and from the
>> menu?
>>> What
>>> happens in both.
>>> 
>>> I'm running i.group in exactly the same way as other commands are
> run.
>> I
>>> can
>>> change the procedure, but wonder if this is causing problems with
>> other
>>> commands too on your system.
>>> 
>>> BTW, what system are you doing this on?
>>> 
>>> Michael
>>> __________________________________________
>>> Michael Barton, Professor of Anthropology
>>> School of Human Evolution & Social Change
>>> Center for Social Dynamics & Complexity
>>> Arizona State University
>>> 
>>> phone: 480-965-6213
>>> fax: 480-965-7671
>>> www: http://www.public.asu.edu/~cmbarton
>>> 
>>> 
>>> 
>>>> From: "Patton, Eric" <epatton@nrcan.gc.ca>
>>>> Date: Fri, 6 Oct 2006 10:59:58 -0300
>>>> To: 'Michael Barton ' <michael.barton@asu.edu>
>>>> Subject: RE: Your post on Grass list: i.group failed in new
>>> Georectifier
>>>> 
>>>> Michael,
>>>> 
>>>> I tried it again after updating to CVS - same thing:
>>>> 
>>>>  
>>>> ERROR: Required parameter <group> not set:
>>>>     (Name of imagery group).
>>>> 
>>>> ~ Eric.
>>>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Michael Barton
>>>> To: Patton, Eric
>>>> Sent: 10/5/2006 5:37 PM
>>>> Subject: Re: Your post on Grass list: i.group failed in new
>>> Georectifier
>>>> 
>>>> Probably not. I bet mine went in about 15 minutes later.
>>>> 
>>>> Michael
>>>> __________________________________________
>>>> Michael Barton, Professor of Anthropology
>>>> School of Human Evolution & Social Change
>>>> Center for Social Dynamics and Complexity
>>>> Arizona State University
>>>> 
>>>> phone: 480-965-6213
>>>> fax: 480-965-7671
>>>> www: http://www.public.asu.edu/~cmbarton
>>>> 
>>>> 
>>>> 
>>> 
>> 
> 

From glynn at gclements.plus.com  Fri Oct  6 22:56:51 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri Oct  6 22:56:54 2006
Subject: [GRASS-dev] help with r.le.setup bug
In-Reply-To: <17701.65489.384104.860083@cerise.gclements.plus.com>
References: <20061005202758.5cada66a.hamish_nospam@yahoo.com>
	<17701.36465.481407.663082@cerise.gclements.plus.com>
	<20061006171053.6c363735.hamish_nospam@yahoo.com>
	<17701.65489.384104.860083@cerise.gclements.plus.com>
Message-ID: <17702.49939.387436.834468@cerise.gclements.plus.com>


Glynn Clements wrote:

> > > > I think it's a simple type mismatch in variables getting passed to a
> > > > function.
> > 
> > > It is. ux/uy are arrays of ints but calc_unit_loc() expects arrays of
> > > doubles.
> > > 
> > > Try the attached patch.
> > 
> > [also cast to int for overlap() fn]
> > 
> > yes, thanks.  funny, even with your patch it still messes up the "y"
> > values of draw_box() unless I add in the fn prototype to setup.h.
> 
> Right. overlap() expects "int"s, but some of the values passed are
> changed to double by my patch. If a valid prototype is in scope, the
> compiler will automatically cast them to int, otherwise it will pass
> them as double.
> 
> All of those declarations in setup.h should be either fixed or
> removed. If the compiler needs a prototype (because the function isn't
> already in scope at the point that it's used), it needs the *correct*
> prototype.

I've cleaned up r.le.setup. All of the functions have correct
prototypes, and any which aren't used outside of the file in which
they are defined have been declared "static". Also, I've removed the
local copy of the <dirent.h> stuff.

There is one warning which may indicate an error:

sample.c:826: warning: suggest parentheses around assignment used as truth value

which relates to:

	   if (n = i % h_d)

I don't know enough about the code to determine whether this is meant
to be an assignment or a comparison.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Fri Oct  6 23:05:23 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri Oct  6 23:05:26 2006
Subject: [GRASS-dev] VASKLIB in IMAGERYLIB?
In-Reply-To: <340505ef0610060525t47c42bewc31702abc6edd83d@mail.gmail.com>
References: <340505ef0610060525t47c42bewc31702abc6edd83d@mail.gmail.com>
Message-ID: <17702.50451.24247.833053@cerise.gclements.plus.com>


Radim Blazek wrote:

> adding VASKLIB to IMAGERYLIB breaks compilation of some modules
> (r.in.gdal) on windows  or --without-curses. VASKLIB is not used by in modules
> which use IMAGERYLIB, IMO VASKLIB should only be used in modules Makefiles
> which realy use it.

That approach fails if IMAGERYLIB is a shared library.

The most robust solution would be to move the parts of IMAGERYLIB
which depend upon VASKLIB into a separate library.

-- 
Glynn Clements <glynn@gclements.plus.com>

From tutey at o2.pl  Sat Oct  7 13:32:25 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sat Oct  7 13:32:33 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
Message-ID: <45279049.9030907@o2.pl>

Hi,

Propably due to the recent work on --v and --q flags (great stuff, many
thanks to the authors!), r.mapcalc doesn't print any progress indicator
anymore.

Also g.remove doesn't return any info if trying to remove a
non-existant map. If used with --v it will print eg.:

$ g.remove rast=dummy --v
REMOVE [dummy]
raster MISSING
header MISSING
category MISSING
color MISSING
history MISSING
misc MISSING
fcell MISSING
g3dcell MISSING

as it used before introducing --q and --v. But if --v is not
explicitely set (default), it will remain silent.

It should print "ERROR: raster map <dummy> not found" instead.

And IMO it would be best if it printed such info in either case (quiet
or verbose), as the current g.remove --v output is over-informative.
All those header/category/color etc. entries are a noise that should be
printed only at a higher level of debug, not by defalt, I think.

BTW - what's the "g3dcell" above?

If the map to be removed is present, in --q mode nothing should be
printed, and in the --v mode only "Raster map <dummy> removed" instead
of the current 9 lines of output.


Also in case of vectors, currently it's:


		exists:			doesn't exist:

--v:	REMOVE [x]		REMOVE [x]
				ERROR: Vector map <x> not found

--q:	silent			ERROR: Vector map <x> not found




Which should be:



		exists:			doesn't exist:

--v:	Vector map <x> removed	ERROR: Vector map <x> not found

--q:	silent			ERROR: Vector map <x> not found


Maciek

From grass-bugs at intevation.de  Sat Oct  7 13:45:21 2006
From: grass-bugs at intevation.de (Maciek Sieczka via RT)
Date: Sat Oct  7 13:45:23 2006
Subject: [GRASS-dev] [bug #5176] (grass) v.in.ogr: segfault when a full path
	to dsn is missing
Message-ID: <20061007114521.0058910015B@lists.intevation.de>

rez@touchofmadness.com wrote (Thu, Oct 5 2006 05:35:57):

> Should be fixed in CVS.

Brad,

I'm sorry but it's not. Still exactly the same problem using today's CVS.


Here's a backtrace:

$ ulimit -c 3000
$ grass63
$ v.in.ogr dsn=force_lrconnect_cl_onlycat139
output=force_lrconnect_cl_onlycat139_import
layer=force_lrconnect_cl_onlycat139

(segfault)

$ gdb v.in.ogr core

(gdb) bt
#0  0x00010101 in ?? ()
#1  0xb7cb5c2f in OGRSpatialReference::Release ()
   from /usr/local/lib/libgdal.so.1
#2  0xb7cab4e7 in OGRGeometry::~OGRGeometry () from
/usr/local/lib/libgdal.so.1
#3  0xb7ca6810 in OGRCurve::~OGRCurve () from /usr/local/lib/libgdal.so.1
#4  0xb7ca6ad8 in OGRLineString::~OGRLineString ()
   from /usr/local/lib/libgdal.so.1
#5  0xb7caf6ff in OGRFeature::~OGRFeature () from
/usr/local/lib/libgdal.so.1
#6  0xb7caefa5 in OGR_F_Destroy () from /usr/local/lib/libgdal.so.1
#7  0x0804ccfc in main (argc=4, argv=0xbffcb044) at main.c:744
(gdb) q


Grass or GDAL issue? Using GDAL 1.3.2+CVS 2006-07-24.

Maciek


-------------------------------------------- Managed by Request Tracker

From mlennert at club.worldonline.be  Sat Oct  7 16:02:32 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sat Oct  7 16:02:12 2006
Subject: [GRASS-dev] adding 'desc' to dbf sql driver
In-Reply-To: <1a486f560609271831m747f3495sa6d8495273c107d4@mail.gmail.com>
References: <4513A84E.8090807@club.worldonline.be>
	<1a486f560609271831m747f3495sa6d8495273c107d4@mail.gmail.com>
Message-ID: <48506.85.10.69.159.1160229752.squirrel@geog-pc40.ulb.ac.be>

Hi Daniel,

On Thu, September 28, 2006 03:31, Daniel Calvelo wrote:
> Hi Moritz. See below
>
> On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:
>> Hi,
>>
>> Reworking on d.vect.chart I need to be able to sort the reults of a
>> select in descending order. As the dbf driver doesn't allow this, I have
>> been trying to see how to extend the driver.
>>
>> IIUC, it's "just" a question of conditionalising the qsort call on line
>> 566 of db/drivers/dbf/dbfexe.c, and (would this be enough ?) use
>>
>> qsort(set, nset, sizeof(int), -cmp_row);
>
> That might work. Although it would be much nicer to use an expression
> as sorting order.
>
>> if the desc keyword is present.
>>
>> However, I have some trouble understanding the parsing of the sql
>> statement.
>>
>> If I understand correctly, we would need to extent the SQLPSTMT
>> structure in include/sqlp.h to include a flag for 'desc' (and possible
>> 'asc') and the parser to identify and set that flag.
>>
>> But this is as far as I get. Could someone help me with this ?
>
> Quick shot: you need to
>
> - change SQLPSTMT to have an "order"/"direction"/"sort_order"  element
>
> - add ASC and DESC in lex.l as tokens
>
> - change yac.y to stg like:
>
> y_order: y_order_asc | y_order_desc ;
> y_order_asc:
>        NAME ASC { sqpOrderColumn( $1 ); sqpOrderDirection( 1 ); }
> ;
> y_order_desc:
>       NAME DESC { sqpOrderColumn( $1 );sqpOrderDirection( 2 );}
> ;
>
> - add in sql.c a sqpOrderDirection() function that sets the element
> you added to SQLPSTMT
>
> (Alternatively, you can change sqpOrderColumn() to receive two
> arguments, one being the sorting direction. I'd also rather #define
> SORT_ASC and SORT_DESC instead of using magic numbers as above.)
>
> - use that value in dbfexe.c to test the sorting direction.

Here's an attempt at translating your very clear instructions. Could you
or someone else just have a quick look to see if I didn't do anything bad.
One question for me was how to handle the different comparison functions
for ASC and DESC. At this stage I just duplicated the function
(cmp_row_asc and cpm_row_desc) and inverted the signs. Maybe there is a
more elegant way ?

Thanks !

Moritz
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbf.diff.tgz
Type: application/x-compressed-tar
Size: 1919 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061007/5a26e8d2/dbf.diff.bin
From grass-bugs at intevation.de  Sat Oct  7 17:19:36 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Sat Oct  7 17:19:38 2006
Subject: [GRASS-dev] [bug #5192] (grass) tclsh error in
	/grass-6.2.0RC2/etc/gm/gm.tcl
Message-ID: <20061007151936.EC3A810015B@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5192
-------------------------------------------------------------------------

Subject: tclsh error in /grass-6.2.0RC2/etc/gm/gm.tcl

Platform: GNU/Linux/x86
grass obtained from: Trento Italy site
grass binary for platform: Compiled from Sources

Hello,

I packaged GRASS 6.2.0RC2 for Pardus -Linux. When I start GRASS, I get this error below.

And tcl version is 8.5_alpha3...

murat@pardus grass $ grass
Cleaning up temporary files.....
Starting GRASS ...










Welcome to GRASS 6.2.0RC2 (2006)
GRASS homepage:                          http://grass.itc.it/
This version running thru:               Bash Shell (/bin/bash)
Help is available with the command:      g.manual -i
See the licence terms with:              g.version -c
If required, restart the graphical user interface with: gis.m &
When ready to quit enter:                exit
GRASS 6.2.0RC2 (samples):~/Desktop/grass > Error in startup script: bad variable name "coords(1)": upvar won't create a scalar variable that looks like an array element
    while executing
"global coords($mon)"
    (procedure "MapCanvas::pointer" line 5)
    invoked from within
"MapCanvas::pointer $mon"
    (procedure "MapCanvas::create" line 226)
    invoked from within
"MapCanvas::create"
    (procedure "Gm::startmon" line 11)
    invoked from within
"Gm::startmon"
    (procedure "Gm::create" line 69)
    invoked from within
"Gm::create"
    (procedure "main" line 30)
    invoked from within
"main $argc $argv"
    (file "/var/tmp/pisi/grass-6.2.0_rc2-3/install/opt/grass-6.2.0RC2/etc/gm/gm.tcl" line 521)

-------------------------------------------- Managed by Request Tracker

From glynn at gclements.plus.com  Sun Oct  8 01:13:33 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Oct  8 01:13:35 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <45279049.9030907@o2.pl>
References: <45279049.9030907@o2.pl>
Message-ID: <17704.13469.442502.801590@cerise.gclements.plus.com>


Maciej Sieczka wrote:

> Propably due to the recent work on --v and --q flags (great stuff, many
> thanks to the authors!), r.mapcalc doesn't print any progress indicator
> anymore.

AFAIK, modules are quiet by default now. If you want verbosity (e.g.
progress indication) you have to enable it.

As r.mapcalc doesn't use G_parser(), --v won't work; you would need to
set GRASS_VERBOSE.

There probably needs to be a "stub" version of G_parser() which
implements the built-in switches (--help, --verbose etc) but doesn't
attempt to parse the entire command line.

Changing the syntax of r.mapcalc to conform to the normal convention
would probably be too radical a change. While we can fix our own
scripts, there are likely to be a lot of home-grown scripts which
would be broken (not to mention users who are accustomed to using the
existing syntax from the command line).

> Also g.remove doesn't return any info if trying to remove a
> non-existant map. If used with --v it will print eg.:
> 
> $ g.remove rast=dummy --v
> REMOVE [dummy]
> raster MISSING
> header MISSING
> category MISSING
> color MISSING
> history MISSING
> misc MISSING
> fcell MISSING
> g3dcell MISSING
> 
> as it used before introducing --q and --v. But if --v is not
> explicitely set (default), it will remain silent.
> 
> It should print "ERROR: raster map <dummy> not found" instead.

Specifying a map which doesn't exist (one with no elements) has never
been an error. At most, it should generate a warning if no elements
are found.

-- 
Glynn Clements <glynn@gclements.plus.com>

From hamish_nospam at yahoo.com  Sun Oct  8 04:40:44 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 04:40:51 2006
Subject: [GRASS-dev] proj -l
Message-ID: <20061008154044.4c9f4a45.hamish_nospam@yahoo.com>

Hi,

I just learned of the "proj -l" command from PROJ.4. (post on Proj.4 ml)

       -l[p|P|=|e|u|d]id
              List projection identifiers with -l,  -lp
              or  -lP  (expanded)  that can be selected
              with   +proj.    -l=id   gives   expanded
              description   of   projection  id.   List
              ellipsoid identifiers with -le, that  can
              be  selected  with  +ellps,  -lu  list of
              cartesian  to  meter  conversion  factors
              that  can  be selected with +units or -ld
              list of datums that can be selected  with
              +datum.


Maybe it would be useful in a future auto-gen g.setproj GUI wizard [if
GRASS moves to "full" use of proj.4].


Hamish

From hamish_nospam at yahoo.com  Sun Oct  8 04:59:45 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 05:00:01 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect
	causes error :can't read "_data(.gronsole.gronsole, 9,
	donecmd)": no such element in array
In-Reply-To: <45267957.2020505@club.worldonline.be>
References: <45267957.2020505@club.worldonline.be>
Message-ID: <20061008155945.57c29721.hamish_nospam@yahoo.com>

Moritz Lennert wrote:
> Using a where clause in vector display in gis.m causes the following 
> error under WinGRASS. Any suggestions ?
> (WinGRASS version 2006-09-17)
> 
> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
> element in array
>      while executing
> "set donecmd $_data($path,$ci,donecmd)"


also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
query in the "query cat values" box by mistake. I just made the same
mistake trying to recreate your error.

(spearfish dataset, "fields" vector map, query: "cat > 30")


Put the query in the "use SQL query" box not the "query cat values" and
it performs the query & display correctly.

If you put "30" in the "query cat values" box it just draws area 30.

If you put "30,54" in the "query cat values" box it just draws areas 30
and 54.

If you put "30-54" in the "query cat values" box it just draws areas 30
through 54.

If you put "30-54" in the "query cat values" box it just draws areas 30
through 54.

If you put "30-54,63" in the "query cat values" box it just draws areas
30 through 54 and area 63.


I think the ">" is getting treated as a redirect. With other non int
range stuff in that line G_parser() gives an understandable error.


better wording and/or input sanity checks needed in gis.m..
 (or note-to-self for future WxPython rewrites).


Hamish

From grass-bugs at intevation.de  Sun Oct  8 06:05:35 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Sun Oct  8 06:05:37 2006
Subject: [GRASS-dev] [bug #5193] (grass) Javier
Message-ID: <20061008040535.5A28510015B@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5193
-------------------------------------------------------------------------

Subject: Javier

grass binary for platform: Compiled from Sources

Please enter your name and error description here. Don't write general statements such as "this could be better" - please explain in
details how a certain problem can be solved or a feature be added/improved. Send different report for different problems. Thanks!

-------------------------------------------- Managed by Request Tracker

From hamish_nospam at yahoo.com  Sun Oct  8 06:46:46 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 06:46:51 2006
Subject: [GRASS-dev] extraneous files in grass-6.2.0RC2.tar.gz & 6.2.0
	release plans
Message-ID: <20061008174646.6a7d04b2.hamish_nospam@yahoo.com>

Hi,

"lib/init/gis_set.tcl.orig" shouldn't be there.

$ tar tzf grass-6.2.0RC2.tar.gz | grep gis_set.tcl
grass-6.2.0RC2/lib/init/gis_set.tcl.orig
grass-6.2.0RC2/lib/init/gis_set.tcl

also,  visualization/nviz/scripts/nviz2.2_script.orig

they don't seem to be in CVS so problem is just left over local files.
("? path/filename" at start of processing with "cvs update -q")


In 6.3-cvs I have removed the tcltk web browsers from NVIZ and (the
duplicate) in lib/init/. Both were previously made redundant by Markus.
This saves ~ 240kb in the source tree.




RC2 builds fine on Debian/Sarge (tcltk 8.3).

For me, the welcome text is now large, but not huge:

  Welcome to GRASS GIS Version 6.2.0RC2
   The world's leading open source GIS

 Select an existing project location and mapset
   or define a new location



known release to-dos:
 [high priority]
 - refine the press release
 - make v.digit 8.3 compatible, note "gis.m may need 8.4" in REQUIREMENTS.html

 [minor]
 - r.le.* G_calloc() before G_gisinit()

 [optional]
 - apply v.buffer patch? (trade bad known bug for lightly tested band-aid)
 - remove TclTk web browser from NVIZ & lin/init/ (merge from HEAD)

 [??]
 - anything else?


Hamish

From ychemin at gmail.com  Sun Oct  8 06:50:02 2006
From: ychemin at gmail.com (Yann Chemin)
Date: Sun Oct  8 06:50:05 2006
Subject: [GRASS-dev] r.albedo
Message-ID: <6278879c0610072150m5ba26ad0k33d5b2a5104df19e@mail.gmail.com>

Hi all,

a small module, r.albedo, enables calculation of shortwave Albedo from
individual reflectance files for Aster, Modis, Landsat and AVHRR. This
is a precursor to r.sun and other modeling like energy-belance for
example.

direct download
---------------------
http://www.star.ait.ac.th/~yann/r.albedo.tar.gz

WIKI
------
http://grass.gdf-hannover.de/wiki/GRASS_AddOns#Raster_add-ons



-- 
residence:
http://maps.google.com/maps?q=37.936037,58.402939&hl=en&ie=UTF8&om=1&z=18&ll=37.93624,58.40332&spn=0.002018,0.004565&t=h&iwloc=A
office:
http://maps.google.com/maps?q=37.941735,58.383912&hl=en&ie=UTF8&om=1&z=18&ll=37.941795,58.384084&spn=0.002018,0.004565&t=h&iwloc=A

Some Google Working rules:
*  Developers can switch teams and/or projects any time they want, no
questions asked; just say the word and the movers will show up the
next day to put you in your new office with your new team.
* There aren't very many meetings. I'd say an average developer
attends perhaps 3 meetings a week.
* Google has a philosophy of not ever telling developers what to work
on, and they take it pretty seriously.
* Google tends not to pre-announce. They really do understand that you
can't rush good cooking, you can't rush babies out, and you can't rush
software development.

From hamish_nospam at yahoo.com  Sun Oct  8 08:18:27 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 08:18:41 2006
Subject: [GRASS-dev] what can come before G_gisinit()?
In-Reply-To: <17701.65039.812309.262648@cerise.gclements.plus.com>
References: <20061006145647.17f50301.hamish_nospam@yahoo.com>
	<17701.65039.812309.262648@cerise.gclements.plus.com>
Message-ID: <20061008191827.2d0f1b74.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> 
> > is it ok to call G_calloc() before G_gisinit()?
> 
> No.
> 
> G_calloc() calls G_fatal_error() if calloc() fails. G_fatal_error()
> calls G_program_name(), which uses the program name set by
> G_gisinit().



Ok, r.le needs some more fixing then, e.g. r.le.patch

main.c:
struct CHOICE *choice;

int main(){
  struct GModule *module;

  /* allocate space for the choice data structure */
  choice = (struct CHOICE *)G_calloc(1, sizeof(struct CHOICE));
 ..
  G_gisinit();
  module = G_define_module();
  user_input(argc,argv);
 ..
  fprintf(stderr, "\tMAP:\t  %s\n", choice->fn);
 ..
}

input.c:
extern struct CHOICE *choice;  // again!!

void user_input (int argc, char **argv) {
  ..
   struct Option *name;
   struct Option *sampling_method;
  ..
   G_gisinit(argv[0]);   // again!!
  ..
   name = G_define_option();
   sampling_method = G_define_option();
  ..
   if (G_parser(argc,argv))
      exit(EXIT_FAILURE);
  ..
   G_strcpy(choice->fn, name->answer);

   choice->wrum = sampling_method->answer[0];
  ..
}

patch.h:
struct CHOICE {
        char fn[30], reg[30],out[30],
             wrum;
        int  core2, size2, shape2,
             edge, fb, coremap, units;
        int  perim2, trace, patchmap;   
        int  Mx[4];
        int  att[9], size[9], shape[8], 
             boundary[5], perim[8], core[11];
        } ;
   ...
/** main.c **/
void  user_input();



too many choices,
Hamish

From hamish_nospam at yahoo.com  Sun Oct  8 09:16:56 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 09:17:01 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <72C13BC4-FC1F-485B-A6A8-2B1BF77D4796@mac.com>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BA6@s5-dar-r1.nrn.nrcan.gc.ca>
	<72C13BC4-FC1F-485B-A6A8-2B1BF77D4796@mac.com>
Message-ID: <20061008201656.383bd7b9.hamish_nospam@yahoo.com>

- gedit
+ nedit


;)

Hamish

From mlennert at club.worldonline.be  Sun Oct  8 10:30:22 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sun Oct  8 10:30:03 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect 
	causes error :can't read "_data(.gronsole.gronsole,9,
	donecmd)": no such element in array
In-Reply-To: <20061008155945.57c29721.hamish_nospam@yahoo.com>
References: <45267957.2020505@club.worldonline.be>
	<20061008155945.57c29721.hamish_nospam@yahoo.com>
Message-ID: <42215.85.10.65.158.1160296222.squirrel@geog-pc40.ulb.ac.be>

On Sun, October 8, 2006 04:59, Hamish wrote:
> Moritz Lennert wrote:
>> Using a where clause in vector display in gis.m causes the following
>> error under WinGRASS. Any suggestions ?
>> (WinGRASS version 2006-09-17)
>>
>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>> element in array
>>      while executing
>> "set donecmd $_data($path,$ci,donecmd)"
>
>
> also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
> query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive that this
is not the problem here. I entered the query in the where box, not the cat
box.

But I'll make sure tomorrow.

Moritz


From mlennert at club.worldonline.be  Sun Oct  8 10:37:49 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Sun Oct  8 10:37:28 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect  
	causes error :can't read "_data(.gronsole.gronsole,9,
	donecmd)": no such element in array
In-Reply-To: <42215.85.10.65.158.1160296222.squirrel@geog-pc40.ulb.ac.be>
References: <45267957.2020505@club.worldonline.be>
	<20061008155945.57c29721.hamish_nospam@yahoo.com>
	<42215.85.10.65.158.1160296222.squirrel@geog-pc40.ulb.ac.be>
Message-ID: <43559.85.10.65.158.1160296669.squirrel@geog-pc40.ulb.ac.be>

On Sun, October 8, 2006 10:30, Moritz Lennert wrote:
> On Sun, October 8, 2006 04:59, Hamish wrote:
>> Moritz Lennert wrote:
>>> Using a where clause in vector display in gis.m causes the following
>>> error under WinGRASS. Any suggestions ?
>>> (WinGRASS version 2006-09-17)
>>>
>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>>> element in array
>>>      while executing
>>> "set donecmd $_data($path,$ci,donecmd)"
>>
>>
>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
>> query in the "query cat values" box by mistake.
>
> I am not near a windows box right now, but I am quite positive that this
> is not the problem here. I entered the query in the where box, not the cat
> box.
>
> But I'll make sure tomorrow.

Actually I just managed to test (Qemu over NX, quite an experience ;-) ),
and I can confirm that the problem is with the sql query box. So it is not
the same problem as the one described by Hamish.

Moritz


From hamish_nospam at yahoo.com  Sun Oct  8 11:03:34 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 11:09:52 2006
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
In-Reply-To: <C14BBE17.F729%michael.barton@asu.edu>
References: <20061005070346.GB30865@bartok.itc.it>
	<C14BBE17.F729%michael.barton@asu.edu>
Message-ID: <20061008220334.26ae410f.hamish_nospam@yahoo.com>

Michael Barton wrote:
> It turns out that bwidget LabelFrame is not just a drop in replacement
> for the tk 8.4 labelframe. For one thing, LabelFrame seems buggy in
> the version of bwidgets that GRASS uses and the frame border will not
> draw with a label there. Second the options are slightly different.

Yes, I can't get a frame border either. Thanks for translating the options.

There are (Very Good) bwidget instructions and demo.tcl in the GRASS 5
source code. (hopefully you found them?)

[should we copy into GRASS 6 lib/external/bwidget?
 252K    demo/
 368K    BWman/
]

cd grass-5.4.0/src/libes/bwidget/demo/
wish demo.tcl

in the demo the LabelFrames borders work correctly, so I think it is
something we are overlooking (???).


> If you want to replace the labelframe statement in toolbox.tcl (ca.
> Line 223) with the following and see what happens,

I do want to replace it for 6.2,

> On my Mac, running x11, it creates the label but does not draw the
> box, no matter what I do. This is problematic, but maybe it at least
> runs on 8.3.

As it works in demo/demo.tcl, I think it's a fixable bug on our behalf.
( somewhere :-/  window parent/child relationship? lack of content?)

> Again, I can't say if there are any other 8.4 features that won't run
> on 8.3, so I'm not sure it's worth it anyway.

.. but but but .. are there bwidget replacements for those we can use?

=== (lib/external/bwidget/README.grass) ========
only requires 2 lines of code in your Tcl/Tk script to use the new widgets.
Some of the new widgets include

    On mouse over help balloons
    Tabbed notebook panes - like worksheets in Excel
    Directory tree listing
    Combination box or drop down option list
    Progress bar
    Many others
================================================

seems to me that there should be replacements, and we don't (really)
have to worry about finding any we don't know about until we get an
error report. And then it's a (hopefully) quick fix. We are pretty
sure this is the only v.digit problem, and pretty sure that d.m is ok
(so I'm not as worried about gis.m).


> LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
>     -text [G_msg "mouse button actions (left, right, center)"]

works for me (besides missing border). I expect it will work on all
platforms (I can't see why it wouldn't).

An immediate solution: adding "-background HoneyDew" makes the
"-relief groove -borderwidth 1" failure less important.


thanks,
Hamish

From hamish_nospam at yahoo.com  Sun Oct  8 12:08:41 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 12:08:54 2006
Subject: [GRASS-dev] Re: [GRASS-user] r.what and d.what.rast
In-Reply-To: <20061003225622.74b6887f@localhost.localdomain>
References: <000501c6e63d$ae6695f0$7a4291c1@ceh.cedex.es>
	<20061003225622.74b6887f@localhost.localdomain>
Message-ID: <20061008230841.42889bb7.hamish_nospam@yahoo.com>

Trevor Wiens wrote:
> Javier ??lvarez Rodr??guez wrote:
> 
> > Hi all,
> > My problem is about I'm obtaining different results when using d.what.rast
> > and r.what. 
> > Using interactively d.what.rast on a map named bas, I obtain these
> > results:
> > 
> > 361421.875(E) 4540953.125(N)
> > bas in DATOS, quant   (854)
> > bas in DATOS, actual  (854.000000)
> > 
> > Then I write x and y coordinates in a file named pp3.txt 
> > 
> > 361421 4540953 (no matter real or integer coordinates)
> > 
> > and when using r.what
> > r.what bas@DATOS < pp3.txt
> > result is 860
> 
> I'm not sure of the cause, but in doing some tests of the same data
> set, it would appear that r.what is probably reporting incorrectly.
> 
> I looked at the code briefly and can't see any obvious errors, but I'm
> ccing the developers list to see if anyone has seen this bug before.


The problem is with d.what.rast when zoomed out:

# spearfish dataset
G63> g.region elevation.10m
G63> d.rast elvation.10m

G63> d.what.rast 

Buttons
 Left:  what's here
 Right: quit

595509.1750503(E) 4920363.03822938(N)
elevation.10m in PERMANENT, quant   (1432)
elevation.10m in PERMANENT, actual  (1432.339600)


G63> r.what in=elevation.10m east_north=595509.1750503,4920363.03822938
595509.1750503|4920363.03822938||1432.65918


1432.339600  !=  1432.65918


G63> r.stats -1gn elevation.10m | grep 1432.3396            
595515 4920365 1432.3396

G63> r.stats -1gn elevation.10m | grep 1432.65918
595505 4920365 1432.65918


Indeed, reported x coordinate is off by one column.


G63> g.region n=4920450 s=n-100  e=595550 w=e-80
G63> d.redraw

G63> d.rast.num elevation.10m

G63> echo -e "width 2\nsymbol basic/circle 30 595509.1 4920363.0 yellow none" \
  | d.graph -m


G63> d.what.rast -c
595509.81707317(E) 4920363.23170732(N), 549(col) 763(row)
elevation.10m in PERMANENT, quant   (1433)
elevation.10m in PERMANENT, actual  (1432.659180)

595510.30487805(E) 4920363.23170732(N), 550(col) 763(row)
elevation.10m in PERMANENT, quant   (1432)
elevation.10m in PERMANENT, actual  (1432.339600)


So it works ok once zoomed in.

G63> r.what in=elevation.10m east_north=595509.81707317,4920364.20731707
595509.81707317|4920364.20731707||1432.65918

G63> r.what in=elevation.10m east_north=595510.06097561,4920364.08536585
595510.06097561|4920364.08536585||1432.3396



#zooming back out:
g.region rast=elevation.10m
d.redraw
echo -e "width 2\nsymbol basic/circle 5 595509.1 4920363.0 yellow none" \
  | d.graph -m
d.what.rast -c

595518.63321799(E) 4920366.76470588(N), 550(col) 763(row)
elevation.10m in PERMANENT, quant   (1432)
elevation.10m in PERMANENT, actual  (1432.462769)

G63> r.stats -1gn elevation.10m | grep 1432.462769   
595515 4920375 1432.462769

now d.what.rast's y is off by one row ...



Hamish


ps - display/d.what.rast/what.c
  if (G_get_c_raster_row (fd[i], buf, row) < 0)

should that be G_get_raster_row(,, type) ??

From tutey at o2.pl  Sun Oct  8 12:43:35 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sun Oct  8 12:43:38 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <17704.13469.442502.801590@cerise.gclements.plus.com>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
Message-ID: <4528D657.9080803@o2.pl>

Glynn Clements wrote:

> Maciej Sieczka wrote:

>> Propably due to the recent work on --v and --q flags (great stuff, many
>> thanks to the authors!), r.mapcalc doesn't print any progress indicator
>> anymore.

> AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> progress indication) you have to enable it.

I didn't realize that quiet mode implies no progress indicator. In that
case verbose should be the default IMO, because we can't leave users
without a feedback from the module progress unless they implicitely
requests that. Am I wrong?

> As r.mapcalc doesn't use G_parser(), --v won't work; you would need to
> set GRASS_VERBOSE.
> 
> There probably needs to be a "stub" version of G_parser() which
> implements the built-in switches (--help, --verbose etc) but doesn't
> attempt to parse the entire command line.
> 
> Changing the syntax of r.mapcalc to conform to the normal convention
> would probably be too radical a change. While we can fix our own
> scripts, there are likely to be a lot of home-grown scripts which
> would be broken (not to mention users who are accustomed to using the
> existing syntax from the command line).

If verbose would be the default that would also fix the problem of
no-progress in r.mapcalc by default.

>> Also g.remove doesn't return any info if trying to remove a
>> non-existant map. If used with --v it will print eg.:
>>
>> $ g.remove rast=dummy --v
>> REMOVE [dummy]
>> raster MISSING
>> header MISSING
>> category MISSING
>> color MISSING
>> history MISSING
>> misc MISSING
>> fcell MISSING
>> g3dcell MISSING
>>
>> as it used before introducing --q and --v. But if --v is not
>> explicitely set (default), it will remain silent.
>>
>> It should print "ERROR: raster map <dummy> not found" instead.

> Specifying a map which doesn't exist (one with no elements) has never
> been an error.

Not really, it is an error in case of vectors already. Try this:

$ g.remove vect=dummy

you'll get:

ERROR: Vector map <dummy> not found

$ echo $?
1

> At most, it should generate a warning if no elements
> are found.

Why shouldn't it generate an error? The user is trying to use a
non-existant map for the g.remove input. Other modules return an error
in such case. g.remove vect does the same. But g.remove
rast/rast3d/region/group doesn't. Shouldn't they conform?

Also, in the verbose mode, only a single-line information like "Raster
map <dummy> removed" should be printed insated of the current 9 lines:

$ g.remove rast=dummy --v
REMOVE [dummy]
raster
header
category
color MISSING
history
misc
fcell MISSING
g3dcell MISSING

BTW, I'd like to ask again what is the g3dcell?





Talking of g.remove - could the following types should be disposed in
GRASS 7?:

1. sites - there is no sites functionality in Grass>=5.7
2. region3d - 3D region settings have been merged into region
3. 3dview - remainment of Grass <5.7 3d.view command
4? icon - I don't know, propably too? what is it?
5. oldvect
6. asciivect

Same applies to g.copy/rename/list

?

Maciek

From hamish_nospam at yahoo.com  Sun Oct  8 13:21:49 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 13:22:01 2006
Subject: [GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??
In-Reply-To: <452104F6.7070101@o2.pl>
References: <20061002012404.885D61005D8@lists.intevation.de>
	<452104F6.7070101@o2.pl>
Message-ID: <20061009002149.6e81787a.hamish_nospam@yahoo.com>

Maciej Sieczka wrote:
> I have tried your recent patch you sent.
> 
> It improves things a bit, but doesn't solve the bug yet. See the
> attached screndumps. These are xcf files, so you extract the v.buffer
> syntax used from them.
> 
> As you can see the 4m (buf4.xcf) buffer of my ditches looks kindoff
> better - there is no single bulge now, but a buffered ditch. The
> problems are that the buffer width is not 4m as declared, but circa 1m
> and there is a half-bulge on the left side and some artifact at the
> top-left.
> 
> In case of the 1m buffer (buf1.xcf) there is no change at all when
> compared to the previous result.
> 
> If you still have the sample Grass location (vbuffer_bugs) I sent you
> please try reproducing these.


patch applied to 6.3-cvs and 6.2 branch.

square_rot_buf30 is fixed.
ditch_1188 is fixed.


1 and 4m buffer around ditches seem to work fine for me, but they did
before the patch. (?)  (command taken from "v.info -h ditches_buf1")


I still see the "holes get filled" bug in my own data though,
 (v.buffer in=roads bufcol="LANE_COUNT")

so that one's still open.

I seem to remeber Radim commenting on this a long time ago, here we go,
complete with screenshots:
  http://grass.itc.it/pipermail/grass-dev/2005-November/020133.html
  http://grass.itc.it/pipermail/grass-dev/2005-November/020136.html
  http://thread.gmane.org/gmane.comp.gis.grass.devel/9506


This is probably the same bug in v.buffer as you see and nothing to do
with buffcol= (??).

Ahh, I've got you now Obi Wan, the interior-fill bug happens when there
is an interior dangle in my road network ... and I've isolated it to a
vector made up of 10 polylines.

can you try buffering your ditches after
  v.clean tool=rmdangle thresh=[big]
?



I don't understand why you consistently get the error, and I
don't, using the same* dataset.  [*] are we really using the same data?

md5sum vbuffer_bugs.tar.bz2
d229fb3e5724acb7bf6314d940fc4def  vbuffer_bugs.tar.bz2



Hamish

From hamish_nospam at yahoo.com  Sun Oct  8 14:04:14 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 14:04:19 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <4528D657.9080803@o2.pl>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
Message-ID: <20061009010414.26e05b9a.hamish_nospam@yahoo.com>

Maciej Sieczka wrote:

> >> Propably due to the recent work on --v and --q flags (great stuff,
> >> many thanks to the authors!), r.mapcalc doesn't print any progress
> >> indicator anymore.
>
> > AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> > progress indication) you have to enable it.
>
> I didn't realize that quiet mode implies no progress indicator. In
> that case verbose should be the default IMO, because we can't leave
> users without a feedback from the module progress unless they
> implicitely requests that. Am I wrong?

(not sure if I fully understand the current mode, sorry I haven't been
following this thread, but from observation, ...)

I think it is wrong to make all modules --quiet be default. Many years
of tuning have gone into the current message level, we just throw that
out? Sure some modules are very noisy and that should be dealt with
(remove useless noise and move debug info to G_debug()).

IMO the "only create output if something interesting happens"
guideline should only apply to UNIX-like small "do one thing well"
modules. Quick little modules used in a script (ie in a loop) can be
made a bit quieter, sure.

But for long running modules like v.surf.rst and r.sun, we should
definitely let the user know what's going on, what mode the module is
running in, how many points used for processing, etc. Anything which is
expected to take longer than about 10 seconds under normal conditions
should at least give G_percent() output IMO.

This is especially important for new users who are not confident or
knowledgeable about what is going on or how long it will take.

Hiding all G_message() and G_percent() output *by default* is totally
nuts. Adding --quiet or GRASS_VERBOSE=0 isn't hard if you are writing a
script or GUI frontend.

It's great to have the fine grained control, but I suggest this change:

Index: verbose.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/gis/verbose.c,v
retrieving revision 2.3
diff -u -r2.3 verbose.c
--- verbose.c   25 Sep 2006 09:43:09 -0000      2.3
+++ verbose.c   8 Oct 2006 11:52:26 -0000
@@ -46,7 +46,7 @@
                 ;
         }
         else
-            verbose = MINLEVEL;
+            verbose = MAXLEVEL;
     }
     return verbose;
 }



2c,
Hamish


ps -
in verbose.c, is this test correct?

static int verbose;
G_verbose() {
 ..
    /* verbose not defined -> get it from env. */
    if ( !verbose ) {
 ..
}

so it gets read from GRASS_VERBOSE not only if its unset but also if
it happens to be at MINLEVEL?

From hamish_nospam at yahoo.com  Sun Oct  8 14:11:18 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun Oct  8 14:11:22 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <4528D657.9080803@o2.pl>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
Message-ID: <20061009011118.5cb42753.hamish_nospam@yahoo.com>

Maciej Sieczka wrote:
> $ g.remove rast=dummy --v
> REMOVE [dummy]
..
> g3dcell MISSING
> 
> BTW, I'd like to ask again what is the g3dcell?

3D raster map created with r3.*
?


> Talking of g.remove - could the following types should be disposed in
> GRASS 7?:
> 
> 1. sites - there is no sites functionality in Grass>=5.7

actually there is, see lib/sites/README
by 7.0 this may be gone though.

> 4? icon - I don't know, propably too? what is it?

this should stay. A user (without write access to $GISBASE) can have their
own vector symbols in their a mapset. (icon=basic/circle and friends)
probably change the name to symbol.

> 5. oldvect

backwards compatibility with GRASS 5, keep as long as we keep v.convert.

> 6. asciivect

v.out.ascii / v.in.ascii used to store format=standard data in a folder 
in the mapset. keep for backwards compatibility with GRASS 5, keep as
long as we keep v.convert.
 
> Same applies to g.copy/rename/list

types should be listed in g.list help page.


Hamish

From glynn at gclements.plus.com  Sun Oct  8 14:35:05 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Oct  8 14:35:07 2006
Subject: [GRASS-dev] proj -l
In-Reply-To: <20061008154044.4c9f4a45.hamish_nospam@yahoo.com>
References: <20061008154044.4c9f4a45.hamish_nospam@yahoo.com>
Message-ID: <17704.61561.885010.737049@cerise.gclements.plus.com>


Hamish wrote:

> I just learned of the "proj -l" command from PROJ.4. (post on Proj.4 ml)
> 
>        -l[p|P|=|e|u|d]id
>               List projection identifiers with -l,  -lp
>               or  -lP  (expanded)  that can be selected
>               with   +proj.    -l=id   gives   expanded
>               description   of   projection  id.   List
>               ellipsoid identifiers with -le, that  can
>               be  selected  with  +ellps,  -lu  list of
>               cartesian  to  meter  conversion  factors
>               that  can  be selected with +units or -ld
>               list of datums that can be selected  with
>               +datum.
> 
> 
> Maybe it would be useful in a future auto-gen g.setproj GUI wizard [if
> GRASS moves to "full" use of proj.4].

It doesn't really help. -l alone only lists the projections, not which
parameters they accept/require. -lP lists the parameters, but the
format isn't quite machine-readable (it's not far off, but a miss is
as good as mile in this context). No option lists the default values.

Also, there's no guarantee that whichever "proj" executable comes
first in the path uses the same libproj library as GRASS.

For the foreseeable future, we'll need to maintain our own metadata.

-- 
Glynn Clements <glynn@gclements.plus.com>

From tutey at o2.pl  Sun Oct  8 14:40:36 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sun Oct  8 14:40:40 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <20061009011118.5cb42753.hamish_nospam@yahoo.com>
References: <45279049.9030907@o2.pl>	<17704.13469.442502.801590@cerise.gclements.plus.com>	<4528D657.9080803@o2.pl>
	<20061009011118.5cb42753.hamish_nospam@yahoo.com>
Message-ID: <4528F1C4.9080703@o2.pl>

Hamish wrote:
> Maciej Sieczka wrote:
>> $ g.remove rast=dummy --v
>> REMOVE [dummy]
> .
>> g3dcell MISSING
>>
>> BTW, I'd like to ask again what is the g3dcell?
> 
> 3D raster map created with r3.*
> ?

I think not. Create a rast3d and rast maps of the same name 'dummy'.
Although rast3d 'dummy' is present, g.remove rast=dummy still prints
"g3dcell MISSING"

Why would rast3d be listed in 'g.remove *rast*' output anyway?

>> Talking of g.remove - could the following types should be disposed in
>> GRASS 7?:
>>
>> 1. sites - there is no sites functionality in Grass>=5.7
> 
> actually there is, see lib/sites/README
> by 7.0 this may be gone though.

My bad (there is even v.in.sites in Grass 6).

>> 4? icon - I don't know, propably too? what is it?
> 
> this should stay. A user (without write access to $GISBASE) can have their
> own vector symbols in their a mapset. (icon=basic/circle and friends)
> probably change the name to symbol.

Where exactly in the mapset can be icons stored?

What are the Grass commands to create those icons? I mean - if there
are none, either in Grass 5 or 6, there also shouldn't be a command
for... removing them.

>> 5. oldvect
> 
> backwards compatibility with GRASS 5, keep as long as we keep v.convert.
> 
>> 6. asciivect
> 
> v.out.ascii / v.in.ascii used to store format=standard data in a folder 
> in the mapset. keep for backwards compatibility with GRASS 5, keep as
> long as we keep v.convert.
>  
>> Same applies to g.copy/rename/list
> 
> types should be listed in g.list help page.

Or better there should be a general site with types described and each
g.copy/list/remove/rename should link to it.

Maciek

From glynn at gclements.plus.com  Sun Oct  8 14:40:56 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Oct  8 14:40:59 2006
Subject: [GRASS-dev] extraneous files in grass-6.2.0RC2.tar.gz & 6.2.0
	release plans
In-Reply-To: <20061008174646.6a7d04b2.hamish_nospam@yahoo.com>
References: <20061008174646.6a7d04b2.hamish_nospam@yahoo.com>
Message-ID: <17704.61912.698944.25387@cerise.gclements.plus.com>


Hamish wrote:

> "lib/init/gis_set.tcl.orig" shouldn't be there.
> 
> $ tar tzf grass-6.2.0RC2.tar.gz | grep gis_set.tcl
> grass-6.2.0RC2/lib/init/gis_set.tcl.orig
> grass-6.2.0RC2/lib/init/gis_set.tcl
> 
> also,  visualization/nviz/scripts/nviz2.2_script.orig
> 
> they don't seem to be in CVS so problem is just left over local files.
> ("? path/filename" at start of processing with "cvs update -q")

CVS ignores files and directories which match specific patterns; by
default, the list includes "*.orig". It won't attempt to check in or
update such files, and they won't be listed with a "?" if you update a
directory.

>From the CVS Info file:

: Ignoring files via cvsignore
: ============================
: 
:    There are certain file names that frequently occur inside your
: working copy, but that you don't want to put under CVS control.
: Examples are all the object files that you get while you compile your
: sources.  Normally, when you run `cvs update', it prints a line for
: each file it encounters that it doesn't know about (*note update
: output::).
: 
:    CVS has a list of files (or sh(1) file name patterns) that it should
: ignore while running `update', `import' and `release'.  This list is
: constructed in the following way.
: 
:    * The list is initialized to include certain file name patterns:
:      names associated with CVS administration, or with other common
:      source control systems; common names for patch files, object files,
:      archive files, and editor backup files; and other names that are
:      usually artifacts of assorted utilities.  Currently, the default
:      list of ignored file name patterns is:
: 
:               RCS     SCCS    CVS     CVS.adm
:               RCSLOG  cvslog.*
:               tags    TAGS
:               .make.state     .nse_depinfo
:               *~      #*      .#*     ,*      _$*     *$
:               *.old   *.bak   *.BAK   *.orig  *.rej   .del-*
:               *.a     *.olb   *.o     *.obj   *.so    *.exe
:               *.Z     *.elc   *.ln
:               core
: 
:    * The per-repository list in `$CVSROOT/CVSROOT/cvsignore' is
:      appended to the list, if that file exists.
: 
:    * The per-user list in `.cvsignore' in your home directory is
:      appended to the list, if it exists.
: 
:    * Any entries in the environment variable `$CVSIGNORE' is appended
:      to the list.
: 
:    * Any `-I' options given to CVS is appended.
: 
:    * As CVS traverses through your directories, the contents of any
:      `.cvsignore' will be appended to the list.  The patterns found in
:      `.cvsignore' are only valid for the directory that contains them,
:      not for any sub-directories.
: 
:    In any of the 5 places listed above, a single exclamation mark (`!')
: clears the ignore list.  This can be used if you want to store any file
: which normally is ignored by CVS.
: 
:    Specifying `-I !' to `cvs import' will import everything, which is
: generally what you want to do if you are importing files from a
: pristine distribution or any other source which is known to not contain
: any extraneous files.  However, looking at the rules above you will see
: there is a fly in the ointment; if the distribution contains any
: `.cvsignore' files, then the patterns from those files will be
: processed even if `-I !' is specified.  The only workaround is to
: remove the `.cvsignore' files in order to do the import.  Because this
: is awkward, in the future `-I !' might be modified to override
: `.cvsignore' files in each directory.
: 
:    Note that the syntax of the ignore files consists of a series of
: lines, each of which contains a space separated list of filenames.
: This offers no clean way to specify filenames which contain spaces, but
: you can use a workaround like `foo?bar' to match a file named `foo bar'
: (it also matches `fooxbar' and the like).  Also note that there is
: currently no way to specify comments.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Sun Oct  8 15:04:46 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Oct  8 15:04:48 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <4528D657.9080803@o2.pl>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
Message-ID: <17704.63342.78554.477221@cerise.gclements.plus.com>


Maciej Sieczka wrote:

> >> Propably due to the recent work on --v and --q flags (great stuff, many
> >> thanks to the authors!), r.mapcalc doesn't print any progress indicator
> >> anymore.
> 
> > AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> > progress indication) you have to enable it.
> 
> I didn't realize that quiet mode implies no progress indicator. In that
> case verbose should be the default IMO, because we can't leave users
> without a feedback from the module progress unless they implicitely
> requests that. Am I wrong?

Yes. The normal behaviour for Unix command-line programs is not to
print anything unless something unexpected happens.

> > Specifying a map which doesn't exist (one with no elements) has never
> > been an error.
> 
> Not really, it is an error in case of vectors already. Try this:
> 
> $ g.remove vect=dummy

It has never been an error for rasters (or other types), and wasn't
for vectors until the vector subsystem was changed to the DBMI-backed
implementation.

The fact that it's now an error for vectors (and only vectors) is
essentially an oversight.

When vector maps ceased to be simply a collection of files, the
general/manage code needed to be modified for that specific case. If
you look at the code, you will note that most of it is "generic"; it
applies to any type of entity which is defined in the
$GISBASE/etc/element_list. Vectors are a hard-coded special case.

> > At most, it should generate a warning if no elements
> > are found.
> 
> Why shouldn't it generate an error? The user is trying to use a
> non-existant map for the g.remove input. Other modules return an error
> in such case. g.remove vect does the same. But g.remove
> rast/rast3d/region/group doesn't. Shouldn't they conform?

Compatibility. Management commands are used extensively in scripts.

Apart from anything else, generating an error at the point that the
specific map is processed (the way that vectors are currently handled)
means that it won't even attempt to remove any subsequent maps. E.g.

	g.remove vect=vect1,vectnonexist,vect2

will abort on vectnonexist and won't attempt to remove vect2.

> Also, in the verbose mode, only a single-line information like "Raster
> map <dummy> removed" should be printed insated of the current 9 lines:
> 
> $ g.remove rast=dummy --v
> REMOVE [dummy]
> raster
> header
> category
> color MISSING
> history
> misc
> fcell MISSING
> g3dcell MISSING

IMHO, verbose mode should display everything, quiet mode should
display a single warning for each map with no elements (i.e. the map
doesn't exist).

> BTW, I'd like to ask again what is the g3dcell?

No idea.

> Talking of g.remove - could the following types should be disposed in
> GRASS 7?:
> 
> 1. sites - there is no sites functionality in Grass>=5.7
> 2. region3d - 3D region settings have been merged into region
> 3. 3dview - remainment of Grass <5.7 3d.view command
> 4? icon - I don't know, propably too? what is it?
> 5. oldvect
> 6. asciivect
> 
> Same applies to g.copy/rename/list

Removing them from copy/rename seems reasonable enough. However you
might upgrade from 5.x to 6.x but still have 5.x entities left in the
database directories, so you need some way to remove them.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Sun Oct  8 15:11:57 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun Oct  8 15:11:59 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <20061009010414.26e05b9a.hamish_nospam@yahoo.com>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
	<20061009010414.26e05b9a.hamish_nospam@yahoo.com>
Message-ID: <17704.63773.101985.783481@cerise.gclements.plus.com>


Hamish wrote:

> > >> Propably due to the recent work on --v and --q flags (great stuff,
> > >> many thanks to the authors!), r.mapcalc doesn't print any progress
> > >> indicator anymore.
> >
> > > AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> > > progress indication) you have to enable it.
> >
> > I didn't realize that quiet mode implies no progress indicator. In
> > that case verbose should be the default IMO, because we can't leave
> > users without a feedback from the module progress unless they
> > implicitely requests that. Am I wrong?
> 
> (not sure if I fully understand the current mode, sorry I haven't been
> following this thread, but from observation, ...)
> 
> I think it is wrong to make all modules --quiet be default. Many years
> of tuning have gone into the current message level, we just throw that
> out?

I doubt that there has been any "tuning". Previously, modules wrote
out anything which the author thought might be useful to someone, on
the basis that the user can ignore what is displayed but can't see
something which isn't displayed. Unless a piece of information was
always displayed, it simply wasn't available.

> ps -
> in verbose.c, is this test correct?

No.

> static int verbose;
> G_verbose() {
>  ..
>     /* verbose not defined -> get it from env. */
>     if ( !verbose ) {
>  ..
> }
> 
> so it gets read from GRASS_VERBOSE not only if its unset but also if
> it happens to be at MINLEVEL?

It should initialise verbose to -1 then check "if (verbose < 0) ..." 
instead.

-- 
Glynn Clements <glynn@gclements.plus.com>

From landa.martin at gmail.com  Sun Oct  8 15:39:42 2006
From: landa.martin at gmail.com (Martin Landa)
Date: Sun Oct  8 15:39:46 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <20061009010414.26e05b9a.hamish_nospam@yahoo.com>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
	<20061009010414.26e05b9a.hamish_nospam@yahoo.com>
Message-ID: <f8fe65c40610080639tc726718kd90284e2ec7bff5b@mail.gmail.com>

Hi,

I agree, default verbose level should be set to MAXLEVEL (--v) ...

Martin

2006/10/8, Hamish <hamish_nospam@yahoo.com>:
> Maciej Sieczka wrote:
>
> > >> Propably due to the recent work on --v and --q flags (great stuff,
> > >> many thanks to the authors!), r.mapcalc doesn't print any progress
> > >> indicator anymore.
> >
> > > AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> > > progress indication) you have to enable it.
> >
> > I didn't realize that quiet mode implies no progress indicator. In
> > that case verbose should be the default IMO, because we can't leave
> > users without a feedback from the module progress unless they
> > implicitely requests that. Am I wrong?
>
> (not sure if I fully understand the current mode, sorry I haven't been
> following this thread, but from observation, ...)
>
> I think it is wrong to make all modules --quiet be default. Many years
> of tuning have gone into the current message level, we just throw that
> out? Sure some modules are very noisy and that should be dealt with
> (remove useless noise and move debug info to G_debug()).
>
> IMO the "only create output if something interesting happens"
> guideline should only apply to UNIX-like small "do one thing well"
> modules. Quick little modules used in a script (ie in a loop) can be
> made a bit quieter, sure.
>
> But for long running modules like v.surf.rst and r.sun, we should
> definitely let the user know what's going on, what mode the module is
> running in, how many points used for processing, etc. Anything which is
> expected to take longer than about 10 seconds under normal conditions
> should at least give G_percent() output IMO.
>
> This is especially important for new users who are not confident or
> knowledgeable about what is going on or how long it will take.
>
> Hiding all G_message() and G_percent() output *by default* is totally
> nuts. Adding --quiet or GRASS_VERBOSE=0 isn't hard if you are writing a
> script or GUI frontend.
>
> It's great to have the fine grained control, but I suggest this change:
>
> Index: verbose.c
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/lib/gis/verbose.c,v
> retrieving revision 2.3
> diff -u -r2.3 verbose.c
> --- verbose.c   25 Sep 2006 09:43:09 -0000      2.3
> +++ verbose.c   8 Oct 2006 11:52:26 -0000
> @@ -46,7 +46,7 @@
>                  ;
>          }
>          else
> -            verbose = MINLEVEL;
> +            verbose = MAXLEVEL;
>      }
>      return verbose;
>  }
>
>
>
> 2c,
> Hamish
>
>
> ps -
> in verbose.c, is this test correct?
>
> static int verbose;
> G_verbose() {
>  ..
>     /* verbose not defined -> get it from env. */
>     if ( !verbose ) {
>  ..
> }
>
> so it gets read from GRASS_VERBOSE not only if its unset but also if
> it happens to be at MINLEVEL?
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

From tutey at o2.pl  Sun Oct  8 15:48:42 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sun Oct  8 15:48:46 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <17704.63342.78554.477221@cerise.gclements.plus.com>
References: <45279049.9030907@o2.pl>	<17704.13469.442502.801590@cerise.gclements.plus.com>	<4528D657.9080803@o2.pl>
	<17704.63342.78554.477221@cerise.gclements.plus.com>
Message-ID: <452901BA.1060603@o2.pl>

Glynn Clements wrote:

> Maciej Sieczka wrote:

>>>> Propably due to the recent work on --v and --q flags (great stuff, many
>>>> thanks to the authors!), r.mapcalc doesn't print any progress indicator
>>>> anymore.
>>> AFAIK, modules are quiet by default now. If you want verbosity (e.g.
>>> progress indication) you have to enable it.

>> I didn't realize that quiet mode implies no progress indicator. In that
>> case verbose should be the default IMO, because we can't leave users
>> without a feedback from the module progress unless they implicitely
>> requests that. Am I wrong?

> Yes. The normal behaviour for Unix command-line programs is not to
> print anything unless something unexpected happens.

GRASS modules are not 'normal UNIX programs'. A user must be informed
if there's a progress. Otherwise he will not even know if the module
freezed or what. I fully second what Hamish says in this regard (in his
post in this thread).

>>> Specifying a map which doesn't exist (one with no elements) has never
>>> been an error.

>> Not really, it is an error in case of vectors already. Try this:
>>
>> $ g.remove vect=dummy

> It has never been an error for rasters (or other types), and wasn't
> for vectors until the vector subsystem was changed to the DBMI-backed
> implementation.
> 
> The fact that it's now an error for vectors (and only vectors) is
> essentially an oversight.
> 
> When vector maps ceased to be simply a collection of files, the
> general/manage code needed to be modified for that specific case. If
> you look at the code, you will note that most of it is "generic"; it
> applies to any type of entity which is defined in the
> $GISBASE/etc/element_list. Vectors are a hard-coded special case.

>>> At most, it should generate a warning if no elements
>>> are found.

>> Why shouldn't it generate an error? The user is trying to use a
>> non-existant map for the g.remove input. Other modules return an error
>> in such case. g.remove vect does the same. But g.remove
>> rast/rast3d/region/group doesn't. Shouldn't they conform?

> Compatibility. Management commands are used extensively in scripts.
> 
> Apart from anything else, generating an error at the point that the
> specific map is processed (the way that vectors are currently handled)
> means that it won't even attempt to remove any subsequent maps. E.g.
> 
> 	g.remove vect=vect1,vectnonexist,vect2
> 
> will abort on vectnonexist and won't attempt to remove vect2.

Fine. Then g.remove vect should be fixed to behave like the other
types, and a non-fatal "WARNING: Vector map <dummy> not found" shoud be
issued if needed. Same for all other types. And, most importantly,
those warnings should issued by default, unless the user requests
g.remove to run quietly (which implies that a verbose mode should be
the default). Otherwise the user will not know that the map he tried to
remove doesn't exist.

>> Also, in the verbose mode, only a single-line information like "Raster
>> map <dummy> removed" should be printed insated of the current 9 lines:
>>
>> $ g.remove rast=dummy --v
>> REMOVE [dummy]
>> raster
>> header
>> category
>> color MISSING
>> history
>> misc
>> fcell MISSING
>> g3dcell MISSING

> IMHO, verbose mode should display everything, quiet mode should
> display a single warning for each map with no elements (i.e. the map
> doesn't exist).

But all those lines: raster, header, category, color, history, misc,
fcell are meaningless for a normal user. He should only be told that
"Raster map <blahblah> was removed". Why does one need to read all
those lines anyway? They don't give any usefull information but
distract and occupy space on the terminal. They should be displayed
only at a higher DEBUG level.

>>> g3dcell MISSING

>> BTW, I'd like to ask again what is the g3dcell?

> No idea.

Could it be removed then?

>> Talking of g.remove - could the following types should be disposed in
>> GRASS 7?:
>>
>> 1. sites - there is no sites functionality in Grass>=5.7
>> 2. region3d - 3D region settings have been merged into region
>> 3. 3dview - remainment of Grass <5.7 3d.view command
>> 4? icon - I don't know, propably too? what is it?
>> 5. oldvect
>> 6. asciivect
>>
>> Same applies to g.copy/rename/list

> Removing them from copy/rename seems reasonable enough. However you
> might upgrade from 5.x to 6.x

I'm talking about GRASS 7.

> but still have 5.x entities left in the database directories, so
> you need some way to remove them.

The question might be: is GRASS 7 supposed to provide tools to make the
switch from GRASS 5 easy, like GRASS 6 does?

Maciek

From tutey at o2.pl  Sun Oct  8 15:59:02 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sun Oct  8 15:59:07 2006
Subject: [GRASS-dev] Grass Documentation How-to html page
In-Reply-To: <20061008201656.383bd7b9.hamish_nospam@yahoo.com>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BA6@s5-dar-r1.nrn.nrcan.gc.ca>	<72C13BC4-FC1F-485B-A6A8-2B1BF77D4796@mac.com>
	<20061008201656.383bd7b9.hamish_nospam@yahoo.com>
Message-ID: <45290426.1020509@o2.pl>

Hamish wrote:
> - gedit
> + nedit

Either is as good as it's bad. Eg. on my Ubuntu Dapper I don't have
nedit installed by default. Luckily this example is not neccessary. A
general reference to "a text editor" in the sentence is enough for
anyone to understand it.

Maciek

From landa.martin at gmail.com  Sun Oct  8 15:59:26 2006
From: landa.martin at gmail.com (Martin Landa)
Date: Sun Oct  8 15:59:29 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <f8fe65c40610080639tc726718kd90284e2ec7bff5b@mail.gmail.com>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
	<20061009010414.26e05b9a.hamish_nospam@yahoo.com>
	<f8fe65c40610080639tc726718kd90284e2ec7bff5b@mail.gmail.com>
Message-ID: <f8fe65c40610080659p70f4569ape498a9cd3dc51546@mail.gmail.com>

... I meant that all G_percent () and G_message () output should be
printed by default (in the current verbose implementation it is
MAXLEVEL).

 * Currently, there are 3 levels of verbosity:
 * \param 0 - module should print nothing but errors and warnings
(G_fatal_error, G_warning)
 * \param 1 - module will print progress information (G_percent)
 * \param 2 - module will print all messages (G_message)


Martin

2006/10/8, Martin Landa <landa.martin@gmail.com>:
> Hi,
>
> I agree, default verbose level should be set to MAXLEVEL (--v) ...
>
> Martin
>
> 2006/10/8, Hamish <hamish_nospam@yahoo.com>:
> > Maciej Sieczka wrote:
> >
> > > >> Propably due to the recent work on --v and --q flags (great stuff,
> > > >> many thanks to the authors!), r.mapcalc doesn't print any progress
> > > >> indicator anymore.
> > >
> > > > AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> > > > progress indication) you have to enable it.
> > >
> > > I didn't realize that quiet mode implies no progress indicator. In
> > > that case verbose should be the default IMO, because we can't leave
> > > users without a feedback from the module progress unless they
> > > implicitely requests that. Am I wrong?
> >
> > (not sure if I fully understand the current mode, sorry I haven't been
> > following this thread, but from observation, ...)
> >
> > I think it is wrong to make all modules --quiet be default. Many years
> > of tuning have gone into the current message level, we just throw that
> > out? Sure some modules are very noisy and that should be dealt with
> > (remove useless noise and move debug info to G_debug()).
> >
> > IMO the "only create output if something interesting happens"
> > guideline should only apply to UNIX-like small "do one thing well"
> > modules. Quick little modules used in a script (ie in a loop) can be
> > made a bit quieter, sure.
> >
> > But for long running modules like v.surf.rst and r.sun, we should
> > definitely let the user know what's going on, what mode the module is
> > running in, how many points used for processing, etc. Anything which is
> > expected to take longer than about 10 seconds under normal conditions
> > should at least give G_percent() output IMO.
> >
> > This is especially important for new users who are not confident or
> > knowledgeable about what is going on or how long it will take.
> >
> > Hiding all G_message() and G_percent() output *by default* is totally
> > nuts. Adding --quiet or GRASS_VERBOSE=0 isn't hard if you are writing a
> > script or GUI frontend.
> >
> > It's great to have the fine grained control, but I suggest this change:
> >
> > Index: verbose.c
> > ===================================================================
> > RCS file: /home/grass/grassrepository/grass6/lib/gis/verbose.c,v
> > retrieving revision 2.3
> > diff -u -r2.3 verbose.c
> > --- verbose.c   25 Sep 2006 09:43:09 -0000      2.3
> > +++ verbose.c   8 Oct 2006 11:52:26 -0000
> > @@ -46,7 +46,7 @@
> >                  ;
> >          }
> >          else
> > -            verbose = MINLEVEL;
> > +            verbose = MAXLEVEL;
> >      }
> >      return verbose;
> >  }
> >
> >
> >
> > 2c,
> > Hamish
> >
> >
> > ps -
> > in verbose.c, is this test correct?
> >
> > static int verbose;
> > G_verbose() {
> >  ..
> >     /* verbose not defined -> get it from env. */
> >     if ( !verbose ) {
> >  ..
> > }
> >
> > so it gets read from GRASS_VERBOSE not only if its unset but also if
> > it happens to be at MINLEVEL?
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev@grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev
> >
>
>
> --
> Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
>


-- 
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *

From tutey at o2.pl  Sun Oct  8 16:27:16 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Sun Oct  8 16:27:20 2006
Subject: [GRASS-dev] Re: [bug #2765] (grass) v.buffer bug??
In-Reply-To: <20061009002149.6e81787a.hamish_nospam@yahoo.com>
References: <20061002012404.885D61005D8@lists.intevation.de>	<452104F6.7070101@o2.pl>
	<20061009002149.6e81787a.hamish_nospam@yahoo.com>
Message-ID: <45290AC4.5010509@o2.pl>

Hamish wrote:
> patch applied to 6.3-cvs and 6.2 branch.
> 
> square_rot_buf30 is fixed.

Confirmed. Great!

> ditch_1188 is fixed.

Confirmed. Yay.

> 1 and 4m buffer around ditches seem to work fine for me, but they did
> before the patch. (?)  (command taken from "v.info -h ditches_buf1")
> 
> 
> I still see the "holes get filled" bug in my own data though,
>  (v.buffer in=roads bufcol="LANE_COUNT")
> 
> so that one's still open.
> 
> I seem to remeber Radim commenting on this a long time ago, here we go,
> complete with screenshots:
>   http://grass.itc.it/pipermail/grass-dev/2005-November/020133.html
>   http://grass.itc.it/pipermail/grass-dev/2005-November/020136.html
>   http://thread.gmane.org/gmane.comp.gis.grass.devel/9506
> 
> 
> This is probably the same bug in v.buffer as you see and nothing to do
> with buffcol= (??).
> 
> Ahh, I've got you now Obi Wan, the interior-fill bug happens when there
> is an interior dangle in my road network ... and I've isolated it to a
> vector made up of 10 polylines.
> 
> can you try buffering your ditches after
>   v.clean tool=rmdangle thresh=[big]

I tried with tresh=1000. Nothing was modified (Removed dangles:     0
removed lines:     0).

> I don't understand why you consistently get the error, and I
> don't, using the same* dataset.  [*] are we really using the same data?
> 
> md5sum vbuffer_bugs.tar.bz2
> d229fb3e5724acb7bf6314d940fc4def  vbuffer_bugs.tar.bz2

Yes, we are using the same:
$ shoofi@sorbus:~/tmp$ md5sum vbuffer_bugs.tar.bz2
d229fb3e5724acb7bf6314d940fc4def  vbuffer_bugs.tar.bz2

Very strange. Maybe it has something to do with the compiler used?

$ gcc -v
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

Or locale? I'm from Poland, where we use "," instead of "." for decimal
point delimiter. But how that would impact v.buffer I don't know - just
trying to think of *something*.

Does v.buffer depend on anything that could differ between your and my
system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is yours?

Maciek

From paul-grass at stjohnspoint.co.uk  Sun Oct  8 17:20:28 2006
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Sun Oct  8 17:20:30 2006
Subject: [GRASS-dev] proj -l
In-Reply-To: <20061008154044.4c9f4a45.hamish_nospam@yahoo.com>
References: <20061008154044.4c9f4a45.hamish_nospam@yahoo.com>
Message-ID: <Pine.LNX.4.62.0610081612530.32166@agrippa.ukshells.co.uk>

Hello Hamish

On Sun, 8 Oct 2006, Hamish wrote:

> Hi,
>
> I just learned of the "proj -l" command from PROJ.4. (post on Proj.4 ml)
>
[...]
>
> Maybe it would be useful in a future auto-gen g.setproj GUI wizard [if
> GRASS moves to "full" use of proj.4].

There was some discussion about this on the PROJ list a while ago when 
someone was trying to tidy up inconsistencies in the proj -lP with a view 
to automatically parsing it for exactly such a purpose: 
http://lists.maptools.org/pipermail/proj/2003-July/000831.html

but it became apparent that the output isn't reliable enough. Gerald 
Evenden's usage paradigm seems to always have been that before formulating 
a set of PROJ parameters the user needs to read the full documentation for 
that particular projection and understand exactly which parameters they 
need. This manifests itself in some interesting ways such as the multiple 
ways to represent an lcc (Lambert Conformal Conic) projection. I'm sure 
there are others but I have to confess I don't really know very much about 
this, apart from the fact that the intention of the -lP output is 
inconsistent with it being automatically parsed. But it may be possible!

As I said before it would be great to make this functionality part of the 
re-worked PROJ.4 library that Frank is proposing to do at some point.

Paul

From landa.martin at gmail.com  Sun Oct  8 17:39:00 2006
From: landa.martin at gmail.com (Martin Landa)
Date: Sun Oct  8 17:39:04 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <4528D657.9080803@o2.pl>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
Message-ID: <f8fe65c40610080839u77d65877xdbb8304cef393ffe@mail.gmail.com>

Hi,

trying to cleanup g.remove module I have prepared the patch. Is it OK
for you? Any comments welcomed...

Best regards, Martin

2006/10/8, Maciej Sieczka <tutey@o2.pl>:
> Glynn Clements wrote:
>
> > Maciej Sieczka wrote:
>
> >> Propably due to the recent work on --v and --q flags (great stuff, many
> >> thanks to the authors!), r.mapcalc doesn't print any progress indicator
> >> anymore.
>
> > AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> > progress indication) you have to enable it.
>
> I didn't realize that quiet mode implies no progress indicator. In that
> case verbose should be the default IMO, because we can't leave users
> without a feedback from the module progress unless they implicitely
> requests that. Am I wrong?
>
> > As r.mapcalc doesn't use G_parser(), --v won't work; you would need to
> > set GRASS_VERBOSE.
> >
> > There probably needs to be a "stub" version of G_parser() which
> > implements the built-in switches (--help, --verbose etc) but doesn't
> > attempt to parse the entire command line.
> >
> > Changing the syntax of r.mapcalc to conform to the normal convention
> > would probably be too radical a change. While we can fix our own
> > scripts, there are likely to be a lot of home-grown scripts which
> > would be broken (not to mention users who are accustomed to using the
> > existing syntax from the command line).
>
> If verbose would be the default that would also fix the problem of
> no-progress in r.mapcalc by default.
>
> >> Also g.remove doesn't return any info if trying to remove a
> >> non-existant map. If used with --v it will print eg.:
> >>
> >> $ g.remove rast=dummy --v
> >> REMOVE [dummy]
> >> raster MISSING
> >> header MISSING
> >> category MISSING
> >> color MISSING
> >> history MISSING
> >> misc MISSING
> >> fcell MISSING
> >> g3dcell MISSING
> >>
> >> as it used before introducing --q and --v. But if --v is not
> >> explicitely set (default), it will remain silent.
> >>
> >> It should print "ERROR: raster map <dummy> not found" instead.
>
> > Specifying a map which doesn't exist (one with no elements) has never
> > been an error.
>
> Not really, it is an error in case of vectors already. Try this:
>
> $ g.remove vect=dummy
>
> you'll get:
>
> ERROR: Vector map <dummy> not found
>
> $ echo $?
> 1
>
> > At most, it should generate a warning if no elements
> > are found.
>
> Why shouldn't it generate an error? The user is trying to use a
> non-existant map for the g.remove input. Other modules return an error
> in such case. g.remove vect does the same. But g.remove
> rast/rast3d/region/group doesn't. Shouldn't they conform?
>
> Also, in the verbose mode, only a single-line information like "Raster
> map <dummy> removed" should be printed insated of the current 9 lines:
>
> $ g.remove rast=dummy --v
> REMOVE [dummy]
> raster
> header
> category
> color MISSING
> history
> misc
> fcell MISSING
> g3dcell MISSING
>
> BTW, I'd like to ask again what is the g3dcell?
>
>
>
>
>
> Talking of g.remove - could the following types should be disposed in
> GRASS 7?:
>
> 1. sites - there is no sites functionality in Grass>=5.7
> 2. region3d - 3D region settings have been merged into region
> 3. 3dview - remainment of Grass <5.7 3d.view command
> 4? icon - I don't know, propably too? what is it?
> 5. oldvect
> 6. asciivect
>
> Same applies to g.copy/rename/list
>
> ?
>
> Maciek
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
Martin Landa <landa.martin@gmail.com> * http://gama.fsv.cvut.cz/~landa *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g_remove.diff.gz
Type: application/x-gzip
Size: 2141 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061008/936b925a/g_remove.diff.gz
From paul-grass at stjohnspoint.co.uk  Sun Oct  8 17:45:27 2006
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Sun Oct  8 17:45:30 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <20061009010414.26e05b9a.hamish_nospam@yahoo.com>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
	<20061009010414.26e05b9a.hamish_nospam@yahoo.com>
Message-ID: <Pine.LNX.4.62.0610081641060.32166@agrippa.ukshells.co.uk>

On Mon, 9 Oct 2006, Hamish wrote:

> I think it is wrong to make all modules --quiet be default. Many years
> of tuning have gone into the current message level, we just throw that
> out? Sure some modules are very noisy and that should be dealt with
> (remove useless noise and move debug info to G_debug()).
>
> IMO the "only create output if something interesting happens"
> guideline should only apply to UNIX-like small "do one thing well"
> modules. Quick little modules used in a script (ie in a loop) can be
> made a bit quieter, sure.
>
> But for long running modules like v.surf.rst and r.sun, we should
> definitely let the user know what's going on, what mode the module is
> running in, how many points used for processing, etc. Anything which is
> expected to take longer than about 10 seconds under normal conditions
> should at least give G_percent() output IMO.
>
> This is especially important for new users who are not confident or
> knowledgeable about what is going on or how long it will take.
>
> Hiding all G_message() and G_percent() output *by default* is totally
> nuts. Adding --quiet or GRASS_VERBOSE=0 isn't hard if you are writing a
> script or GUI frontend.

I agree with all this - it's what I was trying to say when Jachym first 
proposed this and I suggested a --quiet flag would be better to have than 
--verbose (i.e. keep the current output as default but allow frontends 
that need to run modules in quiet to achieve that), but I couldn't find 
the words to express myself very well and so gave up replying to the 
thread :/ I'm surprised more people didn't object at the time; FWIW it's 
worth I just have trouble with the idea of treating GRASS modules as 
normal Unix programs that only emit output when there's an error.

Paul

From dca.gis at gmail.com  Sun Oct  8 19:13:46 2006
From: dca.gis at gmail.com (Daniel Calvelo)
Date: Sun Oct  8 19:13:49 2006
Subject: [GRASS-dev] adding 'desc' to dbf sql driver
In-Reply-To: <48506.85.10.69.159.1160229752.squirrel@geog-pc40.ulb.ac.be>
References: <4513A84E.8090807@club.worldonline.be>
	<1a486f560609271831m747f3495sa6d8495273c107d4@mail.gmail.com>
	<48506.85.10.69.159.1160229752.squirrel@geog-pc40.ulb.ac.be>
Message-ID: <1a486f560610081013j3ce2197fgaf7ded786e4f5d76@mail.gmail.com>

Hi Moritz,

Looks good to me. In the yac.y patch, you don't need to duplicate the
code for ORDER BY NAME and ORDER BY NAME ASC. For cmp_row_desc, you
could just return( - cmp_row_asc) with the same arguments. Glynn, a
cursory look?

FYI, the text file in lib/db/sqlp/test/test allows for some testing of
the parser. That may help you find any hidden bugs in the sqlp part of
your patch. You might also wish to update print.c to accomodate for
asc/desc (it's a one-line change near the end).

And of course, after testing, this has to be documented :)

Daniel.

On 10/7/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:
> Hi Daniel,
>
> On Thu, September 28, 2006 03:31, Daniel Calvelo wrote:
> > Hi Moritz. See below
> >
> > On 9/22/06, Moritz Lennert <mlennert@club.worldonline.be> wrote:
> >> Hi,
> >>
> >> Reworking on d.vect.chart I need to be able to sort the reults of a
> >> select in descending order. As the dbf driver doesn't allow this, I have
> >> been trying to see how to extend the driver.
> >>
> >> IIUC, it's "just" a question of conditionalising the qsort call on line
> >> 566 of db/drivers/dbf/dbfexe.c, and (would this be enough ?) use
> >>
> >> qsort(set, nset, sizeof(int), -cmp_row);
> >
> > That might work. Although it would be much nicer to use an expression
> > as sorting order.
> >
> >> if the desc keyword is present.
> >>
> >> However, I have some trouble understanding the parsing of the sql
> >> statement.
> >>
> >> If I understand correctly, we would need to extent the SQLPSTMT
> >> structure in include/sqlp.h to include a flag for 'desc' (and possible
> >> 'asc') and the parser to identify and set that flag.
> >>
> >> But this is as far as I get. Could someone help me with this ?
> >
> > Quick shot: you need to
> >
> > - change SQLPSTMT to have an "order"/"direction"/"sort_order"  element
> >
> > - add ASC and DESC in lex.l as tokens
> >
> > - change yac.y to stg like:
> >
> > y_order: y_order_asc | y_order_desc ;
> > y_order_asc:
> >        NAME ASC { sqpOrderColumn( $1 ); sqpOrderDirection( 1 ); }
> > ;
> > y_order_desc:
> >       NAME DESC { sqpOrderColumn( $1 );sqpOrderDirection( 2 );}
> > ;
> >
> > - add in sql.c a sqpOrderDirection() function that sets the element
> > you added to SQLPSTMT
> >
> > (Alternatively, you can change sqpOrderColumn() to receive two
> > arguments, one being the sorting direction. I'd also rather #define
> > SORT_ASC and SORT_DESC instead of using magic numbers as above.)
> >
> > - use that value in dbfexe.c to test the sorting direction.
>
> Here's an attempt at translating your very clear instructions. Could you
> or someone else just have a quick look to see if I didn't do anything bad.
> One question for me was how to handle the different comparison functions
> for ASC and DESC. At this stage I just duplicated the function
> (cmp_row_asc and cpm_row_desc) and inverted the signs. Maybe there is a
> more elegant way ?
>
> Thanks !
>
> Moritz
>
>


-- 
-- Daniel Calvelo Aros

From michael.barton at asu.edu  Sun Oct  8 20:25:20 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  8 20:25:23 2006
Subject: [GRASS-dev] [bug #5192] (grass) tclsh error in
	/grass-6.2.0RC2/etc/gm/gm.tcl
In-Reply-To: <20061007151936.EC3A810015B@lists.intevation.de>
Message-ID: <C14E90A0.F804%michael.barton@asu.edu>

We use TclTk 8.4.x. You are using 8.5 alpha.

I don't know if this is indeed the problem, but it is the first place I'd
start checking given the error you have.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Request Tracker <grass-bugs@intevation.de>
> Reply-To: Request Tracker <grass-bugs@intevation.de>
> Date: Sat,  7 Oct 2006 17:19:36 +0200 (CEST)
> To: <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] [bug #5192] (grass) tclsh error in
> /grass-6.2.0RC2/etc/gm/gm.tcl
> 
> this bug's URL: http://intevation.de/rt/webrt?serial_num=5192
> -------------------------------------------------------------------------
> 
> Subject: tclsh error in /grass-6.2.0RC2/etc/gm/gm.tcl
> 
> Platform: GNU/Linux/x86
> grass obtained from: Trento Italy site
> grass binary for platform: Compiled from Sources
> 
> Hello,
> 
> I packaged GRASS 6.2.0RC2 for Pardus -Linux. When I start GRASS, I get this
> error below.
> 
> And tcl version is 8.5_alpha3...
> 
> murat@pardus grass $ grass
> Cleaning up temporary files.....
> Starting GRASS ...
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Welcome to GRASS 6.2.0RC2 (2006)
> GRASS homepage:                          http://grass.itc.it/
> This version running thru:               Bash Shell (/bin/bash)
> Help is available with the command:      g.manual -i
> See the licence terms with:              g.version -c
> If required, restart the graphical user interface with: gis.m &
> When ready to quit enter:                exit
> GRASS 6.2.0RC2 (samples):~/Desktop/grass > Error in startup script: bad
> variable name "coords(1)": upvar won't create a scalar variable that looks
> like an array element
>     while executing
> "global coords($mon)"
>     (procedure "MapCanvas::pointer" line 5)
>     invoked from within
> "MapCanvas::pointer $mon"
>     (procedure "MapCanvas::create" line 226)
>     invoked from within
> "MapCanvas::create"
>     (procedure "Gm::startmon" line 11)
>     invoked from within
> "Gm::startmon"
>     (procedure "Gm::create" line 69)
>     invoked from within
> "Gm::create"
>     (procedure "main" line 30)
>     invoked from within
> "main $argc $argv"
>     (file 
> "/var/tmp/pisi/grass-6.2.0_rc2-3/install/opt/grass-6.2.0RC2/etc/gm/gm.tcl"
> line 521)
> 
> -------------------------------------------- Managed by Request Tracker
> 
> 

From michael.barton at asu.edu  Sun Oct  8 20:27:29 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  8 20:27:29 2006
Subject: [GRASS-dev] proj -l
In-Reply-To: <20061008154044.4c9f4a45.hamish_nospam@yahoo.com>
Message-ID: <C14E9121.F806%michael.barton@asu.edu>

I agree. This has useful potential. Thanks for uncovering it.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam@yahoo.com>
> Date: Sun, 8 Oct 2006 15:40:44 +1300
> To: grass5 <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] proj -l
> 
> Hi,
> 
> I just learned of the "proj -l" command from PROJ.4. (post on Proj.4 ml)
> 
>        -l[p|P|=|e|u|d]id
>               List projection identifiers with -l,  -lp
>               or  -lP  (expanded)  that can be selected
>               with   +proj.    -l=id   gives   expanded
>               description   of   projection  id.   List
>               ellipsoid identifiers with -le, that  can
>               be  selected  with  +ellps,  -lu  list of
>               cartesian  to  meter  conversion  factors
>               that  can  be selected with +units or -ld
>               list of datums that can be selected  with
>               +datum.
> 
> 
> Maybe it would be useful in a future auto-gen g.setproj GUI wizard [if
> GRASS moves to "full" use of proj.4].
> 
> 
> Hamish
> 
> 

From michael.barton at asu.edu  Sun Oct  8 20:35:57 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  8 20:35:57 2006
Subject: [GRASS-dev] extraneous files in grass-6.2.0RC2.tar.gz & 6.2.0
	release plans
In-Reply-To: <20061008174646.6a7d04b2.hamish_nospam@yahoo.com>
Message-ID: <C14E931D.F809%michael.barton@asu.edu>

Hi Hamish.

I looked at substituting bwidgets LabelFrame for the tk 8.4 labelframe. It
is not a drop in and has a bug in that it won't display the border. But it
will display the text.

I sent this to Markus (and thought I copied you, but maybe just imagined
that) on Thursday or Friday to see if it made any difference. I can't tell
because I don't have TclTk 8.3.

I'll send it here again. It goes ca. line 223 to replace labelframe...

LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
    -text [G_msg "mouse button actions (left, right, center)"]

Except for not drawing the border, it is otherwise harmless on my Mac with
x11. I don't know what it does for Mac Aqua or Windows.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam@yahoo.com>
> Date: Sun, 8 Oct 2006 17:46:46 +1300
> To: grass5 <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] extraneous files in grass-6.2.0RC2.tar.gz & 6.2.0 release
> plans
> 
> 
> known release to-dos:
>  [high priority]
>  - refine the press release
>  - make v.digit 8.3 compatible, note "gis.m may need 8.4" in REQUIREMENTS.html
> 
>  [minor]
>  - r.le.* G_calloc() before G_gisinit()
> 
>  [optional]
>  - apply v.buffer patch? (trade bad known bug for lightly tested band-aid)
>  - remove TclTk web browser from NVIZ & lin/init/ (merge from HEAD)
> 
>  [??]
>  - anything else?
> 

From michael.barton at asu.edu  Sun Oct  8 20:38:33 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  8 20:38:35 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect 
	causes error :can't read "_data(.gronsole.gronsole, 9,
	donecmd)": no such element in array
In-Reply-To: <42215.85.10.65.158.1160296222.squirrel@geog-pc40.ulb.ac.be>
Message-ID: <C14E93B9.F80A%michael.barton@asu.edu>

Something along this line popped up in a Mac installation. I think it was a
colleague of William Kyngesburye, so I'm copying him here. In that case
there was something missing in the installation that finally turned out to
be the problem.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Moritz Lennert <mlennert@club.worldonline.be>
> Date: Sun, 8 Oct 2006 10:30:22 +0200 (CEST)
> To: Hamish <hamish_nospam@yahoo.com>, <michael.barton@asu.edu>
> Cc: <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] gis.m in wingrass: using where clause in d.vect
> causes error :can't read "_data(.gronsole.gronsole,9, donecmd)": no such
> element in array
> 
> On Sun, October 8, 2006 04:59, Hamish wrote:
>> Moritz Lennert wrote:
>>> Using a where clause in vector display in gis.m causes the following
>>> error under WinGRASS. Any suggestions ?
>>> (WinGRASS version 2006-09-17)
>>> 
>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>>> element in array
>>>      while executing
>>> "set donecmd $_data($path,$ci,donecmd)"
>> 
>> 
>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
>> query in the "query cat values" box by mistake.
> 
> I am not near a windows box right now, but I am quite positive that this
> is not the problem here. I entered the query in the where box, not the cat
> box.
> 
> But I'll make sure tomorrow.
> 
> Moritz
> 
> 

From michael.barton at asu.edu  Sun Oct  8 20:41:20 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  8 20:41:21 2006
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
In-Reply-To: <20061008220334.26ae410f.hamish_nospam@yahoo.com>
Message-ID: <C14E9460.F80B%michael.barton@asu.edu>

Working my way up through digest email. Is the demo that has a border using
the same (old) version of bwidgets that we do? If so, I'll try to look at
the code and see what it's doing that I didn't see.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam@yahoo.com>
> Date: Sun, 8 Oct 2006 22:03:34 +1300
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-dev@grass.itc.it>
> Subject: Re: tcltk 8.3 and v.digit toolbox
> 
> Michael Barton wrote:
>> It turns out that bwidget LabelFrame is not just a drop in replacement
>> for the tk 8.4 labelframe. For one thing, LabelFrame seems buggy in
>> the version of bwidgets that GRASS uses and the frame border will not
>> draw with a label there. Second the options are slightly different.
> 
> Yes, I can't get a frame border either. Thanks for translating the options.
> 
> There are (Very Good) bwidget instructions and demo.tcl in the GRASS 5
> source code. (hopefully you found them?)
> 
> [should we copy into GRASS 6 lib/external/bwidget?
>  252K    demo/
>  368K    BWman/
> ]
> 
> cd grass-5.4.0/src/libes/bwidget/demo/
> wish demo.tcl
> 
> in the demo the LabelFrames borders work correctly, so I think it is
> something we are overlooking (???).
> 
> 
>> If you want to replace the labelframe statement in toolbox.tcl (ca.
>> Line 223) with the following and see what happens,
> 
> I do want to replace it for 6.2,
> 
>> On my Mac, running x11, it creates the label but does not draw the
>> box, no matter what I do. This is problematic, but maybe it at least
>> runs on 8.3.
> 
> As it works in demo/demo.tcl, I think it's a fixable bug on our behalf.
> ( somewhere :-/  window parent/child relationship? lack of content?)
> 
>> Again, I can't say if there are any other 8.4 features that won't run
>> on 8.3, so I'm not sure it's worth it anyway.
> 
> .. but but but .. are there bwidget replacements for those we can use?
> 
> === (lib/external/bwidget/README.grass) ========
> only requires 2 lines of code in your Tcl/Tk script to use the new widgets.
> Some of the new widgets include
> 
>     On mouse over help balloons
>     Tabbed notebook panes - like worksheets in Excel
>     Directory tree listing
>     Combination box or drop down option list
>     Progress bar
>     Many others
> ================================================
> 
> seems to me that there should be replacements, and we don't (really)
> have to worry about finding any we don't know about until we get an
> error report. And then it's a (hopefully) quick fix. We are pretty
> sure this is the only v.digit problem, and pretty sure that d.m is ok
> (so I'm not as worried about gis.m).
> 
> 
>> LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
>>     -text [G_msg "mouse button actions (left, right, center)"]
> 
> works for me (besides missing border). I expect it will work on all
> platforms (I can't see why it wouldn't).
> 
> An immediate solution: adding "-background HoneyDew" makes the
> "-relief groove -borderwidth 1" failure less important.
> 
> 
> thanks,
> Hamish

From michael.barton at asu.edu  Sun Oct  8 21:16:43 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  8 21:16:44 2006
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
In-Reply-To: <20061008220334.26ae410f.hamish_nospam@yahoo.com>
Message-ID: <C14E9CAB.F810%michael.barton@asu.edu>

Still catching up with a lot of traffic over past 24 hours.

I'll look at the demo file, but giving the frame a honeydew background is a
good substitute if that fails.

We already use bwidgets for most of the widgets listed below. Only in a few
cases (generally noted in the bwidgets docs) have there been new tk widgets
that supercede these. The more complicated issue is changes to existing
TclTk widgets and other syntax. This is only a gism issue as you point out.
It's not that substitutes can't be found or worked out, it's just that I
don't have much in the way of time to do it, and it's additionally difficult
since I'm running 8.4--as are most people who can test. I've already had to
put wxGRASS aside for a month (and am already forgetting what I learned this
past summer) while doing necessary bug fixes on TclTk 8.4 code for 6.2 and
6.3. So I'm not against it as long as it doesn't degrade the UI, I just
don't want to be the person who has to make gism work with 8.3.

On the other hand, as you note, v.digit needs to work with both old and new
GUI. So as long as we maintain d.m, I agree that v.digit should be backward
compatible. So let's get this one set and see what happens next.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Hamish <hamish_nospam@yahoo.com>
> Date: Sun, 8 Oct 2006 22:03:34 +1300
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-dev@grass.itc.it>
> Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
> 
> Michael Barton wrote:
>> It turns out that bwidget LabelFrame is not just a drop in replacement
>> for the tk 8.4 labelframe. For one thing, LabelFrame seems buggy in
>> the version of bwidgets that GRASS uses and the frame border will not
>> draw with a label there. Second the options are slightly different.
> 
> Yes, I can't get a frame border either. Thanks for translating the options.
> 
> There are (Very Good) bwidget instructions and demo.tcl in the GRASS 5
> source code. (hopefully you found them?)
> 
> [should we copy into GRASS 6 lib/external/bwidget?
>  252K    demo/
>  368K    BWman/
> ]
> 
> cd grass-5.4.0/src/libes/bwidget/demo/
> wish demo.tcl
> 
> in the demo the LabelFrames borders work correctly, so I think it is
> something we are overlooking (???).
> 
> 
>> If you want to replace the labelframe statement in toolbox.tcl (ca.
>> Line 223) with the following and see what happens,
> 
> I do want to replace it for 6.2,
> 
>> On my Mac, running x11, it creates the label but does not draw the
>> box, no matter what I do. This is problematic, but maybe it at least
>> runs on 8.3.
> 
> As it works in demo/demo.tcl, I think it's a fixable bug on our behalf.
> ( somewhere :-/  window parent/child relationship? lack of content?)
> 
>> Again, I can't say if there are any other 8.4 features that won't run
>> on 8.3, so I'm not sure it's worth it anyway.
> 
> .. but but but .. are there bwidget replacements for those we can use?
> 
> === (lib/external/bwidget/README.grass) ========
> only requires 2 lines of code in your Tcl/Tk script to use the new widgets.
> Some of the new widgets include
> 
>     On mouse over help balloons
>     Tabbed notebook panes - like worksheets in Excel
>     Directory tree listing
>     Combination box or drop down option list
>     Progress bar
>     Many others
> ================================================
> 
> seems to me that there should be replacements, and we don't (really)
> have to worry about finding any we don't know about until we get an
> error report. And then it's a (hopefully) quick fix. We are pretty
> sure this is the only v.digit problem, and pretty sure that d.m is ok
> (so I'm not as worried about gis.m).
> 
> 
>> LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
>>     -text [G_msg "mouse button actions (left, right, center)"]
> 
> works for me (besides missing border). I expect it will work on all
> platforms (I can't see why it wouldn't).
> 
> An immediate solution: adding "-background HoneyDew" makes the
> "-relief groove -borderwidth 1" failure less important.
> 
> 
> thanks,
> Hamish
> 
> 

From jan-oliver.wagner at intevation.de  Sun Oct  8 21:49:13 2006
From: jan-oliver.wagner at intevation.de (Jan-Oliver Wagner)
Date: Sun Oct  8 21:49:47 2006
Subject: [GRASS-dev] First steps to switch the bug tracker
In-Reply-To: <452915CA.2090204@o2.pl>
References: <200610052333.01123.jan-oliver.wagner@intevation.de>
	<452915CA.2090204@o2.pl>
Message-ID: <200610082149.14877.jan-oliver.wagner@intevation.de>

On Sunday 08 October 2006 17:14, Maciej Sieczka wrote:
> Jan-Oliver Wagner wrote:
> > The managers and anyone submitting or working on
> > bug entries should create a user account.
>
> Done. Sent you a request to add me to GRASS project.

You are added.

> > Also, you will currently see quite a number of tabs for
> > the project (forums, mailing lists, tasks, etc).
> > Actually, we only need the bug tracker (so far).
> > All others can be switched off. I will do so unless
> > you want a specific feature to remain.
> >
> > Next, there are curently some default trackers configured.
> > These could be deleted, or additionally be created and of course
> > configured to some extend.
>
> You mean Bugs, Support, Patches, Feature Request? I think we could drop
> Support. It will be better to keep all tech-support traffic on
> the lists as we used to, so more people would participate in discussion
> and more could benefit of it.

sounds reasonable.

> I also would prefer to close the Forums and Lists - for the same
> reason. We have too little recources to take care of all the eventuall
> discussions spreaded here and there.
>
> Regarding Tasks, Docs, Surveys, News and Files there are dedicated
> facilities on grass.itc.it and on GRASS WIKI. So I would prefer to
> remove them too.

make sense.

> What about the SCM? Is moving to SVN planned? If not, could we close
> that as well?

well, it is on the roadmap to move on to a better SCM. Whether it should
be SVN or even something more advanced like Mercurial is still to be 
discussed.
 
> Regarding the trackers:
>
> @ Oliver:
>
> 1. Can I use more than 1 email for "Send email on new submission to
> address:"?

don't know. Should be tested.

> 2. Is it posible to customize what columns will be displayed in
> http://wald.intevation.org/tracker/?atid=167&group_id=21&func=browse
> ? I'd like to add Version there.

not in the admin interface. But maybe at some deeper point. 

Best

	Jan
-- 
Jan-Oliver Wagner: www.intevation.de/~jan  | GISpatcher: www.gispatcher.de
Kolab Konsortium : www.kolab-konsortium.de | Thuban    : thuban.intevation.org
Intevation GmbH  : www.intevation.de       | Kolab     : www.kolab.org
FreeGIS          : www.freegis.org         | GAV       : www.grass-verein.de

From michael.barton at asu.edu  Sun Oct  8 23:39:11 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Sun Oct  8 23:39:12 2006
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
In-Reply-To: <C14E9CAB.F810%michael.barton@asu.edu>
Message-ID: <C14EBE0F.F817%michael.barton@asu.edu>

I went through the GRASS 5.4 source code and looked at all the bwidget demo
files and tried all permutations of LabelFrame from there. It all comes out
the same on my Mac with x11. I don't know what is up, but I can't get a
border to show up no matter what I do. Maybe it does in 8.3 but not in 8.4.
Maybe it's something else in the v.digit code.

I guess just add -bg honeydew2 to the options and call it good. This looks
nice and gives the same delineation of the mouse buttons as the labelframe
border.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Michael Barton <michael.barton@asu.edu>
> Date: Sun, 08 Oct 2006 12:16:43 -0700
> To: Hamish <hamish_nospam@yahoo.com>
> Cc: <grass-dev@grass.itc.it>
> Conversation: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
> Subject: Re: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
> 
> Still catching up with a lot of traffic over past 24 hours.
> 
> I'll look at the demo file, but giving the frame a honeydew background is a
> good substitute if that fails.
> 
> We already use bwidgets for most of the widgets listed below. Only in a few
> cases (generally noted in the bwidgets docs) have there been new tk widgets
> that supercede these. The more complicated issue is changes to existing TclTk
> widgets and other syntax. This is only a gism issue as you point out. It's not
> that substitutes can't be found or worked out, it's just that I don't have
> much in the way of time to do it, and it's additionally difficult since I'm
> running 8.4--as are most people who can test. I've already had to put wxGRASS
> aside for a month (and am already forgetting what I learned this past summer)
> while doing necessary bug fixes on TclTk 8.4 code for 6.2 and 6.3. So I'm not
> against it as long as it doesn't degrade the UI, I just don't want to be the
> person who has to make gism work with 8.3.
> 
> On the other hand, as you note, v.digit needs to work with both old and new
> GUI. So as long as we maintain d.m, I agree that v.digit should be backward
> compatible. So let's get this one set and see what happens next.
> 
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
> 
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
> 
> 
> 
>> From: Hamish <hamish_nospam@yahoo.com>
>> Date: Sun, 8 Oct 2006 22:03:34 +1300
>> To: Michael Barton <michael.barton@asu.edu>
>> Cc: <grass-dev@grass.itc.it>
>> Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
>> 
>> Michael Barton wrote:
>>> It turns out that bwidget LabelFrame is not just a drop in replacement
>>> for the tk 8.4 labelframe. For one thing, LabelFrame seems buggy in
>>> the version of bwidgets that GRASS uses and the frame border will not
>>> draw with a label there. Second the options are slightly different.
>> 
>> Yes, I can't get a frame border either. Thanks for translating the options.
>> 
>> There are (Very Good) bwidget instructions and demo.tcl in the GRASS 5
>> source code. (hopefully you found them?)
>> 
>> [should we copy into GRASS 6 lib/external/bwidget?
>>  252K    demo/
>>  368K    BWman/
>> ]
>> 
>> cd grass-5.4.0/src/libes/bwidget/demo/
>> wish demo.tcl
>> 
>> in the demo the LabelFrames borders work correctly, so I think it is
>> something we are overlooking (???).
>> 
>> 
>>> If you want to replace the labelframe statement in toolbox.tcl (ca.
>>> Line 223) with the following and see what happens,
>> 
>> I do want to replace it for 6.2,
>> 
>>> On my Mac, running x11, it creates the label but does not draw the
>>> box, no matter what I do. This is problematic, but maybe it at least
>>> runs on 8.3.
>> 
>> As it works in demo/demo.tcl, I think it's a fixable bug on our behalf.
>> ( somewhere :-/  window parent/child relationship? lack of content?)
>> 
>>> Again, I can't say if there are any other 8.4 features that won't run
>>> on 8.3, so I'm not sure it's worth it anyway.
>> 
>> .. but but but .. are there bwidget replacements for those we can use?
>> 
>> === (lib/external/bwidget/README.grass) ========
>> only requires 2 lines of code in your Tcl/Tk script to use the new widgets.
>> Some of the new widgets include
>> 
>>     On mouse over help balloons
>>     Tabbed notebook panes - like worksheets in Excel
>>     Directory tree listing
>>     Combination box or drop down option list
>>     Progress bar
>>     Many others
>> ================================================
>> 
>> seems to me that there should be replacements, and we don't (really)
>> have to worry about finding any we don't know about until we get an
>> error report. And then it's a (hopefully) quick fix. We are pretty
>> sure this is the only v.digit problem, and pretty sure that d.m is ok
>> (so I'm not as worried about gis.m).
>> 
>> 
>>> LabelFrame .bpf -bd 1 -relief groove -side top -anchor n \
>>>     -text [G_msg "mouse button actions (left, right, center)"]
>> 
>> works for me (besides missing border). I expect it will work on all
>> platforms (I can't see why it wouldn't).
>> 
>> An immediate solution: adding "-background HoneyDew" makes the
>> "-relief groove -borderwidth 1" failure less important.
>> 
>> 
>> thanks,
>> Hamish
>> 
>> 

From woklist at kyngchaos.com  Mon Oct  9 00:56:22 2006
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Mon Oct  9 01:00:24 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect
	causes error :can't read "_data(.gronsole.gronsole, 9,
	donecmd)": no such element in array
In-Reply-To: <C14E93B9.F80A%michael.barton@asu.edu>
References: <C14E93B9.F80A%michael.barton@asu.edu>
Message-ID: <FE35B477-CCED-49E9-BF0C-C6A169FF810F@kyngchaos.com>

I was holding off on replying to this, waiting for a windows reply.   
And, this issue was brought up mid-Sept also, I guess a solution  
wasn't found then.

The Mac problem had to do with using TclTk Aqua vs. X11.  For Aqua  
the osxaqua=1 env must be set, or you get this error.  Maybe if you  
look at what setting osxaqua makes GRASS do differently with the  
GUI?  There are a couple settings in init.sh dependent on osxaqua, I  
never looked to see if it's used elsewhere.

This is the Mac bug:

http://intevation.de/rt/webrt?serial_num=5096&display=History

On Oct 9, 2006, at 3:38 AM, Michael Barton wrote:

> Something along this line popped up in a Mac installation. I think  
> it was a
> colleague of William Kyngesburye, so I'm copying him here. In that  
> case
> there was something missing in the installation that finally turned  
> out to
> be the problem.
>
> Michael
> __________________________________________
> Michael Barton, Professor of Anthropology
> School of Human Evolution & Social Change
> Center for Social Dynamics & Complexity
> Arizona State University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>
>
>
>> From: Moritz Lennert <mlennert@club.worldonline.be>
>> Date: Sun, 8 Oct 2006 10:30:22 +0200 (CEST)
>> To: Hamish <hamish_nospam@yahoo.com>, <michael.barton@asu.edu>
>> Cc: <grass-dev@grass.itc.it>
>> Subject: Re: [GRASS-dev] gis.m in wingrass: using where clause in  
>> d.vect
>> causes error :can't read "_data(.gronsole.gronsole,9, donecmd)":  
>> no such
>> element in array
>>
>> On Sun, October 8, 2006 04:59, Hamish wrote:
>>> Moritz Lennert wrote:
>>>> Using a where clause in vector display in gis.m causes the  
>>>> following
>>>> error under WinGRASS. Any suggestions ?
>>>> (WinGRASS version 2006-09-17)
>>>>
>>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such  
>>>> element in
>>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>>>> element in array
>>>>      while executing
>>>> "set donecmd $_data($path,$ci,donecmd)"
>>>
>>>
>>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
>>> query in the "query cat values" box by mistake.
>>
>> I am not near a windows box right now, but I am quite positive  
>> that this
>> is not the problem here. I entered the query in the where box, not  
>> the cat
>> box.
>>
>> But I'll make sure tomorrow.
>>
>> Moritz
>>
>>
>

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that  
the past isn't a fiction designed to account for the discrepancy  
between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe


From grass-bugs at intevation.de  Mon Oct  9 01:10:37 2006
From: grass-bugs at intevation.de (Maciek Sieczka via RT)
Date: Mon Oct  9 01:10:40 2006
Subject: [GRASS-dev] [bug #2793] (grass) where v.segment creates the points
Message-ID: <20061008231037.7A9191005A8@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=2793

Request number 2793 was commented on by 'msieczka' (Maciek Sieczka). 
Responding to this message will send mail to the requestor.
			
			Request Tracker
			rt@intevation.de

--------------------------------------------------------------
Cc: grass-dev@grass.itc.it

I have used v.segment in the last days and I'm sure there is a bug in the side
offset, at least for point mode. The bug is that the offset doesn't work, it
is always 0.

Folks have been reporting this:

http://grass.itc.it/pipermail/grassuser/2005-December/031522.html
http://www.nabble.com/-GRASS-user--HEC-RAS-tf2066275.html#a5691777
http://www.nabble.com/-GRASS-user--v.segment---how-to-use-orthogonal-offset--tf2065644.html#a5691131

Maciek



-------------------------------------------- Managed by Request Tracker

From michael.barton at asu.edu  Mon Oct  9 01:54:59 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Oct  9 01:55:07 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect 
	causes error :can't read "_data(.gronsole.gronsole, 9,
	donecmd)": no such element in array
In-Reply-To: <FE35B477-CCED-49E9-BF0C-C6A169FF810F@kyngchaos.com>
Message-ID: <C14EDDE3.F821%michael.barton@asu.edu>

Here is what happens for setting the osx aqua variable.

Mac Aqua version of TclTk is used instead of x11 version

The GUI startup script, gis.m is launched with...

    "$GISBASE/scripts/gis.m" | sh &
    
Instead of with...

    "$GISBASE/scripts/gis.m" &


The variable execom is set to "spawn"; otherwise it is "execute"

I think this was used for awhile in the menu system, but can't find any use
for this now. If true, it needs to be deleted.

I'm adding Lorenzo to the CC list. He developed the aqua variable and has
worked the most with this version of TclTk.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: William Kyngesburye <woklist@kyngchaos.com>
> Reply-To: William Kyngesburye <kyngchaos@kyngchaos.com>
> Date: Mon, 9 Oct 2006 07:56:22 +0900
> To: Michael Barton <michael.barton@asu.edu>
> Cc: Moritz Lennert <mlennert@club.worldonline.be>, Hamish
> <hamish_nospam@yahoo.com>, <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] gis.m in wingrass: using where clause in d.vect
> causes error :can't read "_data(.gronsole.gronsole,9, donecmd)": no such
> element in array
> 
> I was holding off on replying to this, waiting for a windows reply.
> And, this issue was brought up mid-Sept also, I guess a solution
> wasn't found then.
> 
> The Mac problem had to do with using TclTk Aqua vs. X11.  For Aqua
> the osxaqua=1 env must be set, or you get this error.  Maybe if you
> look at what setting osxaqua makes GRASS do differently with the
> GUI?  There are a couple settings in init.sh dependent on osxaqua, I
> never looked to see if it's used elsewhere.
> 
> This is the Mac bug:
> 
> http://intevation.de/rt/webrt?serial_num=5096&display=History
> 
> On Oct 9, 2006, at 3:38 AM, Michael Barton wrote:
> 
>> Something along this line popped up in a Mac installation. I think
>> it was a
>> colleague of William Kyngesburye, so I'm copying him here. In that
>> case
>> there was something missing in the installation that finally turned
>> out to
>> be the problem.
>> 
>> Michael
>> __________________________________________
>> Michael Barton, Professor of Anthropology
>> School of Human Evolution & Social Change
>> Center for Social Dynamics & Complexity
>> Arizona State University
>> 
>> phone: 480-965-6213
>> fax: 480-965-7671
>> www: http://www.public.asu.edu/~cmbarton
>> 
>> 
>> 
>>> From: Moritz Lennert <mlennert@club.worldonline.be>
>>> Date: Sun, 8 Oct 2006 10:30:22 +0200 (CEST)
>>> To: Hamish <hamish_nospam@yahoo.com>, <michael.barton@asu.edu>
>>> Cc: <grass-dev@grass.itc.it>
>>> Subject: Re: [GRASS-dev] gis.m in wingrass: using where clause in
>>> d.vect
>>> causes error :can't read "_data(.gronsole.gronsole,9, donecmd)":
>>> no such
>>> element in array
>>> 
>>> On Sun, October 8, 2006 04:59, Hamish wrote:
>>>> Moritz Lennert wrote:
>>>>> Using a where clause in vector display in gis.m causes the
>>>>> following
>>>>> error under WinGRASS. Any suggestions ?
>>>>> (WinGRASS version 2006-09-17)
>>>>> 
>>>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>>>>> element in
>>>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>>>>> element in array
>>>>>      while executing
>>>>> "set donecmd $_data($path,$ci,donecmd)"
>>>> 
>>>> 
>>>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
>>>> query in the "query cat values" box by mistake.
>>> 
>>> I am not near a windows box right now, but I am quite positive
>>> that this
>>> is not the problem here. I entered the query in the where box, not
>>> the cat
>>> box.
>>> 
>>> But I'll make sure tomorrow.
>>> 
>>> Moritz
>>> 
>>> 
>> 
> 
> -----
> William Kyngesburye <kyngchaos@kyngchaos.com>
> http://www.kyngchaos.com/
> 
> "This is a question about the past, is it? ... How can I tell that
> the past isn't a fiction designed to account for the discrepancy
> between my immediate physical sensations and my state of mind?"
> 
> - The Ruler of the Universe
> 
> 

From hamish_nospam at yahoo.com  Mon Oct  9 02:01:12 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  9 02:01:23 2006
Subject: [GRASS-dev] Re: [GRASS-user] Large vector files
In-Reply-To: <1160333153.2382.103.camel@devel>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BC7@s5-dar-r1.nrn.nrcan.gc.ca>
	<20061008185113.5ebd15af.hamish_nospam@yahoo.com>
	<17704.61035.48627.525465@cerise.gclements.plus.com>
	<1160333153.2382.103.camel@devel>
Message-ID: <20061009130112.31fab641.hamish_nospam@yahoo.com>

[moved to the devel list]
 
HB:
> > > I am always looking for feedback on how r.in.xyz goes with massive
> > > input data. (>2gb? >4gb?)
GC:
> > r.in.xyz doesn't use LFS, so it will be limited to 2Gb on 32-bit
> > systems (any system where "long" is 32 bits). As it uses ANSI stdio
> > functions (including ftell/fseek), extending it to support large
> > files would be non-trivial.

It's inherent in the purpose of the module that it be LFS compliant.


I disagree with "extending it to support large files is non-trivial":

All the filesize, ftell, fseek calls don't need to be there and can 
easily be #ifdef'd out if required. They are just there for the
(somewhat lame & inaccurate; but fast, lightweight, and non-critical)
guess at the total number of lines in the input file to pass to
G_percent().

But G_percent() is most interesting when the processing will take a long
time, so it would be nice to have it there for large files.


This is the critical loop:
 while( 0 != G_getl2(buff, BUFFSIZE-1, in_fd) ) { ... }

besides that it's just fopen() and fclose() -- it is very simple really.
All the other scanning stuff is optional.


BD:
> Attached is a quick patch to enable LFS.  It's "poorly" implemented
> with fseeko/ftello, so I'm not sure if I should commit it.

Thanks Brad. The patch looks good to my untrained eye, my only query is
if those calls should be conditionalized to USE_LARGEFILES, as fseeko()
& co are not ANSI compliant:

====snip====
NOTES
       These  functions  are found on SysV-like systems.  They are not
       present in libc4, libc5, glibc 2.0 but  available  since  glibc
       2.1.

CONFORMING TO
       The fseeko and ftello functions conform to SUSv2.
============


I don't have:
 - a 64 bit machine
 - a dataset that large
 - a [funded] research project that needs it
 - any real experience with LFS

so it is as it is, and I welcome improvements from anybody with
something from the above list.


Hamish

From hamish_nospam at yahoo.com  Mon Oct  9 02:27:49 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  9 02:27:53 2006
Subject: [GRASS-dev] First steps to switch the bug tracker
In-Reply-To: <200610052333.01123.jan-oliver.wagner@intevation.de>
References: <200610052333.01123.jan-oliver.wagner@intevation.de>
Message-ID: <20061009132749.2f6f6f79.hamish_nospam@yahoo.com>

> Have fun :-)

Hi,

Just for kicks I was looking to add GRASS 6.2.0RC2 to the "Files"
release section. 

I encounter this:  (Maximum upload file size: 6M)

the source .tar.gz is 12M.


Hamish

From rez at touchofmadness.com  Mon Oct  9 03:14:34 2006
From: rez at touchofmadness.com (Brad Douglas)
Date: Mon Oct  9 03:14:52 2006
Subject: [GRASS-dev] Re: [GRASS-user] Large vector files
In-Reply-To: <20061009130112.31fab641.hamish_nospam@yahoo.com>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BC7@s5-dar-r1.nrn.nrcan.gc.ca>
	<20061008185113.5ebd15af.hamish_nospam@yahoo.com>
	<17704.61035.48627.525465@cerise.gclements.plus.com>
	<1160333153.2382.103.camel@devel>
	<20061009130112.31fab641.hamish_nospam@yahoo.com>
Message-ID: <1160356474.2382.155.camel@devel>

On Mon, 2006-10-09 at 13:01 +1300, Hamish wrote:
> HB:
> > > > I am always looking for feedback on how r.in.xyz goes with massive
> > > > input data. (>2gb? >4gb?)
> GC:
> > > r.in.xyz doesn't use LFS, so it will be limited to 2Gb on 32-bit
> > > systems (any system where "long" is 32 bits). As it uses ANSI stdio
> > > functions (including ftell/fseek), extending it to support large
> > > files would be non-trivial.
> HA:
> It's inherent in the purpose of the module that it be LFS compliant.
>
> I disagree with "extending it to support large files is non-trivial":

I disagree with your disagreement. :-)

> HA:
> All the filesize, ftell, fseek calls don't need to be there and can 
> easily be #ifdef'd out if required. They are just there for the
> (somewhat lame & inaccurate; but fast, lightweight, and non-critical)
> guess at the total number of lines in the input file to pass to
> G_percent().
> 
> But G_percent() is most interesting when the processing will take a long
> time, so it would be nice to have it there for large files.
> 
> 
> This is the critical loop:
>  while( 0 != G_getl2(buff, BUFFSIZE-1, in_fd) ) { ... }

And this is where the bulk of the problem lies.  'in_fd' is a
misinformed name for the variable.  It is not a file descriptor, but is
in fact a 'FILE' struct.

Many GRASS functions almost require using fopen()/fclose()/fseek(), etc.
because of its dependence on the 'FILE' structure.
open()/close()/lseek() are better bets if you don't like your data
truncated, but requires POSIX.1.

> HA:
> besides that it's just fopen() and fclose() -- it is very simple really.
> All the other scanning stuff is optional.

I sent Glynn a few ideas I have.  They would require that GRASS handles
all file IO, so we'd have to add a G_open()/G_close().  Large files are
quickly becoming a show-stopper.

> BD:
> > Attached is a quick patch to enable LFS.  It's "poorly" implemented
> > with fseeko/ftello, so I'm not sure if I should commit it.
> HA:
> Thanks Brad. The patch looks good to my untrained eye, my only query is
> if those calls should be conditionalized to USE_LARGEFILES, as fseeko()
> & co are not ANSI compliant:
> 
> ====snip====
> NOTES
>        These  functions  are found on SysV-like systems.  They are not
>        present in libc4, libc5, glibc 2.0 but  available  since  glibc
>        2.1.
> 
> CONFORMING TO
>        The fseeko and ftello functions conform to SUSv2.
> ============

This is why I didn't want to commit it.  Besides being non-standard,
they are poor implementations with plenty of caveats to go around.
Collect them all and trade them with your friends! ;-)


-- 
Brad Douglas <rez touchofmadness com>                    KB8UYR/6
Address: 37.493,-121.924 / WGS84    National Map Corps #TNMC-3785

From hamish_nospam at yahoo.com  Mon Oct  9 05:14:47 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  9 05:16:15 2006
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
In-Reply-To: <C14E9CAB.F810%michael.barton@asu.edu>
References: <20061008220334.26ae410f.hamish_nospam@yahoo.com>
	<C14E9CAB.F810%michael.barton@asu.edu>
Message-ID: <20061009161447.2bac7562.hamish_nospam@yahoo.com>

[6.3cvs and 6.2 branch updated to use bwidget's LabelFrame + bg color]

Michael Barton wrote:
> Still catching up with a lot of traffic over past 24 hours.

I'm still trying to catch up with last month..

> We already use bwidgets for most of the widgets listed below.

ok, it was a new discovery for me.

> It's not that substitutes can't be found or worked out, it's just that
> I don't have much in the way of time to do it, and it's additionally
> difficult since I'm running 8.4--as are most people who can test.

Well, fwiw it only takes me a minute for me to swich in Debian, and I
don't mind living in 8.3. (I had upgraded to 8.4 to test incompatibility
with NVIZ!)

> So I'm not against it as long as it doesn't degrade the UI, I just
> don't want to be the person who has to make gism work with 8.3.

No worries, the project can deal with these things as they come up. If
any new code goes in, it would be nice if it wasn't known to be 8.4+
only though. (but hopefully all new code will be wx so it won't matter)

> On the other hand, as you note, v.digit needs to work with both old
> and new GUI. So as long as we maintain d.m, I agree that v.digit
> should be backward compatible.

After 6.2.0, why should we maintain d.m? I don't think we have the
manpower to maintain 3 GUIs (see above "trying to catch up..")
Moreover, after 6.2.0 should gis.m be maintained in a minimal "legacy
support" mode until the wx gui is ready?


> I went through the GRASS 5.4 source code and looked at all the bwidget
> demo files and tried all permutations of LabelFrame from there. It all
> comes out the same on my Mac with x11. I don't know what is up, but I
> can't get a border to show up no matter what I do. Maybe it does in
> 8.3 but not in 8.4. Maybe it's something else in the v.digit code.

I had no luck with 8.3. I tried and making a few line demo app which
only contained a frame, but didn't quite get how to get the parent/
child relationship established; my text always drew outside the box.
(so the box was empty / so no box).

> I guess just add -bg honeydew2 to the options and call it good. This
> looks nice and gives the same delineation of the mouse buttons as the
> labelframe border.

done. also switched the order of the (left, right, center) text, as
center was on the right! It might be cleaner to put those words above
each button instead of in the title, but it's fairly self-explanitory
and I'm not too worried about it.



thanks for your help,
Hamish

From michael.barton at asu.edu  Mon Oct  9 06:09:22 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Oct  9 06:09:22 2006
Subject: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
In-Reply-To: <20061009161447.2bac7562.hamish_nospam@yahoo.com>
Message-ID: <C14F1982.F82F%michael.barton@asu.edu>


> From: Hamish <hamish_nospam@yahoo.com>
> Date: Mon, 9 Oct 2006 16:14:47 +1300
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] Re: tcltk 8.3 and v.digit toolbox
> 
> Well, fwiw it only takes me a minute for me to swich in Debian, and I
> don't mind living in 8.3. (I had upgraded to 8.4 to test incompatibility
> with NVIZ!)
> 
>> So I'm not against it as long as it doesn't degrade the UI, I just
>> don't want to be the person who has to make gism work with 8.3.
> 
> No worries, the project can deal with these things as they come up. If
> any new code goes in, it would be nice if it wasn't known to be 8.4+
> only though. (but hopefully all new code will be wx so it won't matter)

Thanks. This is a big help.

> 
>> On the other hand, as you note, v.digit needs to work with both old
>> and new GUI. So as long as we maintain d.m, I agree that v.digit
>> should be backward compatible.
> 
> After 6.2.0, why should we maintain d.m? I don't think we have the
> manpower to maintain 3 GUIs (see above "trying to catch up..")
> Moreover, after 6.2.0 should gis.m be maintained in a minimal "legacy
> support" mode until the wx gui is ready?

I am very much in favor of this. I can just barely maintain one GUI and work
on a 2nd--though there is real hope that more people will be able to help on
the wx side.

Michael

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



From hamish_nospam at yahoo.com  Mon Oct  9 08:02:13 2006
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon Oct  9 08:02:22 2006
Subject: [GRASS-dev] bug in Vect_break_lines() ? [bug #2765] [was: v.buffer
	bug]
In-Reply-To: <45290AC4.5010509@o2.pl>
References: <20061002012404.885D61005D8@lists.intevation.de>
	<452104F6.7070101@o2.pl>
	<20061009002149.6e81787a.hamish_nospam@yahoo.com>
	<45290AC4.5010509@o2.pl>
Message-ID: <20061009190213.1f2e84c8.hamish_nospam@yahoo.com>

> Hamish wrote:
> > I still see the "holes get filled" bug in my own data though,
..
> > Ahh, I've got you now Obi Wan, the interior-fill bug happens when
> > there is an interior dangle in my road network ... and I've isolated
> > it to a vector made up of 10 polylines.

attached are instructions for recreating the bug with a simplified set
of lines which trigger it.   ("v.clean tool=prune" worked well!)

Things start to go wrong in Vect_break_lines(): the island (hole) in the
middle of the area (test with d.what.vect) becomes an area, so then
area_in_buffer() loops through it as a real overlapping area. Then the
island's centroid is nearer to a boundary than the buffer distance,
which lets it pass the test. Perhaps area_in_buffer() could test cw vs
ccw side of polygon to solve this?

I get the same results if I stop v.buffer with debug=buffer and run
"v.clean tool=break".

also in the Vect_break_lines() step it goes from 8 boundaries to 167,
so I can't later pass a stored buffer value for each of the 8 buffers to
the area_in_buffer() test (but this may not be important if it knows
that the island isn't an area in the first place). It's still a bug that
the dynamic buffer size area_in_buffer() uses the last buffer &
tolerance loaded for post-processing, as I've noted in the source.


> > I don't understand why you consistently get the error, and I
> > don't, using the same* dataset.
..
> Very strange. Maybe it has something to do with the compiler used?
> 
> $ gcc -v
> gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
> 
> Or locale? I'm from Poland, where we use "," instead of "." for
> decimal point delimiter. But how that would impact v.buffer I don't
> know - just trying to think of *something*.
> 
> Does v.buffer depend on anything that could differ between your and my
> system? I'm on Ubuntu Dapper 6.06, kernel 2.6.15-27-686. What is
> yours?

No idea. I'm using Debian/Sarge, gcc 3.3.5, linux 2.4.27-3-686 on a P4.


Can you try running
  v.buffer ditches buffer=4 debug=buffer
? and have a look at the output with d.vect and d.what.vect ?
maybe some clues/hope there.



Hamish
-------------- next part --------------
cat << EOF > vbuf_fill_bug.vasc
L  2 1
 1772686.30519775 5851775.14702921
 1773306.00632122 5852447.04425756
 1     1         
L  2 1
 1774243.98302532 5850080.4624088
 1773306.00632122 5852447.04425756
 1     2         
L  2 1
 1773306.00632122 5852447.04425756
 1773195.48790797 5853628.13605358
 1     3         
L  4 1
 1773145.65706623 5849811.18970544
 1771278.44193002 5850577.88976232
 1771661.0129225 5852557.45636742
 1773195.48790797 5853628.13605358
 1     4         
L  2 1
 1773145.65706623 5849811.18970544
 1774243.98302532 5850080.4624088
 1     5         
L  2 1
 1773218.55495855 5849304     
 1773145.65706623 5849811.18970544
 1     6         
L  2 1
 1773195.48790797 5853628.13605358
 1774528      5854386.23216845
 1     7         
L  2 1
 1774243.98302532 5850080.4624088
 1774528      5850056.01304682
 1     8         
EOF


OUTMAP="vbuf_fill_bug"
v.in.ascii -n in=vbuf_fill_bug.vasc out="$OUTMAP" format=standard

ATTR_COLS="CAT int, ID int, LANE_COUNT int"
v.db.addtable map="$OUTMAP" columns="$ATTR_COLS"

db.execute << EOF
  UPDATE $OUTMAP SET id=16029, lane_count=1 WHERE cat=1;
  UPDATE $OUTMAP SET id=16032, lane_count=1 WHERE cat=2;
  UPDATE $OUTMAP SET id=16032, lane_count=1 WHERE cat=3;
  UPDATE $OUTMAP SET id=6,     lane_count=2 WHERE cat=4;
  UPDATE $OUTMAP SET id=16033, lane_count=2 WHERE cat=5;
  UPDATE $OUTMAP SET id=6,     lane_count=2 WHERE cat=6;
  UPDATE $OUTMAP SET id=6,     lane_count=2 WHERE cat=7;
  UPDATE $OUTMAP SET id=16033, lane_count=2 WHERE cat=8;
EOF

# demonstation of buggy output
v.buffer input=$OUTMAP output=${OUTMAP}_buf_dyn bufcol=LANE_COUNT scale=150

# stop processing after buffering, before cleaning
v.buffer input=$OUTMAP output=${OUTMAP}_buf_dyn_DBGb bufcol=LANE_COUNT \
   scale=150 debug=buffer

# 8 boundaries: how to associate the 8 lane_count values for area_in_buffer() ?
v.info -t ${OUTMAP}_buf_dyn_DBGb
 
 
# notice center hole is not reported an Area
d.vect ${OUTMAP}_buf_dyn_DBGb
d.what.vect

### No good: tool=break makes island into an area, 
###   and makes relating 8 parent polygons to lane_count ?? v.distance ??
# break at intersections
v.clean in=${OUTMAP}_buf_dyn_DBGb out=${OUTMAP}_bdy tool=break
# add centroids
v.category in=${OUTMAP}_bdy out=${OUTMAP}_area step=0
# result: same as v.buffer without debug:
v.dissolve in=${OUTMAP}_area out=${OUTMAP}_final
From tutey at o2.pl  Mon Oct  9 09:08:31 2006
From: tutey at o2.pl (Maciej Sieczka)
Date: Mon Oct  9 09:08:35 2006
Subject: [GRASS-dev] First steps to switch the bug tracker
In-Reply-To: <20061009132749.2f6f6f79.hamish_nospam@yahoo.com>
References: <200610052333.01123.jan-oliver.wagner@intevation.de>
	<20061009132749.2f6f6f79.hamish_nospam@yahoo.com>
Message-ID: <4529F56F.9030503@o2.pl>

Hamish wrote:
>> Have fun :-)
> 
> Hi,
> 
> Just for kicks

OK, but we *won't* be putting here anything for *real*, will we?

Cheers,
Maciek

From mlennert at club.worldonline.be  Mon Oct  9 10:33:32 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Oct  9 10:33:11 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect 
	causes error :can't read "_data(.gronsole.gronsole, 9,
	donecmd)": no such element in array
In-Reply-To: <43559.85.10.65.158.1160296669.squirrel@geog-pc40.ulb.ac.be>
References: <45267957.2020505@club.worldonline.be>	<20061008155945.57c29721.hamish_nospam@yahoo.com>	<42215.85.10.65.158.1160296222.squirrel@geog-pc40.ulb.ac.be>
	<43559.85.10.65.158.1160296669.squirrel@geog-pc40.ulb.ac.be>
Message-ID: <452A095C.2050005@club.worldonline.be>

Moritz Lennert wrote:
> On Sun, October 8, 2006 10:30, Moritz Lennert wrote:
>> On Sun, October 8, 2006 04:59, Hamish wrote:
>>> Moritz Lennert wrote:
>>>> Using a where clause in vector display in gis.m causes the following
>>>> error under WinGRASS. Any suggestions ?
>>>> (WinGRASS version 2006-09-17)
>>>>
>>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
>>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>>>> element in array
>>>>      while executing
>>>> "set donecmd $_data($path,$ci,donecmd)"
>>>
>>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
>>> query in the "query cat values" box by mistake.
>> I am not near a windows box right now, but I am quite positive that this
>> is not the problem here. I entered the query in the where box, not the cat
>> box.
>>
>> But I'll make sure tomorrow.
> 
> Actually I just managed to test (Qemu over NX, quite an experience ;-) ),
> and I can confirm that the problem is with the sql query box. So it is not
> the same problem as the one described by Hamish.


Huidae or Glynn, any ideas on this ?

Moritz

From glynn at gclements.plus.com  Mon Oct  9 12:10:07 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  9 12:10:10 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <452901BA.1060603@o2.pl>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
	<17704.63342.78554.477221@cerise.gclements.plus.com>
	<452901BA.1060603@o2.pl>
Message-ID: <17706.8191.796068.690754@cerise.gclements.plus.com>


Maciej Sieczka wrote:

> >>>> Propably due to the recent work on --v and --q flags (great stuff, many
> >>>> thanks to the authors!), r.mapcalc doesn't print any progress indicator
> >>>> anymore.
> >>> AFAIK, modules are quiet by default now. If you want verbosity (e.g.
> >>> progress indication) you have to enable it.
> 
> >> I didn't realize that quiet mode implies no progress indicator. In that
> >> case verbose should be the default IMO, because we can't leave users
> >> without a feedback from the module progress unless they implicitely
> >> requests that. Am I wrong?
> 
> > Yes. The normal behaviour for Unix command-line programs is not to
> > print anything unless something unexpected happens.
> 
> GRASS modules are not 'normal UNIX programs'. A user must be informed
> if there's a progress. Otherwise he will not even know if the module
> freezed or what. I fully second what Hamish says in this regard (in his
> post in this thread).

On that, we'll just have to disagree. It isn't important, as the user
can just set GRASS_VERBOSE explicitly if the default value isn't to
their liking.

> > Apart from anything else, generating an error at the point that the
> > specific map is processed (the way that vectors are currently handled)
> > means that it won't even attempt to remove any subsequent maps. E.g.
> > 
> > 	g.remove vect=vect1,vectnonexist,vect2
> > 
> > will abort on vectnonexist and won't attempt to remove vect2.
> 
> Fine. Then g.remove vect should be fixed to behave like the other
> types, and a non-fatal "WARNING: Vector map <dummy> not found" shoud be
> issued if needed. Same for all other types. And, most importantly,
> those warnings should issued by default, unless the user requests
> g.remove to run quietly (which implies that a verbose mode should be
> the default). Otherwise the user will not know that the map he tried to
> remove doesn't exist.

Warnings are supposed to be issued even at minimum verbosity. It's the
more detailed output which needs to vary according the verbosity
settings.

> >> Also, in the verbose mode, only a single-line information like "Raster
> >> map <dummy> removed" should be printed insated of the current 9 lines:
> >>
> >> $ g.remove rast=dummy --v
> >> REMOVE [dummy]
> >> raster
> >> header
> >> category
> >> color MISSING
> >> history
> >> misc
> >> fcell MISSING
> >> g3dcell MISSING
> 
> > IMHO, verbose mode should display everything, quiet mode should
> > display a single warning for each map with no elements (i.e. the map
> > doesn't exist).
> 
> But all those lines: raster, header, category, color, history, misc,
> fcell are meaningless for a normal user. He should only be told that
> "Raster map <blahblah> was removed". Why does one need to read all
> those lines anyway? They don't give any usefull information but
> distract and occupy space on the terminal. They should be displayed
> only at a higher DEBUG level.

In retrospect, I agree that those should be considered "debug"
information. Historically, they have been the only way to discover
that a map is entirely absent.

BTW, etc/element_list doesn't distinguish between "core" elements
(e.g. cellhd, cell etc) and ancilliary elements (history, color etc). 
Ideally, it shouldn't be possible to have the latter without the
former, but I wouldn't assume that it's completely impossible in
practice.

For now, I think we'll have to be satisfied with distinguishing
between zero elements existing and one or more elements existing,
regardless of the signficance of the elements.

> >>> g3dcell MISSING
> 
> >> BTW, I'd like to ask again what is the g3dcell?
> 
> > No idea.
> 
> Could it be removed then?

No idea.

> >> Talking of g.remove - could the following types should be disposed in
> >> GRASS 7?:
> >>
> >> 1. sites - there is no sites functionality in Grass>=5.7
> >> 2. region3d - 3D region settings have been merged into region
> >> 3. 3dview - remainment of Grass <5.7 3d.view command
> >> 4? icon - I don't know, propably too? what is it?
> >> 5. oldvect
> >> 6. asciivect
> >>
> >> Same applies to g.copy/rename/list
> 
> > Removing them from copy/rename seems reasonable enough. However you
> > might upgrade from 5.x to 6.x
> 
> I'm talking about GRASS 7.
> 
> > but still have 5.x entities left in the database directories, so
> > you need some way to remove them.
> 
> The question might be: is GRASS 7 supposed to provide tools to make the
> switch from GRASS 5 easy, like GRASS 6 does?

I see no reason to remove that functionality, given that it's
essentially a few lines in the element_list file. None of this is
actually coded.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Oct  9 12:28:05 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  9 12:28:09 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <f8fe65c40610080839u77d65877xdbb8304cef393ffe@mail.gmail.com>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
	<f8fe65c40610080839u77d65877xdbb8304cef393ffe@mail.gmail.com>
Message-ID: <17706.9269.774566.263774@cerise.gclements.plus.com>


Martin Landa wrote:

> trying to cleanup g.remove module I have prepared the patch. Is it OK
> for you? Any comments welcomed...

Rather than hard-coding checks for specific entity types:

+	if (G_strcasecmp(list[n].alias, "rast") == 0 ) {
+	    if ((mapset = G_find_cell2 (old, "")) == NULL) {
+		G_warning(_("Raster map <%s> not found"), old);
+		result = 1;
+	    }
+	}
+	
+	if (G_strcasecmp(list[n].alias, "rast3d") == 0 ) {
+	    if ((mapset = G_find_grid3 (old, "")) == NULL) {
+		G_warning(_("Raster 3d map <%s> not found"), old);
+		result = 1;
+	    }
+	}

I would add a flag which is initially cleared for each entity (map
etc) and set when an element is actually removed. A warning would be
generated if the flag is still clear when all of the elements for an
entity have been processed.

E.g.:

+	removed = 0;
 	for (i = 0; i < list[n].nelem; i++) {
 	    switch (G_remove (list[n].element[i], old))
 	    {
 	    case -1: 
-	        G_warning (" %-*s %s", len, list[n].desc[i],_("COULD NOT REMOVE"));
+	        G_warning ("%s: %s", list[n].desc[i],_("couldn't be removed"));
 	        result = 1;
 		break;
 	    case  0: 
-	        G_message (" %-*s %s", len, list[n].desc[i],_("MISSING"));
+	        G_debug (1, "%s: %s", list[n].desc[i],_("missing"));
 		break;
 	    case 1:
-	        G_message (" %-*s ", len, list[n].desc[i]);
+	        G_debug (1, "%s: %s", list[n].desc[i],_("removed"));
+	        removed = 1;
 		break;
 	    }
 	}
+
+	if (!removed)
+		G_warning ("%s: %s", list[n].desc[i],_("nothing removed"));

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Oct  9 12:34:06 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  9 12:34:19 2006
Subject: [GRASS-dev] adding 'desc' to dbf sql driver
In-Reply-To: <4513A84E.8090807@club.worldonline.be>
References: <4513A84E.8090807@club.worldonline.be>
Message-ID: <17706.9630.541911.407286@cerise.gclements.plus.com>


Moritz Lennert wrote:

> Hi,
> 
> Reworking on d.vect.chart I need to be able to sort the reults of a 
> select in descending order. As the dbf driver doesn't allow this, I have 
> been trying to see how to extend the driver.
> 
> IIUC, it's "just" a question of conditionalising the qsort call on line 
> 566 of db/drivers/dbf/dbfexe.c, and (would this be enough ?) use
> 
> qsort(set, nset, sizeof(int), -cmp_row);

That won't work. It might compile, but you're essentially converting
the address of the cmp_row() function to an integer, negating it, then
converting it back to a pointer.

However, you can do:

	static int cmp_row_desc(const void *pa, const void *pb)
	{
		return -cmp_row_asc(pa, pb);
	}

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Oct  9 12:39:41 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  9 12:39:44 2006
Subject: [GRASS-dev] Re: [GRASS-user] Large vector files
In-Reply-To: <20061009130112.31fab641.hamish_nospam@yahoo.com>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BC7@s5-dar-r1.nrn.nrcan.gc.ca>
	<20061008185113.5ebd15af.hamish_nospam@yahoo.com>
	<17704.61035.48627.525465@cerise.gclements.plus.com>
	<1160333153.2382.103.camel@devel>
	<20061009130112.31fab641.hamish_nospam@yahoo.com>
Message-ID: <17706.9965.293498.407328@cerise.gclements.plus.com>


Hamish wrote:

> HB:
> > > > I am always looking for feedback on how r.in.xyz goes with massive
> > > > input data. (>2gb? >4gb?)
> GC:
> > > r.in.xyz doesn't use LFS, so it will be limited to 2Gb on 32-bit
> > > systems (any system where "long" is 32 bits). As it uses ANSI stdio
> > > functions (including ftell/fseek), extending it to support large
> > > files would be non-trivial.
> 
> It's inherent in the purpose of the module that it be LFS compliant.
> 
> I disagree with "extending it to support large files is non-trivial":
> 
> All the filesize, ftell, fseek calls don't need to be there and can 
> easily be #ifdef'd out if required. They are just there for the
> (somewhat lame & inaccurate; but fast, lightweight, and non-critical)
> guess at the total number of lines in the input file to pass to
> G_percent().

In that case, if you remove the fseek/ftell calls, LFS should be
straightforward. You just need include <grass/config.h> before
including any other header.

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Oct  9 12:48:06 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  9 12:48:09 2006
Subject: [GRASS-dev] Re: [GRASS-user] Large vector files
In-Reply-To: <1160356474.2382.155.camel@devel>
References: <0E5A77B55A57D511BB3F0002A537C26208C55BC7@s5-dar-r1.nrn.nrcan.gc.ca>
	<20061008185113.5ebd15af.hamish_nospam@yahoo.com>
	<17704.61035.48627.525465@cerise.gclements.plus.com>
	<1160333153.2382.103.camel@devel>
	<20061009130112.31fab641.hamish_nospam@yahoo.com>
	<1160356474.2382.155.camel@devel>
Message-ID: <17706.10470.314449.833797@cerise.gclements.plus.com>


Brad Douglas wrote:

> > All the filesize, ftell, fseek calls don't need to be there and can 
> > easily be #ifdef'd out if required. They are just there for the
> > (somewhat lame & inaccurate; but fast, lightweight, and non-critical)
> > guess at the total number of lines in the input file to pass to
> > G_percent().
> > 
> > But G_percent() is most interesting when the processing will take a long
> > time, so it would be nice to have it there for large files.
> > 
> > 
> > This is the critical loop:
> >  while( 0 != G_getl2(buff, BUFFSIZE-1, in_fd) ) { ... }
> 
> And this is where the bulk of the problem lies.  'in_fd' is a
> misinformed name for the variable.  It is not a file descriptor, but is
> in fact a 'FILE' struct.
> 
> Many GRASS functions almost require using fopen()/fclose()/fseek(), etc.
> because of its dependence on the 'FILE' structure.
> open()/close()/lseek() are better bets if you don't like your data
> truncated, but requires POSIX.1.

We already require those functions in libgis and a lot of other
places.

OTOH, it would be nice to minimise the number of places that use the
Unix I/O functions are used, with most modules restricted to the ANSI
stdio functions. Unfortunately, that makes LFS a pain.

It would all be so much easier if the Linux API/ABI was redefined to
use a 64-bit "long" even on 32-bit platforms; _FILE_OFFSET_BITS is a
really ugly hack.

> > HA:
> > besides that it's just fopen() and fclose() -- it is very simple really.
> > All the other scanning stuff is optional.
> 
> I sent Glynn a few ideas I have.  They would require that GRASS handles
> all file IO, so we'd have to add a G_open()/G_close().  Large files are
> quickly becoming a show-stopper.

It isn't open/close that's the problem; we need G_seek() and G_tell()
functions that always use off_t, using fseeko() and ftello() where
available, and fseek() and ftell() (with their 32-bit limitations)
where they aren't.

BTW, note that the problems with large files aren't necessarily
limited to I/O. Modules which compute cell counts can overrun the
31-bit range (even with files <2GiB, by virtue of compression).

-- 
Glynn Clements <glynn@gclements.plus.com>

From glynn at gclements.plus.com  Mon Oct  9 12:54:02 2006
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon Oct  9 13:00:58 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect 
	causes error :can't read "_data(.gronsole.gronsole, 9,
	donecmd)": no such element in array
In-Reply-To: <452A095C.2050005@club.worldonline.be>
References: <45267957.2020505@club.worldonline.be>
	<20061008155945.57c29721.hamish_nospam@yahoo.com>
	<42215.85.10.65.158.1160296222.squirrel@geog-pc40.ulb.ac.be>
	<43559.85.10.65.158.1160296669.squirrel@geog-pc40.ulb.ac.be>
	<452A095C.2050005@club.worldonline.be>
Message-ID: <17706.10826.18404.911170@cerise.gclements.plus.com>


Moritz Lennert wrote:

> >>>> Using a where clause in vector display in gis.m causes the following
> >>>> error under WinGRASS. Any suggestions ?
> >>>> (WinGRASS version 2006-09-17)
> >>>>
> >>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
> >>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
> >>>> element in array
> >>>>      while executing
> >>>> "set donecmd $_data($path,$ci,donecmd)"
> >>>
> >>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
> >>> query in the "query cat values" box by mistake.
> >> I am not near a windows box right now, but I am quite positive that this
> >> is not the problem here. I entered the query in the where box, not the cat
> >> box.
> >>
> >> But I'll make sure tomorrow.
> > 
> > Actually I just managed to test (Qemu over NX, quite an experience ;-) ),
> > and I can confirm that the problem is with the sql query box. So it is not
> > the same problem as the one described by Hamish.
> 
> Huidae or Glynn, any ideas on this ?

	# Actually run the program
	if { $mingw == "1" } {
		# shell scripts require sh.exe.
		set cmd [concat | sh -c '$cmd']
	} else {
		set cmd [concat | $cmd 2>@ stdout]
	}

If you want to use "sh -c ...", you have to escape any shell
metacharacters, otherwise commands which happen to contain shell
metacharacters (e.g. "<" or ">" in a SQL "WHERE" clause) won't work.

I've already explained this in the thread discussing these changes.

-- 
Glynn Clements <glynn@gclements.plus.com>

From mlennert at club.worldonline.be  Mon Oct  9 13:50:45 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Oct  9 13:50:23 2006
Subject: [GRASS-dev] adding 'desc' to dbf sql driver
In-Reply-To: <1a486f560610081013j3ce2197fgaf7ded786e4f5d76@mail.gmail.com>
References: <4513A84E.8090807@club.worldonline.be>	<1a486f560609271831m747f3495sa6d8495273c107d4@mail.gmail.com>	<48506.85.10.69.159.1160229752.squirrel@geog-pc40.ulb.ac.be>
	<1a486f560610081013j3ce2197fgaf7ded786e4f5d76@mail.gmail.com>
Message-ID: <452A3795.4060606@club.worldonline.be>

Daniel Calvelo wrote:
> Hi Moritz,
> 
> Looks good to me. In the yac.y patch, you don't need to duplicate the
> code for ORDER BY NAME and ORDER BY NAME ASC.

How do I take care of the case where neither asc nor desc are given in 
the sql ? This should default to asc, but this:

+y_order_asc:
+               NAME | NAME ASC                         { 
sqpOrderColumn( $1, SORT_ASC ); }

does not work, i.e. results of 'order by' without asc are not sorted.

So how does this need to be formulated ?


> For cmp_row_desc, you
> could just return( - cmp_row_asc) with the same arguments. Glynn, a
> cursory look?

Did that and it seems to work.

> 
> FYI, the text file in lib/db/sqlp/test/test allows for some testing of
> the parser. That may help you find any hidden bugs in the sqlp part of
> your patch. 


I get

Input row: -->>INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', +32, +56.7 );
<<--
Input statement: -->>INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', +32, 
+56.7 )<<--
Error: statement was not parsed successfully.

Don't know how this would be related to my changes.

(BTW

INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', -32, -56.7 );

does not cause any problems.)

If I remove the above insert statement and add:

SELECT c1,c3 FROM pok order by c1;

it runs perfectly.

However, when I insert

SELECT c1,c3 FROM pok order by c1 ASC;
or
SELECT c1,c3 FROM pok order by c1 DESC;

I get a segmentation fault:

Input row: -->>SELECT c1,c3 FROM pok order by c1 ASC;
<<--
Input statement: -->>SELECT c1,c3 FROM pok order by c1 ASC<<--
********** SQL PARSER RESULT **********
INPUT: SELECT c1,c3 FROM pok order by c1 ASC
COMMAND: SELECT
TABLE: pok
COLUMN  1: c1
COLUMN  2: c3
./test2: line 15: 32474 Done                    echo "SELECT c1,c3 FROM 
pok where c3 <> 34 and c5 = 2.3;
SELECT c1,c3 FROM pok order by c1 ASC;
INSERT INTO pok  VALUES ( 'abc', 32, 56.7 );
INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', 32, 56.7 );
INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', -32, -56.7 );
upDAte pok SET c2 = '5', c3 = 1  WHERE c1 = '1' AND c5 = 6;
delete FROM pok WHERE c1 = '1' and c2=3 AND c5 <= 4.35;
CREATE TABLE pok ( c1 INT, c2 VARCHAR (5), c3 DOUBLE );
DROP TABLE pok;
ALTER TABLE pok ADD COLUMN id int;
ALTER TABLE pok ADD popis varchar(10);
UPDATE pok SET c2 = NULL, c1=c2, c3=(-c3+12)/c1 where c1 NOT NULL;
update pok set c1=c2,c2=c1,c3=NULL where c1+2>1/cat+0.5 and not (c1=1 or 
c2=2);"     32475 Segmentation fault      | ./sqlptest


I'm a bit lost here. What is print.c used for ?

> You might also wish to update print.c to accomodate for
> asc/desc (it's a one-line change near the end).

Did that, but not sure if correctly. Should I check for the existance of 
orderDir before using it, i.e. should it rather be

if ( sqlpStmt->command == SQLP_SELECT ) {
     if ( sqlpStmt->orderDir )
        {
         fprintf( stderr, "ORDER BY: %s %s\n", sqlpStmt->orderCol, 
sqlpStmt->orderDir );
        } else {
         fprintf( stderr, "ORDER BY: %s\n", sqlpStmt->orderCol );
        }

or is this not necessary ?


> 
> And of course, after testing, this has to be documented :)
> 

Obviously... :-)

Moritz

From mlennert at club.worldonline.be  Mon Oct  9 13:53:51 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Oct  9 13:53:31 2006
Subject: [GRASS-dev] adding 'desc' to dbf sql driver
In-Reply-To: <452A3795.4060606@club.worldonline.be>
References: <4513A84E.8090807@club.worldonline.be>	<1a486f560609271831m747f3495sa6d8495273c107d4@mail.gmail.com>	<48506.85.10.69.159.1160229752.squirrel@geog-pc40.ulb.ac.be>
	<1a486f560610081013j3ce2197fgaf7ded786e4f5d76@mail.gmail.com>
	<452A3795.4060606@club.worldonline.be>
Message-ID: <452A384F.7090708@club.worldonline.be>

Forgot to attach the latest patch. Here it is.

Moritz

Moritz Lennert wrote:
> Daniel Calvelo wrote:
>> Hi Moritz,
>>
>> Looks good to me. In the yac.y patch, you don't need to duplicate the
>> code for ORDER BY NAME and ORDER BY NAME ASC.
> 
> How do I take care of the case where neither asc nor desc are given in 
> the sql ? This should default to asc, but this:
> 
> +y_order_asc:
> +               NAME | NAME ASC                         { 
> sqpOrderColumn( $1, SORT_ASC ); }
> 
> does not work, i.e. results of 'order by' without asc are not sorted.
> 
> So how does this need to be formulated ?
> 
> 
>> For cmp_row_desc, you
>> could just return( - cmp_row_asc) with the same arguments. Glynn, a
>> cursory look?
> 
> Did that and it seems to work.
> 
>>
>> FYI, the text file in lib/db/sqlp/test/test allows for some testing of
>> the parser. That may help you find any hidden bugs in the sqlp part of
>> your patch. 
> 
> 
> I get
> 
> Input row: -->>INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', +32, +56.7 );
> <<--
> Input statement: -->>INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', +32, 
> +56.7 )<<--
> Error: statement was not parsed successfully.
> 
> Don't know how this would be related to my changes.
> 
> (BTW
> 
> INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', -32, -56.7 );
> 
> does not cause any problems.)
> 
> If I remove the above insert statement and add:
> 
> SELECT c1,c3 FROM pok order by c1;
> 
> it runs perfectly.
> 
> However, when I insert
> 
> SELECT c1,c3 FROM pok order by c1 ASC;
> or
> SELECT c1,c3 FROM pok order by c1 DESC;
> 
> I get a segmentation fault:
> 
> Input row: -->>SELECT c1,c3 FROM pok order by c1 ASC;
> <<--
> Input statement: -->>SELECT c1,c3 FROM pok order by c1 ASC<<--
> ********** SQL PARSER RESULT **********
> INPUT: SELECT c1,c3 FROM pok order by c1 ASC
> COMMAND: SELECT
> TABLE: pok
> COLUMN  1: c1
> COLUMN  2: c3
> ./test2: line 15: 32474 Done                    echo "SELECT c1,c3 FROM 
> pok where c3 <> 34 and c5 = 2.3;
> SELECT c1,c3 FROM pok order by c1 ASC;
> INSERT INTO pok  VALUES ( 'abc', 32, 56.7 );
> INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', 32, 56.7 );
> INSERT INTO pok ( c1, c2,c3) VALUES ( 'abc', -32, -56.7 );
> upDAte pok SET c2 = '5', c3 = 1  WHERE c1 = '1' AND c5 = 6;
> delete FROM pok WHERE c1 = '1' and c2=3 AND c5 <= 4.35;
> CREATE TABLE pok ( c1 INT, c2 VARCHAR (5), c3 DOUBLE );
> DROP TABLE pok;
> ALTER TABLE pok ADD COLUMN id int;
> ALTER TABLE pok ADD popis varchar(10);
> UPDATE pok SET c2 = NULL, c1=c2, c3=(-c3+12)/c1 where c1 NOT NULL;
> update pok set c1=c2,c2=c1,c3=NULL where c1+2>1/cat+0.5 and not (c1=1 or 
> c2=2);"     32475 Segmentation fault      | ./sqlptest
> 
> 
> I'm a bit lost here. What is print.c used for ?
> 
>> You might also wish to update print.c to accomodate for
>> asc/desc (it's a one-line change near the end).
> 
> Did that, but not sure if correctly. Should I check for the existance of 
> orderDir before using it, i.e. should it rather be
> 
> if ( sqlpStmt->command == SQLP_SELECT ) {
>     if ( sqlpStmt->orderDir )
>        {
>         fprintf( stderr, "ORDER BY: %s %s\n", sqlpStmt->orderCol, 
> sqlpStmt->orderDir );
>        } else {
>         fprintf( stderr, "ORDER BY: %s\n", sqlpStmt->orderCol );
>        }
> 
> or is this not necessary ?
> 
> 
>>
>> And of course, after testing, this has to be documented :)
>>
> 
> Obviously... :-)
> 
> Moritz
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dbf.diff.tgz
Type: application/x-gtar
Size: 1853 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061009/96a55de3/dbf.diff.gtar
From mlennert at club.worldonline.be  Mon Oct  9 14:02:04 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Oct  9 14:01:43 2006
Subject: [GRASS-dev] gis.m in wingrass: using where clause in d.vect 
	causes error :can't read "_data(.gronsole.gronsole, 9,
	donecmd)": no such element in array
In-Reply-To: <17706.10826.18404.911170@cerise.gclements.plus.com>
References: <45267957.2020505@club.worldonline.be>	<20061008155945.57c29721.hamish_nospam@yahoo.com>	<42215.85.10.65.158.1160296222.squirrel@geog-pc40.ulb.ac.be>	<43559.85.10.65.158.1160296669.squirrel@geog-pc40.ulb.ac.be>	<452A095C.2050005@club.worldonline.be>
	<17706.10826.18404.911170@cerise.gclements.plus.com>
Message-ID: <452A3A3C.3060107@club.worldonline.be>

Glynn Clements wrote:
> Moritz Lennert wrote:
> 
>>>>>> Using a where clause in vector display in gis.m causes the following
>>>>>> error under WinGRASS. Any suggestions ?
>>>>>> (WinGRASS version 2006-09-17)
>>>>>>
>>>>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
>>>>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>>>>>> element in array
>>>>>>      while executing
>>>>>> "set donecmd $_data($path,$ci,donecmd)"
>>>>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1  IF you put the
>>>>> query in the "query cat values" box by mistake.
>>>> I am not near a windows box right now, but I am quite positive that this
>>>> is not the problem here. I entered the query in the where box, not the cat
>>>> box.
>>>>
>>>> But I'll make sure tomorrow.
>>> Actually I just managed to test (Qemu over NX, quite an experience ;-) ),
>>> and I can confirm that the problem is with the sql query box. So it is not
>>> the same problem as the one described by Hamish.
>> Huidae or Glynn, any ideas on this ?
> 
> 	# Actually run the program
> 	if { $mingw == "1" } {
> 		# shell scripts require sh.exe.
> 		set cmd [concat | sh -c '$cmd']
> 	} else {
> 		set cmd [concat | $cmd 2>@ stdout]
> 	}
> 
> If you want to use "sh -c ...", you have to escape any shell
> metacharacters, otherwise commands which happen to contain shell
> metacharacters (e.g. "<" or ">" in a SQL "WHERE" clause) won't work.
> 
> I've already explained this in the thread discussing these changes.

Found
http://grass.itc.it/pipermail/grass5/2006-September/025834.html

where you say

"The simplest solution to the issue of
metacharacters is to replace any occurrences of the single quote
character in arguments with "'\''" (quote, backslash, quote, quote)
and surround each argument with single quotes.

Even then, there might be issues due to the shell messing with the
environment, signal handling, process groups etc (as well as possible
Unix-compatibility "features"). Shells are very complex programs."

Not sure that I understand exactly what needs to be done and where.

Moritz

From mlennert at club.worldonline.be  Mon Oct  9 14:03:35 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Oct  9 14:03:13 2006
Subject: [GRASS-dev] no v.digit in wingrass
Message-ID: <452A3A97.2030509@club.worldonline.be>

Am I right in assuming that v.digit cannot run in wingrass because of 
the current need for a monitor to be run which is not possible in MS Win ?

So the only current option for MS Win users is to use QGIS ?

Moritz

From jachym.cepicky at centrum.cz  Mon Oct  9 15:29:16 2006
From: jachym.cepicky at centrum.cz (Jachym Cepicky)
Date: Mon Oct  9 15:29:22 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <17706.9269.774566.263774@cerise.gclements.plus.com>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
	<f8fe65c40610080839u77d65877xdbb8304cef393ffe@mail.gmail.com>
	<17706.9269.774566.263774@cerise.gclements.plus.com>
Message-ID: <20061009132916.GA31152@localdomain>

hi,

was this patch commited to cvs ?

thanks

jachym

On Mon, Oct 09, 2006 at 11:28:05AM +0100, Glynn Clements wrote:
> 
> Martin Landa wrote:
> 
> > trying to cleanup g.remove module I have prepared the patch. Is it OK
> > for you? Any comments welcomed...
> 
> Rather than hard-coding checks for specific entity types:
> 
> +	if (G_strcasecmp(list[n].alias, "rast") == 0 ) {
> +	    if ((mapset = G_find_cell2 (old, "")) == NULL) {
> +		G_warning(_("Raster map <%s> not found"), old);
> +		result = 1;
> +	    }
> +	}
> +	
> +	if (G_strcasecmp(list[n].alias, "rast3d") == 0 ) {
> +	    if ((mapset = G_find_grid3 (old, "")) == NULL) {
> +		G_warning(_("Raster 3d map <%s> not found"), old);
> +		result = 1;
> +	    }
> +	}
> 
> I would add a flag which is initially cleared for each entity (map
> etc) and set when an element is actually removed. A warning would be
> generated if the flag is still clear when all of the elements for an
> entity have been processed.
> 
> E.g.:
> 
> +	removed = 0;
>  	for (i = 0; i < list[n].nelem; i++) {
>  	    switch (G_remove (list[n].element[i], old))
>  	    {
>  	    case -1: 
> -	        G_warning (" %-*s %s", len, list[n].desc[i],_("COULD NOT REMOVE"));
> +	        G_warning ("%s: %s", list[n].desc[i],_("couldn't be removed"));
>  	        result = 1;
>  		break;
>  	    case  0: 
> -	        G_message (" %-*s %s", len, list[n].desc[i],_("MISSING"));
> +	        G_debug (1, "%s: %s", list[n].desc[i],_("missing"));
>  		break;
>  	    case 1:
> -	        G_message (" %-*s ", len, list[n].desc[i]);
> +	        G_debug (1, "%s: %s", list[n].desc[i],_("removed"));
> +	        removed = 1;
>  		break;
>  	    }
>  	}
> +
> +	if (!removed)
> +		G_warning ("%s: %s", list[n].desc[i],_("nothing removed"));
> 
> -- 
> Glynn Clements <glynn@gclements.plus.com>
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-- 
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
Department of Geoinformation Technologies 
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL:    http://mapserver.mendelu.cz
Tel.:   +420 545 134 514
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061009/e8b0d144/attachment-0001.bin
From jachym.cepicky at centrum.cz  Mon Oct  9 15:32:20 2006
From: jachym.cepicky at centrum.cz (Jachym Cepicky)
Date: Mon Oct  9 15:32:23 2006
Subject: [GRASS-dev] r.mapcalc and g.remove --v/q issues
In-Reply-To: <20061009010414.26e05b9a.hamish_nospam@yahoo.com>
References: <45279049.9030907@o2.pl>
	<17704.13469.442502.801590@cerise.gclements.plus.com>
	<4528D657.9080803@o2.pl>
	<20061009010414.26e05b9a.hamish_nospam@yahoo.com>
Message-ID: <20061009133220.GB31152@localdomain>

hallo,

On Mon, Oct 09, 2006 at 01:04:14AM +1300, Hamish wrote:
> -            verbose = MINLEVEL;
> +            verbose = MAXLEVEL;

I agree

> 
> ps -
> in verbose.c, is this test correct?
> 
> static int verbose;
> G_verbose() {
>  ..
>     /* verbose not defined -> get it from env. */
>     if ( !verbose ) {
>  ..
> }
> 
> so it gets read from GRASS_VERBOSE not only if its unset but also if
> it happens to be at MINLEVEL?
> 

no, sorry, this is not correct. as glyn writes, it should be initialized
to -1 and the test should look like 

    if ( verbose < 0 )

could you commit this changes, or should I?

thank you

jachym

-- 
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------   
OFFICE:                                     
Department of Geoinformation Technologies 
Zemedelska 3
613 00, Brno
Czech Republick
e-mail: xcepicky@node.mendelu.cz
URL:    http://mapserver.mendelu.cz
Tel.:   +420 545 134 514
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20061009/fa621126/attachment.bin
From grass-bugs at intevation.de  Mon Oct  9 16:29:30 2006
From: grass-bugs at intevation.de (Request Tracker)
Date: Mon Oct  9 16:29:32 2006
Subject: [GRASS-dev] [bug #5195] (grass) ps.map sets encoding to iso-8859-1
Message-ID: <20061009142930.818711006B8@lists.intevation.de>

this bug's URL: http://intevation.de/rt/webrt?serial_num=5195
-------------------------------------------------------------------------

Subject: ps.map sets encoding to iso-8859-1

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs_head_20060921

On line 92 of ps/ps.map/prolog.ps the encoding is set to ISOLatin1Encoding.

If I understand correctly (and some testing confirms this) this means that the instructions file for ps.map has to be encoded in iso-8859-1 (or similar) to work, i.e. to be able to print accented characters. If you are in a UTF-8 environment, ps.map creates a ps file which doesn't show correct accented characters be it in iso or in utf.

Is there any reason why ps.map hardcodes the encoding ? Is it possible to automatically use the users encoding ?

Moritz

-------------------------------------------- Managed by Request Tracker

From mlennert at club.worldonline.be  Mon Oct  9 16:34:47 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Oct  9 16:34:25 2006
Subject: [Fwd: [GRASS-dev] [bug #5195] (grass) ps.map sets encoding to
	iso-8859-1]
Message-ID: <452A5E07.1000005@club.worldonline.be>

Since the Gforge tracker is now operational, should bugs be reported there ?

Will these bugs still be sent to the dev list ?

Moritz

-------- Original Message --------
Subject: [GRASS-dev] [bug #5195] (grass) ps.map sets encoding to iso-8859-1
Date: Mon,  9 Oct 2006 16:29:30 +0200 (CEST)
From: Request Tracker <grass-bugs@intevation.de>
Reply-To: Request Tracker <grass-bugs@intevation.de>
To: grass-dev@grass.itc.it

this bug's URL: http://intevation.de/rt/webrt?serial_num=5195
-------------------------------------------------------------------------

Subject: ps.map sets encoding to iso-8859-1

Platform: GNU/Linux/x86
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: cvs_head_20060921

On line 92 of ps/ps.map/prolog.ps the encoding is set to ISOLatin1Encoding.

If I understand correctly (and some testing confirms this) this means 
that the instructions file for ps.map has to be encoded in iso-8859-1 
(or similar) to work, i.e. to be able to print accented characters. If 
you are in a UTF-8 environment, ps.map creates a ps file which doesn't 
show correct accented characters be it in iso or in utf.

Is there any reason why ps.map hardcodes the encoding ? Is it possible 
to automatically use the users encoding ?

Moritz

-------------------------------------------- Managed by Request Tracker

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

From michael.barton at asu.edu  Mon Oct  9 16:58:35 2006
From: michael.barton at asu.edu (Michael Barton)
Date: Mon Oct  9 16:58:39 2006
Subject: [GRASS-dev] Re: no v.digit in wingrass
In-Reply-To: <452A3A97.2030509@club.worldonline.be>
Message-ID: <C14FB1AB.F84E%michael.barton@asu.edu>

V.digit cannot run in wingrass because it requires interaction with an
xterminal--in this case to display GRASS vector data and to update vector
topology interactively.

This is an excellent example of why we need to move away from requiring any
particular display environment to do critical GRASS functions.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton



> From: Moritz Lennert <mlennert@club.worldonline.be>
> Date: Mon, 09 Oct 2006 14:03:35 +0200
> To: Grass Developers List <grass-dev@grass.itc.it>
> Cc: Huidae Cho <grass4u@gmail.com>, Michael Barton <michael.barton@asu.edu>,
> Glynn Clements <glynn@gclements.plus.com>
> Subject: no v.digit in wingrass
> 
> Am I right in assuming that v.digit cannot run in wingrass because of
> the current need for a monitor to be run which is not possible in MS Win ?
> 
> So the only current option for MS Win users is to use QGIS ?
> 
> Moritz

From cavallini at faunalia.it  Mon Oct  9 17:02:17 2006
From: cavallini at faunalia.it (Paolo Cavallini)
Date: Mon Oct  9 17:02:21 2006
Subject: [GRASS-dev] r.li: new version and tests
Message-ID: <452A6479.7060002@faunalia.it>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all.
A new version of r.li (0.2.6) is available at the usual site:
http://www.faunalia.it/download/r_li/
A bug preventing floating points calculations has been discovered and fixed.
First test on the comparison with r.le give very encouraging results:
numeric differences between the two programs are *very* small,
presumably due to rounding effects. A map of the differences is available:
http://www.faunalia.it/download/r_li/shannon.png is the resulting map
(Shannon index)
http://www.faunalia.it/download/r_li/diff.png is the map of the differences.
All the best.
pc
- --
Paolo Cavallini
email+jabber: cavallini@faunalia.it
www.faunalia.it
Piazza Garibaldi 5 - 56025 Pontedera (PI), Italy   Tel: (+39)348-3801953
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFKmR4/NedwLUzIr4RAvrSAKCZtOa0qZXOSVkk/umS+/5fE+MNQQCdHrr0
NaqQPAdP5+f1ftrm32tM+0Q=
=aTSp
-----END PGP SIGNATURE-----

From radim.blazek at gmail.com  Mon Oct  9 18:08:32 2006
From: radim.blazek at gmail.com (Radim Blazek)
Date: Mon Oct  9 18:08:36 2006
Subject: [GRASS-dev] v.kernel Vect_check_input_output_name
Message-ID: <340505ef0610090908l4aad8925i3b3430537413f0df@mail.gmail.com>

Hi,
v.kernel should not use Vect_check_input_output_name for output
because output is raster.

Radim

From mlennert at club.worldonline.be  Mon Oct  9 18:26:19 2006
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon Oct  9 18:25:57 2006
Subject: [GRASS-dev] Re: bug in Vect_cidx_find_next() ?
In-Reply-To: <340505ef0609290217yd6f0d80yd2e1adac1ca82f00@mail.gmail.com>
References: <451BDBA8.4090709@club.worldonline.be>	
	<340505ef0609281321y1a74b6b9s8d64d4250bd59f30@mail.gmail.com>	
	<451C4B26.4010102@club.wo