Re: [GRASS-user] v.breach available?

[Maciej Sieczka]

M S pisze:
I downloaded all the grass-addons, and didnt seen v.breach in the 
directory.  I also tried to download it as a specific module and I

get a message saying it doesnt exist.

"svn checkout https://svn.osgeo.org/grass/grass-addons/v.breach 
grass-addons/v.breach"


yields...

svn: URL 'https://svn.osgeo.org/grass/grass-addons/v.breach' doesn't
exist

Any suggestions?


It's here:

http://www.sieczka.org/programy_en.html

Maciek

--
Maciej Sieczka
http://www.sieczka.org

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

[GRASS-user] Re: v.breach addon

[Maciej Sieczka]

Luís Ferreira pisze:

On Mon, 2009-12-07 at 08:11 +0100, Maciej Sieczka wrote:

Luís Ferreira pisze:



I had to change some strings to make v.breach work on GRASS
6.4svn revision 39873, Ubuntu/Debian 9.10.



Can you send a diff (diff original_file your_file), as attachment?



Here is it :)


The problem with v.breach is down to v.parallel interface change in
v.parallel2 - option `distance' does not accept negative offsets
anymore, and introduces a new `side' option to distinguish left/right,
instead:

$ v.parallel in=lines out=lines_par dist=-1

ERROR: value <-1> out of range for parameter 
   Legal range: 0-1

@Devs: It would be cool if v.parallel could be changed to accept
negative offsets, for compatibility within 6.x line.

@Luís: I applied most your of patch. Thanks! Are you sure that's all
errors? I keep on getting warnings like:

WARNING: Unable to get point on line: cat = 1 offset = 2.831711 (line
 length = 0)

at v.segment calls in the script, and a crash at v.in.ascii.

Best,
Maciek

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

[GRASS-user] Re: grass-user Digest, Vol 44, Issue 41

[Michael Barton]

Thanks much. This is exciting news. I'll be looking forward to seeing  
how these turn out.


Michael

On Dec 13, 2009, at 10:00 AM, grass-user-requ...@lists.osgeo.org wrote:


From: Rich Shepard 
Subject: Re: [GRASS-user] Re: Hydroligics in grass
To: "grass-user@lists.osgeo.org" 
Message-ID:
   
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Sat, 12 Dec 2009, Michael Barton wrote:


I agree that it would be nice to have the Java-based "Horton machine"
modules available for the GRASS community. However, as is the case  
with

all truly open source projects, contribution to GRASS is voluntary.


Michael,

  Yup.

  I found a java to python translator (there are a few out there)  
and will
take a shot at producing working python code. Several years ago I  
switched

from C to python for our approximate reasoning models because of the
extensive mathematical and scientific tools available for python.  
While by
no means an expert, I can usually get things working, especially  
using the

wxPython GUI.

Rich




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

Re: [GRASS-user] Re: [GRASS-dev] DEM creation from stereo pairs

[Michael Barton]

Christoph,

Thanks for the information. I tried out stereo and your tutorial. I  
need to ask something, however. AFAICT, stereo xyz output for only the  
points that you click on in the 2 images. So, after calibration, if  
you click on 6 points, you get xyz coordinates for those 6 points and  
no more. That is, it does not create a regular grid of xyz points to  
use for DEM creation. Is this correct? Or am I missing something?


Note that I could see the xyz point output in the terminal-like  
window, but could not see the rendering because I can't determine how  
what to push on my Mac keyboard that it will recognize as alt-R.


Michael

On Dec 12, 2009, at 4:44 PM, grass-user-requ...@lists.osgeo.org wrote:


Date: Sun, 13 Dec 2009 00:39:04 +0100
From: Christoph H?gl 
Subject: Re: [GRASS-user] Re: [GRASS-dev] DEM creation from stereo
   pairs
To: grass-user@lists.osgeo.org
Message-ID: <200912130039.05207.c.ho...@gmx.net>
Content-Type: Text/Plain;  charset="iso-8859-1"

