[GRASS-user] r.stream.order export to shapefile
Markus Metz
markus.metz.giswork at gmail.com
Sun Sep 2 05:33:26 PDT 2012
On Wed, Aug 29, 2012 at 1:28 PM, Micha Silver <micha at arava.co.il> wrote:
> Hi Markus,
> Thanks for responding. I still can't seem to get this to work.
> Here are my steps:
>
>> r.stream.extract elev=dtm thresh=500000 stream_rast=stream_500
>> stream_vect=stream_500 dir=fdir_500
>> r.stream.order stream=stream_500 dir=fdir_500 table=stream_order
>> v.db.connect map=stream_500 driv=sqlite table=stream_order key=cat layer=2
>
> Here I get:
> The table <stream_order> is now part of vector map <stream_500> and may be
> deleted or overwritten by GRASS modules
> DBMI-SQLite driver error:
> Cannot create index:
> create unique index stream_order_cat on stream_order ( cat )
> index stream_order_cat already exists
>
> WARNING: Cannot create index
> Select privileges were granted on the table
>
> Next:
>> v.category stream_500 opt=report layer=2
> Layer/table: 1/stream_500
> type count min max
> point 248 1 237
> line 237 1 237
> boundary 0 0 0
> centroid 0 0 0
> area 0 0 0
> all 485 1 237
> Layer/table: 2/stream_order
> type count min max
> point 248 0 2
> line 237 0 1
> boundary 0 0 0
> centroid 0 0 0
> area 0 0 0
> all 485 0 2
>
> Why in layer 2 are there only 2 cat values?
Because
"In layer 1, categories are unique IDs,
identical to the cell value of the raster output. The attribute table
for layer 1 holds information about the type of stream segment: start
segment, or intermediate segment with tributaries. Columns are cat int,
stream_type varchar(), type_code int. The encoding for type_code is 0 =
start, 1 = intermediate. In layer 2, categories are identical to
type_code in layer 1 with additional category 2 = outlet for outlet
points. Points with category 1 = intermediate in layer 2 are at the
location of confluences."
> Shouldn't I get all the cats as
> in layer 1 when I use "key=cat" in the v.db.connect??
No, v.db.connect connects a table to a vector layer. It does not
modify the vector layer.
> Do I need to delete
> and recreate the cats in layer 2 ?
No. Simply connect the table to layer 1, this should give you the
desired result.
>
> And finally, the export:
> GRASS 6.4.2 (ITM):~/GIS/DEM/LIDAR_EinYahav > v.out.ogr -c -e stream_500
> type=line dsn=stream_500.shp layer=2
> WARNING: 248 point(s) found, but not requested to be exported. Verify
> 'type' parameter.
> Exporting 485 geometries...
> WARNING: 124 features without attributes were written
> v.out.ogr complete. 237 features written to <stream_500> (ESRI_Shapefile).
>
> Why am I getting 485 geometries?
This is probably a bogus message. There are a total of 485 geometries
in the vector, 248 points and 237 lines. As the last message of
v.out.ogr says, 237 features were written.
> and why are 124 with no attributes?
Because you exported layer 2, where cat=0 is a valid cat, but the
table you attached to layer 2 does not have an entry for cat=0.
Markus M
>
>
>
> On 08/28/2012 11:15 PM, Markus Metz wrote:
>>
>> On Tue, Aug 28, 2012 at 9:05 PM, Micha Silver<micha at arava.co.il> wrote:
>>>
>>> A few more details regarding v.out.ogr when layer=2
>>> I see this ticket, possibly similar:
>>> http://trac.osgeo.org/grass/ticket/991
>>>
>>> I tried to export to PostGIS, and again, all attribute fields are created
>>> but all values are NULL. I also tried with the layer 2 database as a dbf
>>> file, instead of sqlite. Same result.
>>>
>>> This was all with GRASS 6.4.2 on scientific linux 6
>>
>> What does v.category op=report say? Are there any categories in layer
>> 2? If not, there is nothing to export.
>>
>> Markus M
>>
>>> Thanks,
>>> Micha
>>>
>>>
>>> On 08/28/2012 02:57 PM, Micha Silver wrote:
>>>
>>> I'm having two problems when exporting the output of r.stream.order to a
>>> shapefile.
>>> I have attached the created table (saved in my setup in sqlite) to the
>>> 'streams' map thru layer 2. Then
>>> v.db.select streams layer=2
>>> shows all the details of strahler order, prev_str, etc.
>>>
>>>
>>> First problem: When I try to do v.out.ogr, the column header named
>>> "next_stream" fails because it's 10 characters long, too long for a
>>> shapefile dbf. As a result all attributes are missing. Here's a patch to
>>> io.c in r.stream.order I put in place to correct this:
>>>
>>> [micha at SL6 r.stream.order]$ diff -u io.c.orig io.c
>>> --- io.c.orig 2012-08-28 12:21:46.020275045 +0300
>>> +++ io.c 2012-08-28 12:22:17.951382882 +0300
>>> @@ -292,7 +292,7 @@
>>> /* table definition */
>>> char *tab_cat_col_name = "cat integer";
>>> char *tab_stream = "stream integer";
>>> - char *tab_next_stream = "next_stream integer";
>>> + char *tab_next_stream = "next_str integer";
>>> char *tab_prev_streams;
>>> char *tab_strahler = "strahler integer";
>>> char *tab_horton = "horton integer";
>>> @@ -300,7 +300,7 @@
>>> char *tab_hack = "hack integer";
>>> char *tab_length = "length double precision";
>>> char *tab_cumlength = "cum_length double precision";
>>> - char *tab_stright = "stright double precision";
>>> + char *tab_stright = "straight double precision";
>>> char *tab_fractal = "fractal double precision";
>>> char *tab_distance = "out_dist double precision";
>>> char *tab_topo_dim = "topo_dim integer";
>>>
>>> (Also corrects a small typo in the column name "stright")
>>>
>>> After recompiling, then rerunning the r.stream.order addon, the sqlite
>>> table
>>> now has all column headers<= 10 characters suitable to shapefile.
>>>
>>>
>>> Problem 2, where I'm stuck. I export the vector map using :
>>> v.out.ogr streams layer=2 dsn=streams.shp
>>> The process finishes OK, and the shape is created with all attrib
>>> columns,
>>> but *all* values are NULL (including the cat). Any ideas what I've done
>>> wrong?
>>>
>>> Thanks,
>>> Micha
>>>
>>>
>>> This mail was received via Mail-SeCure System.
>>>
>>>
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>>> This mail was received via Mail-SeCure System.
>>>
>>>
>>>
>>>
>>> --
>>> Micha Silver
>>> GIS Consultant, Arava Development Co.
>>> http://www.surfaces.co.il
>>>
>>>
>>> _______________________________________________
>>> grass-user mailing list
>>> grass-user at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/grass-user
>>>
>> This mail was received via Mail-SeCure System.
>>
>>
>
More information about the grass-user
mailing list