[GRASS-user] Compiling NVIZ / OpenGL with nVidia drivers

2010-01-06 Thread John Stevenson

Hi,

Perhaps more a general Linux question than a specific grass one, but  
does anyone know how to compile GRASS with OpenGL and NVIZ support?


I am running Ubuntu 9.04 with the proprietary nVidia drivers for my  
graphics card.  Whenever I try to install OpenGL it breaks my nVidia  
settings.  NVIZ works fine when I download the binary in a  
pre-compiled version of grass.


So far, I can only get grass to compile with --without-opengl.

Thanks

John

--
Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building
University of Manchester
Manchester M13 9PL
UK
tel. +44(0)161 306 9360; fax. +44(0)161 306 9361;
john.steven...@manchester.ac.uk

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Compiling addons - description.html

2009-08-12 Thread John Stevenson

Hi,

When compiling addons, how do I make the description.html file that  
comes with the addon be installed as the help page that loads with  
g.manual?  Currently, I am getting a short page with just the commands  
as generated by g.parser.


e.g. in grass-addons/raster/r.denoise, or r.surf.volcano
sudo make MODULE_TOPDIR=/usr/local/grass-6.5.svn
sudo make MODULE_TOPDIR=/usr/local/grass-6.5.svn install

Cheers

John

--
Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building
University of Manchester
Manchester M13 9PL
UK
tel. +44(0)161 306 9360; fax. +44(0)161 306 9361;
john.steven...@manchester.ac.uk

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Open Source GIS Meeting - Nottingham University - Monday

2009-06-20 Thread John Stevenson

Is anyone else on the list going to this?

I'm giving a presentation in the afternoon:

From ASCII files to orthophotos: The processing of high-
resolution aerial survey data using open source GIS software.


High quality maps are an important tool in volcanology. In August 2007  
the NERC Airborne
Research and Survey Facility (ARSF) mapped the Nesjavellir region in  
Iceland's Western Volcanic
Zone. LiDAR, aerial photos and multispectral infrared data were  
collected with the purpose of
surveying the Nesjahraun, a lava flow that was erupted there  
approximately 2000 years ago and

which exhibits complex and varied surface textures.

To allow maximum flexibility for the end user,
only low-level processing was carried out by NERC. The remaining  
processing was carried out
using open source tools, mainly GRASS, GMT, GDAL and gstat to generate  
higher level products.
The command-line interface of these tools allows tight integration  
with standard text- and file-
manipulation tools that are built into the GNU/Linux operating system  
and lends itself easily to the

creation of scripts for the batch processing of multiple files.

The LiDAR data were provided as 6.5 Gb of ASCII text containing  
information on the location and
intensity of each laser return. A preliminary DEM was prepared by  
binning the data onto a 10 m
grid in GRASS. For more detailed work, the LiDAR points were  
interpolated onto a 1 m grid by
kriging using the gstat software in combination with GRASS. This  
high-resolution DEM was used
to orthorectify the aerial photos and multispectral infrared data by  
providing both ground control
points and a topographic model. The rectified photos were formatted  
for printing in GMT to
produce hard-copy maps while false-colour composite images were made  
by combining different
bands of the multispectral infrared data in GRASS. GRASS was also used  
to digitise roads and
other features from the orthophotos and to plot measurements made in  
the field. Conversion of the
format and projection via the GDAL software allows visualisation of  
much of the data in Google

EarthTM.

The article outlines the GRASS modules and other software tools used  
to generate high-level
datasets from ARSF data, as a workflow template. It also demonstrates  
that open source software is
a viable and cost-effective alternative to proprietary software in  
analysis of GIS data.



Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
john.steven...@manchester.ac.uk

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] i.rectify: how to make it works?!?!?

2009-04-07 Thread John Stevenson

Enrico Graziani wrote:

Hello!
I'm trying to use imagery tools to georeference/rectify an image taken 
from google earth...

Here's the procedure I've used without success:
 
- From GEarth saved image to a local file (jpeg) ( I've tried to 
convert this jpeg to png but this didn't helped me. In both case I've 
keeped the image as 24 bit...)
- Created a location wgs84 utm29 (North!) with region coordinate taken 
from GEarth (in local format)