Am Samstag, 12. Dezember 2009 22:18:37 schrieb Hamish:

Hamish:

have a look at:
http://grass.osgeo.org/gdp/stereo-grass/

I'm pretty sure there was a FOSS conference paper on that
method a few years ago.


Michael:

Unfortunately, the requisite "stereo" package not only has
not been maintained since 1997 (according to the stereo-grass
page), but its web page has disappeared too.


the question is, how well did it work back then? working code
remains working code. :)

you might try to look for a copy of the website on archive.org,
if not maybe I or one of us has an old copy of the source
somewhere in the old dusty attic.


shrug
Hamish


Well, the package did work and sometimes still does.
it's job.

The accuracy of the process after tweaking it a bit for small  
rounding mishaps
is about 12 to 14 bits (16bits data input). In comparison a hugin- 
based
process achieves a little -literally- 1 bit more of accuracy at  
about 5 times
the amount of time for data preparation (human) and 3-fold data  
processing

time (cpu-time).

In the old times of stereo I even had to reduce resolution of the  
source

images in order to get them processed with 256M of RAM (8 Mega-Pixels
(3344x2508) down to 4 MP (2364x1772) at that time)

It still provided about pixel accuracy with regards to optical  
problems

(mirage/thermal inversion/turbulence of the air caused by heat/cold).

To make it more feasible:
Using a mounted camera 8 MP (which is common these days in this work  
field),
provides at a field of view of 45� a angular distance of about 48  
arc seconds
or about 1/75 of a degree which gives a accuracy of about 23cm at a  
distance
of 1000 meters. The atmospheric effect at that distance is way  
beyond (~ 3

meters)
If you are after taking photos in less ambitious way, let's say  
shooting an
excavation from 100m or less, the accuracy is -> 2.3cm at best,  
obviously
better near the center of field (less lens distortion, ...) and  
nearer to the

lens (less atmospheric (d)ef(f)ects).

Even if we take a sefety measure of factor 5 for each photo taken  
using a
shaky tripod or even factor 10 from a kite mounted camera and  
multiply all
worse effects instead of flattening out, the accuracy still exceeds  
most needs
at archeological sites (2.54cm = 1 inch) at distances of up to 25 m  
by a

factor of 8.

The worst case i had with stereo was a misplacement by 1.5m  at 100m  
distance
using scans of ballon-mounted photograph from the late 30ies  
combined with
a 2003 photo taken using 4MP camera. (BTW, the 4MP was the culprit  
in the end)


One of the miracles using stereo was the ability to revisit a place  
in the
desert by triangulation using stereo after 8 years with 30cm  
accuracy and
pretty unsharp joshua-trees in the background (at distances of ~15m  
and ~25m
unsharp, 6 team photos taken in front of a car, taking the rim as  
rule using a

4MP camera). GPS Data was misleading by 4-8 meters.

The main reason for using stereo is it's ability to combine  
different sorts of
source materials (plates/film/digital imagery) in pretty short time.  
(I use it
still as stated above for small projects, where only a few points in  
3d-space

need to be 'surveyed')
As stereo takes more than 2 pictures it is even more powerful than  
most

standard off-the-shelf commercial solutions.

The main reasons against it's use is the lack of automation in the  
process,
the lack of dedicated support (I'm not able to provide it, though  
stereo would
really deserve it) as well as the lack of camera/lens adjustment  
combined with

a really awful codebase.


Hope that helps a bit,
Christoph


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

Re: [GRASS-user] Re: Hydroligics in grass

[Joop Goedbloed]

On Sat, 12 Dec 2009, Michael Barton wrote:


> > I agree that it would be nice to have the Java-based "Horton machine"
> > modules available for the GRASS community. However, as is the case with
> > all truly open source projects, contribution to GRASS is voluntary.
>   
Michael,

   Yup.

   I found a java to python translator (there are a few out there) and will
take a shot at producing working python code. Several years ago I switched
from C to python for our approximate reasoning models because of the
extensive mathematical and scientific tools available for python. While by
no means an expert, I can usually get things working, especially using the
wxPython GUI.

