[GRASS-user] SOLVED: Compilation Errors Installing GRASS 70 on Centos 6.5
Re-checked out SVN Clean install directory Installed without a hitch :-) ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] Compilation Errors Installing GRASS 70 on Centos 6.5
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/tc
Re: [GRASS-user] r.patch number of input limitation?
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] removing small lines
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch number of input limitation?
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 >> > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch number of input limitation?
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. ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch number of input limitation?
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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch number of input limitation?
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] r.patch number of input limitation?
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/sdb2437G 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
Re: [GRASS-user] New GRASS 7 addon: v.lidar.mcc
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.blumentr...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/grass-user > ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
[GRASS-user] New GRASS 7 addon: v.lidar.mcc
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@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