- Created a location xy in grass (6.2.3) with region as big as the picture
- Imported the image with g.in.gdal: this creates 3 raster maps, blue 
green and red

- r.composite the 3 rasters to one gearth raster
- i.group to create group group containing the gearth raster
- i.target giving target the wgs84 utm29 location (mapset user)
- i.points to give 3 GCPs
(- tried also to run i.group to remove the gearth raster from 
r.composite and add the 3 rgb rasters map)

- i.rectify -a group=group input=group extension=_rect order=1
 
Everything goes fine till here, except for the fact that if I add the 
-c option to i.rectify it will always fail with error while writing 
to temp file.

However, when I go to other location the map doesn't display.
If I've rectified the 3 rgb rasters I can try to display the map with 
an RGB layer or creating a single raster map with r.composite but, 
first of all, it takes forever (running top while doing this 
displayed a 99% of CPU use by d.rgb or r.composite) and, last but not 
last, the map doesn't display. If I select on the map display zoom to 
selected map it will zoom to default region (the selected region in 
this location) even if I used i.rectify without the -c flag!
Worster if I try to rectify the r.composited raster (the one 
containing the 3 imported channel)  first and then rectify it. 
Everything goes ok but if I try to display it grass just stuck and I 
need to restart the x server to quit the grass windows...
 
I had a look at the data in the wgs84_utm29 location and noticed that 
this last r.composited raster hasn't been converted. Data in the 
cell directory is around 24 kb and there is a 148 kb file in the 
cell_misc/$RASTER_NAME directory ..   starting jpeg was a couple of MBs..
Stranger in the other case (rectifying the 3 channels and then 
displaying rgb layer or r.composite them): the files in the cell 
directory are around 15 kb and 148 kb in the cell_misc folders, but 
after r.composite, the raster coming from this has 6.9 MB in the cell 
folder and 107.3 MB in the cell_misc folder of data.
All the files I'm talking about in the cell misc folder are called 
null and dolphin recognized them by the MIME type as jpeg2000, but 
gwenview isn't able to display them...
 
My configuration is the installation of the GRASS Live DVD coming from 
the Trento University in a VMWare machine running with VMPlayer 2.0.5 
on Debian Etch.

This live should be Kubuntu Hardy ( ?) based.


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
  

For a quick georeferencing, with just 3 gcps, you can just use gdal.

gdal_translate -a_srs EPSG:4326 -of GTiff -gcp x1 y1 X1 Y1 -gcp x2 y2 
X2 Y2 -gcp x3 y3 X3 Y3 gearth.jpg gearth.tif


gdalwarp -t_srs EPSG:4326 -rc  gearth.tif gearth_rectified.tif

Then load the image with r.in.gdal.
You can get the gcps by hovering the mouse over landmarks in The Gimp 
(x,y) and Google Earth (X,Y).
You can find the EPSG code for your utm region here: 
http://www.epsg-registry.org/


Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
john.steven...@manchester.ac.uk 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Off Topic: Importing GRASS tiffs to GMT

2009-04-07 Thread John Stevenson

Hamish wrote:

Eric wrote:


I'll post here before checking on the GMT list;
hopefully I can get some answers from a GRASS/GMT guru...
  


Moritz wrote:
  

I can't help you on your precise questions, but have you seen
Dylan's article:
http://casoilresource.lawr.ucdavis.edu/drupal/node/561
(see link to pdf on that page) ?



and of course the GRASS Wiki:
  http://grass.osgeo.org/wiki/GMT

(which of course forever needs updating)



Hamish



  


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

  
By a tiff, do you mean a georeferenced map? I've plotted aerial photos 
that I rectified in GRASS using the following to export the RGB bands:


r.mapcalc image.red=r#image; image.green=g#image; image.blue=b#image
r.out.bin -h input=image.red output=image.red.grd
r.out.bin -h input=image.green output=image.green.grd
r.out.bin -h input=image.blue output=image.blue.grd

Followed by:

