[GRASS-user] Contour lines extraction

GRASS GRASS user
1

Hi all,
I need to extract some contour lines from a vector map (imported with v.in.dwg -z). While I can do this on the base of their category, it would be easier to directly select the desired elevations, but I don’t know how to refer to them. With d.what.vect I obtain the following textual output:

GRASS 6.1.cvs (Valledaosta):/media/sda7/zodoardo/cartografia > d.what.vect -x ma p=dwg0351
Building spatial index …
100%

Buttons
Left: what’s here
Right: quit

405718.49528848(E) 5051089.77547112(N)

dwg0351 in zodoardo Line
length 4098.283965
Line height: 560.000000
Layer: 1
category: 15833
driver: dbf
database: //media/sda7/zodoardo/cartografia/grassdb/Valledaosta/zodoardo/dbf/
table: dwg0351
key column: cat
cat : 15833
entity_nam : POLYLINE
color : 256
weight : -1
layer : 12L04
block :
txt :
Done.

The problem is that “Line height” doesn’t appear in the dbf table.
What can I do?

Thanks.

Odoardo

Odoardo Zecca
Institut Agricole Régional
Aosta (It)

2

Thanks for your prompt reply, Luca.
Unfortunately it doesn’t work: I started importing without the z flag and, as you can see, didn’t obtain any information about elevations.

GRASS 6.1.cvs (Valledaosta):/media/sda7/zodoardo/cartografia > d.what.vect -x ma p=noz0351
Building spatial index …
100%

Buttons
Left: what’s here
Right: quit

406529.90978316(E) 5051417.65316489(N)

noz0351 in zodoardo Line
length 2531.588789
Layer: 1
category: 15614
driver: dbf
database: //media/sda7/zodoardo/cartografia/grassdb/Valledaosta/zodoardo/dbf/
table: noz0351
key column: cat
cat : 15614
entity_nam : POLYLINE
color : 256
weight : -1
layer : 12L04
block :
txt :
Done.

On 7/20/06, Luca Casagrande <luca.casagrande@gmail.com > wrote:

I don’t know if the v.in.dwg works like v.in.ogr, but i think you don’t need the 3d flag…Try to remve it. In your example you need a 2d vector with z in the attribute table.

Bye
Luca

On 7/20/06, Odoardo Zecca <odoardo.zecca@gmail.com> wrote:

Hi all,
I need to extract some contour lines from a vector map (imported with v.in.dwg -z). While I can do this on the base of their category, it would be easier to directly select the desired elevations, but I don’t know how to refer to them. With d.what.vect I obtain the following textual output:

GRASS 6.1.cvs (Valledaosta):/media/sda7/zodoardo/cartografia > d.what.vect -x ma p=dwg0351
Building spatial index …
100%

Buttons
Left: what’s here
Right: quit

405718.49528848(E) 5051089.77547112(N)

dwg0351 in zodoardo Line
length 4098.283965
Line height: 560.000000
Layer: 1
category: 15833
driver: dbf
database: //media/sda7/zodoardo/cartografia/grassdb/Valledaosta/zodoardo/dbf/
table: dwg0351
key column: cat
cat : 15833
entity_nam : POLYLINE
color : 256
weight : -1
layer : 12L04
block :
txt :
Done.

The problem is that “Line height” doesn’t appear in the dbf table.
What can I do?

Thanks.

Odoardo

Odoardo Zecca
Institut Agricole Régional
Aosta (It)

grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

3

Odoardo Zecca napisa?(a):

Hi all,
I need to extract some contour lines from a vector map (imported with
v.in.dwg -z). While I can do this on the base of their category, it would
be easier to directly select the desired elevations, but I don't know
how to refer to them.

Maybe

add a x,y,z columns to your table (v.db.addcol)

populate it with coords (v.to.db option=coor)

now z coord is stored in table

?

Maciek

4

Thank you Maciej.

It seem to work only for points, but not for lines. Maybe this doesn’t work for lines because they don’t have a unique x and y but only a unique z, or am I doing something wrong?

On 7/20/06, Maciej Sieczka <tutey@o2.pl> wrote:

