[GRASS-dev] G6.4.2: gis.m issue on Ubuntu
Hi devs, I got a request from an Ubuntu user related to gis.m/tcltk/sqlite but have no idea how to help: On Tue, Jul 23, 2013 at 10:01 AM, wrote: I am trying to run Grass 6.4 following instructions in chapter 3 of your book using the nc_spm_08 downloaded from your site. I am using Ubuntu 12.10 64-bit, with Grass 6.4 installed from the Ubuntu Software Center, and with SQLite 3. I get this message when trying to run - gis.m GRASS 6.4.2 (nc_spm_08):~ gis.m GRASS 6.4.2 (nc_spm_08):~ error reading package index file /usr/lib/sqlite/pkgIndex.tcl: expected version number but got 0.0. The line in pkgIndex.tcl is: package ifneeded sqlite 0.0. [list load [file join $dir libtclsqlite.so.0] sqlite] How can this be fixed? Does anyone have a suggestion for this user? thanks Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
On Thu, Jul 18, 2013 at 6:42 PM, Markus Neteler nete...@osgeo.org wrote: Hi all, after the publication of 6.4.3RC4 http://grass.osgeo.org/news/25/15/GRASS-GIS-6-4-3RC4-released/ let's think about the final release in these days: See also: * all GRASS 6 bugs ordered by topic: https://trac.osgeo.org/grass/report/16 I would note that there is no blocker bug report at time. http://trac.osgeo.org/grass/query?status=newstatus=assignedstatus=reopenedgroup=typeorder=prioritypriority=blockerpriority=criticalmilestone=6.4.3milestone=6.4.2milestone=6.4.1milestone=6.4.0 Greetings from Prague (http://grasswiki.osgeo.org/wiki/Talk:GRASS_Community_Sprint_Prague_2013) Today could be a great rlease-6.4.3-day :) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] start grass with only initializing the environment
On Mon, Jul 15, 2013 at 5:44 PM, Rainer M Krug rai...@krugs.de wrote: ... I would therefore suggest an additional startup argument for grass, which only sets the environmental variables, including library paths, so that GRASS commands can be executed afterwards, and if the LOCATION_NAME and MAPSET are not provided, they will be null and *have to be set manualy afterwards*. This could e.g. have the name -noui indicating that no ui will be started. I wonder what the difference to starting GRASS 7 with -text is... Maybe that's already enough? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
On 23 July 2013 10:29, Markus Neteler nete...@osgeo.org wrote: Today could be a great rlease-6.4.3-day :) we are so close to 30 July that we could wait a week and release in the same day of his born :-) Markus -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1940: wingrass - nsis - script in release mode: !define SVN_REVISION @GRASS_VERSION_SVN@ not set
#1940: wingrass - nsis - script in release mode: !define SVN_REVISION
@GRASS_VERSION_SVN@ not set
+---
Reporter: hellik | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical| Milestone: 6.4.3
Component: Packaging | Version: 6.4.3 RCs
Keywords: nsis, wingrass |Platform: MSWindows 7
Cpu: x86-64 |
+---
Comment(by hellik):
Replying to [comment:11 hamish]:
from the subject of this bug it seems the issue has to do with building
an official versioned release, not with a random svn snapshot build?
In that case the svn rev and thus svnversion are mostly irrelevant;
.svn/ metadata is not in the final tarball, and if a historian is
curious what svn rev the version refers to they can always look it up in
the tag's log.
see
http://trac.osgeo.org/grass/browser/grass/branches/releasebranch_6_4/mswindows
/GRASS-Installer.nsi.tmpl#L251
{{{
!define /math VERSION ${SVN_REVISION} + ${BINARY_REVISION}
}}}
${VERSION} is used in the nsis-script/wingrass-installer to check if the
installer is newer/older than the already installed
--
Ticket URL: http://trac.osgeo.org/grass/ticket/1940#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] #1275: zipped HGT Import fails on wingrass as unzip isn't in the package
#1275: zipped HGT Import fails on wingrass as unzip isn't in the package +--- Reporter: MartinOver | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: 6.4.3 Component: Packaging | Version: svn-releasebranch64 Keywords: r.in.srtm, wingrass, unzip |Platform: MSWindows XP Cpu: All | +--- Comment(by hellik): Replying to [comment:10 martinl]: Replying to [comment:9 neteler]: An easy solution would be to add the zip package http://sourceforge.net/projects/gnuwin32/files/zip/ to the MSYS package: http://trac.osgeo.org/osgeo4w/wiki/pkg-msys done for `msys-1.0.11-11` (1) (1) http://trac.osgeo.org/osgeo4w/wiki/pkg-msys#Extrapackages unzip [1] seems to be needed to close this ticket. [1] http://gnuwin32.sourceforge.net/packages/unzip.htm -- Ticket URL: https://trac.osgeo.org/grass/ticket/1275#comment:15 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] G6.4.2: gis.m issue on Ubuntu
MarkusN: I got a request from an Ubuntu user related to gis.m/tcltk/sqlite but have no idea how to help: On Tue, Jul 23, 2013 at 10:01 AM, wrote: I am trying to run Grass 6.4 following instructions in chapter 3 of your book using the nc_spm_08 downloaded from your site. I am using Ubuntu 12.10 64-bit, with Grass 6.4 installed from the Ubuntu Software Center, and with SQLite 3. I get this message when trying to run - gis.m GRASS 6.4.2 (nc_spm_08):~ gis.m GRASS 6.4.2 (nc_spm_08):~ error reading package index file /usr/lib/sqlite/pkgIndex.tcl: expected version number but got 0.0. The line in pkgIndex.tcl is: package ifneeded sqlite 0.0. [list load [file join $dir libtclsqlite.so.0] sqlite] How can this be fixed? Does anyone have a suggestion for this user? not really, /usr/lib/sqlite/pkgIndex.tcl comes from the libsqlite-tcl package, but that is not used or required by the grass package(s) AFAIK. I just tried GIS.m in an Lubuntu 13.04 VM and gis.m worked ok. I did get the same error message if I manually installed the libsqlite-tcl package (even with dbf as the db.connect default), but other than the message in the terminal gis.m seemed to work ok. So I'd guess an error in the other package and grass users can ignore it? ?, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] start grass with only initializing the environment
Rainer wrote:
I would therefore suggest an additional startup argument for grass,
which only sets the environmental variables, including library paths,
so that GRASS commands can be executed afterwards,
just make your own batch file or function(){} for /etc/bash.bashrc?
and if the LOCATION_NAME and MAPSET are not provided, they will be
null and *have to be set manualy afterwards*.
that doesn't sound like a practice we should promote.
what part of the start up are you trying to avoid? ('grass64 -text'
works in 6 too, or 'g.gui text' to avoid the gui at startup)
see also the usage for GRASS_BATCH_JOB, which basically does that in
a non-interactive environment.
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
#2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
--+-
Reporter: huhabla | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: major | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: display, Python, multiprocessing |Platform: All
Cpu: All |
--+-
Comment(by huhabla):
I am not fully convinced using the mmap() approach for IPC. It is not
guaranteed that mmap() is faster then the usual file I/O.[1]
I have written a small python script to test the performance of d.rast and
d.vect using the north carolina sample dataset. The script is attached. I
am using the PNG and Cairo driver, switching mmap on and of for different
window sizes. In addition i call the d.rast (1x) and d.vect (2x) modules
in parallel to measure a render speed gain. The composition is still
missing, but i will add the PIL approach available in the grass wiki with
python.mmap support. Here is the script:
{{{
# -*- coding: utf-8 -*-
from grass.pygrass import modules
import os
import time
parallel = [True, False]
drivers = [png, cairo]
mmap_modes = [FALSE, TRUE]
sizes = [1024, 4096]
def render_image(module, driver=png, pngfile=test.png,
size=4096, mapped=TRUE):
os.putenv(GRASS_RENDER_IMMEDIATE, %s%driver)
os.putenv(GRASS_PNGFILE, %s%pngfile)
os.putenv(GRASS_WIDTH, %i%size)
os.putenv(GRASS_HEIGHT, %i%size)
os.putenv(GRASS_PNG_MAPPED, %s%mapped)
module.run()
def composite_images(files):
pass
def main():
# Set the region
modules.Module(g.region, rast=elevation, flags=p)
for finish in parallel:
if finish:
print(*** Serial runs)
else:
print(*** Parallel runs)
# Setup the modules
rast = modules.Module(d.rast, map=elevation, run_=False,
quiet=True, finish_=False)
vectB = modules.Module(d.vect, map=streams, width=1,
color=blue,
fcolor=aqua, type=[area,line],
run_=False, quiet=True, finish_=finish)
vectA = modules.Module(d.vect, map=roadsmajor, width=2,
run_=False, quiet=True, finish_=finish)
count = 0
for driver in drivers:
for mode in mmap_modes:
for size in sizes:
start = time.time()
count += 1
files = []
if mode == TRUE:
rast_file = rast.bmp
vectA_file=vectA.bmp
vectB_file=vectB.bmp
else:
rast_file = rast.png
vectA_file=vectA.png
vectB_file=vectB.png
render_image(rast, driver=driver, pngfile=rast_file,
size=size, mapped=mode)
render_image(vectA, driver=driver, pngfile=vectA_file,
size=size, mapped=mode)
render_image(vectB, driver=driver, pngfile=vectB_file,
size=size, mapped=mode)
files.append(rast_file)
files.append(vectA_file)
files.append(vectB_file)
# Wait for processes
rast.popen.wait()
vectA.popen.wait()
vectB.popen.wait()
# Composite the images
composite_images(files)
for file in files:
os.remove(file)
elapsed = (time.time() - start)
print(*** Run %i Driver=%s mmap=%s Size=%i
time=%f%(count,
driver,
mode,
size,
elapsed))
main()
}}}
The result of the benchmark:
{{{
GRASS 7.0.svn (nc_spm_08_grass7):~/src python display_bench.py
projection: 99 (Lambert Conformal Conic)
zone: 0
datum: nad83
ellipsoid: a=6378137 es=0.006694380022900787
north: 228500
south: 215000
west: 63
east: 645000
nsres: 10
ewres: 10
rows: 1350
cols: 1500
cells: 2025000
*** Serial runs
*** Run 1 Driver=png mmap=FALSE Size=1024 time=0.796055
*** Run 2 Driver=png mmap=FALSE Size=4096 time=3.389201
*** Run 3 Driver=png mmap=TRUE Size=1024 time=0.449877
*** Run 4 Driver=png mmap=TRUE Size=4096 time=3.723065
*** Run 5 Driver=cairo mmap=FALSE Size=1024 time=0.824797
***
Re: [GRASS-dev] GRASS 6.4.3 release planning
Markus Neteler wrote: Today could be a great rlease-6.4.3-day :) since on the 24th we are +2 weeks since RC4 without any major bugs being reported I think we are ok to release any time now. I don't know about anyone else but I can't say I've really tested rc4 very much beyond making sure the debian package building still works. too busy :-/ Luca: we are so close to 30 July that we could wait a week and release in the same day of his born :-) It would be a nice little something for the release announcement too. :) Speaking of which, do we want to write the formal release announcement + 2 paragraph abstract as we have for earlier releases in grass-web svn, or do something different now? I think we need something higher-level than the trac wiki's detailed changelog highlights, and that it should be done before release. I might try a first draft tomorrow if no one else has started on it. Also MarkusN's visual changelog idea is nice, the trac news items for the earlier RCs should give some ideas. anyone like to start on screenshots for that? maybe host/compose in the more thumbnail- friendly/prettier grass mediawiki? fyi the only bug I'm actively thinking on in 6.x is m.proj (and so r.in.wms) on WinGrass when the location uses a grid transform file. It fails due to a cs2cs quoting problem + spaces in $GISBASE/etc/ path to the NTv2 grid file. I've got it close to working in 6.5svn (but not quite) and can prototype it working on the command line in wingrass 6.4, but still it gives bad results from the script. Things are quite busy for me right now so unless someone else wants to help I think that can wait for the next train. It's listed in the rc4 errata and I think the next step is working on some known-good transforms of modern and pre-satellite era datum transforms into a new m.proj test_suite/ script. best, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] d.rast3d not launching on windows
Anna:
Unable to fetch interface description for command 'd.rast3d.py'.
...
Details: C:\OSGeo4W_dev\bin\python.exe: can't open file
'd.rast3d.py': [Errno 2] No such file or directory
[1] http://trac.osgeo.org/grass/changeset/57218
...
os.chdir(...)
Hamish:
the Unable to fetch interface description for command error is typically
because the g.parser script-handling module can not find the script that
called it in the system $PATH.
(error message happens in lib/python/script/task.py)
The os.chdir() solution may work on Windows since . is usually in
%PATH% there, but on Unix . is typically not in your path.
I think it's better remove the os.chdir()s and replace them by adding
$GISBASE/etc/gui/scripts/ to the PATH when the wxGUI first starts up.
Going into the grass7 wxGUI's Python shell tab, and import os,
os.getenv('PATH') shows the last entry as etc/gui/scripts/ already.
(tested on linux) :-/ so that might not be it.
Anna:
the command is launched with python executable:
.../python.exe d.rast3d.py
so it seems that it expects the full path to the script and
therefore chdir before it made it work.
$GISBASE/etc/gui/scripts/ is already on the PATH.
if etc/gui/scripts/ is already in the PATH why does cd make any
difference? perhaps it needs to be in PYTHONPATH instead? as you
describe the reason is the way it is called, using:
/path/to/python.exe script.py
since script.py is the argument it never goes near $PATH, but maybe
python still checks $PYTHONPATH ?
or if it is just called like:
/path/to/python.exe /path/to/script.py
then the cd wouldn't be needed any more.
note g.parser (at least in 6.x) removes all but the basename from
the original $0 for the second pass, IIRC.
So we can keep this solution until someone finds something better.
I'm not really worried about special cases to make d.rast3d work since
it's a private/internal script, but for other regular scripts if a cd
is done it's a bug: scripts which write out an output file would no
longer write them to the current directory the script was run from,
the files would either end up in scripts/ or get an error about no
permission to write to scripts/.
In line 540 of trunk/gui/wxpython/core/gcmd.py it seems that bug
exists. (i.e. for: d.polar db.out.ogr i.spectral m.proj r.in.wms
r.out.xyz r.pack v.out.gps v.pack, ...)
thanks,
Hamish
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2036: Failed watershed analysis on Grass
#2036: Failed watershed analysis on Grass --+- Reporter: mehmeto | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 6.4.4 Component: Raster | Version: 6.4.2 Resolution: fixed|Keywords: LFS, r.watershed Platform: MSWindows 7 | Cpu: x86-64 --+- Comment(by hamish): Hi, I tried in 6.4.3svn on Windows7 with Spearfish's elevation.10m with g.region at 2m, with r.watershed run using the '-m' flag and 4 output maps. It seemed to work fine that way. (region size ~ 7000x9500) mmetz: It's not so easy for Windows. You need to use the LFS API explicitely, i.e. off64_t, fseeko64(), ftello64, lseek64(), _stati64, etc. so more #ifdefs are needed in G_ftell() and G_fseek(), then more modules in g6 need to use those functions? (right now only r.in.bin does) If so it doesn't seem so hard. As a future maintenance goal, full 64bit file support on Windows for 6.4.x seems to me a rather important thing to work towards. (From both the grass code, msys, and osgeo4w ends) For trunk, the -m flag could become the default, in order to avoid tickets like this. mmph, I'm not a fan of that, rather just document the memory issues in the man page and have it go fast in the typical cases. (how much RAM will the average computer have when g7 is middle aged?) Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/2036#comment:20 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] compilation of grass on AIX 7.1
Markus Neteler wrote:
On Thu, Jul 18, 2013 at 8:48 PM, Glynn Clements
gl...@gclements.plus.com wrote:
...
Right; someone forgot the %{...%} around the comments:
--- lib/db/sqlp/sqlp.l (revision 57205)
+++ lib/db/sqlp/sqlp.l (working copy)
...
I have tried the updated SVN version (thanks!) but still get one:
-bash-3.2$ gmake
lex -t sqlp.l sqlp.yy.c
5: (Warning) No translation given - null string assumed
This should be fixed by r57254.
--
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] compilation of grass on AIX 7.1
On Tue, Jul 23, 2013 at 3:13 PM, Glynn Clements gl...@gclements.plus.com wrote: ... This should be fixed by r57254. Thanks, yes, confirmed: -bash-3.2$ gmake lex -t sqlp.l sqlp.yy.c 512/1200 nodes(%e), 1160/5000 positions(%p), 159/2500 (%n), 36582 transitions 506/1000 packed char classes(%k) 1769/5000 packed transitions(%a) 2336/9096 output slots(%o) Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
#2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI --+- Reporter: huhabla | Owner: grass-dev@… Type: enhancement | Status: new Priority: major | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: display, Python, multiprocessing |Platform: All Cpu: All | --+- Comment(by glynn): Replying to [comment:4 huhabla]: Your tests are comparing raw BMP with PNG (which uses zlib compression). If you aren't seeing a significant difference between those two, then the I/O overhead is negligible and performance is dictated by rendering speed. Regardless of whether I/O uses mmap() or write() and read(), disk transfer doesn't get involved unless memory pressure is so high that the data gets discarded from the cache before it is read. And if memory pressure is that high, disk transfer will get involved anyhow when the memory buffers are swapped out (and if memory pressure is high and you don't have swap, then you'll just get an out-of-memory failure). -- Ticket URL: http://trac.osgeo.org/grass/ticket/2033#comment:5 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] #2036: Failed watershed analysis on Grass
#2036: Failed watershed analysis on Grass --+- Reporter: mehmeto | Owner: grass-dev@… Type: defect | Status: closed Priority: normal | Milestone: 6.4.4 Component: Raster | Version: 6.4.2 Resolution: fixed|Keywords: LFS, r.watershed Platform: MSWindows 7 | Cpu: x86-64 --+- Comment(by mmetz): Replying to [comment:20 hamish]: mmetz: It's not so easy for Windows. You need to use the LFS API explicitely, i.e. off64_t, fseeko64(), ftello64, lseek64(), _stati64, etc. so more #ifdefs are needed in G_ftell() and G_fseek(), then more modules in g6 need to use those functions? (right now only r.in.bin does) If so it doesn't seem so hard. In g6, G_ftell() and G_fseek() do not have LFS on Windows because they use fseeko and ftello, not fseeko64 and ftello64. Besides, it does not make sense to enable LFS on module level if the libraries do not have LFS (which they do not have on wingrass 6). This is why LFS is globally enabled/disabled in g7 by configure which in turn creates config.h and Platform.make. Libraries and modules do no longer need any additional switches. As a future maintenance goal, full 64bit file support on Windows for 6.4.x seems to me a rather important thing to work towards. (From both the grass code, msys, and osgeo4w ends) Considering that ticket #1131 (Global LFS for wingrass) was opened 3 years ago and closed 10 days ago, which triggered you to ask it depends: is LFS working in MS Windows? i.e. has it been tested with the latest trunk code and passed? We shouldn't close tickets on assumptions. I suggest to 1) release the GRASS GIS 7 tech-preview asap, 2) leave wingrass LFS for g7. LFS is not so easy for Windows. Interesting that for a change you ask for low-level modification of g 6.4.x which I regard as too invasive. For trunk, the -m flag could become the default, in order to avoid tickets like this. mmph, I'm not a fan of that, rather just document the memory issues in the man page and have it go fast in the typical cases. I prefer modules to finish successfully, even if it takes some time, instead of first freezing the machine by going into swap, then failing with an out-of-memory error. (how much RAM will the average computer have when g7 is middle aged?) Replacing g7 with currently cutting edge software under development, this is an easy question. The answer has been the same for the last decades and will be the same for the foreseeable future: not enough, even for your average HPC. This is the reason for the design of the GRASS raster library since its inception and the reason for the existence of the segment and rowio libraries. I assume that the data available will continue to prevent processing all in RAM. For example, the SRTM data have been collected in February 2000, and as of today only few hardware + software combos exist that can process the whole SRTM dataset. I guess the reason why an all-in-RAM r.watershed version exists at all is that the all-in-RAM version was really slow and the disk-swap version was even slower. This has been changed, the current disk-swap version is magnitudes faster than the pre g-6.4 all-in-RAM version. Anyway, as long as wingrass is compiled as a 32 bit application, it can only access the amount of RAM available to a 32 bit application with correspondingly sized pointers. Another reason to use the low-memory module versions by default and release the g7 tech preview asap. -- Ticket URL: https://trac.osgeo.org/grass/ticket/2036#comment:21 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] r57119 v.pack: move db and proj file to the root, preparation for packaging multiple maps
Please update v.unpack accordingly. Thanks, Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r57119 v.pack: move db and proj file to the root, preparation for packaging multiple maps
Hi, 2013/7/23 Markus Metz markus.metz.gisw...@gmail.com: Please update v.unpack accordingly. it remained unfinished from GRASS Community Sprint. Sorry, I will fix it ASAP. Martin -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G6.4.2: gis.m issue on Ubuntu
On Tue, Jul 23, 2013 at 11:52 AM, Hamish hamis...@yahoo.com wrote: MarkusN: I got a request from an Ubuntu user related to gis.m/tcltk/sqlite but have no idea how to help: On Tue, Jul 23, 2013 at 10:01 AM, wrote: I am trying to run Grass 6.4 following instructions in chapter 3 of your book using the nc_spm_08 downloaded from your site. I am using Ubuntu 12.10 64-bit, with Grass 6.4 installed from the Ubuntu Software Center, and with SQLite 3. I get this message when trying to run - gis.m GRASS 6.4.2 (nc_spm_08):~ gis.m GRASS 6.4.2 (nc_spm_08):~ error reading package index file /usr/lib/sqlite/pkgIndex.tcl: expected version number but got 0.0. ... /usr/lib/sqlite/pkgIndex.tcl comes from the libsqlite-tcl package, but that is not used or required by the grass package(s) AFAIK. I just tried GIS.m in an Lubuntu 13.04 VM and gis.m worked ok. I did get the same error message if I manually installed the libsqlite-tcl package (even with dbf as the db.connect default), but other than the message in the terminal gis.m seemed to work ok. So I'd guess an error in the other package and grass users can ignore it? I just received an update: The issue got fixed in Ubuntu 12.10 https://bugs.launchpad.net/ubuntu/+source/sqlite/+bug/996644 So it was not a GRASS bug... good to know. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r57119 v.pack: move db and proj file to the root, preparation for packaging multiple maps
Hi, 2013/7/23 Markus Metz markus.metz.gisw...@gmail.com: Please update v.unpack accordingly. I checked `v.unpack`. What exactly is not working? I haven't found any problem related to db [1] and proj file [2]. Martin [1] http://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.unpack/v.unpack.py#L109 [2] http://trac.osgeo.org/grass/browser/grass/trunk/scripts/v.unpack/v.unpack.py#L101 -- Martin Landa landa.martin gmail.com * http://geo.fsv.cvut.cz/~landa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
Today could be a great rlease-6.4.3-day :) we are so close to 30 July that we could wait a week and release in the same day of his born :-) +1 - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/GRASS-6-4-3-release-planning-tp4995930p5068316.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G6.4.2: gis.m issue on Ubuntu
User wrote: I am using Ubuntu 12.10 64-bit, with Grass 6.4 installed from the Ubuntu Software Center, and with SQLite 3. I get this message when trying to run - gis.m GRASS 6.4.2 (nc_spm_08):~ gis.m GRASS 6.4.2 (nc_spm_08):~ error reading package index file /usr/lib/sqlite/pkgIndex.tcl: expected version number but got 0.0. Hamish: /usr/lib/sqlite/pkgIndex.tcl comes from the libsqlite-tcl package, but that is not used or required by the grass package(s) AFAIK. I just tried GIS.m in an Lubuntu 13.04 VM and gis.m worked ok. I did get the same error message if I manually installed the libsqlite-tcl package ... So I'd guess an error in the other package and grass users can ignore it? Markus: I just received an update: The issue got fixed in Ubuntu 12.10 https://bugs.launchpad.net/ubuntu/+source/sqlite/+bug/996644 but the user reported it from 12.10, and I saw the same in 13.04. I think the seems to work in 12.10 in the ubuntu ticket was not correct, and the earlier debian bug it linked to was from 2009. So it was not a GRASS bug... good to know. Right, to be continued elsewhere.. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS 6.4.3 release planning
On 23 July 2013 12:30, Hamish hamis...@yahoo.com wrote: Markus Neteler wrote: Today could be a great rlease-6.4.3-day :) since on the 24th we are +2 weeks since RC4 without any major bugs being reported I think we are ok to release any time now. I don't know about anyone else but I can't say I've really tested rc4 very much beyond making sure the debian package building still works. too busy :-/ Luca: we are so close to 30 July that we could wait a week and release in the same day of his born :-) It would be a nice little something for the release announcement too. :) Speaking of which, do we want to write the formal release announcement + 2 paragraph abstract as we have for earlier releases in grass-web svn, or do something different now? I think we need something higher-level than the trac wiki's detailed changelog highlights, and that it should be done before release. I might try a first draft tomorrow if no one else has started on it. please Hamish start it you could use some pad Also MarkusN's visual changelog idea is nice, the trac news items for the earlier RCs should give some ideas. anyone like to start on screenshots for that? maybe host/compose in the more thumbnail- friendly/prettier grass mediawiki? markus we could also create a video like this http://www.youtube.com/watch?feature=player_embeddedv=suyDqmGXoWk best, Hamish -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
#2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
--+-
Reporter: huhabla | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: major | Milestone: 7.0.0
Component: wxGUI | Version: svn-trunk
Keywords: display, Python, multiprocessing |Platform: All
Cpu: All |
--+-
Comment(by huhabla):
I have improved the benchmark script and implemented PIL based and
g.pnmcomp image composition (without transparency). Now png, bmp and ppm
images are created and mmap is enabled for bmp images. Time is measured
for the whole rendering/composition process and separately for the
composition.
My test system is a core-i5 2410M with 8GB RAM and 320Gig HD running
Ubuntu 12.04 LTS.
It seems to me that creating raw bmp images without mmap enabled shows the
best performance for the PNG and Cairo driver. Maybe i did something
wrong, but the use of mmap shows no obvious benefit?
The png compression slows the rendering significantly down and is IMHO not
well suited as image exchange format in the rendering/composition process.
Running the render processes in parallel shows only for the 4096x4096
pixel size images a significant benefit.
Any suggestions to improve the benchmark? Does my setup produce reasonable
results?
Here the script:
{{{
# -*- coding: utf-8 -*-
import os
import time
import Image
import wx
from grass.pygrass import modules
parallel = [True, False]
drivers = [png, cairo]
bitmaps = [png, bmp, ppm]
mmap_modes = [FALSE, TRUE]
sizes = [1024, 4096]
def render_image(module, driver=png, pngfile=test.png,
size=4096, mapped=TRUE):
os.putenv(GRASS_RENDER_IMMEDIATE, %s%driver)
os.putenv(GRASS_PNGFILE, %s%pngfile)
os.putenv(GRASS_WIDTH, %i%size)
os.putenv(GRASS_HEIGHT, %i%size)
os.putenv(GRASS_PNG_MAPPED, %s%mapped)
module.run()
def composite_images(files, bitmap, mode, size):
start = time.time()
if bitmap == ppm:
filename = output
filename += .ppm
modules.Module(g.pnmcomp, input=files, width=size, height=size,
output=filename)
# Load the image as wx image for visualization
img = wx.Image(filename, wx.BITMAP_TYPE_ANY)
os.remove(filename)
else:
images = []
size = None
for m in files:
im = Image.open(m)
images.append(im)
size = im.size
comp = Image.new('RGB', size)
for im in images:
comp.paste(im)
wxImage = wx.EmptyImage(*comp.size)
wxImage.SetData(comp.convert('RGB').tostring())
return (time.time() - start)
def main():
# Set the region
modules.Module(g.region, rast=elevation, flags=p)
for finish in parallel:
if finish:
print(*** Serial runs)
else:
print(*** Parallel runs)
print(Run\tSize\tDriver\tBitmap\tmmap\trender\tcomposite)
# Setup the modules
rast = modules.Module(d.rast, map=elevation, run_=False,
quiet=True, finish_=False)
vectB = modules.Module(d.vect, map=streams, width=1,
color=blue,
fcolor=aqua, type=[area,line],
run_=False, quiet=True, finish_=finish)
vectA = modules.Module(d.vect, map=roadsmajor, width=2,
run_=False, quiet=True, finish_=finish)
count = 0
for size in sizes:
for driver in drivers:
for bitmap in bitmaps:
for mode in mmap_modes:
# Skip mmap for non-bmp files
if mode == TRUE and bitmap != bmp:
continue
start = time.time()
count += 1
files = []
rast_file = rast.%s%(bitmap)
vectA_file=vectA.%s%(bitmap)
vectB_file=vectB.%s%(bitmap)
files.append(rast_file)
files.append(vectA_file)
files.append(vectB_file)
render_image(rast, driver=driver,
pngfile=rast_file,
Re: [GRASS-dev] [GRASS GIS] #2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI
#2033: Moving g.pnmcomp to lib/display to improve render performance of wxGUI --+- Reporter: huhabla | Owner: grass-dev@… Type: enhancement | Status: new Priority: major | Milestone: 7.0.0 Component: wxGUI | Version: svn-trunk Keywords: display, Python, multiprocessing |Platform: All Cpu: All | --+- Comment(by glynn): Replying to [comment:6 huhabla]: It seems to me that creating raw bmp images without mmap enabled shows the best performance for the PNG and Cairo driver. Maybe i did something wrong, but the use of mmap shows no obvious benefit? Using mmap() in the driver is probably not that significant in this context. It's more useful when GRASS_PNG_READ=TRUE, the resolution is high, and the rendering is simple and/or limited to a portion of the image. In that situation, mmap() eliminates the read() as well as the write(), and only the modified portion needs to be read and written. Another area where it matters is with e.g. wximgview.py (and its predecessors), as it's safe to read a BMP image which is being modified using mmap(), whereas doing the same thing to a file which is being written out with write() runs the risk reading a truncated file. Other than that, the performance difference between using mmap() and read() on the read side boils down to mmap() avoiding a memcpy(). The extent to which that matters depends upon what else you're doing with the data. For wxGUI, it's probably a drop in the ocean. Any suggestions to improve the benchmark? Does my setup produce reasonable results? There isn't anything I'd particularly take issue with. However: 1. With the cairo driver, BMP files use pre-multiplied alpha (because that's what cairo uses internally), whereas PPM/PGM output includes an un- multiplication step. So depending upon your perspective, the cairodriver benchmarks are rigged against PPM or in favour of BMP. 2. Producing separate results for PPM with g.pnmcomp and PPM with PIL would provide a clearer comparison between the two compositing options and the various formats. -- Ticket URL: http://trac.osgeo.org/grass/ticket/2033#comment:7 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