grdimage image.red.grd image.green.grd image.blue.grd -J -R -B ...etc.

I've just put the same workflow onto the wiki.  I've also used r.his to 
make coloured shaded relief maps, and plotted them in GMT using the same 
method.  I don't think that it is the optimal method, but at least it 
preserved my colour rules.


Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
john.steven...@manchester.ac.uk 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] r.patch, images vs coloured elevation data, aerial photo mosaic

2009-02-16 Thread John Stevenson

Hi,

I have two questions, first a specific one, secondly a more general one.

1)  I have some aerial photos that I want to mosaic.  I am able to do 
this with r.patch.  However, the photos only cover about half of the 
region.  In the remainder of the region, I would like to show a shaded 
relief map as a background to give context to the photos.  When I 
include the shaded relief map in the list to patch, it comes out as 
varying shades of red.  My question is therefore, what do I have to do 
to the shaded relief map to turn it into an 'rgb image' that I can 
include in r.patch.


2)  More generally, what is the best way of converting a good-looking 
map into a georeferenced image e.g. by converting the elevation data 
into rgb pixel colour data.  Currently I would use d.out.file then 
gdal_translate, but that is dependent on the screen resolution.


Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
john.steven...@manchester.ac.uk 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] r.patch, images vs coloured elevation data, aerial photo mosaic

2009-02-16 Thread John Stevenson

Nikos Alexandris wrote:

On Mon, 2009-02-16 at 11:35 +, John Stevenson wrote:
  

Hi,

I have two questions, first a specific one, secondly a more general one.

1)  I have some aerial photos that I want to mosaic.  I am able to do 
this with r.patch.  However, the photos only cover about half of the 
region.  In the remainder of the region, I would like to show a shaded 
relief map as a background to give context to the photos.  When I 
include the shaded relief map in the list to patch, it comes out as 
varying shades of red.  My question is therefore, what do I have to do 
to the shaded relief map to turn it into an 'rgb image' that I can 
include in r.patch.



Do you really want to patch the shaed relief map along with the
orthophotos in one map? What about r.blend?

If you insist on patching, then, I think, you would need to create 3 new
versions of your shaded map which will correspond to R(ed), G(reen) and
B(lue), rescale them to 0,255 (r.rescale). Then you patch them with the
R, G and B mosaic's of the orthophotos and compose (r.composite) an RGB
map.

I would expect the shaded part to look grey-scaled since you will have
the same pixel value in all of the R, G and B layers. But I am 100% sure
that it will work.



  

Thanks Nikos,

In the end, I made a composite from the original shaded relief:

r.composite red=nesja_shade green=nesja_shade 
blue=nesja_shade levels=32 output=elev_shade_comp


then patched it with the photos:

r.patch 
input=p43_trimmed,p44_trimmed,p33_trimmed,elev_shade_comp  
output=aerial  

This gave me coloured aerial photos where the data exist, and a grey 
shaded relief map where they don't.


2)  More generally, what is the best way of converting a good-looking 
map into a georeferenced image e.g. by converting the elevation data 
into rgb pixel colour data.  Currently I would use d.out.file then 
gdal_translate, but that is dependent on the screen resolution.



What about d.out.file in=YourMap out=YourMap resolution=2 # or
resolution=4 ?

  


Good point.


Cheers

John



Kind regards, Nikos


  



--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
john.steven...@manchester.ac.uk 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Appropriate use of v.surf.rst (lidar data)

2009-02-11 Thread John Stevenson

Wesley Roberts wrote:

Dear Grass Users,

I am having trouble with interpolating a canopy height model using v.surf.rst 
and some lidar data. The lidar point density ranges from 5 - 8 points per meter 
squared. I know I can import the data using r.in.xyz but I would prefer to use 
an interpolation technique as opposed to a spatial average. I chose r.surf.xyz 
based on the paper written by Helena Mitasova, Lubos Mitas, and Russell S. 
Harmon. While the applications differ the use of a large data set with many 
points means dealing with the same issues. I ran the algorithm using default 
values and the result was a smooth moon-like surface not really approximating a 
plantation forest canopy (see link 2)

