Re: [GRASS-user] Adjacent polygons rejected by v.patch
Humberto Cereser Ibanez wrote: Hi, I'm trying to join polygons, but unfortunately some, at the boundaries are been rejected by v.patch. The Screenshot attached is showing this. 1) Import shapefile with v.in.ogr: v.in.ogr dsn=ma.shp output=maGrass snap=0.001 min_area=0.0001 The same for others shapefiles pi, ce, rn, pb, pe, al, se and ba 2) Aggregate polygons with v.patch v.patch input=maGrass,piGrass,ceGrass,rnGrass,pbGrass,peGrass,alGrass,seGrass,baGrass output=nePatched I do not figure out how I can solve this issue. There are 3 ways to patch shapefiles: 1) before import with ogr2ogr -append. I don't know what happens when the attribute tables are not compatible. 2) during import you need to use to folder with the shapefiles as dsn for v.in.ogr, then all OGR layers are imported at once and patched together. Each OGR layer will result in a separate GRASS layer in the output GRASS vector. Each GRASS vector layer will have its own attribute table, i.e. it does not matter if attribute tables are not compatible. 3) after import with v.patch Categories might need to be prepared first in order to avoid that areas from different input vector maps end up with the same category. Preserving attributes with v.patch is not trivial. The output of v.patch will require further cleaning. From the manual: Boundaries may need to be cleaned with v.clean tool=break,rmdupl,rmsa repeatedly until the rmsa tool (Remove small angles at nodes) no longer modifies any boundaries. If vector topology is still not clean, boundaries may also need to be snapped with v.clean tool=snap,break,rmdupl. HTH, Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] i.maxlik's reject versus i.segment's goodness
On 18/11/14 09:47, Markus Metz wrote: On Sun, Nov 16, 2014 at 3:21 AM, Vaclav Petras wenzesl...@gmail.com wrote: Hi, I executed the examples in i.cluster and i.maxlik manuals and also the following i.segment command: i.segment group=lsat7_2002@w1-imagery output=lsat7_2002_segments threshold=0.5 goodness=lsat7_2002_segments_goodness (using the imagery group created in i.cluster example, otherwise unrelated) I looked at goodness from i.segment and then reject from i.maxlik. I noticed that there is some correlation between these two. Well, this is quite okay since they are using same pixel values. However, then I noticed that low values of goodness (-5000, ...) i.segment's goodness estimate is supposed to be in the range [0,1]. Fixed in r62793,4. Can you test again? Could you explain / put into the manual the explanation of the calculation / meaning of this goodness of fit ? Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] an example of GRASS GIS for biodiversity research
For those interested in biodiversity research and GRASS: http://authors.elsevier.com/a/1Q2wd5c6cKWAeR Advancing species diversity estimate by remotely sensed proxies: A conceptual review Best! D ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] an example of GRASS GIS for biodiversity research
On Wed, Nov 19, 2014 at 12:34 PM, Duccio Rocchini ducciorocch...@gmail.com wrote: For those interested in biodiversity research and GRASS: http://authors.elsevier.com/a/1Q2wd5c6cKWAeR Advancing species diversity estimate by remotely sensed proxies: A conceptual review Nice, thanks for sharing. I learned about the i.colors.enhance [1] thanks to the paper. I just don't understand the note about i.colors.rgb in description for figure 5. Isn't that some copy and paste error? Vaclav [1] http://grass.osgeo.org/grass71/manuals/i.colors.enhance.html Best! D ___ 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] r.stream.*
Hei, I'm new to GRASS and try to do some watershed stats. Running GRASS 6.4.4 on OS X 10.9.5. One problem is how to choose the correct threshold value for stream delineation, what would be the best way of finding this value? Also is it possible to manually edit the streams before using r.stream.order, and r.stream.stats? Seems to me that r.stream.extract gives a good delineation, but would like to do a few edits, like removal of old non flowing channels, and possibly a few small changes to other stream channels. Best wishes Svein Harald Sønderland ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] an example of GRASS GIS for biodiversity research
Last change failed... It happens... btw The code is OK. .. checked by MN eh eh D On 19/11/2014 7:05 PM, Vaclav Petras wenzesl...@gmail.com wrote: On Wed, Nov 19, 2014 at 12:34 PM, Duccio Rocchini ducciorocch...@gmail.com wrote: For those interested in biodiversity research and GRASS: http://authors.elsevier.com/a/1Q2wd5c6cKWAeR Advancing species diversity estimate by remotely sensed proxies: A conceptual review Nice, thanks for sharing. I learned about the i.colors.enhance [1] thanks to the paper. I just don't understand the note about i.colors.rgb in description for figure 5. Isn't that some copy and paste error? Vaclav [1] http://grass.osgeo.org/grass71/manuals/i.colors.enhance.html Best! D ___ 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] an example of GRASS GIS for biodiversity research
Ahah!! Now I understand the point, Vaclav. The PDF file has been properly corrected by the Publisher while in the internet version of the ms they did not make such a change. D ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] wxGUI raster digitizer available
Hi Anna,
On Tue, Nov 18, 2014 at 5:19 AM, Anna Petrášová kratocha...@gmail.com wrote:
Hi all,
I added raster digitizer in r62792 in trunk.
what a great job!
If you didn't find it: it is in the Map Display windows, then
selector on the right side (2D/3D/Vector digitizer/Raster digitizer).
You are welcome to test it and
report bugs/enhancements.
It currently allows to draw areas, lines and points and specify width to
buffer individual features. We can discuss some changes in gui interface and
behavior if you find the current one intuitive. There is still a lot to
improve especially in the drawing part (needs some refactoring of the old
drawing code).
One general thing I found (also valid for the vector digitizer): I
wonder where to put a message what the mouse buttons mean.
Maybe in the status bar at bottom of the display/digitizer window?
Features:
- draw area, line, point
... works.
- specify buffer width for individual features to create for example
circles, roads of certain width...
... maybe rename from Width to Buffer width? Otherwise it could be
confused with the drawing line width.
- specify background map
... works (maybe have a button to optionally take computational region
from that map?)
- simple undo
- save button to save results during drawing
here I got an issue somewhere:
Exception in thread Thread-4:
Traceback (most recent call last):
File /usr/lib64/python2.7/threading.py, line 811, in
__bootstrap_inner
self.run()
File /home/neteler/software/grass71/dist.x86_64-unknown-
linux-gnu/gui/wxpython/core/gthread.py, line 94, in run
ret = vars()['callable'](*args, **kwds)
File /home/neteler/software/grass71/dist.x86_64-unknown-
linux-gnu/gui/wxpython/rdigit/controller.py, line 432, in
_exportRaster
if item.GetPropertyVal('widthValue') and \
File /home/neteler/software/grass71/dist.x86_64-unknown-
linux-gnu/gui/wxpython/mapwin/graphics.py, line 439, in
GetPropertyVal
raise KeyError(_(Property does not exist: %s) %
(propName))
KeyError: 'Property does not exist: widthValue'
- keeps drawing order in the output raster map
- change color of drawing
- doesn't block gui when exporting raster (which can take some time)
Nice!
Does not support (yet?):
- adding labels
- interactive setting color of raster cells (not planned, there are other
tools)
- vector export/import
Known issues:
- r.in.poly supports only CELL (I just realized that, this must be changed)
(meanwhile you changed that already, thanks)
- various small drawing issues
- slow when exporting features with buffers (r.grow is slow, probably
because it's a script)
Not sure but r.buffer would be appropriate/faster?
Markus
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Problem with r.basin in grass7
Hi Helmut and Margherita, Thanks for your mails! Here are the answers to your questions: a)This is the result of r.info and g.region: r.info map@Elevation ++ Map: map@Elevation Date: Sat Nov 15 16:35:08 2014 Mapset: Elevation Login of Creator: Andrea Location: ElevationData DataBase: C:UsersAndreaDocumentsgrassdata Title: ( map ) Timestamp: none Type of Map: raster Number of Categories: 0 Data Type: FCELL Rows: 21612 Columns: 10812 Total Cells: 233668944 Projection: Latitude-Longitude N: 45:00:02N S: 42:59:58N Res: 0:00:00.33 E: 70:59:58W W: 72:00:02W Res: 0:00:00.33 Range of data: min = 18.40538 max = 1916.398 Data Description: generated by r.patch Comments: r.patch input=n44-72@Elevation,n45_72@Elevation output=map ++ g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: nad83 ellipsoid: grs80 north: 45:00:02N south: 42:59:58N west: 72:00:02W east: 70:59:58W nsres: 0:00:01 ewres: 0:00:01 rows: 7204 cols: 3604 cells: 25963216 b) These are all my steps: ++ open grass ++ load my two raster files ++ r.patch --overwrite input=n44_72@Elevation,n45_72@Elevation output=map ++ g.remove -f type=all name=original@Elevation,o_map_accumulation@Elevation,o_map_aspect@Elevation,o_map_aspect_mod@Elevation,o_map_average_hillslope@Elevation,o_map_basin@Elevation,o_map_dist2out@Elevation,o_map_drainage@Elevation,o_map_drainage_e@Elevation,o_map_hack@Elevation,o_map_height_average@Elevation,o_map_hillslope_distance@Elevation,o_map_horton@Elevation,o_map_mainchannel@Elevation,o_map_mainchannel_dim@Elevation,o_map_mainchannel_thin@Elevation,o_map_mask@Elevation,o_map_ord_1@Elevation,o_map_ord_1_thin@Elevation,o_map_r_outlet@Elevation,o_map_shreve@Elevation,o_map_slope@Elevation,o_map_strahler@Elevation,o_map_stream_e@Elevation,o_map_stream_e_thin@Elevation,r_elevation_crop@Elevation,o_map_basin@Elevation,o_map_mainchannel@Elevation,o_map_mainchannel_dim@Elevation,o_map_mainchannel_dim_point@Elevation,o_map_network@Elevation,o_map_ord_1@Elevation,o_map_outlet@Elevation,o_map_outlet_snap@Elevation,o_map_mainchannel_dim_thin@Elevation ++ g.region rast=map@Elevation res=0:00:01 (also tried with g.region -a rast=map@Elevation res=0:00:01, and got the same result) ++ r.basin map=map@Elevation prefix=o coordinates=-71.10394196,43.9865230801 threshold=19005 dir=C:UsersAndreaBasins5 c) Try to use the NC dataset I downloaded it, but did not any changes in the resolution and computational region, since the manual said that the maps were ready for use... I chose some coordinates just by a visual inspection of the DEM and used just random threshold. I run: r.basin map=elev_ned_30m@PERMANENT prefix=o coordinates=640856.761198,215050.690725 threshold=400 dir=C:UsersAndreaBasins6 and get: ... ... Tot. cells 543.0 === Hypsometric quantiles === 106 0.025 105 0.05 103 0.1 100 0.25 95 0.5 87 0.75 89 0.7 81 0.9 76 0.975 Done! -- -- Traceback (most recent call last): File C:UsersAndreaAppDataRoamingGRASS7addons/scri pts/r.width.funct.py, line 130, in module sys.exit(main()) File C:UsersAndreaAppDataRoamingGRASS7addons/scri pts/r.width.funct.py, line 86, in main prc[4,0] , prc[4,1] = findint(kl,0.5) , 0.5 File C:UsersAndreaAppDataRoamingGRASS7addons/scri pts/r.width.funct.py, line 123, in findint z1 , z2 , f1 , f2 = kl[float(Xf[0])][0] , kl[float(Xf[0]-1)][0] , kl[float(Xf[0])][1] , kl[float(Xf[0]-1)][1] TypeError: only length-1 arrays can be converted to Python scalars Tot. cells 543.0 Tot. area 441051.75 Max distance 1693.190486 -- An ERROR occurred running r.basin Please check for error messages above or try with another pairs of outlet coordinates d) Results of r.info and g.region for the NC dataset r.info elev_ned_30m@PERMANENT ++ Map: elev_ned_30m@PERMANENT Date: Tue Nov 7 00:35:18 2006 Mapset: PERMANENT Login of Creator: helena Location: nc_spm_08_grass7 DataBase: C:UsersAndreaDocumentsgrassdatanc_spm_08_grass7 Title: South-West Wake county: National Elevation Data 30m ( elev_ned30 Timestamp: none Type of Map: raster Number of Categories: 255 Data Type: FCELL Rows: 450 Columns: 500 Total Cells: 225000 Projection: Lambert Conformal Conic N: 228500 S: 215000 Res: 30 E: 645000 W: 63 Res: 30 Range of data: min = 55.1736 max = 156.3865 Data Description: generated by
Re: [GRASS-user] Problem with r.basin in grass7
These various resolutions, referred to as NED layers, are stored and distributed in geographic coordinates at 1/9, 1/3, 1, and 2 seconds of arc. for several reasons r.basin works in projected locations, but not in geographic locations. the NED seems to be geographic. try to reproject your DEM data first into a projected location. regarding the NC sample data set I'll have look later in the day, as in this sample location it works for me. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Problem-with-r-basin-in-grass7-tp5169155p5173943.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] i.maxlik's reject versus i.segment's goodness
On Wed, Nov 19, 2014 at 2:04 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 18/11/14 09:47, Markus Metz wrote: On Sun, Nov 16, 2014 at 3:21 AM, Vaclav Petras wenzesl...@gmail.com wrote: Hi, I executed the examples in i.cluster and i.maxlik manuals and also the following i.segment command: i.segment group=lsat7_2002@w1-imagery output=lsat7_2002_segments threshold=0.5 goodness=lsat7_2002_segments_goodness (using the imagery group created in i.cluster example, otherwise unrelated) I looked at goodness from i.segment and then reject from i.maxlik. I noticed that there is some correlation between these two. Well, this is quite okay since they are using same pixel values. However, then I noticed that low values of goodness (-5000, ...) i.segment's goodness estimate is supposed to be in the range [0,1]. Fixed in r62793,4. Can you test again? Could you explain / put into the manual the explanation of the calculation / meaning of this goodness of fit ? Done in r62830: The goodness of fit for each pixel is calculated as 1 - distance of the pixel to the object it belongs to. The distance is calculated with the selected similarity method. A value of 1 means identical values, perfect fit, and a value of 0 means maximum possible distance, worst possible fit. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
