From rez at touchofmadness.com  Tue May  1 00:14:04 2007
From: rez at touchofmadness.com (Brad Douglas)
Date: Tue May  1 00:14:11 2007
Subject: [GRASSGUI] Re: [GRASS-dev] numeric-numpy-scipy for graphs?
In-Reply-To: <17966.20866.880716.138907@cerise.gclements.plus.com>
References: <17964.32012.691862.169314@cerise.gclements.plus.com>
	<C25216D5.21544%michael.barton@asu.edu>
	<20070424175011.4b5067df.hamish_nospam@yahoo.com>
	<17966.20866.880716.138907@cerise.gclements.plus.com>
Message-ID: <1177971244.21738.148.camel@dev64.localdomain>

On Tue, 2007-04-24 at 19:50 +0100, Glynn Clements wrote:
> Hamish wrote:
> 
> > > The one complication is changing window size. The GRASS command would
> > > need to be rerun and the graphic rendered. With the new PS driver, we
> > > might not be stuck with a rasterized version.
> > 
> > just to throw something else out there: What if we had a SVG driver?
> >   http://en.wikipedia.org/wiki/Svg
> 
> SVG is a viable alternative to PostScript.
> 
> As it's orientated towards video graphics rather than hardcopy, it
> provides some features which PostScript doesn't. OTOH, some of those
> features (e.g. translucency) can't be realised in hardcopy (other than
> by rasterising everything and printing the resulting image, which
> effectively means lower resolution).
> 
> My main concern with SVG is whether it is sufficiently mature.

Last I checked, PS is used by virtually every GIS company in existence.
I don't believe SVG is going to be any advantage over PS for those of us
who print posters, etc.  No reason to reinvent a perfectly functioning
wheel...we could use a few more PS enhancements (transparency
immediately comes to mind), however.

Most of us paid heavily for that PS support and extra memory on our
printer/plotters.  Might as well get some use out of them. ;-)


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

From dca.gis at gmail.com  Tue May  1 02:35:30 2007
From: dca.gis at gmail.com (Daniel Calvelo)
Date: Tue May  1 02:35:33 2007
Subject: [GRASS-dev] figuring out fonts - part 2
In-Reply-To: <17973.5547.383300.980452@cerise.gclements.plus.com>
References: <C25A2708.21743%michael.barton@asu.edu>
	<17973.5547.383300.980452@cerise.gclements.plus.com>
Message-ID: <1a486f560704301735j420384acmec65d5c8e4f6aef@mail.gmail.com>

There are some Free/Libre TT fonts out there, of which the most
remarkable is Bitstream Vera. Any of those could be distributed within
GRASS. That would cover the FreeType lib case. One of the lucidas may
be all right as X or t1.

Is stroke font the minimal font support in GRASS? Anything default
between stroke and TT?

Daniel.

On 4/29/07, Glynn Clements <glynn@gclements.plus.com> wrote:
>
> Michael Barton wrote:
>
> > It is a good thing that GRASS has a set of fonts that can be guaranteed to
> > be present, regardless of the system. These are the venerable stroke fonts.
> > But these fonts are ugly and hard to read. Romans just doesn?t stand out
> > well in a scale or legend, for example, unless against a white background
> > and even then it is not clear at a distance for presentations.
> >
> > So here is a question. Can GRASS ship with a better set of fonts? Can it
> > come with a minimal TrueType set, for example, that could be guaranteed
> > present regardless of the system? Or is this technically not realistically
> > feasible?
>
> Support for TrueType fonts requires the FreeType library, which is
> currently an optional dependency.
>
> That aside, most people will already have the Luxi font from the X.org
> packages.
>
> --
> Glynn Clements <glynn@gclements.plus.com>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
-- Daniel Calvelo Aros

From glynn at gclements.plus.com  Tue May  1 07:10:29 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue May  1 07:10:32 2007
Subject: [GRASS-dev] Re: [GRASS-user] Benchmarking Grass 4.3, 5.4, 6.0,
	6.2 raster commands
In-Reply-To: <2A41DE5D-FA9F-495E-9B39-57258C82B42C@unity.ncsu.edu>
References: <3.0.3.32.20070430152812.009de6b0@popin.ncl.ac.uk>
	<17974.12968.328085.755096@cerise.gclements.plus.com>
	<2A41DE5D-FA9F-495E-9B39-57258C82B42C@unity.ncsu.edu>
Message-ID: <17974.52165.463568.991859@cerise.gclements.plus.com>


Helena Mitasova wrote:

> does the null implementation affect also the runs with rasters that  
> have no nulls and there is no MASK present?

It affects any raster which has a null bitmap, even if no cells are
actually null.

> 10x faster is a huge difference - it may be worthwhile to find out
> whether it is true for integer maps without nulls and whether it
> is really nulls slowing it down so badly.

It's relatively easy to test the effect of the null bitmap:
delete/rename the cell_misc/<name>/null file. There will still be some
residual overhead due to the conversion of zeroes to nulls, but this
will determine the cost of the filesystem calls.

> There were many discussions about the null implementation and as  
> Glynn correctly
> points out the main driver for the current design was to sacrifice  
> the performance
> to preserve the backwards compatibility. Wishes of old users (many of  
> whom
> contributed funds to GRASS development) were given very high priority.

It's possible to embed nulls while retaining compatibility, but the
result is that most CELL maps will end up using 4 bytes per cell
(prior to RLE or zlib compression).

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

From glynn at gclements.plus.com  Tue May  1 07:18:20 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue May  1 07:18:27 2007
Subject: [GRASS-dev] figureing out fonts - part 3 correction
In-Reply-To: <C25B9C64.2EAAE%michael.barton@asu.edu>
References: <17974.17175.749807.221628@cerise.gclements.plus.com>
	<C25B9C64.2EAAE%michael.barton@asu.edu>
Message-ID: <17974.52636.3356.227119@cerise.gclements.plus.com>


Michael Barton wrote:

> Thanks for the ideas. To clarify, will the fonts be listed in $GRAS_FT_CAP
> such that I can just parse this?

The mkftcap script will generate a freetypecap file containing all
.ttf files found in its hard-coded list of directories. The user may
subsequently edit the file.

For binary distributions, the mkftcap script will need to be run on
the target system after installation, or the user will need to create
the file by other means.

Any fonts which are added after the freetypecap file is created won't
appear until the file is explicitly updated.

IOW, there can be fonts which are installed but which aren't listed in
the freetypecap file. This may be an explicit choice on the user's
part, or it may be an oversight. If you could guarantee that all fonts
were listed in that file, there wouldn't be any need to support
specifying fonts by an absolute path.

One reason why the freetypecap file may not list all available fonts
is that some users may have a lot of fonts, and don't want an
excessively-long list of options for any font= parameters.

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

From hamish_nospam at yahoo.com  Tue May  1 07:26:08 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue May  1 07:26:15 2007
Subject: [GRASS-dev] [grass-code R][386] GIS manager and d.rast.edit
In-Reply-To: <46362599.8050705@o2.pl>
References: <C25B510E.217A5%michael.barton@asu.edu>
	<46362599.8050705@o2.pl>
Message-ID: <20070501172608.55a9bec0.hamish_nospam@yahoo.com>

Maciej Sieczka wrote:
> Before you replied to this ticket I have deleted it, because it is a
> duplicate of an earlier ticket #385 [1].

is it possible to merge tickets, as it was in the old tracker?

(just wondering as I don't see how; this one was a pure dupe so deletion
was appropriate)


Hamish

From glynn at gclements.plus.com  Tue May  1 07:49:51 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue May  1 07:50:02 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <DEEB1AD1-6677-4E34-B8B7-568CC956D884@kyngchaos.com>
References: <17973.6027.501488.6826@cerise.gclements.plus.com>
	<C25A7ABA.2175A%michael.barton@asu.edu>
	<17973.14328.976484.737490@cerise.gclements.plus.com>
	<45498D53-739B-4CF9-83B5-AFC2ADE6935C@kyngchaos.com>
	<17973.43565.792862.529314@cerise.gclements.plus.com>
	<C3D9289B-E502-469C-8E9D-80CC7EF871DF@kyngchaos.com>
	<17974.14679.620262.783465@cerise.gclements.plus.com>
	<DEEB1AD1-6677-4E34-B8B7-568CC956D884@kyngchaos.com>
Message-ID: <17974.54527.625692.277043@cerise.gclements.plus.com>


William Kyngesburye wrote:

> >> - Maybe Michael's proposed font path env var could be used here?  For
> >> additional user font paths to search automatically.
> >
> > I can add "$@" to the list used by mkftcap, so other directories can
> > be passed as arguments. Environment variables are problematic when
> > directories contain spaces, but command-line arguments can be quoted.
> 
> If it uses a colon-separated list like other path env vars do, can't  
> it be split that way, and then each item quoted in the loop?  My  
> shell scripting isn't very good to know.

The shell's string processing facilities are actually pretty poor. 
Trying to do anything non-trivial gets ugly quite quickly.

> >> - since this is now in /tools and installed in etc/, that implies
> >> that mkftcap will get run automatically somehow?  From GUI?  Or some
> >> future script module?  On startup?
> >
> > At present, it gets run at build time; thereafter, it has to be run
> > manually. It could be run from a post-install script used by the
> > packaging system (.deb, .rpm, etc).
> >
> > It isn't intended to be run automatically during normal use.
> 
> What about at startup time?  Users may want to manage fonts in  
> between runs of GRASS, so the available fonts can change often.

Ultimately, the freetypecap file is meant to reflect user preference;
it isn't a cache of all fonts which are present on the system, which
is why R_font() also allows a complete path to be used in place of a
font name.

Users with many fonts may only want the most common ones to appear in
any option lists.

> >> - regenerating the freetypecap at runtime in the GRASS application
> >> folder is not a good thing on OSX (see my previous discussions about
> >> OSX apps and user preference/config/addon files).  There should be
> >> some way to have GRASS look for alternative external freetypecap
> >> files, for both generating the freetypecap file, and reading it to
> >> set the font.
> >
> > The code which reads the file already uses $GRASS_FT_CAP if that is
> > set.
> 
> I missed GRASS_FT_CAP - how recent is this?

$GRASS_FREETYPECAP was added to d.text.freetype on 2002/05/30, and it
still uses that name. It was added to d.font.freetype when freetypecap
support was added on 2004/10/28.

$GRASS_FT_CAP has been used since the FreeType support was merged with
the driver's existing font handling on on 2006/09/01.

Note that d.{text,font}.freetype are no longer compiled; they have
been replaced by scripts which call d.text.new and d.font
respectively. d.text.new and d.font both use R_font(), which uses the
driver's built-in FreeType support, so $GRASS_FREETYPECAP is no longer
relevant.

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

From hamish_nospam at yahoo.com  Tue May  1 08:00:03 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue May  1 08:00:10 2007
Subject: [GRASS-dev] figureing out fonts - part 3 correction
In-Reply-To: <C25B4C25.2179B%michael.barton@asu.edu>
References: <20070430201625.1ff65432.hamish_nospam@yahoo.com>
	<C25B4C25.2179B%michael.barton@asu.edu>
Message-ID: <20070501180003.3474b216.hamish_nospam@yahoo.com>

Michael Barton wrote:
> if uname -s can differentiate Debian from other systems, it's easy
> enough to make /usr/share/fonts/freetype as the initial directory for
> those systems.

No, it can't. It just gives "Linux" or "Darwin" or whatever.
(the OS kernel is distinct from the distribution (Linux vs GNU; Debian
can run using Hurd or *BSD instead of Linux))

Don't worry too much about accommodating special changes for Debian.
It's more a question of what's now commonly used industry-wide.


Hamish

From wolf+grass at bergenheim.net  Tue May  1 08:07:31 2007
From: wolf+grass at bergenheim.net (Wolf Bergenheim)
Date: Tue May  1 08:08:05 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <C25B9E96.2EAB5%michael.barton@asu.edu>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
Message-ID: <4636D923.4040306@bergenheim.net>

On 30.04.2007 23:24, Michael Barton wrote:
> Some of these probably won't display with GRASS's TrueType drivers.
> 
> Trying to find all the potentially useable fonts on all kinds of systems is
> indeed a laudable task--and clearly a complex one. My goal is somewhat more

Trying to find all fonts (within a configured font path) on a Linux
system is actually quite easy. Just run the command 'fc-list' If you
want the filenames and the families, you could run 'fc-list : file
family'. Note that this will list also fonts other then truetype fonts,
but that should be ok since at least freetype lib should be able to
display them. if you want to limit to truetype only you can grep for ttf
 ;) there is I think some way to specify it, but I haven't really
researched it. Using this list one could easily construct a freetypecap
file from this.

--Wolf

> modest. I just need to make it easier for people to find where their fonts
> are located so that they can manually pick one they want to use for a
> session default.
> 
> This is pretty easy for Mac and Windows--although recognizing that not all
> fonts will be in 'standard' locations. It is more complicated for Linux,
> where there are several 'standard' locations depending on flavor. What would
> further make this process more convenient is to be able to set a desired
> font path and desired default that will persist beyond each GUI or GRASS
> session.
> 
> Michael
> 
> 
> On 4/30/07 12:54 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:
> 
>> On Apr 30, 2007, at 1:50 PM, Michael Barton wrote:
>>
>>> Are any of the fonts normally in the /Library/Fonts directory of
>>> OSX NOT
>>> freetype? Would there be any problem with a non-freetype font
>>> sneaking into
>>> freetypecap beyond it simply not displaying?
>>>
>>> If the answer to these is generally negative, why not just grab all
>>> the
>>> fonts from /LibraryFonts (and maybe $HOME/Library/Fonts) for
>>> freetypecap and
>>> not worry about whether they have a .ttf extension or not.
>>>
>>> Michael
>> This is related to another font item that I hesitated to bring up
>> since the focus has been on TT fonts - postscript and opentype (which
>> are really just font packages for PS and TT) fonts.  Sure, assuming
>> all files are font files may be OK, and thus get all types of fonts
>> (PS and TT).  But with PS fonts, there are multiple files per font face.
>>
>> On OSX there is the bitmap/suitcase that has the pre-made bitmaps for
>> certain sizes and references to all the faces, and then each face has
>> its own PS font file.  You normally reference a suitcase font from
>> the suitcase file and a face index or name, not the PS file (though
>> FT may be able to do that also, I don't know).  And on other
>> platforms PS fonts are usually split into individual faces, but can
>> also have more than one file per face - pfb/pfa, afm and possibly
>> others.
>>
>> You would have to filter out the extras or you will get a mess of
>> duplicate or unusable fonts.
>>
>> One possibility would be to test each font file found with freetype
>> calls, but this might add more time to the startup than simply
>> listing files, and I don't know if it could be done from a script -
>> mkftcap might need to be a C prog.
>>
>> -----
>> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
>> http://www.kyngchaos.com/
>>
>> "Oh, look, I seem to have fallen down a deep, dark hole.  Now what
>> does that remind me of?  Ah, yes - life."
>>
>> - Marvin
>>
>>
> 
> __________________________________________
> 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 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-- 

<:3 )---- Wolf Bergenheim ----( 8:>

From michael.barton at asu.edu  Tue May  1 08:13:34 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue May  1 08:13:47 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <4636D923.4040306@bergenheim.net>
Message-ID: <C25C289E.2188F%michael.barton@asu.edu>

This is really useful. Thanks.

Michael


On 4/30/07 11:07 PM, "Wolf Bergenheim" <wolf+grass@bergenheim.net> wrote:

> Trying to find all fonts (within a configured font path) on a Linux
> system is actually quite easy. Just run the command 'fc-list' If you
> want the filenames and the families, you could run 'fc-list : file
> family'. Note that this will list also fonts other then truetype fonts,
> but that should be ok since at least freetype lib should be able to
> display them. if you want to limit to truetype only you can grep for ttf
>  ;) there is I think some way to specify it, but I haven't really
> researched it. Using this list one could easily construct a freetypecap
> file from this.
> 

__________________________________________
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 May  1 08:45:22 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue May  1 08:45:32 2007
Subject: [GRASS-dev] default vector point symbol
In-Reply-To: <C25B623C.217B8%michael.barton@asu.edu>
References: <C25B623C.217B8%michael.barton@asu.edu>
Message-ID: <20070501184522.00e9ec77.hamish_nospam@yahoo.com>

Michael Barton wrote:
> what do you all think about making a circle the default point icon
> rather than an X?

"o" is bad for centroids as a circle over a series small island makes
all of them look round. (circle is bigger than island)


"x" marks the spot.

we could make the "x" smaller (say size=3), but that's not a good size
for other icons.


for points I usually run my d.stations script as a shortcut to typing a
long d.vect line. (wiki addons)

In addition I have a "d.mark x y" script to put a marker on the xmon at
a given x,y, which is pretty handy, much easier than v.in.ascii+d.vect.
 (just added to addons)
examples:
  d.mark 65,30
  d.mark -m 595968,4918693


I repeat my plea to separate the GUI vector plotting controls into tabs,
4 different tools (pt, line, area, mixed vectors/advanced [current]), or
however. maybe have an "advanced" sub menu for all 3 primary feature
types.

To a new user the vector controls in GIS.m look like a 747 cockpit,
they are overwhelmed with obscure features they'll never use.


If you had three+ GUI vector control panels, points could default to
tiny circles and centroids could default to x's *independently*.


Hamish

From tutey at o2.pl  Tue May  1 09:13:40 2007
From: tutey at o2.pl (Maciej Sieczka)
Date: Tue May  1 09:13:43 2007
Subject: [GRASS-dev] merge tickets in GForge
In-Reply-To: <20070501172608.55a9bec0.hamish_nospam@yahoo.com>
References: <C25B510E.217A5%michael.barton@asu.edu>	<46362599.8050705@o2.pl>
	<20070501172608.55a9bec0.hamish_nospam@yahoo.com>
Message-ID: <4636E8A4.6010502@o2.pl>

Hamish wrote:
> Maciej Sieczka wrote:

>> Before you replied to this ticket I have deleted it, because it is a
>> duplicate of an earlier ticket #385 [1].

> is it possible to merge tickets, as it was in the old tracker?
> 
> (just wondering as I don't see how; this one was a pure dupe so deletion
> was appropriate)

At least I haven't seen a possibility to merge tickets in GForge.
Neither a way to "close as a duplicate of" while keeping the link
between the original and duplicate report (like in Bugzilla). Too bad.

Maciek

From hamish_nospam at yahoo.com  Tue May  1 09:17:55 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue May  1 09:18:09 2007
Subject: [GRASS-dev] figureing out fonts - part 3 correction
In-Reply-To: <17974.52636.3356.227119@cerise.gclements.plus.com>
References: <17974.17175.749807.221628@cerise.gclements.plus.com>
	<C25B9C64.2EAAE%michael.barton@asu.edu>
	<17974.52636.3356.227119@cerise.gclements.plus.com>
Message-ID: <20070501191755.008356a0.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> The mkftcap script will generate a freetypecap file containing all
> .ttf files found in its hard-coded list of directories. The user may
> subsequently edit the file.

patch attached, for your consideration.
(run without needing a fake mapset, add copyright and file header)

Can "^*" be added to promote a consistent non-romans default font (if
found)? eg. Helvetica, Vera, or something common (sans).

How well does it deal with spaces in font path names?


> For binary distributions, the mkftcap script will need to be run on
> the target system after installation, or the user will need to create
> the file by other means.

shall we add the running of the script to this part of lib/init/init.sh
  # First time user - GISRC is defined in the GRASS script
  if [ ! -f "$GISRC" ] ; then
    ...

and add a rescan button to Michael's new GUI default font picker tool?


> Any fonts which are added after the freetypecap file is created won't
> appear until the file is explicitly updated.

for this we could add a hint in the d.font help page to run
"$GISBASE/etc/mkftcap" from the GRASS prompt.

> IOW, there can be fonts which are installed but which aren't listed in
> the freetypecap file. This may be an explicit choice on the user's
> part, or it may be an oversight. If you could guarantee that all fonts
> were listed in that file, there wouldn't be any need to support
> specifying fonts by an absolute path.

so Michael's new GUI font picker tool could have three entries:

//////////////////
// <> stoke font [pulldown list of the usual suspects]
// <> (registered) TTF [pulldown list parsed from freetypecap] [Rescan]
// <> Browse filesystem for TTF file
//
// Selected font: [____]    [Set as Default]
/////////////////



Hamish
-------------- next part --------------
Index: tools/mkftcap/mkftcap
===================================================================
RCS file: /home/grass/grassrepository/grass6/tools/mkftcap/mkftcap,v
retrieving revision 1.2
diff -u -r1.2 mkftcap
--- tools/mkftcap/mkftcap	30 Apr 2007 19:35:13 -0000	1.2
+++ tools/mkftcap/mkftcap	1 May 2007 07:00:24 -0000
@@ -1,10 +1,24 @@
 #!/bin/sh
 
-if  [ -z "$GISBASE" ]
-then
-	echo "You must be in GRASS GIS to run this program" >&2
-	exit 1
-fi
+# CODE PROVENIENCE:
+#  ADD AUTHORSHIP AND COPYRIGHT INFO HERE
+#
+
+# header info
+cat << EOF
+# FreeType2 definition file
+# Generated on $HOSTNAME at `date`
+#
+# FORMAT:
+#	font:fontpath:charset[:color:size]:description
+#	*default_font:fontpath:charset[:color:size]:description
+#
+# NOTE:
+#	It does not allow spaces, tabs, and multiple lines in one font.
+#	description is never used.
+#	DO NOT ADD A DEFAULT FONT IN THE CVS VERSION. :-)
+#
+EOF
 
 for dir in /usr/lib/X11/fonts /usr/share/X11/fonts /usr/share/fonts \
     "$HOME/Library/Fonts" /Library/Fonts /System/Library/Fonts \
@@ -16,4 +30,3 @@
 	| sed 's/.ttf:/:/'
     fi
 done
-
From hamish_nospam at yahoo.com  Tue May  1 09:59:03 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue May  1 09:59:16 2007
Subject: [GRASS-dev] figureing out fonts - part 3 correction
In-Reply-To: <17973.43998.565549.610975@cerise.gclements.plus.com>
References: <C25A2827.21747%michael.barton@asu.edu>
	<20070430144156.2147dc7f.hamish_nospam@yahoo.com>
	<17973.43998.565549.610975@cerise.gclements.plus.com>
Message-ID: <20070501195903.3d966741.hamish_nospam@yahoo.com>

Michael:
> > > Further testing and looks like d.text DOES respect GRASS_FONT
> > > settings
> > > 
> > > This leaves only d.label

Hamish:
> > currently do_labels.c has:
> > 
> > #define STANDARD_FONT "romans"
> > ...
> > if (sscanf (text, "%*s %s", font) != 1
> > 	||  !strcmp (font, "standard"))
> >     strcpy (font, STANDARD_FONT);
> >
> > we could change that

Glynn:
> "standard" selects "romans" rather than the current font at module
> startup (i.e. that selected by d.font). In that regard, the
> corresponding fix would be e.g.:
> 
> 	const char *std_font;
> 	std_font = getenv("GRASS_FT_FONT");
> 	if (!std_font)
> 		std_font = getenv("GRASS_FONT");
> 	if (!std_font)
> 		std_font = "romans";

done in cvs. (for GRASS_FONT only)

d.labels still won't respect d.font, but if the font changes there is no
way to know what it started as for the next font-less label, so I'm not
sure it would be a good idea to try / have it change the default font
part-way through.


> We should probably kill one of GRASS_FONT/GRASS_FT_FONT now that there
> are no longer separate stroke/freetype fonts.

GRASS_FT_FONT seems like the obvious choice for removal as it is now a
subset of GRASS_FONT, but not the other way around.


Hamish

From hamish_nospam at yahoo.com  Tue May  1 10:15:01 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue May  1 10:15:07 2007
Subject: [GRASS-dev] [bug #5499] (grass) bash scripts starting with
	#!/bin/sh
In-Reply-To: <20070430113423.E22401006AB@lists.intevation.de>
References: <20070430113423.E22401006AB@lists.intevation.de>
Message-ID: <20070501201501.0173a79c.hamish_nospam@yahoo.com>

Maciek Sieczka via RT wrote:
> > In current 6.3 CVS there are several instances of "echo -e", which
> > is a bashism. In dash "echo -e" will just print '-e' string.
> 
> > lib/gis/Makefile:       echo -e "#include <stdlib.h>\n#include
> > <fcntl.h>\n#undef _fmode\nint _fmode = _O_BINARY;" >
> > $(OBJDIR)/fmode.c

left to someone else to fix. (I'm not big on Makefile fu)

> > lib/init/grass-run.src:   echo -e "\033]0;${TITLE}\007\c"
> > lib/init/grass-run.src:   echo -e "\r"
> 
> These two instances make the grass-run.sh affected as well. "-e" is a
> bashism. Since grass-run.sh has a "#!/bin/sh" shebang, even in bash in
> runs in a POSIX shell compliant, thus prints spurious "-e"'s into the
> terminal.

fixed in CVS.


Hamish

From glynn at gclements.plus.com  Tue May  1 10:44:17 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue May  1 10:44:24 2007
Subject: [GRASS-dev] figuring out fonts - part 2
In-Reply-To: <1a486f560704301735j420384acmec65d5c8e4f6aef@mail.gmail.com>
References: <C25A2708.21743%michael.barton@asu.edu>
	<17973.5547.383300.980452@cerise.gclements.plus.com>
	<1a486f560704301735j420384acmec65d5c8e4f6aef@mail.gmail.com>
Message-ID: <17974.64993.340639.237951@cerise.gclements.plus.com>


Daniel Calvelo wrote:

> There are some Free/Libre TT fonts out there, of which the most
> remarkable is Bitstream Vera. Any of those could be distributed within
> GRASS. That would cover the FreeType lib case. One of the lucidas may
> be all right as X or t1.

I don't think that we should be bundling fonts which most users will
already have (Luxi and Vera are both pretty common).

> Is stroke font the minimal font support in GRASS? Anything default
> between stroke and TT?

The default font is the "romans" stroke font. The stroke fonts will
always be available; TrueType fonts can only be used if GRASS was
built with FreeType support.

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

From hamish_nospam at yahoo.com  Tue May  1 10:47:28 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Tue May  1 10:47:33 2007
Subject: [GRASS-dev] [grass-code R][386] GIS manager and d.rast.edit
In-Reply-To: <20070430091123.151CE19F5FEA@pyrosoma.intevation.org>
References: <20070430091123.151CE19F5FEA@pyrosoma.intevation.org>
Message-ID: <20070501204728.020e7932.hamish_nospam@yahoo.com>

[fwd from tracker]
http://wald.intevation.org/tracker/?func=detail&atid=188&aid=386

> code R item #386, was opened at 30/04/2007 11:11
> Summary: GIS manager and d.rast.edit 
..
> In Grass 6.2.1GIS Manager the menu " Edit category values of
> individual cells for displayed raster map " ignores the active monitor
> and always open a new monitor, white, without toolbar, and without any
> reaction to the mouse buttons.

GUI menu updated in 6.2 cvs to grey-out the d.rast.edit entry as it
won't work:

"guarantee_xmon; term d.rast.edit" needs a d.rast call in between. We
could write a wrapper script for this, but it's ugly (see discussions
about d.path_wrapper.sh), especially when you consider the zooming
problems.


d.rast.edit will still work from the command line, with advice:

d.mon x0
d.rast mapname
d.zoom  #very far in
d.rast.edit


(it may haved worked onceuponatime from d.m, but not with guarantee_xmon)


Hamish

From glynn at gclements.plus.com  Tue May  1 11:05:15 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue May  1 11:05:21 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <4636D923.4040306@bergenheim.net>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
Message-ID: <17975.715.470421.874125@cerise.gclements.plus.com>


Wolf Bergenheim wrote:

> > Some of these probably won't display with GRASS's TrueType drivers.
> > 
> > Trying to find all the potentially useable fonts on all kinds of systems is
> > indeed a laudable task--and clearly a complex one. My goal is somewhat more
> 
> Trying to find all fonts (within a configured font path) on a Linux
> system is actually quite easy. Just run the command 'fc-list'

Part of fontconfig. Although that's a fairly common package, it isn't
guaranteed to be installed, particularly on servers.

It probably won't be present on Windows or MacOSX unless you have a
fair amount of Linux compatibility stuff installed. I have several
native GTK+ apps on my Windows box, but no native fc-list. I have a
Cygwin fc-list, although that fails to list the Windows TTF fonts.

But, given that we're trying for a best-guess, there's no harm in
using it if it's present, so long as we don't rely upon it to the
exclusion of all other options.

> If you
> want the filenames and the families, you could run 'fc-list : file
> family'. Note that this will list also fonts other then truetype fonts,
> but that should be ok since at least freetype lib should be able to
> display them. if you want to limit to truetype only you can grep for ttf
>  ;) there is I think some way to specify it, but I haven't really
> researched it. Using this list one could easily construct a freetypecap
> file from this.

It appears that you can e.g. "fc-list :outline file" to only list
outline fonts. That eliminates the PCF fonts (X11 bitmap fonts),
although it still picks up the PFA/PFB files from my Ghostscript
installation.

Unfortunately, the "rasterizer" property cannot be used or output from
within fc-list; I'm guessing that this is only meaningful if you have
initialised the font for rendering.

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

From glynn at gclements.plus.com  Tue May  1 11:22:54 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue May  1 11:22:57 2007
Subject: [GRASS-dev] figureing out fonts - part 3 correction
In-Reply-To: <20070501191755.008356a0.hamish_nospam@yahoo.com>
References: <17974.17175.749807.221628@cerise.gclements.plus.com>
	<C25B9C64.2EAAE%michael.barton@asu.edu>
	<17974.52636.3356.227119@cerise.gclements.plus.com>
	<20070501191755.008356a0.hamish_nospam@yahoo.com>
Message-ID: <17975.1774.694550.795776@cerise.gclements.plus.com>


Hamish wrote:

> > The mkftcap script will generate a freetypecap file containing all
> > .ttf files found in its hard-coded list of directories. The user may
> > subsequently edit the file.
> 
> patch attached, for your consideration.
> (run without needing a fake mapset, add copyright and file header)

The $GISBASE test was needed when it wrote to
$GISBASE/etc/freetypecap, but is no longer required.

> Can "^*" be added to promote a consistent non-romans default font (if
> found)? eg. Helvetica, Vera, or something common (sans).

I would rather leave it to the user to set GRASS_FONT in their
~/.grass.bashrc etc.

> How well does it deal with spaces in font path names?

It seems to work okay. Certainly, it handles spaces in the filenames;
I don't have any fonts in directories which have spaces.

> > For binary distributions, the mkftcap script will need to be run on
> > the target system after installation, or the user will need to create
> > the file by other means.
> 
> shall we add the running of the script to this part of lib/init/init.sh
>   # First time user - GISRC is defined in the GRASS script
>   if [ ! -f "$GISRC" ] ; then
>     ...
> 
> and add a rescan button to Michael's new GUI default font picker tool?

The user may not be able to modify the system-wide freetypecap file
due to filesystem permissions.

The "right" place to generate the global freetypecap file is either at
build time (when building from source) or from a post-install script
(when installing a binary package).

Also, I consider the freetypecap file to be a configuration file. 
Auto-generation is useful for a quick start, but once the file exists,
it should only be modified by the user.

> > Any fonts which are added after the freetypecap file is created won't
> > appear until the file is explicitly updated.
> 
> for this we could add a hint in the d.font help page to run
> "$GISBASE/etc/mkftcap" from the GRASS prompt.

It's actually in the scripts directory at the moment.

> > IOW, there can be fonts which are installed but which aren't listed in
> > the freetypecap file. This may be an explicit choice on the user's
> > part, or it may be an oversight. If you could guarantee that all fonts
> > were listed in that file, there wouldn't be any need to support
> > specifying fonts by an absolute path.
> 
> so Michael's new GUI font picker tool could have three entries:
> 
> //////////////////
> // <> stoke font [pulldown list of the usual suspects]
> // <> (registered) TTF [pulldown list parsed from freetypecap] [Rescan]
> // <> Browse filesystem for TTF file
> //
> // Selected font: [____]    [Set as Default]
> /////////////////

Sounds reasonable.

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

From glynn at gclements.plus.com  Tue May  1 11:28:37 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue May  1 11:28:40 2007
Subject: [GRASS-dev] figureing out fonts - part 3 correction
In-Reply-To: <20070501195903.3d966741.hamish_nospam@yahoo.com>
References: <C25A2827.21747%michael.barton@asu.edu>
	<20070430144156.2147dc7f.hamish_nospam@yahoo.com>
	<17973.43998.565549.610975@cerise.gclements.plus.com>
	<20070501195903.3d966741.hamish_nospam@yahoo.com>
Message-ID: <17975.2117.243026.569650@cerise.gclements.plus.com>


Hamish wrote:

> > We should probably kill one of GRASS_FONT/GRASS_FT_FONT now that there
> > are no longer separate stroke/freetype fonts.
> 
> GRASS_FT_FONT seems like the obvious choice for removal as it is now a
> subset of GRASS_FONT, but not the other way around.

In terms of implementation, they both do exactly the same thing:

lib/raster/loc_io.c:

	const char *ftfont = getenv("GRASS_FT_FONT");
	...
	const char *font = getenv("GRASS_FONT");
	...
	if (ftfont)
		R_font(ftfont);
	else if (font)
		R_font(font);
	else
		R_font("romans");

display/d.mon/pgms/select.c:

	const char *ftfont = getenv("GRASS_FT_FONT");
	...
	const char *font = getenv("GRASS_FONT");
	...
	R_font((ftfont ? ftfont : (font ? font : "romans")));

R_font() gets passed the value of whichever variable is defined; using
GRASS_FT_FONT=romans would work. OTOH, the _FT_ is misleading, so that
one should probably go.

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

From glynn at gclements.plus.com  Tue May  1 11:33:23 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Tue May  1 11:33:33 2007
Subject: [GRASS-dev] [bug #5499] (grass) bash scripts starting with
	#!/bin/sh
In-Reply-To: <20070430113423.E22401006AB@lists.intevation.de>
References: <20070430113423.E22401006AB@lists.intevation.de>
Message-ID: <17975.2403.288208.341332@cerise.gclements.plus.com>


Maciek Sieczka via RT wrote:

> > In current 6.3 CVS there are several instances of "echo -e", which is a
> > bashism. In dash "echo -e" will just print '-e' string.
> 
> > lib/gis/Makefile:       echo -e "#include <stdlib.h>\n#include
> > <fcntl.h>\n#undef _fmode\nint _fmode = _O_BINARY;" > $(OBJDIR)/fmode.c

I suggest putting the code into e.g. fmode.dat then using:

	cat fmode.dat > $(OBJDIR)/fmode.c

It can't be a normal .c file, as the default rules automatically
compile all .c files and link the resulting objects into the library.

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

From grass-bugs at intevation.de  Tue May  1 12:14:22 2007
From: grass-bugs at intevation.de (Markus Neteler via RT)
Date: Tue May  1 12:14:23 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
Message-ID: <20070501101422.93F7F1006C7@lists.intevation.de>

https://intevation.de/rt/webrt?serial_num=2793

Apparently Vect_point_on_line() lacks support for side offset. Indeed, it
doesn't even have such a parameter.

We can now either remove all the side_offset stuff from the manual page or
convince a developer to expand Vect_point_on_line(). The functions used in
v.buffer/v.parallel might be helpful in this regard.

Markus

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

From R.A.Sanderson at newcastle.ac.uk  Tue May  1 10:58:34 2007
From: R.A.Sanderson at newcastle.ac.uk (Roy Sanderson)
Date: Tue May  1 12:27:58 2007
Subject: [GRASS-dev] Re: [GRASS-user] Benchmarking Grass 4.3, 5.4,
	6.0,6.2 raster commands
In-Reply-To: <17974.52165.463568.991859@cerise.gclements.plus.com>
References: <2A41DE5D-FA9F-495E-9B39-57258C82B42C@unity.ncsu.edu>
	<3.0.3.32.20070430152812.009de6b0@popin.ncl.ac.uk>
	<17974.12968.328085.755096@cerise.gclements.plus.com>
	<2A41DE5D-FA9F-495E-9B39-57258C82B42C@unity.ncsu.edu>
Message-ID: <3.0.3.32.20070501085834.009fb360@popin.ncl.ac.uk>

Hello Again

Thanks for the various piecies of feedback - I've tried removing the null
file (and there isn't a MASK), and unfortunately it hasn't made much
difference.

Having done some very rough benchmarking, based on a simple r.stats command
on a much smaller map than our user was struggling with, figures are:

Grass 4.3 - 10 seconds
Grass 5.4 - 67 seconds
Grass 6.2 - 74 seconds

Given that this is being run across an NFS network, the figures are only
approximate, but it looks as though the performance hit came from the
switch from Grass 4.3 to 5.4.  Oddly enough, even the d.rast commands seem
faster in Grass 4 (though that may simply be because the no. of colours
used in the monitor is lower).

Best wishes
Roy

At 06:10 01/05/07 +0100, Glynn Clements wrote:
>
>Helena Mitasova wrote:
>
>> does the null implementation affect also the runs with rasters that  
>> have no nulls and there is no MASK present?
>
>It affects any raster which has a null bitmap, even if no cells are
>actually null.
>
>> 10x faster is a huge difference - it may be worthwhile to find out
>> whether it is true for integer maps without nulls and whether it
>> is really nulls slowing it down so badly.
>
>It's relatively easy to test the effect of the null bitmap:
>delete/rename the cell_misc/<name>/null file. There will still be some
>residual overhead due to the conversion of zeroes to nulls, but this
>will determine the cost of the filesystem calls.
>
>> There were many discussions about the null implementation and as  
>> Glynn correctly
>> points out the main driver for the current design was to sacrifice  
>> the performance
>> to preserve the backwards compatibility. Wishes of old users (many of  
>> whom
>> contributed funds to GRASS development) were given very high priority.
>
>It's possible to embed nulls while retaining compatibility, but the
>result is that most CELL maps will end up using 4 bytes per cell
>(prior to RLE or zlib compression).
>
>-- 
>Glynn Clements <glynn@gclements.plus.com>
>
>

From neteler at itc.it  Tue May  1 12:37:15 2007
From: neteler at itc.it (Markus Neteler)
Date: Tue May  1 12:37:16 2007
Subject: [GRASS-dev] Streams extraction from streams map
Message-ID: <20070501103714.GA19013@bartok.itc.it>

Hi,

I have a network of streams (say, Spearfish or better the new
NC data set at http://mpa.itc.it/grasstutor/data_menu3rd.phtml )
and want to extract a single stream system. Names are lacking,
is there any trick to extract topologically connected lines
into a new map?

Markus

From michael.barton at asu.edu  Tue May  1 16:24:11 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue May  1 16:24:32 2007
Subject: [GRASS-dev] default vector point symbol
In-Reply-To: <20070501184522.00e9ec77.hamish_nospam@yahoo.com>
Message-ID: <C25C9B9B.218A0%michael.barton@asu.edu>




On 4/30/07 11:45 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:

> Michael Barton wrote:
>> what do you all think about making a circle the default point icon
>> rather than an X?
> 
> "o" is bad for centroids as a circle over a series small island makes
> all of them look round. (circle is bigger than island)
> 
> 
> "x" marks the spot.
> 
> we could make the "x" smaller (say size=3), but that's not a good size
> for other icons.
> 
> 
> for points I usually run my d.stations script as a shortcut to typing a
> long d.vect line. (wiki addons)
> 
> In addition I have a "d.mark x y" script to put a marker on the xmon at
> a given x,y, which is pretty handy, much easier than v.in.ascii+d.vect.
>  (just added to addons)
> examples:
>   d.mark 65,30
>   d.mark -m 595968,4918693
> 

This sounds real handy. Is it on the WIKI? Maybe we should add it to the
main GRASS distribution. It is an easy update to make it respond to a mouse
click in the GUI

> 
> I repeat my plea to separate the GUI vector plotting controls into tabs,
> 4 different tools (pt, line, area, mixed vectors/advanced [current]), or
> however. maybe have an "advanced" sub menu for all 3 primary feature
> types.

This is the way it is working in wxPython currently.

> 
> To a new user the vector controls in GIS.m look like a 747 cockpit,
> they are overwhelmed with obscure features they'll never use.

I agree. Maybe if I have some time as the semester winds down I can look
into a notebook for TclTk too.

Michael

> 
> 
> If you had three+ GUI vector control panels, points could default to
> tiny circles and centroids could default to x's *independently*.
> 
> 
> Hamish

__________________________________________
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 woklist at kyngchaos.com  Tue May  1 16:28:30 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Tue May  1 16:28:39 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17975.715.470421.874125@cerise.gclements.plus.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
Message-ID: <789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>

On May 1, 2007, at 4:05 AM, Glynn Clements wrote:

> Wolf Bergenheim wrote:
>
>> Trying to find all fonts (within a configured font path) on a Linux
>> system is actually quite easy. Just run the command 'fc-list'
>
> Part of fontconfig. Although that's a fairly common package, it isn't
> guaranteed to be installed, particularly on servers.
>
> It probably won't be present on Windows or MacOSX unless you have a
> fair amount of Linux compatibility stuff installed. I have several
> native GTK+ apps on my Windows box, but no native fc-list. I have a
> Cygwin fc-list, although that fails to list the Windows TTF fonts.
>
Fontconfig is included in the OSX X11 package, and searches the  
standard OSX font locations.  Though this is an optional package for  
OSX, it's still required for the current tcltk GUI.  I do know that  
at one time fontconfig was NOT included in the OSX X11, but I think  
it's in OSX 10.3.9 X11.  I realize we want to reduce dependecy on X11  
in OSX, but this looks like a useful tool.

I just thought of another possibility for OSX - AppleScript.  AS can  
run from the CLI.  The Font Book application in OSX (which handles  
font installation) can return font info for installed fonts,  
including font paths.  I can look into that.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"We are at war with them. Neither in hatred nor revenge and with no  
particular pleasure I shall kill every ___ I can until the war is  
over. That is my duty."

"Don't you even hate 'em?"

"What good would it do if I did? If all the many millions of people  
of the allied nations devoted an entire year exclusively to hating  
the ____ it wouldn't kill one ___ nor shorten the war one day."

<Ha, ha> "And it might give 'em all stomach ulcers."

- Tarzan, on war

From michael.barton at asu.edu  Tue May  1 16:53:26 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue May  1 16:53:37 2007
Subject: [GRASS-dev] [grass-code R][386] GIS manager and d.rast.edit
In-Reply-To: <20070501204728.020e7932.hamish_nospam@yahoo.com>
Message-ID: <C25CA276.218A6%michael.barton@asu.edu>

Hamish,

Thanks. This is a good solution. It just doesn't work from the GUI menu (and
was never intended to work that way). It's been awhile since I've worked
with d.rast.edit in the old form and so couldn't remember how problematic it
was with the TclTk GUI.

MIchael


On 5/1/07 1:47 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

> [fwd from tracker]
> http://wald.intevation.org/tracker/?func=detail&atid=188&aid=386
> 
>> code R item #386, was opened at 30/04/2007 11:11
>> Summary: GIS manager and d.rast.edit
> ..
>> In Grass 6.2.1GIS Manager the menu " Edit category values of
>> individual cells for displayed raster map " ignores the active monitor
>> and always open a new monitor, white, without toolbar, and without any
>> reaction to the mouse buttons.
> 
> GUI menu updated in 6.2 cvs to grey-out the d.rast.edit entry as it
> won't work:
> 
> "guarantee_xmon; term d.rast.edit" needs a d.rast call in between. We
> could write a wrapper script for this, but it's ugly (see discussions
> about d.path_wrapper.sh), especially when you consider the zooming
> problems.
> 
> 
> d.rast.edit will still work from the command line, with advice:
> 
> d.mon x0
> d.rast mapname
> d.zoom  #very far in
> d.rast.edit
> 
> 
> (it may haved worked onceuponatime from d.m, but not with guarantee_xmon)
> 
> 
> Hamish
> 
> 

__________________________________________
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 neteler at itc.it  Tue May  1 17:25:03 2007
From: neteler at itc.it (Markus Neteler)
Date: Tue May  1 17:25:06 2007
Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar?
Message-ID: <20070501152503.GB19013@bartok.itc.it>

Hi,

can we safely change v.univar.sh -> v.univar in d.vect.thematic?
This might speed up calculations...

Markus

From soerengebbert at gmx.de  Tue May  1 21:44:16 2007
From: soerengebbert at gmx.de (=?ISO-8859-15?Q?S=F6ren_Gebbert?=)
Date: Tue May  1 21:44:44 2007
Subject: [GRASS-dev] Licence problems in gmath LU decomposition
Message-ID: <46379890.4000700@gmx.de>

Dear developers,
i just noticed that the code of G_ludcmp() is an exact copy of
the numerical recipes algorithm. :(
We need to replace it.

I have implemented a new simple parallel LU decomposition in the gpde library (since several months in CVS).
But this algorithm lacks the ability of pivoting (it would be very hard to implement this as a parallel version).
So it is not usable within the rst library in grass and maybe others? This is a big problem.

The rst library creates linear equation systems with a zero entry in the diagonal matrix. All the
algorithms implemented in gpde library to solve linear equation systems are not able to
handle this (LU, Gauss, jacobi, SOR) except the bicgstab algorithm.
The bicgstab is a state of the art iterative linear equation solver algorithm for non-symmetric matrices.
But it will fail on very bad conditioned matrices, so it is not the best choice if a direct solve can be used.

I have created a very simple patch for the rst library (regular spline with tension) to use the bicgstab
algorithm form the gpde lib instead of G_ludcmp(). Just for testing.
It seems to work and it is not slower than G_ludcmp(). The patch is attached.
It would be better if the rst lib would create matrices with a better condition and without
zero entries at the diagonal matrix. Then we could use other gpde algorithms than bicgstab.

The main question is, what to do with G_ludcmp()? There is a free implementation of the LU
decomposition algorithm with pivoting in the GSL library, which we can use. Or we use the bicgstab
algorithm in cases where the simple LU algorithm from the gpde library will fail?

Any suggestions are welcome
Best regards
Soeren
-------------- next part --------------
Index: interp_float/matrix.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/rst/interp_float/matrix.c,v
retrieving revision 2.3
diff -u -u -r2.3 matrix.c
--- interp_float/matrix.c	29 Mar 2006 20:05:08 -0000	2.3
+++ interp_float/matrix.c	1 May 2007 19:41:01 -0000
@@ -154,12 +154,13 @@
         matrix[i][j] = A[m];
       }
     }
-
-    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) { /* find the inverse of the mat
-rix */
+/*
+    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) { 
+ 
       fprintf(stderr,"G_ludcmp() failed! n=%d\n",n_points);
       return -1;
     }
+    */
 /*
     G_free_vector(A);
 */
Index: interp_float/segmen2d.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/rst/interp_float/segmen2d.c,v
retrieving revision 2.5
diff -u -u -r2.5 segmen2d.c
--- interp_float/segmen2d.c	9 Feb 2006 03:08:58 -0000	2.5
+++ interp_float/segmen2d.c	1 May 2007 19:41:02 -0000
@@ -8,6 +8,7 @@
 #include <math.h>
 #include <grass/gis.h>
 #include <grass/glocale.h>
+#include <grass/N_pde.h>
 
 #include <grass/interpf.h>
 
@@ -263,7 +264,30 @@
         for (i = 0; i < data->n_points; i++)
           b[i+1] = data->points[i].z;
         b[0] = 0.;
-        G_lubksb(matrix,data->n_points+1,indx,b);
+
+	/*create the gpde lineare equation system and transfer the data*/
+	N_les * les  = N_alloc_les(data->n_points + 1, N_NORMAL_LES);
+	for(i = 0; i < data->n_points + 1; i++) {
+	  les->b[i] = b[i];
+	  for(j = 0; j < data->n_points + 1; j++) {
+		les->A[i][j] = matrix[i][j];
+	  }
+	}
+	/*solve it with the bicgstab algorithm*/
+	N_solver_bicgstab(les, 100000, 0.000000001);
+	double d;
+
+	/* for testing */
+	//G_ludcmp(matrix,data->n_points + 1,indx,&d);
+        //G_lubksb(matrix,data->n_points + 1,indx,b);
+
+	/*transfer the result*/
+	for(i = 0; i < data->n_points + 1; i++) 
+	b[i] = les->x[i];
+
+	/*release memory*/
+	N_free_les(les);
+
         params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
         } else if (segtest == 1)
         {
@@ -273,7 +297,6 @@
                   G_lubksb(matrix,data->n_points,indx,b);
                   params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
         }
-
         } /*cv loop */
         
 	if(!params->cv)
From hmitaso at unity.ncsu.edu  Tue May  1 23:36:42 2007
From: hmitaso at unity.ncsu.edu (Helena Mitasova)
Date: Tue May  1 23:36:43 2007
Subject: [GRASS-dev] Licence problems in gmath LU decomposition
In-Reply-To: <46379890.4000700@gmx.de>
References: <46379890.4000700@gmx.de>
Message-ID: <C81A9010-DC02-41A5-A52F-99884BBDBC89@unity.ncsu.edu>

Soeren -

by default rst does not have 0 on the diagonal - it has the value of  
the smoothing parameter
which is 0.1 or 0.01 (I would have to check, I just found it is  
missing in the man page).
This keeps the solution stable.
It runs with zero smoothing too if you have sufficiently high tension,
but it gets unstable for small tension and zero smoothing. That is  
why the defaults and
overall internal adjustments of the parameters are set to avoid it  
and the program
gives warnings about the overshoots. There is more here (see e.g.  
fig. 2)
http://skagit.meas.ncsu.edu/~helena/gmslab/papers/IEEEGRSL2005.pdf

But the G_ludcmp() needs to be replaced - it was discussed long time  
ago and
I somehow thought that it was done and the function does not include  
the num. recipes
program.

Thanks for the patch, I planned to look at the solver because of the  
performance issues,
so this helps, although the strange performance behavior since  
somewhere GRASS5*
may be more related to recently reported stunning degradation of  
performance for
rasters between 4.* and 5.* than in lineq. solver. I always though it  
is slower due to the
floating point introduction and did not realize that it affects  
integer rasters too,

Helena


-------------- next part --------------
A non-text attachment was scrubbed...
Name: LINEQS.c
Type: application/octet-stream
Size: 3030 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070501/ad796268/LINEQS-0001.obj
-------------- next part --------------


Helena Mitasova
Dept. of Marine, Earth and Atm. Sciences
1125 Jordan Hall, NCSU Box 8208,
Raleigh NC 27695
http://skagit.meas.ncsu.edu/~helena/



On May 1, 2007, at 3:44 PM, S?ren Gebbert wrote:

> Dear developers,
> i just noticed that the code of  is an exact copy of
> the numerical recipes algorithm. :(
> We need to replace it.
>
> I have implemented a new simple parallel LU decomposition in the  
> gpde library (since several months in CVS).
> But this algorithm lacks the ability of pivoting (it would be very  
> hard to implement this as a parallel version).
> So it is not usable within the rst library in grass and maybe  
> others? This is a big problem.
>
> The rst library creates linear equation systems with a zero entry  
> in the diagonal matrix. All the
> algorithms implemented in gpde library to solve linear equation  
> systems are not able to
> handle this (LU, Gauss, jacobi, SOR) except the bicgstab algorithm.
> The bicgstab is a state of the art iterative linear equation solver  
> algorithm for non-symmetric matrices.
> But it will fail on very bad conditioned matrices, so it is not the  
> best choice if a direct solve can be used.
>
> I have created a very simple patch for the rst library (regular  
> spline with tension) to use the bicgstab
> algorithm form the gpde lib instead of G_ludcmp(). Just for testing.
> It seems to work and it is not slower than G_ludcmp(). The patch is  
> attached.
> It would be better if the rst lib would create matrices with a  
> better condition and without
> zero entries at the diagonal matrix. Then we could use other gpde  
> algorithms than bicgstab.
>
> The main question is, what to do with G_ludcmp()? There is a free  
> implementation of the LU
> decomposition algorithm with pivoting in the GSL library, which we  
> can use. Or we use the bicgstab
> algorithm in cases where the simple LU algorithm from the gpde  
> library will fail?
>
> Any suggestions are welcome
> Best regards
> Soeren
> Index: interp_float/matrix.c
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/lib/rst/interp_float/ 
> matrix.c,v
> retrieving revision 2.3
> diff -u -u -r2.3 matrix.c
> --- interp_float/matrix.c	29 Mar 2006 20:05:08 -0000	2.3
> +++ interp_float/matrix.c	1 May 2007 19:41:01 -0000
> @@ -154,12 +154,13 @@
>          matrix[i][j] = A[m];
>        }
>      }
> -
> -    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) { /* find the  
> inverse of the mat
> -rix */
> +/*
> +    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) {
> +
>        fprintf(stderr,"G_ludcmp() failed! n=%d\n",n_points);
>        return -1;
>      }
> +    */
>  /*
>      G_free_vector(A);
>  */
> Index: interp_float/segmen2d.c
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/lib/rst/interp_float/ 
> segmen2d.c,v
> retrieving revision 2.5
> diff -u -u -r2.5 segmen2d.c
> --- interp_float/segmen2d.c	9 Feb 2006 03:08:58 -0000	2.5
> +++ interp_float/segmen2d.c	1 May 2007 19:41:02 -0000
> @@ -8,6 +8,7 @@
>  #include <math.h>
>  #include <grass/gis.h>
>  #include <grass/glocale.h>
> +#include <grass/N_pde.h>
>
>  #include <grass/interpf.h>
>
> @@ -263,7 +264,30 @@
>          for (i = 0; i < data->n_points; i++)
>            b[i+1] = data->points[i].z;
>          b[0] = 0.;
> -        G_lubksb(matrix,data->n_points+1,indx,b);
> +
> +	/*create the gpde lineare equation system and transfer the data*/
> +	N_les * les  = N_alloc_les(data->n_points + 1, N_NORMAL_LES);
> +	for(i = 0; i < data->n_points + 1; i++) {
> +	  les->b[i] = b[i];
> +	  for(j = 0; j < data->n_points + 1; j++) {
> +		les->A[i][j] = matrix[i][j];
> +	  }
> +	}
> +	/*solve it with the bicgstab algorithm*/
> +	N_solver_bicgstab(les, 100000, 0.000000001);
> +	double d;
> +
> +	/* for testing */
> +	//G_ludcmp(matrix,data->n_points + 1,indx,&d);
> +        //G_lubksb(matrix,data->n_points + 1,indx,b);
> +
> +	/*transfer the result*/
> +	for(i = 0; i < data->n_points + 1; i++)
> +	b[i] = les->x[i];
> +
> +	/*release memory*/
> +	N_free_les(les);
> +
>          params->check_points 
> (params,data,b,ertot,zmin,dnorm,skip_point);
>          } else if (segtest == 1)
>          {
> @@ -273,7 +297,6 @@
>                    G_lubksb(matrix,data->n_points,indx,b);
>                    params->check_points 
> (params,data,b,ertot,zmin,dnorm,skip_point);
>          }
> -
>          } /*cv loop */
>
>  	if(!params->cv)
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

From michael.barton at asu.edu  Tue May  1 23:49:14 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Tue May  1 23:49:25 2007
Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar?
In-Reply-To: <20070501152503.GB19013@bartok.itc.it>
Message-ID: <C25D03EA.218FC%michael.barton@asu.edu>

If it does extended stats now and the output is the same, it should be an
easy switch.

Michael


On 5/1/07 8:25 AM, "Markus Neteler" <neteler@itc.it> wrote:

> Hi,
> 
> can we safely change v.univar.sh -> v.univar in d.vect.thematic?
> This might speed up calculations...
> 
> Markus
> 
> 

__________________________________________
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 at asu.edu  Wed May  2 01:53:38 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 01:53:55 2007
Subject: [GRASS-dev] selecting default display font from a GUI: update
Message-ID: <C25D2112.21934%michael.barton@asu.edu>

I appreciate all of the info, discussion, and development over the past few
days concerning ways to improve user access to fonts?especially TrueType
fonts?to be used in the default GRASS displays. I want to summarize where I
think we are currently.

I **think** that all d.* commands that generate text now respect the default
font set with the GRASS_FONT variable (did d.rast.num get changed?), though
some can override it with local settings. This will make for consistently
nice looking output in all GRASS displays

GRASS_FT_FONT is being deprecated because GRASS_FONT includes and extends
its functionality. One less environmental variable to worry about.

A new script built by Glynn (mkftcap) will automatically build an enhanced
freetypecap file by scanning the usual suspects of font-containing
directories on Linux, Mac, and Windows systems to look for *.ttf files.
However, it will not search directories not coded into the script and won't
find font files (especially on Mac) that don't end in the standard *.ttf.
Nevertheless, this will be very helpful for those who want to quickly set
fonts from the command line (MUCH more helpful that the previous minimalist
freetypecap file)

The font configure utility fc-list will quickly find all fonts on Linux and
Mac systems, but alas we cannot depend on font configure to be present on
all systems. Also, it doesn't work on Windows.

>From a GUI perspective, it seems at this time that the best route to take
remains letting the user browse to a desired font file.

Trying to create a list and present it to user seems chancy across all GRASS
using systems. fc-list works great, but is not available at all for Windows
and not on all Linux/Mac systems. The new and improved freetypecap will
probably do well for Linux and maybe for Windows, but will miss many useable
fonts on Mac's since they do not have a *.ttf extension. Making a widget
with multiple list boxes and file browsers just to set a single font sounds
complicated and confusing to a potential user.

The ideal would be for one of the nice font selection controls in wxPython
or TclTk to return the simple path to the font. But they seem to return
everything but this.

So at the moment, I think a file browser that 'remembers' where it searched
for fonts seems like the most reliable and complete solution to this.
However, I remain open to better solutions.

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 soerengebbert at gmx.de  Wed May  2 02:01:50 2007
From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=)
Date: Wed May  2 02:02:20 2007
Subject: [GRASS-dev] Licence problems in gmath LU decomposition
In-Reply-To: <C81A9010-DC02-41A5-A52F-99884BBDBC89@unity.ncsu.edu>
References: <46379890.4000700@gmx.de>
	<C81A9010-DC02-41A5-A52F-99884BBDBC89@unity.ncsu.edu>
Message-ID: <4637D4EE.30203@gmx.de>

Helena,

Helena Mitasova schrieb:
> Soeren -
> 
> by default rst does not have 0 on the diagonal - it has the value of the 
> smoothing parameter
> which is 0.1 or 0.01 (I would have to check, I just found it is missing 
> in the man page).
> This keeps the solution stable.

This is right, but while assembling the matrix a new row and column is added
to the linear equation system. Because i don't know how the rst method works,
i have no clue if this can be avoided.
(The matrix assembling code looks like good old Fortran code converted to C)
Take a look at this sample session with 10 points:

GRASS 6.3.cvs > v.surf.rst --o input=ranvect elev=test segmax=600 tension=100 smooth=10
Percent complete:
Reading lines from vector map ... Reading nodes from vector map ...  100%
  111%
WARNING: strip exists with insufficient data

WARNING: 10 points given for interpolation (after thinning) is less than
          given NPMIN=300

The number of points from vector map is 10
The number of points outside of 2D/3D region 0
The number of points being used is 10
Processing all selected output files
will require 40016 bytes of disk space for temp files
Percent complete:
0.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000   *  0.00000  =  0.00000
1.00000 -10.00000 4.44122 5.22566 3.98839 5.46536 4.72084 3.82040 5.43142 4.38633 3.76136   *  0.00000  =  0.00000
1.00000 4.44122 -10.00000 4.48757 1.62831 4.11558 1.52070 2.10155 3.65654 2.48392 3.45935   *  0.00000  =  1.00000
1.00000 5.22566 4.48757 -10.00000 4.32808 3.35973 4.08760 4.81887 4.28695 3.66799 3.93563   *  0.00000  =  2.00000
1.00000 3.98839 1.62831 4.32808 -10.00000 4.27582 2.35813 1.77920 4.10082 1.82269 2.52327   *  0.00000  =  3.00000
1.00000 5.46536 4.11558 3.35973 4.27582 -10.00000 3.48756 4.69876 2.60567 3.71819 4.42648   *  0.00000  =  4.00000
1.00000 4.72084 1.52070 4.08760 2.35813 3.48756 -10.00000 3.14712 3.01723 1.98567 3.48508   *  0.00000  =  5.00000
1.00000 3.82040 2.10155 4.81887 1.77920 4.69876 3.14712 -10.00000 4.41198 3.17120 3.37596   *  0.00000  =  6.00000
1.00000 5.43142 3.65654 4.28695 4.10082 2.60567 3.01723 4.41198 -10.00000 3.78608 4.56449   *  0.00000  =  7.00000
1.00000 4.38633 2.48392 3.66799 1.82269 3.71819 1.98567 3.17120 3.78608 -10.00000 2.30508   *  0.00000  =  8.00000
1.00000 3.76136 3.45935 3.93563 2.52327 4.42648 3.48508 3.37596 4.56449 2.30508 -10.00000   *  0.00000  =  9.00000
Number of unknowns 11
BiCGStab -- iteration 0 error 285
BiCGStab -- iteration 1 error 778.166
BiCGStab -- iteration 2 error 2.90633
BiCGStab -- iteration 3 error 2.27454
BiCGStab -- iteration 4 error 0.369957
BiCGStab -- iteration 5 error 0.000523873
BiCGStab -- iteration 6 error 0.000268323
BiCGStab -- iteration 7 error 5.94182e-08
BiCGStab -- iteration 8 error 1.63458e-12
  100%
history initiated
v.surf.rst complete.

The first entry of the matrix is zero.
IMHO the first column and first row can not be removed. The diagonal entries [i][i] = -10
reflecting the smoothing parameter and will be zero if the smoothing parameter is zero
(exactly as you explained). Luckily the bicgstab method can handle this.


Here an example with smoothing = 0:

GRASS 6.3.cvs > v.surf.rst --o input=ranvect elev=test segmax=600 tension=100 smooth=0
Percent complete:
Reading lines from vector map ... Reading nodes from vector map ...  100%
  111%
WARNING: strip exists with insufficient data

WARNING: 10 points given for interpolation (after thinning) is less than
          given NPMIN=300

The number of points from vector map is 10
The number of points outside of 2D/3D region 0
The number of points being used is 10
Processing all selected output files
will require 40016 bytes of disk space for temp files
Percent complete:
0.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000   *  0.00000  =  0.00000
1.00000 -0.00000 4.44122 5.22566 3.98839 5.46536 4.72084 3.82040 5.43142 4.38633 3.76136   *  0.00000  =  0.00000
1.00000 4.44122 -0.00000 4.48757 1.62831 4.11558 1.52070 2.10155 3.65654 2.48392 3.45935   *  0.00000  =  1.00000
1.00000 5.22566 4.48757 -0.00000 4.32808 3.35973 4.08760 4.81887 4.28695 3.66799 3.93563   *  0.00000  =  2.00000
1.00000 3.98839 1.62831 4.32808 -0.00000 4.27582 2.35813 1.77920 4.10082 1.82269 2.52327   *  0.00000  =  3.00000
1.00000 5.46536 4.11558 3.35973 4.27582 -0.00000 3.48756 4.69876 2.60567 3.71819 4.42648   *  0.00000  =  4.00000
1.00000 4.72084 1.52070 4.08760 2.35813 3.48756 -0.00000 3.14712 3.01723 1.98567 3.48508   *  0.00000  =  5.00000
1.00000 3.82040 2.10155 4.81887 1.77920 4.69876 3.14712 -0.00000 4.41198 3.17120 3.37596   *  0.00000  =  6.00000
1.00000 5.43142 3.65654 4.28695 4.10082 2.60567 3.01723 4.41198 -0.00000 3.78608 4.56449   *  0.00000  =  7.00000
1.00000 4.38633 2.48392 3.66799 1.82269 3.71819 1.98567 3.17120 3.78608 -0.00000 2.30508   *  0.00000  =  8.00000
1.00000 3.76136 3.45935 3.93563 2.52327 4.42648 3.48508 3.37596 4.56449 2.30508 -0.00000   *  0.00000  =  9.00000
Number of unknowns 11
BiCGStab -- iteration 0 error 285
BiCGStab -- iteration 1 error 165.856
BiCGStab -- iteration 2 error 6.9055
BiCGStab -- iteration 3 error 1.2445
BiCGStab -- iteration 4 error 0.39798
BiCGStab -- iteration 5 error 0.155552
BiCGStab -- iteration 6 error 0.0760317
BiCGStab -- iteration 7 error 0.00483319
BiCGStab -- iteration 8 error 0.0191541
BiCGStab -- iteration 9 error 1.27935e-05
BiCGStab -- iteration 10 error 3.69912e-08
BiCGStab -- iteration 11 error 1.60303e-10
  100%
history initiated
v.surf.rst complete.


> It runs with zero smoothing too if you have sufficiently high tension,
> but it gets unstable for small tension and zero smoothing. That is why 
> the defaults and
> overall internal adjustments of the parameters are set to avoid it and 
> the program
> gives warnings about the overshoots. There is more here (see e.g. fig. 2)
> http://skagit.meas.ncsu.edu/~helena/gmslab/papers/IEEEGRSL2005.pdf
> 
> But the G_ludcmp() needs to be replaced - it was discussed long time ago 
> and
> I somehow thought that it was done and the function does not include the 
> num. recipes
> program.
 >
 > Thanks for the patch, I planned to look at the solver because of the
 > performance issues,
 > so this helps, although the strange performance behavior since somewhere
 > GRASS5*
 > may be more related to recently reported stunning degradation of
 > performance for
 > rasters between 4.* and 5.* than in lineq. solver. I always though it is
 > slower due to the
 > floating point introduction and did not realize that it affects integer
 > rasters too,
 >

The strength of the bicgstab algorithm is to solve sparse linear equation systems very fast.
And i guess we will always get fully occupied matrices in case of the rst algorithm (each point
influences each other point).
The speed of the bicgstab solver depends on the initial guess. The better the guess the faster the solution is.
So i'm not sure if the bicgstab is really faster then a LU decomposition, because it depends
on the initial guess and the constitution of the matrix, which is getting
better with higher smoothing factors.

In case of the examples above, the bicgstab will be faster than a LU decomposition if the number of iterations
is much lower than the number of unknowns. Internally two matrix multiplications
and several vector operations are performed for each iteration.
If the smoothing factor is zero, the number of iterations is larger
than the number of unknowns. In this case the LU decomposition would be faster.

A short benchmark with 500 points proved my guess. The G_ludcmp() solver is faster for matrices with bad
condition (smoothing 0 - 7), the bicgstab will be faster with smoothing factors greater than 9.

IMHO a LU decomposition with pivoting would be the best choice in case of bad conditioning.
If we can avoid zeros and really bad matrix condition
(smoothing factor should be always greater than zero), we can use the parallelized LU decomposition of the gpde
library. The bicgstab solver is parallelized too and can be used in case of good conditions.
Maybe we can implement booth algorithms and let the user choose?
The rst computation will definitely benefit from  parallel solvers.


Best regards
Soeren

> Helena
> 
> 
> 
> 
> Helena Mitasova
> Dept. of Marine, Earth and Atm. Sciences
> 1125 Jordan Hall, NCSU Box 8208,
> Raleigh NC 27695
> http://skagit.meas.ncsu.edu/~helena/
> 
> 
> 
> On May 1, 2007, at 3:44 PM, S?ren Gebbert wrote:
> 
>> Dear developers,
>> i just noticed that the code of  is an exact copy of
>> the numerical recipes algorithm. :(
>> We need to replace it.
>>
>> I have implemented a new simple parallel LU decomposition in the gpde 
>> library (since several months in CVS).
>> But this algorithm lacks the ability of pivoting (it would be very 
>> hard to implement this as a parallel version).
>> So it is not usable within the rst library in grass and maybe others? 
>> This is a big problem.
>>
>> The rst library creates linear equation systems with a zero entry in 
>> the diagonal matrix. All the
>> algorithms implemented in gpde library to solve linear equation 
>> systems are not able to
>> handle this (LU, Gauss, jacobi, SOR) except the bicgstab algorithm.
>> The bicgstab is a state of the art iterative linear equation solver 
>> algorithm for non-symmetric matrices.
>> But it will fail on very bad conditioned matrices, so it is not the 
>> best choice if a direct solve can be used.
>>
>> I have created a very simple patch for the rst library (regular spline 
>> with tension) to use the bicgstab
>> algorithm form the gpde lib instead of G_ludcmp(). Just for testing.
>> It seems to work and it is not slower than G_ludcmp(). The patch is 
>> attached.
>> It would be better if the rst lib would create matrices with a better 
>> condition and without
>> zero entries at the diagonal matrix. Then we could use other gpde 
>> algorithms than bicgstab.
>>
>> The main question is, what to do with G_ludcmp()? There is a free 
>> implementation of the LU
>> decomposition algorithm with pivoting in the GSL library, which we can 
>> use. Or we use the bicgstab
>> algorithm in cases where the simple LU algorithm from the gpde library 
>> will fail?
>>
>> Any suggestions are welcome
>> Best regards
>> Soeren
>> Index: interp_float/matrix.c
>> ===================================================================
>> RCS file: 
>> /home/grass/grassrepository/grass6/lib/rst/interp_float/matrix.c,v
>> retrieving revision 2.3
>> diff -u -u -r2.3 matrix.c
>> --- interp_float/matrix.c    29 Mar 2006 20:05:08 -0000    2.3
>> +++ interp_float/matrix.c    1 May 2007 19:41:01 -0000
>> @@ -154,12 +154,13 @@
>>          matrix[i][j] = A[m];
>>        }
>>      }
>> -
>> -    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) { /* find the inverse 
>> of the mat
>> -rix */
>> +/*
>> +    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) {
>> +
>>        fprintf(stderr,"G_ludcmp() failed! n=%d\n",n_points);
>>        return -1;
>>      }
>> +    */
>>  /*
>>      G_free_vector(A);
>>  */
>> Index: interp_float/segmen2d.c
>> ===================================================================
>> RCS file: 
>> /home/grass/grassrepository/grass6/lib/rst/interp_float/segmen2d.c,v
>> retrieving revision 2.5
>> diff -u -u -r2.5 segmen2d.c
>> --- interp_float/segmen2d.c    9 Feb 2006 03:08:58 -0000    2.5
>> +++ interp_float/segmen2d.c    1 May 2007 19:41:02 -0000
>> @@ -8,6 +8,7 @@
>>  #include <math.h>
>>  #include <grass/gis.h>
>>  #include <grass/glocale.h>
>> +#include <grass/N_pde.h>
>>
>>  #include <grass/interpf.h>
>>
>> @@ -263,7 +264,30 @@
>>          for (i = 0; i < data->n_points; i++)
>>            b[i+1] = data->points[i].z;
>>          b[0] = 0.;
>> -        G_lubksb(matrix,data->n_points+1,indx,b);
>> +
>> +    /*create the gpde lineare equation system and transfer the data*/
>> +    N_les * les  = N_alloc_les(data->n_points + 1, N_NORMAL_LES);
>> +    for(i = 0; i < data->n_points + 1; i++) {
>> +      les->b[i] = b[i];
>> +      for(j = 0; j < data->n_points + 1; j++) {
>> +        les->A[i][j] = matrix[i][j];
>> +      }
>> +    }
>> +    /*solve it with the bicgstab algorithm*/
>> +    N_solver_bicgstab(les, 100000, 0.000000001);
>> +    double d;
>> +
>> +    /* for testing */
>> +    //G_ludcmp(matrix,data->n_points + 1,indx,&d);
>> +        //G_lubksb(matrix,data->n_points + 1,indx,b);
>> +
>> +    /*transfer the result*/
>> +    for(i = 0; i < data->n_points + 1; i++)
>> +    b[i] = les->x[i];
>> +
>> +    /*release memory*/
>> +    N_free_les(les);
>> +
>>          params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
>>          } else if (segtest == 1)
>>          {
>> @@ -273,7 +297,6 @@
>>                    G_lubksb(matrix,data->n_points,indx,b);
>>                    
>> params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
>>          }
>> -
>>          } /*cv loop */
>>
>>      if(!params->cv)
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

From soerengebbert at gmx.de  Wed May  2 02:34:30 2007
From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=)
Date: Wed May  2 02:35:03 2007
Subject: [GRASS-dev] Licence problems in gmath LU decomposition
In-Reply-To: <4637D4EE.30203@gmx.de>
References: <46379890.4000700@gmx.de>	<C81A9010-DC02-41A5-A52F-99884BBDBC89@unity.ncsu.edu>
	<4637D4EE.30203@gmx.de>
Message-ID: <4637DC96.2090801@gmx.de>

I forgot an important information.
Because the rst matrix is symmetric, the N_solver_bicgstab and the N_solver_cg
can be used to solve the linear equation system. The cg (conjugate gradient)
solver is optimized for symmetric matrices and therefore much faster than the bicgstab algorithm (only
one matrix*vector operation per iteration) and parallelized as well.


Best regards
Soeren

S?ren Gebbert schrieb:
> Helena,
> 
> Helena Mitasova schrieb:
>> Soeren -
>>
>> by default rst does not have 0 on the diagonal - it has the value of 
>> the smoothing parameter
>> which is 0.1 or 0.01 (I would have to check, I just found it is 
>> missing in the man page).
>> This keeps the solution stable.
> 
> This is right, but while assembling the matrix a new row and column is 
> added
> to the linear equation system. Because i don't know how the rst method 
> works,
> i have no clue if this can be avoided.
> (The matrix assembling code looks like good old Fortran code converted 
> to C)
> Take a look at this sample session with 10 points:
> 
> GRASS 6.3.cvs > v.surf.rst --o input=ranvect elev=test segmax=600 
> tension=100 smooth=10
> Percent complete:
> Reading lines from vector map ... Reading nodes from vector map ...  100%
>  111%
> WARNING: strip exists with insufficient data
> 
> WARNING: 10 points given for interpolation (after thinning) is less than
>          given NPMIN=300
> 
> The number of points from vector map is 10
> The number of points outside of 2D/3D region 0
> The number of points being used is 10
> Processing all selected output files
> will require 40016 bytes of disk space for temp files
> Percent complete:
> 0.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 
> 1.00000 1.00000   *  0.00000  =  0.00000
> 1.00000 -10.00000 4.44122 5.22566 3.98839 5.46536 4.72084 3.82040 
> 5.43142 4.38633 3.76136   *  0.00000  =  0.00000
> 1.00000 4.44122 -10.00000 4.48757 1.62831 4.11558 1.52070 2.10155 
> 3.65654 2.48392 3.45935   *  0.00000  =  1.00000
> 1.00000 5.22566 4.48757 -10.00000 4.32808 3.35973 4.08760 4.81887 
> 4.28695 3.66799 3.93563   *  0.00000  =  2.00000
> 1.00000 3.98839 1.62831 4.32808 -10.00000 4.27582 2.35813 1.77920 
> 4.10082 1.82269 2.52327   *  0.00000  =  3.00000
> 1.00000 5.46536 4.11558 3.35973 4.27582 -10.00000 3.48756 4.69876 
> 2.60567 3.71819 4.42648   *  0.00000  =  4.00000
> 1.00000 4.72084 1.52070 4.08760 2.35813 3.48756 -10.00000 3.14712 
> 3.01723 1.98567 3.48508   *  0.00000  =  5.00000
> 1.00000 3.82040 2.10155 4.81887 1.77920 4.69876 3.14712 -10.00000 
> 4.41198 3.17120 3.37596   *  0.00000  =  6.00000
> 1.00000 5.43142 3.65654 4.28695 4.10082 2.60567 3.01723 4.41198 
> -10.00000 3.78608 4.56449   *  0.00000  =  7.00000
> 1.00000 4.38633 2.48392 3.66799 1.82269 3.71819 1.98567 3.17120 3.78608 
> -10.00000 2.30508   *  0.00000  =  8.00000
> 1.00000 3.76136 3.45935 3.93563 2.52327 4.42648 3.48508 3.37596 4.56449 
> 2.30508 -10.00000   *  0.00000  =  9.00000
> Number of unknowns 11
> BiCGStab -- iteration 0 error 285
> BiCGStab -- iteration 1 error 778.166
> BiCGStab -- iteration 2 error 2.90633
> BiCGStab -- iteration 3 error 2.27454
> BiCGStab -- iteration 4 error 0.369957
> BiCGStab -- iteration 5 error 0.000523873
> BiCGStab -- iteration 6 error 0.000268323
> BiCGStab -- iteration 7 error 5.94182e-08
> BiCGStab -- iteration 8 error 1.63458e-12
>  100%
> history initiated
> v.surf.rst complete.
> 
> The first entry of the matrix is zero.
> IMHO the first column and first row can not be removed. The diagonal 
> entries [i][i] = -10
> reflecting the smoothing parameter and will be zero if the smoothing 
> parameter is zero
> (exactly as you explained). Luckily the bicgstab method can handle this.
> 
> 
> Here an example with smoothing = 0:
> 
> GRASS 6.3.cvs > v.surf.rst --o input=ranvect elev=test segmax=600 
> tension=100 smooth=0
> Percent complete:
> Reading lines from vector map ... Reading nodes from vector map ...  100%
>  111%
> WARNING: strip exists with insufficient data
> 
> WARNING: 10 points given for interpolation (after thinning) is less than
>          given NPMIN=300
> 
> The number of points from vector map is 10
> The number of points outside of 2D/3D region 0
> The number of points being used is 10
> Processing all selected output files
> will require 40016 bytes of disk space for temp files
> Percent complete:
> 0.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 1.00000 
> 1.00000 1.00000   *  0.00000  =  0.00000
> 1.00000 -0.00000 4.44122 5.22566 3.98839 5.46536 4.72084 3.82040 5.43142 
> 4.38633 3.76136   *  0.00000  =  0.00000
> 1.00000 4.44122 -0.00000 4.48757 1.62831 4.11558 1.52070 2.10155 3.65654 
> 2.48392 3.45935   *  0.00000  =  1.00000
> 1.00000 5.22566 4.48757 -0.00000 4.32808 3.35973 4.08760 4.81887 4.28695 
> 3.66799 3.93563   *  0.00000  =  2.00000
> 1.00000 3.98839 1.62831 4.32808 -0.00000 4.27582 2.35813 1.77920 4.10082 
> 1.82269 2.52327   *  0.00000  =  3.00000
> 1.00000 5.46536 4.11558 3.35973 4.27582 -0.00000 3.48756 4.69876 2.60567 
> 3.71819 4.42648   *  0.00000  =  4.00000
> 1.00000 4.72084 1.52070 4.08760 2.35813 3.48756 -0.00000 3.14712 3.01723 
> 1.98567 3.48508   *  0.00000  =  5.00000
> 1.00000 3.82040 2.10155 4.81887 1.77920 4.69876 3.14712 -0.00000 4.41198 
> 3.17120 3.37596   *  0.00000  =  6.00000
> 1.00000 5.43142 3.65654 4.28695 4.10082 2.60567 3.01723 4.41198 -0.00000 
> 3.78608 4.56449   *  0.00000  =  7.00000
> 1.00000 4.38633 2.48392 3.66799 1.82269 3.71819 1.98567 3.17120 3.78608 
> -0.00000 2.30508   *  0.00000  =  8.00000
> 1.00000 3.76136 3.45935 3.93563 2.52327 4.42648 3.48508 3.37596 4.56449 
> 2.30508 -0.00000   *  0.00000  =  9.00000
> Number of unknowns 11
> BiCGStab -- iteration 0 error 285
> BiCGStab -- iteration 1 error 165.856
> BiCGStab -- iteration 2 error 6.9055
> BiCGStab -- iteration 3 error 1.2445
> BiCGStab -- iteration 4 error 0.39798
> BiCGStab -- iteration 5 error 0.155552
> BiCGStab -- iteration 6 error 0.0760317
> BiCGStab -- iteration 7 error 0.00483319
> BiCGStab -- iteration 8 error 0.0191541
> BiCGStab -- iteration 9 error 1.27935e-05
> BiCGStab -- iteration 10 error 3.69912e-08
> BiCGStab -- iteration 11 error 1.60303e-10
>  100%
> history initiated
> v.surf.rst complete.
> 
> 
>> It runs with zero smoothing too if you have sufficiently high tension,
>> but it gets unstable for small tension and zero smoothing. That is why 
>> the defaults and
>> overall internal adjustments of the parameters are set to avoid it and 
>> the program
>> gives warnings about the overshoots. There is more here (see e.g. fig. 2)
>> http://skagit.meas.ncsu.edu/~helena/gmslab/papers/IEEEGRSL2005.pdf
>>
>> But the G_ludcmp() needs to be replaced - it was discussed long time 
>> ago and
>> I somehow thought that it was done and the function does not include 
>> the num. recipes
>> program.
>  >
>  > Thanks for the patch, I planned to look at the solver because of the
>  > performance issues,
>  > so this helps, although the strange performance behavior since somewhere
>  > GRASS5*
>  > may be more related to recently reported stunning degradation of
>  > performance for
>  > rasters between 4.* and 5.* than in lineq. solver. I always though it is
>  > slower due to the
>  > floating point introduction and did not realize that it affects integer
>  > rasters too,
>  >
> 
> The strength of the bicgstab algorithm is to solve sparse linear 
> equation systems very fast.
> And i guess we will always get fully occupied matrices in case of the 
> rst algorithm (each point
> influences each other point).
> The speed of the bicgstab solver depends on the initial guess. The 
> better the guess the faster the solution is.
> So i'm not sure if the bicgstab is really faster then a LU 
> decomposition, because it depends
> on the initial guess and the constitution of the matrix, which is getting
> better with higher smoothing factors.
> 
> In case of the examples above, the bicgstab will be faster than a LU 
> decomposition if the number of iterations
> is much lower than the number of unknowns. Internally two matrix 
> multiplications
> and several vector operations are performed for each iteration.
> If the smoothing factor is zero, the number of iterations is larger
> than the number of unknowns. In this case the LU decomposition would be 
> faster.
> 
> A short benchmark with 500 points proved my guess. The G_ludcmp() solver 
> is faster for matrices with bad
> condition (smoothing 0 - 7), the bicgstab will be faster with smoothing 
> factors greater than 9.
> 
> IMHO a LU decomposition with pivoting would be the best choice in case 
> of bad conditioning.
> If we can avoid zeros and really bad matrix condition
> (smoothing factor should be always greater than zero), we can use the 
> parallelized LU decomposition of the gpde
> library. The bicgstab solver is parallelized too and can be used in case 
> of good conditions.
> Maybe we can implement booth algorithms and let the user choose?
> The rst computation will definitely benefit from  parallel solvers.
> 
> 
> Best regards
> Soeren
> 
>> Helena
>>
>>
>>
>>
>> Helena Mitasova
>> Dept. of Marine, Earth and Atm. Sciences
>> 1125 Jordan Hall, NCSU Box 8208,
>> Raleigh NC 27695
>> http://skagit.meas.ncsu.edu/~helena/
>>
>>
>>
>> On May 1, 2007, at 3:44 PM, S?ren Gebbert wrote:
>>
>>> Dear developers,
>>> i just noticed that the code of  is an exact copy of
>>> the numerical recipes algorithm. :(
>>> We need to replace it.
>>>
>>> I have implemented a new simple parallel LU decomposition in the gpde 
>>> library (since several months in CVS).
>>> But this algorithm lacks the ability of pivoting (it would be very 
>>> hard to implement this as a parallel version).
>>> So it is not usable within the rst library in grass and maybe others? 
>>> This is a big problem.
>>>
>>> The rst library creates linear equation systems with a zero entry in 
>>> the diagonal matrix. All the
>>> algorithms implemented in gpde library to solve linear equation 
>>> systems are not able to
>>> handle this (LU, Gauss, jacobi, SOR) except the bicgstab algorithm.
>>> The bicgstab is a state of the art iterative linear equation solver 
>>> algorithm for non-symmetric matrices.
>>> But it will fail on very bad conditioned matrices, so it is not the 
>>> best choice if a direct solve can be used.
>>>
>>> I have created a very simple patch for the rst library (regular 
>>> spline with tension) to use the bicgstab
>>> algorithm form the gpde lib instead of G_ludcmp(). Just for testing.
>>> It seems to work and it is not slower than G_ludcmp(). The patch is 
>>> attached.
>>> It would be better if the rst lib would create matrices with a better 
>>> condition and without
>>> zero entries at the diagonal matrix. Then we could use other gpde 
>>> algorithms than bicgstab.
>>>
>>> The main question is, what to do with G_ludcmp()? There is a free 
>>> implementation of the LU
>>> decomposition algorithm with pivoting in the GSL library, which we 
>>> can use. Or we use the bicgstab
>>> algorithm in cases where the simple LU algorithm from the gpde 
>>> library will fail?
>>>
>>> Any suggestions are welcome
>>> Best regards
>>> Soeren
>>> Index: interp_float/matrix.c
>>> ===================================================================
>>> RCS file: 
>>> /home/grass/grassrepository/grass6/lib/rst/interp_float/matrix.c,v
>>> retrieving revision 2.3
>>> diff -u -u -r2.3 matrix.c
>>> --- interp_float/matrix.c    29 Mar 2006 20:05:08 -0000    2.3
>>> +++ interp_float/matrix.c    1 May 2007 19:41:01 -0000
>>> @@ -154,12 +154,13 @@
>>>          matrix[i][j] = A[m];
>>>        }
>>>      }
>>> -
>>> -    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) { /* find the 
>>> inverse of the mat
>>> -rix */
>>> +/*
>>> +    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) {
>>> +
>>>        fprintf(stderr,"G_ludcmp() failed! n=%d\n",n_points);
>>>        return -1;
>>>      }
>>> +    */
>>>  /*
>>>      G_free_vector(A);
>>>  */
>>> Index: interp_float/segmen2d.c
>>> ===================================================================
>>> RCS file: 
>>> /home/grass/grassrepository/grass6/lib/rst/interp_float/segmen2d.c,v
>>> retrieving revision 2.5
>>> diff -u -u -r2.5 segmen2d.c
>>> --- interp_float/segmen2d.c    9 Feb 2006 03:08:58 -0000    2.5
>>> +++ interp_float/segmen2d.c    1 May 2007 19:41:02 -0000
>>> @@ -8,6 +8,7 @@
>>>  #include <math.h>
>>>  #include <grass/gis.h>
>>>  #include <grass/glocale.h>
>>> +#include <grass/N_pde.h>
>>>
>>>  #include <grass/interpf.h>
>>>
>>> @@ -263,7 +264,30 @@
>>>          for (i = 0; i < data->n_points; i++)
>>>            b[i+1] = data->points[i].z;
>>>          b[0] = 0.;
>>> -        G_lubksb(matrix,data->n_points+1,indx,b);
>>> +
>>> +    /*create the gpde lineare equation system and transfer the data*/
>>> +    N_les * les  = N_alloc_les(data->n_points + 1, N_NORMAL_LES);
>>> +    for(i = 0; i < data->n_points + 1; i++) {
>>> +      les->b[i] = b[i];
>>> +      for(j = 0; j < data->n_points + 1; j++) {
>>> +        les->A[i][j] = matrix[i][j];
>>> +      }
>>> +    }
>>> +    /*solve it with the bicgstab algorithm*/
>>> +    N_solver_bicgstab(les, 100000, 0.000000001);
>>> +    double d;
>>> +
>>> +    /* for testing */
>>> +    //G_ludcmp(matrix,data->n_points + 1,indx,&d);
>>> +        //G_lubksb(matrix,data->n_points + 1,indx,b);
>>> +
>>> +    /*transfer the result*/
>>> +    for(i = 0; i < data->n_points + 1; i++)
>>> +    b[i] = les->x[i];
>>> +
>>> +    /*release memory*/
>>> +    N_free_les(les);
>>> +
>>>          
>>> params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
>>>          } else if (segtest == 1)
>>>          {
>>> @@ -273,7 +297,6 @@
>>>                    G_lubksb(matrix,data->n_points,indx,b);
>>>                    
>>> params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
>>>          }
>>> -
>>>          } /*cv loop */
>>>
>>>      if(!params->cv)
>>> _______________________________________________
>>> grass-dev mailing list
>>> grass-dev@grass.itc.it
>>> http://grass.itc.it/mailman/listinfo/grass-dev
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
> 

From woklist at kyngchaos.com  Wed May  2 02:39:39 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Wed May  2 02:39:48 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
Message-ID: <B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>

On May 1, 2007, at 9:28 AM, William Kyngesburye wrote:

> On May 1, 2007, at 4:05 AM, Glynn Clements wrote:
>
>> Wolf Bergenheim wrote:
>>
>>> Trying to find all fonts (within a configured font path) on a Linux
>>> system is actually quite easy. Just run the command 'fc-list'
>>
>> Part of fontconfig. Although that's a fairly common package, it isn't
>> guaranteed to be installed, particularly on servers.
>>
>> It probably won't be present on Windows or MacOSX unless you have a
>> fair amount of Linux compatibility stuff installed. I have several
>> native GTK+ apps on my Windows box, but no native fc-list. I have a
>> Cygwin fc-list, although that fails to list the Windows TTF fonts.
>>
> Fontconfig is included in the OSX X11 package, and searches the  
> standard OSX font locations.  Though this is an optional package  
> for OSX, it's still required for the current tcltk GUI.  I do know  
> that at one time fontconfig was NOT included in the OSX X11, but I  
> think it's in OSX 10.3.9 X11.  I realize we want to reduce  
> dependecy on X11 in OSX, but this looks like a useful tool.

I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is  
present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and  
below) it was a beta and is not available for download any more, as  
far as I can tell.  I think the betas must be where fontconfig wasn't  
a part of Apple's X11 package (and I'm sure it wasn't at first).

So, using fc-list on OSX, if it's available, for mkftcap is  
reasonable, for now.

> I just thought of another possibility for OSX - AppleScript.  AS  
> can run from the CLI.  The Font Book application in OSX (which  
> handles font installation) can return font info for installed  
> fonts, including font paths.  I can look into that.
>
After a bit of thought, this could work, yes.  But it would mean that  
Font Book.app would briefly run so that AppleScript can do its  
thing.  A minor inconvenience, especially if mkftcap is only run on  
install or infrequently when a user installs fonts.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*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 soerengebbert at gmx.de  Wed May  2 03:26:13 2007
From: soerengebbert at gmx.de (=?ISO-8859-1?Q?S=F6ren_Gebbert?=)
Date: Wed May  2 03:26:43 2007
Subject: [GRASS-dev] Licence problems in gmath LU decomposition
In-Reply-To: <4637DC96.2090801@gmx.de>
References: <46379890.4000700@gmx.de>	<C81A9010-DC02-41A5-A52F-99884BBDBC89@unity.ncsu.edu>	<4637D4EE.30203@gmx.de>
	<4637DC96.2090801@gmx.de>
Message-ID: <4637E8B5.7030301@gmx.de>

I have created a new patch for the rst library to test the gpde solvers
with the rst matrices. I have added a new function to  rst/interp_float/segmen2d.c (solve_matrix).
If you want to test the different gpde solvers (only cg and bicgstab will work),
just remove or add a comment within the new function.
The created linear eqution system can be printed to stdout,
just remove the comment before N_print_les(les).

This is a quick and dirty hack and only for testing purpose. :)

You have to patch the rst library and v.surf.rst to get it work.

This is the v.surf.rst patch:

Index: Makefile
===================================================================
RCS file: /home/grass/grassrepository/grass6/vector/v.surf.rst/Makefile,v
retrieving revision 1.7
diff -u -r1.7 Makefile
--- Makefile    20 Feb 2004 17:43:33 -0000      1.7
+++ Makefile    2 May 2007 01:16:20 -0000
@@ -5,7 +5,7 @@
  EXTRA_CLEAN_DIRS=doxygenhtml

  LIBES     = $(INTERPDATALIB) $(QTREELIB) $(INTERPFLLIB) $(BITMAPLIB) $(LINKMLIB) \
-            $(VECTLIB) $(VECTLIB_REAL) $(DBMILIB) $(SITESLIB) $(GISLIB) $(DATETIMELIB) $(GMATHLIB)
+            $(VECTLIB) $(VECTLIB_REAL) $(DBMILIB) $(SITESLIB) $(GISLIB) $(DATETIMELIB) $(GMATHLIB) $(GPDELIB)
  DEPENDENCIES = $(INTERPDATADEP) $(QTREEDEP) $(INTERPFLDEP) $(BITMAPDEP) $(LINKMDEP) \
              $(VECTDEP) $(DBMIDEP) $(GISDEP) $(DATETIMEDEP) $(GMATHDEP)
  EXTRA_INC = $(VECT_INC)





The rst library patch is attached.

Best regards
Soeren

-------------- next part --------------
Index: interp_float/matrix.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/rst/interp_float/matrix.c,v
retrieving revision 2.3
diff -u -r2.3 matrix.c
--- interp_float/matrix.c	29 Mar 2006 20:05:08 -0000	2.3
+++ interp_float/matrix.c	2 May 2007 01:14:15 -0000
@@ -154,12 +154,6 @@
         matrix[i][j] = A[m];
       }
     }
-
-    if (G_ludcmp(matrix,n_points+1,indx,&d)<=0) { /* find the inverse of the mat
-rix */
-      fprintf(stderr,"G_ludcmp() failed! n=%d\n",n_points);
-      return -1;
-    }
 /*
     G_free_vector(A);
 */
Index: interp_float/segmen2d.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/rst/interp_float/segmen2d.c,v
retrieving revision 2.5
diff -u -r2.5 segmen2d.c
--- interp_float/segmen2d.c	9 Feb 2006 03:08:58 -0000	2.5
+++ interp_float/segmen2d.c	2 May 2007 01:14:17 -0000
@@ -8,10 +8,12 @@
 #include <math.h>
 #include <grass/gis.h>
 #include <grass/glocale.h>
+#include <grass/N_pde.h>
 
 #include <grass/interpf.h>
 
 static double  smallest_segment( struct multtree *, int);
+void solve_matrix(struct quaddata *data, double *b, double **matrix, int *indx, int ofs);
 
 int IL_interp_segments_2d (
     struct interp_params *params,
@@ -249,31 +251,21 @@
      }
       }/* segment area test */
 
-        if (!params->cv){
-        if (params->matrix_create(params,data->points,data->n_points,
+        if (!params->cv) {
+        	if (params->matrix_create(params,data->points,data->n_points,
                                        matrix,indx) < 0)  return -1;
-        }
-        else if (segtest == 1)
-	{
-                if (params->matrix_create(params,data->points,data->n_points-1,
-                                        matrix,indx) < 0)  return -1;
-        }
 
-        if (!params->cv) {
-        for (i = 0; i < data->n_points; i++)
-          b[i+1] = data->points[i].z;
-        b[0] = 0.;
-        G_lubksb(matrix,data->n_points+1,indx,b);
-        params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
+		  /*solve the equation system*/
+		  solve_matrix(data, b, matrix, indx, 1);
+        	  params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
         } else if (segtest == 1)
         {
-                for (i = 0; i < data->n_points-1; i++)
-                  b[i+1] = data->points[i].z;
-                  b[0] = 0.;
-                  G_lubksb(matrix,data->n_points,indx,b);
+                if (params->matrix_create(params,data->points,data->n_points-1,
+                                        matrix,indx) < 0)  return -1;
+		  /*solve the equation system*/
+		  solve_matrix(data, b, matrix, indx, 0);
                   params->check_points(params,data,b,ertot,zmin,dnorm,skip_point);
         }
-
         } /*cv loop */
         
 	if(!params->cv)
@@ -340,4 +332,44 @@
 }
 
 
+/*Solve linear equation system with different solvers*/
+void solve_matrix(struct quaddata *data, double *b, double **matrix, int *indx, int ofs)
+{
+  int i, j;
+  double d;
 
+  N_les * les  = N_alloc_les(data->n_points + ofs, N_NORMAL_LES);
+
+  for (i = 0; i < data->n_points - 1 - ofs; i++)
+    b[i+1] = data->points[i].z;
+  b[0] = 0.;
+
+  /*create the gpde lineare equation system and transfer the data*/
+  for(i = 0; i < data->n_points + ofs; i++) {
+    les->b[i] = b[i];
+    for(j = 0; j < data->n_points + ofs; j++) {
+      les->A[i][j] = matrix[i][j];
+    }
+  }
+  /*solve it with the bicgstab algorithm*/
+  //N_print_les(les);
+  //N_solver_gauss(les);
+  //N_solver_lu(les);
+  //N_solver_jacobi(les, 100, 1, 0.00001);
+  //N_solver_SOR(les, 100, 1, 0.00001);
+  //N_solver_bicgstab(les, 100000, 0.000000001);
+  N_solver_cg(les, 100000, 0.000000001);
+
+  /*transfer the result*/
+  for(i = 0; i < data->n_points + ofs; i++) 
+  b[i] = les->x[i];
+
+  /*release memory*/
+  N_free_les(les);
+
+  /* for testing, uncomment this if you want to test the lu decomposition */
+  //G_ludcmp(matrix,data->n_points + ofs,indx,&d);
+  //G_lubksb(matrix,data->n_points + ofs,indx,b);
+  
+return;
+}
From glynn at gclements.plus.com  Wed May  2 04:18:20 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed May  2 04:18:32 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
Message-ID: <17975.62700.469950.591439@cerise.gclements.plus.com>


William Kyngesburye wrote:

> I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is  
> present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and  
> below) it was a beta and is not available for download any more, as  
> far as I can tell.  I think the betas must be where fontconfig wasn't  
> a part of Apple's X11 package (and I'm sure it wasn't at first).
> 
> So, using fc-list on OSX, if it's available, for mkftcap is  
> reasonable, for now.

Is it possible to filter any non-TrueType fonts from the output? Or
are there not enough TrueType fonts to worry about?

We can probably tolerate a few bogus entries in an auto-generated
freetypecap file; the user can always remove entries which don't work. 
However, on my system, "fc-list :outline file" generates 102 entries;
51 are .ttf files and 51 are .pfa/.pfb files, which is too high a
signal-to-noise ratio.

That doesn't matter on Linux, as I can just ignore anything which
doesn't have a .ttf extension. For OSX, we'll need to find some other
way unless the number of false positives in the original fc-list
output is low.

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

From hamish_nospam at yahoo.com  Wed May  2 05:04:35 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed May  2 05:05:10 2007
Subject: [GRASS-dev] [grass-code R][386] GIS manager and d.rast.edit
In-Reply-To: <20070501204728.020e7932.hamish_nospam@yahoo.com>
References: <20070430091123.151CE19F5FEA@pyrosoma.intevation.org>
	<20070501204728.020e7932.hamish_nospam@yahoo.com>
Message-ID: <20070502150435.7664fae4.hamish_nospam@yahoo.com>

Hamish wrote:
> [fwd from tracker]
> http://wald.intevation.org/tracker/?func=detail&atid=188&aid=385&group_id=21
> 
> > code R item #386, was opened at 30/04/2007 11:11
> > Summary: GIS manager and d.rast.edit 
> ..
> > In Grass 6.2.1GIS Manager the menu " Edit category values of
> > individual cells for displayed raster map " ignores the active
> > monitor and always open a new monitor, white, without toolbar, and
> > without any reaction to the mouse buttons.
> 
> GUI menu updated in 6.2 cvs to grey-out the d.rast.edit entry as it
> won't work:
> 
> "guarantee_xmon; term d.rast.edit" needs a d.rast call in between. We
> could write a wrapper script for this, but it's ugly (see discussions
> about d.path_wrapper.sh), especially when you consider the zooming
> problems.
> 
> d.rast.edit will still work from the command line, with advice:
> 
> d.mon x0
g.region rast=mapname
> d.rast mapname
> d.rast.edit


In 6.2 cvs I've now changed it to be a bit more helpful. It now pops up
a message giving the above advice.



Hamish

From woklist at kyngchaos.com  Wed May  2 05:38:44 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Wed May  2 05:39:23 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17975.62700.469950.591439@cerise.gclements.plus.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
	<17975.62700.469950.591439@cerise.gclements.plus.com>
Message-ID: <97D61CF6-36DC-46A7-BEB5-499332C5462B@kyngchaos.com>

On May 1, 2007, at 9:18 PM, Glynn Clements wrote:

> William Kyngesburye wrote:
>
>> I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is
>> present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and
>> below) it was a beta and is not available for download any more, as
>> far as I can tell.  I think the betas must be where fontconfig wasn't
>> a part of Apple's X11 package (and I'm sure it wasn't at first).
>>
>> So, using fc-list on OSX, if it's available, for mkftcap is
>> reasonable, for now.
>
> Is it possible to filter any non-TrueType fonts from the output? Or
> are there not enough TrueType fonts to worry about?
>
I'd say all are TT fonts.  The problem is the mix of font packaging  
and file extensions, or lack thereof.

Though, FreeType is easily built with support for all types of fonts  
and font packages (my FT framework build supports all) - TT & PS (&  
others), and nix/pc flat file, Mac resource font, dfont & otf packages.

I'm a bit puzzled by the fixation on TT fonts for FreeType support.   
Shouldn't the text display commands be able to use whatever types of  
fonts that are supported by the installed build of FreeType?

For the usefulness of particular fonts, this appears to be the  
general pattern of fonts:

- resource fonts (TT) - MS fonts

- ttf - language support fonts, so limited usefulness, but there  
appears to be a couple general use fonts

- dfont (TT) - where most of the useful fonts are, besides the MS  
fonts, including Helvetica, Times and a collection of other fonts,  
but also includes some language support fonts

- otf (TT) - there are a few opentype fonts for Japanese and Chinese


So generally, what is supplied in OSX are all TT fonts, it's just  
that the ttf packaging has the least useful of them.

Then there is the other problem - resource fonts, dfonts and otf  
fonts can have, and most do in the OSX system, multiple faces per  
file.  The font display routines in GRASS need an option to specify a  
face in a font file, either by index number or name.  Otherwise most  
of the fonts included in OSX are of limited usefulness.

(Time to pop over to the tracker and make a feature request...)

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*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


From grass-coder at wald.intevation.org  Wed May  2 06:23:37 2007
From: grass-coder at wald.intevation.org (grass-coder@wald.intevation.org)
Date: Wed May  2 06:23:46 2007
Subject: [GRASS-dev] [grass-code R][388] freetype display needs to support
	multiple faces in a font file
Message-ID: <20070502042337.46FE019F5FFA@pyrosoma.intevation.org>

code R item #388, was opened at 2007-05-01 23:23
Status: Open
Priority: 3
Submitted By: William Kyngesburye (kyngchaos)
Assigned to: Nobody (None)
Summary: freetype display needs to support multiple faces in a font file 
Issue status: None
GRASS component: display
Operating system: MacOS X
Operating system version: any


Initial Comment:
Some font packages can contain multiple faces (styles) in a single file.  This includes, on OSX resource(suitcase) fonts and dfonts, and on any platform otf fonts.  Most of the useful fonts included in OSX have multiple faces in a font file.

FreeType display routines and commands need to support specifying a face within a font file, either by index number or name.  If used without a face, FT uses the first face found in a file.  This is not guaranteed to be what might be expected, such as a plain style.  And of course, none of the other styles, or faces, in the font can be used.

An additional useful tool would be a command to return info on a font file, such as the faces in the file and their index numbers, maybe the type of font (TT, PS or others).  d.freetype.info maybe?


----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=188&aid=388&group_id=21

From michael.barton at asu.edu  Wed May  2 06:29:25 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 06:29:53 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17975.62700.469950.591439@cerise.gclements.plus.com>
Message-ID: <C25D61B5.21944%michael.barton@asu.edu>

I tried various fonts randomly on my Mac without regard to extension and (so
far) all of them worked. So I assume that they are TrueType or FreeType
compatible in some way.

Michael


On 5/1/07 7:18 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> William Kyngesburye wrote:
> 
>> I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is
>> present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and
>> below) it was a beta and is not available for download any more, as
>> far as I can tell.  I think the betas must be where fontconfig wasn't
>> a part of Apple's X11 package (and I'm sure it wasn't at first).
>> 
>> So, using fc-list on OSX, if it's available, for mkftcap is
>> reasonable, for now.
> 
> Is it possible to filter any non-TrueType fonts from the output? Or
> are there not enough TrueType fonts to worry about?
> 
> We can probably tolerate a few bogus entries in an auto-generated
> freetypecap file; the user can always remove entries which don't work.
> However, on my system, "fc-list :outline file" generates 102 entries;
> 51 are .ttf files and 51 are .pfa/.pfb files, which is too high a
> signal-to-noise ratio.
> 
> That doesn't matter on Linux, as I can just ignore anything which
> doesn't have a .ttf extension. For OSX, we'll need to find some other
> way unless the number of false positives in the original fc-list
> output is low.

__________________________________________
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 at asu.edu  Wed May  2 06:40:45 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 06:41:43 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <97D61CF6-36DC-46A7-BEB5-499332C5462B@kyngchaos.com>
Message-ID: <C25D645D.21946%michael.barton@asu.edu>

This is sounding more encouraging. If there is a way to dependably use
fc-list in the new freetypecap script, along with scanning directories for
*.ttf files, then it can be pretty representative of available fonts on a
system. I suppose then, that a user could manually add to the freetypecap
file if there are other fonts in other locations that he/she wanted to use
for default display fonts. In this case, we could indeed have a scrolled
list box of fonts (many) and not worry about a file browser.

Michael


On 5/1/07 8:38 PM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

> On May 1, 2007, at 9:18 PM, Glynn Clements wrote:
> 
>> William Kyngesburye wrote:
>> 
>>> I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is
>>> present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and
>>> below) it was a beta and is not available for download any more, as
>>> far as I can tell.  I think the betas must be where fontconfig wasn't
>>> a part of Apple's X11 package (and I'm sure it wasn't at first).
>>> 
>>> So, using fc-list on OSX, if it's available, for mkftcap is
>>> reasonable, for now.
>> 
>> Is it possible to filter any non-TrueType fonts from the output? Or
>> are there not enough TrueType fonts to worry about?
>> 
> I'd say all are TT fonts.  The problem is the mix of font packaging
> and file extensions, or lack thereof.
> 
> Though, FreeType is easily built with support for all types of fonts
> and font packages (my FT framework build supports all) - TT & PS (&
> others), and nix/pc flat file, Mac resource font, dfont & otf packages.
> 
> I'm a bit puzzled by the fixation on TT fonts for FreeType support.
> Shouldn't the text display commands be able to use whatever types of
> fonts that are supported by the installed build of FreeType?
> 
> For the usefulness of particular fonts, this appears to be the
> general pattern of fonts:
> 
> - resource fonts (TT) - MS fonts
> 
> - ttf - language support fonts, so limited usefulness, but there
> appears to be a couple general use fonts
> 
> - dfont (TT) - where most of the useful fonts are, besides the MS
> fonts, including Helvetica, Times and a collection of other fonts,
> but also includes some language support fonts
> 
> - otf (TT) - there are a few opentype fonts for Japanese and Chinese
> 
> 
> So generally, what is supplied in OSX are all TT fonts, it's just
> that the ttf packaging has the least useful of them.
> 
> Then there is the other problem - resource fonts, dfonts and otf
> fonts can have, and most do in the OSX system, multiple faces per
> file.  The font display routines in GRASS need an option to specify a
> face in a font file, either by index number or name.  Otherwise most
> of the fonts included in OSX are of limited usefulness.
> 
> (Time to pop over to the tracker and make a feature request...)
> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*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
> 
> 

__________________________________________
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 at asu.edu  Wed May  2 07:50:59 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 07:51:21 2007
Subject: [GRASS-dev] problems with mkftcap
Message-ID: <C25D74D4.2194B%michael.barton@asu.edu>

I just updated, did a make distclean, and recompiled GRASS 6.3.

mkftcap is  not working on my Mac Intel MacBook Pro (OS X 4.9)

When I compiled, there was an error in compiling mkftcap. I changed to the
mkftcap directory and ran make and it compiled without apparent error. But
when I try to run it, I get an error. I list all below. My freetypecap file
is empty.

Michael

***************************ORIGINAL ERROR WITH MAKE

mkftcap
if [ ! -d 
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/scripts ]; then
mkdir /Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/scripts;
fi
/usr/bin/install -c  mkftcap
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/scripts/mkftcap
GISRC=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/demolocat
ion/.grassrc63 
GISBASE=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1
PATH="/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/bin:$PATH
" 
DYLD_LIBRARY_PATH="/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.
9.1/bin:/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/lib:"
LC_ALL=C 
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/scripts/mkftcap
--html-description | grep -v '</body>\|</html>' > mkftcap.tmp.html ; true
find: -printf: unknown expression primary
find: -printf: unknown expression primary
find: -printf: unknown expression primary
find: -printf: unknown expression primary
mkdir -p 
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/docs/html
mv -f mkftcap.tmp.html
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/docs/html/mkftc
ap.html
for file in  *.png *.jpg ; do \
        head -n 1 $file | grep '^#!' > /dev/null ; \
        if [ $? -ne 0 ] ; then \
           /usr/bin/install -c  -m 644 $file
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/docs/html ; \
        fi \
        done 2> /dev/null ; true
GISRC=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/demolocat
ion/.grassrc63 
GISBASE=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1
PATH=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/bin:$PATH
DYLD_LIBRARY_PATH="/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.
9.1/lib:" g.parser -t mkftcap | sed s/\"/\\\\\"/g | sed 's/.*/_("&")/' >
../../locale/scriptstrings/mkftcap_to_translate.c ; true
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/scripts/mkftcap
> 
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/etc/freetypecap
You must be in GRASS GIS to run this program
make[2]: *** 
[/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/etc/freetypeca
p] Error 1

***************************RESULTS AFTER RUNING MAKE IN THE MKFTCAP
DIRECTORY

cmb-MBP:~/grass_dev/grass6 cmbarton$ cd ./tools/mkftcap
cmb-MBP:~/grass_dev/grass6/tools/mkftcap cmbarton$ make
GISRC=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/demolocat
ion/.grassrc63 
GISBASE=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1
PATH="/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/bin:$PATH
" 
DYLD_LIBRARY_PATH="/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.
9.1/bin:/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/lib:"
LC_ALL=C 
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/scripts/mkftcap
--html-description | grep -v '</body>\|</html>' > mkftcap.tmp.html ; true
find: -printf: unknown expression primary
find: -printf: unknown expression primary
find: -printf: unknown expression primary
find: -printf: unknown expression primary
mkdir -p 
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/docs/html
mv -f mkftcap.tmp.html
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/docs/html/mkftc
ap.html
for file in  *.png *.jpg ; do \
        head -n 1 $file | grep '^#!' > /dev/null ; \
        if [ $? -ne 0 ] ; then \
           /usr/bin/install -c  -m 644 $file
/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/docs/html ; \
        fi \
        done 2> /dev/null ; true
GISRC=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/demolocat
ion/.grassrc63 
GISBASE=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1
PATH=/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.9.1/bin:$PATH
DYLD_LIBRARY_PATH="/Users/cmbarton/grass_dev/grass6/dist.i686-apple-darwin8.
9.1/lib:" g.parser -t mkftcap | sed s/\"/\\\\\"/g | sed 's/.*/_("&")/' >
../../locale/scriptstrings/mkftcap_to_translate.c ; true


***************************ERROR ON RUNING MKFTCAP

GRASS 6.3.cvs (spearfish60_test):~ > mkftcap
find: -printf: unknown expression primary
find: -printf: unknown expression primary
find: -printf: unknown expression primary
find: -printf: unknown expression primary

__________________________________________
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070501/8b9361a0/attachment.html
From hamish_nospam at yahoo.com  Wed May  2 08:01:01 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed May  2 08:01:22 2007
Subject: [GRASS-dev] symbol rotation is go
In-Reply-To: <17968.55731.74064.993514@cerise.gclements.plus.com>
References: <20070427015100.1430c1e9.hamish_nospam@yahoo.com>
	<17968.55731.74064.993514@cerise.gclements.plus.com>
Message-ID: <20070502180101.7f70e0e0.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> > I have just added a new libgis function: G_rotate_around_pt() in
> > 6.3cvs.
> >  (make distclean, yet again)
> > 
> > It rotates a point around a given center coord by a given angle.
> 
> I would suggest an alternate version:
> 
> void G_rotate_around_point(double X0, double Y0, double *X1, double *Y1, double angle) {
> 	double dx = *X1 - X0;
> 	double dy = *X1 - X0;
> 	double c = cos(D2R(angle));
> 	double s = sin(D2R(angle));
> 	double dx1 = dx * c - dy * s;
> 	double dy1 = dx * s + dy * c;
> 
> 	*X1 = X0 + dx1;
> 	*Y1 = Y0 + dy1;
> }


Hi,

committed, with a minor fix:
 -double dy = *X1 - X0;
 +double dy = *Y1 - Y0;


thanks,
Hamish

From glynn at gclements.plus.com  Wed May  2 08:57:42 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed May  2 08:58:23 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <97D61CF6-36DC-46A7-BEB5-499332C5462B@kyngchaos.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
	<17975.62700.469950.591439@cerise.gclements.plus.com>
	<97D61CF6-36DC-46A7-BEB5-499332C5462B@kyngchaos.com>
Message-ID: <17976.13926.328258.937247@cerise.gclements.plus.com>


William Kyngesburye wrote:

> >> I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is
> >> present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and
> >> below) it was a beta and is not available for download any more, as
> >> far as I can tell.  I think the betas must be where fontconfig wasn't
> >> a part of Apple's X11 package (and I'm sure it wasn't at first).
> >>
> >> So, using fc-list on OSX, if it's available, for mkftcap is
> >> reasonable, for now.
> >
> > Is it possible to filter any non-TrueType fonts from the output? Or
> > are there not enough TrueType fonts to worry about?
> 
> I'd say all are TT fonts.  The problem is the mix of font packaging  
> and file extensions, or lack thereof.
> 
> Though, FreeType is easily built with support for all types of fonts  
> and font packages (my FT framework build supports all) - TT & PS (&  
> others), and nix/pc flat file, Mac resource font, dfont & otf packages.
> 
> I'm a bit puzzled by the fixation on TT fonts for FreeType support.   
> Shouldn't the text display commands be able to use whatever types of  
> fonts that are supported by the installed build of FreeType?

Yes. However, that isn't all of the fonts which fc-list shows. E.g.
fc-list shows the PCF fonts, but those don't work with R_font(). Type1
fonts work.

> For the usefulness of particular fonts, this appears to be the  
> general pattern of fonts:
> 
> - resource fonts (TT) - MS fonts
> 
> - ttf - language support fonts, so limited usefulness, but there  
> appears to be a couple general use fonts
> 
> - dfont (TT) - where most of the useful fonts are, besides the MS  
> fonts, including Helvetica, Times and a collection of other fonts,  
> but also includes some language support fonts
> 
> - otf (TT) - there are a few opentype fonts for Japanese and Chinese
> 
> So generally, what is supplied in OSX are all TT fonts, it's just  
> that the ttf packaging has the least useful of them.

In that case, you can probably just convert the entire output from
"fc-list : file" to a freetypecap file.

> Then there is the other problem - resource fonts, dfonts and otf  
> fonts can have, and most do in the OSX system, multiple faces per  
> file.  The font display routines in GRASS need an option to specify a  
> face in a font file, either by index number or name.  Otherwise most  
> of the fonts included in OSX are of limited usefulness.

That's easy enough to implement.

One option is to pick an arbitrary character to separate the index
from the filename. If the path ends with that character followed by a
number, the number is the index.

That has the advantage that only the lowest level of the driver code
needs to change (draw_main(), in lib/driver/text3.c; the function
which calls FT_New_Face()).

Obviously, alphanumerics are out, as are CR, LF, colon, dot, slash and
backslash; also, space, dash and underscore are all too common. 
Characters outside the range 32-126 are also problematic. That
basically means an ASCII punctuation character.

A vertical bar (ASCII 124) might be a good choice. It isn't legal in
Windows filenames (all of \/:*?"<>| are prohibited); I use it a field
separator in text files (comma isn't that uncommon in filenames), and
I've never had a problem due to it occurring in a filename.

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

From glynn at gclements.plus.com  Wed May  2 09:02:34 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed May  2 09:02:44 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <C25D74D4.2194B%michael.barton@asu.edu>
References: <C25D74D4.2194B%michael.barton@asu.edu>
Message-ID: <17976.14218.356268.260031@cerise.gclements.plus.com>


Michael Barton wrote:

> I just updated, did a make distclean, and recompiled GRASS 6.3.
> 
> mkftcap is  not working on my Mac Intel MacBook Pro (OS X 4.9)
> 
> When I compiled, there was an error in compiling mkftcap. I changed to the
> mkftcap directory and ran make and it compiled without apparent error. But
> when I try to run it, I get an error. I list all below. My freetypecap file
> is empty.

mkftcap is just a script.

> GRASS 6.3.cvs (spearfish60_test):~ > mkftcap
> find: -printf: unknown expression primary
> find: -printf: unknown expression primary
> find: -printf: unknown expression primary
> find: -printf: unknown expression primary

The command in question is:

	find "$dir" -type f -iname '*.ttf' -printf '%f:%p:utf-8:\n'

Does OSX have a command called "find" which isn't the standard Unix
"find" command?

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

From michael.barton at asu.edu  Wed May  2 09:05:39 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 09:05:55 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <17976.14218.356268.260031@cerise.gclements.plus.com>
Message-ID: <C25D8653.21956%michael.barton@asu.edu>

I *thought* it was a script, which is why my results seemed very strange.


On 5/2/07 12:02 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> The command in question is:
> 
> find "$dir" -type f -iname '*.ttf' -printf '%f:%p:utf-8:\n'
> 
> Does OSX have a command called "find" which isn't the standard Unix
> "find" command?
> 
find
usage: find [-H | -L | -P] [-EXdsx] [-f file] [file ...] [expression]

Is this different from the standard?

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 grass-codei at wald.intevation.org  Wed May  2 09:51:29 2007
From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org)
Date: Wed May  2 09:51:34 2007
Subject: [GRASS-dev] [grass-code I][389] problem with r.what at the
	longitudinal edge 
Message-ID: <20070502075129.DD5DA19F5FFA@pyrosoma.intevation.org>

code I item #389, was opened at 2007-05-02 16:51
Status: Open
Priority: 3
Submitted By: Etsushi Kato (ekato)
Assigned to: Nobody (None)
Summary: problem with r.what at the longitudinal edge  
Issue type: module bug
Issue status: None
GRASS version: 6.2.1
GRASS component: raster
Operating system: Linux
Operating system version: Fedora Core 6
GRASS CVS checkout date, if applies (YYMMDD): 070414


Initial Comment:
I get null '*' value when specifying longitude edge with grass6.2.2cvs (20070414) compiled with Fedora Core 6.

r.what input=mod12 east_north=180W,55N
** note ** 180W 55N is outside your current window
180W|55N||*

If I change r.what/main.c as in the attached file, I get

> r.what input=mod12 east_north=180W,55N
180W|55N||0


I assume this is related to Fedora Core 6's compiler bug or optimization thing. However, I think it is safe to cast the dcol to int in this case.


Here is my system information.

$ cat /proc/version
Linux version 2.6.20-1.2933.fc6 (brewbuilder@hs20-bc2-4.build.redhat.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Mon Mar 19 11:38:26 EDT 2007

$ gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.40GHz
stepping        : 1
cpu MHz         : 3391.747
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 3
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor ds_cpl cid xtpr
bogomips        : 6787.36
clflush size    : 64

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.40GHz
stepping        : 1
cpu MHz         : 3391.747
cache size      : 1024 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 1
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 3
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc pni monitor ds_cpl cid xtpr
bogomips        : 6782.97
clflush size    : 64


----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=204&aid=389&group_id=21

From glynn at gclements.plus.com  Wed May  2 10:00:03 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed May  2 10:00:07 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <C25D8653.21956%michael.barton@asu.edu>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
Message-ID: <17976.17667.172986.583275@cerise.gclements.plus.com>


Michael Barton wrote:

> > The command in question is:
> > 
> > find "$dir" -type f -iname '*.ttf' -printf '%f:%p:utf-8:\n'
> > 
> > Does OSX have a command called "find" which isn't the standard Unix
> > "find" command?
> > 
> find
> usage: find [-H | -L | -P] [-EXdsx] [-f file] [file ...] [expression]
> 
> Is this different from the standard?

No, that's the right command; it appears -printf is a GNU extension.

That shouldn't be a problem in this case; using:

	find "$dir" -type f -iname '*.ttf' -print | sed 's!^\(.*\)/\(.*\)$!\2:\1/\2:utf-8:!'

should do the same job.

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

From glynn at gclements.plus.com  Wed May  2 10:10:51 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed May  2 10:10:57 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17976.13926.328258.937247@cerise.gclements.plus.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
	<17975.62700.469950.591439@cerise.gclements.plus.com>
	<97D61CF6-36DC-46A7-BEB5-499332C5462B@kyngchaos.com>
	<17976.13926.328258.937247@cerise.gclements.plus.com>
Message-ID: <17976.18315.188453.944179@cerise.gclements.plus.com>


Glynn Clements wrote:

> > I'm a bit puzzled by the fixation on TT fonts for FreeType support.   
> > Shouldn't the text display commands be able to use whatever types of  
> > fonts that are supported by the installed build of FreeType?
> 
> Yes. However, that isn't all of the fonts which fc-list shows. E.g.
> fc-list shows the PCF fonts, but those don't work with R_font(). Type1
> fonts work.

FWIW, I've extended the mkftcap script to accept .pfa and .pfb files.

> In that case, you can probably just convert the entire output from
> "fc-list : file" to a freetypecap file.

In addition to scanning directories for files with specific
extensions, mkftcap also uses the output from "fc-list :outline",
which should find all of the OSX fonts.

> > Then there is the other problem - resource fonts, dfonts and otf  
> > fonts can have, and most do in the OSX system, multiple faces per  
> > file.  The font display routines in GRASS need an option to specify a  
> > face in a font file, either by index number or name.  Otherwise most  
> > of the fonts included in OSX are of limited usefulness.
> 
> That's easy enough to implement.
> 
> One option is to pick an arbitrary character to separate the index
> from the filename. If the path ends with that character followed by a
> number, the number is the index.
> 
> That has the advantage that only the lowest level of the driver code
> needs to change (draw_main(), in lib/driver/text3.c; the function
> which calls FT_New_Face()).
> 
> Obviously, alphanumerics are out, as are CR, LF, colon, dot, slash and
> backslash; also, space, dash and underscore are all too common. 
> Characters outside the range 32-126 are also problematic. That
> basically means an ASCII punctuation character.
> 
> A vertical bar (ASCII 124) might be a good choice. It isn't legal in
> Windows filenames (all of \/:*?"<>| are prohibited); I use it a field
> separator in text files (comma isn't that uncommon in filenames), and
> I've never had a problem due to it occurring in a filename.

The updated mkftcap script should cope with multi-font files; the part
which uses fc-list outputs the index, and should append it to the path
if it isn't zero. I can't test this, as none of my font files have
more than one font.

Also, I haven't updated the driver code to handle indices yet.

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

From glynn at gclements.plus.com  Wed May  2 10:40:08 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed May  2 10:40:12 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17976.18315.188453.944179@cerise.gclements.plus.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
	<17975.62700.469950.591439@cerise.gclements.plus.com>
	<97D61CF6-36DC-46A7-BEB5-499332C5462B@kyngchaos.com>
	<17976.13926.328258.937247@cerise.gclements.plus.com>
	<17976.18315.188453.944179@cerise.gclements.plus.com>
Message-ID: <17976.20072.823682.704770@cerise.gclements.plus.com>


Glynn Clements wrote:

> The updated mkftcap script should cope with multi-font files; the part
> which uses fc-list outputs the index, and should append it to the path
> if it isn't zero. I can't test this, as none of my font files have
> more than one font.
> 
> Also, I haven't updated the driver code to handle indices yet.

I've updated the driver, although I can't actually test it with
multi-font files.

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

From peter.loewe at gmx.de  Wed May  2 10:40:54 2007
From: peter.loewe at gmx.de (=?iso-8859-1?Q?=22Peter_L=F6we=22?=)
Date: Wed May  2 10:40:58 2007
Subject: [GRASS-dev] Access of remote Mysql database ?
In-Reply-To: <200705020751.l427pgtt019066@grass.itc.it>
References: <200705020751.l427pgtt019066@grass.itc.it>
Message-ID: <20070502084054.300920@gmx.net>

Dear all,

the problem I am dealing seems currently not to be covered in the manuals:

How to hook up a remote mysql-database which requires a login ?

There is a mysql-database "the_database" with a table "the_table" on a remote computer "dbserver.foo.org", which can be accessed by a db-user  "joshua" (password: swordfish).

The goal is to establish a layer 2 link between this table (let the column be "id") similar to:

v.db.connect -o map=my_map   table=the_table layer=2 key=id driver=mysql database="host=dbserver.foo.org,dbname=the_database" key=id

Unfortunately db.login does not provide means to enter a remote server.

Is there a known workaround like hacking the .grasslogin6 -file ?

Any help would be much appreciated,
Peter 
-- 
Dr. Peter L?we

Diplom-Geograph

<loewe@geomancers.net>
<peter.loewe@gmx.de>





"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

From tutey at o2.pl  Wed May  2 10:45:31 2007
From: tutey at o2.pl (Maciej Sieczka)
Date: Wed May  2 10:45:35 2007
Subject: [GRASS-dev] d.rast.edit: can't remove some temp files
Message-ID: <46384FAB.7020307@o2.pl>

Hi,

The tcl/tk d.rast.edit in current 6.3 CVS prints following info to the
output after "Exit":

Raster map <tmp.d.rast.edit> not found
Raster map <tmp.d.rast.edit> not found
<tmp.d.rast.edit> nothing removed
<tmp.d.rast.edit> nothing removed

Is that OK?

Maciek

From stephan.holl at intevation.de  Wed May  2 11:00:55 2007
From: stephan.holl at intevation.de (Stephan Holl)
Date: Wed May  2 11:00:58 2007
Subject: [GRASS-dev] Access of remote Mysql database ?
In-Reply-To: <20070502084054.300920@gmx.net>
References: <200705020751.l427pgtt019066@grass.itc.it>
	<20070502084054.300920@gmx.net>
Message-ID: <20070502110055.4259a642@thoe.hq.intevation.de>

Hello Peter,

"Peter L?we" <peter.loewe@gmx.de>, [20070502 - 10:40:54]

> Dear all,
> 
> the problem I am dealing seems currently not to be covered in the
> manuals:
> 
> How to hook up a remote mysql-database which requires a login ?
> 
> There is a mysql-database "the_database" with a table "the_table" on
> a remote computer "dbserver.foo.org", which can be accessed by a
> db-user  "joshua" (password: swordfish).
> 
> The goal is to establish a layer 2 link between this table (let the
> column be "id") similar to:
> 
> v.db.connect -o map=my_map   table=the_table layer=2 key=id
> driver=mysql database="host=dbserver.foo.org,dbname=the_database"
> key=id

what about (untested):
v.db.connect -o map=my_map   table=the_table layer=2 key=id
driver=mysql
database="host=dbserver.foo.org,dbname=the_database,user=joshua,password=swordfish"
key=id

> 
> Unfortunately db.login does not provide means to enter a remote
> server.
> 
> Is there a known workaround like hacking the .grasslogin6 -file ?
> 
> Any help would be much appreciated,

Best

	Stephan

-- 
Stephan Holl <stephan.holl@intevation.de>, http://intevation.de/~stephan
Tel: +49 (0)541-33 50 8 32 | Intevation GmbH | AG Osnabr?ck - HR B 18998
Gesch?ftsf?hrer:  Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner

From neteler at itc.it  Wed May  2 11:02:58 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 11:03:00 2007
Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar?
In-Reply-To: <C25D03EA.218FC%michael.barton@asu.edu>
References: <20070501152503.GB19013@bartok.itc.it>
	<C25D03EA.218FC%michael.barton@asu.edu>
Message-ID: <20070502090258.GA27153@bartok.itc.it>

It seems to be slightly more complicated (I tried), so I
leave it for now.

Markus

On Tue, May 01, 2007 at 02:49:14PM -0700, Michael Barton wrote:
> If it does extended stats now and the output is the same, it should be an
> easy switch.
> 
> Michael
> 
> 
> On 5/1/07 8:25 AM, "Markus Neteler" <neteler@itc.it> wrote:
> 
> > Hi,
> > 
> > can we safely change v.univar.sh -> v.univar in d.vect.thematic?
> > This might speed up calculations...
> > 
> > Markus
> > 
> > 
> 
> __________________________________________
> 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
> 
> 

-- 
Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
FBK-irst -  Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy

From neteler at itc.it  Wed May  2 11:04:36 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 11:04:39 2007
Subject: [GRASS-dev] Streams extraction from streams map
In-Reply-To: <20070501103714.GA19013@bartok.itc.it>
References: <20070501103714.GA19013@bartok.itc.it>
Message-ID: <20070502090436.GB27153@bartok.itc.it>

On Tue, May 01, 2007 at 12:37:15PM +0200, Markus Neteler wrote:
> Hi,
> 
> I have a network of streams (say, Spearfish or better the new
> NC data set at http://mpa.itc.it/grasstutor/data_menu3rd.phtml )
> and want to extract a single stream system. Names are lacking,
> is there any trick to extract topologically connected lines
> into a new map?

Probably we need some equivalent to the "sides" operator in
v.to.db (which tells you the cats of the left and right polygon).
Some magic which finds the lines which are connected and writes
out some related attribute(s).

Ideas welcome,
Markus

From neteler at itc.it  Wed May  2 11:05:55 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 11:05:56 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17973.47593.760354.352347@cerise.gclements.plus.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
Message-ID: <20070502090554.GC27153@bartok.itc.it>

On Mon, Apr 30, 2007 at 10:42:01AM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > >>> Bear in mind that the raster map is always opaque, so it will obscure
> > >>> anything which is drawn beneath it.
> > >>>       
> > >> Markus:
> > >>     
> > >>> That's exactly what I need: in my case the raster map contains a few
> > >>> cells only, but I need it on top to not be covered by vector contour
> > >>> lines etc.
> > >>>       
> > >> ..
> > >>     
> > >>> Maybe ps.map's raster command needs an additional parameter "ontop" or
> > >>> something like this? Hacking C code as Hamish suggests might be asked
> > >>> too much for the average user.
> > >>>       
> > >> are the null areas solid white, not transparent?
> > >>     
> > >
> > > They are transparent. All fine.
> > Of course I was too hasty. Nothing fine.
> > > Just that the tons of contour
> > > lines cover the scarse raster areas in the raster maps. That's
> > > why I need them on top of the dense contour lines.
> > >   
> > ... and it seems that NULL is not respected by ps.map (as you will know
> > already).
> 
> For masked images, you need to use the one-operand form of the "image"
> operator with an image dictionary; see the RASTERMASK procedure in
> lib/psdriver/psdriver.ps for an example. This requires support for
> level 3 PostScript (present in GhostScript for a few years now; I
> don't know about printers).
> 
> Regarding the generation of the image data (ps/ps.map/ps_raster.c), a
> masked image needs 2 (mono) or 4 (RGB) components, with the mask byte
> first (i.e. AARRGGBB); see lib/psdriver/Raster.c.

I am afraid that I am not able to implement this.

Markus

From neteler at itc.it  Wed May  2 11:14:34 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 11:14:35 2007
Subject: [GRASS-dev] broken API
In-Reply-To: <463072B6.9090209@faunalia.it>
References: <463072B6.9090209@faunalia.it>
Message-ID: <20070502091433.GD27153@bartok.itc.it>

On Thu, Apr 26, 2007 at 11:36:54AM +0200, Paolo Cavallini wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all.
> While compiling qgis, I noticed that GRASS API has been broken:
> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/include/version.h.in.diff?r1=1.4&r2=1.5
> As a result, QGIS can no longer be compiled with GRASS support.

https://svn.qgis.org/trac/ticket/712

It has been fixed last night in QGIS SVN HEAD.
You need to fixed GRASS-GDAL-Plugin from GDAL SVN HEAD, too
(for raster support). A new plugin will be released soon:
http://trac.osgeo.org/gdal/ticket/1587

Apparently things are operational again.

Markus

From neteler at itc.it  Wed May  2 11:18:14 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 11:18:16 2007
Subject: [GRASS-dev] Access of remote Mysql database ?
In-Reply-To: <20070502084054.300920@gmx.net>
References: <200705020751.l427pgtt019066@grass.itc.it>
	<20070502084054.300920@gmx.net>
Message-ID: <20070502091813.GE27153@bartok.itc.it>

On Wed, May 02, 2007 at 10:40:54AM +0200, "Peter L?we" wrote:
> Dear all,
> 
> the problem I am dealing seems currently not to be covered in the manuals:

(so we should document it once figured out)
 
> How to hook up a remote mysql-database which requires a login ?
> 
> There is a mysql-database "the_database" with a table "the_table" on a remote computer "dbserver.foo.org", which can be accessed by a db-user  "joshua" (password: swordfish).
> 
> The goal is to establish a layer 2 link between this table (let the column be "id") similar to:
> 
> v.db.connect -o map=my_map   table=the_table layer=2 key=id driver=mysql database="host=dbserver.foo.org,dbname=the_database" key=id
> 
> Unfortunately db.login does not provide means to enter a remote server.

db.login is not responible for that. This would be done with db.connect:

g.manual db.connect
-> MySQL (external server)

Does that example not work for you?

If you just want to connect the individual map, v.db.connect should be right.
Indeed, an example is missing. Please tell us once you have a working
solution.

Markus

From peter.loewe at gmx.de  Wed May  2 11:29:15 2007
From: peter.loewe at gmx.de (=?iso-8859-1?Q?=22Peter_L=F6we=22?=)
Date: Wed May  2 11:29:17 2007
Subject: [GRASS-dev] Access of remote Mysql database ?
In-Reply-To: <20070502110055.4259a642@thoe.hq.intevation.de>
References: <200705020751.l427pgtt019066@grass.itc.it>
	<20070502084054.300920@gmx.net>
	<20070502110055.4259a642@thoe.hq.intevation.de>
Message-ID: <20070502092915.312090@gmx.net>

Hello Stephan,

unfortunately this does not work:
 ---------------

GRASS 6.3.cvs (ETM_POTSDAM):/usr/local/share/locations > v.db.connect -o map=my_map table=the_table layer=2 key=id driver=mysql database="host=dbserver.foo.org,dbname=the_database,user=joshua,password=swordfish" key=id
WARNING: 'user' in database definition is not supported, use db.login
WARNING: 'password' in database definition is not supported, use db.login
DBMI-MySQL driver error:
Cannot connect to MySQL: Access denied for user 'Peter'@'123.gfz-potsdam.de' (using password: NO)

WARNING: Cannot open database
         'host=dbserver.foo.org,dbname=the_database,user=joshua,password=swordfish'
WARNING: Cannot open database
         'host=dbserver.foo.org,dbname=the_database,user=joshua,password=swordfish'
         by driver 'mysql'
ERROR: Table <the_table> does not exist in database
       <host=dbserver.foo.org,dbname=the_database,user=joshua,password=swordfish>
----------------

Apparently there are two things causing trouble:
1) the login is not recognised - "joshua" is ignored, instead "peter@123" without a password is used. I already tried db.login so there is a .grasslogin6 file, but this lacks the link to the remote box where the db is kept (but .grasslogin6 is not looked up at this point anyway...)
2) something goes wrong when the database string is processed (last line of error messages <host=...> )

Comments, anyone ?

:-/
Peter



>> Dear all,
>> 
>> the problem I am dealing seems currently not to be covered in the
>> manuals:
>> 
>> How to hook up a remote mysql-database which requires a login ?
>> 
>> There is a mysql-database "the_database" with a table "the_table" on
>> a remote computer "dbserver.foo.org", which can be accessed by a
>> db-user  "joshua"(password: swordfish).
>> 
>> The goal is to establish a layer 2 link between this table (let the
>> column be "id") similar to:
>> 
>> v.db.connect -o map=my_map   table=the_table layer=2 key=id
>> driver=mysql database="host=dbserver.foo.org,dbname=the_database"
>> key=id
>
>what about (untested):
>v.db.connect -o map=my_map   table=the_table layer=2 key=id
>driver=mysql
>database="host=dbserver.foo.org,dbname=the_database,user=joshua,password=swordfish"
>key=id
>
>> 
>> Unfortunately db.login does not provide means to enter a remote
>> server.
>> 
>> Is there a known workaround like hacking the .grasslogin6 -file 

-- 
Dr. Peter L?we

Diplom-Geograph

<loewe@geomancers.net>
<peter.loewe@gmx.de>





"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

From glynn at gclements.plus.com  Wed May  2 12:36:15 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed May  2 12:36:18 2007
Subject: [GRASS-dev] d.rast.edit: can't remove some temp files
In-Reply-To: <46384FAB.7020307@o2.pl>
References: <46384FAB.7020307@o2.pl>
Message-ID: <17976.27039.237519.236194@cerise.gclements.plus.com>


Maciej Sieczka wrote:

> The tcl/tk d.rast.edit in current 6.3 CVS prints following info to the
> output after "Exit":
> 
> Raster map <tmp.d.rast.edit> not found
> Raster map <tmp.d.rast.edit> not found
> <tmp.d.rast.edit> nothing removed
> <tmp.d.rast.edit> nothing removed
> 
> Is that OK?

Yes. It always removes the temporary map on exit, regardless of
whether or not it used it.

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

From Agustin.Diez at uv.es  Wed May  2 12:48:44 2007
From: Agustin.Diez at uv.es (Agustin Diez Castillo)
Date: Wed May  2 12:50:00 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17975.62700.469950.591439@cerise.gclements.plus.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
	<17975.62700.469950.591439@cerise.gclements.plus.com>
Message-ID: <9B06D8C9-102C-4827-846F-76668C83BE34@uv.es>

mdfind 'kMDItemContentType = "*truetype*"'
Finds all the truetype fonts on my Computer, even those inside an  
Application folder or on devices attached to it.
**************************************
/System/Library/Fonts/Apple LiGothic Medium.dfont
/System/Library/Fonts/AppleGothic.dfont
/System/Library/Fonts/Courier.dfont
/System/Library/Fonts/Geneva.dfont
/System/Library/Fonts/Helvetica.dfont
/System/Library/Fonts/Keyboard.dfont
/System/Library/Fonts/LastResort.dfont
/System/Library/Fonts/LucidaGrande.dfont
/System/Library/Fonts/Monaco.dfont
/System/Library/Fonts/Symbol.dfont
/System/Library/Fonts/Times.dfont
/System/Library/Fonts/ZapfDingbats.dfont
/System/Library/Fonts/?? Pro.ttf
/System/Library/Fonts/????.ttf
/System/Library/Fonts/????.ttf
/Library/Fonts/tt9830z_.ttf
/Library/Fonts/AmericanTypewriter.dfont
/Library/Fonts/Apple Chancery.dfont
/Library/Fonts/Apple Symbols.ttf
/Library/Fonts/Baskerville.dfont
/Library/Fonts/BigCaslon.dfont
/Library/Fonts/Chalkboard.ttf
/Library/Fonts/ChalkboardBold.ttf
/Library/Fonts/Cochin.dfont
/Library/Fonts/Copperplate.dfont
/Library/Fonts/Didot.dfont
/Library/Fonts/Futura.dfont
/Library/Fonts/GillSans.dfont
/Library/Fonts/HelveticaNeue.dfont
/Library/Fonts/Herculanum.dfont
/Library/Fonts/Hoefler Text.dfont
/Library/Fonts/MarkerFelt.dfont
/Library/Fonts/Apple LiSung Light.dfont
/Library/Fonts/BiauKai.dfont
/Library/Fonts/NISC18030.ttf
/Library/Fonts/?? Pro.ttf
/Library/Fonts/????.ttf
/Library/Fonts/????.ttf
/Library/Fonts/????.ttf
/Library/Fonts/#Gungseouche.dfont
/Library/Fonts/#HeadlineA.dfont
/Library/Fonts/#PCmyoungjo.dfont
/Library/Fonts/#Pilgiche.dfont
/Library/Fonts/AppleMyungjo.dfont
/Library/Fonts/AlBayan.ttf
/Library/Fonts/AlBayanBold.ttf
/Library/Fonts/ArialHB.ttf
/Library/Fonts/ArialHBBold.ttf
/Library/Fonts/Ayuthaya.ttf
/Library/Fonts/Baghdad.ttf
/Library/Fonts/CharcoalCY.dfont
/Library/Fonts/Corsiva.ttf
/Library/Fonts/CorsivaBold.ttf
/Library/Fonts/DecoTypeNaskh.ttf
/Library/Fonts/DevanagariMT.ttf
/Library/Fonts/DevanagariMTBold.ttf
/Library/Fonts/EuphemiaCASBold.ttf
/Library/Fonts/EuphemiaCASItalic.ttf
/Library/Fonts/EuphemiaCASRegular.ttf
/Library/Fonts/GenevaCY.dfont
/Library/Fonts/GujaratiMT.ttf
/Library/Fonts/GujaratiMTBold.ttf
/Library/Fonts/Gurmukhi.ttf
/Library/Fonts/HelveticaCY.dfont
/Library/Fonts/InaiMathi.ttf
/Library/Fonts/Krungthep.ttf
/Library/Fonts/Optima.dfont
/Library/Fonts/Papyrus.dfont
/Library/Fonts/Skia.dfont
/Library/Fonts/Zapfino.dfont
/System/Library/Fonts/Geeza Pro Bold.ttf
/System/Library/Fonts/Geeza Pro.ttf
/System/Library/Fonts/Osaka.dfont
/System/Library/Fonts/OsakaMono.dfont
/Library/Fonts/Kai.dfont
/System/Library/Fonts/Hei.dfont
/Library/Fonts/KufiStandarGK.ttf
/Library/Fonts/MshtakanBold.ttf
/Library/Fonts/MshtakanBoldOblique.ttf
/Library/Fonts/MshtakanOblique.ttf
/Library/Fonts/MshtakanRegular.ttf
/Library/Fonts/Nadeem.ttf
/Library/Fonts/NewPeninimMT.ttf
/Library/Fonts/NewPeninimMTBold.ttf
/Library/Fonts/NewPeninimMTBoldInclined.ttf
/Library/Fonts/NewPeninimMTInclined.ttf
/Library/Fonts/PlantagenetCherokee.ttf
/Library/Fonts/Raanana.ttf
/Library/Fonts/RaananaBold.ttf
/Library/Fonts/Sathu.ttf
/Library/Fonts/Silom.ttf
/Library/Fonts/Thonburi.ttf
/Applications/rsi/idl_6.2/resource/fonts/tt/tt0003m_.ttf
....
/Volumes/LaCieDisk/Users/Shared/cosas de Smigol/Library/Perl/5.8.1/ 
darwin-thread-multi-2level/VRML/fonts/Amrigoi.ttf
...
***************************************
+ 1000 fonts
and
mdls /Library/Fonts/Silom.ttf, writes the metadata
***********************
/Library/Fonts/Silom.ttf -------------
kMDItemAttributeChangeDate     = 2006-08-11 10:56:25 +0200
kMDItemContentCreationDate     = 2006-07-02 17:20:18 +0200
kMDItemContentModificationDate = 2006-07-02 17:20:18 +0200
kMDItemContentType             = "public.truetype-ttf-font"
kMDItemContentTypeTree         = (
     "public.truetype-ttf-font",
     "public.truetype-font",
     "public.font",
     "public.data",
     "public.item"
)
kMDItemCopyright               = "? 1992-2003 Apple Computer, Inc."
kMDItemDisplayName             = "Silom.ttf"
kMDItemFonts                   = (Silom)
kMDItemFSContentChangeDate     = 2006-07-02 17:20:18 +0200
kMDItemFSCreationDate          = 2006-07-02 17:20:18 +0200
kMDItemFSCreatorCode           = 0
kMDItemFSFinderFlags           = 0
kMDItemFSInvisible             = 0
kMDItemFSIsExtensionHidden     = 0
kMDItemFSLabel                 = 0
kMDItemFSName                  = "Silom.ttf"
kMDItemFSNodeCount             = 0
kMDItemFSOwnerGroupID          = 80
kMDItemFSOwnerUserID           = 0
kMDItemFSSize                  = 250996
kMDItemFSTypeCode              = 0
kMDItemID                      = 227671
kMDItemKind                    = "Windows TrueType font"
kMDItemVersion                 = "10.4d5e1"
***************************
On May 2, 2007, at 4:18 AM, Glynn Clements wrote:

>
> William Kyngesburye wrote:
>
>> I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is
>> present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and
>> below) it was a beta and is not available for download any more, as
>> far as I can tell.  I think the betas must be where fontconfig wasn't
>> a part of Apple's X11 package (and I'm sure it wasn't at first).
>>
>> So, using fc-list on OSX, if it's available, for mkftcap is
>> reasonable, for now.
>
> Is it possible to filter any non-TrueType fonts from the output? Or
> are there not enough TrueType fonts to worry about?
>
> We can probably tolerate a few bogus entries in an auto-generated
> freetypecap file; the user can always remove entries which don't work.
> However, on my system, "fc-list :outline file" generates 102 entries;
> 51 are .ttf files and 51 are .pfa/.pfb files, which is too high a
> signal-to-noise ratio.
>
> That doesn't matter on Linux, as I can just ignore anything which
> doesn't have a .ttf extension. For OSX, we'll need to find some other
> way unless the number of false positives in the original fc-list
> output is low.
>
> -- 
> Glynn Clements <glynn@gclements.plus.com>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070502/49c1e989/attachment-0001.html
From hamish_nospam at yahoo.com  Wed May  2 13:20:08 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed May  2 13:20:13 2007
Subject: [GRASS-dev] d.vect changes
Message-ID: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>

Hi,

I've just committed some changes to d.vect in CVS. of note:

bugfix: it wasn't calculating new x,y for symbols if colors were all
none. (potentially nasty, probably invisible so was benign?)


simplification: use D_symbol() to plot symbols. This changes how -c
random and rgb_column work on symbols. Now fill color is constant (ie
whatever fcolor= was set to) and line color changes; previously -c or -a
changed either the line color or fillcolor depending on if the symbol
primitive drawing STRINGs or POLYGONs (that does odd things to symbols
that use both, like pushpin). I don't really see a way around this
without a new flag to specify if the custom color is meant to be the
line color or fill color. Deciding what to do on a per-symbol or per-
primitive basis sucks IMO. I'm open to suggestions (other than putting
the low level symbol rendering code back into d.vect).
I can solve the pushpin problem by forcing its line color to always be
black. But that doesn't solve the "x" vs "o", stroke vs fill, problem.
Lines, areas, and centroids are unaffected.

clone of D_symbol() using primary_color and secondary_color instead of
line_color and fill_color??

speed: It now only plots symbols which are in the graphics frame.
For my tests with the NC sample LIDAR dataset (1.15M points), this,
together with the switch to D_symbol(), sped up zoomed rendering by 54%
(zoomed display region covered 12% of original region area)
The overlapping edges of large offscreen symbols will no longer be drawn
at the edges of the display monitor; the point has to be in the frame.


Hamish

From peter.loewe at gmx.de  Wed May  2 13:22:04 2007
From: peter.loewe at gmx.de (peter.loewe@gmx.de)
Date: Wed May  2 13:22:05 2007
Subject: [GRASS-dev] Access of remote Mysql database ?
In-Reply-To: <20070502091813.GE27153@bartok.itc.it>
References: <200705020751.l427pgtt019066@grass.itc.it>
	<20070502084054.300920@gmx.net> <20070502091813.GE27153@bartok.itc.it>
Message-ID: <20070502112204.186410@gmx.net>

Dear Markus, Dear Stephan,
thank you for your input.
Here is the correct sequence needed to hook up a remote mysql database, optional commands as comments with a hash 

db.connect driver=mysql database="host=dbserver.foo.org,dbname=my_database"

db.login user=joshua pass=swordfish

# db.tables -p 
# db.connect -p 

v.db.connect -o map=my_map table=my_mysql_table layer=2  key=baz
# v.db.select -c map=my_map_neu layer=1 column=cat 
v.db.select -c map=my_map layer=2 column=baz

It would be great if this info would end up in the official documentation.

Peter

-- 
Dr. Peter L?we

Diplom-Geograph

<loewe@geomancers.net>
<peter.loewe@gmx.de>





"Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

From hamish_nospam at yahoo.com  Wed May  2 13:35:10 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed May  2 13:35:14 2007
Subject: [GRASS-dev] Streams extraction from streams map
In-Reply-To: <20070502090436.GB27153@bartok.itc.it>
References: <20070501103714.GA19013@bartok.itc.it>
	<20070502090436.GB27153@bartok.itc.it>
Message-ID: <20070502233510.7ea64abd.hamish_nospam@yahoo.com>

Markus Neteler wrote:
> > I have a network of streams (say, Spearfish or better the new
> > NC data set at http://mpa.itc.it/grasstutor/data_menu3rd.phtml )
> > and want to extract a single stream system. Names are lacking,
> > is there any trick to extract topologically connected lines
> > into a new map?
> 
> Probably we need some equivalent to the "sides" operator in
> v.to.db (which tells you the cats of the left and right polygon).
> Some magic which finds the lines which are connected and writes
> out some related attribute(s).

how about v.net.iso? disconnected networks will have infinite cost.


!,
Hamish

From hamish_nospam at yahoo.com  Wed May  2 14:25:56 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Wed May  2 14:26:06 2007
Subject: [GRASS-dev] default vector point symbol
In-Reply-To: <C25C9B9B.218A0%michael.barton@asu.edu>
References: <20070501184522.00e9ec77.hamish_nospam@yahoo.com>
	<C25C9B9B.218A0%michael.barton@asu.edu>
Message-ID: <20070503002556.0d441504.hamish_nospam@yahoo.com>

Michael Barton wrote:
> > In addition I have a "d.mark x y" script to put a marker on the xmon
> > at a given x,y, which is pretty handy, much easier than
> > v.in.ascii+d.vect.
> >  (just added to addons)
> > examples:
> >   d.mark 65,30
> >   d.mark -m 595968,4918693
> > 
> 
> This sounds real handy. Is it on the WIKI? Maybe we should add it to
> the main GRASS distribution.

It's on the wiki addons page. It's just a shortcut & doesn't add
anything new so I never considered adding it to the main GRASS CVS.
shrug.

> It is an easy update to make it respond to a mouse click in the GUI

it takes at=x,y (% of display frame) as an argument, so yes. If you want
something like this, probably just rewrite the same method in Python
with a system call to d.graph, rather than bother with calling it as a
shell script.

see also "d.where -f" (but that's current frame, not display window)


Hamish

From glynn at gclements.plus.com  Wed May  2 14:51:58 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Wed May  2 14:52:01 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <20070502090554.GC27153@bartok.itc.it>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
Message-ID: <17976.35182.363572.196185@cerise.gclements.plus.com>


Markus Neteler wrote:

> > > >>> Bear in mind that the raster map is always opaque, so it will obscure
> > > >>> anything which is drawn beneath it.
> > > >>>       
> > > >> Markus:
> > > >>     
> > > >>> That's exactly what I need: in my case the raster map contains a few
> > > >>> cells only, but I need it on top to not be covered by vector contour
> > > >>> lines etc.
> > > >>>       
> > > >> ..
> > > >>     
> > > >>> Maybe ps.map's raster command needs an additional parameter "ontop" or
> > > >>> something like this? Hacking C code as Hamish suggests might be asked
> > > >>> too much for the average user.
> > > >>>       
> > > >> are the null areas solid white, not transparent?
> > > >>     
> > > >
> > > > They are transparent. All fine.
> > > Of course I was too hasty. Nothing fine.
> > > > Just that the tons of contour
> > > > lines cover the scarse raster areas in the raster maps. That's
> > > > why I need them on top of the dense contour lines.
> > > >   
> > > ... and it seems that NULL is not respected by ps.map (as you will know
> > > already).
> > 
> > For masked images, you need to use the one-operand form of the "image"
> > operator with an image dictionary; see the RASTERMASK procedure in
> > lib/psdriver/psdriver.ps for an example. This requires support for
> > level 3 PostScript (present in GhostScript for a few years now; I
> > don't know about printers).
> > 
> > Regarding the generation of the image data (ps/ps.map/ps_raster.c), a
> > masked image needs 2 (mono) or 4 (RGB) components, with the mask byte
> > first (i.e. AARRGGBB); see lib/psdriver/Raster.c.
> 
> I am afraid that I am not able to implement this.

Try the attached patch.

It only works with single rasters, not R/G/B groups. Also, the masked
flag is currently hard-coded on; ultimately, this would need to be
made into an option to the raster/rgb/group commands.

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

-------------- next part --------------
Index: ps/ps.map/ps_raster.c
===================================================================
RCS file: /grassrepository/grass6/ps/ps.map/ps_raster.c,v
retrieving revision 1.5
diff -u -r1.5 ps_raster.c
--- ps/ps.map/ps_raster.c	8 Jan 2007 07:25:26 -0000	1.5
+++ ps/ps.map/ps_raster.c	2 May 2007 12:47:53 -0000
@@ -65,6 +65,7 @@
     int i, n, r, g, b, rr, gg, bb, row, col, doing_color;
     RASTER_MAP_TYPE map_type, grp_map_type[3];
     void *cellbuf=NULL, *cbuf[3], *ptr;
+    int masked = 1;
 
     if (!PS.do_raster && !grp.do_group) return 1;
 
@@ -84,7 +85,35 @@
     fprintf(PS.fp, "%d %d scale\n", 
 	(int)(PS.map_pix_wide + 0.5), (int)(PS.map_pix_high + 0.5));
 
-
+    if (masked)
+    {
+    /* make strings to hold image RGB values */
+    if (doing_color) fprintf(PS.fp, "/DeviceRGB setcolorspace\n");
+    else	     fprintf(PS.fp, "/DeviceGray setcolorspace\n");
+    if (doing_color) fprintf(PS.fp, "/imgstrg cw 4 mul string def\n");
+    else	     fprintf(PS.fp, "/imgstrg cw 2 mul string def\n");
+    fprintf(PS.fp, "4 dict dup begin\n");
+    fprintf(PS.fp, "/ImageType 3 def\n");
+    fprintf(PS.fp, "/InterleaveType 1 def\n");
+    fprintf(PS.fp, "/DataDict 7 dict def\n");
+    fprintf(PS.fp, "/MaskDict 6 dict def\n");
+    fprintf(PS.fp, "MaskDict begin\n");
+    fprintf(PS.fp, "/ImageType 1 def\n");
+    fprintf(PS.fp, "/Width cw def\n");
+    fprintf(PS.fp, "/Height ch def\n");
+    fprintf(PS.fp, "/ImageMatrix [cw 0 0 ch neg 0 ch] def\n");
+    fprintf(PS.fp, "/BitsPerComponent 8 def\n");
+    fprintf(PS.fp, "/Decode [0 1] def\n");
+    fprintf(PS.fp, "end\n");
+    fprintf(PS.fp, "MaskDict DataDict copy begin\n");
+    if (doing_color) fprintf(PS.fp, "/Decode [0 1 0 1 0 1] def\n");
+    fprintf(PS.fp, "/DataSource {currentfile imgstrg readhexstring pop} def\n");
+    fprintf(PS.fp, "end\n");
+    fprintf(PS.fp, "end\n");
+    fprintf(PS.fp, "image\n");
+    }
+    else
+    {
     /* make strings to hold image RGB values */
     if (doing_color) fprintf(PS.fp, "/imgstrg cw 3 mul string def\n");
     else	     fprintf(PS.fp, "/imgstrg cw string def\n");
@@ -93,6 +122,7 @@
     fprintf(PS.fp, "{currentfile imgstrg readhexstring pop}\n");
     if (doing_color) fprintf(PS.fp, "false 3 colorimage\n");
     else	     fprintf(PS.fp, "image\n");
+    }
 
     /* let user know what's happenning */
     if (PS.do_raster)
@@ -114,31 +144,62 @@
 	    if ((row % PS.row_delta) == 0)
 	    {   ptr = cellbuf;
 		for (col = 0; col < PS.w.cols; col += PS.col_delta) 
-	        {   
+	        {
 	            G_get_raster_color(ptr, &r, &g, &b, &PS.colors, map_type);
-    
-		    /* if color raster */
-		    if (doing_color)
+
+		    if (masked)
 		    {
-		        fprintf(PS.fp, "%02X%02X%02X", r, g, b);
-	                if (++n == 13)
-	                {	
-		            n = 0;
-		            fprintf(PS.fp, "\n");
-		        }
-		    }
+			int nul = G_is_null_value(ptr, map_type) ? 0xFF : 0x00;
+
+			/* if color raster */
+			if (doing_color)
+			{
+			    fprintf(PS.fp, "%02X%02X%02X%02X", nul, r, g, b);
+			    if (++n == 9)
+			    {	
+				n = 0;
+				fprintf(PS.fp, "\n");
+			    }
+			}
 	    	
-		    /* if grey raster */
+			/* if grey raster */
+			else
+			{
+			    fprintf(PS.fp, "%02X%02X", nul,
+				    (int)(.3 * (double)r + .59 * (double)g + 
+					  .11 * (double)b));
+			    if (++n == 19)
+			    {	
+				n = 0;
+				fprintf(PS.fp, "\n");
+			    }
+			}
+		    }
 		    else
 		    {
-		        fprintf(PS.fp, "%02X",
-		            (int)(.3 * (double)r + .59 * (double)g + 
-				  .11 * (double)b));
-	                if (++n == 39)
-	                {	
-		            n = 0;
-		            fprintf(PS.fp, "\n");
-		        }
+			/* if color raster */
+			if (doing_color)
+			{
+			    fprintf(PS.fp, "%02X%02X%02X", r, g, b);
+			    if (++n == 13)
+			    {	
+				n = 0;
+				fprintf(PS.fp, "\n");
+			    }
+			}
+	    	
+			/* if grey raster */
+			else
+			{
+			    fprintf(PS.fp, "%02X",
+				    (int)(.3 * (double)r + .59 * (double)g + 
+					  .11 * (double)b));
+			    if (++n == 39)
+			    {	
+				n = 0;
+				fprintf(PS.fp, "\n");
+			    }
+			}
 		    }
 		    ptr = G_incr_void_ptr(ptr, G_raster_size(map_type) * PS.col_delta);
 	        }
From neteler at itc.it  Wed May  2 15:30:19 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 15:30:21 2007
Subject: [GRASS-dev] Access of remote Mysql database ?
In-Reply-To: <20070502112204.186410@gmx.net>
References: <200705020751.l427pgtt019066@grass.itc.it>
	<20070502084054.300920@gmx.net>
	<20070502091813.GE27153@bartok.itc.it>
	<20070502112204.186410@gmx.net>
Message-ID: <20070502133019.GL27153@bartok.itc.it>

On Wed, May 02, 2007 at 01:22:04PM +0200, peter.loewe@gmx.de wrote:
> Dear Markus, Dear Stephan,
> thank you for your input.
> Here is the correct sequence needed to hook up a remote mysql database, optional commands as comments with a hash 
> 
> db.connect driver=mysql database="host=dbserver.foo.org,dbname=my_database"
> 
> db.login user=joshua pass=swordfish
> 
> # db.tables -p 
> # db.connect -p 
> 
> v.db.connect -o map=my_map table=my_mysql_table layer=2  key=baz
> # v.db.select -c map=my_map_neu layer=1 column=cat 
> v.db.select -c map=my_map layer=2 column=baz
> 
> It would be great if this info would end up in the official documentation.

Done so in slightly modified form (6.2-CVS for 6.2.2 and 6.3-CVS).

ciao
Markus

From neteler at itc.it  Wed May  2 15:51:29 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 15:51:31 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17976.35182.363572.196185@cerise.gclements.plus.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
Message-ID: <20070502135129.GM27153@bartok.itc.it>

On Wed, May 02, 2007 at 01:51:58PM +0100, Glynn Clements wrote:
Content-Description: message body and .signature
> 
> Markus Neteler wrote:
> 
> > > > >>> Bear in mind that the raster map is always opaque, so it will obscure
> > > > >>> anything which is drawn beneath it.
> > > > >>>       
> > > > >> Markus:
> > > > >>     
> > > > >>> That's exactly what I need: in my case the raster map contains a few
> > > > >>> cells only, but I need it on top to not be covered by vector contour
> > > > >>> lines etc.
> > > > >>>       
> > > > >> ..
> > > > >>     
> > > > >>> Maybe ps.map's raster command needs an additional parameter "ontop" or
> > > > >>> something like this? Hacking C code as Hamish suggests might be asked
> > > > >>> too much for the average user.
> > > > >>>       
> > > > >> are the null areas solid white, not transparent?
> > > > >>     
> > > > >
> > > > > They are transparent. All fine.
> > > > Of course I was too hasty. Nothing fine.
> > > > > Just that the tons of contour
> > > > > lines cover the scarse raster areas in the raster maps. That's
> > > > > why I need them on top of the dense contour lines.
> > > > >   
> > > > ... and it seems that NULL is not respected by ps.map (as you will know
> > > > already).
> > > 
> > > For masked images, you need to use the one-operand form of the "image"
> > > operator with an image dictionary; see the RASTERMASK procedure in
> > > lib/psdriver/psdriver.ps for an example. This requires support for
> > > level 3 PostScript (present in GhostScript for a few years now; I
> > > don't know about printers).
> > > 
> > > Regarding the generation of the image data (ps/ps.map/ps_raster.c), a
> > > masked image needs 2 (mono) or 4 (RGB) components, with the mask byte
> > > first (i.e. AARRGGBB); see lib/psdriver/Raster.c.
> > 
> > I am afraid that I am not able to implement this.
> 
> Try the attached patch.

Great - works like a charm!
 
> It only works with single rasters, not R/G/B groups. Also, the masked
> flag is currently hard-coded on; ultimately, this would need to be
> made into an option to the raster/rgb/group commands.

This is already a great step forward, thanks!

Markus

From neteler at itc.it  Wed May  2 15:54:36 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 15:54:38 2007
Subject: [GRASS-dev] default vector point symbol
In-Reply-To: <20070503002556.0d441504.hamish_nospam@yahoo.com>
References: <20070501184522.00e9ec77.hamish_nospam@yahoo.com>
	<C25C9B9B.218A0%michael.barton@asu.edu>
	<20070503002556.0d441504.hamish_nospam@yahoo.com>
Message-ID: <20070502135436.GN27153@bartok.itc.it>

On Thu, May 03, 2007 at 12:25:56AM +1200, Hamish wrote:
> Michael Barton wrote:
> > > In addition I have a "d.mark x y" script to put a marker on the xmon
> > > at a given x,y, which is pretty handy, much easier than
> > > v.in.ascii+d.vect.
> > >  (just added to addons)
> > > examples:
> > >   d.mark 65,30
> > >   d.mark -m 595968,4918693
> > > 
> > 
> > This sounds real handy. Is it on the WIKI? Maybe we should add it to
> > the main GRASS distribution.
> 
> It's on the wiki addons page. It's just a shortcut & doesn't add
> anything new so I never considered adding it to the main GRASS CVS.
> shrug.

I think that such a functionality is regularly needed. Maybe,
it could go into d.labels as being close with 'labels' then
optional and additional reading from stdin? On the other hand,
we don't have too many d.* modules yet.

Markus

From woklist at kyngchaos.com  Wed May  2 15:58:52 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Wed May  2 15:58:58 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <9B06D8C9-102C-4827-846F-76668C83BE34@uv.es>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
	<17975.62700.469950.591439@cerise.gclements.plus.com>
	<9B06D8C9-102C-4827-846F-76668C83BE34@uv.es>
Message-ID: <F47FE015-3D23-4F4C-9ABB-69A01CF78A98@kyngchaos.com>

Only works on Tiger+ (10.4+).  Panther doesn't have Spotlight, which  
is what mdfind is from.

On May 2, 2007, at 5:48 AM, Agustin Diez Castillo wrote:

> mdfind 'kMDItemContentType = "*truetype*"'
> Finds all the truetype fonts on my Computer, even those inside an  
> Application folder or on devices attached to it.
> **************************************
> /System/Library/Fonts/Apple LiGothic Medium.dfont
> /System/Library/Fonts/AppleGothic.dfont
> /System/Library/Fonts/Courier.dfont
> /System/Library/Fonts/Geneva.dfont
> /System/Library/Fonts/Helvetica.dfont
> /System/Library/Fonts/Keyboard.dfont
> /System/Library/Fonts/LastResort.dfont
> /System/Library/Fonts/LucidaGrande.dfont
> /System/Library/Fonts/Monaco.dfont
> /System/Library/Fonts/Symbol.dfont
> /System/Library/Fonts/Times.dfont
> /System/Library/Fonts/ZapfDingbats.dfont
> /System/Library/Fonts/?? Pro.ttf
> /System/Library/Fonts/????.ttf
> /System/Library/Fonts/????.ttf
> /Library/Fonts/tt9830z_.ttf
> /Library/Fonts/AmericanTypewriter.dfont
> /Library/Fonts/Apple Chancery.dfont
> /Library/Fonts/Apple Symbols.ttf
> /Library/Fonts/Baskerville.dfont
> /Library/Fonts/BigCaslon.dfont
> /Library/Fonts/Chalkboard.ttf
> /Library/Fonts/ChalkboardBold.ttf
> /Library/Fonts/Cochin.dfont
> /Library/Fonts/Copperplate.dfont
> /Library/Fonts/Didot.dfont
> /Library/Fonts/Futura.dfont
> /Library/Fonts/GillSans.dfont
> /Library/Fonts/HelveticaNeue.dfont
> /Library/Fonts/Herculanum.dfont
> /Library/Fonts/Hoefler Text.dfont
> /Library/Fonts/MarkerFelt.dfont
> /Library/Fonts/Apple LiSung Light.dfont
> /Library/Fonts/BiauKai.dfont
> /Library/Fonts/NISC18030.ttf
> /Library/Fonts/?? Pro.ttf
> /Library/Fonts/????.ttf
> /Library/Fonts/????.ttf
> /Library/Fonts/????.ttf
> /Library/Fonts/#Gungseouche.dfont
> /Library/Fonts/#HeadlineA.dfont
> /Library/Fonts/#PCmyoungjo.dfont
> /Library/Fonts/#Pilgiche.dfont
> /Library/Fonts/AppleMyungjo.dfont
> /Library/Fonts/AlBayan.ttf
> /Library/Fonts/AlBayanBold.ttf
> /Library/Fonts/ArialHB.ttf
> /Library/Fonts/ArialHBBold.ttf
> /Library/Fonts/Ayuthaya.ttf
> /Library/Fonts/Baghdad.ttf
> /Library/Fonts/CharcoalCY.dfont
> /Library/Fonts/Corsiva.ttf
> /Library/Fonts/CorsivaBold.ttf
> /Library/Fonts/DecoTypeNaskh.ttf
> /Library/Fonts/DevanagariMT.ttf
> /Library/Fonts/DevanagariMTBold.ttf
> /Library/Fonts/EuphemiaCASBold.ttf
> /Library/Fonts/EuphemiaCASItalic.ttf
> /Library/Fonts/EuphemiaCASRegular.ttf
> /Library/Fonts/GenevaCY.dfont
> /Library/Fonts/GujaratiMT.ttf
> /Library/Fonts/GujaratiMTBold.ttf
> /Library/Fonts/Gurmukhi.ttf
> /Library/Fonts/HelveticaCY.dfont
> /Library/Fonts/InaiMathi.ttf
> /Library/Fonts/Krungthep.ttf
> /Library/Fonts/Optima.dfont
> /Library/Fonts/Papyrus.dfont
> /Library/Fonts/Skia.dfont
> /Library/Fonts/Zapfino.dfont
> /System/Library/Fonts/Geeza Pro Bold.ttf
> /System/Library/Fonts/Geeza Pro.ttf
> /System/Library/Fonts/Osaka.dfont
> /System/Library/Fonts/OsakaMono.dfont
> /Library/Fonts/Kai.dfont
> /System/Library/Fonts/Hei.dfont
> /Library/Fonts/KufiStandarGK.ttf
> /Library/Fonts/MshtakanBold.ttf
> /Library/Fonts/MshtakanBoldOblique.ttf
> /Library/Fonts/MshtakanOblique.ttf
> /Library/Fonts/MshtakanRegular.ttf
> /Library/Fonts/Nadeem.ttf
> /Library/Fonts/NewPeninimMT.ttf
> /Library/Fonts/NewPeninimMTBold.ttf
> /Library/Fonts/NewPeninimMTBoldInclined.ttf
> /Library/Fonts/NewPeninimMTInclined.ttf
> /Library/Fonts/PlantagenetCherokee.ttf
> /Library/Fonts/Raanana.ttf
> /Library/Fonts/RaananaBold.ttf
> /Library/Fonts/Sathu.ttf
> /Library/Fonts/Silom.ttf
> /Library/Fonts/Thonburi.ttf
> /Applications/rsi/idl_6.2/resource/fonts/tt/tt0003m_.ttf
> ....
> /Volumes/LaCieDisk/Users/Shared/cosas de Smigol/Library/Perl/5.8.1/ 
> darwin-thread-multi-2level/VRML/fonts/Amrigoi.ttf
> ...
> ***************************************
> + 1000 fonts
> and
> mdls /Library/Fonts/Silom.ttf, writes the metadata
> ***********************
> /Library/Fonts/Silom.ttf -------------
> kMDItemAttributeChangeDate     = 2006-08-11 10:56:25 +0200
> kMDItemContentCreationDate     = 2006-07-02 17:20:18 +0200
> kMDItemContentModificationDate = 2006-07-02 17:20:18 +0200
> kMDItemContentType             = "public.truetype-ttf-font"
> kMDItemContentTypeTree         = (
>     "public.truetype-ttf-font",
>     "public.truetype-font",
>     "public.font",
>     "public.data",
>     "public.item"
> )
> kMDItemCopyright               = "? 1992-2003 Apple Computer, Inc."
> kMDItemDisplayName             = "Silom.ttf"
> kMDItemFonts                   = (Silom)
> kMDItemFSContentChangeDate     = 2006-07-02 17:20:18 +0200
> kMDItemFSCreationDate          = 2006-07-02 17:20:18 +0200
> kMDItemFSCreatorCode           = 0
> kMDItemFSFinderFlags           = 0
> kMDItemFSInvisible             = 0
> kMDItemFSIsExtensionHidden     = 0
> kMDItemFSLabel                 = 0
> kMDItemFSName                  = "Silom.ttf"
> kMDItemFSNodeCount             = 0
> kMDItemFSOwnerGroupID          = 80
> kMDItemFSOwnerUserID           = 0
> kMDItemFSSize                  = 250996
> kMDItemFSTypeCode              = 0
> kMDItemID                      = 227671
> kMDItemKind                    = "Windows TrueType font"
> kMDItemVersion                 = "10.4d5e1"
> ***************************
> On May 2, 2007, at 4:18 AM, Glynn Clements wrote:
>
>>
>> William Kyngesburye wrote:
>>
>>> I just had a chance to check OSX 10.3 (Panther) X11 - fontconfig is
>>> present.  For OSX Panther, X11 is v1.0, before that (OSX 10.2 and
>>> below) it was a beta and is not available for download any more, as
>>> far as I can tell.  I think the betas must be where fontconfig  
>>> wasn't
>>> a part of Apple's X11 package (and I'm sure it wasn't at first).
>>>
>>> So, using fc-list on OSX, if it's available, for mkftcap is
>>> reasonable, for now.
>>
>> Is it possible to filter any non-TrueType fonts from the output? Or
>> are there not enough TrueType fonts to worry about?
>>
>> We can probably tolerate a few bogus entries in an auto-generated
>> freetypecap file; the user can always remove entries which don't  
>> work.
>> However, on my system, "fc-list :outline file" generates 102 entries;
>> 51 are .ttf files and 51 are .pfa/.pfb files, which is too high a
>> signal-to-noise ratio.
>>
>> That doesn't matter on Linux, as I can just ignore anything which
>> doesn't have a .ttf extension. For OSX, we'll need to find some other
>> way unless the number of false positives in the original fc-list
>> output is low.
>>
>> -- 
>> Glynn Clements <glynn@gclements.plus.com>
>>
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
>>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Time is an illusion - lunchtime doubly so."

- Ford Prefect



From woklist at kyngchaos.com  Wed May  2 16:24:51 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Wed May  2 16:24:56 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17976.18315.188453.944179@cerise.gclements.plus.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
	<17975.62700.469950.591439@cerise.gclements.plus.com>
	<97D61CF6-36DC-46A7-BEB5-499332C5462B@kyngchaos.com>
	<17976.13926.328258.937247@cerise.gclements.plus.com>
	<17976.18315.188453.944179@cerise.gclements.plus.com>
Message-ID: <E98809FC-8F5B-46F3-9A97-7454EEB8DE6B@kyngchaos.com>

On May 2, 2007, at 3:10 AM, Glynn Clements wrote:

>> Yes. However, that isn't all of the fonts which fc-list shows. E.g.
>> fc-list shows the PCF fonts, but those don't work with R_font().  
>> Type1
>> fonts work.
>
Ah.

> In addition to scanning directories for files with specific
> extensions, mkftcap also uses the output from "fc-list :outline",
> which should find all of the OSX fonts.

New snag - fc-list :outline doesn't get resource fonts (where all the  
useful MS fonts are).  I believe this is because these contain  
bitmaps for some font sizes, so fc-list is seeing them as bitmap  
fonts, not outlined.

What about fc-list :scalable?  Does that leave out the PCF fonts?  It  
does get the resource fonts for me.

> The updated mkftcap script should cope with multi-font files; the part
> which uses fc-list outputs the index, and should append it to the path
> if it isn't zero. I can't test this, as none of my font files have
> more than one font.
>
Actually, the index from fc-list isn't useful.  All it does is return  
the first index (0) in each file, whether or not it has multiple  
faces.  That is, there is only one entry per font file, which makes  
sense, since it's listing font files and that's all we really want at  
this stage.

The face index should be left to the user to find out, with some sort  
of d.freetype.info command, which could use the FT library to get  
font info in C.  It should return index and face name, so the user  
would know what index to use for which style.  The output could also  
be parsed and used by the GUI so a full list of fonts and styles  
could be build instead of just a list of files.


-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an  
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy


From michael.barton at asu.edu  Wed May  2 17:01:22 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 17:01:35 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <E98809FC-8F5B-46F3-9A97-7454EEB8DE6B@kyngchaos.com>
Message-ID: <C25DF5D2.2196A%michael.barton@asu.edu>


On 5/2/07 7:24 AM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

> On May 2, 2007, at 3:10 AM, Glynn Clements wrote:
> 
>>> Yes. However, that isn't all of the fonts which fc-list shows. E.g.
>>> fc-list shows the PCF fonts, but those don't work with R_font().
>>> Type1
>>> fonts work.
>> 
> Ah.
> 
>> In addition to scanning directories for files with specific
>> extensions, mkftcap also uses the output from "fc-list :outline",
>> which should find all of the OSX fonts.
> 
> New snag - fc-list :outline doesn't get resource fonts (where all the
> useful MS fonts are).  I believe this is because these contain
> bitmaps for some font sizes, so fc-list is seeing them as bitmap
> fonts, not outlined.
> 
> What about fc-list :scalable?  Does that leave out the PCF fonts?  It
> does get the resource fonts for me.

AFAICT, :outline, :outlined, and :scalable all produce the same list of
fonts. It would help (me at least) if there was some guide to fc-list syntax
and options. The help is zen-like in its minimalism. Looking at the man page
for fontconfigure isn't much help either.


> 
>> The updated mkftcap script should cope with multi-font files; the part
>> which uses fc-list outputs the index, and should append it to the path
>> if it isn't zero. I can't test this, as none of my font files have
>> more than one font.
>> 
> Actually, the index from fc-list isn't useful.  All it does is return
> the first index (0) in each file, whether or not it has multiple
> faces.  That is, there is only one entry per font file, which makes
> sense, since it's listing font files and that's all we really want at
> this stage.
> 
> The face index should be left to the user to find out, with some sort
> of d.freetype.info command, which could use the FT library to get
> font info in C.  It should return index and face name, so the user
> would know what index to use for which style.  The output could also
> be parsed and used by the GUI so a full list of fonts and styles
> could be build instead of just a list of files.

So, if you DO know the font face index, how do you specify it in GRASS_FONT?

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 at asu.edu  Wed May  2 17:05:40 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 17:05:52 2007
Subject: [GRASS-dev] Streams extraction from streams map
In-Reply-To: <20070502090436.GB27153@bartok.itc.it>
Message-ID: <C25DF6D4.2196E%michael.barton@asu.edu>

Markus,

I remember that someone recently wrote a module that will calculate stream
Strahler order. This may well have code that you can use for this task,
since it must calculate whether or not a stream segment has 'tributaries'. I
think that it's posted somewhere--WIKI, Grassaddons, ?

Michael


On 5/2/07 2:04 AM, "Markus Neteler" <neteler@itc.it> wrote:

> On Tue, May 01, 2007 at 12:37:15PM +0200, Markus Neteler wrote:
>> Hi,
>> 
>> I have a network of streams (say, Spearfish or better the new
>> NC data set at http://mpa.itc.it/grasstutor/data_menu3rd.phtml )
>> and want to extract a single stream system. Names are lacking,
>> is there any trick to extract topologically connected lines
>> into a new map?
> 
> Probably we need some equivalent to the "sides" operator in
> v.to.db (which tells you the cats of the left and right polygon).
> Some magic which finds the lines which are connected and writes
> out some related attribute(s).
> 
> Ideas welcome,
> Markus
> 
> 

__________________________________________
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 neteler at itc.it  Wed May  2 17:12:06 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 17:12:07 2007
Subject: [GRASS-dev] Streams extraction from streams map
In-Reply-To: <C25DF6D4.2196E%michael.barton@asu.edu>
References: <20070502090436.GB27153@bartok.itc.it>
	<C25DF6D4.2196E%michael.barton@asu.edu>
Message-ID: <20070502151205.GQ27153@bartok.itc.it>

On Wed, May 02, 2007 at 08:05:40AM -0700, Michael Barton wrote:
> Markus,
> 
> I remember that someone recently wrote a module that will calculate stream
> Strahler order. This may well have code that you can use for this task,
> since it must calculate whether or not a stream segment has 'tributaries'. I
> think that it's posted somewhere--WIKI, Grassaddons, ?

I tried this v.strahler recently but it didn't work (it is in the GRASS
Addons SVN) - for me. Maybe it's still under development. But yes,
this would probably do the job.

Markus

From michael.barton at asu.edu  Wed May  2 17:16:45 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 17:16:57 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <17976.17667.172986.583275@cerise.gclements.plus.com>
Message-ID: <C25DF96D.21970%michael.barton@asu.edu>

I just updated. Works great. Thanks.

I'll move ahead on building a listbox control in wxPython that will use
this.

Michael


On 5/2/07 1:00 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>>> The command in question is:
>>> 
>>> find "$dir" -type f -iname '*.ttf' -printf '%f:%p:utf-8:\n'
>>> 
>>> Does OSX have a command called "find" which isn't the standard Unix
>>> "find" command?
>>> 
>> find
>> usage: find [-H | -L | -P] [-EXdsx] [-f file] [file ...] [expression]
>> 
>> Is this different from the standard?
> 
> No, that's the right command; it appears -printf is a GNU extension.
> 
> That shouldn't be a problem in this case; using:
> 
> find "$dir" -type f -iname '*.ttf' -print | sed
> 's!^\(.*\)/\(.*\)$!\2:\1/\2:utf-8:!'
> 
> should do the same job.

__________________________________________
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 tutey at o2.pl  Wed May  2 17:25:57 2007
From: tutey at o2.pl (Maciej Sieczka)
Date: Wed May  2 17:26:02 2007
Subject: [GRASS-dev] broken API
In-Reply-To: <20070502091433.GD27153@bartok.itc.it>
References: <463072B6.9090209@faunalia.it>
	<20070502091433.GD27153@bartok.itc.it>
Message-ID: <4638AD85.1010500@o2.pl>

Markus Neteler wrote:
> On Thu, Apr 26, 2007 at 11:36:54AM +0200, Paolo Cavallini wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi all.
>> While compiling qgis, I noticed that GRASS API has been broken:
>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/include/version.h.in.diff?r1=1.4&r2=1.5
>> As a result, QGIS can no longer be compiled with GRASS support.
> 
> https://svn.qgis.org/trac/ticket/712
> 
> It has been fixed last night in QGIS SVN HEAD.

Still broken for QGIS 0.8.1 to-be-relased "stable" branch, though.

Maciek

From woklist at kyngchaos.com  Wed May  2 17:41:48 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Wed May  2 17:41:53 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <17976.17667.172986.583275@cerise.gclements.plus.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
Message-ID: <893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>

I'm having a different problem with mkftcap - it's getting hung up  
doing nothing.  One on my processors maxes out and there is no disk  
activity for the find operations.

I tried cutting out each part separately - find and fc-list - to see  
if one of those was the problem, but no go.

Further cutting points to something wrong in the sed lines - if I  
remove those so the raw find and fc-list results are returned, it  
finishes.

On May 2, 2007, at 3:00 AM, Glynn Clements wrote:

>
> Michael Barton wrote:
>
>>> The command in question is:
>>>
>>> find "$dir" -type f -iname '*.ttf' -printf '%f:%p:utf-8:\n'
>>>
>>> Does OSX have a command called "find" which isn't the standard Unix
>>> "find" command?
>>>
>> find
>> usage: find [-H | -L | -P] [-EXdsx] [-f file] [file ...] [expression]
>>
>> Is this different from the standard?
>
> No, that's the right command; it appears -printf is a GNU extension.
>
> That shouldn't be a problem in this case; using:
>
> 	find "$dir" -type f -iname '*.ttf' -print | sed 's!^\(.*\)/\(.*\)$! 
> \2:\1/\2:utf-8:!'
>
> should do the same job.
>
> -- 
> Glynn Clements <glynn@gclements.plus.com>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled  
with hyena offal?
Second Pogril: I don't know.  Why IS life like sticking your head in  
a bucket filled with hyena offal?
First Pogril: I don't know either.  Wretched, isn't it?

-HitchHiker's Guide to the Galaxy


From woklist at kyngchaos.com  Wed May  2 17:55:06 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Wed May  2 17:55:12 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <C25DF5D2.2196A%michael.barton@asu.edu>
References: <C25DF5D2.2196A%michael.barton@asu.edu>
Message-ID: <E6510840-45E6-4E06-B0A1-1A273896B3AE@kyngchaos.com>

On May 2, 2007, at 10:01 AM, Michael Barton wrote:
>> What about fc-list :scalable?  Does that leave out the PCF fonts?  It
>> does get the resource fonts for me.
>
> AFAICT, :outline, :outlined, and :scalable all produce the same  
> list of
> fonts. It would help (me at least) if there was some guide to fc- 
> list syntax
> and options. The help is zen-like in its minimalism. Looking at the  
> man page
> for fontconfigure isn't much help either.
>
You're right.  A closer look and they do appear to be the same for me  
also.  The problem seems to be that I saw that Arial was missing and  
I didn't pay much attention to the rest.  But Arial is missing on  
both methods, though the other Arials are present - narrow, rounded,  
black.  Strange.  I must have a bum Arial font, it does have an older  
date than the rest...

> So, if you DO know the font face index, how do you specify it in  
> GRASS_FONT?
>
Glynn:
> That's easy enough to implement.
>
> One option is to pick an arbitrary character to separate the index
> from the filename. If the path ends with that character followed by a
> number, the number is the index.
...
> I've updated the driver, although I can't actually test it with
> multi-font files.

What char did you use Glynn?  vert bar?

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Oh, look, I seem to have fallen down a deep, dark hole.  Now what  
does that remind me of?  Ah, yes - life."

- Marvin


From michael.barton at asu.edu  Wed May  2 18:06:47 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Wed May  2 18:07:00 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
Message-ID: <C25E0527.2197E%michael.barton@asu.edu>

In fact, I was too hasty in my optimistic report. mkftcap works, but it
doesn't put the output into my $GISBASE/etc/freetypecap file. It just
outputs it to the terminal. I can manually deal with this

mkftcap>$GISBASE/etc/freetypecap

but something is not working right. Maybe need to recompile.

Michael




On 5/2/07 8:41 AM, "William Kyngesburye" <woklist@kyngchaos.com> wrote:

> I'm having a different problem with mkftcap - it's getting hung up
> doing nothing.  One on my processors maxes out and there is no disk
> activity for the find operations.
> 
> I tried cutting out each part separately - find and fc-list - to see
> if one of those was the problem, but no go.
> 
> Further cutting points to something wrong in the sed lines - if I
> remove those so the raw find and fc-list results are returned, it
> finishes.
> 
> On May 2, 2007, at 3:00 AM, Glynn Clements wrote:
> 
>> 
>> Michael Barton wrote:
>> 
>>>> The command in question is:
>>>> 
>>>> find "$dir" -type f -iname '*.ttf' -printf '%f:%p:utf-8:\n'
>>>> 
>>>> Does OSX have a command called "find" which isn't the standard Unix
>>>> "find" command?
>>>> 
>>> find
>>> usage: find [-H | -L | -P] [-EXdsx] [-f file] [file ...] [expression]
>>> 
>>> Is this different from the standard?
>> 
>> No, that's the right command; it appears -printf is a GNU extension.
>> 
>> That shouldn't be a problem in this case; using:
>> 
>> find "$dir" -type f -iname '*.ttf' -print | sed 's!^\(.*\)/\(.*\)$!
>> \2:\1/\2:utf-8:!'
>> 
>> should do the same job.
>> 
>> -- 
>> Glynn Clements <glynn@gclements.plus.com>
>> 
>> _______________________________________________
>> grass-dev mailing list
>> grass-dev@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass-dev
> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
> 
> First Pogril: Why is life like sticking your head in a bucket filled
> with hyena offal?
> Second Pogril: I don't know.  Why IS life like sticking your head in
> a bucket filled with hyena offal?
> First Pogril: I don't know either.  Wretched, isn't it?
> 
> -HitchHiker's Guide to the Galaxy
> 
> 

__________________________________________
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 soerengebbert at gmx.de  Wed May  2 19:41:32 2007
From: soerengebbert at gmx.de (=?ISO-8859-15?Q?S=F6ren_Gebbert?=)
Date: Wed May  2 19:41:59 2007
Subject: [GRASS-dev] NR licence issue and replacement of G_ludcmp()
Message-ID: <4638CD4C.3000106@gmx.de>

Hi folks,
i have implemented a pivoting strategy for the direct linear equation solvers
in the gpde library. Now a weighted row pivoting strategy is available for
the LU decomposition solver N_solver_lu() and the gauss elimination N_solver_gauss().

The gpde lu and gauss solver still work in parallel. :)
I have tested the solvers with a Hilbert matrix and v.surf.rst
and it seems to work.

Now 4 gpde solver are available to solve the linear equations
in the rst library, so G_ludcmp() can be replaced. The solvers are:
* N_solver_lu()
* N_solver_gauss()
* N_solver_cg()
* N_solver_bicgstab()

The new lu solver is not as fast as the G_ludcmp() algorithm, which is
related to the parallel approach of the gpde library. But because of
the licence problem with numerical recipes, we need to remove the G_ludcmp() code.

But, i did not had a look at :
./imagery/i.gensigset/invert.c
./imagery/i.smap/bouman/invert.c
and
./raster/r.param.scale/process.c

yet, which also use the G_ludcmp() algorithm.

The new solvers are available in CVS.

Best regards
Soeren

From neteler at itc.it  Wed May  2 20:51:32 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 20:51:33 2007
Subject: [GRASS-dev] v.digit crash
Message-ID: <20070502185131.GU27153@bartok.itc.it>

HI,

I managed to crash the new v.digit by editing the "streams"
map of the new NC dataset. I tried to insert a new point
(outlet), then

g.copy vect=streams,mystreams
v.digit mystreams
X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  53 (X_CreatePixmap)
  Serial number of failed request:  4353
  Current serial number in output stream:  4361


strace v.digit mystreams
....
write(8, "\3\30\2\0\313\0\0\4\16\0\2\0\313\0\0\4", 16) = 16
read(8, "\1\0\375\t\3\0\0\0!\0\0\0\1\0\1\1\377\377\377\377\0\0\0"..., 32) = 32
read(8, "\177\200\301\0\177\200\301\0\0\0\37\10", 12) = 12
read(8, "\1\30\376\t\0\0\0\0\242\0\0\0\4\0C\1a\256\26\0\0\0\0\0"..., 32) = 32
write(8, "\10\30\2\0\313\0\0\4>\0\7\0\303\0\0\4\277\0\0\4\177\0\0"..., 188) = 188
write(7, "\0", 1)                       = 1
futex(0x83b93e8, FUTEX_WAKE, 1)         = 1
futex(0x8705388, FUTEX_WAKE, 1)         = 1
futex(0x870538c, FUTEX_WAIT, 471, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1)         = 0
gettimeofday({1178131672, 506046}, {4294967176, 0}) = 0
ioctl(8, FIONREAD, [64])                = 0
read(8, "\17\360\377\t\313\0\0\4\1\2\0\0\337\2\0\0\377\177\0\0\223"..., 64) = 64
write(7, "\0", 1)                       = 1
futex(0x83b93e8, FUTEX_WAKE, 1)         = 1
futex(0x8705388, FUTEX_WAKE, 1)         = 1
futex(0x870538c, FUTEX_WAIT, 473, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1)         = 0
gettimeofday({1178131672, 507598}, {4294967176, 0}) = 0
write(8, "5\30\4\0\303\0\0\4\275\0\0\4\21\0\340\1F\0\5\0\303\0\0"..., 1424) = 1424
write(7, "\0", 1)                       = 1
futex(0x83b93e8, FUTEX_WAKE, 1)         = 1
futex(0x8705388, FUTEX_WAKE, 1)         = 1
futex(0x870538c, FUTEX_WAIT, 475, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1)         = 0
gettimeofday({1178131672, 509871}, {4294967176, 0}) = 0
ioctl(8, FIONREAD, [288])               = 0
read(8, "\0\v;\n\303\0\0\4\0\0005\0\0\0\0\0\20\0\0\0\235q\t\10\0"..., 288) = 288
open("/usr/share/X11/XErrorDB", O_RDONLY) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=37949, ...}) = 0
read(9, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 37949) = 37949
close(9)                                = 0
brk(0xbf45000)                          = 0xbf45000
write(2, "X Error of failed request:  BadA"..., 78X Error of failed request:  BadAlloc (insufficient resources for operation)
  ) = 78
write(2, "Major opcode of failed request: "..., 35Major opcode of failed request:  53) = 35
write(2, " (X_CreatePixmap)\n", 18 (X_CreatePixmap)
)     = 18
write(2, "  ", 2  )                       = 2
write(2, "Serial number of failed request:"..., 38Serial number of failed request:  2619) = 38
write(2, "\n  ", 3
  )                     = 3
write(2, "Current serial number in output "..., 45Current serial number in output stream:  2627) = 45
write(2, "\n", 1
)                       = 1
exit_group(1)                           = ?
Process 26510 detached


I see that it tried to open the database table form then zap.

v.db.connect -p mystreams
Vector map <mystreams> is connected by:
layer <1> table <mystreams> in database </home/neteler/grassdata/nc_spm_04/sqlite/sqlite.db> through driver <sqlite> with key <cat>

Please suggest how to debug this one.

Markus

From woklist at kyngchaos.com  Wed May  2 21:11:57 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Wed May  2 21:12:02 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
	<893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
Message-ID: <C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>

On May 2, 2007, at 10:41 AM, William Kyngesburye wrote:

> I'm having a different problem with mkftcap - it's getting hung up  
> doing nothing.  One on my processors maxes out and there is no disk  
> activity for the find operations.
>
> I tried cutting out each part separately - find and fc-list - to  
> see if one of those was the problem, but no go.
>
> Further cutting points to something wrong in the sed lines - if I  
> remove those so the raw find and fc-list results are returned, it  
> finishes.
>
I found the source of my problem - in my .bash_profile, I set:

export LC_CTYPE="en_US.UTF-8"
export LANG="en_US.UTF-8"

if I unset both, mkftcap works.  I also have:

set dspmbyte = \"utf8\"

but I don't need to change that for mkftcap to work.

I set these (maybe naively?) so my Terminals match the default OSX  
charset of utf8.  The window display settings for Terminal.app  
default to utf8 (and I didn't need to change that either).

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*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


From woklist at kyngchaos.com  Wed May  2 21:36:07 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Wed May  2 21:36:12 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
	<893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
	<C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>
Message-ID: <00CBBE51-DC43-45DB-8D59-4079D674A6FA@kyngchaos.com>

Sorry, responding to myself again...

On May 2, 2007, at 2:11 PM, William Kyngesburye wrote:

> On May 2, 2007, at 10:41 AM, William Kyngesburye wrote:
>
>> I'm having a different problem with mkftcap - it's getting hung up  
>> doing nothing.  One on my processors maxes out and there is no  
>> disk activity for the find operations.
>>
>> I tried cutting out each part separately - find and fc-list - to  
>> see if one of those was the problem, but no go.
>>
>> Further cutting points to something wrong in the sed lines - if I  
>> remove those so the raw find and fc-list results are returned, it  
>> finishes.
>>
> I found the source of my problem - in my .bash_profile, I set:
>
> export LC_CTYPE="en_US.UTF-8"
> export LANG="en_US.UTF-8"
>
> if I unset both, mkftcap works.  I also have:
>
> set dspmbyte = \"utf8\"
>
> but I don't need to change that for mkftcap to work.
>
> I set these (maybe naively?) so my Terminals match the default OSX  
> charset of utf8.  The window display settings for Terminal.app  
> default to utf8 (and I didn't need to change that either).
>
After trying various combinations of these settings, it appears I  
don't need these any more.  They are probably leftovers in  
my .bash_profile from the early OSX days when Terminal didn't handle  
UTF8 directly very well.  It looks like the window setting takes care  
of this now.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.


From neteler at itc.it  Wed May  2 22:46:53 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 22:46:54 2007
Subject: [GRASS-dev] v.digit crash
In-Reply-To: <20070502185131.GU27153@bartok.itc.it>
References: <20070502185131.GU27153@bartok.itc.it>
Message-ID: <20070502204652.GX27153@bartok.itc.it>

On Wed, May 02, 2007 at 08:51:32PM +0200, Markus Neteler wrote:
> HI,
> 
> I managed to crash the new v.digit by editing the "streams"
> map of the new NC dataset. I tried to insert a new point
> (outlet), then
> 
> g.copy vect=streams,mystreams
> v.digit mystreams
> X Error of failed request:  BadAlloc (insufficient resources for operation)
>   Major opcode of failed request:  53 (X_CreatePixmap)
>   Serial number of failed request:  4353
>   Current serial number in output stream:  4361
> 
> 
> strace v.digit mystreams
> ....
> write(8, "\3\30\2\0\313\0\0\4\16\0\2\0\313\0\0\4", 16) = 16
> read(8, "\1\0\375\t\3\0\0\0!\0\0\0\1\0\1\1\377\377\377\377\0\0\0"..., 32) = 32
> read(8, "\177\200\301\0\177\200\301\0\0\0\37\10", 12) = 12
> read(8, "\1\30\376\t\0\0\0\0\242\0\0\0\4\0C\1a\256\26\0\0\0\0\0"..., 32) = 32
> write(8, "\10\30\2\0\313\0\0\4>\0\7\0\303\0\0\4\277\0\0\4\177\0\0"..., 188) = 188
> write(7, "\0", 1)                       = 1
> futex(0x83b93e8, FUTEX_WAKE, 1)         = 1
> futex(0x8705388, FUTEX_WAKE, 1)         = 1
> futex(0x870538c, FUTEX_WAIT, 471, NULL) = -1 EAGAIN (Resource temporarily unavailable)
> futex(0x83b93e8, FUTEX_WAKE, 1)         = 0
> gettimeofday({1178131672, 506046}, {4294967176, 0}) = 0
> ioctl(8, FIONREAD, [64])                = 0
> read(8, "\17\360\377\t\313\0\0\4\1\2\0\0\337\2\0\0\377\177\0\0\223"..., 64) = 64
> write(7, "\0", 1)                       = 1
> futex(0x83b93e8, FUTEX_WAKE, 1)         = 1
> futex(0x8705388, FUTEX_WAKE, 1)         = 1
> futex(0x870538c, FUTEX_WAIT, 473, NULL) = -1 EAGAIN (Resource temporarily unavailable)
> futex(0x83b93e8, FUTEX_WAKE, 1)         = 0
> gettimeofday({1178131672, 507598}, {4294967176, 0}) = 0
> write(8, "5\30\4\0\303\0\0\4\275\0\0\4\21\0\340\1F\0\5\0\303\0\0"..., 1424) = 1424
> write(7, "\0", 1)                       = 1
> futex(0x83b93e8, FUTEX_WAKE, 1)         = 1
> futex(0x8705388, FUTEX_WAKE, 1)         = 1
> futex(0x870538c, FUTEX_WAIT, 475, NULL) = -1 EAGAIN (Resource temporarily unavailable)
> futex(0x83b93e8, FUTEX_WAKE, 1)         = 0
> gettimeofday({1178131672, 509871}, {4294967176, 0}) = 0
> ioctl(8, FIONREAD, [288])               = 0
> read(8, "\0\v;\n\303\0\0\4\0\0005\0\0\0\0\0\20\0\0\0\235q\t\10\0"..., 288) = 288
> open("/usr/share/X11/XErrorDB", O_RDONLY) = 9
> fstat64(9, {st_mode=S_IFREG|0644, st_size=37949, ...}) = 0
> read(9, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 37949) = 37949
> close(9)                                = 0
> brk(0xbf45000)                          = 0xbf45000
> write(2, "X Error of failed request:  BadA"..., 78X Error of failed request:  BadAlloc (insufficient resources for operation)
>   ) = 78
> write(2, "Major opcode of failed request: "..., 35Major opcode of failed request:  53) = 35
> write(2, " (X_CreatePixmap)\n", 18 (X_CreatePixmap)
> )     = 18
> write(2, "  ", 2  )                       = 2
> write(2, "Serial number of failed request:"..., 38Serial number of failed request:  2619) = 38
> write(2, "\n  ", 3
>   )                     = 3
> write(2, "Current serial number in output "..., 45Current serial number in output stream:  2627) = 45
> write(2, "\n", 1
> )                       = 1
> exit_group(1)                           = ?
> Process 26510 detached
> 
> 
> I see that it tried to open the database table form then zap.
> 
> v.db.connect -p mystreams
> Vector map <mystreams> is connected by:
> layer <1> table <mystreams> in database </home/neteler/grassdata/nc_spm_04/sqlite/sqlite.db> through driver <sqlite> with key <cat>
> 
> Please suggest how to debug this one.

Digging further into this, I found out that it doesn't crash with the DBF
driver. So it is related to the SQLite driver.

Here some more debugging stuff:
http://mpa.itc.it/markus/tmp/vdigit_settings_sqlite.png
(how the table definition looks like in v.digit - all 99999 lengths!)

DEBUG=2 output, put here to not make the mail too long:
http://mpa.itc.it/markus/tmp/vdigit_settings_sqlite.txt

There are various size=99999 there which come from
db/drivers/sqlite/describe.c

   113          fsize = 99999; /* sqlite doesn't care, it must be long enough to
   114                            satisfy tests in GRASS */

Last year I changes fsize from -1 to 99999 for v.in.ascii:

2006-07-04 11:24  markus
        * describe.c: define sufficient length to make v.in.ascii functional

So far it worked. The trick seems to be to get it fixed for the form in
v.digit.

Markus

From neteler at itc.it  Wed May  2 22:47:37 2007
From: neteler at itc.it (Markus Neteler)
Date: Wed May  2 22:47:39 2007
Subject: [GRASS-dev] broken API
In-Reply-To: <4638AD85.1010500@o2.pl>
References: <463072B6.9090209@faunalia.it>
	<20070502091433.GD27153@bartok.itc.it> <4638AD85.1010500@o2.pl>
Message-ID: <20070502204737.GY27153@bartok.itc.it>

On Wed, May 02, 2007 at 05:25:57PM +0200, Maciej Sieczka wrote:
> Markus Neteler wrote:
> > On Thu, Apr 26, 2007 at 11:36:54AM +0200, Paolo Cavallini wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> Hi all.
> >> While compiling qgis, I noticed that GRASS API has been broken:
> >> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/include/version.h.in.diff?r1=1.4&r2=1.5
> >> As a result, QGIS can no longer be compiled with GRASS support.
> > 
> > https://svn.qgis.org/trac/ticket/712
> > 
> > It has been fixed last night in QGIS SVN HEAD.
> 
> Still broken for QGIS 0.8.1 to-be-relased "stable" branch, though.

I have posted this there and re-opened ticket 712.

Markus

From neteler at itc.it  Thu May  3 00:05:43 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 00:05:44 2007
Subject: [GRASS-dev] d.vect kills d.mon
Message-ID: <20070502220542.GA27153@bartok.itc.it>

Hi,

mysterious day: I used v.clean on a map to break/snap/rmdupl
and a topologically correct map is generated. But looking at
it, d.vect kills x0:

GRASS 6.3.cvs (spearfish60):~ > v.build myroads_net
Building topology ...
948 primitives registered
Building areas:  100%
0 areas built
0 isles built
Attaching islands:
Attaching centroids:  100%
Topology was built.
Number of nodes     :   683
Number of primitives:   948
Number of points    :   2
Number of lines     :   946
Number of boundaries:   0
Number of centroids :   0
Number of areas     :   0
Number of isles     :   0

GRASS 6.3.cvs (spearfish60):~ > d.mon x0
using default visual which is TrueColor
ncolors: 16777216
Graphics driver [x0] started

GRASS 6.3.cvs (spearfish60):~ > d.vect myroads_net col=red
ERROR eof from graphics driver.

I did "make distclean; ..." before.

strace d.vect myroads_net col=red
...
_llseek(6, 147456, [147456], SEEK_SET)  = 0
_llseek(6, 147456, [147456], SEEK_SET)  = 0
_llseek(6, 147456, [147456], SEEK_SET)  = 0
_llseek(6, 147456, [147456], SEEK_SET)  = 0
read(6, "\252\327\353\307\353>\"A\274\222\250\200\301\311RA\v\2"..., 4096) = 139
_llseek(6, 147595, [147595], SEEK_SET)  = 0
_llseek(6, 147595, [147595], SEEK_SET)  = 0
_llseek(6, 147595, [147595], SEEK_SET)  = 0
rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
write(4, "\0\0\177\6\377\0\0\177\6\377\0\0\177\6\377\0\0\177\6\377"..., 1484) = 1484
read(5, "", 1)                          = 0
write(2, "ERROR eof from graphics driver.\n", 32ERROR eof from graphics driver.
) = 32
exit_group(1)                           = ?
Process 27067 detached

Not sure where "ERROR eof from graphics driver" originates from, probably
lib/raster/rem_io.c?

Markus

Markus

From neteler at itc.it  Thu May  3 00:13:43 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 00:13:45 2007
Subject: [GRASS-dev] v.net.path and v.net.iso examples (Spearfish)
Message-ID: <20070502221342.GA5624@bartok.itc.it>

Hi,

I have added some examples based on Spearfish:
v.net.iso/description.html
v.net.path/description.html

They need testing and simplification (v.net.path).
My problem is how to get the nodes (centers) onto the
network lines. Maybe we should implement threshold such
as in d.path? If you look at the v.net.path, you see that
it is rather painful to connect the node to the network.
Or some fancy v.edit trick to digitize the start/end
nodes?

Markus

From glynn at gclements.plus.com  Thu May  3 01:55:19 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 01:55:39 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <C25DF5D2.2196A%michael.barton@asu.edu>
References: <E98809FC-8F5B-46F3-9A97-7454EEB8DE6B@kyngchaos.com>
	<C25DF5D2.2196A%michael.barton@asu.edu>
Message-ID: <17977.9447.577505.410325@cerise.gclements.plus.com>


Michael Barton wrote:

> > New snag - fc-list :outline doesn't get resource fonts (where all the
> > useful MS fonts are).  I believe this is because these contain
> > bitmaps for some font sizes, so fc-list is seeing them as bitmap
> > fonts, not outlined.
> > 
> > What about fc-list :scalable?  Does that leave out the PCF fonts?  It
> > does get the resource fonts for me.
> 
> AFAICT, :outline, :outlined, and :scalable all produce the same list of
> fonts.

Same here.

> It would help (me at least) if there was some guide to fc-list syntax
> and options. The help is zen-like in its minimalism. Looking at the man page
> for fontconfigure isn't much help either.

The list of standard properties in the fontconfig-user HTML/TXT/PDF file:

  Property        Type    Description
  --------------------------------------------------------------
  family          String  Font family names
  familylang      String  Languages corresponding to each family
  style           String  Font style. Overrides weight and slant
  stylelang       String  Languages corresponding to each style
  fullname        String  Font full names (often includes style)
  fullnamelang    String  Languages corresponding to each fullname
  slant           Int     Italic, oblique or roman
  weight          Int     Light, medium, demibold, bold or black
  size            Double  Point size
  width           Int     Condensed, normal or expanded
  aspect          Double  Stretches glyphs horizontally before hinting
  pixelsize       Double  Pixel size
  spacing         Int     Proportional, dual-width, monospace or charcell
  foundry         String  Font foundry name
  antialias       Bool    Whether glyphs can be antialiased
  hinting         Bool    Whether the rasterizer should use hinting
  hintstyle       Int     Automatic hinting style
  verticallayout  Bool    Use vertical layout
  autohint        Bool    Use autohinter instead of normal hinter
  globaladvance   Bool    Use font global advance data
  file            String  The filename holding the font
  index           Int     The index of the font within the file
  ftface          FT_Face Use the specified FreeType face object
  rasterizer      String  Which rasterizer is in use
  outline         Bool    Whether the glyphs are outlines
  scalable        Bool    Whether glyphs can be scaled
  scale           Double  Scale factor for point->pixel conversions
  dpi             Double  Target dots per inch
  rgba            Int     unknown, rgb, bgr, vrgb, vbgr,
                          none - subpixel geometry
  minspace        Bool    Eliminate leading from line spacing
  charset         CharSet Unicode chars encoded by the font
  lang            String  List of RFC-3066-style languages this
                          font supports
  fontversion     Int     Version number of the font
  capability      String  List of layout capabilities in the font
  embolden        Bool    Rasterizer should synthetically embolden the font

Not all of these are usable by fc-list.

> >> The updated mkftcap script should cope with multi-font files; the part
> >> which uses fc-list outputs the index, and should append it to the path
> >> if it isn't zero. I can't test this, as none of my font files have
> >> more than one font.
> >> 
> > Actually, the index from fc-list isn't useful.  All it does is return
> > the first index (0) in each file, whether or not it has multiple
> > faces.  That is, there is only one entry per font file, which makes
> > sense, since it's listing font files and that's all we really want at
> > this stage.
> > 
> > The face index should be left to the user to find out, with some sort
> > of d.freetype.info command, which could use the FT library to get
> > font info in C.  It should return index and face name, so the user
> > would know what index to use for which style.  The output could also
> > be parsed and used by the GUI so a full list of fonts and styles
> > could be build instead of just a list of files.
> 
> So, if you DO know the font face index, how do you specify it in GRASS_FONT?

Append a vertical bar followed by the index (in decimal) to the file's
path.

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

From glynn at gclements.plus.com  Thu May  3 01:59:30 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 01:59:43 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <C25E0527.2197E%michael.barton@asu.edu>
References: <893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
	<C25E0527.2197E%michael.barton@asu.edu>
Message-ID: <17977.9698.623547.191734@cerise.gclements.plus.com>


Michael Barton wrote:

> In fact, I was too hasty in my optimistic report. mkftcap works, but it
> doesn't put the output into my $GISBASE/etc/freetypecap file. It just
> outputs it to the terminal. I can manually deal with this
> 
> mkftcap>$GISBASE/etc/freetypecap
> 
> but something is not working right. Maybe need to recompile.

It is meant to write to stdout; it originally wrote directly to the
freetypecap file, but was changed to improve flexibility.

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

From michael.barton at asu.edu  Thu May  3 02:04:47 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Thu May  3 02:04:54 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17977.9447.577505.410325@cerise.gclements.plus.com>
Message-ID: <C25E752F.2EC77%michael.barton@asu.edu>

Thanks for the info. Another one to file away.

Michael


On 5/2/07 4:55 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>>> New snag - fc-list :outline doesn't get resource fonts (where all the
>>> useful MS fonts are).  I believe this is because these contain
>>> bitmaps for some font sizes, so fc-list is seeing them as bitmap
>>> fonts, not outlined.
>>> 
>>> What about fc-list :scalable?  Does that leave out the PCF fonts?  It
>>> does get the resource fonts for me.
>> 
>> AFAICT, :outline, :outlined, and :scalable all produce the same list of
>> fonts.
> 
> Same here.
> 
>> It would help (me at least) if there was some guide to fc-list syntax
>> and options. The help is zen-like in its minimalism. Looking at the man page
>> for fontconfigure isn't much help either.
> 
> The list of standard properties in the fontconfig-user HTML/TXT/PDF file:
> 
>   Property        Type    Description
>   --------------------------------------------------------------
>   family          String  Font family names
>   familylang      String  Languages corresponding to each family
>   style           String  Font style. Overrides weight and slant
>   stylelang       String  Languages corresponding to each style
>   fullname        String  Font full names (often includes style)
>   fullnamelang    String  Languages corresponding to each fullname
>   slant           Int     Italic, oblique or roman
>   weight          Int     Light, medium, demibold, bold or black
>   size            Double  Point size
>   width           Int     Condensed, normal or expanded
>   aspect          Double  Stretches glyphs horizontally before hinting
>   pixelsize       Double  Pixel size
>   spacing         Int     Proportional, dual-width, monospace or charcell
>   foundry         String  Font foundry name
>   antialias       Bool    Whether glyphs can be antialiased
>   hinting         Bool    Whether the rasterizer should use hinting
>   hintstyle       Int     Automatic hinting style
>   verticallayout  Bool    Use vertical layout
>   autohint        Bool    Use autohinter instead of normal hinter
>   globaladvance   Bool    Use font global advance data
>   file            String  The filename holding the font
>   index           Int     The index of the font within the file
>   ftface          FT_Face Use the specified FreeType face object
>   rasterizer      String  Which rasterizer is in use
>   outline         Bool    Whether the glyphs are outlines
>   scalable        Bool    Whether glyphs can be scaled
>   scale           Double  Scale factor for point->pixel conversions
>   dpi             Double  Target dots per inch
>   rgba            Int     unknown, rgb, bgr, vrgb, vbgr,
>                           none - subpixel geometry
>   minspace        Bool    Eliminate leading from line spacing
>   charset         CharSet Unicode chars encoded by the font
>   lang            String  List of RFC-3066-style languages this
>                           font supports
>   fontversion     Int     Version number of the font
>   capability      String  List of layout capabilities in the font
>   embolden        Bool    Rasterizer should synthetically embolden the font
> 
> Not all of these are usable by fc-list.
> 
>>>> The updated mkftcap script should cope with multi-font files; the part
>>>> which uses fc-list outputs the index, and should append it to the path
>>>> if it isn't zero. I can't test this, as none of my font files have
>>>> more than one font.
>>>> 
>>> Actually, the index from fc-list isn't useful.  All it does is return
>>> the first index (0) in each file, whether or not it has multiple
>>> faces.  That is, there is only one entry per font file, which makes
>>> sense, since it's listing font files and that's all we really want at
>>> this stage.
>>> 
>>> The face index should be left to the user to find out, with some sort
>>> of d.freetype.info command, which could use the FT library to get
>>> font info in C.  It should return index and face name, so the user
>>> would know what index to use for which style.  The output could also
>>> be parsed and used by the GUI so a full list of fonts and styles
>>> could be build instead of just a list of files.
>> 
>> So, if you DO know the font face index, how do you specify it in GRASS_FONT?
> 
> Append a vertical bar followed by the index (in decimal) to the file's
> path.

__________________________________________
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  Thu May  3 02:07:06 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Thu May  3 02:07:22 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <17977.9698.623547.191734@cerise.gclements.plus.com>
Message-ID: <C25E75BA.2EC78%michael.barton@asu.edu>

In that case it is working correctly.

Michael


On 5/2/07 4:59 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> In fact, I was too hasty in my optimistic report. mkftcap works, but it
>> doesn't put the output into my $GISBASE/etc/freetypecap file. It just
>> outputs it to the terminal. I can manually deal with this
>> 
>> mkftcap>$GISBASE/etc/freetypecap
>> 
>> but something is not working right. Maybe need to recompile.
> 
> It is meant to write to stdout; it originally wrote directly to the
> freetypecap file, but was changed to improve flexibility.

__________________________________________
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  Thu May  3 02:16:01 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 02:16:11 2007
Subject: [GRASS-dev] v.digit crash
In-Reply-To: <20070502204652.GX27153@bartok.itc.it>
References: <20070502185131.GU27153@bartok.itc.it>
	<20070502204652.GX27153@bartok.itc.it>
Message-ID: <17977.10689.814954.842123@cerise.gclements.plus.com>


Markus Neteler wrote:

> > I managed to crash the new v.digit by editing the "streams"
> > map of the new NC dataset. I tried to insert a new point
> > (outlet), then
> > 
> > g.copy vect=streams,mystreams
> > v.digit mystreams
> > X Error of failed request:  BadAlloc (insufficient resources for operation)
> >   Major opcode of failed request:  53 (X_CreatePixmap)
> >   Serial number of failed request:  4353
> >   Current serial number in output stream:  4361

> Digging further into this, I found out that it doesn't crash with the DBF
> driver. So it is related to the SQLite driver.
> 
> Here some more debugging stuff:
> http://mpa.itc.it/markus/tmp/vdigit_settings_sqlite.png
> (how the table definition looks like in v.digit - all 99999 lengths!)
> 
> DEBUG=2 output, put here to not make the mail too long:
> http://mpa.itc.it/markus/tmp/vdigit_settings_sqlite.txt

> <INPUT type=text size=99999 name=FTYPE value="">

That will translate into a Tk entry widget with "-width 99999", which
could be nasty.

> There are various size=99999 there which come from
> db/drivers/sqlite/describe.c
> 
>    113          fsize = 99999; /* sqlite doesn't care, it must be long enough to
>    114                            satisfy tests in GRASS */
> 
> Last year I changes fsize from -1 to 99999 for v.in.ascii:
> 
> 2006-07-04 11:24  markus
>         * describe.c: define sufficient length to make v.in.ascii functional
> 
> So far it worked. The trick seems to be to get it fixed for the form in
> v.digit.

The same issue could apply to code using the form library, as that
uses the same HTML library.

The main question is where to fix it; in the HTML library, in the code
which generates the form, or in the database driver.

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

From glynn at gclements.plus.com  Thu May  3 02:22:01 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 02:22:05 2007
Subject: [GRASS-dev] d.vect kills d.mon
In-Reply-To: <20070502220542.GA27153@bartok.itc.it>
References: <20070502220542.GA27153@bartok.itc.it>
Message-ID: <17977.11049.536917.664754@cerise.gclements.plus.com>


Markus Neteler wrote:

> mysterious day: I used v.clean on a map to break/snap/rmdupl
> and a topologically correct map is generated. But looking at
> it, d.vect kills x0:

Hamish made some changes to icon plotting in d.vect yesterday, so
those would be the prime suspect:

	RCS file: /grassrepository/grass6/display/d.vect/plot1.c,v
	Working file: plot1.c
	head: 1.32
	branch:
	locks: strict
	access list:
	keyword substitution: kv
	total revisions: 33;	selected revisions: 3
	description:
	----------------------------
	revision 1.32
	date: 2007/05/02 10:42:34;  author: hamish;  state: Exp;  lines: +2 -1
	centroids always use default color to stand out from underlying area
	----------------------------
	revision 1.31
	date: 2007/05/02 10:04:39;  author: hamish;  state: Exp;  lines: +68 -125
	bugfix: wasn't calculating new x,y for icon if colors were off (potentially nasty)
	simplification: use D_symbol() to plot symbols
	speed: only plot symbols which are in the graphics frame (massive speedup for LIDAR)
	readability: change "rgb" variable name and set it using boolean values
	----------------------------
	revision 1.20.4.1
	date: 2007/05/02 10:13:51;  author: hamish;  state: Exp;  lines: +4 -3
	bugfix: wasn't calculating new x,y for icon if colors were offr
	   (potentially nasty, probably never triggered)

> strace d.vect myroads_net col=red
> ...
> _llseek(6, 147456, [147456], SEEK_SET)  = 0
> _llseek(6, 147456, [147456], SEEK_SET)  = 0
> _llseek(6, 147456, [147456], SEEK_SET)  = 0
> _llseek(6, 147456, [147456], SEEK_SET)  = 0
> read(6, "\252\327\353\307\353>\"A\274\222\250\200\301\311RA\v\2"..., 4096) = 139
> _llseek(6, 147595, [147595], SEEK_SET)  = 0
> _llseek(6, 147595, [147595], SEEK_SET)  = 0
> _llseek(6, 147595, [147595], SEEK_SET)  = 0
> rt_sigaction(SIGINT, {SIG_IGN}, {SIG_DFL}, 8) = 0
> rt_sigaction(SIGQUIT, {SIG_IGN}, {SIG_DFL}, 8) = 0
> write(4, "\0\0\177\6\377\0\0\177\6\377\0\0\177\6\377\0\0\177\6\377"..., 1484) = 1484
> read(5, "", 1)                          = 0
> write(2, "ERROR eof from graphics driver.\n", 32ERROR eof from graphics driver.
> ) = 32
> exit_group(1)                           = ?
> Process 27067 detached
> 
> Not sure where "ERROR eof from graphics driver" originates from, probably
> lib/raster/rem_io.c?

Yes.

Debugging display commands is easier using direct rendering, as the
task isn't split between multiple processes (the client and the
display driver). E.g.:

	$ GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect
	> run myroads_net col=red

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

From woklist at kyngchaos.com  Thu May  3 02:28:23 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Thu May  3 02:28:29 2007
Subject: [GRASS-dev] Can't get font face index to work
Message-ID: <2EB8EDC8-DA97-46FB-8B4E-AC6636851355@kyngchaos.com>

Any index I try is displaying the same default face 0.

Bypassing the freetypecap for now so I can try it:

d.font path="/System/Library/Fonts/Times.dfont"
d.text -m text="some text"

-> Times roman used

d.font path="/System/Library/Fonts/Times.dfont|1"
d.text -m text="some text"

-> Times roman

...

d.font path="/System/Library/Fonts/Times.dfont|4"
d.text -m text="some text"

-> Times roman

This one is outside the range of available faces (4) in this font file.


Tried putting them in the freetypecap:

Times0:/System/Library/Fonts/Times.dfont|0:utf-8:
Times1:/System/Library/Fonts/Times.dfont|1:utf-8:
Times2:/System/Library/Fonts/Times.dfont|2:utf-8:
Times3:/System/Library/Fonts/Times.dfont|3:utf-8:

d.font doesn't complain, but when I click where I want to draw the  
text, it says "WARNING: unable to open font map 'Times0'"

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.


From woklist at kyngchaos.com  Thu May  3 02:44:20 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Thu May  3 02:44:26 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <00CBBE51-DC43-45DB-8D59-4079D674A6FA@kyngchaos.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
	<893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
	<C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>
	<00CBBE51-DC43-45DB-8D59-4079D674A6FA@kyngchaos.com>
Message-ID: <5D81E0F1-F769-4C18-9349-500275DB28BC@kyngchaos.com>

more trouble...

Now that mkftcap is not hanging for me, next problem.  For some  
reason the resource fonts are getting filtered out.

The first part, listing ttf, seems to be working.  The fc-list part  
should work - alone, the fc-list :outline file index command shows  
all the fonts.  But after the sed, they're gone.  Could it be because  
they don't have a file extension?

Here's a small clip of the raw fc-list output:

/System/Library/Fonts/Times.dfont: :index=0
/Library/Fonts/Arial Narrow: :index=0
/System/Library/Fonts/???????? Std W8.otf: :index=0
/System/Library/Fonts/Apple LiGothic Medium.dfont: :index=0
/Library/Fonts/Arial Rounded Bold: :index=0
/Library/Fonts/Times New Roman: :index=0
/Library/Fonts/Andale Mono: :index=0
/System/Library/Fonts/ZapfDingbats.dfont: :index=0
/System/Library/Fonts/Hei.dfont: :index=0

Arial Narrow, Arial Rounded Bold, Times New Roman and Andale Mono  
disappear after the sed.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an  
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy



From hamish_nospam at yahoo.com  Thu May  3 03:17:02 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 03:17:06 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <5D81E0F1-F769-4C18-9349-500275DB28BC@kyngchaos.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
	<893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
	<C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>
	<00CBBE51-DC43-45DB-8D59-4079D674A6FA@kyngchaos.com>
	<5D81E0F1-F769-4C18-9349-500275DB28BC@kyngchaos.com>
Message-ID: <20070503131702.1026de6d.hamish_nospam@yahoo.com>

William Kyngesburye wrote:
> 
> Here's a small clip of the raw fc-list output:
> 
> /System/Library/Fonts/Times.dfont: :index=0
> /Library/Fonts/Arial Narrow: :index=0
> /System/Library/Fonts/???????????????????????? Std W8.otf: :index=0
> /System/Library/Fonts/Apple LiGothic Medium.dfont: :index=0
> /Library/Fonts/Arial Rounded Bold: :index=0
> /Library/Fonts/Times New Roman: :index=0
> /Library/Fonts/Andale Mono: :index=0
> /System/Library/Fonts/ZapfDingbats.dfont: :index=0
> /System/Library/Fonts/Hei.dfont: :index=0
> 
> Arial Narrow, Arial Rounded Bold, Times New Roman and Andale Mono  
> disappear after the sed.


replace spaces in font names with underscores?


Hamish

From woklist at kyngchaos.com  Thu May  3 03:32:17 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Thu May  3 03:32:24 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <20070503131702.1026de6d.hamish_nospam@yahoo.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
	<893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
	<C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>
	<00CBBE51-DC43-45DB-8D59-4079D674A6FA@kyngchaos.com>
	<5D81E0F1-F769-4C18-9349-500275DB28BC@kyngchaos.com>
	<20070503131702.1026de6d.hamish_nospam@yahoo.com>
Message-ID: <4022A8D1-3C65-4094-84C0-DDB3D7963D29@kyngchaos.com>


On May 2, 2007, at 8:17 PM, Hamish wrote:

> William Kyngesburye wrote:
>>
>> Here's a small clip of the raw fc-list output:
>>
>> /System/Library/Fonts/Times.dfont: :index=0
>> /Library/Fonts/Arial Narrow: :index=0
>> /System/Library/Fonts/???????? ??????????????? Std W8.otf: :index=0
>> /System/Library/Fonts/Apple LiGothic Medium.dfont: :index=0
>> /Library/Fonts/Arial Rounded Bold: :index=0
>> /Library/Fonts/Times New Roman: :index=0
>> /Library/Fonts/Andale Mono: :index=0
>> /System/Library/Fonts/ZapfDingbats.dfont: :index=0
>> /System/Library/Fonts/Hei.dfont: :index=0
>>
>> Arial Narrow, Arial Rounded Bold, Times New Roman and Andale Mono
>> disappear after the sed.
>
>
> replace spaces in font names with underscores?

Not a good idea - if you mean renaming the font files.  These are  
standard fonts supplied with OSX.  Renaming them can create possible  
OS update problems.

If I take enough time to let my brain process the sed command, it  
looks like it's something in:

\(.*\)\.\([^.]*\):

that is, the file extension is not optional.  Spaces are OK in that.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

[Trillian]  What are you supposed to do WITH a maniacally depressed  
robot?

[Marvin]  You think you have problems?  What are you supposed to do  
if you ARE a maniacally depressed robot?  No, don't try and answer,  
I'm 50,000 times more intelligent than you and even I don't know the  
answer...

- HitchHiker's Guide to the Galaxy



From dca.gis at gmail.com  Thu May  3 04:52:06 2007
From: dca.gis at gmail.com (Daniel Calvelo)
Date: Thu May  3 04:52:11 2007
Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar?
In-Reply-To: <20070502090258.GA27153@bartok.itc.it>
References: <20070501152503.GB19013@bartok.itc.it>
	<C25D03EA.218FC%michael.barton@asu.edu>
	<20070502090258.GA27153@bartok.itc.it>
Message-ID: <1a486f560705021952o3c5787fbla35fe06afb9f93bd@mail.gmail.com>

Markus, could you try the version attached? I think I got it right but
can't access a CVS build right now, so v.univar -e is unavailable for
me right now.

If ok, I'll commit to HEAD.

Daniel.

On 5/2/07, Markus Neteler <neteler@itc.it> wrote:
> It seems to be slightly more complicated (I tried), so I
> leave it for now.
>
> Markus
>
> On Tue, May 01, 2007 at 02:49:14PM -0700, Michael Barton wrote:
> > If it does extended stats now and the output is the same, it should be an
> > easy switch.
> >
> > Michael
> >
> >
> > On 5/1/07 8:25 AM, "Markus Neteler" <neteler@itc.it> wrote:
> >
> > > Hi,
> > >
> > > can we safely change v.univar.sh -> v.univar in d.vect.thematic?
> > > This might speed up calculations...
> > >
> > > Markus
> > >
> > >
> >
> > __________________________________________
> > 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
> >
> >
>
> --
> Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
> FBK-irst -  Centro per la Ricerca Scientifica e Tecnologica
> MPBA - Predictive Models for Biol. & Environ. Data Analysis
> Via Sommarive, 18        -       38050 Povo (Trento), Italy
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>


-- 
-- Daniel Calvelo Aros
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w
Type: application/octet-stream
Size: 37670 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070502/e0d76822/w-0001.obj
From hamish_nospam at yahoo.com  Thu May  3 05:01:46 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 05:01:52 2007
Subject: [GRASS-dev] Re: d.vect changes
In-Reply-To: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
Message-ID: <20070503150146.4134703f.hamish_nospam@yahoo.com>

Yesterday, Hamish wrote:
> I've just committed some changes to d.vect in CVS. of note:
..
> simplification: use D_symbol() to plot symbols. This changes how -c
> random and rgb_column work on symbols. Now fill color is constant (ie
> whatever fcolor= was set to) and line color changes; previously -c or
> -a changed either the line color or fillcolor depending on if the
> symbol primitive drawing STRINGs or POLYGONs (that does odd things to
> symbols that use both, like pushpin).
..
> I can solve the pushpin problem by forcing its line color to always be
> black.

I've done that now.

> But that doesn't solve the "x" vs "o", stroke vs fill, problem.
..
> clone of D_symbol() using primary_color and secondary_color instead of
> line_color and fill_color??

I've done that now.

D_symbol2():
 * The same as D_symbol(), but it uses a primary and secondary color
 * instead of line and fill color. The primary color is used to draw
 * stroke lines (STRINGs) and as the fill color for polygons. The
 * secondary color is used for polygon outlines.
TODO: merge duplicate D_symbol() code into common lib fns in symbol.c


Markus wrote:
> d.vect kills x0
..
> strace d.vect myroads_net col=red

don't know, can you reproduce it with a spearfish map?
make distclean? ;)

In the past segfaults had arisen from untested combinations of
color=none and fcolor=none leading to uninit'd variables, but I think
I've caught all those. One thing I haven't tested is using with
rgb_column, but I haven't touched that part of d.vect so I think it'll
still be ok.

> mysterious day:

same here, e.g. I never received your email, nor mine above. Only
Glynn's response. But they show up on Gmane. (changing back my new yahoo
->/dev/null spam filter to ->bulkmail)


Hamish

From dca.gis at gmail.com  Thu May  3 05:09:10 2007
From: dca.gis at gmail.com (Daniel Calvelo)
Date: Thu May  3 05:09:14 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <4022A8D1-3C65-4094-84C0-DDB3D7963D29@kyngchaos.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
	<893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
	<C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>
	<00CBBE51-DC43-45DB-8D59-4079D674A6FA@kyngchaos.com>
	<5D81E0F1-F769-4C18-9349-500275DB28BC@kyngchaos.com>
	<20070503131702.1026de6d.hamish_nospam@yahoo.com>
	<4022A8D1-3C65-4094-84C0-DDB3D7963D29@kyngchaos.com>
Message-ID: <1a486f560705022009o48596ccexd3b697eeb056df33@mail.gmail.com>

On 5/2/07, William Kyngesburye <woklist@kyngchaos.com> wrote:
[...]
>
> If I take enough time to let my brain process the sed command, it
> looks like it's something in:
>
> \(.*\)\.\([^.]*\):
>
> that is, the file extension is not optional.  Spaces are OK in that.

Try \(.*\)(\.\([^.]*\))?: instead.

Daniel.

-- 
-- Daniel Calvelo Aros

From glynn at gclements.plus.com  Thu May  3 05:50:12 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 05:50:14 2007
Subject: [GRASS-dev] Can't get font face index to work
In-Reply-To: <2EB8EDC8-DA97-46FB-8B4E-AC6636851355@kyngchaos.com>
References: <2EB8EDC8-DA97-46FB-8B4E-AC6636851355@kyngchaos.com>
Message-ID: <17977.23540.24386.542852@cerise.gclements.plus.com>


William Kyngesburye wrote:

> Any index I try is displaying the same default face 0.
> 
> Bypassing the freetypecap for now so I can try it:
> 
> d.font path="/System/Library/Fonts/Times.dfont"
> d.text -m text="some text"
> 
> -> Times roman used
> 
> d.font path="/System/Library/Fonts/Times.dfont|1"
> d.text -m text="some text"
> 
> -> Times roman
> 
> ...
> 
> d.font path="/System/Library/Fonts/Times.dfont|4"
> d.text -m text="some text"
> 
> -> Times roman
> 
> This one is outside the range of available faces (4) in this font file.
> 
> 
> Tried putting them in the freetypecap:
> 
> Times0:/System/Library/Fonts/Times.dfont|0:utf-8:
> Times1:/System/Library/Fonts/Times.dfont|1:utf-8:
> Times2:/System/Library/Fonts/Times.dfont|2:utf-8:
> Times3:/System/Library/Fonts/Times.dfont|3:utf-8:
> 
> d.font doesn't complain, but when I click where I want to draw the  
> text, it says "WARNING: unable to open font map 'Times0'"

Weird. I would expect specifying an explicit path to fail, as the
driver code checks for the existence of the file before stripping the
index. Using a name from the freetypecap file should work, though.

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

From glynn at gclements.plus.com  Thu May  3 06:02:59 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 06:03:01 2007
Subject: [GRASS-dev] Can't get font face index to work
In-Reply-To: <17977.23540.24386.542852@cerise.gclements.plus.com>
References: <2EB8EDC8-DA97-46FB-8B4E-AC6636851355@kyngchaos.com>
	<17977.23540.24386.542852@cerise.gclements.plus.com>
Message-ID: <17977.24307.449270.231967@cerise.gclements.plus.com>


Glynn Clements wrote:

> > Any index I try is displaying the same default face 0.
> > 
> > Bypassing the freetypecap for now so I can try it:
> > 
> > d.font path="/System/Library/Fonts/Times.dfont"
> > d.text -m text="some text"
> > 
> > -> Times roman used
> > 
> > d.font path="/System/Library/Fonts/Times.dfont|1"
> > d.text -m text="some text"
> > 
> > -> Times roman
> > 
> > ...
> > 
> > d.font path="/System/Library/Fonts/Times.dfont|4"
> > d.text -m text="some text"
> > 
> > -> Times roman
> > 
> > This one is outside the range of available faces (4) in this font file.
> > 
> > 
> > Tried putting them in the freetypecap:
> > 
> > Times0:/System/Library/Fonts/Times.dfont|0:utf-8:
> > Times1:/System/Library/Fonts/Times.dfont|1:utf-8:
> > Times2:/System/Library/Fonts/Times.dfont|2:utf-8:
> > Times3:/System/Library/Fonts/Times.dfont|3:utf-8:
> > 
> > d.font doesn't complain, but when I click where I want to draw the  
> > text, it says "WARNING: unable to open font map 'Times0'"
> 
> Weird. I would expect specifying an explicit path to fail, as the
> driver code checks for the existence of the file before stripping the
> index. Using a name from the freetypecap file should work, though.

Actually, I expect using a name from the freetypecap file to result in
the index being ignored. parse_freetypecap() strips the index so that
it can check for file existence, then returns the stripped version.

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

From glynn at gclements.plus.com  Thu May  3 06:28:35 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 06:28:39 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <1a486f560705022009o48596ccexd3b697eeb056df33@mail.gmail.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
	<893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
	<C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>
	<00CBBE51-DC43-45DB-8D59-4079D674A6FA@kyngchaos.com>
	<5D81E0F1-F769-4C18-9349-500275DB28BC@kyngchaos.com>
	<20070503131702.1026de6d.hamish_nospam@yahoo.com>
	<4022A8D1-3C65-4094-84C0-DDB3D7963D29@kyngchaos.com>
	<1a486f560705022009o48596ccexd3b697eeb056df33@mail.gmail.com>
Message-ID: <17977.25843.954195.730942@cerise.gclements.plus.com>


Daniel Calvelo wrote:

> > If I take enough time to let my brain process the sed command, it
> > looks like it's something in:
> >
> > \(.*\)\.\([^.]*\):
> >
> > that is, the file extension is not optional.  Spaces are OK in that.
> 
> Try \(.*\)(\.\([^.]*\))?: instead.

A ? in a sed regexp is a GNU extension.

I've updated mkftcap to handle files without an extension separately:

        fc-list :outline file index \
            | sed -n \
                  -e 's!^\(.*\)/\(.*\)\.\([^.]*\): :index=0$!\2:\1/\2.\3:utf-8:!p' \
                  -e 's!^\(.*\)/\(.*\)\.\([^.]*\): :index=\([0-9]\+\)$!\2:\1/\2.\3|\4:utf-8:!p' \
                  -e 's!^\(.*\)/\(.*\): :index=0$!\2:\1/\2:utf-8:!p' \
                  -e 's!^\(.*\)/\(.*\): :index=\([0-9]\+\)$!\2:\1/\2|\3:utf-8:!p'

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

From glynn at gclements.plus.com  Thu May  3 06:29:06 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 06:29:08 2007
Subject: [GRASS-dev] Can't get font face index to work
In-Reply-To: <17977.24307.449270.231967@cerise.gclements.plus.com>
References: <2EB8EDC8-DA97-46FB-8B4E-AC6636851355@kyngchaos.com>
	<17977.23540.24386.542852@cerise.gclements.plus.com>
	<17977.24307.449270.231967@cerise.gclements.plus.com>
Message-ID: <17977.25874.205224.611892@cerise.gclements.plus.com>


Glynn Clements wrote:

> > > Any index I try is displaying the same default face 0.
> > > 
> > > Bypassing the freetypecap for now so I can try it:
> > > 
> > > d.font path="/System/Library/Fonts/Times.dfont"
> > > d.text -m text="some text"
> > > 
> > > -> Times roman used
> > > 
> > > d.font path="/System/Library/Fonts/Times.dfont|1"
> > > d.text -m text="some text"
> > > 
> > > -> Times roman
> > > 
> > > ...
> > > 
> > > d.font path="/System/Library/Fonts/Times.dfont|4"
> > > d.text -m text="some text"
> > > 
> > > -> Times roman
> > > 
> > > This one is outside the range of available faces (4) in this font file.
> > > 
> > > 
> > > Tried putting them in the freetypecap:
> > > 
> > > Times0:/System/Library/Fonts/Times.dfont|0:utf-8:
> > > Times1:/System/Library/Fonts/Times.dfont|1:utf-8:
> > > Times2:/System/Library/Fonts/Times.dfont|2:utf-8:
> > > Times3:/System/Library/Fonts/Times.dfont|3:utf-8:
> > > 
> > > d.font doesn't complain, but when I click where I want to draw the  
> > > text, it says "WARNING: unable to open font map 'Times0'"
> > 
> > Weird. I would expect specifying an explicit path to fail, as the
> > driver code checks for the existence of the file before stripping the
> > index. Using a name from the freetypecap file should work, though.
> 
> Actually, I expect using a name from the freetypecap file to result in
> the index being ignored. parse_freetypecap() strips the index so that
> it can check for file existence, then returns the stripped version.

This should now be fixed.

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

From glynn at gclements.plus.com  Thu May  3 06:41:03 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 06:41:07 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17976.13926.328258.937247@cerise.gclements.plus.com>
References: <C25B9E96.2EAB5%michael.barton@asu.edu>
	<4636D923.4040306@bergenheim.net>
	<17975.715.470421.874125@cerise.gclements.plus.com>
	<789F1BC0-9494-4A42-B385-C0D8AA23B37A@kyngchaos.com>
	<B6582416-B6F4-4DBA-B2BF-5F37E6537397@kyngchaos.com>
	<17975.62700.469950.591439@cerise.gclements.plus.com>
	<97D61CF6-36DC-46A7-BEB5-499332C5462B@kyngchaos.com>
	<17976.13926.328258.937247@cerise.gclements.plus.com>
Message-ID: <17977.26591.140274.81383@cerise.gclements.plus.com>


Glynn Clements wrote:

> > Then there is the other problem - resource fonts, dfonts and otf  
> > fonts can have, and most do in the OSX system, multiple faces per  
> > file.  The font display routines in GRASS need an option to specify a  
> > face in a font file, either by index number or name.  Otherwise most  
> > of the fonts included in OSX are of limited usefulness.
> 
> That's easy enough to implement.
> 
> One option is to pick an arbitrary character to separate the index
> from the filename. If the path ends with that character followed by a
> number, the number is the index.
> 
> That has the advantage that only the lowest level of the driver code
> needs to change (draw_main(), in lib/driver/text3.c; the function
> which calls FT_New_Face()).

One disadvantage is that it won't work with options with:

	opt->gisprompt = "old_file,..."

I'm strongly leaning towards eliminating the option to specify fonts
by paths, and just require the use of a name which is looked up in the
freetypecap file.

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

From dca.gis at gmail.com  Thu May  3 06:51:46 2007
From: dca.gis at gmail.com (Daniel Calvelo)
Date: Thu May  3 06:51:51 2007
Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar?
In-Reply-To: <1a486f560705021952o3c5787fbla35fe06afb9f93bd@mail.gmail.com>
References: <20070501152503.GB19013@bartok.itc.it>
	<C25D03EA.218FC%michael.barton@asu.edu>
	<20070502090258.GA27153@bartok.itc.it>
	<1a486f560705021952o3c5787fbla35fe06afb9f93bd@mail.gmail.com>
Message-ID: <1a486f560705022151x5e1fadf4xa2cc1451b0ef136c@mail.gmail.com>

Ooops, sorry for the noise. I managed to recompile CVS and of course I
had gotten it all wrong. v.univar and v.univar.sh have different
interfaces.

Good news: the attached d.vect.thematic version works using v.univar

Bad news: as pointed out in v.univar source, extended stats
(nonparametric) are only available for points/centroids

Martin, why is it harder to calculate those for area/boundary/line ?
Aren't we just accessing the db corresponding to the layer?

So currently, we can't fully replace v.univar.sh with v.univar for
d.vect.thematic purposes. The clean course of action is to extend
v.univar to calculate extended stats for the rest of types.

Daniel.

On 5/2/07, Daniel Calvelo <dca.gis@gmail.com> wrote:
> Markus, could you try the version attached? I think I got it right but
> can't access a CVS build right now, so v.univar -e is unavailable for
> me right now.
>
> If ok, I'll commit to HEAD.
>
> Daniel.
>
> On 5/2/07, Markus Neteler <neteler@itc.it> wrote:
> > It seems to be slightly more complicated (I tried), so I
> > leave it for now.
> >
> > Markus
> >
> > On Tue, May 01, 2007 at 02:49:14PM -0700, Michael Barton wrote:
> > > If it does extended stats now and the output is the same, it should be an
> > > easy switch.
> > >
> > > Michael
> > >
> > >
> > > On 5/1/07 8:25 AM, "Markus Neteler" <neteler@itc.it> wrote:
> > >
> > > > Hi,
> > > >
> > > > can we safely change v.univar.sh -> v.univar in d.vect.thematic?
> > > > This might speed up calculations...
> > > >
> > > > Markus
> > > >
> > > >
> > >
> > > __________________________________________
> > > 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
> > >
> > >
> >
> > --
> > Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
> > FBK-irst -  Centro per la Ricerca Scientifica e Tecnologica
> > MPBA - Predictive Models for Biol. & Environ. Data Analysis
> > Via Sommarive, 18        -       38050 Povo (Trento), Italy
> >
> > _______________________________________________
> > grass-dev mailing list
> > grass-dev@grass.itc.it
> > http://grass.itc.it/mailman/listinfo/grass-dev
> >
>
>
> --
> -- Daniel Calvelo Aros
>
>


-- 
-- Daniel Calvelo Aros
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w
Type: application/octet-stream
Size: 37648 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070502/152928fd/w-0001.obj
From woklist at kyngchaos.com  Thu May  3 07:00:10 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Thu May  3 07:00:18 2007
Subject: [GRASS-dev] problems with mkftcap
In-Reply-To: <17977.25843.954195.730942@cerise.gclements.plus.com>
References: <17976.14218.356268.260031@cerise.gclements.plus.com>
	<C25D8653.21956%michael.barton@asu.edu>
	<17976.17667.172986.583275@cerise.gclements.plus.com>
	<893F5A23-607A-4FA3-9039-E3377EDDC816@kyngchaos.com>
	<C1D557E4-6E39-4F51-AAFD-BACDA366B382@kyngchaos.com>
	<00CBBE51-DC43-45DB-8D59-4079D674A6FA@kyngchaos.com>
	<5D81E0F1-F769-4C18-9349-500275DB28BC@kyngchaos.com>
	<20070503131702.1026de6d.hamish_nospam@yahoo.com>
	<4022A8D1-3C65-4094-84C0-DDB3D7963D29@kyngchaos.com>
	<1a486f560705022009o48596ccexd3b697eeb056df33@mail.gmail.com>
	<17977.25843.954195.730942@cerise.gclements.plus.com>
Message-ID: <8351208D-DEBD-4131-A330-66FF65F27D81@kyngchaos.com>

That works.  (still a minor problem with Arial, but not the other  
Arial varieties, it's probably a corrupt font file or other non- 
fontconfig/grass issue)

One note - did you catch my other comment a while back?  the index  
from fc-list is useless, since fc-list appears to only list font  
files, thus only showing index 0 for any font file.  We'll have to  
find another way to figure out available faces within a font file.

On May 2, 2007, at 11:28 PM, Glynn Clements wrote:

>
> Daniel Calvelo wrote:
>
>>> If I take enough time to let my brain process the sed command, it
>>> looks like it's something in:
>>>
>>> \(.*\)\.\([^.]*\):
>>>
>>> that is, the file extension is not optional.  Spaces are OK in that.
>>
>> Try \(.*\)(\.\([^.]*\))?: instead.
>
> A ? in a sed regexp is a GNU extension.
>
> I've updated mkftcap to handle files without an extension separately:
>
>         fc-list :outline file index \
>             | sed -n \
>                   -e 's!^\(.*\)/\(.*\)\.\([^.]*\): :index=0$!\2:\1/ 
> \2.\3:utf-8:!p' \
>                   -e 's!^\(.*\)/\(.*\)\.\([^.]*\): :index=\([0-9]\+ 
> \)$!\2:\1/\2.\3|\4:utf-8:!p' \
>                   -e 's!^\(.*\)/\(.*\): :index=0$!\2:\1/\2:utf-8:!p' \
>                   -e 's!^\(.*\)/\(.*\): :index=\([0-9]\+\)$!\2:\1/ 
> \2|\3:utf-8:!p'
>
> -- 
> Glynn Clements <glynn@gclements.plus.com>

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled  
with hyena offal?
Second Pogril: I don't know.  Why IS life like sticking your head in  
a bucket filled with hyena offal?
First Pogril: I don't know either.  Wretched, isn't it?

-HitchHiker's Guide to the Galaxy


From dca.gis at gmail.com  Thu May  3 07:18:51 2007
From: dca.gis at gmail.com (Daniel Calvelo)
Date: Thu May  3 07:18:53 2007
Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar?
In-Reply-To: <1a486f560705022151x5e1fadf4xa2cc1451b0ef136c@mail.gmail.com>
References: <20070501152503.GB19013@bartok.itc.it>
	<C25D03EA.218FC%michael.barton@asu.edu>
	<20070502090258.GA27153@bartok.itc.it>
	<1a486f560705021952o3c5787fbla35fe06afb9f93bd@mail.gmail.com>
	<1a486f560705022151x5e1fadf4xa2cc1451b0ef136c@mail.gmail.com>
Message-ID: <1a486f560705022218k3317ed08wf3084f12807ebf68@mail.gmail.com>

Replying to myself twice, sorry.

After reading v.univar/main.c more thoroughly, I think I'm
understanding the issue: v.univar.sh is *not* a shell equivalent of
v.univar. Actually, v.univar.sh should have been called v.db.univar.
In v.univar the statistics collected are those of the vector map, not
only of its database: a type=area in v.univar should mean collect
statistics weighted by area and so on.

For d.vect.thematic as it stands now, no information is used about the
geometry, so it only depends on the currently implemented
type=point,centroid behaviour of v.univar.

I commited to CVS.

Daniel.

On 5/2/07, Daniel Calvelo <dca.gis@gmail.com> wrote:
> Ooops, sorry for the noise. I managed to recompile CVS and of course I
> had gotten it all wrong. v.univar and v.univar.sh have different
> interfaces.
>
> Good news: the attached d.vect.thematic version works using v.univar
>
> Bad news: as pointed out in v.univar source, extended stats
> (nonparametric) are only available for points/centroids
>
> Martin, why is it harder to calculate those for area/boundary/line ?
> Aren't we just accessing the db corresponding to the layer?
>
> So currently, we can't fully replace v.univar.sh with v.univar for
> d.vect.thematic purposes. The clean course of action is to extend
> v.univar to calculate extended stats for the rest of types.
>
> Daniel.
>
> On 5/2/07, Daniel Calvelo <dca.gis@gmail.com> wrote:
> > Markus, could you try the version attached? I think I got it right but
> > can't access a CVS build right now, so v.univar -e is unavailable for
> > me right now.
> >
> > If ok, I'll commit to HEAD.
> >
> > Daniel.
> >
> > On 5/2/07, Markus Neteler <neteler@itc.it> wrote:
> > > It seems to be slightly more complicated (I tried), so I
> > > leave it for now.
> > >
> > > Markus
> > >
> > > On Tue, May 01, 2007 at 02:49:14PM -0700, Michael Barton wrote:
> > > > If it does extended stats now and the output is the same, it should be an
> > > > easy switch.
> > > >
> > > > Michael
> > > >
> > > >
> > > > On 5/1/07 8:25 AM, "Markus Neteler" <neteler@itc.it> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > can we safely change v.univar.sh -> v.univar in d.vect.thematic?
> > > > > This might speed up calculations...
> > > > >
> > > > > Markus
> > > > >
> > > > >
> > > >
> > > > __________________________________________
> > > > 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
> > > >
> > > >
> > >
> > > --
> > > Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
> > > FBK-irst -  Centro per la Ricerca Scientifica e Tecnologica
> > > MPBA - Predictive Models for Biol. & Environ. Data Analysis
> > > Via Sommarive, 18        -       38050 Povo (Trento), Italy
> > >
> > > _______________________________________________
> > > grass-dev mailing list
> > > grass-dev@grass.itc.it
> > > http://grass.itc.it/mailman/listinfo/grass-dev
> > >
> >
> >
> > --
> > -- Daniel Calvelo Aros
> >
> >
>
>
> --
> -- Daniel Calvelo Aros
>
>


-- 
-- Daniel Calvelo Aros

From woklist at kyngchaos.com  Thu May  3 07:33:54 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Thu May  3 07:34:01 2007
Subject: [GRASS-dev] Can't get font face index to work
In-Reply-To: <17977.25874.205224.611892@cerise.gclements.plus.com>
References: <2EB8EDC8-DA97-46FB-8B4E-AC6636851355@kyngchaos.com>
	<17977.23540.24386.542852@cerise.gclements.plus.com>
	<17977.24307.449270.231967@cerise.gclements.plus.com>
	<17977.25874.205224.611892@cerise.gclements.plus.com>
Message-ID: <259FF46D-61E8-4413-B9FA-C88F7B737694@kyngchaos.com>

On May 2, 2007, at 11:29 PM, Glynn Clements wrote:

>> Actually, I expect using a name from the freetypecap file to  
>> result in
>> the index being ignored. parse_freetypecap() strips the index so that
>> it can check for file existence, then returns the stripped version.
>
> This should now be fixed.
>
Progress!

These work (no warnings, and draw correct face):

Arial Narrow:/Library/Fonts/Arial Narrow:utf-8:
Times1:/System/Library/Fonts/Times.dfont|1:utf-8:

But these give the "WARNING: unable to open font map '...'":

Arial Narrow 0:/Library/Fonts/Arial Narrow|0:utf-8:
ArialNarrow0:/Library/Fonts/Arial Narrow|0:utf-8:
Times 1:/System/Library/Fonts/Times.dfont|1:utf-8:

There appear to be some <space> issues with specifying an index.

I haven't tried these by path.  Getting sleepy...

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

All generalizations are dangerous, even this one.


From neteler at itc.it  Thu May  3 07:38:07 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 07:38:09 2007
Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar?
In-Reply-To: <1a486f560705021952o3c5787fbla35fe06afb9f93bd@mail.gmail.com>
References: <20070501152503.GB19013@bartok.itc.it>
	<C25D03EA.218FC%michael.barton@asu.edu>
	<20070502090258.GA27153@bartok.itc.it>
	<1a486f560705021952o3c5787fbla35fe06afb9f93bd@mail.gmail.com>
Message-ID: <20070503053806.GB19083@bartok.itc.it>

On Wed, May 02, 2007 at 09:52:06PM -0500, Daniel Calvelo wrote:
> Markus, could you try the version attached? I think I got it right but
> can't access a CVS build right now, so v.univar -e is unavailable for
> me right now.
> 
> If ok, I'll commit to HEAD.

This version would revert all recent g.message changes.
It looks like that you worked on an older file version?

Markus
 
> Daniel.
> 
> On 5/2/07, Markus Neteler <neteler@itc.it> wrote:
> >It seems to be slightly more complicated (I tried), so I
> >leave it for now.
> >
> >Markus
> >
> >On Tue, May 01, 2007 at 02:49:14PM -0700, Michael Barton wrote:
> >> If it does extended stats now and the output is the same, it should be an
> >> easy switch.
> >>
> >> Michael
> >>
> >>
> >> On 5/1/07 8:25 AM, "Markus Neteler" <neteler@itc.it> wrote:
> >>
> >> > Hi,
> >> >
> >> > can we safely change v.univar.sh -> v.univar in d.vect.thematic?
> >> > This might speed up calculations...
> >> >
> >> > Markus
> >> >
> >> >
> >>
> >> __________________________________________
> >> 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
> >>
> >>
> >
> >--
> >Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
> >FBK-irst -  Centro per la Ricerca Scientifica e Tecnologica
> >MPBA - Predictive Models for Biol. & Environ. Data Analysis
> >Via Sommarive, 18        -       38050 Povo (Trento), Italy
> >
> >_______________________________________________
> >grass-dev mailing list
> >grass-dev@grass.itc.it
> >http://grass.itc.it/mailman/listinfo/grass-dev
> >
> 
> 
> -- 
> -- Daniel Calvelo Aros


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

-- 
Markus Neteler  <neteler itc it>  http://mpa.itc.it/markus/
FBK-irst -  Centro per la Ricerca Scientifica e Tecnologica
MPBA - Predictive Models for Biol. & Environ. Data Analysis
Via Sommarive, 18        -       38050 Povo (Trento), Italy

From neteler at itc.it  Thu May  3 07:46:22 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 07:46:24 2007
Subject: [GRASS-dev] d.vect kills d.mon
In-Reply-To: <17977.11049.536917.664754@cerise.gclements.plus.com>
References: <20070502220542.GA27153@bartok.itc.it>
	<17977.11049.536917.664754@cerise.gclements.plus.com>
Message-ID: <20070503054622.GC19083@bartok.itc.it>

On Thu, May 03, 2007 at 01:22:01AM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > mysterious day: I used v.clean on a map to break/snap/rmdupl
> > and a topologically correct map is generated. But looking at
> > it, d.vect kills x0:
> 
> Hamish made some changes to icon plotting in d.vect yesterday, so
> those would be the prime suspect:
> 
...
> > Not sure where "ERROR eof from graphics driver" originates from, probably
> > lib/raster/rem_io.c?
> 
> Yes.
> 
> Debugging display commands is easier using direct rendering, as the
> task isn't split between multiple processes (the client and the
> display driver). E.g.:
> 
> 	$ GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect
> 	> run myroads_net col=red

Ah, nice. So:

GRASS 6.3.cvs (spearfish60):~/grass63/scripts > d.mon x0

GRASS 6.3.cvs (spearfish60):~/grass63/scripts > GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect
GNU gdb 6.3-8mdv2007.0 (Mandriva Linux release 2007.0)
...
(gdb) run myroads_net col=red
Starting program: /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/bin/d.vect myroads_net col=red
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xbfffe000
[Thread debugging using libthread_db enabled]
[New Thread -1225832752 (LWP 14496)]
PNG: GRASS_TRUECOLOR status: FALSE

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225832752 (LWP 14496)]
0xb77e42d8 in fputs () from /lib/i686/libc.so.6
(gdb) bt
#0  0xb77e42d8 in fputs () from /lib/i686/libc.so.6
#1  0xb7ec37a0 in print_error (
    msg=0xbfde35a0 "PNG: collecting to  map.png,\n     GRASS_WIDTH=640, GRASS_HEIGHT=480", type=0)
    at error.c:276
#2  0xb7ec3ca5 in G_message (
    msg=0xb7e637c8 "PNG: collecting to  %s,\n     GRASS_WIDTH=%d, GRASS_HEIGHT=%d") at error.c:112
#3  0xb7e61c62 in PNG_Graph_set (argc=0, argv=0x0) at Graph_set.c:133
#4  0xb7e57351 in COM_Graph_set (argc=0, argv=0x0) at Graph.c:7
#5  0xb7e5869e in LIB_init (drv=0xb7e64f40, argc=0, argv=0x0) at init.c:79
#6  0xb7e6ad92 in LOC_open_driver () at loc_io.c:67
#7  0xb7e6a014 in R_open_driver () at com_io.c:180
#8  0x0804d7f5 in main (argc=3, argv=0xbfde6774) at main.c:375

(gdb) bt full
#0  0xb77e42d8 in fputs () from /lib/i686/libc.so.6
No symbol table info available.
#1  0xb7ec37a0 in print_error (
    msg=0xbfde35a0 "PNG: collecting to  map.png,\n     GRASS_WIDTH=640, GRASS_HEIGHT=480", type=0)
    at error.c:276
        w = Variable "w" is not available.

Hopefully this indicates the problem,
Markus

From neteler at itc.it  Thu May  3 07:47:59 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 07:48:01 2007
Subject: [GRASS-dev] Re: d.vect changes
In-Reply-To: <20070503150146.4134703f.hamish_nospam@yahoo.com>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
Message-ID: <20070503054759.GD19083@bartok.itc.it>

On Thu, May 03, 2007 at 03:01:46PM +1200, Hamish wrote:
> Markus wrote:
> > d.vect kills x0
> ..
> > strace d.vect myroads_net col=red
> 
> don't know, can you reproduce it with a spearfish map?
> make distclean? ;)

It happens with Spearfish. Just try my new v.net.path
example in the description.html.

BTW: the v.clean step therein fails - it does NOT properly
connect the lines. Sigh.
 
Markus

From otto.dassau at gmx.de  Thu May  3 07:56:17 2007
From: otto.dassau at gmx.de (Otto Dassau)
Date: Thu May  3 07:56:20 2007
Subject: [GRASS-dev] Re: d.vect changes
In-Reply-To: <20070503054759.GD19083@bartok.itc.it>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
Message-ID: <20070503075617.004779b3@localhost.localdomain>

Hi Markus,

On Thu, 3 May 2007 07:47:59 +0200
Markus Neteler <neteler@itc.it> wrote:

> On Thu, May 03, 2007 at 03:01:46PM +1200, Hamish wrote:
> > Markus wrote:
> > > d.vect kills x0
> > ..
> > > strace d.vect myroads_net col=red
> > 
> > don't know, can you reproduce it with a spearfish map?
> > make distclean? ;)
> 
> It happens with Spearfish. Just try my new v.net.path
> example in the description.html.
> 
> BTW: the v.clean step therein fails - it does NOT properly
> connect the lines. Sigh.

I don't know your example, but I had similar problems some time ago because I
used a wrong tool order. As far as I remember the one below worked for me
and connected all lines.

v.clean in=xx out=xx tool=snap,break thres=xx

regards,
 Otto

> Markus
> 

From hamish_nospam at yahoo.com  Thu May  3 08:07:29 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 08:07:34 2007
Subject: [GRASS-dev] [grass-code I][381] r.colors rules: some scripts
	broken
In-Reply-To: <20070425172455.12BE21936633@pyrosoma.intevation.org>
References: <20070425172455.12BE21936633@pyrosoma.intevation.org>
Message-ID: <20070503180729.7337dc08.hamish_nospam@yahoo.com>

http://wald.intevation.org/tracker/?func=detail&atid=204&aid=381&group_id=21
..
> code I item #381, was opened at 2007-04-25 19:24
> Summary: r.colors rules: some scripts broken 
..
> Eg. in GRASS 6.3 scripts dir:
> 
> i.in.spotvgt: 213: r.colors ${NAME} rules=ndvi 2>&1 >/dev/null
> i.in.spotvgt: 275: r.colors ${NAME}_filt rules=ndvi 2>&1 >/dev/null
> r.in.srtm: 237: r.colors rul=srtm map=$TILEOUT
> 
> Such syntax leads now to "ERROR: Unable to load rules file srtm".
> 
> How do we fix it? Add the $GISBASE/etc/colors/ before the rule name?
> Looks like a broken backwards compatibility...


[cc'd from the tracker]

r.colors was changed in 6.3 CVS,

-------
Revision 2.14, Sat Apr 14 03:35:32 2007 UTC by glynn 
..
r.colors:
..
 Merge rules= with color=
 Use rules= for external rules file
-------

you can get rid of the errors by changing "r.colors rules="
to "r.colors color=". I've just done this for r.in.srtm.

But really this will break a lot of scripts and should be revisited
to be backwards compatible. Suggestion: when it looks for the rules
file it should try looking for $GISBASE/etc/colors/$RULEFILE if it
can't find the file as just $RULEFILE.

Anything written using "r.colors rules=" will be affected.


Hamish

From hamish_nospam at yahoo.com  Thu May  3 08:36:31 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 08:36:37 2007
Subject: [GRASS-dev] [grass-code R][382] v.colors wish
In-Reply-To: <20070425203536.882961973FB6@pyrosoma.intevation.org>
References: <20070425203536.882961973FB6@pyrosoma.intevation.org>
Message-ID: <20070503183631.6802c8a7.hamish_nospam@yahoo.com>

[cc from the wish tracker]
http://wald.intevation.org/tracker/?func=detail&atid=188&aid=382&group_id=21
> code R item #382, was opened at 2007-04-25 22:35
> Submitted By: Markus Neteler (markusn)
> Summary: v.colors wish 
..
> A v.colors module (script?) is desired which helps to easily colorize
> vector maps. 
> 
> v.colors vectormap column=name color=rulesfile
> 
> where
> - column defines the column to use for colorization
> - color defines a file to the list of attribute-color matches
> 
> The principal steps will be:
> 
> 1. v.db.addcol vectormap col="GRASSRGB varchar(11)"
> 
> 2. read color definition in the style
>      attribute1 color1
>      attribute2 color2
>      ...
> 
>      with 
>        - attributeX be existing attribute in specified column
>        - colorX be color name (from X11 color list?) or RGB pattern
> 
> 3. if needed, translate color names to RRR:GGG:BBB values
> 
> 4. update attribute table column GRASSRGB
>    loop over all lines in rulesfile, doing
>       v.db.update vectormap col=GRASSRGB val="RRR:GGG:BBB"
>       where="column=attributeX"
> 
> Maybe rather easy to do, some scripting...



Date: 2007-05-03 18:31
Sender: Hamish

> A v.colors module (script?)

It is hard to do (efficiently) inside a script alone, as you
need to do some math to interpolate between the rule values for
each data point.

Suggestion: r.what.colors could be expanded to include a
colors=/rules= option to query the color for some value= based
on a predefined rules file instead of a raster map? Then you feed
all the values to be queried to r.what.colors via stdin, and get
a nice list of RRR:GGG:BBB to give to v.db.update.

Instead of v.db.update, write the SQL update statements to a $TMP
file (with ";" at each EOL) then use a single call to db.execute input=,
as this will be much much faster. (see v.in.garmin)


Hamish

ps- this would be really cool for "snail trail" plots
for a geolocated time series of vector point data.

(I have a matlab[/octave] script somewhere that does this
interpolation already, for this same purpose)

From otto.dassau at gmx.de  Thu May  3 09:20:54 2007
From: otto.dassau at gmx.de (Otto Dassau)
Date: Thu May  3 09:20:58 2007
Subject: [GRASS-dev] grass with gdal support
Message-ID: <20070503092054.5e23fd11@localhost.localdomain>

Hi, 

trying to build grass cvs with gdal support with a gdal-config inside a svn
folder I get following error message (both checkouts are only a few minutes
ago):

checking whether to use GDAL... yes
yes
checking for gdal-config... /software/gdal/apps/gdal-config
checking for GDALOpen... no
checking for GDALOpen... no
configure: error: *** couldn't find GDAL

when I build grass with the installed debian gdal package it works fine.

checking whether to use GDAL... yes
checking for gdal-config... /usr/bin/gdal-config
checking for GDALOpen... yes

Does anybody know this problem and can help?

regards,
 Otto


From neteler at itc.it  Thu May  3 09:28:31 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 09:28:33 2007
Subject: v.net.path example - was Re: [GRASS-dev] Re: d.vect changes
In-Reply-To: <20070503075617.004779b3@localhost.localdomain>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
	<20070503075617.004779b3@localhost.localdomain>
Message-ID: <20070503072829.GE19083@bartok.itc.it>

On Thu, May 03, 2007 at 07:56:17AM +0200, Otto Dassau wrote:
> Hi Markus,
> 
> On Thu, 3 May 2007 07:47:59 +0200
> Markus Neteler <neteler@itc.it> wrote:
> 
> > On Thu, May 03, 2007 at 03:01:46PM +1200, Hamish wrote:
> > > Markus wrote:
> > > > d.vect kills x0
> > > ..
> > > > strace d.vect myroads_net col=red
> > > 
> > > don't know, can you reproduce it with a spearfish map?
> > > make distclean? ;)
> > 
> > It happens with Spearfish. Just try my new v.net.path
> > example in the description.html.
> > 
> > BTW: the v.clean step therein fails - it does NOT properly
> > connect the lines. Sigh.
> 
> I don't know your example,

It is in the manual page of v.net.path (CVS).

> but I had similar problems some time ago because I
> used a wrong tool order. As far as I remember the one below worked for me
> and connected all lines.
> 
> v.clean in=xx out=xx tool=snap,break thres=xx

Indeed, this helps. To me the order of snap,break isn't much
intuitive but well.

Unfortunately, even though that the map looks ok in v.digit,
v.net.path fails to navigate (but d.path does!):

...
dglShortestPath error: Head Node Not Found
WARNUNG: Point with category [10] is not reachable from point with category
         [9]
WARNUNG: [1] destinations unreachable (including points outof threshold)
...

However, the cats are correct:
d.vect myroads_net disp=shape,cat type=point

Maybe someone could try the example?

thanks
Markus

From glynn at gclements.plus.com  Thu May  3 09:36:56 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 09:37:00 2007
Subject: [GRASS-dev] [grass-code I][381] r.colors rules: some scripts
	broken
In-Reply-To: <20070503180729.7337dc08.hamish_nospam@yahoo.com>
References: <20070425172455.12BE21936633@pyrosoma.intevation.org>
	<20070503180729.7337dc08.hamish_nospam@yahoo.com>
Message-ID: <17977.37144.972151.385@cerise.gclements.plus.com>


Hamish wrote:

> http://wald.intevation.org/tracker/?func=detail&atid=204&aid=381&group_id=21
> ..
> > code I item #381, was opened at 2007-04-25 19:24
> > Summary: r.colors rules: some scripts broken 
> ..
> > Eg. in GRASS 6.3 scripts dir:
> > 
> > i.in.spotvgt: 213: r.colors ${NAME} rules=ndvi 2>&1 >/dev/null
> > i.in.spotvgt: 275: r.colors ${NAME}_filt rules=ndvi 2>&1 >/dev/null
> > r.in.srtm: 237: r.colors rul=srtm map=$TILEOUT
> > 
> > Such syntax leads now to "ERROR: Unable to load rules file srtm".
> > 
> > How do we fix it? Add the $GISBASE/etc/colors/ before the rule name?
> > Looks like a broken backwards compatibility...
> 
> 
> [cc'd from the tracker]
> 
> r.colors was changed in 6.3 CVS,
> 
> -------
> Revision 2.14, Sat Apr 14 03:35:32 2007 UTC by glynn 
> ..
> r.colors:
> ..
>  Merge rules= with color=
>  Use rules= for external rules file
> -------
> 
> you can get rid of the errors by changing "r.colors rules="
> to "r.colors color=". I've just done this for r.in.srtm.
> 
> But really this will break a lot of scripts and should be revisited
> to be backwards compatible. Suggestion: when it looks for the rules
> file it should try looking for $GISBASE/etc/colors/$RULEFILE if it
> can't find the file as just $RULEFILE.
> 
> Anything written using "r.colors rules=" will be affected.

When I added rules=, it was made clear that this was a temporary
feature until it could replace color=.

As there hasn't been a 6.3.0 release yet, the 6.3 API remains subject
to change.

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

From glynn at gclements.plus.com  Thu May  3 10:09:03 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 10:09:05 2007
Subject: [GRASS-dev] d.vect kills d.mon
In-Reply-To: <20070503054622.GC19083@bartok.itc.it>
References: <20070502220542.GA27153@bartok.itc.it>
	<17977.11049.536917.664754@cerise.gclements.plus.com>
	<20070503054622.GC19083@bartok.itc.it>
Message-ID: <17977.39071.540639.288979@cerise.gclements.plus.com>


Markus Neteler wrote:

> GRASS 6.3.cvs (spearfish60):~/grass63/scripts > GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect
> GNU gdb 6.3-8mdv2007.0 (Mandriva Linux release 2007.0)
> ...
> (gdb) run myroads_net col=red
> Starting program: /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/bin/d.vect myroads_net col=red
> Reading symbols from shared object read from target memory...done.
> Loaded system supplied DSO at 0xbfffe000
> [Thread debugging using libthread_db enabled]
> [New Thread -1225832752 (LWP 14496)]
> PNG: GRASS_TRUECOLOR status: FALSE
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1225832752 (LWP 14496)]
> 0xb77e42d8 in fputs () from /lib/i686/libc.so.6
> (gdb) bt
> #0  0xb77e42d8 in fputs () from /lib/i686/libc.so.6
> #1  0xb7ec37a0 in print_error (
>     msg=0xbfde35a0 "PNG: collecting to  map.png,\n     GRASS_WIDTH=640, GRASS_HEIGHT=480", type=0)
>     at error.c:276
> #2  0xb7ec3ca5 in G_message (
>     msg=0xb7e637c8 "PNG: collecting to  %s,\n     GRASS_WIDTH=%d, GRASS_HEIGHT=%d") at error.c:112
> #3  0xb7e61c62 in PNG_Graph_set (argc=0, argv=0x0) at Graph_set.c:133
> #4  0xb7e57351 in COM_Graph_set (argc=0, argv=0x0) at Graph.c:7
> #5  0xb7e5869e in LIB_init (drv=0xb7e64f40, argc=0, argv=0x0) at init.c:79
> #6  0xb7e6ad92 in LOC_open_driver () at loc_io.c:67
> #7  0xb7e6a014 in R_open_driver () at com_io.c:180
> #8  0x0804d7f5 in main (argc=3, argv=0xbfde6774) at main.c:375

> #2  0xb7ec3ca5 in G_message (
>     msg=0xb7e637c8 "PNG: collecting to  %s,\n     GRASS_WIDTH=%d, GRASS_HEIGHT=%d") at error.c:112

Huh? Where did the "file:" go?

> #3  0xb7e61c62 in PNG_Graph_set (argc=0, argv=0x0) at Graph_set.c:133

133	G_message("PNG: collecting to file: %s,\n     GRASS_WIDTH=%d, GRASS_HEIGHT=%d",
134		file_name, width, height);

It may be that this is just a problem with the way that you copied the
output into the message (in which case, use "script" and a text editor
and attach the output; if you're posting diagnostic output, it needs
to be *exact*).

Apart from that:

> #0  0xb77e42d8 in fputs () from /lib/i686/libc.so.6
> #1  0xb7ec37a0 in print_error (
>     msg=0xbfde35a0 "PNG: collecting to  map.png,\n     GRASS_WIDTH=640, GRASS_HEIGHT=480", type=0)
>     at error.c:276

276	    fprintf(stderr,"%s", prefix_std[type] );

I can't think of anything except for memory corruption. But:

> #3  0xb7e61c62 in PNG_Graph_set (argc=0, argv=0x0) at Graph_set.c:133
> #4  0xb7e57351 in COM_Graph_set (argc=0, argv=0x0) at Graph.c:7
> #5  0xb7e5869e in LIB_init (drv=0xb7e64f40, argc=0, argv=0x0) at init.c:79
> #6  0xb7e6ad92 in LOC_open_driver () at loc_io.c:67
> #7  0xb7e6a014 in R_open_driver () at com_io.c:180
> #8  0x0804d7f5 in main (argc=3, argv=0xbfde6774) at main.c:375

375	if (R_open_driver() != 0)

This is still really early, not long after G_parser() has returned. I
can't see how anything in the actual d.vect code could cause this. 
And, if it's a problem with the display architecture, I would expect
it to affect a lot more than just d.vect.

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

From glynn at gclements.plus.com  Thu May  3 10:12:30 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 10:12:32 2007
Subject: [GRASS-dev] grass with gdal support
In-Reply-To: <20070503092054.5e23fd11@localhost.localdomain>
References: <20070503092054.5e23fd11@localhost.localdomain>
Message-ID: <17977.39278.238378.376563@cerise.gclements.plus.com>


Otto Dassau wrote:

> trying to build grass cvs with gdal support with a gdal-config inside a svn
> folder I get following error message (both checkouts are only a few minutes
> ago):
> 
> checking whether to use GDAL... yes
> yes
> checking for gdal-config... /software/gdal/apps/gdal-config
> checking for GDALOpen... no
> checking for GDALOpen... no
> configure: error: *** couldn't find GDAL

What do:

    /software/gdal/apps/gdal-config --libs
    /software/gdal/apps/gdal-config --dep-libs

say?

If you've compiled GDAL but haven't installed it, gdal-config may be
returning output corresponding to where the libraries will get
installed, not necessarily where they currently reside.

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

From hamish_nospam at yahoo.com  Thu May  3 10:32:00 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 10:32:07 2007
Subject: [GRASS-dev] Re: d.vect changes
In-Reply-To: <20070503054759.GD19083@bartok.itc.it>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
Message-ID: <20070503203200.01aac525.hamish_nospam@yahoo.com>

> > Markus wrote:
> > > d.vect kills x0
> > ..
> > > strace d.vect myroads_net col=red
HB:
> > don't know, can you reproduce it with a spearfish map?
> > make distclean? ;)
MN: 
> It happens with Spearfish. Just try my new v.net.path
> example in the description.html.

all works fine for me, even when fancy:
  d.vect myroads_net icon=basic/triangle fcol=green size=12
  d.vect myroads_net disp=cat type=point lsize=14


> BTW: the v.clean step therein fails - it does NOT properly
> connect the lines. Sigh.

Is that where this v.net.path error comes from?

Building graph ...
Registering arcs ...
 100%
Flattening the graph ...
Graph was built
dglShortestPath error: Head Node Not Found
WARNING: Point with category [10] is not reachable from point with category
         [9]
WARNING: [1] destinations unreachable (including points outof threshold)
Building topology ...
0 primitives registered      

 * "[1] destinations unreachable" reads weird as "1" is not parenthetical

This is because "connect" lines are missing any cat values. v.clean (and
almost all vector modules) work by cycling through the list of cats. You
have to use v.category to give them a cat before going on. I have forgotten
to do this enough times that now I always remember it.

[...]
v.db.addtable connect  ...

# use cat 0 (no data) for both roads as "off-road" ?
v.category in=connect out=connect_cat cat=0 step=0
# not sure if this is needed later?
# v.db.update won't work for a insert? add a -i flag to it? new module?
echo "INSERT INTO connect_cat (cat, label, forward, backward) VALUES (0, 'no data', 50, 50)" | db.execute

v.db.select connect
v.db.select connect_cat

[...]

then I get a nice mypath vector and no error from v.net.path.


> I have added some examples based on Spearfish:
> v.net.iso/description.html
> v.net.path/description.html
> 
> They need testing and simplification (v.net.path).
> My problem is how to get the nodes (centers) onto the
> network lines. Maybe we should implement threshold such
> as in d.path? If you look at the v.net.path, you see that
> it is rather painful to connect the node to the network.
> Or some fancy v.edit trick to digitize the start/end
> nodes?

v.net.iso: the v.clean step also removes the point patched into roads_n ?


v.net.path:
"Shortest path from two digitized nodes" example
also try:
  d.path -b roads coor="601653.5,4922869.2","593330.8,4924096.6"
and
  d.path -b myroads_net coor="601653.5,4922869.2","593330.8,4924096.6" \
    afcol=forward hcolor=green


[I do get a segfault from d.path if I spell the af column name wrong.]


Hamish

From hamish_nospam at yahoo.com  Thu May  3 11:15:34 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 11:15:46 2007
Subject: [GRASS-dev] [grass-code I][381] r.colors rules: some scripts
	broken
In-Reply-To: <17977.37144.972151.385@cerise.gclements.plus.com>
References: <20070425172455.12BE21936633@pyrosoma.intevation.org>
	<20070503180729.7337dc08.hamish_nospam@yahoo.com>
	<17977.37144.972151.385@cerise.gclements.plus.com>
Message-ID: <20070503211534.2bc6a6d5.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> > you can get rid of the errors by changing "r.colors rules="
> > to "r.colors color=". I've just done this for r.in.srtm.
> > 
> > But really this will break a lot of scripts and should be revisited
> > to be backwards compatible. Suggestion: when it looks for the rules
> > file it should try looking for $GISBASE/etc/colors/$RULEFILE if it
> > can't find the file as just $RULEFILE.
> > 
> > Anything written using "r.colors rules=" will be affected.
> 
> When I added rules=, it was made clear that this was a temporary
> feature until it could replace color=.

I am happy for r.colors to evolve, and glad the rules files are now
finally merged into color=, but fear we will damage tons of user scripts
with this change.

"r.colors rules=" has been there for more than 3 years now, since before
the 6.0.0 release (5.3.0 and 5.7.0 too), and until recently the only way
to get at e.g. the srtm color rules, so widely used. All new rules since
then were added to rules= as it is so much easier than writing a new C
function for the old color= option.

> As there hasn't been a 6.3.0 release yet, the 6.3 API remains subject
> to change.

It is my understanding that module options are frozen for 6.x, not 6.x.y.
The idea being that a user script written for GRASS 6.0.0 will still
work with GRASS 6.9.99. Often an application is still in use at an
institution long after the original programmer/brain cells have moved on.

Would quietly checking for the file in $GISBASE/etc/colors/, after it
isn't found normally, really hurt much? (leaving that under-documented
in the help pages to discourage new use) We could flag it for removal
in GRASS7 if code clutter is a concern.


Hamish

From neteler at itc.it  Thu May  3 11:50:22 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 11:50:24 2007
Subject: [GRASS-dev] S-JTSK strikes back
Message-ID: <20070503095022.GA26403@bartok.itc.it>

Hi,

for a project I need to define a S-JTSK location. I thought
that we resolved this recently, but apparently not:

# S-JTSK (Ferro) / Krovak
<2065> +proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=ferro +units=m +no_defs  <>

So I do:

g.proj epsg=2065

g.proj -w
PROJCS["Krovak",
    GEOGCS["bessel",
        DATUM["unknown",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Krovak"],
    PARAMETER["latitude_of_center",49.5],
    PARAMETER["longitude_of_center",24.83333333333333],
    PARAMETER["azimuth",0],
    PARAMETER["pseudo_standard_parallel_1",0],
    PARAMETER["scale_factor",0.9999],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

This is not quite right. It should be
http://lists.maptools.org/pipermail/proj/2003-February/000626.html
something like this:
PROJCS["S-JTSK (Ferro) / Krovak",
     GEOGCS["S-JTSK (Ferro)",
         DATUM["S_JTSK_Ferro",
             SPHEROID["Bessel 1841",6377397.155,299.1528128,
                 AUTHORITY["EPSG","7004"]],
             AUTHORITY["EPSG","6818"]],
         PRIMEM["Ferro",-17.66666666666667,
             AUTHORITY["EPSG","8909"]],
         UNIT["degree",0.0174532925199433],
         AUTHORITY["EPSG","4818"]],
     PROJECTION["Krovak"],
     PARAMETER["latitude_of_center",49.5],
     PARAMETER["longitude_of_center",42.5],
     PARAMETER["azimuth",30.28813972222222],
     PARAMETER["pseudo_standard_parallel_1",78.5],
     PARAMETER["scale_factor",0.9999],
     PARAMETER["false_easting",0],
     PARAMETER["false_northing",0],
     UNIT["metre",1,
         AUTHORITY["EPSG","9001"]],
     AUTHORITY["EPSG","2065"]]

Is any name remapping still missing in
lib/proj/convert.c
?

Markus

From hamish_nospam at yahoo.com  Thu May  3 11:53:27 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 11:53:39 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
In-Reply-To: <20070501101422.93F7F1006C7@lists.intevation.de>
References: <20070501101422.93F7F1006C7@lists.intevation.de>
Message-ID: <20070503215327.369698b9.hamish_nospam@yahoo.com>

Markus Neteler via RT wrote:
> https://intevation.de/rt/webrt?serial_num=2793
> 
> Apparently Vect_point_on_line() lacks support for side offset. Indeed,
> it doesn't even have such a parameter.
> 
> We can now either remove all the side_offset stuff from the manual
> page or convince a developer to expand Vect_point_on_line(). The
> functions used in v.buffer/v.parallel might be helpful in this regard.


Vect_point_on_line() is fine, the adjustment should come just after:



ret = Vect_point_on_line ( LPoints, offset1, &x, &y, &z, &angle, NULL);

/* Should Vect_point_on_line be passed the side offset here? */
/***  (YES) ***/

if(side_offset != 0.0)    better? if(fabs(side_offset) > 0.0)
  shift_point_90(&x, &y, side_offset, angle);
...
Vect_append_point ( SPoints, x, y, z );


if we know the slope of the line at the point (angle*), it is easy
enough to calculate a point perpendicular to it (in the x,y plane)
offset by a certain distance with a little trig.

Vect_point_on_line()
  *angle     - pointer to angle of line in that point (radians, 
               counter clockwise from x axis) or NULL


with luck the line direction is ok- shift off to the left or right?

can anyone compose a nicer example for the v.segment help page?
(v.to.points -n or -v to get points?)

or is <side offset> for a threshold? (I'm not really sure how v.segment
is supposed to work)

For 6.2 we should <!-- comment out --> the references to it in the help
page.


Hamish

From neteler at itc.it  Thu May  3 12:09:19 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 12:09:21 2007
Subject: [GRASS-dev] S-JTSK strikes back
In-Reply-To: <20070503095022.GA26403@bartok.itc.it>
References: <20070503095022.GA26403@bartok.itc.it>
Message-ID: <20070503100918.GD26403@bartok.itc.it>

On Thu, May 03, 2007 at 11:50:22AM +0200, Markus Neteler wrote:
> Hi,
> 
> for a project I need to define a S-JTSK location. I thought
> that we resolved this recently, but apparently not:
> 
> # S-JTSK (Ferro) / Krovak
> <2065> +proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=ferro +units=m +no_defs  <>
> 
> So I do:
> 
> g.proj epsg=2065
> 
> g.proj -w
> PROJCS["Krovak",
>     GEOGCS["bessel",
>         DATUM["unknown",
>             SPHEROID["Bessel_1841",6377397.155,299.1528128]],
>         PRIMEM["Greenwich",0],
>         UNIT["degree",0.0174532925199433]],
>     PROJECTION["Krovak"],
>     PARAMETER["latitude_of_center",49.5],
>     PARAMETER["longitude_of_center",24.83333333333333],
>     PARAMETER["azimuth",0],
>     PARAMETER["pseudo_standard_parallel_1",0],
>     PARAMETER["scale_factor",0.9999],
>     PARAMETER["false_easting",0],
>     PARAMETER["false_northing",0],
>     UNIT["Meter",1]]
> 
> This is not quite right.

Mhh, not sure about my statement. Anyway, the map which I have to import 
looks like this:

PROJCS["S-JTSK_Krovak",GEOGCS["GCS_S_JTSK",DATUM["D_S_JTSK",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Krovak"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Pseudo_Standard_Parallel_1",78.5],PARAMETER["Scale_Factor",0.9999],PARAMETER["Azimuth",30.28813975277778],PARAMETER["Longitude_Of_Center",24.83333333333333],PARAMETER["Latitude_Of_Center",49.5],PARAMETER["X_Scale",1.0],PARAMETER["Y_Scale",1.0],PARAMETER["XY_Plane_Rotation",0.0],UNIT["Meter",1.0]]

And:

g.proj wkt=Area_topolcianky.prj
g.proj -w
PROJCS["Krovak",
    GEOGCS["bessel",
        DATUM["unknown",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Krovak"],
    PARAMETER["latitude_of_center",49.5],
    PARAMETER["longitude_of_center",24.83333333333333],
    PARAMETER["azimuth",0],
    PARAMETER["pseudo_standard_parallel_1",0],
    PARAMETER["scale_factor",0.9999],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

Doesn't seem to correspond (see pseudo_standard_parallel_1, scale_factor etc).

Markus

From hamish_nospam at yahoo.com  Thu May  3 12:18:24 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 12:18:31 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
In-Reply-To: <20070503215327.369698b9.hamish_nospam@yahoo.com>
References: <20070501101422.93F7F1006C7@lists.intevation.de>
	<20070503215327.369698b9.hamish_nospam@yahoo.com>
Message-ID: <20070503221824.311669d8.hamish_nospam@yahoo.com>

> Markus Neteler via RT wrote:
> > https://intevation.de/rt/webrt?serial_num=2793
> > 
> > Apparently Vect_point_on_line() lacks support for side offset.
> > Indeed, it doesn't even have such a parameter.

Hamish:
> if we know the slope of the line at the point (angle*), it is easy
> enough to calculate a point perpendicular to it (in the x,y plane)
> offset by a certain distance with a little trig.
..
> with luck the line direction is ok- shift off to the left or right?


see attached patch. raw & completely untested. All I know is that it
compiles.

> can anyone compose a nicer example for the v.segment help page?
> (v.to.points -n or -v to get points?)



Hamish
-------------- next part --------------
Index: main.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/vector/v.segment/main.c,v
retrieving revision 1.9
diff -u -r1.9 main.c
--- main.c	26 Mar 2007 02:47:04 -0000	1.9
+++ main.c	3 May 2007 10:14:42 -0000
@@ -16,6 +16,7 @@
  **************************************************************/
 #include <stdlib.h>
 #include <string.h>
+#include <math.h>
 #include <time.h>
 #include <grass/gis.h>
 #include <grass/Vect.h>
@@ -23,9 +24,11 @@
 #include <grass/glocale.h>
 
 int find_line ( struct Map_info *Map, int lfield, int cat );
-    
+void offset_pt_90(double *, double *, double, double);
+
 int main(int argc, char **argv)
 {
+    int    i;
     int    ret, points_written, lines_written, points_read, lines_read;
     int    lfield;
     int    line;
@@ -117,6 +120,9 @@
 		    break;
 		}
 
+		if(fabs(side_offset) > 0.0)
+		    offset_pt_90(&x, &y, angle, side_offset);
+
                 Vect_append_point ( SPoints, x, y, z );
 		Vect_cat_set ( SCats, 1, id );
 
@@ -154,7 +160,12 @@
 			                      lcat, offset1, offset2, len, buf);
 		    break;
 		}
-		
+
+		if(fabs(side_offset) > 0.0) {
+		    for(i=0; i<SPoints->n_points; i++)
+			offset_pt_90(&SPoints->x[i], &SPoints->y[i], angle, side_offset);
+		}
+
 		Vect_cat_set ( SCats, 1, id );
 
 		Vect_write_line ( &Out, GV_LINE, SPoints, SCats);
@@ -203,4 +214,14 @@
     }
 
     return 0;
+}
+
+
+/* calculate a point perpendicular to the current line angle, offset by a distance
+ * works in the x,y plane.
+ */
+void offset_pt_90(double *x, double *y, double angle, double distance)
+{
+    *x += distance * cos(M_PI_2 - angle);
+    *y += distance * sin(M_PI_2 - angle);
 }
From florian.kindl at uibk.ac.at  Thu May  3 12:27:15 2007
From: florian.kindl at uibk.ac.at (Florian Kindl)
Date: Thu May  3 12:29:21 2007
Subject: [GRASS-dev] Streams extraction from streams map
In-Reply-To: <20070502151205.GQ27153@bartok.itc.it>
References: <20070502090436.GB27153@bartok.itc.it>
	<C25DF6D4.2196E%michael.barton@asu.edu>
	<20070502151205.GQ27153@bartok.itc.it>
Message-ID: <20070503102715.GB19284@uibk.ac.at>

On May 02 [17:12], Markus Neteler wrote:
> 
> I tried this v.strahler recently but it didn't work (it is in the GRASS
> Addons SVN) - for me. Maybe it's still under development. But yes,
> this would probably do the job.
> 

Hi,
Yes, v.strahler assigns a common identifier to all connected segments.
The code is in forest2tree.c:
StrahForestToTrees() makes use of Vect_get_line_nodes() and
Vect_get_node_line() to accomplish this.

Hints on why the code fails are more than welcome.

A word on why Vect_get_node_line() is hidden in StrahGetNodeLine():
I tried to implement "sloppy" mode where lines need not connect in a
topologically correct way but merely share nodes within a certain distance.
However, this adds a lot of complexity and isn't the point of v.strahler
at all (better run v.clean instead) - so it's defunct for now.

As far as the module "is still under development": well, it should be,
but for the moment I don't find the time. Feel free to hack on the
code if you have a good idea.

\flo


-- 
Florian Kindl
Institute of Geography
University of Innsbruck
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070503/40caf7d0/attachment.bin
From landa.martin at gmail.com  Thu May  3 12:43:24 2007
From: landa.martin at gmail.com (Martin Landa)
Date: Thu May  3 12:43:27 2007
Subject: [GRASS-dev] S-JTSK strikes back
In-Reply-To: <20070503095022.GA26403@bartok.itc.it>
References: <20070503095022.GA26403@bartok.itc.it>
Message-ID: <f8fe65c40705030343v54175c84m8675ddc1501597ad@mail.gmail.com>

Hi,

I tried

2007/5/3, Markus Neteler <neteler@itc.it>:

> # S-JTSK (Ferro) / Krovak
> <2065> +proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=ferro +units=m +no_defs  <>
>
> So I do:
>
> g.proj epsg=2065

g.proj epsg=2065 -c loc=s-jtsk datum=3

g.gisenv | grep LOC
LOCATION_NAME='s-jtsk';

g.proj -w

I got different values...

> g.proj -w
>         DATUM["unknown",
>             SPHEROID["Bessel_1841",6377397.155,299.1528128]],
>         PRIMEM["Greenwich",0],
>         UNIT["degree",0.0174532925199433]],

        DATUM["Militar_Geographische_Institut",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
        PRIMEM["ferro",-17.666666666668],
        UNIT["degree",0.0174532925199433]],

    PARAMETER["longitude_of_center",24.833333333332], <- This should
be 42.5 (because of Ferro)

I am wonder why g.proj -w gives different values...

g.proj -jf
+proj=krovak +lat_0=49.5 +lon_0=42.5 +k=0.9999 +x_0=0 +y_0=0 +pm=ferro
+no_defs +a=6377397.155 +rf=299.1528128
+towgs84=570.8,85.7,462.8,4.998,1.587,5.261,3.56 +to_meter=1

Martin

> This is not quite right. It should be
> http://lists.maptools.org/pipermail/proj/2003-February/000626.html
> something like this:
> PROJCS["S-JTSK (Ferro) / Krovak",
>      GEOGCS["S-JTSK (Ferro)",
>          DATUM["S_JTSK_Ferro",
>              SPHEROID["Bessel 1841",6377397.155,299.1528128,
>                  AUTHORITY["EPSG","7004"]],
>              AUTHORITY["EPSG","6818"]],
>          PRIMEM["Ferro",-17.66666666666667,
>              AUTHORITY["EPSG","8909"]],
>          UNIT["degree",0.0174532925199433],
>          AUTHORITY["EPSG","4818"]],
>      PROJECTION["Krovak"],
>      PARAMETER["latitude_of_center",49.5],
>      PARAMETER["longitude_of_center",42.5],
>      PARAMETER["azimuth",30.28813972222222],
>      PARAMETER["pseudo_standard_parallel_1",78.5],
>      PARAMETER["scale_factor",0.9999],
>      PARAMETER["false_easting",0],
>      PARAMETER["false_northing",0],
>      UNIT["metre",1,
>          AUTHORITY["EPSG","9001"]],
>      AUTHORITY["EPSG","2065"]]
>
> Is any name remapping still missing in
> lib/proj/convert.c
> ?
>
> Markus
>
> _______________________________________________
> 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 glynn at gclements.plus.com  Thu May  3 13:06:35 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 13:06:37 2007
Subject: [GRASS-dev] [grass-code I][381] r.colors rules: some scripts
	broken
In-Reply-To: <20070503211534.2bc6a6d5.hamish_nospam@yahoo.com>
References: <20070425172455.12BE21936633@pyrosoma.intevation.org>
	<20070503180729.7337dc08.hamish_nospam@yahoo.com>
	<17977.37144.972151.385@cerise.gclements.plus.com>
	<20070503211534.2bc6a6d5.hamish_nospam@yahoo.com>
Message-ID: <17977.49723.783733.672549@cerise.gclements.plus.com>


Hamish wrote:

> I am happy for r.colors to evolve, and glad the rules files are now
> finally merged into color=, but fear we will damage tons of user scripts
> with this change.

The longer it's left, the more scripts will be broken by the change. 
It's already been left far too long (if it was originally done in 5.3,
it should have been changed for 6.0.0).

> > As there hasn't been a 6.3.0 release yet, the 6.3 API remains subject
> > to change.
> 
> It is my understanding that module options are frozen for 6.x, not 6.x.y.

That would make the rate of evolution far too slow. It would
essentially mean periods of several years where no real development
can occur.

If that was the case, I would have left after 6.0.0 was released, and
probably have forgotten all about GRASS by the time that 7.x was open
for development.

AIUI, major numbers are for "total" change: 5.x introduced FP and
null. 6.x (originally 5.7) completely changed the source directory
structure (no src/src.contrib/src.nonGPL, no cmd/inter
subdirectories), the build system, and the vector subsystem.

Minor numbers are for incompatible changes, release numbers are for
bug fixes and backward-compatible enhancements.

IOW, analogous to the Linux kernel: 2.0/2.2/2.4/2.6 all have
substantial differences, while all 2.6.x versions are mostly
compatible with each other.

> Would quietly checking for the file in $GISBASE/etc/colors/, after it
> isn't found normally, really hurt much?

Yes.

Either the argument to rules= is a filename or it isn't. If it is a
filename, relative filenames are relative to the current directory. If
it isn't a filename, then it's an arbitrary string, the GUI can't
offer a file browser for it.

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

From neteler at itc.it  Thu May  3 13:19:42 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 13:19:44 2007
Subject: v.net.path - was Re: [GRASS-dev] Re: d.vect changes
In-Reply-To: <20070503203200.01aac525.hamish_nospam@yahoo.com>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
	<20070503203200.01aac525.hamish_nospam@yahoo.com>
Message-ID: <20070503111942.GE26403@bartok.itc.it>

[ v.net.path example ]

On Thu, May 03, 2007 at 08:32:00PM +1200, Hamish wrote:
...
> This is because "connect" lines are missing any cat values. v.clean (and
> almost all vector modules) work by cycling through the list of cats. You
> have to use v.category to give them a cat before going on. I have forgotten
> to do this enough times that now I always remember it.

If you look at v.db.addtable, you see that it tries to add
categories. But only in the table. Perhaps *there* should be
an addition to first check if categories are present at all,
if not, add them?

See line 192 in v.db.addtable.

This would greatly simplify the example.

Markus

From neteler at itc.it  Thu May  3 13:24:33 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 13:24:35 2007
Subject: [GRASS-dev] v.net.path
In-Reply-To: <20070503203200.01aac525.hamish_nospam@yahoo.com>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
	<20070503203200.01aac525.hamish_nospam@yahoo.com>
Message-ID: <20070503112433.GF26403@bartok.itc.it>

On Thu, May 03, 2007 at 08:32:00PM +1200, Hamish wrote:
> > > Markus wrote:
...
> > BTW: the v.clean step therein fails - it does NOT properly
> > connect the lines. Sigh.
> 
> Is that where this v.net.path error comes from?
> WARNING: Point with category [10] is not reachable from point with category
>          [9]
> WARNING: [1] destinations unreachable (including points outof threshold)
> Building topology ...
> 0 primitives registered      
> 
>  * "[1] destinations unreachable" reads weird as "1" is not parenthetical

fixed in CVS.
 
> This is because "connect" lines are missing any cat values. v.clean (and
> almost all vector modules) work by cycling through the list of cats. You
> have to use v.category to give them a cat before going on. I have forgotten
> to do this enough times that now I always remember it.

Haha!! OK, this wasn't really clear to me. Unfortunately there is
no error message/warning indicating this.
See my other mail concerning v.db.addtable.

> [...]
> v.db.addtable connect  ...
> 
> # use cat 0 (no data) for both roads as "off-road" ?
> v.category in=connect out=connect_cat cat=0 step=0
> # not sure if this is needed later?
> # v.db.update won't work for a insert? add a -i flag to it? new module?
> echo "INSERT INTO connect_cat (cat, label, forward, backward) VALUES (0, 'no data', 50, 50)" | db.execute
> 
> v.db.select connect
> v.db.select connect_cat
> 
> [...]
> 
> then I get a nice mypath vector and no error from v.net.path.

Now me, too! :)

I have updated the example in CVS.
Still the chosen path looks a bit weird to me, maybe the speed
limits (mph) are chosen badly.


> > I have added some examples based on Spearfish:
> > v.net.iso/description.html
> > v.net.path/description.html
> > 
> > They need testing and simplification (v.net.path).
> > My problem is how to get the nodes (centers) onto the
> > network lines. Maybe we should implement threshold such
> > as in d.path? If you look at the v.net.path, you see that
> > it is rather painful to connect the node to the network.
> > Or some fancy v.edit trick to digitize the start/end
> > nodes?
> 
> v.net.iso: the v.clean step also removes the point patched into roads_n ?

Good question. Maybe Martin has an idea? I guess it survives since
it is a different vector type.


> v.net.path:
> "Shortest path from two digitized nodes" example
> also try:
>   d.path -b roads coor="601653.5,4922869.2","593330.8,4924096.6"
> and
>   d.path -b myroads_net coor="601653.5,4922869.2","593330.8,4924096.6" \
     afcol=forward hcolor=green

How cool, I didn't realize this -b flag so far.
The difference is striking. I am not really sure about the second one.


> [I do get a segfault from d.path if I spell the af column name wrong.]

Same thing for v.net.path. Perhaps we need a global sanity check
for column names. Maybe with db_get_column()?

Markus

PS: Amazing, where the v.net.iso suggestion for streams gets us :)

From neteler at itc.it  Thu May  3 13:30:11 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 13:30:13 2007
Subject: [GRASS-dev] d.vect kills d.mon
In-Reply-To: <17977.39071.540639.288979@cerise.gclements.plus.com>
References: <20070502220542.GA27153@bartok.itc.it>
	<17977.11049.536917.664754@cerise.gclements.plus.com>
	<20070503054622.GC19083@bartok.itc.it>
	<17977.39071.540639.288979@cerise.gclements.plus.com>
Message-ID: <20070503113010.GG26403@bartok.itc.it>

On Thu, May 03, 2007 at 09:09:03AM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > GRASS 6.3.cvs (spearfish60):~/grass63/scripts > GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect
> > GNU gdb 6.3-8mdv2007.0 (Mandriva Linux release 2007.0)
> > ...
> > (gdb) run myroads_net col=red

Richt, copy-paste fails here.
Using "script" now, see attached dvect_debug.txt.

Markus
-------------- next part --------------
Script started on Thu 03 May 2007 01:26:59 PM CEST
]0;neteler@localhost: /home/neteler/grass63/lib/dbGRASS 6.3.cvs (spearfish60):~/grass63/lib/db > GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect
GNU gdb 6.3-8mdv2007.0 (Mandriva Linux release 2007.0)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...Using host libthread_db library "/lib/i686/libthread_db.so.1".

(gdb) 
(gdb) r
(gdb) ru
(gdb) run
(gdb) run 
(gdb) run m
(gdb) run my
(gdb) run myr
(gdb) run myro
(gdb) run myroa
(gdb) run myroad
(gdb) run myroads
(gdb) run myroads_
(gdb) run myroads_n
(gdb) run myroads_ne
(gdb) run myroads_net
(gdb) run myroads_net 
(gdb) run myroads_net c
(gdb) run myroads_net co
(gdb) run myroads_net col
(gdb) run myroads_net col=
(gdb) run myroads_net col=r
(gdb) run myroads_net col=re
(gdb) run myroads_net col=red
(gdb) run myroads_net col=red
Starting program: /home/neteler/soft/63grass_cvsexp/dist.i686-pc-linux-gnu/bin/d.vect myroads_net col=red
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xbfffe000
[Thread debugging using libthread_db enabled]
[New Thread -1225034032 (LWP 21533)]
PNG: GRASS_TRUECOLOR status: FALSE

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1225034032 (LWP 21533)]
0xb78a72d8 in fputs () from /lib/i686/libc.so.6
(gdb) 
(gdb) b
(gdb) bt
(gdb) bt
#0  0xb78a72d8 in fputs () from /lib/i686/libc.so.6
#1  0xb7f867a0 in print_error (
    msg=0xbfa84a60 "PNG: collecting to file: map.png,\n     GRASS_WIDTH=640, GRASS_HEIGHT=480", type=0)
    at error.c:276
#2  0xb7f86ca5 in G_message (
    msg=0xb7f267c8 "PNG: collecting to file: %s,\n     GRASS_WIDTH=%d, GRASS_HEIGHT=%d") at error.c:112
#3  0xb7f24c62 in PNG_Graph_set (argc=0, argv=0x0) at Graph_set.c:133
#4  0xb7f1a351 in COM_Graph_set (argc=0, argv=0x0) at Graph.c:7
#5  0xb7f1b69e in LIB_init (drv=0xb7f27f40, argc=0, argv=0x0) at init.c:79
#6  0xb7f2dd92 in LOC_open_driver () at loc_io.c:67
#7  0xb7f2d014 in R_open_driver () at com_io.c:180
#8  0x0804d7f5 in main (argc=3, argv=0xbfa87c34) at main.c:375
(gdb) 
(gdb) b
(gdb) bt
(gdb) bt 
(gdb) bt f
(gdb) bt fu
(gdb) bt ful
(gdb) bt full
(gdb) bt full
#0  0xb78a72d8 in fputs () from /lib/i686/libc.so.6
No symbol table info available.
#1  0xb7f867a0 in print_error (
    msg=0xbfa84a60 "PNG: collecting to file: map.png,\n     GRASS_WIDTH=640, GRASS_HEIGHT=480", type=0)
    at error.c:276
	w = Variable "w" is not available.
(gdb) 
(gdb) q
(gdb) q
From neteler at itc.it  Thu May  3 13:43:02 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 13:43:04 2007
Subject: v.net.iso - was Re: [GRASS-dev] v.net.path
In-Reply-To: <20070503112433.GF26403@bartok.itc.it>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
	<20070503203200.01aac525.hamish_nospam@yahoo.com>
	<20070503112433.GF26403@bartok.itc.it>
Message-ID: <20070503114302.GH26403@bartok.itc.it>

On Thu, May 03, 2007 at 01:24:33PM +0200, Markus Neteler wrote:
> On Thu, May 03, 2007 at 08:32:00PM +1200, Hamish wrote:
> > > > Markus wrote:
...
> > > I have added some examples based on Spearfish:
> > > v.net.iso/description.html
> > 
> > v.net.iso: the v.clean step also removes the point patched into roads_n ?
> 
> Good question. Maybe Martin has an idea? I guess it survives since
> it is a different vector type.

Indeed, it doesn't survive. I have updated the procedure to
create a connecting line, snap and break it and then also
the v.net.iso example works.

Updated in
vector/v.net.iso/description.html

Cheers
Markus

From neteler at itc.it  Thu May  3 13:51:32 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 13:51:35 2007
Subject: [GRASS-dev] d.vect.thematic: v.univar.sh -> v.univar?
In-Reply-To: <20070503053806.GB19083@bartok.itc.it>
References: <20070501152503.GB19013@bartok.itc.it>
	<C25D03EA.218FC%michael.barton@asu.edu>
	<20070502090258.GA27153@bartok.itc.it>
	<1a486f560705021952o3c5787fbla35fe06afb9f93bd@mail.gmail.com>
	<20070503053806.GB19083@bartok.itc.it>
Message-ID: <20070503115132.GI26403@bartok.itc.it>

On Thu, May 03, 2007 at 07:38:07AM +0200, Markus Neteler wrote:
> On Wed, May 02, 2007 at 09:52:06PM -0500, Daniel Calvelo wrote:
> > Markus, could you try the version attached? I think I got it right but
> > can't access a CVS build right now, so v.univar -e is unavailable for
> > me right now.
> > 
> > If ok, I'll commit to HEAD.
> 
> This version would revert all recent g.message changes.
> It looks like that you worked on an older file version?

For the record: fixed by Daniel in CVS.

Markus

From neteler at itc.it  Thu May  3 13:57:43 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 13:57:44 2007
Subject: [GRASS-dev] S-JTSK strikes back
In-Reply-To: <20070503100918.GD26403@bartok.itc.it>
References: <20070503095022.GA26403@bartok.itc.it>
	<20070503100918.GD26403@bartok.itc.it>
Message-ID: <20070503115742.GJ26403@bartok.itc.it>

On Thu, May 03, 2007 at 12:09:19PM +0200, Markus Neteler wrote:

cat Area_topolcianky.prj
PROJCS["S-JTSK_Krovak",GEOGCS["GCS_S_JTSK",DATUM["D_S_JTSK",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Krovak"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Pseudo_Standard_Parallel_1",78.5],PARAMETER["Scale_Factor",0.9999],PARAMETER["Azimuth",30.28813975277778],PARAMETER["Longitude_Of_Center",24.83333333333333],PARAMETER["Latitude_Of_Center",49.5],PARAMETER["X_Scale",1.0],PARAMETER["Y_Scale",1.0],PARAMETER["XY_Plane_Rotation",0.0],UNIT["Meter",1.0]]


g.proj wkt=Area_topolcianky.prj
WARNUNG: Datum 'Jednotne_Trigonometricke_Site_Katastralni' not recognised
         by GRASS and no parameters found.
g.proj -w
PROJCS["Krovak",
    GEOGCS["bessel",
        DATUM["unknown",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Krovak"],
    PARAMETER["latitude_of_center",49.5],
    PARAMETER["longitude_of_center",24.83333333333333],
    PARAMETER["azimuth",0],
    PARAMETER["pseudo_standard_parallel_1",0],
    PARAMETER["scale_factor",0.9999],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

It has picked up at least 0.9999 (lost pseudo_standard_parallel_1 etc).

If I do the same with OGR, I get
ogrinfo -so Area_topolcianky.shp Area_topolcianky
INFO: Open of `Area_topolcianky.shp'
      using driver `ESRI Shapefile' successful.

Layer name: Area_topolcianky
Geometry: Polygon
Feature Count: 1
Extent: (1255514.000000, 473866.000000) - (1256400.000000, 474752.000000)
Layer SRS WKT:
PROJCS["S-JTSK_Krovak",
    GEOGCS["GCS_S_JTSK",
        DATUM["Jednotne_Trigonometricke_Site_Katastralni",
            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
        PRIMEM["Greenwich",0.0],
        UNIT["Degree",0.0174532925199433]],
    PROJECTION["Krovak"],
    PARAMETER["False_Easting",0.0],
    PARAMETER["False_Northing",0.0],
    PARAMETER["Pseudo_Standard_Parallel_1",78.5],
    PARAMETER["Scale_Factor",0.9999],
    PARAMETER["Azimuth",30.28813975277778],
    PARAMETER["Longitude_Of_Center",24.83333333333333],
    PARAMETER["Latitude_Of_Center",49.5],
    PARAMETER["X_Scale",1.0],
    PARAMETER["Y_Scale",1.0],
    PARAMETER["XY_Plane_Rotation",0.0],
    UNIT["Meter",1.0]]
Id: Integer (6.0)
AREA: Real (19.11)
PERIM: Real (19.11)

Apparently GRASS is still lacking something.

Markus

From neteler at itc.it  Thu May  3 14:06:31 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 14:06:33 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
In-Reply-To: <20070503221824.311669d8.hamish_nospam@yahoo.com>
References: <20070501101422.93F7F1006C7@lists.intevation.de>
	<20070503215327.369698b9.hamish_nospam@yahoo.com>
	<20070503221824.311669d8.hamish_nospam@yahoo.com>
Message-ID: <20070503120631.GK26403@bartok.itc.it>

On Thu, May 03, 2007 at 10:18:24PM +1200, Hamish wrote:
> > Markus Neteler via RT wrote:
> > > https://intevation.de/rt/webrt?serial_num=2793
> > > 
> > > Apparently Vect_point_on_line() lacks support for side offset.
> > > Indeed, it doesn't even have such a parameter.
> 
> Hamish:
> > if we know the slope of the line at the point (angle*), it is easy
> > enough to calculate a point perpendicular to it (in the x,y plane)
> > offset by a certain distance with a little trig.
> ..
> > with luck the line direction is ok- shift off to the left or right?
> 
> 
> see attached patch. raw & completely untested. All I know is that it
> compiles.

Will do, thanks.
 
> > can anyone compose a nicer example for the v.segment help page?
> > (v.to.points -n or -v to get points?)

Will try...

BTW: v.lrs.segment suffers from the same problem:
http://grass.itc.it/grass63/manuals/html63_user/v.lrs.segment.html
P <pid> <lid> <milepost>+<offset> [<side offset>]
L <sid> <lid> <milepost>+<offset> <milepost>+<offset> [<side offset>]

:) (hint hint)

Markus

From hamish_nospam at yahoo.com  Thu May  3 14:08:02 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Thu May  3 14:08:10 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
In-Reply-To: <20070503221824.311669d8.hamish_nospam@yahoo.com>
References: <20070501101422.93F7F1006C7@lists.intevation.de>
	<20070503215327.369698b9.hamish_nospam@yahoo.com>
	<20070503221824.311669d8.hamish_nospam@yahoo.com>
Message-ID: <20070504000802.3991423c.hamish_nospam@yahoo.com>

> > Markus Neteler via RT wrote:
> > > https://intevation.de/rt/webrt?serial_num=2793
> > > 
> > > Apparently Vect_point_on_line() lacks support for side offset.
> > > Indeed, it doesn't even have such a parameter.
> 
> Hamish:
> > if we know the slope of the line at the point (angle*), it is easy
> > enough to calculate a point perpendicular to it (in the x,y plane)
> > offset by a certain distance with a little trig.

now functional in CVS. please test.

Backport to 6.2 or comment out references to offset in the help page?

> > shift offset to the left or right?

I have set it to shift to the left as you go along the line, for little
reason other than I had to pick something and that's the side of the
road we drive on here. If there is a reason to have positive offsets
shift to the right (e.g. v.lrs or vector topology side 1,2 conventions;
Cartesian axes make +x go to the right; electro-magnetic interactions;
other..) let me know and I'll swap it.

Untested on 3D points & lines. Right now it outputs in the xy plane, but
full 3D points would be possible using Vect_point_on_line(...,slope);
(probably reuse Lat/lon code for that!) but offset is only 1D right now.
Vect_line_parallel() is only 2D AFAICT, so lines would require more
work, but would be a cool feature to have. (but again with the 1D offset)


still open:
> can anyone compose a nice example (x2) for the v.segment help page?


Hamish

From neteler at itc.it  Thu May  3 14:15:50 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 14:15:52 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
In-Reply-To: <20070503215327.369698b9.hamish_nospam@yahoo.com>
References: <20070501101422.93F7F1006C7@lists.intevation.de>
	<20070503215327.369698b9.hamish_nospam@yahoo.com>
Message-ID: <20070503121549.GL26403@bartok.itc.it>

On Thu, May 03, 2007 at 09:53:27PM +1200, Hamish wrote:
...
> can anyone compose a nicer example for the v.segment help page?
> (v.to.points -n or -v to get points?)
> 
> or is <side offset> for a threshold? (I'm not really sure how v.segment
> is supposed to work)

I think that you can

- generate parallel segments using <side offset> (create left and
  right lanes of a highway which you have as single line only)

   ----------------------------- back
   . . . . . . . . . . . . . . . . . . <- your original highway line
   ----------------------------- forth


- generate points along the line with <side offset>, such as

   +  +  +  +
   ---------* +
   +  +  +  +\  +  +  +  +  +  
              *---------------
             +  +  +  +  +  +

  (trees along an alley?)

Our power users may invent some nice example for Spearfish :)


Markus

From neteler at itc.it  Thu May  3 14:24:06 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 14:24:09 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
In-Reply-To: <20070504000802.3991423c.hamish_nospam@yahoo.com>
References: <20070501101422.93F7F1006C7@lists.intevation.de>
	<20070503215327.369698b9.hamish_nospam@yahoo.com>
	<20070503221824.311669d8.hamish_nospam@yahoo.com>
	<20070504000802.3991423c.hamish_nospam@yahoo.com>
Message-ID: <20070503122406.GM26403@bartok.itc.it>

On Fri, May 04, 2007 at 12:08:02AM +1200, Hamish wrote:
> > > Markus Neteler via RT wrote:
> > > > https://intevation.de/rt/webrt?serial_num=2793
> > > > 
> > > > Apparently Vect_point_on_line() lacks support for side offset.
> > > > Indeed, it doesn't even have such a parameter.
> > 
> > Hamish:
> > > if we know the slope of the line at the point (angle*), it is easy
> > > enough to calculate a point perpendicular to it (in the x,y plane)
> > > offset by a certain distance with a little trig.
> 
> now functional in CVS. please test.

Excellent:

d.vect myrailroads disp=shape,dir
echo "P 1 1 5000 -100" | v.segment myrailroads out=myrailroads_segp2
d.vect myrailroads_segp2 col=blue
-> works (to the right of vector direction with negative side offset)

echo "L 1 1 400 5000 -100" | v.segment myrailroads out=myrailroads_segl2
d.vect myrailroads_segl2 disp=shape,dir
-> works (to the right of vector direction with negative side offset)


> Backport to 6.2 or comment out references to offset in the help page?

+1 for backport.
 
> > > shift offset to the left or right?
> 
> I have set it to shift to the left as you go along the line, for little
> reason other than I had to pick something and that's the side of the
> road we drive on here. If there is a reason to have positive offsets
> shift to the right (e.g. v.lrs or vector topology side 1,2 conventions;
> Cartesian axes make +x go to the right; electro-magnetic interactions;
> other..) let me know and I'll swap it.

At least it should be consistent within GRASS.

> Untested on 3D points & lines. Right now it outputs in the xy plane, but
> full 3D points would be possible using Vect_point_on_line(...,slope);
> (probably reuse Lat/lon code for that!) but offset is only 1D right now.
> Vect_line_parallel() is only 2D AFAICT, so lines would require more
> work, but would be a cool feature to have. (but again with the 1D offset)

Indeed:

with vertical offset we could easily approximate powerlines and
such for trams in the city (cable over a street). On the other
hand, v.transform with z shift already does this.

> 
> still open:
> > can anyone compose a nice example (x2) for the v.segment help page?
...

Markus

From neteler at itc.it  Thu May  3 14:39:51 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 14:39:54 2007
Subject: [GRASS-dev] v.digit crash
In-Reply-To: <17977.10689.814954.842123@cerise.gclements.plus.com>
References: <20070502185131.GU27153@bartok.itc.it>
	<20070502204652.GX27153@bartok.itc.it>
	<17977.10689.814954.842123@cerise.gclements.plus.com>
Message-ID: <20070503123950.GN26403@bartok.itc.it>

On Thu, May 03, 2007 at 01:16:01AM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > I managed to crash the new v.digit by editing the "streams"
> > > map of the new NC dataset. I tried to insert a new point
> > > (outlet), then
> > > 
> > > g.copy vect=streams,mystreams
> > > v.digit mystreams
> > > X Error of failed request:  BadAlloc (insufficient resources for operation)
> > >   Major opcode of failed request:  53 (X_CreatePixmap)
> > >   Serial number of failed request:  4353
> > >   Current serial number in output stream:  4361
> 
> > Digging further into this, I found out that it doesn't crash with the DBF
> > driver. So it is related to the SQLite driver.
> > 
> > Here some more debugging stuff:
> > http://mpa.itc.it/markus/tmp/vdigit_settings_sqlite.png
> > (how the table definition looks like in v.digit - all 99999 lengths!)
> > 
> > DEBUG=2 output, put here to not make the mail too long:
> > http://mpa.itc.it/markus/tmp/vdigit_settings_sqlite.txt
> 
> > <INPUT type=text size=99999 name=FTYPE value="">
> 
> That will translate into a Tk entry widget with "-width 99999", which
> could be nasty.
> 
> > There are various size=99999 there which come from
> > db/drivers/sqlite/describe.c
> > 
> >    113          fsize = 99999; /* sqlite doesn't care, it must be long enough to
> >    114                            satisfy tests in GRASS */
> > 
> > Last year I changes fsize from -1 to 99999 for v.in.ascii:
> > 
> > 2006-07-04 11:24  markus
> >         * describe.c: define sufficient length to make v.in.ascii functional
> > 
> > So far it worked. The trick seems to be to get it fixed for the form in
> > v.digit.
> 
> The same issue could apply to code using the form library, as that
> uses the same HTML library.
> 
> The main question is where to fix it; in the HTML library, in the code
> which generates the form, or in the database driver.

Probably the database driver would be best:

(db/drivers/sqlite/describe.c)

since only SQLITE_INTEGER, SQLITE_TEXT, and SQLITE_FLOAT are
supported, we could define the typical length for these fields
(based on what the DBF driver does or the PostgreSQL driver).

Attached a patch which cures the problem. If ok, I will submit.

Markus
-------------- next part --------------
Index: describe.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/db/drivers/sqlite/describe.c,v
retrieving revision 1.8
diff -u -r1.8 describe.c
--- describe.c	19 Mar 2007 14:01:44 -0000	1.8
+++ describe.c	3 May 2007 12:39:04 -0000
@@ -138,8 +138,23 @@
 	    continue;
 	}
 
-        fsize = 99999; /* sqlite doesn't care, it must be long enough to
+	switch ( litetype) {
+	case SQLITE_INTEGER:
+	    fsize = 20;
+	    break;
+
+	case SQLITE_TEXT:
+	    fsize = 255;
+	    break;
+	    
+	case SQLITE_FLOAT:
+	    fsize = 20;
+	    break;
+	    
+	default:
+	    fsize = 99999; /* sqlite doesn't care, it must be long enough to
                           satisfy tests in GRASS */
+	}
 
 	column = db_get_table_column(*table, nkcols);
 
From neteler at itc.it  Thu May  3 16:43:13 2007
From: neteler at itc.it (Markus Neteler)
Date: Thu May  3 16:43:15 2007
Subject: [GRASS-dev] Streams extraction from streams map
In-Reply-To: <20070502233510.7ea64abd.hamish_nospam@yahoo.com>
References: <20070501103714.GA19013@bartok.itc.it>
	<20070502090436.GB27153@bartok.itc.it>
	<20070502233510.7ea64abd.hamish_nospam@yahoo.com>
Message-ID: <20070503144312.GA2236@bartok.itc.it>

On Wed, May 02, 2007 at 11:35:10PM +1200, Hamish wrote:
> Markus Neteler wrote:
> > > I have a network of streams (say, Spearfish or better the new
> > > NC data set at http://mpa.itc.it/grasstutor/data_menu3rd.phtml )
> > > and want to extract a single stream system. Names are lacking,
> > > is there any trick to extract topologically connected lines
> > > into a new map?
> > 
> > Probably we need some equivalent to the "sides" operator in
> > v.to.db (which tells you the cats of the left and right polygon).
> > Some magic which finds the lines which are connected and writes
> > out some related attribute(s).
> 
> how about v.net.iso? disconnected networks will have infinite cost.

Wow - that works!

Spearfish example:

d.vect streams disp=shape,dir
d.where
g.copy vect=streams,mystreams

echo "602042|4927928" | v.in.ascii out=outlet --o
v.distance -p from=outlet to=mystreams out=connect upload=dist column=dist --o

v.patch in=mystreams,connect,outlet out=streams_n --o
v.clean streams_n out=streams_net tool=snap,break thresh=5,0 --o

g.region vect=streams_net
d.erase
d.vect streams_net
d.vect streams_net type=point col=red icon=basic/triangle

v.net.iso streams_net out=myriver ccats=1 costs=99999999 nlayer=1 --o

v.category myriver option=report
# The network is of 2 categories
# show selected river network
d.vect myriver col=blue  cats=1
d.vect myriver col=green cats=2

# now v.extract  etc ...

Note that some upper parts of the river network are not found due to
unconnected lines.

Thanks for the hint,
Markus

From michael.barton at asu.edu  Thu May  3 17:08:52 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Thu May  3 17:08:59 2007
Subject: [GRASS-dev] [grass-code I][381] r.colors rules: some scripts
	broken
In-Reply-To: <17977.37144.972151.385@cerise.gclements.plus.com>
Message-ID: <C25F4914.21A04%michael.barton@asu.edu>

FWIW, the old way rules= was implemented never made much sense. It should
have followed the old concept of rulesfile > r.colors and made it easier to
implement, but was a strange hybrid of this and colors=. The current
implementation is much more logical. I'm sympathetic about the problem with
user scripts, but it's easy to fix (change rules= to colors=).

Michael


On 5/3/07 12:36 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Hamish wrote:
> 
>> http://wald.intevation.org/tracker/?func=detail&atid=204&aid=381&group_id=21
>> ..
>>> code I item #381, was opened at 2007-04-25 19:24
>>> Summary: r.colors rules: some scripts broken
>> ..
>>> Eg. in GRASS 6.3 scripts dir:
>>> 
>>> i.in.spotvgt: 213: r.colors ${NAME} rules=ndvi 2>&1 >/dev/null
>>> i.in.spotvgt: 275: r.colors ${NAME}_filt rules=ndvi 2>&1 >/dev/null
>>> r.in.srtm: 237: r.colors rul=srtm map=$TILEOUT
>>> 
>>> Such syntax leads now to "ERROR: Unable to load rules file srtm".
>>> 
>>> How do we fix it? Add the $GISBASE/etc/colors/ before the rule name?
>>> Looks like a broken backwards compatibility...
>> 
>> 
>> [cc'd from the tracker]
>> 
>> r.colors was changed in 6.3 CVS,
>> 
>> -------
>> Revision 2.14, Sat Apr 14 03:35:32 2007 UTC by glynn
>> ..
>> r.colors:
>> ..
>>  Merge rules= with color=
>>  Use rules= for external rules file
>> -------
>> 
>> you can get rid of the errors by changing "r.colors rules="
>> to "r.colors color=". I've just done this for r.in.srtm.
>> 
>> But really this will break a lot of scripts and should be revisited
>> to be backwards compatible. Suggestion: when it looks for the rules
>> file it should try looking for $GISBASE/etc/colors/$RULEFILE if it
>> can't find the file as just $RULEFILE.
>> 
>> Anything written using "r.colors rules=" will be affected.
> 
> When I added rules=, it was made clear that this was a temporary
> feature until it could replace color=.
> 
> As there hasn't been a 6.3.0 release yet, the 6.3 API remains subject
> to change.

__________________________________________
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 at gclements.plus.com  Thu May  3 18:10:06 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 18:10:09 2007
Subject: [GRASS-dev] d.vect kills d.mon
In-Reply-To: <17977.39071.540639.288979@cerise.gclements.plus.com>
References: <20070502220542.GA27153@bartok.itc.it>
	<17977.11049.536917.664754@cerise.gclements.plus.com>
	<20070503054622.GC19083@bartok.itc.it>
	<17977.39071.540639.288979@cerise.gclements.plus.com>
Message-ID: <17978.2398.836522.598651@cerise.gclements.plus.com>


Glynn Clements wrote:

> > GRASS 6.3.cvs (spearfish60):~/grass63/scripts > GRASS_RENDER_IMMEDIATE=TRUE gdb d.vect

> > PNG: GRASS_TRUECOLOR status: FALSE

I missed this at first. After setting GRASS_TRUECOLOR=FALSE, I managed
to reproduce this and find the problem.

> I can't think of anything except for memory corruption. But:
> 
> > #3  0xb7e61c62 in PNG_Graph_set (argc=0, argv=0x0) at Graph_set.c:133
> > #4  0xb7e57351 in COM_Graph_set (argc=0, argv=0x0) at Graph.c:7
> > #5  0xb7e5869e in LIB_init (drv=0xb7e64f40, argc=0, argv=0x0) at init.c:79
> > #6  0xb7e6ad92 in LOC_open_driver () at loc_io.c:67
> > #7  0xb7e6a014 in R_open_driver () at com_io.c:180
> > #8  0x0804d7f5 in main (argc=3, argv=0xbfde6774) at main.c:375
> 
> 375	if (R_open_driver() != 0)
> 
> This is still really early, not long after G_parser() has returned. I
> can't see how anything in the actual d.vect code could cause this. 
> And, if it's a problem with the display architecture, I would expect
> it to affect a lot more than just d.vect.

It's due to a combination of factors:

1. Both libpngdriver and d.vect define variables named "palette".
2. GRASS_TRUECOLOR=FALSE initialises the wrong "palette" variable
(libpngdriver's is 256*4 bytes, d.vect's is only 16*4 bytes).
3. stdio structures reside shortly after d.vect's palette variable,
so when libpngdriver overflows it, stdio variables get corrupted.

IOW, it's only luck that it hasn't happened before.

The crash disappears if the library is built with -Wl,-Bsymbolic,
which causes libraries to bind to their own variable definitions
rather than allowing them to be overriden by the executable.

That should probably be the default. Relying upon libraries' global
variables not conflicting with those of an executable is bound to be
unreliable.

I can make that change to the Linux section of SC_CONFIG_CFLAGS in
aclocal.m4. It's already the default on Windows (you have to go to
some trouble to export symbols from the executable into a DLL). That
just leaves the sections for MacOSX, plus a couple of dozen platforms
which we pretend to support but don't really (i.e. all of the
commercial Unices).

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

From glynn at gclements.plus.com  Thu May  3 18:11:54 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Thu May  3 18:11:57 2007
Subject: [GRASS-dev] v.digit crash
In-Reply-To: <20070503123950.GN26403@bartok.itc.it>
References: <20070502185131.GU27153@bartok.itc.it>
	<20070502204652.GX27153@bartok.itc.it>
	<17977.10689.814954.842123@cerise.gclements.plus.com>
	<20070503123950.GN26403@bartok.itc.it>
Message-ID: <17978.2506.498061.966343@cerise.gclements.plus.com>


Markus Neteler wrote:

> since only SQLITE_INTEGER, SQLITE_TEXT, and SQLITE_FLOAT are
> supported, we could define the typical length for these fields
> (based on what the DBF driver does or the PostgreSQL driver).
> 
> Attached a patch which cures the problem. If ok, I will submit.

Seems okay.

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

From michael.barton at asu.edu  Fri May  4 02:28:42 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Fri May  4 02:28:47 2007
Subject: [GRASS-dev] default font selection in wxgrass
Message-ID: <C25FCC4A.21A8E%michael.barton@asu.edu>

I?ve implemented a default font selection dialog in the development wxPython
GUI that builds a listbox from either stroke fonts or the truetype fonts in
freetypecap. 

I added dfont and otf to acceptable extensions in mkftcap on my system and
it works well. Any reason not to commit this change?

The wxPython font selection dialog is also filtering fonts that have
duplicate face names. I?m getting a LOT of duplicates from multiple
directories. Any reason not to do this? Would it be better to do in the
script, or is it too difficult to do there?

Anyway, give it a try.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070503/61cdedcf/attachment.html
From woklist at kyngchaos.com  Fri May  4 05:08:10 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Fri May  4 05:08:19 2007
Subject: [GRASS-dev] the other part of font face index support
Message-ID: <057520D3-C513-4E9A-BB1A-F1D1058246F3@kyngchaos.com>

Aside from getting the face index to a font file to work for fonts  
with multiple styles in one file, the other problem is listing those  
indexes and matching them with actual styles, or face names.  This is  
needed because there is no guarantee of the order of the faces in the  
file - regular is not always 0, bold not always 1, ...

As an example, when I set the font to Arial Narrow, which has the  
usual assortment of regular, italic, bold and bold-italic in a single  
file, without an index (which defaults to 0), FreeType displays Arial  
Narrow Italic.

fc-list appears to only list files.  The index info is always 0, and  
so is useless.  OSX has an older FontConfig (I couldn't figure out  
which version, since the library version doesn't seem to correspond  
to the package version), so maybe the latest FC will list all font  
faces in font files?  Not that that will be any use if we want to  
minimize necessity for replacing/updating what is supplied by the OS.

I worked out an AppleScript to get font info from the OSX Font  
Book.app, but it has no concept of indexes of faces in files, just  
names.  But at least I got ALL faces in the font files, and their paths.

I thought in FreeType you could open a face by style name, but waht  
little I could understand from the FT API docs all points to just  
indexes.  Maybe there is a get font info function that can be used to  
somehow return names of all face indexes in a font file?

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

[Trillian]  What are you supposed to do WITH a maniacally depressed  
robot?

[Marvin]  You think you have problems?  What are you supposed to do  
if you ARE a maniacally depressed robot?  No, don't try and answer,  
I'm 50,000 times more intelligent than you and even I don't know the  
answer...

- HitchHiker's Guide to the Galaxy


From paul-grass at stjohnspoint.co.uk  Fri May  4 06:10:42 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Fri May  4 06:10:50 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17974.14679.620262.783465@cerise.gclements.plus.com>
References: <17973.6027.501488.6826@cerise.gclements.plus.com>
	<C25A7ABA.2175A%michael.barton@asu.edu>
	<17973.14328.976484.737490@cerise.gclements.plus.com>
	<45498D53-739B-4CF9-83B5-AFC2ADE6935C@kyngchaos.com>
	<17973.43565.792862.529314@cerise.gclements.plus.com>
	<C3D9289B-E502-469C-8E9D-80CC7EF871DF@kyngchaos.com>
	<17974.14679.620262.783465@cerise.gclements.plus.com>
Message-ID: <Pine.LNX.4.62.0705040503540.8987@agrippa.ukshells.co.uk>

On Mon, 30 Apr 2007, Glynn Clements wrote:

> At present, it gets run at build time; thereafter, it has to be run
> manually. It could be run from a post-install script used by the
> packaging system (.deb, .rpm, etc).
>
> It isn't intended to be run automatically during normal use.

Amazingly enough, the script works as is on native Windows. I had thought 
there would be problems with Msys/Windows paths - in the past I've had to 
carefully distinguish between where paths were going to be used by Msys 
utilities during compiling (in which case Msys paths were needed) and 
where paths were going to be used by running GRASS modules (either during 
or after installation), in which case Windows paths were needed. But the 
Msys find command appears to work with Windows paths so that's just great.

A quick web search suggests that $SYSTEMROOT is the "preferred" variable 
for the windows directory from NT on, whereas $WINDIR is always set for 
backward compatibility with Win 9x. So I guess it doesn't really matter 
but in my experience Microsoft scripts etc. tend to use SYSTEMROOT.

Also I have a proposed modification to the script:

Index: mkftcap
===================================================================
RCS file: /home/grass/grassrepository/grass6/tools/mkftcap/mkftcap,v
retrieving revision 1.6
diff -u -r1.6 mkftcap
--- mkftcap     3 May 2007 04:25:17 -0000       1.6
+++ mkftcap     4 May 2007 03:51:37 -0000
@@ -12,7 +12,7 @@
              for ext in $exts ; do
                  find "$dir" -type f -iname '*.'"$ext" -print \
                      | sed 's!^\(.*\)/\(.*\)$!\2:\1/\2:utf-8:!' \
-                    | sed 's/\.'"$ext"':/:/'
+                    | sed 's/\.'"$ext"':/:/I'
              done
          fi
      done

This will case-insensitively match the filename extension when it's 
stripping it out to form the short name for the font at the start of the 
line - some files had the extension in capitals and it wasn't matching 
them. Not a big deal though - just looked a bit uglier. But maybe the I 
flag for case insensitive matching might not work with all versions of 
sed.

Next step is to compile Windows GRASS with Freetype and debug/test that.

Paul

From woklist at kyngchaos.com  Fri May  4 06:21:47 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Fri May  4 06:21:56 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <Pine.LNX.4.62.0705040503540.8987@agrippa.ukshells.co.uk>
References: <17973.6027.501488.6826@cerise.gclements.plus.com>
	<C25A7ABA.2175A%michael.barton@asu.edu>
	<17973.14328.976484.737490@cerise.gclements.plus.com>
	<45498D53-739B-4CF9-83B5-AFC2ADE6935C@kyngchaos.com>
	<17973.43565.792862.529314@cerise.gclements.plus.com>
	<C3D9289B-E502-469C-8E9D-80CC7EF871DF@kyngchaos.com>
	<17974.14679.620262.783465@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705040503540.8987@agrippa.ukshells.co.uk>
Message-ID: <77EBAF8C-D7FF-45B6-A34B-6F2BB6FBFD6A@kyngchaos.com>

On May 3, 2007, at 11:10 PM, Paul Kelly wrote:

> Also I have a proposed modification to the script:
>
> Index: mkftcap
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/tools/mkftcap/mkftcap,v
> retrieving revision 1.6
> diff -u -r1.6 mkftcap
> --- mkftcap     3 May 2007 04:25:17 -0000       1.6
> +++ mkftcap     4 May 2007 03:51:37 -0000
> @@ -12,7 +12,7 @@
>              for ext in $exts ; do
>                  find "$dir" -type f -iname '*.'"$ext" -print \
>                      | sed 's!^\(.*\)/\(.*\)$!\2:\1/\2:utf-8:!' \
> -                    | sed 's/\.'"$ext"':/:/'
> +                    | sed 's/\.'"$ext"':/:/I'
>              done
>          fi
>      done
>
> This will case-insensitively match the filename extension when it's  
> stripping it out to form the short name for the font at the start  
> of the line - some files had the extension in capitals and it  
> wasn't matching them. Not a big deal though - just looked a bit  
> uglier. But maybe the I flag for case insensitive matching might  
> not work with all versions of sed.

It's already been discussed (r.in.wms problem) that /I is a GNU  
extension to sed.  OSX, at least, is BSD.  Don't know what to say  
otherwise...

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"History is an illusion caused by the passage of time, and time is an  
illusion caused by the passage of history."

- Hitchhiker's Guide to the Galaxy


From glynn at gclements.plus.com  Fri May  4 06:55:30 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri May  4 06:55:52 2007
Subject: [GRASS-dev] Re: [GRASSGUI] default font selection in wxgrass
In-Reply-To: <C25FCC4A.21A8E%michael.barton@asu.edu>
References: <C25FCC4A.21A8E%michael.barton@asu.edu>
Message-ID: <17978.48322.803315.736430@cerise.gclements.plus.com>


Michael Barton wrote:

> I?ve implemented a default font selection dialog in the development wxPython
> GUI that builds a listbox from either stroke fonts or the truetype fonts in
> freetypecap. 
> 
> I added dfont and otf to acceptable extensions in mkftcap on my system and
> it works well. Any reason not to commit this change?
> 
> The wxPython font selection dialog is also filtering fonts that have
> duplicate face names. I?m getting a LOT of duplicates from multiple
> directories. Any reason not to do this? Would it be better to do in the
> script, or is it too difficult to do there?

The ideal solution would be to force the names to be unique, but
that's quite hard to do in a shell script.

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

From glynn at gclements.plus.com  Fri May  4 07:06:51 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri May  4 07:06:53 2007
Subject: [GRASS-dev] d.vect kills d.mon
In-Reply-To: <17978.2398.836522.598651@cerise.gclements.plus.com>
References: <20070502220542.GA27153@bartok.itc.it>
	<17977.11049.536917.664754@cerise.gclements.plus.com>
	<20070503054622.GC19083@bartok.itc.it>
	<17977.39071.540639.288979@cerise.gclements.plus.com>
	<17978.2398.836522.598651@cerise.gclements.plus.com>
Message-ID: <17978.49003.415995.744717@cerise.gclements.plus.com>


Glynn Clements wrote:

> The crash disappears if the library is built with -Wl,-Bsymbolic,
> which causes libraries to bind to their own variable definitions
> rather than allowing them to be overriden by the executable.
> 
> That should probably be the default. Relying upon libraries' global
> variables not conflicting with those of an executable is bound to be
> unreliable.

Unfortunately, that method appears to prevent executables from
referencing variables which are defined in a library. This is most
noticable with XDRIVER, which uses several variables which are defined
in libdriver. If libdriver is built with -Bsymbolic, XDRIVER ends up
getting its own copies, which doesn't work.

For now, I'm just going to rename the "palette" variable in
libpngdriver, so that d.vect works.

Ultimately, we need to avoid relying upon variables exported from
libraries. Doing so is quite fragile, depending upon platform and
linker issues.

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

From glynn at gclements.plus.com  Fri May  4 07:11:05 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Fri May  4 07:11:10 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <77EBAF8C-D7FF-45B6-A34B-6F2BB6FBFD6A@kyngchaos.com>
References: <17973.6027.501488.6826@cerise.gclements.plus.com>
	<C25A7ABA.2175A%michael.barton@asu.edu>
	<17973.14328.976484.737490@cerise.gclements.plus.com>
	<45498D53-739B-4CF9-83B5-AFC2ADE6935C@kyngchaos.com>
	<17973.43565.792862.529314@cerise.gclements.plus.com>
	<C3D9289B-E502-469C-8E9D-80CC7EF871DF@kyngchaos.com>
	<17974.14679.620262.783465@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705040503540.8987@agrippa.ukshells.co.uk>
	<77EBAF8C-D7FF-45B6-A34B-6F2BB6FBFD6A@kyngchaos.com>
Message-ID: <17978.49257.54158.338385@cerise.gclements.plus.com>


William Kyngesburye wrote:

> > Also I have a proposed modification to the script:
> >
> > Index: mkftcap
> > ===================================================================
> > RCS file: /home/grass/grassrepository/grass6/tools/mkftcap/mkftcap,v
> > retrieving revision 1.6
> > diff -u -r1.6 mkftcap
> > --- mkftcap     3 May 2007 04:25:17 -0000       1.6
> > +++ mkftcap     4 May 2007 03:51:37 -0000
> > @@ -12,7 +12,7 @@
> >              for ext in $exts ; do
> >                  find "$dir" -type f -iname '*.'"$ext" -print \
> >                      | sed 's!^\(.*\)/\(.*\)$!\2:\1/\2:utf-8:!' \
> > -                    | sed 's/\.'"$ext"':/:/'
> > +                    | sed 's/\.'"$ext"':/:/I'
> >              done
> >          fi
> >      done
> >
> > This will case-insensitively match the filename extension when it's  
> > stripping it out to form the short name for the font at the start  
> > of the line - some files had the extension in capitals and it  
> > wasn't matching them. Not a big deal though - just looked a bit  
> > uglier. But maybe the I flag for case insensitive matching might  
> > not work with all versions of sed.
> 
> It's already been discussed (r.in.wms problem) that /I is a GNU  
> extension to sed.  OSX, at least, is BSD.  Don't know what to say  
> otherwise...

An alternative is to change -iname to -name, and include both upper-
and lower-case versions of the extension in exts.

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

From wolf+grass at bergenheim.net  Fri May  4 07:30:28 2007
From: wolf+grass at bergenheim.net (Wolf Bergenheim)
Date: Fri May  4 07:31:03 2007
Subject: [GRASS-dev] the other part of font face index support
In-Reply-To: <057520D3-C513-4E9A-BB1A-F1D1058246F3@kyngchaos.com>
References: <057520D3-C513-4E9A-BB1A-F1D1058246F3@kyngchaos.com>
Message-ID: <463AC4F4.9090102@bergenheim.net>

Perhaps the ftinfo tool can help you find more things about the font?

ftinfo -a fontfile will give you a lot of data :)

--Wolf

On 04.05.2007 06:08, William Kyngesburye wrote:
> Aside from getting the face index to a font file to work for fonts with
> multiple styles in one file, the other problem is listing those indexes
> and matching them with actual styles, or face names.  This is needed
> because there is no guarantee of the order of the faces in the file -
> regular is not always 0, bold not always 1, ...
> 
> As an example, when I set the font to Arial Narrow, which has the usual
> assortment of regular, italic, bold and bold-italic in a single file,
> without an index (which defaults to 0), FreeType displays Arial Narrow
> Italic.
> 
> fc-list appears to only list files.  The index info is always 0, and so
> is useless.  OSX has an older FontConfig (I couldn't figure out which
> version, since the library version doesn't seem to correspond to the
> package version), so maybe the latest FC will list all font faces in
> font files?  Not that that will be any use if we want to minimize
> necessity for replacing/updating what is supplied by the OS.
> 
> I worked out an AppleScript to get font info from the OSX Font Book.app,
> but it has no concept of indexes of faces in files, just names.  But at
> least I got ALL faces in the font files, and their paths.
> 
> I thought in FreeType you could open a face by style name, but waht
> little I could understand from the FT API docs all points to just
> indexes.  Maybe there is a get font info function that can be used to
> somehow return names of all face indexes in a font file?
> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
> http://www.kyngchaos.com/
> 
> [Trillian]  What are you supposed to do WITH a maniacally depressed robot?
> 
> [Marvin]  You think you have problems?  What are you supposed to do if
> you ARE a maniacally depressed robot?  No, don't try and answer, I'm
> 50,000 times more intelligent than you and even I don't know the answer...
> 
> - HitchHiker's Guide to the Galaxy
> 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-- 

<:3 )---- Wolf Bergenheim ----( 8:>

From michael.barton at asu.edu  Fri May  4 07:52:32 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Fri May  4 07:52:41 2007
Subject: [GRASS-dev] the other part of font face index support
In-Reply-To: <463AC4F4.9090102@bergenheim.net>
Message-ID: <C2601830.21AAD%michael.barton@asu.edu>

This is not installed on my Mac, although I have installed X11 and a bunch
of other stuff.

Michael


On 5/3/07 10:30 PM, "Wolf Bergenheim" <wolf+grass@bergenheim.net> wrote:

> Perhaps the ftinfo tool can help you find more things about the font?
> 
> ftinfo -a fontfile will give you a lot of data :)

__________________________________________
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 grass-codei at wald.intevation.org  Fri May  4 07:53:59 2007
From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org)
Date: Fri May  4 07:54:04 2007
Subject: [GRASS-dev] [grass-code I][390] v.parallel: problems with inside
	corners
Message-ID: <20070504055359.D52401800CF8@pyrosoma.intevation.org>

code I item #390, was opened at 2007-05-04 17:53
Status: Open
Priority: 3
Submitted By: Hamish Bowman (hamish)
Assigned to: Nobody (None)
Summary: v.parallel: problems with inside corners 
Issue type: library bug
Issue status: None
GRASS version: CVS HEAD
GRASS component: vector
Operating system: all
Operating system version: 
GRASS CVS checkout date, if applies (YYMMDD): 


Initial Comment:
There is a problem with v.segment side-offset parallel line generation for inside corners. It is in Vect_line_parallel(), so v.parallel, v.buffer, et al. are also affected. See it by doing the "-500" side-offset example in the v.segment help page and changing -500 to +500. Or do "v.parallel dist=500" using the railroads vector map.


Hamish


----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=204&aid=390&group_id=21

From hamish_nospam at yahoo.com  Fri May  4 07:54:49 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri May  4 07:54:56 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
In-Reply-To: <20070503122406.GM26403@bartok.itc.it>
References: <20070501101422.93F7F1006C7@lists.intevation.de>
	<20070503215327.369698b9.hamish_nospam@yahoo.com>
	<20070503221824.311669d8.hamish_nospam@yahoo.com>
	<20070504000802.3991423c.hamish_nospam@yahoo.com>
	<20070503122406.GM26403@bartok.itc.it>
Message-ID: <20070504175449.7a682342.hamish_nospam@yahoo.com>

Markus Neteler wrote:
> > > > > https://intevation.de/rt/webrt?serial_num=2793
..
> > now functional in CVS.
..
> > Backport to 6.2 or comment out references to offset in the help
> > page?
> 
> +1 for backport.

done.

 
> > > > shift offset to the left or right?
Markus:
> At least it should be consistent within GRASS.

I have now changed it to match Vect_line_parallel(). Positive side-
offsets now go to the right side of the line.


> > > can anyone compose a nice example (x2) for the v.segment help
> > > page?

Markus did this, and just now I've added a little more.


Markus:
> BTW: v.lrs.segment suffers from the same problem:
> http://grass.itc.it/grass63/manuals/html63_user/v.lrs.segment.html
> P <pid> <lid> <milepost>+<offset> [<side offset>]
> L <sid> <lid> <milepost>+<offset> <milepost>+<offset> [<side offset>]

Yes, code is mostly cloned so it would be easy to copy & paste in the
same solution.


BUG: (adding to the tracker)
There is a problem with side-offset parallel line generation for inside
corners. It is in Vect_line_parallel(), so v.parallel et al. are also
affected. See it by doing the "-500" side-offset example in the
v.segment help page and changing -500 to +500. Or "v.parallel dist=500"
using the railroads vector map.



Hamish

From grass-coder at wald.intevation.org  Fri May  4 08:20:31 2007
From: grass-coder at wald.intevation.org (grass-coder@wald.intevation.org)
Date: Fri May  4 08:20:38 2007
Subject: [GRASS-dev] [grass-code R][391] d.legend: option to get info from
	stdin instead of raster
Message-ID: <20070504062031.1AF7E1800CF5@pyrosoma.intevation.org>

code R item #391, was opened at 2007-05-04 18:20
Status: Open
Priority: 3
Submitted By: Hamish Bowman (hamish)
Assigned to: Nobody (None)
Summary: d.legend: option to get info from stdin instead of raster 
Issue status: None
GRASS component: display
Operating system: all
Operating system version: 


Initial Comment:
Hi,

It would be nice if d.legend could look for "map=-" and if so take legend cat and color info from stdin. That way vector maps and custom legends could be made without resorting to tricks like making a dummy raster file to hold that info.

If data is fed from stdin (signaled by map=-) create categorical legend
using that data. Data format: "cat|label|color"

e.g.

d.legend -m map="-" <<EOF
1|Main Street|255:0:0
2|Elm Street|0:255:0
3|Old Coach Road|0:0:255
EOF

In this way d.legend could work as a system module by the GUI instead of
a user module, and be useful for non-raster tasks too.


see expanded thread on the -dev mailing list:
 http://thread.gmane.org/gmane.comp.gis.grass.devel/19852/focus=19952


Hamish


----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=188&aid=391&group_id=21

From hamish_nospam at yahoo.com  Fri May  4 08:30:24 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri May  4 08:30:28 2007
Subject: v.net.iso - was Re: [GRASS-dev] v.net.path
In-Reply-To: <20070503114302.GH26403@bartok.itc.it>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
	<20070503203200.01aac525.hamish_nospam@yahoo.com>
	<20070503112433.GF26403@bartok.itc.it>
	<20070503114302.GH26403@bartok.itc.it>
Message-ID: <20070504183024.63dd18f1.hamish_nospam@yahoo.com>

Markus Neteler wrote:
> > > v.net.iso: the v.clean step also removes the point patched into
> > > roads_n ?
> > 
> > Good question. Maybe Martin has an idea? I guess it survives since
> > it is a different vector type.
> 
> Indeed, it doesn't survive.

v.clean type='s default includes points:
  default: point,line,boundary,centroid,area

so it should get passed through based on that.

perhaps the point is being treated as a node and snapped to the line it
is on? test: does it get "cleaned" if it isn't on/near a line?

it has a category number, right?


Hamish

From wolf+grass at bergenheim.net  Fri May  4 08:36:36 2007
From: wolf+grass at bergenheim.net (Wolf Bergenheim)
Date: Fri May  4 08:37:10 2007
Subject: [GRASS-dev] the other part of font face index support
In-Reply-To: <C2601830.21AAD%michael.barton@asu.edu>
References: <C2601830.21AAD%michael.barton@asu.edu>
Message-ID: <463AD474.5080404@bergenheim.net>

Ah. it is part of the fttools package on Debian. Well I guess one (I)
could make a similar utility to ship with GRASS...

--Wolf

On 04.05.2007 08:52, Michael Barton wrote:
> This is not installed on my Mac, although I have installed X11 and a bunch
> of other stuff.
> 
> Michael
> 
> 
> On 5/3/07 10:30 PM, "Wolf Bergenheim" <wolf+grass@bergenheim.net> wrote:
> 
>> Perhaps the ftinfo tool can help you find more things about the font?
>>
>> ftinfo -a fontfile will give you a lot of data :)
> 
> __________________________________________
> 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
> 
> 
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev

-- 

<:3 )---- Wolf Bergenheim ----( 8:>

From grass-coder at wald.intevation.org  Fri May  4 08:41:21 2007
From: grass-coder at wald.intevation.org (grass-coder@wald.intevation.org)
Date: Fri May  4 08:41:25 2007
Subject: [GRASS-dev] [grass-code R][392] raster metadata: units and veritcal
	datum -> cell_misc/
Message-ID: <20070504064121.AADF31800CF5@pyrosoma.intevation.org>

code R item #392, was opened at 2007-05-04 18:41
Status: Open
Priority: 3
Submitted By: Hamish Bowman (hamish)
Assigned to: Nobody (None)
Summary: raster metadata: units and veritcal datum -> cell_misc/ 
Issue status: None
GRASS component: raster
Operating system: None
Operating system version: 


Initial Comment:
Hi,

as discussed on the mailing list*, it would be nice to add both units and vertical datum metadata.


proposal:

add raster map specific cell_misc/units and cell_misc/vertical_datum
files.

Each would hold a single line string containing the info.
You could set the value with e.g. "r.support units=".
You could query with e.g. "r.info -u".
Likewise: "r.support vdatum=", "r.info -d".

read/write using new cell_misc libgis fns described by Glynn**. [copied below]

both would be fully optional, and non-existing by default, so fully backwards
compatible with old maps.

for use by modules, just start with strcmp(tolower(*string), "meters")
for hinting. units can be anything, so I prefer to allow freeform
metadata there, not just something from a list. I fear that vertical
datums may use very local names so while a common table would be helpful
we need to allow a custom entries. I'm not too sure about them though.


[**] Glynn wrote:
-----
Given that cell_misc exists and can't easily be removed right now, you
may as well use it for now.

Just use the _misc functions which I recently added, i.e.

	char *G__file_name_misc(char *, const char *, const char *, const char *, const char *);
	char *G_find_file_misc(const char *, const char *, char *, const char *);
	char *G_find_file2_misc(const char *, const char *, const char *, const char *);
	int G__make_mapset_element_misc (const char *, const char *);
	int G_open_new_misc(const char *, const char *, const char *);
	int G_open_old_misc(const char *, const char *, const char *, const char *);
	int G_open_update_misc(const char *, const char *, const char *);
	FILE *G_fopen_new_misc(const char *, const char *, const char *);
	FILE *G_fopen_old_misc(const char *, const char *, const char *, const char *);
	FILE *G_fopen_append_misc(const char *, const char *, const char *);
	FILE *G_fopen_modify_misc(const char *, const char *, const char *);
	int G_remove_misc (const char *, const char *, const char *);

rather than using sprintf(element, "cell_misc/%s", name) hacks.
-----

examples:
  raster/r.null/null.c
  raster/r.support/front/front.c
  lib/gis/open_misc.c

and in lib/gis/:
 closecell.c
 file_name.c
 find_file.c
 get_row.c
 histogram.c
 mapset_msc.c
 opencell.c
 quant_io.c
 quant_rw.c
 range.c
 reclass.c
 remove.c
 timestamp.c
 user_config.c


[*] previous mailing list discussions: 
  http://thread.gmane.org/gmane.comp.gis.grass.devel/19648/focus=19824
  http://thread.gmane.org/gmane.comp.gis.grass.devel/14704/focus=14789
  http://thread.gmane.org/gmane.comp.gis.grass.devel/13281/focus=13494
  http://thread.gmane.org/gmane.comp.gis.grass.devel/3840/focus=4240



Hamish


----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=188&aid=392&group_id=21

From neteler at itc.it  Fri May  4 10:10:14 2007
From: neteler at itc.it (Markus Neteler)
Date: Fri May  4 10:10:15 2007
Subject: [GRASS-dev] Re: v.net.path
In-Reply-To: <20070503112433.GF26403@bartok.itc.it>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
	<20070503203200.01aac525.hamish_nospam@yahoo.com>
	<20070503112433.GF26403@bartok.itc.it>
Message-ID: <20070504081014.GA32285@bartok.itc.it>

On Thu, May 03, 2007 at 01:24:33PM +0200, Markus Neteler wrote:
> On Thu, May 03, 2007 at 08:32:00PM +1200, Hamish wrote:
...
> > v.net.path:
> > "Shortest path from two digitized nodes" example
> > also try:
> >   d.path -b roads coor="601653.5,4922869.2","593330.8,4924096.6"
> > and
> >   d.path -b myroads_net coor="601653.5,4922869.2","593330.8,4924096.6" \
>            afcol=forward hcolor=green
> 
> How cool, I didn't realize this -b flag so far.
> The difference is striking. I am not really sure about the second one.

OK, my mistake - the column should contain *costs*. That might be
the inverse of the speed limit, not the speed limit itself:

e.g.
# define traveling costs as inverse of speed limit:
v.db.update myroads col=forward val=1/50

I have update the example in CVS. Please suggest if you have better
ideas.

Markus

From neteler at itc.it  Fri May  4 10:37:06 2007
From: neteler at itc.it (Markus Neteler)
Date: Fri May  4 11:16:39 2007
Subject: [GRASS-dev] broken API
In-Reply-To: <20070502204737.GY27153@bartok.itc.it>
References: <463072B6.9090209@faunalia.it>
	<20070502091433.GD27153@bartok.itc.it> <4638AD85.1010500@o2.pl>
	<20070502204737.GY27153@bartok.itc.it>
Message-ID: <20070504083706.GA4120@bartok.itc.it>

On Wed, May 02, 2007 at 10:47:37PM +0200, Markus Neteler wrote:
> On Wed, May 02, 2007 at 05:25:57PM +0200, Maciej Sieczka wrote:
> > Markus Neteler wrote:
> > > On Thu, Apr 26, 2007 at 11:36:54AM +0200, Paolo Cavallini wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >> Hi all.
> > >> While compiling qgis, I noticed that GRASS API has been broken:
> > >> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/include/version.h.in.diff?r1=1.4&r2=1.5
> > >> As a result, QGIS can no longer be compiled with GRASS support.
> > > 
> > > https://svn.qgis.org/trac/ticket/712
> > > 
> > > It has been fixed last night in QGIS SVN HEAD.
> > 
> > Still broken for QGIS 0.8.1 to-be-relased "stable" branch, though.
> 
> I have posted this there and re-opened ticket 712.

https://svn.qgis.org/trac/ticket/712
05/03/07 14:26:22 changed by wonder

    * status changed from reopened to closed.
    * resolution set to fixed.

    Okay, I've ported it to 0.8 branch in r6925.


Also done.
Markus

From tutey at o2.pl  Fri May  4 11:15:00 2007
From: tutey at o2.pl (Maciej Sieczka)
Date: Fri May  4 11:17:10 2007
Subject: [GRASS-dev] broken API
In-Reply-To: <20070502204737.GY27153@bartok.itc.it>
References: <463072B6.9090209@faunalia.it>	<20070502091433.GD27153@bartok.itc.it>
	<4638AD85.1010500@o2.pl> <20070502204737.GY27153@bartok.itc.it>
Message-ID: <463AF994.7060901@o2.pl>

Markus Neteler wrote:
> On Wed, May 02, 2007 at 05:25:57PM +0200, Maciej Sieczka wrote:
>> Markus Neteler wrote:
>>> On Thu, Apr 26, 2007 at 11:36:54AM +0200, Paolo Cavallini wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> Hi all.
>>>> While compiling qgis, I noticed that GRASS API has been broken:
>>>> http://freegis.org/cgi-bin/viewcvs.cgi/grass6/include/version.h.in.diff?r1=1.4&r2=1.5
>>>> As a result, QGIS can no longer be compiled with GRASS support.
>>> https://svn.qgis.org/trac/ticket/712
>>>
>>> It has been fixed last night in QGIS SVN HEAD.
>> Still broken for QGIS 0.8.1 to-be-relased "stable" branch, though.
> 
> I have posted this there and re-opened ticket 712.

The workaround has now been backported to QGIS 0.8 SVN branch. Thanks
to Martin Dobias.

Maciek

From neteler at itc.it  Fri May  4 11:51:00 2007
From: neteler at itc.it (Markus Neteler)
Date: Fri May  4 11:51:02 2007
Subject: [GRASS-dev] v.digit crash
In-Reply-To: <17978.2506.498061.966343@cerise.gclements.plus.com>
References: <20070502185131.GU27153@bartok.itc.it>	<20070502204652.GX27153@bartok.itc.it>	<17977.10689.814954.842123@cerise.gclements.plus.com>	<20070503123950.GN26403@bartok.itc.it>
	<17978.2506.498061.966343@cerise.gclements.plus.com>
Message-ID: <463B0204.90205@itc.it>

Glynn Clements wrote on 05/03/2007 06:11 PM:
> Markus Neteler wrote:
>
>   
>> since only SQLITE_INTEGER, SQLITE_TEXT, and SQLITE_FLOAT are
>> supported, we could define the typical length for these fields
>> (based on what the DBF driver does or the PostgreSQL driver).
>>
>> Attached a patch which cures the problem. If ok, I will submit.
>>     
>
> Seems okay.
>   
Submitted and backported to 6.2-CVS.

Markus


------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

From paul-grass at stjohnspoint.co.uk  Fri May  4 12:34:55 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Fri May  4 12:34:59 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <17978.49257.54158.338385@cerise.gclements.plus.com>
References: <17973.6027.501488.6826@cerise.gclements.plus.com>
	<C25A7ABA.2175A%michael.barton@asu.edu>
	<17973.14328.976484.737490@cerise.gclements.plus.com>
	<45498D53-739B-4CF9-83B5-AFC2ADE6935C@kyngchaos.com>
	<17973.43565.792862.529314@cerise.gclements.plus.com>
	<C3D9289B-E502-469C-8E9D-80CC7EF871DF@kyngchaos.com>
	<17974.14679.620262.783465@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705040503540.8987@agrippa.ukshells.co.uk>
	<77EBAF8C-D7FF-45B6-A34B-6F2BB6FBFD6A@kyngchaos.com>
	<17978.49257.54158.338385@cerise.gclements.plus.com>
Message-ID: <Pine.LNX.4.62.0705041132590.13625@agrippa.ukshells.co.uk>

On Fri, 4 May 2007, Glynn Clements wrote:

> William Kyngesburye wrote:
>
>> It's already been discussed (r.in.wms problem) that /I is a GNU
>> extension to sed.  OSX, at least, is BSD.  Don't know what to say
>> otherwise...
>
> An alternative is to change -iname to -name, and include both upper-
> and lower-case versions of the extension in exts.

OK, that works (see patch below). The font names are a bit cryptic though, 
as they all seem to be constrained to the 8 character limit, but I suppose 
that isn't so important.

Index: mkftcap
===================================================================
RCS file: /home/grass/grassrepository/grass6/tools/mkftcap/mkftcap,v
retrieving revision 1.6
diff -u -r1.6 mkftcap
--- mkftcap     3 May 2007 04:25:17 -0000       1.6
+++ mkftcap     4 May 2007 10:26:51 -0000
@@ -1,6 +1,6 @@
  #!/bin/sh

-exts='ttf pfa pfb'
+exts='ttf TTF pfa PFA pfb PFB'

  (
      for dir in /usr/lib/X11/fonts /usr/share/X11/fonts /usr/share/fonts \
@@ -10,7 +10,7 @@
      do
          if [ -d "$dir" ] ; then
              for ext in $exts ; do
-                find "$dir" -type f -iname '*.'"$ext" -print \
+                find "$dir" -type f -name '*.'"$ext" -print \
                      | sed 's!^\(.*\)/\(.*\)$!\2:\1/\2:utf-8:!' \
                      | sed 's/\.'"$ext"':/:/'
              done


From paul-grass at stjohnspoint.co.uk  Fri May  4 12:50:02 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Fri May  4 12:50:05 2007
Subject: [GRASS-dev] S-JTSK strikes back
In-Reply-To: <20070503095022.GA26403@bartok.itc.it>
References: <20070503095022.GA26403@bartok.itc.it>
Message-ID: <Pine.LNX.4.62.0705041145180.13625@agrippa.ukshells.co.uk>

On Thu, 3 May 2007, Markus Neteler wrote:

> Hi,
>
> for a project I need to define a S-JTSK location. I thought
> that we resolved this recently, but apparently not:
>
> # S-JTSK (Ferro) / Krovak
> <2065> +proj=krovak +lat_0=49.5 +lon_0=42.5 +alpha=30.28813972222222 +k=0.9999 +x_0=0 +y_0=0 +ellps=bessel +pm=ferro +units=m +no_defs  <>
>
> So I do:
>
> g.proj epsg=2065

Hello Markus,
As far as I can remember it was only resolved in so far as we decided that 
you couldn't create a Krovak location using EPSG codes and it needed to be 
done manually using g.setproj? This was because of problems translating 
WKT into a PROJ.4 description inside OGR, partly related to the fact that 
"proj=krovak" is still kind of temporary and has various paramters 
hard-coded in it and a good flexible translation will require to use the 
new "proj=kocc" when it is eventually merged into PROJ.4. But if you think 
there is more to it than this then I can look into it more.

Paul

>
> g.proj -w
> PROJCS["Krovak",
>    GEOGCS["bessel",
>        DATUM["unknown",
>            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
>        PRIMEM["Greenwich",0],
>        UNIT["degree",0.0174532925199433]],
>    PROJECTION["Krovak"],
>    PARAMETER["latitude_of_center",49.5],
>    PARAMETER["longitude_of_center",24.83333333333333],
>    PARAMETER["azimuth",0],
>    PARAMETER["pseudo_standard_parallel_1",0],
>    PARAMETER["scale_factor",0.9999],
>    PARAMETER["false_easting",0],
>    PARAMETER["false_northing",0],
>    UNIT["Meter",1]]
>
> This is not quite right. It should be
> http://lists.maptools.org/pipermail/proj/2003-February/000626.html
> something like this:
> PROJCS["S-JTSK (Ferro) / Krovak",
>     GEOGCS["S-JTSK (Ferro)",
>         DATUM["S_JTSK_Ferro",
>             SPHEROID["Bessel 1841",6377397.155,299.1528128,
>                 AUTHORITY["EPSG","7004"]],
>             AUTHORITY["EPSG","6818"]],
>         PRIMEM["Ferro",-17.66666666666667,
>             AUTHORITY["EPSG","8909"]],
>         UNIT["degree",0.0174532925199433],
>         AUTHORITY["EPSG","4818"]],
>     PROJECTION["Krovak"],
>     PARAMETER["latitude_of_center",49.5],
>     PARAMETER["longitude_of_center",42.5],
>     PARAMETER["azimuth",30.28813972222222],
>     PARAMETER["pseudo_standard_parallel_1",78.5],
>     PARAMETER["scale_factor",0.9999],
>     PARAMETER["false_easting",0],
>     PARAMETER["false_northing",0],
>     UNIT["metre",1,
>         AUTHORITY["EPSG","9001"]],
>     AUTHORITY["EPSG","2065"]]
>
> Is any name remapping still missing in
> lib/proj/convert.c
> ?
>
> Markus
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>

From paul-grass at stjohnspoint.co.uk  Fri May  4 13:18:09 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Fri May  4 13:18:11 2007
Subject: [GRASS-dev] S-JTSK strikes back
In-Reply-To: <20070503115742.GJ26403@bartok.itc.it>
References: <20070503095022.GA26403@bartok.itc.it>
	<20070503100918.GD26403@bartok.itc.it>
	<20070503115742.GJ26403@bartok.itc.it>
Message-ID: <Pine.LNX.4.62.0705041206480.13625@agrippa.ukshells.co.uk>

OK I think I see now what you are noticing. This seems like a slightly
different problem again from the one we came across last time. In general
I think the Krovak support in OGR/PROJ needs completely re-done using
proj=kocc; it is not enough to keep coming across little issues like this
and filing bug reports for OGR but anyway let's have a look...

On Thu, 3 May 2007, Markus Neteler wrote:

> On Thu, May 03, 2007 at 12:09:19PM +0200, Markus Neteler wrote:
>
> cat Area_topolcianky.prj
> PROJCS["S-JTSK_Krovak",GEOGCS["GCS_S_JTSK",DATUM["D_S_JTSK",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Krovak"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Pseudo_Standard_Parallel_1",78.5],PARAMETER["Scale_Factor",0.9999],PARAMETER["Azimuth",30.28813975277778],PARAMETER["Longitude_Of_Center",24.83333333333333],PARAMETER["Latitude_Of_Center",49.5],PARAMETER["X_Scale",1.0],PARAMETER["Y_Scale",1.0],PARAMETER["XY_Plane_Rotation",0.0],UNIT["Meter",1.0]]

Saving this to a file tmp.prj and running g.proj -p wkt=tmp.prj gives

-PROJ_INFO-------------------------------------------------
name       : Krovak
proj       : krovak
ellps      : bessel
lat_0      : 49.5
lon_0      : 24.83333333333333
alpha      : 30.28813975277778
k          : 0.9999
x_0        : 0
y_0        : 0
no_defs    : defined
-PROJ_UNITS------------------------------------------------
unit       : Meter
units      : Meters
meters     : 1

> g.proj wkt=Area_topolcianky.prj
> WARNUNG: Datum 'Jednotne_Trigonometricke_Site_Katastralni' not recognised
>         by GRASS and no parameters found.
> g.proj -w
> PROJCS["Krovak",
>    GEOGCS["bessel",
>        DATUM["unknown",
>            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
>        PRIMEM["Greenwich",0],
>        UNIT["degree",0.0174532925199433]],
>    PROJECTION["Krovak"],
>    PARAMETER["latitude_of_center",49.5],
>    PARAMETER["longitude_of_center",24.83333333333333],
>    PARAMETER["azimuth",0],
>    PARAMETER["pseudo_standard_parallel_1",0],
>    PARAMETER["scale_factor",0.9999],
>    PARAMETER["false_easting",0],
>    PARAMETER["false_northing",0],
>    UNIT["Meter",1]]
>
> It has picked up at least 0.9999 (lost pseudo_standard_parallel_1 etc).

This goes through two translations here (WKT to GRASS format and back to 
WKT), so is more complicated and I will come back to it later. But note 
that scale_factor =0.9999 is present in the orginal WKT above. I see 
Pseudo Standard Parallel is gone, but again have to ask - is it important 
for the PROJ.4 version of proj=krovak? I really have no idea.

> If I do the same with OGR, I get
> ogrinfo -so Area_topolcianky.shp Area_topolcianky
> INFO: Open of `Area_topolcianky.shp'
>      using driver `ESRI Shapefile' successful.
>
> Layer name: Area_topolcianky
> Geometry: Polygon
> Feature Count: 1
> Extent: (1255514.000000, 473866.000000) - (1256400.000000, 474752.000000)
> Layer SRS WKT:
> PROJCS["S-JTSK_Krovak",
>    GEOGCS["GCS_S_JTSK",
>        DATUM["Jednotne_Trigonometricke_Site_Katastralni",
>            SPHEROID["Bessel_1841",6377397.155,299.1528128]],
>        PRIMEM["Greenwich",0.0],
>        UNIT["Degree",0.0174532925199433]],
>    PROJECTION["Krovak"],
>    PARAMETER["False_Easting",0.0],
>    PARAMETER["False_Northing",0.0],
>    PARAMETER["Pseudo_Standard_Parallel_1",78.5],
>    PARAMETER["Scale_Factor",0.9999],
>    PARAMETER["Azimuth",30.28813975277778],
>    PARAMETER["Longitude_Of_Center",24.83333333333333],
>    PARAMETER["Latitude_Of_Center",49.5],
>    PARAMETER["X_Scale",1.0],
>    PARAMETER["Y_Scale",1.0],
>    PARAMETER["XY_Plane_Rotation",0.0],
>    UNIT["Meter",1.0]]
> Id: Integer (6.0)
> AREA: Real (19.11)
> PERIM: Real (19.11)
>
> Apparently GRASS is still lacking something.

The WKT description here is just an exact copy of the one you posted at 
the top of the e-mail there and hasn't been processed at all. So no 
surprises that it hasn't changed.

Therefore it seems some information (the pseudo standard parallel value) 
is lost when converting from WKT into GRASS format, and some more 
information (the alpha value) is lost when converting from GRASS format 
back to WKT. Is this important? I don't know anyway how important alpha 
and pseudo standard parallel are. Are they important for proj=krovak or 
does it just ignore it? It seems alpha corresonds to Azimuth in the WKT and 
OSRImportFromProj4() isn't converting it properly, but I really don't know 
how important it is for proj=krovak so wouldn't like to get too deeply 
involved there... Likewise for Pseudo_Standard_Parallel_1 and 
OSRExportToProj4().

Paul

From landa.martin at gmail.com  Fri May  4 13:42:48 2007
From: landa.martin at gmail.com (Martin Landa)
Date: Fri May  4 13:42:51 2007
Subject: [GRASS-dev] S-JTSK strikes back
In-Reply-To: <Pine.LNX.4.62.0705041206480.13625@agrippa.ukshells.co.uk>
References: <20070503095022.GA26403@bartok.itc.it>
	<20070503100918.GD26403@bartok.itc.it>
	<20070503115742.GJ26403@bartok.itc.it>
	<Pine.LNX.4.62.0705041206480.13625@agrippa.ukshells.co.uk>
Message-ID: <f8fe65c40705040442k20aa3a10icddf1f91a2e512a1@mail.gmail.com>

Hi Paul,

2007/5/4, Paul Kelly <paul-grass@stjohnspoint.co.uk>:
> OK I think I see now what you are noticing. This seems like a slightly
> different problem again from the one we came across last time. In general
> I think the Krovak support in OGR/PROJ needs completely re-done using
> proj=kocc; it is not enough to keep coming across little issues like this
> and filing bug reports for OGR but anyway let's have a look...

Agree...

[snip]

> > It has picked up at least 0.9999 (lost pseudo_standard_parallel_1 etc).
>
> This goes through two translations here (WKT to GRASS format and back to
> WKT), so is more complicated and I will come back to it later. But note
> that scale_factor =0.9999 is present in the orginal WKT above. I see
> Pseudo Standard Parallel is gone, but again have to ask - is it important
> for the PROJ.4 version of proj=krovak? I really have no idea.

> The WKT description here is just an exact copy of the one you posted at
> the top of the e-mail there and hasn't been processed at all. So no
> surprises that it hasn't changed.
>
> Therefore it seems some information (the pseudo standard parallel value)
> is lost when converting from WKT into GRASS format, and some more
> information (the alpha value) is lost when converting from GRASS format
> back to WKT. Is this important? I don't know anyway how important alpha
> and pseudo standard parallel are. Are they important for proj=krovak or
> does it just ignore it? It seems alpha corresonds to Azimuth in the WKT and
> OSRImportFromProj4() isn't converting it properly, but I really don't know
> how important it is for proj=krovak so wouldn't like to get too deeply
> involved there... Likewise for Pseudo_Standard_Parallel_1 and
> OSRExportToProj4().

Latitude of pseudo standard parallel (78d30m) is hard-coded in
PJ_krovak.c and alpha I guess is ignored.

I see problem using g.proj epsg=2065 -p / -w :

PRIMEM["ferro",-17.666666666668]
PARAMETER["longitude_of_center",24.833333333332], <- not Ferro, but Greenwich
x
pm         : ferro
lon_0      : 42.5 <- OK

Martin

>
> Paul
>
> _______________________________________________
> 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 paul-grass at stjohnspoint.co.uk  Fri May  4 13:57:02 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Fri May  4 13:57:11 2007
Subject: [GRASS-dev] S-JTSK strikes back
In-Reply-To: <f8fe65c40705040442k20aa3a10icddf1f91a2e512a1@mail.gmail.com>
References: <20070503095022.GA26403@bartok.itc.it>
	<20070503100918.GD26403@bartok.itc.it>
	<20070503115742.GJ26403@bartok.itc.it>
	<Pine.LNX.4.62.0705041206480.13625@agrippa.ukshells.co.uk>
	<f8fe65c40705040442k20aa3a10icddf1f91a2e512a1@mail.gmail.com>
Message-ID: <Pine.LNX.4.62.0705041255090.13625@agrippa.ukshells.co.uk>

Hello Martin

On Fri, 4 May 2007, Martin Landa wrote:

>> information (the alpha value) is lost when converting from GRASS format
>> back to WKT. Is this important? I don't know anyway how important alpha
>> and pseudo standard parallel are. Are they important for proj=krovak or
>> does it just ignore it? It seems alpha corresonds to Azimuth in the WKT and
>> OSRImportFromProj4() isn't converting it properly, but I really don't know
>> how important it is for proj=krovak so wouldn't like to get too deeply
>> involved there... Likewise for Pseudo_Standard_Parallel_1 and
>> OSRExportToProj4().
>
> Latitude of pseudo standard parallel (78d30m) is hard-coded in
> PJ_krovak.c and alpha I guess is ignored.

OK thanks for clearing this up a bit. So it isn't a big problem then. Just 
a bit messy.

> I see problem using g.proj epsg=2065 -p / -w :
>
> PRIMEM["ferro",-17.666666666668]
> PARAMETER["longitude_of_center",24.833333333332], <- not Ferro, but Greenwich

Yes this is the problem we came across before. It is currently the subject 
of a pending bug report in OGR: http://trac.osgeo.org/gdal/ticket/367

Paul

> x
> pm         : ferro
> lon_0      : 42.5 <- OK
>
> Martin
>
>> 
>> Paul
>> 
>> _______________________________________________
>> 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 woklist at kyngchaos.com  Fri May  4 16:23:31 2007
From: woklist at kyngchaos.com (William Kyngesburye)
Date: Fri May  4 16:23:42 2007
Subject: [GRASS-dev] the other part of font face index support
In-Reply-To: <463AD474.5080404@bergenheim.net>
References: <C2601830.21AAD%michael.barton@asu.edu>
	<463AD474.5080404@bergenheim.net>
Message-ID: <6FA8DF32-92F5-454E-B91D-6082EF2014DB@kyngchaos.com>

I guess I didn't finish my thoughts in my email (oops)...

- Add some utility to retrieve font info using FT functions - either  
an etc/ tool or a module (ie d.freetype.info).  mkftcap would step  
thru each font file in the initial list and see if it has multiple  
faces, building a new more complete freetypecap list.

It could even be used in place of fc-list, since mkftcap checks the  
usual dirs anyways, and can check dirs passed to it.  Instead of  
finding specific extensions, get the font info on every file, and if  
it's not a font file, no info will be returned.  Unusable fonts, like  
PCF, can still be detected and skipped.

If you can write a simple utility like this, go for it.  And it would  
be much more dependable than using fc-list IF it's installed, or  
requiring yet another external package to be installed, since it  
would be a part of GRASS.


On May 4, 2007, at 1:36 AM, Wolf Bergenheim wrote:

> Ah. it is part of the fttools package on Debian. Well I guess one (I)
> could make a similar utility to ship with GRASS...
>
> --Wolf
>
> On 04.05.2007 08:52, Michael Barton wrote:
>> This is not installed on my Mac, although I have installed X11 and  
>> a bunch
>> of other stuff.
>>
>> Michael
>>
>>
>> On 5/3/07 10:30 PM, "Wolf Bergenheim" <wolf+grass@bergenheim.net>  
>> wrote:
>>
>>> Perhaps the ftinfo tool can help you find more things about the  
>>> font?
>>>
>>> ftinfo -a fontfile will give you a lot of data :)

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*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  Fri May  4 16:31:15 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri May  4 16:31:27 2007
Subject: [GRASS-dev] [grass-code I][381] r.colors rules: some scripts
	broken
In-Reply-To: <17977.49723.783733.672549@cerise.gclements.plus.com>
References: <20070425172455.12BE21936633@pyrosoma.intevation.org>
	<20070503180729.7337dc08.hamish_nospam@yahoo.com>
	<17977.37144.972151.385@cerise.gclements.plus.com>
	<20070503211534.2bc6a6d5.hamish_nospam@yahoo.com>
	<17977.49723.783733.672549@cerise.gclements.plus.com>
Message-ID: <20070505023115.2c511b33.hamish_nospam@yahoo.com>

[you should probably read this bottom-up, as solutions>>rhetoric.
hopefully the attached script demonstrates that there's really not much
of an issue here after all -> our ideas are not mutually exclusive]

> Hamish wrote:
> > I am happy for r.colors to evolve, and glad the rules files are now
> > finally merged into color=, but fear we will damage tons of user
> > scripts with this change.

Glynn:
> The longer it's left, the more scripts will be broken by the change. 

As long as the functionality is no longer advertised, no new scripts
should use it (or at least fewer and fewer).

> It's already been left far too long (if it was originally done in 5.3,
> it should have been changed for 6.0.0).

ok, but water under the bridge now.

GC:
> > > As there hasn't been a 6.3.0 release yet, the 6.3 API remains
> > > subject to change.
HB:
> > It is my understanding that module options are frozen for 6.x, not
> > 6.x.y.
GC:
> That would make the rate of evolution far too slow. It would
> essentially mean periods of several years where no real development
> can occur.
> 
> If that was the case, I would have left after 6.0.0 was released, and
> probably have forgotten all about GRASS by the time that 7.x was open
> for development.

ok, "frozen" was perhaps a bad choice of word. my meaning was "existing
command line options locked in for the duration". Repeating my main
concern: a user script written for GRASS 6.0.0 should still work with
GRASS 6.9.99. People can adapt to GUI changes easy enough, scripts are
not so flexible.

> AIUI, major numbers are for "total" change: 5.x introduced FP and
> null. 6.x (originally 5.7) completely changed the source directory
> structure (no src/src.contrib/src.nonGPL, no cmd/inter
> subdirectories), the build system, and the vector subsystem.

yes; as far as the user is concerned the data files may not be
compatible between major versions.
 
> Minor numbers are for incompatible changes,

That was not true for 6.0->6.2, we held that to mostly incremental
improvements. In fact I don't know of a single incompatible command line
change we did*. It would be a shame to first break our compatibility
guarantee so close to 7.0, as a little discipline on our part translates
into a lot of goodwill.

[*] outside of 1 option change in v.surf.rst? which was fixing an error

> release numbers are for bug fixes and backward-compatible
> enhancements.

right.

> IOW, analogous to the Linux kernel: 2.0/2.2/2.4/2.6 all have
> substantial differences, while all 2.6.x versions are mostly
> compatible with each other.

Linux kernel devel is not 100% relevant, but FwIW my understanding is
that the 2.6 line has diverged into a continual upgrade cycle (no plans
for an unstable 2.7 or next-gen 2.8).

 
> > Would quietly checking for the file in $GISBASE/etc/colors/, after
> > it isn't found normally, really hurt much?
> 
> Yes.
> 
> Either the argument to rules= is a filename or it isn't.

it *is* a file name. I'm just asking to quietly augment the search path.

> If it is a filename, relative filenames are relative to the current
> directory.

$GISBASE should start with a root "/" or "C:", so no problem there.

Even if Tcl does not allow full path names in the file browser, that's
not a problem as 1) I'm talking about passing options from a script, and
2) if the user was hell-bent on using rules= in the old way from the
auto-gen GUI window, they can type whatever string they want in the
options box - it's not the file browser until you click on the file
folder icon.

> If it isn't a filename, then it's an arbitrary string, the GUI can't
> offer a file browser for it.

gisprompt->old_file is a good thing- of course the "new" rules= file
option should use it. The remaining question is if the parser checks for
the existence of the file when using old_file, or if it is up to the
module to do that. If it's up to the module then we can code in a path-
search trick to keep backwards compatibility, aka no problem. And this
seems to be the case -- try the attached script from the command line
using "srtm" as the file name. It works, and is all I am asking for the
C code to do.


anyway, yet another reason to push the move to SVN and begin the 7.0
branch so these discussions become moot.



Hamish


ps- all scripts/ in 6.3 CVS are now updated to use "r.colors color="
instead of rules=.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: g.testfile.sh
Type: text/x-sh
Size: 738 bytes
Desc: not available
Url : http://grass.itc.it/pipermail/grass-dev/attachments/20070505/f981300a/g.testfile.bin
From hamish_nospam at yahoo.com  Fri May  4 17:24:40 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Fri May  4 17:24:45 2007
Subject: [GRASS-dev] Re: v.net.path
In-Reply-To: <20070504081014.GA32285@bartok.itc.it>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
	<20070503203200.01aac525.hamish_nospam@yahoo.com>
	<20070503112433.GF26403@bartok.itc.it>
	<20070504081014.GA32285@bartok.itc.it>
Message-ID: <20070505032440.67f2bc16.hamish_nospam@yahoo.com>

> > > v.net.path:
> > > "Shortest path from two digitized nodes" example
> > > also try:
> > >   d.path -b roads coor="601653.5,4922869.2","593330.8,4924096.6"
> > > and
> > >   d.path -b myroads_net
> > >   coor="601653.5,4922869.2","593330.8,4924096.6" \
> >            afcol=forward hcolor=green
> > 
> > How cool, I didn't realize this -b flag so far.

I just added it recently, same time as coor=.
  (coor= so we can use d.path from the GUI)

> > The difference is striking. I am not really sure about the second
> > one.
> 
> OK, my mistake - the column should contain *costs*. That might be
> the inverse of the speed limit, not the speed limit itself:
> e.g.
> # define traveling costs as inverse of speed limit:
> v.db.update myroads col=forward val=1/50

ahh. Is "backward" really needed? (is it optional in d.path) I'm not
really sure what that means actually. Does it mean it costs more to
drive the wrong direction on a one way street? Harder to canoe upsteam?

> I have update the example in CVS. Please suggest if you have better
> ideas.

For completeness: re speed limits- Expect 30mph on residential streets,
55mph on minor highways and up to 75mph on the interstate. This varies
state to state & I'm not sure what the rules are in the Dakotas, but I
expect they let you go pretty damn fast. :)

but google knows all:
 http://www.iihs.org/laws/state_laws/speed_limit_laws.html



Hamish

From neteler at itc.it  Fri May  4 17:28:29 2007
From: neteler at itc.it (Markus Neteler)
Date: Fri May  4 17:28:31 2007
Subject: [GRASS-dev] Re: v.net.path
In-Reply-To: <20070505032440.67f2bc16.hamish_nospam@yahoo.com>
References: <20070502232008.040ef6dc.hamish_nospam@yahoo.com>
	<20070503150146.4134703f.hamish_nospam@yahoo.com>
	<20070503054759.GD19083@bartok.itc.it>
	<20070503203200.01aac525.hamish_nospam@yahoo.com>
	<20070503112433.GF26403@bartok.itc.it>
	<20070504081014.GA32285@bartok.itc.it>
	<20070505032440.67f2bc16.hamish_nospam@yahoo.com>
Message-ID: <20070504152828.GE29719@bartok.itc.it>

On Sat, May 05, 2007 at 03:24:40AM +1200, Hamish wrote:
> Markus wrote:
> > OK, my mistake - the column should contain *costs*. That might be
> > the inverse of the speed limit, not the speed limit itself:
> > e.g.
> > # define traveling costs as inverse of speed limit:
> > v.db.update myroads col=forward val=1/50
> 
> ahh. Is "backward" really needed? (is it optional in d.path) I'm not
> really sure what that means actually. Does it mean it costs more to
> drive the wrong direction on a one way street? Harder to canoe upsteam?

It's for the cases that you have a two lane road (see NC dataset).
You can simulate traffic jam: say, morning time one lane, in
the evening the other lane. Or connect to some traffic service
which updates your DB in real time.

> > I have update the example in CVS. Please suggest if you have better
> > ideas.
> 
> For completeness: re speed limits- Expect 30mph on residential streets,
> 55mph on minor highways and up to 75mph on the interstate. This varies
> state to state & I'm not sure what the rules are in the Dakotas, but I
> expect they let you go pretty damn fast. :)
> 
> but google knows all:
>  http://www.iihs.org/laws/state_laws/speed_limit_laws.html

Cool. So we can improve it again...

Markus

From michael.barton at asu.edu  Fri May  4 17:57:08 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Fri May  4 17:57:19 2007
Subject: [GRASS-dev] [grass-code R][391] d.legend: option to get info
	from stdin instead of raster
In-Reply-To: <20070504062031.1AF7E1800CF5@pyrosoma.intevation.org>
Message-ID: <C260A5E4.21AD1%michael.barton@asu.edu>




On 5/3/07 11:20 PM, "grass-coder@wald.intevation.org"
<grass-coder@wald.intevation.org> wrote:

> 
> Initial Comment:
> Hi,
> 
> It would be nice if d.legend could look for "map=-" and if so take legend cat
> and color info from stdin. That way vector maps and custom legends could be
> made without resorting to tricks like making a dummy raster file to hold that
> info.
> 
> If data is fed from stdin (signaled by map=-) create categorical legend
> using that data. Data format: "cat|label|color"
> 
> e.g.
> 
> d.legend -m map="-" <<EOF
> 1|Main Street|255:0:0
> 2|Elm Street|0:255:0
> 3|Old Coach Road|0:0:255
> EOF

I'm overall in favor of d.legend being able to build a legend from such
output. It would simplify matters for making thematic map and thematic chart
legends and might even work for making vector legends.

However, the interactive format shown above wouldn't work in a scriptable
GUI setting. I'm also having trouble trying to envision how it *could* work
in such a setting in order to make an alternative suggestion.

d.vect.chart [flag to send legend output to stdout] | d.legend map=- ????

Michael

> 
> In this way d.legend could work as a system module by the GUI instead of
> a user module, and be useful for non-raster tasks too.
> 
> 
> see expanded thread on the -dev mailing list:
>  http://thread.gmane.org/gmane.comp.gis.grass.devel/19852/focus=19952
> 
> 
> Hamish
> 
> 
> ----------------------------------------------------------------------
> 
> You can respond by visiting:
> http://wald.intevation.org/tracker/?func=detail&atid=188&aid=391&group_id=21
> 
> 

__________________________________________
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 paul-grass at stjohnspoint.co.uk  Fri May  4 18:06:05 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Fri May  4 18:06:08 2007
Subject: [GRASS-dev] Problem with font selection in gis.m on Windows
Message-ID: <Pine.LNX.4.62.0705041659160.21475@agrippa.ukshells.co.uk>

The recent talk of fonts on this list brought me to try out some stuff on 
Windows. I discovered there's a font selector control in gis.m (Config 
Menu-->Set default display font) but if I click the button to try and 
change it to anything other than Romans I get the following error:

couldn't execute "uname": no such file or directory
couldn't execute "uname": no such file or directory
     while executing
"exec uname -s"
     (procedure "Gm::SelectFont" line 7)
     invoked from within
"Gm::SelectFont"
     ("uplevel" body line 1)
     invoked from within
"uplevel \#0 $cmd"
     (procedure "Button::_release" line 18)
     invoked from within
"Button::_release .dispfont.fontopt2.b"
     (command bound to event)

Obviously trying to use the "uname" command (not available on native 
Windows) is the bug, but looking closer at the code (line 537 onwards in 
gui/tcltk/gis.m/gm.tcl) it seems the relevant part is trying to put 
together directories to search for Freetype fonts in? Which
(a) shouldn't even be needed here as I have the stroke font radio button 
in the dialog selected and don't even have GRASS compiled with Freetype 
support and
(b) might possibly be being made redundant by Glynn's new script to 
populate $GISBASE/etc/freetypecap?

Not sure what's the best way to fix this, taking into account those 
points.

Paul

From wolf+grass at bergenheim.net  Fri May  4 18:52:11 2007
From: wolf+grass at bergenheim.net (Wolf Bergenheim)
Date: Fri May  4 18:52:48 2007
Subject: [GRASS-dev] the other part of font face index support
In-Reply-To: <6FA8DF32-92F5-454E-B91D-6082EF2014DB@kyngchaos.com>
References: <C2601830.21AAD%michael.barton@asu.edu>
	<463AD474.5080404@bergenheim.net>
	<6FA8DF32-92F5-454E-B91D-6082EF2014DB@kyngchaos.com>
Message-ID: <463B64BB.8020108@bergenheim.net>

I'm willing to do this, but can you wait a week? I have 2 exams 3
project deadlines and a work deadline all by next week. So you can guess
how many minutes I can spend on GRASS the next week... :(

--Wolf

On 04.05.2007 17:23, William Kyngesburye wrote:
> I guess I didn't finish my thoughts in my email (oops)...
> 
> - Add some utility to retrieve font info using FT functions - either an
> etc/ tool or a module (ie d.freetype.info).  mkftcap would step thru
> each font file in the initial list and see if it has multiple faces,
> building a new more complete freetypecap list.
> 
> It could even be used in place of fc-list, since mkftcap checks the
> usual dirs anyways, and can check dirs passed to it.  Instead of finding
> specific extensions, get the font info on every file, and if it's not a
> font file, no info will be returned.  Unusable fonts, like PCF, can
> still be detected and skipped.
> 
> If you can write a simple utility like this, go for it.  And it would be
> much more dependable than using fc-list IF it's installed, or requiring
> yet another external package to be installed, since it would be a part
> of GRASS.
> 
> 
> On May 4, 2007, at 1:36 AM, Wolf Bergenheim wrote:
> 
>> Ah. it is part of the fttools package on Debian. Well I guess one (I)
>> could make a similar utility to ship with GRASS...
>>
>> --Wolf
>>
>> On 04.05.2007 08:52, Michael Barton wrote:
>>> This is not installed on my Mac, although I have installed X11 and a
>>> bunch
>>> of other stuff.
>>>
>>> Michael
>>>
>>>
>>> On 5/3/07 10:30 PM, "Wolf Bergenheim" <wolf+grass@bergenheim.net> wrote:
>>>
>>>> Perhaps the ftinfo tool can help you find more things about the font?
>>>>
>>>> ftinfo -a fontfile will give you a lot of data :)
> 
> -----
> William Kyngesburye <kyngchaos*at*kyngchaos*dot*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
> 
> 

-- 

<:3 )---- Wolf Bergenheim ----( 8:>

From paul-grass at stjohnspoint.co.uk  Sat May  5 15:41:33 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Sat May  5 15:41:35 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
Message-ID: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>

As mentioned in an earlier e-mail, I thought I'd try and see if I can get
Freetype font support working on native Windows. Came across the error
message below in lib/driver. As far as I can see it is because I don't
have iconv installed, but the section of the source is only
conditionalised on HAVE_FT2BUILD_H. I'm wondering if the bits that
reference convert_str (which presumably does translation) could safely be
conditionalised on HAVE_ICONV_H, or does anybody know if the
interdependency between Freetype and iconv goes deeper than that?

sh-2.04$ cd lib/driver
sh-2.04$ make
gcc -I/c/grass/grass6/dist.i686-pc-mingw32/include -I/c/grass/extra/include -g -
O2  -I/c/grass/extra/include      -DPACKAGE=\""grasslibs"\" -I/c/grass/extra/inc
lude/freetype2    -DPACKAGE=\""grasslibs"\"  -I/c/grass/grass6/dist.i686-pc-ming
w32/include \
          -o OBJ.i686-pc-mingw32/text3.o -c text3.c
text3.c: In function `convert_str':
text3.c:139: error: `iconv_t' undeclared (first use in this function)
text3.c:139: error: (Each undeclared identifier is reported only once
text3.c:139: error: for each function it appears in.)
text3.c:139: error: syntax error before "cd"
text3.c:157: error: `cd' undeclared (first use in this function)
make: *** [OBJ.i686-pc-mingw32/text3.o] Error 1

From neteler at itc.it  Sat May  5 16:29:00 2007
From: neteler at itc.it (Markus Neteler)
Date: Sat May  5 16:29:02 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17976.35182.363572.196185@cerise.gclements.plus.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
Message-ID: <20070505142900.GA14720@bartok.itc.it>

On Wed, May 02, 2007 at 01:51:58PM +0100, Glynn Clements wrote:
> Markus Neteler wrote:
> 
> > > > >>> Bear in mind that the raster map is always opaque, so it will obscure
> > > > >>> anything which is drawn beneath it.
> > > > >>>       
> > > > >> Markus:
> > > > >>     
> > > > >>> That's exactly what I need: in my case the raster map contains a few
> > > > >>> cells only, but I need it on top to not be covered by vector contour
> > > > >>> lines etc.
> > > > >>>       
> > > > >> ..
> > > > >>     
> > > > >>> Maybe ps.map's raster command needs an additional parameter "ontop" or
> > > > >>> something like this? Hacking C code as Hamish suggests might be asked
> > > > >>> too much for the average user.
> > > > >>>       
> > > > >> are the null areas solid white, not transparent?
> > > > >>     
> > > > >
> > > > > They are transparent. All fine.
> > > > Of course I was too hasty. Nothing fine.
> > > > > Just that the tons of contour
> > > > > lines cover the scarse raster areas in the raster maps. That's
> > > > > why I need them on top of the dense contour lines.
> > > > >   
> > > > ... and it seems that NULL is not respected by ps.map (as you will know
> > > > already).
> > > 
> > > For masked images, you need to use the one-operand form of the "image"
> > > operator with an image dictionary; see the RASTERMASK procedure in
> > > lib/psdriver/psdriver.ps for an example. This requires support for
> > > level 3 PostScript (present in GhostScript for a few years now; I
> > > don't know about printers).
> > > 
> > > Regarding the generation of the image data (ps/ps.map/ps_raster.c), a
> > > masked image needs 2 (mono) or 4 (RGB) components, with the mask byte
> > > first (i.e. AARRGGBB); see lib/psdriver/Raster.c.
> > 
> > I am afraid that I am not able to implement this.
> 
> Try the attached patch.
> 
> It only works with single rasters, not R/G/B groups. Also, the masked
> flag is currently hard-coded on; ultimately, this would need to be
> made into an option to the raster/rgb/group commands.

Glynn,

do you consider to submit it? It seems to work well.

Thanks
Markus

From glynn at gclements.plus.com  Sat May  5 17:18:57 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sat May  5 17:19:00 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
Message-ID: <17980.41057.504876.936561@cerise.gclements.plus.com>


Paul Kelly wrote:

> As mentioned in an earlier e-mail, I thought I'd try and see if I can get
> Freetype font support working on native Windows. Came across the error
> message below in lib/driver. As far as I can see it is because I don't
> have iconv installed, but the section of the source is only
> conditionalised on HAVE_FT2BUILD_H. I'm wondering if the bits that
> reference convert_str (which presumably does translation) could safely be
> conditionalised on HAVE_ICONV_H, or does anybody know if the
> interdependency between Freetype and iconv goes deeper than that?

d.text.freetype already handles the lack of iconv(); look at
convert_text() in d.text.freetype/main.c.

You just need a hard-coded conversion to UCS-2 for the case where
iconv() is unavailable. ISO-8859-1 -> UCS-2 (used by d.text.freetype)
is trivial; a built-in UTF-8 -> UCS-2 converter wouldn't be a lot of
work.

Alternatively, you could use mbstowcs() to convert according to the
current locale.

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

From glynn at gclements.plus.com  Sat May  5 17:30:44 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sat May  5 17:30:47 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <20070505142900.GA14720@bartok.itc.it>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
Message-ID: <17980.41764.666518.270623@cerise.gclements.plus.com>


Markus Neteler wrote:

> > > > For masked images, you need to use the one-operand form of the "image"
> > > > operator with an image dictionary; see the RASTERMASK procedure in
> > > > lib/psdriver/psdriver.ps for an example. This requires support for
> > > > level 3 PostScript (present in GhostScript for a few years now; I
> > > > don't know about printers).
> > > > 
> > > > Regarding the generation of the image data (ps/ps.map/ps_raster.c), a
> > > > masked image needs 2 (mono) or 4 (RGB) components, with the mask byte
> > > > first (i.e. AARRGGBB); see lib/psdriver/Raster.c.
> > > 
> > > I am afraid that I am not able to implement this.
> > 
> > Try the attached patch.
> > 
> > It only works with single rasters, not R/G/B groups. Also, the masked
> > flag is currently hard-coded on; ultimately, this would need to be
> > made into an option to the raster/rgb/group commands.
> 
> do you consider to submit it? It seems to work well.

Not in its present form. The main problem is that the "masked" setting
is currently hard-coded, and masked images require level 3 PostScript. 
This would make the output from ps.map incompatible with older
versions of Ghostscript and some printers.

Realistically, the ps.map input syntax needs to be extended to add a
"masked" option to the raster, greyrast, rgb and group commands, so
that masked images are only used if specifically requested. 
Alternatively, masking could be enabled only if the raster isn't the
bottom-most layer (it used to always be drawn first, but presumably
that has been changed).

Also, the patch only affects the raster/greyrast commands; the
rgb/group case needs similar treatment.

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

From michael.barton at asu.edu  Sat May  5 19:01:40 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sat May  5 19:01:50 2007
Subject: [GRASS-dev] access to wingrass binaries
Message-ID: <C2620684.21B3A%michael.barton@asu.edu>

Can we list Moritz? wingrass binary site on the GRASS binaries download page
in addition to or instead of Huidae Cho?s page? Huidae?s binaries are way
out of date and I understand that Moritz is doing regular binary
maintenance.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://grass.itc.it/pipermail/grass-dev/attachments/20070505/61de4bee/attachment.html
From michael.barton at asu.edu  Sat May  5 19:10:39 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sat May  5 19:10:48 2007
Subject: [GRASS-dev] Problem with font selection in gis.m on Windows
In-Reply-To: <Pine.LNX.4.62.0705041659160.21475@agrippa.ukshells.co.uk>
Message-ID: <C262089F.21B3E%michael.barton@asu.edu>

I lifted this from Init.sh, where it checks for things like Mingw and
Cygwin, so I thought it would work with windows. If it doesn't, I guess it's
pointless to have it in Init.sh too.

As the current font selection is done, I need to know if a Mac, Windows, or
other system is running to know where to look for fonts. If uname doesn't
work on Windows, I don't know how to find this out.

If there is no other solution, I'll try to implement an alternate kind of
dialog, using a listbox and the new and improved freetypecap file, like I've
done for the wxPython GUI.

Michael


On 5/4/07 9:06 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

> The recent talk of fonts on this list brought me to try out some stuff on
> Windows. I discovered there's a font selector control in gis.m (Config
> Menu-->Set default display font) but if I click the button to try and
> change it to anything other than Romans I get the following error:
> 
> couldn't execute "uname": no such file or directory
> couldn't execute "uname": no such file or directory
>      while executing
> "exec uname -s"
>      (procedure "Gm::SelectFont" line 7)
>      invoked from within
> "Gm::SelectFont"
>      ("uplevel" body line 1)
>      invoked from within
> "uplevel \#0 $cmd"
>      (procedure "Button::_release" line 18)
>      invoked from within
> "Button::_release .dispfont.fontopt2.b"
>      (command bound to event)
> 
> Obviously trying to use the "uname" command (not available on native
> Windows) is the bug, but looking closer at the code (line 537 onwards in
> gui/tcltk/gis.m/gm.tcl) it seems the relevant part is trying to put
> together directories to search for Freetype fonts in? Which
> (a) shouldn't even be needed here as I have the stroke font radio button
> in the dialog selected and don't even have GRASS compiled with Freetype
> support and
> (b) might possibly be being made redundant by Glynn's new script to
> populate $GISBASE/etc/freetypecap?
> 
> Not sure what's the best way to fix this, taking into account those
> points.
> 
> Paul
> 
> 

__________________________________________
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 neteler at itc.it  Sat May  5 19:47:54 2007
From: neteler at itc.it (Markus Neteler)
Date: Sat May  5 19:47:56 2007
Subject: [GRASS-dev] access to wingrass binaries
In-Reply-To: <C2620684.21B3A%michael.barton@asu.edu>
References: <C2620684.21B3A%michael.barton@asu.edu>
Message-ID: <20070505174754.GB19710@bartok.itc.it>

On Sat, May 05, 2007 at 10:01:40AM -0700, Michael Barton wrote:
>    Can we list Moritz' wingrass binary site on the GRASS binaries download
>    page in addition to or instead of Huidae Cho's page? Huidae's binaries are
>    way out of date and I understand that Moritz is doing regular binary
>    maintenance.

The winGRASS native binaries available from
 http://moritz.homelinux.org/grass/wingrass/
is from end of March...

In general, all developers with write access can modify
the web pages.

Markus

From soerengebbert at gmx.de  Sat May  5 22:36:33 2007
From: soerengebbert at gmx.de (=?ISO-8859-15?Q?S=F6ren_Gebbert?=)
Date: Sat May  5 22:37:06 2007
Subject: [GRASS-dev] release management lecture 
Message-ID: <463CEAD1.2040304@gmx.de>

Hi folks,
maybe you are interested in this:
http://video.google.de/videoplay?docid=-5503858974016723264

best regards
soeren

From paul-grass at stjohnspoint.co.uk  Sat May  5 23:59:21 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Sat May  5 23:59:24 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <17980.41057.504876.936561@cerise.gclements.plus.com>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
	<17980.41057.504876.936561@cerise.gclements.plus.com>
Message-ID: <Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>

On Sat, 5 May 2007, Glynn Clements wrote:

> You just need a hard-coded conversion to UCS-2 for the case where
> iconv() is unavailable. ISO-8859-1 -> UCS-2 (used by d.text.freetype)
> is trivial; a built-in UTF-8 -> UCS-2 converter wouldn't be a lot of
> work.

Thanks for the hint - that seems to have worked out fine and I've already 
committed the fix.

I've attached a diff of a few more changes I'm considering making, mostly 
relating to path and filename handling for Windows compatibility in 
loading fonts. Here's what I've changed so far:

lib/driver/Font.c, COM_Font_get():
* Cross-platform check for absolute path (new gislib function added)
* Check for pathname matching the GRASS stroke fonts made more robust by
   (a) First converting all directory separator characters to '/'
   (b) Doing a case-insensitive comparison

lib/driver/font2.c, read_fontmap():
* Warning message when unable to open font made clearer by specifying
the exact path it was trying to open and giving the system error message.

font_init():
* Convert directory separator characters to '/' so that the way the 
directory name is stripped off works
* Strip off the ".hmp" extension if it was there. It strikes me as very
weird that I needed to do this, because without that I reall can't see how 
passing the full path to one of the GRASS stroke fronts would have worked. 
The full filename has to be given in the GRASS_FONT variable, otherwise 
the font_exists() check in COM_Font_get() will fail, but the .hmp is never 
stripped off and then it is added again in read_fontmap(), resulting in it 
trying to open a file ending in ".hmp.hmp".

I haven't committed the changes yet as they're not complete. Apart from
being unsure about stripping off the .hmp extension, specifying a
font in GRASS_FONT from the freetypecap file doesn't work. I'm just
testing this from the command line on Windows, i.e. using direct
rendering as drivers don't work, and I can't see where/if the freetypecap 
file is actually being read. Specifying the full path to a Freetype font
works fine, but is the freetypecap file only read when a driver process
is initialised?

-------------- next part --------------
Index: include/gisdefs.h
===================================================================
RCS file: /home/grass/grassrepository/grass6/include/gisdefs.h,v
retrieving revision 1.99
diff -u -r1.99 gisdefs.h
--- include/gisdefs.h	2 May 2007 06:00:33 -0000	1.99
+++ include/gisdefs.h	5 May 2007 21:43:58 -0000
@@ -865,6 +865,7 @@
 /* paths.c */
 int G_mkdir(const char *);
 int G_is_dirsep(char);
+int G_is_absolute_path(const char *);
 char *G_convert_dirseps_to_host(char *);
 char *G_convert_dirseps_from_host(char *);
 struct stat;
 
 /* timestamp.c */
Index: lib/gis/paths.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/gis/paths.c,v
retrieving revision 2.3
diff -u -r2.3 paths.c
--- lib/gis/paths.c	4 Apr 2007 04:07:01 -0000	2.3
+++ lib/gis/paths.c	5 May 2007 21:43:58 -0000
@@ -41,6 +41,27 @@
 }
 
 /**
+ * \brief Checks if a specified path looks like an absolute
+ *        path on the host system
+ *
+ * \param path String containing path to check
+ *
+ * \return 1 if path looks like an absolute path, 0 if not
+ **/
+
+int G_is_absolute_path(const char *path)
+{
+    if ( G_is_dirsep(path[0])
+#ifdef __MINGW32__	
+	|| ((path[1] == ':') && G_is_dirsep(path[2])) 
+#endif
+       )
+        return 1;
+    else
+        return 0;
+}
+   
+/**
  * \brief Converts directory separator characters in a string to the
  *        native host separator character (/ on Unix, \ on Windows)
  *
Index: lib/driver/Font.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/driver/Font.c,v
retrieving revision 1.8
diff -u -r1.8 Font.c
--- lib/driver/Font.c	3 May 2007 04:32:03 -0000	1.8
+++ lib/driver/Font.c	5 May 2007 21:43:58 -0000
@@ -24,17 +24,25 @@
 
 void COM_Font_get(const char *name)
 {
-	if (name[0] == '/')
+	if (G_is_absolute_path(name))
 	{
 		static char prefix[4096];
+		char name_copy[4096];
 
 		if (!font_exists(name))
 			return;
 
 		if (!*prefix)
+		{		
 			sprintf(prefix, "%s/fonts/", G_gisbase());
-
-		if (strncmp(name, prefix, strlen(prefix)) == 0)
+			G_convert_dirseps_from_host(prefix);
+		}	   
+	   	   
+		/* Case-insensitive comparison with all '/' dirsep chars */
+		strncpy(name_copy, name, strlen(prefix));
+		name_copy[strlen(prefix)] = '\0';
+		G_convert_dirseps_from_host(name_copy);	   
+		if (G_strcasecmp(name_copy, prefix) == 0)
 			stroke_set(name);
 		else
 			freetype_set(name);
Index: lib/driver/font2.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/lib/driver/font2.c,v
retrieving revision 1.2
diff -u -r1.2 font2.c
--- lib/driver/font2.c	5 Mar 2007 06:20:00 -0000	1.2
+++ lib/driver/font2.c	5 May 2007 21:43:58 -0000
@@ -2,6 +2,7 @@
 #include <stdlib.h>
 #include <string.h>
 #include <unistd.h>
+#include <errno.h>
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <fcntl.h>
@@ -152,7 +153,8 @@
 	fp = fopen(buf, "r");
 	if (!fp)
 	{
-		G_warning("unable to open font map '%s'", name);
+		G_warning("unable to open font map '%s': %s", buf,
+			  strerror(errno));
 		return;
 	}
 
@@ -185,13 +187,23 @@
 
 int font_init(const char *name)
 {
-	if (strchr(name, '/'))
-		name = strrchr(name, '/') + 1;
+	char name_copy[4096];
+	char *name_ptr;
 
-	if (strcmp(name, current_font) == 0)
+	strcpy(name_copy, name);
+	G_convert_dirseps_from_host(name_copy);	   
+   
+	if (strchr(name_copy, GRASS_DIRSEP))
+		name_ptr = strrchr(name_copy, GRASS_DIRSEP) + 1;
+	else
+		name_ptr = name_copy;     
+
+        G_basename(name_ptr, "hmp");
+
+	if (strcmp(name_ptr, current_font) == 0)
 		return 0;
 
-	strcpy(current_font, name);
+	strcpy(current_font, name_ptr);
 	font_loaded = 0;
 
 	return 0;
From michael.barton at asu.edu  Sun May  6 01:54:31 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sun May  6 01:54:38 2007
Subject: [GRASS-dev] access to wingrass binaries
In-Reply-To: <20070505174754.GB19710@bartok.itc.it>
Message-ID: <C2626747.21B4D%michael.barton@asu.edu>

Yes, but I wouldn't want to list Moritz' site without his permission.

Michael


On 5/5/07 10:47 AM, "Markus Neteler" <neteler@itc.it> wrote:

> On Sat, May 05, 2007 at 10:01:40AM -0700, Michael Barton wrote:
>>    Can we list Moritz' wingrass binary site on the GRASS binaries download
>>    page in addition to or instead of Huidae Cho's page? Huidae's binaries are
>>    way out of date and I understand that Moritz is doing regular binary
>>    maintenance.
> 
> The winGRASS native binaries available from
>  http://moritz.homelinux.org/grass/wingrass/
> is from end of March...
> 
> In general, all developers with write access can modify
> the web pages.
> 
> Markus
> 
> 

__________________________________________
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 paul-grass at stjohnspoint.co.uk  Sun May  6 06:05:46 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Sun May  6 06:05:49 2007
Subject: [GRASS-dev] Problem with font selection in gis.m on Windows
In-Reply-To: <C262089F.21B3E%michael.barton@asu.edu>
References: <C262089F.21B3E%michael.barton@asu.edu>
Message-ID: <Pine.LNX.4.62.0705060458460.22639@agrippa.ukshells.co.uk>

uname will generally be available if Init.sh works, but Init.sh only 
runs in Msys on Windows - true native Windows GRASS doesn't require Msys 
for running (only compiling) and won't have Unix commands like uname 
available at run-time. We have an alternative Windows batch file, 
init.bat, that can be used to start native Windows GRASS and avoids the 
need to have a shell interpreter and run Init.sh.

Usually I did platform checking in Tcl by looking for environment 
variables that were platform-specific, e.g. something like:
if {[info exists env(OS)] && $env(OS) == "Windows_NT"}
but I see in the new d.rast.edit Glynn has used some kind of Tcl variable 
which looks like an even neater way of doing it:
if {$tcl_platform(platform) == "windows"}

But I agree it's best to wait to see how the font support settles down 
before we decide how best to fix this.

On Sat, 5 May 2007, Michael Barton wrote:

> I lifted this from Init.sh, where it checks for things like Mingw and
> Cygwin, so I thought it would work with windows. If it doesn't, I guess it's
> pointless to have it in Init.sh too.
>
> As the current font selection is done, I need to know if a Mac, Windows, or
> other system is running to know where to look for fonts. If uname doesn't
> work on Windows, I don't know how to find this out.
>
> If there is no other solution, I'll try to implement an alternate kind of
> dialog, using a listbox and the new and improved freetypecap file, like I've
> done for the wxPython GUI.
>
> Michael
>
>
> On 5/4/07 9:06 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
>
>> The recent talk of fonts on this list brought me to try out some stuff on
>> Windows. I discovered there's a font selector control in gis.m (Config
>> Menu-->Set default display font) but if I click the button to try and
>> change it to anything other than Romans I get the following error:
>>
>> couldn't execute "uname": no such file or directory
>> couldn't execute "uname": no such file or directory
>>      while executing
>> "exec uname -s"
>>      (procedure "Gm::SelectFont" line 7)
>>      invoked from within
>> "Gm::SelectFont"
>>      ("uplevel" body line 1)
>>      invoked from within
>> "uplevel \#0 $cmd"
>>      (procedure "Button::_release" line 18)
>>      invoked from within
>> "Button::_release .dispfont.fontopt2.b"
>>      (command bound to event)
>>
>> Obviously trying to use the "uname" command (not available on native
>> Windows) is the bug, but looking closer at the code (line 537 onwards in
>> gui/tcltk/gis.m/gm.tcl) it seems the relevant part is trying to put
>> together directories to search for Freetype fonts in? Which
>> (a) shouldn't even be needed here as I have the stroke font radio button
>> in the dialog selected and don't even have GRASS compiled with Freetype
>> support and
>> (b) might possibly be being made redundant by Glynn's new script to
>> populate $GISBASE/etc/freetypecap?
>>
>> Not sure what's the best way to fix this, taking into account those
>> points.
>>
>> Paul
>>
>>
>
> __________________________________________
> 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 May  6 07:07:22 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun May  6 07:07:30 2007
Subject: [GRASS-dev] default vector point symbol
In-Reply-To: <20070502135436.GN27153@bartok.itc.it>
References: <20070501184522.00e9ec77.hamish_nospam@yahoo.com>
	<C25C9B9B.218A0%michael.barton@asu.edu>
	<20070503002556.0d441504.hamish_nospam@yahoo.com>
	<20070502135436.GN27153@bartok.itc.it>
Message-ID: <20070506170722.346a61c2.hamish_nospam@yahoo.com>

Markus Neteler wrote:
> On Thu, May 03, 2007 at 12:25:56AM +1200, Hamish wrote:
> > Michael Barton wrote:
> > > > In addition I have a "d.mark x y" script to put a marker on the
> > > > xmon at a given x,y, which is pretty handy, much easier than
> > > > v.in.ascii+d.vect.
> > > >  (just added to addons)
> > > > examples:
> > > >   d.mark 65,30
> > > >   d.mark -m 595968,4918693
> > > > 
> > > 
> > > This sounds real handy. Is it on the WIKI? Maybe we should add it
> > > to the main GRASS distribution.
> > 
> > It's on the wiki addons page. It's just a shortcut & doesn't add
> > anything new so I never considered adding it to the main GRASS CVS.
> > shrug.
> 
> I think that such a functionality is regularly needed. Maybe,
> it could go into d.labels as being close with 'labels' then
> optional and additional reading from stdin? On the other hand,
> we don't have too many d.* modules yet.

It already is "in" d.graph. See the example in the d.graph help page.
The guts of the script is just the 1-liner of that example- d.mark just
rearranges the options to make it a bit simpler+faster to type.
Adding it to d.labels would be an unneeded complication IMO.

I agree that the label system is a bit complicated to use, much like
ps.map is a bit complicated to use. But it works in a predictable and
repeatable way (WYSIWYWant), and it is possible to have the GUI
frontend(s) hide that complication from the user in simple tools. For
command line stuff there is little wrapper scripts like d.mark,
d.stations, and d.varea. I think they differ from other wrapper scripts
like v.centroids, v.dissolve, and r.out.xyz in that it isn't obvious
that for those last 3 that the needed functionality is burried in
v.category, v.extract, and r.stats, whereas for the former you can guess
that d.vect and d.graph should be able to do it, it's just pain to do as
there are so many options to sort past.


2c only,
Hamish

From hamish_nospam at yahoo.com  Sun May  6 07:25:45 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun May  6 07:25:55 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17980.41764.666518.270623@cerise.gclements.plus.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
Message-ID: <20070506172545.531f29b8.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> Alternatively, masking could be enabled only if the raster isn't the
> bottom-most layer (it used to always be drawn first, but presumably
> that has been changed).

AFAICT raster is still always drawn first.


Hamish

From hamish_nospam at yahoo.com  Sun May  6 07:41:30 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun May  6 07:42:05 2007
Subject: [GRASS-dev] [grass-code R][391] d.legend: option to get info
	from stdin instead of raster
In-Reply-To: <C260A5E4.21AD1%michael.barton@asu.edu>
References: <20070504062031.1AF7E1800CF5@pyrosoma.intevation.org>
	<C260A5E4.21AD1%michael.barton@asu.edu>
Message-ID: <20070506174130.7e3d37dd.hamish_nospam@yahoo.com>

http://wald.intevation.org/tracker/?func=detail&atid=188&aid=391&group_id=21
[copied from the wish ticket]


Michael Barton wrote:
> I'm overall in favor of d.legend being able to build a legend from
> such output. It would simplify matters for making thematic map and
> thematic chart legends and might even work for making vector legends.
> 
> However, the interactive format shown above wouldn't work in a
> scriptable GUI setting.

drop the -m and it uses default placement, or use "at=" --

> I'm also having trouble trying to envision how it *could* work in such
> a setting in order to make an alternative suggestion.

in the gui tool allow the user to draw a box. get the % of canvas coords
of two opposite corners and use them as "at=bottom,top,left,right".

 
> d.vect.chart [flag to send legend output to stdout] | d.legend map=-
> ????

yes, or 
  g.tempfile
  d.vect.chart -l > $TMPlegend
  d.legend map=- at=$B,$T,$L,$R < $TMPlegend

doing that in two steps with a temp file makes a bit more sense for use
within the d.vect.thematic script than the d.vect.chart example.

to survive redraw it might need to do command line replacement tricks
like d.text does. Getting it smooth will probably require a file= option
added to d.legend. But I'll wait until a stdin prototype is working and
see how that works in practice before worrying about that refinement.

FYI, this is a low priority for me right now, which is why I filed it as
a wish report, so it isn't lost.


Hamish

From michael.barton at asu.edu  Sun May  6 09:17:06 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sun May  6 09:17:15 2007
Subject: [GRASS-dev] Problem with font selection in gis.m on Windows
In-Reply-To: <Pine.LNX.4.62.0705060458460.22639@agrippa.ukshells.co.uk>
Message-ID: <C262CF02.21B55%michael.barton@asu.edu>

Thanks for the useful tips.

Michael


On 5/5/07 9:05 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

> uname will generally be available if Init.sh works, but Init.sh only
> runs in Msys on Windows - true native Windows GRASS doesn't require Msys
> for running (only compiling) and won't have Unix commands like uname
> available at run-time. We have an alternative Windows batch file,
> init.bat, that can be used to start native Windows GRASS and avoids the
> need to have a shell interpreter and run Init.sh.
> 
> Usually I did platform checking in Tcl by looking for environment
> variables that were platform-specific, e.g. something like:
> if {[info exists env(OS)] && $env(OS) == "Windows_NT"}
> but I see in the new d.rast.edit Glynn has used some kind of Tcl variable
> which looks like an even neater way of doing it:
> if {$tcl_platform(platform) == "windows"}
> 
> But I agree it's best to wait to see how the font support settles down
> before we decide how best to fix this.
> 
> On Sat, 5 May 2007, Michael Barton wrote:
> 
>> I lifted this from Init.sh, where it checks for things like Mingw and
>> Cygwin, so I thought it would work with windows. If it doesn't, I guess it's
>> pointless to have it in Init.sh too.
>> 
>> As the current font selection is done, I need to know if a Mac, Windows, or
>> other system is running to know where to look for fonts. If uname doesn't
>> work on Windows, I don't know how to find this out.
>> 
>> If there is no other solution, I'll try to implement an alternate kind of
>> dialog, using a listbox and the new and improved freetypecap file, like I've
>> done for the wxPython GUI.
>> 
>> Michael
>> 
>> 
>> On 5/4/07 9:06 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:
>> 
>>> The recent talk of fonts on this list brought me to try out some stuff on
>>> Windows. I discovered there's a font selector control in gis.m (Config
>>> Menu-->Set default display font) but if I click the button to try and
>>> change it to anything other than Romans I get the following error:
>>> 
>>> couldn't execute "uname": no such file or directory
>>> couldn't execute "uname": no such file or directory
>>>      while executing
>>> "exec uname -s"
>>>      (procedure "Gm::SelectFont" line 7)
>>>      invoked from within
>>> "Gm::SelectFont"
>>>      ("uplevel" body line 1)
>>>      invoked from within
>>> "uplevel \#0 $cmd"
>>>      (procedure "Button::_release" line 18)
>>>      invoked from within
>>> "Button::_release .dispfont.fontopt2.b"
>>>      (command bound to event)
>>> 
>>> Obviously trying to use the "uname" command (not available on native
>>> Windows) is the bug, but looking closer at the code (line 537 onwards in
>>> gui/tcltk/gis.m/gm.tcl) it seems the relevant part is trying to put
>>> together directories to search for Freetype fonts in? Which
>>> (a) shouldn't even be needed here as I have the stroke font radio button
>>> in the dialog selected and don't even have GRASS compiled with Freetype
>>> support and
>>> (b) might possibly be being made redundant by Glynn's new script to
>>> populate $GISBASE/etc/freetypecap?
>>> 
>>> Not sure what's the best way to fix this, taking into account those
>>> points.
>>> 
>>> Paul
>>> 
>>> 
>> 
>> __________________________________________
>> 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
>> 
>> 
>> 

__________________________________________
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 May  6 10:15:02 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Sun May  6 10:15:10 2007
Subject: [GRASS-dev] [bug #2793] (grass) v.segment: side offset is ignored
In-Reply-To: <20070504175449.7a682342.hamish_nospam@yahoo.com>
References: <20070501101422.93F7F1006C7@lists.intevation.de>
	<20070503215327.369698b9.hamish_nospam@yahoo.com>
	<20070503221824.311669d8.hamish_nospam@yahoo.com>
	<20070504000802.3991423c.hamish_nospam@yahoo.com>
	<20070503122406.GM26403@bartok.itc.it>
	<20070504175449.7a682342.hamish_nospam@yahoo.com>
Message-ID: <20070506201502.669c92f3.hamish_nospam@yahoo.com>

> Markus:
> > BTW: v.lrs.segment suffers from the same problem:
> > http://grass.itc.it/grass63/manuals/html63_user/v.lrs.segment.html
> > P <pid> <lid> <milepost>+<offset> [<side offset>]
> > L <sid> <lid> <milepost>+<offset> <milepost>+<offset> [<side
> > offset>]
H:
> Yes, code is mostly cloned so it would be easy to copy & paste in the
> same solution.

v.lrs.segment updated in 6.3 CVS to observe side_offset.

I also added a file= option to both v.segment and v.lrs.segment to read
the instructions from a file instead of stdin. This is so the modules
can work from the GUI menu where stdin is not available.

none of the v.lrs.segment changes have been tested, as I've never used
LRS. I'd appreciate if someone who has can test that the side_offset
and file= options work properly.


Hamish

From glynn at gclements.plus.com  Sun May  6 11:34:17 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun May  6 11:34:20 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
	<17980.41057.504876.936561@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>
Message-ID: <17981.41241.747882.668092@cerise.gclements.plus.com>


Paul Kelly wrote:
> On Sat, 5 May 2007, Glynn Clements wrote:
> 
> I've attached a diff of a few more changes I'm considering making, mostly 
> relating to path and filename handling for Windows compatibility in 
> loading fonts. Here's what I've changed so far:
> 
> lib/driver/Font.c, COM_Font_get():
> * Cross-platform check for absolute path (new gislib function added)
> * Check for pathname matching the GRASS stroke fonts made more robust by
>    (a) First converting all directory separator characters to '/'
>    (b) Doing a case-insensitive comparison

That last point is probably safe, in that you're unlikely to have
another directory which differs only in case on Unix.

Although, in this case, I'd be inclined to simply remove the option to
specify a stroke font using a full path. Personally, I doubt that this
feature would ever be used.

FWIW, the robust way to check whether two paths are equivalent is to
stat() (or lstat()) both of them, and check whether the device and
inode numbers match.

That handles all of the different ways that you can make multiple
paths refer to the same file/directory (case sensitivity, symlinks,
hard links, mount points, use of . and .., etc).

However, I don't know whether it works on Windows, i.e. whether the
device/inode numbers are meaningful.

> I haven't committed the changes yet as they're not complete. Apart from
> being unsure about stripping off the .hmp extension, specifying a
> font in GRASS_FONT from the freetypecap file doesn't work. I'm just
> testing this from the command line on Windows, i.e. using direct
> rendering as drivers don't work, and I can't see where/if the freetypecap 
> file is actually being read. Specifying the full path to a Freetype font
> works fine, but is the freetypecap file only read when a driver process
> is initialised?

parse_freetypecap() is called from LIB_init(), in lib/driver/init.c. 
For direct rendering, this is called from LOC_open_driver(); for a
standalone driver it's called from main().

Also, I'd guess that using a colon as the field separator is likely to
be problematic on Windows.

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

From glynn at gclements.plus.com  Sun May  6 11:53:49 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun May  6 11:53:57 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <20070506172545.531f29b8.hamish_nospam@yahoo.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
Message-ID: <17981.42413.865376.470245@cerise.gclements.plus.com>


Hamish wrote:

> > Alternatively, masking could be enabled only if the raster isn't the
> > bottom-most layer (it used to always be drawn first, but presumably
> > that has been changed).
> 
> AFAICT raster is still always drawn first.

In which case, there wouldn't be any point in having masked rasters.

I'm presuming that Markus tried this in conjunction with your previous
suggestion:

> easy modification (in C) for a one-off job--
> 
> in ps/ps.map/ps_map.c move this down a few lines, ie after both calls to
> do_vectors():
> 
>     /* do the raster stuff, if any */
>     if (PS.do_raster || grp.do_group) PS_raster_plot();

Obviously, that's no good for general use. AFAICT, the only real
solution would be to render things in the order in which they appear
in the input file.

But that would probably a rather significant change to the structure
of ps.map. I'm not sure that the effort would be worthwhile; it would
be better (IMHO) to work on getting better PostScript output from d.*
commands.

FWIW, what are the main advantages of ps.map over using the PS driver
and d.* commands?

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

From neteler at itc.it  Sun May  6 12:41:21 2007
From: neteler at itc.it (Markus Neteler)
Date: Sun May  6 12:41:23 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17981.42413.865376.470245@cerise.gclements.plus.com>
References: <20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
Message-ID: <20070506104120.GC9213@bartok.itc.it>

On Sun, May 06, 2007 at 10:53:49AM +0100, Glynn Clements wrote:
...
> FWIW, what are the main advantages of ps.map over using the PS driver
> and d.* commands?

Certainly I tried this as well. If I recall correctly, the
PS file size from PS driver/d.* was way bigger than the
output of ps.map. In my case I was getting hundreds of MB.

I can try again of course.

Markus

From paul-grass at stjohnspoint.co.uk  Sun May  6 13:03:48 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Sun May  6 13:03:51 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <17981.41241.747882.668092@cerise.gclements.plus.com>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
	<17980.41057.504876.936561@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>
	<17981.41241.747882.668092@cerise.gclements.plus.com>
Message-ID: <Pine.LNX.4.62.0705061156470.15764@agrippa.ukshells.co.uk>

On Sun, 6 May 2007, Glynn Clements wrote:

>> lib/driver/Font.c, COM_Font_get():
>> * Cross-platform check for absolute path (new gislib function added)
>> * Check for pathname matching the GRASS stroke fonts made more robust by
>>    (a) First converting all directory separator characters to '/'
>>    (b) Doing a case-insensitive comparison
>
> That last point is probably safe, in that you're unlikely to have
> another directory which differs only in case on Unix.
>
> Although, in this case, I'd be inclined to simply remove the option to
> specify a stroke font using a full path. Personally, I doubt that this
> feature would ever be used.

I thought it might be used in the gis.m font chooser, where it opens a 
file browse dialog in the $GISBASE/etc/fonts directory and after choosing 
puts the full path to the stroke font into the text box in the dialog 
widget. But I'm not 100% sure if it does that. Just appears to.

> FWIW, the robust way to check whether two paths are equivalent is to
> stat() (or lstat()) both of them, and check whether the device and
> inode numbers match.

Interesting; here we are comparing the directory the fonts are stored in 
rather than the font files themselves but perhaps still of use? I suppose 
I could test it on Windows.

> That handles all of the different ways that you can make multiple
> paths refer to the same file/directory (case sensitivity, symlinks,
> hard links, mount points, use of . and .., etc).
>
> However, I don't know whether it works on Windows, i.e. whether the
> device/inode numbers are meaningful.
>
[...]
>
> parse_freetypecap() is called from LIB_init(), in lib/driver/init.c.
> For direct rendering, this is called from LOC_open_driver(); for a
> standalone driver it's called from main().
>
> Also, I'd guess that using a colon as the field separator is likely to
> be problematic on Windows.

Yes, that was it. If I use a semi-colon instead all works great - maybe we 
could change mkftcap to generate a file with semi-colon separators? And 
change parse_freetypecap() to handle both for backwards compatibility? Is 
the last character on a line in freetypecap always a separator character? 
If so that would be a quick way to check. Or could scan the first line and 
whichever appeared first between : and ; use that as the separator?

It seems we're nearly there.

From glynn at gclements.plus.com  Sun May  6 17:03:27 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun May  6 17:03:30 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <20070506104120.GC9213@bartok.itc.it>
References: <20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070506104120.GC9213@bartok.itc.it>
Message-ID: <17981.60991.491700.577371@cerise.gclements.plus.com>


Markus Neteler wrote:

> > FWIW, what are the main advantages of ps.map over using the PS driver
> > and d.* commands?
> 
> Certainly I tried this as well. If I recall correctly, the
> PS file size from PS driver/d.* was way bigger than the
> output of ps.map. In my case I was getting hundreds of MB.
> 
> I can try again of course.

I'd suggest looking at which parts of the output are taking up all of
the space. If it's the raster, that suggests that the two attempts
were using different resolutions. If it's the vectors, different
render= options might help (for filled areas, the default render=g
setting will produce excessively large output and worse quality).

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

From glynn at gclements.plus.com  Sun May  6 17:20:56 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun May  6 17:20:59 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <Pine.LNX.4.62.0705061156470.15764@agrippa.ukshells.co.uk>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
	<17980.41057.504876.936561@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>
	<17981.41241.747882.668092@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705061156470.15764@agrippa.ukshells.co.uk>
Message-ID: <17981.62040.196624.166998@cerise.gclements.plus.com>


Paul Kelly wrote:

> > FWIW, the robust way to check whether two paths are equivalent is to
> > stat() (or lstat()) both of them, and check whether the device and
> > inode numbers match.
> 
> Interesting; here we are comparing the directory the fonts are stored in 
> rather than the font files themselves but perhaps still of use?

Yes; in the case of COM_Font_get(), you would need to remove the last
part of the path and check whether the directory part refers to the
same device/inode as $GISBASE/fonts.

> > That handles all of the different ways that you can make multiple
> > paths refer to the same file/directory (case sensitivity, symlinks,
> > hard links, mount points, use of . and .., etc).
> >
> > However, I don't know whether it works on Windows, i.e. whether the
> > device/inode numbers are meaningful.
> >
> [...]
> >
> > parse_freetypecap() is called from LIB_init(), in lib/driver/init.c.
> > For direct rendering, this is called from LOC_open_driver(); for a
> > standalone driver it's called from main().
> >
> > Also, I'd guess that using a colon as the field separator is likely to
> > be problematic on Windows.
> 
> Yes, that was it. If I use a semi-colon instead all works great - maybe we 
> could change mkftcap to generate a file with semi-colon separators? And 
> change parse_freetypecap() to handle both for backwards compatibility? Is 
> the last character on a line in freetypecap always a separator character? 
> If so that would be a quick way to check. Or could scan the first line and 
> whichever appeared first between : and ; use that as the separator?

If it's going to be changed, one option is to use a vertical bar
(which isn't a legal filename character on Windows), and make the face
index a separate column.

That would eliminate the possibility of using a non-zero index when
specifying a font by a pathname, but that's problematic for other
reasons (e.g. gisprompt = "old_file,..." should probably check for
file existence, which would rule out the option of using something
which is "almost" a filename).

AFAIK, the trailing separator is an artifact of the time that style
information (colour, size) was included in the freetypecap file.

BTW, the encoding field isn't used either (d.font.freetype and
d.text.freetype used it, but the driver doesn't).

Note that d.font has code which parses the freetypecap file in order
to generate the option list for font=, and to implement the -l switch,
so that will need to be updated if the format changes.

d.font.freetype and d.text.freetype have similar code, but they no
longer need to be maintained; they have been replaced by scripts which
call d.font and d.text (which is actually d.text.new) respectively.

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

From michael.barton at asu.edu  Sun May  6 22:31:56 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Sun May  6 22:32:06 2007
Subject: [GRASS-dev] how to check for system in TclTk
In-Reply-To: <Pine.LNX.4.62.0705060458460.22639@agrippa.ukshells.co.uk>
Message-ID: <C263894C.21B61%michael.barton@asu.edu>

Glynn,

Paul Kelly sent me this great-sounding tip as a way to get system
information without invoking the Unix command uname, which is unavailable
under windows.

The only problem is that I get an error...

can't read "tcl_platform(platform)": no such variable

...whenever I try to invoke it in a TclTk script. Even odder, if I invoke it
from a wish command line, it is fine (though it report unix on my Mac
because I'm using x11).

Is there some secret trick to using this? It is not apparent in the TclTk
docs that I'm reading.

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


------ Forwarded Message
> From: Paul Kelly <paul-grass@stjohnspoint.co.uk>
> Date: Sun, 6 May 2007 05:05:46 +0100 (BST)
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-dev@grass.itc.it>
> Subject: Re: [GRASS-dev] Problem with font selection in gis.m on Windows
> 
> Usually I did platform checking in Tcl by looking for environment
> variables that were platform-specific, e.g. something like:
> if {[info exists env(OS)] && $env(OS) == "Windows_NT"}
> but I see in the new d.rast.edit Glynn has used some kind of Tcl variable
> which looks like an even neater way of doing it:
> if {$tcl_platform(platform) == "windows"}

------ End of Forwarded Message

From glynn at gclements.plus.com  Sun May  6 23:09:16 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Sun May  6 23:09:22 2007
Subject: [GRASS-dev] Re: how to check for system in TclTk
In-Reply-To: <C263894C.21B61%michael.barton@asu.edu>
References: <Pine.LNX.4.62.0705060458460.22639@agrippa.ukshells.co.uk>
	<C263894C.21B61%michael.barton@asu.edu>
Message-ID: <17982.17404.431300.581626@cerise.gclements.plus.com>


Michael Barton wrote:

> Paul Kelly sent me this great-sounding tip as a way to get system
> information without invoking the Unix command uname, which is unavailable
> under windows.
> 
> The only problem is that I get an error...
> 
> can't read "tcl_platform(platform)": no such variable
> 
> ...whenever I try to invoke it in a TclTk script. Even odder, if I invoke it
> from a wish command line, it is fine (though it report unix on my Mac
> because I'm using x11).
> 
> Is there some secret trick to using this? It is not apparent in the TclTk
> docs that I'm reading.

Are you using it from within a procedure? If so, you need to use
"global tcl_platform", as with any other global variable.

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

From mlennert at club.worldonline.be  Mon May  7 00:25:31 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon May  7 00:22:17 2007
Subject: [GRASS-dev] compiling error for r.le.setup in Windows: sleep not
	implemented
Message-ID: <3725.85.10.117.251.1178490331.squirrel@geog-pc40.ulb.ac.be>

r.le.setup won't compile on Windows because of the use of sleep. We could
replace it by G_sleep to make it compile, but at the moment, this is just
an empty token for Windows. Is sleep essential for r.le.setup ? How
difficult is implementing a windows version of sleep ?

OBJ.i686-pc-mingw32/ask_group.o: In function
`get_group_drv':c:/grasssrc/grass6/raster/r.le/r.le.setup/ask_group.c:100:
undefined reference to `sleep'
:c:/grasssrc/grass6/raster/r.le/r.le.setup/ask_group.c:106: undefined
reference to `sleep'
:c:/grasssrc/grass6/raster/r.le/r.le.setup/ask_group.c:112: undefined
reference to `sleep'
:c:/grasssrc/grass6/raster/r.le/r.le.setup/ask_group.c:118: undefined
reference to `sleep'
:c:/grasssrc/grass6/raster/r.le/r.le.setup/ask_group.c:124: undefined
reference to `sleep'
OBJ.i686-pc-mingw32/ask_group.o:c:/grasssrc/grass6/raster/r.le/r.le.setup/ask_group.c:130:
more undefined references to `sleep' follow
collect2: ld returned 1 exit status
make: *** [/c/grasssrc/grass6/dist.i686-pc-mingw32/bin/r.le.setup.exe]
Error 1

Moritz

From mlennert at club.worldonline.be  Mon May  7 01:03:47 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon May  7 01:00:40 2007
Subject: [GRASS-dev] access to wingrass binaries
In-Reply-To: <C2626747.21B4D%michael.barton@asu.edu>
References: <C2626747.21B4D%michael.barton@asu.edu>
Message-ID: <1878.85.10.117.251.1178492627.squirrel@geog-pc40.ulb.ac.be>

On Sun, May 6, 2007 01:54, Michael Barton wrote:
> Yes, but I wouldn't want to list Moritz' site without his permission.

I herewith give my permission.


> On 5/5/07 10:47 AM, "Markus Neteler" <neteler@itc.it> wrote:
>
>> On Sat, May 05, 2007 at 10:01:40AM -0700, Michael Barton wrote:
>>>    Can we list Moritz' wingrass binary site on the GRASS binaries
>>> download
>>>    page in addition to or instead of Huidae Cho's page?

done (in replacement Huidae's page)


>>
>> The winGRASS native binaries available from
>>  http://moritz.homelinux.org/grass/wingrass/
>> is from end of March...


Yes, sorry, I haven't kept up with my promise...
I just uploaded a new version.

Any feedback on whether this "package" works as it should / as expected by
users is more than welcome.

I also imagine that if we want to make this more official, we need to add
licensing information, including for all the binaries that come from
Paul's package of dependencies. I added a short note at the end of the
readme, but this is surely insufficient. At least we should give the
respective web links. Paul, could you give me the list ? Also, should
these libraries maybe be updated to their latest versions ?

Moritz

From paul-grass at stjohnspoint.co.uk  Mon May  7 02:15:11 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Mon May  7 02:15:16 2007
Subject: [GRASS-dev] access to wingrass binaries
In-Reply-To: <1878.85.10.117.251.1178492627.squirrel@geog-pc40.ulb.ac.be>
References: <C2626747.21B4D%michael.barton@asu.edu>
	<1878.85.10.117.251.1178492627.squirrel@geog-pc40.ulb.ac.be>
Message-ID: <Pine.LNX.4.62.0705070110360.30014@agrippa.ukshells.co.uk>

Hello Moritz

On Mon, 7 May 2007, Moritz Lennert wrote:

> Any feedback on whether this "package" works as it should / as expected by
> users is more than welcome.

I haven't tried this one but did give the last one a try and it seemed to 
work OK. I just tried command-line usage (grass63 -text) as the computer I 
was using it on didn't have Tcl/TK installed. I think we should be able to 
include Tcl and Tk libraries in the binary distribution too actually, to 
reduce compatibility issues and make it *really* easy to install.

> I also imagine that if we want to make this more official, we need to add
> licensing information, including for all the binaries that come from
> Paul's package of dependencies. I added a short note at the end of the
> readme, but this is surely insufficient. At least we should give the
> respective web links. Paul, could you give me the list ? Also, should
> these libraries maybe be updated to their latest versions ?

Funnily enough I was just working on that yesterday. I've put an updated 
version of wingrass-extralibs.tar.gz up on www.stjohnspoint.co.uk/grass 
now. There you will also find build instructions with weblinks. Most of it 
is public domain or BSD-style licensed I think; perhaps one or two 
packages are GPL. This time the XDR library is compiled statically to work 
around the problems we had with database connections. Also FFTW and 
Freetype libraries are included for the first time. Things still aren't 
perfect (i.e. compiling is not as straightforward as it should be) but it 
all seems to work.

Paul

From hamish_nospam at yahoo.com  Mon May  7 02:52:05 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon May  7 02:56:03 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17981.42413.865376.470245@cerise.gclements.plus.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
Message-ID: <20070507125205.41fe339b.hamish_nospam@yahoo.com>

Glynn Clements wrote:
> it would be better (IMHO) to work on getting better PostScript output
> from d.* commands.

I think it would be really nice to have the PS driver better, but we are
nowhere near (yet) having something that rivals ps.map's output quality.
(ie I haven't given up on ps.map)

> FWIW, what are the main advantages of ps.map over using the PS driver
> and d.* commands?

I think there are a few, mainly related to ps.map already tuned to the
problem of hardcopy output. The PS driver would need a hardcopy-wizard
wrapper GUI, at least to help with the presets.

But one specific issue when I tried the PS driver with d.vect.chart was
rendering method of filled areas being drawn as a series of horizontal
lines instead of a solid area. Filled vector areas were fine.

Another issue I noticed was lack of page margins in the final PS file.


Hamish

From hamish_nospam at yahoo.com  Mon May  7 03:19:59 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon May  7 03:31:50 2007
Subject: [GRASS-dev] compiling error for r.le.setup in Windows: sleep
	not	implemented
In-Reply-To: <3725.85.10.117.251.1178490331.squirrel@geog-pc40.ulb.ac.be>
References: <3725.85.10.117.251.1178490331.squirrel@geog-pc40.ulb.ac.be>
Message-ID: <20070507131959.54a08702.hamish_nospam@yahoo.com>

Moritz Lennert wrote:
> r.le.setup won't compile on Windows because of the use of sleep. We
> could replace it by G_sleep to make it compile,

done in CVS HEAD.

> but at the moment, this is just an empty token for Windows. Is sleep
> essential for r.le.setup ?

sleep is used in r.le.setup to give you a chance to read the result of a
command before the screen (text menu) is cleared to make way for the
next menu.

> How difficult is implementing a windows version of sleep ?

no idea, but having a fn which the programmer intends to do something
but it fails to do, isn't so nice.


Hamish

From michael.barton at asu.edu  Mon May  7 06:24:14 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon May  7 06:24:24 2007
Subject: [GRASS-dev] Re: how to check for system in TclTk
In-Reply-To: <17982.17404.431300.581626@cerise.gclements.plus.com>
Message-ID: <C263F7FE.21B73%michael.barton@asu.edu>

I've fixed this in the CVS, so that setting the default font should work
with Windows now.

Michael


On 5/6/07 2:09 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Michael Barton wrote:
> 
>> Paul Kelly sent me this great-sounding tip as a way to get system
>> information without invoking the Unix command uname, which is unavailable
>> under windows.
>> 
>> The only problem is that I get an error...
>> 
>> can't read "tcl_platform(platform)": no such variable
>> 
>> ...whenever I try to invoke it in a TclTk script. Even odder, if I invoke it
>> from a wish command line, it is fine (though it report unix on my Mac
>> because I'm using x11).
>> 
>> Is there some secret trick to using this? It is not apparent in the TclTk
>> docs that I'm reading.
> 
> Are you using it from within a procedure? If so, you need to use
> "global tcl_platform", as with any other global variable.

__________________________________________
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 benjamin.ducke at ufg.uni-kiel.de  Mon May  7 10:02:38 2007
From: benjamin.ducke at ufg.uni-kiel.de (Benjamin Ducke)
Date: Mon May  7 09:47:08 2007
Subject: [GRASS-dev] access to wingrass binaries
In-Reply-To: <Pine.LNX.4.62.0705070110360.30014@agrippa.ukshells.co.uk>
References: <C2626747.21B4D%michael.barton@asu.edu>	<1878.85.10.117.251.1178492627.squirrel@geog-pc40.ulb.ac.be>
	<Pine.LNX.4.62.0705070110360.30014@agrippa.ukshells.co.uk>
Message-ID: <463EDD1E.8030500@ufg.uni-kiel.de>

How does this compare to the binaries currently shipped with QGIS?
Since these are also a MINGW/MSYS build, it should be possible to
put together a distribution including QGIS and GRASS with Tcl/Tk
support, yes?

This would be wonderful, as we could cover all levels of user
skills/habits, from GUI to command line and have a complete GRASS
running on all major platforms.

Benjamin

Paul Kelly wrote:
> Hello Moritz
> 
> On Mon, 7 May 2007, Moritz Lennert wrote:
> 
>> Any feedback on whether this "package" works as it should / as
>> expected by
>> users is more than welcome.
> 
> I haven't tried this one but did give the last one a try and it seemed
> to work OK. I just tried command-line usage (grass63 -text) as the
> computer I was using it on didn't have Tcl/TK installed. I think we
> should be able to include Tcl and Tk libraries in the binary
> distribution too actually, to reduce compatibility issues and make it
> *really* easy to install.
> 
>> I also imagine that if we want to make this more official, we need to add
>> licensing information, including for all the binaries that come from
>> Paul's package of dependencies. I added a short note at the end of the
>> readme, but this is surely insufficient. At least we should give the
>> respective web links. Paul, could you give me the list ? Also, should
>> these libraries maybe be updated to their latest versions ?
> 
> Funnily enough I was just working on that yesterday. I've put an updated
> version of wingrass-extralibs.tar.gz up on www.stjohnspoint.co.uk/grass
> now. There you will also find build instructions with weblinks. Most of
> it is public domain or BSD-style licensed I think; perhaps one or two
> packages are GPL. This time the XDR library is compiled statically to
> work around the problems we had with database connections. Also FFTW and
> Freetype libraries are included for the first time. Things still aren't
> perfect (i.e. compiling is not as straightforward as it should be) but
> it all seems to work.
> 
> Paul
> 
> _______________________________________________
> 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 glynn at gclements.plus.com  Mon May  7 11:09:57 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 11:10:02 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <20070507125205.41fe339b.hamish_nospam@yahoo.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070507125205.41fe339b.hamish_nospam@yahoo.com>
Message-ID: <17982.60645.690053.919208@cerise.gclements.plus.com>


Hamish wrote:

> > it would be better (IMHO) to work on getting better PostScript output
> > from d.* commands.
> 
> I think it would be really nice to have the PS driver better, but we are
> nowhere near (yet) having something that rivals ps.map's output quality.
> (ie I haven't given up on ps.map)
> 
> > FWIW, what are the main advantages of ps.map over using the PS driver
> > and d.* commands?
> 
> I think there are a few, mainly related to ps.map already tuned to the
> problem of hardcopy output. The PS driver would need a hardcopy-wizard
> wrapper GUI, at least to help with the presets.
> 
> But one specific issue when I tried the PS driver with d.vect.chart was
> rendering method of filled areas being drawn as a series of horizontal
> lines instead of a solid area. Filled vector areas were fine.

That's an inevitable problem with using G_plot_polygon(), which does
its own rasterisation. This cannot be made to work with non-raster
drivers such as PS and HTMLMAP.

Nothing should ever use G_plot_polygon() in conjuction with the R_* or
D_* functions; it's only legitimate use is for modules which *need* to
perform their own rasterising, e.g. v.to.rast or r.in.poly.

Of the modules which currently use it:

 display/d.mapgraph/OBJ.i686-pc-linux-gnu/do_graph.o | G_plot_polygon
 display/d.vect/OBJ.i686-pc-linux-gnu/plot1.o        | G_plot_polygon
 display/d.vect.chart/OBJ.i686-pc-linux-gnu/bar.o    | G_plot_polygon
 display/d.vect.chart/OBJ.i686-pc-linux-gnu/pie.o    | G_plot_polygon
 display/d.what.vect/OBJ.i686-pc-linux-gnu/flash.o   | G_plot_polygon
 raster/r.in.poly/OBJ.i686-pc-linux-gnu/poly2rast.o  | G_plot_polygon
 vector/v.to.rast/OBJ.i686-pc-linux-gnu/do_areas.o   | G_plot_polygon

The last two are legitimate, the others aren't (at least d.vect
provides the render= option; unless there are specific objections I
intend to change the default from g to l).

> Another issue I noticed was lack of page margins in the final PS file.

That isn't hard to change; the main issue is deciding how to feed the
various parameters to the driver, preferably without adding a dozen
new environment variables. OTOH, it isn't hard to change externally,
using e.g. psutils.

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

From glynn at gclements.plus.com  Mon May  7 11:19:20 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 11:19:25 2007
Subject: [GRASS-dev] compiling error for r.le.setup in Windows: sleep
	not	implemented
In-Reply-To: <20070507131959.54a08702.hamish_nospam@yahoo.com>
References: <3725.85.10.117.251.1178490331.squirrel@geog-pc40.ulb.ac.be>
	<20070507131959.54a08702.hamish_nospam@yahoo.com>
Message-ID: <17982.61208.884622.247114@cerise.gclements.plus.com>


Hamish wrote:

> > How difficult is implementing a windows version of sleep ?
> 
> no idea, but having a fn which the programmer intends to do something
> but it fails to do, isn't so nice.

Does _sleep() work? It's declared in MinGW's stdlib.h, with a note
that it's deprecated in favour of Sleep() (from Kernel32.dll).

Otherwise, you could busy-wait on time(); it's less than ideal, but
should work.

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

From neteler at itc.it  Mon May  7 11:46:14 2007
From: neteler at itc.it (Markus Neteler)
Date: Mon May  7 11:46:15 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <20070507125205.41fe339b.hamish_nospam@yahoo.com>
References: <46321E13.6070204@itc.it>	<17970.28635.172625.944822@cerise.gclements.plus.com>	<4635961C.406@itc.it>	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>	<20070430075832.GA30195@bartok.itc.it>
	<4635A574.4090800@itc.it>	<17973.47593.760354.352347@cerise.gclements.plus.com>	<20070502090554.GC27153@bartok.itc.it>	<17976.35182.363572.196185@cerise.gclements.plus.com>	<20070505142900.GA14720@bartok.itc.it>	<17980.41764.666518.270623@cerise.gclements.plus.com>	<20070506172545.531f29b8.hamish_nospam@yahoo.com>	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070507125205.41fe339b.hamish_nospam@yahoo.com>
Message-ID: <463EF566.8020906@itc.it>

Hamish wrote on 05/07/2007 02:52 AM:
> Glynn Clements wrote:
>   
>> FWIW, what are the main advantages of ps.map over using the PS driver
>> and d.* commands?
>>     
>
> I think there are a few, mainly related to ps.map already tuned to the
> problem of hardcopy output. The PS driver would need a hardcopy-wizard
> wrapper GUI, at least to help with the presets.
>   
One advantage of ps.map is that I can easily define the paper size.
AFAIK that's not
yet possible with the PS/d.* approach.

Markus


------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

From neteler at itc.it  Mon May  7 11:51:56 2007
From: neteler at itc.it (Markus Neteler)
Date: Mon May  7 11:57:00 2007
Subject: [GRASS-dev] access to wingrass binaries
In-Reply-To: <463EDD1E.8030500@ufg.uni-kiel.de>
References: <C2626747.21B4D%michael.barton@asu.edu>	<1878.85.10.117.251.1178492627.squirrel@geog-pc40.ulb.ac.be>	<Pine.LNX.4.62.0705070110360.30014@agrippa.ukshells.co.uk>
	<463EDD1E.8030500@ufg.uni-kiel.de>
Message-ID: <463EF6BC.9030203@itc.it>

Benjamin Ducke wrote on 05/07/2007 10:02 AM:
> How does this compare to the binaries currently shipped with QGIS?
> Since these are also a MINGW/MSYS build, it should be possible to
> put together a distribution including QGIS and GRASS with Tcl/Tk
> support, yes?
>   
At this point we don't really know which version is used by the QGIS
packagers.
>From the blog it isn't clear:
  http://blog.qgis.org/?q=node/56
nor from the testbuilds directory:
  http://qgis.org/uploadfiles/testbuilds/

Tim, you could please document this?

thanks,
Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

From hamish_nospam at yahoo.com  Mon May  7 12:47:43 2007
From: hamish_nospam at yahoo.com (Hamish)
Date: Mon May  7 12:47:56 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17982.60645.690053.919208@cerise.gclements.plus.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070507125205.41fe339b.hamish_nospam@yahoo.com>
	<17982.60645.690053.919208@cerise.gclements.plus.com>
Message-ID: <20070507224743.051bee33.hamish_nospam@yahoo.com>

> Hamish wrote:
> > But one specific issue when I tried the PS driver with d.vect.chart
> > was rendering method of filled areas being drawn as a series of
> > horizontal lines instead of a solid area. Filled vector areas were
> > fine.

[trying the PS driver with d.vect.chart as there is no equivalent ps.map
functionality for this module (n.b. but there is for bubble plots)]

Glynn:
> That's an inevitable problem with using G_plot_polygon(), which does
> its own rasterisation. This cannot be made to work with non-raster
> drivers such as PS and HTMLMAP.
> 
> Nothing should ever use G_plot_polygon() in conjuction with the R_* or
> D_* functions; it's only legitimate use is for modules which *need* to
> perform their own rasterising, e.g. v.to.rast or r.in.poly.

ok. there's nothing in the fn's Doxygen comments about that.
(lib/gis/plot.c)

> Of the modules which currently use it:
> 
>  display/d.mapgraph/OBJ.i686-pc-linux-gnu/do_graph.o | G_plot_polygon

from the d.mapgraph help page:
"This module is superseded and scheduled for demolition. 
Please use 'd.graph -m' instead."

I think we can now safely deactivate the module in the Makefile and
replace it with a something that calls "d.graph -m", ala recent
d.text.freetype. If a script it needs to pass through any input from
stdin. AFAIAC the module is abandonware at this point.

The equivalent section of d.graph uses R_polygon_abs().


>  display/d.vect.chart/OBJ.i686-pc-linux-gnu/bar.o    | G_plot_polygon
>  display/d.vect.chart/OBJ.i686-pc-linux-gnu/pie.o    | G_plot_polygon

is R_polygon_abs() an easy drop-in replacement here?


>  display/d.what.vect/OBJ.i686-pc-linux-gnu/flash.o   | G_plot_polygon

again, R_polygon_abs()? (flashheart strikes again)


Hamish

From glynn at gclements.plus.com  Mon May  7 13:44:14 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 13:44:16 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <20070507224743.051bee33.hamish_nospam@yahoo.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070507125205.41fe339b.hamish_nospam@yahoo.com>
	<17982.60645.690053.919208@cerise.gclements.plus.com>
	<20070507224743.051bee33.hamish_nospam@yahoo.com>
Message-ID: <17983.4366.205454.425649@cerise.gclements.plus.com>


Hamish wrote:

> >  display/d.vect.chart/OBJ.i686-pc-linux-gnu/bar.o    | G_plot_polygon
> >  display/d.vect.chart/OBJ.i686-pc-linux-gnu/pie.o    | G_plot_polygon
> 
> is R_polygon_abs() an easy drop-in replacement here?

Use D_polygon().

[Or possibly D_polygon_cull() or D_polygon_clip() if a lot of the
output is likely to lie outside the frame. Clipping to the current
frame will always get performed somewhere, but the _clip/_cull
versions do it earlier, which can provide a performance gain if most
of the data lies outside of the frame. OTOH, if most of the data lies
within the frame, the _clip/_cull versions will probably be slower.]

R_polygon_abs() takes integer coordinates in the monitor's base
coordinate system, while D_polygon() etc take floating-point
coordinates in the coordinate system established by D_do_conversions()
etc (typically, the current region is mapped to the bounds of the
current frame).

G_plot_polygon() performs the same coordinate translations as the D_*
functions, so the D_* versions are a better match.

[I suspect that this is why some modules use G_plot_polygon() for
display. lib/display/draw2.c is a recent addition; previously, if you
wanted to use geographic coordinates or honour display frames, you had
to do the work yourself.]

> >  display/d.what.vect/OBJ.i686-pc-linux-gnu/flash.o   | G_plot_polygon
> 
> again, R_polygon_abs()? (flashheart strikes again)

D_polygon() etc.

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

From paul-grass at stjohnspoint.co.uk  Mon May  7 14:02:56 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Mon May  7 14:03:01 2007
Subject: [GRASS-dev] font path question for Linux and Windows
In-Reply-To: <Pine.LNX.4.62.0705041132590.13625@agrippa.ukshells.co.uk>
References: <17973.6027.501488.6826@cerise.gclements.plus.com>
	<C25A7ABA.2175A%michael.barton@asu.edu>
	<17973.14328.976484.737490@cerise.gclements.plus.com>
	<45498D53-739B-4CF9-83B5-AFC2ADE6935C@kyngchaos.com>
	<17973.43565.792862.529314@cerise.gclements.plus.com>
	<C3D9289B-E502-469C-8E9D-80CC7EF871DF@kyngchaos.com>
	<17974.14679.620262.783465@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705040503540.8987@agrippa.ukshells.co.uk>
	<77EBAF8C-D7FF-45B6-A34B-6F2BB6FBFD6A@kyngchaos.com>
	<17978.49257.54158.338385@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705041132590.13625@agrippa.ukshells.co.uk>
Message-ID: <Pine.LNX.4.62.0705071301590.10974@agrippa.ukshells.co.uk>

On Fri, 4 May 2007, Paul Kelly wrote:

> On Fri, 4 May 2007, Glynn Clements wrote:
>
>> William Kyngesburye wrote:
>> 
>>> It's already been discussed (r.in.wms problem) that /I is a GNU
>>> extension to sed.  OSX, at least, is BSD.  Don't know what to say
>>> otherwise...
>> 
>> An alternative is to change -iname to -name, and include both upper-
>> and lower-case versions of the extension in exts.
>
> OK, that works (see patch below). The font names are a bit cryptic though, as 
> they all seem to be constrained to the 8 character limit, but I suppose that 
> isn't so important.

I've committed this patch to CVS (with a slight change to include the new 
extensions that Michael added).

>
> Index: mkftcap
> ===================================================================
> RCS file: /home/grass/grassrepository/grass6/tools/mkftcap/mkftcap,v
> retrieving revision 1.6
> diff -u -r1.6 mkftcap
> --- mkftcap     3 May 2007 04:25:17 -0000       1.6
> +++ mkftcap     4 May 2007 10:26:51 -0000
> @@ -1,6 +1,6 @@
> #!/bin/sh
>
> -exts='ttf pfa pfb'
> +exts='ttf TTF pfa PFA pfb PFB'
>
> (
>     for dir in /usr/lib/X11/fonts /usr/share/X11/fonts /usr/share/fonts \
> @@ -10,7 +10,7 @@
>     do
>         if [ -d "$dir" ] ; then
>             for ext in $exts ; do
> -                find "$dir" -type f -iname '*.'"$ext" -print \
> +                find "$dir" -type f -name '*.'"$ext" -print \
>                     | sed 's!^\(.*\)/\(.*\)$!\2:\1/\2:utf-8:!' \
>                     | sed 's/\.'"$ext"':/:/'
>             done
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass-dev
>

From glynn at gclements.plus.com  Mon May  7 14:10:33 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 14:10:35 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <463EF566.8020906@itc.it>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070507125205.41fe339b.hamish_nospam@yahoo.com>
	<463EF566.8020906@itc.it>
Message-ID: <17983.5945.696271.788491@cerise.gclements.plus.com>


Markus Neteler wrote:

> >> FWIW, what are the main advantages of ps.map over using the PS driver
> >> and d.* commands?
> >>     
> >
> > I think there are a few, mainly related to ps.map already tuned to the
> > problem of hardcopy output. The PS driver would need a hardcopy-wizard
> > wrapper GUI, at least to help with the presets.
> 
> One advantage of ps.map is that I can easily define the paper size.
> AFAIK that's not
> yet possible with the PS/d.* approach.

The size of the output is determined by GRASS_WIDTH and GRASS_HEIGHT,
which are interpreted in points. Setting:

	GRASS_WIDTH=595 GRASS_HEIGHT=842

should give an A4 page.

Margins aren't implemented explicitly, although using d.frame is an
option; e.g.:

	d.frame at=8.55,91.45,6.05,93.95

will give 0.5" left/right margins and 1.0" top/bottom margins (those
are the settings from ps/ps.map/paper.h).

One drawback of frames is that the frame's border cannot currently be
disabled (the border is drawn by D_show_window(), which is called from
several places in lib/display/window.c). Also, not all modules respect
frames.

It would be fairly straightforward to copy paper.h into the PS driver,
and allow e.g. GRASS_PAPER=a4 to override GRASS_{WIDTH,HEIGHT}, as
well as adding margins. Supporting rotation (i.e. landscape) would
also be straightforward.

I'll come up with a draft implementation today.

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

From paul-grass at stjohnspoint.co.uk  Mon May  7 14:13:27 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Mon May  7 14:13:30 2007
Subject: [GRASS-dev] Re: how to check for system in TclTk
In-Reply-To: <C263F7FE.21B73%michael.barton@asu.edu>
References: <C263F7FE.21B73%michael.barton@asu.edu>
Message-ID: <Pine.LNX.4.62.0705071307020.10974@agrippa.ukshells.co.uk>

On Sun, 6 May 2007, Michael Barton wrote:

> I've fixed this in the CVS, so that setting the default font should work
> with Windows now.

OK thanks I made a few more changes and now it is working quite well. Most 
notably that the
global env, tcl_platform
syntax didn't work (env(GISBASE) was an unknown variable) and I had to 
change it to:
global env
global tcl_platform
(which is what the Tcl documentation suggests anyway; ISTR coming across 
this before but it seemed to be OK then. Not too sure.)

The other noteworthy change was using the Native Tk file browser widget 
::tk::dialog::file:: instead of the native Windows one that tk_getOpenFile 
uses. The native Windows one was very slow and clunky and most 
importantly didn't work for selecting fonts from the Windows fonts 
directory. Clicking on a file didn't put it into the selection box and 
double-clicking opened a Window displaying the font's capabilities. The 
native Tk widget admittedly has a distinct early-90s look to it but it is 
fast and (most importantly) works.

Paul

From paul-grass at stjohnspoint.co.uk  Mon May  7 15:43:00 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Mon May  7 15:43:02 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <17981.62040.196624.166998@cerise.gclements.plus.com>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
	<17980.41057.504876.936561@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>
	<17981.41241.747882.668092@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705061156470.15764@agrippa.ukshells.co.uk>
	<17981.62040.196624.166998@cerise.gclements.plus.com>
Message-ID: <Pine.LNX.4.62.0705071358340.10974@agrippa.ukshells.co.uk>

On Sun, 6 May 2007, Glynn Clements wrote:

>
> Paul Kelly wrote:
>
>>> FWIW, the robust way to check whether two paths are equivalent is to
>>> stat() (or lstat()) both of them, and check whether the device and
>>> inode numbers match.
>>
>> Interesting; here we are comparing the directory the fonts are stored in
>> rather than the font files themselves but perhaps still of use?
>
> Yes; in the case of COM_Font_get(), you would need to remove the last
> part of the path and check whether the directory part refers to the
> same device/inode as $GISBASE/fonts.

OK well it doesn't work on Windows anyway. The device number corresponds 
to the drive letter but it appears the inode number is always 0. So I 
suppose we can just keep the string comparison of the directory names. Or 
remove the option of specifying the full path to a GRASS stroke font - I 
generally feel unhappy with the idea of removing functionality but maybe 
it is the best option here?

>>> Also, I'd guess that using a colon as the field separator is likely to
>>> be problematic on Windows.
>>
>> Yes, that was it. If I use a semi-colon instead all works great - maybe we
>> could change mkftcap to generate a file with semi-colon separators? And
>> change parse_freetypecap() to handle both for backwards compatibility? Is
>> the last character on a line in freetypecap always a separator character?
>> If so that would be a quick way to check. Or could scan the first line and
>> whichever appeared first between : and ; use that as the separator?
>
> If it's going to be changed, one option is to use a vertical bar
> (which isn't a legal filename character on Windows), and make the face
> index a separate column.

I can't see an easy way though of keeping old freetypecap files compatible 
with the current reading code that way though - just recognising an 
alternative separator character doesn't seem to be too disruptive (apart 
from adding extra code and requiring it to be kept there for ever.)

> That would eliminate the possibility of using a non-zero index when
> specifying a font by a pathname, but that's problematic for other

Yes but that's quite neat and an easy and simple way of specifying a 
non-zero index if you need to, I thought.

> reasons (e.g. gisprompt = "old_file,..." should probably check for
> file existence, which would rule out the option of using something
> which is "almost" a filename).

Yes if the font was being specified through a module like d.font - I 
suppose an extra parameter could be added to specify the index. But when 
the font is just being read from an environment variable then it's more 
complicated and anyway the parser isn't going to be involved here so as 
far as I can see the check for file existence needs to be done manually 
anyway as it currently is.

> AFAIK, the trailing separator is an artifact of the time that style
> information (colour, size) was included in the freetypecap file.
>
> BTW, the encoding field isn't used either (d.font.freetype and
> d.text.freetype used it, but the driver doesn't).
>
> Note that d.font has code which parses the freetypecap file in order
> to generate the option list for font=, and to implement the -l switch,
> so that will need to be updated if the format changes.
>
> d.font.freetype and d.text.freetype have similar code, but they no
> longer need to be maintained; they have been replaced by scripts which
> call d.font and d.text (which is actually d.text.new) respectively.

OK. Well here is my current proposal, which can be easily added to both 
d.font and libdriver: dynamically generate the format conversion string 
(containing either a : or ; as separator) based on the relative position 
of : and ; characters in the first line of the file that contains either 
of them.
The code looks like below; it is complicated but I can't see how to make 
it simpler without losing backwards compatibility. I'm not quite happy 
enough with it to commit it yet. It can be easily included in both d.font 
and libdriver as-is, though.

char format[16] = "";

while(fgets(buf, sizeof(buf), fp) && !feof(fp))
{
 	char *p;

 	p = strchr(buf, '#');
 	if(p)
 		*p = 0;

 	if (!*format)
 	{
 		char *first_colon = strchr(buf, ':');
 		char *first_semi = strchr(buf, ';');

 		if (first_colon || first_semi)
 		{
 			char sep_char;

 			if (first_colon == NULL)
 				sep_char = ';';
 			else if (first_semi == NULL)
 				sep_char = ':';
 			else
 				sep_char = (first_colon < first_semi)? ':' : ';';

 			sprintf(format, "%%[^%c]%c%%[^%c]", sep_char, sep_char, sep_char);
 		}
 		else
 			continue;
 	}

 	if(sscanf(buf, format, iname, ipath) != 2)
 		continue;

From glynn at gclements.plus.com  Mon May  7 16:15:51 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 16:15:55 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17983.5945.696271.788491@cerise.gclements.plus.com>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070507125205.41fe339b.hamish_nospam@yahoo.com>
	<463EF566.8020906@itc.it>
	<17983.5945.696271.788491@cerise.gclements.plus.com>
Message-ID: <17983.13463.772360.950275@cerise.gclements.plus.com>


Glynn Clements wrote:

> It would be fairly straightforward to copy paper.h into the PS driver,
> and allow e.g. GRASS_PAPER=a4 to override GRASS_{WIDTH,HEIGHT}, as
> well as adding margins. Supporting rotation (i.e. landscape) would
> also be straightforward.
> 
> I'll come up with a draft implementation today.

Done. The size/margins can be set via GRASS_PAPER, while
GRASS_LANDSCAPE=TRUE will rotate the output.

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

From glynn at gclements.plus.com  Mon May  7 16:18:01 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 16:18:05 2007
Subject: [GRASS-dev] Re: how to check for system in TclTk
In-Reply-To: <Pine.LNX.4.62.0705071307020.10974@agrippa.ukshells.co.uk>
References: <C263F7FE.21B73%michael.barton@asu.edu>
	<Pine.LNX.4.62.0705071307020.10974@agrippa.ukshells.co.uk>
Message-ID: <17983.13593.232365.155447@cerise.gclements.plus.com>


Paul Kelly wrote:

> > I've fixed this in the CVS, so that setting the default font should work
> > with Windows now.
> 
> OK thanks I made a few more changes and now it is working quite well. Most 
> notably that the
> global env, tcl_platform
> syntax didn't work (env(GISBASE) was an unknown variable) and I had to 
> change it to:
> global env
> global tcl_platform

You can specify multiple variables in a single "global" statement, but
there shouldn't be any commas. "global env, tcl_platform" will attempt
to import a variable named "env," (with a trailing comma).

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

From mlennert at club.worldonline.be  Mon May  7 16:27:33 2007
From: mlennert at club.worldonline.be (Moritz Lennert)
Date: Mon May  7 16:24:21 2007
Subject: [GRASS-dev] access to wingrass binaries
In-Reply-To: <Pine.LNX.4.62.0705070110360.30014@agrippa.ukshells.co.uk>
References: <C2626747.21B4D%michael.barton@asu.edu>
	<1878.85.10.117.251.1178492627.squirrel@geog-pc40.ulb.ac.be>
	<Pine.LNX.4.62.0705070110360.30014@agrippa.ukshells.co.uk>
Message-ID: <463F3755.50400@club.worldonline.be>

On 07/05/07 02:15, Paul Kelly wrote:
> Hello Moritz
> 
> On Mon, 7 May 2007, Moritz Lennert wrote:
> 
>> Any feedback on whether this "package" works as it should / as 
>> expected by
>> users is more than welcome.
> 
> I haven't tried this one but did give the last one a try and it seemed 
> to work OK. I just tried command-line usage (grass63 -text) as the 
> computer I was using it on didn't have Tcl/TK installed. I think we 
> should be able to include Tcl and Tk libraries in the binary 
> distribution too actually, to reduce compatibility issues and make it 
> *really* easy to install.

Any licensing issues concerning the ActiveState distribution that we 
have to take care of ?

> 
>> I also imagine that if we want to make this more official, we need to add
>> licensing information, including for all the binaries that come from
>> Paul's package of dependencies. I added a short note at the end of the
>> readme, but this is surely insufficient. At least we should give the
>> respective web links. Paul, could you give me the list ? Also, should
>> these libraries maybe be updated to their latest versions ?
> 
> Funnily enough I was just working on that yesterday. I've put an updated 
> version of wingrass-extralibs.tar.gz up on www.stjohnspoint.co.uk/grass 
> now. There you will also find build instructions with weblinks. Most of 
> it is public domain or BSD-style licensed I think; perhaps one or two 
> packages are GPL. This time the XDR library is compiled statically to 
> work around the problems we had with database connections. Also FFTW and 
> Freetype libraries are included for the first time. Things still aren't 
> perfect (i.e. compiling is not as straightforward as it should be) but 
> it all seems to work.

Thanks !
I just uploaded a new version of the winGRASS binaries using your latest 
and greatest library package.

Moritz

From glynn at gclements.plus.com  Mon May  7 16:32:01 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 16:32:06 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <Pine.LNX.4.62.0705071358340.10974@agrippa.ukshells.co.uk>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
	<17980.41057.504876.936561@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>
	<17981.41241.747882.668092@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705061156470.15764@agrippa.ukshells.co.uk>
	<17981.62040.196624.166998@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705071358340.10974@agrippa.ukshells.co.uk>
Message-ID: <17983.14433.339843.361407@cerise.gclements.plus.com>


Paul Kelly wrote:

> >>> FWIW, the robust way to check whether two paths are equivalent is to
> >>> stat() (or lstat()) both of them, and check whether the device and
> >>> inode numbers match.
> >>
> >> Interesting; here we are comparing the directory the fonts are stored in
> >> rather than the font files themselves but perhaps still of use?
> >
> > Yes; in the case of COM_Font_get(), you would need to remove the last
> > part of the path and check whether the directory part refers to the
> > same device/inode as $GISBASE/fonts.
> 
> OK well it doesn't work on Windows anyway. The device number corresponds 
> to the drive letter but it appears the inode number is always 0. So I 
> suppose we can just keep the string comparison of the directory names. Or 
> remove the option of specifying the full path to a GRASS stroke font - I 
> generally feel unhappy with the idea of removing functionality but maybe 
> it is the best option here?

I think so.

Allowing a full path is exposing an implementation detail, it isn't
sufficient for files containing multiple faces, and it may cause
problems with future development.

I would rather just have fonts selected by an abstract identifier.

> >>> Also, I'd guess that using a colon as the field separator is likely to
> >>> be problematic on Windows.
> >>
> >> Yes, that was it. If I use a semi-colon instead all works great - maybe we
> >> could change mkftcap to generate a file with semi-colon separators? And
> >> change parse_freetypecap() to handle both for backwards compatibility? Is
> >> the last character on a line in freetypecap always a separator character?
> >> If so that would be a quick way to check. Or could scan the first line and
> >> whichever appeared first between : and ; use that as the separator?
> >
> > If it's going to be changed, one option is to use a vertical bar
> > (which isn't a legal filename character on Windows), and make the face
> > index a separate column.
> 
> I can't see an easy way though of keeping old freetypecap files compatible 
> with the current reading code that way though - just recognising an 
> alternative separator character doesn't seem to be too disruptive (apart 
> from adding extra code and requiring it to be kept there for ever.)

I don't think that maintaining compatibility is all that important.
The original freetypecap format is something which Huidae made up on
the spot. It's already lost the colour/size fields, and the encoding
field isn't actually used.

> > That would eliminate the possibility of using a non-zero index when
> > specifying a font by a pathname, but that's problematic for other
> 
> Yes but that's quite neat and an easy and simple way of specifying a 
> non-zero index if you need to, I thought.
> 
> > reasons (e.g. gisprompt = "old_file,..." should probably check for
> > file existence, which would rule out the option of using something
> > which is "almost" a filename).
> 
> Yes if the font was being specified through a module like d.font - I 
> suppose an extra parameter could be added to specify the index. But when 
> the font is just being read from an environment variable then it's more 
> complicated and anyway the parser isn't going to be involved here so as 
> far as I can see the check for file existence needs to be done manually 
> anyway as it currently is.

Yes, but we should be able to use a generic file existence check,
without having to worry about hacks. When I was implementing the face
index hack, it took several iterations to get it right (either
forgetting to strip the index for the check, or inadvertantly using
the stripped version when the index was needed). My suspicion is that
the index hack will bite people continuously so long as it's around.

> > AFAIK, the trailing separator is an artifact of the time that style
> > information (colour, size) was included in the freetypecap file.
> >
> > BTW, the encoding field isn't used either (d.font.freetype and
> > d.text.freetype used it, but the driver doesn't).
> >
> > Note that d.font has code which parses the freetypecap file in order
> > to generate the option list for font=, and to implement the -l switch,
> > so that will need to be updated if the format changes.
> >
> > d.font.freetype and d.text.freetype have similar code, but they no
> > longer need to be maintained; they have been replaced by scripts which
> > call d.font and d.text (which is actually d.text.new) respectively.
> 
> OK. Well here is my current proposal, which can be easily added to both 
> d.font and libdriver: dynamically generate the format conversion string 
> (containing either a : or ; as separator) based on the relative position 
> of : and ; characters in the first line of the file that contains either 
> of them.
> The code looks like below; it is complicated but I can't see how to make 
> it simpler without losing backwards compatibility. I'm not quite happy 
> enough with it to commit it yet. It can be easily included in both d.font 
> and libdriver as-is, though.

Here's my proposal: don't bother maintaining compatibility with the
current freetypecap format or the ability to select fonts by absolute
path. Both of those were made up on the spot without any real
consideration.

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

From paul-grass at stjohnspoint.co.uk  Mon May  7 16:34:10 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Mon May  7 16:34:13 2007
Subject: [GRASS-dev] access to wingrass binaries
In-Reply-To: <463F3755.50400@club.worldonline.be>
References: <C2626747.21B4D%michael.barton@asu.edu>
	<1878.85.10.117.251.1178492627.squirrel@geog-pc40.ulb.ac.be>
	<Pine.LNX.4.62.0705070110360.30014@agrippa.ukshells.co.uk>
	<463F3755.50400@club.worldonline.be>
Message-ID: <Pine.LNX.4.62.0705071529420.24112@agrippa.ukshells.co.uk>

On Mon, 7 May 2007, Moritz Lennert wrote:

> Any licensing issues concerning the ActiveState distribution that we have to 
> take care of ?

I was thinking more along the lines of compiling Tcl/Tk from scratch on 
MinGW and including our own binaries, or including the 8.4.1 MinGW 
binaries that are available somewhere on the net.

> Thanks !
> I just uploaded a new version of the winGRASS binaries using your latest and 
> greatest library package.

Does it all run OK? Things to check: Display modules not able to find the 
libfreetype-6.dll, but moving it around a bit to whereever they seemed to 
be looking fixed that. Also GDAL and GRASS seemed to be looking for the 
libz dll under different names - AFAICR GRASS was libz.dll.1.2.3 and GDAL 
libz.dll.1.2.3.dll! But these issues might have been resolved when you put 
everything together in the GRASS library directory; I didn't really 
investigate too much what was causing them.

Paul

From neteler at itc.it  Mon May  7 17:00:43 2007
From: neteler at itc.it (Markus Neteler)
Date: Mon May  7 17:00:46 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17983.13463.772360.950275@cerise.gclements.plus.com>
References: <46321E13.6070204@itc.it>	<17970.28635.172625.944822@cerise.gclements.plus.com>	<4635961C.406@itc.it>	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>	<20070430075832.GA30195@bartok.itc.it>	<4635A574.4090800@itc.it>	<17973.47593.760354.352347@cerise.gclements.plus.com>	<20070502090554.GC27153@bartok.itc.it>	<17976.35182.363572.196185@cerise.gclements.plus.com>	<20070505142900.GA14720@bartok.itc.it>	<17980.41764.666518.270623@cerise.gclements.plus.com>	<20070506172545.531f29b8.hamish_nospam@yahoo.com>	<17981.42413.865376.470245@cerise.gclements.plus.com>	<20070507125205.41fe339b.hamish_nospam@yahoo.com>	<463EF566.8020906@itc.it>	<17983.5945.696271.788491@cerise.gclements.plus.com>
	<17983.13463.772360.950275@cerise.gclements.plus.com>
Message-ID: <463F3F1B.90803@itc.it>

Glynn Clements wrote on 05/07/2007 04:15 PM:
> Glynn Clements wrote:
>
>   
>> It would be fairly straightforward to copy paper.h into the PS driver,
>> and allow e.g. GRASS_PAPER=a4 to override GRASS_{WIDTH,HEIGHT}, as
>> well as adding margins. Supporting rotation (i.e. landscape) would
>> also be straightforward.
>>
>> I'll come up with a draft implementation today.
>>     
>
> Done. The size/margins can be set via GRASS_PAPER, while
> GRASS_LANDSCAPE=TRUE will rotate the output.
>   
Cool!
Would it make sense to move the paper definitions from
 lib/psdriver/Graph_set.c
 ps/ps.map/paper.h (contains more definitions)
to
 include/pspaper.h

?

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------

From paul-grass at stjohnspoint.co.uk  Mon May  7 17:02:22 2007
From: paul-grass at stjohnspoint.co.uk (Paul Kelly)
Date: Mon May  7 17:02:24 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <17983.14433.339843.361407@cerise.gclements.plus.com>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
	<17980.41057.504876.936561@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>
	<17981.41241.747882.668092@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705061156470.15764@agrippa.ukshells.co.uk>
	<17981.62040.196624.166998@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705071358340.10974@agrippa.ukshells.co.uk>
	<17983.14433.339843.361407@cerise.gclements.plus.com>
Message-ID: <Pine.LNX.4.62.0705071552590.24112@agrippa.ukshells.co.uk>

On Mon, 7 May 2007, Glynn Clements wrote:

> Here's my proposal: don't bother maintaining compatibility with the
> current freetypecap format or the ability to select fonts by absolute
> path. Both of those were made up on the spot without any real
> consideration.

So what about having a totally new file, let's call it fontcap - different 
name to make it clear there is no backwards compatiblity. It could include 
the stroke fonts as well as freetype-compatible fonts, with a field to 
indicate whether the font is stroke or freetype, also absolute filename, 
index within the file, perhaps a field for a descriptive/long name too.

I wonder if something like this is what Michael had in mind when we 
started this whole discussion - a simple list of all the avaiable fonts 
that could be offered to the user to choose from through the GUI?

It would be generated automatically on compilation/installation and then 
the user could further edit it to add to / strip it down if required.
Wolf said he was interested in writing something to automatically extract 
information from font files on the system - maybe what he comes up with 
can be used to generate this fontcap file. And then once we're finished 
GRASS_FONT can only contain a font id string from this file - nothing else 
is accepted. Does that sound like it might be workable?

From michael.barton at asu.edu  Mon May  7 17:20:40 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon May  7 17:20:48 2007
Subject: [GRASS-dev] Re: how to check for system in TclTk
In-Reply-To: <Pine.LNX.4.62.0705071307020.10974@agrippa.ukshells.co.uk>
Message-ID: <C26491D8.21B8C%michael.barton@asu.edu>

Thanks Paul. I'll update my version.

Michael


On 5/7/07 5:13 AM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

> On Sun, 6 May 2007, Michael Barton wrote:
> 
>> I've fixed this in the CVS, so that setting the default font should work
>> with Windows now.
> 
> OK thanks I made a few more changes and now it is working quite well. Most
> notably that the
> global env, tcl_platform
> syntax didn't work (env(GISBASE) was an unknown variable) and I had to
> change it to:
> global env
> global tcl_platform
> (which is what the Tcl documentation suggests anyway; ISTR coming across
> this before but it seemed to be OK then. Not too sure.)
> 
> The other noteworthy change was using the Native Tk file browser widget
> ::tk::dialog::file:: instead of the native Windows one that tk_getOpenFile
> uses. The native Windows one was very slow and clunky and most
> importantly didn't work for selecting fonts from the Windows fonts
> directory. Clicking on a file didn't put it into the selection box and
> double-clicking opened a Window displaying the font's capabilities. The
> native Tk widget admittedly has a distinct early-90s look to it but it is
> fast and (most importantly) works.
> 
> Paul

__________________________________________
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 at asu.edu  Mon May  7 17:26:16 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon May  7 17:26:27 2007
Subject: [GRASS-dev] Re: how to check for system in TclTk
In-Reply-To: <17983.13593.232365.155447@cerise.gclements.plus.com>
Message-ID: <C2649328.21B8E%michael.barton@asu.edu>

Typo on my part. I'm surprised it work OK for me.

Michael


On 5/7/07 7:18 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Paul Kelly wrote:
> 
>>> I've fixed this in the CVS, so that setting the default font should work
>>> with Windows now.
>> 
>> OK thanks I made a few more changes and now it is working quite well. Most
>> notably that the
>> global env, tcl_platform
>> syntax didn't work (env(GISBASE) was an unknown variable) and I had to
>> change it to:
>> global env
>> global tcl_platform
> 
> You can specify multiple variables in a single "global" statement, but
> there shouldn't be any commas. "global env, tcl_platform" will attempt
> to import a variable named "env," (with a trailing comma).

__________________________________________
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 at asu.edu  Mon May  7 17:38:39 2007
From: michael.barton at asu.edu (Michael Barton)
Date: Mon May  7 17:38:50 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <17983.14433.339843.361407@cerise.gclements.plus.com>
Message-ID: <C264960F.21B92%michael.barton@asu.edu>




On 5/7/07 7:32 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

> 
> Paul Kelly wrote:

...

>> OK well it doesn't work on Windows anyway. The device number corresponds
>> to the drive letter but it appears the inode number is always 0. So I
>> suppose we can just keep the string comparison of the directory names. Or
>> remove the option of specifying the full path to a GRASS stroke font - I
>> generally feel unhappy with the idea of removing functionality but maybe
>> it is the best option here?
> 
> I think so.
> 
> Allowing a full path is exposing an implementation detail, it isn't
> sufficient for files containing multiple faces, and it may cause
> problems with future development.
> 
> I would rather just have fonts selected by an abstract identifier.
> 

Could this be the kind of font specification used in native font selection
dialogs for wxPython and TclTk? They *appear* to be quite similar in the way
they specify fonts. But I still have found no way to get back to original
font files from these specifications, suggesting that it happens somewhere
at the system level. If we could somehow tap into that, it could ultimately
make life easier for cross-platform font selection.

...
>> 
>> OK. Well here is my current proposal, which can be easily added to both
>> d.font and libdriver: dynamically generate the format conversion string
>> (containing either a : or ; as separator) based on the relative position
>> of : and ; characters in the first line of the file that contains either
>> of them.
>> The code looks like below; it is complicated but I can't see how to make
>> it simpler without losing backwards compatibility. I'm not quite happy
>> enough with it to commit it yet. It can be easily included in both d.font
>> and libdriver as-is, though.
> 
> Here's my proposal: don't bother maintaining compatibility with the
> current freetypecap format or the ability to select fonts by absolute
> path. Both of those were made up on the spot without any real
> consideration.

Then I'm not going to worry about implementing a different way of selecting
fonts that uses freetypecap in the TclTk GUI at the moment. It is working OK
now, so I'll leave well enough alone until this gets sorted out further.

But it *is* really nice to see this discussion over improvements in how to
specify display fonts in GRASS. It makes an enormous impact on the
professional look of GRASS output, not to mention its readability in
presentations. Thanks much guys.

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 grass-codei at wald.intevation.org  Mon May  7 17:54:17 2007
From: grass-codei at wald.intevation.org (grass-codei@wald.intevation.org)
Date: Mon May  7 17:54:21 2007
Subject: [GRASS-dev] [grass-code I][393] projected raster map looses reclass
	data
Message-ID: <20070507155417.6E6AA180420E@pyrosoma.intevation.org>

code I item #393, was opened at 07/05/2007 15:54
Status: Open
Priority: 3
Submitted By: Alessandro Frigeri (alf)
Assigned to: Nobody (None)
Summary: projected raster map looses reclass data 
Issue type: library bug
Issue status: None
GRASS version: CVS HEAD
GRASS component: raster
Operating system: Linux
Operating system version: Debian amd64/unstable
GRASS CVS checkout date, if applies (YYMMDD): 


Initial Comment:
Reprojecting (r.proj) a reclassed map results in a map without the original reclass informations.

The reclass file ($grassdb/$location/$mapset/cats/mymap) shows up:

--BEGIN
# 7 categories


0.00 0.00 0.00 0.00
--END

so it seems that the '7 categories' list is just not written to the file.

Regards,

Alessandro



----------------------------------------------------------------------

You can respond by visiting: 
http://wald.intevation.org/tracker/?func=detail&atid=204&aid=393&group_id=21

From glynn at gclements.plus.com  Mon May  7 18:14:43 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 18:14:46 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <463F3F1B.90803@itc.it>
References: <46321E13.6070204@itc.it>
	<17970.28635.172625.944822@cerise.gclements.plus.com>
	<4635961C.406@itc.it>
	<20070430195547.6f713b5d.hamish_nospam@yahoo.com>
	<20070430075832.GA30195@bartok.itc.it> <4635A574.4090800@itc.it>
	<17973.47593.760354.352347@cerise.gclements.plus.com>
	<20070502090554.GC27153@bartok.itc.it>
	<17976.35182.363572.196185@cerise.gclements.plus.com>
	<20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070507125205.41fe339b.hamish_nospam@yahoo.com>
	<463EF566.8020906@itc.it>
	<17983.5945.696271.788491@cerise.gclements.plus.com>
	<17983.13463.772360.950275@cerise.gclements.plus.com>
	<463F3F1B.90803@itc.it>
Message-ID: <17983.20595.535723.916561@cerise.gclements.plus.com>


Markus Neteler wrote:

> >> It would be fairly straightforward to copy paper.h into the PS driver,
> >> and allow e.g. GRASS_PAPER=a4 to override GRASS_{WIDTH,HEIGHT}, as
> >> well as adding margins. Supporting rotation (i.e. landscape) would
> >> also be straightforward.
> >>
> >> I'll come up with a draft implementation today.
> >>     
> >
> > Done. The size/margins can be set via GRASS_PAPER, while
> > GRASS_LANDSCAPE=TRUE will rotate the output.
> >   
> Cool!
> Would it make sense to move the paper definitions from
>  lib/psdriver/Graph_set.c
>  ps/ps.map/paper.h (contains more definitions)
> to
>  include/pspaper.h

Maybe, maybe not.

E.g., lib/psdriver makes the variable static (libraries should avoid
exporting unnecessary symbols), while ps.map doesn't.

If a common table of paper sizes is desired, it would be better for
libgis to provide a function, similar to the way that the table of
standard colours is handled (G_standard_color_rgb(), lib/gis/color_str.c).

Better still would be the ability to read the information from a text
file, so that new sizes can be added by the user.

I didn't add the landscape defintions because they're usually the
wrong thing to do; e.g. gv doesn't offer landscape paper sizes (except
for Ledger, which is always landscape), hardcopy typically requires an
A3 printer (even then, most printers will assume that the document is
portrait and rotate it, unless told otherwise).

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

From neteler at itc.it  Mon May  7 18:18:43 2007
From: neteler at itc.it (Markus Neteler)
Date: Mon May  7 18:18:44 2007
Subject: [GRASS-dev] ps.map: raster always under vector map?
In-Reply-To: <17983.20595.535723.916561@cerise.gclements.plus.com>
References: <20070505142900.GA14720@bartok.itc.it>
	<17980.41764.666518.270623@cerise.gclements.plus.com>
	<20070506172545.531f29b8.hamish_nospam@yahoo.com>
	<17981.42413.865376.470245@cerise.gclements.plus.com>
	<20070507125205.41fe339b.hamish_nospam@yahoo.com>
	<463EF566.8020906@itc.it>
	<17983.5945.696271.788491@cerise.gclements.plus.com>
	<17983.13463.772360.950275@cerise.gclements.plus.com>
	<463F3F1B.90803@itc.it>
	<17983.20595.535723.916561@cerise.gclements.plus.com>
Message-ID: <20070507161842.GR17722@bartok.itc.it>

On Mon, May 07, 2007 at 05:14:43PM +0100, Glynn Clements wrote:
...
> I didn't add the landscape defintions because they're usually the
> wrong thing to do; e.g. gv doesn't offer landscape paper sizes (except
> for Ledger, which is always landscape), hardcopy typically requires an
> A3 printer (even then, most printers will assume that the document is
> portrait and rotate it, unless told otherwise).

Since I have no A3 printer here, I used 'poster' [1] to split the
ps.map output into a series of A4 sheets (the trick is that
'poster' wants EPS instead of PS). Apparently the a3-landscape
worked well to get a rather big map. But I didn't try with a3 paper.

Markus

[1] by Jos van Eijndhoven, from KDE print utils

From glynn at gclements.plus.com  Mon May  7 18:29:58 2007
From: glynn at gclements.plus.com (Glynn Clements)
Date: Mon May  7 18:30:00 2007
Subject: [GRASS-dev] iconv a required dependency for using Freetype?
In-Reply-To: <Pine.LNX.4.62.0705071552590.24112@agrippa.ukshells.co.uk>
References: <Pine.LNX.4.62.0705051441030.17334@agrippa.ukshells.co.uk>
	<17980.41057.504876.936561@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705052253390.29495@agrippa.ukshells.co.uk>
	<17981.41241.747882.668092@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705061156470.15764@agrippa.ukshells.co.uk>
	<17981.62040.196624.166998@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705071358340.10974@agrippa.ukshells.co.uk>
	<17983.14433.339843.361407@cerise.gclements.plus.com>
	<Pine.LNX.4.62.0705071552590.24112@agrippa.ukshells.co.uk>
Message-ID: <17983.21510.834760.884342@cerise.gclements.plus.com>


Paul Kelly wrote:

> > Here's my proposal: don't bother maintaining compatibility with the