v.surf.rst input=areaone_4...@wesley layer=1 zcolumn=dbl_3 elev=Area1_4_def 
tension=40. segmax=40 npmin=300 dmin=0.05 dmax=0.25 zmult=1.0

Given that I am working with very dense data with a high number of points I 
then ran the algorithm with a smaller tension value (roughly 2.5) with an 
incrase in the maximum number of points per segment (decrese computation time) 
and I find that the interpolation is blocky in nature. (see link 3)

v.surf.rst input=areaone_4...@wesley layer=1 zcolumn=dbl_3 elev=Area1_4_def6 tension=2.5 smooth=0.0001 segmax=100 npmin=300 dmin=0.05 dmax=0.25 zmult=1.0 


Is the blockiness related to the increase in the maximum number of points in a 
segment i.e. segmax value?

I have also been looking at using R to do the interpolation using gstat or automap. Does anyone on the list have any 
advice with regards to methods to use for the interpolation of lidar canopy returns, with a view to creating a 3-D model
of the canopy. The website spatial-analyst (http://spatial-analyst.net) suggests the use of regression-kriging but 
I don't have any ancillary data besides height and intensity.


I have uploaded pics of the study area and interpolation results to flickr 
(everyone should have access to these)

Link 1
http://www.flickr.com/photos/35273...@n07/3271646498/
Link 2
http://www.flickr.com/photos/35273...@n07/3270854029/
Link 3
http://www.flickr.com/photos/35273...@n07/3270904761/

Many thanks for taking the time to read my post and for your valuable 
contributions
Wesley (I am using Grass 6.3.0 on Ubuntu Hardy Heron)


Wesley Roberts MSc.
Researcher: Earth Observation (Ecosystems)
Natural Resources and the Environment
CSIR
Tel: +27 (21) 888-2490
Fax: +27 (21) 888-2693

To know the road ahead, ask those coming back.
- Chinese proverb


  

Hi Wesley,

I've tried various methods for processing LiDAR data.  I have a few 
comments:


1) Play with the resolution of your map and try different settings.

2) r.in.xyz does give good results, so don't rule it out for first 
approximation, and to help decide the resolution that you need.


3) r.surf.nnbathy might do the trick, but I haven't tried it.

4) If I want to interpolate to a higher resolution that my data covers, 
I usually krige in gstat.  I found that easier than learning how to use 
R on top of everything else. 

The examples on p348-353 of the GRASS Book are easily adapted to your 
own data.