Rich

Hi Users list

Im my point of view is not necessary to translate any module from jgrass to 
grass or visa versa

I'm using grass and jgrass beside each other and doing with the same session 
with the jgrass
Horton machine. the results are almost the same as in grass.

Here is the link to the results : dempng is the dem and j.png the 
jgrass results

Jgrass 

Joop Goedbloed


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

[GRASS-user] Re: Unable to open gridded data

[Hermann Peifer]

I never had any problems with importing ESRI grid data with GRASS 6.4. 

Just follow the Wiki page for the header and use r.in.gdal for importing the data. 


Hermann


 Original Message  
Subject: Re:Unable to open gridded data
From: Muhammad Rahiz 
To: 
Date: 13/12/2009 16:24



Thanks Hermann,

My original datafile has no colons. I've tried adding colon, removing 
colon, removing spaces etc but nothing works.


Muhammad Rahiz  |  Doctoral Student in Regional Climate Modeling
Climate Research Laboratory, School of Geography & the Environment   
Oxford University Centre for the Environment, University of Oxford

South Parks Road, Oxford, OX1 3QY, United Kingdom
Tel: +44 (0)1865-285194 Mobile: +44 (0)7854-625974
Email: muhammad.ra...@ouce.ox.ac.uk



Hermann Peifer wrote:

Illegal line in header
ncols: 180



My guess would be that the colon is the culprit. See also 
http://en.wikipedia.org/wiki/ESRI_grid



Hermann

 Original Message  
Subject: Unable to open gridded data
From: Muhammad Rahiz 
To: Date: 11/12/2009 10:07

 

Dear GRASS-users,

I'm new to GRASS although I'm not new to GIS. I can't seem to be able 
to load my gridded data into GRASS using r.in.arc.


The following error message appears

Illegal line in header
ncols: 180
"yllcorner" field missing from header
"xllcorner" field missing from header
"nrows" field missing from header
"ncols" field missing from header
"cellsize" field missing from header
"nodata_value" field missing from header
ERROR: Can't get cell header

The following is how the format  of the header of my gridded data 
looks like;


ncols 180
nrows 290
xllcorner -20
yllcorner -20
cellsize  5000
NODATA_value  -

Does anyone have any suggestions?

Thanks.

Muhammad




  

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



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

Re: [GRASS-user] Re: Hydroligics in grass

[Rich Shepard]

On Sat, 12 Dec 2009, Michael Barton wrote:


I agree that it would be nice to have the Java-based "Horton machine"
modules available for the GRASS community. However, as is the case with
all truly open source projects, contribution to GRASS is voluntary.


Michael,

  Yup.

  I found a java to python translator (there are a few out there) and will
take a shot at producing working python code. Several years ago I switched
from C to python for our approximate reasoning models because of the
extensive mathematical and scientific tools available for python. While by
no means an expert, I can usually get things working, especially using the
wxPython GUI.

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

[GRASS-user] Re: Unable to open gridded data

[Muhammad Rahiz]

Thanks Hermann,

My original datafile has no colons. I've tried adding colon, removing 
colon, removing spaces etc but nothing works.


Muhammad Rahiz  |  Doctoral Student in Regional Climate Modeling
Climate Research Laboratory, School of Geography & the Environment  
Oxford University Centre for the Environment, University of Oxford
South Parks Road, Oxford, OX1 3QY, United Kingdom
Tel: +44 (0)1865-285194  Mobile: +44 (0)7854-625974
Email: muhammad.ra...@ouce.ox.ac.uk



Hermann Peifer wrote:

Illegal line in header
ncols: 180



My guess would be that the colon is the culprit. See also 
http://en.wikipedia.org/wiki/ESRI_grid


Hermann

 Original Message  
Subject: Unable to open gridded data
From: Muhammad Rahiz 
To: 
Date: 11/12/2009 10:07


  

Dear GRASS-users,

I'm new to GRASS although I'm not new to GIS. I can't seem to be able to 
load my gridded data into GRASS using r.in.arc.


