Dear GRASSusers,
In using GRASS under cygwin I'm having some trouble with the keyboard
setting.
I have an italian keyboard that run well under Windows xp and cygwin, but
when I enter GRASS in Xfree86, the keyboard change (probably in US layout).
Any suggestion?
Many thanks
Aldo Clerici
Parma University
Italy
Aldo Clerici wrote:
In using GRASS under cygwin I'm having some trouble with the keyboard
setting.
I have an italian keyboard that run well under Windows xp and cygwin, but
when I enter GRASS in Xfree86, the keyboard change (probably in US layout).
Any suggestion?
Normally, this would be set via the XF86Config file; however, the last
time I checked, Cygwin's X server doesn't use a config file.
You can use the xmodmap utility to reconfigure the keyboard.
Typically, you would put the necessary xmodmap directives into the
file ~/.Xmodmap; the default xinitrc file (/etc/X11/xinit/xinitrc)
will run xmodmap on this file if it exists.
E.g. for a UK keyboard, I used the following ~/.Xmodmap file:
keycode 11 = 2 quotedbl
keycode 12 = 3 sterling
keycode 48 = apostrophe at
keycode 51 = numbersign asciitilde
keycode 94 = backslash bar
You can use the "xev" program to discover the keycodes (numbers) and
the keysyms (names).
--
Glynn Clements <glynn.clements@virgin.net>
I've got a rather strange problem I can't figure out, using GRASS 5.0.1
I have a large number of sites (on the order of 176,000) that I'm trying to
use as elevations to create a surface (they were derived from road surveys,
control points, signposts, and miscellaneous building perimeters, scavenged
from a DXF file by a script I wrote). The logical way to do this would be to
bring them in as sites, and do s.surf.rst, but the surface I get is too
convoluted (and playing with tension values from 10 to 100 doesn't seem to
make any noticeable difference).
My next thought was s.to.rast to surface them as a raster, but s.to.rast
seems to die an ugly segfault death at a few thousand sites. In desparation,
I wrote a perl script that went through the sites and built up a raster map
file suitable for import with r.in.ascii (averaging multiple sites that fall
in the same cell, unlike s.to.rast, which just keeps the last value, which,
for my purposes, is a Good Thing).
I've used this script to import two fields of sites, with no fuss. The
surfaces I get with r.surf.idw look very good, with very little convolution.
Everything was going smooth as silk. I got to the third batch of data, and
suddenly r.in.ascii is failing.
If I look at the ascii file that I'm importing, I can see many non-null
cells. Searching the file for decimal points (non-null cells), there are
almost seventy thousand. Doing r.stats on one of the previous maps (of
similar size and density) shows thousands of non-null cells. But when I
import the third map, only about fifty cells out of a million and a half are
non-null, according to r.stats. During import, it reports no errors at all.
I've played with region settings every which way (my script kicks out East,
West, North and South limits, as well as Min-Z and Max-Z. "g.region -p"
reports exactly the same numbers when I do g.region rast=, as does "r.info")
The location is set up as UTM, nad83, zone13, grs80. The first few lines of
the generated raster file look like this:
north: 4402330
south: 4395940
east: 466740
west: 442750
rows: 639
cols: 2399
null: N
type: float
N N N N N N N ....
(etc, for another 639 lines of 2399 columns, many of which contain something
other than "N" -- like 2569.481. The column separator is a space [0x20] The
row separator is 0x0A. Yes, I've looked at this with hexdump to see if there
are any bad invisible characters)
(if anybody is curious about the entire raster, it can be found at
http://www.timension.com/GIS/I70_3.UTM.rast.gz -- this is a 273K file
{Oh, this is too cool -- I just found out that Mozilla will gunzip zipped
files, and put it on the screen for you -- Neat! So if you're using Mozilla,
you can see directly how many cells are non-null}
I'm at wits end trying to figure this out, especially since it worked
(apparently) perfectly the first two times. Am I missing something
fundamental? Is my script creating flawed rasters? Is there a file-size
limit to r.in.ascii that only allows for small rasters to be imported (say,
under a million cells)?
I eagerly await any help (okay, I don't await -- I keep farting with my
scripts because I'm on deadline, but with diminishing hope of success).
Victor Wren
Victor Wren
Designer,
Timension Inc.
1350 C Pear Ave
Mountain View CA 94043
(650) 564-9397
Fax: (650) 564-9398
Opinions stated in this letter are not necessarily
those of Timension Inc. or the management. All
Rights Reserved. No spitting.
Never mind this message. After fighting with it all day yesterday, I
discovered a mask file that I had forgotten about because I've slept since
then. I only figured it out about it when I tried to draw a new mask file
for surfacing, and THAT wouldn't display.
NUTS!!
If course, s.to.rast still segfaults...
I've got a rather strange problem I can't figure out, using GRASS 5.0.1
I have a large number of sites (on the order of 176,000) that I'm trying to
use as elevations to create a surface (they were derived from road surveys,
control points, signposts, and miscellaneous building perimeters....
VW
Victor Wren
Designer,
Timension Inc.
1350 C Pear Ave
Mountain View CA 94043
(650) 564-9397
Fax: (650) 564-9398
Opinions stated in this letter are not necessarily
those of Timension Inc. or the management. All
Rights Reserved. No spitting.
Hello
On Thu, 3 Apr 2003, Victor Wren wrote:
I've got a rather strange problem I can't figure out, using GRASS 5.0.1
I have a large number of sites (on the order of 176,000) that I'm trying to
use as elevations to create a surface (they were derived from road surveys,
control points, signposts, and miscellaneous building perimeters, scavenged
from a DXF file by a script I wrote). The logical way to do this would be to
bring them in as sites, and do s.surf.rst, but the surface I get is too
convoluted (and playing with tension values from 10 to 100 doesn't seem to
make any noticeable difference).
Did you try using s.surf.idw? I've recently added an improved version to
CVS, which should be able to deal with many hundreds of thousands of sites
quite quickly (provided they aren't located too sparsely) and I would
appreciate some testing for it.
If you don't like using CVS, you can get the changed main.c file from
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass/src/sites/s.surf.idw/cmd/main.c
Just rename the main.c in src/sites/s.surf.idw/cmd/ and copy this file in,
then recompile with gmake5 -i.
The updated man page is at
http://freegis.org/cgi-bin/viewcvs.cgi/*checkout*/grass/html/html/s.surf.idw.html
Paul
On Thu, Apr 03, 2003 at 12:34:44PM -0800, Victor Wren wrote:
Never mind this message. After fighting with it all day yesterday, I
discovered a mask file that I had forgotten about because I've slept since
then. I only figured it out about it when I tried to draw a new mask file
for surfacing, and THAT wouldn't display.NUTS!!
What if there were the work 'MASK' or just 'M' in the GRASS prompt?
I was fighing with the same problem recently ...
Something like
GRASS:~ >
and
GRASS(M):~ >
in case a MASK is present. Maybe there is a possibility to
add a file check to
PS1='GRASS:\w > '
?
Markus
On Thu, 10 Apr 2003, H Bowman wrote:
It picked out 3000 sites which were within the mask(?) to work with.
s.surf.rst picked out 3542 or so within the region, & uses all those(?)
It should use all the sites in the region (ignoring the mask) for
interpolation.
The number printed on the screen was only updated every time the number of
sites read passed a multiple of 1000, so if there were 3542 it would still
be stuck on 3000. I copied the behaviour from s.info but I see now it's a
bit confusing and I've just commited a fix to CVS so it will now report
the actual number of sites loaded. Hopefully you should see 3542....
Markus Neteler wrote:
> Never mind this message. After fighting with it all day yesterday, I
> discovered a mask file that I had forgotten about because I've slept since
> then. I only figured it out about it when I tried to draw a new mask file
> for surfacing, and THAT wouldn't display.
>
> NUTS!!What if there were the work 'MASK' or just 'M' in the GRASS prompt?
I was fighing with the same problem recently ...Something like
GRASS:~ >
and
GRASS(M):~ >in case a MASK is present. Maybe there is a possibility to
add a file check to
PS1='GRASS:\w > '
?
With bash, the variable PROMPT_COMMAND can be used to specify a
command which is run before printing the prompt. E.g.
PROMPT_COMMAND='if r.info MASK &> /dev/null ; then echo -n "GRASS(M):" ; else echo -n "GRASS:" ; fi'
PS1='\w '
Except that the above will repeatedly send you email with the error
message from r.info when MASK doesn't exist. Ideally, you want a
dedicated utility which tests for the existence of a mask.
--
Glynn Clements <glynn.clements@virgin.net>
I wouldn't mind that.
David Finlayson
dfinlays@u.washington.edu
Department of Earth and Space Sciences
University of Washington, Box 351310
Seattle, WA 98195-1310
(206) 685-7981 or (206) 543-1975
On Thu, 10 Apr 2003, Markus Neteler wrote:
On Thu, Apr 03, 2003 at 12:34:44PM -0800, Victor Wren wrote:
> Never mind this message. After fighting with it all day yesterday, I
> discovered a mask file that I had forgotten about because I've slept since
> then. I only figured it out about it when I tried to draw a new mask file
> for surfacing, and THAT wouldn't display.
>
> NUTS!!What if there were the work 'MASK' or just 'M' in the GRASS prompt?
I was fighing with the same problem recently ...Something like
GRASS:~ >
and
GRASS(M):~ >in case a MASK is present. Maybe there is a possibility to
add a file check to
PS1='GRASS:\w > '
?Markus
On Thu, Apr 10, 2003 at 04:54:44PM +0100, Glynn Clements wrote:
Markus Neteler wrote:
[...]
> What if there were the work 'MASK' or just 'M' in the GRASS prompt?
> I was fighing with the same problem recently ...
>
> Something like
> GRASS:~ >
> and
> GRASS(M):~ >
>
> in case a MASK is present. Maybe there is a possibility to
> add a file check to
> PS1='GRASS:\w > '
> ?With bash, the variable PROMPT_COMMAND can be used to specify a
command which is run before printing the prompt. E.g.PROMPT_COMMAND='if r.info MASK &> /dev/null ; then echo -n "GRASS(M):" ; else echo -n "GRASS:" ; fi'
PS1='\w 'Except that the above will repeatedly send you email with the error
message from r.info when MASK doesn't exist. Ideally, you want a
dedicated utility which tests for the existence of a mask.
Thanks for the idea!
An alternate hack solving the mail problem is:
PROMPT_COMMAND='if test -f `g.gisenv GISDBASE`/`g.gisenv LOCATION_NAME`/`g.gisenv MAPSET`/cell/MASK ; then echo -n "GRASS(M):" ; else echo -n "GRASS:" ; fi'
PS1='\w >'
Works without sending mails.
Markus