(http://www.springerlink.com/content/j21632/)

Note that the default method calculates a global variogram, which can 
take a long time with LiDAR data.  The examples on p53-54 of the gstat 
manual describe how you can limit the analysis to a local neighborhood 
or set a maximum number of points to include in each calculation and 
thus dramatically speed up the interpolation.

(http://www.gstat.org/gstat.pdf)

Later

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
john.steven...@manchester.ac.uk 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] r.neighbors, wide filtering

2008-12-04 Thread John Stevenson

Hi,

For my research, I am testing a mesh denoising algorithm on topographic 
data.  It smooths the surfaces much like using r.neighbors 
method=average or r.neighbors method=median, and, depending on 
settings,  gives similar results to r.neighbors when size 5.  The 
advantage of the algorithm is that it has some ability to preserve 
features.  In cases where more significant smoothing is necessary 
(r.neighbors size  5) it is much better at preserving minimum and 
maximum elevations etc as it converges on a stable solution for the 
smoothed landscape.


My question relates to understanding in which cases is it necessarily to 
smooth to such an extent?  From what I have seen e.g. taking speckle out 
of SRTM DEMs, smoothing by such extremes removes a lot of useful 
information and results in unrealistic surfaces.


Has anyone come across a situation/dataset or type of analysis where 
they need to smooth with r.neighbors (method=average/median, size  5)?  
I would be interested to know, and to see if this algorithm would be useful.


Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
[EMAIL PROTECTED] 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Tips for setting up an new FOSS-GEO-linux-box

2008-11-03 Thread John Stevenson

Hi,

I have some other tips for the setting up of a box.  I came as a new 
user to both GRASS and Linux at the same time so perhaps these tips 
would help people in a similar situation.


Instructions to install a load of GIS software on Ubuntu can be found here:

http://www.perrygeo.net/wordpress/?p=119

If you are working on a dual boot system, with Windows NTFS and Linux, 
and the main data are stored on the NTFS partition, then you need to 
mount it with yourself as the owner to be able to work on it in GRASS.  
The following entry in the /etc/fstab works:


/dev/sda3   /media/Windows   ntfs-3g 
umask=0002,uid=YOUR_LOGIN,gid=YOUR_GROUP,allow_other  00



I got most of my packages from the repositories, but installed the 
following from source:


gstat (http://www.gstat.org/) - Calculate variograms and interpolate by 
kriging

liblas (http://liblas.org/) - Read and write LiDAR data in LAS format

Cheers

John
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] How to install Grass into Ubuntu

2008-10-23 Thread John Stevenson

Hi Matt,

I'm using Grass on a dual-boot Vista/Xubuntu 7.10 machine.  It's mine, 
so my data live on the NTFS partition and I can mount it with me as the 
owner (and group).  It took me a while to figure it out, and now I can't 
remember how I did it, but my fstab entry looks like this:


/dev/sda3   /media/OS   ntfs-3g 
umask=0002,uid=mbessjs3,gid=mbessjs3,allow_other  00


Hopefully that works for you, too.

John


Matt B wrote:



On Thu, Oct 23, 2008 at 1:14 AM, Glynn Clements 
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:



Matt B wrote:

  Note that GRASS won't let you select a mapset as the current
mapset
  (where new files are stored) unless you own it. Write
permission isn't
  sufficient.
 
  If you are creating a location which is to be shared by multiple
  users, you either need to create a mapset directory for each user,
  owned by the user, or grant all such users write permission on the
  location directory so that they can create their own mapset
directory
  (which they will own).

 Thanks for the heads up on this Glynn, my problem is that I'm on
a dual boot
 system and I'm storing mapsets/data on an NTFS drive. It's being
 automatically mounted with the owner set as root and read/write
permission
 for everyone. If I put the data on the ext3 filesystem, it
works. I'll mess
 around with fstab and mount the data drive as the appropriate
user. Having
 said that it does seem to me that this sort of check is
doubling up.
 File permissions are usually run by the file system/OS. While
having a
 sanity check for read/write access is a good idea, checking
for ownership
 seems a little over the top. insert newby user disclaimer here.

AFAICT, the check exists because otherwise people grant group-write
permission to mapset directories without fully understanding the
consequences. In particular, you can end up being unable to modify,
rename or remove files because they reside in a directory created by
another user and lacking group-write permission.

The possibility of free-for-all filesystems (i.e. where not only are
all files and directories world-writable, but where any new files and
directories will always be world-writable) has only arisen recently.

The native Windows builds skip the ownership check, but Unix builds
will perform it regardless of the filesystem type. Unfortunately, I
don't know of any (robust and portable) way to detect when a Windows
filesystem is being used on Unix.

--
Glynn Clements [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]


After banging my head against the ntfs wall for a little while here 
(for some reason the guys who write the ntfs stuff also have some 
ideas on who should be allowed to mount / own filesystems and block 
devices).
While writing software for the lowest common denominator isn't 
necessarily a bad thing, including this sort of thing in the software 
to stop people overwriting others files does seem a little redundant 
and in my case annoying. I'll add another disclaimer in case someone 
points out that theres an easy fix for this as I'm the guy who can't 
get an ntfs partition mounted without it being owned by root (without 
recompiling stuff that would probably break on the next apt-get update).


I'll be running this from my somewhat smaller ext3 partition for the 
time being unless someone can point me at a don't do this check 
button (please, someone point me at that button).


Matt



___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
  



--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
[EMAIL PROTECTED] 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] gstat in a latlon location / exit+reenter grass from a script

2008-10-22 Thread John Stevenson

Hi,

I am using gstat within grass to calculate variograms.  It works very 
well in UTM locations, but now I need to use it in a lat-long location, 
which it doesn't support.  I am trying to think of a way round this and 
decided on the following strategy:


1- export the data to a text file (r.stats -1g)
2 - reproject the data in the text file to UTM (cs2cs)
3 - use gstat to calculate the variogram of the text file

This method works, provided that I run gstat outside of GRASS.  However, 
I would now like to run these calculations from a batch file.  I can 
imagine two ways of doing this, and these are my questions:


Option 1:  Trick gstat so that it thinks that it is running outside of 
GRASS so that it will let me input my data from a text file.  I tried 
unsetting some of the GRASS variables but this didn't work.  Is there a 
way that I can do this?


Option 2:  Get my shell script to exit from GRASS, run the gstat 
commands, then return to GRASS where it left off.  Is this way 
possible?  Alternatively, if I could get GRASS to run commands as if 
from another shell then that may work, too.


Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
[EMAIL PROTECTED] 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] SRTM data aliases in UTM