Odoardo Zecca napisa?(a):

Hi all,
I need to extract some contour lines from a vector map (imported with
v.in.dwg -z). While I can do this on the base of their category, it would
be easier to directly select the desired elevations, but I don’t know
how to refer to them.

Maybe

add a x,y,z columns to your table (v.db.addcol)

populate it with coords (v.to.db option=coor)

now z coord is stored in table

?

Maciek

5

On 7/21/06, Odoardo Zecca <odoardo.zecca@gmail.com> wrote:

Thank you Maciej.

It seem to work only for points, but not for lines. Maybe this doesn’t work for lines because they don’t have a unique x and y but only a unique z, or am I doing something wrong?

OK! the right option is ‘start’ (or ‘end’):

v.db.addcol map=cl6361 layer=1 “columns=x double precision,y double precision,z double precision”

v.to.db map=cl6361 type=line layer=1 qlayer=1 units=meters option=start column=x,y,z

Thank you very much, Maciej, this is an important step for may work!

6

Odoardo Zecca napisa?(a):

On 7/21/06, Odoardo Zecca <odoardo.zecca@gmail.com> wrote:

Thank you Maciej.

It seem to work only for points, but not for lines. Maybe this doesn't
work for lines because they don't have a unique x and y but only a
unique z,
or am I doing something wrong?

OK! the right option is 'start' (or 'end'):

v.db.addcol map=cl6361 layer=1 "columns=x double precision,y double
precision,z double precision"

v.to.db map=cl6361 type=line layer=1 qlayer=1 units=meters option=start
column=x,y,z

Thank you very much, Maciej, this is an important step for may work!

Glad I could help.

Best,
Maciek

7

I've been running this CVA analysis for two days straight on an AMD64 4400. The sites file contains one waypoint. The raster file is at 30 meter resolution. I'd don't have the extents of the raster file handy, but the site is near the edge, so you can estimate that CVA is looking at a half circle 2000 meters out, which if I did my math correctly is about 14k cells. No virtual memory is required as the CPU has 3.2Gbytes of ram.

r.cva input=nev616 sites=mtstircsv2 output=mtstircva2 obs_elev=1.75
target_elev=0.0 max_dist=2000 seed=1 sample=10.0 type=sites curvc=0.0

Does the run time seem reasonable? CVA provides no estimate of progress.

8

Some GRASS modules have extremely long runtimes, it'd probably be best to test the CVA analysis on a small region containing your site, monitor performance, and assume it will scale linearly from that estimate.

Shaun Walbridge

gary wrote:

I've been running this CVA analysis for two days straight on an AMD64 4400. The sites file contains one waypoint. The raster file is at 30 meter resolution. I'd don't have the extents of the raster file handy, but the site is near the edge, so you can estimate that CVA is looking at a half circle 2000 meters out, which if I did my math correctly is about 14k cells. No virtual memory is required as the CPU has 3.2Gbytes of ram.

r.cva input=nev616 sites=mtstircsv2 output=mtstircva2 obs_elev=1.75
target_elev=0.0 max_dist=2000 seed=1 sample=10.0 type=sites curvc=0.0

Does the run time seem reasonable? CVA provides no estimate of progress.

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

9

Just an FYI, the latest release of r.cva is supposed to report it's progress unless you select that it run quietly. I suspect I've got some other bug as it never reported anything in 3 days of execution. I started it again with a radius of 200 meter.

gary wrote:

I've been running this CVA analysis for two days straight on an AMD64 4400. The sites file contains one waypoint. The raster file is at 30 meter resolution. I'd don't have the extents of the raster file handy, but the site is near the edge, so you can estimate that CVA is looking at a half circle 2000 meters out, which if I did my math correctly is about 14k cells. No virtual memory is required as the CPU has 3.2Gbytes of ram.

r.cva input=nev616 sites=mtstircsv2 output=mtstircva2 obs_elev=1.75
target_elev=0.0 max_dist=2000 seed=1 sample=10.0 type=sites curvc=0.0

Does the run time seem reasonable? CVA provides no estimate of progress.

_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser

10

gary wrote:

I've been running this CVA analysis for two days straight on an AMD64
4400. The sites file contains one waypoint. The raster file is at 30
meter resolution. I'd don't have the extents of the raster file handy,
but the site is near the edge, so you can estimate that CVA is looking
at a half circle 2000 meters out, which if I did my math correctly is
about 14k cells. No virtual memory is required as the CPU has
3.2Gbytes of ram.

r.cva input=nev616 sites=mtstircsv2 output=mtstircva2 obs_elev=1.75
target_elev=0.0 max_dist=2000 seed=1 sample=10.0 type=sites curvc=0.0

Does the run time seem reasonable? CVA provides no estimate of
progress.

r.los runtime is ~exponential with number of cells in the region, I
expect r.cva has similar issues. Start out with 500x500 cells and go
finer until it takes too long to run. If I understand correctly, one of
the reasons that r.cva was written was because r.los was so incredibly
slow.

good luck,
Hamish

11

I was hoping that setting max_dist to be small would reduce the data. Otherwise, I need to figure out how to truncate my DEM.

Hamish wrote:

gary wrote:

I've been running this CVA analysis for two days straight on an AMD64 4400. The sites file contains one waypoint. The raster file is at 30 meter resolution. I'd don't have the extents of the raster file handy,
but the site is near the edge, so you can estimate that CVA is looking
at a half circle 2000 meters out, which if I did my math correctly is about 14k cells. No virtual memory is required as the CPU has
3.2Gbytes of ram.

r.cva input=nev616 sites=mtstircsv2 output=mtstircva2 obs_elev=1.75
target_elev=0.0 max_dist=2000 seed=1 sample=10.0 type=sites curvc=0.0

Does the run time seem reasonable? CVA provides no estimate of
progress.

r.los runtime is ~exponential with number of cells in the region, I
expect r.cva has similar issues. Start out with 500x500 cells and go
finer until it takes too long to run. If I understand correctly, one of
the reasons that r.cva was written was because r.los was so incredibly
slow.

good luck,
Hamish

12

On Sat, 22 Jul 2006, gary wrote:

I was hoping that setting max_dist to be small would reduce the data. Otherwise, I need to figure out how to truncate my DEM.

Ha ha no I remember from my experiences with r.los several years ago that the code performed the calculation anyway, then at the last minute checked if the point was within the max distance and if not discarded the result!! So max_dist doesn't affect the processing time at all and really just operates as a mask that you could create anyway afterwards with r.mapcalc if you needed it.

There is a fairly promising fast algorithm available that someone with an interest in the subject and good C programming skills could check out:
A fast algorithm for approximate viewshed computation
David Izraelevitz (TEC/Eng. Res. and Development Center, U.S. Army Corps of Engineers, SRI International)
Photogrammetric Engineering and Remote Sensing, v 69, n 7, Jul 1, 2003, pp 767-774
Would be a lot of work though to do it well.

Paul

13

Per Hamish's suggestion, I have resampled the raster map until I could get an output from r.cva. I had to reduce the resolution by a factor of 8. I don't want to interrupt the run, but that should be around 800x300 or so cells.

The output of the "sites" CVA was a solid yellow image, which I assume means everything was seen. I replaced "type=sites" with "type=all" and am rerunning at the moment.

Paul Kelly wrote:

On Sat, 22 Jul 2006, gary wrote:

I was hoping that setting max_dist to be small would reduce the data. Otherwise, I need to figure out how to truncate my DEM.

Ha ha no I remember from my experiences with r.los several years ago that the code performed the calculation anyway, then at the last minute checked if the point was within the max distance and if not discarded the result!! So max_dist doesn't affect the processing time at all and really just operates as a mask that you could create anyway afterwards with r.mapcalc if you needed it.

There is a fairly promising fast algorithm available that someone with an interest in the subject and good C programming skills could check out:
A fast algorithm for approximate viewshed computation
David Izraelevitz (TEC/Eng. Res. and Development Center, U.S. Army Corps of Engineers, SRI International)
Photogrammetric Engineering and Remote Sensing, v 69, n 7, Jul 1, 2003, pp 767-774
Would be a lot of work though to do it well.

Paul