On Wed, Aug 29, 2012 at 1:28 PM, Micha Silver <mi...@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<mi...@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@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@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@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> This mail was received via Mail-SeCure System. >> >> > _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user