2008-10-06 Thread John Stevenson

Hi,

I have imported some tiles of 1 arcsecond SRTM data into GRASS 6.3 using 
r.in.srtm into a lat-long region.  Whenever I import them to a UTM 
region, res=30, I get aliasing problems.  This results in a grid of 
lines of jumps in elevation running through my data.


This happens when I use r.proj.  I have also tried generating a text 
file of UTM coordinates via r.stats -1g, and cs2cs.  Importing this as a 
raster or vector, and interpolating with r.surf.rst or v.surf.rst also 
give aliasing errors.


What is the best way round this?  Importing at a higher resolution?  How 
much higher?  My ultimate aim is to compare the SRTM with LiDAR data, so 
if possible I would like to use an exact interpolation where possible.


Cheers

John

--


Dr John Stevenson
Postdoctoral Research Associate
School of Earth, Atmospheric and Environmental Sciences
Williamson Building (Room 2.42)
University of Manchester
Manchester M13 9PL, UK
tel. +44(0)161 306 6585; fax. +44(0)161 306 9361;
[EMAIL PROTECTED] 


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] nnbathy

2008-09-23 Thread John Stevenson

Hi,

I am keen to try r.surf.nnbathy, but I cannot find the nn libraries 
online.  The link given in the instructions:


http://www.marine.csiro.au/~sak007

is dead.  Does anyone know where I can get them from now?

Cheers

John
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Making and Uploading Maps for Garmin Etrex Legend GPS - v.net.salesman

2008-08-13 Thread John Stevenson
Thanks to everyone for their help so far.  It seems like this is much 
less straightforward than I had expected.  I've looked into some of the 
options e.g. QLandkarte, cGISmapper and tried to upload a ready-made 
.img file but had problems with the port speed (I'm using a usb/serial 
converter to connect to the GPS).


As I am most interested in loading up my road data, I thought about 
putting them on as tracks.  I exported the vector map to kml, then used 
gpsbabel to convert to .gpx format.  I then edited this by hand to name 
the tracks and join all the parts into track segments.  Unfortunately 
when it loads up, all the segments get joined together so that the end 
of one road jumps onto the start of the next.  I think that either 
gpsbabel or my etrex don't support that feature.


So now I have a new plan:  is it possible to use v.net.salesman to 
export a single track that covers every road in my network and doubles 
back on itself to return to the start?  If so, can someone give me some 
pointers on how to do it - I'm still getting to grips with the vector 
format and don't really have a clue where to start.


Thanks,

John




Tom Russo wrote:

On Thu, Aug 07, 2008 at 10:12:08AM -0700, we recorded a bogon-computron collision of 
the [EMAIL PROTECTED] flavor, containing:
  
I see some room for confusion here. I think on Garmins the basemaps 
built-in maps are not vector format but raster format .img files.
So the short answer is you can't dump them on the way you're trying to, 
you need to convert them.



Try looking at cgpsmapper and GPSMapEdit.  Neither is open source, but 
both work under WINE on linux.  There's a Linux build of cgpsmapper, too.
These tools will let you create maps for your Garmin GPS from various vector 
data (with a lot of work).  See:


