[GRASS-user] Grass in openSuse-Build-service

Hello! Ich thought that i have seen the Grass-rpms in the openSuse Buildservice some time ago, but i cannot find them anymore for 11.0? Are they available there, so that they can be added as a repository? Or can i add the 'regular' source as a repository? Thank you! Uwe Seher

Re: [GRASS-user] Grass in openSuse-Build-service

Hi Uwe, On Tue, 29 Jul 2008 08:16:49 +0200 Uwe Seher [EMAIL PROTECTED] wrote: Hello! Ich thought that i have seen the Grass-rpms in the openSuse Buildservice some time ago, but i cannot find them anymore for 11.0? Are they available there, so that they can be added as a repository? Or

Re: [GRASS-user] r.watershed speed-up

Markus, Thank you very much! I have not tested it yet, but after I do I'll write you with my impressions. I think this could be a very valuable contribution. Regards, Tom Markus Metz wrote: Hello list, I'm not sure if this list is the right place or rather the developer list. For the A *

Re: [GRASS-user] r.terraflow

Il giorno mar, 29/07/2008 alle 02.22 +0200, G. Allegri ha scritto: Thanks Luca. The coding mapping seems correct. So, zeroes are for unsolved pixels... I'll do some tests to compare the results with r.watershed. At now they seem quite different. I'm not sure if I should trust onflow

Re: [GRASS-user] r.terraflow

Ivan et al, Below are some snippets from an email thread in 2005: Has anyone had any luck using the results from r.terraflow in r.water.outlet? More specifically I want to use the output direction grid from r.terraflow for the drainage direction map input of r.water.outlet. The

Re: [GRASS-user] r.terraflow

Thanks Thomas. I think we should put these on the wiki... When I find time. I understand the coding scheme, but reclassifying from directions r.terraflow scheme to the r.watershed one yealds significative differences, and r.water.outlut works bad with the r.terraflow results... The main problem

[GRASS-user] r.watershed speed-up

First results of one test I did: excellent!!! 1392776 cells dem with steep slopes but also plain areas r.watershed.fast: 7 seconds r.watershed: 4 min and 14 seconds no difference at all between the two generated network paths... markus: many thanks.. Ivan Il giorno lun, 28/07/2008 alle

Re: [GRASS-user] r.watershed speed-up

Ivan anticipated me for a bit. GREAT Markus! I could crunch Sardinia in one shot. I haven't measured the time but it was less then 2 minutes, while with r.watershed I got stalled. Analyzing the differences between the r.watershed and r.watershed.fast for a narrower region, there was some subtle,

Re: [GRASS-user] r.watershed speed-up

Yes, there are some differences. Please look at where these differences are located and if they are significantly changing the results. In flat areas, there will be several possibilities about how water could flow. This might also affect the flowpath further upstream. Both the original version

Re: [GRASS-user] r.watershed speed-up

We're definitely interested in giving this a try too. Michael C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Phone: 480-965-6262 Fax:

Re: [GRASS-user] r.watershed speed-up

On 28/07/08 23:14, Markus Metz wrote: Hello list, I'm not sure if this list is the right place or rather the developer list. For the A * Search algorithm in r.watershed (memory version without -m flag set, r.watershed.ram), I implemented a binary min-heap instead of a linear array to store

RE: [GRASS-user] r.watershed speed-up

Dear Markus and other r.watershed enthusiasts, I've thought of a way to make your faster version of r.watershed give identical results as the older r.watershed. r.watershed.old uses a breadth first search in section 2. r.watershed.fast is breadth first when the DEM values are different. The trick

Re: [GRASS-user] r.watershed speed-up

Dear Chuck, r.watershed is a much valued tool in GRASS, for me the best watershed analsis tool not only in GRASS, therefore I thought about a a way to keep the results identical too. I am also aware that the closer the results produced by changes in the algorithm are to the results produced

[GRASS-user] Re: import a folder full of shapefiles and reproject on-the-fly?

Hello, Here you can find some scripts, perhaps useful. Thanks you for these scripts. They are really useful. Nevertheless, I cannot get around expressing my disappointment about GRASS in this area. * I cannot just point the program to a directory of shapefiles and tell it import all. QGIS,

[GRASS-user] calibrating a interpolated or contour map

Hello, what methodes are recommended to use within GRASS to calibrate a map with by using geostatistical methods? OK, normally the method depends on the kind of data. Therefore I may give an example: I have long-term meteorological mesurement data (timeseries aggregated to monthly frequency)

[GRASS-user] how to speed of map generation with ps.map?

Hello, for my current project I would like to create some postscript maps. When I run ps.map it takes a lot of time. I use a DEM as raster layer and country borders as vector layer on top of it. The DEM covers two SRTM tiles. Is there any way to speed the process up? How do I best set the

Re: [GRASS-user] calibrating a interpolated or contour map

On Tuesday 29 July 2008, Tim Michelsen wrote: Hello, what methodes are recommended to use within GRASS to calibrate a map with by using geostatistical methods? OK, normally the method depends on the kind of data. Therefore I may give an example: I have long-term meteorological mesurement

Re: [GRASS-user] Re: import a folder full of shapefiles and reproject on-the-fly?

Tim Michelsen pisze: Nevertheless, I cannot get around expressing my disappointment about GRASS in this area. * I cannot just point the program to a directory of shapefiles and tell it import all. QGIS, gvSIG and ArcGIS can do this. Well, true. I clearly remember how frustrating it was for

Re: [GRASS-user] r.watershed speed-up

I just want to note something very tactfully mentioned below. That is, all such algorithms are estimates of real watershed behavior. AFAICT, r.watershed produces a very good estimate of these parameters and dynamics. Nevertheless, we should be careful about trying to exactly replicate its

Re: [GRASS-user] how to speed of map generation with ps.map?

On Tuesday 29 July 2008, Tim Michelsen wrote: Hello, for my current project I would like to create some postscript maps. When I run ps.map it takes a lot of time. I use a DEM as raster layer and country borders as vector layer on top of it. The DEM covers two SRTM tiles. Is there any way

Re: [GRASS-user] Re: import a folder full of shapefiles and reproject on-the-fly?

GRASS'ers: Although I don't echo Tim's dissapointment with GRASS (I use it routinely and wouldn't trade it for the world), I do agree that GRASS is more programmer-friendly than casual-user friendly environment. GRASS reminds me, in many ways, of Arc/Info (pre-ArcMap, the 'ol command line

[GRASS-user] Georectify problem

I am having a problem with the georectify tool that is probably obvious to someone who is more familiar with the tool. I have a jpg that I want to georectify into another mapset. I imported that jpg into an xy mapset and then followed the steps in the georectify tool help (I am using 6.3 on

Re: [GRASS-user] Re: import a folder full of shapefiles and reproject on-the-fly?

Tim Michelsen ha scritto: Nevertheless, I cannot get around expressing my disappointment about GRASS in this area. * I cannot just point the program to a directory of shapefiles and tell it import all. QGIS, gvSIG and ArcGIS can do this. So, use QGIS! ;) Seriously, I understand your

Re: [GRASS-user] r.soils.texture

Hy, I'm afraid but I can't help you. But you can try r.soil.texture for your area: 1. import in grass soils sample point with sand and clay atttributes; 2. interpolate sand a nd clay surface with one algorithm available in grass (or with R interface for geostatistica analisys) 3. run