Re: [GRASS-user] Manually Defining Location
On Fri, May 20, 2011 at 17:12, Rich Shepard rshep...@appl-ecosys.com wrote: On Fri, 20 May 2011, Bryan Keith wrote: I'm not convinced that's a valid wkt description of the coordinate system you want. Bryan, Let me back up and ask the question from a different point. Here's the WKT from one of the maps: PROJCS[Project, GEOGCS[GCS_North_American_1927, DATUM[D_North_American_1927, SPHEROID[Clarke_1866,6378206.4,294.9786982]], PRIMEM[Greenwich,0.0], UNIT[Degree,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[False_Easting,50.0], PARAMETER[False_Northing,-200.0], PARAMETER[Central_Meridian,-115.58], PARAMETER[Scale_Factor,0.], PARAMETER[Latitude_Of_Origin,34.75], UNIT[Foot_US,0.3048006096012192]] From this I created this proj4 description: +proj=tmerc +datum=nad27 +ellipse=clrk66 +a=6378206.4 +b=294.9786982 +x_0=50.0 +y_0=-200.0 +k_0=0. +lat_0=34.75 +lon_0=-115.58 +no_defs +units=us-ft Is this an accurate description to use in creating the location? Does the order matter? Well, let's see how this differs from when I tried to do the same thing: +proj=tmerc +lat_0=34.75 +lon_0=-115.58 +k=0. +x_0=152400.3048006096 +y_0=-609601.21920243837 +ellps=clrk66 +datum=NAD27 +units=us-ft +no_defs I think a and b are defined by the ellipsoid. Are the a and b you specified the same as what clrk66 uses? I don't know. If you specify both the ellipsoid and a and b, what takes precedence? I don't know. Everything else looks the same except for x and y, the false easting and false northing. In proj.4 those are always specified in meters while in the wkt definition, I think those numbers are in the projection units. That's why I changed the numbers 0.3048006096012192 * 50 152400.30480060959 0.3048006096012192 * -200 -609601.21920243837 If you use your proj.4 string, does your data end up in the correct location? To answer your other question, I don't think the order matters. These proj.4 questions are outside my area of expertise. Bryan Rich ___ 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
Re: [GRASS-user] Identifying Projection/Datum From Coordinates
Rich, I've done this many times, and you really just have to guess. It helps to know what units your coordinates are in to narrow down your choices. Often you can figure that out if you have a general idea of how far away a couple of your points are. Then you guess it has to be feet or meters. Well, I just tried the 5 obvious choices (UTM NAD27 and NAD83; NV stateplane east NAD27 and NAD83 and NAD83 with us-ft). Here are the results, and none looks right. You can see that 32007 (NV stateplane east NAD27) at least gets you in Nevada but not where you describe. cs2cs -f %0.6f +init=epsg:3421 +to +init=epsg:4326 371801.76 427253.14 -116.548880 -36.339992 0.00 cs2cs -f %0.6f +init=epsg:32007 +to +init=epsg:4326 371801.76 427253.14 -116.017176 35.923115 0.00 cs2cs -f %0.6f +init=epsg:32107 +to +init=epsg:4326 371801.76 427253.14 -113.731151 -33.652406 0.00 cs2cs -f %0.6f +init=epsg:26911 +to +init=epsg:4326 371801.76 427253.14 -118.154615 3.864647 0.00 cs2cs -f %0.6f +init=epsg:26711 +to +init=epsg:4326 371801.76 427253.14 -118.154603 3.864893 0.00 Since 32007 was somewhat reasonable, I tried 32008 (central): cs2cs -f %0.6f +init=epsg:32008 +to +init=epsg:4326 371801.76 427253.14 -117.100541 35.923099 0.00 Good luck. Sorry it wasn't more conclusive. Bryan On Fri, May 20, 2011 at 09:38, Rich Shepard rshep...@appl-ecosys.com wrote: I'd appreciate advice from folks here on a question of coordinates and projections. I have been given a list of site coordinates such as these: easting: 371801.756688, northing: 427253.142826 located in northeastern Nevada. Because they are each 6 digits (left of the decimal point) I assume that they are in State Plane Coordinates for eastern Nevada (zone 4601) and I want to convert them to UTM (zone 11). Using the NGS/NOAA SPC to GeoCoords converter results in latitudes of either 50 degrees N (for NAD83 in meters) or 47.5 degrees N (for NAD27 in feet), both of which are well off. I live about 45.5 degrees N and am well north of the area of interest. Please suggest how I can identify the projection and datum for these points so I can use proj4 to re-project them. TIA, Rich ___ 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
Re: [GRASS-user] Manually Defining Location
Rich, I'm not convinced that's a valid wkt description of the coordinate system you want. If I convert that to proj.4, I get +proj=longlat +ellps=clrk66 +datum=NAD27 +no_defs which is clearly wrong. If I use the GRASS location wizard and point it to that wkt, it thinks it is +proj=longlat +no_defs +a=6378206.4 +rf=294.9786982 +towgs84=-22.000,157.000,176.000 which is also clearly wrong. If I try to manually make a proj.4 string from that wkt, I come up with this: +proj=tmerc +lat_0=34.75 +lon_0=-115.58 +k=0. +x_0=152400.3048006096 +y_0=-609601.21920243837 +ellps=clrk66 +datum=NAD27 +units=us-ft +no_defs Check my numbers there because maybe I did something wrong. When I use that proj.4 to convert your coordinates, the results are cs2cs -f %0.6f +proj=tmerc +lat_0=34.75 +lon_0=-115.58 +k=0. +x_0=152400.3048006096 +y_0=-609601.21920243837 +ellps=clrk66 +datum=NAD27 +units=us-ft +no_defs +to +init=epsg:4326 371801.76 427253.14 -116.051661 41.414985 0.00 which is SW of 41.87 N, -115.43 W but I understand that you think you should be NW of that point Don't know if this helps or just adds confusion. Bryan On Fri, May 20, 2011 at 15:50, Rich Shepard rshep...@appl-ecosys.com wrote: On Fri, 20 May 2011, Rich Shepard wrote: GEOGCS[GCS_North_American_1927, DATUM[D_North_American_1927, SPHEROID[Clarke_1866,6378206.4,294.9786982]], PRIMEM[Greenwich,0.0], UNIT[Degree,0.0174532925199433]], I now understand that the above is angular units. However, the problem that the location wizard wants local units in meters for tmerc, nad27 rather than US feet remains. Rich ___ 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] Re: how to only fill small sinks with r.fill.dir
Any ideas on this? Bryan On Mon, Apr 18, 2011 at 14:49, Bryan Keith bke...@itascadenver.com wrote: Hello, Is there a way to only fill sinks in a DEM if they are smaller than a certain tolerance? I have a couple areas of internal drainage that really are correct (and quite large), and I have a quite few small sinks that are incorrect and artifacts of the interpolation. Any ideas how to this? r.fill.dir attempt to fill all the sinks. I'm trying to improve the results from r.flow Too many tracks end in small holes where I'd like them to continue downstream. Thanks. Bryan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: how to only fill small sinks with r.fill.dir
Hmmm, I'm not following all your steps, but I don't want to manually identify valid sinks vs. invalid sinks. I have quite a lot of surfaces to process, and I'm happy to fill all sinks except those deeper than 10m. On Tue, Apr 26, 2011 at 10:04, Saber razmjoo...@faunalia.co.uk wrote: Here is a (not a very quick) solution I can think of: 1- Create an inverse mask 2- convert the mask to vector (r.to.vect) 3- clean the vector file to get rid of the areas not required (v.clean) 4- convert the vector back to raster (v.to.rast) 5- Use the new raster as a mask for filling holes (probably you need step 4.5 to slightly buffer the raster) Hope that helps Any ideas on this? Bryan On Mon, Apr 18, 2011 at 14:49, Bryan Keith bke...@itascadenver.com wrote: Hello, Is there a way to only fill sinks in a DEM if they are smaller than a certain tolerance? I have a couple areas of internal drainage that really are correct (and quite large), and I have a quite few small sinks that are incorrect and artifacts of the interpolation. Any ideas how to this? r.fill.dir attempt to fill all the sinks. I'm trying to improve the results from r.flow Too many tracks end in small holes where I'd like them to continue downstream. Thanks. Bryan ___ 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
Re: [GRASS-user] Re: how to only fill small sinks with r.fill.dir
Great ideas, thank you. I did something like this: r.fill.dir input=wl200310_krig_g elevation=wl200310_fill_g direction=wl200310_dir_g r.mapcalc wl200310diff_g=wl200310_fill_g - wl200310_krig_g r.mapcalc wl200310diffsel_g = if(wl200310diff_g 5.0, 0, wl200310diff_g) r.mapcalc wl200310sel_g = wl200310diffsel_g + wl200310_krig_g r.fill.dir input=wl200310sel_g elevation=wl200310sel_fill_g direction=wl200310sel_dir_g r.flow elevin=wl200310sel_fill_g flout=test_ln I think my problem is now with r.flow. I would like to see flows continue through the filled sink and out the other end (as if it were a lake), but that doesn't happen. I don't think it can happen with r.flow because r.flow encounters a flat area. Not sure what to try next. This was a problem even before messing around with the sink tolerance. Bryan On Tue, Apr 26, 2011 at 10:31, Saber razmjoo...@faunalia.co.uk wrote: Sorry...I thought the sinks are as null values. Ignore my previous email. I can't think of anything apart from improving your DEM to get rid of the artifacts. One way will be to get the initial result from the r.fill.dir. Identify the areas where the depth is more than say 10 metre (r.nulls map=initial_result setnull 0-9.99) You can then add the new depth raster to the DEM to create the filled hole. (first r.mask to match initial_result and then r.mapcalc filled_holes=initial_result+DEM) Then remove the mast and r.patch r.patch input=filled_holes,DEM output=patched_DEM You can then use the patched_DEM for r.fill.dir Hope that helps. Hmmm, I'm not following all your steps, but I don't want to manually identify valid sinks vs. invalid sinks. I have quite a lot of surfaces to process, and I'm happy to fill all sinks except those deeper than 10m. On Tue, Apr 26, 2011 at 10:04, Saber razmjoo...@faunalia.co.uk wrote: Here is a (not a very quick) solution I can think of: 1- Create an inverse mask 2- convert the mask to vector (r.to.vect) 3- clean the vector file to get rid of the areas not required (v.clean) 4- convert the vector back to raster (v.to.rast) 5- Use the new raster as a mask for filling holes (probably you need step 4.5 to slightly buffer the raster) Hope that helps Any ideas on this? Bryan On Mon, Apr 18, 2011 at 14:49, Bryan Keith bke...@itascadenver.com wrote: Hello, Is there a way to only fill sinks in a DEM if they are smaller than a certain tolerance? I have a couple areas of internal drainage that really are correct (and quite large), and I have a quite few small sinks that are incorrect and artifacts of the interpolation. Any ideas how to this? r.fill.dir attempt to fill all the sinks. I'm trying to improve the results from r.flow Too many tracks end in small holes where I'd like them to continue downstream. Thanks. Bryan ___ 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
Re: [GRASS-user] Re: how to only fill small sinks with r.fill.dir
On Tue, Apr 26, 2011 at 12:53, Markus Metz markus.metz.gisw...@googlemail.com wrote: On Tue, Apr 26, 2011 at 7:54 PM, Bryan Keith bke...@itascadenver.com wrote: I think my problem is now with r.flow. I would like to see flows continue through the filled sink and out the other end (as if it were a lake), but that doesn't happen. I don't think it can happen with r.flow because r.flow encounters a flat area. r.watershed would do that. Also r.terrraflow, but r.terraflow fills You mean with the stream output? The problem with that is you're unable to specify where you'd like the streams to start. You only get the largest accumulation streams, but I want output similar to r.flow which distributes particles throughout the area of interest. r.drain allows you to specify where the particulars start, but it's limited to 8-directional flow instead of the smooth flow that r.flow generates (which I prefer). all remaining sinks internally which is apparently not what you want. r.watershed also allows you to specify locations of real sinks which are not traversed. BTW, sometime in the next months I want to make available a new module that performs hydrological conditioning of a DEM using not sink filling but an impact reduction approach, and which has an option to remove only sinks smaller than a given size. Sounds like this may be what I'm after! Bryan Markus M Not sure what to try next. This was a problem even before messing around with the sink tolerance. Bryan On Tue, Apr 26, 2011 at 10:31, Saber razmjoo...@faunalia.co.uk wrote: Sorry...I thought the sinks are as null values. Ignore my previous email. I can't think of anything apart from improving your DEM to get rid of the artifacts. One way will be to get the initial result from the r.fill.dir. Identify the areas where the depth is more than say 10 metre (r.nulls map=initial_result setnull 0-9.99) You can then add the new depth raster to the DEM to create the filled hole. (first r.mask to match initial_result and then r.mapcalc filled_holes=initial_result+DEM) Then remove the mast and r.patch r.patch input=filled_holes,DEM output=patched_DEM You can then use the patched_DEM for r.fill.dir Hope that helps. Hmmm, I'm not following all your steps, but I don't want to manually identify valid sinks vs. invalid sinks. I have quite a lot of surfaces to process, and I'm happy to fill all sinks except those deeper than 10m. On Tue, Apr 26, 2011 at 10:04, Saber razmjoo...@faunalia.co.uk wrote: Here is a (not a very quick) solution I can think of: 1- Create an inverse mask 2- convert the mask to vector (r.to.vect) 3- clean the vector file to get rid of the areas not required (v.clean) 4- convert the vector back to raster (v.to.rast) 5- Use the new raster as a mask for filling holes (probably you need step 4.5 to slightly buffer the raster) Hope that helps Any ideas on this? Bryan On Mon, Apr 18, 2011 at 14:49, Bryan Keith bke...@itascadenver.com wrote: Hello, Is there a way to only fill sinks in a DEM if they are smaller than a certain tolerance? I have a couple areas of internal drainage that really are correct (and quite large), and I have a quite few small sinks that are incorrect and artifacts of the interpolation. Any ideas how to this? r.fill.dir attempt to fill all the sinks. I'm trying to improve the results from r.flow Too many tracks end in small holes where I'd like them to continue downstream. Thanks. Bryan ___ 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 mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Re: how to only fill small sinks with r.fill.dir
On Tue, Apr 26, 2011 at 12:51, Saber Razmjooei razmjoo...@faunalia.co.uk wrote: You probably need a full 2D hydraulic model to do work based on water level gradient. Maybe something like like ANUGA: http://sourceforge.net/projects/anuga/ This seems like an overkill. What I want is to do be able to put particles on a 2d field and generate smooth (not 8-directional) flow paths. I also have the cavaet of not having perfect input data. I have a surface that has small sinks that need to be removed but has large sinks that are valid data. r.flow gets very close to what I want. Actually I think r.flow would do exactly what I want if my input sinks were filled and pointed toward the new outlet (something that doesn't happen when they're filled manually). With the manual sink filling or r.watershed or r.drain, I'm still not much closer than the original r.flow output. Bryan On Tue, 2011-04-26 at 11:54 -0600, Bryan Keith wrote: Great ideas, thank you. I did something like this: r.fill.dir input=wl200310_krig_g elevation=wl200310_fill_g direction=wl200310_dir_g r.mapcalc wl200310diff_g=wl200310_fill_g - wl200310_krig_g r.mapcalc wl200310diffsel_g = if(wl200310diff_g 5.0, 0, wl200310diff_g) r.mapcalc wl200310sel_g = wl200310diffsel_g + wl200310_krig_g r.fill.dir input=wl200310sel_g elevation=wl200310sel_fill_g direction=wl200310sel_dir_g r.flow elevin=wl200310sel_fill_g flout=test_ln I think my problem is now with r.flow. I would like to see flows continue through the filled sink and out the other end (as if it were a lake), but that doesn't happen. I don't think it can happen with r.flow because r.flow encounters a flat area. Not sure what to try next. This was a problem even before messing around with the sink tolerance. Bryan On Tue, Apr 26, 2011 at 10:31, Saber razmjoo...@faunalia.co.uk wrote: Sorry...I thought the sinks are as null values. Ignore my previous email. I can't think of anything apart from improving your DEM to get rid of the artifacts. One way will be to get the initial result from the r.fill.dir. Identify the areas where the depth is more than say 10 metre (r.nulls map=initial_result setnull 0-9.99) You can then add the new depth raster to the DEM to create the filled hole. (first r.mask to match initial_result and then r.mapcalc filled_holes=initial_result+DEM) Then remove the mast and r.patch r.patch input=filled_holes,DEM output=patched_DEM You can then use the patched_DEM for r.fill.dir Hope that helps. Hmmm, I'm not following all your steps, but I don't want to manually identify valid sinks vs. invalid sinks. I have quite a lot of surfaces to process, and I'm happy to fill all sinks except those deeper than 10m. On Tue, Apr 26, 2011 at 10:04, Saber razmjoo...@faunalia.co.uk wrote: Here is a (not a very quick) solution I can think of: 1- Create an inverse mask 2- convert the mask to vector (r.to.vect) 3- clean the vector file to get rid of the areas not required (v.clean) 4- convert the vector back to raster (v.to.rast) 5- Use the new raster as a mask for filling holes (probably you need step 4.5 to slightly buffer the raster) Hope that helps Any ideas on this? Bryan On Mon, Apr 18, 2011 at 14:49, Bryan Keith bke...@itascadenver.com wrote: Hello, Is there a way to only fill sinks in a DEM if they are smaller than a certain tolerance? I have a couple areas of internal drainage that really are correct (and quite large), and I have a quite few small sinks that are incorrect and artifacts of the interpolation. Any ideas how to this? r.fill.dir attempt to fill all the sinks. I'm trying to improve the results from r.flow Too many tracks end in small holes where I'd like them to continue downstream. Thanks. Bryan ___ 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 to only fill small sinks with r.fill.dir
Hello, Is there a way to only fill sinks in a DEM if they are smaller than a certain tolerance? I have a couple areas of internal drainage that really are correct (and quite large), and I have a quite few small sinks that are incorrect and artifacts of the interpolation. Any ideas how to this? r.fill.dir attempt to fill all the sinks. I'm trying to improve the results from r.flow Too many tracks end in small holes where I'd like them to continue downstream. Thanks. Bryan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve for lines?
On 11/05/2010 09:59 PM, Bryan Keith wrote: On 10/19/2010 11:17 PM, Bryan Keith wrote: Hello, I have a vector line file that has lots of two-vertex lines. Many of these two-vertex lines share endpoints and really just make parts of one longer line. I'd like to dissolve these lines into one line when they have the same end point. It looks like v.dissolve only works for areas. Is there somewhere else I should be looking? Thank you. Did you have a look at v.build.polylines ? Additional note: line vectors have a direction. Two line segments with an equivalent node (end point) will *not* connect if they are in opposite directions. In this case you can try the v.edit tool=flip option (on those segments only) Thank you for the response. I finally got around to looking at this today. I made a simple example and tested with v.build.polylines, and it works great. Thank you. However, it turns out that I have many duplicate lines in my dataset. I created a simple example where there are duplicate lines, and v.build.polylines doesn't work in that case. What do I need to look at to get rid of duplicate lines? v.clean tool=rmdupl Might do it if the lines exactly overlap. Yes, that worked in my case. Thanks so much, Micha! Bryan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.dissolve for lines?
On 10/19/2010 11:17 PM, Bryan Keith wrote: Hello, I have a vector line file that has lots of two-vertex lines. Many of these two-vertex lines share endpoints and really just make parts of one longer line. I'd like to dissolve these lines into one line when they have the same end point. It looks like v.dissolve only works for areas. Is there somewhere else I should be looking? Thank you. Did you have a look at v.build.polylines ? Additional note: line vectors have a direction. Two line segments with an equivalent node (end point) will *not* connect if they are in opposite directions. In this case you can try the v.edit tool=flip option (on those segments only) Thank you for the response. I finally got around to looking at this today. I made a simple example and tested with v.build.polylines, and it works great. Thank you. However, it turns out that I have many duplicate lines in my dataset. I created a simple example where there are duplicate lines, and v.build.polylines doesn't work in that case. What do I need to look at to get rid of duplicate lines? Bryan _ 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 Arava Development Co. +972-52-3665918 http://www.surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] v.dissolve for lines?
Hello, I have a vector line file that has lots of two-vertex lines. Many of these two-vertex lines share endpoints and really just make parts of one longer line. I'd like to dissolve these lines into one line when they have the same end point. It looks like v.dissolve only works for areas. Is there somewhere else I should be looking? Thank you. Bryan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] converting lines to polygons
Micha Silver wrote: Bryan Keith wrote: Orange boundaries are duplicates - overlapping lines - that GRASS topology doesn't allow. You should be able to get rid of these with: v.clean in=... out=... tool=break,bpol,rmdupl But I've never had good luck with this. The alternative that might work better for you: Re-import the layer from the original shapefiles (or where ever they came from) but use the type=line option to v.in.ogr. (No centroids will be created) Now do v.clean on this new GRASS vector, using tool=snap,break,rmdupl. Next use v.type ... type=line,boundary to convert the (cleaned) lines to boundaries, and then v.centroids ... opt=add to create area centroids inside each closed boundary. Micha, Yes, thank you, that worked! Here's what I did: Cheers. Although I think I misled you a bit. I was mistaken about the orange line color in the digitizer. It simply indicates a boundary that is wholly shared by two adjacent areas. *Not* a topological error. In any case, importing polygon shapefiles first as lines (not boundaries), doing the topology cleanup, and then convert to boundaries and add centroids seems to be the smoother way to go. I object because 1. you would need to replicate the cleaning steps done by v.in.ogr which has, amongst others, a snapping option 2. adding centroids will add centroids to all areas, also those that where holes in polygons provided by OGR, e.g. a waterbodies shapefile with lakes and islands in lakes: the islands are not waterbodies and should not get a centroid 3. you will loose attributes because there is no (easy) way to link any attributes coming with the shapefile to newly generated centroids, e.g. land cover/land use shapefiles Markus, I agree with you regarding #1. However, in my case I had a line shapefile, not polygons, so #2 and #3 did not apply. I haven't tried to import a polygon shapefile as areas into GRASS. Importing as lines and fixing attributes does not seem like the desired approach. Bryan Markus M v.in.ogr -o dsn=C:\path\to\shapefile\test_ln.shp output=testm_ln type=line v.clean input=testm_ln output=testmclean_ln tool=snap,break,rmdupl thresh=0.2,0,0 v.type input=testmclean_ln output=testmclean_bnd type=line,boundary v.centroids input=testmclean_bnd output=testmclean_py option=add Thanks for all the help. Bryan -- Micha Silver Arava Development Co. +972-52-3665918 http://surfaces.co.il ___ 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
Re: [GRASS-user] converting lines to polygons
On 09/22/2010 02:40 PM, Bryan Keith wrote: On 09/22/2010 12:45 AM, Bryan Keith wrote: Hello, I'm using these commands: v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0 v.type input=testclean_ln output=testclean_bnd type=line,boundary v.centroids input=testclean_bnd output=testclean_py trying to convert a bunch of lines to 5 polygons. I've tried lots of variations of v.clean including many snap thresholds, but I can only get 3 polygons. Is there something I'm doing wrong? If it's only two missing, then just manually add centroids to those two areas that are not yet polygons. (using v.digit) Well, it's two in this simple little example clipped from a larger file, and I have lots of files to process so I'm looking for an automated process. Can you figure out why other areas were not closed? Maybe you need a larger threshold value? By opening the vector with v.digit you'll see by the color coding of the nodes which are part of closed boundaries (dark green) and which are on a broken boundary (red). You'll also see quickly where you have centroids inside correct boundaries, and where you're missing them. No, I can't figure out why the other areas were not closed. A larger threshold value does not help. I have never used v.digit, and I actually can't get anything to display with v.digit Hmmm, I'm not sure what I'm doing wrong with v.digit I would be nice to be able to see where nodes aren't connected (I'm guessing that's the problem) and be able to measure how far apart they are from each other. I'm surprised how increasing the threshold makes some boundaries that were correct incorrect. Bryan Check out the line and polygons here: http://www.ideotrope.org/~bryan/lines.png http://www.ideotrope.org/~bryan/polygons.png Bryan ___ 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 Arava Development Co. +972-52-3665918 http://surfaces.co.il This mail was received via Mail-SeCure System. -- Micha Silver Arava Development Co. +972-52-3665918 http://surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] converting lines to polygons
On 09/22/2010 12:45 AM, Bryan Keith wrote: Hello, I'm using these commands: v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0 v.type input=testclean_ln output=testclean_bnd type=line,boundary v.centroids input=testclean_bnd output=testclean_py and I have lots of files to process so I'm looking for an automated process. Can you figure out why other areas were not closed? Maybe you need a larger threshold value? By opening the vector with v.digit you'll see by the color coding of the nodes which are part of closed boundaries (dark green) and which are on a broken boundary (red). You'll also see quickly where you have centroids inside correct boundaries, and where you're missing them. No, I can't figure out why the other areas were not closed. A larger threshold value does not help. I have never used v.digit, and I actually can't get anything to display with v.digit Hmmm, I'm not sure what I'm doing wrong with v.digit What OS are you on? what version of GRASS, and what GUI? I'll answer these questions anyway, but I figured out the v.digit problem (see below). Windows XP GRASS 6.4.0 wxGUI I would be nice to be able to see where nodes aren't connected (I'm guessing that's the problem) and be able to measure how far apart they are from each other. I'm surprised how increasing the threshold makes some boundaries that were correct incorrect. Yes, Surprising. Can we see, as Markus M suggested, the output of v.info -t or v.clean? Also what units is your data in? i.e the output of v.info -g and g.region -p ? OK, getting closer, I think. The reason v.digit wasn't working was because g.region was set incorrectly. Now I can look at the various maps with v.digit and see the different colors of the lines and nodes. In the meantime I created a very simple example and processed that map and was able to get results that I expected. So then I looked at the one that worked and the one that didn't using v.digit to see what the differences were. The files that doesn't have all the areas that I expect has lines that are displayed orange (Boundary (1 area)) while the correct version has lines that are display green (Boundary (2 areas)). Could that be why I'm not getting all the areas that I expect? All the nodes look correct (no red ones). How do I fix this? An option in v.clean? Bryan Check out the line and polygons here: http://www.ideotrope.org/~bryan/lines.png http://www.ideotrope.org/~bryan/polygons.png Bryan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] converting lines to polygons
On 09/22/2010 12:45 AM, Bryan Keith wrote: Hello, I'm using these commands: v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0 v.type input=testclean_ln output=testclean_bnd type=line,boundary v.centroids input=testclean_bnd output=testclean_py trying to convert a bunch of lines to 5 polygons. I've tried lots of variations of v.clean including many snap thresholds, but I can only get 3 polygons. Is there something I'm doing wrong? If it's only two missing, then just manually add centroids to those two areas that are not yet polygons. (using v.digit) Well, it's two in this simple little example clipped from a larger file, and I have lots of files to process so I'm looking for an automated process. Bryan Check out the line and polygons here: http://www.ideotrope.org/~bryan/lines.png http://www.ideotrope.org/~bryan/polygons.png Bryan ___ 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 Arava Development Co. +972-52-3665918 http://surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] converting lines to polygons
Hello, I'm using these commands: v.clean input=test_ln output=testclean_ln tool=snap,bpol thresh=0.2,0 v.type input=testclean_ln output=testclean_bnd type=line,boundary v.centroids input=testclean_bnd output=testclean_py trying to convert a bunch of lines to 5 polygons. I've tried lots of variations of v.clean including many snap thresholds, but I can only get 3 polygons. Is there something I'm doing wrong? Check out the line and polygons here: http://www.ideotrope.org/~bryan/lines.png http://www.ideotrope.org/~bryan/polygons.png Bryan ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
