From carlos.grohmann at gmail.com Mon Sep 1 08:00:46 2014 From: carlos.grohmann at gmail.com (Carlos Grohmann) Date: Mon, 1 Sep 2014 12:00:46 -0300 Subject: [GRASS-user] OSX Yosemite - GRASS 6.4 stopped working Message-ID: Hi all I'm running OS X Yosemite Beta, and my GRASS install just stopped working. It was running fine until last week, but now I can't open it, with the following error msg: Last login: Mon Sep 1 11:37:04 on ttys002 '/Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh'; exit GuanoBookPro:~ guano$ '/Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh'; exit -bash: /Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh: No such file or directory logout [Process completed] The same happens with GRASS-7 I don't recall updating anything (maybe some automatic update happened in the background), and I already tried to reinstall GRASS. Trying to run grass.sh from /Applications/GRASS-6.4.app/Contents/MacOS/ will not work as well, first with a Gis_set Error about the splash screen (should a missing splash screen gif cause an error on startup??), and after it, with a python error: Starting GRASS ... Traceback (most recent call last): File "./etc/wxpython/gis_set.py", line 1003, in GRASSStartUp = StartUp(0) File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", line 8631, in __init__ self._BootstrapApp() File "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", line 8196, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File "./etc/wxpython/gis_set.py", line 978, in OnInit StartUp = GRASSStartup() File "./etc/wxpython/gis_set.py", line 95, in __init__ versionFile = open(os.path.join(globalvar.ETCDIR, "VERSIONNUMBER")) IOError: [Errno 2] No such file or directory: './etc/VERSIONNUMBER' Error in GUI startup. If necessary, please report this error to the GRASS developers. Switching to text mode now. Hit RETURN to continue... So, I went and reinstall wxpython, but again with no success. any help at this point is very much welcome best Carlos -- Prof. Carlos Henrique Grohmann Institute of Energy and Environment - Univ. of S?o Paulo, Brazil - Digital Terrain Analysis | GIS | Remote Sensing - http://carlosgrohmann.com http://orcid.org/0000-0001-5073-5572 ________________ Can't stop the signal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tea3rd at gmail.com Mon Sep 1 09:48:36 2014 From: tea3rd at gmail.com (Thomas Adams) Date: Mon, 1 Sep 2014 12:48:36 -0400 Subject: [GRASS-user] OSX Yosemite - GRASS 6.4 stopped working In-Reply-To: References: Message-ID: Carlos, I have seen the same thing; here is what I figured-out as a brute force work-around: (1) in the TERM window that pops-up do Control-C (2) copy and paste: /Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh (or the GRASS 7 equivalent) (3) This works every time I get this + it seems to temporarily 'fix' the problem... Cheers! Tom On Mon, Sep 1, 2014 at 11:00 AM, Carlos Grohmann wrote: > Hi all > > I'm running OS X Yosemite Beta, and my GRASS install just stopped working. > It was running fine until last week, but now I can't open it, with the > following error msg: > > > > Last login: Mon Sep 1 11:37:04 on ttys002 > '/Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh'; > exit > GuanoBookPro:~ guano$ > '/Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh'; > exit > -bash: > /Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh: > No such file or directory > logout > > [Process completed] > > > The same happens with GRASS-7 > > I don't recall updating anything (maybe some automatic update happened in > the background), and I already tried to reinstall GRASS. > > Trying to run grass.sh from /Applications/GRASS-6.4.app/Contents/MacOS/ > will not work as well, first with a Gis_set Error about the splash screen > (should a missing splash screen gif cause an error on startup??), and after > it, with a python error: > > Starting GRASS ... > Traceback (most recent call last): > File "./etc/wxpython/gis_set.py", line 1003, in > GRASSStartUp = StartUp(0) > File > "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", line > 8631, in __init__ > self._BootstrapApp() > File > "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", line > 8196, in _BootstrapApp > return _core_.PyApp__BootstrapApp(*args, **kwargs) > File "./etc/wxpython/gis_set.py", line 978, in OnInit > StartUp = GRASSStartup() > File "./etc/wxpython/gis_set.py", line 95, in __init__ > versionFile = open(os.path.join(globalvar.ETCDIR, "VERSIONNUMBER")) > IOError: [Errno 2] No such file or directory: './etc/VERSIONNUMBER' > Error in GUI startup. If necessary, please > report this error to the GRASS developers. > Switching to text mode now. > Hit RETURN to continue... > > > So, I went and reinstall wxpython, but again with no success. > > > any help at this point is very much welcome > > best > > Carlos > > > > > > > > > > > > > -- > Prof. Carlos Henrique Grohmann > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil > - Digital Terrain Analysis | GIS | Remote Sensing - > > http://carlosgrohmann.com > http://orcid.org/0000-0001-5073-5572 > ________________ > Can?t stop the signal. > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos.grohmann at gmail.com Mon Sep 1 09:54:58 2014 From: carlos.grohmann at gmail.com (Carlos Grohmann) Date: Mon, 1 Sep 2014 13:54:58 -0300 Subject: [GRASS-user] OSX Yosemite - GRASS 6.4 stopped working In-Reply-To: References: Message-ID: Thanks Tom, but I couldn't replicate your workaround. You mean the term window that opens when GRASS is started "normally" (from dock or Application)? If so, mine was a bit fast and I couldn't hit ctrl-C fast enough to stop it in a normal term window, just pasting the line you provided also returned me the same error as before (No such file or directory) best Carlos On Mon, Sep 1, 2014 at 1:48 PM, Thomas Adams wrote: > Carlos, > > I have seen the same thing; here is what I figured-out as a brute force > work-around: > > (1) in the TERM window that pops-up do Control-C > (2) copy and paste: > /Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh > (or the GRASS 7 equivalent) > (3) > > This works every time I get this + it seems to temporarily 'fix' the > problem... > > Cheers! > > Tom > > > On Mon, Sep 1, 2014 at 11:00 AM, Carlos Grohmann < > carlos.grohmann at gmail.com> wrote: > >> Hi all >> >> I'm running OS X Yosemite Beta, and my GRASS install just stopped >> working. It was running fine until last week, but now I can't open it, with >> the following error msg: >> >> >> >> Last login: Mon Sep 1 11:37:04 on ttys002 >> '/Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh'; >> exit >> GuanoBookPro:~ guano$ >> '/Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh'; >> exit >> -bash: >> /Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh: >> No such file or directory >> logout >> >> [Process completed] >> >> >> The same happens with GRASS-7 >> >> I don't recall updating anything (maybe some automatic update happened in >> the background), and I already tried to reinstall GRASS. >> >> Trying to run grass.sh from /Applications/GRASS-6.4.app/Contents/MacOS/ >> will not work as well, first with a Gis_set Error about the splash screen >> (should a missing splash screen gif cause an error on startup??), and after >> it, with a python error: >> >> Starting GRASS ... >> Traceback (most recent call last): >> File "./etc/wxpython/gis_set.py", line 1003, in >> GRASSStartUp = StartUp(0) >> File >> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", line >> 8631, in __init__ >> self._BootstrapApp() >> File >> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", line >> 8196, in _BootstrapApp >> return _core_.PyApp__BootstrapApp(*args, **kwargs) >> File "./etc/wxpython/gis_set.py", line 978, in OnInit >> StartUp = GRASSStartup() >> File "./etc/wxpython/gis_set.py", line 95, in __init__ >> versionFile = open(os.path.join(globalvar.ETCDIR, "VERSIONNUMBER")) >> IOError: [Errno 2] No such file or directory: './etc/VERSIONNUMBER' >> Error in GUI startup. If necessary, please >> report this error to the GRASS developers. >> Switching to text mode now. >> Hit RETURN to continue... >> >> >> So, I went and reinstall wxpython, but again with no success. >> >> >> any help at this point is very much welcome >> >> best >> >> Carlos >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> Prof. Carlos Henrique Grohmann >> Institute of Energy and Environment - Univ. of S?o Paulo, Brazil >> - Digital Terrain Analysis | GIS | Remote Sensing - >> >> http://carlosgrohmann.com >> http://orcid.org/0000-0001-5073-5572 >> ________________ >> Can't stop the signal. >> >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > -- Prof. Carlos Henrique Grohmann Institute of Energy and Environment - Univ. of S?o Paulo, Brazil - Digital Terrain Analysis | GIS | Remote Sensing - http://carlosgrohmann.com http://orcid.org/0000-0001-5073-5572 ________________ Can't stop the signal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tea3rd at gmail.com Mon Sep 1 14:24:52 2014 From: tea3rd at gmail.com (Thomas Adams) Date: Mon, 1 Sep 2014 17:24:52 -0400 Subject: [GRASS-user] OSX Yosemite - GRASS 6.4 stopped working In-Reply-To: References: Message-ID: Carlos, Yes, the 'normal' GRASS TERM window. My apologies; I did not mean to use Control-C during the GRASS launch, but -AFTER- the error appears. What I sent you was from your original post. Interestingly, when I try to launch GRASS on my Mac, I got the error I often see, but *your* error message is very different from *mine*. You get: /Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh The error I get has the path: /Applications/GRASS-6.4.app/Contents/MacOS/grass.sh See what happens if you use my path, above. If you have GRASS in your Applications folder, the path I have should work. I have no idea why yours is so different. No wonder GRASS is not launching. BTW, just now, when I used my path above, GRASS just launched just fine for me. Best, Tom On Mon, Sep 1, 2014 at 12:54 PM, Carlos Grohmann wrote: > Thanks Tom, > > but I couldn't replicate your workaround. You mean the term window that > opens when GRASS is started "normally" (from dock or Application)? > > If so, mine was a bit fast and I couldn't hit ctrl-C fast enough to stop > it > > in a normal term window, just pasting the line you provided also returned > me the same error as before (No such file or directory) > > > best > > Carlos > > > > > > > > > > > On Mon, Sep 1, 2014 at 1:48 PM, Thomas Adams wrote: > >> Carlos, >> >> I have seen the same thing; here is what I figured-out as a brute force >> work-around: >> >> (1) in the TERM window that pops-up do Control-C >> (2) copy and paste: >> /Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh >> (or the GRASS 7 equivalent) >> (3) >> >> This works every time I get this + it seems to temporarily 'fix' the >> problem... >> >> Cheers! >> >> Tom >> >> >> On Mon, Sep 1, 2014 at 11:00 AM, Carlos Grohmann < >> carlos.grohmann at gmail.com> wrote: >> >>> Hi all >>> >>> I'm running OS X Yosemite Beta, and my GRASS install just stopped >>> working. It was running fine until last week, but now I can't open it, with >>> the following error msg: >>> >>> >>> >>> Last login: Mon Sep 1 11:37:04 on ttys002 >>> '/Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh'; >>> exit >>> GuanoBookPro:~ guano$ >>> '/Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh'; >>> exit >>> -bash: >>> /Applications/GRASS-6.4.app/Contents/Resources/Scripts/GRASS.scptContents/MacOS/grass.sh: >>> No such file or directory >>> logout >>> >>> [Process completed] >>> >>> >>> The same happens with GRASS-7 >>> >>> I don't recall updating anything (maybe some automatic update happened >>> in the background), and I already tried to reinstall GRASS. >>> >>> Trying to run grass.sh from /Applications/GRASS-6.4.app/Contents/MacOS/ >>> will not work as well, first with a Gis_set Error about the splash screen >>> (should a missing splash screen gif cause an error on startup??), and after >>> it, with a python error: >>> >>> Starting GRASS ... >>> Traceback (most recent call last): >>> File "./etc/wxpython/gis_set.py", line 1003, in >>> GRASSStartUp = StartUp(0) >>> File >>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", line >>> 8631, in __init__ >>> self._BootstrapApp() >>> File >>> "/Applications/GRASS-6.4.app/Contents/MacOS/etc/python/wx/_core.py", line >>> 8196, in _BootstrapApp >>> return _core_.PyApp__BootstrapApp(*args, **kwargs) >>> File "./etc/wxpython/gis_set.py", line 978, in OnInit >>> StartUp = GRASSStartup() >>> File "./etc/wxpython/gis_set.py", line 95, in __init__ >>> versionFile = open(os.path.join(globalvar.ETCDIR, "VERSIONNUMBER")) >>> IOError: [Errno 2] No such file or directory: './etc/VERSIONNUMBER' >>> Error in GUI startup. If necessary, please >>> report this error to the GRASS developers. >>> Switching to text mode now. >>> Hit RETURN to continue... >>> >>> >>> So, I went and reinstall wxpython, but again with no success. >>> >>> >>> any help at this point is very much welcome >>> >>> best >>> >>> Carlos >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> Prof. Carlos Henrique Grohmann >>> Institute of Energy and Environment - Univ. of S?o Paulo, Brazil >>> - Digital Terrain Analysis | GIS | Remote Sensing - >>> >>> http://carlosgrohmann.com >>> http://orcid.org/0000-0001-5073-5572 >>> ________________ >>> Can?t stop the signal. >>> >>> _______________________________________________ >>> grass-user mailing list >>> grass-user at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> >> > > > -- > Prof. Carlos Henrique Grohmann > Institute of Energy and Environment - Univ. of S?o Paulo, Brazil > - Digital Terrain Analysis | GIS | Remote Sensing - > > http://carlosgrohmann.com > http://orcid.org/0000-0001-5073-5572 > ________________ > Can?t stop the signal. > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Mon Sep 1 14:45:45 2014 From: neteler at osgeo.org (Markus Neteler) Date: Mon, 1 Sep 2014 23:45:45 +0200 Subject: [GRASS-user] Topological Trouble In-Reply-To: <824e3833-78b6-4c13-a2ed-2f57a0617394@email.android.com> References: <53FF1521.1020105@jimkeener.com> <824e3833-78b6-4c13-a2ed-2f57a0617394@email.android.com> Message-ID: On Thu, Aug 28, 2014 at 10:32 PM, James Keener wrote: > 6.4.3 sorry about not including that from the start. > > On August 28, 2014 3:42:45 PM EDT, Markus Neteler wrote: ... >> On Thu, Aug 28, 2014 at 1:40 PM, James Keener wrote: >>> >>> I'm trying to create a map with isolines for the road-distance places >>> are from bus routes. I was trying to roughly follow >>> >>> http://jcastellssala.wordpress.com/2012/05/07/basic-network-analysis-with-grass/ (nice tutorial, btw) Note that their projection is in meters, while... >>> I am using the following shapefiles in SRID 2272 (NAD83 / Pennsylvania >>> South (ftUS)): ... your's is in US feet (http://epsg.io/2272). This affect the threshold you use below: ... >>> So, the first thing I did is import these files: ... >>> Then I connect the stops to the network >>> >>>> v.net input=roads points=stops output=network operation=connect >>>> thresh=500 Note that the threshold is specified in map units (so, here feet in your case). Sidenote: in GRASS GIS 7 the module is a bit more advanced: http://grass.osgeo.org/grass70/manuals/v.net.html Perhaps (guessing, I didn't have time to test your data), the initial threshold makes the difference? Best, Markus From neteler at osgeo.org Mon Sep 1 14:59:27 2014 From: neteler at osgeo.org (Markus Neteler) Date: Mon, 1 Sep 2014 23:59:27 +0200 Subject: [GRASS-user] r.li circular window and not integer radius In-Reply-To: References: Message-ID: On Sat, Aug 30, 2014 at 1:42 PM, Sergio Vignali wrote: > Hi Markus, > I've just checked in GRASS 7. > If I use an integer radius or a real number the module doesn't give an error > (see below) > > https://www.dropbox.com/s/vv5j0xkzb90j9gv/mv_setting.png?dl=0 > > but it don't create the configuration file as you can see in the image below Could you please send us the steps how you generated the circular window, ideally in the North Carolina location? This would accelerate to help you... thanks Markus From jim at jimkeener.com Mon Sep 1 16:26:03 2014 From: jim at jimkeener.com (James Keener) Date: Mon, 01 Sep 2014 19:26:03 -0400 Subject: [GRASS-user] Topological Trouble In-Reply-To: References: <53FF1521.1020105@jimkeener.com> <824e3833-78b6-4c13-a2ed-2f57a0617394@email.android.com> Message-ID: <5405008B.3050900@jimkeener.com> Thanks for replying Markus, > > Note that their projection is in meters, while... > >>>> I am using the following shapefiles in SRID 2272 (NAD83 / Pennsylvania >>>> South (ftUS)): > > ... your's is in US feet (http://epsg.io/2272). > This affect the threshold you use below: > I know. For testing purposes it seemed to be reasonable, though (increments of 1000 ft. For my final map I'll probably do 1/4mi, 1/2mi, 3/4mi, and 1mi increments). >>>>> v.net input=roads points=stops output=network operation=connect >>>>> thresh=500 > > Note that the threshold is specified in map units (so, here feet in your case). > I spot checked a lot of the bus stops, and they appeared to be connected to the road graph. FWIW. The TIGER road maps do appear to make intersections overlap, but don't put a point that all the adjoining roads connect to. (This brings up something I was going to worry about later: bridges vs intersections?) > Sidenote: in GRASS GIS 7 the module is a bit more advanced: > http://grass.osgeo.org/grass70/manuals/v.net.html > > Perhaps (guessing, I didn't have time to test your data), the initial > threshold makes the difference? > I'll have to give GRASS 7 a shot:) (GRASS 6 is what was in the repo I was using). I'm completely new at this so the biggest problem for me is not know exactly where to look when something isn't working. Thanks again for your input! Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rajat27404 at gmail.com Tue Sep 2 05:57:58 2014 From: rajat27404 at gmail.com (Rajat Nayak) Date: Tue, 2 Sep 2014 18:27:58 +0530 Subject: [GRASS-user] help with batch exporting r.out.gdal Message-ID: Dear All, I just created a list of files (NPPFILES) using g,mlist command in grass7. Now I would like to export these files as .tiff files. I tried this command for files in $NPPFILES; do r.out.gdal input="$NPPFILES" output="$NPPFILES.tiff" format=GTiff ; done This is not working for me. I tried giving directory path, still no result. I will be grateful if anybody can help me with this. Thanking you, Regards Rajat Nayak -------------- next part -------------- An HTML attachment was scrubbed... URL: From tea3rd at gmail.com Tue Sep 2 06:20:01 2014 From: tea3rd at gmail.com (Thomas Adams) Date: Tue, 2 Sep 2014 09:20:01 -0400 Subject: [GRASS-user] help with batch exporting r.out.gdal In-Reply-To: References: Message-ID: Rajat, I assume you are running this at the GRASS prompt? If not, you must do this. Also, if you don't provide the full path for 'NPPFILES', you should run the command from the directory where 'NPPFILES' is located. Additionally, you may want to change your code to this: for files in $(cat NPPFILES); do echo $files; r.out.gdal input="$NPPFILES" output="$NPPFILES.tiff" format=GTiff ; done You may want to include the line "echo $files;" to see if the individual map names are being read correctly Regards, Tom On Tue, Sep 2, 2014 at 8:57 AM, Rajat Nayak wrote: > Dear All, > > I just created a list of files (NPPFILES) using g,mlist command in grass7. > Now I would like to export these files as .tiff files. > I tried this command > for files in $NPPFILES; do > r.out.gdal input="$NPPFILES" output="$NPPFILES.tiff" format=GTiff ; done > > This is not working for me. I tried giving directory path, still no result. > > I will be grateful if anybody can help me with this. > > Thanking you, > > Regards > > Rajat Nayak > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lluis at sigte.udg.es Tue Sep 2 06:16:34 2014 From: lluis at sigte.udg.es (=?windows-1252?Q?Llu=EDs_Vicens?=) Date: Tue, 02 Sep 2014 15:16:34 +0200 Subject: [GRASS-user] Strange behaviour of v.net on GRASS GIS 7 In-Reply-To: References: <53B53F44.20409@sigte.udg.es> Message-ID: <5405C332.90101@sigte.udg.es> On 28/08/14 22:56, Markus Metz wrote: > On Thu, Jul 3, 2014 at 1:32 PM, Llu?s Vicens wrote: >> Hi, >> >> I'm working with GRASS GIS 7.0.0svn (r59969) on Ubuntu 14.04 LTS and I'm >> experiencing a strange behaviour when using v.net. I have set of nodes that >> I want to connect to a collection of streets on a network. >> >> When I execute "v.net streets points=poi out=net op=connect thresh=35" on >> GRASS GIS 6.4.4, the new arc(s)/line(s) that connect the points to the >> network, inherit all the attributes (even the 'cat' value) of the >> pre-existing arcs. But, when I execute the same command on GRASS GIS 7.0.0 >> that expected behaviour doesn't take place. The new arc(s)/line(s) generated >> with GRASS 7 doesn't have attributes, a new cat value is generated for each >> new line but they doesn't appear on the attribute table... >> >> I don't know if this is a bug/error, or a different but deliberated >> behaviour. > This new behaviour is by purpose. It does not make sense for a new arc > to inherit the category and attributes of a pre-existing arc. For > example connecting a point to a one-way road could cause the point to > become unreachable because the new arc would also be a one-way road. > If a pre-existing arc is split into two parts, the two new components > should inherit the attributes, but not the categories in order to be > able to assign unique costs to the arcs. See the manual for v.net.path > for an example. > > Unless you want to do something particular with these new arcs, it is > usually easier to snap the points to the network instead of creating > new arcs from the points to the network (GRASS 7 only). > > Markus M A lot of thanks Markus, for your answer and explanation. Cheers, Llu?s > >> Thanks in advance. >> Cheers, >> Llu?s >> >> -- >> Llu?s Vicens >> >> SIGTE - Universitat de Girona >> Pl. Ferrater Mora, 1 >> 17071 Girona >> >> >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user -- Llu?s Vicens SIGTE - Universitat de Girona Pl. Ferrater Mora, 1 17071 Girona -------------- next part -------------- An HTML attachment was scrubbed... URL: From vignalisergio30 at gmail.com Tue Sep 2 11:51:27 2014 From: vignalisergio30 at gmail.com (Sergio Vignali) Date: Tue, 2 Sep 2014 20:51:27 +0200 Subject: [GRASS-user] r.li circular window and not integer radius In-Reply-To: References: Message-ID: So, here my steps with GRASS 7: I used the North Carolina mapset, I chose the raster map landuse96_28m and set the region to this map setup for r.li module: create new configuration file for r.li module Select maps and define name Name for new configuration file to create circmw Raster map to use to select areas landuse96_28m at PERMANENT Define sampling region(region for analysis Whole map layer https://www.dropbox.com/s/kbbm5udk81rwwsn/r_li_shannon.png?dl=0 next>> Insert sampling areas moving window choose a method use keyboard to enter sampling area https://www.dropbox.com/s/x0p2c1i5hi9021e/grass2.png?dl=0 next>> Set moving windows select type of shape circle what radius size(in metres)? 50 name of the circle mask circlemw50 https://www.dropbox.com/s/jp9anfx1kur0qyx/grass3.png?dl=0 next>> the window shows the Summary https://www.dropbox.com/s/blinm97w90uig7f/grass4.png?dl=0 Finish>> Do you want to create a r.li configuartion file (circmw)? Yes The configuration file doesn't appeare on the GRASS GIS Setup for r.li modules on the list of available sampling area configuration files https://www.dropbox.com/s/y0mifl4dx872o7v/grass5.png?dl=0 While I'm writing my steps I see an error message on the command console (see below) https://www.dropbox.com/s/1b5hjmp745wh1hk/grass6.png?dl=0 anyway if I open again the setup module my configuration file is on the list, and then View/Edit buttom>> the window is empty https://www.dropbox.com/s/1b5hjmp745wh1hk/grass7.png?dl=0 I hope this can help you to find the error All the best Sergio 2014-09-01 23:59 GMT+02:00 Markus Neteler : > On Sat, Aug 30, 2014 at 1:42 PM, Sergio Vignali > wrote: > > Hi Markus, > > I've just checked in GRASS 7. > > If I use an integer radius or a real number the module doesn't give an > error > > (see below) > > > > https://www.dropbox.com/s/vv5j0xkzb90j9gv/mv_setting.png?dl=0 > > > > but it don't create the configuration file as you can see in the image > below > > Could you please send us the steps how you generated the circular > window, ideally in the North Carolina location? > This would accelerate to help you... > > thanks > Markus > -- Sergio Vignali -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannesradinger at gmail.com Wed Sep 3 02:17:42 2014 From: johannesradinger at gmail.com (Johannes Radinger) Date: Wed, 3 Sep 2014 11:17:42 +0200 Subject: [GRASS-user] r.clump2 for GRASS7 Message-ID: Hi, I am just wondering if the add-on r.clump2 is still available for GRASS 7. I can find the add-on manual mentioned here: http://grass.osgeo.org/grass70/manuals/addons/r.clump2.html However I could not find r.clump2 via g.extension. I seems that the list http://grass.osgeo.org/grass70/manuals/ is out of date (e.g. r.fidimo add-on is missing). I was just interested in r.clump2 as this add-on also considered diagonal cells. However, most probably I can find a work around with r.grow in combination with r.clump. But it would be nice if the feature of r.clump2 to clump also diagonal cells can be integrated in the main r.clump. Cheers, Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From peifer at gmx.eu Wed Sep 3 02:42:24 2014 From: peifer at gmx.eu (peifer) Date: Wed, 3 Sep 2014 02:42:24 -0700 (PDT) Subject: [GRASS-user] r.clump2 for GRASS7 In-Reply-To: References: Message-ID: <1409737344006-5159846.post@n6.nabble.com> Johannes Radinger wrote > I was just interested in r.clump2 as this add-on also considered diagonal > cells. What about using r.clump -d, see http://grass.osgeo.org/grass70/manuals/r.clump.html Hermann -- View this message in context: http://osgeo-org.1560.x6.nabble.com/r-clump2-for-GRASS7-tp5159837p5159846.html Sent from the Grass - Users mailing list archive at Nabble.com. From johan_debraak at hotmail.com Wed Sep 3 07:46:38 2014 From: johan_debraak at hotmail.com (Johan de Braak) Date: Wed, 3 Sep 2014 16:46:38 +0200 Subject: [GRASS-user] v.to.rast weird output In-Reply-To: <1409737344006-5159846.post@n6.nabble.com> References: , <1409737344006-5159846.post@n6.nabble.com> Message-ID: Dear all, I try to convert some training data for an image classification to raster (so it can serve in i.gensig). Since this training data is thematical (1 is bare soil, 2 is degraded forest etc.), I used only whole numbers to assign the classes. However, when checking the result using r.report, I get classes as: 1-1.03 and 1.97-2.03 and descriptions like "from bare soil to degraded forest"... Should I be concerned of this? Did I made a mistake somewhere along the path? Can this be avoided? Best wishes, Johan de Braak -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannesradinger at gmail.com Wed Sep 3 09:32:07 2014 From: johannesradinger at gmail.com (Johannes Radinger) Date: Wed, 3 Sep 2014 18:32:07 +0200 Subject: [GRASS-user] multiple output maps of r.random.surface Message-ID: Hi, I'd like to generate multiple random surface with different spatial autocorrelation. Of course I can do that with multiple runs of r.random.surface (GRASS7) by setting different values for the distance parameter for each run (this works fine). In the manual I read that if "If multiple values are given [for the distance parameter?], each output map will have multiple filters, one for each set of distance, exponent, and weight values." Indeed, I can provide multiple names for the desired output maps, but if I want to use multiple values for the distance parameter only the first is considered. Maybe I understood the manual wrong and somebody can explain it. Here an example (e.g. for the NC dataset): r.random.surface --overwrite output=r1,r2,r3 distance=50000.0,2.0,2000.0 seed=999 high=20000 There are multiple different maps generated but the spatial dependence of the maps seems the same. Any ideas? Anyway, there is of course still the easy way of running r.random.surface in loops. cheers, Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Wed Sep 3 21:14:50 2014 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Thu, 4 Sep 2014 00:14:50 -0400 Subject: [GRASS-user] Problem installing v.class.mlpy on Mac OS X Lion 10.7.5 In-Reply-To: References: Message-ID: On Thu, Aug 28, 2014 at 3:08 AM, Christina Ludwig wrote: > Hi everyone, > > I just started using GRASS GIS and I would like to use the v.class.mlpy > extension. So I successfully installed numpy, scipy and mlpy and when I > import them in Python they all seem to work fine. However, when I try to > install the v.class.mlpy extension using "g.extension > extension=v.class.mlpy" I get the following error message: > > "Cannot import mlpy (http://mlpy.sourceforge.net) library. Please install > it or ensure that it is on path. (use PYTHONPATH variable)." > > The mlpy folder > (/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mlpy/) > is on my PYTHONPATH and if I start Python in the terminal and import mlpy > everything works fine. > > If I try to directly import mlpy in the GRASS GIS Python shell I get the > following message: > > Python 2.7.8 (v2.7.8:ee879c0ffa11, Jun 29 2014, 21:07:35) > [GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > import mlpy > Traceback (most recent call last): > File "", line 1, in > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mlpy/__init__.py", > line 18, in > import gsl > ImportError: > dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mlpy/gsl.so, > 2): Symbol not found: _gsl_sf_fact > Referenced from: > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mlpy/gsl.so > Expected in: flat namespace > in > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mlpy/gsl.so > > Does anybody know what might be the problem? I would greatly appreciate > any help!! :) > > I don't know where is the problem. It seems that Python environment is somehow broken in GRASS session. This might be due to the different ways how software is installed on Mac. To understand the problem more, you can try to run python from standard command line but in GRASS GIS session (i.e. not from the GUI). You can also check PYTHONPATH environmental variable there. Compare also values of DYLD_LIBRARY_PATH environmental variable. Also Python variable sys.executable might be interesting. Note that there is also v.class.ml module which has richer but different functionality and can use also scikit-learn library. http://svn.osgeo.org/grass/grass-addons/grass7/vector/v.class.ml/v.class.ml.html http://scikit-learn.org/stable/ Vaclav > > Cheers, > Christina > > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajat27404 at gmail.com Wed Sep 3 23:00:51 2014 From: rajat27404 at gmail.com (Rajat Nayak) Date: Thu, 4 Sep 2014 11:30:51 +0530 Subject: [GRASS-user] help with batch exporting r.out.gdal In-Reply-To: References: Message-ID: Thank you Tom for the mail. I'm still unable to get it working. Some smaller cliche I guess, will try again. Regards Rajat Nayak On Tue, Sep 2, 2014 at 6:50 PM, Thomas Adams wrote: > Rajat, > > I assume you are running this at the GRASS prompt? If not, you must do > this. Also, if you don't provide the full path for 'NPPFILES', you should > run the command from the directory where 'NPPFILES' is located. > Additionally, you may want to change your code to this: > > for files in $(cat NPPFILES); do > echo $files; > > r.out.gdal input="$NPPFILES" output="$NPPFILES.tiff" format=GTiff ; done > > You may want to include the line "echo $files;" to see if the individual > map names are being read correctly > > Regards, > Tom > > > On Tue, Sep 2, 2014 at 8:57 AM, Rajat Nayak wrote: > >> Dear All, >> >> I just created a list of files (NPPFILES) using g,mlist command in >> grass7. >> Now I would like to export these files as .tiff files. >> I tried this command >> for files in $NPPFILES; do >> r.out.gdal input="$NPPFILES" output="$NPPFILES.tiff" format=GTiff ; done >> >> This is not working for me. I tried giving directory path, still no >> result. >> >> I will be grateful if anybody can help me with this. >> >> Thanking you, >> >> Regards >> >> Rajat Nayak >> >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nik at nikosalexandris.net Thu Sep 4 00:09:45 2014 From: nik at nikosalexandris.net (Nikos Alexandris) Date: Thu, 4 Sep 2014 10:09:45 +0300 Subject: [GRASS-user] help with batch exporting r.out.gdal In-Reply-To: References: Message-ID: <20140904070945.GA2707@tpx1c2g> Rajat Nayak wrote: > >> I just created a list of files (NPPFILES) using g,mlist command in > >> grass7. Now I would like to export these files as .tiff files. > >> I tried this command > >> for files in $NPPFILES; do > >> r.out.gdal input="$NPPFILES" output="$NPPFILES.tiff" format=GTiff ; done Here, you ask the string "files" to get each of the whatsoever values are stored inside the variable $NPPFILES. 1. is there an NPPFILES variable defined already? Something like NPPFILES=" file_1 file_2 flie_3" 2. What you actually need to feed the "input=" parameter, is the "files" term, not the "$NPPFILES". > >> This is not working for me. I tried giving directory path, still no > >> result. ok, assuming you are running this from inside a GRASSy session, you should be, at the time of executing the for loop, inside the directory where the "list of files" is also present. I guess you created a file, say "nppfiles_list". To be sure, just instruct cat nppfiles_list and expect to get the list of files you created. If that's ok, then it should work, e.g.: for File in `cat nppfiles_list`; do r.out.gdal input=${File} output=${File}.tiff; done Note, instead of "File" it could be any other string you like. Hope this helps a bit. Nikos From rajat27404 at gmail.com Thu Sep 4 00:38:12 2014 From: rajat27404 at gmail.com (Rajat Nayak) Date: Thu, 4 Sep 2014 13:08:12 +0530 Subject: [GRASS-user] help with batch exporting r.out.gdal In-Reply-To: <20140904070945.GA2707@tpx1c2g> References: <20140904070945.GA2707@tpx1c2g> Message-ID: Thank you Nikos and Tom. The command worked. This is what I used, for files in `cat NPPFILES`; do r.out.gdal in="${files}" out="${files}" format="GTiff"; done Regards Rajat Nayak On Thu, Sep 4, 2014 at 12:39 PM, Nikos Alexandris wrote: > > Rajat Nayak wrote: > > > >> I just created a list of files (NPPFILES) using g,mlist command in > > >> grass7. Now I would like to export these files as .tiff files. > > >> I tried this command > > > >> for files in $NPPFILES; do > > >> r.out.gdal input="$NPPFILES" output="$NPPFILES.tiff" format=GTiff ; > done > > > Here, you ask the string "files" to get each of the whatsoever values > are stored inside the variable $NPPFILES. > > 1. is there an NPPFILES variable defined already? Something like > > NPPFILES=" > file_1 > file_2 > flie_3" > > 2. What you actually need to feed the "input=" parameter, is the "files" > term, not the "$NPPFILES". > > > > >> This is not working for me. I tried giving directory path, still no > > >> result. > > > ok, assuming you are running this from inside a GRASSy session, you > should be, at the time of executing the for loop, inside the directory > where the "list of files" is also present. I guess you created a file, > say "nppfiles_list". > > To be sure, just instruct > > cat nppfiles_list > > and expect to get the list of files you created. > > If that's ok, then it should work, e.g.: > > for File in `cat nppfiles_list`; do r.out.gdal input=${File} > output=${File}.tiff; done > > Note, instead of "File" it could be any other string you like. > > Hope this helps a bit. > > Nikos > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannesradinger at gmail.com Thu Sep 4 02:32:57 2014 From: johannesradinger at gmail.com (Johannes Radinger) Date: Thu, 4 Sep 2014 11:32:57 +0200 Subject: [GRASS-user] raster exchange between GRASS and R with nodata Message-ID: Hi, I want to export a raster map (FCELL) from GRASS70 to the geotiff format using r.out.gdal and to import it later on in R. The map contains many no data values. Here some details about the raster: Type of Map: raster Number of Categories: 0 Data Type: FCELL Rows: 750 Columns: 750 Total Cells: 562500 total null and non-null cells: 15105636 total null cells: 15105047 So when I export the map, r.out.gdal reports: "Input raster map contains cells with NULL-value (no-data). The value -nan will be used to represent no-data values in the input map. You can specify a nodata value with the nodata option." When I subsequently try to import the geotiff into R (using the package 'Raster') the nodata values are not recognised as NA's: a <- raster("*.tif") summary(a) Min. 0.5294496 1st Qu. 0.7171210 Median 0.7871540 3rd Qu. 1.1581826 Max. 1.5494517 NA's 0.0000000 So I am wondering if I need to set any specific parameter during the export (r.out.gdal) or import (raster()). As I am not only exporting FCELL (Float32) raster but also multiple (N=500) other rasters to R I would be interested in a solution also for DCELL (Float64). Of course I can export all of as Float64 as the file size should not be a problem. Any suggestions or experiences of handling NA's during raster exchange between GRASS and R? /Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From p.vanbreugel at gmail.com Thu Sep 4 04:46:08 2014 From: p.vanbreugel at gmail.com (Paulo van Breugel) Date: Thu, 4 Sep 2014 13:46:08 +0200 Subject: [GRASS-user] raster exchange between GRASS and R with nodata In-Reply-To: References: Message-ID: You probably have good reasons for your work flow, but just to make sure: is there a specific reason to export to geotiff first? It seems easier to import the raster layer directly from GRASS into R using the spgrass6 package (readRAST6)? You can subsequently convert the spatial raster to the raster format. On Thu, Sep 4, 2014 at 11:32 AM, Johannes Radinger < johannesradinger at gmail.com> wrote: > Hi, > > I want to export a raster map (FCELL) from GRASS70 to the geotiff format > using r.out.gdal and to import it later on in R. The map contains many no > data values. > > Here some details about the raster: > Type of Map: raster Number of Categories: 0 > Data Type: FCELL > Rows: 750 > Columns: 750 > Total Cells: 562500 > total null and non-null cells: 15105636 > total null cells: 15105047 > > So when I export the map, r.out.gdal reports: "Input raster map contains > cells with NULL-value (no-data). The value -nan will be used to represent > no-data values in the input map. You can specify a nodata value with the > nodata option." > > When I subsequently try to import the geotiff into R (using the package > 'Raster') the nodata values are not recognised as NA's: > > a <- raster("*.tif") > summary(a) > Min. 0.5294496 > 1st Qu. 0.7171210 > Median 0.7871540 > 3rd Qu. 1.1581826 > Max. 1.5494517 > NA's 0.0000000 > > So I am wondering if I need to set any specific parameter during the > export (r.out.gdal) or import (raster()). > > As I am not only exporting FCELL (Float32) raster but also multiple > (N=500) other rasters to R I would be interested in a solution also for > DCELL (Float64). Of course I can export all of as Float64 as the file size > should not be a problem. > > Any suggestions or experiences of handling NA's during raster exchange > between GRASS and R? > > /Johannes > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajat27404 at gmail.com Thu Sep 4 04:51:23 2014 From: rajat27404 at gmail.com (Rajat Nayak) Date: Thu, 4 Sep 2014 17:21:23 +0530 Subject: [GRASS-user] help with r.series Message-ID: Dear All, I have created a few list using g.mlist command in grass7. Each list has a few raster layers. For example; FILE2000 has lists of all monthly layers for the year 2000, FILE2001 has layers for 2001...so on. Now I want to create one layer each for each of these lists (each year). I can use "r.series" command with method="average", to get a layer with averaged values across all the months for a particular year. Now I have 14 such lists corresponding to 14 years and do not want to repeat the process for each year. Is there a way to automate this process using grass prompt? I don't want to move to R, would like to complete all the work in GRASS. Thank you Regards Rajat Nayak -------------- next part -------------- An HTML attachment was scrubbed... URL: From tea3rd at gmail.com Thu Sep 4 05:31:28 2014 From: tea3rd at gmail.com (Thomas Adams) Date: Thu, 4 Sep 2014 08:31:28 -0400 Subject: [GRASS-user] raster exchange between GRASS and R with nodata In-Reply-To: References: Message-ID: Johannes, If you want to read your file into R, there is no need to export your map from GRASS to do this. Simply install and use the R contributed package 'spgrass6' (spgrass6 has R dependencies that need to be installed first); it works wonderfully: Within GRASS, at the GRASS terminal prompt... > library(spgrass6) Loading required package: sp Loading required package: XML GRASS GIS interface loaded with GRASS version: GRASS 7.0.0beta3 (2014) and location: ohrfc_mpe > dat<-readRAST6("xmrg0101200306z") > image(dat) This is far more efficient. Tom On Thu, Sep 4, 2014 at 5:32 AM, Johannes Radinger < johannesradinger at gmail.com> wrote: > Hi, > > I want to export a raster map (FCELL) from GRASS70 to the geotiff format > using r.out.gdal and to import it later on in R. The map contains many no > data values. > > Here some details about the raster: > Type of Map: raster Number of Categories: 0 > Data Type: FCELL > Rows: 750 > Columns: 750 > Total Cells: 562500 > total null and non-null cells: 15105636 > total null cells: 15105047 > > So when I export the map, r.out.gdal reports: "Input raster map contains > cells with NULL-value (no-data). The value -nan will be used to represent > no-data values in the input map. You can specify a nodata value with the > nodata option." > > When I subsequently try to import the geotiff into R (using the package > 'Raster') the nodata values are not recognised as NA's: > > a <- raster("*.tif") > summary(a) > Min. 0.5294496 > 1st Qu. 0.7171210 > Median 0.7871540 > 3rd Qu. 1.1581826 > Max. 1.5494517 > NA's 0.0000000 > > So I am wondering if I need to set any specific parameter during the > export (r.out.gdal) or import (raster()). > > As I am not only exporting FCELL (Float32) raster but also multiple > (N=500) other rasters to R I would be interested in a solution also for > DCELL (Float64). Of course I can export all of as Float64 as the file size > should not be a problem. > > Any suggestions or experiences of handling NA's during raster exchange > between GRASS and R? > > /Johannes > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.zamb at gmail.com Thu Sep 4 05:35:42 2014 From: peter.zamb at gmail.com (Pietro) Date: Thu, 4 Sep 2014 14:35:42 +0200 Subject: [GRASS-user] help with r.series In-Reply-To: References: Message-ID: Hi Rajat, On Thu, Sep 4, 2014 at 1:51 PM, Rajat Nayak wrote: > I have created a few list using g.mlist command in grass7. Each list has a > few raster layers. For example; FILE2000 has lists of all monthly layers for > the year 2000, FILE2001 has layers for 2001...so on. > Now I want to create one layer each for each of these lists (each year). I > can use "r.series" command with method="average", to get a layer with > averaged values across all the months for a particular year. Now I have 14 > such lists corresponding to 14 years and do not want to repeat the process > for each year. Is there a way to automate this process using grass prompt? I > don't want to move to R, would like to complete all the work in GRASS. Yes you can do it, using BASH or python, personally I prefer/use python. A possible solution for grass6/7 could be something like: {{{ from grass import script # define the pattern to select the maps that will be aggregate PATTERNS = ('rast2001*', 'rast2002*', 'rast2003*') # etc. # define the name of the output names OUTPUTS = ('out2001', 'out2002', 'out2003') # start a cycle for each pattern and for each output for pattern, output in zip(PATTERNS, OUTPUTS): # get the list of input maps inputs = script.mlist_strings('rast', pattern=pattern) # run your command script.run_command('r.series', input=inputs, output=output, method='average') }}} From johannesradinger at gmail.com Thu Sep 4 06:27:28 2014 From: johannesradinger at gmail.com (Johannes Radinger) Date: Thu, 4 Sep 2014 15:27:28 +0200 Subject: [GRASS-user] raster exchange between GRASS and R with nodata In-Reply-To: References: Message-ID: Hi all, of course it is possible to load the raster maps directly via spgrass6. However, we use this work flow also to exchange some of the maps between different users (e.g. via email) and to permanently store single files (geotiffs that contain the proj information within the file). So, I agree that using spgrass6 would be much more efficient, but I'll stick to exporting to geotiffs and so I need to solve the issues with NA's. /Johannes On Thu, Sep 4, 2014 at 2:31 PM, Thomas Adams wrote: > Johannes, > > If you want to read your file into R, there is no need to export your map > from GRASS to do this. Simply install and use the R contributed package > 'spgrass6' (spgrass6 has R dependencies that need to be installed first); > it works wonderfully: > > Within GRASS, at the GRASS terminal prompt... > > > library(spgrass6) > Loading required package: sp > Loading required package: XML > GRASS GIS interface loaded with GRASS version: GRASS 7.0.0beta3 (2014) > and location: ohrfc_mpe > > dat<-readRAST6("xmrg0101200306z") > > image(dat) > > This is far more efficient. > > Tom > > > On Thu, Sep 4, 2014 at 5:32 AM, Johannes Radinger < > johannesradinger at gmail.com> wrote: > >> Hi, >> >> I want to export a raster map (FCELL) from GRASS70 to the geotiff format >> using r.out.gdal and to import it later on in R. The map contains many no >> data values. >> >> Here some details about the raster: >> Type of Map: raster Number of Categories: 0 >> Data Type: FCELL >> Rows: 750 >> Columns: 750 >> Total Cells: 562500 >> total null and non-null cells: 15105636 >> total null cells: 15105047 >> >> So when I export the map, r.out.gdal reports: "Input raster map contains >> cells with NULL-value (no-data). The value -nan will be used to represent >> no-data values in the input map. You can specify a nodata value with the >> nodata option." >> >> When I subsequently try to import the geotiff into R (using the package >> 'Raster') the nodata values are not recognised as NA's: >> >> a <- raster("*.tif") >> summary(a) >> Min. 0.5294496 >> 1st Qu. 0.7171210 >> Median 0.7871540 >> 3rd Qu. 1.1581826 >> Max. 1.5494517 >> NA's 0.0000000 >> >> So I am wondering if I need to set any specific parameter during the >> export (r.out.gdal) or import (raster()). >> >> As I am not only exporting FCELL (Float32) raster but also multiple >> (N=500) other rasters to R I would be interested in a solution also for >> DCELL (Float64). Of course I can export all of as Float64 as the file size >> should not be a problem. >> >> Any suggestions or experiences of handling NA's during raster exchange >> between GRASS and R? >> >> /Johannes >> >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nunocesardesa at gmail.com Thu Sep 4 06:38:26 2014 From: nunocesardesa at gmail.com (=?UTF-8?B?TnVubyBTw6E=?=) Date: Thu, 4 Sep 2014 14:38:26 +0100 Subject: [GRASS-user] raster exchange between GRASS and R with nodata In-Reply-To: References: Message-ID: Hello! Did you try this one? *r.out.gdal etc nodata*=*'NA'* On 4 September 2014 14:27, Johannes Radinger wrote: > Hi all, > > of course it is possible to load the raster maps directly via spgrass6. > However, we use this work > flow also to exchange some of the maps between different users (e.g. via > email) and to permanently > store single files (geotiffs that contain the proj information within the > file). So, I agree that using spgrass6 would be much more efficient, but > I'll stick to exporting to geotiffs and so I need to solve the issues with > NA's. > > /Johannes > > > On Thu, Sep 4, 2014 at 2:31 PM, Thomas Adams wrote: > >> Johannes, >> >> If you want to read your file into R, there is no need to export your map >> from GRASS to do this. Simply install and use the R contributed package >> 'spgrass6' (spgrass6 has R dependencies that need to be installed first); >> it works wonderfully: >> >> Within GRASS, at the GRASS terminal prompt... >> >> > library(spgrass6) >> Loading required package: sp >> Loading required package: XML >> GRASS GIS interface loaded with GRASS version: GRASS 7.0.0beta3 (2014) >> and location: ohrfc_mpe >> > dat<-readRAST6("xmrg0101200306z") >> > image(dat) >> >> This is far more efficient. >> >> Tom >> >> >> On Thu, Sep 4, 2014 at 5:32 AM, Johannes Radinger < >> johannesradinger at gmail.com> wrote: >> >>> Hi, >>> >>> I want to export a raster map (FCELL) from GRASS70 to the geotiff format >>> using r.out.gdal and to import it later on in R. The map contains many no >>> data values. >>> >>> Here some details about the raster: >>> Type of Map: raster Number of Categories: 0 >>> Data Type: FCELL >>> Rows: 750 >>> Columns: 750 >>> Total Cells: 562500 >>> total null and non-null cells: 15105636 >>> total null cells: 15105047 >>> >>> So when I export the map, r.out.gdal reports: "Input raster map contains >>> cells with NULL-value (no-data). The value -nan will be used to represent >>> no-data values in the input map. You can specify a nodata value with the >>> nodata option." >>> >>> When I subsequently try to import the geotiff into R (using the package >>> 'Raster') the nodata values are not recognised as NA's: >>> >>> a <- raster("*.tif") >>> summary(a) >>> Min. 0.5294496 >>> 1st Qu. 0.7171210 >>> Median 0.7871540 >>> 3rd Qu. 1.1581826 >>> Max. 1.5494517 >>> NA's 0.0000000 >>> >>> So I am wondering if I need to set any specific parameter during the >>> export (r.out.gdal) or import (raster()). >>> >>> As I am not only exporting FCELL (Float32) raster but also multiple >>> (N=500) other rasters to R I would be interested in a solution also for >>> DCELL (Float64). Of course I can export all of as Float64 as the file size >>> should not be a problem. >>> >>> Any suggestions or experiences of handling NA's during raster exchange >>> between GRASS and R? >>> >>> /Johannes >>> >>> _______________________________________________ >>> grass-user mailing list >>> grass-user at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> >> >> > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -- Nuno C?sar de S? +351 91 961 90 37 -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannesradinger at gmail.com Thu Sep 4 06:47:00 2014 From: johannesradinger at gmail.com (Johannes Radinger) Date: Thu, 4 Sep 2014 15:47:00 +0200 Subject: [GRASS-user] raster exchange between GRASS and R with nodata In-Reply-To: References: Message-ID: On Thu, Sep 4, 2014 at 3:38 PM, Nuno S? wrote: > Hello! > > Did you try this one? > > *r.out.gdal etc nodata*=*'NA'* > As mentioned in the manual of r.out.gdal, the no data parameter takes only float values and no strings like 'NA'. Without stating as specific value in GRASS, this nodata-value is automatically set to e.g. 65535 for DCELL rasters if I remember correctly and to 255 for BYTE rasters. However, this seems not to be recognized when imported into R with the package 'raster'. /Johannes > > > > On 4 September 2014 14:27, Johannes Radinger > wrote: > >> Hi all, >> >> of course it is possible to load the raster maps directly via spgrass6. >> However, we use this work >> flow also to exchange some of the maps between different users (e.g. via >> email) and to permanently >> store single files (geotiffs that contain the proj information within the >> file). So, I agree that using spgrass6 would be much more efficient, but >> I'll stick to exporting to geotiffs and so I need to solve the issues with >> NA's. >> >> /Johannes >> >> >> On Thu, Sep 4, 2014 at 2:31 PM, Thomas Adams wrote: >> >>> Johannes, >>> >>> If you want to read your file into R, there is no need to export your >>> map from GRASS to do this. Simply install and use the R contributed package >>> 'spgrass6' (spgrass6 has R dependencies that need to be installed first); >>> it works wonderfully: >>> >>> Within GRASS, at the GRASS terminal prompt... >>> >>> > library(spgrass6) >>> Loading required package: sp >>> Loading required package: XML >>> GRASS GIS interface loaded with GRASS version: GRASS 7.0.0beta3 (2014) >>> and location: ohrfc_mpe >>> > dat<-readRAST6("xmrg0101200306z") >>> > image(dat) >>> >>> This is far more efficient. >>> >>> Tom >>> >>> >>> On Thu, Sep 4, 2014 at 5:32 AM, Johannes Radinger < >>> johannesradinger at gmail.com> wrote: >>> >>>> Hi, >>>> >>>> I want to export a raster map (FCELL) from GRASS70 to the geotiff >>>> format using r.out.gdal and to import it later on in R. The map contains >>>> many no data values. >>>> >>>> Here some details about the raster: >>>> Type of Map: raster Number of Categories: 0 >>>> Data Type: FCELL >>>> Rows: 750 >>>> Columns: 750 >>>> Total Cells: 562500 >>>> total null and non-null cells: 15105636 >>>> total null cells: 15105047 >>>> >>>> So when I export the map, r.out.gdal reports: "Input raster map >>>> contains cells with NULL-value (no-data). The value -nan will be used to >>>> represent no-data values in the input map. You can specify a nodata value >>>> with the nodata option." >>>> >>>> When I subsequently try to import the geotiff into R (using the package >>>> 'Raster') the nodata values are not recognised as NA's: >>>> >>>> a <- raster("*.tif") >>>> summary(a) >>>> Min. 0.5294496 >>>> 1st Qu. 0.7171210 >>>> Median 0.7871540 >>>> 3rd Qu. 1.1581826 >>>> Max. 1.5494517 >>>> NA's 0.0000000 >>>> >>>> So I am wondering if I need to set any specific parameter during the >>>> export (r.out.gdal) or import (raster()). >>>> >>>> As I am not only exporting FCELL (Float32) raster but also multiple >>>> (N=500) other rasters to R I would be interested in a solution also for >>>> DCELL (Float64). Of course I can export all of as Float64 as the file size >>>> should not be a problem. >>>> >>>> Any suggestions or experiences of handling NA's during raster exchange >>>> between GRASS and R? >>>> >>>> /Johannes >>>> >>>> _______________________________________________ >>>> grass-user mailing list >>>> grass-user at lists.osgeo.org >>>> http://lists.osgeo.org/mailman/listinfo/grass-user >>>> >>> >>> >>> >>> >> >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > > -- > > Nuno C?sar de S? > +351 91 961 90 37 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nunocesardesa at gmail.com Thu Sep 4 06:52:55 2014 From: nunocesardesa at gmail.com (=?UTF-8?B?TnVubyBTw6E=?=) Date: Thu, 4 Sep 2014 14:52:55 +0100 Subject: [GRASS-user] raster exchange between GRASS and R with nodata In-Reply-To: References: Message-ID: Ok, didn't check that before since I didn't have the same problem before. Try exporting with a "crazy value" as NA such as in a 16bit unsigned r.out.gdal etc nodata=65535 Then on R use the mask function such as: mask(x, mask, filename="", inverse=FALSE, maskvalue=65535, updatevalue='NA', ...) might work but its very, you know, hurtful to see :P but I'm like you, I prefer .tif. On 4 September 2014 14:47, Johannes Radinger wrote: > > > > On Thu, Sep 4, 2014 at 3:38 PM, Nuno S? wrote: > >> Hello! >> >> Did you try this one? >> >> *r.out.gdal etc nodata*=*'NA'* >> > > As mentioned in the manual of r.out.gdal, the no data parameter takes only > float values > and no strings like 'NA'. Without stating as specific value in GRASS, this > nodata-value is > automatically set to e.g. 65535 for DCELL rasters if I remember correctly > and to 255 > for BYTE rasters. However, this seems not to be recognized when imported > into R with > the package 'raster'. > > /Johannes > > >> >> >> >> On 4 September 2014 14:27, Johannes Radinger >> wrote: >> >>> Hi all, >>> >>> of course it is possible to load the raster maps directly via spgrass6. >>> However, we use this work >>> flow also to exchange some of the maps between different users (e.g. via >>> email) and to permanently >>> store single files (geotiffs that contain the proj information within >>> the file). So, I agree that using spgrass6 would be much more efficient, >>> but I'll stick to exporting to geotiffs and so I need to solve the issues >>> with NA's. >>> >>> /Johannes >>> >>> >>> On Thu, Sep 4, 2014 at 2:31 PM, Thomas Adams wrote: >>> >>>> Johannes, >>>> >>>> If you want to read your file into R, there is no need to export your >>>> map from GRASS to do this. Simply install and use the R contributed package >>>> 'spgrass6' (spgrass6 has R dependencies that need to be installed first); >>>> it works wonderfully: >>>> >>>> Within GRASS, at the GRASS terminal prompt... >>>> >>>> > library(spgrass6) >>>> Loading required package: sp >>>> Loading required package: XML >>>> GRASS GIS interface loaded with GRASS version: GRASS 7.0.0beta3 (2014) >>>> and location: ohrfc_mpe >>>> > dat<-readRAST6("xmrg0101200306z") >>>> > image(dat) >>>> >>>> This is far more efficient. >>>> >>>> Tom >>>> >>>> >>>> On Thu, Sep 4, 2014 at 5:32 AM, Johannes Radinger < >>>> johannesradinger at gmail.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I want to export a raster map (FCELL) from GRASS70 to the geotiff >>>>> format using r.out.gdal and to import it later on in R. The map contains >>>>> many no data values. >>>>> >>>>> Here some details about the raster: >>>>> Type of Map: raster Number of Categories: 0 >>>>> Data Type: FCELL >>>>> Rows: 750 >>>>> Columns: 750 >>>>> Total Cells: 562500 >>>>> total null and non-null cells: 15105636 >>>>> total null cells: 15105047 >>>>> >>>>> So when I export the map, r.out.gdal reports: "Input raster map >>>>> contains cells with NULL-value (no-data). The value -nan will be used to >>>>> represent no-data values in the input map. You can specify a nodata value >>>>> with the nodata option." >>>>> >>>>> When I subsequently try to import the geotiff into R (using the >>>>> package 'Raster') the nodata values are not recognised as NA's: >>>>> >>>>> a <- raster("*.tif") >>>>> summary(a) >>>>> Min. 0.5294496 >>>>> 1st Qu. 0.7171210 >>>>> Median 0.7871540 >>>>> 3rd Qu. 1.1581826 >>>>> Max. 1.5494517 >>>>> NA's 0.0000000 >>>>> >>>>> So I am wondering if I need to set any specific parameter during the >>>>> export (r.out.gdal) or import (raster()). >>>>> >>>>> As I am not only exporting FCELL (Float32) raster but also multiple >>>>> (N=500) other rasters to R I would be interested in a solution also for >>>>> DCELL (Float64). Of course I can export all of as Float64 as the file size >>>>> should not be a problem. >>>>> >>>>> Any suggestions or experiences of handling NA's during raster exchange >>>>> between GRASS and R? >>>>> >>>>> /Johannes >>>>> >>>>> _______________________________________________ >>>>> grass-user mailing list >>>>> grass-user at lists.osgeo.org >>>>> http://lists.osgeo.org/mailman/listinfo/grass-user >>>>> >>>> >>>> >>>> >>>> >>> >>> _______________________________________________ >>> grass-user mailing list >>> grass-user at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> >> >> -- >> >> Nuno C?sar de S? >> +351 91 961 90 37 >> >> > -- Nuno C?sar de S? +351 91 961 90 37 -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Thu Sep 4 06:57:53 2014 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 4 Sep 2014 15:57:53 +0200 Subject: [GRASS-user] r.clump2 for GRASS7 In-Reply-To: References: Message-ID: On Wed, Sep 3, 2014 at 11:17 AM, Johannes Radinger wrote: > Hi, > > I am just wondering if the add-on r.clump2 is still available for GRASS 7. > I can find the add-on manual mentioned here: > http://grass.osgeo.org/grass70/manuals/addons/r.clump2.html ok, I have removed that page now because... > However I could not find r.clump2 via g.extension. ... the functionality of r.clump2 and been merged into the standard r.clump in GRASS 7. > I seems that the list > http://grass.osgeo.org/grass70/manuals/ is out of date (e.g. r.fidimo > add-on is missing). Good point. I'll speak to Martin Landa that we need to clean the directory and update it via cronjob. Markus From neteler at osgeo.org Thu Sep 4 07:41:14 2014 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 4 Sep 2014 16:41:14 +0200 Subject: [GRASS-user] GRASS GIS code sprint @FOSS4G 2014 - Portland: Sept 13th, 2014 Message-ID: Join us at the upcoming GRASS GIS code sprint @FOSS4G 2014, Portland http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Portland_2014 This Portland FOSS4G Code Sprint 2014 is a great occasion for folks to support the development by actively contributing to the source code, manuals or likewise. This code sprint is targeting members of OSGeo software projects. We will aim at getting close to the GRASS GIS 7.0.0 release, especially discussing how to resolve the remaining blocking issues. Please don't hesitate to add your suggestions here: http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Portland_2014#Ideas From christophe0joey at gmail.com Thu Sep 4 07:56:53 2014 From: christophe0joey at gmail.com (christophe joey) Date: Thu, 4 Sep 2014 14:56:53 +0000 Subject: [GRASS-user] rasterize vector layer (string column) Message-ID: hello i would like to rasterize a vector layer i guess within: *v.to.rast* but the type of the column to use in the rasterization is string not numeric *.* is it possible to do it in grass 6.4 ? *thank you* -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Thu Sep 4 12:00:50 2014 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 4 Sep 2014 21:00:50 +0200 Subject: [GRASS-user] rasterize vector layer (string column) In-Reply-To: References: Message-ID: On Thu, Sep 4, 2014 at 4:56 PM, christophe joey wrote: > hello > > i would like to rasterize a vector layer i guess within: v.to.rast > but the type of the column to use in the rasterization is string not > numeric. > > is it possible to do it in grass 6.4 ? Yes. - use v.db.addcol to add a new numeric column - then cast the string numbers to numeric with v.db.update: http://grass.osgeo.org/grass64/manuals/v.db.update.html --> see last example (that's for the SQLite or other true SQL drivers only, not the DBF backend) Markus From glynn at gclements.plus.com Thu Sep 4 13:41:39 2014 From: glynn at gclements.plus.com (Glynn Clements) Date: Thu, 4 Sep 2014 21:41:39 +0100 Subject: [GRASS-user] help with r.series In-Reply-To: References: Message-ID: <21512.52867.70545.922121@cerise.gclements.plus.com> Rajat Nayak wrote: > I have created a few list using g.mlist command in grass7. Each list has a > few raster layers. For example; FILE2000 has lists of all monthly layers > for the year 2000, FILE2001 has layers for 2001...so on. > Now I want to create one layer each for each of these lists (each year). I > can use "r.series" command with method="average", to get a layer with > averaged values across all the months for a particular year. Now I have 14 > such lists corresponding to 14 years and do not want to repeat the process > for each year. Is there a way to automate this process using grass prompt? > I don't want to move to R, would like to complete all the work in GRASS. bash: for file in FILE20?? ; do r.series file=$file output=output${file#file} method=average done Python: import os import grass.script as grass for file in os.listdir('.'): if not file.startswith('FILE20'): continue output = 'output' + file[4:] grass.run_command('r.series', file=file, output=output, method='average') -- Glynn Clements From roberto.marzocchi at gmail.com Fri Sep 5 02:46:28 2014 From: roberto.marzocchi at gmail.com (Roberto Marzocchi) Date: Fri, 5 Sep 2014 11:46:28 +0200 Subject: [GRASS-user] r.regression.multi for logistic regression - it is possible? Message-ID: Dear all, I have dichotomous data (occurrence 1 and non-occurence 0) and I want to use the logistic regression method in order to obtain susceptibility map of landslide occurrence. I try to use r.regression.multi, but I am not sure to correctly define the mapy variable.. I try to use r.mapcalc *r.mapcalc expression="logit_occurrence=log(occurrence_map+0.00001)-log(1-occurrence_map+0.00001)"* obtaining a map that go from -11.5 (not occurrence) to +11.5 (occurrence) when I try to use r.regression.multi I obtain a lot of null values in residuals and estimates map. i do not understand why.. Thanks in advanced for the attention Roberto -------------- parte successiva -------------- Un allegato HTML ? stato rimosso... URL: From nunocesardesa at gmail.com Fri Sep 5 03:11:42 2014 From: nunocesardesa at gmail.com (=?UTF-8?B?TnVubyBTw6E=?=) Date: Fri, 5 Sep 2014 11:11:42 +0100 Subject: [GRASS-user] r.regression.multi for logistic regression - it is possible? In-Reply-To: References: Message-ID: Hey Roberto! Never done it in Grass but its a typical operation. For me it seems a bit confusing with for me since you are not showing me a glm fitting but instead just using the occurrence map in the logistic link function. What you need to do is to fit a GLM to the binary data you have, something you can do in R for example check here: http://www.statmethods.net/advstats/glm.html Then you will build your output in grass using the r.mapcalc: F(x) = 1 / ( 1+ e^(-GLM) (That will be your probability map). But, you can actually do everything using R only, no need to come into grass but you can if you want. Good luck! Ciao! On 5 September 2014 10:46, Roberto Marzocchi wrote: > Dear all, > > I have dichotomous data (occurrence 1 and non-occurence 0) and I want to > use the logistic regression method in order to obtain susceptibility map > of landslide occurrence. > > I try to use r.regression.multi, but I am not sure to correctly define the > mapy variable.. > > I try to use r.mapcalc > > *r.mapcalc > expression="logit_occurrence=log(occurrence_map+0.00001)-log(1-occurrence_map+0.00001)"* > > obtaining a map that go from -11.5 (not occurrence) to +11.5 (occurrence) > > when I try to use r.regression.multi I obtain a lot of null values in > residuals and estimates map. > > i do not understand why.. > > Thanks in advanced for the attention > Roberto > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -- Nuno C?sar de S? +351 91 961 90 37 -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Fri Sep 5 04:38:17 2014 From: neteler at osgeo.org (Markus Neteler) Date: Fri, 5 Sep 2014 13:38:17 +0200 Subject: [GRASS-user] r.clump2 for GRASS7 In-Reply-To: References: Message-ID: On Thu, Sep 4, 2014 at 3:57 PM, Markus Neteler wrote: > On Wed, Sep 3, 2014 at 11:17 AM, Johannes Radinger ... >> I seems that the list >> http://grass.osgeo.org/grass70/manuals/ is out of date (e.g. r.fidimo >> add-on is missing). > > Good point. I'll speak to Martin Landa that we need to clean the > directory and update it via cronjob. Martin has fixed that now, the pages get updated again. Note: the fact that r.fidimo is missing is stated here: http://grass.osgeo.org/download/addons/ -> logs -> http://grass.osgeo.org/addons/grass7/logs/r.fidimo.log I have now installed the missing python module on the server. At the next round it should go through. If not, let me know. Markus From luis.miguel.royo at gmail.com Fri Sep 5 05:26:30 2014 From: luis.miguel.royo at gmail.com (=?UTF-8?B?THVpcyBNaWd1ZWwgUm95byBQw6lyZXo=?=) Date: Fri, 05 Sep 2014 14:26:30 +0200 Subject: [GRASS-user] r.walk doubt Message-ID: <5409ABF6.5010106@gmail.com> Hi everyone, I have some doubts with the generation of a cost surface with /r.walk/ . It's assumed that the resulting layer is measured in seconds, but when I try to convert seconds in days march (6h per day), the resulting layer has no sense. This is the workflow I'm following: *1st.-* I have several vector layers as roads, rivers, bridges, and a raster layer of elevation. *2nd.-* Rasterize the vector layers with a field named "weight" (PESO in spanish) where I have weighted this variables according to if they facilitate the walking or not. Reclassify is made if it's needed. *3rd.-* Find Slope (in percent) layer and reclasify as follow: * 0-10=1; * 11-maxValue=100 *4th.-* r.cross with all the rasterized layer. (roads, bridge, river and reclassified slope). *5th.-* I create a new friction layer using this formula proposed by Pandolf (1977) with /r.mapcalc/ : |M=1.5W+2.0(W+L)(L/W)^2+"CrossedLayer"*(W+L)(1.5V^2+0.35V*abs("SlopeLayer"+10)) | *6th.-* With this layer measured in Watts I use /r.walk/ with default parameters. *7th.-* Once obtained this layer measured in seconds I try to convert it in hours dividing 3600 and then convert these hours in days march dividing 6 (6 hours per day). Well, the results are not what I expected, the max data of this layer is about 8.000... No sense, it should be something like 3 or 4 days, maybe. */Here are the files I'm using to do this workflow./* I don't know what I'm missing, maybe is the 4th step wrong? Maybe the 5th? Another point of view would be nice to me. If you need more info, please ask for it and I will add to the question. Thank you very much to everyone. Thanks a lot! ------------ pr?xima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From christophe0joey at gmail.com Fri Sep 5 06:00:21 2014 From: christophe0joey at gmail.com (christophe joey) Date: Fri, 5 Sep 2014 13:00:21 +0000 Subject: [GRASS-user] rasterize vector layer (string column) In-Reply-To: References: Message-ID: thank you markus for the reply well, in vector layer i don't have a field containing numbers in string field, here is my attribute table: objectID Type 1 A 2 A 3 B 4 A 5 C so, i have to rasterize it using the type field wich is not numeric. How can i do it ? thank you On Thu, Sep 4, 2014 at 7:00 PM, Markus Neteler wrote: > On Thu, Sep 4, 2014 at 4:56 PM, christophe joey > wrote: > > hello > > > > i would like to rasterize a vector layer i guess within: v.to.rast > > but the type of the column to use in the rasterization is string not > > numeric. > > > > is it possible to do it in grass 6.4 ? > > Yes. > - use v.db.addcol to add a new numeric column > - then cast the string numbers to numeric with v.db.update: > http://grass.osgeo.org/grass64/manuals/v.db.update.html > --> see last example (that's for the SQLite or other true SQL > drivers only, not the DBF backend) > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hellik at web.de Fri Sep 5 11:37:23 2014 From: hellik at web.de (Helmut Kudrnovsky) Date: Fri, 5 Sep 2014 11:37:23 -0700 (PDT) Subject: [GRASS-user] rasterize vector layer (string column) In-Reply-To: References: Message-ID: <1409942243740-5160418.post@n6.nabble.com> christophe wrote > thank you markus for the reply > > well, in vector layer i don't have a field containing numbers in string > field, here is my attribute table: > > objectID Type > 1 A > 2 A > 3 B > 4 A > 5 C > > > so, i have to rasterize it using the type field wich is not numeric. > How can i do it ? > > thank you something like this should do it: - use v.db.addcol to add a new numeric column (e.g. column name: typenumeric) - use v.db.update with WHERE conditions to 'translate' e.g. all A to 1, all B to 2 and so on (e.g. v.db.update map=yourvectordata column=typenumeric value=1 where="Type = A", v.db.update map=yourvectordata column=typenumeric value=2 where="Type = B", etc.) - use v.to.rast to rasterize the vector and label your raster map with the type information (e.g. v.to.rast input=yourvectordata column=typenumeric labelcolumn=Type) ----- best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/rasterize-vector-layer-string-column-tp5160150p5160418.html Sent from the Grass - Users mailing list archive at Nabble.com. From christophe0joey at gmail.com Fri Sep 5 15:01:07 2014 From: christophe0joey at gmail.com (christophe joey) Date: Fri, 5 Sep 2014 22:01:07 +0000 Subject: [GRASS-user] rastization failed : can't allocate memory Message-ID: hello i'm trying to rasterize my vector layer but i got this error for all of my vectors : v.to.rast input=pedo at mapset output=pedorast use=attr column=valeur labelcolumn=SOL Loading data... R?gion actuelle 51365 lignes, 56484 colonnes ERROR: G_calloc: impossible d'allouer 231358464 * 1 octets de m?moire ? raster.c:79 (Fri Sep 05 22:51:55 2014) La commande s'est termin?e (0 sec) thanks From daniel.victoria at gmail.com Fri Sep 5 15:38:39 2014 From: daniel.victoria at gmail.com (Daniel Victoria) Date: Fri, 5 Sep 2014 19:38:39 -0300 Subject: [GRASS-user] rastization failed : can't allocate memory In-Reply-To: References: Message-ID: Check your region resolution. It's probably too high and so gives you lots of row and cols On Sep 5, 2014 7:01 PM, "christophe joey" wrote: > hello > > > i'm trying to rasterize my vector layer but i got this error for all > of my vectors : > > v.to.rast input=pedo at mapset output=pedorast use=attr column=valeur > labelcolumn=SOL > Loading data... > R?gion actuelle 51365 lignes, 56484 colonnes > ERROR: G_calloc: impossible d'allouer 231358464 * 1 octets de m?moire > ? raster.c:79 > (Fri Sep 05 22:51:55 2014) La commande s'est termin?e (0 sec) > > thanks > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe0joey at gmail.com Fri Sep 5 16:50:44 2014 From: christophe0joey at gmail.com (christophe joey) Date: Fri, 5 Sep 2014 23:50:44 +0000 Subject: [GRASS-user] rastization failed : can't allocate memory In-Reply-To: References: Message-ID: thank you daniel victoria. in the options i had by default rows = 4000 so i reduce it. thanks On Fri, Sep 5, 2014 at 10:38 PM, Daniel Victoria wrote: > Check your region resolution. It's probably too high and so gives you lots > of row and cols > On Sep 5, 2014 7:01 PM, "christophe joey" > wrote: > >> hello >> >> >> i'm trying to rasterize my vector layer but i got this error for all >> of my vectors : >> >> v.to.rast input=pedo at mapset output=pedorast use=attr column=valeur >> labelcolumn=SOL >> Loading data... >> R?gion actuelle 51365 lignes, 56484 colonnes >> ERROR: G_calloc: impossible d'allouer 231358464 * 1 octets de m?moire >> ? raster.c:79 >> (Fri Sep 05 22:51:55 2014) La commande s'est termin?e (0 sec) >> >> thanks >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Fri Sep 5 18:16:50 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sat, 6 Sep 2014 03:16:50 +0200 Subject: [GRASS-user] rasterize vector layer (string column) In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 3:00 PM, christophe joey wrote: > thank you markus for the reply > > well, in vector layer i don't have a field containing numbers in string > field, here is my attribute table: > > objectID Type > 1 A > 2 A > 3 B > 4 A > 5 C > > > so, i have to rasterize it using the type field wich is not numeric. > How can i do it ? You can either do it as Helmut suggested or take a look at Example 3 http://grass.osgeo.org/grass70/manuals/v.to.rast.html#examples 3. Convert a vector polygon map to raster including descriptive labels Markus From neteler at osgeo.org Fri Sep 5 19:10:29 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sat, 6 Sep 2014 04:10:29 +0200 Subject: [GRASS-user] rastization failed : can't allocate memory In-Reply-To: References: Message-ID: On Sat, Sep 6, 2014 at 1:50 AM, christophe joey wrote: > thank you daniel victoria. > in the options i had by default rows = 4000 so i reduce it. I think we should develop some "magic" to better decide how many rows are processed in v.to.rast in parallel. Suggestions? It also affects v.rast.stats which internally calls v.to.rast. Markus From neteler at osgeo.org Fri Sep 5 20:15:16 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sat, 6 Sep 2014 05:15:16 +0200 Subject: [GRASS-user] execGRASS("r.diversity") Done. No rasters created (Large rasters) In-Reply-To: References: Message-ID: Dear Sandra, On Fri, Jun 20, 2014 at 7:49 AM, Markus Neteler wrote: > On Sat, Jun 14, 2014 at 9:21 AM, Sandra MacFadyen wrote: >> I am using r.diversity (GRASS GIS 7.0.0svn build 60785 win32) through R >> (R version 3.0.2 win32) on Windows 7 64bit. ... >> However, when running the same code on a larger image (cells=6746328) from my >> own location, although it reports Done, no rasters are created. If I subset the image >> (cells=1632830) and run it again its works (see # sub2Kruger # code and results below). >> So I'm guessing it is a memory issue? ... > ... it consumes a lot of memory... will check on a bigger machine, > perhaps a memory leak. The assumption turned out to be right and I think we got it today! Vaclav Petras checked it and discovered an "unfortunate" memory allocation which he fixed in r.li.* in revision http://trac.osgeo.org/grass/changeset/61812 ("r.li: fix memory handling (memory leak in avl_to_array function))". Now r.li has become very fast, on my laptop: GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 res=10 -a ... rows: 1355 cols: 1503 cells: 2036565 GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 output=lsat5_1987_div__simpson_size_5.0 r.li.simpson complete. Raster map created. --> 29.32 seconds or with a simulated higher resolution: GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 res=5 -aprojection: 99 (Lambert Conformal Conic) ... rows: 2708 cols: 3005 cells: 8137540 GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 output=lsat5_1987_div__simpson_size_5.0 r.li.simpson complete. Raster map created. --> 227.37 seconds (used to be > 2 hours) So, to grab this improvement for Windows, grab the version from here: http://wingrass.fsv.cvut.cz/grass71/ (or via OSGeo4W installer). Be sure that the revision is at least r61812 which is indicated in the file name. Please let us know if all works to avoid that the change has any negative impact. Tests here did not show any changes in the output except for the speed improvement and solved memory leak. Subsequently also r.diversity should behave now. I'll backport it to GRASS 7.0 release branch after some testing. Markus From daniel.victoria at gmail.com Sat Sep 6 03:32:45 2014 From: daniel.victoria at gmail.com (Daniel Victoria) Date: Sat, 6 Sep 2014 07:32:45 -0300 Subject: [GRASS-user] rastization failed : can't allocate memory In-Reply-To: References: Message-ID: Maybe, instead of throwing a memory error, grass could check the region size and if the number of cells is too high, ask for user confirmation or suggest how the user can change the region. On Sep 5, 2014 11:10 PM, "Markus Neteler" wrote: > On Sat, Sep 6, 2014 at 1:50 AM, christophe joey > wrote: > > thank you daniel victoria. > > in the options i had by default rows = 4000 so i reduce it. > > I think we should develop some "magic" to better decide how many rows > are processed in v.to.rast in parallel. > Suggestions? > > It also affects v.rast.stats which internally calls v.to.rast. > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Sat Sep 6 09:24:44 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sat, 6 Sep 2014 18:24:44 +0200 Subject: [GRASS-user] rastization failed : can't allocate memory In-Reply-To: References: Message-ID: On Sat, Sep 6, 2014 at 12:32 PM, Daniel Victoria wrote: > Maybe, instead of throwing a memory error, grass could check the region size > and if the number of cells is too high, ask for user confirmation or suggest > how the user can change the region. I have for now added a message: # test case: GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region vect=zipcodes_wake res=5 -pa projection: 99 (Lambert Conformal Conic) zone: 0 datum: nad83 ellipsoid: a=6378137 es=0.006694380022900787 north: 258110 south: 196320 west: 610040 east: 677070 nsres: 5 ewres: 5 rows: 12358 cols: 13406 cells: 165671348 # new message about RAM added: GRASS 7.1.svn (nc_spm_08_grass7):~ > v.to.rast zipcodes_wake out=zipcodes_wake_area use=attr attrcol=SHAPE_Area --o Using at least 0.4 GB of RAM (adjust with 'rows' parameter) Pass 1 of 4: Reading areas... [...] # other test case: GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region vect=zipcodes_wake res=1 -pa projection: 99 (Lambert Conformal Conic) ... rows: 61780 cols: 67020 cells: 4140495600 GRASS 7.1.svn (nc_spm_08_grass7):~ > v.to.rast zipcodes_wake out=zipcodes_wake_area use=attr attrcol=SHAPE_Area --o rows=10000 Using at least 4.6 GB of RAM (adjust with 'rows' parameter) ... Is that new message understandable? Markus From fotios.xystrakis at gmail.com Sat Sep 6 14:21:55 2014 From: fotios.xystrakis at gmail.com (fotios.xystrakis) Date: Sat, 6 Sep 2014 14:21:55 -0700 (PDT) Subject: [GRASS-user] Problem with Python GUI Grass 6 In-Reply-To: References: <764F6510771B904AB16F5AF94EAB7DBE1A01173B@ITSMBX-3.lunet.lboro.ac.uk> Message-ID: <1410038515916-5160560.post@n6.nabble.com> Daer list members. I am also facing the same problem (when trying to display a vector file, there is no drop-down list, an empy layer appears), yet I do not receive any erro message. Some trivial analyses I have tried (v.overlay) seem to work normaly + i have acces to my mapset via QGIS Grass toolbox from where I can view my files normaly. I am running windows 7 professional 64x I have installed GRASS via OSGEO4w set up and I haven't installed any other GIS application besides Quantum and SAGA GIS (also installed vis OSGEO4W setup). Actually was among he first software to be installed after windows... *sorry in advanced if I am not posting in the correct place. thank you in advance, Fotis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Problem-with-Python-GUI-Grass-6-tp5100874p5160560.html Sent from the Grass - Users mailing list archive at Nabble.com. From neteler at osgeo.org Sat Sep 6 15:50:52 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sun, 7 Sep 2014 00:50:52 +0200 Subject: [GRASS-user] Suggested workflow for Importing DXF Wind Turbines onto Map in Grass 6.4.4 In-Reply-To: References: Message-ID: On Wed, Jul 30, 2014 at 10:57 PM, Paul Shapley wrote: > Hi, > > I have imported a single wind turbine (dxf) into grass with v.in.dxf > successfully. I need to position it on a map but do not know where to start. > > From the grasswiki pages it says it is best to use XY location Not sure - better import it into your real world location and then shift it around therein. > but how do > you assign known location co-ordinates to the base of a wind turbine > (without a copy of AutoCAD). I would also need to add many more wind > turbines onto the same map.Do i need to use v.proj/v.transform/v.rectify? Say, you have a UTM location, import it into it with v.in.dxf. Then get it into the right position with v.transform (scale x, y, and z). > I might also need to set the height of the turbine but again not sure which > is the best action. The z scale of v.transform will do that. I got the water tower in http://grasswiki.osgeo.org/wiki/Help_with_3D#Vector_3D_polygons like that into the right position. Sorry for the late answer, Markus From landa.martin at gmail.com Sun Sep 7 04:31:13 2014 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 7 Sep 2014 13:31:13 +0200 Subject: [GRASS-user] r.clump2 for GRASS7 In-Reply-To: References: Message-ID: Hi, 2014-09-05 13:38 GMT+02:00 Markus Neteler : > -> logs > -> http://grass.osgeo.org/addons/grass7/logs/r.fidimo.log > I have now installed the missing python module on the server. > At the next round it should go through. If not, let me know. I have installed python-scipy on the server, the next should be OK. Let me know in the case of problems. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From landa.martin at gmail.com Sun Sep 7 04:32:47 2014 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 7 Sep 2014 13:32:47 +0200 Subject: [GRASS-user] r.clump2 for GRASS7 In-Reply-To: References: Message-ID: 2014-09-07 13:31 GMT+02:00 Martin Landa : > I have installed python-scipy on the server, the next should be OK. > Let me know in the case of problems. Martin see also logs overview for G7 [1] and G6 [2]. Martin [1] http://grass.osgeo.org/addons/grass7/logs/ [2] http://grass.osgeo.org/addons/grass6/logs/ -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From landa.martin at gmail.com Sun Sep 7 04:34:04 2014 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 7 Sep 2014 13:34:04 +0200 Subject: [GRASS-user] r.clump2 for GRASS7 In-Reply-To: References: Message-ID: 2014-09-07 13:32 GMT+02:00 Martin Landa : > [2] http://grass.osgeo.org/addons/grass6/logs/ ah, G6 is completely broken. I will fix it. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From landa.martin at gmail.com Sun Sep 7 05:58:29 2014 From: landa.martin at gmail.com (Martin Landa) Date: Sun, 7 Sep 2014 14:58:29 +0200 Subject: [GRASS-user] r.clump2 for GRASS7 In-Reply-To: References: Message-ID: Hi, 2014-09-07 13:34 GMT+02:00 Martin Landa : >> [2] http://grass.osgeo.org/addons/grass6/logs/ > > ah, G6 is completely broken. I will fix it. Martin fixed. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From ttessier at solaradata.com Mon Sep 8 01:37:20 2014 From: ttessier at solaradata.com (ttessier at solaradata.com) Date: Mon, 8 Sep 2014 03:37:20 -0500 (CDT) Subject: [GRASS-user] r.horizon: gives only elevations of 0 in all directions using Grass demo data Message-ID: <51828.50.71.10.253.1410165440.squirrel@mail.solaradata.com> Hello, Using Grass 6.4.4 on Windows 7 on one computer and on Windows XP on another computer, we are only getting elevations to the horizon of 0.00000,-0.000000 at all angles. We are using the elevation models included in the demonstration sites for North Carolina and South Dakota. Tried many combinations of input and always receive the zeros as the answer. In one case, I tried putting in the same input as in the manual page for r.horizon: r.horizon elevin=elevation direction=215 horizonstep=0 bufferzone=200 coord=638871.6,223384.4 Still produces zeros. Any ideas? Thanks, -Tom From daniel.victoria at gmail.com Mon Sep 8 08:17:01 2014 From: daniel.victoria at gmail.com (Daniel Victoria) Date: Mon, 8 Sep 2014 12:17:01 -0300 Subject: [GRASS-user] rastization failed : can't allocate memory In-Reply-To: References: Message-ID: I never realized there was a rows parameter. oops The message is understandable but I was thinking more in terms of the users who have set the resolution too high without realizing, or using wrong setting in the beginning. So maybe, add: adjust 'rows' parameter or check region resoluiton with g.region On Sat, Sep 6, 2014 at 1:24 PM, Markus Neteler wrote: > On Sat, Sep 6, 2014 at 12:32 PM, Daniel Victoria > wrote: > > Maybe, instead of throwing a memory error, grass could check the region > size > > and if the number of cells is too high, ask for user confirmation or > suggest > > how the user can change the region. > > I have for now added a message: > > # test case: > GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region vect=zipcodes_wake res=5 -pa > projection: 99 (Lambert Conformal Conic) > zone: 0 > datum: nad83 > ellipsoid: a=6378137 es=0.006694380022900787 > north: 258110 > south: 196320 > west: 610040 > east: 677070 > nsres: 5 > ewres: 5 > rows: 12358 > cols: 13406 > cells: 165671348 > > # new message about RAM added: > GRASS 7.1.svn (nc_spm_08_grass7):~ > v.to.rast zipcodes_wake > out=zipcodes_wake_area use=attr attrcol=SHAPE_Area --o > Using at least 0.4 GB of RAM (adjust with 'rows' parameter) > Pass 1 of 4: > Reading areas... > [...] > > > > # other test case: > GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region vect=zipcodes_wake res=1 -pa > projection: 99 (Lambert Conformal Conic) > ... > rows: 61780 > cols: 67020 > cells: 4140495600 > > GRASS 7.1.svn (nc_spm_08_grass7):~ > v.to.rast zipcodes_wake > out=zipcodes_wake_area use=attr attrcol=SHAPE_Area --o rows=10000 > Using at least 4.6 GB of RAM (adjust with 'rows' parameter) > ... > > Is that new message understandable? > > Markus > -------------- next part -------------- An HTML attachment was scrubbed... URL: From misc2345 at outlook.com Mon Sep 8 13:48:01 2014 From: misc2345 at outlook.com (Joseph Bailey) Date: Mon, 8 Sep 2014 21:48:01 +0100 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 Message-ID: Hi all, I am really struggling to to use the r.geomorphon (or indeed any) add-on in GRASS 7 (it's not available in 6) and I have spent a great many hours trying to get this working before seeking advice here. Any help would be hugely appreciated. I really am a GRASS novice so I may well have missed something obvious, despite trying to be thorough. This is also my first post here so I hope it's up to scratch. First, system Info: GRASS version: 7.0.0beta3 GRASS SVN Revision: 61541 Build Date: 2014-09-08 Build Platform: x86_64-unknown-linux-gnu GDAL/OGR: 1.11.0 PROJ.4: 4.8.0 GEOS: 3.4.2 SQLite: 3.8.2 Python: 2.7.6 wxPython: 2.8.12.1 Platform: Linux-3.13.0-35-generic-x86_64-with-Ubuntu-14.04-trusty How I got to this stage:As you can see from System Info, I compiled GRASS GIS 7.0.0beta3 from source code via "svn checkout http://svn.osgeo.org/grass/grass/tags/release_20140806_grass_7_0_0beta3", but I had also tried it via "svn co https://svn.osgeo.org/grass/grass/trunk" before, with the same negative result. I cannot use the stable version of GRASS GIS 7 (I tried that first) because of the issue with g.extension, which is fixed in these later versions (see http://lists.osgeo.org/pipermail/grass-user/2014-June/070480.html). I've compiled and installed GRASS 7 using the instructions from the OSGeo Ubuntu Wiki page (http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu#GRASS_GIS) and have been sure run the commands under 'Dependencies'. A post on this issue appears here - http://lists.osgeo.org/pipermail/grass-user/2013-February/067241.html The compilation set-up that I've used is as follows (this does not produce any errors):CFLAGS="-O2 -Wall" LDFLAGS="-s" ./configure \--enable-largefile=yes \--with-nls \--with-cxx \--with-python=yes \--with-wxwidgets \--with-cairo \--with-freetype=yes \--with-freetype-includes="/usr/include/freetype2/" \--with-opengl-libs=/usr/include/GL \--with-postgres=yes \--with-postgres-includes="/usr/include/postgresql" \--with-sqlite=yes \--with-mysql=yes \--with-mysql-includes="/usr/include/mysql" \--with-odbc=no \--with-geos=yes And here's the summary once compiled (does anything stand out as being missing?): BLAS support: no C++ support: yes Cairo support: yes DWG support: no FFMPEG support: no FFTW support: yes FreeType support: yes GDAL support: yes GEOS support: yes LAPACK support: no Large File support (LFS): yes libLAS support: no MySQL support: yes NetCDF support: no NLS support: yes ODBC support: yes OGR support: yes OpenCL support: no OpenGL support: yes OpenMP support: no PNG support: yes POSIX thread support: no PostgreSQL support: yes Readline support: no Regex support: yes SQLite support: yes TIFF support: yes wxWidgets support: yes X11 support: yes Finally, here's the output upon attempting to install r.geomorphon via g.extension (g.extension extension=r.geomorphon svnurl=http://svn.osgeo.org/grass/grass-addons/grass7). I've also put another couple of error-filled outputs from other add-ons below. Many thanks in advance, Joe g.extension extension=r.geomorphon svnurl=http://svn.osgeo.org/grass/grass-addons/grass7Fetching from GRASS-Addons SVN (be patient)...Compiling...geom.c: In function ?ternary_rotate?:geom.c:22:9: warning: unused variable ?res? [-Wunused-variable] int res; ^geom.c: At top level:geom.c:2:15: warning: ?dirs? defined but not used[-Wunused-variable] static double dirs[8] = { 0.7854, 0., 5.4978, 4.7124,3.9270, 3.1416, 2.3562, 1.5708 }; /* radians */ ^geom.c: In function ?shape?:geom.c:252:26: warning: ?rymax? may be useduninitialized in this function [-Wmaybe-uninitialized] rymax = ry > rymax ? ry : rymax; ^geom.c:251:26: warning: ?rymin? may be useduninitialized in this function [-Wmaybe-uninitialized] rymin = ry < rymin ? ry : rymin; ^geom.c:250:26: warning: ?rxmax? may be useduninitialized in this function [-Wmaybe-uninitialized] rxmax = rx > rxmax ? rx : rxmax; ^geom.c:249:26: warning: ?rxmin? may be useduninitialized in this function [-Wmaybe-uninitialized] rxmin = rx < rxmin ? rx : rxmin; ^geom.c:232:15: warning: ?avg_x_square? may be useduninitialized in this function [-Wmaybe-uninitialized] avg_x_square += pattern->x[i] * pattern->x[i]; ^main.c: In function ?main?:main.c:312:20: warning: unused variable ?formC?[-Wunused-variable] int formA, formB, formC; ^main.c:312:13: warning: unused variable ?formB?[-Wunused-variable] int formA, formB, formC; ^main.c:312:6: warning: unused variable ?formA?[-Wunused-variable] int formA, formB, formC; ^main.c:93:28: warning: unused variable ?radius?[-Wunused-variable] int row, cur_row, col, radius; ^main.c:91:15: warning: unused variable ?n? [-Wunused-variable] int i, j, n; ^main.c:91:12: warning: unused variable ?j? [-Wunused-variable] int i, j, n; ^main.c:553:1: warning: control reaches end of non-voidfunction [-Wreturn-type] } ^memory.c: In function ?open_map?:memory.c:10:9: warning: unused variable ?bufsize?[-Wunused-variable] int bufsize; ^memory.c:7:9: warning: unused variable ?fd? [-Wunused-variable] int fd; ^memory.c: In function ?shift_buffers?:memory.c:75:39: warning: unused variable ?aspect_tmp?[-Wunused-variable] FCELL *tmp_elev_buf, *slope_tmp, *aspect_tmp; ^memory.c:75:27: warning: unused variable ?slope_tmp?[-Wunused-variable] FCELL *tmp_elev_buf, *slope_tmp, *aspect_tmp; ^memory.c: In function ?write_contrast_colors?:memory.c:131:23: warning: unused variable ?cats?[-Wunused-variable] struct Categories cats; ^multires.c: In function ?pattern_matching?:multires.c:23:29: warning: suggest parentheses aroundcomparison in operand of ?&? [-Wparentheses] return (result & source == source) ? 1 : 0; ^pattern.c: In function ?calc_pattern?:pattern.c:134:24: warning: ?nadir_distance? may be useduninitialized in this function [-Wmaybe-uninitialized] pattern->distance[i] = nadir_distance; ^pattern.c:128:24: warning: ?zenith_distance? may be useduninitialized in this function [-Wmaybe-uninitialized] pattern->distance[i] = zenith_distance; ^pattern.c:133:25: warning: ?nadir_height? may be useduninitialized in this function [-Wmaybe-uninitialized] pattern->elevation[i] = nadir_height; //ZMIANA! ^pattern.c:127:25: warning: ?zenith_height? may be useduninitialized in this function [-Wmaybe-uninitialized] pattern->elevation[i] = zenith_height; //ZMIANA! ^Installing...Updating metadata file...WARNING: Unable to parse 'http://grass.osgeo.org/addons/grass7/modules.xml'. Metadata file not updated.Installation of successfully finished -- END of OUTPUT 1 -- I also get errors when attempting to install other add-ons, e.g. r.bioclim: g.extension extension=r.bioclim svnurl=http://svn.osgeo.org/grass/grass-addons/grass7Fetching from GRASS-Addons SVN (be patient)...Compiling.../bin/sh: 1: cannot create /usr/local/grass-7.0.0beta3/locale/scriptstrings/r.bioclim_to_translate.c: Directorynonexistentmake: [/usr/local/grass-7.0.0beta3/locale/scriptstrings/r.bioclim_to_translate.c] Error 2 (ignored)Installing...Updating metadata file...WARNING: Unable to parse 'http://grass.osgeo.org/addons/grass7/modules.xml'. Metadata file not updated.Installation of successfully finished -- END of OUTPUT 2 -- e.g. r.stream.basins: Fetching from GRASS-Addons SVN (be patient)...Compiling...io.c: In function ?ram_write_map?:io.c:221:10: warning: ?c? may be used uninitialized inthis function [-Wmaybe-uninitialized] G_debug(1, "ram_null:Cannot convert to null at: %d %d",r, c); ^io.c: In function ?seg_write_map?:io.c:531:12: warning: ?c? may be used uninitialized inthis function [-Wmaybe-uninitialized] G_warning(_("Unable to convert to null at: %d %d"), r, ^Installing...Updating metadata file...WARNING: Unable to parse 'http://grass.osgeo.org/addons/grass7/modules.xml'. Metadata file not updated.Installation of successfully finished -- END of OUTPUT 3 -- --- END --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From landa.martin at gmail.com Mon Sep 8 23:57:34 2014 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 9 Sep 2014 08:57:34 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: Message-ID: Hi, 2014-09-08 22:48 GMT+02:00 Joseph Bailey : > WARNING: Unable to parse 'http://grass.osgeo.org/addons/grass7/modules.xml'. > Metadata file not updated. > Installation of successfully finished it's related to the problem on the server where modules.xml is generated. I am working on solving it. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From misc2345 at outlook.com Tue Sep 9 00:04:38 2014 From: misc2345 at outlook.com (geo-joe) Date: Tue, 9 Sep 2014 00:04:38 -0700 (PDT) Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: Message-ID: <1410246278645-5160795.post@n6.nabble.com> Thanks for the quick reply; much appreciated. I was partly hoping it was something I was doing wrong so that it was fixable. Not to worry. Is there anything that I can do in the meantime so that I can use the add-on, please? Is it possible to compile locally from the source code (https://svn.osgeo.org/grass/grass-addons/grass7/raster/r.geomorphon/), for example? The add-on does load and runs but produces no output and doesn't appear in the 'installed add-ons' list as it is, despite saying "Installation ... successfully finished". Many thanks, Joe ----- Joe B -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Add-on-compilation-errors-in-GRASS-7-tp5160758p5160795.html Sent from the Grass - Users mailing list archive at Nabble.com. From landa.martin at gmail.com Tue Sep 9 00:16:16 2014 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 9 Sep 2014 09:16:16 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: <1410246278645-5160795.post@n6.nabble.com> References: <1410246278645-5160795.post@n6.nabble.com> Message-ID: Hi, 2014-09-09 9:04 GMT+02:00 geo-joe : > > Thanks for the quick reply; much appreciated. I was partly hoping it was > something I was doing wrong so that it was fixable. Not to worry. Is there > anything that I can do in the meantime so that I can use the add-on, please? this warning (modules.xml) has nothing to do the with the functionality of addons module... > Is it possible to compile locally from the source code > (https://svn.osgeo.org/grass/grass-addons/grass7/raster/r.geomorphon/), for > example? The add-on does load and runs but produces no output and doesn't > appear in the 'installed add-ons' list as it is, despite saying > "Installation ... successfully finished". Can you launch the module or not? Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From misc2345 at outlook.com Tue Sep 9 00:14:43 2014 From: misc2345 at outlook.com (geo-joe) Date: Tue, 9 Sep 2014 00:14:43 -0700 (PDT) Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: <1410246278645-5160795.post@n6.nabble.com> Message-ID: <1410246883784-5160798.post@n6.nabble.com> Hello, r.geomorphon launches and presents the GUI when I type 'r.geomorphon' into the command line. I can launch the module's GUI and enter the inputs but it doesn't produce an output when it runs, which I assumed was to do with the warning following compilation. Thanks, Joe ----- Joe B -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Add-on-compilation-errors-in-GRASS-7-tp5160758p5160798.html Sent from the Grass - Users mailing list archive at Nabble.com. From misc2345 at outlook.com Tue Sep 9 00:43:24 2014 From: misc2345 at outlook.com (geo-joe) Date: Tue, 9 Sep 2014 00:43:24 -0700 (PDT) Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: <1410246883784-5160798.post@n6.nabble.com> References: <1410246278645-5160795.post@n6.nabble.com> <1410246883784-5160798.post@n6.nabble.com> Message-ID: <1410248604385-5160809.post@n6.nabble.com> I just thought, does that final warning on the parsing issue relate to the previous warnings or are they separate issues? I was assuming that it did but maybe not, considering what you say. Could these be caused by missing components during GRASS compilation? e.g. geom.c: In function ?ternary_rotate?: geom.c:22:9: warning: unused variable ?res? [-Wunused- variable] int res; ^ Thanks, Joe ----- Joe B -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Add-on-compilation-errors-in-GRASS-7-tp5160758p5160809.html Sent from the Grass - Users mailing list archive at Nabble.com. From landa.martin at gmail.com Tue Sep 9 01:08:19 2014 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 9 Sep 2014 10:08:19 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: <1410248604385-5160809.post@n6.nabble.com> References: <1410246278645-5160795.post@n6.nabble.com> <1410246883784-5160798.post@n6.nabble.com> <1410248604385-5160809.post@n6.nabble.com> Message-ID: Hi, 2014-09-09 9:43 GMT+02:00 geo-joe : > I just thought, does that final warning on the parsing issue relate to the > previous warnings or are they separate issues? I was assuming that it did right, completely separated issues. The first part comes from compilation (such warnings/errors should be fixed by an author of the module). Warning about broken modules.xml is related to g.extension which tries to keep metadata about installed modules [1]. This will be fixed by me since the generation of modules.xml file is done on our university server (CTU in Prague). > but maybe not, considering what you say. Could these be caused by missing > components during GRASS compilation? > e.g. > geom.c: In function 'ternary_rotate': > geom.c:22:9: warning: unused variable 'res' [-Wunused- > variable] > int res; > ^ No, such warnings are harmless and have no impact on functionality of the module. Martin [1] http://trac.osgeo.org/grass/wiki/AddOnsManagement From misc2345 at outlook.com Tue Sep 9 01:14:15 2014 From: misc2345 at outlook.com (geo-joe) Date: Tue, 9 Sep 2014 01:14:15 -0700 (PDT) Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: <1410246278645-5160795.post@n6.nabble.com> <1410246883784-5160798.post@n6.nabble.com> <1410248604385-5160809.post@n6.nabble.com> Message-ID: <1410250455881-5160822.post@n6.nabble.com> Hi, Ok, sorry, my lack of GRASS know-how is being highlighted here! So, if I've understood correctly, the module /should/ work, despite the separate 'Wunused' and 'broken modules.xml' warnings received? It would be great to get this ironed out. I'll contact the module's authors and link through to this thread. Thanks for your time on this, Joe ----- Joe B -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Add-on-compilation-errors-in-GRASS-7-tp5160758p5160822.html Sent from the Grass - Users mailing list archive at Nabble.com. From landa.martin at gmail.com Tue Sep 9 01:43:53 2014 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 9 Sep 2014 10:43:53 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: Message-ID: Hi, 2014-09-08 22:48 GMT+02:00 Joseph Bailey : > /bin/sh: 1: cannot create /usr/local/grass-7.0.0beta3/locale > /scriptstrings/r.bioclim_to_translate.c: Directory > nonexistent > make: [/usr/local/grass-7.0.0beta3/locale/scriptstrings/r.bi > oclim_to_translate.c] Error 2 (ignored) this issue has been fixed after beta3 [1], could you try out more recent version from SVN [2]? Martin [1] http://trac.osgeo.org/grass/changeset/61713/grass/branches/releasebranch_7_0/scripts/g.extension/g.extension.py [2] http://trac.osgeo.org/grass/wiki/DownloadSource#GRASS7.0 -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From landa.martin at gmail.com Tue Sep 9 01:57:56 2014 From: landa.martin at gmail.com (Martin Landa) Date: Tue, 9 Sep 2014 10:57:56 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: <1410246278645-5160795.post@n6.nabble.com> <1410246883784-5160798.post@n6.nabble.com> <1410248604385-5160809.post@n6.nabble.com> Message-ID: 2014-09-09 10:08 GMT+02:00 Martin Landa : > module). Warning about broken modules.xml is related to g.extension > which tries to keep metadata about installed modules [1]. This will be > fixed by me since the generation of modules.xml file is done on our > university server (CTU in Prague). hopefully fixed. g.extension r.geomorphon Fetching from GRASS-Addons SVN repository (be patient)... Compiling... geom.c: In function 'ternary_rotate': geom.c:22:9: warning: unused variable 'res' [-Wunused-variable] ... Installing... Updating metadata file... Installation of successfully finished Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From peifer at gmx.eu Tue Sep 9 04:22:34 2014 From: peifer at gmx.eu (peifer) Date: Tue, 9 Sep 2014 04:22:34 -0700 (PDT) Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: <1410246278645-5160795.post@n6.nabble.com> <1410246883784-5160798.post@n6.nabble.com> <1410248604385-5160809.post@n6.nabble.com> Message-ID: <1410261754761-5160862.post@n6.nabble.com> Martin Landa wrote > 2014-09-09 10:08 GMT+02:00 Martin Landa < > landa.martin@ > >: >> module). Warning about broken modules.xml is related to g.extension >> which tries to keep metadata about installed modules [1]. This will be >> fixed by me since the generation of modules.xml file is done on our >> university server (CTU in Prague). > > hopefully fixed. Thanks for fixing. Installation works fine now [1]. I will close my ticket from earlier today [2]. r.geomorphon seems to work fine for me and creates a forms output map as expected. I'm using svn/grass7_releasebranch Hermann [1] [GRASS:test]> g.extension r.geomorphon Fetching from GRASS-Addons SVN repository (be patient)... Compiling... Installing... Updating metadata file... Installation of successfully finished [GRASS:test]> g.extension -l List of available extensions (modules): r.geomorphon [GRASS:test]> [2] https://trac.osgeo.org/grass/ticket/2411 -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Add-on-compilation-errors-in-GRASS-7-tp5160758p5160862.html Sent from the Grass - Users mailing list archive at Nabble.com. From misc2345 at outlook.com Tue Sep 9 12:28:10 2014 From: misc2345 at outlook.com (geo-joe) Date: Tue, 9 Sep 2014 12:28:10 -0700 (PDT) Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: Message-ID: <1410290890399-5160964.post@n6.nabble.com> Ah yes, the parsing error is now gone. The others are still present, however, and the add-on isn't working... I'll try a clean install and maybe contact the author of the tool when I'm sure it's not something that I'm doing. Thanks again for all of this, Joe ----- Joe B -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Add-on-compilation-errors-in-GRASS-7-tp5160758p5160964.html Sent from the Grass - Users mailing list archive at Nabble.com. From peifer at gmx.eu Tue Sep 9 23:06:01 2014 From: peifer at gmx.eu (Hermann Peifer) Date: Wed, 10 Sep 2014 08:06:01 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: Message-ID: <540FEA49.6060506@gmx.eu> On 2014-09-09 8:57, Martin Landa wrote: > > it's related to the problem on the server where modules.xml is > generated. I am working on solving it. > Hi Martin, I assume that at some point, there will be a full-size modules.xml file for grass7, i.e. comparable to http://grass.osgeo.org/addons/grass6/modules.xml Any idea when this will be? Thanks in advance, Hermann From landa.martin at gmail.com Wed Sep 10 00:23:08 2014 From: landa.martin at gmail.com (Martin Landa) Date: Wed, 10 Sep 2014 09:23:08 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: <540FEA49.6060506@gmx.eu> References: <540FEA49.6060506@gmx.eu> Message-ID: Hi, 2014-09-10 8:06 GMT+02:00 Hermann Peifer : > I assume that at some point, there will be a full-size modules.xml file for > grass7, i.e. comparable to http://grass.osgeo.org/addons/grass6/modules.xml > > Any idea when this will be? hm, it's broken again, strangely only when launched via cronjobs (this happens after I reinstalled the server where it's running). Manually launched scripts simply work. Will fix it manually right now, and I will try to find out what is wrong with cronjob which should work in the same way as launching scripts manually. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From sawdef at hotmail.com Wed Sep 10 00:27:35 2014 From: sawdef at hotmail.com (Sofiane Bendoukha) Date: Wed, 10 Sep 2014 09:27:35 +0200 Subject: [GRASS-user] Grass commands to web services Message-ID: Hello evryone, it's my first participation, Is there a solution to wrap a grass command to a web service. I want to use that command from a browser. Thank you. Regards. From landa.martin at gmail.com Wed Sep 10 01:11:55 2014 From: landa.martin at gmail.com (Martin Landa) Date: Wed, 10 Sep 2014 10:11:55 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: <540FEA49.6060506@gmx.eu> Message-ID: 2014-09-10 9:23 GMT+02:00 Martin Landa : > launched scripts simply work. Will fix it manually right now, and I > will try to find out what is wrong with cronjob which should work in it's back. I will test cronjobs and try to fix the real problem behind. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From Luis.M.Barranco at cedex.es Wed Sep 10 01:13:42 2014 From: Luis.M.Barranco at cedex.es (Luis Miguel Barranco Sanz) Date: Wed, 10 Sep 2014 08:13:42 +0000 Subject: [GRASS-user] d.rast.num Message-ID: <2F1DA59D3A722B46AD795081F486520BBA1CEC@SBUZTSITIC103.fomento.es> Dear all: When I?m trying to execute d.rast.num in Grass71, an error appear that did not appear in Grass64: GRASS 7.1.svn > d.rast.num MASK Command 'd.rast.num map=MASK grid_color=gray dp=1 text_color=black' failed Details: Current region size: 418 rows X 638 cols Your current region setting may be too large. Cells displayed on your graphics window may be too small for cell category number to be visible. The problem is that my current region has only 323 cells: GRASS 7.1.svn > g.region -p nsres: 1000 ewres: 1000 rows: 19 cols: 17 cells: 323 Has anyone had this problem? Does anyone know how to solve it? Thanks Luis Barranco Luis Miguel Barranco Sanz Centro de Estudios Hidrogr?ficos Paseo Bajo Virgen del Puerto 3 28005 Madrid Tel: 34 913357927 luis.m.barranco at cedex.es ------------ pr?xima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From landa.martin at gmail.com Wed Sep 10 02:46:30 2014 From: landa.martin at gmail.com (Martin Landa) Date: Wed, 10 Sep 2014 11:46:30 +0200 Subject: [GRASS-user] Add-on compilation errors in GRASS 7 In-Reply-To: References: <540FEA49.6060506@gmx.eu> Message-ID: Hi, 2014-09-10 10:11 GMT+02:00 Martin Landa : >> launched scripts simply work. Will fix it manually right now, and I >> will try to find out what is wrong with cronjob which should work in > > it's back. I will test cronjobs and try to fix the real problem behind. Martin the problem was that the path defined by crontab lacked `/usr/local/bin`. I have fixed that, hopefully the next call (this night) will be finally OK. Martin -- Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa From will.openfields at gmail.com Wed Sep 10 07:31:20 2014 From: will.openfields at gmail.com (Will Fields) Date: Wed, 10 Sep 2014 10:31:20 -0400 Subject: [GRASS-user] v.net.centrality closeness Message-ID: I'm using v.net.centrality to do some calculations, and I had a question about how closeness centrality is calculated by the module: Is the value for closeness centrality actually "farness" (the sum of the distance from a site in a network to all other sites in the network)? v.net.centrality is returning large values for closeness in a data set rather than a decimal between 0 and 1. I tried to look through the C code for the module, but I wasn't able to make sense of it. Thanks in advance. Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From kratochanna at gmail.com Wed Sep 10 08:35:47 2014 From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=) Date: Wed, 10 Sep 2014 11:35:47 -0400 Subject: [GRASS-user] d.rast.num In-Reply-To: <2F1DA59D3A722B46AD795081F486520BBA1CEC@SBUZTSITIC103.fomento.es> References: <2F1DA59D3A722B46AD795081F486520BBA1CEC@SBUZTSITIC103.fomento.es> Message-ID: On Wed, Sep 10, 2014 at 4:13 AM, Luis Miguel Barranco Sanz < Luis.M.Barranco at cedex.es> wrote: > Dear all: > > > > When I?m trying to execute d.rast.num in Grass71, an error appear that did > not appear in Grass64: > > > > *GRASS 7.1.svn > d.rast.num MASK* > > > > *Command 'd.rast.num map=MASK grid_color=gray dp=1 text_color=black' > failed* > > *Details: Current region size: 418 rows X 638 cols* > > *Your current region setting may be too large. Cells displayed on your > graphics window may be too small for cell category number to be visible.* > > > > > > The problem is that my current region has only 323 cells: > > > > *GRASS 7.1.svn > g.region -p* > > > > *nsres: 1000* > > *ewres: 1000* > > *rows: 19* > > *cols: 17* > > *cells: 323* > > > > Has anyone had this problem? Does anyone know how to solve it? > > When you go to the Map Display statusbar and find item Display resolution, do you have the checkbox 'Constrain display resolution to computational settings' checked (it has to be checked for d.rast.num)? It should ask you if you want to check it when you run the d.rast.num, I think. Anna > > > Thanks > > > > Luis Barranco > > > > > > > > Luis Miguel Barranco Sanz > > Centro de Estudios Hidrogr?ficos > > Paseo Bajo Virgen del Puerto 3 > > 28005 Madrid > > Tel: 34 913357927 > > luis.m.barranco at cedex.es > > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Wed Sep 10 08:57:06 2014 From: neteler at osgeo.org (Markus Neteler) Date: Wed, 10 Sep 2014 17:57:06 +0200 Subject: [GRASS-user] Grass commands to web services In-Reply-To: References: Message-ID: On Wed, Sep 10, 2014 at 9:27 AM, Sofiane Bendoukha wrote: > Hello evryone, > > it's my first participation, Is there a solution to wrap a grass command to > a web service. I want to use that command from a browser. Please take a look at GRASS GIS based OGC Web Processing Service (WPS) standard implementations. There is a Wiki page indicating some ways to go: http://grasswiki.osgeo.org/wiki/WPS Best, Markus From bbbvvgtm at yahoo.com Wed Sep 10 11:58:27 2014 From: bbbvvgtm at yahoo.com (Scott Pickett) Date: Wed, 10 Sep 2014 11:58:27 -0700 Subject: [GRASS-user] How to add volexes to a map showing what a camera can see Message-ID: <1410375507.66965.YahooMailNeo@web165003.mail.bf1.yahoo.com> Can GRASS do the following analysis for me? We have 6 cameras, each with a 45 degree view angle. They are placed on various peaks in a 1 km X 4 km area. I want to display a map of the area showing the 6 cameras and what part of the terrain each can see. If it's view blocked by intervening terrain, it will not be able to see ground level at that location. In those cases, I'd like it to show the minimum altitude it can see. I would like to highlight all areas that can be seen up to a height of 1500 feet as a set of voxels and display this volume above the base terrain map. I would like to be able to do all of this programatically so I can fully control the process. I want the user to be able to visualize this in some reasonable way. I know this is a big question, but does anyone know if GRASS can do some or all of this and what modules I should be looking at, it would be a big help. Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From royroge at outlook.com Thu Sep 11 03:50:15 2014 From: royroge at outlook.com (m roy) Date: Thu, 11 Sep 2014 10:50:15 +0000 Subject: [GRASS-user] =?utf-8?q?question_about_r=2Einfo?= Message-ID: Checking a raster map about null values i get results that seem non consistent: the map is a result from r.mapcalc (1 for null and 0 for all othe values) r.info min = 0 max = 1 r.stats 0 775? * 805?. r.info claims max value is 1 r.stats no cell with value 1 maybe i do not get how r.info is supposed to work but if i have no value 1 cell how can be the range beetwen ?0 ? and ?1? thanks , Roy Inviata da Windows Mail -------------- next part -------------- An HTML attachment was scrubbed... URL: From peifer at gmx.eu Thu Sep 11 04:24:12 2014 From: peifer at gmx.eu (peifer) Date: Thu, 11 Sep 2014 04:24:12 -0700 (PDT) Subject: [GRASS-user] question about r.info In-Reply-To: References: Message-ID: <1410434652735-5161299.post@n6.nabble.com> m roy wrote > r.info min = 0 max = 1 > > r.stats > 0 775? > * 805?. r.stats honours the current region, r.info doesn't. If your map's data area would be in Europe and your current region is by mistake defined somewhere in the middle of Canada: r.stats would report all values to be NULL. Hermann -- View this message in context: http://osgeo-org.1560.x6.nabble.com/question-about-r-info-tp5161293p5161299.html Sent from the Grass - Users mailing list archive at Nabble.com. From Stefan.Blumentrath at nina.no Thu Sep 11 04:51:26 2014 From: Stefan.Blumentrath at nina.no (Blumentrath, Stefan) Date: Thu, 11 Sep 2014 11:51:26 +0000 Subject: [GRASS-user] GRASS Community Sprint Portland 2014 - user contributions Message-ID: <2C5F82DA3EE3E449BD473075F2C290BF9C2D407A@NINSRV05.nina.no> Dear all, If you are as fond of the upcoming GRASS 7 version as I am and if you - like me - whish to see this brilliant version released rather today than tomorrow, I would like to invite you to consider supporting the devs at the GRASS Community Sprint Portland 2014 by filling incomplete manual pages. The html-standard for manual pages is not too complicated (see: https://trac.osgeo.org/grass/wiki/Submitting/Docs), so programming skills are not required. Furthermore, you can find lots of examples from other modues. On the GRASS-wiki-site for the Community Sprint there is a list of modules with incomplete manuals (please feel free to add, if you are aware of more): http://grasswiki.osgeo.org/wiki/GRASS_Community_Sprint_Portland_2014 There you can sign up for a manual page you like to fill with content. So, check out the source code: svn checkout https://svn.osgeo.org/grass/grass/branches/releasebranch_7_0 grass70_release Fill the manual page for a module you are reasonable familiar with, create a patch (see: http://grasswiki.osgeo.org/wiki/Patches) and send it to: e.g. neteler.osgeo at gmail.com (hope that is OK Markus?) Looking forward to the event! Cheers Stefan From royroge at outlook.com Thu Sep 11 05:10:11 2014 From: royroge at outlook.com (m roy) Date: Thu, 11 Sep 2014 12:10:11 +0000 Subject: [GRASS-user] =?utf-8?q?question_about_r=2Einfo?= Message-ID: Thank?s for the replay Hermann, this is not the case AFAIK because i generated the map using r.mapcalc with region and MASK properly set ? roy Da: peifer Data invio: ?gioved?? ?11? ?settembre? ?2014 ?13?.?31 A: grass-user at lists.osgeo.org m roy wrote > r.info min = 0 max = 1 > > r.stats > 0 775? > * 805?. r.stats honours the current region, r.info doesn't. If your map's data area would be in Europe and your current region is by mistake defined somewhere in the middle of Canada: r.stats would report all values to be NULL. Hermann -- View this message in context: http://osgeo-org.1560.x6.nabble.com/question-about-r-info-tp5161293p5161299.html Sent from the Grass - Users mailing list archive at Nabble.com. _______________________________________________ grass-user mailing list grass-user at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlennert at club.worldonline.be Thu Sep 11 06:44:19 2014 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Thu, 11 Sep 2014 15:44:19 +0200 Subject: [GRASS-user] v.net.centrality closeness In-Reply-To: References: Message-ID: <5411A733.9030600@club.worldonline.be> On 10/09/14 16:31, Will Fields wrote: > I'm using v.net.centrality to do some calculations, and I had a question > about how closeness centrality is calculated by the module: > Is the value for closeness centrality actually "farness" (the sum of the > distance from a site in a network to all other sites in the network)? > v.net.centrality is returning large values for closeness in a data > set rather than a decimal between 0 and 1. I tried to look through the > C code for the module, but I wasn't able to make sense of it. I think you are right. In its current form, it seems to be more of a measure of "farness". By inverting the "closeness" variable with a simple 1 / closeness I get a result that seems more adequate. But I also don't really understand the calculations in the code. Notably, if farness of a node is (according to the Wikipedia article referenced in the man page) "the sum of its distances to all other nodes", shouldn't it be the sum of the distances of the node to all other nodes, i.e. you should be able to calculate farness using v.net.allpair and then summing the distances by from_node ? When I use v.net.centrality on a network combining streets_wake and schools_wake from the NC dataset and I calculate the "closeness" (aka farness), I get this for the nodes with the highest values: cat | dist -----+-------------- 39 | 39769.319852 128 | 39316.769189 159 | 38730.565742 38 | 34311.673453 59 | 33649.126805 112 | 33406.022609 131 | 33080.405319 140 | 33062.412818 33 | 32580.971836 135 | 32183.519299 77 | 32059.527469 158 | 32039.010031 129 | 31501.214954 103 | 31327.647516 42 | 31283.00064 But when I calculate all distances with v.net.allpairs and the sum the distances by from_cat, I get from_cat | dist ----------+------------- 39 | 6254233.946 128 | 6175455.627 159 | 6080808.494 140 | 5498739.16 33 | 5403162.189 38 | 5336049.601 158 | 5322613.245 112 | 5241168.562 131 | 5211368.296 59 | 5201325.561 103 | 5182372.74 156 | 5171904.939 157 | 5116144.746 143 | 5065893.211 77 | 5047493.908 i.e. both the values _and_ the order of nodes are different. Maybe you should file two bugs against v.net.centrality: 1) make closeness the real closeness, i.e. the inverse of farness 2) improve the documentation of the module by explaining the exact calculations of each variable, instead of just referencing a Wikipedia article Moritz From jim at jimkeener.com Thu Sep 11 20:29:05 2014 From: jim at jimkeener.com (James Keener) Date: Thu, 11 Sep 2014 23:29:05 -0400 Subject: [GRASS-user] Looking for critiques on a tutorial In-Reply-To: References: <53FF1521.1020105@jimkeener.com> <824e3833-78b6-4c13-a2ed-2f57a0617394@email.android.com> Message-ID: <54126881.9050502@jimkeener.com> Hello, I wrote a tutorial on how to go from a TIGER road map and GTFS data to a topological analysis of bus stops. There are some minor formatting issues I'm working on, but was hoping to get technical or other feedback on it. http://jimkeener.com/posts/analyizing-bus-routes Thank you, Jim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From neteler at osgeo.org Fri Sep 12 01:10:27 2014 From: neteler at osgeo.org (Markus Neteler) Date: Fri, 12 Sep 2014 10:10:27 +0200 Subject: [GRASS-user] r.li circular window and not integer radius In-Reply-To: References: Message-ID: Hi Sergio, Luca has made a fix in GRASS 7.1 for testing in revision r61866. Could you please test it? Best Markus From tea3rd at gmail.com Fri Sep 12 04:11:01 2014 From: tea3rd at gmail.com (Thomas Adams) Date: Fri, 12 Sep 2014 07:11:01 -0400 Subject: [GRASS-user] Looking for critiques on a tutorial In-Reply-To: <54126881.9050502@jimkeener.com> References: <53FF1521.1020105@jimkeener.com> <824e3833-78b6-4c13-a2ed-2f57a0617394@email.android.com> <54126881.9050502@jimkeener.com> Message-ID: Jim, I'll try to find some time to work through your tutorial in the next few days; I'll get back to you -- I just took a quick look and I think it looks good. BTW, I'm also using Ubuntu (14.04). Tom On Thu, Sep 11, 2014 at 11:29 PM, James Keener wrote: > Hello, > > I wrote a tutorial on how to go from a TIGER road map and GTFS data to a > topological analysis of bus stops. There are some minor formatting > issues I'm working on, but was hoping to get technical or other feedback > on it. > > http://jimkeener.com/posts/analyizing-bus-routes > > Thank you, > Jim > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johannesradinger at gmail.com Fri Sep 12 04:20:37 2014 From: johannesradinger at gmail.com (Johannes Radinger) Date: Fri, 12 Sep 2014 13:20:37 +0200 Subject: [GRASS-user] Installation r.fuzzy.system on GRASS7 (Mac OSX) failed Message-ID: Hi, I'd like to install the add-on r.fuzzy.system on GRASS7 on my Mac OSX (10.9.4). GRASS7beta3 (r61585M) has been installed via http://grassmac.wikidot.com/downloads. All necessary frameworks have also been installed and grass itself works properly. However, when it comes to the installation of the add-on, I get following error: g.extension extension=r.fuzzy.system svnurl= http://svn.osgeo.org/grass/grass-addons/grass7 Fetching from GRASS-Addons SVN (be patient)... Compiling... system.c:122:11: warning: 7 enumeration values not handled in switch: 't_START', 't_IS_NOT', 't_IS'... [-Wswitch] switch (operator_stack[opr_top]) { ^ 1 warning generated. system.c:122:11: warning: 7 enumeration values not handled in switch: 't_START', 't_IS_NOT', 't_IS'... [-Wswitch] switch (operator_stack[opr_top]) { ^ 1 warning generated. /bin/sh: Radinger-18713/gisrc: No such file or directory make: *** [r.fuzzy.system.tmp.html] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. Do I need to install any other packages etc. or is just the add-on broken? Just to mention, my computer's name includes a space, so e.g. the grass7rc is located here: "/Users/Johannes Radinger/.grass7/rc" If that information is needed.... Maybe anybody has some more information about that issue. Best regards, Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From royroge at outlook.com Fri Sep 12 06:17:36 2014 From: royroge at outlook.com (m roy) Date: Fri, 12 Sep 2014 13:17:36 +0000 Subject: [GRASS-user] =?utf-8?q?question_about_r=2Einfo?= Message-ID: That?s all right, thanks ! Da: Hermann Peifer Data invio: ?gioved?? ?11? ?settembre? ?2014 ?19?.?06 A: m roy On 2014-09-11 14:10, m roy wrote: > > > Thank?s for the replay Hermann, > > this is not the case AFAIK because i generated the map using r.mapcalc > with region and MASK properly set ? > Just to be on the safe side, you could do: r.mask -r g.region -p rast=myMap r.describe myMap r.stats -c myMap Hermann -------------- next part -------------- An HTML attachment was scrubbed... URL: From markus.metz.giswork at gmail.com Fri Sep 12 09:02:08 2014 From: markus.metz.giswork at gmail.com (Markus Metz) Date: Fri, 12 Sep 2014 18:02:08 +0200 Subject: [GRASS-user] v.net.centrality closeness In-Reply-To: <5411A733.9030600@club.worldonline.be> References: <5411A733.9030600@club.worldonline.be> Message-ID: On Thu, Sep 11, 2014 at 3:44 PM, Moritz Lennert wrote: > On 10/09/14 16:31, Will Fields wrote: >> >> I'm using v.net.centrality to do some calculations, and I had a question >> about how closeness centrality is calculated by the module: >> Is the value for closeness centrality actually "farness" (the sum of the >> distance from a site in a network to all other sites in the network)? >> v.net.centrality is returning large values for closeness in a data >> set rather than a decimal between 0 and 1. I tried to look through the >> C code for the module, but I wasn't able to make sense of it. > > > I think you are right. In its current form, it seems to be more of a measure > of "farness". > > By inverting the "closeness" variable with a simple > > 1 / closeness > > I get a result that seems more adequate. > > But I also don't really understand the calculations in the code. Notably, if > farness of a node is (according to the Wikipedia article referenced in the > man page) "the sum of its distances to all other nodes", shouldn't it be the > sum of the distances of the node to all other nodes, i.e. you should be able > to calculate farness using v.net.allpair and then summing the distances by > from_node ? > > When I use v.net.centrality on a network combining streets_wake and > schools_wake from the NC dataset and I calculate the "closeness" (aka > farness), I get this for the nodes with the highest values: > > cat | dist > -----+-------------- > 39 | 39769.319852 > 128 | 39316.769189 > 159 | 38730.565742 > 38 | 34311.673453 > 59 | 33649.126805 > 112 | 33406.022609 > 131 | 33080.405319 > 140 | 33062.412818 > 33 | 32580.971836 > 135 | 32183.519299 > 77 | 32059.527469 > 158 | 32039.010031 > 129 | 31501.214954 > 103 | 31327.647516 > 42 | 31283.00064 > > But when I calculate all distances with v.net.allpairs and the sum the > distances by from_cat, I get > > from_cat | dist > ----------+------------- > 39 | 6254233.946 > 128 | 6175455.627 > 159 | 6080808.494 > 140 | 5498739.16 > 33 | 5403162.189 > 38 | 5336049.601 > 158 | 5322613.245 > 112 | 5241168.562 > 131 | 5211368.296 > 59 | 5201325.561 > 103 | 5182372.74 > 156 | 5171904.939 > 157 | 5116144.746 > 143 | 5065893.211 > 77 | 5047493.908 > > i.e. both the values _and_ the order of nodes are different. According to the code, closeness is the average distance to all other nodes reachable from the current node, i.e. something like average farness. Markus M > > Maybe you should file two bugs against v.net.centrality: > > 1) make closeness the real closeness, i.e. the inverse of farness > > 2) improve the documentation of the module by explaining the exact > calculations of each variable, instead of just referencing a Wikipedia > article > > Moritz > > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user From benducke at fastmail.fm Fri Sep 12 10:04:12 2014 From: benducke at fastmail.fm (Benjamin Ducke) Date: Fri, 12 Sep 2014 19:04:12 +0200 Subject: [GRASS-user] Duplicate features in output of v.out.ogr Message-ID: <5413278C.2000205@fastmail.fm> Hi All, I have extracted the centroids of a map with polygons, but some of the extracted centroids have identical "cat" numbers. I suspect that those are centroids of multi- part polygons that share the same attribute table records in the original input data (a MapInfo file). I would like to reduce my set of centroids to only one per "cat" value. So my question is. Is there a simple way to remove features with duplicate "cat" numbers from a GRASS map? Thanks and best, Ben -- Dr. Benjamin Ducke, M.A. {*} Geospatial Consultant {*} GIS Developer benducke at fastmail.fm From confirmacao at peticaopublica.com.br Fri Sep 12 10:11:53 2014 From: confirmacao at peticaopublica.com.br (=?utf-8?Q?Peti=C3=A7=C3=A3o P=C3=BAblica?=) Date: 12 Sep 2014 18:11:53 +0100 Subject: [GRASS-user] =?iso-8859-1?q?Jos=E9_Anderson_enviou-lhe_o_seguinte?= =?iso-8859-1?q?_Abaixo-Assinado?= Message-ID: <6544F6DD-E7B7-43E8-A3E1-DD4F3D4F9688@mail.peticaopublica.com.br> An HTML attachment was scrubbed... URL: From vignalisergio30 at gmail.com Sat Sep 13 07:07:18 2014 From: vignalisergio30 at gmail.com (Sergio Vignali) Date: Sat, 13 Sep 2014 16:07:18 +0200 Subject: [GRASS-user] r.li circular window and not integer radius In-Reply-To: References: Message-ID: Hi Markus, I tried to install grass 7.1 but I get this error Scaricamento di:1 http://ppa.launchpad.net/grass/grass-devel/ubuntu/ precise/main grass70-core amd64 7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1 [8330 kB] Scaricamento di:2 http://ppa.launchpad.net/grass/grass-devel/ubuntu/ precise/main grass70-gui amd64 7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1 [2100 kB] Scaricamento di:3 http://ppa.launchpad.net/grass/grass-devel/ubuntu/ precise/main grass70 all 7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1 [12,8 kB] Scaricamento di:4 http://ppa.launchpad.net/grass/grass-devel/ubuntu/ precise/main grass70-doc all 7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1 [9177 kB] Recuperati 19,6 MB in 27s (725 kB/s) Selezionato il pacchetto grass70-core non precedentemente selezionato. (Lettura del database... 406788 file e directory attualmente installati.) Estrazione di grass70-core (da .../grass70-core_7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1_amd64.deb)... Selezionato il pacchetto grass70-gui non precedentemente selezionato. Estrazione di grass70-gui (da .../grass70-gui_7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1_amd64.deb)... Selezionato il pacchetto grass70 non precedentemente selezionato. Estrazione di grass70 (da .../grass70_7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1_all.deb)... Selezionato il pacchetto grass70-doc non precedentemente selezionato. Estrazione di grass70-doc (da .../grass70-doc_7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1_all.deb)... dpkg: errore nell'elaborare /var/cache/apt/archives/grass70-doc_7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1_all.deb (--unpack): tentata sovrascrittura di "/usr/share/man/man1/v.surf.rst.1grass.gz" presente anche nel pacchetto grass-doc 6.4.4-2~precise4 dpkg-deb: errore: il sottoprocesso paste ? stato terminato dal segnale (Pipe interrotta) Elaborazione dei trigger per bamfdaemon... Rebuilding /usr/share/applications/bamf.index... Elaborazione dei trigger per desktop-file-utils... Elaborazione dei trigger per gnome-menus... Elaborazione dei trigger per hicolor-icon-theme... Elaborazione dei trigger per man-db... Elaborazione dei trigger per doc-base... Si sono verificati degli errori nell'elaborazione: /var/cache/apt/archives/grass70-doc_7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) what do you think? all the best Sergio 2014-09-12 10:10 GMT+02:00 Markus Neteler : > Hi Sergio, > > Luca has made a fix in GRASS 7.1 for testing in revision r61866. > > Could you please test it? > > Best > Markus > -- Sergio Vignali -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Sat Sep 13 11:34:59 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sat, 13 Sep 2014 20:34:59 +0200 Subject: [GRASS-user] r.li circular window and not integer radius In-Reply-To: References: Message-ID: Hi, 2014-09-13 16:07 GMT+02:00 Sergio Vignali : > Hi Markus, I tried to install grass 7.1 but I get this error > > Scaricamento di:1 http://ppa.launchpad.net/grass/grass-devel/ubuntu/ > precise/main grass70-core amd64 > 7.0.0+0ubuntu3~develppa~2~svn-30303~ubuntu12.04.1 [8330 kB] > Scaricamento di:2 http://ppa.launchpad.net/grass/grass-devel/ubuntu/ > precise/main grass70-gui amd64 I checked what's written here: http://grass.osgeo.org/download/software/linux/#grass71 but it seems that trunk disappeared from the PPA: https://launchpad.net/~grass/+archive/ubuntu/grass-devel Rashad, would you mind to check that? thanks, Markus PS: Sergio, it may be way easier for now to just http://grasswiki.osgeo.org/wiki/Compile_and_Install_Ubuntu From neteler at osgeo.org Sun Sep 14 22:28:32 2014 From: neteler at osgeo.org (Markus Neteler) Date: Mon, 15 Sep 2014 07:28:32 +0200 Subject: [GRASS-user] rastization failed : can't allocate memory In-Reply-To: References: Message-ID: On Mon, Sep 8, 2014 at 5:17 PM, Daniel Victoria wrote: > I never realized there was a rows parameter. oops No problem and now it is history for GRASS 7(.1): http://trac.osgeo.org/grass/changeset/61909 v.to.rast: change rows option to memory option This makes it way easier to understand. Please test, then we can backport it to GRASS 7.0 release branch. Markus From aginau at googlemail.com Mon Sep 15 14:29:23 2014 From: aginau at googlemail.com (Andreas Ginau) Date: Mon, 15 Sep 2014 23:29:23 +0200 Subject: [GRASS-user] Model to python script Message-ID: <54175A33.8010905@googlemail.com> Dear Grass community, I have a mapset containing landsat channels B1,B2,B3,B4,B5,B6,B7,B8,B9,B10,B11 which are basically the result of the landsat_import script. I want to load the mapset and run the following commands in order to perform i.landsat.toar, which does not work and returns exit code 1. Graphical model works fine but when I export the model as a python script and run the script it also does not work. grass.run_command("g.mapsets", mapset="LC81760382013119LGN01") grass.run_command("i.landsat.toar", input_prefix = "B", output_prefix = "test", metfile = metfile, sensor = "ot8", method = "dos4") How do I run i.landsat.toar on my mapset using python. My goal is to include the toar transformation into the landsat_import script. Greetings From luis.miguel.royo at gmail.com Wed Sep 17 09:59:49 2014 From: luis.miguel.royo at gmail.com (=?UTF-8?B?THVpcyBNaWd1ZWwgUm95byBQw6lyZXo=?=) Date: Wed, 17 Sep 2014 18:59:49 +0200 Subject: [GRASS-user] Problems installing add-ons GRASS 7 Message-ID: <5419BE05.5060007@gmail.com> Hi everyone, I'm getting this error when I try to install add-ons in Lubuntu 14.04 Unable to load extensions. Traceback (most recent call last): File "/usr/lib/grass70/scripts/g.extension", line 1081, in version = grass.version()['version'].split('.') KeyError: 'version' I've installed the dev packages. Am I missing something? or is just a bug due it's a beta version? Thanks a lot. ------------ pr?xima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From sandramf at live.co.za Wed Sep 17 16:40:51 2014 From: sandramf at live.co.za (Sandra MacFadyen) Date: Thu, 18 Sep 2014 01:40:51 +0200 Subject: [GRASS-user] Solved: execGRASS("r.diversity") Done. No rasters created (Large rasters) Message-ID: Dear Markus, Excellent! Thanks to everyone for their help. I tested r.diversity in the new revision (61840) on a raster with 12933032 cells and it took under 3 minutes to complete r.li.simpson, r.li.shannon, r.li.pielou and r.li.renyi outputs. Amazing :) > execGRASS("r.diversity",flags="overwrite", parameters=list(input="flow", prefix="flow_div", alpha=0.5, size=3)) > r.li.simpson complete. Raster map created. > r.li.shannon complete. Raster map created. > r.li.pielou complete. Raster map created. > r.li.renyi complete. Raster map > created. > Done. Thanks again and keep well. Cheers Sandra -----Original Message----- From: neteler.osgeo at gmail.com [mailto:neteler.osgeo at gmail.com] On Behalf Of Markus Neteler Sent: 06 September 2014 05:15 AM To: Sandra MacFadyen Cc: GRASS user list; Duccio Rocchini; Luca Delucchi Subject: Re: [GRASS-user] execGRASS("r.diversity") Done. No rasters created (Large rasters) Dear Sandra, On Fri, Jun 20, 2014 at 7:49 AM, Markus Neteler wrote: > On Sat, Jun 14, 2014 at 9:21 AM, Sandra MacFadyen wrote: >> I am using r.diversity (GRASS GIS 7.0.0svn build 60785 win32) through >> R (R version 3.0.2 win32) on Windows 7 64bit. ... >> However, when running the same code on a larger image (cells=6746328) >> from my own location, although it reports Done, no rasters are >> created. If I subset the image >> (cells=1632830) and run it again its works (see # sub2Kruger # code and results below). >> So I'm guessing it is a memory issue? ... > ... it consumes a lot of memory... will check on a bigger machine, > perhaps a memory leak. The assumption turned out to be right and I think we got it today! Vaclav Petras checked it and discovered an "unfortunate" memory allocation which he fixed in r.li.* in revision http://trac.osgeo.org/grass/changeset/61812 ("r.li: fix memory handling (memory leak in avl_to_array function))". Now r.li has become very fast, on my laptop: GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 res=10 -a ... rows: 1355 cols: 1503 cells: 2036565 GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 output=lsat5_1987_div__simpson_size_5.0 r.li.simpson complete. Raster map created. --> 29.32 seconds or with a simulated higher resolution: GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 res=5 -aprojection: 99 (Lambert Conformal Conic) ... rows: 2708 cols: 3005 cells: 8137540 GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 output=lsat5_1987_div__simpson_size_5.0 r.li.simpson complete. Raster map created. --> 227.37 seconds (used to be > 2 hours) So, to grab this improvement for Windows, grab the version from here: http://wingrass.fsv.cvut.cz/grass71/ (or via OSGeo4W installer). Be sure that the revision is at least r61812 which is indicated in the file name. Please let us know if all works to avoid that the change has any negative impact. Tests here did not show any changes in the output except for the speed improvement and solved memory leak. Subsequently also r.diversity should behave now. I'll backport it to GRASS 7.0 release branch after some testing. Markus From wenzeslaus at gmail.com Wed Sep 17 17:45:43 2014 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Wed, 17 Sep 2014 20:45:43 -0400 Subject: [GRASS-user] Solved: execGRASS("r.diversity") Done. No rasters created (Large rasters) In-Reply-To: References: Message-ID: On Wed, Sep 17, 2014 at 7:40 PM, Sandra MacFadyen wrote: > Dear Markus, > > Excellent! Thanks to everyone for their help. > I tested r.diversity in the new revision (61840) on a raster with 12933032 > cells and it took under 3 minutes to complete r.li.simpson, r.li.shannon, > r.li.pielou and r.li.renyi outputs. > Amazing :) > > > execGRASS("r.diversity",flags="overwrite", parameters=list(input="flow", > prefix="flow_div", alpha=0.5, size=3)) > > r.li.simpson complete. Raster map created. > > r.li.shannon complete. Raster map created. > > r.li.pielou complete. Raster map created. > > r.li.renyi complete. Raster map > > created. > > Done. > > Thanks again and keep well. > > Good to hear that. Can you say if the results are correct? I computed difference of one map before and after and it was OK. But it would be great to have more tests. Let's start with: does the result make sense? Vaclav > Cheers > Sandra > > -----Original Message----- > From: neteler.osgeo at gmail.com [mailto:neteler.osgeo at gmail.com] On Behalf > Of Markus Neteler > Sent: 06 September 2014 05:15 AM > To: Sandra MacFadyen > Cc: GRASS user list; Duccio Rocchini; Luca Delucchi > Subject: Re: [GRASS-user] execGRASS("r.diversity") Done. No rasters > created (Large rasters) > > Dear Sandra, > > On Fri, Jun 20, 2014 at 7:49 AM, Markus Neteler wrote: > > On Sat, Jun 14, 2014 at 9:21 AM, Sandra MacFadyen > wrote: > >> I am using r.diversity (GRASS GIS 7.0.0svn build 60785 win32) through > >> R (R version 3.0.2 win32) on Windows 7 64bit. > ... > >> However, when running the same code on a larger image (cells=6746328) > >> from my own location, although it reports Done, no rasters are > >> created. If I subset the image > >> (cells=1632830) and run it again its works (see # sub2Kruger # code and > results below). > >> So I'm guessing it is a memory issue? > ... > > ... it consumes a lot of memory... will check on a bigger machine, > > perhaps a memory leak. > > The assumption turned out to be right and I think we got it today! > > Vaclav Petras checked it and discovered an "unfortunate" memory allocation > which he fixed in r.li.* in revision > http://trac.osgeo.org/grass/changeset/61812 ("r.li: fix memory handling > (memory leak in avl_to_array function))". > > Now r.li has become very fast, on my laptop: > > GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 > res=10 -a ... > rows: 1355 > cols: 1503 > cells: 2036565 > > GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o > input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 > output=lsat5_1987_div__simpson_size_5.0 > r.li.simpson complete. Raster map > created. > --> 29.32 seconds > > or with a simulated higher resolution: > > GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 > res=5 -aprojection: 99 (Lambert Conformal Conic) ... > rows: 2708 > cols: 3005 > cells: 8137540 > > GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o > input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 > output=lsat5_1987_div__simpson_size_5.0 > r.li.simpson complete. Raster map > created. > --> 227.37 seconds (used to be > 2 hours) > > So, to grab this improvement for Windows, grab the version from here: > http://wingrass.fsv.cvut.cz/grass71/ > > (or via OSGeo4W installer). Be sure that the revision is at least > r61812 which is indicated in the file name. > > Please let us know if all works to avoid that the change has any negative > impact. > Tests here did not show any changes in the output except for the speed > improvement and solved memory leak. > > Subsequently also r.diversity should behave now. > > I'll backport it to GRASS 7.0 release branch after some testing. > > Markus > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peifer at gmx.eu Wed Sep 17 23:41:46 2014 From: peifer at gmx.eu (Hermann Peifer) Date: Thu, 18 Sep 2014 08:41:46 +0200 Subject: [GRASS-user] GRASS7: problems with WMS Message-ID: <541A7EAA.8080808@gmx.eu> Hi All, I am trying to load a WMS using GRASS7, which I compiled from svn/release branch. Connecting to the WMServer, selecting and adding a layer works fine, but I do not get any image into the map display. The GUI's Map Console reports: Unable to determine region, m.proj failed The console, from which I started the GUI says: ERROR 4: `/path/to/mapset/.tmp/hostname/3199.12' does not exist in the file system, and is not recognised as a supported dataset name. After noting the error related to region/m.proj, I tried both: to load a WMS in EPSG:3035 into my LAEA location and to load another WMS in EPSG:4326 into my WGS84 location, whithout any luck. Any hints? Thanks in advance, Hermann From neteler at osgeo.org Thu Sep 18 05:31:28 2014 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 18 Sep 2014 14:31:28 +0200 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: <53FE3E5C.1050907@wildintellect.com> References: <53FE3E5C.1050907@wildintellect.com> Message-ID: On Wed, Aug 27, 2014 at 10:23 PM, Alex Mandel wrote: > libgdal1h does not exist in stock Ubuntu 12.04 but does in 14.04 > It was a name change introduced in Debian/UbuntuGIS to deal with some > libtiff build issue. > > In order for the package to work it needs to say libgdal1 || libgdal1h > (basically OR). ... was this ever implemented in the control file of the PPA? Still problems are reported. thanks, Markus From mohammedrashadkm at gmail.com Thu Sep 18 05:45:29 2014 From: mohammedrashadkm at gmail.com (Rashad M) Date: Thu, 18 Sep 2014 18:15:29 +0530 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: References: <53FE3E5C.1050907@wildintellect.com> Message-ID: Yes, I had this in control file. libgdal-dev | libgdal1-dev, http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/view/head:/control On Thu, Sep 18, 2014 at 6:01 PM, Markus Neteler wrote: > On Wed, Aug 27, 2014 at 10:23 PM, Alex Mandel > wrote: > > libgdal1h does not exist in stock Ubuntu 12.04 but does in 14.04 > > It was a name change introduced in Debian/UbuntuGIS to deal with some > > libtiff build issue. > > > > In order for the package to work it needs to say libgdal1 || libgdal1h > > (basically OR). > > ... was this ever implemented in the control file of the PPA? > Still problems are reported. > > thanks, > Markus > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From mohammedrashadkm at gmail.com Thu Sep 18 05:58:50 2014 From: mohammedrashadkm at gmail.com (Rashad M) Date: Thu, 18 Sep 2014 18:28:50 +0530 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: References: <53FE3E5C.1050907@wildintellect.com> Message-ID: Hi Markus, Pushed the proposed changes and waiting for a clean build. https://code.launchpad.net/~grass/+recipe/grass70-release On Thu, Sep 18, 2014 at 6:15 PM, Rashad M wrote: > Yes, > > I had this in control file. > > libgdal-dev | libgdal1-dev, > > http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/view/head:/control > > > > > On Thu, Sep 18, 2014 at 6:01 PM, Markus Neteler wrote: > >> On Wed, Aug 27, 2014 at 10:23 PM, Alex Mandel >> wrote: >> > libgdal1h does not exist in stock Ubuntu 12.04 but does in 14.04 >> > It was a name change introduced in Debian/UbuntuGIS to deal with some >> > libtiff build issue. >> > >> > In order for the package to work it needs to say libgdal1 || libgdal1h >> > (basically OR). >> >> ... was this ever implemented in the control file of the PPA? >> Still problems are reported. >> >> thanks, >> Markus >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > > -- > Regards, > Rashad > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From peifer at gmx.eu Thu Sep 18 10:24:28 2014 From: peifer at gmx.eu (Hermann Peifer) Date: Thu, 18 Sep 2014 19:24:28 +0200 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: <541A7EAA.8080808@gmx.eu> References: <541A7EAA.8080808@gmx.eu> Message-ID: <541B154C.1030708@gmx.eu> Just to add that I continue trying to load the WMS, without success, though. My current error message is: ERROR 4: `/home/peifer/grassdata/laea/test/.tmp/whitefish/17189.4' does not exist in the file system, and is not recognised as a supported dataset name. When looking into .tmp/whitefish, I see a series of 17189.* files, but obviously not 17189.4: [GRASS:test]> ls -l .tmp/whitefish/ total 1184 -rw-r--r-- 1 peifer mtr 1144239 Sep 18 19:18 17189.0.ppm -rw-r--r-- 1 peifer mtr 9125 Sep 18 19:10 17189.10 -rw-r--r-- 1 peifer mtr 8903 Sep 18 19:10 17189.11 -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.5 -rw-r--r-- 1 peifer mtr 9125 Sep 18 19:10 17189.6 -rw-r--r-- 1 peifer mtr 8903 Sep 18 19:10 17189.7 -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.8 -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.9 On 2014-09-18 8:41, Hermann Peifer wrote: > Hi All, > > I am trying to load a WMS using GRASS7, which I compiled from > svn/release branch. > > Connecting to the WMServer, selecting and adding a layer works fine, but > I do not get any image into the map display. > > The GUI's Map Console reports: > Unable to determine region, m.proj failed > > The console, from which I started the GUI says: > ERROR 4: `/path/to/mapset/.tmp/hostname/3199.12' does not exist in the > file system, and is not recognised as a supported dataset name. > > After noting the error related to region/m.proj, I tried both: to load a > WMS in EPSG:3035 into my LAEA location and to load another WMS in > EPSG:4326 into my WGS84 location, whithout any luck. > > Any hints? > > Thanks in advance, Hermann From tech_dev at wildintellect.com Thu Sep 18 10:27:48 2014 From: tech_dev at wildintellect.com (Alex Mandel) Date: Thu, 18 Sep 2014 10:27:48 -0700 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: References: <53FE3E5C.1050907@wildintellect.com> Message-ID: <541B1614.5020808@wildintellect.com> Hmm, I don't think libgdal1h and -dev are the same thing. libgdal1h is a dep of libgdal-dev and gdalbin. libgdal1h is the library and -dev is the dev files that go with the library. There is no libgdal1h-dev (it's libgdal-dev afaik) I think the issue is that on ubuntu 12.04 the stock libgdal1-dev http://packages.ubuntu.com/precise/libgdal1-dev On stock systems libgdal-dev is an alias for libgdal1-dev I'm not really sure what the fix here is, other than making the grass ppa depend on the ubuntugis ppa, or getting the grass70 package into ubuntugis and telling people to use that one. Or to copy newer gdal over from ubuntugis into the grass ppa for Precise. Thanks, Alex On 09/18/2014 05:58 AM, Rashad M wrote: > Hi Markus, > > Pushed the proposed changes and waiting for a clean build. > > https://code.launchpad.net/~grass/+recipe/grass70-release > > On Thu, Sep 18, 2014 at 6:15 PM, Rashad M > wrote: > >> Yes, >> >> I had this in control file. >> >> libgdal-dev | libgdal1-dev, >> >> http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/view/head:/control >> >> >> >> >> On Thu, Sep 18, 2014 at 6:01 PM, Markus Neteler wrote: >> >>> On Wed, Aug 27, 2014 at 10:23 PM, Alex Mandel >>> wrote: >>>> libgdal1h does not exist in stock Ubuntu 12.04 but does in 14.04 >>>> It was a name change introduced in Debian/UbuntuGIS to deal with some >>>> libtiff build issue. >>>> >>>> In order for the package to work it needs to say libgdal1 || libgdal1h >>>> (basically OR). >>> >>> ... was this ever implemented in the control file of the PPA? >>> Still problems are reported. >>> >>> thanks, >>> Markus >>> _______________________________________________ >>> grass-user mailing list >>> grass-user at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> >> >> -- >> Regards, >> Rashad >> > > > > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > From stepan.turek at seznam.cz Thu Sep 18 13:31:53 2014 From: stepan.turek at seznam.cz (=?utf-8?q?=C5=A0t=C4=9Bp=C3=A1n_Turek?=) Date: Thu, 18 Sep 2014 22:31:53 +0200 (CEST) Subject: [GRASS-user] GRASS7: problems with WMS References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> Message-ID: Hi Hermann, would be possible to send me the WMS service URL you are trying to connect? Best Stepan ---------- P?vodn? zpr?va ---------- Od: Hermann Peifer Komu: GRASS user list Datum: 18. 9. 2014 19:24:44 P?edm?t: Re: [GRASS-user] GRASS7: problems with WMS "Just to add that I continue trying to load the WMS, without success, though. My current error message is: ERROR 4: `/home/peifer/grassdata/laea/test/.tmp/whitefish/17189.4' does not exist in the file system, and is not recognised as a supported dataset name. When looking into .tmp/whitefish, I see a series of 17189.* files, but obviously not 17189.4: [GRASS:test]> ls -l .tmp/whitefish/ total 1184 -rw-r--r-- 1 peifer mtr 1144239 Sep 18 19:18 17189.0.ppm -rw-r--r-- 1 peifer mtr 9125 Sep 18 19:10 17189.10 -rw-r--r-- 1 peifer mtr 8903 Sep 18 19:10 17189.11 -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.5 -rw-r--r-- 1 peifer mtr 9125 Sep 18 19:10 17189.6 -rw-r--r-- 1 peifer mtr 8903 Sep 18 19:10 17189.7 -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.8 -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.9 On 2014-09-18 8:41, Hermann Peifer wrote: > Hi All, > > I am trying to load a WMS using GRASS7, which I compiled from > svn/release branch. > > Connecting to the WMServer, selecting and adding a layer works fine, but > I do not get any image into the map display. > > The GUI's Map Console reports: > Unable to determine region, m.proj failed > > The console, from which I started the GUI says: > ERROR 4: `/path/to/mapset/.tmp/hostname/3199.12' does not exist in the > file system, and is not recognised as a supported dataset name. > > After noting the error related to region/m.proj, I tried both: to load a > WMS in EPSG:3035 into my LAEA location and to load another WMS in > EPSG:4326 into my WGS84 location, whithout any luck. > > Any hints? > > Thanks in advance, Hermann _______________________________________________ grass-user mailing list grass-user at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user" -------------- next part -------------- An HTML attachment was scrubbed... URL: From tea3rd at gmail.com Thu Sep 18 19:36:26 2014 From: tea3rd at gmail.com (Thomas Adams) Date: Thu, 18 Sep 2014 19:36:26 -0700 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: <541B1614.5020808@wildintellect.com> References: <53FE3E5C.1050907@wildintellect.com> <541B1614.5020808@wildintellect.com> Message-ID: Rashad, I've only built from source on Ubuntu -- which has been unproblematic for me; I'm using 14.04 currently with GRASS 7.0beta3. Here is what I do: (1) sudo apt-get install \ build-essential \ make flex bison gcc libgcc1 g++ cmake ccache \ python python-dev python-qt4 python-qt4-dev \ python-opengl \ python-wxversion python-wxtools python-wxgtk2.8 \ python-dateutil libgsl0-dev python-numpy \ wx2.8-headers wx-common libwxgtk2.8-dev libwxgtk2.8-dbg \ libwxbase2.8-dev libwxbase2.8-dbg \ libncurses5-dev \ zlib1g-dev gettext \ libtiff4-dev \ tcl8.5-dev tk8.5-dev \ libcairo2 libcairo2-dev \ sqlite3 libsqlite3-dev \ libpq-dev \ libreadline6 libreadline6-dev libfreetype6-dev \ txt2tags \ libfftw3-3 libfftw3-dev \ libqt4-core libqt4-dbg libqt4-dev libqt4-gui libqt4-sql libqt4-qt3support \ lsb-qt4 qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig \ libapt-pkg-perl resolvconf \ libjasper-dev \ ruby \ subversion \ libavcodec-dev \ libxmu-dev \ libavformat-dev libswscale-dev \ checkinstall \ libglu1-mesa-dev libxmu-dev It's possible other libs should be included. (2) ./configure --with-opengl-includes=/usr/include/GL --enable-64bit --with-cxx --with-readline --with-freetype=yes --with-freetype-includes=/usr/include/freetype2/ --enable-largefile=yes --with-opengl-libs=/usr/lib --with-geos=/usr/local/bin/geos-config --with-tcltk-includes=/usr/local/include --with-tcltk-libs=/usr/local/lib --with-sqlite --with-sqlite-includes=/usr/local/include --with-sqlite-libs=/usr/local/lib --with-postgres --with-postgres-includes=/usr/local/pgsql/include --with-postgres-libs=/usr/local/pgsql/lib --with-python --with-wxwidgets=/usr/bin/wx-config --with-proj-includes=/usr/local/include --with-proj-libs=/usr/local/lib --with-proj-share=/usr/local/share/proj --with-gdal=/usr/local/bin/gdal-config --with-proj-includes=/usr/local/include --with-proj-libs=/usr/local/lib --with-netcdf=/usr/local/bin/nc-config --with-blas-libs=/usr/local/lib --with-blas-includes=/usr/local/include/liblas --with-liblas=/usr/local/bin/liblas-config (3) make (4) sudo make install And that's it! Hope this helps... Cheers! Tom On Thu, Sep 18, 2014 at 10:27 AM, Alex Mandel wrote: > Hmm, I don't think libgdal1h and -dev are the same thing. libgdal1h is a > dep of libgdal-dev and gdalbin. libgdal1h is the library and -dev is the > dev files that go with the library. > > There is no libgdal1h-dev (it's libgdal-dev afaik) > > I think the issue is that on ubuntu 12.04 the stock libgdal1-dev > http://packages.ubuntu.com/precise/libgdal1-dev > On stock systems libgdal-dev is an alias for libgdal1-dev > > I'm not really sure what the fix here is, other than making the grass > ppa depend on the ubuntugis ppa, or getting the grass70 package into > ubuntugis and telling people to use that one. Or to copy newer gdal over > from ubuntugis into the grass ppa for Precise. > > Thanks, > Alex > > On 09/18/2014 05:58 AM, Rashad M wrote: > > Hi Markus, > > > > Pushed the proposed changes and waiting for a clean build. > > > > https://code.launchpad.net/~grass/+recipe/grass70-release > > > > On Thu, Sep 18, 2014 at 6:15 PM, Rashad M > > wrote: > > > >> Yes, > >> > >> I had this in control file. > >> > >> libgdal-dev | libgdal1-dev, > >> > >> > http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/view/head:/control > >> > >> > >> > >> > >> On Thu, Sep 18, 2014 at 6:01 PM, Markus Neteler > wrote: > >> > >>> On Wed, Aug 27, 2014 at 10:23 PM, Alex Mandel > >>> wrote: > >>>> libgdal1h does not exist in stock Ubuntu 12.04 but does in 14.04 > >>>> It was a name change introduced in Debian/UbuntuGIS to deal with some > >>>> libtiff build issue. > >>>> > >>>> In order for the package to work it needs to say libgdal1 || libgdal1h > >>>> (basically OR). > >>> > >>> ... was this ever implemented in the control file of the PPA? > >>> Still problems are reported. > >>> > >>> thanks, > >>> Markus > >>> _______________________________________________ > >>> grass-user mailing list > >>> grass-user at lists.osgeo.org > >>> http://lists.osgeo.org/mailman/listinfo/grass-user > >>> > >> > >> > >> > >> -- > >> Regards, > >> Rashad > >> > > > > > > > > > > > > _______________________________________________ > > grass-user mailing list > > grass-user at lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-user > > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peifer at gmx.eu Thu Sep 18 22:12:04 2014 From: peifer at gmx.eu (Hermann Peifer) Date: Fri, 19 Sep 2014 07:12:04 +0200 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> Message-ID: <541BBB24.5090903@gmx.eu> As far as I tried out: the error occurs for any WMS in any projection, including all the built-in servers. It looks like no other GRASS7 user ever had the same issue, which is surprising. From the error message, I assume that soemthing is going systematically wrong with the numbering of the files in the .tmp directory. I am currently trying with layer: "WMS Global Mosaic, pan sharpened" from the built-in server list: http://onearth.jpl.nasa.gov/wms.cgi The result is: ERROR 4: `/home/peifer/grassdata/wgs84/PERMANENT/.tmp/whitefish/32754.4' does not exist in the file system, and is not recognised as a supported dataset name. File 32754.4 does indeed not exist. See below. Hermann [GRASS:PERMANENT]> file .tmp/whitefish/* .tmp/whitefish/32754.0.ppm: Netpbm PPM "rawbits" image data .tmp/whitefish/32754.10: XML document text .tmp/whitefish/32754.11: XML document text .tmp/whitefish/32754.5: XML document text .tmp/whitefish/32754.6: XML document text .tmp/whitefish/32754.7: XML document text .tmp/whitefish/32754.8: HTML document text .tmp/whitefish/32754.9: XML document text On 2014-09-18 22:31, ?t?p?n Turek wrote: > Hi Hermann, > > would be possible to send me the WMS service URL you are trying to connect? > > Best > Stepan > > > ---------- P?vodn? zpr?va ---------- > Od: Hermann Peifer > Komu: GRASS user list > Datum: 18. 9. 2014 19:24:44 > P?edm?t: Re: [GRASS-user] GRASS7: problems with WMS > > > Just to add that I continue trying to load the WMS, without success, > though. My current error message is: > > ERROR 4: `/home/peifer/grassdata/laea/test/.tmp/whitefish/17189.4' does > not exist in the file system, and is not recognised as a supported > dataset name. > > When looking into .tmp/whitefish, I see a series of 17189.* files, but > obviously not 17189.4: > > [GRASS:test]> ls -l .tmp/whitefish/ > total 1184 > -rw-r--r-- 1 peifer mtr 1144239 Sep 18 19:18 17189.0.ppm > -rw-r--r-- 1 peifer mtr 9125 Sep 18 19:10 17189.10 > -rw-r--r-- 1 peifer mtr 8903 Sep 18 19:10 17189.11 > -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.5 > -rw-r--r-- 1 peifer mtr 9125 Sep 18 19:10 17189.6 > -rw-r--r-- 1 peifer mtr 8903 Sep 18 19:10 17189.7 > -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.8 > -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.9 > > > > On 2014-09-18 8:41, Hermann Peifer wrote: > > Hi All, > > > > I am trying to load a WMS using GRASS7, which I compiled from > > svn/release branch. > > > > Connecting to the WMServer, selecting and adding a layer works > fine, but > > I do not get any image into the map display. > > > > The GUI's Map Console reports: > > Unable to determine region, m.proj failed > > > > The console, from which I started the GUI says: > > ERROR 4: `/path/to/mapset/.tmp/hostname/3199.12' does not exist > in the > > file system, and is not recognised as a supported dataset name. > > > > After noting the error related to region/m.proj, I tried both: to > load a > > WMS in EPSG:3035 into my LAEA location and to load another WMS in > > EPSG:4326 into my WGS84 location, whithout any luck. > > > > Any hints? > > > > Thanks in advance, Hermann > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > From sawdef at hotmail.com Fri Sep 19 00:25:35 2014 From: sawdef at hotmail.com (Sofiane Soulfly) Date: Fri, 19 Sep 2014 09:25:35 +0200 Subject: [GRASS-user] Grass and Java Message-ID: Hi, except http://grasswiki.osgeo.org/wiki/GRASS_and_Java and https://code.google.com/p/vtk-grass-bridge/wiki/HowToCompile, are there any other resources about calling Grass from Java? Thank you, Regards, SB From mohammedrashadkm at gmail.com Fri Sep 19 01:18:36 2014 From: mohammedrashadkm at gmail.com (Rashad M) Date: Fri, 19 Sep 2014 13:48:36 +0530 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: References: <53FE3E5C.1050907@wildintellect.com> <541B1614.5020808@wildintellect.com> Message-ID: Hello Thomas, On Fri, Sep 19, 2014 at 8:06 AM, Thomas Adams wrote: > Rashad, > > I've only built from source on Ubuntu -- which has been unproblematic for > me; I'm using 14.04 currently with GRASS 7.0beta3. Here is what I do: > Is it problematic with Ubuntu 14.04 only or also on 12.04? > > (1) > > sudo apt-get install \ > build-essential \ > make flex bison gcc libgcc1 g++ cmake ccache \ > python python-dev python-qt4 python-qt4-dev \ > python-opengl \To > python-wxversion python-wxtools python-wxgtk2.8 \ > python-dateutil libgsl0-dev python-numpy \ > wx2.8-headers wx-common libwxgtk2.8-dev libwxgtk2.8-dbg \ > libwxbase2.8-dev libwxbase2.8-dbg \ > libncurses5-dev \ > zlib1g-dev gettext \ > libtiff4-dev \ > tcl8.5-dev tk8.5-dev \ > libcairo2 libcairo2-dev \ > sqlite3 libsqlite3-dev \ > libpq-dev \ > libreadline6 libreadline6-dev libfreetype6-dev \ > txt2tags \ > libfftw3-3 libfftw3-dev \ > libqt4-core libqt4-dbg libqt4-dev libqt4-gui libqt4-sql libqt4-qt3support > \ > lsb-qt4 qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig \ > libapt-pkg-perl resolvconf \ > libjasper-dev \ > ruby \ > subversion \ > libavcodec-dev \ > libxmu-dev \ > libavformat-dev libswscale-dev \ > checkinstall \ > libglu1-mesa-dev libxmu-dev > > It's possible other libs should be included. > > (2) > > ./configure --with-opengl-includes=/usr/include/GL --enable-64bit > --with-cxx --with-readline --with-freetype=yes > --with-freetype-includes=/usr/include/freetype2/ --enable-largefile=yes > --with-opengl-libs=/usr/lib --with-geos=/usr/local/bin/geos-config > --with-tcltk-includes=/usr/local/include --with-tcltk-libs=/usr/local/lib > --with-sqlite --with-sqlite-includes=/usr/local/include > --with-sqlite-libs=/usr/local/lib --with-postgres > --with-postgres-includes=/usr/local/pgsql/include > --with-postgres-libs=/usr/local/pgsql/lib --with-python > --with-wxwidgets=/usr/bin/wx-config --with-proj-includes=/usr/local/include > --with-proj-libs=/usr/local/lib --with-proj-share=/usr/local/share/proj > --with-gdal=/usr/local/bin/gdal-config > --with-proj-includes=/usr/local/include --with-proj-libs=/usr/local/lib > --with-netcdf=/usr/local/bin/nc-config --with-blas-libs=/usr/local/lib > --with-blas-includes=/usr/local/include/liblas > --with-liblas=/usr/local/bin/liblas-config > > (3) make > > (4) sudo make install > > And that's it! > > Hope this helps... > > Cheers! > Tom > > > > > > > On Thu, Sep 18, 2014 at 10:27 AM, Alex Mandel > wrote: > >> Hmm, I don't think libgdal1h and -dev are the same thing. libgdal1h is a >> dep of libgdal-dev and gdalbin. libgdal1h is the library and -dev is the >> dev files that go with the library. >> >> There is no libgdal1h-dev (it's libgdal-dev afaik) >> >> I think the issue is that on ubuntu 12.04 the stock libgdal1-dev >> http://packages.ubuntu.com/precise/libgdal1-dev >> On stock systems libgdal-dev is an alias for libgdal1-dev >> >> I'm not really sure what the fix here is, other than making the grass >> ppa depend on the ubuntugis ppa, or getting the grass70 package into >> ubuntugis and telling people to use that one. Or to copy newer gdal over >> from ubuntugis into the grass ppa for Precise. >> >> Thanks, >> Alex >> >> On 09/18/2014 05:58 AM, Rashad M wrote: >> > Hi Markus, >> > >> > Pushed the proposed changes and waiting for a clean build. >> > >> > https://code.launchpad.net/~grass/+recipe/grass70-release >> > >> > On Thu, Sep 18, 2014 at 6:15 PM, Rashad M >> > wrote: >> > >> >> Yes, >> >> >> >> I had this in control file. >> >> >> >> libgdal-dev | libgdal1-dev, >> >> >> >> >> http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/view/head:/control >> >> >> >> >> >> >> >> >> >> On Thu, Sep 18, 2014 at 6:01 PM, Markus Neteler >> wrote: >> >> >> >>> On Wed, Aug 27, 2014 at 10:23 PM, Alex Mandel >> >>> wrote: >> >>>> libgdal1h does not exist in stock Ubuntu 12.04 but does in 14.04 >> >>>> It was a name change introduced in Debian/UbuntuGIS to deal with some >> >>>> libtiff build issue. >> >>>> >> >>>> In order for the package to work it needs to say libgdal1 || >> libgdal1h >> >>>> (basically OR). >> >>> >> >>> ... was this ever implemented in the control file of the PPA? >> >>> Still problems are reported. >> >>> >> >>> thanks, >> >>> Markus >> >>> _______________________________________________ >> >>> grass-user mailing list >> >>> grass-user at lists.osgeo.org >> >>> http://lists.osgeo.org/mailman/listinfo/grass-user >> >>> >> >> >> >> >> >> >> >> -- >> >> Regards, >> >> Rashad >> >> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > grass-user mailing list >> > grass-user at lists.osgeo.org >> > http://lists.osgeo.org/mailman/listinfo/grass-user >> > >> >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> > > > -- Regards, Rashad -------------- next part -------------- An HTML attachment was scrubbed... URL: From peifer at gmx.eu Fri Sep 19 04:49:33 2014 From: peifer at gmx.eu (peifer) Date: Fri, 19 Sep 2014 04:49:33 -0700 (PDT) Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: <541BBB24.5090903@gmx.eu> References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> Message-ID: <1411127373119-5162883.post@n6.nabble.com> Maybe this helps to locate the problem. If not: I simply have to give up loading a WMS with GRASS7. Hermann [GRASS6.4.5svn]> r.in.wms map=http://wms.cuzk.cz/wms.asp out=wms layers=kn srs=EPSG:3035 format=png Calculating tiles Requesting 30 tiles. Downloading tiles ... [GRASS7.0.0svn]> r.in.wms url=http://wms.cuzk.cz/wms.asp out=wms layers=kn srs=3035 format=png ERROR: Sorry, is not a valid parameter ERROR: Unable to determine region, m.proj failed -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GRASS7-problems-with-WMS-tp5162533p5162883.html Sent from the Grass - Users mailing list archive at Nabble.com. From wenzeslaus at gmail.com Fri Sep 19 06:25:12 2014 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Fri, 19 Sep 2014 09:25:12 -0400 Subject: [GRASS-user] Grass and Java In-Reply-To: References: Message-ID: On Fri, Sep 19, 2014 at 3:25 AM, Sofiane Soulfly wrote: > Hi, > > except http://grasswiki.osgeo.org/wiki/GRASS_and_Java and > https://code.google.com/p/vtk-grass-bridge/wiki/HowToCompile, are there > any other resources about calling Grass from Java? > > Not any GRASS official resources I think but you can try to find things in gvSIG (SEXTANTE) and uDig (JGRASS) world. https://code.google.com/p/jgrass/ Try to share your progress if possible, there could be more people interested. Vaclav > > Thank you, > > Regards, > > SB > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kratochanna at gmail.com Fri Sep 19 06:33:29 2014 From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=) Date: Fri, 19 Sep 2014 09:33:29 -0400 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: <541BBB24.5090903@gmx.eu> References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> Message-ID: On Fri, Sep 19, 2014 at 1:12 AM, Hermann Peifer wrote: > > As far as I tried out: the error occurs for any WMS in any projection, > including all the built-in servers. It looks like no other GRASS7 user ever > had the same issue, which is surprising. From the error message, I assume > that soemthing is going systematically wrong with the numbering of the > files in the .tmp directory. > > I am currently trying with layer: "WMS Global Mosaic, pan sharpened" from > the built-in server list: http://onearth.jpl.nasa.gov/wms.cgi > > The result is: > > ERROR 4: `/home/peifer/grassdata/wgs84/PERMANENT/.tmp/whitefish/32754.4' > does not exist in the file system, and is not recognised as a supported > dataset name. > I get the same, however in the gui console I also get: WMS server error: This server no longer provides full WMS services! so this service doesn't work any more. Anna > File 32754.4 does indeed not exist. See below. > > Hermann > > [GRASS:PERMANENT]> file .tmp/whitefish/* > .tmp/whitefish/32754.0.ppm: Netpbm PPM "rawbits" image data > .tmp/whitefish/32754.10: XML document text > .tmp/whitefish/32754.11: XML document text > .tmp/whitefish/32754.5: XML document text > .tmp/whitefish/32754.6: XML document text > .tmp/whitefish/32754.7: XML document text > .tmp/whitefish/32754.8: HTML document text > .tmp/whitefish/32754.9: XML document text > > > > > > > On 2014-09-18 22:31, ?t?p?n Turek wrote: > >> Hi Hermann, >> >> would be possible to send me the WMS service URL you are trying to >> connect? >> >> Best >> Stepan >> >> >> ---------- P?vodn? zpr?va ---------- >> Od: Hermann Peifer >> Komu: GRASS user list >> Datum: 18. 9. 2014 19:24:44 >> P?edm?t: Re: [GRASS-user] GRASS7: problems with WMS >> >> >> Just to add that I continue trying to load the WMS, without success, >> though. My current error message is: >> >> ERROR 4: `/home/peifer/grassdata/laea/test/.tmp/whitefish/17189.4' >> does >> not exist in the file system, and is not recognised as a supported >> dataset name. >> >> When looking into .tmp/whitefish, I see a series of 17189.* files, but >> obviously not 17189.4: >> >> [GRASS:test]> ls -l .tmp/whitefish/ >> total 1184 >> -rw-r--r-- 1 peifer mtr 1144239 Sep 18 19:18 17189.0.ppm >> -rw-r--r-- 1 peifer mtr 9125 Sep 18 19:10 17189.10 >> -rw-r--r-- 1 peifer mtr 8903 Sep 18 19:10 17189.11 >> -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.5 >> -rw-r--r-- 1 peifer mtr 9125 Sep 18 19:10 17189.6 >> -rw-r--r-- 1 peifer mtr 8903 Sep 18 19:10 17189.7 >> -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.8 >> -rw-r--r-- 1 peifer mtr 574 Sep 18 19:10 17189.9 >> >> >> >> On 2014-09-18 8:41, Hermann Peifer wrote: >> > Hi All, >> > >> > I am trying to load a WMS using GRASS7, which I compiled from >> > svn/release branch. >> > >> > Connecting to the WMServer, selecting and adding a layer works >> fine, but >> > I do not get any image into the map display. >> > >> > The GUI's Map Console reports: >> > Unable to determine region, m.proj failed >> > >> > The console, from which I started the GUI says: >> > ERROR 4: `/path/to/mapset/.tmp/hostname/3199.12' does not exist >> in the >> > file system, and is not recognised as a supported dataset name. >> > >> > After noting the error related to region/m.proj, I tried both: to >> load a >> > WMS in EPSG:3035 into my LAEA location and to load another WMS in >> > EPSG:4326 into my WGS84 location, whithout any luck. >> > >> > Any hints? >> > >> > Thanks in advance, Hermann >> >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user >> >> > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kratochanna at gmail.com Fri Sep 19 07:02:36 2014 From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=) Date: Fri, 19 Sep 2014 10:02:36 -0400 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: <1411127373119-5162883.post@n6.nabble.com> References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> <1411127373119-5162883.post@n6.nabble.com> Message-ID: On Fri, Sep 19, 2014 at 7:49 AM, peifer wrote: > Maybe this helps to locate the problem. If not: I simply have to give up > loading a WMS with GRASS7. Hermann > > [GRASS6.4.5svn]> r.in.wms map=http://wms.cuzk.cz/wms.asp out=wms layers=kn > srs=EPSG:3035 format=png > Calculating tiles > Requesting 30 tiles. > Downloading tiles > ... > > [GRASS7.0.0svn]> r.in.wms url=http://wms.cuzk.cz/wms.asp out=wms layers=kn > srs=3035 format=png > > ERROR: Sorry, is not a valid parameter > ERROR: Unable to determine region, m.proj failed > > I have no idea, the probably refers to m.proj but m.proj has input parameter. Could you try to run only m.proj (take some example from manual), if it works? Anna > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/GRASS7-problems-with-WMS-tp5162533p5162883.html > Sent from the Grass - Users mailing list archive at Nabble.com. > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peifer at gmx.eu Fri Sep 19 10:18:27 2014 From: peifer at gmx.eu (Hermann Peifer) Date: Fri, 19 Sep 2014 19:18:27 +0200 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> <1411127373119-5162883.post@n6.nabble.com> Message-ID: <541C6563.1090108@gmx.eu> On 2014-09-19 16:02, Anna Petr??ov? wrote: > > > I have no idea, the probably refers to m.proj but m.proj has > input parameter. Could you try to run only m.proj (take some example > from manual), if it works? > Either I am doing something terribly stupid, or m.proj is *really* broken in the release branch. I wonder what m.proj or cs2cs is expected to do with colors: [color=style] and [color=name]. Furthermore: no coordinate input seems to be needed, see [1]. This parameter list looks like a joke, to say it in a friendly way. I "fixed" all of my earlier reported issues related to m.proj and loading a WMS by moving from the GRASS7 release branch to svn/trunk. In trunk, m.proj has a reasonable parameter list [2] and loading the WMS works as expected. Hermann [1] Welcome to GRASS 7.0.0svn (r61824) ... [GRASS:test]> m.proj --h Description: Converts coordinates from one projection to another (cs2cs frontend). Keywords: miscellaneous, projection Usage: m.proj [-iodec] [color=style] [output=name] [separator=character] [color=name] [proj_in=string] [proj_out=string] [--overwrite] [--help] [--verbose] [--quiet] [2] Welcome to GRASS 7.1.svn (r62036) ... [GRASS:PERMANENT]> m.proj --help Description: Converts coordinates from one projection to another (cs2cs frontend). Keywords: miscellaneous, projection Usage: m.proj [-iodec] [coordinates=east,north] [input=name] [output=name] [separator=character] [proj_in=string] [proj_out=string] [--overwrite] [--help] [--verbose] [--quiet] From kratochanna at gmail.com Fri Sep 19 10:29:32 2014 From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=) Date: Fri, 19 Sep 2014 13:29:32 -0400 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: <541C6563.1090108@gmx.eu> References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> <1411127373119-5162883.post@n6.nabble.com> <541C6563.1090108@gmx.eu> Message-ID: On Fri, Sep 19, 2014 at 1:18 PM, Hermann Peifer wrote: > On 2014-09-19 16:02, Anna Petr??ov? wrote: > >> >> >> I have no idea, the probably refers to m.proj but m.proj has >> input parameter. Could you try to run only m.proj (take some example >> from manual), if it works? >> >> > Either I am doing something terribly stupid, or m.proj is *really* broken > in the release branch. I wonder what m.proj or cs2cs is expected to do with > colors: [color=style] and [color=name]. Furthermore: no coordinate input > seems to be needed, see [1]. This parameter list looks like a joke, to say > it in a friendly way. > yes, that's pretty funny. Do you have any local changes (svn diff)? I looked in the recent changes but there is nothing suggesting this error. > I "fixed" all of my earlier reported issues related to m.proj and loading > a WMS by moving from the GRASS7 release branch to svn/trunk. In trunk, > m.proj has a reasonable parameter list [2] and loading the WMS works as > expected. > > Hermann > > > [1] Welcome to GRASS 7.0.0svn (r61824) > ... > > [GRASS:test]> m.proj --h > > Description: > Converts coordinates from one projection to another (cs2cs frontend). > > Keywords: > miscellaneous, projection > > Usage: > m.proj [-iodec] [color=style] [output=name] [separator=character] > [color=name] [proj_in=string] [proj_out=string] [--overwrite] [--help] > [--verbose] [--quiet] > > > [2] Welcome to GRASS 7.1.svn (r62036) > ... > > [GRASS:PERMANENT]> m.proj --help > > Description: > Converts coordinates from one projection to another (cs2cs frontend). > > Keywords: > miscellaneous, projection > > Usage: > m.proj [-iodec] [coordinates=east,north] [input=name] [output=name] > [separator=character] [proj_in=string] [proj_out=string] [--overwrite] > [--help] [--verbose] [--quiet] > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From peifer at gmx.eu Fri Sep 19 10:44:34 2014 From: peifer at gmx.eu (Hermann Peifer) Date: Fri, 19 Sep 2014 19:44:34 +0200 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> <1411127373119-5162883.post@n6.nabble.com> <541C6563.1090108@gmx.eu> Message-ID: <541C6B82.1090701@gmx.eu> On 2014-09-19 19:29, Anna Petr??ov? wrote: > > > yes, that's pretty funny. Do you have any local changes (svn diff)? I > looked in the recent changes but there is nothing suggesting this error. > > No diff at all. And until yesterday, I did not even know that m.proj existed. Hermann From peifer at gmx.eu Fri Sep 19 10:59:30 2014 From: peifer at gmx.eu (Hermann Peifer) Date: Fri, 19 Sep 2014 19:59:30 +0200 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: <541C6B82.1090701@gmx.eu> References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> <1411127373119-5162883.post@n6.nabble.com> <541C6563.1090108@gmx.eu> <541C6B82.1090701@gmx.eu> Message-ID: <541C6F02.8020405@gmx.eu> On 2014-09-19 19:44, Hermann Peifer wrote: > On 2014-09-19 19:29, Anna Petr??ov? wrote: >> >> >> yes, that's pretty funny. Do you have any local changes (svn diff)? I >> looked in the recent changes but there is nothing suggesting this error. >> >> > > No diff at all. And until yesterday, I did not even know that m.proj > existed. > This might help the initiated to find some bug: diff grass/scripts/m.proj/m.proj.py grass70_release/scripts/m.proj/m.proj.py 38c38 < #% description: '-' for standard input --- > #% description: '-' to read from standard input 96d95 < from grass.script.utils import separator, parse_key_val 162,163c161,162 < ifs = separator(ifs) < ofs = separator(ofs) --- > ifs = grass.separator(ifs) > ofs = grass.separator(ofs) 167c166 < kv = parse_key_val(s) --- > kv = grass.parse_key_val(s) From jwall at ncsu.edu Fri Sep 19 11:30:36 2014 From: jwall at ncsu.edu (John Wall) Date: Fri, 19 Sep 2014 14:30:36 -0400 Subject: [GRASS-user] Minimum fitting ellipse with attributes Message-ID: Hello, I am trying to fit a minimum fitting/bounding ellipse to each polygon in a series of polygons. Ideally the ellipse would also give me attributes such as major and minor axes lengths along with orientation. Is this possible within GRASS 7.0 on a Mac? I cannot seem to find a tool to do this. Thanks, John ------------------------------------------------------------------------------- John Wall Earth Science Ph.D. Student Department of Marine, Earth & Atmospheric Sciences North Carolina State University -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenzeslaus at gmail.com Fri Sep 19 14:35:24 2014 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Fri, 19 Sep 2014 17:35:24 -0400 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: <541C6F02.8020405@gmx.eu> References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> <1411127373119-5162883.post@n6.nabble.com> <541C6563.1090108@gmx.eu> <541C6B82.1090701@gmx.eu> <541C6F02.8020405@gmx.eu> Message-ID: On Fri, Sep 19, 2014 at 1:59 PM, Hermann Peifer wrote: > On 2014-09-19 19:44, Hermann Peifer wrote: > >> On 2014-09-19 19:29, Anna Petr??ov? wrote: >> >>> >>> >>> yes, that's pretty funny. Do you have any local changes (svn diff)? I >>> looked in the recent changes but there is nothing suggesting this error. >>> >>> >>> >> No diff at all. And until yesterday, I did not even know that m.proj >> existed. >> >> > This might help the initiated to find some bug: > > diff grass/scripts/m.proj/m.proj.py grass70_release/scripts/m.proj/ > m.proj.py > > 38c38 > < #% description: '-' for standard input > --- > > #% description: '-' to read from standard input > > 96d95 > < from grass.script.utils import separator, parse_key_val > > 162,163c161,162 > < ifs = separator(ifs) > < ofs = separator(ofs) > --- > > ifs = grass.separator(ifs) > > ofs = grass.separator(ofs) > > 167c166 > < kv = parse_key_val(s) > --- > > kv = grass.parse_key_val(s) > > This cannot cause the problem, so let's try something else. When in GRASS command line do which m.proj Then open the file which it will tell and also make a diff of that file with grass70_release/scripts/m.proj/m.proj.py Afterwards, you can also try to recompile GRASS (make distclean && ./configure ... && make). > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tea3rd at gmail.com Fri Sep 19 19:50:34 2014 From: tea3rd at gmail.com (Thomas Adams) Date: Fri, 19 Sep 2014 22:50:34 -0400 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: References: <53FE3E5C.1050907@wildintellect.com> <541B1614.5020808@wildintellect.com> Message-ID: Rashad I think what I sent you should also work for Ubuntu 12.04 ? I don't see what it should not? Regards, Tom On Fri, Sep 19, 2014 at 4:18 AM, Rashad M wrote: > Hello Thomas, > > On Fri, Sep 19, 2014 at 8:06 AM, Thomas Adams wrote: > >> Rashad, >> >> I've only built from source on Ubuntu -- which has been unproblematic for >> me; I'm using 14.04 currently with GRASS 7.0beta3. Here is what I do: >> > > Is it problematic with Ubuntu 14.04 only or also on 12.04? > >> >> (1) >> >> sudo apt-get install \ >> build-essential \ >> make flex bison gcc libgcc1 g++ cmake ccache \ >> python python-dev python-qt4 python-qt4-dev \ >> python-opengl \To >> >> python-wxversion python-wxtools python-wxgtk2.8 \ >> python-dateutil libgsl0-dev python-numpy \ >> wx2.8-headers wx-common libwxgtk2.8-dev libwxgtk2.8-dbg \ >> libwxbase2.8-dev libwxbase2.8-dbg \ >> libncurses5-dev \ >> zlib1g-dev gettext \ >> libtiff4-dev \ >> tcl8.5-dev tk8.5-dev \ >> libcairo2 libcairo2-dev \ >> sqlite3 libsqlite3-dev \ >> libpq-dev \ >> libreadline6 libreadline6-dev libfreetype6-dev \ >> txt2tags \ >> libfftw3-3 libfftw3-dev \ >> libqt4-core libqt4-dbg libqt4-dev libqt4-gui libqt4-sql >> libqt4-qt3support \ >> lsb-qt4 qt4-designer qt4-dev-tools qt4-doc qt4-qtconfig \ >> libapt-pkg-perl resolvconf \ >> libjasper-dev \ >> ruby \ >> subversion \ >> libavcodec-dev \ >> libxmu-dev \ >> libavformat-dev libswscale-dev \ >> checkinstall \ >> libglu1-mesa-dev libxmu-dev >> >> It's possible other libs should be included. >> >> (2) >> >> ./configure --with-opengl-includes=/usr/include/GL --enable-64bit >> --with-cxx --with-readline --with-freetype=yes >> --with-freetype-includes=/usr/include/freetype2/ --enable-largefile=yes >> --with-opengl-libs=/usr/lib --with-geos=/usr/local/bin/geos-config >> --with-tcltk-includes=/usr/local/include --with-tcltk-libs=/usr/local/lib >> --with-sqlite --with-sqlite-includes=/usr/local/include >> --with-sqlite-libs=/usr/local/lib --with-postgres >> --with-postgres-includes=/usr/local/pgsql/include >> --with-postgres-libs=/usr/local/pgsql/lib --with-python >> --with-wxwidgets=/usr/bin/wx-config --with-proj-includes=/usr/local/include >> --with-proj-libs=/usr/local/lib --with-proj-share=/usr/local/share/proj >> --with-gdal=/usr/local/bin/gdal-config >> --with-proj-includes=/usr/local/include --with-proj-libs=/usr/local/lib >> --with-netcdf=/usr/local/bin/nc-config --with-blas-libs=/usr/local/lib >> --with-blas-includes=/usr/local/include/liblas >> --with-liblas=/usr/local/bin/liblas-config >> >> (3) make >> >> (4) sudo make install >> >> And that's it! >> >> Hope this helps... >> >> Cheers! >> Tom >> >> >> >> >> >> >> On Thu, Sep 18, 2014 at 10:27 AM, Alex Mandel > > wrote: >> >>> Hmm, I don't think libgdal1h and -dev are the same thing. libgdal1h is a >>> dep of libgdal-dev and gdalbin. libgdal1h is the library and -dev is the >>> dev files that go with the library. >>> >>> There is no libgdal1h-dev (it's libgdal-dev afaik) >>> >>> I think the issue is that on ubuntu 12.04 the stock libgdal1-dev >>> http://packages.ubuntu.com/precise/libgdal1-dev >>> On stock systems libgdal-dev is an alias for libgdal1-dev >>> >>> I'm not really sure what the fix here is, other than making the grass >>> ppa depend on the ubuntugis ppa, or getting the grass70 package into >>> ubuntugis and telling people to use that one. Or to copy newer gdal over >>> from ubuntugis into the grass ppa for Precise. >>> >>> Thanks, >>> Alex >>> >>> On 09/18/2014 05:58 AM, Rashad M wrote: >>> > Hi Markus, >>> > >>> > Pushed the proposed changes and waiting for a clean build. >>> > >>> > https://code.launchpad.net/~grass/+recipe/grass70-release >>> > >>> > On Thu, Sep 18, 2014 at 6:15 PM, Rashad M >>> > wrote: >>> > >>> >> Yes, >>> >> >>> >> I had this in control file. >>> >> >>> >> libgdal-dev | libgdal1-dev, >>> >> >>> >> >>> http://bazaar.launchpad.net/~grass/grass/grass70_release_debian/view/head:/control >>> >> >>> >> >>> >> >>> >> >>> >> On Thu, Sep 18, 2014 at 6:01 PM, Markus Neteler >>> wrote: >>> >> >>> >>> On Wed, Aug 27, 2014 at 10:23 PM, Alex Mandel >>> >>> wrote: >>> >>>> libgdal1h does not exist in stock Ubuntu 12.04 but does in 14.04 >>> >>>> It was a name change introduced in Debian/UbuntuGIS to deal with >>> some >>> >>>> libtiff build issue. >>> >>>> >>> >>>> In order for the package to work it needs to say libgdal1 || >>> libgdal1h >>> >>>> (basically OR). >>> >>> >>> >>> ... was this ever implemented in the control file of the PPA? >>> >>> Still problems are reported. >>> >>> >>> >>> thanks, >>> >>> Markus >>> >>> _______________________________________________ >>> >>> grass-user mailing list >>> >>> grass-user at lists.osgeo.org >>> >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >>> >>> >> >>> >> >>> >> >>> >> -- >>> >> Regards, >>> >> Rashad >>> >> >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > grass-user mailing list >>> > grass-user at lists.osgeo.org >>> > http://lists.osgeo.org/mailman/listinfo/grass-user >>> > >>> >>> _______________________________________________ >>> grass-user mailing list >>> grass-user at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >> >> >> > > > -- > Regards, > Rashad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Fri Sep 19 21:03:43 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sat, 20 Sep 2014 06:03:43 +0200 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: <1411127373119-5162883.post@n6.nabble.com> References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> <1411127373119-5162883.post@n6.nabble.com> Message-ID: On Fri, Sep 19, 2014 at 1:49 PM, peifer wrote: > Maybe this helps to locate the problem. If not: I simply have to give up > loading a WMS with GRASS7. Hermann > > [GRASS6.4.5svn]> r.in.wms map=http://wms.cuzk.cz/wms.asp out=wms layers=kn > srs=EPSG:3035 format=png > Calculating tiles > Requesting 30 tiles. > Downloading tiles > ... Fine. > [GRASS7.0.0svn]> r.in.wms url=http://wms.cuzk.cz/wms.asp out=wms layers=kn srs=3035 format=png > ERROR: Sorry, is not a valid parameter > ERROR: Unable to determine region, m.proj failed Which version (g.version -g) do you use? I have made a test: GRASS 7.0.0svn (latlong):~ > g.region n=90 s=-90 w=-180 e=180 res=0:30:00 -pprojection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 90N south: 90S west: 180W east: 180E nsres: 0:30 ewres: 0:30 rows: 360 cols: 720 cells: 259200 GRASS 7.0.0svn (latlong):~ > r.in.wms url=http://watzmann-geog.urz.uni-heidelberg.de/cached/osm layers=osm_auto:all output=osm format=png --o Downloading data from WMS server... Importing raster map into GRASS... WARNING: Raster map already exists and will be overwritten created. WARNING: Raster map is a base map for . Remove forced. GRASS 7.0.0svn (latlong):~ > g.version -g version=7.0.0svn date=2014 revision=62008 build_date=2014-09-17 build_platform=x86_64-unknown-linux-gnu Works ok with the OSM server. Markus From peifer at gmx.eu Fri Sep 19 22:28:04 2014 From: peifer at gmx.eu (Hermann Peifer) Date: Sat, 20 Sep 2014 07:28:04 +0200 Subject: [GRASS-user] GRASS7: problems with WMS In-Reply-To: References: <541A7EAA.8080808@gmx.eu> <541B154C.1030708@gmx.eu> <541BBB24.5090903@gmx.eu> <1411127373119-5162883.post@n6.nabble.com> <541C6563.1090108@gmx.eu> <541C6B82.1090701@gmx.eu> <541C6F02.8020405@gmx.eu> Message-ID: <541D1064.3090406@gmx.eu> On 2014-09-19 23:35, Vaclav Petras wrote: > > > Afterwards, you can also try to recompile GRASS (make distclean && > ./configure ... && make). > I actually did that, without any further investigations. After make distclean, I also used: svn up, which brought me from r61824 to r62033. When comparing the output of make to what I got 12 days ago, I see a difference related to grass70_release/dist.x86_64-unknown-linux-gnu/etc/python/grass/script/utils.py. Maybe this has to do with my problems, maybe not. In any case: all reported issues are gone now and loading a WMS just works as expected. Thanks to all for their time. Hermann From neteler at osgeo.org Sat Sep 20 04:48:14 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sat, 20 Sep 2014 13:48:14 +0200 Subject: [GRASS-user] Minimum fitting ellipse with attributes In-Reply-To: References: Message-ID: On Fri, Sep 19, 2014 at 8:30 PM, John Wall wrote: > Hello, > I am trying to fit a minimum fitting/bounding ellipse to each polygon in a > series of polygons. Ideally the ellipse would also give me attributes such > as major and minor axes lengths along with orientation. Is this possible > within GRASS 7.0 on a Mac? I cannot seem to find a tool to do this. I found some Python code online, so the best solution might be to combine that with pygrass: http://grass.osgeo.org/grass71/manuals/libpython/pygrass_index.html http://grass.osgeo.org/grass71/manuals/libpython/pygrass_vector.html Markus From lk.palao at gmail.com Sat Sep 20 05:22:02 2014 From: lk.palao at gmail.com (Leo Kris Palao) Date: Sat, 20 Sep 2014 20:22:02 +0800 Subject: [GRASS-user] please remove my email from the mailing list Message-ID: thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedrongvenancio at gmail.com Sat Sep 20 09:13:38 2014 From: pedrongvenancio at gmail.com (=?UTF-8?Q?Pedro_Ven=C3=A2ncio?=) Date: Sat, 20 Sep 2014 17:13:38 +0100 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: References: <53FE3E5C.1050907@wildintellect.com> <541B1614.5020808@wildintellect.com> Message-ID: Hi, Here the installation worked in ubuntu 12.04, following this instructions http://grass.osgeo.org/download/software/linux/. But I also get 'Unable to get GRASS version': __________ ___ __________ _______________ / ____/ __ \/ | / ___/ ___/ / ____/ _/ ___/ / / __/ /_/ / /| | \__ \\_ \ / / __ / / \__ \ / /_/ / _, _/ ___ |___/ /__/ / / /_/ // / ___/ / \____/_/ |_/_/ |_/____/____/ \____/___//____/ Welcome to GRASS 7.0.0 GRASS homepage: http://grass.osgeo.org This version running through: Bash Shell (/bin/bash) Help is available with the command: g.manual -i See the licence terms with: g.version -c If required, restart the GUI with: g.gui wxpython When ready to quit enter: exit Launching GUI in the background, please wait... GRASS 7.0.0 (pinhel):~ > Unable to get GRASS version Unable to get GRASS version GRASS 7.0.0 (pinhel):~ > g.extension -a Traceback (most recent call last): File "/usr/lib/grass70/scripts/g.extension", line 1082, in version = grass.version()['version'].split('.') KeyError: 'version' GRASS 7.0.0 (pinhel):~ > g.version -e GRASS 7.0.0svn (2014) PROJ.4: 4.8.0 GDAL/OGR: 1.10.0 GEOS: 3.4.2 SQLite: 3.7.9 Thanks! Pedro -------------- next part -------------- An HTML attachment was scrubbed... URL: From kratochanna at gmail.com Sat Sep 20 17:04:53 2014 From: kratochanna at gmail.com (=?UTF-8?B?QW5uYSBQZXRyw6HFoW92w6E=?=) Date: Sat, 20 Sep 2014 20:04:53 -0400 Subject: [GRASS-user] Minimum fitting ellipse with attributes In-Reply-To: References: Message-ID: On Sat, Sep 20, 2014 at 7:48 AM, Markus Neteler wrote: > On Fri, Sep 19, 2014 at 8:30 PM, John Wall wrote: > > Hello, > > I am trying to fit a minimum fitting/bounding ellipse to each polygon in > a > > series of polygons. Ideally the ellipse would also give me attributes > such > > as major and minor axes lengths along with orientation. Is this possible > > within GRASS 7.0 on a Mac? I cannot seem to find a tool to do this. > > I found some Python code online, so the best solution might be to > combine that with pygrass: > Markus, perhaps you wanted to give us a link to the Python code? Anna > > http://grass.osgeo.org/grass71/manuals/libpython/pygrass_index.html > http://grass.osgeo.org/grass71/manuals/libpython/pygrass_vector.html > > Markus > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Sun Sep 21 04:06:12 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sun, 21 Sep 2014 13:06:12 +0200 Subject: [GRASS-user] Minimum fitting ellipse with attributes In-Reply-To: References: Message-ID: Hi Anna On Sep 21, 2014 2:05 AM, "Anna Petr??ov?" wrote: > > > > On Sat, Sep 20, 2014 at 7:48 AM, Markus Neteler wrote: >> >> On Fri, Sep 19, 2014 at 8:30 PM, John Wall wrote: >> > Hello, >> > I am trying to fit a minimum fitting/bounding ellipse to each polygon in a >> > series of polygons. Ideally the ellipse would also give me attributes such >> > as major and minor axes lengths along with orientation. Is this possible >> > within GRASS 7.0 on a Mac? I cannot seem to find a tool to do this. >> >> I found some Python code online, so the best solution might be to >> combine that with pygrass: > > > Markus, perhaps you wanted to give us a link to the Python code? I just found some code using google search (first hits) but did not check their license. That's why I did not add the links right away. Markus (on mobile at time) > Anna >> >> >> http://grass.osgeo.org/grass71/manuals/libpython/pygrass_index.html >> http://grass.osgeo.org/grass71/manuals/libpython/pygrass_vector.html >> >> Markus >> _______________________________________________ >> grass-user mailing list >> grass-user at lists.osgeo.org >> http://lists.osgeo.org/mailman/listinfo/grass-user > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwall at ncsu.edu Sun Sep 21 11:59:33 2014 From: jwall at ncsu.edu (John Wall) Date: Sun, 21 Sep 2014 14:59:33 -0400 Subject: [GRASS-user] Minimum fitting ellipse with attributes In-Reply-To: References: Message-ID: Markus, Is this some of the code you are talking about: http://nicky.vanforeest.com/misc/fitEllipse/fitEllipse.html I do not see any other code than this when I search for it on Google. Thanks, John ------------------------------------------------------------------------------- John Wall Earth Science Ph.D. Student Department of Marine, Earth & Atmospheric Sciences North Carolina State University On Sun, Sep 21, 2014 at 7:06 AM, Markus Neteler wrote: > Hi Anna > On Sep 21, 2014 2:05 AM, "Anna Petr??ov?" wrote: > > > > > > > > On Sat, Sep 20, 2014 at 7:48 AM, Markus Neteler > wrote: > >> > >> On Fri, Sep 19, 2014 at 8:30 PM, John Wall wrote: > >> > Hello, > >> > I am trying to fit a minimum fitting/bounding ellipse to each polygon > in a > >> > series of polygons. Ideally the ellipse would also give me attributes > such > >> > as major and minor axes lengths along with orientation. Is this > possible > >> > within GRASS 7.0 on a Mac? I cannot seem to find a tool to do this. > >> > >> I found some Python code online, so the best solution might be to > >> combine that with pygrass: > > > > > > Markus, perhaps you wanted to give us a link to the Python code? > > I just found some code using google search (first hits) but did not check > their license. That's why I did not add the links right away. > > Markus (on mobile at time) > > > Anna > >> > >> > >> http://grass.osgeo.org/grass71/manuals/libpython/pygrass_index.html > >> http://grass.osgeo.org/grass71/manuals/libpython/pygrass_vector.html > >> > >> Markus > >> _______________________________________________ > >> grass-user mailing list > >> grass-user at lists.osgeo.org > >> http://lists.osgeo.org/mailman/listinfo/grass-user > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jakob at grimstveit.no Sun Sep 21 15:09:10 2014 From: jakob at grimstveit.no (Jakob Breivik Grimstveit) Date: Mon, 22 Sep 2014 00:09:10 +0200 Subject: [GRASS-user] Problems installing addons to Ubuntu 14.04 fresh setup Message-ID: Hi, Installed Grass GIS 6.4 using apt-get install and started using it. Seems fine, no errors upon startup, but I get this error when installing addons. What am I doing wrong? (Sun Sep 21 19:17:37 2014) g.extension.py extension=r.basin svnurl=http://svn.osgeo.org/grass/grass-addons/grass6 Fetching from GRASS-Addons SVN (be patient)... Compiling... /usr/lib/grass64/include/Make/Grass.make:423: warning: overriding commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Grass.make:414: warning: ignoring old commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Grass.make:423: warning: overriding commands for target `Data/GBNP/PERMANENT/.tmp/Pingwinindabox/2206.0/r.basin/bin' /usr/lib/grass64/include/Make/Grass.make:414: warning: ignoring old commands for target `Data/GBNP/PERMANENT/.tmp/Pingwinindabox/2206.0/r.basin/bin' /usr/lib/grass64/include/Make/Grass.make:426: warning: overriding commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Grass.make:423: warning: ignoring old commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Html.make:40: warning: overriding commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Grass.make:426: warning: ignoring old commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Man.make:38: warning: overriding commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Html.make:40: warning: ignoring old commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Script.make:21: warning: overriding commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Man.make:38: warning: ignoring old commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Script.make:27: warning: overriding commands for target `/home/snarrald/Desktop/Grass' /usr/lib/grass64/include/Make/Script.make:21: warning: ignoring old commands for target `/home/snarrald/Desktop/Grass' make: *** No rule to make target `/usr/lib/grass64/scripts/windows_launch.bat', needed by `/home/snarrald/Desktop/Grass'. Stop. ERROR: Compilation failed, sorry. Please check above error messages. (Sun Sep 21 19:17:44 2014) Command finished (6 sec) -- Vyrdsamt, Jakob Breivik Grimstveit | +47 4829 8152 http://grimstveit.no/jakob -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Mon Sep 22 09:01:33 2014 From: neteler at osgeo.org (Markus Neteler) Date: Mon, 22 Sep 2014 18:01:33 +0200 Subject: [GRASS-user] Problems installing addons to Ubuntu 14.04 fresh setup In-Reply-To: References: Message-ID: On Mon, Sep 22, 2014 at 12:09 AM, Jakob Breivik Grimstveit wrote: > Hi, > > Installed Grass GIS 6.4 using apt-get install and started using it. Seems > fine, no errors upon startup, but I get this error when installing addons. > What am I doing wrong? > > (Sun Sep 21 19:17:37 2014) > g.extension.py extension=r.basin > svnurl=http://svn.osgeo.org/grass/grass-addons/grass6 > Fetching from GRASS-Addons SVN (be patient)... > Compiling... > /usr/lib/grass64/include/Make/Grass.make:423: warning: > overriding commands for target > `/home/snarrald/Desktop/Grass' > /usr/lib/grass64/include/Make/Grass.make:414: warning: > ignoring old commands for target > `/home/snarrald/Desktop/Grass' > /usr/lib/grass64/include/Make/Grass.make:423: warning: > overriding commands for target > `Data/GBNP/PERMANENT/.tmp/Pingwinindabox/2206.0/r.basin/bin' ... Is it possible that your directory is called: /home/snarrald/Desktop/Grass Data/ with a white space between s and D? If yes, please rename it to GrassData, it may be that g.extension in GRASS 6.4 (still) doesn't manage to cope with white space in path names. Markus From neteler at osgeo.org Mon Sep 22 10:02:40 2014 From: neteler at osgeo.org (Markus Neteler) Date: Mon, 22 Sep 2014 19:02:40 +0200 Subject: [GRASS-user] Minimum fitting ellipse with attributes In-Reply-To: References: Message-ID: On Sun, Sep 21, 2014 at 8:59 PM, John Wall wrote: > Markus, > Is this some of the code you are talking about: > http://nicky.vanforeest.com/misc/fitEllipse/fitEllipse.html Yes. > I do not see any other code than this when I search for it on Google. I just searched briefly during travelling. Here was a reference but it is referred to the same code: https://stackoverflow.com/questions/13635528/fit-a-ellipse-in-python-given-a-set-of-points-xi-xi-yi Maybe books about computational geometry could be useful, too. Markus From johannesradinger at gmail.com Tue Sep 23 01:23:58 2014 From: johannesradinger at gmail.com (Johannes Radinger) Date: Tue, 23 Sep 2014 10:23:58 +0200 Subject: [GRASS-user] Equidistant points along lines of a vector network Message-ID: Hi, I've got a vector network (river network) and I want to place points along that network. The points should be placed every 250 m starting from the outlet. Any network junctions should be ignored so that every point is 250 apart from the next upstream and downstream point. With the tool v.segment only the single parts of the polyline (lines between nodes) are splitted based on the distance parameter. So v.segment ignores the network. Maybe v.net.iso can be of use in this case, but here I am missing the option to create points in given distance classes from a starting point. Is there any specific GRASS tool or procedure for such tasks? Any suggestions? Best regards, Johannes -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlennert at club.worldonline.be Tue Sep 23 05:39:51 2014 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue, 23 Sep 2014 14:39:51 +0200 Subject: [GRASS-user] Equidistant points along lines of a vector network In-Reply-To: References: Message-ID: <54216A17.2030507@club.worldonline.be> On 23/09/14 10:23, Johannes Radinger wrote: > Hi, > > I've got a vector network (river network) and I want to place points > along that network. The points should be placed every 250 m starting > from the outlet. Any network junctions should be ignored so that every > point is 250 apart from the next upstream and downstream point. > > With the tool v.segment only the single parts of the polyline (lines between > nodes) are splitted based on the distance parameter. So v.segment ignores > the network. Maybe v.net.iso can be of use in this case, but here I am > missing > the option to create points in given distance classes from a starting point. > > > Is there any specific GRASS tool or procedure for such tasks? Would v.build.polylines help here ? I don't know how v.segment acts on polylines. Moritz From neteler at osgeo.org Tue Sep 23 07:51:25 2014 From: neteler at osgeo.org (Markus Neteler) Date: Tue, 23 Sep 2014 16:51:25 +0200 Subject: [GRASS-user] problem to install grass70 on ubuntu 12.04 In-Reply-To: References: <53FE3E5C.1050907@wildintellect.com> <541B1614.5020808@wildintellect.com> Message-ID: Hi, just FYI - the person who asked for my assistance with Ubuntu, got it running after these two steps (as not being an Ubuntu user I don't know what it means): software-properties-gtk sudo apt-get update Once these two steps made, the GRASS packages appeared in the Software Center under GRASS Packages stable series. ... thought to post that here, maybe useful. Markus From caesarivs at gmail.com Tue Sep 23 11:44:25 2014 From: caesarivs at gmail.com (=?UTF-8?Q?C=C3=A9sar_Augusto_Ram=C3=ADrez_Franco?=) Date: Tue, 23 Sep 2014 13:44:25 -0500 Subject: [GRASS-user] Equidistant points along lines of a vector network In-Reply-To: <54216A17.2030507@club.worldonline.be> References: <54216A17.2030507@club.worldonline.be> Message-ID: Have you tried v.points module? 2014-09-23 7:39 GMT-05:00 Moritz Lennert : > On 23/09/14 10:23, Johannes Radinger wrote: > >> Hi, >> >> I've got a vector network (river network) and I want to place points >> along that network. The points should be placed every 250 m starting >> from the outlet. Any network junctions should be ignored so that every >> point is 250 apart from the next upstream and downstream point. >> >> With the tool v.segment only the single parts of the polyline (lines >> between >> nodes) are splitted based on the distance parameter. So v.segment ignores >> the network. Maybe v.net.iso can be of use in this case, but here I am >> missing >> the option to create points in given distance classes from a starting >> point. >> >> >> Is there any specific GRASS tool or procedure for such tasks? >> > > Would v.build.polylines help here ? I don't know how v.segment acts on > polylines. > > Moritz > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -- *C?sar Augusto Ram?rez Franco* Laboratorio de Sistemas Complejos Naturales Escuela de Geociencias Facultad de Ciencias Universidad Nacional de Colombia - Sede Medell?n Tel?fono: (57-4) 430 9369 - 300 459 6085 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pedro.palheiro at gmail.com Tue Sep 23 17:04:35 2014 From: pedro.palheiro at gmail.com (Pedro Palheiro) Date: Wed, 24 Sep 2014 01:04:35 +0100 Subject: [GRASS-user] Equidistant points along lines of a vector network (Johannes Radinger) Message-ID: Hi Johannes, one way might be using v.to.points and setting dmax=250 (so that the points are at most 250m apart): v.to.points -vi input=river output=river_pt250m dmax=250 Regards, Pedro 2014-09-23 20:00 GMT+01:00 : > Send grass-user mailing list submissions to > grass-user at lists.osgeo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/grass-user > or, via email, send a message with subject or body 'help' to > grass-user-request at lists.osgeo.org > > You can reach the person managing the list at > grass-user-owner at lists.osgeo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of grass-user digest..." > > > Today's Topics: > > 1. Equidistant points along lines of a vector network > (Johannes Radinger) > 2. Re: Equidistant points along lines of a vector network > (Moritz Lennert) > 3. Re: problem to install grass70 on ubuntu 12.04 (Markus Neteler) > 4. Re: Equidistant points along lines of a vector network > (C?sar Augusto Ram?rez Franco) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 23 Sep 2014 10:23:58 +0200 > From: Johannes Radinger < > ?? > johannesradinger at gmail.com> > To: GRASS user list > Subject: [GRASS-user] Equidistant points along lines of a vector > network > Message-ID: > 3Y+REmQoptCb5YVwoUbW4DVy5cbOgF1p2MaLQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I've got a vector network (river network) and I want to place points > along that network. The points should be placed every 250 m starting > from the outlet. Any network junctions should be ignored so that every > point is 250 apart from the next upstream and downstream point. > > With the tool v.segment only the single parts of the polyline (lines > between > nodes) are splitted based on the distance parameter. So v.segment ignores > the network. Maybe v.net.iso can be of use in this case, but here I am > missing > the option to create points in given distance classes from a starting > point. > > > Is there any specific GRASS tool or procedure for such tasks? > Any suggestions? > > Best regards, > Johannes > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/grass-user/attachments/20140923/5bc459af/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 23 Sep 2014 14:39:51 +0200 > From: Moritz Lennert > To: Johannes Radinger , GRASS user list > > Subject: Re: [GRASS-user] Equidistant points along lines of a vector > network > Message-ID: <54216A17.2030507 at club.worldonline.be> > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 23/09/14 10:23, Johannes Radinger wrote: > > Hi, > > > > I've got a vector network (river network) and I want to place points > > along that network. The points should be placed every 250 m starting > > from the outlet. Any network junctions should be ignored so that every > > point is 250 apart from the next upstream and downstream point. > > > > With the tool v.segment only the single parts of the polyline (lines > between > > nodes) are splitted based on the distance parameter. So v.segment ignores > > the network. Maybe v.net.iso can be of use in this case, but here I am > > missing > > the option to create points in given distance classes from a starting > point. > > > > > > Is there any specific GRASS tool or procedure for such tasks? > > Would v.build.polylines help here ? I don't know how v.segment acts on > polylines. > > Moritz > > > ------------------------------ > > Message: 3 > Date: Tue, 23 Sep 2014 16:51:25 +0200 > From: Markus Neteler > To: Rashad M > Cc: GRASS user list , Mohammed Rashad > , "tech at wildintellect.com" > > Subject: Re: [GRASS-user] problem to install grass70 on ubuntu 12.04 > Message-ID: > 4S0O+T9yOeaOaNM6SKw0kHctey2MNjtXCoeNw at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > Hi, > > just FYI - the person who asked for my assistance with Ubuntu, got it > running after these two steps (as not being an Ubuntu user I don't > know what it means): > > software-properties-gtk > sudo apt-get update > > Once these two steps made, the GRASS packages appeared in the Software > Center under GRASS Packages stable series. > > ... thought to post that here, maybe useful. > > Markus > > > ------------------------------ > > Message: 4 > Date: Tue, 23 Sep 2014 13:44:25 -0500 > From: C?sar Augusto Ram?rez Franco > To: Moritz Lennert > Cc: GRASS user list , Johannes Radinger > > Subject: Re: [GRASS-user] Equidistant points along lines of a vector > network > Message-ID: > crCUSQKKHsans8TLXYEewZemZ5AU_c2HC22N5RL8ELA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Have you tried v.points module? > > 2014-09-23 7:39 GMT-05:00 Moritz Lennert : > > > On 23/09/14 10:23, Johannes Radinger wrote: > > > >> Hi, > >> > >> I've got a vector network (river network) and I want to place points > >> along that network. The points should be placed every 250 m starting > >> from the outlet. Any network junctions should be ignored so that every > >> point is 250 apart from the next upstream and downstream point. > >> > >> With the tool v.segment only the single parts of the polyline (lines > >> between > >> nodes) are splitted based on the distance parameter. So v.segment > ignores > >> the network. Maybe v.net.iso can be of use in this case, but here I am > >> missing > >> the option to create points in given distance classes from a starting > >> point. > >> > >> > >> Is there any specific GRASS tool or procedure for such tasks? > >> > > > > Would v.build.polylines help here ? I don't know how v.segment acts on > > polylines. > > > > Moritz > > _______________________________________________ > > grass-user mailing list > > grass-user at lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-user > > > > > > -- > *C?sar Augusto Ram?rez Franco* > Laboratorio de Sistemas Complejos Naturales > Escuela de Geociencias > Facultad de Ciencias > Universidad Nacional de Colombia - Sede Medell?n > Tel?fono: (57-4) 430 9369 - 300 459 6085 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/grass-user/attachments/20140923/14347dd3/attachment-0001.html > > > > ------------------------------ > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > End of grass-user Digest, Vol 101, Issue 34 > ******************************************* > -- Pedro Palheiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefan.Blumentrath at nina.no Wed Sep 24 00:49:07 2014 From: Stefan.Blumentrath at nina.no (Blumentrath, Stefan) Date: Wed, 24 Sep 2014 07:49:07 +0000 Subject: [GRASS-user] New GRASS 7 addon: v.lidar.mcc Message-ID: <2C5F82DA3EE3E449BD473075F2C290BF9C2E8A7A@NINSRV05.nina.no> Dear all, Today I uploaded a new GRASS 7 addon to SVN. The Python-script ?v.lidar.mcc? aims at removing vegetation returns from LiDAR point-clouds. It is a modified implementation if Evans & Hudak`s (2007) multiscale curvature classification (mcc) algorith. Compared to the original, the GRASS module has a few more options (useer can define also spline steps, number of scale domains, and convergence threshold). I am not sure if terrain interpolation method in v.outlier (which v.lidar.mcc uses) does match exactly the thin-plate interpolation that Evans & Hudak used. When I find the time I will compare results and performance to the original mcc-tool... I hope the manual is understandable and I would be happy about feedback... Cheers Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From mseibel at gmail.com Wed Sep 24 04:44:58 2014 From: mseibel at gmail.com (Mark Seibel) Date: Wed, 24 Sep 2014 07:44:58 -0400 Subject: [GRASS-user] New GRASS 7 addon: v.lidar.mcc In-Reply-To: <2C5F82DA3EE3E449BD473075F2C290BF9C2E8A7A@NINSRV05.nina.no> References: <2C5F82DA3EE3E449BD473075F2C290BF9C2E8A7A@NINSRV05.nina.no> Message-ID: Thanks for this contribution. I look forward to trying this when I have time. Mark On Wed, Sep 24, 2014 at 3:49 AM, Blumentrath, Stefan < Stefan.Blumentrath at nina.no> wrote: > Dear all, > > > Today I uploaded a new GRASS 7 addon to SVN. > > The Python-script ?v.lidar.mcc? aims at removing vegetation returns from > LiDAR point-clouds. It is a modified implementation if Evans & Hudak`s > (2007) multiscale curvature classification (mcc) algorith. > > Compared to the original, the GRASS module has a few more options (useer > can define also spline steps, number of scale domains, and convergence > threshold). I am not sure if terrain interpolation method in v.outlier > (which v.lidar.mcc uses) does match exactly the thin-plate interpolation > that Evans & Hudak used. > > > When I find the time I will compare results and performance to the > original mcc-tool... I hope the manual is understandable and I would be > happy about feedback... > > > Cheers > > Stefan > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuszinger at giscom.hu Wed Sep 24 05:40:56 2014 From: kuszinger at giscom.hu (Robert Kuszinger) Date: Wed, 24 Sep 2014 14:40:56 +0200 Subject: [GRASS-user] r.patch number of input limitation? Message-ID: Hello! I'm trying to patch 1393 pieces of raster images with *r.patch*. before r.patch, the projection is set as follows: *projection: 3 (Latitude-Longitude)* *zone: 0* *datum: wgs84* *ellipsoid: wgs84* *north: 33:00:00.5N* *south: 14:00:00.5S* *west: 75:59:59.5E* *east: 136:00:00.5E* *nsres: 0:01:00.000355* *ewres: 0:01:00.000278* *rows: 2820* *cols: 3600* *cells: 10152000 <10152000>* As you see, the target mosaic is set to be a moderate resolution by setting es/nwres to 1 minute instead of seconds. I do then: GRASS 6.4.3 (wgs84pure):~/grassdata/import > *MAPS=`g.mlist type=rast sep=, pat="AST*"`* GRASS 6.4.3 (wgs84pure):~/grassdata/import > *r.patch in=$MAPS out=mosaic* *WARNING: Unable to open raster map * ERROR: One or more input raster maps not found How could it be? *Is there a limitation on the string what r.patch is parsing from the command line?* The raster coverage is there, for sure, I can display it. What is even more: *g.region rast=$MAPS* was run with no error..... This is why I think that it could be a kind of parsing error or internal limitation on the number of raster coverages to integrate in the patch process... System is: *uname -a* Linux delli7010 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux There is also enough free diskspace, ram is 3Gb: /dev/sdb2 437G 149G *266G* 36% /media/kuszi/etc thanks Robert *(for those, who are curious, the value of $MAPS is here)* *GRASS 6.4.3 (wgs84pure):~/grassdata/import > echo $MAPS* ASTGTM2N00E097,ASTGTM2N00E098,ASTGTM2N00E099,ASTGTM2N00E100,ASTGTM2N00E101,ASTGTM2N00E102,ASTGTM2N00E103,ASTGTM2N00E104,ASTGTM2N00E106,ASTGTM2N00E107,ASTGTM2N00E108,ASTGTM2N00E109,ASTGTM2N00E110,ASTGTM2N00E111,ASTGTM2N00E112,ASTGTM2N00E113,ASTGTM2N00E114,ASTGTM2N00E115,ASTGTM2N00E116,ASTGTM2N00E117,ASTGTM2N00E118,ASTGTM2N00E119,ASTGTM2N00E120,ASTGTM2N00E121,ASTGTM2N00E122,ASTGTM2N00E123,ASTGTM2N00E124,ASTGTM2N00E126,ASTGTM2N00E127,ASTGTM2N00E128,ASTGTM2N00E129,ASTGTM2N00E130,ASTGTM2N01E097,ASTGTM2N01E098,ASTGTM2N01E099,ASTGTM2N01E100,ASTGTM2N01E101,ASTGTM2N01E102,ASTGTM2N01E103,ASTGTM2N01E104,ASTGTM2N01E107,ASTGTM2N01E108,ASTGTM2N01E109,ASTGTM2N01E110,ASTGTM2N01E111,ASTGTM2N01E112,ASTGTM2N01E113,ASTGTM2N01E114,ASTGTM2N01E115,ASTGTM2N01E116,ASTGTM2N01E117,ASTGTM2N01E118,ASTGTM2N01E120,ASTGTM2N01E121,ASTGTM2N01E122,ASTGTM2N01E124,ASTGTM2N01E125,ASTGTM2N01E126,ASTGTM2N01E127,ASTGTM2N01E128,ASTGTM2N02E095,ASTGTM2N02E096,ASTGTM2N02E097,ASTGTM2N02E098,ASTGTM2N02E099,ASTGTM2N02E100,ASTGTM2N02E101,ASTGTM2N02E102,ASTGTM2N02E103,ASTGTM2N02E104,ASTGTM2N02E105,ASTGTM2N02E106,ASTGTM2N02E107,ASTGTM2N02E108,ASTGTM2N02E109,ASTGTM2N02E111,ASTGTM2N02E112,ASTGTM2N02E113,ASTGTM2N02E114,ASTGTM2N02E115,ASTGTM2N02E116,ASTGTM2N02E117,ASTGTM2N02E118,ASTGTM2N02E125,ASTGTM2N02E127,ASTGTM2N02E128,ASTGTM2N03E096,ASTGTM2N03E097,ASTGTM2N03E098,ASTGTM2N03E099,ASTGTM2N03E100,ASTGTM2N03E101,ASTGTM2N03E102,ASTGTM2N03E103,ASTGTM2N03E105,ASTGTM2N03E106,ASTGTM2N03E107,ASTGTM2N03E108,ASTGTM2N03E112,ASTGTM2N03E113,ASTGTM2N03E114,ASTGTM2N03E115,ASTGTM2N03E116,ASTGTM2N03E117,ASTGTM2N03E125,ASTGTM2N03E126,ASTGTM2N04E095,ASTGTM2N04E096,ASTGTM2N04E097,ASTGTM2N04E098,ASTGTM2N04E100,ASTGTM2N04E101,ASTGTM2N04E102,ASTGTM2N04E103,ASTGTM2N04E107,ASTGTM2N04E108,ASTGTM2N04E113,ASTGTM2N04E114,ASTGTM2N04E115,ASTGTM2N04E116,ASTGTM2N04E117,ASTGTM2N04E118,ASTGTM2N04E119,ASTGTM2N04E120,ASTGTM2N04E126,ASTGTM2N04E127,ASTGTM2N04E131,ASTGTM2N04E132,ASTGTM2N05E080,ASTGTM2N05E095,ASTGTM2N05E096,ASTGTM2N05E097,ASTGTM2N05E100,ASTGTM2N05E101,ASTGTM2N05E102,ASTGTM2N05E103,ASTGTM2N05E114,ASTGTM2N05E115,ASTGTM2N05E116,ASTGTM2N05E117,ASTGTM2N05E118,ASTGTM2N05E119,ASTGTM2N05E120,ASTGTM2N05E121,ASTGTM2N05E124,ASTGTM2N05E125,ASTGTM2N06E079,ASTGTM2N06E080,ASTGTM2N06E081,ASTGTM2N06E093,ASTGTM2N06E099,ASTGTM2N06E100,ASTGTM2N06E101,ASTGTM2N06E102,ASTGTM2N06E115,ASTGTM2N06E116,ASTGTM2N06E117,ASTGTM2N06E118,ASTGTM2N06E120,ASTGTM2N06E121,ASTGTM2N06E122,ASTGTM2N06E123,ASTGTM2N06E124,ASTGTM2N06E125,ASTGTM2N06E126,ASTGTM2N06E134,ASTGTM2N07E079,ASTGTM2N07E080,ASTGTM2N07E081,ASTGTM2N07E093,ASTGTM2N07E098,ASTGTM2N07E099,ASTGTM2N07E100,ASTGTM2N07E116,ASTGTM2N07E117,ASTGTM2N07E118,ASTGTM2N07E121,ASTGTM2N07E122,ASTGTM2N07E123,ASTGTM2N07E124,ASTGTM2N07E125,ASTGTM2N07E126,ASTGTM2N07E134,ASTGTM2N08E076,ASTGTM2N08E077,ASTGTM2N08E078,ASTGTM2N08E079,ASTGTM2N08E080,ASTGTM2N08E081,ASTGTM2N08E092,ASTGTM2N08E093,ASTGTM2N08E097,ASTGTM2N08E098,ASTGTM2N08E099,ASTGTM2N08E100,ASTGTM2N08E104,ASTGTM2N08E105,ASTGTM2N08E106,ASTGTM2N08E116,ASTGTM2N08E117,ASTGTM2N08E118,ASTGTM2N08E122,ASTGTM2N08E123,ASTGTM2N08E124,ASTGTM2N08E125,ASTGTM2N08E126,ASTGTM2N08E134,ASTGTM2N09E076,ASTGTM2N09E077,ASTGTM2N09E078,ASTGTM2N09E079,ASTGTM2N09E080,ASTGTM2N09E092,ASTGTM2N09E097,ASTGTM2N09E098,ASTGTM2N09E099,ASTGTM2N09E100,ASTGTM2N09E102,ASTGTM2N09E103,ASTGTM2N09E104,ASTGTM2N09E105,ASTGTM2N09E106,ASTGTM2N09E117,ASTGTM2N09E118,ASTGTM2N09E120,ASTGTM2N09E121,ASTGTM2N09E122,ASTGTM2N09E123,ASTGTM2N09E124,ASTGTM2N09E125,ASTGTM2N09E126,ASTGTM2N10E076,ASTGTM2N10E077,ASTGTM2N10E078,ASTGTM2N10E079,ASTGTM2N10E092,ASTGTM2N10E097,ASTGTM2N10E098,ASTGTM2N10E099,ASTGTM2N10E103,ASTGTM2N10E104,ASTGTM2N10E105,ASTGTM2N10E106,ASTGTM2N10E107,ASTGTM2N10E108,ASTGTM2N10E114,ASTGTM2N10E118,ASTGTM2N10E119,ASTGTM2N10E120,ASTGTM2N10E121,ASTGTM2N10E122,ASTGTM2N10E123,ASTGTM2N10E124,ASTGTM2N10E125,ASTGTM2N10E126,ASTGTM2N11E076,ASTGTM2N11E077,ASTGTM2N11E078,ASTGTM2N11E079,ASTGTM2N11E092,ASTGTM2N11E093,ASTGTM2N11E097,ASTGTM2N11E098,ASTGTM2N11E099,ASTGTM2N11E102,ASTGTM2N11E103,ASTGTM2N11E104,ASTGTM2N11E105,ASTGTM2N11E106,ASTGTM2N11E107,ASTGTM2N11E108,ASTGTM2N11E109,ASTGTM2N11E119,ASTGTM2N11E120,ASTGTM2N11E121,ASTGTM2N11E122,ASTGTM2N11E123,ASTGTM2N11E124,ASTGTM2N11E125,ASTGTM2N12E076,ASTGTM2N12E077,ASTGTM2N12E078,ASTGTM2N12E079,ASTGTM2N12E080,ASTGTM2N12E092,ASTGTM2N12E093,ASTGTM2N12E097,ASTGTM2N12E098,ASTGTM2N12E099,ASTGTM2N12E100,ASTGTM2N12E101,ASTGTM2N12E102,ASTGTM2N12E103,ASTGTM2N12E104,ASTGTM2N12E105,ASTGTM2N12E106,ASTGTM2N12E107,ASTGTM2N12E108,ASTGTM2N12E109,ASTGTM2N12E119,ASTGTM2N12E120,ASTGTM2N12E121,ASTGTM2N12E122,ASTGTM2N12E123,ASTGTM2N12E124,ASTGTM2N12E125,ASTGTM2N13E076,ASTGTM2N13E077,ASTGTM2N13E078,ASTGTM2N13E079,ASTGTM2N13E080,ASTGTM2N13E092,ASTGTM2N13E093,ASTGTM2N13E094,ASTGTM2N13E097,ASTGTM2N13E098,ASTGTM2N13E099,ASTGTM2N13E100,ASTGTM2N13E101,ASTGTM2N13E102,ASTGTM2N13E103,ASTGTM2N13E104,ASTGTM2N13E105,ASTGTM2N13E106,ASTGTM2N13E107,ASTGTM2N13E108,ASTGTM2N13E109,ASTGTM2N13E120,ASTGTM2N13E121,ASTGTM2N13E122,ASTGTM2N13E123,ASTGTM2N13E124,ASTGTM2N14E076,ASTGTM2N14E077,ASTGTM2N14E078,ASTGTM2N14E079,ASTGTM2N14E080,ASTGTM2N14E093,ASTGTM2N14E097,ASTGTM2N14E098,ASTGTM2N14E099,ASTGTM2N14E100,ASTGTM2N14E101,ASTGTM2N14E102,ASTGTM2N14E103,ASTGTM2N14E104,ASTGTM2N14E105,ASTGTM2N14E106,ASTGTM2N14E107,ASTGTM2N14E108,ASTGTM2N14E109,ASTGTM2N14E120,ASTGTM2N14E121,ASTGTM2N14E122,ASTGTM2N14E123,ASTGTM2N14E124,ASTGTM2N15E076,ASTGTM2N15E077,ASTGTM2N15E078,ASTGTM2N15E079,ASTGTM2N15E080,ASTGTM2N15E081,ASTGTM2N15E094,ASTGTM2N15E095,ASTGTM2N15E097,ASTGTM2N15E098,ASTGTM2N15E099,ASTGTM2N15E100,ASTGTM2N15E101,ASTGTM2N15E102,ASTGTM2N15E103,ASTGTM2N15E104,ASTGTM2N15E105,ASTGTM2N15E106,ASTGTM2N15E107,ASTGTM2N15E108,ASTGTM2N15E109,ASTGTM2N15E111,ASTGTM2N15E117,ASTGTM2N15E119,ASTGTM2N15E120,ASTGTM2N15E121,ASTGTM2N15E122,ASTGTM2N16E076,ASTGTM2N16E077,ASTGTM2N16E078,ASTGTM2N16E079,ASTGTM2N16E080,ASTGTM2N16E081,ASTGTM2N16E082,ASTGTM2N16E094,ASTGTM2N16E095,ASTGTM2N16E096,ASTGTM2N16E097,ASTGTM2N16E098,ASTGTM2N16E099,ASTGTM2N16E100,ASTGTM2N16E101,ASTGTM2N16E102,ASTGTM2N16E103,ASTGTM2N16E104,ASTGTM2N16E105,ASTGTM2N16E106,ASTGTM2N16E107,ASTGTM2N16E108,ASTGTM2N16E112,ASTGTM2N16E119,ASTGTM2N16E120,ASTGTM2N16E121,ASTGTM2N16E122,ASTGTM2N17E076,ASTGTM2N17E077,ASTGTM2N17E078,ASTGTM2N17E079,ASTGTM2N17E080,ASTGTM2N17E081,ASTGTM2N17E082,ASTGTM2N17E083,ASTGTM2N17E094,ASTGTM2N17E095,ASTGTM2N17E096,ASTGTM2N17E097,ASTGTM2N17E098,ASTGTM2N17E099,ASTGTM2N17E100,ASTGTM2N17E101,ASTGTM2N17E102,ASTGTM2N17E103,ASTGTM2N17E104,ASTGTM2N17E105,ASTGTM2N17E106,ASTGTM2N17E107,ASTGTM2N17E120,ASTGTM2N17E121,ASTGTM2N17E122,ASTGTM2N18E076,ASTGTM2N18E077,ASTGTM2N18E078,ASTGTM2N18E079,ASTGTM2N18E080,ASTGTM2N18E081,ASTGTM2N18E082,ASTGTM2N18E083,ASTGTM2N18E084,ASTGTM2N18E093,ASTGTM2N18E094,ASTGTM2N18E095,ASTGTM2N18E096,ASTGTM2N18E097,ASTGTM2N18E098,ASTGTM2N18E099,ASTGTM2N18E100,ASTGTM2N18E101,ASTGTM2N18E102,ASTGTM2N18E103,ASTGTM2N18E104,ASTGTM2N18E105,ASTGTM2N18E106,ASTGTM2N18E108,ASTGTM2N18E109,ASTGTM2N18E110,ASTGTM2N18E120,ASTGTM2N18E121,ASTGTM2N18E122,ASTGTM2N19E076,ASTGTM2N19E077,ASTGTM2N19E078,ASTGTM2N19E079,ASTGTM2N19E080,ASTGTM2N19E081,ASTGTM2N19E082,ASTGTM2N19E083,ASTGTM2N19E084,ASTGTM2N19E085,ASTGTM2N19E086,ASTGTM2N19E092,ASTGTM2N19E093,ASTGTM2N19E094,ASTGTM2N19E095,ASTGTM2N19E096,ASTGTM2N19E097,ASTGTM2N19E098,ASTGTM2N19E099,ASTGTM2N19E100,ASTGTM2N19E101,ASTGTM2N19E102,ASTGTM2N19E103,ASTGTM2N19E104,ASTGTM2N19E105,ASTGTM2N19E106,ASTGTM2N19E108,ASTGTM2N19E109,ASTGTM2N19E110,ASTGTM2N19E111,ASTGTM2N19E121,ASTGTM2N19E122,ASTGTM2N20E076,ASTGTM2N20E077,ASTGTM2N20E078,ASTGTM2N20E079,ASTGTM2N20E080,ASTGTM2N20E081,ASTGTM2N20E082,ASTGTM2N20E083,ASTGTM2N20E084,ASTGTM2N20E085,ASTGTM2N20E086,ASTGTM2N20E087,ASTGTM2N20E092,ASTGTM2N20E093,ASTGTM2N20E094,ASTGTM2N20E095,ASTGTM2N20E096,ASTGTM2N20E097,ASTGTM2N20E098,ASTGTM2N20E099,ASTGTM2N20E100,ASTGTM2N20E101,ASTGTM2N20E102,ASTGTM2N20E103,ASTGTM2N20E104,ASTGTM2N20E105,ASTGTM2N20E106,ASTGTM2N20E107,ASTGTM2N20E109,ASTGTM2N20E110,ASTGTM2N20E116,ASTGTM2N20E121,ASTGTM2N20E122,ASTGTM2N21E076,ASTGTM2N21E077,ASTGTM2N21E078,ASTGTM2N21E079,ASTGTM2N21E080,ASTGTM2N21E081,ASTGTM2N21E082,ASTGTM2N21E083,ASTGTM2N21E084,ASTGTM2N21E085,ASTGTM2N21E086,ASTGTM2N21E087,ASTGTM2N21E088,ASTGTM2N21E089,ASTGTM2N21E090,ASTGTM2N21E091,ASTGTM2N21E092,ASTGTM2N21E093,ASTGTM2N21E094,ASTGTM2N21E095,ASTGTM2N21E096,ASTGTM2N21E097,ASTGTM2N21E098,ASTGTM2N21E099,ASTGTM2N21E100,ASTGTM2N21E101,ASTGTM2N21E102,ASTGTM2N21E103,ASTGTM2N21E104,ASTGTM2N21E105,ASTGTM2N21E106,ASTGTM2N21E107,ASTGTM2N21E108,ASTGTM2N21E109,ASTGTM2N21E110,ASTGTM2N21E111,ASTGTM2N21E112,ASTGTM2N21E113,ASTGTM2N21E114,ASTGTM2N21E120,ASTGTM2N21E121,ASTGTM2N22E076,ASTGTM2N22E077,ASTGTM2N22E078,ASTGTM2N22E079,ASTGTM2N22E080,ASTGTM2N22E081,ASTGTM2N22E082,ASTGTM2N22E083,ASTGTM2N22E084,ASTGTM2N22E085,ASTGTM2N22E086,ASTGTM2N22E087,ASTGTM2N22E088,ASTGTM2N22E089,ASTGTM2N22E090,ASTGTM2N22E091,ASTGTM2N22E092,ASTGTM2N22E093,ASTGTM2N22E094,ASTGTM2N22E095,ASTGTM2N22E096,ASTGTM2N22E097,ASTGTM2N22E098,ASTGTM2N22E099,ASTGTM2N22E100,ASTGTM2N22E101,ASTGTM2N22E102,ASTGTM2N22E103,ASTGTM2N22E104,ASTGTM2N22E105,ASTGTM2N22E106,ASTGTM2N22E107,ASTGTM2N22E108,ASTGTM2N22E109,ASTGTM2N22E110,ASTGTM2N22E111,ASTGTM2N22E112,ASTGTM2N22E113,ASTGTM2N22E114,ASTGTM2N22E115,ASTGTM2N22E116,ASTGTM2N22E120,ASTGTM2N22E121,ASTGTM2N23E076,ASTGTM2N23E077,ASTGTM2N23E078,ASTGTM2N23E079,ASTGTM2N23E080,ASTGTM2N23E081,ASTGTM2N23E082,ASTGTM2N23E083,ASTGTM2N23E084,ASTGTM2N23E085,ASTGTM2N23E086,ASTGTM2N23E087,ASTGTM2N23E088,ASTGTM2N23E089,ASTGTM2N23E090,ASTGTM2N23E091,ASTGTM2N23E092,ASTGTM2N23E093,ASTGTM2N23E094,ASTGTM2N23E095,ASTGTM2N23E096,ASTGTM2N23E097,ASTGTM2N23E098,ASTGTM2N23E099,ASTGTM2N23E100,ASTGTM2N23E101,ASTGTM2N23E102,ASTGTM2N23E103,ASTGTM2N23E104,ASTGTM2N23E105,ASTGTM2N23E106,ASTGTM2N23E107,ASTGTM2N23E108,ASTGTM2N23E109,ASTGTM2N23E110,ASTGTM2N23E111,ASTGTM2N23E112,ASTGTM2N23E113,ASTGTM2N23E114,ASTGTM2N23E115,ASTGTM2N23E116,ASTGTM2N23E117,ASTGTM2N23E119,ASTGTM2N23E120,ASTGTM2N23E121,ASTGTM2N24E076,ASTGTM2N24E077,ASTGTM2N24E078,ASTGTM2N24E079,ASTGTM2N24E080,ASTGTM2N24E081,ASTGTM2N24E082,ASTGTM2N24E083,ASTGTM2N24E084,ASTGTM2N24E085,ASTGTM2N24E086,ASTGTM2N24E087,ASTGTM2N24E088,ASTGTM2N24E089,ASTGTM2N24E090,ASTGTM2N24E091,ASTGTM2N24E092,ASTGTM2N24E093,ASTGTM2N24E094,ASTGTM2N24E095,ASTGTM2N24E096,ASTGTM2N24E097,ASTGTM2N24E098,ASTGTM2N24E099,ASTGTM2N24E100,ASTGTM2N24E101,ASTGTM2N24E102,ASTGTM2N24E103,ASTGTM2N24E104,ASTGTM2N24E105,ASTGTM2N24E106,ASTGTM2N24E107,ASTGTM2N24E108,ASTGTM2N24E109,ASTGTM2N24E110,ASTGTM2N24E111,ASTGTM2N24E112,ASTGTM2N24E113,ASTGTM2N24E114,ASTGTM2N24E115,ASTGTM2N24E116,ASTGTM2N24E117,ASTGTM2N24E118,ASTGTM2N24E119,ASTGTM2N24E120,ASTGTM2N24E121,ASTGTM2N24E122,ASTGTM2N24E123,ASTGTM2N24E124,ASTGTM2N24E125,ASTGTM2N24E131,ASTGTM2N25E076,ASTGTM2N25E077,ASTGTM2N25E078,ASTGTM2N25E079,ASTGTM2N25E080,ASTGTM2N25E081,ASTGTM2N25E082,ASTGTM2N25E083,ASTGTM2N25E084,ASTGTM2N25E085,ASTGTM2N25E086,ASTGTM2N25E087,ASTGTM2N25E088,ASTGTM2N25E089,ASTGTM2N25E090,ASTGTM2N25E091,ASTGTM2N25E092,ASTGTM2N25E093,ASTGTM2N25E094,ASTGTM2N25E095,ASTGTM2N25E096,ASTGTM2N25E097,ASTGTM2N25E098,ASTGTM2N25E099,ASTGTM2N25E100,ASTGTM2N25E101,ASTGTM2N25E102,ASTGTM2N25E103,ASTGTM2N25E104,ASTGTM2N25E105,ASTGTM2N25E106,ASTGTM2N25E107,ASTGTM2N25E108,ASTGTM2N25E109,ASTGTM2N25E110,ASTGTM2N25E111,ASTGTM2N25E112,ASTGTM2N25E113,ASTGTM2N25E114,ASTGTM2N25E115,ASTGTM2N25E116,ASTGTM2N25E117,ASTGTM2N25E118,ASTGTM2N25E119,ASTGTM2N25E121,ASTGTM2N25E123,ASTGTM2N25E124,ASTGTM2N25E131,ASTGTM2N26E076,ASTGTM2N26E077,ASTGTM2N26E078,ASTGTM2N26E079,ASTGTM2N26E080,ASTGTM2N26E081,ASTGTM2N26E082,ASTGTM2N26E083,ASTGTM2N26E084,ASTGTM2N26E085,ASTGTM2N26E086,ASTGTM2N26E087,ASTGTM2N26E088,ASTGTM2N26E089,ASTGTM2N26E090,ASTGTM2N26E091,ASTGTM2N26E092,ASTGTM2N26E093,ASTGTM2N26E094,ASTGTM2N26E095,ASTGTM2N26E096,ASTGTM2N26E097,ASTGTM2N26E098,ASTGTM2N26E099,ASTGTM2N26E100,ASTGTM2N26E101,ASTGTM2N26E102,ASTGTM2N26E103,ASTGTM2N26E104,ASTGTM2N26E105,ASTGTM2N26E106,ASTGTM2N26E107,ASTGTM2N26E108,ASTGTM2N26E109,ASTGTM2N26E110,ASTGTM2N26E111,ASTGTM2N26E112,ASTGTM2N26E113,ASTGTM2N26E114,ASTGTM2N26E115,ASTGTM2N26E116,ASTGTM2N26E117,ASTGTM2N26E118,ASTGTM2N26E119,ASTGTM2N26E120,ASTGTM2N26E126,ASTGTM2N26E127,ASTGTM2N26E128,ASTGTM2N27E076,ASTGTM2N27E077,ASTGTM2N27E078,ASTGTM2N27E079,ASTGTM2N27E080,ASTGTM2N27E081,ASTGTM2N27E082,ASTGTM2N27E083,ASTGTM2N27E084,ASTGTM2N27E085,ASTGTM2N27E086,ASTGTM2N27E087,ASTGTM2N27E088,ASTGTM2N27E089,ASTGTM2N27E090,ASTGTM2N27E091,ASTGTM2N27E092,ASTGTM2N27E093,ASTGTM2N27E094,ASTGTM2N27E095,ASTGTM2N27E096,ASTGTM2N27E097,ASTGTM2N27E098,ASTGTM2N27E099,ASTGTM2N27E100,ASTGTM2N27E101,ASTGTM2N27E102,ASTGTM2N27E103,ASTGTM2N27E104,ASTGTM2N27E105,ASTGTM2N27E106,ASTGTM2N27E107,ASTGTM2N27E108,ASTGTM2N27E109,ASTGTM2N27E110,ASTGTM2N27E111,ASTGTM2N27E112,ASTGTM2N27E113,ASTGTM2N27E114,ASTGTM2N27E115,ASTGTM2N27E116,ASTGTM2N27E117,ASTGTM2N27E118,ASTGTM2N27E119,ASTGTM2N27E120,ASTGTM2N27E121,ASTGTM2N27E127,ASTGTM2N27E128,ASTGTM2N27E129,ASTGTM2N28E076,ASTGTM2N28E077,ASTGTM2N28E078,ASTGTM2N28E079,ASTGTM2N28E080,ASTGTM2N28E081,ASTGTM2N28E082,ASTGTM2N28E083,ASTGTM2N28E084,ASTGTM2N28E085,ASTGTM2N28E086,ASTGTM2N28E087,ASTGTM2N28E088,ASTGTM2N28E089,ASTGTM2N28E090,ASTGTM2N28E091,ASTGTM2N28E092,ASTGTM2N28E093,ASTGTM2N28E094,ASTGTM2N28E095,ASTGTM2N28E096,ASTGTM2N28E097,ASTGTM2N28E098,ASTGTM2N28E099,ASTGTM2N28E100,ASTGTM2N28E101,ASTGTM2N28E102,ASTGTM2N28E103,ASTGTM2N28E104,ASTGTM2N28E105,ASTGTM2N28E106,ASTGTM2N28E107,ASTGTM2N28E108,ASTGTM2N28E109,ASTGTM2N28E110,ASTGTM2N28E111,ASTGTM2N28E112,ASTGTM2N28E113,ASTGTM2N28E114,ASTGTM2N28E115,ASTGTM2N28E116,ASTGTM2N28E117,ASTGTM2N28E118,ASTGTM2N28E119,ASTGTM2N28E120,ASTGTM2N28E121,ASTGTM2N28E128,ASTGTM2N28E129,ASTGTM2N28E130,ASTGTM2N29E076,ASTGTM2N29E077,ASTGTM2N29E078,ASTGTM2N29E079,ASTGTM2N29E080,ASTGTM2N29E081,ASTGTM2N29E082,ASTGTM2N29E083,ASTGTM2N29E084,ASTGTM2N29E085,ASTGTM2N29E086,ASTGTM2N29E087,ASTGTM2N29E088,ASTGTM2N29E089,ASTGTM2N29E090,ASTGTM2N29E091,ASTGTM2N29E092,ASTGTM2N29E093,ASTGTM2N29E094,ASTGTM2N29E095,ASTGTM2N29E096,ASTGTM2N29E097,ASTGTM2N29E098,ASTGTM2N29E099,ASTGTM2N29E100,ASTGTM2N29E101,ASTGTM2N29E102,ASTGTM2N29E103,ASTGTM2N29E104,ASTGTM2N29E105,ASTGTM2N29E106,ASTGTM2N29E107,ASTGTM2N29E108,ASTGTM2N29E109,ASTGTM2N29E110,ASTGTM2N29E111,ASTGTM2N29E112,ASTGTM2N29E113,ASTGTM2N29E114,ASTGTM2N29E115,ASTGTM2N29E116,ASTGTM2N29E117,ASTGTM2N29E118,ASTGTM2N29E119,ASTGTM2N29E120,ASTGTM2N29E121,ASTGTM2N29E122,ASTGTM2N29E129,ASTGTM2N30E076,ASTGTM2N30E077,ASTGTM2N30E078,ASTGTM2N30E079,ASTGTM2N30E080,ASTGTM2N30E081,ASTGTM2N30E082,ASTGTM2N30E083,ASTGTM2N30E084,ASTGTM2N30E085,ASTGTM2N30E086,ASTGTM2N30E087,ASTGTM2N30E088,ASTGTM2N30E089,ASTGTM2N30E090,ASTGTM2N30E091,ASTGTM2N30E092,ASTGTM2N30E093,ASTGTM2N30E094,ASTGTM2N30E095,ASTGTM2N30E096,ASTGTM2N30E097,ASTGTM2N30E098,ASTGTM2N30E099,ASTGTM2N30E100,ASTGTM2N30E101,ASTGTM2N30E102,ASTGTM2N30E103,ASTGTM2N30E104,ASTGTM2N30E105,ASTGTM2N30E106,ASTGTM2N30E107,ASTGTM2N30E108,ASTGTM2N30E109,ASTGTM2N30E110,ASTGTM2N30E111,ASTGTM2N30E112,ASTGTM2N30E113,ASTGTM2N30E114,ASTGTM2N30E115,ASTGTM2N30E116,ASTGTM2N30E117,ASTGTM2N30E118,ASTGTM2N30E119,ASTGTM2N30E120,ASTGTM2N30E121,ASTGTM2N30E122,ASTGTM2N30E129,ASTGTM2N30E130,ASTGTM2N30E131,ASTGTM2N31E076,ASTGTM2N31E077,ASTGTM2N31E078,ASTGTM2N31E079,ASTGTM2N31E080,ASTGTM2N31E081,ASTGTM2N31E082,ASTGTM2N31E083,ASTGTM2N31E084,ASTGTM2N31E085,ASTGTM2N31E086,ASTGTM2N31E087,ASTGTM2N31E088,ASTGTM2N31E089,ASTGTM2N31E090,ASTGTM2N31E091,ASTGTM2N31E092,ASTGTM2N31E093,ASTGTM2N31E094,ASTGTM2N31E095,ASTGTM2N31E096,ASTGTM2N31E097,ASTGTM2N31E098,ASTGTM2N31E099,ASTGTM2N31E100,ASTGTM2N31E101,ASTGTM2N31E102,ASTGTM2N31E103,ASTGTM2N31E104,ASTGTM2N31E105,ASTGTM2N31E106,ASTGTM2N31E107,ASTGTM2N31E108,ASTGTM2N31E109,ASTGTM2N31E110,ASTGTM2N31E111,ASTGTM2N31E112,ASTGTM2N31E113,ASTGTM2N31E114,ASTGTM2N31E115,ASTGTM2N31E116,ASTGTM2N31E117,ASTGTM2N31E118,ASTGTM2N31E119,ASTGTM2N31E120,ASTGTM2N31E121,ASTGTM2N31E129,ASTGTM2N31E130,ASTGTM2N31E131,ASTGTM2N32E076,ASTGTM2N32E077,ASTGTM2N32E078,ASTGTM2N32E079,ASTGTM2N32E080,ASTGTM2N32E081,ASTGTM2N32E082,ASTGTM2N32E083,ASTGTM2N32E084,ASTGTM2N32E085,ASTGTM2N32E086,ASTGTM2N32E087,ASTGTM2N32E088,ASTGTM2N32E089,ASTGTM2N32E090,ASTGTM2N32E091,ASTGTM2N32E092,ASTGTM2N32E093,ASTGTM2N32E094,ASTGTM2N32E095,ASTGTM2N32E096,ASTGTM2N32E097,ASTGTM2N32E098,ASTGTM2N32E099,ASTGTM2N32E100,ASTGTM2N32E101,ASTGTM2N32E102,ASTGTM2N32E103,ASTGTM2N32E104,ASTGTM2N32E105,ASTGTM2N32E106,ASTGTM2N32E107,ASTGTM2N32E108,ASTGTM2N32E109,ASTGTM2N32E110,ASTGTM2N32E111,ASTGTM2N32E112,ASTGTM2N32E113,ASTGTM2N32E114,ASTGTM2N32E115,ASTGTM2N32E116,ASTGTM2N32E117,ASTGTM2N32E118,ASTGTM2N32E119,ASTGTM2N32E120,ASTGTM2N32E121,ASTGTM2N32E128,ASTGTM2N32E129,ASTGTM2N32E130,ASTGTM2N32E131,ASTGTM2N32E132,ASTGTM2N32E133,ASTGTM2S01E097,ASTGTM2S01E098,ASTGTM2S01E099,ASTGTM2S01E100,ASTGTM2S01E101,ASTGTM2S01E102,ASTGTM2S01E103,ASTGTM2S01E104,ASTGTM2S01E109,ASTGTM2S01E110,ASTGTM2S01E111,ASTGTM2S01E112,ASTGTM2S01E113,ASTGTM2S01E114,ASTGTM2S01E115,ASTGTM2S01E116,ASTGTM2S01E117,ASTGTM2S01E119,ASTGTM2S01E120,ASTGTM2S01E121,ASTGTM2S01E122,ASTGTM2S01E123,ASTGTM2S01E127,ASTGTM2S01E128,ASTGTM2S01E129,ASTGTM2S01E130,ASTGTM2S01E131,ASTGTM2S01E132,ASTGTM2S01E133,ASTGTM2S01E134,ASTGTM2S01E135,ASTGTM2S02E098,ASTGTM2S02E099,ASTGTM2S02E100,ASTGTM2S02E101,ASTGTM2S02E102,ASTGTM2S02E103,ASTGTM2S02E104,ASTGTM2S02E105,ASTGTM2S02E106,ASTGTM2S02E108,ASTGTM2S02E109,ASTGTM2S02E110,ASTGTM2S02E111,ASTGTM2S02E112,ASTGTM2S02E113,ASTGTM2S02E114,ASTGTM2S02E115,ASTGTM2S02E116,ASTGTM2S02E117,ASTGTM2S02E119,ASTGTM2S02E120,ASTGTM2S02E121,ASTGTM2S02E122,ASTGTM2S02E123,ASTGTM2S02E124,ASTGTM2S02E125,ASTGTM2S02E126,ASTGTM2S02E127,ASTGTM2S02E128,ASTGTM2S02E129,ASTGTM2S02E130,ASTGTM2S02E131,ASTGTM2S02E132,ASTGTM2S02E133,ASTGTM2S02E134,ASTGTM2S02E135,ASTGTM2S03E099,ASTGTM2S03E100,ASTGTM2S03E101,ASTGTM2S03E102,ASTGTM2S03E103,ASTGTM2S03E104,ASTGTM2S03E105,ASTGTM2S03E106,ASTGTM2S03E107,ASTGTM2S03E108,ASTGTM2S03E110,ASTGTM2S03E111,ASTGTM2S03E112,ASTGTM2S03E113,ASTGTM2S03E114,ASTGTM2S03E115,ASTGTM2S03E116,ASTGTM2S03E117,ASTGTM2S03E118,ASTGTM2S03E119,ASTGTM2S03E120,ASTGTM2S03E121,ASTGTM2S03E122,ASTGTM2S03E123,ASTGTM2S03E124,ASTGTM2S03E125,ASTGTM2S03E126,ASTGTM2S03E127,ASTGTM2S03E128,ASTGTM2S03E129,ASTGTM2S03E130,ASTGTM2S03E131,ASTGTM2S03E132,ASTGTM2S03E133,ASTGTM2S03E134,ASTGTM2S03E135,ASTGTM2S04E100,ASTGTM2S04E101,ASTGTM2S04E102,ASTGTM2S04E103,ASTGTM2S04E104,ASTGTM2S04E105,ASTGTM2S04E106,ASTGTM2S04E107,ASTGTM2S04E108,ASTGTM2S04E110,ASTGTM2S04E111,ASTGTM2S04E112,ASTGTM2S04E113,ASTGTM2S04E114,ASTGTM2S04E115,ASTGTM2S04E116,ASTGTM2S04E117,ASTGTM2S04E118,ASTGTM2S04E119,ASTGTM2S04E120,ASTGTM2S04E121,ASTGTM2S04E122,ASTGTM2S04E123,ASTGTM2S04E126,ASTGTM2S04E127,ASTGTM2S04E128,ASTGTM2S04E129,ASTGTM2S04E130,ASTGTM2S04E131,ASTGTM2S04E132,ASTGTM2S04E133,ASTGTM2S04E134,ASTGTM2S04E135,ASTGTM2S05E102,ASTGTM2S05E103,ASTGTM2S05E104,ASTGTM2S05E105,ASTGTM2S05E114,ASTGTM2S05E115,ASTGTM2S05E116,ASTGTM2S05E119,ASTGTM2S05E120,ASTGTM2S05E121,ASTGTM2S05E122,ASTGTM2S05E123,ASTGTM2S05E129,ASTGTM2S05E130,ASTGTM2S05E131,ASTGTM2S05E132,ASTGTM2S05E133,ASTGTM2S05E134,ASTGTM2S05E135,ASTGTM2S06E102,ASTGTM2S06E103,ASTGTM2S06E104,ASTGTM2S06E105,ASTGTM2S06E106,ASTGTM2S06E107,ASTGTM2S06E108,ASTGTM2S06E110,ASTGTM2S06E112,ASTGTM2S06E114,ASTGTM2S06E117,ASTGTM2S06E118,ASTGTM2S06E119,ASTGTM2S06E120,ASTGTM2S06E121,ASTGTM2S06E122,ASTGTM2S06E123,ASTGTM2S06E124,ASTGTM2S06E127,ASTGTM2S06E131,ASTGTM2S06E132,ASTGTM2S06E133,ASTGTM2S06E134,ASTGTM2S07E105,ASTGTM2S07E106,ASTGTM2S07E107,ASTGTM2S07E108,ASTGTM2S07E109,ASTGTM2S07E110,ASTGTM2S07E111,ASTGTM2S07E112,ASTGTM2S07E113,ASTGTM2S07E114,ASTGTM2S07E115,ASTGTM2S07E116,ASTGTM2S07E118,ASTGTM2S07E119,ASTGTM2S07E120,ASTGTM2S07E121,ASTGTM2S07E122,ASTGTM2S07E124,ASTGTM2S07E126,ASTGTM2S07E129,ASTGTM2S07E130,ASTGTM2S07E131,ASTGTM2S07E132,ASTGTM2S07E134,ASTGTM2S08E105,ASTGTM2S08E106,ASTGTM2S08E107,ASTGTM2S08E108,ASTGTM2S08E109,ASTGTM2S08E110,ASTGTM2S08E111,ASTGTM2S08E112,ASTGTM2S08E113,ASTGTM2S08E114,ASTGTM2S08E115,ASTGTM2S08E117,ASTGTM2S08E118,ASTGTM2S08E120,ASTGTM2S08E121,ASTGTM2S08E122,ASTGTM2S08E123,ASTGTM2S08E125,ASTGTM2S08E126,ASTGTM2S08E127,ASTGTM2S08E128,ASTGTM2S08E129,ASTGTM2S08E130,ASTGTM2S08E131,ASTGTM2S08E134,ASTGTM2S09E110,ASTGTM2S09E111,ASTGTM2S09E112,ASTGTM2S09E113,ASTGTM2S09E114,ASTGTM2S09E115,ASTGTM2S09E116,ASTGTM2S09E117,ASTGTM2S09E118,ASTGTM2S09E119,ASTGTM2S09E120,ASTGTM2S09E121,ASTGTM2S09E122,ASTGTM2S09E123,ASTGTM2S09E124,ASTGTM2S09E125,ASTGTM2S09E126,ASTGTM2S09E127,ASTGTM2S09E128,ASTGTM2S09E129,ASTGTM2S09E130,ASTGTM2S09E131,ASTGTM2S10E116,ASTGTM2S10E117,ASTGTM2S10E118,ASTGTM2S10E119,ASTGTM2S10E120,ASTGTM2S10E123,ASTGTM2S10E124,ASTGTM2S10E125,ASTGTM2S10E126,ASTGTM2S11E105,ASTGTM2S11E119,ASTGTM2S11E120,ASTGTM2S11E121,ASTGTM2S11E122,ASTGTM2S11E123,ASTGTM2S11E124,ASTGTM2S11E132,ASTGTM2S11E133,ASTGTM2S12E122,ASTGTM2S12E130,ASTGTM2S12E131,ASTGTM2S12E132,ASTGTM2S12E133,ASTGTM2S12E134,ASTGTM2S12E135,ASTGTM2S13E096,ASTGTM2S13E130,ASTGTM2S13E131,ASTGTM2S13E132,ASTGTM2S13E133,ASTGTM2S13E134,ASTGTM2S13E135,ASTGTM2S14E125,ASTGTM2S14E126,ASTGTM2S14E127,ASTGTM2S14E129,ASTGTM2S14E130,ASTGTM2S14E131,ASTGTM2S14E132,ASTGTM2S14E133,ASTGTM2S14E134,ASTGTM2S14E135 *GRASS 6.4.3 (wgs84pure):~/grassdata/import > * -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Wed Sep 24 06:21:55 2014 From: neteler at osgeo.org (Markus Neteler) Date: Wed, 24 Sep 2014 15:21:55 +0200 Subject: [GRASS-user] r.patch number of input limitation? In-Reply-To: References: Message-ID: On Wed, Sep 24, 2014 at 2:40 PM, Robert Kuszinger wrote: > > Hello! > > > I'm trying to patch 1393 pieces of raster images with r.patch. > > before r.patch, the projection is set as follows: > > > projection: 3 (Latitude-Longitude) > zone: 0 > datum: wgs84 > ellipsoid: wgs84 > north: 33:00:00.5N > south: 14:00:00.5S > west: 75:59:59.5E > east: 136:00:00.5E > nsres: 0:01:00.000355 > ewres: 0:01:00.000278 > rows: 2820 > cols: 3600 > cells: 10152000 > > As you see, the target mosaic is set to be a moderate resolution by setting > es/nwres to 1 minute instead of seconds. > > I do then: > > GRASS 6.4.3 (wgs84pure):~/grassdata/import > MAPS=`g.mlist type=rast sep=, > pat="AST*"` > GRASS 6.4.3 (wgs84pure):~/grassdata/import > r.patch in=$MAPS out=mosaic > WARNING: Unable to open raster map > ERROR: One or more input raster maps not found > > How could it be? Is there a limitation on the string what r.patch is parsing > from the command line? It is indeed the operating system which limits the number of open files. For Linux, it is likely 1024 files. I have now added a note to the manual of r.patch (using those of r.series). For a solution, see also http://grasswiki.osgeo.org/wiki/Large_raster_data_processing#Number_of_open_files_limitation You can increase this limit. Hope this helps, Markus From wenzeslaus at gmail.com Wed Sep 24 06:38:28 2014 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Wed, 24 Sep 2014 09:38:28 -0400 Subject: [GRASS-user] r.patch number of input limitation? In-Reply-To: References: Message-ID: On Wed, Sep 24, 2014 at 9:21 AM, Markus Neteler wrote: > On Wed, Sep 24, 2014 at 2:40 PM, Robert Kuszinger > wrote: > > > > Hello! > > > > > > I'm trying to patch 1393 pieces of raster images with r.patch. > > > > before r.patch, the projection is set as follows: > > > > > > projection: 3 (Latitude-Longitude) > > zone: 0 > > datum: wgs84 > > ellipsoid: wgs84 > > north: 33:00:00.5N > > south: 14:00:00.5S > > west: 75:59:59.5E > > east: 136:00:00.5E > > nsres: 0:01:00.000355 > > ewres: 0:01:00.000278 > > rows: 2820 > > cols: 3600 > > cells: 10152000 > > > > As you see, the target mosaic is set to be a moderate resolution by > setting > > es/nwres to 1 minute instead of seconds. > > > > I do then: > > > > GRASS 6.4.3 (wgs84pure):~/grassdata/import > MAPS=`g.mlist type=rast > sep=, > > pat="AST*"` > > GRASS 6.4.3 (wgs84pure):~/grassdata/import > r.patch in=$MAPS out=mosaic > > WARNING: Unable to open raster map > > ERROR: One or more input raster maps not found > > > > How could it be? Is there a limitation on the string what r.patch is > parsing > > from the command line? > > It is indeed the operating system which limits the number of open > files. For Linux, it is likely 1024 files. > I have now added a note to the manual of r.patch (using those of r.series). > > Would it be possible to provide some possible reasons/suggestions in the error message? (the wording should be that it is "possible reason") > For a solution, see also > > > http://grasswiki.osgeo.org/wiki/Large_raster_data_processing#Number_of_open_files_limitation > > You can increase this limit. > > Hope this helps, > Markus > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Wed Sep 24 06:51:07 2014 From: neteler at osgeo.org (Markus Neteler) Date: Wed, 24 Sep 2014 15:51:07 +0200 Subject: [GRASS-user] r.patch number of input limitation? In-Reply-To: References: Message-ID: On Wed, Sep 24, 2014 at 3:38 PM, Vaclav Petras wrote: > On Wed, Sep 24, 2014 at 9:21 AM, Markus Neteler wrote: >> >> On Wed, Sep 24, 2014 at 2:40 PM, Robert Kuszinger >> wrote: ... >> > I'm trying to patch 1393 pieces of raster images with r.patch. ... >> > GRASS 6.4.3 (wgs84pure):~/grassdata/import > r.patch in=$MAPS out=mosaic >> > WARNING: Unable to open raster map >> > ERROR: One or more input raster maps not found ... > Would it be possible to provide some possible reasons/suggestions in the > error message? (the wording should be that it is "possible reason") Probably not. I think that the messages comes from a generic libgis or librast function. Markus >> For a solution, see also >> >> >> http://grasswiki.osgeo.org/wiki/Large_raster_data_processing#Number_of_open_files_limitation >> >> You can increase this limit. From kuszinger at giscom.hu Wed Sep 24 06:52:31 2014 From: kuszinger at giscom.hu (Robert Kuszinger) Date: Wed, 24 Sep 2014 15:52:31 +0200 Subject: [GRASS-user] r.patch number of input limitation? In-Reply-To: References: Message-ID: Dear Markus, great, it works. I've reconfigured the workstation and now it runs... I've also read the others tips there which are all great. Vaclav: let me answer... I think this error message is from the underlying OS which is hard to classify and comment with a good hit rate, especially in cross-OS systems. File number limitation may cause a "file cannot open" and depending on developer frameworks - not only GRASS - it is not easy to differentiate... Thanks all to you for the fast help! Robert 2014-09-24 15:38 GMT+02:00 Vaclav Petras : > >> >> It is indeed the operating system which limits the number of open >> files. For Linux, it is likely 1024 files. >> I have now added a note to the manual of r.patch (using those of >> r.series). >> >> Would it be possible to provide some possible reasons/suggestions in the > error message? (the wording should be that it is "possible reason") > > >> For a solution, see also >> >> >> http://grasswiki.osgeo.org/wiki/Large_raster_data_processing#Number_of_open_files_limitation >> >> You can increase this limit. >> >> Hope this helps, >> Markus >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlevente89 at gmail.com Wed Sep 24 07:22:54 2014 From: jlevente89 at gmail.com (=?UTF-8?Q?Levente_Juh=C3=A1sz?=) Date: Wed, 24 Sep 2014 10:22:54 -0400 Subject: [GRASS-user] removing small lines Message-ID: Hi all, I've seen that the remove_small method of v.generalize has been eliminated. Reduction method does not work in the way I want since it just removes point from lines and it seems like has no effect on a line of 2 points - even if they're smaller than the threshold. Can someone tell me what the workaround is for removing small lines from a vector for example by a threshold in map units? Cheers, Levente -------------- next part -------------- An HTML attachment was scrubbed... URL: From glynn at gclements.plus.com Wed Sep 24 15:44:22 2014 From: glynn at gclements.plus.com (Glynn Clements) Date: Wed, 24 Sep 2014 23:44:22 +0100 Subject: [GRASS-user] r.patch number of input limitation? In-Reply-To: References: Message-ID: <21539.18758.514332.953404@cerise.gclements.plus.com> Markus Neteler wrote: > >> > GRASS 6.4.3 (wgs84pure):~/grassdata/import > r.patch in=$MAPS out=mosaic > >> > WARNING: Unable to open raster map > >> > ERROR: One or more input raster maps not found > ... > > Would it be possible to provide some possible reasons/suggestions in the > > error message? (the wording should be that it is "possible reason") > > Probably not. I think that the messages comes from a generic libgis or > librast function. In 7.x, G__open() will generate a warning message which includes strerror(errno) if the open() call fails. OTOH, 7.x requires twice as many descriptors per map, as it keeps both the cell (or fcell) and null files open, whereas 6.x closes the null file after reading each chunk. For modules which often open a large number of maps (e.g. r.patch, r.series), we could check the estimated number of open files against the result of sysconf(_SC_OPEN_MAX) (at least for Unix) and warn the user if the limit is likely to be exceeded. -- Glynn Clements From mark at dimensionaledge.com Wed Sep 24 19:30:42 2014 From: mark at dimensionaledge.com (Mark Wynter) Date: Thu, 25 Sep 2014 12:00:42 +0930 Subject: [GRASS-user] Compilation Errors Installing GRASS 70 on Centos 6.5 Message-ID: Upon running ?make?, I get errors consistent with the message below. Any clues as to the source of the Error 1 messages, and what the fix is? Thanks Mark ##### make -C v.centroids || echo /home/grass/grass70/releasebranch_7_0/scripts/v.centroids >> /home/grass/grass70/releasebranch_7_0/error.log make[3]: Entering directory `/home/grass/grass70/releasebranch_7_0/scripts/v.centroids' if [ "/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/scripts/v.centroids" != "" ] ; then GISRC=/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/demolocation/.grassrc70 GISBASE=/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu PATH="/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/bin:/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/bin:/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/scripts:$PATH" PYTHONPATH="/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/etc/python:/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/gui/wxpython:$PYTHONPATH" LD_LIBRARY_PATH="/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/bin:/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/scripts:/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/lib:/home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/lib:" LC_ALL=C /home/grass/grass70/releasebranch_7_0/dist.x86_64-unknown-linux-gnu/scripts/v.centroids --html-description < /dev/null | grep -v '\|' > v.centroids.tmp.html ; fi make[3]: *** [v.centroids.tmp.html] Error 1 rm v.centroids.tmp.html make[3]: Leaving directory `/home/grass/grass70/releasebranch_7_0/scripts/v.centroids? #Essentially the same errors for??.. Errors in: /home/grass/grass70/releasebranch_7_0/scripts/d.correlate /home/grass/grass70/releasebranch_7_0/scripts/d.out.file /home/grass/grass70/releasebranch_7_0/scripts/d.polar /home/grass/grass70/releasebranch_7_0/scripts/d.rast.edit /home/grass/grass70/releasebranch_7_0/scripts/d.rast.leg /home/grass/grass70/releasebranch_7_0/scripts/d.redraw /home/grass/grass70/releasebranch_7_0/scripts/d.shadedmap /home/grass/grass70/releasebranch_7_0/scripts/d.vect.thematic /home/grass/grass70/releasebranch_7_0/scripts/db.dropcolumn /home/grass/grass70/releasebranch_7_0/scripts/db.droptable /home/grass/grass70/releasebranch_7_0/scripts/db.in.ogr /home/grass/grass70/releasebranch_7_0/scripts/db.out.ogr /home/grass/grass70/releasebranch_7_0/scripts/db.test /home/grass/grass70/releasebranch_7_0/scripts/g.extension.all /home/grass/grass70/releasebranch_7_0/scripts/g.manual /home/grass/grass70/releasebranch_7_0/scripts/i.colors.enhance /home/grass/grass70/releasebranch_7_0/scripts/i.image.mosaic /home/grass/grass70/releasebranch_7_0/scripts/i.in.spotvgt /home/grass/grass70/releasebranch_7_0/scripts/i.oif /home/grass/grass70/releasebranch_7_0/scripts/i.pansharpen /home/grass/grass70/releasebranch_7_0/scripts/i.spectral /home/grass/grass70/releasebranch_7_0/scripts/i.tasscap /home/grass/grass70/releasebranch_7_0/scripts/m.proj /home/grass/grass70/releasebranch_7_0/scripts/r.blend /home/grass/grass70/releasebranch_7_0/scripts/r.buffer.lowmem /home/grass/grass70/releasebranch_7_0/scripts/r.colors.stddev /home/grass/grass70/releasebranch_7_0/scripts/r.fillnulls /home/grass/grass70/releasebranch_7_0/scripts/r.grow /home/grass/grass70/releasebranch_7_0/scripts/r.in.aster /home/grass/grass70/releasebranch_7_0/scripts/r.in.srtm /home/grass/grass70/releasebranch_7_0/scripts/r.in.wms /home/grass/grass70/releasebranch_7_0/scripts/r.mask /home/grass/grass70/releasebranch_7_0/scripts/r.out.xyz /home/grass/grass70/releasebranch_7_0/scripts/r.pack /home/grass/grass70/releasebranch_7_0/scripts/r.plane /home/grass/grass70/releasebranch_7_0/scripts/r.reclass.area /home/grass/grass70/releasebranch_7_0/scripts/r.rgb /home/grass/grass70/releasebranch_7_0/scripts/r.tileset /home/grass/grass70/releasebranch_7_0/scripts/r.unpack /home/grass/grass70/releasebranch_7_0/scripts/r3.in.xyz /home/grass/grass70/releasebranch_7_0/scripts/v.build.all /home/grass/grass70/releasebranch_7_0/scripts/v.centroids /home/grass/grass70/releasebranch_7_0/scripts/v.convert.all /home/grass/grass70/releasebranch_7_0/scripts/v.db.addcolumn /home/grass/grass70/releasebranch_7_0/scripts/v.db.addtable #The steps I followed to this point: #Instructions for installing the dependencies with a couple of additional packages needed #http://grasswiki.osgeo.org/wiki/Compile_and_Install#CentOS #yum -y install readline readline-devel cd /home/grass/grass70/releasebranch_7_0 CFLAGS="-g" ./configure \ --enable-debug \ --with-cxx \ --without-ffmpeg \ --with-gdal=/usr/bin/gdal-config \ --with-geos \ --with-readline \ --with-freetype=yes \ --with-freetype-includes="/usr/include/freetype2/" \ --enable-largefile=yes \ --with-proj-share=/usr/share/proj/ \ --with-geos=/usr/bin/geos-config \ --with-cairo \ --with-tcltk-includes="/usr/lib64/tcl8.5/" \ --with-wxwidgets=/usr/bin/wx-config \ --with-postgres=yes \ --with-postgres-libs="/usr/pgsql-9.3/lib/" \ --with-postgres-includes="/usr/pgsql-9.3/include/" \ --with-sqlite=yes \ --with-python=yes \ --with-opengl-libs="/usr/include/GL" --without-mysql \ GRASS is now configured for: x86_64-unknown-linux-gnu Source directory: /home/grass/grass70/releasebranch_7_0 Build directory: /home/grass/grass70/releasebranch_7_0 Installation directory: ${prefix}/grass-7.0.0svn Startup script in directory:${exec_prefix}/bin C compiler: gcc -g C++ compiler: c++ -g -O2 Building shared libraries: yes OpenGL platform: X11 MacOSX application: no MacOSX architectures: MacOSX SDK: BLAS support: no C++ support: yes Cairo support: yes DWG support: no FFTW support: yes FreeType support: yes GDAL support: yes GEOS support: yes LAPACK support: no Large File support (LFS): yes libLAS support: no MySQL support: no NetCDF support: no NLS support: no ODBC support: no OGR support: yes OpenCL support: no OpenGL support: yes OpenMP support: no PNG support: yes POSIX thread support: no PostgreSQL support: yes Readline support: yes Regex support: yes SQLite support: yes TIFF support: yes wxWidgets support: yes X11 support: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at dimensionaledge.com Wed Sep 24 23:44:59 2014 From: mark at dimensionaledge.com (Mark Wynter) Date: Thu, 25 Sep 2014 16:14:59 +0930 Subject: [GRASS-user] SOLVED: Compilation Errors Installing GRASS 70 on Centos 6.5 Message-ID: Re-checked out SVN Clean install directory Installed without a hitch :-) From neteler at osgeo.org Thu Sep 25 01:25:25 2014 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 25 Sep 2014 10:25:25 +0200 Subject: [GRASS-user] removing small lines In-Reply-To: References: Message-ID: On Wed, Sep 24, 2014 at 4:22 PM, Levente Juh?sz wrote: > Hi all, > > I've seen that the remove_small method of v.generalize has been eliminated. > Reduction method does not work in the way I want since it just removes point > from lines and it seems like has no effect on a line of 2 points - even if > they're smaller than the threshold. > Can someone tell me what the workaround is for removing small lines from a > vector for example by a threshold in map units? You may use v.to.db and option=length (line length), then use v.extract to extract into a new map according to a threshold you need. Markus From luis.miguel.royo at gmail.com Thu Sep 25 01:35:52 2014 From: luis.miguel.royo at gmail.com (=?UTF-8?B?THVpcyBNaWd1ZWwgUm95byBQw6lyZXo=?=) Date: Thu, 25 Sep 2014 10:35:52 +0200 Subject: [GRASS-user] Problems with r.viewshed Message-ID: <5423D3E8.5090206@gmail.com> Hi everyone, when I try to run r.viewshed the output shows me this: Nodata value set to -nan rows=198, cols=217, total = 42966 In-memory memory usage is 4298336 B (4 MB), max mem allowed=524288000 B(500MB) ***** IN_MEMORY MODE ***** Start sweeping. Computing events ... Sorting events... Terminado. Determine visibility... r.viewshed: statusstructure.cpp:73: float get_vertical_angle(Viewpoint, StatusNode, surface_type, int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se cumple. Anyone has a clue about what it could be happening? I'm using GRASS 6.4.4 in Xubuntu 14.04. I think I must say that a few days ago I installed GRASS 7 but I removed it and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? Thanks a lot!!! ------------ pr?xima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From neteler at osgeo.org Thu Sep 25 03:46:13 2014 From: neteler at osgeo.org (Markus Neteler) Date: Thu, 25 Sep 2014 12:46:13 +0200 Subject: [GRASS-user] Problems with r.viewshed In-Reply-To: <5423D3E8.5090206@gmail.com> References: <5423D3E8.5090206@gmail.com> Message-ID: On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez wrote: > Hi everyone, > > when I try to run r.viewshed the output shows me this: (in GRASS 6 it is an Addon) > Nodata value set to -nan > rows=198, cols=217, total = 42966 > In-memory memory usage is 4298336 B (4 MB), max mem > allowed=524288000 B(500MB) > ***** IN_MEMORY MODE ***** > Start sweeping. > Computing events ... > Sorting events... > Terminado. > Determine visibility... > r.viewshed: statusstructure.cpp:73: float > get_vertical_angle(Viewpoint, StatusNode, surface_type, > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > cumple. > > Anyone has a clue about what it could be happening? > > I'm using GRASS 6.4.4 in Xubuntu 14.04. I have backported some fixes from GRASS 7 to the addon in GRASS 6. Please reinstall the addon with g.extension and try again. > I think I must say that a few days ago I installed GRASS 7 but I removed it > and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? No, GRASS 6 and 7 can happily live together. Please let us know if the updated Addon runs ok for you. Markus From luis.miguel.royo at gmail.com Thu Sep 25 05:11:36 2014 From: luis.miguel.royo at gmail.com (=?UTF-8?B?THVpcyBNaWd1ZWwgUm95byBQw6lyZXo=?=) Date: Thu, 25 Sep 2014 14:11:36 +0200 Subject: [GRASS-user] Problems with r.viewshed In-Reply-To: References: <5423D3E8.5090206@gmail.com> Message-ID: <54240678.7060005@gmail.com> I'm sorry but it didn't work. I have reinstalled the addon but it didn't work, reinstalled GRASS 6.4 and neither, then installed GRASS7 again, and appears this message: r.viewshed -b input=Portada at inisig output=visPort coordinates=-3.74034324324,42.5352702703 obs_elev=9 tgt_elev=1.75 max_dist=30000 Computing events... Computing visibility... r.viewshed: statusstructure.cpp:73: float get_vertical_angle(Viewpoint, StatusNode, surface_type, int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se cumple. I will try in another PC. Thank you for your time. El 25/09/14 a las #4, Markus Neteler escribi?: > On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez > wrote: >> Hi everyone, >> >> when I try to run r.viewshed the output shows me this: > (in GRASS 6 it is an Addon) > >> Nodata value set to -nan >> rows=198, cols=217, total = 42966 >> In-memory memory usage is 4298336 B (4 MB), max mem >> allowed=524288000 B(500MB) >> ***** IN_MEMORY MODE ***** >> Start sweeping. >> Computing events ... >> Sorting events... >> Terminado. >> Determine visibility... >> r.viewshed: statusstructure.cpp:73: float >> get_vertical_angle(Viewpoint, StatusNode, surface_type, >> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se >> cumple. >> >> Anyone has a clue about what it could be happening? >> >> I'm using GRASS 6.4.4 in Xubuntu 14.04. > I have backported some fixes from GRASS 7 to the addon in GRASS 6. > Please reinstall the addon with g.extension and try again. > >> I think I must say that a few days ago I installed GRASS 7 but I removed it >> and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > No, GRASS 6 and 7 can happily live together. > > Please let us know if the updated Addon runs ok for you. > > Markus ------------ pr?xima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From pedro.palheiro at gmail.com Thu Sep 25 16:15:36 2014 From: pedro.palheiro at gmail.com (Pedro Palheiro) Date: Fri, 26 Sep 2014 00:15:36 +0100 Subject: [GRASS-user] Problems with r.viewshed Message-ID: Hello Luis, Maybe it is a coordinate reference system problem? It looks like you're using wgs84 for the input and coordinates, and requesting the calculation in meters (obs_elev, tgt_elev and max_dist). Try to change the CRS to see if it works. r.viewshed -b input=Portada at inisig output=visPort *coordinates=-3.74034324324,42.5352702703* obs_elev=9 tgt_elev=1.75 max_dist=30000 Computing events... Computing visibility... r.viewshed: statusstructure.cpp:73: float get_vertical_angle(Viewpoint, StatusNode, surface_type, int): La declaraci?n `*fabs(sn.dist2vp) > 0.001*' no se cumple. Adios, Pedro Palheiro 2014-09-25 20:00 GMT+01:00 : > Send grass-user mailing list submissions to > grass-user at lists.osgeo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/grass-user > or, via email, send a message with subject or body 'help' to > grass-user-request at lists.osgeo.org > > You can reach the person managing the list at > grass-user-owner at lists.osgeo.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of grass-user digest..." > > > Today's Topics: > > 1. Re: removing small lines (Markus Neteler) > 2. Problems with r.viewshed (Luis Miguel Royo P?rez) > 3. Re: Problems with r.viewshed (Markus Neteler) > 4. Re: Problems with r.viewshed (Luis Miguel Royo P?rez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Sep 2014 10:25:25 +0200 > From: Markus Neteler > To: Levente Juh?sz > Cc: GRASS user list > Subject: Re: [GRASS-user] removing small lines > Message-ID: > me+C_8o6+Y9CTA1P-cofD3NemuyE30uBmvF5Q at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Wed, Sep 24, 2014 at 4:22 PM, Levente Juh?sz > wrote: > > Hi all, > > > > I've seen that the remove_small method of v.generalize has been > eliminated. > > Reduction method does not work in the way I want since it just removes > point > > from lines and it seems like has no effect on a line of 2 points - even > if > > they're smaller than the threshold. > > Can someone tell me what the workaround is for removing small lines from > a > > vector for example by a threshold in map units? > > > You may use v.to.db and option=length (line length), then use > v.extract to extract into a new map according to a threshold you need. > > Markus > > > ------------------------------ > > Message: 2 > Date: Thu, 25 Sep 2014 10:35:52 +0200 > From: Luis Miguel Royo P?rez < > ?? > luis.miguel.royo at gmail.com> > To: grass-user at lists.osgeo.org > Subject: [GRASS-user] Problems with r.viewshed > Message-ID: <5423D3E8.5090206 at gmail.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi everyone, > > when I try to run r.viewshed the output shows me this: > > Nodata value set to -nan > rows=198, cols=217, total = 42966 > In-memory memory usage is 4298336 B (4 MB), max mem > allowed=524288000 B(500MB) > ***** IN_MEMORY MODE ***** > Start sweeping. > Computing events ... > Sorting events... > Terminado. > Determine visibility... > r.viewshed: statusstructure.cpp:73: float > get_vertical_angle(Viewpoint, StatusNode, surface_type, > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > cumple. > > Anyone has a clue about what it could be happening? > > I'm using GRASS 6.4.4 in Xubuntu 14.04. > > I think I must say that a few days ago I installed GRASS 7 but I removed > it and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > > > Thanks a lot!!! > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/grass-user/attachments/20140925/15c0ab71/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 25 Sep 2014 12:46:13 +0200 > From: Markus Neteler > To: Luis Miguel Royo P?rez > Cc: GRASS user list > Subject: Re: [GRASS-user] Problems with r.viewshed > Message-ID: > sVaXsFFEOaTALg at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez > wrote: > > Hi everyone, > > > > when I try to run r.viewshed the output shows me this: > > (in GRASS 6 it is an Addon) > > > Nodata value set to -nan > > rows=198, cols=217, total = 42966 > > In-memory memory usage is 4298336 B (4 MB), max mem > > allowed=524288000 B(500MB) > > ***** IN_MEMORY MODE ***** > > Start sweeping. > > Computing events ... > > Sorting events... > > Terminado. > > Determine visibility... > > r.viewshed: statusstructure.cpp:73: float > > get_vertical_angle(Viewpoint, StatusNode, surface_type, > > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > > cumple. > > > > Anyone has a clue about what it could be happening? > > > > I'm using GRASS 6.4.4 in Xubuntu 14.04. > > I have backported some fixes from GRASS 7 to the addon in GRASS 6. > Please reinstall the addon with g.extension and try again. > > > I think I must say that a few days ago I installed GRASS 7 but I removed > it > > and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > > No, GRASS 6 and 7 can happily live together. > > Please let us know if the updated Addon runs ok for you. > > Markus > > > ------------------------------ > > Message: 4 > Date: Thu, 25 Sep 2014 14:11:36 +0200 > From: Luis Miguel Royo P?rez > To: Markus Neteler > Cc: GRASS user list > Subject: Re: [GRASS-user] Problems with r.viewshed > Message-ID: <54240678.7060005 at gmail.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > I'm sorry but it didn't work. > > I have reinstalled the addon but it didn't work, reinstalled GRASS 6.4 > and neither, then installed GRASS7 again, and appears this message: > > r.viewshed -b input=Portada at inisig output=visPort > coordinates=-3.74034324324,42.5352702703 obs_elev=9 tgt_elev=1.75 > max_dist=30000 > Computing events... > Computing visibility... > r.viewshed: statusstructure.cpp:73: float > get_vertical_angle(Viewpoint, StatusNode, surface_type, > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > cumple. > > > I will try in another PC. > > Thank you for your time. > > El 25/09/14 a las #4, Markus Neteler escribi?: > > On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez > > wrote: > >> Hi everyone, > >> > >> when I try to run r.viewshed the output shows me this: > > (in GRASS 6 it is an Addon) > > > >> Nodata value set to -nan > >> rows=198, cols=217, total = 42966 > >> In-memory memory usage is 4298336 B (4 MB), max mem > >> allowed=524288000 B(500MB) > >> ***** IN_MEMORY MODE ***** > >> Start sweeping. > >> Computing events ... > >> Sorting events... > >> Terminado. > >> Determine visibility... > >> r.viewshed: statusstructure.cpp:73: float > >> get_vertical_angle(Viewpoint, StatusNode, surface_type, > >> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > >> cumple. > >> > >> Anyone has a clue about what it could be happening? > >> > >> I'm using GRASS 6.4.4 in Xubuntu 14.04. > > I have backported some fixes from GRASS 7 to the addon in GRASS 6. > > Please reinstall the addon with g.extension and try again. > > > >> I think I must say that a few days ago I installed GRASS 7 but I > removed it > >> and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > > No, GRASS 6 and 7 can happily live together. > > > > Please let us know if the updated Addon runs ok for you. > > > > Markus > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.osgeo.org/pipermail/grass-user/attachments/20140925/edaf5af2/attachment-0001.html > > > > ------------------------------ > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > End of grass-user Digest, Vol 101, Issue 39 > ******************************************* > -- Pedro Palheiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From diregola at gmail.com Fri Sep 26 02:56:24 2014 From: diregola at gmail.com (Margherita Di Leo) Date: Fri, 26 Sep 2014 11:56:24 +0200 Subject: [GRASS-user] how to tweak the parameters to speed up i.segment Message-ID: Hi, I have not clear understanding how the parameters meansize, iterations, memory, etc. in i.segment could be tweaked to speed up the running time. In which direction should they be tuned and what are the drawbacks? Is there some trick? ;-) Thank you in advance -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-leo at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From luis.miguel.royo at gmail.com Fri Sep 26 03:37:19 2014 From: luis.miguel.royo at gmail.com (=?UTF-8?B?THVpcyBNaWd1ZWwgUm95byBQw6lyZXo=?=) Date: Fri, 26 Sep 2014 12:37:19 +0200 Subject: [GRASS-user] Problems with r.viewshed In-Reply-To: References: Message-ID: <542541DF.8030800@gmail.com> Thank you very much. That was the problem. Sorry for any inconvenience. Kind regards. El 26/09/14 a las #4, Pedro Palheiro escribi?: > Hello Luis, > > Maybe it is a coordinate reference system problem? It looks like > you're using wgs84 for the input and coordinates, and requesting the > calculation in meters (obs_elev, tgt_elev and max_dist). Try to change > the CRS to see if it works. > > r.viewshed -b input=Portada at inisig output=visPort > *coordinates=-3.74034324324,42.5352702703* > obs_elev=9 tgt_elev=1.75 > max_dist=30000 > Computing events... > Computing visibility... > r.viewshed: statusstructure.cpp:73: float > get_vertical_angle(Viewpoint, StatusNode, surface_type, > int): La declaraci?n `*fabs(sn.dist2vp) > 0.001*' no se > cumple. > > Adios, > Pedro Palheiro > > > 2014-09-25 20:00 GMT+01:00 >: > > Send grass-user mailing list submissions to > grass-user at lists.osgeo.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.osgeo.org/mailman/listinfo/grass-user > or, via email, send a message with subject or body 'help' to > grass-user-request at lists.osgeo.org > > > You can reach the person managing the list at > grass-user-owner at lists.osgeo.org > > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of grass-user digest..." > > > Today's Topics: > > 1. Re: removing small lines (Markus Neteler) > 2. Problems with r.viewshed (Luis Miguel Royo P?rez) > 3. Re: Problems with r.viewshed (Markus Neteler) > 4. Re: Problems with r.viewshed (Luis Miguel Royo P?rez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 25 Sep 2014 10:25:25 +0200 > From: Markus Neteler > > To: Levente Juh?sz > > Cc: GRASS user list > > Subject: Re: [GRASS-user] removing small lines > Message-ID: > > > > Content-Type: text/plain; charset=UTF-8 > > On Wed, Sep 24, 2014 at 4:22 PM, Levente Juh?sz > > wrote: > > Hi all, > > > > I've seen that the remove_small method of v.generalize has been > eliminated. > > Reduction method does not work in the way I want since it just > removes point > > from lines and it seems like has no effect on a line of 2 points > - even if > > they're smaller than the threshold. > > Can someone tell me what the workaround is for removing small > lines from a > > vector for example by a threshold in map units? > > > You may use v.to.db and option=length (line length), then use > v.extract to extract into a new map according to a threshold you need. > > Markus > > > ------------------------------ > > Message: 2 > Date: Thu, 25 Sep 2014 10:35:52 +0200 > From: Luis Miguel Royo P?rez < > ? ? > luis.miguel.royo at gmail.com > > To: grass-user at lists.osgeo.org > Subject: [GRASS-user] Problems with r.viewshed > Message-ID: <5423D3E8.5090206 at gmail.com > > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi everyone, > > when I try to run r.viewshed the output shows me this: > > Nodata value set to -nan > rows=198, cols=217, total = 42966 > In-memory memory usage is 4298336 B (4 MB), max mem > allowed=524288000 B(500MB) > ***** IN_MEMORY MODE ***** > Start sweeping. > Computing events ... > Sorting events... > Terminado. > Determine visibility... > r.viewshed: statusstructure.cpp:73: float > get_vertical_angle(Viewpoint, StatusNode, surface_type, > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > cumple. > > Anyone has a clue about what it could be happening? > > I'm using GRASS 6.4.4 in Xubuntu 14.04. > > I think I must say that a few days ago I installed GRASS 7 but I > removed > it and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > > > Thanks a lot!!! > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Message: 3 > Date: Thu, 25 Sep 2014 12:46:13 +0200 > From: Markus Neteler > > To: Luis Miguel Royo P?rez > > Cc: GRASS user list > > Subject: Re: [GRASS-user] Problems with r.viewshed > Message-ID: > > > > Content-Type: text/plain; charset=UTF-8 > > On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez > > > wrote: > > Hi everyone, > > > > when I try to run r.viewshed the output shows me this: > > (in GRASS 6 it is an Addon) > > > Nodata value set to -nan > > rows=198, cols=217, total = 42966 > > In-memory memory usage is 4298336 B (4 MB), max mem > > allowed=524288000 B(500MB) > > ***** IN_MEMORY MODE ***** > > Start sweeping. > > Computing events ... > > Sorting events... > > Terminado. > > Determine visibility... > > r.viewshed: statusstructure.cpp:73: float > > get_vertical_angle(Viewpoint, StatusNode, surface_type, > > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > > cumple. > > > > Anyone has a clue about what it could be happening? > > > > I'm using GRASS 6.4.4 in Xubuntu 14.04. > > I have backported some fixes from GRASS 7 to the addon in GRASS 6. > Please reinstall the addon with g.extension and try again. > > > I think I must say that a few days ago I installed GRASS 7 but I > removed it > > and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > > No, GRASS 6 and 7 can happily live together. > > Please let us know if the updated Addon runs ok for you. > > Markus > > > ------------------------------ > > Message: 4 > Date: Thu, 25 Sep 2014 14:11:36 +0200 > From: Luis Miguel Royo P?rez > > To: Markus Neteler > > Cc: GRASS user list > > Subject: Re: [GRASS-user] Problems with r.viewshed > Message-ID: <54240678.7060005 at gmail.com > > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > I'm sorry but it didn't work. > > I have reinstalled the addon but it didn't work, reinstalled GRASS 6.4 > and neither, then installed GRASS7 again, and appears this message: > > r.viewshed -b input=Portada at inisig output=visPort > coordinates=-3.74034324324,42.5352702703 obs_elev=9 tgt_elev=1.75 > max_dist=30000 > Computing events... > Computing visibility... > r.viewshed: statusstructure.cpp:73: float > get_vertical_angle(Viewpoint, StatusNode, surface_type, > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > cumple. > > > I will try in another PC. > > Thank you for your time. > > El 25/09/14 a las #4, Markus Neteler escribi?: > > On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez > > > > wrote: > >> Hi everyone, > >> > >> when I try to run r.viewshed the output shows me this: > > (in GRASS 6 it is an Addon) > > > >> Nodata value set to -nan > >> rows=198, cols=217, total = 42966 > >> In-memory memory usage is 4298336 B (4 MB), max mem > >> allowed=524288000 B(500MB) > >> ***** IN_MEMORY MODE ***** > >> Start sweeping. > >> Computing events ... > >> Sorting events... > >> Terminado. > >> Determine visibility... > >> r.viewshed: statusstructure.cpp:73: float > >> get_vertical_angle(Viewpoint, StatusNode, surface_type, > >> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > >> cumple. > >> > >> Anyone has a clue about what it could be happening? > >> > >> I'm using GRASS 6.4.4 in Xubuntu 14.04. > > I have backported some fixes from GRASS 7 to the addon in GRASS 6. > > Please reinstall the addon with g.extension and try again. > > > >> I think I must say that a few days ago I installed GRASS 7 but > I removed it > >> and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > > No, GRASS 6 and 7 can happily live together. > > > > Please let us know if the updated Addon runs ok for you. > > > > Markus > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > End of grass-user Digest, Vol 101, Issue 39 > ******************************************* > > > > > -- > Pedro Palheiro ------------ pr?xima parte ------------ Se ha borrado un adjunto en formato HTML... URL: From neteler at osgeo.org Fri Sep 26 04:07:36 2014 From: neteler at osgeo.org (Markus Neteler) Date: Fri, 26 Sep 2014 13:07:36 +0200 Subject: [GRASS-user] Problems with r.viewshed In-Reply-To: <542541DF.8030800@gmail.com> References: <542541DF.8030800@gmail.com> Message-ID: On Sep 26, 2014 12:37 PM, "Luis Miguel Royo P?rez" < luis.miguel.royo at gmail.com> wrote: > > Thank you very much. That was the problem. Please suggest how to improve the module help text or manual. Thanks Markus > Sorry for any inconvenience. > > Kind regards. > > > El 26/09/14 a las #4, Pedro Palheiro escribi?: >> >> Hello Luis, >> >> Maybe it is a coordinate reference system problem? It looks like you're using wgs84 for the input and coordinates, and requesting the calculation in meters (obs_elev, tgt_elev and max_dist). Try to change the CRS to see if it works. >> >> r.viewshed -b input=Portada at inisig output=visPort >> coordinates=-3.74034324324,42.5352702703 >> obs_elev=9 tgt_elev=1.75 >> max_dist=30000 >> Computing events... >> Computing visibility... >> r.viewshed: statusstructure.cpp:73: float >> get_vertical_angle(Viewpoint, StatusNode, surface_type, >> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se >> cumple. >> >> Adios, >> Pedro Palheiro >> >> >> 2014-09-25 20:00 GMT+01:00 : >>> >>> Send grass-user mailing list submissions to >>> grass-user at lists.osgeo.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> or, via email, send a message with subject or body 'help' to >>> grass-user-request at lists.osgeo.org >>> >>> You can reach the person managing the list at >>> grass-user-owner at lists.osgeo.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of grass-user digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: removing small lines (Markus Neteler) >>> 2. Problems with r.viewshed (Luis Miguel Royo P?rez) >>> 3. Re: Problems with r.viewshed (Markus Neteler) >>> 4. Re: Problems with r.viewshed (Luis Miguel Royo P?rez) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 25 Sep 2014 10:25:25 +0200 >>> From: Markus Neteler >>> To: Levente Juh?sz >>> Cc: GRASS user list >>> Subject: Re: [GRASS-user] removing small lines >>> Message-ID: >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> On Wed, Sep 24, 2014 at 4:22 PM, Levente Juh?sz wrote: >>> > Hi all, >>> > >>> > I've seen that the remove_small method of v.generalize has been eliminated. >>> > Reduction method does not work in the way I want since it just removes point >>> > from lines and it seems like has no effect on a line of 2 points - even if >>> > they're smaller than the threshold. >>> > Can someone tell me what the workaround is for removing small lines from a >>> > vector for example by a threshold in map units? >>> >>> >>> You may use v.to.db and option=length (line length), then use >>> v.extract to extract into a new map according to a threshold you need. >>> >>> Markus >>> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 25 Sep 2014 10:35:52 +0200 >>> From: Luis Miguel Royo P?rez < >>> ? ? >>> luis.miguel.royo at gmail.com> >>> To: grass-user at lists.osgeo.org >>> Subject: [GRASS-user] Problems with r.viewshed >>> Message-ID: <5423D3E8.5090206 at gmail.com> >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>> >>> Hi everyone, >>> >>> when I try to run r.viewshed the output shows me this: >>> >>> Nodata value set to -nan >>> rows=198, cols=217, total = 42966 >>> In-memory memory usage is 4298336 B (4 MB), max mem >>> allowed=524288000 B(500MB) >>> ***** IN_MEMORY MODE ***** >>> Start sweeping. >>> Computing events ... >>> Sorting events... >>> Terminado. >>> Determine visibility... >>> r.viewshed: statusstructure.cpp:73: float >>> get_vertical_angle(Viewpoint, StatusNode, surface_type, >>> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se >>> cumple. >>> >>> Anyone has a clue about what it could be happening? >>> >>> I'm using GRASS 6.4.4 in Xubuntu 14.04. >>> >>> I think I must say that a few days ago I installed GRASS 7 but I removed >>> it and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? >>> >>> >>> Thanks a lot!!! >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < http://lists.osgeo.org/pipermail/grass-user/attachments/20140925/15c0ab71/attachment-0001.html > >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Thu, 25 Sep 2014 12:46:13 +0200 >>> From: Markus Neteler >>> To: Luis Miguel Royo P?rez >>> Cc: GRASS user list >>> Subject: Re: [GRASS-user] Problems with r.viewshed >>> Message-ID: >>> >>> Content-Type: text/plain; charset=UTF-8 >>> >>> On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez >>> wrote: >>> > Hi everyone, >>> > >>> > when I try to run r.viewshed the output shows me this: >>> >>> (in GRASS 6 it is an Addon) >>> >>> > Nodata value set to -nan >>> > rows=198, cols=217, total = 42966 >>> > In-memory memory usage is 4298336 B (4 MB), max mem >>> > allowed=524288000 B(500MB) >>> > ***** IN_MEMORY MODE ***** >>> > Start sweeping. >>> > Computing events ... >>> > Sorting events... >>> > Terminado. >>> > Determine visibility... >>> > r.viewshed: statusstructure.cpp:73: float >>> > get_vertical_angle(Viewpoint, StatusNode, surface_type, >>> > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se >>> > cumple. >>> > >>> > Anyone has a clue about what it could be happening? >>> > >>> > I'm using GRASS 6.4.4 in Xubuntu 14.04. >>> >>> I have backported some fixes from GRASS 7 to the addon in GRASS 6. >>> Please reinstall the addon with g.extension and try again. >>> >>> > I think I must say that a few days ago I installed GRASS 7 but I removed it >>> > and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? >>> >>> No, GRASS 6 and 7 can happily live together. >>> >>> Please let us know if the updated Addon runs ok for you. >>> >>> Markus >>> >>> >>> ------------------------------ >>> >>> Message: 4 >>> Date: Thu, 25 Sep 2014 14:11:36 +0200 >>> From: Luis Miguel Royo P?rez >>> To: Markus Neteler >>> Cc: GRASS user list >>> Subject: Re: [GRASS-user] Problems with r.viewshed >>> Message-ID: <54240678.7060005 at gmail.com> >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>> >>> I'm sorry but it didn't work. >>> >>> I have reinstalled the addon but it didn't work, reinstalled GRASS 6.4 >>> and neither, then installed GRASS7 again, and appears this message: >>> >>> r.viewshed -b input=Portada at inisig output=visPort >>> coordinates=-3.74034324324,42.5352702703 obs_elev=9 tgt_elev=1.75 >>> max_dist=30000 >>> Computing events... >>> Computing visibility... >>> r.viewshed: statusstructure.cpp:73: float >>> get_vertical_angle(Viewpoint, StatusNode, surface_type, >>> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se >>> cumple. >>> >>> >>> I will try in another PC. >>> >>> Thank you for your time. >>> >>> El 25/09/14 a las #4, Markus Neteler escribi?: >>> > On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez >>> > wrote: >>> >> Hi everyone, >>> >> >>> >> when I try to run r.viewshed the output shows me this: >>> > (in GRASS 6 it is an Addon) >>> > >>> >> Nodata value set to -nan >>> >> rows=198, cols=217, total = 42966 >>> >> In-memory memory usage is 4298336 B (4 MB), max mem >>> >> allowed=524288000 B(500MB) >>> >> ***** IN_MEMORY MODE ***** >>> >> Start sweeping. >>> >> Computing events ... >>> >> Sorting events... >>> >> Terminado. >>> >> Determine visibility... >>> >> r.viewshed: statusstructure.cpp:73: float >>> >> get_vertical_angle(Viewpoint, StatusNode, surface_type, >>> >> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se >>> >> cumple. >>> >> >>> >> Anyone has a clue about what it could be happening? >>> >> >>> >> I'm using GRASS 6.4.4 in Xubuntu 14.04. >>> > I have backported some fixes from GRASS 7 to the addon in GRASS 6. >>> > Please reinstall the addon with g.extension and try again. >>> > >>> >> I think I must say that a few days ago I installed GRASS 7 but I removed it >>> >> and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? >>> > No, GRASS 6 and 7 can happily live together. >>> > >>> > Please let us know if the updated Addon runs ok for you. >>> > >>> > Markus >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < http://lists.osgeo.org/pipermail/grass-user/attachments/20140925/edaf5af2/attachment-0001.html > >>> >>> ------------------------------ >>> >>> _______________________________________________ >>> grass-user mailing list >>> grass-user at lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/grass-user >>> >>> End of grass-user Digest, Vol 101, Issue 39 >>> ******************************************* >> >> >> >> >> -- >> Pedro Palheiro > > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlennert at club.worldonline.be Fri Sep 26 04:36:35 2014 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Fri, 26 Sep 2014 13:36:35 +0200 Subject: [GRASS-user] how to tweak the parameters to speed up i.segment In-Reply-To: References: Message-ID: <54254FC3.8080105@club.worldonline.be> On 26/09/14 11:56, Margherita Di Leo wrote: > Hi, > > I have not clear understanding how the parameters [...] > in i.segment could be tweaked to speed up the running time. > meansize I suppose you mean minsize ? This does not speed up running time. It just adds a last iteration that ignores the threshold parameter and merges segments that are smaller than minsize to their closest (in variable space) neighbor. > iterations, If you set this very low, this can "speed up" the running time, but it will then merge less segments, even though some might still have neighbors at a distance less than threshold. So, I wouldn't use it by default for speeding up the process. I don't think I've actually ever reached the max iterations... > memory, This is probably the parameter you most want to play with. If you have lots of memory on the machine you can seriously increase this and this should normally speed up the process. > In which direction should they be tuned and what are the drawbacks? > Is there some trick? ;-) You can try following the suggestion on the man page and go though some iteration with increasing threshold parameters, using the output of the preceding run as seeds for the next run. More generally, segmentation is a time-consuming process. i.segment is already much faster than the proprietary market leader.... You could possible speed up things if you have several CPUs by cutting up your image in several regions and processing them in parallel. Then you would probably want to patch the results and run i.segment again with this result as seed map. Haven't tried this, yet, though, and so I don't know what effect this will have on segmentation results. You might have to do some r.mapcalc'ing before patching to ensure that all segments have unique ids... Moritz > > Thank you in advance > > -- Best regards, > > Dr. Margherita DI LEO Scientific / technical project officer > > European Commission - DG JRC Institute for Environment and > Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP > 261 Tel. +39 0332 78 3600 margherita.di-leo at 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 at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > From pedro.palheiro at gmail.com Fri Sep 26 05:16:52 2014 From: pedro.palheiro at gmail.com (Pedro Palheiro) Date: Fri, 26 Sep 2014 13:16:52 +0100 Subject: [GRASS-user] Problems with r.viewshed In-Reply-To: References: <542541DF.8030800@gmail.com> Message-ID: Hello Markus, Is there a place/link to include the suggestions to improve the module help or manual? Or should we send them to you directly? Thank you, Regards, Pedro 2014-09-26 12:07 GMT+01:00 Markus Neteler : > > On Sep 26, 2014 12:37 PM, "Luis Miguel Royo P?rez" < > luis.miguel.royo at gmail.com> wrote: > > > > Thank you very much. That was the problem. > > Please suggest how to improve the module help text or manual. > > Thanks > Markus > > > Sorry for any inconvenience. > > > > Kind regards. > > > > > > El 26/09/14 a las #4, Pedro Palheiro escribi?: > >> > >> Hello Luis, > >> > >> Maybe it is a coordinate reference system problem? It looks like you're > using wgs84 for the input and coordinates, and requesting the calculation > in meters (obs_elev, tgt_elev and max_dist). Try to change the CRS to see > if it works. > >> > >> r.viewshed -b input=Portada at inisig output=visPort > >> coordinates=-3.74034324324,42.5352702703 > >> obs_elev=9 tgt_elev=1.75 > >> max_dist=30000 > >> Computing events... > >> Computing visibility... > >> r.viewshed: statusstructure.cpp:73: float > >> get_vertical_angle(Viewpoint, StatusNode, surface_type, > >> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > >> cumple. > >> > >> Adios, > >> Pedro Palheiro > >> > >> > >> 2014-09-25 20:00 GMT+01:00 : > >>> > >>> Send grass-user mailing list submissions to > >>> grass-user at lists.osgeo.org > >>> > >>> To subscribe or unsubscribe via the World Wide Web, visit > >>> http://lists.osgeo.org/mailman/listinfo/grass-user > >>> or, via email, send a message with subject or body 'help' to > >>> grass-user-request at lists.osgeo.org > >>> > >>> You can reach the person managing the list at > >>> grass-user-owner at lists.osgeo.org > >>> > >>> When replying, please edit your Subject line so it is more specific > >>> than "Re: Contents of grass-user digest..." > >>> > >>> > >>> Today's Topics: > >>> > >>> 1. Re: removing small lines (Markus Neteler) > >>> 2. Problems with r.viewshed (Luis Miguel Royo P?rez) > >>> 3. Re: Problems with r.viewshed (Markus Neteler) > >>> 4. Re: Problems with r.viewshed (Luis Miguel Royo P?rez) > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 1 > >>> Date: Thu, 25 Sep 2014 10:25:25 +0200 > >>> From: Markus Neteler > >>> To: Levente Juh?sz > >>> Cc: GRASS user list > >>> Subject: Re: [GRASS-user] removing small lines > >>> Message-ID: > >>> me+C_8o6+Y9CTA1P-cofD3NemuyE30uBmvF5Q at mail.gmail.com> > >>> Content-Type: text/plain; charset=UTF-8 > >>> > >>> On Wed, Sep 24, 2014 at 4:22 PM, Levente Juh?sz > wrote: > >>> > Hi all, > >>> > > >>> > I've seen that the remove_small method of v.generalize has been > eliminated. > >>> > Reduction method does not work in the way I want since it just > removes point > >>> > from lines and it seems like has no effect on a line of 2 points - > even if > >>> > they're smaller than the threshold. > >>> > Can someone tell me what the workaround is for removing small lines > from a > >>> > vector for example by a threshold in map units? > >>> > >>> > >>> You may use v.to.db and option=length (line length), then use > >>> v.extract to extract into a new map according to a threshold you need. > >>> > >>> Markus > >>> > >>> > >>> ------------------------------ > >>> > >>> Message: 2 > >>> Date: Thu, 25 Sep 2014 10:35:52 +0200 > >>> From: Luis Miguel Royo P?rez < > >>> ? ? > >>> luis.miguel.royo at gmail.com> > >>> To: grass-user at lists.osgeo.org > >>> Subject: [GRASS-user] Problems with r.viewshed > >>> Message-ID: <5423D3E8.5090206 at gmail.com> > >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" > >>> > >>> Hi everyone, > >>> > >>> when I try to run r.viewshed the output shows me this: > >>> > >>> Nodata value set to -nan > >>> rows=198, cols=217, total = 42966 > >>> In-memory memory usage is 4298336 B (4 MB), max mem > >>> allowed=524288000 B(500MB) > >>> ***** IN_MEMORY MODE ***** > >>> Start sweeping. > >>> Computing events ... > >>> Sorting events... > >>> Terminado. > >>> Determine visibility... > >>> r.viewshed: statusstructure.cpp:73: float > >>> get_vertical_angle(Viewpoint, StatusNode, surface_type, > >>> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > >>> cumple. > >>> > >>> Anyone has a clue about what it could be happening? > >>> > >>> I'm using GRASS 6.4.4 in Xubuntu 14.04. > >>> > >>> I think I must say that a few days ago I installed GRASS 7 but I > removed > >>> it and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > >>> > >>> > >>> Thanks a lot!!! > >>> -------------- next part -------------- > >>> An HTML attachment was scrubbed... > >>> URL: < > http://lists.osgeo.org/pipermail/grass-user/attachments/20140925/15c0ab71/attachment-0001.html > > > >>> > >>> ------------------------------ > >>> > >>> Message: 3 > >>> Date: Thu, 25 Sep 2014 12:46:13 +0200 > >>> From: Markus Neteler > >>> To: Luis Miguel Royo P?rez > >>> Cc: GRASS user list > >>> Subject: Re: [GRASS-user] Problems with r.viewshed > >>> Message-ID: > >>> sVaXsFFEOaTALg at mail.gmail.com> > >>> Content-Type: text/plain; charset=UTF-8 > >>> > >>> On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez > >>> wrote: > >>> > Hi everyone, > >>> > > >>> > when I try to run r.viewshed the output shows me this: > >>> > >>> (in GRASS 6 it is an Addon) > >>> > >>> > Nodata value set to -nan > >>> > rows=198, cols=217, total = 42966 > >>> > In-memory memory usage is 4298336 B (4 MB), max mem > >>> > allowed=524288000 B(500MB) > >>> > ***** IN_MEMORY MODE ***** > >>> > Start sweeping. > >>> > Computing events ... > >>> > Sorting events... > >>> > Terminado. > >>> > Determine visibility... > >>> > r.viewshed: statusstructure.cpp:73: float > >>> > get_vertical_angle(Viewpoint, StatusNode, surface_type, > >>> > int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > >>> > cumple. > >>> > > >>> > Anyone has a clue about what it could be happening? > >>> > > >>> > I'm using GRASS 6.4.4 in Xubuntu 14.04. > >>> > >>> I have backported some fixes from GRASS 7 to the addon in GRASS 6. > >>> Please reinstall the addon with g.extension and try again. > >>> > >>> > I think I must say that a few days ago I installed GRASS 7 but I > removed it > >>> > and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > >>> > >>> No, GRASS 6 and 7 can happily live together. > >>> > >>> Please let us know if the updated Addon runs ok for you. > >>> > >>> Markus > >>> > >>> > >>> ------------------------------ > >>> > >>> Message: 4 > >>> Date: Thu, 25 Sep 2014 14:11:36 +0200 > >>> From: Luis Miguel Royo P?rez > >>> To: Markus Neteler > >>> Cc: GRASS user list > >>> Subject: Re: [GRASS-user] Problems with r.viewshed > >>> Message-ID: <54240678.7060005 at gmail.com> > >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" > >>> > >>> I'm sorry but it didn't work. > >>> > >>> I have reinstalled the addon but it didn't work, reinstalled GRASS 6.4 > >>> and neither, then installed GRASS7 again, and appears this message: > >>> > >>> r.viewshed -b input=Portada at inisig output=visPort > >>> coordinates=-3.74034324324,42.5352702703 obs_elev=9 tgt_elev=1.75 > >>> max_dist=30000 > >>> Computing events... > >>> Computing visibility... > >>> r.viewshed: statusstructure.cpp:73: float > >>> get_vertical_angle(Viewpoint, StatusNode, surface_type, > >>> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > >>> cumple. > >>> > >>> > >>> I will try in another PC. > >>> > >>> Thank you for your time. > >>> > >>> El 25/09/14 a las #4, Markus Neteler escribi?: > >>> > On Thu, Sep 25, 2014 at 10:35 AM, Luis Miguel Royo P?rez > >>> > wrote: > >>> >> Hi everyone, > >>> >> > >>> >> when I try to run r.viewshed the output shows me this: > >>> > (in GRASS 6 it is an Addon) > >>> > > >>> >> Nodata value set to -nan > >>> >> rows=198, cols=217, total = 42966 > >>> >> In-memory memory usage is 4298336 B (4 MB), max mem > >>> >> allowed=524288000 B(500MB) > >>> >> ***** IN_MEMORY MODE ***** > >>> >> Start sweeping. > >>> >> Computing events ... > >>> >> Sorting events... > >>> >> Terminado. > >>> >> Determine visibility... > >>> >> r.viewshed: statusstructure.cpp:73: float > >>> >> get_vertical_angle(Viewpoint, StatusNode, surface_type, > >>> >> int): La declaraci?n `fabs(sn.dist2vp) > 0.001' no se > >>> >> cumple. > >>> >> > >>> >> Anyone has a clue about what it could be happening? > >>> >> > >>> >> I'm using GRASS 6.4.4 in Xubuntu 14.04. > >>> > I have backported some fixes from GRASS 7 to the addon in GRASS 6. > >>> > Please reinstall the addon with g.extension and try again. > >>> > > >>> >> I think I must say that a few days ago I installed GRASS 7 but I > removed it > >>> >> and reinstalled GRASS 6.4.4. Maybe is there any incompatibility? > >>> > No, GRASS 6 and 7 can happily live together. > >>> > > >>> > Please let us know if the updated Addon runs ok for you. > >>> > > >>> > Markus > >>> > >>> -------------- next part -------------- > >>> An HTML attachment was scrubbed... > >>> URL: < > http://lists.osgeo.org/pipermail/grass-user/attachments/20140925/edaf5af2/attachment-0001.html > > > >>> > >>> ------------------------------ > >>> > >>> _______________________________________________ > >>> grass-user mailing list > >>> grass-user at lists.osgeo.org > >>> http://lists.osgeo.org/mailman/listinfo/grass-user > >>> > >>> End of grass-user Digest, Vol 101, Issue 39 > >>> ******************************************* > >> > >> > >> > >> > >> -- > >> Pedro Palheiro > > > > > > > > _______________________________________________ > > grass-user mailing list > > grass-user at lists.osgeo.org > > http://lists.osgeo.org/mailman/listinfo/grass-user > -- Pedro Palheiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From diregola at gmail.com Fri Sep 26 05:19:37 2014 From: diregola at gmail.com (Margherita Di Leo) Date: Fri, 26 Sep 2014 14:19:37 +0200 Subject: [GRASS-user] how to tweak the parameters to speed up i.segment In-Reply-To: <54254FC3.8080105@club.worldonline.be> References: <54254FC3.8080105@club.worldonline.be> Message-ID: Moritz, On Fri, Sep 26, 2014 at 1:36 PM, Moritz Lennert < mlennert at club.worldonline.be> wrote: > On 26/09/14 11:56, Margherita Di Leo wrote: > >> >> > > meansize >> > > I suppose you mean minsize ? > Oops.. yep > > [...] > > > > You could possible speed up things if you have several CPUs by cutting up > your image in several regions and processing them in parallel. Then you > would probably want to patch the results and run i.segment again with this > result as seed map. Haven't tried this, yet, though, and so I don't know > what effect this will have on segmentation results. You might have to do > some r.mapcalc'ing before patching to ensure that all segments have unique > ids... > >> >> Thank you very much for your precious hints. I'll go this direction. cheers, madi -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-leo at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.zamb at gmail.com Fri Sep 26 05:49:23 2014 From: peter.zamb at gmail.com (Pietro) Date: Fri, 26 Sep 2014 14:49:23 +0200 Subject: [GRASS-user] how to tweak the parameters to speed up i.segment In-Reply-To: <54254FC3.8080105@club.worldonline.be> References: <54254FC3.8080105@club.worldonline.be> Message-ID: Hi, at the moment I guess the only way to speed up it is exactly what suggested by Moritz: On Fri, Sep 26, 2014 at 1:36 PM, Moritz Lennert wrote: > You could possible speed up things if you have several CPUs by cutting up > your image in several regions and processing them in parallel. Then you > would probably want to patch the results and run i.segment again with this > result as seed map. Haven't tried this, yet, though, and so I don't know > what effect this will have on segmentation results. Following this approach I've implement: i.segment.hierarchical (grass-addons). I've used this module to segment an image (RGB) of 24 x 48 kpixels on my laptop in less than 12 hours (if I remeber correctly). Still I think we can reach greater improvement working at C level but I didn't have time to work on it I have just some ideas, no code. All the best Pietro From neteler at osgeo.org Fri Sep 26 06:14:30 2014 From: neteler at osgeo.org (Markus Neteler) Date: Fri, 26 Sep 2014 15:14:30 +0200 Subject: [GRASS-user] Problems with r.viewshed In-Reply-To: References: <542541DF.8030800@gmail.com> Message-ID: Hello Pedro, On Fri, Sep 26, 2014 at 2:16 PM, Pedro Palheiro wrote: > Hello Markus, > > Is there a place/link to include the suggestions to improve the module help > or manual? That would be http://trac.osgeo.org/grass > Or should we send them to you directly? that's also fine. best Markus From diregola at gmail.com Fri Sep 26 06:18:04 2014 From: diregola at gmail.com (Margherita Di Leo) Date: Fri, 26 Sep 2014 15:18:04 +0200 Subject: [GRASS-user] how to tweak the parameters to speed up i.segment In-Reply-To: References: <54254FC3.8080105@club.worldonline.be> Message-ID: Ciao Pietro! On Fri, Sep 26, 2014 at 2:49 PM, Pietro wrote: > > > Following this approach I've implement: i.segment.hierarchical > (grass-addons). I've used this module to segment an image (RGB) of 24 > x 48 kpixels on my laptop in less than 12 hours (if I remeber > correctly). Still I think we can reach greater improvement working at > C level but I didn't have time to work on it I have just some ideas, > no code. > > > kudos! :-D I have some troubles installing it though: > g.extension i.segment.hierarchical Fetching from GRASS-Addons SVN repository (be patient)... Compiling... Makefile:17: warning: overriding commands for target `/tmp/tmpc7e9Oc/i.segment.hierarchical/etc/i.segment.hierarchical/i.segment.hierarchical' /space/gis/grass_trunk/grass-7.1.svn/include/Make/ScriptRules.make:19: warning: ignoring old commands for target `/tmp/tmpc7e9Oc/i.segment.hierarchical/etc/i.segment.hierarchical/i.segment.hierarchical' Traceback (most recent call last): File "/tmp/tmpc7e9Oc/i.segment.hierarchical/scripts/i.segment.hierarchical", line 158, in from isegpatch import rpatch_map ImportError: No module named isegpatch make: *** [i.segment.hierarchical.tmp.html] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. ? Thanks! madi -- Best regards, Dr. Margherita DI LEO Scientific / technical project officer European Commission - DG JRC Institute for Environment and Sustainability (IES) Via Fermi, 2749 I-21027 Ispra (VA) - Italy - TP 261 Tel. +39 0332 78 3600 margherita.di-leo at 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.zamb at gmail.com Fri Sep 26 06:32:27 2014 From: peter.zamb at gmail.com (Pietro) Date: Fri, 26 Sep 2014 15:32:27 +0200 Subject: [GRASS-user] how to tweak the parameters to speed up i.segment In-Reply-To: References: <54254FC3.8080105@club.worldonline.be> Message-ID: On Fri, Sep 26, 2014 at 3:18 PM, Margherita Di Leo wrote: > I have some troubles installing it though: > >> g.extension i.segment.hierarchical > Fetching from GRASS-Addons SVN repository (be > patient)... > Compiling... > Makefile:17: warning: overriding commands for target > `/tmp/tmpc7e9Oc/i.segment.hierarchical/etc/i.segment.hierarchical/i.segment.hierarchical' > /space/gis/grass_trunk/grass-7.1.svn/include/Make/ScriptRules.make:19: > warning: ignoring old commands for target > `/tmp/tmpc7e9Oc/i.segment.hierarchical/etc/i.segment.hierarchical/i.segment.hierarchical' > Traceback (most recent call last): > File > "/tmp/tmpc7e9Oc/i.segment.hierarchical/scripts/i.segment.hierarchical", line > 158, in > from isegpatch import rpatch_map > ImportError: No module named isegpatch > make: *** [i.segment.hierarchical.tmp.html] Error 1 > ERROR: Compilation failed, sorry. Please check above error messages. It Is not coping the file isegpatch in the right directory, please try to copy the directory in grass71/script and run make, in this way it is working without problems on my computer. I guess that g.external doesn't like python module libraries or the makefile is not written correctly to work with g.external. Let me know. Pietro From johannesradinger at gmail.com Fri Sep 26 08:05:27 2014 From: johannesradinger at gmail.com (Johannes Radinger) Date: Fri, 26 Sep 2014 17:05:27 +0200 Subject: [GRASS-user] raster exchange between GRASS and R with nodata In-Reply-To: References: Message-ID: I think I discovered the problem. This was a mistake on my side: The summary() function in R applied on a raster does subsample the data in case of very large raster maps. However, this seems to cause that summary information about NA gets lost and no NA are mentioned in the summary output although there are NA included in the raster map. Here an example output of a map with lots of NA's which are ignored by summary(rastermap): > summary(streams[[1]]) Elbe_distance_from_mouth Min. 0.0000 1st Qu. 488.7067 Median 789.8560 3rd Qu. 1025.4501 Max. 1876.6429 NA's 0.0000 Warning message: In .local(object, ...) : summary is an estimate based on a sample of 1e+05 cells (10.7% of all cells) > length(bioclim[[1]][is.na(bioclim[[1]])]) [1] 12688 So there was actually no problem, just some confusion concerning the information about NA in the summary. Best regards, Johannes On Thu, Sep 4, 2014 at 6:26 PM, Robert J. Hijmans wrote: > Johannes, > > raster uses GDAL to access GTiff data. So it seems that there is no, > or at least GDAL does not see, a no data value in the file. > I would suggest running GDALinfo to troubleshoot. Can you email me a > small example file? > > By the way, the spgrass6 route has a shortcoming: it may not work with > very large files as it attempts to load all values into RAM. > > Robert > > On Thu, Sep 4, 2014 at 6:47 AM, Johannes Radinger > wrote: > > > > > > > > On Thu, Sep 4, 2014 at 3:38 PM, Nuno S? wrote: > >> > >> Hello! > >> > >> Did you try this one? > >> > >> r.out.gdal etc nodata='NA' > > > > > > As mentioned in the manual of r.out.gdal, the no data parameter takes > only > > float values > > and no strings like 'NA'. Without stating as specific value in GRASS, > this > > nodata-value is > > automatically set to e.g. 65535 for DCELL rasters if I remember correctly > > and to 255 > > for BYTE rasters. However, this seems not to be recognized when imported > > into R with > > the package 'raster'. > > > > /Johannes > > > >> > >> > >> > >> > >> On 4 September 2014 14:27, Johannes Radinger < > johannesradinger at gmail.com> > >> wrote: > >>> > >>> Hi all, > >>> > >>> of course it is possible to load the raster maps directly via spgrass6. > >>> However, we use this work > >>> flow also to exchange some of the maps between different users (e.g. > via > >>> email) and to permanently > >>> store single files (geotiffs that contain the proj information within > the > >>> file). So, I agree that using spgrass6 would be much more efficient, > but > >>> I'll stick to exporting to geotiffs and so I need to solve the issues > with > >>> NA's. > >>> > >>> /Johannes > >>> > >>> > >>> On Thu, Sep 4, 2014 at 2:31 PM, Thomas Adams wrote: > >>>> > >>>> Johannes, > >>>> > >>>> If you want to read your file into R, there is no need to export your > >>>> map from GRASS to do this. Simply install and use the R contributed > package > >>>> 'spgrass6' (spgrass6 has R dependencies that need to be installed > first); it > >>>> works wonderfully: > >>>> > >>>> Within GRASS, at the GRASS terminal prompt... > >>>> > >>>> > library(spgrass6) > >>>> Loading required package: sp > >>>> Loading required package: XML > >>>> GRASS GIS interface loaded with GRASS version: GRASS 7.0.0beta3 (2014) > >>>> and location: ohrfc_mpe > >>>> > dat<-readRAST6("xmrg0101200306z") > >>>> > image(dat) > >>>> > >>>> This is far more efficient. > >>>> > >>>> Tom > >>>> > >>>> > >>>> On Thu, Sep 4, 2014 at 5:32 AM, Johannes Radinger > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> I want to export a raster map (FCELL) from GRASS70 to the geotiff > >>>>> format using r.out.gdal and to import it later on in R. The map > contains > >>>>> many no data values. > >>>>> > >>>>> Here some details about the raster: > >>>>> Type of Map: raster Number of Categories: 0 > >>>>> Data Type: FCELL > >>>>> Rows: 750 > >>>>> Columns: 750 > >>>>> Total Cells: 562500 > >>>>> total null and non-null cells: 15105636 > >>>>> total null cells: 15105047 > >>>>> > >>>>> So when I export the map, r.out.gdal reports: "Input raster map > >>>>> contains cells with NULL-value (no-data). The value -nan will be > used to > >>>>> represent no-data values in the input map. You can specify a nodata > value > >>>>> with the nodata option." > >>>>> > >>>>> When I subsequently try to import the geotiff into R (using the > package > >>>>> 'Raster') the nodata values are not recognised as NA's: > >>>>> > >>>>> a <- raster("*.tif") > >>>>> summary(a) > >>>>> Min. 0.5294496 > >>>>> 1st Qu. 0.7171210 > >>>>> Median 0.7871540 > >>>>> 3rd Qu. 1.1581826 > >>>>> Max. 1.5494517 > >>>>> NA's 0.0000000 > >>>>> > >>>>> So I am wondering if I need to set any specific parameter during the > >>>>> export (r.out.gdal) or import (raster()). > >>>>> > >>>>> As I am not only exporting FCELL (Float32) raster but also multiple > >>>>> (N=500) other rasters to R I would be interested in a solution also > for > >>>>> DCELL (Float64). Of course I can export all of as Float64 as the > file size > >>>>> should not be a problem. > >>>>> > >>>>> Any suggestions or experiences of handling NA's during raster > exchange > >>>>> between GRASS and R? > >>>>> > >>>>> /Johannes > >>>>> > >>>>> _______________________________________________ > >>>>> grass-user mailing list > >>>>> grass-user at lists.osgeo.org > >>>>> http://lists.osgeo.org/mailman/listinfo/grass-user > >>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> _______________________________________________ > >>> grass-user mailing list > >>> grass-user at lists.osgeo.org > >>> http://lists.osgeo.org/mailman/listinfo/grass-user > >> > >> > >> > >> > >> -- > >> > >> Nuno C?sar de S? > >> +351 91 961 90 37 > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aorr at anl.gov Fri Sep 26 07:46:06 2014 From: aorr at anl.gov (Orr, Andrew B.) Date: Fri, 26 Sep 2014 14:46:06 +0000 Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 Message-ID: Hello all, I've been working on a r.cost and r.drain python script that is using very large rasters. I've been running into some memory issues with this script due to the size of the rasters. I read about setting the amount of memory that the map can be stored in with the "percent_memory=xx" argument for r.cost, however the performance of running the script is becoming a problem (it takes too long to run for our goal). I then started watching the Task Manager and noticed it was peaked out at less ~4 gigs of ram and I realized it's only a 32 bit version of Python installed with GRASS. My question is: is there a compatible 64 bit version of Python for GRASS 6.4.x, and if so, how does one install it? Thanks for your help! -Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From aorr at anl.gov Fri Sep 26 08:30:41 2014 From: aorr at anl.gov (Orr, Andrew B.) Date: Fri, 26 Sep 2014 15:30:41 +0000 Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 In-Reply-To: <109f01cfd99d$b2f7a260$18e6e720$@lutraconsulting.co.uk> References: <109f01cfd99d$b2f7a260$18e6e720$@lutraconsulting.co.uk> Message-ID: Thanks Saber, I already have GRASS installed, and if I recall the application you linked me to is an interface for installing GRASS? What I'm hoping for is upgrading the version of Python to 64 bit that GRASS is using. When I open GRASS and go to the Python shell it says it's using a 32 bit version of Python 2.7.2. I know it's a separate installation for ArcGIS to get a 64 bit version of Python installed so I was thinking that GRASS may be the same procedure? Thanks, -Andy From: Saber Razmjooei [mailto:saber.razmjooei at lutraconsulting.co.uk] Sent: Friday, September 26, 2014 10:23 AM To: Orr, Andrew B.; grass-user at lists.osgeo.org Subject: RE: [GRASS-user] 64 bit Python in GRASS 6.4.2 Hi Andy, You can try this: http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86_64.exe Cheers, Saber From: grass-user-bounces at lists.osgeo.org [mailto:grass-user-bounces at lists.osgeo.org] On Behalf Of Orr, Andrew B. Sent: 26 September 2014 15:46 To: 'grass-user at lists.osgeo.org' Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 Hello all, I've been working on a r.cost and r.drain python script that is using very large rasters. I've been running into some memory issues with this script due to the size of the rasters. I read about setting the amount of memory that the map can be stored in with the "percent_memory=xx" argument for r.cost, however the performance of running the script is becoming a problem (it takes too long to run for our goal). I then started watching the Task Manager and noticed it was peaked out at less ~4 gigs of ram and I realized it's only a 32 bit version of Python installed with GRASS. My question is: is there a compatible 64 bit version of Python for GRASS 6.4.x, and if so, how does one install it? Thanks for your help! -Andy ________________________________ This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viru ses is taken and it is your responsibility to carry out such checks as you feel appropriate. If this email contains a quote or offer to sell products, carry out work or perform services then our standard terms and conditions shall apply unless explicitly stated otherwise. Saber Razmjooei and Peter Wells trading as Lutra Consulting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saber.razmjooei at lutraconsulting.co.uk Fri Sep 26 08:22:34 2014 From: saber.razmjooei at lutraconsulting.co.uk (Saber Razmjooei) Date: Fri, 26 Sep 2014 16:22:34 +0100 Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 In-Reply-To: References: Message-ID: <109f01cfd99d$b2f7a260$18e6e720$@lutraconsulting.co.uk> Hi Andy, You can try this: http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86_64.exe Cheers, Saber From: grass-user-bounces at lists.osgeo.org [mailto:grass-user-bounces at lists.osgeo.org] On Behalf Of Orr, Andrew B. Sent: 26 September 2014 15:46 To: 'grass-user at lists.osgeo.org' Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 Hello all, I've been working on a r.cost and r.drain python script that is using very large rasters. I've been running into some memory issues with this script due to the size of the rasters. I read about setting the amount of memory that the map can be stored in with the "percent_memory=xx" argument for r.cost, however the performance of running the script is becoming a problem (it takes too long to run for our goal). I then started watching the Task Manager and noticed it was peaked out at less ~4 gigs of ram and I realized it's only a 32 bit version of Python installed with GRASS. My question is: is there a compatible 64 bit version of Python for GRASS 6.4.x, and if so, how does one install it? Thanks for your help! -Andy -- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viruses is taken and it is your responsibility to carry out such checks as you feel appropriate. If this email contains a quote or offer to sell products, carry out work or perform services then our standard terms and conditions (which can be found at http://www.lutraconsulting.co.uk/downloads/Lutra%20Consulting%20Standard%20Terms%20and%20Conditions.pdf shall apply unless explicitly stated otherwise. Saber Razmjooei and Peter Wells trading as Lutra Consulting. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tech_dev at wildintellect.com Fri Sep 26 09:37:05 2014 From: tech_dev at wildintellect.com (Alex Mandel) Date: Fri, 26 Sep 2014 09:37:05 -0700 Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 In-Reply-To: References: <109f01cfd99d$b2f7a260$18e6e720$@lutraconsulting.co.uk> Message-ID: <54259631.20901@wildintellect.com> The suggestion is that your reinstall GRASS using the OSGeo4w64 installer. You likely used the OSGeo4w previously, which is a 32 bit bundle of open source geo software. You can't just swap out the python you have to get everything compiled for 64bit. Thanks, Alex On 09/26/2014 08:30 AM, Orr, Andrew B. wrote: > Thanks Saber, > I already have GRASS installed, and if I recall the application you linked me to is an interface for installing GRASS? What I'm hoping for is upgrading the version of Python to 64 bit that GRASS is using. > > When I open GRASS and go to the Python shell it says it's using a 32 bit version of Python 2.7.2. > I know it's a separate installation for ArcGIS to get a 64 bit version of Python installed so I was thinking that GRASS may be the same procedure? > Thanks, > -Andy > > > > From: Saber Razmjooei [mailto:saber.razmjooei at lutraconsulting.co.uk] > Sent: Friday, September 26, 2014 10:23 AM > To: Orr, Andrew B.; grass-user at lists.osgeo.org > Subject: RE: [GRASS-user] 64 bit Python in GRASS 6.4.2 > > Hi Andy, > > You can try this: > http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86_64.exe > > Cheers, > Saber > > > From: grass-user-bounces at lists.osgeo.org [mailto:grass-user-bounces at lists.osgeo.org] On Behalf Of Orr, Andrew B. > Sent: 26 September 2014 15:46 > To: 'grass-user at lists.osgeo.org' > Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 > > Hello all, > I've been working on a r.cost and r.drain python script that is using very large rasters. I've been running into some memory issues with this script due to the size of the rasters. I read about setting the amount of memory that the map can be stored in with the "percent_memory=xx" argument for r.cost, however the performance of running the script is becoming a problem (it takes too long to run for our goal). > > I then started watching the Task Manager and noticed it was peaked out at less ~4 gigs of ram and I realized it's only a 32 bit version of Python installed with GRASS. > My question is: is there a compatible 64 bit version of Python for GRASS 6.4.x, and if so, how does one install it? > > Thanks for your help! > -Andy > > ________________________________ > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > > Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viru ses is taken and it is your responsibility to carry out such checks as you feel appropriate. > > If this email contains a quote or offer to sell products, carry out work or perform services then our standard terms and conditions shall apply unless explicitly stated otherwise. > > Saber Razmjooei and Peter Wells trading as Lutra Consulting. > > > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > From wenzeslaus at gmail.com Fri Sep 26 10:26:18 2014 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Fri, 26 Sep 2014 13:26:18 -0400 Subject: [GRASS-user] how to tweak the parameters to speed up i.segment In-Reply-To: <54254FC3.8080105@club.worldonline.be> References: <54254FC3.8080105@club.worldonline.be> Message-ID: On Fri, Sep 26, 2014 at 7:36 AM, Moritz Lennert < mlennert at club.worldonline.be> wrote: > More generally, segmentation is a time-consuming process. i.segment is > already much faster than the proprietary market leader.... Oh, this is interesting. I'm not sure if you already did something like it but if not, can you please try to do some benchmarks and post them somewhere? It think it would be really good to actually see the numbers. -------------- next part -------------- An HTML attachment was scrubbed... URL: From aorr at anl.gov Fri Sep 26 11:42:03 2014 From: aorr at anl.gov (Orr, Andrew B.) Date: Fri, 26 Sep 2014 18:42:03 +0000 Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 In-Reply-To: <54259631.20901@wildintellect.com> References: <109f01cfd99d$b2f7a260$18e6e720$@lutraconsulting.co.uk> <54259631.20901@wildintellect.com> Message-ID: Thank you everyone that helped with this. I was able to get the 64 bit version of Python and GRASS to play nicely together. For the recods, it took uninstalling GRASS and OSGeo4W from my machine and then reinstalling it with the link Saber provided @ http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86_64.exe -Andy -----Original Message----- From: Alex Mandel [mailto:tech_dev at wildintellect.com] Sent: Friday, September 26, 2014 11:37 AM To: Orr, Andrew B.; grass-user at lists.osgeo.org Subject: Re: [GRASS-user] 64 bit Python in GRASS 6.4.2 The suggestion is that your reinstall GRASS using the OSGeo4w64 installer. You likely used the OSGeo4w previously, which is a 32 bit bundle of open source geo software. You can't just swap out the python you have to get everything compiled for 64bit. Thanks, Alex On 09/26/2014 08:30 AM, Orr, Andrew B. wrote: > Thanks Saber, > I already have GRASS installed, and if I recall the application you linked me to is an interface for installing GRASS? What I'm hoping for is upgrading the version of Python to 64 bit that GRASS is using. > > When I open GRASS and go to the Python shell it says it's using a 32 bit version of Python 2.7.2. > I know it's a separate installation for ArcGIS to get a 64 bit version of Python installed so I was thinking that GRASS may be the same procedure? > Thanks, > -Andy > > > > From: Saber Razmjooei [mailto:saber.razmjooei at lutraconsulting.co.uk] > Sent: Friday, September 26, 2014 10:23 AM > To: Orr, Andrew B.; grass-user at lists.osgeo.org > Subject: RE: [GRASS-user] 64 bit Python in GRASS 6.4.2 > > Hi Andy, > > You can try this: > http://download.osgeo.org/osgeo4w/osgeo4w-setup-x86_64.exe > > Cheers, > Saber > > > From: grass-user-bounces at lists.osgeo.org [mailto:grass-user-bounces at lists.osgeo.org] On Behalf Of Orr, Andrew B. > Sent: 26 September 2014 15:46 > To: 'grass-user at lists.osgeo.org' > Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 > > Hello all, > I've been working on a r.cost and r.drain python script that is using very large rasters. I've been running into some memory issues with this script due to the size of the rasters. I read about setting the amount of memory that the map can be stored in with the "percent_memory=xx" argument for r.cost, however the performance of running the script is becoming a problem (it takes too long to run for our goal). > > I then started watching the Task Manager and noticed it was peaked out at less ~4 gigs of ram and I realized it's only a 32 bit version of Python installed with GRASS. > My question is: is there a compatible 64 bit version of Python for GRASS 6.4.x, and if so, how does one install it? > > Thanks for your help! > -Andy > > ________________________________ > > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. > > Whilst reasonable care has been taken to avoid virus transmission, no responsibility for viru ses is taken and it is your responsibility to carry out such checks as you feel appropriate. > > If this email contains a quote or offer to sell products, carry out work or perform services then our standard terms and conditions shall apply unless explicitly stated otherwise. > > Saber Razmjooei and Peter Wells trading as Lutra Consulting. > > > > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > From markus.metz.giswork at gmail.com Fri Sep 26 12:06:24 2014 From: markus.metz.giswork at gmail.com (Markus Metz) Date: Fri, 26 Sep 2014 21:06:24 +0200 Subject: [GRASS-user] how to tweak the parameters to speed up i.segment In-Reply-To: <54254FC3.8080105@club.worldonline.be> References: <54254FC3.8080105@club.worldonline.be> Message-ID: On Fri, Sep 26, 2014 at 1:36 PM, Moritz Lennert wrote: > On 26/09/14 11:56, Margherita Di Leo wrote: >> >> Hi, >> >> I have not clear understanding how the parameters > > [...] >> >> in i.segment could be tweaked to speed up the running time. > >> memory, > > This is probably the parameter you most want to play with. If you have > lots of memory on the machine you can seriously increase this and this > should normally speed up the process. threshold is probably even more important than memory, because a larger threshold value means longer running time. If you are not sure which threshold value gives you the desired results (depends on your data and your objective), you should start with a low value, e.g. 0.01, and then perform hierarchical segmentation by using the output of the last run as seeds for the next run. Suggested steps are 0.01, 0.05, 0.1, 0.2. You could also test one or several small regions within your study area before performing the real segmentation on the full study area. > > More generally, segmentation is a time-consuming process. i.segment is > already much faster than the proprietary market leader.... To be fair, this market leader offers some time consuming features that are not implemented in i.segment. Markus M From glynn at gclements.plus.com Fri Sep 26 19:12:01 2014 From: glynn at gclements.plus.com (Glynn Clements) Date: Sat, 27 Sep 2014 03:12:01 +0100 Subject: [GRASS-user] 64 bit Python in GRASS 6.4.2 In-Reply-To: <54259631.20901@wildintellect.com> References: <109f01cfd99d$b2f7a260$18e6e720$@lutraconsulting.co.uk> <54259631.20901@wildintellect.com> Message-ID: <21542.7409.506604.911370@cerise.gclements.plus.com> Alex Mandel wrote: > The suggestion is that your reinstall GRASS using the OSGeo4w64 > installer. You likely used the OSGeo4w previously, which is a 32 bit > bundle of open source geo software. You can't just swap out the python > you have to get everything compiled for 64bit. FWIW, the grass.script library doesn't require that GRASS uses the same architecture (32-bit or 64-bit) as the Python interpreter. The grass.lib library (and grass.pygrass and grass.temporal, which use it) accesses the GRASS dynamic libraries from the Python interpreter, so the Python interpreter has to match the architecture for which GRASS was built. -- Glynn Clements From daniel.teske at web.de Sat Sep 27 05:28:40 2014 From: daniel.teske at web.de (teeschke) Date: Sat, 27 Sep 2014 05:28:40 -0700 (PDT) Subject: [GRASS-user] extract wind steams from raster Message-ID: <1411820920459-5164542.post@n6.nabble.com> Hi list, I am totally excitedabout the vector visualizations of Wind Map* and Earth Wind**. So I'm now trying to extract this kind of vector from meteorological grib files, which has set the wind parameters angle and speed per cell. I tried to work with r.to.vect, but this seems to be not the best starting point, because the stream vectors must be calculated before. Right? Could you please give me any hints to extract some kind of wind stream vectors? Thank you very much and best regards, teeschke *http://hint.fm/wind/ ** http://earth.nullschool.net/ -- View this message in context: http://osgeo-org.1560.x6.nabble.com/extract-wind-steams-from-raster-tp5164542.html Sent from the Grass - Users mailing list archive at Nabble.com. From wenzeslaus at gmail.com Sat Sep 27 10:00:06 2014 From: wenzeslaus at gmail.com (Vaclav Petras) Date: Sat, 27 Sep 2014 13:00:06 -0400 Subject: [GRASS-user] extract wind steams from raster In-Reply-To: <1411820920459-5164542.post@n6.nabble.com> References: <1411820920459-5164542.post@n6.nabble.com> Message-ID: On Sat, Sep 27, 2014 at 8:28 AM, teeschke wrote: > Hi list, > > I am totally excitedabout the vector visualizations of Wind Map* and Earth > Wind**. So I'm now trying to extract this kind of vector from > meteorological > grib files, which has set the wind parameters angle and speed per cell. > > Hi, I was also excited. > I tried to work with r.to.vect, but this seems to be not the best starting > point, because the stream vectors must be calculated before. Right? Could > you please give me any hints to extract some kind of wind stream vectors? > > So, I have created: https://github.com/ncsu-osgeorel/comet-like-visualization the result can be seen here: http://geospatial.ncsu.edu/osgeorel/foss4g-2014-spatio-temporal-visualization.html Let me know what do you think. There is not much documentation but it should be pretty clear, although it is quite sensitive to sizes, so you must be careful in setting region right. Vaclav Thank you very much and best regards, > teeschke > > *http://hint.fm/wind/ > ** http://earth.nullschool.net/ > > > > -- > View this message in context: > http://osgeo-org.1560.x6.nabble.com/extract-wind-steams-from-raster-tp5164542.html > Sent from the Grass - Users mailing list archive at Nabble.com. > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > -------------- next part -------------- An HTML attachment was scrubbed... URL: From miloslauter at hotmail.com Sun Sep 28 03:30:13 2014 From: miloslauter at hotmail.com (Milos Lauter) Date: Sun, 28 Sep 2014 11:30:13 +0100 Subject: [GRASS-user] Problem with GRASS GIS 6.4.4 Message-ID: Hello, I am having problem with module i.class. When I call it I get a message " 'i.class' is not recognized as an internal or external command, operable program or batch file. " and in GUI Imagery->classify image->interactive input for supervised classification (requires Xterm) [i.class] is unavailable. I am using GRASS GIS 6.4.4 on Windows 8.1. How can I solve this problem? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neteler at osgeo.org Sun Sep 28 12:57:27 2014 From: neteler at osgeo.org (Markus Neteler) Date: Sun, 28 Sep 2014 21:57:27 +0200 Subject: [GRASS-user] Problem with GRASS GIS 6.4.4 In-Reply-To: References: Message-ID: On Sun, Sep 28, 2014 at 12:30 PM, Milos Lauter wrote: > Hello, I am having problem with module i.class. When I call it I get a > message " 'i.class' is not recognized as an internal or external command, > operable program or batch file. " and in GUI Imagery->classify > image->interactive input for supervised classification (requires Xterm) > [i.class] is unavailable. I am using GRASS GIS 6.4.4 on Windows 8.1. How can > I solve this problem? Thank you. This portability problem has been addressed in GRASS GIS 7: http://trac.osgeo.org/grass/wiki/Grass7/NewFeatures#Imageprocessing --> Image processing --> i.class: rewritten in wxGUI, see G7:g.gui.iclass http://grass.osgeo.org/grass70/manuals/g.gui.iclass.html The old i.class in GRASS 6 depends on the X Server which is not part of Windows. With Cygwin you could get it running but it is way more interesting to install GRASS 7 (also in parallel). Markus From ilaria.ferrando at alice.it Mon Sep 29 03:54:10 2014 From: ilaria.ferrando at alice.it (Pilaf) Date: Mon, 29 Sep 2014 03:54:10 -0700 (PDT) Subject: [GRASS-user] Which algorithm does v.net.path use? Message-ID: <1411988050282-5164696.post@n6.nabble.com> Hi everybody, I'm interested in knowing what algorithm is used for the v.net.path shortest path computation. Thank you very much! -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Which-algorithm-does-v-net-path-use-tp5164696.html Sent from the Grass - Users mailing list archive at Nabble.com. From snarrald at gmail.com Mon Sep 29 13:18:09 2014 From: snarrald at gmail.com (=?UTF-8?Q?Svein_Harald_S=C3=B8nderland?=) Date: Mon, 29 Sep 2014 22:18:09 +0200 Subject: [GRASS-user] r.stream.order Message-ID: Hei, I'm a new grass user and I can't manage to install r.stream.order addon on my mac OSX v.10.9.5. Installed Grass GIS 6.4, which runs fine. What am I doing wrong? Thanks in advance! Error message: (Mon Sep 29 11:46:38 2014) g.extension.py extension=r.stream.order svnurl=http://svn.osgeo.org/grass/grass-addons/grass6 GRASS_ADDON_PATH has more items, using first defined - '/Users/snarrald/Library/GRASS/6.4/Modules/bin' Fetching from GRASS-Addons SVN (be patient)... Compiling... /Applications/GRASS-6.4.app/Contents/MacOS/include/Make/Modu le.make:25: warning: overriding commands for target `install' /Applications/GRASS-6.4.app/Contents/MacOS/include/Make/Rule s.make:90: warning: ignoring old commands for target `install' io.c:1:10: fatal error: 'grass/glocale.h' file not found #include ^ 1 error generated. make: *** [OBJ.i386-apple-darwin11.4.0/io.o] Error 1 ERROR: Compilation failed, sorry. Please check above error messages. (Mon Sep 29 11:46:48 2014) Command finished (9 sec) From joseandersonbatista at gmail.com Mon Sep 29 15:20:32 2014 From: joseandersonbatista at gmail.com (=?UTF-8?Q?Jos=C3=A9_Anderson?=) Date: Mon, 29 Sep 2014 19:20:32 -0300 Subject: [GRASS-user] Grass70 win7 r.basin Message-ID: Dear all, in the addon r.basin, the help says that basin output coordinates must be picked up from some vector feature, the river network, which is generated by the addon r.stream.extract. That means I have the utm elevation raster and successfully ran r.watershed for accumulation raster on grass70/win7. However, despite the plugin get steps 1 through 4 without errors, it cannot complete the area delineation. I have tried, both, picking a utm point from point geometries and from line geometries. The message I get is: -- An Error has occurred. Please try with another pairs of outlet coordinates. -- Have anybody tried r.basin from grass70 on win7? Thanks in advance. Jose Anderson -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandramf at live.co.za Mon Sep 29 18:24:47 2014 From: sandramf at live.co.za (Sandra MacFadyen) Date: Tue, 30 Sep 2014 03:24:47 +0200 Subject: [GRASS-user] Solved: execGRASS("r.diversity") Done. No rasters created (Large rasters) In-Reply-To: References: Message-ID: Dear Vaclav, I did a quick manual test to see if the results were correct for a few 5x5 windows and yes, everything appears 100%: # Example data from one 5x5 window test1 = c(572,617,661,638,616, 662,617,593,638,616, 662,639,572,661,616, 662,662,639,662,616, 594,572,594,639,593) # Calculate info needed for diversity indices freq1 = as.data.frame(table(test1)) # Calculate frequency table S = length(unique(test1)) # Total number of species (S) N = length(test1) # Total number of individuals (N) ln.S = log(S) #Natural log of species (ln S) ln.N = log(N) # Natural log of individuals (ln N) Pi = freq1$Freq/N # Proportion of individuals that belong to each species Pi2 = (Pi ^ 2) ln.pi = log(Pi) pi.ln.pi = Pi * ln.pi pi.ln.pi2 = (ln.pi^2)*Pi # Calculate different diversity indices (M = (S-1)/ln.N) # Margalef's index (M) (i.Di = 1/sum(Pi2)) # Simpson's index [Inverse] (i.Di) (i.Dc = 1 - (sum(Pi2))) # Simpson's index [Complement] (i.Dc) * This one calculated with r.diversity (H = sum(pi.ln.pi)*-1) # Shannon-Wiener index (H') (J = H/ln.S) # Pielou's index (J) Thanks again Cheers Sandra From: Vaclav Petras [mailto:wenzeslaus at gmail.com] Sent: 18 September 2014 02:46 AM To: Sandra MacFadyen Cc: Markus Neteler; GRASS user list; Duccio Rocchini; Luca Delucchi Subject: Re: [GRASS-user] Solved: execGRASS("r.diversity") Done. No rasters created (Large rasters) On Wed, Sep 17, 2014 at 7:40 PM, Sandra MacFadyen wrote: Dear Markus, Excellent! Thanks to everyone for their help. I tested r.diversity in the new revision (61840) on a raster with 12933032 cells and it took under 3 minutes to complete r.li.simpson, r.li.shannon, r.li.pielou and r.li.renyi outputs. Amazing :) > execGRASS("r.diversity",flags="overwrite", parameters=list(input="flow", prefix="flow_div", alpha=0.5, size=3)) > r.li.simpson complete. Raster map created. > r.li.shannon complete. Raster map created. > r.li.pielou complete. Raster map created. > r.li.renyi complete. Raster map > created. > Done. Thanks again and keep well. Good to hear that. Can you say if the results are correct? I computed difference of one map before and after and it was OK. But it would be great to have more tests. Let's start with: does the result make sense? Vaclav Cheers Sandra -----Original Message----- From: neteler.osgeo at gmail.com [mailto:neteler.osgeo at gmail.com] On Behalf Of Markus Neteler Sent: 06 September 2014 05:15 AM To: Sandra MacFadyen Cc: GRASS user list; Duccio Rocchini; Luca Delucchi Subject: Re: [GRASS-user] execGRASS("r.diversity") Done. No rasters created (Large rasters) Dear Sandra, On Fri, Jun 20, 2014 at 7:49 AM, Markus Neteler wrote: > On Sat, Jun 14, 2014 at 9:21 AM, Sandra MacFadyen wrote: >> I am using r.diversity (GRASS GIS 7.0.0svn build 60785 win32) through >> R (R version 3.0.2 win32) on Windows 7 64bit. ... >> However, when running the same code on a larger image (cells=6746328) >> from my own location, although it reports Done, no rasters are >> created. If I subset the image >> (cells=1632830) and run it again its works (see # sub2Kruger # code and results below). >> So I'm guessing it is a memory issue? ... > ... it consumes a lot of memory... will check on a bigger machine, > perhaps a memory leak. The assumption turned out to be right and I think we got it today! Vaclav Petras checked it and discovered an "unfortunate" memory allocation which he fixed in r.li.* in revision http://trac.osgeo.org/grass/changeset/61812 ("r.li: fix memory handling (memory leak in avl_to_array function))". Now r.li has become very fast, on my laptop: GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 res=10 -a ... rows: 1355 cols: 1503 cells: 2036565 GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 output=lsat5_1987_div__simpson_size_5.0 r.li.simpson complete. Raster map created. --> 29.32 seconds or with a simulated higher resolution: GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 res=5 -aprojection: 99 (Lambert Conformal Conic) ... rows: 2708 cols: 3005 cells: 8137540 GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 output=lsat5_1987_div__simpson_size_5.0 r.li.simpson complete. Raster map created. --> 227.37 seconds (used to be > 2 hours) So, to grab this improvement for Windows, grab the version from here: http://wingrass.fsv.cvut.cz/grass71/ (or via OSGeo4W installer). Be sure that the revision is at least r61812 which is indicated in the file name. Please let us know if all works to avoid that the change has any negative impact. Tests here did not show any changes in the output except for the speed improvement and solved memory leak. Subsequently also r.diversity should behave now. I'll backport it to GRASS 7.0 release branch after some testing. Markus _______________________________________________ grass-user mailing list grass-user at lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user -------------- next part -------------- An HTML attachment was scrubbed... URL: From mlennert at club.worldonline.be Tue Sep 30 00:04:03 2014 From: mlennert at club.worldonline.be (Moritz Lennert) Date: Tue, 30 Sep 2014 09:04:03 +0200 Subject: [GRASS-user] Which algorithm does v.net.path use? In-Reply-To: <1411988050282-5164696.post@n6.nabble.com> References: <1411988050282-5164696.post@n6.nabble.com> Message-ID: <542A55E3.8020007@club.worldonline.be> On 29/09/14 12:54, Pilaf wrote: > Hi everybody, > I'm interested in knowing what algorithm is used for the v.net.path shortest > path computation. AFAICT, it's Dijkstra: http://trac.osgeo.org/grass/browser/grass/trunk/lib/vector/dglib/graph.c#L785 Moritz From ducciorocchini at gmail.com Tue Sep 30 00:39:39 2014 From: ducciorocchini at gmail.com (Duccio Rocchini) Date: Tue, 30 Sep 2014 09:39:39 +0200 Subject: [GRASS-user] Solved: execGRASS("r.diversity") Done. No rasters created (Large rasters) In-Reply-To: References: Message-ID: This is great Sandra. Now I am curious to see final ecological relationships you are searching for! D 2014-09-30 3:24 GMT+02:00 Sandra MacFadyen : > Dear Vaclav, > > > > I did a quick manual test to see if the results were correct for a few 5x5 > windows and yes, everything appears 100%: > > > > # Example data from one 5x5 window > > test1 = c(572,617,661,638,616, > > 662,617,593,638,616, > > 662,639,572,661,616, > > 662,662,639,662,616, > > 594,572,594,639,593) > > > > # Calculate info needed for diversity indices > > freq1 = as.data.frame(table(test1)) # Calculate frequency table > > S = length(unique(test1)) # Total number of species (S) > > N = length(test1) # Total number of individuals (N) > > ln.S = log(S) #Natural log of species (ln S) > > ln.N = log(N) # Natural log of individuals (ln N) > > Pi = freq1$Freq/N # Proportion of individuals that belong to each species > > Pi2 = (Pi ^ 2) > > ln.pi = log(Pi) > > pi.ln.pi = Pi * ln.pi > > pi.ln.pi2 = (ln.pi^2)*Pi > > > > # Calculate different diversity indices > > (M = (S-1)/ln.N) # Margalef's index (M) > > (i.Di = 1/sum(Pi2)) # Simpson's index [Inverse] (i.Di) > > (i.Dc = 1 - (sum(Pi2))) # Simpson's index [Complement] (i.Dc) * This one > calculated with r.diversity > > (H = sum(pi.ln.pi)*-1) # Shannon-Wiener index (H') > > (J = H/ln.S) # Pielou's index (J) > > > > Thanks again > > > > Cheers > > Sandra > > > > *From:* Vaclav Petras [mailto:wenzeslaus at gmail.com ] > > *Sent:* 18 September 2014 02:46 AM > *To:* Sandra MacFadyen > *Cc:* Markus Neteler; GRASS user list; Duccio Rocchini; Luca Delucchi > *Subject:* Re: [GRASS-user] Solved: execGRASS("r.diversity") Done. No > rasters created (Large rasters) > > > > > > > > On Wed, Sep 17, 2014 at 7:40 PM, Sandra MacFadyen > wrote: > > Dear Markus, > > Excellent! Thanks to everyone for their help. > I tested r.diversity in the new revision (61840) on a raster with 12933032 > cells and it took under 3 minutes to complete r.li.simpson, r.li.shannon, > r.li.pielou and r.li.renyi outputs. > Amazing :) > > > execGRASS("r.diversity",flags="overwrite", parameters=list(input="flow", > prefix="flow_div", alpha=0.5, size=3)) > > r.li.simpson complete. Raster map created. > > r.li.shannon complete. Raster map created. > > r.li.pielou complete. Raster map created. > > r.li.renyi complete. Raster map > > created. > > Done. > > Thanks again and keep well. > > Good to hear that. Can you say if the results are correct? I computed > difference of one map before and after and it was OK. But it would be great > to have more tests. Let's start with: does the result make sense? > > > > Vaclav > > > Cheers > Sandra > > -----Original Message----- > From: neteler.osgeo at gmail.com [mailto:neteler.osgeo at gmail.com] On Behalf > Of Markus Neteler > Sent: 06 September 2014 05:15 AM > To: Sandra MacFadyen > Cc: GRASS user list; Duccio Rocchini; Luca Delucchi > Subject: Re: [GRASS-user] execGRASS("r.diversity") Done. No rasters > created (Large rasters) > > Dear Sandra, > > On Fri, Jun 20, 2014 at 7:49 AM, Markus Neteler wrote: > > On Sat, Jun 14, 2014 at 9:21 AM, Sandra MacFadyen > wrote: > >> I am using r.diversity (GRASS GIS 7.0.0svn build 60785 win32) through > >> R (R version 3.0.2 win32) on Windows 7 64bit. > ... > >> However, when running the same code on a larger image (cells=6746328) > >> from my own location, although it reports Done, no rasters are > >> created. If I subset the image > >> (cells=1632830) and run it again its works (see # sub2Kruger # code and > results below). > >> So I'm guessing it is a memory issue? > ... > > ... it consumes a lot of memory... will check on a bigger machine, > > perhaps a memory leak. > > The assumption turned out to be right and I think we got it today! > > Vaclav Petras checked it and discovered an "unfortunate" memory allocation > which he fixed in r.li.* in revision > http://trac.osgeo.org/grass/changeset/61812 ("r.li: fix memory handling > (memory leak in avl_to_array function))". > > Now r.li has become very fast, on my laptop: > > GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 > res=10 -a ... > rows: 1355 > cols: 1503 > cells: 2036565 > > GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o > input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 > output=lsat5_1987_div__simpson_size_5.0 > r.li.simpson complete. Raster map > created. > --> 29.32 seconds > > or with a simulated higher resolution: > > GRASS 7.1.svn (nc_spm_08_grass7):~ > g.region -p rast=lsat5_1987_10 > res=5 -aprojection: 99 (Lambert Conformal Conic) ... > rows: 2708 > cols: 3005 > cells: 8137540 > > GRASS 7.1.svn (nc_spm_08_grass7):~ > time -p r.li.simpson --o > input=lsat5_1987_10 at landsat conf=conf_diversity_5.0 > output=lsat5_1987_div__simpson_size_5.0 > r.li.simpson complete. Raster map > created. > --> 227.37 seconds (used to be > 2 hours) > > So, to grab this improvement for Windows, grab the version from here: > http://wingrass.fsv.cvut.cz/grass71/ > > (or via OSGeo4W installer). Be sure that the revision is at least > r61812 which is indicated in the file name. > > Please let us know if all works to avoid that the change has any negative > impact. > Tests here did not show any changes in the output except for the speed > improvement and solved memory leak. > > Subsequently also r.diversity should behave now. > > I'll backport it to GRASS 7.0 release branch after some testing. > > Markus > > _______________________________________________ > grass-user mailing list > grass-user at lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > > > -- Duccio Rocchini, PhD http://gis.cri.fmach.it/rocchini/ Fondazione Edmund Mach Research and Innovation Centre Department of Biodiversity and Molecular Ecology GIS and Remote Sensing Unit Via Mach 1, 38010 San Michele all'Adige (TN) - Italy Phone +39 0461 615 570 ducciorocchini at gmail.com duccio.rocchini at fmach.it skype: duccio.rocchini Google Scholar Profile: scholar.google.it/citations?hl=it&user=OJtw7agAAAAJ -------------- next part -------------- An HTML attachment was scrubbed... URL: