[GRASS-user] r.stream.order export to shapefile
Markus Metz
markus.metz.giswork at gmail.com
Tue Sep 4 03:40:36 PDT 2012
On Mon, Sep 3, 2012 at 9:53 AM, Micha Silver <micha at arava.co.il> wrote:
> Hi Markus:
> Again, many thanks for the detailed explanation.
>
> I am using your suggestion: v.db.connect -o to overwrite and connect the
> r.streams.order table to the streams vector thru layer 1, overwriting the
> original connection. Works fine.
> I guess if I had used layer=3 from the start it would also work correctly?
No, because the vector output of r.stream.extract has categories only
in layer 1 and 2. There are no categories in layer 3, thus attributes
in a table attached to layer 3 are ignored. You can copy attributes
from one layer to another with v.category option=transfer, though.
Markus M
>
>
> BTW: I missed the section you quoted from the man page, because I got no man
> page when compiling the extensions. The error was:
>
> sudo make MODULE_TOPDIR=/usr/local/grass-6.4.2/
> ....
> <compile goes OK>
> ....
> GRASS_PERL=/usr/bin/perl VERSION_NUMBER=6.4.2 sh
> /usr/local/grass-6.4.2//tools/g.html2man
> /usr/local/grass-6.4.2/docs/html/r.stream.extract.html
> /usr/local/grass-6.4.2/man/man1/r.stream.extract.1 1
> /usr/local/grass-6.4.2//tools/g.html2man:
> /usr/local/grass-6.4.2//tools/g.html2man: is a directory
> make[2]: *** [/usr/local/grass-6.4.2/man/man1/r.stream.extract.1] Error 126
> make[2]: Leaving directory
> `/home/micha/Downloads/grass-addons/r.stream.extract'
> make[1]: *** [mancmd] Error 2
> make[1]: Leaving directory
> `/home/micha/Downloads/grass-addons/r.stream.extract'
> make: *** [cmd] Error 2
>
> The g.html2man perl script is *under a directory* also called g.html2man. Is
> that correct? Do I need to change something in the addon Makefile?
>
> Cheers,
> Micha
>
>
> On 09/02/2012 03:33 PM, Markus Metz wrote:
>>
>> 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.
>>>>
>>>>
>> This mail was received via Mail-SeCure System.
>>
>>
>
More information about the grass-user
mailing list