On Sun, Mar 7, 2010 at 8:50 PM, Dwight Needels <need...@translucida.com> wrote: > On Mar 7, 2010, at 2:10 PM, Markus Neteler wrote: >> On Sun, Mar 7, 2010 at 7:13 PM, Dwight Needels <need...@translucida.com> >> wrote: >>> I have a 3D vector [test_3D] created using v.drape, confirmed as 3D with >>> v.info. I used v.split to split the polyline at the vertices: >>> >>> v.split input=test_3D output=test_3D_split vertices=2 >>> >>> The resulting vector [test_3D_split] is a 2D vector (i.e. it lost the z >>> geometry data according to v.info, and v.to.db reports all slopes = 0). ... > Markus, I would appreciate if you would be able to compile and test for me. > Here is a Spearfish example that shows the same behavior (using v.info to > test 2D/3D vector status). > > v.drape input=t_hydro rast=elevation.dem output=t_hydro_3D method=cubic > v.split input=t_hydro_3D output=t_hydro_split vertices=2
Looks good: v.info t_hydro_split | grep 3D | Map is 3D: Yes ##### orig map v.to.db -p t_hydro option=slope Reading features... 100% cat|slope -1|0 0 categories read from vector map (layer 1) 0 records updated/inserted (layer 1) # draped map v.to.db -p t_hydro_3D option=slope Reading features... 100% cat|slope -1|-6.16016389653397 0 categories read from vector map (layer 1) 0 records updated/inserted (layer 1) # split map v.to.db -p t_hydro_split option=slope Reading features... 100% cat|slope -1|-96.9755874160899 0 categories read from vector map (layer 1) 0 records updated/inserted (layer 1) -> is that right? maybe there is some cat mess in the original map? # 3D view: v.info t_hydro_split | grep B | B: 1085.64427482 T: 1698.36345331 -> reasonable r.mapcalc "bottom = 1085" nviz bottom vect=t_hydro_split -> nice 3D vector lines Markus _______________________________________________ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user