Re: [GRASS-user] How to assign costs to nodes using v.net.distance
On Mon, Apr 1, 2013 at 10:23 AM, דור פרידמן dof1...@gmail.com wrote: Hi Markus, I was very surprised to read your comment about v.net.distance since the manual indicates the following: v.net.distance - Computes shortest distance via the network between the given sets of features. Finds the shortest paths from each 'from' point to the nearest 'to' feature and various information about this relation are uploaded to the attribute table Is it possible that you had a mistake, or is it that the manual is incorrect? I wrote: I think v.net.distance is the wrong module for this task because it finds for each 'from' feature the nearest 'to' feature and not the shortest path from each 'from' feature to each 'to' feature. From the manual: ...the table has three columns: *cat*, *tcat* and *dist* storing category of each *from* feature, category of the nearest *to* feature and the distance between them respectively. No contradiction AFAICT. How can I assign costs to the destination nodes That does not make sense because destination nodes are usually not crossed. Assigning costs to nodes makes more sense for nodes between the start and the end node. to receive the lowest cost (shortest) path from each origin node to the nearest (cheapest) target node? The shortest path for each 'from' node to the nearest 'to' node is included in the output map. See also the example in the manual. Markus M Best, Dor 2013/3/29 Markus Metz markus.metz.gisw...@gmail.com On Thu, Mar 28, 2013 at 2:52 PM, דור פרידמן dof1...@gmail.com wrote: Hello all, After I've got my v.net.distance up and running I have to adjust my analysis method to the software's capabilities. Basically, I have a 3 layered network: myroads_net2 which contain layers as follow: Layer 1: Arch (roads) Layer 2: Points (Landfills - destinations) Layer 3: Points (Settlements - source) As one might understood I'm trying to calculate the lowest cost route between each settlement (layer 3) to each landfill (layer 2). I think v.net.distance is the wrong module for this task because it finds for each 'from' feature the nearest 'to' feature and not the shortest path from each 'from' feature to each 'to' feature. Actually, I don't think any of the v.net.* modules does exactly that. You could file a ticket for enhancement to request such a module. Roads' costs are constant, which now set to 1 (currency per distance unit - I guess that it is meter). I would like to include a cost for landfill (gate fee) which will be measured with the same currency. MY attempt to use ncolumn (cost for nodes) didn't go well. I have opened a new column (double precision) in layer 2 and named it gatefee. I have assigned 0 to all cats, except cat=3 which I have assigned with 60. My expectation was that at least some of the settlements that were allocated to cat=3 on layer 2 will be allocated to another one. However after running v.net.distance again with ncolumn=gatefee I have found out that more settlements were allocated to cat=3 of layer 2. If I understand the code of v.net.distance correctly, node costs are ignored. Markus M Did I misused that option? I can't find any guide to how to use it in the manual or tutorials and will appreciate an explanation or a reference to such guide or tutorial. Best, Dor ___ 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] Fill area between isolines?
On Fri, Mar 29, 2013 at 4:01 PM, Tim Michelsen timmichel...@gmx-topmail.de wrote: Hello user list, I have a question filling the area between isolines by the values of the isolines (without interpolation): I have a vector with isolines of which the values define certain properties of the area (e.g. cost factor). How can I create an area that fills the area between these lines and to which the same value as the last adjacent line is attached (all points from one line to the other have the same cost factor)? You could try to 1. set the region, e.g. with g.region vect=name_of_isolines_vector res=1 -a (adjust resolution to your needs) 2. convert isolines to raster 3. r.grow.distance value=name_of_filled_areas Markus M I understand that in this case a interpolation is not required. It would be great to receive some helpful hints and tips on above outlined question. Kind regards and thanks in advance, Timmie ___ 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] How to assign costs to nodes using v.net.distance
On Thu, Mar 28, 2013 at 2:52 PM, דור פרידמן dof1...@gmail.com wrote: Hello all, After I've got my v.net.distance up and running I have to adjust my analysis method to the software's capabilities. Basically, I have a 3 layered network: myroads_net2 which contain layers as follow: Layer 1: Arch (roads) Layer 2: Points (Landfills - destinations) Layer 3: Points (Settlements - source) As one might understood I'm trying to calculate the lowest cost route between each settlement (layer 3) to each landfill (layer 2). I think v.net.distance is the wrong module for this task because it finds for each 'from' feature the nearest 'to' feature and not the shortest path from each 'from' feature to each 'to' feature. Actually, I don't think any of the v.net.* modules does exactly that. You could file a ticket for enhancement to request such a module. Roads' costs are constant, which now set to 1 (currency per distance unit - I guess that it is meter). I would like to include a cost for landfill (gate fee) which will be measured with the same currency. MY attempt to use ncolumn (cost for nodes) didn't go well. I have opened a new column (double precision) in layer 2 and named it gatefee. I have assigned 0 to all cats, except cat=3 which I have assigned with 60. My expectation was that at least some of the settlements that were allocated to cat=3 on layer 2 will be allocated to another one. However after running v.net.distance again with ncolumn=gatefee I have found out that more settlements were allocated to cat=3 of layer 2. If I understand the code of v.net.distance correctly, node costs are ignored. Markus M Did I misused that option? I can't find any guide to how to use it in the manual or tutorials and will appreciate an explanation or a reference to such guide or tutorial. Best, Dor ___ 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] Grass7 on FreeBSD 9.1 : LD_SEARCH_FLAGS
On Mon, Mar 25, 2013 at 11:31 PM, Pierre Stévens pie...@geobsd.com wrote:
There are some specific aspects on compiling Grass7 on FreeBSD 9.1.
1. Must use gmake instead of make. 'Make' is different under BSD
Environnement.
This seems to be true for most BSD and UNIX systems.
2. The 'gis.h' header try to include the 'alloca.h' header. On FreeBSD,
alloca() is declared in 'stdlib.h'
(http://forums.freebsd.org/showthread.php?t=30354).
This issue was temporarily fixed with : ' #touch
/usr/local/include/alloca.h '
gis.h is fixed in r55519.
3. Current error appears in ' grass7/dist.i386-freebsd/lib/manage ' :
ld: unrecognized option '-Wl, -rpath, /grass7/dist.i386-freebsd/lib
Possible solution could be found in LD_SEARCH_FLAGS like in this post
(https://trac.osgeo.org/grass/ticket/1757#comment:4).
I try to modify line 562 in ' aclocal.m4 ' and replace
SHLIB_LD=ld -Bshareable -x
by SHLIB_LD=${CC} -shared
But it didn't work.
If you use
SHLIB_LD=${CC} -shared
you must also use
LD_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
You would also need to patch configure or run autoconf (version 2.13).
HTH,
Markus M
PS: grass 7 compiles for me on FreeBSD 9.0 with SHLIB_LD=ld
-Bshareable -x, even though it should actually fail.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Grass7 on FreeBSD 9.1 : LD_SEARCH_FLAGS
On Tue, Mar 26, 2013 at 10:10 AM, Markus Metz
markus.metz.gisw...@gmail.com wrote:
On Mon, Mar 25, 2013 at 11:31 PM, Pierre Stévens pie...@geobsd.com wrote:
There are some specific aspects on compiling Grass7 on FreeBSD 9.1.
1. Must use gmake instead of make. 'Make' is different under BSD
Environnement.
This seems to be true for most BSD and UNIX systems.
2. The 'gis.h' header try to include the 'alloca.h' header. On FreeBSD,
alloca() is declared in 'stdlib.h'
(http://forums.freebsd.org/showthread.php?t=30354).
This issue was temporarily fixed with : ' #touch
/usr/local/include/alloca.h '
gis.h is fixed in r55519.
3. Current error appears in ' grass7/dist.i386-freebsd/lib/manage ' :
ld: unrecognized option '-Wl, -rpath, /grass7/dist.i386-freebsd/lib
Possible solution could be found in LD_SEARCH_FLAGS like in this post
(https://trac.osgeo.org/grass/ticket/1757#comment:4).
I try to modify line 562 in ' aclocal.m4 ' and replace
SHLIB_LD=ld -Bshareable -x
by SHLIB_LD=${CC} -shared
But it didn't work.
If you use
SHLIB_LD=${CC} -shared
you must also use
LD_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
You would also need to patch configure or run autoconf (version 2.13).
HTH,
Markus M
PS: grass 7 compiles for me on FreeBSD 9.0 with SHLIB_LD=ld
-Bshareable -x, even though it should actually fail.
G7 compiles and runs for me on FreeBSD 9.0 with either
SHLIB_LD=${CC} -shared
LD_SEARCH_FLAGS='-Wl,-rpath,${LIB_RUNTIME_DIR}'
or
SHLIB_LD=ld -Bshareable -x
LD_SEARCH_FLAGS='-rpath ${LIB_RUNTIME_DIR}'
The former is now the default in r55521.
Markus M
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] A problem using v.net.distance
On Mon, Mar 25, 2013 at 3:29 PM, דור פרידמן dof1...@gmail.com wrote: Hi All, I'm trying to use v.net distance as follows: I use 3 maps (2 point vectors for locations and 1 polyline vector for roads). I used v.net twice to connect points to the network as follows: v.net input=myroads points=fillsite output=myroads_net1 operation=connect thresh=6000 alayer=1 nlayer=2 v.net input=myroads_net1 points=set1 output=myroads_net2 operation=connect thresh=6000 alayer=1 nlayer=2 Than I have added a column to myroads_net2 named cost (double precision) and updated it with the value 1, since I wanted all the roads to have the same scale. Than I was using v.net.distance as follows: v.net.distance input=myroads_net2 output=test1 afcolumn=cost from_layer=2 to_layer=3 In the manual it is written that a table will be created and linked to the output map (test1) and will contain the from and to category and the distance. The problem is that it doesn't happen: there are no geometrics displayed by test1 and no tables attached to it. When I've tried to view the attribute tables it has printed that I've to connect it to the database by manage tables. What can be the problem and how can I fix it? Can you post the output of v.category option=report for myroads_net2 and test1? Can you also post the output of v.db.connect -p test1? Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.out.ascii bug with where=
On Wed, Mar 20, 2013 at 2:01 PM, Micha Silver mi...@arava.co.il wrote: I need some guidance here. I have a point vector, created using v.to.points. Trying to select out some of the points using v.out.ascii with a where= clause, but I'm getting a few points which do NOT match the where condition. Please try r55482. Markus M Using v.db.select with the same condition works as expected. Here's what I get: GRASS:grass-hecras g.version GRASS 7.0.svn (2013) GRASS:grass-hecras v.info -c n_xsect_pts Displaying column types/names for database connection of layer 1: INTEGER|cat INTEGER|reach INTEGER|station_id GRASS:grass-hecras v.info -c n_xsect_pts layer=2 Displaying column types/names for database connection of layer 2: INTEGER|cat INTEGER|lcat DOUBLE PRECISION|along GRASS:grass-hecras v.db.select n_xsect_pts where=reach=1259 cat|reach|station_id 47|1259|1259001 48|1259|1259002 49|1259|1259003 50|1259|1259004 51|1259|1259005 52|1259|1259006 53|1259|1259007 54|1259|1259008 55|1259|1259009 56|1259|1259010 57|1259|1259011 GRASS:grass-hecras v.out.ascii n_xsect_pts where=reach=1259 columns=reach,station_id layer=1 Fetching data... east|north|cat|reach|station_id 194816.2781556|391418.14073617|15|1338|1338009 - 194785.2522622|391271.38449631|15|1338|1338009 194969.45079367|391550.93984055|16|1338|1338010 195013.09512544|391407.42965867|16|1338|1338010 195056.73945721|391263.91947679|16|1338|1338010 195859.29153025|391864.89133855|17|1729|1729001 195865|391715|17|1729|1729001 195870.70846975|391565.10866145|17|1729|1729001 196110.07342651|391851.71960973|18|1729|1729002 196060.83217701|391710.0322802|18|1729|1729002 196011.59092752|391568.34495067|18|1729|1729002 192978.12160181|391913.80105547|47|1259|1259001 193055|391785|47|1259|1259001 193131.87839819|391656.19894453|47|1259|1259001 193285.50571827|391994.23318538|48|1259|1259002 193239.36927725|391851.50467102|48|1259|1259002 193193.23283624|391708.77615667|48|1259|1259002 .. (lots more correctly matching rows) Note the first 10 or so rows above do NOT match the where condition!?? I tried with several other reach numbers and each time I get a few NON-matching rows in the result. Tearing my hair out Any ideas are certainly welcome, Micha ___ 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] [GRASS-dev] minimal wxPython version
On Tue, Mar 19, 2013 at 6:24 PM, Patrice Dumas pertu...@free.fr wrote: On Tue, Mar 19, 2013 at 02:39:33PM +0100, Anna Kratochvílová wrote: Hi all, I would like to change minimal required version of wxPython [1]. Currently we support (theoretically) version 2.8.1.1 (released 2007). I suggest to change it to 2.8.10.1 (2009), for example 2.8.10.1 was shipped with Ubuntu 10.04 LTS. The reason is obvious: wxGUI is limited by this requirement. Even the 2.8.10.1 version is pretty old so I think this won't hurt anybody. Any objections? epel 5 (add-on repository for rhel 5, the oldest still maintained rhel distribution) has 2.8.12. I am not sure that more conservative repositories have this version, but at least it is available in one repository with a sufficiently high version. Another old but still maintained repository, ports for FreeBSD 8.3, has python 2.7 and wxpython 2.8.12. No objections. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.overlay and points?
On Tue, Mar 19, 2013 at 2:50 PM, charlie caro...@yahoo.com wrote: Nikos, Thanks for the reply. Will v.patch merge the attribute table so all of the data will be combined together in a new attribute table? I am trying to merge 2 files, one with plot and address info (area) and the second with property owner info (point). Both of these files contain information about the the plot of land hence they precisely overlay each other, but neither contain any data, besides geography,that can be used to merge the files. That sounds more like a job for v.distance where you can upload attributes from the nearest feature in map B to Map A. In GRASS 6 you can upload area info to the points, in GRASS 7 you can also upload point info to the areas. HTH, Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Migrate to Grass 7 question; vector topology?
On Mon, Mar 18, 2013 at 1:21 PM, Nikos Alexandris n...@nikosalexandris.net wrote: in G6, revision=55280M real2m4.002s user1m19.377s sys 0m9.093s # v.info -t returns nodes=63241 [snip] in G7, revision=55284M real0m33.384s user0m29.194s sys 0m4.092s # v.info -t returns nodes=32698 [snip] ps- Curious: why is the reported number of nodes different? In G7, points and centroids no longer have nodes. Nodes are only used to connect lines/boundaries (G6 + G7). Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.resamp.rst error : Not enough disk space--cannot write files
On Sun, Mar 10, 2013 at 11:28 PM, bidon sanshuile piano...@hotmail.com wrote: Date: Sun, 10 Mar 2013 20:24:08 +0100 Subject: Re: [GRASS-user] r.resamp.rst error : Not enough disk space--cannot write files From: markus.metz.gisw...@gmail.com To: piano...@hotmail.com CC: grass-user@lists.osgeo.org On Sun, Mar 10, 2013 at 7:41 PM, bidon sanshuile piano...@hotmail.com wrote: Date: Sun, 10 Mar 2013 16:28:49 +0100 Subject: Re: [GRASS-user] r.resamp.rst error : Not enough disk space--cannot write files From: markus.metz.gisw...@gmail.com To: piano...@hotmail.com CC: grass-user@lists.osgeo.org On Sun, Mar 10, 2013 at 9:33 AM, bidon sanshuile piano...@hotmail.com wrote: Hello, I'm in an internship for a marine institute and try to calculate the sandwaves migration rate. Everything was ok until today. I am confronted to a difficulty I cannot manage. When I try to use the tool r.resamp.rst, it gives me as answer: r.resamp.rst input=map@PERMANENT ew_res=11 ns_res=11 pcurv=curv Processing all selected output files will require Note that this message: 261320 bytes of disk space for temp files. is bogus for large regions with fine resolution because of integer overflow (fixed in trunk). How many cells are in your current region with resolution=11? Thank you for your answers! Here are the characteristics of the raster: | Rows: 3062 | | Columns: 2587 | | Total Cells: 7921394 I don't know how many of these have a resolution of 11. You need to provide the output of g.region -p. Note that all cells have the same resolution, and that r.resamp.rst is typically used to resample to a finer resolution, e.g. 20 to 10 map units. Here is the result: projection: 0 (x,y) zone: 0 north: 5682231.5 south: 5679169.5 west: 469641.5 east: 472228.5 nsres: 1 ewres: 1 rows: 3062 cols: 2587 cells: 7921394 I must admit that I am quite new in GRASS, and I don't master all the concepts. Is the raster too big? Do I have to increase the memory allocated? In this last case, I don't know at all which module to use. The raster does not seem too big, but r.resamp.rst needs quite a bit of disk space depending on the selected output maps. In this case, the target resolution 11 is larger than the source resolution 1. You would rather want to use r.resamp.stats in order to aggregate several input cells into one output cell. r.resamp.rst is meant to be used when you want to go to a finer resolution, e.g. from 10 to 1. Markus M . I am following a step by step manual where they advise to set ew_res at this value. Why 11 and not 10? It doesn't work for both ^^ It works until I put 7, but I would like to make it as written in the manual, to be precise enough. Markus M What filesystem? FAT32 cannot support files larger than 4 GiB; NTFS shouldn't have any problems. My two hard discs are NTFS Temporarily changing the region to desired resolution ... Changing back to the original region ... Percent complete: Not enough disk space--cannot write files Not enough disk space--cannot write files Not enough disk space--cannot write files Not enough disk space--cannot write files . interpolate() failed dnorm in mainc after grid before out1= 12.961481 ERROR: split_and_interpolate() failed I have 14GB left on my hard disk so I don't understand why they are saying me that :/ I tried to find solution, and I found some answers (e.g. here : http://lists.osgeo.org/pipermail/grass-dev/2005-April/018152.html) but I dont understand ^^ They speak about a ulimit -f function, but where should I write it ? It doesn't work in GRASS. I am on windows, maybe is that the problem. SO in conclusion, I am more than lost so if someone could help me it would be perfect! Thank you, b.raoul ___ 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] r.resamp.rst error : Not enough disk space--cannot write files
On Sun, Mar 10, 2013 at 9:33 AM, bidon sanshuile piano...@hotmail.com wrote: Hello, I'm in an internship for a marine institute and try to calculate the sandwaves migration rate. Everything was ok until today. I am confronted to a difficulty I cannot manage. When I try to use the tool r.resamp.rst, it gives me as answer: r.resamp.rst input=map@PERMANENT ew_res=11 ns_res=11 pcurv=curv Processing all selected output files will require Note that this message: 261320 bytes of disk space for temp files. is bogus for large regions with fine resolution because of integer overflow (fixed in trunk). How many cells are in your current region with resolution=11? Markus M Temporarily changing the region to desired resolution ... Changing back to the original region ... Percent complete: Not enough disk space--cannot write files Not enough disk space--cannot write files Not enough disk space--cannot write files Not enough disk space--cannot write files . interpolate() failed dnorm in mainc after grid before out1= 12.961481 ERROR: split_and_interpolate() failed I have 14GB left on my hard disk so I don't understand why they are saying me that :/ I tried to find solution, and I found some answers (e.g. here : http://lists.osgeo.org/pipermail/grass-dev/2005-April/018152.html) but I dont understand ^^ They speak about a ulimit -f function, but where should I write it ? It doesn't work in GRASS. I am on windows, maybe is that the problem. SO in conclusion, I am more than lost so if someone could help me it would be perfect! Thank you, b.raoul ___ 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] weighted mean
On Sat, Mar 9, 2013 at 12:06 AM, Giuliano Urgeghe giulian...@gmail.com wrote: Hi, does anyone here know if there is a command in Grass that calculates the weighted mean (on areas) of values in a coloumn in the attribute table of a vector layer? v.univar calculates for areas the mean from values in a column in the attribute table weighted by the size of each area. Is this what you are looking for? Markus M Since I need to execute this command for several vector layers, would it be possible to automatically create a new tablet filled with the calculated values? I thank you in advance for your reply. Best regards. -- Ing. Giuliano Urgeghe Via Prunizzedda 61 - 07100 Sassari giulian...@gmail.com tel. 3283268186 ___ 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] r.resamp.rst error : Not enough disk space--cannot write files
On Sun, Mar 10, 2013 at 7:41 PM, bidon sanshuile piano...@hotmail.com wrote: Date: Sun, 10 Mar 2013 16:28:49 +0100 Subject: Re: [GRASS-user] r.resamp.rst error : Not enough disk space--cannot write files From: markus.metz.gisw...@gmail.com To: piano...@hotmail.com CC: grass-user@lists.osgeo.org On Sun, Mar 10, 2013 at 9:33 AM, bidon sanshuile piano...@hotmail.com wrote: Hello, I'm in an internship for a marine institute and try to calculate the sandwaves migration rate. Everything was ok until today. I am confronted to a difficulty I cannot manage. When I try to use the tool r.resamp.rst, it gives me as answer: r.resamp.rst input=map@PERMANENT ew_res=11 ns_res=11 pcurv=curv Processing all selected output files will require Note that this message: 261320 bytes of disk space for temp files. is bogus for large regions with fine resolution because of integer overflow (fixed in trunk). How many cells are in your current region with resolution=11? Thank you for your answers! Here are the characteristics of the raster: | Rows: 3062 | | Columns: 2587 | | Total Cells: 7921394 I don't know how many of these have a resolution of 11. You need to provide the output of g.region -p. Note that all cells have the same resolution, and that r.resamp.rst is typically used to resample to a finer resolution, e.g. 20 to 10 map units. . I am following a step by step manual where they advise to set ew_res at this value. Why 11 and not 10? Markus M What filesystem? FAT32 cannot support files larger than 4 GiB; NTFS shouldn't have any problems. My two hard discs are NTFS Temporarily changing the region to desired resolution ... Changing back to the original region ... Percent complete: Not enough disk space--cannot write files Not enough disk space--cannot write files Not enough disk space--cannot write files Not enough disk space--cannot write files . interpolate() failed dnorm in mainc after grid before out1= 12.961481 ERROR: split_and_interpolate() failed I have 14GB left on my hard disk so I don't understand why they are saying me that :/ I tried to find solution, and I found some answers (e.g. here : http://lists.osgeo.org/pipermail/grass-dev/2005-April/018152.html) but I dont understand ^^ They speak about a ulimit -f function, but where should I write it ? It doesn't work in GRASS. I am on windows, maybe is that the problem. SO in conclusion, I am more than lost so if someone could help me it would be perfect! Thank you, b.raoul ___ 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] importing raster from a linear projection into current location
On Fri, Mar 1, 2013 at 11:06 PM, Sebastian P. Luque splu...@gmail.com wrote: On Fri, 1 Mar 2013 22:42:56 +0100, Markus Neteler nete...@osgeo.org wrote: On Fri, Mar 1, 2013 at 9:53 PM, Seb splu...@gmail.com wrote: Hi, I am trying to import a series of rasters (HDF) in a linear projection, i.e. without any projection information, where x and y are simple indexes; gdalinfo shows: Could you say a bit more about the HDF files? The xy output is probably right but GCPs may be in the file itself (so gdalwarp is needed or the like). This file was produced with WIM/WAM (wimsoft.com), and the full output of gdalinfo is: $ gdalinfo chl_48_200.hdf Driver: HDF4Image/HDF4 Dataset Files: chl_48_200.hdf Size is 1572, 1114 Coordinate System is `' Metadata: Base=10 Intercept=-2 Map Projection=WIM Linear Scaling=Logarithmic Slope=0.015 WIM Color Range=0, 255 WIM Color Stretch=48, 200 WIM Linear Coeffs=45, 0.012723, -40, -0.008977 Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 1114.0) Upper Right ( 1572.0,0.0) Lower Right ( 1572.0, 1114.0) Center ( 786.0, 557.0) Band 1 Block=1572x636 Type=Byte, ColorInterp=Gray The relevant information is in the WIM Linear Coeffs line, where 45, -40 are the coordinates of the upper right corner of the map, and 0.012723, -0.008977 are the lon, lat resolution. It seems that you need to override the projection check with r.in.gdal -o. After that, you need to fix the raster metadata with r.region. The lon, lat resolutions look really weird, BTW. Markus M Thanks, -- Seb ___ 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] importing raster from a linear projection into current location
On Fri, Mar 1, 2013 at 11:34 PM, Seb splu...@gmail.com wrote: On Fri, 1 Mar 2013 23:16:54 +0100, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Mar 1, 2013 at 11:06 PM, Sebastian P. Luque splu...@gmail.com wrote: On Fri, 1 Mar 2013 22:42:56 +0100, Markus Neteler nete...@osgeo.org wrote: On Fri, Mar 1, 2013 at 9:53 PM, Seb splu...@gmail.com wrote: Hi, I am trying to import a series of rasters (HDF) in a linear projection, i.e. without any projection information, where x and y are simple indexes; gdalinfo shows: Could you say a bit more about the HDF files? The xy output is probably right but GCPs may be in the file itself (so gdalwarp is needed or the like). This file was produced with WIM/WAM (wimsoft.com), and the full output of gdalinfo is: $ gdalinfo chl_48_200.hdf Driver: HDF4Image/HDF4 Dataset Files: chl_48_200.hdf Size is 1572, 1114 Coordinate System is `' Metadata: Base=10 Intercept=-2 Map Projection=WIM Linear Scaling=Logarithmic Slope=0.015 WIM Color Range=0, 255 WIM Color Stretch=48, 200 WIM Linear Coeffs=45, 0.012723, -40, -0.008977 Corner Coordinates: Upper Left ( 0.0, 0.0) Lower Left ( 0.0, 1114.0) Upper Right ( 1572.0, 0.0) Lower Right ( 1572.0, 1114.0) Center ( 786.0, 557.0) Band 1 Block=1572x636 Type=Byte, ColorInterp=Gray The relevant information is in the WIM Linear Coeffs line, where 45, -40 are the coordinates of the upper right corner of the map, and 0.012723, -0.008977 are the lon, lat resolution. It seems that you need to override the projection check with r.in.gdal -o. After that, you need to fix the raster metadata with r.region. If I do that I get: r.in.gdal -o input=chl_48_200.hdf output=chl_48_200 Over-riding projection check G_set_window(): Illegal latitude for North Oops. I forgot, you also need the -l flag for r.in.gdal to force Lat/Lon maps to fit into geographic coordinates (90N,S; 180E,W). After that you need to run r.region, otherwise the raster is not usable. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Forward and backward RMS error.
On Wed, Feb 27, 2013 at 3:57 PM, Aldo Clerici aldo.cler...@unipr.it wrote: Dear GRASS users and developers, where can I find an explanation about the meaning of forward and backward RMS errors in i.points? In the 6.4.3 and 6.5 manuals for i.points a unique value for RMS error is reported, but the two values are actually computed. In 7.0 manual the two values are mentioned but no description of their meaning is reported. How can the two values be used to evaluate accuracy in georectification? Which is used to rectify the map? i.points, i.rectify, etc. calculate transformation equations from ground control points (GCPs). RMS (root mean square) errors are then determined by transforming each GCP and calculating the root mean square from the deviations of the transformed coordinates from the GCP coordinates. Since you can transform coordinates from source to target (forward) and from target to source (backward), you can also calculate two RMS errors. The forward RMS error is probably of more interest and ideally smaller than the target resolution (sub-pixel transformation accuracy). HTH, Markus M Many thanks in advance. Aldo Clerici Earth Sciences Dep. Parma University ___ 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] v.transform reports erroneous values in the transformation matrix
On Tue, Feb 26, 2013 at 2:17 PM, José María Michia Roberts jose.maria.mic...@gmail.com wrote: Hi all! I've found that values of transformation matrix reported by v.transform are erroneous after using this values in ST_Affine (a PostGIS's function). The values that seems to be erroneous are x_offset and y_offset. The rotation values seems to are fine. The transformed elements are ok (it is, their coordinates are in the right place). Values reported by v.transform: xoff = -139153.031250 yoff = 8352534.450195 The correct values must be (aproximately): xoff = 5461371 yoff = 6321181 The complete session's log with one test element is there (same results with a whole layer): http://pastebin.com/FUtnePvb Local map: tmp Transformed map: tmp_geo Take a look at the map region for tmp/tmp_geo (reported by v.info), and compare these values with those of x_off / y_off (reported by v.transform). Note that there are two transformation matrices, one for forward transformation, one for backward transformation. Can the PostGIS ST_Affine function print both matrices? If possible, rather use v.rectify in GRASS 7 instead of v.transform in GRASS 6. With a recent version of GDAL/OGR, you can also add GCPs to a datasource with ogr2ogr -gcp which should then automatically transform the coordinates. Markus M Maybe I'm not interpreting this correctly. Thanks all! Jose ___ 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] Apply v.transform in polygons with overlays
On Tue, Feb 26, 2013 at 2:36 PM, Jose M Michia Roberts jose.maria.mic...@gmail.com wrote: 2013/2/26 Benjamin Ducke bendu...@fastmail.fm: A fix might be to introduce a new GRASS env variable that can be set to suppress the cleaning functions. While it would probably be trivial to implement this, it would also break with GRASS' basic design and the assumptions that its vector processing modules make (namely that the input data is topologically correct). Yes, I know. But I think that there are some cases, like this, where the overlaps between polygons are part of the information and need to be preserved. The overlaps between polygons are only preserved if you do not use the -c flag for v.in.ogr. Each original polygon can then be recreated with v.extract -d cat=X. If you use the -c flag with v.in.ogr, you are on your own. BTW, v.transform simply transforms coordinates, it does not do any cleaning. v.transform should actually work without topology, building topology on the output is optional (in GRASS 7). And I understand that a situation like this would limit the application of other modules. Maybe I'm totally wrong: I still have so much to study about GRASS! For this particular problem (georectifying overlapping polygons) there is probably an easier solution outside GRASS. Maybe QGIS supports coordinate transformation/rectification using GCPs? Markus M (english too... right?) :D Thanks, Jose ___ 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] How to calculates linear regression from three or more raster maps?
On Fri, Feb 22, 2013 at 9:44 AM, 王德辉 deh...@gig.ac.cn wrote: I want to caculate linear regression function of X1 raster map to X2,X3,X4. The addon r.regression.multi (GRASS 7 only) does that [0]. Markus M [0] http://grasswiki.osgeo.org/wiki/AddOns/GRASS7/raster#r.regression.multi r.series can not do it. Thanks! dehui 在2013-02-22 16:02:00,王德辉deh...@gig.ac.cn写道： =?GBK?B?zfW1wrvU?= wrote: How to calculates linear regression from three or more raster maps £¨X1 = a + bX2 + cX3 +dX4 + ...)? r.series with a method of slope, offset and/or detcoeff. -- Glynn Clements gl...@gclements.plus.com ___ 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] r.proj - how to use different dbase?
On Sat, Feb 16, 2013 at 4:50 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Dear all, I have two grass spatial database, each on different directory and with different projection/datum. How can I import a raster map while reprojectingit? Just suppose I am connected on C:\Mydata\GrassSDB_target newLocation PERMANENT and the source data are on C:\users\GrassSDB_source newLocation PERMANENT mymap_UTM_sad69 I tryed something like r.proj input=mymap_UTM_sad69 location=newLocation mapset=PERMANENT dbase=C:\users\GrassSDB_source But I get ERRO:Mapset PERMANENT in input location newLocation - not found Any idea of how to solve this? r.proj tests first for the same location name, which in your case is identical. Try to rename one and only one of your newLocation locations, then try r.proj again. This is a bug in r.proj. HTH, Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] getting from DBF to SQLite
On Fri, Feb 15, 2013 at 8:21 AM, Micha Silver mi...@arava.co.il wrote: On 15/02/2013 01:42, Hamish wrote: Markus Metz wrote: In GRASS 6.4.1- it was possible to have a separate sqlite db for each vector in $MAPSET/vector/$MAP/sqlite.db. I have no idea why this option has been disabled. The VAR file can be DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/vector/$MAP/sqlite.db Should we revert the changes that make it now impossible to have a separate sqlite db for each vector? AFAIK it's still possible to have a separate sqlite db for each vector if you use v.db.connect (see v.pack.py), it's just that you can't tell db.connect to make that the default for all new maps. perhaps if [v.]db.connect understood to parse '$MAP' you could have a portable database='$GISDBASE/$LOCATION_NAME/$MAPSET/vector/$MAP/sqlite.db' string saved in the VAR file? (and so, by default but user- alterable, all sqlite layers for that map saved in the same file) db.sqlite or sqlite.db for the filename? If the $MAP variable is available, I'd like to see the database names as '$GISDBASE/$LOCATION_NAME/$MAPSET/vector/sqlite/$MAP.sqlite' This could cause problems with SQLite directory locking because of [0]. Therefore I would prefer to restore the previous behaviour of allowing '$GISDBASE/$LOCATION_NAME/$MAPSET/vector/$MAP/sqlite.db Markus M [0] http://www.sqlite.org/lockingv3.html and I think you're suggestion to put all layers for a vector into one sqlite file does make sense. THere are definitely situations where you want to join between different layers within the same vector. Having both in the same sqlite makes that easier. Hamish ___ 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 GIS Consulting 052-3665918 http://www.surfaces.co.il ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] getting from DBF to SQLite
On Thu, Feb 14, 2013 at 12:50 AM, Hamish hamis...@yahoo.com wrote: Richard wrote: Is it is possible to set a single SQLite database for the entire GRASS GIS database or each mapset requires its own sqlite db file? organize your system as you like, but be sure to ask yourself what happens to portability with 32bit machines and/or filesystems when the overall DB file gets to be larger than 2gb or 4gb in size. The maximum file size of a SQLite db is 140 TB, independent of the architecture, i.e. LFS is always there. Usually SQLite will hit the maximum file size limit of the underlying filesystem or disk hardware size limit long before it hits its own internal size limit [0]. Markus M [0] http://www.sqlite.org/fileformat2.html Even per-mapset sqlite DBs worry me a bit for that, not to mention the damage-fallout from a bad HD sector or accidental `rm` and ease of moving stuff to another mapset/ system by hand. Hamish ___ 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] getting from DBF to SQLite
On Thu, Feb 14, 2013 at 11:26 PM, Hamish hamis...@yahoo.com wrote: Hamish wrote: I thought the question was still up in the air for g7 and for now it was user choosable by the way you constructed the db.connect string. Michael: How can you change the default by changing the db.connect string? I'd like to do it. I don't think it is all that difficult connecting tables across different vector objects, but agree (and said at the time) that it is probably a pretty rare occurrence in reality. hmm, I thought it did emulate the dbf way if you only speficied the directory, but just testing it looks like it doesn't: [trunk] cd $MAPSET mkdir sqlite db.connect driver=sqlite database='$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/' echo 1|2|abc | v.in.ascii in=- out=testmap ... DBMI-SQLite driver error: Unable to open database: unable to open database file we definitely should make that option work for people who want/need that though. :) Is there a reason to collect them in a common $MAPSET/dbf/ or $MAPSET/sqlite/ dir instead of under $MAPSET/vector/$MAPNAME/sqlite.db ? (and would you want separate sqlite db files for each db layer, or for a single map keep all of the layer connections using the sqlite driver all in the same sqlite file?) I guess the reason for one common sqlite database is the ability to do joins. In GRASS 6.4.1- it was possible to have a separate sqlite db for each vector in $MAPSET/vector/$MAP/sqlite.db. I have no idea why this option has been disabled. The VAR file can be DB_DRIVER: sqlite DB_DATABASE: $GISDBASE/$LOCATION_NAME/$MAPSET/vector/$MAP/sqlite.db Should we revert the changes that make it now impossible to have a separate sqlite db for each vector? Markus M Note v.pack(.py) demos the method to make a $MAPSET/vector/ $MAPNAME/db.sqlite per-map extract. Hamish ___ 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] Count points in a network between two locations
On Tue, Feb 5, 2013 at 5:22 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 04/02/13 18:54, Moritz Lennert wrote: in the code of v.distance, there is a TODO at that point related to this issue: /* TODO: all cats of given field ? */ So, either we have to enhance v.distance to take into account all cat values in a given layer, or for this particular issue, the old version of v.net.allpairs is actually easier to use. Maybe a flag to v.net.allpairs could allow to not remove duplicates ? In the current version, v.net.allpairs does not remove duplicates, it avoids duplicates. The current output is more in accordance with the GRASS vector model, but if this output is more (or too) difficult to post-process, it can be reverted to the old behaviour. I would suggest to wait for some more feedback. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Count points in a network between two locations
On Tue, Feb 5, 2013 at 5:54 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 05/02/13 16:56, Markus Metz wrote: On Tue, Feb 5, 2013 at 5:22 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 04/02/13 18:54, Moritz Lennert wrote: in the code of v.distance, there is a TODO at that point related to this issue: /* TODO: all cats of given field ? */ So, either we have to enhance v.distance to take into account all cat values in a given layer, or for this particular issue, the old version of v.net.allpairs is actually easier to use. Maybe a flag to v.net.allpairs could allow to not remove duplicates ? In the current version, v.net.allpairs does not remove duplicates, it avoids duplicates. Yes, sorry for the misformulation. What I meant was that it is not possible to simply deactivate duplicate removal because duplicates are never created. Adding such a flag would mean to add the code of the version with duplicates, then run either version 1 or version 2. Markus M The current output is more in accordance with the GRASS vector model, but if this output is more (or too) difficult to post-process, it can be reverted to the old behaviour. I'm all for the accordance with the vector model, and so am not sure I would like to see this reversed. Ideally, it is v.distance that would need to be enhanced to take into account multiple cats in from and to features. However, if enhancing v.distance proves a bigger challenge, I thought that maybe we could create a flag in v.net.allpairs that if set would create output in the old way (duplicate lines) in order to allow treatment such as the v.distance one I explained. I would suggest to wait for some more feedback. Ok. Happy hacking at the sprint ! Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Interpolation with v.surf.rst
On Mon, Feb 4, 2013 at 9:20 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 03/02/13 16:53, Martin Landa wrote: 2013/2/3 Moritz Lennertmlenn...@club.worldonline.be: * if input is 2D and zcolumn is not given - using categories I'm pretty sure that this will create lots of confusion. I think in this case it should fail with an error message. +1 Using categories as elevation does not really make sense IMHO. Markus M just note, it's current behaviour. Martin Only in GRASS7 and I have to admit I hadn't noticed this, yet, or otherwise I would have reacted before. In grass6: v.surf.rst input=elev_lid792_randpts@PERMANENT elev=elevation ERROR: Value to be interpolated needs to be defined by zcol or -z flag Moritz ___ 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] Count points in a network between two locations
On Sat, Feb 2, 2013 at 12:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/02/13 19:55, Markus Metz wrote: On Fri, Feb 1, 2013 at 6:39 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/02/13 11:44, Johannes Radinger wrote: the problem is that the v.net.allpairs lines are partly overlapping (sharing parts). So there are several barriers on partly overlapping lines, but I want to select all barriers per line category. IIUC v.net.allpairs actually creates several duplicate segments which seems contrary to GRASS topology rules. GRASS topology supports overlapping lines. Yes, but having several overlapping line segments that are actually the representation of the exact same path kind of seems against the idea of not duplicating information if not necessary. Shouldn't these rather be represented by single segments with multiple category values (like v.buffer in grass7) ? Yes, but only if the segment directions are also identical. For example, if backward direction costs are identical to forward direction costs, the path from node A to node B is a duplicate of the path from node B to node A, but in reverse direction. Right, didn't think about direction here. I was more thinking about the situation where paths from A to B, C, D, E all have a common part before forking to the respective destination later on. But I guess even for this situation overlapping lines are not so much of an evil to justify making this into an issue. Fixed in r54893. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Count points in a network between two locations
On Mon, Feb 4, 2013 at 1:49 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 04/02/13 12:29, Markus Metz wrote: On Sat, Feb 2, 2013 at 12:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/02/13 19:55, Markus Metz wrote: On Fri, Feb 1, 2013 at 6:39 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/02/13 11:44, Johannes Radinger wrote: the problem is that the v.net.allpairs lines are partly overlapping (sharing parts). So there are several barriers on partly overlapping lines, but I want to select all barriers per line category. IIUC v.net.allpairs actually creates several duplicate segments which seems contrary to GRASS topology rules. GRASS topology supports overlapping lines. Yes, but having several overlapping line segments that are actually the representation of the exact same path kind of seems against the idea of not duplicating information if not necessary. Shouldn't these rather be represented by single segments with multiple category values (like v.buffer in grass7) ? Yes, but only if the segment directions are also identical. For example, if backward direction costs are identical to forward direction costs, the path from node A to node B is a duplicate of the path from node B to node A, but in reverse direction. Right, didn't think about direction here. I was more thinking about the situation where paths from A to B, C, D, E all have a common part before forking to the respective destination later on. But I guess even for this situation overlapping lines are not so much of an evil to justify making this into an issue. Fixed in r54893. v.net in=roadsmajor points=schools_wake out=network --o op=connect thresh=500 time v.net.allpairs input=network@user1 output=allpairs cats=1-999 --o r53630 real0m0.992s user0m0.416s sys 0m0.436s r54893 Ctrl-C at 78%: real26m37.379s user26m12.010s sys 0m10.641s This is on a very old system (P4 !), but still, this seems a very strong performance regression. Fixed in r54895. Instead of cleaning up duplicates afterwards, the module now avoids duplicates. Trying to run with tool=break,rmdupl gives me the following error: ERROR: Nodes not available for line 1 The type option was missing, or in other words, tool=break works only for lines and boundaries, points are not supported, and a corresponding test is (yet) missing. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Count points in a network between two locations
On Mon, Feb 4, 2013 at 3:41 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 04/02/13 14:52, Markus Metz wrote: On Mon, Feb 4, 2013 at 1:49 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 04/02/13 12:29, Markus Metz wrote: On Sat, Feb 2, 2013 at 12:51 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/02/13 19:55, Markus Metz wrote: On Fri, Feb 1, 2013 at 6:39 PM, Moritz Lennert mlenn...@club.worldonline.bewrote: On 01/02/13 11:44, Johannes Radinger wrote: the problem is that the v.net.allpairs lines are partly overlapping (sharing parts). So there are several barriers on partly overlapping lines, but I want to select all barriers per line category. IIUC v.net.allpairs actually creates several duplicate segments which seems contrary to GRASS topology rules. GRASS topology supports overlapping lines. Yes, but having several overlapping line segments that are actually the representation of the exact same path kind of seems against the idea of not duplicating information if not necessary. Shouldn't these rather be represented by single segments with multiple category values (like v.buffer in grass7) ? Yes, but only if the segment directions are also identical. For example, if backward direction costs are identical to forward direction costs, the path from node A to node B is a duplicate of the path from node B to node A, but in reverse direction. Right, didn't think about direction here. I was more thinking about the situation where paths from A to B, C, D, E all have a common part before forking to the respective destination later on. But I guess even for this situation overlapping lines are not so much of an evil to justify making this into an issue. Fixed in r54893. v.net in=roadsmajor points=schools_wake out=network --o op=connect thresh=500 time v.net.allpairs input=network@user1 output=allpairs cats=1-999 --o r53630 real0m0.992s user0m0.416s sys 0m0.436s r54893 Ctrl-C at 78%: real26m37.379s user26m12.010s sys 0m10.641s This is on a very old system (P4 !), but still, this seems a very strong performance regression. Fixed in r54895. Instead of cleaning up duplicates afterwards, the module now avoids duplicates. Now I get a segfault. gdb full backtrace and DEBUG=3 log attached. Do you need something else ? Should be fixed in r54897. Sprinting a bit fast, Markus M Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Count points in a network between two locations
On Mon, Feb 4, 2013 at 4:41 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 04/02/13 16:07, Markus Metz wrote: On Mon, Feb 4, 2013 at 3:41 PM, Moritz Lennert Now I get a segfault. gdb full backtrace and DEBUG=3 log attached. Do you need something else ? Should be fixed in r54897. The module runs now and very fast, but weirdly enough I cannot display the category values in the resulting map. Using wxgui, I get The command 'd.vect map=allpairs@user1 type=point,line,area,face display=shape,cat' has failed The same for d.vect map=allpairs@user1 layer=1 type=line display=shape,cat Trying to run this on the command line: d.mon cairo d.vect map=allpairs@user1 layer=1 type=line display=shape,cat Gives me a seg fault at Debug=3: D3/3: cat lab: field = 1, cat = 1121 D3/3: Vect_read_next_line(): next_line = 53 D3/3: V2_read_next_line_nat() D3/3: Vect__Read_line_nat: offset = 95566 D3/3: type = 2, do_cats = 1 dead = 0 D3/3: n_cats = 96 D3/3: n_points = 41 Erreur de segmentation gdb: Program received signal SIGSEGV, Segmentation fault. dig_alloc_points (points=0x313231, num=42) at struct_alloc.c:338 338 alloced = points-alloc_points; The segfault is caused by d.vect because the maximum text length is 100 characters only !!! I'm going to fix it. Another bug in d.vect is the use of sprintf(text, %s%d, text, cat), for which the behaviour is undefined. Looking at the map I do get out of the operation (attached) I would think that the list of cats for a given segment might just be too long... I guess my idea was maybe not so wise and your original implementation was actually better. Sprinting a bit fast, Hey, that's what sprints are for, no ? I'd call this agile programming ;-) Thanks ;-) Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Count points in a network between two locations
On Mon, Feb 4, 2013 at 5:01 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Mon, Feb 4, 2013 at 4:41 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 04/02/13 16:07, Markus Metz wrote: On Mon, Feb 4, 2013 at 3:41 PM, Moritz Lennert Now I get a segfault. gdb full backtrace and DEBUG=3 log attached. Do you need something else ? Should be fixed in r54897. The module runs now and very fast, but weirdly enough I cannot display the category values in the resulting map. Using wxgui, I get The command 'd.vect map=allpairs@user1 type=point,line,area,face display=shape,cat' has failed The same for d.vect map=allpairs@user1 layer=1 type=line display=shape,cat Trying to run this on the command line: d.mon cairo d.vect map=allpairs@user1 layer=1 type=line display=shape,cat Gives me a seg fault at Debug=3: D3/3: cat lab: field = 1, cat = 1121 D3/3: Vect_read_next_line(): next_line = 53 D3/3: V2_read_next_line_nat() D3/3: Vect__Read_line_nat: offset = 95566 D3/3: type = 2, do_cats = 1 dead = 0 D3/3: n_cats = 96 D3/3: n_points = 41 Erreur de segmentation gdb: Program received signal SIGSEGV, Segmentation fault. dig_alloc_points (points=0x313231, num=42) at struct_alloc.c:338 338 alloced = points-alloc_points; The segfault is caused by d.vect because the maximum text length is 100 characters only !!! I'm going to fix it. Fixed in r54906. Looking at the map I do get out of the operation (attached) I would think that the list of cats for a given segment might just be too long... I guess my idea was maybe not so wise and your original implementation was actually better. It displays now correct, but correct means long read lines with category numbers. Actually, the display would look the same with duplicate lines. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Count points in a network between two locations
On Fri, Feb 1, 2013 at 6:39 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 01/02/13 11:44, Johannes Radinger wrote: Thank you, that might work. I just realized that my permeabilities are given as probability and they are added up by a multiplication rule. Thus I don't need the sum but rather the product or at least a list of all barries between to sampling stations At this stage costs can only be summed AFAIK. thats what I tried now, v.distance to get from barriers to nearest vector lines from v.net.allpairs, but the problem is that the v.net.allpairs lines are partly overlapping (sharing parts). So there are several barriers on partly overlapping lines, but I want to select all barriers per line category. IIUC v.net.allpairs actually creates several duplicate segments which seems contrary to GRASS topology rules. GRASS topology supports overlapping lines. Shouldn't these rather be represented by single segments with multiple category values (like v.buffer in grass7) ? Yes, but only if the segment directions are also identical. For example, if backward direction costs are identical to forward direction costs, the path from node A to node B is a duplicate of the path from node B to node A, but in reverse direction. So, a solution could be to loop over the all lines (categories) and use v.select as v.select does not have any option for stratified selection (e.g. per category)... I'll try that now, but any other recommendations are mostly welcome... How about v.distance -a to get a complete distance matrix between nodes and paths and then select those elements where distance = 0 (supposing that you snapped the nodes onto the network) ? Another idea would be to look at linear referencing, the v.lrs.* modules. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.out.ascii with vector created by v.net.allpairs
On Thu, Jan 31, 2013 at 11:00 AM, Johannes Radinger johannesradin...@gmail.com wrote: You could 1) create new categories in a new layer with v.category 2) add columns from_cat, to_cat to the new layer 3) upload values by assigning from_cat (new layer) = cat (old layer) and to_cat (new layer) = to_cat (old layer) That sounds like a good idea, but somehow I fail. What I did was: 1) create a new attribute table/layer for the vector point map with v.db.addtable map=orig table=new_table layer=2 2) The second layer does have a cat column but without any entries yet. So far so good So I tried as you said to create new unique categories in this new layer with v.category input=orig output=new layer=2 But here I get following error: Copying attribute table(s)... DBMI-SQLite driver error: Error in sqlite3_step(): indexed columns are not unique WARNING: Unable to create index for table new_1, key cat Try to start everything again anew with dbf as default database connection. This should avoid the index problem because dbf does not support indexing. v.category copies the map to a new one and tries to connect both attribute tablesbut there are no unique cat values in table/layer 1 Is it possible to update layer to without copying the whole map with both layers (v.category) to get new cats in layer 2... But you need the attribute table for layer 1 in order to create the desired attribute table for layer 2? HTH Markus M Anyway it seems the easiest way is to just fetch the entries with db.select as Markus said before. ...or to use GRASS7 :) /johannes ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] unexpected i.pansharpen results
On Thu, Jan 31, 2013 at 7:06 PM, Michael Barton michael.bar...@asu.edu wrote: i.pansharpen uses Python, not Bash. So it is not an integer math problem. But it calls r.mapcalc, e.g. in lines 151-153. If k is integer and not float, r.mapcalc will do integer division. Equivalent for lines 159, 162, 165. This could be fixed by casting the numerator to double with double(). Markus M However, you might try changing your input maps to float or DCELL. See if that changes things. Michael __ C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671(SHESC), 480-727-0709 (CSDC) www: http://csdc.asu.edu, http://shesc.asu.edu http://www.public.asu.edu/~cmbarton On Jan 31, 2013, at 2:11 AM, grass-user-requ...@lists.osgeo.org wrote: From: Yann Chemin yann.che...@gmail.com Subject: Re: [GRASS-user] unexpected i.pansharpen results Date: January 31, 2013 2:11:33 AM MST To: Hamish hamis...@yahoo.com Cc: GRASS user list grass-user@lists.osgeo.org hmmm, yes that looks like an old friend to check... On 31 January 2013 14:06, Hamish hamis...@yahoo.com wrote: (sorry for the html,top posting) I wonder if the script is doing integer division when it should be doing floating point division? http://trac.osgeo.org/grass/browser/grass/trunk/scripts/i.pansharpen/i.pansharpen.py Hamish --- On Wed, 1/30/13, Eric Goddard egoddard1...@gmail.com wrote: From: Eric Goddard egoddard1...@gmail.com Subject: [GRASS-user] unexpected i.pansharpen results To: grass-user@lists.osgeo.org Date: Wednesday, January 30, 2013, 8:30 AM Hi all, I'm attempting to pansharpen some ikonos imagery using the i.pansharpen tool in Grass7 on windows 7 installed via OSGeo4W (r54756-478). The range for the sharpened red, green, and blue outputs are 0-30, which seems suspicious given the 16bit range of the input bands. The command I used was: i.pansharpen.py sharpen=ihs ms3=ik_mss.4@eric ms2=ik_mss.3@eric ms1=ik_mss.2@eric pan=ik_pan@eric output_prefix=ik_ihs The input bands are linked via r.external, would that matter? The output from my test area is below. Any assistance would be greatly appreciated.image.png Thanks, Eric -Inline Attachment Follows- ___ 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] v.out.ascii with vector created by v.net.allpairs
On Thu, Jan 31, 2013 at 11:38 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Thu, Jan 31, 2013 at 11:00 AM, Johannes Radinger johannesradin...@gmail.com wrote: You could 1) create new categories in a new layer with v.category 2) add columns from_cat, to_cat to the new layer 3) upload values by assigning from_cat (new layer) = cat (old layer) and to_cat (new layer) = to_cat (old layer) That sounds like a good idea, but somehow I fail. What I did was: 1) create a new attribute table/layer for the vector point map with v.db.addtable map=orig table=new_table layer=2 2) The second layer does have a cat column but without any entries yet. So far so good So I tried as you said to create new unique categories in this new layer with v.category input=orig output=new layer=2 But here I get following error: Copying attribute table(s)... DBMI-SQLite driver error: Error in sqlite3_step(): indexed columns are not unique WARNING: Unable to create index for table new_1, key cat Try to start everything again anew with dbf as default database connection. This should avoid the index problem because dbf does not support indexing. This advice was nonsense, sorry! The attribute table created by v.net.allpairs in GRASS 6 can not be used as an attribute table. The only two things you can do is dump the table with db.select and v.db.connect -d in order to disconnect the table from the vector. Markus M v.category copies the map to a new one and tries to connect both attribute tablesbut there are no unique cat values in table/layer 1 Is it possible to update layer to without copying the whole map with both layers (v.category) to get new cats in layer 2... But you need the attribute table for layer 1 in order to create the desired attribute table for layer 2? HTH Markus M Anyway it seems the easiest way is to just fetch the entries with db.select as Markus said before. ...or to use GRASS7 :) /johannes ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.out.ascii with vector created by v.net.allpairs
On Wed, Jan 30, 2013 at 3:28 PM, Johannes Radinger johannesradin...@gmail.com wrote: Hi, I performed an analysis to get the distances between single points within a network using v.net.allpairs. As a result a point vector is created containing following information in the attribute table: for example cat,to_cat,cost 1,1,0 1,2,12 1,3,10 2,1,12 2,2,0 2,3,17 so there are actually several lines associated with the same cat value This has been changed in GRASS 7. Here, the attribute table has the entries cat, from_cat, to_cat, cost, cat is unique and the category of a shortest path. However, when I try to export the table into a text file using v.out.ascii only one line per cat is exported... How can I export the whole table as shown in attribute table of the vector? You could try db.select and feed the output to another datatbase. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.out.ascii with vector created by v.net.allpairs
On Wed, Jan 30, 2013 at 5:16 PM, Johannes Radinger johannesradin...@gmail.com wrote: On Wed, Jan 30, 2013 at 4:51 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Jan 30, 2013 at 3:28 PM, Johannes Radinger johannesradin...@gmail.com wrote: Hi, I performed an analysis to get the distances between single points within a network using v.net.allpairs. As a result a point vector is created containing following information in the attribute table: for example cat,to_cat,cost 1,1,0 1,2,12 1,3,10 2,1,12 2,2,0 2,3,17 so there are actually several lines associated with the same cat value This has been changed in GRASS 7. Here, the attribute table has the entries cat, from_cat, to_cat, cost, cat is unique and the category of a shortest path. However, when I try to export the table into a text file using v.out.ascii only one line per cat is exported... How can I export the whole table as shown in attribute table of the vector? You could try db.select and feed the output to another datatbase. I though about creating manually a new from_cat column using v.db.update to get the values from cat to from_cat and then assigning new unique cat values to the cat column (with v.db.*??) You could 1) create new categories in a new layer with v.category 2) add columns from_cat, to_cat to the new layer 3) upload values by assigning from_cat (new layer) = cat (old layer) and to_cat (new layer) = to_cat (old layer) Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Raster processing
On Mon, Jan 28, 2013 at 7:33 PM, Surendran Neelakantan surendra...@gmail.com wrote: Hi I am a new user of GRASS I have been working on a python Geo-processing tool in ESRI ARCGIS desktop. This is basically a DEM data processing which involves Extract by Mask Flow Direction, Flow Accumulation,Slope ,Watershed ,Zonal statistics I would like to rewrite the tool to make it work with GRASS so that later everyone can use this. I have gone through the documentation but I really not able to figure out the equivalent commands in Grass. First of all, set the region to the DEM with g.region -p rast=DEM Create a MASK with r.mask or r.mapcalc or r.to.vect Zoom to the masked area g.region -p zoom=DEM Note that there is no need to clip or extract a subregion of the DEM if the region is set properly Flow direction, flow accumulation, watershed can be calculated with r.watershed Slope can be calculated with r.slope.aspect Zonal statistics can be calculated with r.univar or r.statistics or r.statistics2 or r.statistics3, depending on the desired output. HTH, Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error: accumulation map does not match with elevation map! (r.basin)
On Fri, Jan 25, 2013 at 11:53 AM, Giuliano Urgeghe giulian...@gmail.com wrote: Thank you Markus, would you suggest following Ubuntu's compilation instructions with OS Mint 14 or OS KUbuntu? Since Mint is based on Ubuntu, the compile instructions for Ubuntu [0] should work. Please let us know if they work or need modification. [0] http://grasswiki.osgeo.org/wiki/Compile_and_Install#Ubuntu -- View this message in context: http://osgeo-org.1560.n6.nabble.com/error-accumulation-map-does-not-match-with-elevation-map-tp5029128p5029834.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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error: accumulation map does not match with elevation map! (r.basin)
On Fri, Jan 25, 2013 at 12:08 AM, Giuliano Urgeghe giulian...@gmail.com wrote: Sorry Marcus I found http://trac.osgeo.org/grass/changeset/54765 the bug fixed. How do I upgrade my installation of grass? You can either compile GRASS from source using latest svn [0] or you can modify the r.basin.py script by removing r.watershed and adding drainage direction output to r.stream.extract. The flow accumulation raster is cropped later on in the script but otherwise not used, so you can remove flow accumulation completely from the script. Markus M [0] http://grasswiki.osgeo.org/wiki/Compile_and_Install -- View this message in context: http://osgeo-org.1560.n6.nabble.com/error-accumulation-map-does-not-match-with-elevation-map-tp5029128p5029694.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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error: accumulation map does not match with elevation map! (r.basin)
On Thu, Jan 24, 2013 at 12:43 AM, Giuliano Urgeghe giulian...@gmail.com wrote: I took your advice replacing lines 135-136 and 137 of the file, r.basin.py, in the directory home/grass-addons/grass6/raster/r.basin by editor Kate but I have not found any solution to the problem also because I used a threshold value different from the default I found a bug in r.watershed SFD mode, fixed for 6.4 and 6.5 in r54765-6 (7.0 was not affected). For r.basin, r.watershed could also be run in MFD mode, the results might be a bit more accurate for high-resolution DEMs. Markus M thank for your help -- View this message in context: http://osgeo-org.1560.n6.nabble.com/error-accumulation-map-does-not-match-with-elevation-map-tp5029128p5029421.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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] error: accumulation map does not match with elevation map! (r.basin)
On Wed, Jan 23, 2013 at 1:21 PM, Helmut Kudrnovsky hel...@web.de wrote:
but when I launch r.basin in a closing section of the basin, I get the
error: map of accumulations
does not match the map of elevations.
r.basin is based upon r.stream.extract and other useful modules.
The bug is in r.basin which modifies the current region after
r.watershed is called and before r.stream.extract is called, if the
default threshold should be used. In this case, the region is set to
match the input elevation map in order to get the resolution (nsres
only by the way). The fix would be to replace in r.basin.py line 135 -
137
info_region = grass.read_command('g.region', flags = 'p', rast
= '%s' % (r_elevation))
dict_region = grass.parse_key_val(info_region, ':')
resolution = float(dict_region['nsres'])
with
resolution = grass.region()['nsres']
HTH,
Markus M
from the r.stream.extract-manual [1]:
[...]
If accumulation is given, elevation must be exactly the same map used to
calculate accumulation.
[...]
[1]
http://trac.osgeo.org/grass/browser/grass-addons/grass6/raster/r.stream.extract/description.html
HTH
-
best regards
Helmut
--
View this message in context:
http://osgeo-org.1560.n6.nabble.com/error-accumulation-map-does-not-match-with-elevation-map-tp5029128p5029261.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
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Loss of data using v.net
On Wed, Jan 23, 2013 at 8:22 PM, דור פרידמן dof1...@gmail.com wrote: I'm trying to build a network in GRASS in order to find the shortest path from any settlement out of 1120 (points), to one waste treatment facility out of 27 (points). I plan to use v.net.distance which is designated to this purpose, and to define source and destination points using a column called type. In that column I have assigned the settlements layer with the number 5 and the treatment facilities with 1. My problem occurs when I try to create the network using v.net; If I define nodes layer (nlayer=2) to be 2, I lose all the points and can't find it, even by using v.extract. What is the output of v.category op=report using the output of v.net? Markus M Otherwise (when nlayer=1) the attributes describing type are being auromatically changed to 4, which is the type attribute for roads. Since I have 1120 I find that using from_cat instead of a SQL restriction will be too hard. Any one has an idea why I'm losing this crucial data and how can I prevent it from happening? Thanks in advanced, Dor ___ 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] looking for a solution to a v.net error
On Sun, Jan 20, 2013 at 1:33 PM, דור פרידמן dof1...@gmail.com wrote: Hi all, I was using v.net (operation=connect) to create a network for a v.net.distance analysis. I'm using GRASS 6.4.2 using QGIS 1.8 plugin. My attempt to connect a polyline map with about 11000 categories to a points map with 25 has failed due to an error which described below. My code was: v.net input=network points=cdw1c output=network_v2 operation=connect threshold=4500 My threshold is the maximum distance between a point category to the polyline map and was calculated by v.distance. I've also tried a smaller float to test it, namely threshold=100 The error was: Windows alert claiming that v.net.exe has stopped working correctly... and the program was terminated. Additionally, I have received the following output in grass shell Assertion failed: !p-taken[i], file split_q.e, line 69 An image using Prt Scr is attached. Can someone help me to figure out what am I doing wrong? I think you did everything all right. The problem might rather be with one of the vectors, containing corrupted coordinates. If the lines and the points vector have been created with GRASS and never exported, it is a bug in GRASS. If the lines and the points vector have been imported into GRASS, there is a chance to figure out what went wrong: both vectors must be in the same projection. check the output of ogrinfo -so for both the lines and the points vector check the output of v.info for both the imported lines and the imported points vector The extents of the imported vectors should not be larger than the extents of the original vector. The extents of the imported vectors can be smaller if you made a spatial selection during import. In any case, run v.build on the two GRASS vectors and check for any warnings. If possible, try GRASS 7, because GRASS 7 is more robust with regard to vector processing. If all that does not help, could you make the vectors available for testing? Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.carve - strange problem on dem carved
On Sun, Jan 20, 2013 at 10:43 PM, Markus Neteler nete...@osgeo.org wrote: On Sat, Jan 19, 2013 at 12:54 PM, Ing. Pierluigi De Rosa pierluigi.der...@gfosservices.it wrote: Dear All i'm preparing a DEM hydrologically correct Just FYI, there is also: http://grasswiki.osgeo.org/wiki/AddOns/GRASS7/raster#r.hydrodem r.hydrodem does not carve predefined streams into a DEM, only r.carve does that. Alternatively, you can can calculate the lowest elevation value for each stream segment, carve that value into the DEM and then use r.watershed without any further modifications to the DEM. Markus M (perhaps someone here has an idea about the reported problem). Markus ___ 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] harmonic analysis of time series
There is a new add-on module for GRASS 7 to perform harmonic analysis of time series (HANTS), a kind of customized FFT, after Roerink et al (2000). The original purpose was to reconstruct NDVI time series, but it works with all kinds of time series that show periodicity. The module is called r.hants. Enjoy! Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.hazard.flood.py Grass 6.4.3RC1
On Wed, Jan 16, 2013 at 2:23 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Jan 16, 2013 at 9:40 AM, Margherita Di Leo direg...@gmail.com wrote: Hi Paul, Could you indicate the exact command line that you are executing? Also, on which OS? Thanks, Madi On Wed, Jan 16, 2013 at 9:18 AM, Paul Shapley p.shap...@gmail.com wrote: Hi All, I'm getting the following error trying to execute the r.hazard.flood python script. The module will load and accept the parameters but does not seem to execute. Any advice appreciated. Thanks, Paul Shapley - **kwargs) wx._core . PyAssertionError : C++ assertion m_pendingEvents failed at ..\..\src\common\event.cpp(1172) in wxEvtHandler::ProcessPendingEvents(): Please call wxApp::ProcessPendingEvents() instead Traceback (most recent call last): File C:\Program Files\GRASS GIS 6.4.3RC1\etc\wxpython\gui_core\goutput.py, line 980, in OnProcessPendingOutputWindowEvents self.ProcessPendingEvents() File C:\Program Files\GRASS GIS 6.4.3RC1\Python27\lib \site-packages\wx-2.8-msw-unicode\wx\_core.py, line 3871, in ProcessPendingEvents return _core_.EvtHandler_ProcessPendingEvents(*args, **kwargs) wx._core . PyAssertionError : C++ assertion m_pendingEvents failed at ..\..\src\common\event.cpp(1172) in wxEvtHandler::ProcessPendingEvents(): Please call wxApp::ProcessPendingEvents() instead This has been fixed in trunk 6 months ago. Backport? Backported in r54678-9. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Interpolation with v.surf.rst
On Wed, Jan 16, 2013 at 10:16 AM, Brian Sanjeewa Rupasinghe jink...@gmail.com wrote: Hi, I have 2D isolines in GRASS vector format with elevation in an attribute field called height. I used v.surf.rst function to create raster DEM. However, after creation, it outputs a DEM with value 0 elevation only. The description of the function is given as below. What would be the possible cause for this? I am using wingrass 7. cheers, Brian. v.surf.rst -z input=isoline@TOPOIKDATA zcolumn=height elev=elev_1m If you want to use elevation values from zcolumn, you should not use the -z flag. Try instead v.surf.rst input=isoline@TOPOIKDATA zcolumn=height elev=elev_1m Also make sure that the computational region extents and resolution are set correctly. HTH, Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Count number of roads at intersection
On Wed, Jan 16, 2013 at 2:04 AM, Phil Donovan philiprogerdono...@gmail.com wrote: Hey guys, I want to count the number of roads at an intersection node. Is there an easy way to do this with GRASS? Not really, even though the information is there, internally. You could try v.net op=nreport which prints for each network node the categories of all lines connected to that node. You would then need to count the number of line categories printed for each node. HTH, Markus M I could do it by buffering the points to find the number of roads within the buffer but was curios if there was a 'cleaner' way. Phil. ___ 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] Interpolation with v.surf.rst
On Wed, Jan 16, 2013 at 11:06 AM, Brian Sanjeewa Rupasinghe jink...@gmail.com wrote: Hi, When i omit -z flag, v.surf.rst function keeps on running and nothing happens. Here is what i used. v.surf.rst input=isoline@TOPOIKDATA zcolumn=height elev=elev_1m v.surf.rst can take quite some time with many vector points and a large region with high resolution. You could test with a smaller region to adjust parameters, then process the whole region. Markus M Brian On Wed, Jan 16, 2013 at 3:24 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Jan 16, 2013 at 10:16 AM, Brian Sanjeewa Rupasinghe jink...@gmail.com wrote: Hi, I have 2D isolines in GRASS vector format with elevation in an attribute field called height. I used v.surf.rst function to create raster DEM. However, after creation, it outputs a DEM with value 0 elevation only. The description of the function is given as below. What would be the possible cause for this? I am using wingrass 7. cheers, Brian. v.surf.rst -z input=isoline@TOPOIKDATA zcolumn=height elev=elev_1m If you want to use elevation values from zcolumn, you should not use the -z flag. Try instead v.surf.rst input=isoline@TOPOIKDATA zcolumn=height elev=elev_1m Also make sure that the computational region extents and resolution are set correctly. HTH, Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.hazard.flood.py Grass 6.4.3RC1
On Wed, Jan 16, 2013 at 9:40 AM, Margherita Di Leo direg...@gmail.com wrote: Hi Paul, Could you indicate the exact command line that you are executing? Also, on which OS? Thanks, Madi On Wed, Jan 16, 2013 at 9:18 AM, Paul Shapley p.shap...@gmail.com wrote: Hi All, I'm getting the following error trying to execute the r.hazard.flood python script. The module will load and accept the parameters but does not seem to execute. Any advice appreciated. Thanks, Paul Shapley - **kwargs) wx._core . PyAssertionError : C++ assertion m_pendingEvents failed at ..\..\src\common\event.cpp(1172) in wxEvtHandler::ProcessPendingEvents(): Please call wxApp::ProcessPendingEvents() instead Traceback (most recent call last): File C:\Program Files\GRASS GIS 6.4.3RC1\etc\wxpython\gui_core\goutput.py, line 980, in OnProcessPendingOutputWindowEvents self.ProcessPendingEvents() File C:\Program Files\GRASS GIS 6.4.3RC1\Python27\lib \site-packages\wx-2.8-msw-unicode\wx\_core.py, line 3871, in ProcessPendingEvents return _core_.EvtHandler_ProcessPendingEvents(*args, **kwargs) wx._core . PyAssertionError : C++ assertion m_pendingEvents failed at ..\..\src\common\event.cpp(1172) in wxEvtHandler::ProcessPendingEvents(): Please call wxApp::ProcessPendingEvents() instead This has been fixed in trunk 6 months ago. Backport? Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Geometric correction with GRASS
On Tue, Jan 15, 2013 at 12:09 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: There is currently no orthorectification of satellite images in GRASS. It is on the ToDo list though: http://trac.osgeo.org/grass/wiki/Grass7/ImageryLib = Implement/finish linewise ortho-rectification of satellite data There is experimental code for orthorectification of (Landsat) satellite images in GRASS 5 which would need to be ported to GRASS 7, but that will take some time. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0
On Fri, Jan 11, 2013 at 9:53 AM, Rainer M Krug r.m.k...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/01/13 22:28, Markus Metz wrote: On Thu, Jan 10, 2013 at 8:33 PM, Patrice Dumas pertu...@free.fr wrote: On Thu, Jan 10, 2013 at 03:59:49PM -0200, Milton Cezar Ribeiro wrote: Thanks Rashad, I understand that grass 7 have a lot of new features (or improved/fixed ones), including the powerful contribution of python. But I would like to hear from grass7 users about how stable are this version. Anyone survive using only grass7 our we need to switch between them? I have seen quite a bit of bugs in grass 7, but the GRASS developpers are very quick to fix a correctly reported bug. Some of the bugs reported by you were really helpful to improve new functionality in GRASS 7. GRASS developers actually depend on this kind of feedback, and the more power-users use GRASS 7 and report any bugs, the better. In general, I estimate that GRASS 7 (on the command line) is as robust, but if in doubt faster and less resource intensive than GRASS 6. Some of the bugs reported by you apply to GRASS 6 only, are fixed in GRASS 7 and can not be backported to GRASS 6 because the required changes would break GRASS 6 compatibility. Other bugs that were present in GRASS 6 + 7 are only fixed in GRASS 7 and may or may not be backported to GRASS 6. Obviously I am advocating the use of GRASS 7, but for production work I would, like Paolo, recommend to have GRASS 6 on the side. Following the discussion, I would like to install GRASS 7 weekly snapshot. I relized the Binary link (http://grass.osgeo.org/download/software/) but it points back to the Linux Download page, but I could not find any binaries there for GRASS 7? Maybe this link should be removed? The binaries are here http://grass.osgeo.org/grass64/binary/linux/snapshot/ http://grass.osgeo.org/grass65/binary/linux/snapshot/ http://grass.osgeo.org/grass70/binary/linux/snapshot/ The corresponding links should be updated. Markus M Just wondering, but not a problem, as I am going to install from source anyway. Thanks, Rainer As a GRASS developer, I personally use only GRASS 7 for production work. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlDv0x0ACgkQoYgNqgF2egoqQwCfdumTTn6cTYJnqY7x3+FG3Nh5 WSsAmgK0Zla/k50jR7ACYigTA1fZhcv7 =GMNE -END PGP SIGNATURE- ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] to move or not move ? grass64 - ? - 7.0
On Thu, Jan 10, 2013 at 8:33 PM, Patrice Dumas pertu...@free.fr wrote: On Thu, Jan 10, 2013 at 03:59:49PM -0200, Milton Cezar Ribeiro wrote: Thanks Rashad, I understand that grass 7 have a lot of new features (or improved/fixed ones), including the powerful contribution of python. But I would like to hear from grass7 users about how stable are this version. Anyone survive using only grass7 our we need to switch between them? I have seen quite a bit of bugs in grass 7, but the GRASS developpers are very quick to fix a correctly reported bug. Some of the bugs reported by you were really helpful to improve new functionality in GRASS 7. GRASS developers actually depend on this kind of feedback, and the more power-users use GRASS 7 and report any bugs, the better. In general, I estimate that GRASS 7 (on the command line) is as robust, but if in doubt faster and less resource intensive than GRASS 6. Some of the bugs reported by you apply to GRASS 6 only, are fixed in GRASS 7 and can not be backported to GRASS 6 because the required changes would break GRASS 6 compatibility. Other bugs that were present in GRASS 6 + 7 are only fixed in GRASS 7 and may or may not be backported to GRASS 6. Obviously I am advocating the use of GRASS 7, but for production work I would, like Paolo, recommend to have GRASS 6 on the side. As a GRASS developer, I personally use only GRASS 7 for production work. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] movement direction surface in r.drain
On Tue, Jan 8, 2013 at 3:04 PM, Margherita Di Leo direg...@gmail.com wrote: Markus, Thank you for replying and sorry for delay, On Fri, Dec 28, 2012 at 4:37 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Wed, Dec 19, 2012 at 3:25 PM, Margherita Di Leo direg...@gmail.com wrote: Hi All, I have a friction map, a start polygon and an end polygon and would like to find the least cost path, meaning not a corridor but a thin line. To now I've tried both r.cost and r.walk and r.drain eventually, but the result of this latter r.drain input=friction@PERMANENT output=rdrain_out vector_points=start_line@PERMANENT is a path calculated *within* the start polygon (a closed line). I suppose this is because I don't provide a direction map to r.drain (I'm using GRASS 7). I read: If the input surface (a raster map layer) is a cumulative cost map generated by the r.walk or r.cost modules, the -d flag and a movement direction surface indir must be specified. I assume it's a kind of flow direction or aspect, but what is the physical meaning, and how can I calculate it? Could anyone please provide some further info. The physical meaning is movement direction in degrees CCW from East, similar to e.g. flow direction output of r.watershed. The direction map is an optional output of r.cost and r.walk, and should be used with the indir option for r.drain. The workflow would thus be: 1) convert the first polygon to a raster map 2) use all cells of the first polygon as start points for r.walk, include the friction map 3) convert the second polygon to a raster map quite plain up to this point, but: 4) use the second polygon as a MASK and get the coordinates of the cell with the lowest cost The cost map obtained by r.walk happens to be all 0 within the ending polygon. How should I choose my coordinates in this case? Check if the friction map is not all zero or NULL for the second polygon, that the DEM covers the second polygon, that the second polygon was not used in any way as input for r.walk, that the second polygon is actually reachable from the first polygon in the output of r.walk, and that the current region covers the second polygon. Also have a look at the direction output of r.walk. HTH, Markus M Thanks in advance. Best, madi -- Margherita DI LEO Postdoctoral Researcher European Commission - DG JRC Institute for Environment and Sustainability (IES). Unit H03 – FRC Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] movement direction surface in r.drain
On Tue, Jan 8, 2013 at 3:41 PM, Margherita Di Leo direg...@gmail.com wrote: Thanks for super quick answer, On Tue, Jan 8, 2013 at 3:25 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: Check if the friction map is not all zero or NULL for the second polygon, the friction map within the ending polygon has everywhere value 1. And what are the values of the friction map outside the ending polygon? Should also be 1 I guess. that the second polygon is actually reachable from the first polygon in the output of r.walk, Not sure how to verify that, but i digitized a random point within the ending polygon (i placed it somewhere in the center) and i used it as starting point for r.drain, and obtained a nice least cost path line. Interesting. Are the costs anywhere larger than zero? Also have a look at the direction output of r.walk. Looks OK (it has values) but i'm still not sure what should i check in it. That the directions make sense. In GRASS 7 as of r54582 they are degrees CCW from East, zero is undefined, 360 is due East. A little example in the NC dataset: # walking from Macon county to Dare county g.region -p rast=elev_state_500m@PERMANENT v.to.rast in=boundary_county@PERMANENT use=val val=1 where=NAME = 'DARE' out=dare v.to.rast in=boundary_county@PERMANENT use=val val=1 where=NAME = 'MACON' out=macon r.mapcalc friction = 0.0001 # use Knight's move r.walk elevation=elev_state_500m@PERMANENT friction=friction output=dare_cost outdir=dare_dir start_rast=dare -k r.mask raster=macon r.out.xyz in=dare_cost out=- | sort -t | -k 3 | head -n3 # gives # 234250|147750|490937.498669579 # 234250|147250|491132.5043559544 # 234250|146750|491258.3433474401 # Coordinates with lowest cost in Macon county are 234250,147750, and the lowest cost is zero. r.mask -r # use directions input because the input is a cost surface # and vector output because of Knight's move in r.walk r.drain -d input=dare_cost indir=dare_dir output=macon2dare vector_output=macon2dare start_coordinates=234250,147750 Markus M Thanks, madi HTH, Markus M Thanks in advance. Best, madi -- Margherita DI LEO Postdoctoral Researcher European Commission - DG JRC Institute for Environment and Sustainability (IES). Unit H03 – FRC Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. -- Margherita DI LEO Postdoctoral Researcher European Commission - DG JRC Institute for Environment and Sustainability (IES). Unit H03 – FRC Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.drain problem when flow reach the border
On Sun, Dec 30, 2012 at 11:44 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Markus I am using this commands. r.cost -k input=friction_landuse_roads output=cost_map start_points=map_source_pt stop_points=map_target_pt --o r.drain input=cost_map output=drain_map vector_points=map_target_pt --o r.drain in GRASS 6.4 does not work with cost surfaces generated with the Knight's Move (r.cost -k). Actually, r.drain does not work at all with cost surfaces in GRASS 6.4. You need the direction map together with the cost surface, and this is only available in 6.5 and 7. I have not a direction map, and as for other source-target-friction maps everything works fine without direction map I thougth that this should work for all. I doubt that it works fine if you do not use the direction map generated by r.cost, because r.drain modifies the input surface if no direction map is given, but for a cumulative cost surface these modifications introduce errors. If you have the chance, please run the command and take a look that the drain line finish on right border. I see. The output is correct with regard to the input cost surface only if a direction map is used as indir input for r.drain. I am going to backport r.cost/r.walk/r.drain from 6.5 to 6.4. Happy new year, Markus M best wishes miltinho 2012/12/30, Markus Metz markus.metz.gisw...@gmail.com: On Sun, Dec 30, 2012 at 8:59 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Rashad I tested with the trunk svn, but apparently it still not worked to me. Are you able to test with my datased? https://www.yousendit.com/download/UW16RE9zTkxlM1JBSXNUQw What are the commands you used? I found r.drain input=custo_aux_cost output=custo_aux_cost_drain vector_points=map_target_pt You need to also provide a direction map with the indir option of r.drain. Markus M Thanks! miltinho 2012/12/27, Mohammed Rashad mohammedrasha...@gmail.com: Hi Milton, I think this fix will solve the problem[0]. For elevation data there might be cases where no path exists ie, only single pixel is the selected path. I had tested it by myself and it worked. Please apply the patch and let me know. If any problem comes in compilation or doing r.drain let me know. It will be great if you can share the test data you are using in case not working after applying the patch [0] http://trac.osgeo.org/grass/attachment/ticket/1840/r.drain.diff [1] http://trac.osgeo.org/grass/attachment/ticket/1840/drain.c On Thu, Dec 27, 2012 at 2:31 AM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Mohamed and Markus Mohamed, thanks for your reply, I will wait for a solution within GRASS :-) Markus, thanks for your reply,. Sorry but I disagree a tiny bit, because is expected that between a source and target I will find a solution with the Least Cost path. Do you think that is there any situation where a least cost between source and target will not be found? Maybe if other software provide the soluction, although is not the bestest option, I prefere receive one complete output than a broken one. Happy new year! miltinho 2012/12/23, Markus Metz markus.metz.gisw...@gmail.com: On Sun, Dec 23, 2012 at 7:07 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Dear all, I am running a least cost path analysis combining r.cost and r.drain. But on some cases, when the least cost path between source and target reach the border of my map, r.drain stop on that position, and target point isn´t reached. This is correct because at the borders, the direction can not be determined, the path could lead out of the current region, you can not tell. Running on other softwares the algorithms the source and target is connected using edges without problem. If in doubt, I would call it a bug in that other software. Any hint are welcome. Try to expand the current region Markus M -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Regards, Rashad -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone
Re: [GRASS-user] r.drain problem when flow reach the border
Markus Metz wrote: I am going to backport r.cost/r.walk/r.drain from 6.5 to 6.4. Done in r54470-1. Happy new year, Markus M best wishes miltinho 2012/12/30, Markus Metz markus.metz.gisw...@gmail.com: On Sun, Dec 30, 2012 at 8:59 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Rashad I tested with the trunk svn, but apparently it still not worked to me. Are you able to test with my datased? https://www.yousendit.com/download/UW16RE9zTkxlM1JBSXNUQw What are the commands you used? I found r.drain input=custo_aux_cost output=custo_aux_cost_drain vector_points=map_target_pt You need to also provide a direction map with the indir option of r.drain. Markus M Thanks! miltinho 2012/12/27, Mohammed Rashad mohammedrasha...@gmail.com: Hi Milton, I think this fix will solve the problem[0]. For elevation data there might be cases where no path exists ie, only single pixel is the selected path. I had tested it by myself and it worked. Please apply the patch and let me know. If any problem comes in compilation or doing r.drain let me know. It will be great if you can share the test data you are using in case not working after applying the patch [0] http://trac.osgeo.org/grass/attachment/ticket/1840/r.drain.diff [1] http://trac.osgeo.org/grass/attachment/ticket/1840/drain.c On Thu, Dec 27, 2012 at 2:31 AM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Mohamed and Markus Mohamed, thanks for your reply, I will wait for a solution within GRASS :-) Markus, thanks for your reply,. Sorry but I disagree a tiny bit, because is expected that between a source and target I will find a solution with the Least Cost path. Do you think that is there any situation where a least cost between source and target will not be found? Maybe if other software provide the soluction, although is not the bestest option, I prefere receive one complete output than a broken one. Happy new year! miltinho 2012/12/23, Markus Metz markus.metz.gisw...@gmail.com: On Sun, Dec 23, 2012 at 7:07 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Dear all, I am running a least cost path analysis combining r.cost and r.drain. But on some cases, when the least cost path between source and target reach the border of my map, r.drain stop on that position, and target point isn´t reached. This is correct because at the borders, the direction can not be determined, the path could lead out of the current region, you can not tell. Running on other softwares the algorithms the source and target is connected using edges without problem. If in doubt, I would call it a bug in that other software. Any hint are welcome. Try to expand the current region Markus M -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Regards, Rashad -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass
Re: [GRASS-user] r.drain problem when flow reach the border
On Mon, Dec 31, 2012 at 3:52 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi all, thanks again for the help with this. I tried several versions of 6.4X (6.42 weekly snapshot, 6.43.. ) and 6.5 but in none of them, when I try to see the parameters for create output direction on r.cost man page I can't see how can I generate direction for input on r.drain. For r.cost and r.walk, the option to write directions to a raster map is outdir, see http://grass.osgeo.org/grass65/manuals/r.cost.html http://grass.osgeo.org/grass65/manuals/r.walk.html For r.drain, the option to use directions as input is indir, see http://grass.osgeo.org/grass65/manuals/r.drain.html Including the suggestion of M.Neterler svn checkout https://svn.osgeo.org/grass/grass/branches/develbranch_6 grass6_devel Sorry to do this so trouble, but maybe I am not finding where can I get an updated version of r.cost, r.drain and r.walk. Within the root directory of the source tree svn up Markus M Happy 2013! miltinho 2012/12/31, Markus Neteler nete...@osgeo.org: On Mon, Dec 31, 2012 at 3:05 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Markus Thanks for all your help. Please, which svn command I need to run to get the daily trunk subversion? See here: http://trac.osgeo.org/grass/wiki/Release/6.4.3RC2-News -- SVN Checkout latest 6.4 release branch (including unreleased bugfixes): Best MarkusN -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.drain problem when flow reach the border
On Sun, Dec 30, 2012 at 8:59 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Rashad I tested with the trunk svn, but apparently it still not worked to me. Are you able to test with my datased? https://www.yousendit.com/download/UW16RE9zTkxlM1JBSXNUQw What are the commands you used? I found r.drain input=custo_aux_cost output=custo_aux_cost_drain vector_points=map_target_pt You need to also provide a direction map with the indir option of r.drain. Markus M Thanks! miltinho 2012/12/27, Mohammed Rashad mohammedrasha...@gmail.com: Hi Milton, I think this fix will solve the problem[0]. For elevation data there might be cases where no path exists ie, only single pixel is the selected path. I had tested it by myself and it worked. Please apply the patch and let me know. If any problem comes in compilation or doing r.drain let me know. It will be great if you can share the test data you are using in case not working after applying the patch [0] http://trac.osgeo.org/grass/attachment/ticket/1840/r.drain.diff [1] http://trac.osgeo.org/grass/attachment/ticket/1840/drain.c On Thu, Dec 27, 2012 at 2:31 AM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Mohamed and Markus Mohamed, thanks for your reply, I will wait for a solution within GRASS :-) Markus, thanks for your reply,. Sorry but I disagree a tiny bit, because is expected that between a source and target I will find a solution with the Least Cost path. Do you think that is there any situation where a least cost between source and target will not be found? Maybe if other software provide the soluction, although is not the bestest option, I prefere receive one complete output than a broken one. Happy new year! miltinho 2012/12/23, Markus Metz markus.metz.gisw...@gmail.com: On Sun, Dec 23, 2012 at 7:07 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Dear all, I am running a least cost path analysis combining r.cost and r.drain. But on some cases, when the least cost path between source and target reach the border of my map, r.drain stop on that position, and target point isn´t reached. This is correct because at the borders, the direction can not be determined, the path could lead out of the current region, you can not tell. Running on other softwares the algorithms the source and target is connected using edges without problem. If in doubt, I would call it a bug in that other software. Any hint are welcome. Try to expand the current region Markus M -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -- Regards, Rashad -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Setting default region - incorrect region set after inserting raster resolution
On Sat, Dec 29, 2012 at 6:26 AM, RichardC richtcoo...@hotmail.com wrote: Hi Markus, I entered the values for the default region through the location wizard selected at GRASS start up. The CRS was input via entering EPSG 4326. Then the spatial extent and raster resolution entered. I notice that I'm unable to enter region extents in DMS format, getting the error: 'Invalid value: invalid literal for float(): 0:' For latlon locations, g.region res=0:0:03 works with 6.4.3 and above. Markus M Entering 0.00083 gives the following result in DEFAULT_VIEW: proj: 3 zone: 0 north: 90N south: 90S *east: 179:59:57W west: 179:59:57E* cols: 432002 rows: 216000 e-w resol: 0:00:03 n-s resol: 0:00:03 top:1 bottom: 0 cols3: 360 rows3: 180 depths: 1 e-w resol3: 1:00:00.016667 n-s resol3: 1 t-b resol: 1 Cheers, Richard -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Setting-default-region-incorrect-region-set-after-inserting-raster-resolution-tp5024852p5024972.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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Postgres import on Windows = ERROR: Unable to open data source
On Sat, Dec 29, 2012 at 7:14 PM, Aren Cambre a...@arencambre.com wrote: When it try to run this in 6.4.3svn (last night's build) or 6.4.2: v.in.ogr -t -o dsn=C:\Users\Aren Cambre\Desktop\DEEM documents\TxDOT\grass connection.dsn output=crashes ...all I get this this: ERROR: Unable to open data source C:\Users\Aren Cambre\Desktop\DEEM documents\TxDOT\grass connection.dsn That error is vague. The DSN was generated by v.in.ogr.qgis in Quantum GIS, and it does work in QGIS's bundled GRASS 6.4.2. In the grass connection.dsn file is this: PG:dbname='de' host=localhost port=5432 user='development' password='' sslmode=disable (of course, X is replaced with the actual password) Does v.in.ogr -t -o dsn=PG:dbname='de' host=localhost port=5432 user='development' password='' sslmode=disable output=crashes work? I.e. not using the file grass connection.dsn but its contents. Markus M Through running process monitor, I see that GRASS has no problem accessing the DSN file. Also, through pgAdmin III's Server Status utility, I can verify that GRASS is not attempting to connect to the database. I'm at a loss on how to further diagnose this. Aren ___ 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] movement direction surface in r.drain
On Wed, Dec 19, 2012 at 3:25 PM, Margherita Di Leo direg...@gmail.com wrote: Hi All, I have a friction map, a start polygon and an end polygon and would like to find the least cost path, meaning not a corridor but a thin line. To now I've tried both r.cost and r.walk and r.drain eventually, but the result of this latter r.drain input=friction@PERMANENT output=rdrain_out vector_points=start_line@PERMANENT is a path calculated *within* the start polygon (a closed line). I suppose this is because I don't provide a direction map to r.drain (I'm using GRASS 7). I read: If the input surface (a raster map layer) is a cumulative cost map generated by the r.walk or r.cost modules, the -d flag and a movement direction surface indir must be specified. I assume it's a kind of flow direction or aspect, but what is the physical meaning, and how can I calculate it? Could anyone please provide some further info. The physical meaning is movement direction in degrees CCW from East, similar to e.g. flow direction output of r.watershed. The direction map is an optional output of r.cost and r.walk, and should be used with the indir option for r.drain. The workflow would thus be: 1) convert the first polygon to a raster map 2) use all cells of the first polygon as start points for r.walk, include the friction map 3) convert the second polygon to a raster map 4) use the second polygon as a MASK and get the coordinates of the cell with the lowest cost 5) use these coordinates as start coordinates for r.drain, together with the movement direction map and the cumulative cost map produced by r.drain The result should be a line connecting the two polygons HTH, Markus M Thank you in advance Madi -- Margherita DI LEO Postdoctoral Researcher European Commission - DG JRC Institute for Environment and Sustainability (IES). Unit H03 – FRC Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu Disclaimer: The views expressed are purely those of the writer and may not in any circumstance be regarded as stating an official position of the European Commission. ___ 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] Setting default region - incorrect region set after inserting raster resolution
On Fri, Dec 28, 2012 at 12:41 PM, RichardC richtcoo...@hotmail.com wrote: Hi, I create a new LOCATION and wish to set the default region for global coverage, i.e 90, -90, 180, -180 and, in the case of the current raster file, insert 0.000833 (degrees) as its resolution. What are the exact commands you used to modify the current region? Rather use res=0:0:03 instead of res=0.000833, in this case the DD:MM:SS format is more precise. Or use res=0.00083. HTH, Markus M The resulting DEFAULT_WIND file contains the following: proj: 3 zone: 0 north: 90N south: 90S *east: 179:59:58.3044W west: 179:59:58.3044E* cols: 432174 rows: 216086 e-w resol: 0:00:02.9988 n-s resol: 0:00:02.998806 top:1 bottom: 0 cols3: 360 rows3: 180 depths: 1 e-w resol3: 1:00:00.00942 n-s resol3: 1 t-b resol: 1 The outcome is that I need to click on the Map Display to display the file and the coordinates at left edge of the window are 45E not 180W? If a LOCATION is created with a raster resolution of '1' the default region appears correct (see DEFAULT_WIND below) and I then modify raster resolution with g.region under the PERMANENT MAPSET. proj: 3 zone: 0 north: 90N south: 90S *east: 180E west: 180W* cols: 360 rows: 180 e-w resol: 1 n-s resol: 1 top:1 bottom: 0 cols3: 360 rows3: 180 depths: 1 e-w resol3: 1 n-s resol3: 1 t-b resol: 1 Is there a way of entering the raster resolution of 0.000833 degrees when first creating the default region of a LOCATION? Cheers, Richard GRASS 6.4.2 Linux Mint 13 (ubuntu precise) -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Setting-default-region-incorrect-region-set-after-inserting-raster-resolution-tp5024852.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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.drain problem when flow reach the border
On Wed, Dec 26, 2012 at 10:01 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Mohamed and Markus Mohamed, thanks for your reply, I will wait for a solution within GRASS :-) Markus, thanks for your reply,. Sorry but I disagree a tiny bit, because is expected that between a source and target I will find a solution with the Least Cost path. Do you think that is there any situation where a least cost between source and target will not be found? Maybe if other software provide the soluction, although is not the bestest option, I prefere receive one complete output than a broken one. Ah, you are right, if the input is output from r.cost, the cost directions should be used. Depending on the input data and the region extents, the least cost path found may not be the real least cost path, but there should be one solution. There are situations where there is no connection between source and target if source and target are separated by NULL cells and no NULL cost is specified to r.cost. Markus M Happy new year! miltinho 2012/12/23, Markus Metz markus.metz.gisw...@gmail.com: On Sun, Dec 23, 2012 at 7:07 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Dear all, I am running a least cost path analysis combining r.cost and r.drain. But on some cases, when the least cost path between source and target reach the border of my map, r.drain stop on that position, and target point isn´t reached. This is correct because at the borders, the direction can not be determined, the path could lead out of the current region, you can not tell. Running on other softwares the algorithms the source and target is connected using edges without problem. If in doubt, I would call it a bug in that other software. Any hint are welcome. Try to expand the current region Markus M -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.drain problem when flow reach the border
On Wed, Dec 26, 2012 at 10:01 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Hi Mohamed and Markus Mohamed, thanks for your reply, I will wait for a solution within GRASS :-) Markus, thanks for your reply,. Sorry but I disagree a tiny bit, because is expected that between a source and target I will find a solution with the Least Cost path. Do you think that is there any situation where a least cost between source and target will not be found? Maybe if other software provide the soluction, although is not the bestest option, I prefere receive one complete output than a broken one. r.drain works for me as expected when the input comes from r.cost, i.e. movement directions are supplied. In this case the path does not stop at a border. If the input is a DEM and directions are not supplied, r.drain stops at borders, as it should do, because drainage the direction can not be determined. r.drain, as the name implies, traces a drainage path by following the steepest slope. It is not a least cost path search module, for that you need to use r.cost + r.drain. Markus M Happy new year! miltinho 2012/12/23, Markus Metz markus.metz.gisw...@gmail.com: On Sun, Dec 23, 2012 at 7:07 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Dear all, I am running a least cost path analysis combining r.cost and r.drain. But on some cases, when the least cost path between source and target reach the border of my map, r.drain stop on that position, and target point isn´t reached. This is correct because at the borders, the direction can not be determined, the path could lead out of the current region, you can not tell. Running on other softwares the algorithms the source and target is connected using edges without problem. If in doubt, I would call it a bug in that other software. Any hint are welcome. Try to expand the current region Markus M -- Miltinho - m...@rc.unesp.br Laboratório de Ecologia Espacial e Conservação - LEEC Depto de Ecologia - UNESP - Rio Claro Av. 24A, 1515- Bela Vista 13506-900 Rio Claro, SP, Brasil Fone: +55 19 3526-9647 (office) 19 3526-9680 (lab) Cel: 19 9853-3220 / 19 9853-5430 Depto Ecologia http://www.rc.unesp.br/ib/ecologia/ PG ECO BIODIV http://www.rc.unesp.br/ib/ecologia/posbiodiversidade/index.php CV http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4792988H6mostrarNroCitacoesISI=truemostrarNroCitacoesScopus=true Google citations http://scholar.google.com/citations?user=OWX_2eAJ ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.drain problem when flow reach the border
On Sun, Dec 23, 2012 at 7:07 PM, Milton Cezar Ribeiro miltinho.astrona...@gmail.com wrote: Dear all, I am running a least cost path analysis combining r.cost and r.drain. But on some cases, when the least cost path between source and target reach the border of my map, r.drain stop on that position, and target point isn´t reached. This is correct because at the borders, the direction can not be determined, the path could lead out of the current region, you can not tell. Running on other softwares the algorithms the source and target is connected using edges without problem. If in doubt, I would call it a bug in that other software. Any hint are welcome. Try to expand the current region Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Raster color tables missing entries
On Mon, Dec 17, 2012 at 10:45 PM, Markus Neteler nete...@osgeo.org wrote: On Tue, Jan 10, 2012 at 4:25 PM, Jitendra Kumar jitu1...@gmail.com wrote: I am using the random color table for these rasters. Will it be interpolating in that case too? Is there a way to ensure all colors gets written to the color table? I want to use the color table RGB values for each category, parse it in an external program to add color legends in an Latex document. Jitu Late reply :) I guess that you will need to use the C API to get out a complete color list: http://grass.osgeo.org/programming7/rasterlib.html#Raster_Color_Table You can also try r.colors.out. It should create a color table with a RGB value for each category. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Fwd: GRASS on SSHFS
On Tue, Dec 11, 2012 at 1:41 PM, Glynn Clements gl...@gclements.plus.com wrote: Daniel Lee wrote: [...] is there a specific reason that GRASS requires the user to own a mapset, rather than just have write permission? Historically, there are two reasons: 1. To prevent multiple GRASS sessions from using the same mapset directory. A lock file prevented a user from having more than one session, and the ownership check prevented anyone other than the directory's owner from using a directory as the current mapset. 2. Because otherwise people try to share mapsets by making them group-writable, then discover that they can't replace maps due to permission issues. Specifically, if you allow someone else to write to your mapset directory, and that user has a umask of 022 (or more), any directories which they create (e.g. cell_misc/mapname directories) will be mode 755 (drwxr-xr-x) or less, meaning that you can't remove any files from that directory, and thus won't be able to delete that directory. This will prevent you from removing or overwriting the map using GRASS commands. Point #1 is no longer relevant, but point #2 is, at least on multi-user systems. Point #1 still applies in some environments, e.g. centralized GRASS database, users can log in with the same user name and uid from different machines. We are using such an environment. On Windows, the checks are bypassed because Windows' stat() function doesn't report the owner and Windows doesn't have getuid(). There is a new function G_owner(), r49747, which reports the owner and works also on Windows. We could now activate lock files and ownership tests for Windows. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Fwd: GRASS on SSHFS
Glynn Clements wrote: Markus Metz wrote: There is a new function G_owner(), r49747, which reports the owner and works also on Windows. We could now activate lock files and ownership tests for Windows. On Unix, ownership checks should use the UID, not the username. G_owner is fixed accordingly in r54276. On Windows, the permission mechanism is sufficiently complicated that I'd be inclined to disable ownership checks by default. I agree. If there is a GRASS developer willing to tackle the intricacies of handling user IDs on Windows XP, Vista, 7, 8, Server 2003, Server 2008, Server 2012, we could give it a go. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] LS faktor in r.watershed
On Wed, Dec 12, 2012 at 10:16 AM, Stefan Luedtke slued...@gfz-potsdam.de wrote: Dear friends, I am working with the r.watershed module in order to compute the LS Faktor for (R)evised-Universal-Soil-Loss-Equation. For this option in the module, I have to set the threshold for the minimum size of exterior watersheds. There are many options out there to compute the LS-factor, but I could not find the paper/report/.. that describes the algorithm used in GRASS. Revised Universal Soil Loss Equation for Western Rangelands (Weltz et al. 1987). I want to understand why I need to set this threshold if I want r.watershed to compute the LS -factor. So if somebody could help me with: a) the reference, so I can check by my self. or b) a short explanation why this parameter must be set. The LS and S factor calculation is only done for cells that are not streams. I guess the reason is that soil loss does not apply to streams (rivers). Streams in turn are determined using the threshold option: all cells receiving more than threshold accumulated surface flow are regarded as streams. A reasonable threshold depends on 1) the resolution of the DEM, 2) the characteristics of the area under consideration, 3) the context of the analysis. By the way, I tested r.watershed with several thresholds (resulting in 1 big subbasin up to several hundreds) but the results for the Ls factor hardĺy changed. Because it should have changed only for cells that are streams / not streams depending on the threshold. HTH, Markus M Thanks in advance, Stefan ___ 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] Does v.kernel have to take 16+ hours?
Done in r54271. On Mon, Dec 10, 2012 at 6:00 PM, Michael Barton michael.bar...@asu.edu wrote: +1 for me too. Otherwise very confusing. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Arizona State University voice: 480-965-6262 (SHESC), 480-727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On Dec 10, 2012, at 1:19 AM, grass-user-requ...@lists.osgeo.org wrote: From: Moritz Lennert mlenn...@club.worldonline.be Subject: Re: [GRASS-user] Does v.kernel have to take 16+ hours? Date: December 10, 2012 1:03:46 AM MST To: Markus Metz markus.metz.gisw...@gmail.com Cc: grass-user@lists.osgeo.org On 07/12/12 17:16, Markus Metz wrote: On Thu, Dec 6, 2012 at 10:19 PM, Aren Cambrea...@arencambre.com wrote: OK, I think I get it now. After you've hit 4 SDs (or even arguably 3 SDs!) the contribution of more points to that square fades to almost nothing without extreme clusters of points. Right. Seems like this ought to be clarified in the UI and documentation? Should I file an enhancement request? I would rather have the option 'stddeviation' renamed to 'radius', kernel radius in map units, which it actually is currently for all kernels but gaussian, and internally adjust standard deviation instead of radius for the gaussian kernel. I guess that the kernel radius is of more importance to users than the standard deviation. Makes sense? +1 Moritz ___ 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] i.ortho.photo status
On Mon, Dec 10, 2012 at 4:44 PM, Eric Patton epat...@nrcan.gc.ca wrote: Hi, It's been about 6 years since I've had to do some air-photo rectification, but it looks like an opportunity to work with these data is opening up for me in the near future. Is i.ortho.photo and friends functional in Grass 6.5/7.0? The i.ortho.photo suite is functional, i.e. overhauled, in GRASS 6.4.svn and 6.5, but not yet in 7. Markus M -- Eric Patton ___ 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] g.copy several map layers into one layer without overwriting .....
On Wed, Dec 12, 2012 at 7:37 PM, Markus Neteler nete...@osgeo.org wrote: On Mon, Dec 10, 2012 at 1:17 PM, Glynn Clements gl...@gclements.plus.com There isn't currently an efficient way to join slices either using commands or the public C API. I wonder if the segment lib could be (ab)used for this? I guess that in this case it would be most probably slower than the r.patch or r.mapcalc approach. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Does v.kernel have to take 16+ hours?
On Thu, Dec 6, 2012 at 10:19 PM, Aren Cambre a...@arencambre.com wrote: OK, I think I get it now. After you've hit 4 SDs (or even arguably 3 SDs!) the contribution of more points to that square fades to almost nothing without extreme clusters of points. Right. Seems like this ought to be clarified in the UI and documentation? Should I file an enhancement request? I would rather have the option 'stddeviation' renamed to 'radius', kernel radius in map units, which it actually is currently for all kernels but gaussian, and internally adjust standard deviation instead of radius for the gaussian kernel. I guess that the kernel radius is of more importance to users than the standard deviation. Makes sense? Markus M BTW, I dropped down to a SD of 200, and it ran in 212 minutes. I'm trying a SD of 300 now but on a grid with 1/4 as many squares as I cut the rows and cols by half. We'll see how it does. Aren On Thu, Dec 6, 2012 at 12:17 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Thu, Dec 6, 2012 at 3:13 PM, Aren Cambre a...@arencambre.com wrote: Thanks. I am using EPSG:3081, and its unit is meters. So is it the case that a SD of x on EPSG:3081 means a search radius of 4x meters? If so, why 4x? Because the gaussian function is infinite, a cutoff of 3 to 6 SDs is usually applied when using a gaussian function as kernel density function. In theory, an alternative is to combine the infinite gaussian function with a finite function, e.g. uniform. I think historically v.kernel had only one kernel function, gaussian. The original authors decided to ask for SD and not for the search radius as input and have set the cutoff to 4 x SD where the gaussian function is reasonably close to zero. BTW, search radius = 4 x SD applies only to the gaussian kernel, for all other kernel functions the search radius is equal to SD. Markus M On Thu, Dec 6, 2012 at 2:29 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Thu, Dec 6, 2012 at 3:58 AM, Aren Cambre a...@arencambre.com wrote: It's gotten slow again. This run will probably take more than 10 hours. However, I am using a standard deviation of 1000. Is that what could be causing this? Yes. With a standard deviation of 1000, the search radius is now 4000, that is, for each cell a 8000x8000 box is searched. With many densely packed points, this can take quite some time. Markus M v.kernel input=tickets@PERMANENT output=tickets_new_heatmap_1000 stddeviation=1000 STDDEV: 1000.00 RES: 18.290457 ROWS: 2370 COLS: 2650 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. On Sat, Nov 24, 2012 at 9:03 PM, Aren Cambre a...@arencambre.com wrote: I installed r53983. The v.kernel execution that took almost a day now executes in 25.5 minutes. Thank you! Aren On Fri, Nov 23, 2012 at 12:51 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 5:35 PM, Aren Cambre a...@arencambre.com wrote: Thanks! I am not familiar with GRASS's release customs. Will this become part of a binary release soon, or should I just pull down the latest release in the 6.4.2 trunk? I'm assuming this has been merged into the trunk... It should be available as a binary for Windows by tomorrow in the nightly builds [0]. Markus M [0] http://wingrass.fsv.cvut.cz/grass64/ Aren On Fri, Nov 23, 2012 at 7:32 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre a...@arencambre.com wrote: Isn't taking about 10,000% too much time considered a bug? :-) Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and r53983, respectively. Markus M On Nov 23, 2012 5:11 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre a...@arencambre.com wrote: I'm able to reproduce reliably here. I'll email you details privately. Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with the settings provided by you. It does not crash, however. I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4 because by now only bugs should be fixed. Markus M Aren On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre a...@arencambre.com wrote: I have a dataset of just over 700,000 incidents that happened in square-ish Texas county that's about 30 miles on each side. Here's the parameters
Re: [GRASS-user] Does v.kernel have to take 16+ hours?
On Thu, Dec 6, 2012 at 3:58 AM, Aren Cambre a...@arencambre.com wrote: It's gotten slow again. This run will probably take more than 10 hours. However, I am using a standard deviation of 1000. Is that what could be causing this? Yes. With a standard deviation of 1000, the search radius is now 4000, that is, for each cell a 8000x8000 box is searched. With many densely packed points, this can take quite some time. Markus M v.kernel input=tickets@PERMANENT output=tickets_new_heatmap_1000 stddeviation=1000 STDDEV: 1000.00 RES: 18.290457 ROWS: 2370 COLS: 2650 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. On Sat, Nov 24, 2012 at 9:03 PM, Aren Cambre a...@arencambre.com wrote: I installed r53983. The v.kernel execution that took almost a day now executes in 25.5 minutes. Thank you! Aren On Fri, Nov 23, 2012 at 12:51 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 5:35 PM, Aren Cambre a...@arencambre.com wrote: Thanks! I am not familiar with GRASS's release customs. Will this become part of a binary release soon, or should I just pull down the latest release in the 6.4.2 trunk? I'm assuming this has been merged into the trunk... It should be available as a binary for Windows by tomorrow in the nightly builds [0]. Markus M [0] http://wingrass.fsv.cvut.cz/grass64/ Aren On Fri, Nov 23, 2012 at 7:32 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre a...@arencambre.com wrote: Isn't taking about 10,000% too much time considered a bug? :-) Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and r53983, respectively. Markus M On Nov 23, 2012 5:11 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre a...@arencambre.com wrote: I'm able to reproduce reliably here. I'll email you details privately. Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with the settings provided by you. It does not crash, however. I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4 because by now only bugs should be fixed. Markus M Aren On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre a...@arencambre.com wrote: I have a dataset of just over 700,000 incidents that happened in square-ish Texas county that's about 30 miles on each side. Here's the parameters reported by v.kernel as it's executing: STDDEV: 1000.00 RES: 111.419043 ROWS: 458 COLS: 447 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. I am running this on a Windows 7 x64 machine with 8 GB RAM and an Intel Core i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not multithreaded, only using 1 core. It takes about 16 hours to complete. Is this correct? I'd like to use this on a dataset with closer to 5 million records, and I'm really concerned how long it may take. The time required by v.kernel is a function of the number of cells and the input parameter stddeviation. The larger any of these values is, the more time v.kernel will need. Nevertheless, I think that the 16+ hours are not correct. I tested with a vector with 3 million points for a grid with 2700 rows and 1087 columns, magnitudes larger than the grid used by you. v.kernel completes in just over one minute. I posted my question about the 16+ hours at http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/. Bill Huber, who si apparently knowledgeable about kernel density calculations in general, posted a response, and he felt like a kernel density map shouldn't take much time at all. But digging more deeply, turns out he had come up with a kernel density calculation method over a decade ago using Fourier transforms. See http://www.directionsmag.com/features/convolution/129753 and the next two articles linked to it (they are short articles). Apparently this transforms it from an O(n^2) problem to an O(n ln n) complexity problem. The approach of Bill Huber is raster-based, not vector based, making some things easier, at the cost of precision. The coordinate precision, however, is only needed for kernel functions other than uniform. In GRASS, you could get something like a raster-based density map
Re: [GRASS-user] Does v.kernel have to take 16+ hours?
On Thu, Dec 6, 2012 at 3:13 PM, Aren Cambre a...@arencambre.com wrote: Thanks. I am using EPSG:3081, and its unit is meters. So is it the case that a SD of x on EPSG:3081 means a search radius of 4x meters? If so, why 4x? Because the gaussian function is infinite, a cutoff of 3 to 6 SDs is usually applied when using a gaussian function as kernel density function. In theory, an alternative is to combine the infinite gaussian function with a finite function, e.g. uniform. I think historically v.kernel had only one kernel function, gaussian. The original authors decided to ask for SD and not for the search radius as input and have set the cutoff to 4 x SD where the gaussian function is reasonably close to zero. BTW, search radius = 4 x SD applies only to the gaussian kernel, for all other kernel functions the search radius is equal to SD. Markus M On Thu, Dec 6, 2012 at 2:29 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Thu, Dec 6, 2012 at 3:58 AM, Aren Cambre a...@arencambre.com wrote: It's gotten slow again. This run will probably take more than 10 hours. However, I am using a standard deviation of 1000. Is that what could be causing this? Yes. With a standard deviation of 1000, the search radius is now 4000, that is, for each cell a 8000x8000 box is searched. With many densely packed points, this can take quite some time. Markus M v.kernel input=tickets@PERMANENT output=tickets_new_heatmap_1000 stddeviation=1000 STDDEV: 1000.00 RES: 18.290457 ROWS: 2370 COLS: 2650 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. On Sat, Nov 24, 2012 at 9:03 PM, Aren Cambre a...@arencambre.com wrote: I installed r53983. The v.kernel execution that took almost a day now executes in 25.5 minutes. Thank you! Aren On Fri, Nov 23, 2012 at 12:51 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 5:35 PM, Aren Cambre a...@arencambre.com wrote: Thanks! I am not familiar with GRASS's release customs. Will this become part of a binary release soon, or should I just pull down the latest release in the 6.4.2 trunk? I'm assuming this has been merged into the trunk... It should be available as a binary for Windows by tomorrow in the nightly builds [0]. Markus M [0] http://wingrass.fsv.cvut.cz/grass64/ Aren On Fri, Nov 23, 2012 at 7:32 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre a...@arencambre.com wrote: Isn't taking about 10,000% too much time considered a bug? :-) Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and r53983, respectively. Markus M On Nov 23, 2012 5:11 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre a...@arencambre.com wrote: I'm able to reproduce reliably here. I'll email you details privately. Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with the settings provided by you. It does not crash, however. I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4 because by now only bugs should be fixed. Markus M Aren On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre a...@arencambre.com wrote: I have a dataset of just over 700,000 incidents that happened in square-ish Texas county that's about 30 miles on each side. Here's the parameters reported by v.kernel as it's executing: STDDEV: 1000.00 RES: 111.419043 ROWS: 458 COLS: 447 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. I am running this on a Windows 7 x64 machine with 8 GB RAM and an Intel Core i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not multithreaded, only using 1 core. It takes about 16 hours to complete. Is this correct? I'd like to use this on a dataset with closer to 5 million records, and I'm really concerned how long it may take. The time required by v.kernel is a function of the number of cells and the input parameter stddeviation. The larger any of these values is, the more time v.kernel will need. Nevertheless, I think that the 16+ hours are not correct. I tested with a vector with 3 million points for a grid with 2700 rows and 1087 columns, magnitudes larger than the grid used by you. v.kernel
Re: [GRASS-user] Import of multi-part polygons using v.in.ogr?
On Sun, Dec 2, 2012 at 3:33 PM, Benjamin Ducke bendu...@fastmail.fm wrote: Hi List -- Looking at function centroid() in geom.c of v.in.ogr, it seems to me that the code for import of polygons always assumes that the first ring is the exterior boundary and the following ones are all interior boundaries (see comment on lines 70 and 71). Is this a limitation of GRASS' vector model or would it be possible to import multi-part polygons with more than one outer boundary by amending the code in v.in.ogr? Import of multi-features such as wkbGeometryCollection, wkbMultiPolygon, wkbMultiLineString, wkbMultiPoint is supported by v.in.ogr. For centroid(), see lines 160ff, for geom(), see lines 432ff. I understand that it is possible to import multi-part geometries into GRASS and assign each part the same cat number. However, when exporting with v.out.ogr, they will be exported as separate parts, each with its own attribute table row. Is there any way to preserve multi-part features using v.in.ogr and v.out.ogr? Multi-part features are preserved by v.in.ogr, all included features get the same category. For v.out.ogr, I think this is not so easy because not every OGR-supported output format supports multi-features (may be wrong). If this is currently not possible: Would it be a viable solution to add a -j (join) flag to v.out.ogr so that it will merge geometries with the same cat into multi- part features on export? I guess technically yes, if multi-features are supported by the selected output format. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] Does v.kernel have to take 16+ hours?
On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre a...@arencambre.com wrote: I'm able to reproduce reliably here. I'll email you details privately. Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with the settings provided by you. It does not crash, however. I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4 because by now only bugs should be fixed. Markus M Aren On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre a...@arencambre.com wrote: I have a dataset of just over 700,000 incidents that happened in square-ish Texas county that's about 30 miles on each side. Here's the parameters reported by v.kernel as it's executing: STDDEV: 1000.00 RES: 111.419043 ROWS: 458 COLS: 447 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. I am running this on a Windows 7 x64 machine with 8 GB RAM and an Intel Core i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not multithreaded, only using 1 core. It takes about 16 hours to complete. Is this correct? I'd like to use this on a dataset with closer to 5 million records, and I'm really concerned how long it may take. The time required by v.kernel is a function of the number of cells and the input parameter stddeviation. The larger any of these values is, the more time v.kernel will need. Nevertheless, I think that the 16+ hours are not correct. I tested with a vector with 3 million points for a grid with 2700 rows and 1087 columns, magnitudes larger than the grid used by you. v.kernel completes in just over one minute. I posted my question about the 16+ hours at http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/. Bill Huber, who si apparently knowledgeable about kernel density calculations in general, posted a response, and he felt like a kernel density map shouldn't take much time at all. But digging more deeply, turns out he had come up with a kernel density calculation method over a decade ago using Fourier transforms. See http://www.directionsmag.com/features/convolution/129753 and the next two articles linked to it (they are short articles). Apparently this transforms it from an O(n^2) problem to an O(n ln n) complexity problem. The approach of Bill Huber is raster-based, not vector based, making some things easier, at the cost of precision. The coordinate precision, however, is only needed for kernel functions other than uniform. In GRASS, you could get something like a raster-based density map by - exporting the points with v.out.ascii - re-importing the points with r.in.xyz method=n to get the number of points per cell - running a neighborhood analysis using a circular window with r.neighbors method=sum -c Optionally you could use the gauss option of r.neighbors to get an equivalent to v.kernel kernel=gaussian HTH, Markus M I inspected v.kernel's main.c (http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c), and looks like v.kernel uses an output-centric method (using Bill's wording) of calculating the output, which seems like O(n^2) complexity. So I guess what I'm getting at is it appears to me that the algorithm behind GRASS GIS's v.kernel is straightforward but is a greedy algorithm (http://en.wikipedia.org/wiki/Greedy_algorithm), which is fine, but it make take a while to execute. Is this true? Is there not spatial indexing I could add to the dataset? I've done various Google searches on that and can't come up with anything clear. Aren ___ 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] Does v.kernel have to take 16+ hours?
On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre a...@arencambre.com wrote: Isn't taking about 10,000% too much time considered a bug? :-) Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and r53983, respectively. Markus M On Nov 23, 2012 5:11 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre a...@arencambre.com wrote: I'm able to reproduce reliably here. I'll email you details privately. Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with the settings provided by you. It does not crash, however. I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4 because by now only bugs should be fixed. Markus M Aren On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre a...@arencambre.com wrote: I have a dataset of just over 700,000 incidents that happened in square-ish Texas county that's about 30 miles on each side. Here's the parameters reported by v.kernel as it's executing: STDDEV: 1000.00 RES: 111.419043 ROWS: 458 COLS: 447 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. I am running this on a Windows 7 x64 machine with 8 GB RAM and an Intel Core i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not multithreaded, only using 1 core. It takes about 16 hours to complete. Is this correct? I'd like to use this on a dataset with closer to 5 million records, and I'm really concerned how long it may take. The time required by v.kernel is a function of the number of cells and the input parameter stddeviation. The larger any of these values is, the more time v.kernel will need. Nevertheless, I think that the 16+ hours are not correct. I tested with a vector with 3 million points for a grid with 2700 rows and 1087 columns, magnitudes larger than the grid used by you. v.kernel completes in just over one minute. I posted my question about the 16+ hours at http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/. Bill Huber, who si apparently knowledgeable about kernel density calculations in general, posted a response, and he felt like a kernel density map shouldn't take much time at all. But digging more deeply, turns out he had come up with a kernel density calculation method over a decade ago using Fourier transforms. See http://www.directionsmag.com/features/convolution/129753 and the next two articles linked to it (they are short articles). Apparently this transforms it from an O(n^2) problem to an O(n ln n) complexity problem. The approach of Bill Huber is raster-based, not vector based, making some things easier, at the cost of precision. The coordinate precision, however, is only needed for kernel functions other than uniform. In GRASS, you could get something like a raster-based density map by - exporting the points with v.out.ascii - re-importing the points with r.in.xyz method=n to get the number of points per cell - running a neighborhood analysis using a circular window with r.neighbors method=sum -c Optionally you could use the gauss option of r.neighbors to get an equivalent to v.kernel kernel=gaussian HTH, Markus M I inspected v.kernel's main.c (http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c), and looks like v.kernel uses an output-centric method (using Bill's wording) of calculating the output, which seems like O(n^2) complexity. So I guess what I'm getting at is it appears to me that the algorithm behind GRASS GIS's v.kernel is straightforward but is a greedy algorithm (http://en.wikipedia.org/wiki/Greedy_algorithm), which is fine, but it make take a while to execute. Is this true? Is there not spatial indexing I could add to the dataset? I've done various Google searches on that and can't come up with anything clear. Aren ___ 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] Does v.kernel have to take 16+ hours?
On Fri, Nov 23, 2012 at 5:35 PM, Aren Cambre a...@arencambre.com wrote: Thanks! I am not familiar with GRASS's release customs. Will this become part of a binary release soon, or should I just pull down the latest release in the 6.4.2 trunk? I'm assuming this has been merged into the trunk... It should be available as a binary for Windows by tomorrow in the nightly builds [0]. Markus M [0] http://wingrass.fsv.cvut.cz/grass64/ Aren On Fri, Nov 23, 2012 at 7:32 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 2:07 PM, Aren Cambre a...@arencambre.com wrote: Isn't taking about 10,000% too much time considered a bug? :-) Hmm, yes. v.kernel is fixed in devbr6 and relbr6 with r53982 and r53983, respectively. Markus M On Nov 23, 2012 5:11 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Fri, Nov 23, 2012 at 4:14 AM, Aren Cambre a...@arencambre.com wrote: I'm able to reproduce reliably here. I'll email you details privately. Thanks. I can confirm that v.kernel takes a long time in GRASS 6 with the settings provided by you. It does not crash, however. I can speed up v.kernel in GRASS 6 to complete in 10 minutes instead of 16+ hours, but I am not sure if this fix can/will go into GRASS 6.4 because by now only bugs should be fixed. Markus M Aren On Thu, Nov 22, 2012 at 9:02 AM, Markus Metz markus.metz.gisw...@gmail.com wrote: On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre a...@arencambre.com wrote: I have a dataset of just over 700,000 incidents that happened in square-ish Texas county that's about 30 miles on each side. Here's the parameters reported by v.kernel as it's executing: STDDEV: 1000.00 RES: 111.419043 ROWS: 458 COLS: 447 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. I am running this on a Windows 7 x64 machine with 8 GB RAM and an Intel Core i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not multithreaded, only using 1 core. It takes about 16 hours to complete. Is this correct? I'd like to use this on a dataset with closer to 5 million records, and I'm really concerned how long it may take. The time required by v.kernel is a function of the number of cells and the input parameter stddeviation. The larger any of these values is, the more time v.kernel will need. Nevertheless, I think that the 16+ hours are not correct. I tested with a vector with 3 million points for a grid with 2700 rows and 1087 columns, magnitudes larger than the grid used by you. v.kernel completes in just over one minute. I posted my question about the 16+ hours at http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/. Bill Huber, who si apparently knowledgeable about kernel density calculations in general, posted a response, and he felt like a kernel density map shouldn't take much time at all. But digging more deeply, turns out he had come up with a kernel density calculation method over a decade ago using Fourier transforms. See http://www.directionsmag.com/features/convolution/129753 and the next two articles linked to it (they are short articles). Apparently this transforms it from an O(n^2) problem to an O(n ln n) complexity problem. The approach of Bill Huber is raster-based, not vector based, making some things easier, at the cost of precision. The coordinate precision, however, is only needed for kernel functions other than uniform. In GRASS, you could get something like a raster-based density map by - exporting the points with v.out.ascii - re-importing the points with r.in.xyz method=n to get the number of points per cell - running a neighborhood analysis using a circular window with r.neighbors method=sum -c Optionally you could use the gauss option of r.neighbors to get an equivalent to v.kernel kernel=gaussian HTH, Markus M I inspected v.kernel's main.c (http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c), and looks like v.kernel uses an output-centric method (using Bill's wording) of calculating the output, which seems like O(n^2) complexity. So I guess what I'm getting at is it appears to me that the algorithm behind GRASS GIS's v.kernel is straightforward but is a greedy algorithm (http://en.wikipedia.org/wiki/Greedy_algorithm), which is fine, but it make take a while to execute. Is this true? Is there not spatial indexing I could add to the dataset? I've done various Google searches on that and can't come up with anything clear. Aren
Re: [GRASS-user] Does v.kernel have to take 16+ hours?
On Sat, Nov 17, 2012 at 4:06 PM, Aren Cambre a...@arencambre.com wrote: I have a dataset of just over 700,000 incidents that happened in square-ish Texas county that's about 30 miles on each side. Here's the parameters reported by v.kernel as it's executing: STDDEV: 1000.00 RES: 111.419043 ROWS: 458 COLS: 447 Writing output raster map using smooth parameter=1000.00. Normalising factor=6482635.018778. I am running this on a Windows 7 x64 machine with 8 GB RAM and an Intel Core i7 Q720 1.6 GHz with 4 physical cores. I notice that it's not multithreaded, only using 1 core. It takes about 16 hours to complete. Is this correct? I'd like to use this on a dataset with closer to 5 million records, and I'm really concerned how long it may take. The time required by v.kernel is a function of the number of cells and the input parameter stddeviation. The larger any of these values is, the more time v.kernel will need. Nevertheless, I think that the 16+ hours are not correct. I tested with a vector with 3 million points for a grid with 2700 rows and 1087 columns, magnitudes larger than the grid used by you. v.kernel completes in just over one minute. I posted my question about the 16+ hours at http://gis.stackexchange.com/questions/41058/how-do-i-compute-v-kernel-maps-in-less-than-16-hours/. Bill Huber, who si apparently knowledgeable about kernel density calculations in general, posted a response, and he felt like a kernel density map shouldn't take much time at all. But digging more deeply, turns out he had come up with a kernel density calculation method over a decade ago using Fourier transforms. See http://www.directionsmag.com/features/convolution/129753 and the next two articles linked to it (they are short articles). Apparently this transforms it from an O(n^2) problem to an O(n ln n) complexity problem. The approach of Bill Huber is raster-based, not vector based, making some things easier, at the cost of precision. The coordinate precision, however, is only needed for kernel functions other than uniform. In GRASS, you could get something like a raster-based density map by - exporting the points with v.out.ascii - re-importing the points with r.in.xyz method=n to get the number of points per cell - running a neighborhood analysis using a circular window with r.neighbors method=sum -c Optionally you could use the gauss option of r.neighbors to get an equivalent to v.kernel kernel=gaussian HTH, Markus M I inspected v.kernel's main.c (http://trac.osgeo.org/grass/browser/grass/trunk/vector/v.kernel/main.c), and looks like v.kernel uses an output-centric method (using Bill's wording) of calculating the output, which seems like O(n^2) complexity. So I guess what I'm getting at is it appears to me that the algorithm behind GRASS GIS's v.kernel is straightforward but is a greedy algorithm (http://en.wikipedia.org/wiki/Greedy_algorithm), which is fine, but it make take a while to execute. Is this true? Is there not spatial indexing I could add to the dataset? I've done various Google searches on that and can't come up with anything clear. Aren ___ 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] log(0)-error in r.mapcalculator
On Fri, Nov 9, 2012 at 9:27 AM, Patrick S. patrick_...@gmx.ch wrote: Thank you so much, Markus! That was the missing hint and it works now! However, I just went through the documentation, which says: F means that the functions always results in a floating point value and Function log has F. The documentation is correct. The problem arose because ((A/100)/(1-(A/100)) returns an integer value if A is an integer, i.e. the truncation happened before log() is called. Markus M that On 11/08/2012 07:34 PM, Markus Metz wrote: On Thu, Nov 8, 2012 at 10:50 AM, Patrick S. patrick_...@gmx.ch wrote: Dear List, I keep getting a log(0) error in r.mapcalculator, even if I enlarge the data. This seems to be a bug as I controlled the same data with R and get (non-infinity) values. Does r.mapcalculator eventually truncate the results of formulas to some integer values? logit-expression: log(((A/100)/(1-(A/100))) In r.mapcalc, the numbers are treated as integers. Try instead log(((A / 100.0) / (1.0 - (A / 100.0))) Changing e.g. 1 to 1.0 forces r.mapcalc to do floating point calculations. HTH, Markus M To avoid error of log(0) I enlarged the data by 0.1, 1 and 5 but keep getting the error. I run it out of R with: param-list(amap=r_slope_perc, formula=log(((A+0.1)/100)/(1-(A/100))) , outfile=r_slope_perc_logit) execGRASS(r.mapcalculator, parameters=param, flags=c(overwrite)) (r.mapcalculator amap=r_slope_perc, formula=log(((A+0.1)/100)/(1-(A/100))) outfile=r_slope_perc_logit --overwrite) Any ideas why this happens? Patrick ___ 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] log(0)-error in r.mapcalculator
On Thu, Nov 8, 2012 at 10:50 AM, Patrick S. patrick_...@gmx.ch wrote: Dear List, I keep getting a log(0) error in r.mapcalculator, even if I enlarge the data. This seems to be a bug as I controlled the same data with R and get (non-infinity) values. Does r.mapcalculator eventually truncate the results of formulas to some integer values? logit-expression: log(((A/100)/(1-(A/100))) In r.mapcalc, the numbers are treated as integers. Try instead log(((A / 100.0) / (1.0 - (A / 100.0))) Changing e.g. 1 to 1.0 forces r.mapcalc to do floating point calculations. HTH, Markus M To avoid error of log(0) I enlarged the data by 0.1, 1 and 5 but keep getting the error. I run it out of R with: param-list(amap=r_slope_perc, formula=log(((A+0.1)/100)/(1-(A/100))) , outfile=r_slope_perc_logit) execGRASS(r.mapcalculator, parameters=param, flags=c(overwrite)) (r.mapcalculator amap=r_slope_perc, formula=log(((A+0.1)/100)/(1-(A/100))) outfile=r_slope_perc_logit --overwrite) Any ideas why this happens? Patrick ___ 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] Calculate p value for regression slope in r.series
On Thu, Nov 8, 2012 at 6:22 PM, Glynn Clements gl...@gclements.plus.com wrote: Paulo van Breugel wrote: Just wondering, if it is implemented in r.regression.series, would it be very difficult to port to r.series? Or do the two things function different internally? It could probably be added to r.series quite quickly if someone was willing to provide definitions for t-value and p-value. The t-value of a simple linear regression can be calculate with t = sqrt(Rsq) * sqrt((n - 2) / (1 - Rsq)); Rsq = R squared or coefficient of determination (r.series method=detcoeff) n = sample size This formula is used by r.regression.multi and in some modules in GRASS 5 that also do multiple regressions. The p-value would then be the cumulative probability of observing t according to Student's t-distribution for given n. I think somewhere in GRASS is a function to calculate p for n = inf (normal distribution). Maybe somewhere hidden there is also a function for small n? Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.watershed : minimum size of exterior watershed basin
On Thu, Oct 25, 2012 at 1:11 PM, laurent celati lcel...@latitude-geosystems.com wrote: Hello, Thanks for your reply. Yesterday i tested Grass via SextanteFORQgis. There was a bog during the process and i had a error message. This morning i have tested Grass via Qgis and it's works well. I have 2 questions : 1/With Grass r.watershed i have to enter this following parameter : minimum size of exterior watershed basin (without unit value). What criteria determines the value to be enter? How to know this value ? The unit is number of grid cells. A reasonable value depends on your question and the required detail. It helps often to first calculate flow accumulation, then visually inspect the result to figure out a reasonable value, or look where ground control points are located. In my case, i 'm using SRTM 90m as DEM raster input. 2/According to you, what is the better tool between r.watershed or Taudem StreamReach and watershed ? I could not find StreamReach and watershed in the TauDEM documentation on command line functions[0]. I did find something in the online documentation. It seems to me that the equivalent of Taudem's StreamReach and watershed is r.stream.extract followed by r.stream.order. I would expect the results to be nearly identical if the input data are the same. Note that TauDEM's StreamReach and watershed can not use the output of r.watershed as input, but r.stream.extract can use pretty much any input, also data generated with TauDEM. Markus M [0] http://hydrology.usu.edu/taudem/taudem5.0/TauDEM5CommandLineGuide.pdf Thank you in advance. -- View this message in context: http://osgeo-org.1560.n6.nabble.com/r-watershed-minimum-size-of-exterior-watershed-basin-tp5011178.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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] G_malloc error
On Mon, Oct 29, 2012 at 8:03 PM, Benjamin Ducke bendu...@fastmail.fm wrote: On 10/29/2012 06:27 PM, Glynn Clements wrote: [snip] Also, we don't currently provide 64-bit GRASS binaries for Windows, so you'd need to build it from source with a compiler that can produce 64-bit executables (and you'll need 64-bit versions of all of the relevant libraries). The last time I checked, MingGW-64 was still quite unstable, although I don't know if that has changed since. The build system doesn't support compiling with MSVC (and the free edition doesn't support building 64-bit binaries). True. And it's a beast to install and to get all the libs and header files into place. However, the situation is improving continuously. I have documented my efforts (trying to compile a GRASS 6.4.3 distro with minimal dependencies for use via SEXTANTE in gvSIG) here: http://gvsigce.sourceforge.net/wiki/index.php/Development_and_releases. It's incomplete (I have not been successful at compiling a complete 64 bit binary set on Windows so far), but maybe it will be of some use. This would not help for the reported problem: ERROR: G_malloc: unable to allocate 1279792008 bytes of memory at gsds.c:575 because the function where this error occurs, gsds_alloc_typbuff() in lib/ogsf/gsds.c can only allocate a maximum of 2 GB in GRASS 6. This has been fixed in GRASS 7, but only if GRASS 7 is compiled with 64-bit support. As a workaround, I would suggest to change the resolution of the current region before using any 3D functionality. I guess you tried nviz or wxnviz where an image size of 19998x15999 is most probably by far exceeding the size of the display. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] use of grass 6.4 and 7 on the same location/mapsets
On Mon, Oct 29, 2012 at 7:11 PM, Laura Poggio laura.pog...@gmail.com wrote: Thank you very much for the information. As I am not using vectors very often it should be rather safe. As Paulo wrote, v.build is all you need to convert between GRASS 6 and GRASS7 (any way). v.build does not modify the vector coordinates or geometry objects, therefore it is safe to use in both versions. Markus M Thanks Laura On 29 October 2012 11:34, Paulo van Breugel p.vanbreu...@gmail.com wrote: If you are in 6.4 and want to open a vector layer created in grass 7 (or the other way around), you can use v.build. Alternatively, you can also open the layer, and in the layer manager, right click the layer and select 'rebuild topology'. Rebuilding is very quick in my experience and hasn't give me any trouble, whether rebuilding from 6.4 to 7 or the other way around. Cheers, Paulo On Mon, Oct 29, 2012 at 12:24 PM, Nick Cahill ndcah...@wisc.edu wrote: I found that once I'd converted my vectors to Grass 7, I couldn't go back. I ended up going back to 6.4 and having to restore old vectors from a backup. It was a pain. Is there an easy way to convert back? Thanks, Nick Cahill On Oct 29, 2012, at 11:59 AM, Maris Nartiss wrote: If they are not accessed at a same time, then only problem will be with vector data. GRASS 7 uses a bit different vector data storage format and thus vector data can be used (displayed) only after a v.build run. It's a bit annoying and I don't know if it can introduce any problems (I mean when going G7-G6 vectors), still I haven't observed any. In conclusion - for raster - doesn't matter; vectors - better stick to one version. Maris. 2012/10/28 Laura Poggio laura.pog...@gmail.com: Dear list, are any problems in having mapsets accessed from different version of GRASS (6.4.2. and 7)? Thank you Laura ___ 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 ___ 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] Grass 7.0 - Topology error?
On Thu, Oct 18, 2012 at 4:49 AM, Richard Chirgwin rchirg...@ozemail.com.au wrote: Hi, I've taken the plunge and installed Grass-7.0 for a look. Attempting a v.distance, I'm getting a feature type error. Here is v.info on the to map: GRASS 7.0.svn (Australia):~ v.info MapB -t nodes=0 points=5113 lines=0 boundaries=0 centroids=0 areas=0 islands=0 primitives=5113 map3d=0 Here's what happens to v.distance: GRASS 7.0.svn (Australia):~ v.distance from=MapA from_type=centroid to=MapB to_type=point upload=dist column=Dist ERROR: No features of selected type found in MapB@Copy Oops, fixed in r53459. Markus M Since the maps were copied over from an 6.4 install, I have run v.build on all maps. Environment is Debian (a new install in a virtual machine). Cheers, Richard C ___ 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] v.distance anything to anything
On Tue, Oct 16, 2012 at 12:52 AM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 15/10/12 16:30, Markus Metz wrote: So how does it calculate the distance between two lines (lines or boundaries) ? Between closest vertices ? What about lines that cross several other lines, or lines that cross each other at several points ? For lines to lines, say line A to line B, it calculates shortest distance of each vertex in A with each segment (not vertex) in B. So far, this is the same like in the original version, results are identical. The original version did not have line to line... What I meant was that this is equivalent to the shortest distance of several points to a line, regarding points as line vertices. In GRASS 6, v.distance can calculate distances only from point,centroid to point,line,boundary,centroid,area. AFAIK, this was due to the conceptual issue mentioned above. I think that the answer has to be clearly explained in the manual because they are not as straightforward. And a first rapid test shows that these issues seem to be problematic in your implementation: http://164.15.12.207/grass/v_distance_lines.png http://164.15.12.207/grass/v_distance_areas.png red: from features (quickly digitized test data available here: http://164.15.12.207/grass/v_distance_testdata.tgz) black: to features (roadsmajor and urbanarea from nc_spm_08) green: connecting lines between from and to feature Thanks for testing! These issues should be fixed, at least conforming to my explanation above, in r53401. Much better, thanks ! Just one issue still with the area2area case for the test polygon with cat=2: http://164.15.12.207/grass/v_distance_areas2.png The connection line/point doesn't touch the the polygon in the from map. But it is inside the polygon of the 'from' map. In this implementation, any shared location is as good as any other. Calculating an intersection is costlier than to check if a vertex is inside a polygon. The vertex of the boundary of the 'to' area is inside the 'from' area, thus a common location. For speed reasons, the distance is set to zero and no further tests are done. The results can be unexpected for 'to' areas with isles, because v.distance (in all versions) does not require a 'to' feature to have a category, which also means that isles inside areas which themselves can be areas without centroids are regarded as valid 'to' features, just without category. But even though the results can be unexpected, I would leave them as such, otherwise 'to' feature would need to have a category, potentially leading to also different results for points to lines which has always been supported. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] bigTIFF file input
On Tue, Oct 16, 2012 at 5:20 PM, Paulo van Breugel p.vanbreu...@gmail.com wrote: Hi, Did you build gdal from source? When you compile gdal with internal libtiff or with libtiff = 4.0, GDAL should supports reading and writing BigTIFF files (evolution of the TIFF format to support files larger than 4 GB). You should also enable big file support when compiling grass I think, which you can set with ./configure --enable-largefile If you use the default gdal install, it might not support big files. This is for example the case in Ubuntu (I think, didn't check with 12.04 though). In that case you might want to compile gdal from source. GDAL uses by default its internal libtiff and supports BigTIFF, for a couple of years in its stable versions. If you installed gdal with the package manager of your Linux version, you would need to file a bug report for your Linux version or compile GDAL yourself from source with the default options for GTiff. If you compiled GDAL from source, you may need to update to the latest stable version and compile with the default options for GTiff. HTH, Markus Cheers, Paulo On Tue, Oct 16, 2012 at 4:37 PM, Albert Saribekyan albertsaribek...@rambler.ru wrote: Albert Saribekyan. Hi all, I tryed to import a geotiff file with size of 6 GB and there are a following error GRASS 7.0.svn (example):~ r.in.gdal input=/localuser/albert/test_1.tif output=test_1 location=test1 ERROR 4: This is a BigTIFF file. BigTIFF is not supported by this version of GDAL and libtiff. could you help me please.. regards. ___ 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] i.pca noise reduction
On Sat, Oct 13, 2012 at 6:18 PM, Markus Neteler nete...@osgeo.org wrote: On Sat, Oct 13, 2012 at 3:46 PM, Markus Metz markus.metz.gisw...@gmail.com wrote: i.pca in GRASS 7 can now do noise reduction by reconstructing the input bands from a user.defined subset of the principal components. This sounds like an interesting extension but the usage is not clear to me: # NC data set: g.region rast=lsat7_2002_10 -p i.pca input=lsat7_2002_10,lsat7_2002_20,lsat7_2002_30,lsat7_2002_40,lsat7_2002_50,lsat7_2002_70 -f percent=90 out=lsat7_2002_reduced g.mlist rast | grep reduced raster map(s) available in mapset neteler: attempt to explain: lsat7_2002_reduced.1 = filtered lsat7_2002_10 lsat7_2002_reduced.2 = filtered lsat7_2002_20 lsat7_2002_reduced.3 = filtered lsat7_2002_30 lsat7_2002_reduced.4 = filtered lsat7_2002_40 lsat7_2002_reduced.5 = filtered lsat7_2002_50 lsat7_2002_reduced.6 = filtered lsat7_2002_70 with perc=90, 2 PCA scores will be used for reconstruction, that is each cell of the first output band will be input[1] * PCA[1][1] + input[1] * PCA[2][1] and each cell of the last (6th) output band will be input[6] * PCA[1][6] + input[1] * PCA[2][6]. Any scaling and centering is considered. Say, this is not entirely clear to me: -f Output will be filtered input bands Applies inverse PCA after PCA Added to the manual. (Tha manual has a replicated parameters section which needs to be fixed, too. I can do that as soon as I understand the new functionality). It seems that replicated parameters are kind of a feature in imagery modules... To be fixed. Markus M ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] [GRASS-PSC] PSC nomination: Martin Landa
On Thu, Oct 11, 2012 at 4:27 PM, Margherita Di Leo direg...@gmail.com wrote: Dear PSC members, dear Community, I take the honour to nominate Martin Landa as PSC member. Martin is a top contributor for GRASS GIS over the past years [1] not only authoring source code but he also established the automated winGRASS build chain. He also organized the last two GRASS GIS Community sprints [2,3], an important event for the internal connection among developers, documenters, bug reporters, translators etc. He is always helpful with users and his efforts for the community are well known and I think don't really need further words. I support the nomination of Martin Landa as PSC member, his record of contributions to GRASS is really impressive. Markus M Thank you and best regards, Madi [1] https://www.ohloh.net/p/grass_gis/contributors [2] http://grass.osgeo.org/wiki/GRASS_Community_Sprint_Prague_2011 [3] http://grass.osgeo.org/wiki/GRASS_Community_Sprint_Prague_2012 -- Margherita DI LEO Postdoctoral Researcher European Commission - DG JRC Forest Resources and Climate I-21020 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-...@jrc.ec.europa.eu ___ grass-psc mailing list grass-...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-psc ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] v.buffer and categories
This is fixed only in GRASS 7, here, v.buffer can preserve attributes in the output. Furthermore, v.buffer in GRASS 6 is not working well, there are a number of known bugs. Alternatively, you can delete categories with v.category option=del cat=-1 followed by v.category option=add cat=1 Each polygon will then have its own unique category. HTH, Markus M On Tue, Oct 9, 2012 at 1:40 PM, Martin Album Ytre-Eide martin.album.ytre-e...@nrpa.no wrote: Hello all. I have three points for which I create three areas with v.buffer. However, this new polygon map have no attribute table - so I create one with v.category and v.db.addtable. This gives an attribute table with 3 categories but they are all linked to all polygons! I won't each polygon to have a separate category. Anyone knows what to do? Martin ___ 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] Network Analysis in GRASS
On Tue, Oct 2, 2012 at 12:49 PM, Moritz Lennert mlenn...@club.worldonline.be wrote: On 02/10/12 11:37, Margherita Di Leo wrote: On Tue, Oct 2, 2012 at 11:35 AM, Moritz Lennert mlenn...@club.worldonline.be mailto:mlenn...@club.worldonline.be wrote: On 01/10/12 10:10, Phil Donovan wrote: Kiaora GRASS! I require a network tool which can calculate 'service areas'. I know GRASS can currently do this but the specific problem I have is that I need to do it for a very large dataset (400,000 locations). I tried this with ArcGIS tool (sorry!) but it failed to 'solve' due to an overloaded memory. Would the GRASS tool 'v.net.iso' be able to process this without breaking? I don't have a straight answer to the question, but generally GRASS can handle fairly large datasets. It might depend more on the resources of your machine. The best way to find out would be to try. ;-) ..And please let us know :) Yes ! :-) As a follow-up: you might want to try grass7 as AFAIR some improvements in the modules only exist in that version for the moment. MarkusM can you confirm that ? v.net.iso itself has not changed much, but vector network analysis for large datasets (as other vector operations) should require much less memory in GRASS 7 because of substantial vector library changes. I have not tried network analysis with 400,000 locations myself (yet), but in theory the module would either bail out quickly with an out-of-memory error or happily crunch along. Markus M Moritz ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] problem installing Grass 7 in RHEL6
On Fri, Sep 14, 2012 at 9:17 AM, Mauricio Zambrano-Bigiarini
hzambran.newsgro...@gmail.com wrote:
Dear List,
I already managed to compile and install Grass 7 in Ubuntu 12.04, but
now I want to try it at work.
I'm trying to install Grass 7 on Red Hat Enterprise Linux 6, but I got
stuck during 'make', and I would like to ask your advice for solving
the issue.
According to the error log, most of GRASS was compiled successfully
and can be used without problems. The t.* commands require an
additional package python-dateutil which you can install on RHEL 6
with
yum install python-dateutil
After that package has been installed, the t.* modules should compile
successfully.
HTH,
Markus M
My machine:
$ uname -r
2.6.32-279.5.2.el6.x86_64
Following the instructions given on
'http://grass.osgeo.org/wiki/Compile_and_Install', I tried:
1) Installing all dependencies:
sudo yum install flex bison zlib-devel tcl-devel tk-devel gcc-c++
swig gettext \
libtiff-devel libpng-devel sqlite-devel \
mesa-libGL-devel mesa-libGLU-devel mesa-libGLw-devel \
mesa-libOSMesa-devel libXmu-devel python-devel gtk2-devel\
ncurses-devel postgresql-devel
2) configure:
CFLAGS=-g -Wall ./configure \
--with-cxx \
--with-sqlite \
--with-postgres \
--with-freetype \
--with-freetype-includes=/usr/include/freetype2 \
--with-motif \
--with-proj-share=/usr/share/proj
which gave as output:
GRASS is now configured for: x86_64-unknown-linux-gnu
Source directory:/dataMZB/src/grass_trunk
Build directory: /dataMZB/src/grass_trunk
Installation directory: ${prefix}/grass-7.0.svn
Startup script in directory: ${exec_prefix}/bin
C compiler: gcc -g -O2
C++ compiler:c++ -g -O2
Building shared libraries: yes
OpenGL platform: X11
MacOSX application: no
MacOSX architectures:
MacOSX SDK:
Tcl/Tk NVIZ:yes
BLAS support: no
C++ support:yes
Cairo support: yes
DWG support:no
FFMPEG support: no
FFTW support: no
FreeType support: yes
GDAL support: yes
NETCDF support: no
GEOS support: no
LAPACK support: no
Large File support (LFS): yes
libLAS support: no
MySQL support: no
NLS support:yes
ODBC support: no
OGR support:yes
OpenGL support: yes
OpenMP support: no
PNG support:yes
POSIX thread support: yes
PostgreSQL support: yes
Readline support: no
Regex support: yes
SQLite support: yes
TIFF support: yes
Tcl/Tk support: yes
wxWidgets support: yes
X11 support:yes
3) $ make
and the the errors I got at the end of 'make' were:
/usr/bin/install -c -m 644 REQUIREMENTS.html
/dataMZB/src/grass_trunk/dist.x86_64-unknown-linux-gnu/REQUIREMENTS.html
/usr/bin/install -c -m 644 GPL.TXT
/dataMZB/src/grass_trunk/dist.x86_64-unknown-linux-gnu/GPL.TXT
/usr/bin/install -c -m 644 contributors.csv
/dataMZB/src/grass_trunk/dist.x86_64-unknown-linux-gnu/contributors.csv
/usr/bin/install -c -m 644 contributors_extra.csv
/dataMZB/src/grass_trunk/dist.x86_64-unknown-linux-gnu/contributors_extra.csv
/usr/bin/install -c -m 644 translators.csv
/dataMZB/src/grass_trunk/dist.x86_64-unknown-linux-gnu/translators.csv
make[1]: Leaving directory `/dataMZB/src/grass_trunk'
make manifests
make[1]: Entering directory `/dataMZB/src/grass_trunk'
make[1]: Nothing to be done for `manifests'.
make[1]: Leaving directory `/dataMZB/src/grass_trunk'
GRASS GIS compilation log
-
Started compilation: Thu Sep 13 17:03:08 CEST 2012
--
Errors in:
/dataMZB/src/grass_trunk/scripts/v.krige
/dataMZB/src/grass_trunk/temporal/t.create
/dataMZB/src/grass_trunk/temporal/t.support
/dataMZB/src/grass_trunk/temporal/t.topology
/dataMZB/src/grass_trunk/temporal/t.list
/dataMZB/src/grass_trunk/temporal/t.info
/dataMZB/src/grass_trunk/temporal/t.remove
/dataMZB/src/grass_trunk/temporal/t.sample
/dataMZB/src/grass_trunk/temporal/t.register
/dataMZB/src/grass_trunk/temporal/t.unregister
/dataMZB/src/grass_trunk/temporal/t.rast.aggregate
/dataMZB/src/grass_trunk/temporal/t.rast.aggregate.ds
/dataMZB/src/grass_trunk/temporal/t.rast.to.rast3
/dataMZB/src/grass_trunk/temporal/t.rast.univar
/dataMZB/src/grass_trunk/temporal/t.rast.list
/dataMZB/src/grass_trunk/temporal/t.rast.mapcalc
/dataMZB/src/grass_trunk/temporal/t.rast.series
/dataMZB/src/grass_trunk/temporal/t.rast.export
/dataMZB/src/grass_trunk/temporal/t.rast.out.vtk
Re: [GRASS-user] r.stream.order export to shapefile
On Tue, Sep 4, 2012 at 8:33 AM, Micha Silver mi...@arava.co.il wrote:
On 09/03/2012 11:24 PM, Markus Neteler wrote:
On Mon, Sep 3, 2012 at 9:53 AM, Micha Silver mi...@arava.co.il wrote:
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
-- this should be /usr/local/grass-6.4.2//tools/g.html2man/g.html2man
I found in $GISBASE/include/Make/Man.make:
grep HTML2MAN /usr/local/grass-6.4.2/include/Make/Man.make.orig
Apparently there were changes in the local copy of Man.make which
conflicted with svn up. Either delete all Man.make* or patch your
changes into the current svn Man.make. In any case, you should check
with svn diff for differences.
Markus M
HTML2MAN = GRASS_PERL=${PERL} VERSION_NUMBER=${GRASS_VERSION_NUMBER} sh
$(MODULE_TOPDIR)/tools/g.html2man
When I changed that line to $(MODULE_TOPDIR)/tools/g.html2man/g.html2man the
man pages were created.
Ticket created:
http://trac.osgeo.org/grass/ticket/1721
Regards,
Micha
/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
Could you try to understand why it is incomplete there?
MarkusN
This mail was received via Mail-SeCure System.
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.stream.order export to shapefile
On Mon, Sep 3, 2012 at 9:53 AM, Micha Silver mi...@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 Silvermi...@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=50 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 tablestream_order is now part of vector mapstream_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 countminmax point248 1237 line 237 1237 boundary 0 0 0 centroid 0 0 0 area 0 0 0 all 485 1237 Layer/table: 2/stream_order type countminmax point248 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 tostream_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 Silvermi...@arava.co.il wrote: A few
Re: [GRASS-user] r.stream.order export to shapefile
On Wed, Aug 29, 2012 at 1:28 PM, Micha Silver mi...@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=50 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 countminmax point248 1237 line 237 1237 boundary 0 0 0 centroid 0 0 0 area 0 0 0 all 485 1237 Layer/table: 2/stream_order type countminmax point248 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 Silvermi...@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@SL6 r.stream.order]$ diff -u io.c.orig io.c --- io.c.orig2012-08-28 12:21:46.020275045 +0300 +++ io.c2012-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