The following error message appears

Illegal line in header
ncols: 180
"yllcorner" field missing from header
"xllcorner" field missing from header
"nrows" field missing from header
"ncols" field missing from header
"cellsize" field missing from header
"nodata_value" field missing from header
ERROR: Can't get cell header

The following is how the format  of the header of my gridded data looks 
like;


ncols 180
nrows 290
xllcorner -20
yllcorner -20
cellsize  5000
NODATA_value  -

Does anyone have any suggestions?

Thanks.

Muhammad




  

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

[GRASS-user] Re: Unable to open gridded data

[Hermann Peifer]

Illegal line in header
ncols: 180


My guess would be that the colon is the culprit. See also 
http://en.wikipedia.org/wiki/ESRI_grid


Hermann

 Original Message  
Subject: Unable to open gridded data
From: Muhammad Rahiz 
To: 
Date: 11/12/2009 10:07



Dear GRASS-users,

I'm new to GRASS although I'm not new to GIS. I can't seem to be able to 
load my gridded data into GRASS using r.in.arc.


The following error message appears

Illegal line in header
ncols: 180
"yllcorner" field missing from header
"xllcorner" field missing from header
"nrows" field missing from header
"ncols" field missing from header
"cellsize" field missing from header
"nodata_value" field missing from header
ERROR: Can't get cell header

The following is how the format  of the header of my gridded data looks 
like;


ncols 180
nrows 290
xllcorner -20
yllcorner -20
cellsize  5000
NODATA_value  -

Does anyone have any suggestions?

Thanks.

Muhammad



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

R: [GRASS-user] r.rescale categories definition

[Aldo Clerici]

Glynn,
tanks for your detailed explanations. As an ordinary user I was a bit
confused in looking the command results and trying to find an explanation in
the manual pages. 
For my purposes I would prefer an equal classes subdivision but probably
there is some effective reason for such kind of classes definition. I'm not
able to evaluate it. 
If the current computation is necessary (or not modifiable) couldn't be
useful to warn the user about the specific (and probably unexpected) way the
categories are computed (may be in the manual)? 

Best regards
A.Clerici

 

-Messaggio originale-
Da: Glynn Clements [mailto:gl...@gclements.plus.com] 
Inviato: sabato 12 dicembre 2009 17.59
A: Aldo Clerici
Cc: grass-user@lists.osgeo.org
Oggetto: Re: [GRASS-user] r.rescale categories definition


Aldo Clerici wrote:

> Dear GRASS Users and Developers,
> I'm having some problem in understanding the categories resulting from
> r.rescale 
>  
> With:
> r.rescale in=elevation.dem from=1200,1500 to=1,2 out=elev.resc
>  
> I have this result:
> 1   1200 thru 1349
> 2   1350 thru 1500
>  
> Two categories with a range of 150 meters each.
>  
> But with a new three categories subdivision:
>  r.rescale in=elevation.dem from=1200,1500 to=1,3 out=elev.resc
> the result is:
> 11200 thru 1274
> 21275 thru 1424
> 31425 thru 1500
>  
> The first and last categories have a range of 75 meters and the second one
> of 150 meters. 
>  
> Similar result with a four categories subdivision:
> r.rescale in=elevation.dem from=1200,1500 to=1,4 out=elev.resc
>  
> 11200 thru 1250
> 21251 thru 1350
> 31351 thru 1450
> 41451 thru 1500
>   
> Categories 1 and 4 have a range of 50 meters, 2 and 3 a range of 100
meters.
>  
> It seems that the first and last categories have the half range of all the
> others ones. Is this correct? Shouldn't the range be the same for all
> categories?

This is a result of r.rescale rounding rather than truncating, so the
minimum and maximum input values are the midpoints of the first and
last intervals:

old_delta = old_max - old_min;
new_delta = new_max - new_min;
divisor = (float)new_delta / (float)old_delta;
...
for (cat = old_min; cat <= old_max; cat++) {
value = (int)(divisor * (cat - old_min) + new_min + .5);

You can get balanced intervals with:

#!/bin/sh
inmap=$1
outmap=$2
to_min=$3
to_max=$4
eval `r.info -r $inmap`
awk -vold_min=$min -vold_max=$max -vnew_min=$to_min -vnew_max=$to_max '
BEGIN {
  new_delta = new_max - new_min + 1
  old_delta = old_max - old_min + 1
  for (i = 0; i < new_delta; i++) {
lo = old_min + i * old_delta / new_delta
hi = old_min + (i+1) * old_delta / new_delta - 1
new = new_min + i
printf("%d thru %d = %d %d\n", lo, hi, new, lo)
  }
}' | r.reclass in=$inmap out=$outmap

E.g.:

./rescale.sh elevation.dem elev.resc 1 4

-- 
Glynn Clements 

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

R: [GRASS-user] r.rescale categories definition

[Aldo Clerici]

Glynn,
tanks for your detailed explanations. As an ordinary user I was a bit
confused in looking the command results and trying to find an explanation in
the manual pages. 
For my purposes I would prefer an equal classes subdivision but probably
there is some effective reason for such kind of classes definition. I'm not
able to evaluate it. 
If the current computation is necessary (or not modifiable) couldn't be
useful to warn the user about the specific (and probably unexpected) way the
categories are computed (may be in the manual)? 

Best regards
A.Clerici

 

-Messaggio originale-
Da: Glynn Clements [mailto:gl...@gclements.plus.com] 
Inviato: sabato 12 dicembre 2009 17.59
A: Aldo Clerici
Cc: grass-user@lists.osgeo.org
Oggetto: Re: [GRASS-user] r.rescale categories definition


Aldo Clerici wrote:

> Dear GRASS Users and Developers,
> I'm having some problem in understanding the categories resulting from
> r.rescale 
>  
> With:
> r.rescale in=elevation.dem from=1200,1500 to=1,2 out=elev.resc
>  
> I have this result:
> 1   1200 thru 1349
> 2   1350 thru 1500
>  
> Two categories with a range of 150 meters each.
>  
> But with a new three categories subdivision:
>  r.rescale in=elevation.dem from=1200,1500 to=1,3 out=elev.resc
> the result is:
> 11200 thru 1274
> 21275 thru 1424
> 31425 thru 1500
>  
> The first and last categories have a range of 75 meters and the second one
> of 150 meters. 
>  
> Similar result with a four categories subdivision:
> r.rescale in=elevation.dem from=1200,1500 to=1,4 out=elev.resc
>  
> 11200 thru 1250
> 21251 thru 1350
> 31351 thru 1450
> 41451 thru 1500
>   
> Categories 1 and 4 have a range of 50 meters, 2 and 3 a range of 100
meters.
>  
> It seems that the first and last categories have the half range of all the
> others ones. Is this correct? Shouldn't the range be the same for all
> categories?

This is a result of r.rescale rounding rather than truncating, so the
minimum and maximum input values are the midpoints of the first and
last intervals:

old_delta = old_max - old_min;
new_delta = new_max - new_min;
divisor = (float)new_delta / (float)old_delta;
...
for (cat = old_min; cat <= old_max; cat++) {
value = (int)(divisor * (cat - old_min) + new_min + .5);

You can get balanced intervals with:

#!/bin/sh
inmap=$1
outmap=$2
to_min=$3
to_max=$4
eval `r.info -r $inmap`
awk -vold_min=$min -vold_max=$max -vnew_min=$to_min -vnew_max=$to_max '
BEGIN {
  new_delta = new_max - new_min + 1
  old_delta = old_max - old_min + 1
  for (i = 0; i < new_delta; i++) {
lo = old_min + i * old_delta / new_delta
hi = old_min + (i+1) * old_delta / new_delta - 1
new = new_min + i
printf("%d thru %d = %d %d\n", lo, hi, new, lo)
  }
}' | r.reclass in=$inmap out=$outmap

E.g.:

./rescale.sh elevation.dem elev.resc 1 4

-- 
Glynn Clements 

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