http://home.cinci.rr.com/creek/garmin.htm

for a walk through the process and links to the tools.

Since you've already imported your GPX files from gpsbabel into GRASS, you
can just export them as shapefiles for reading into GPSMapEdit.

GPSMapEdit will read shapefiles, but it's a bit of a chore to get it Just Right.There is 
talk about making an OGR output format that can handle the Polish
format used by cgpsmapper, but it ain't there yet.  I'm not aware of any
other tool than GPSMapEdit that can write Polish format from shapefiles.

HTH,
T.

  

John C. Tull wrote:

I've used gpsbabel for moving points, tracks, and routes to/from a 
Garmin GPSV.


http://www.gpsbabel.org

John

On Aug 7, 2008, at 5:17 AM, John Stevenson wrote:

  
I have digitised some points, roads and a lake in GRASS and would like 
to be able to upload them onto my Garmin Etrex Legend.


I have been able to use v.out.ogr format=kml to output the points, and 
can upload them to the GPS with gpsbabel.
However, I would like the roads and the lake to be loaded into the 
built-in maps.  I read a post on the GRASS mailing list archive that 
mentioned cGPSmapper, but it seems like this only works with ESRI 
shape files (v.out.ogr again) if you have one of the paid-for versions.


Is there any open source software that can do this?  Can GRASS export 
in a format that can be more easily converted to be compatible with 
the GPS?



  


___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Making and Uploading Maps for Garmin Etrex Legend GPS

2008-08-07 Thread John Stevenson
I have digitised some points, roads and a lake in GRASS and would like 
to be able to upload them onto my Garmin Etrex Legend.


I have been able to use v.out.ogr format=kml to output the points, and 
can upload them to the GPS with gpsbabel. 

However, I would like the roads and the lake to be loaded into the 
built-in maps.  I read a post on the GRASS mailing list archive that 
mentioned cGPSmapper, but it seems like this only works with ESRI shape 
files (v.out.ogr again) if you have one of the paid-for versions.


Is there any open source software that can do this?  Can GRASS export in 
a format that can be more easily converted to be compatible with the GPS?


Thanks

John
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] Georectify problem

2008-07-30 Thread John Stevenson

Moritz Lennert wrote:

On 30/07/08 02:00, Adam Dershowitz wrote:
The problem that I am running into is that only the middle half or so 
of the jpg is being rectified.  



Do I have to set some region or something to get it all to work?


Yep, exactly.

AFAICT, the georectify tool calls i.rectify with the -c flag (line 
1366 of gui/tcltk/gis.m/georect.tcl), which means Use curr. region 
settings in target location. So you need to set the correct location 
in the target location.


I'm not sure I understand why this is so. It would seem to be more 
intuitive to run without that flag and thus have i.rectify determine 
the smallest window which covers the image, because otherwise the 
user has to identify target region extents manually...


Michael, any special reason for using -c ?

Maybe this could be made into an option ?
I went through exactly the same problem this week on my first attempts 
on the georectify tool, and also wondered why it it chose those region 
settings.  I updated the wiki page last night to highlight the need for 
a suitable region.


Also, sometimes I found that it crashed when the target region was 
completely wrong because one of the intermediate stages was taking s=0 
w=0 and I was working in UTM with typical values of 40 and 710 
and a resolution of 2 m.  The resulting map must have been huge.


In the end I calculated the region that I would need manually and worked 
out the resolution from the number of pixels in the scanned image.  Does 
i.rectify calculate these, or if not, is that something that could be 
easily added?


Later

John
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] Compile add-ons instructions?

2008-07-04 Thread John Stevenson

Hi,

Are there any instructions on the wiki or elsewhere on how to compile 
Add-Ons?


I am using Grass 6.3.0 which I compiled from source and have downloaded 
the Add-Ons via SVN repository.  I would like to compile the 
i.landsat.acca module, but there is no configure file.  How do I do it?  
Do I have to recompile all of Grass with some extra configuration options?


Cheers,

John
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user