Re: [GRASS-user] Control of camera position in NVIZ
Hi, On Wed, Feb 29, 2012 at 8:07 AM, Maris Nartiss wrote: > Hello, > it's possible to control NVIZ from a script. You can export Your road > via v.out.ascii and use the road vertices to set camera position and > the next vertice to set a point where camera points to. > > I have been playing around with it some time a go. There might be a > better way now thanks to recent developments in NVIZ scripting > capabilities, still I'm attaching an old TCL script file that I was I suggest you to look at m.nviz.image module [1] and its parameters - position, height, perspective, focus. You can also try integrated 3D view in GRASS 6.5 and 7 [2][3], there is a limited way of creating animation. It is able to generate command for m.nviz.image too. Anna [1] http://grass.osgeo.org/grass70/manuals/html70_user/m.nviz.image.html [2] http://grass.osgeo.org/wiki/WxNviz [3] http://grass.osgeo.org/grass65/manuals/html65_user/wxGUI.Nviz.html ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Control of camera position in NVIZ
Hello, it's possible to control NVIZ from a script. You can export Your road via v.out.ascii and use the road vertices to set camera position and the next vertice to set a point where camera points to. I have been playing around with it some time a go. There might be a better way now thanks to recent developments in NVIZ scripting capabilities, still I'm attaching an old TCL script file that I was using to create animation of fly over a lake while changing a lake level by loading it from a raster map created by r.lake. If You are familiar a bit with TCL, You will be able to change that script to just move camera instead of moving camera and changing raster map too. Good luck, Maris. 2012/2/29 Patrick Proffitt : > Using NVIZ, I have been able to visualize a segment of roadway my research > group scanned with LiDAR. The visualization is perfect for what we are > looking for, but there are two things we'd like to do next that I am having > difficulty with. > > 1) We'd like to make an animation of the roadway from a drivers POV. Using > the visualization utilities in NVIZ I have been able to manually adjust the > viewing perspective of the visualization to a point that looks good, as in > it looks like what the driver would see if they were in a vehicle and the > vehicle was on the edge of the visualized surface (or very close to it). > However is there anyway to advance the camera forward, again as if on a > vehicle, as if it's driving ON the roadway? From what I can tell, the > 'camera', or POV for viewing the visualized surface, can be anywhere on a > radius away from the surface, however I cannot make the camera advance to > hover over part of the visualized surface. I can get a good POV shot for a > vehicle about to get started on the roadway, but not for driving across it. > I'd like to make an animation with frame 1 being what I have now, but frame > 2 etc being that exact same orientation, but with the camera having > 'advanced' down the roadway. I cannot seem to make frames 2 onwards. > > 2) In the future we'd like to collect camera images of the driver's POV > looking out the front windshield, so that we'd have an image from the > orientation we'd like to see. Right now I am adjusting the angles until it > 'looks good' - is there anyway to use this out-the-windshield image to > EXACTLY align the visualization into that orientation so that the image and > the visualization are identically aligned? I am also aware of the > orthophoto utilities in GRASS, however without these images I have been > unable to play with that. Will orthophoto do this? > > I recently found POV-Ray which I will be playing with shortly, but I'm > curious as to if anyone else has had these same needs and if so how you > worked with it. > > Thanks! > > Patrick > > ___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > # How it works: # 1) Create NVIZ state file; # 2) Copy surface ID that You will change (in this example it is lake with changing water level); # 3) Set camera position; # 4) Play script in NVIZ. # # This script is based on d.nviz output. I wrote it a year(?) a go and now wonder - how it is # possible that it works? # Anyway - a good beginning for creating own, custom animation script. # # Maris, 05. 02. 2007. # # This is really ugly! # Maris, 09. 08. 2007. # # NVIZ state file SendScriptLineWait "load_state_aux /some/path/to/nviz_state3" script_play puts "Starts... "; set FRAMES 264; # surf*foo is random generated when loading surface. Some normal way must exist, # currently it is copied from state file. (Lake surface ID in nviz state file) set mhandle3 [ReturnMapHandle surf*1138896892]; # More info in source: # src/vizualisation/nviz/anim_support.c SendScriptLine "Nclear_keys" SendScriptLine "Nupdate_frames" SendScriptLine "Nset_numsteps $FRAMES" SendScriptLine "Nupdate_frames" #SendScriptLine "Nset_interp_mode linear" SendScriptLine "Nset_interp_mode spline" SendScriptLine "Nset_tension 0.1" SendScriptLine "Nupdate_frames" # Single camera position with real coordinates # Use d.where or similar to get camera positions # position.c - RTFM :) ## Camera position (last is Z) SendScriptLine "Nmove_to_real 584633.854316 6409321.829185 90" ## Camera target SendScriptLine "Nset_focus_real 573750.33564192 6401754.65674798 55" ## Create keyframe. First integer sets interval between keyframes SendScriptLine "Nadd_key 1 KF_ALL_MASK 1 0.0" SendScriptLine "Nmove_to_real 591744.816528 6402709.021853 280" SendScriptLine "Nset_focus_real 573750.33564192 6401754.65674798 55" SendScriptLine "Nadd_key 2 KF_ALL_MASK 1 0.0" SendScriptLine "Nmove_to_real 590487.090928 6392080.094127 600" SendScriptLine "Nset_focus_real 573750.33564192 6401754.65674798 55" SendScriptLine "Nadd_key 3.5 KF_ALL_MASK 1 0.0" SendScriptLine "Nmove_to_real 580760.958497 6386028.557726 1000" SendScriptLine "Nset_focus_real 573750.33564192
Re: [GRASS-user] GRASS 7 Bottleneck
Hello, the reasons for slow performance can be different. If performance concerns You, You should perform Your module run profiling. Take a look at http://valgrind.org/info/tools.html >From Your description is hard to tell where's the problem - as it might be a disk write - those are more expensive than reads; it could be inefficient memory allocation, cache misses etc. Also 16 CPU's don't change a thing, as most of GRASS code is single threaded - unless You run Your module in parallel (data parallelization), You will use only one CPU/core. Ensure that You don't hit swap, as it will bring any fast system down on it's knees. Not helpful, Maris. 2012/2/28 Seth Price : > I'm running a few instances of GRASS, and I've hit an extreme bottleneck. The > problem is that I can't figure out what it is. > > I have a module that I wrote in the GRASS 7.0 environment that should be I/O > bound. It normally takes about 10 minutes to finish running. I have seven > instances running from one disk, and each one is taking on the order of 10 > hours to finish. Why? > > NOTE: > - The processes aren't I/O bound. 'iostat' lists a constant 30 MB/s transfer > rate. It should be able to handle twice that. The transfers per second are < > 100, and I've seen it handle triple that (at 60 MB/s). > - The load average is currently below 1. I have 16 processors, so CPU > shouldn't be a problem. > - I have 16 GB of RAM, and it's full, but not thrashing. > > If it's not I/O, CPU, or RAM, then what is it slowing GRASS? > Thanks, > Seth___ > grass-user mailing list > grass-user@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] How we can Import data using XLS file rather csv and how we can build polygon by two or more line arc
*Hello Grass User,* ** *Any one can solve me the problem like-"How we can Import data using XLS file rather csv and how we can build polygon by two or more line-arc".* ** *Regards,* ** *Swapan Ghosh* ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Control of camera position in NVIZ
Using NVIZ, I have been able to visualize a segment of roadway my research group scanned with LiDAR. The visualization is perfect for what we are looking for, but there are two things we'd like to do next that I am having difficulty with. 1) We'd like to make an animation of the roadway from a drivers POV. Using the visualization utilities in NVIZ I have been able to manually adjust the viewing perspective of the visualization to a point that looks good, as in it looks like what the driver would see if they were in a vehicle and the vehicle was on the edge of the visualized surface (or very close to it). However is there anyway to advance the camera forward, again as if on a vehicle, as if it's driving ON the roadway? From what I can tell, the 'camera', or POV for viewing the visualized surface, can be anywhere on a radius away from the surface, however I cannot make the camera advance to hover over part of the visualized surface. I can get a good POV shot for a vehicle about to get started on the roadway, but not for driving across it. I'd like to make an animation with frame 1 being what I have now, but frame 2 etc being that exact same orientation, but with the camera having 'advanced' down the roadway. I cannot seem to make frames 2 onwards. 2) In the future we'd like to collect camera images of the driver's POV looking out the front windshield, so that we'd have an image from the orientation we'd like to see. Right now I am adjusting the angles until it 'looks good' - is there anyway to use this out-the-windshield image to EXACTLY align the visualization into that orientation so that the image and the visualization are identically aligned? I am also aware of the orthophoto utilities in GRASS, however without these images I have been unable to play with that. Will orthophoto do this? I recently found POV-Ray which I will be playing with shortly, but I'm curious as to if anyone else has had these same needs and if so how you worked with it. Thanks! Patrick ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SQlite Error, Mac OS X
Johannes wrote: > When I try to open the attribute table (sqlite db) of a line > vector with around 100 columns and several 1000 lines I get > an error message in GRASS6.5 SVN (Mac OSX). > After the error message pops up (saying only error, no > specific description) the attribute table opens and shows > the column heads but no entries and the window seems > frozen. I wonder if "char query[1024];" in v.db.select's main.c is too small. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SQlite Error, Mac OS X
Johannes wrote: > When I try to open the attribute table (sqlite db) of a line > vector with around 100 columns and several 1000 lines I get > an error message in GRASS6.5 SVN (Mac OSX). > After the error message pops up (saying only error, no > specific description) the attribute table opens and shows > the column heads but no entries and the window seems > frozen. > When I check the sqlite datadase with the sqlite manager in > firefox, there is no problem. There is also no problem when > I try to open the simpler vector atrribute tables (with less > lines and attributes). > I am not sure if that is a known problem or how can I tackle > it. There is also a crash report from my OS created (Console > report) which is attached. Hi, it sounds like a (lack of) memory allocation bug in the grass source code. could you open a bug report, and (if possible) share some sample data which triggers it? thanks, Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] calculating centre of mass?
Vishal wrote: > i'm interested in estimating the centre of population of a city > and how it might have changed in 10 years. i have a vector > polygon layer for each year, which is the ward population. > each layer has 198 polygons(wards) with population attributes > for each polygon(ward). The distribution of population within > a ward is not known, hence assumed uniform for now. > > is there a module in GRASS for calculating this. i know we can > calculate > geographic centroids, but was'nt sure if there was > one for this kind of thing. > > Otherwise i could do it manually by extracting the geographic > centroid of each polygon, then the coordinates of the > population centre would be: > > xhat = sum(Pi Xi) /(sum(Pi) > yhat = sum(Pi Yi) / sum(Pi) > > where Xi, Yi are each polygon i's geographic centroids; and > Pi are each polygon's population coordinates are in UTM. Hi, This won't really answer your question, but fyi the centroid position is calculated by Vect_find_poly_centroid() like this: http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/Vlib/poly.c#L309 but then tested to see if the point is within the polygon. beware of "C" or "O" shaped wards, where the center of mass (or the more simple center of the bounding box) may not be. and if you did have population data instead of polygons there is an addon script for that: http://grass.osgeo.org/wiki/AddOns#v.points.cog "v.points.cog is a shell script which will create a new point at the center of gravity of each cluster of input points or centroids, grouped by attribute. Among other things this is useful for labeling swarms of points." maybe it helps one day.. Hamish ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] GRASS 7 Bottleneck
I'm running a few instances of GRASS, and I've hit an extreme bottleneck. The problem is that I can't figure out what it is. I have a module that I wrote in the GRASS 7.0 environment that should be I/O bound. It normally takes about 10 minutes to finish running. I have seven instances running from one disk, and each one is taking on the order of 10 hours to finish. Why? NOTE: - The processes aren't I/O bound. 'iostat' lists a constant 30 MB/s transfer rate. It should be able to handle twice that. The transfers per second are < 100, and I've seen it handle triple that (at 60 MB/s). - The load average is currently below 1. I have 16 processors, so CPU shouldn't be a problem. - I have 16 GB of RAM, and it's full, but not thrashing. If it's not I/O, CPU, or RAM, then what is it slowing GRASS? Thanks, Seth___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Grid height for Austria
FYI from the proj-ML: http://lists.maptools.org/pipermail/proj/2012-February/006144.html __ links: http://www.bev.gv.at/portal/page?_pageid=713,2205044&_dad=portal&_schema=PORTAL http://www.bev.gv.at/portal/page?_pageid=713,2204753&_dad=portal&_schema=PORTAL * New Product of the BEV: Grid height for Austria * The BEV - Federal Office of Metrology and Surveying has developed an Austria-wide transformation grids : "height grid". (GIS-Grid based upon ntv2-definition) This height Grid allows, for example, to calculate and to convert orthometric heights from airborne laser scanning data (ALS) seamlessly for all of Austria to heights into use. the elevation grid (500 x 500 m grid spacing) is offered and free downloadable in the following formats: GeoTIFF and CSV. - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Grid-height-for-Austria-tp4523123p4523123.html Sent from the Grass - Users mailing list archive at Nabble.com. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] cs2cs Command Syntax Check
On Tue, 28 Feb 2012, Tom Russo wrote: For what it's worth, if you are already in a GRASS session in the target location, you can always use the following command line to get lat/lon converted to the location's coordinate system: cs2cs +proj=latlong +datum=NAD83 +to `g.proj -f -j` g.proj -j prints out the correct PROJ.4 format coordinate system specification for the current location. You'll find that g.proj -j in your location will print out the same data as the epsg:3421 entry. I have several lists of sampling locations in various flavors of lat-long. I'll do the conversions first, then insert them in a separate postgres table so they're available for all sampling data. Given the history of this operation there are frequently slight differences between the geographic coordinates recorded for water and biotic samples for the same station ID. Shrug. Thanks again, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] calculating centre of mass?
hi all, i'm interested in estimating the centre of population of a city and how it might have changed in 10 years. i have a vector polygon layer for each year, which is the ward population. each layer has 198 polygons(wards) with population attributes for each polygon(ward). The distribution of population within a ward is not known, hence assumed uniform for now. is there a module in GRASS for calculating this. i know we can calculate geographic centroids, but was'nt sure if there was one for this kind of thing. Otherwise i could do it manually by extracting the geographic centroid of each polygon, then the coordinates of the population centre would be: xhat = sum(Pi Xi) /(sum(Pi) yhat = sum(Pi Yi) / sum(Pi) where Xi, Yi are each polygon i's geographic centroids; and Pi are each polygon's population coordinates are in UTM. what do you think? Thanks, Vishal -- Vishal K. Mehta, PhD Scientist Stockholm Environment Institute - US 133 D St Suite F Davis CA 95616 www.sei-us.org ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] cs2cs Command Syntax Check
On Mon, Feb 27, 2012 at 03:23:55PM -0800, we recorded a bogon-computron collision of the flavor, containing: >I have many lon-lat coordinates in decimal degree format that are to be > converted to spcs Nevada East Zone (FIPS: 2701, ADS: 4601, UTM Zone 11), > NAD83, US survey feet or, as the PROJ_INFO in that location has it: > > name: Transverse Mercator > proj: tmerc > datum: nad83 > ellps: grs80 > lat_0: 34.75 > lon_0: -115.58333 > k: 0. > x_0: 20.1016 > y_0: 800.10163 > no_defs: defined > >The command I propose to use is: > > cs2cs +proj=latlong +datum=NAD83 +to +proj=utm +zone=11 +datum=NAD83 > >Is this correct? No. Nevada East Zone State Plane Coordinate System is not the same as UTM, Zone 11 (even though it may lie in UTM zone 11). Your command line will return UTM coordinates in meters easting and northing, not SPCS coordinates in US survey feet. What you want is to tell cs2cs to use the EPSG number 3421 as the target coordinate system. From the PROJ.4 epsg file, that means: # NAD83 / Nevada East (ft US) <3421> +proj=tmerc +lat_0=34.75 +lon_0=-115.58333 +k=0. +x_0=20.1016 +y_0=800.10163 +ellps=GRS80 +datum=NAD83 +units=us-ft +no_defs <> which you can see matches your PROJ_INFO information. (On my system, the EPSG database for PROJ.4 is in /usr/local/share/proj/epsg) You should use this command line instead: cs2cs +proj=latlong +datum=NAD83 +to +init=epsg:3421 -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM "And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit!" --- The Tick ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] cs2cs Command Syntax Check
On Tue, Feb 28, 2012 at 10:05:46AM -0700, we recorded a bogon-computron collision of the flavor, containing: > On Mon, Feb 27, 2012 at 03:23:55PM -0800, we recorded a bogon-computron > collision of the flavor, containing: > >I have many lon-lat coordinates in decimal degree format that are to be > > converted to spcs Nevada East Zone (FIPS: 2701, ADS: 4601, UTM Zone 11), > > NAD83, US survey feet or, as the PROJ_INFO in that location has it: > > > > name: Transverse Mercator > > proj: tmerc > > datum: nad83 > > ellps: grs80 > > lat_0: 34.75 > > lon_0: -115.58333 > > k: 0. > > x_0: 20.1016 > > y_0: 800.10163 > > no_defs: defined > > > >The command I propose to use is: > > > > cs2cs +proj=latlong +datum=NAD83 +to +proj=utm +zone=11 +datum=NAD83 > > > >Is this correct? > > No. Nevada East Zone State Plane Coordinate System is not the same as > UTM, Zone 11 (even though it may lie in UTM zone 11). Your command line > will > return UTM coordinates in meters easting and northing, not SPCS coordinates > in > US survey feet. > > What you want is to tell cs2cs to use the EPSG number 3421 > as the target coordinate system. From the PROJ.4 epsg file, that means: > > # NAD83 / Nevada East (ft US) > <3421> +proj=tmerc +lat_0=34.75 +lon_0=-115.58333 +k=0. > +x_0=20.1016 +y_0=800.10163 +ellps=GRS80 +datum=NAD83 > +units=us-ft +no_defs <> > > which you can see matches your PROJ_INFO information. > > (On my system, the EPSG database for PROJ.4 is in /usr/local/share/proj/epsg) > > You should use this command line instead: > > cs2cs +proj=latlong +datum=NAD83 +to +init=epsg:3421 For what it's worth, if you are already in a GRASS session in the target location, you can always use the following command line to get lat/lon converted to the location's coordinate system: cs2cs +proj=latlong +datum=NAD83 +to `g.proj -f -j` g.proj -j prints out the correct PROJ.4 format coordinate system specification for the current location. You'll find that g.proj -j in your location will print out the same data as the epsg:3421 entry. -- Tom RussoKM5VY SAR502 DM64ux http://www.swcp.com/~russo/ Tijeras, NM QRPL#1592 K2#398 SOC#236http://kevan.org/brain.cgi?DDTNM "And, isn't sanity really just a one-trick pony anyway? I mean all you get is one trick, rational thinking, but when you're good and crazy, oooh, oooh, oooh, the sky is the limit!" --- The Tick ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] cs2cs Command Syntax Check
On Tue, 28 Feb 2012, Tom Russo wrote: No. Nevada East Zone State Plane Coordinate System is not the same as UTM, Zone 11 (even though it may lie in UTM zone 11). Thanks, Tom. It's been long enough since I last needed to do this type of conversion that I forgot to use the EPSG numer. What you want is to tell cs2cs to use the EPSG number 3421 as the target coordinate system. From the PROJ.4 epsg file, that means: # NAD83 / Nevada East (ft US) <3421> +proj=tmerc +lat_0=34.75 +lon_0=-115.58333 +k=0. +x_0=20.1016 +y_0=800.10163 +ellps=GRS80 +datum=NAD83 +units=us-ft +no_defs <> which you can see matches your PROJ_INFO information. (On my system, the EPSG database for PROJ.4 is in /usr/local/share/proj/epsg) On my Slackware systems it's /usr/share/proj/epsg. You should use this command line instead: cs2cs +proj=latlong +datum=NAD83 +to +init=epsg:3421 Good. I don't need to separately specify each parameter, then. Glad I asked for the reality check. :-) Much appreciated, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] KeyError: 'script-save' when iconset changedKeyError: 'script-save'
By error I changed the iconset in GRASS 6.4.2svn (2011) and now when I try to start it I get the following error: GRASS 6.4.2svn (pofa):~ > Traceback (most recent call last): File "/home/jdeltoro1973/grass64/grass-6.4.2svn/etc/wxpython/wxgui.py", line 65, in from gui_modules import layertree File "/home/jdeltoro1973/grass64/grass-6.4.2svn/etc/wxpython/gui_modules/layertree.py", line 44, in import toolbars File "/home/jdeltoro1973/grass64/grass-6.4.2svn/etc/wxpython/gui_modules/toolbars.py", line 51, in from icon import Icons File "/home/jdeltoro1973/grass64/grass-6.4.2svn/etc/wxpython/icons/icon.py", line 433, in 'scriptSave' : MetaIcon(img = iconSet['script-save'], KeyError: 'script-save' How can I change the iconset to the original set? -- ¡Saludos! / Greetings! Juan José Del Toro M. jdeltoro1...@gmail.com Guadalajara, Jalisco MEXICO ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] SQlite Error, Mac OS X
Hi again, I just found out what causes the problem: It seems that this is related with the length of the column (attribute) names. After cropping them to <8 it works. Anyway that is seems to be a good reason to stick to short attribute names especially when one wants to exchange data with e.g ArcView. Just a suggestion: Maybe the Error message should be more specific for the user. cheers, /johannes Original-Nachricht > Datum: Tue, 28 Feb 2012 12:01:08 +0100 > Von: "Johannes Radinger" > An: grass user list > Betreff: [GRASS-user] SQlite Error, Mac OS X > Hi, > > When I try to open the attribute table (sqlite db) of a line vector with > around 100 columns and several 1000 lines I get an error message in GRASS6.5 > SVN (Mac OSX). > After the error message pops up (saying only error, no specific > description) the attribute table opens and shows the column heads but no > entries and > the window seems frozen. > When I check the sqlite datadase with the sqlite manager in firefox, there > is no problem. There is also no problem when I try to open the simpler > vector atrribute tables (with less lines and attributes). > I am not sure if that is a known problem or how can I tackle it. There is > also a crash report from my OS created (Console report) which is attached. > > Cheers, > Johannes > -- > NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! > > Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a -- Ihr GMX Postfach immer dabei: die kostenlose GMX Mail App für Android. Komfortabel, sicher und schnell: www.gmx.de/android ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] more on v.net: break lines on nodes
Hi, I'd like to re-open a quite old thread about breaking lines in a network. the old thread: >If each line is a straight line, then you have two nodes, one at each end. >>So, do you mean that you want to break the longer line, thus creating two >>new nodes, representing the new end points of the two parts and then snap >>these two nodes back together again and snap a third node (from the other >>line) to that same place ? > >If that is what you want to do, you can use the 'connect' tool in v.edit >>>(see "Connect lines" in the man page). > >If you want to break you line at the coordinates of a specific node, you >can >do it this way: > >v.edit tool=break cat=CatOfTheLineToBreak coords=CoordinatesOfYourNode >thresh= >v.edit tool=snap cat=CatOfTheBrokenLine,CatOfOtherLine thresh > >You can get the coordinates of your nodes with v.to.db. >Hope this helps, >Moritz I am in a similar situation: There is the main stem of a river and a contributing tributary. I want to break the main stem at the point where the tributary joins the it. I attached a screenshot with the Cat-numbers as labels and the selected section of the main stem I'd like to break (yellow). I considered three ways: 1) Use v.clean with first snapping the tributary to the mainstem and then breaking at the intersection. But I am not sure if this works as is is not an intersection (line just joins but don't intersect)!? 2) Using Moritz' approaches with v.edit - connect. Thats what I also tried but without success so far. v.edit map=Treene_test@SDM_Treene tool=connect thresh=100,100,100 cats=768,883 Selecting features... 2 of 1336 features selected from vector map Threshold value for snapping is 100.00 0 lines connected Building topology for vector map ... 3) or with getting the end point of the tributary (v.to.db) and then use break (v.edit) and setting the ID to the section of the mainstem (and setting the threshold). I already tried also this approach and then some basic questions arose: (a) What is the difference between Cat and ID. When I break the line (with v.edit) I get only two IDs but these are actually not two lines (which can e.g. be selected with the "Query vector map tool" in the GUI). (b) What is a suitable threshold (10,10,10?) Can there be a to large threshold if it is snapped to the nearest feature? (c) Is it useful to set the snap flag in v.edit in such cases? Or should I use the snap tool (v.edit) as a second process. (d) As I want two "real" new lines (cats) which show the same attributes, what is the easiest way to go. The connect tool sounds that this should do that job but somehow I fail? Best regards, Johannes -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a <>___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] SQlite Error, Mac OS X
Hi, When I try to open the attribute table (sqlite db) of a line vector with around 100 columns and several 1000 lines I get an error message in GRASS6.5 SVN (Mac OSX). After the error message pops up (saying only error, no specific description) the attribute table opens and shows the column heads but no entries and the window seems frozen. When I check the sqlite datadase with the sqlite manager in firefox, there is no problem. There is also no problem when I try to open the simpler vector atrribute tables (with less lines and attributes). I am not sure if that is a known problem or how can I tackle it. There is also a crash report from my OS created (Console report) which is attached. Cheers, Johannes -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a v.db.select crash report Description: Binary data ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
