Re: [GRASS-dev] r.proj produces null map
Hi, 2015-05-18 17:16 GMT+02:00 Margherita Di Leo direg...@gmail.com: on G7, I made several tentatives trying to reproject raster maps using r.proj, it doesn't yield error but the map is completely empty (null). I made several tentatives on several maps, then also exported and reprojected with gdalwarp, to test if the problem was related to the data. Can someone reproduce this, before i open a ticket. are you sure that you have set in destination location region correctly? See r.proj's -g flag. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Running grass71 from command line on MS Windows
Hi, do you think it would make sense for MS Windows installer to add the main GRASS executable on path? I'm asking because of #2579 (r65252). On MS Windows you will have to use: C:\Program Files (x86)\GRASS GIS...\grass71 C:\grassdata\... exec g.region -p It would be much nicer to be able to do the same as on Linux where GRASS is on path when installed: grass71 ~/grassdata/... exec g.region -p I guess we can instruct the user somewhere (?) that one have to add a particular to PATH variable to have GRASS on path, but this is quite cumbersome to do. Is it possible to modify the installer that it (optionally) adds GRASS on path? The goal is to enable writing (non-grass) scripts which are portable from one computer to another. In case the GRASS command/executable is named grass, rather then grass7 or even grass70/grass71 the scripts can be even more universal (supposing that your script will work with the version marked as grass). Surely, you should have it in some variable in your script but you have to set the value somehow and I would prefer to see scripts not starting with: grass = C:\Program Files (x86)\GRASS GIS...\grass71 but rather grass = grass or grass = grass7 Best, Vaclav https://trac.osgeo.org/grass/ticket/2579 https://trac.osgeo.org/grass/changeset/65252 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding
Dear all, just a short reminder. The crowd funding period for the QGIS GRASS Plugin is still running but will end soon. Everyone who may be willingly to fund this great project can contribute funds until May 23. Best regards Soeren 2015-03-23 19:56 GMT+01:00 Radim Blazek radim.bla...@gmail.com: Hi all, I have finally launched the crowdfunding campaign to support the GRASS plugin upgrade. Briefly, it covers upgrade to GRASS 7, browser integration, drag-and-drop import and new vector editing. All the details are available here: http://www.gissula.eu/qgis-grass-plugin-crowdfunding/ Please propagate this info to all relevant channels, national mailing lists etc. Radim ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r65264 - grass/trunk/lib/cairodriver
2015-05-18 15:46 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: 2015-05-18 15:36 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: +div class=codepre +export GRASS_RENDER_IMMEDIATE=cairo +export GRASS_RENDER_FILE=vectormap.svg + +g.region vector=roadsmajor +d.vect map=roadsmajor -c +/pre/div The syntax is not really nice. Is it possible to replace it with something else like d.mon? Or is this the best interface we have? I am not sure what you mean, but d.mon syntax could be: d.mon cairo out=vectormap.svg g.region vector=roadsmajor d.vect map=roadsmajor -c d.mon -r I think this is exactly what I mean. Any reason for using the variables instead of d.mon? I would say that it make sense to document the both ways (environmental variables on display driver page and d.mon syntax on it's own page), probably we could add note about d.mon to cairo driver manual. Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.proj produces null map
Hi, on G7, I made several tentatives trying to reproject raster maps using r.proj, it doesn't yield error but the map is completely empty (null). I made several tentatives on several maps, then also exported and reprojected with gdalwarp, to test if the problem was related to the data. Can someone reproduce this, before i open a ticket. Thank you -- 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-...@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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] compilation error - macro _n()
Martin Landa wrote:
recently I got problem compiling GRASS module against CGAL library.
The source of problem is duplicated definition of _n() macro.
In file included from /usr/include/boost/random.hpp:37:0,
from /usr/local/include/CGAL/spatial_sort.h:31,
from /usr/local/include/CGAL/Triangulation_3.h:47,
from local_proto.h:4,
from main.cpp:25:
/usr/include/boost/random/discard_block.hpp:60:42: error: macro _n
requires 3 arguments, but only 1 given
discard_block_engine() : _rng(), _n(0) { }
GRASS defines _n() macro as [1], Boost is using _n() macro in different
meaning.
Any idea who to fix this problem correctly?
Boost isn't using any _n() macro; that's the C++ syntax for
initialising a member variable named _n upon construction.
At least, it isn't trying to use a macro. The fact that there happens
to be a macro called _n() in existence at that point is beyond its
control.
It's GRASS' fault for using a reserved name (_n() was added in r59156,
r59189, now 137 occurrences in 52 files), and particularly for using
it as a macro.
Including the CGAL headers before the GRASS headers would avoid this
specific issue.
Note that it's fairly common for C++ code to use such names within
class scope because C++ *has* class scope and reserved names aren't
reserved there. Names created in class scope don't affect other scopes
(and aren't affected by other scopes), and using a reserved name would
normally help to avoid this exact issue.
Macros aren't scoped, so the only way to avoid having a macro
definition breaking your code is to choose a name that's unlikely to
be used as a macro. Ordinarily, a name that's reserved to the
implementation in any scope (i.e. prohibited from being used as a
macro) would be a safe bet for that.
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r65264 - grass/trunk/lib/cairodriver
On Mon, May 18, 2015 at 5:16 AM, svn_gr...@osgeo.org wrote: +h3SVG Example/h3 + +Example: using the driver to generate a SVG vector file with a vector +map (bash-syntax): + +div class=codepre +export GRASS_RENDER_IMMEDIATE=cairo +export GRASS_RENDER_FILE=vectormap.svg + +g.region vector=roadsmajor +d.vect map=roadsmajor -c +/pre/div The syntax is not really nice. Is it possible to replace it with something else like d.mon? Or is this the best interface we have? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS-SVN] r65264 - grass/trunk/lib/cairodriver
Hi, 2015-05-18 15:36 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: +div class=codepre +export GRASS_RENDER_IMMEDIATE=cairo +export GRASS_RENDER_FILE=vectormap.svg + +g.region vector=roadsmajor +d.vect map=roadsmajor -c +/pre/div The syntax is not really nice. Is it possible to replace it with something else like d.mon? Or is this the best interface we have? I am not sure what you mean, but d.mon syntax could be: d.mon cairo out=vectormap.svg g.region vector=roadsmajor d.vect map=roadsmajor -c d.mon -r Martin -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] t.connect test for rasters takes over 3 hours to execute
On Mon, May 18, 2015 at 7:50 AM, Sören Gebbert soerengebb...@googlemail.com wrote: Hi Vaclav, Many thanks for this report. This is really strange, i never run in such problems and cannot reproduce this (3h execution time) on AMD Phenom II with Ubuntu 12.04, AMD FX8350 with Ubuntu 14.04 and google cloud compute engine with Ubuntu 14.04 and debian. It happens to me on some Dell with some Intel and Ubuntu 14.04. Note that it happens with the Italian Location, not NC SPM. First, I though it is related to RPC and lib/python/temporal/testsuite/test_doctests.py on MS Windows ( http://lists.osgeo.org/pipermail/grass-dev/2015-February/074037.html) or to lib/python/pygrass/vector/testsuite/test_doctest.py leaving processes behind* but it is a different test. * I can't find any post about it. I would say I reported that but apparently not. Basically I find every day in process manager 5 processes `python -3 -tt lib/python/pygrass/vector/testsuite/test_doctest.py`. I run the tests 3 times (in 3 different locations). The processes are sleeping with pool_schedule_timeout. This one might be related to the lib/python/pygrass/vector/testsuite/test_doctest.py SIGSEGV ( http://lists.osgeo.org/pipermail/grass-dev/2014-October/071393.html) where Vect_get_num_primitives(), Vect_line_prune() or most often Vect_get_num_db_links() segfaults. Perhaps the functions just cannot deal with maps with don't exist. However, on my machines (AMD Phenom II with Ubuntu 12.04, AMD FX8350 with Ubuntu 14.04 ) the g.remove process segfaults most of the time when called from PyGRASS?? And i have no idea why. I think I'm getting the same error. I was able to reproduce it on one machine with one particular compilation. Although I'm able to reproduce it repetitively (after make distclean) for some time already, it happens just with one particular svn dir and build. It does not happen on the same machine with different svn dir and build. I was not able to figure out what is the difference. Thanks for looking into this, Vaclav I will try to investigate this on different computers in my Institute. Best regards Soeren 2015-05-11 15:52 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: Hi, when I run t.connect test test_distr_tgis_db_raster.py [0] in Piemonte Location [1], it takes 3.5 hours to complete [2]. This is happening constantly for a long time already [3]. There is nothing in the outputs which would indicate anything like this. Any ideas? In case you wonder how different data influence the time, then you can see run in NC SPM Location [4] and in an empty XY Location [5]. Also, similar tests for 3D raster and vector data are fine [6, 7]. Is somebody able to reproduce that behavior or determine why it is happening? Thanks, Vaclav [0] http://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.connect/testsuite/test_distr_tgis_db_raster.py [1] http://grass.osgeo.org/download/sample-data/ [2] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster/index.html [3] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-02-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster/index.html [4] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.connect/test_distr_tgis_db_raster/index.html [5] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_empty_xy_all/temporal/t.connect/test_distr_tgis_db_raster/index.html [6] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster3d/index.html [7] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_vector/index.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2672: r.surf.idw should support FCELL and DCELL
#2672: r.surf.idw should support FCELL and DCELL ---+- Reporter: annakrat | Owner: grass-dev@… Type: defect| Status: new Priority: normal| Milestone: 7.0.1 Component: Raster|Version: svn-releasebranch70 Resolution:| Keywords: r.surf.idw CPU: All | Platform: All ---+- Comment (by kuszinger): '''Comment only''': Any solution is generated, I've realized that in V7 r.surf.id eats much more memory than in 6.4. Addition of FCELL and DCELL is handy, but I'm afraid that it may lead to further memory footprint growing. I'm ready for testing, anyway any new version. I use r.surf.idw extensively on huge sparse rasters where it takes 2 - 10 GB RAM to create the result. When it is about an FCELL source my workaround is creating a temporal CELL coverage with mapcalc and multiplication and rounding original values and when idw is done I calculate it back to an FCELL and remove the temporal map. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2672#comment:3 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] QGIS GRASS Plugin Upgrade Crowdfunding
On Mon, May 18, 2015 at 2:22 PM, Sören Gebbert soerengebb...@googlemail.com wrote: Dear all, just a short reminder. The crowd funding period for the QGIS GRASS Plugin is still running but will end soon. Everyone who may be willingly to fund this great project can contribute funds until May 23. BTW, raster/vector import via browser is in master (pushed today), you can test. Dual build (with GRASS 6 + 7) is also available. Big thanks to Jef for porting dual build to Windows. Currently there is unfortunately some problem in browser with GRASS 7 vectors (crash), but GRASS 7 vectors load correctly from project file (e.g. project created in GRASS 6, vectors upgraded to GRASS 7 and project reopened in QGIS with GRASS 7). I'll do more detailed announcement after QGIS 2.10 freeze. Radim Best regards Soeren 2015-03-23 19:56 GMT+01:00 Radim Blazek radim.bla...@gmail.com: Hi all, I have finally launched the crowdfunding campaign to support the GRASS plugin upgrade. Briefly, it covers upgrade to GRASS 7, browser integration, drag-and-drop import and new vector editing. All the details are available here: http://www.gissula.eu/qgis-grass-plugin-crowdfunding/ Please propagate this info to all relevant channels, national mailing lists etc. Radim ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.proj produces null map
[forgot the list ] On Mon, May 18, 2015 at 8:35 AM, Margherita Di Leo direg...@gmail.com wrote: On Mon, May 18, 2015 at 8:18 AM, Martin Landa landa.mar...@gmail.com wrote: are you sure that you have set in destination location region correctly? See r.proj's -g flag. I think so, unless I can't see the obvious... here's an example r.proj -g input=accum location=GMTED2010-wgs84 mapset=res075 n=3036289.28490875 s=1327842.48956189 w=3859987.52509802 e=5240836.36134497 rows=7200 cols=7200 the region in the destination mapset is g.region -p projection: 99 (Lambert Azimuthal Equal Area) zone: 0 datum: etrs89 ellipsoid: grs80 north: 3036500 south: 1327500 west: 3859750 east: 5241000 nsres: 250 ewres: 250 rows: 6836 cols: 5525 cells: 37768900 r.proj input=accum location=GMTED2010-wgs84 mapset=res075 output=acc_prova method=nearest Input: Cols: 7202 (7200) Rows: 7200 (7200) North: 49.999861 (49.999861) South: 34.999861 (34.999861) West: 364.995694 (4.999861) East: 379.999861 (19.999861) EW-res: 0.002083 NS-res: 0.002083 Output: Cols: 5524 (5525) Rows: 6834 (6836) North: 3036250.00 (3036500.00) South: 1327750.00 (1327500.00) West: 3859750.00 (3859750.00) East: 5240750.00 (5241000.00) EW-res: 250.00 NS-res: 250.00 Allocating memory and reading input raster map... Projecting... r.proj complete. r.info acc_prova ++ | Map: acc_prova Date: Mon May 18 08:26:37 2015| | Mapset: wetness-idxLogin of Creator: user| | Location: GMTED2010-LAEA | | DataBase: /home/user/GIS/grassdata | | Title: ( acc_prova ) | | Timestamp: none| || | | | Type of Map: raster Number of Categories: 0 | | Data Type: DCELL | | Rows: 6834 | | Columns: 5524 | | Total Cells: 37751016 | |Projection: Lambert Azimuthal Equal Area| |N:3036250S:1327750 Res: 250 | |E:5240750W:3859750 Res: 250 | | Range of data:min = -nan max = -nan | | | | Data Description:| |generated by r.proj | | | | Comments:| |r.proj input=accum location=GMTED2010-wgs84 mapset=res075 outp\ | |ut=acc_prova method=nearest memory=300 | | | ++ -- 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-...@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. -- 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-...@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-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2579: Specify command to be exectued as parameter of grass command
#2579: Specify command to be exectued as parameter of grass command --+-- Reporter: wenzeslaus | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.1.0 Component: Startup |Version: svn-trunk Resolution: | Keywords: batch job, GRASS_BATCH_JOB, init CPU: Unspecified | Platform: All --+-- Comment (by wenzeslaus): I've updated documentation in r65269 and r65270. It is not complete (e.g., there are no explanations) but it should be enough to try it and use it. I created example which uses `r.external`, `r.univar` and `g.gui.mapswipe`. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2579#comment:13 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1788: r.viewshed binary flag (-b) not working correctly
#1788: r.viewshed binary flag (-b) not working correctly --+- Reporter: cmbarton | Owner: grass-dev@… Type: defect | Status: reopened Priority: normal | Milestone: 7.0.0 Component: Raster |Version: svn-trunk Resolution: | Keywords: r.viewshed CPU: Unspecified | Platform: Unspecified --+- Changes (by annakrat): * status: closed = reopened * resolution: fixed = Comment: Reopened because it works only when using internal memory. When using external memory mode, binary output gives 1 and nulls. It doesn't seem to be so easily fixable as the in-memory case, because I can't find an easy way to find out which cell should be 0 and which should be null. -- Ticket URL: http://trac.osgeo.org/grass/ticket/1788#comment:4 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE
#2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE --+--- Reporter: neteler | Owner: grass-dev@… Type: enhancement | Status: new Priority: critical | Milestone: 7.1.0 Component: Raster |Version: svn-trunk Resolution: | Keywords: compression, r.compress, null CPU: Unspecified | Platform: All --+--- Comment (by glynn): Replying to [comment:23 neteler]: After cleaning up well on that machine, it is now finally working (sorry for the delay). Committed in r65272, with one minor change: before writing out the null file, both cell_misc/null and cell_misc/null2 are deleted, not just the file which is being replaced. This avoids the situation where overwriting a map with null compression disabled would leave any compressed null file in place, resulting in the map having both a new uncompressed null file and an old compressed null file, with the new file being ignored (a compressed null file takes precedence). Actually, the precedence should probably be changed. If someone uses an older version of GRASS to overwrite a map which already has a compressed null file, newer versions of GRASS will use the (stale) compressed null file. It would be more robust to use the absence of an uncompressed null file to dictate the use of the compressed file, rather than just the presence of a compressed file. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2349#comment:24 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] PROJ problem compiling GRASS trunk
I just updated and tried to compile GRASS trunk. I also updated to the 2015-04-11 version of GDAL complete 1.11 When I tried compiling, I got the following error from /Users/cmbarton/grass_source/grass_trunk/lib/proj urce/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stlrnc.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stpaul.lla /Library/Frameworks/PROJ.framework/Programs/nad2bin FL.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL dyld: Library not loaded: /Users/Shared/src/proj.4/build-4.9.1/lion/usr/lib/libproj.9.dylib Referenced from: /Library/Frameworks/PROJ.framework/Programs/nad2bin Reason: image not found /bin/sh: line 1: 65178 Trace/BPT trap: 5 /Library/Frameworks/PROJ.framework/Programs/nad2bin /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL FL.lla make[1]: *** [/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL] Error 133 When I rolled back to the 2014-12 version of GDAL complete 1.11, it compiles fine. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE
#2349: CELL raster format: make ZLIB level 3 standard compression instead of RLE --+--- Reporter: neteler | Owner: grass-dev@… Type: enhancement | Status: new Priority: critical | Milestone: 7.1.0 Component: Raster |Version: svn-trunk Resolution: | Keywords: compression, r.compress, null CPU: Unspecified | Platform: All --+--- Comment (by glynn): Replying to [comment:24 glynn]: Actually, the precedence should probably be changed. If someone uses an older version of GRASS to overwrite a map which already has a compressed null file, newer versions of GRASS will use the (stale) compressed null file. It would be more robust to use the absence of an uncompressed null file to dictate the use of the compressed file, rather than just the presence of a compressed file. Done in r65273. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2349#comment:25 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS trunk will no longer compile for Mac
A completely new installation compiled without error but will not launch with yet new errors. Michael Last login: Mon May 18 15:28:40 on ttys001 cmb-imaccsdc-2:~ cmbarton$ '/Applications/GRASS-7.1.app/Contents/MacOS/grass.sh'; exit Rebuilding Addon HTML manual pages index... Rebuilding Addon menu... Python 2.7.6 found. Traceback (most recent call last): File /Applications/GRASS-7.1.app/Contents/MacOS/grass71, line 1507, in module params = parse_cmdline(sys.argv[1:]) File /Applications/GRASS-7.1.app/Contents/MacOS/grass71, line 1424, in parse_cmdline params.mapset = args[0] IndexError: list index out of range logout [Process completed] C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On May 18, 2015, at 1:50 PM, Anna Petrášová kratocha...@gmail.commailto:kratocha...@gmail.com wrote: On Mon, May 18, 2015 at 4:22 PM, Michael Barton michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote: Although GRASS compiles without error, it fails on launch with the errors listed below. This was all working a few months back. So some new change has broken it again. Same wxgui stuff as before. Michael File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 140, in module sys.exit(main()) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 132, in main app = GMApp(workspaceFile) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 46, in __init__ wx.App.__init__(self, False) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 79, in OnInit from lmgr.frame import GMFrame File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/frame.py, line 50, in module from lmgr.layertreeimport LayerTree, LMIcons File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py, line 37, in module from mapdisp.frameimport MapFrame File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py, line 34, in module from vdigit.toolbarsimport VDigitToolbar File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py, line 30, in module from iclass.digit import IClassVDigit File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/iclass/digit.py, line 23, in module from vdigit.wxdisplay import DisplayDriver, TYPE_AREA ImportError: cannot import name TYPE_AREA Please try again, we had this before and it was just a mistake, so hopefully nothing is broken http://trac.osgeo.org/grass/ticket/2538 Anna C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262tel:480-965-6262 (SHESC), 480-965-8130tel:480-965-8130/727-9746 (CSDC) fax: 480-965-7671tel:480-965-7671 (SHESC), 480-727-0709tel:480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.eduhttp://csdc.asu.edu/ ___ grass-dev mailing list grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS trunk will no longer compile for Mac
On Mon, May 18, 2015 at 4:22 PM, Michael Barton michael.bar...@asu.edu wrote: Although GRASS compiles without error, it fails on launch with the errors listed below. This was all working a few months back. So some new change has broken it again. Same wxgui stuff as before. Michael File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 140, in module sys.exit(main()) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 132, in main app = GMApp(workspaceFile) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 46, in __init__ wx.App.__init__(self, False) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 79, in OnInit from lmgr.frame import GMFrame File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/frame.py, line 50, in module from lmgr.layertreeimport LayerTree, LMIcons File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py, line 37, in module from mapdisp.frameimport MapFrame File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py, line 34, in module from vdigit.toolbarsimport VDigitToolbar File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py, line 30, in module from iclass.digit import IClassVDigit File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/iclass/digit.py, line 23, in module from vdigit.wxdisplay import DisplayDriver, TYPE_AREA ImportError: cannot import name TYPE_AREA Please try again, we had this before and it was just a mistake, so hopefully nothing is broken http://trac.osgeo.org/grass/ticket/2538 Anna C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS trunk will no longer compile for Mac
On Mon, May 18, 2015 at 6:31 PM, Michael Barton michael.bar...@asu.edu wrote: A completely new installation compiled without error but will not launch with yet new errors. Michael Last login: Mon May 18 15:28:40 on ttys001 cmb-imaccsdc-2:~ cmbarton$ '/Applications/GRASS-7.1.app/Contents/MacOS/grass.sh'; exit Rebuilding Addon HTML manual pages index... Rebuilding Addon menu... Python 2.7.6 found. Traceback (most recent call last): File /Applications/GRASS-7.1.app/Contents/MacOS/grass71, line 1507, in module params = parse_cmdline(sys.argv[1:]) File /Applications/GRASS-7.1.app/Contents/MacOS/grass71, line 1424, in parse_cmdline params.mapset = args[0] IndexError: list index out of range logout Please do svn up again. The error was there between 12:36:53 PM (6 hours ago) and 2:57:19 PM (4 hours ago). Sorry for the inconvenience. https://trac.osgeo.org/grass/changeset/65275 https://trac.osgeo.org/grass/changeset/65274 [Process completed] C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On May 18, 2015, at 1:50 PM, Anna Petrášová kratocha...@gmail.com wrote: On Mon, May 18, 2015 at 4:22 PM, Michael Barton michael.bar...@asu.edu wrote: Although GRASS compiles without error, it fails on launch with the errors listed below. This was all working a few months back. So some new change has broken it again. Same wxgui stuff as before. Michael File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 140, in module sys.exit(main()) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 132, in main app = GMApp(workspaceFile) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 46, in __init__ wx.App.__init__(self, False) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 79, in OnInit from lmgr.frame import GMFrame File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/frame.py, line 50, in module from lmgr.layertreeimport LayerTree, LMIcons File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py, line 37, in module from mapdisp.frameimport MapFrame File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py, line 34, in module from vdigit.toolbarsimport VDigitToolbar File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py, line 30, in module from iclass.digit import IClassVDigit File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/iclass/digit.py, line 23, in module from vdigit.wxdisplay import DisplayDriver, TYPE_AREA ImportError: cannot import name TYPE_AREA Please try again, we had this before and it was just a mistake, so hopefully nothing is broken http://trac.osgeo.org/grass/ticket/2538 Anna C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PROJ problem compiling GRASS trunk
I might have a hack to fix this. I add one of the programs to the path at compile time and could add the others too. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu On May 18, 2015, at 6:40 PM, Anna Petrášová kratocha...@gmail.commailto:kratocha...@gmail.com wrote: On Mon, May 18, 2015 at 8:49 PM, William Kyngesburye wokl...@kyngchaos.commailto:wokl...@kyngchaos.com wrote: Oops, the PROJ programs are still linked to my build. I'll fix it soon. I am not sure if this is related, but there is some problem with PROJ programs not being on path. So when using m.proj which calls cs2cs, you get an error from m.proj (cs2cs program not found, install PROJ.4 first). I saw this on couple of computers which were using Michael's binaries. Anna On May 18, 2015, at 2:51 PM, Michael Barton michael.bar...@asu.edumailto:michael.bar...@asu.edu wrote: I just updated and tried to compile GRASS trunk. I also updated to the 2015-04-11 version of GDAL complete 1.11 When I tried compiling, I got the following error from /Users/cmbarton/grass_source/grass_trunk/lib/proj urce/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stlrnc.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stpaul.lla /Library/Frameworks/PROJ.framework/Programs/nad2bin FL.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL dyld: Library not loaded: /Users/Shared/src/proj.4/build-4.9.1/lion/usr/lib/libproj.9.dylib Referenced from: /Library/Frameworks/PROJ.framework/Programs/nad2bin Reason: image not found /bin/sh: line 1: 65178 Trace/BPT trap: 5 /Library/Frameworks/PROJ.framework/Programs/nad2bin /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL FL.lla make[1]: *** [/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL] Error 133 When I rolled back to the 2014-12 version of GDAL complete 1.11, it compiles fine. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.eduhttp://csdc.asu.edu/ ___ grass-dev mailing list grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.orgmailto:grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PROJ problem compiling GRASS trunk
Oops, the PROJ programs are still linked to my build. I'll fix it soon. On May 18, 2015, at 2:51 PM, Michael Barton michael.bar...@asu.edu wrote: I just updated and tried to compile GRASS trunk. I also updated to the 2015-04-11 version of GDAL complete 1.11 When I tried compiling, I got the following error from /Users/cmbarton/grass_source/grass_trunk/lib/proj urce/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stlrnc.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stpaul.lla /Library/Frameworks/PROJ.framework/Programs/nad2bin FL.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL dyld: Library not loaded: /Users/Shared/src/proj.4/build-4.9.1/lion/usr/lib/libproj.9.dylib Referenced from: /Library/Frameworks/PROJ.framework/Programs/nad2bin Reason: image not found /bin/sh: line 1: 65178 Trace/BPT trap: 5 /Library/Frameworks/PROJ.framework/Programs/nad2bin /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL FL.lla make[1]: *** [/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL] Error 133 When I rolled back to the 2014-12 version of GDAL complete 1.11, it compiles fine. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] GRASS trunk will no longer compile for Mac
Although GRASS compiles without error, it fails on launch with the errors listed below. This was all working a few months back. So some new change has broken it again. Same wxgui stuff as before. Michael File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 140, in module sys.exit(main()) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 132, in main app = GMApp(workspaceFile) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 46, in __init__ wx.App.__init__(self, False) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7981, in __init__ self._BootstrapApp() File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/etc/python/wx/_core.py, line 7555, in _BootstrapApp return _core_.PyApp__BootstrapApp(*args, **kwargs) File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/wxgui.py, line 79, in OnInit from lmgr.frame import GMFrame File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/frame.py, line 50, in module from lmgr.layertreeimport LayerTree, LMIcons File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/lmgr/layertree.py, line 37, in module from mapdisp.frameimport MapFrame File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/mapdisp/frame.py, line 34, in module from vdigit.toolbarsimport VDigitToolbar File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/vdigit/toolbars.py, line 30, in module from iclass.digit import IClassVDigit File /Users/cmbarton/grass_source/grass_trunk/macosx/dist/GRASS-7.1.app/Contents/MacOS/gui/wxpython/iclass/digit.py, line 23, in module from vdigit.wxdisplay import DisplayDriver, TYPE_AREA ImportError: cannot import name TYPE_AREA C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] PROJ problem compiling GRASS trunk
On Mon, May 18, 2015 at 8:49 PM, William Kyngesburye wokl...@kyngchaos.com wrote: Oops, the PROJ programs are still linked to my build. I'll fix it soon. I am not sure if this is related, but there is some problem with PROJ programs not being on path. So when using m.proj which calls cs2cs, you get an error from m.proj (cs2cs program not found, install PROJ.4 first). I saw this on couple of computers which were using Michael's binaries. Anna On May 18, 2015, at 2:51 PM, Michael Barton michael.bar...@asu.edu wrote: I just updated and tried to compile GRASS trunk. I also updated to the 2015-04-11 version of GDAL complete 1.11 When I tried compiling, I got the following error from /Users/cmbarton/grass_source/grass_trunk/lib/proj urce/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stlrnc.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/src/stpaul.lla /Library/Frameworks/PROJ.framework/Programs/nad2bin FL.lla /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL dyld: Library not loaded: /Users/Shared/src/proj.4/build-4.9.1/lion/usr/lib/libproj.9.dylib Referenced from: /Library/Frameworks/PROJ.framework/Programs/nad2bin Reason: image not found /bin/sh: line 1: 65178 Trace/BPT trap: 5 /Library/Frameworks/PROJ.framework/Programs/nad2bin /Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL FL.lla make[1]: *** [/Users/cmbarton/grass_source/grass_trunk/dist.x86_64-apple-darwin14.3.0/etc/proj/nad/FL] Error 133 When I rolled back to the 2014-12 version of GDAL complete 1.11, it compiles fine. Michael C. Michael Barton Director, Center for Social Dynamics Complexity Professor of Anthropology, School of Human Evolution Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ We are at war with them. Neither in hatred nor revenge and with no particular pleasure I shall kill every ___ I can until the war is over. That is my duty. Don't you even hate 'em? What good would it do if I did? If all the many millions of people of the allied nations devoted an entire year exclusively to hating the it wouldn't kill one ___ nor shorten the war one day. Ha, ha And it might give 'em all stomach ulcers. - Tarzan, on war ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] t.connect test for rasters takes over 3 hours to execute
Hi Vaclav, Many thanks for this report. This is really strange, i never run in such problems and cannot reproduce this (3h execution time) on AMD Phenom II with Ubuntu 12.04, AMD FX8350 with Ubuntu 14.04 and google cloud compute engine with Ubuntu 14.04 and debian. However, on my machines (AMD Phenom II with Ubuntu 12.04, AMD FX8350 with Ubuntu 14.04 ) the g.remove process segfaults most of the time when called from PyGRASS?? And i have no idea why. I will try to investigate this on different computers in my Institute. Best regards Soeren 2015-05-11 15:52 GMT+02:00 Vaclav Petras wenzesl...@gmail.com: Hi, when I run t.connect test test_distr_tgis_db_raster.py [0] in Piemonte Location [1], it takes 3.5 hours to complete [2]. This is happening constantly for a long time already [3]. There is nothing in the outputs which would indicate anything like this. Any ideas? In case you wonder how different data influence the time, then you can see run in NC SPM Location [4] and in an empty XY Location [5]. Also, similar tests for 3D raster and vector data are fine [6, 7]. Is somebody able to reproduce that behavior or determine why it is happening? Thanks, Vaclav [0] http://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.connect/testsuite/test_distr_tgis_db_raster.py [1] http://grass.osgeo.org/download/sample-data/ [2] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster/index.html [3] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2014-10-02-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster/index.html [4] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_nc_spm_08_grass7_nc/temporal/t.connect/test_distr_tgis_db_raster/index.html [5] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_empty_xy_all/temporal/t.connect/test_distr_tgis_db_raster/index.html [6] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_raster3d/index.html [7] http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-05-11-07-00/report_for_piemonte_utm32_wgs84_grass7_stdmaps/temporal/t.connect/test_distr_tgis_db_vector/index.html ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
