Re: [GRASS-dev] GRASS manual layout overhaul: less redundancy, more compact
Markus wrote: I have modified tools/build_html_index.sh Hamish: re. r36022, d.font.freetype and d.text.freetype should not be on the no-G_parser() list. perhaps they are failing to run/build on the server for some other reason? Markus: Mhh, no idea. They has only the name of the other (new) module but no description. here they correctly have name:description in the display modules list like any other script. Here it fails. what does 'd.font.freetype --help' say on that machine? Does the build use freetype compile flag? are d.font and d.text there? the scripts are just wrappers that do like: exec d.text $@ shrug. anyway, they aren't active; so we shouldn't advertize them; so I've added them to the ignore list in the script. problem solved ;) g.manual still works if anyone is curious. Well, I guess that the addition to the list in tools/build_html_index.sh is rather harmless (but if you don't think so we can revert that). that script is enough of an ugly PITA to follow without more noise... Hamish ps- what's up with r.li.daemon? the html page is on the no-G_parser() list; the Makefile says it's what becomes libgrass_rli.so, and main.c is named main.c.unused? former frontend to the library or stand-alone version? ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.in.ogr realloc problem
Yann Chemin wrote: Hello list, (GRASS SVN of this morning) Importing a vector of 400Mb (GADM http://biogeo.berkeley.edu/gadm/, country level only) v.in.ogr broke with the following error message: - Break polygons: ERROR: G_realloc: unable to allocate 652680036 bytes at break_polygons.c:188 (Wed Feb 25 10:54:21 2009) Command finished (2163 sec) - The Desktop PC has 8Gb RAM with Debian Sid (sidux) updated this morning too... Any idea how I could let the memory allocation do its job? Same like ticket #494? I got this shapefile http://biogeo.berkeley.edu/gadm/data/gadm_v0dot9_shp.zip and imported the whole thing, all levels, with v.in.ogr, grass65. No problems. Cleaning with v.in.ogr was successful, result is a topologically clean vector. I could not reproduce the error. The G_realloc() error in Vect_break_polygons() remains a mystery. Sorry for no help, Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #500: GUI menu item to swtich GUIs
#500: GUI menu item to swtich GUIs --+- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: major| Milestone: 6.4.0 Component: default | Version: 6.4.0 RCs Resolution: |Keywords: gui Platform: All | Cpu: All --+- Comment (by hamish): back/ported to relbr64 and trunk in r36093, r36094; weirdness remains: I can't change it from the d.m GUI or from the command prompt with --ui using g.change.gui.sh. But it works fine from from gis.m and the command line with an argument. In d.m I just get a red X in the output tab. oh well, it works in d.m if I pass it plain g.gui instead of the simplified g.change.gui.sh wrapper script (done in r36095, r36096), and I doubt anyone will try `$GISBASE/etc/gui/scripts/g.change.gui.sh` very often from the CLI as g.gui is somewhat easier to type. shrug. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/500#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] archive of old RT bug tracker (2000-2007)
On 25 Feb 2009, at 04:02, Hamish wrote: TODO: ... * look through the 391 open and stalled bugs in the RT list and open new reports for still-valid issues in the new trac system. If we can find a volunteer who can still logon then we can close some of those as resolved+done or resolved+ported to put history right and lessen the noise. I found my login, and confirmed it works. I've closed a few that looked obvious to me. I can work (probably slowly) on more, but for many I would have to request input from the list to double-check resolved/need to be ported status. Poking my head up after long absence, Scott Mitchell ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.proj from GaussBoaga to UTM
Hi, using command r.proj to reproject a raster topographic map from a Gauss Boaga location (EPSG:3003) to a UTM location (EPSG:32632) I obtain a shift error of the reprojected map of about 40-50m in south direction. It is related to the towgs84 bursa wolf parameters? Is this a known bug? I'm using Grass 6.3.0-2 on a Mac Intel with Moretti's Build binaries. Thank you Christian ~ Christian Tiso, collaborator Department of Civil and Environmental Engineering University of Trento via Mesiano 77, I-38050 Trento, ITALY http://www.ing.unitn.it/dica phone: +39 0461 882610 fax: +39 0461 882672 E-mail: christian.t...@ing.unitn.it ~ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #507: CSV output option for r.report
#507: CSV output option for r.report -+-- Reporter: dylan| Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: 6.5.0 Component: Raster | Version: svn-develbranch6 Keywords: r.report |Platform: All Cpu: All | -+-- It would be convenient to have the option of printing out long reports from r.report in CSV format. A simple flag option could be used to signal CSV output. It looks like modification from [http://trac.osgeo.org/grass/browser/grass/branches/develbranch_6/raster/r.report/prt_report.c#L156 here] would do the trick. Could be as simple as using a variable for the spacer, and adding a check for printing the '..' between columns. -- Ticket URL: http://trac.osgeo.org/grass/ticket/507 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] large vector problems
Dear Markus, Markus and Jens, My MacBook survived the burn-in test :-) After 29 hours under full load, alternating processor and disk access limited, I got my mega-vector file cleaned. Thank you for the support and suggestions to solve my problems with the large vector cleaning operation! I did recompile the 6.5dev version on Linux, no large file support, no 64bit, used the standard pre-compiled binary and devel packages from the suse repositories, so nothing special at all. A last test showed me that the 6.4RC3 version worked too. Probably 2 effects were mixed that causes my problems: -lack of memory in the first place, and -the database was on a Samba share (which works perfectly well, unless with these mega vector datasets) Why it doesn't work on the Mac _natively_ is a still unanswered question. Maybe some built-in memory limit? At least my VMWare Suse did the job. Although the dataset was cleaned, files of this size are virtually impossible to handle, especially as standard querying, extract and overlay operations with raster datasets simply take too much time. The fact that ArcINFO workstation (also a topological GIS) is an order of magnitude faster and not so memory hungry makes me believe that there should be a way to improve speed on this kind of operations, but unfortunately I'm not a algorythm guru... I'll post a few related issues with mega files that makes working with them very difficult. I'll post them as (separate) enhancements on trac, as they are in my opinion of major importance: -selecting a large vector map from a dropdown box in the wxPython GUI takes a long time -renaming this vector took 25 minutes (PostgreSQL access!) -v.extract is also incredibly slow -removing a vector file with an unreachable PostgreSQL database link does not work, not even in force mode -v.what consuming several GB of RAM only for querying a large vector map?? -v.rast.stats suffers from setting masks, extracting polygons and querying, not usefull anymore for vector files this size, this is a particular slow operations I'll put my shell script to create a new mapset and automatically generate a postgresql schema somewhere on the wiki. With kind regards, Wouter Boasson (MSc) Geo-IT Research and Coordination RIVM - National Institute for Public Health and the Environment Expertise Centre for Methodology and Information Services Contact information --- RIVM VenZ/EMI, Pb 86 t.a.v. dhr. Drs. Wouter Boasson Postbus 1 3720 BA Bilthoven T +31(0)302748518 M +31(0)611131150 F +31(0)302744456 E wouter.boas...@rivm.nl mo - th ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.proj from GaussBoaga to UTM
On Wed, Feb 25, 2009 at 5:02 PM, Christian Tiso christian.t...@ing.unitn.it wrote: Hi, using command r.proj to reproject a raster topographic map from a Gauss Boaga location (EPSG:3003) to a UTM location (EPSG:32632) I obtain a shift error of the reprojected map of about 40-50m in south direction. It is related to the towgs84 bursa wolf parameters? Is this a known bug? I'm using Grass 6.3.0-2 on a Mac Intel with Moretti's Build binaries. please post g.proj -w I assume that the datum definition is lacking or wrong (towgs84). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] GRASS manual layout overhaul: less redundancy, more compact
On Wed, Feb 25, 2009 at 10:47 AM, Hamish hamis...@yahoo.com wrote: Markus wrote: I have modified tools/build_html_index.sh Hamish: re. r36022, d.font.freetype and d.text.freetype should not be on the no-G_parser() list. perhaps they are failing to run/build on the server for some other reason? Markus: Mhh, no idea. They has only the name of the other (new) module but no description. here they correctly have name:description in the display modules list like any other script. Here it fails. what does 'd.font.freetype --help' say on that machine? d.font.freetype --help ... Usage: d.font [-lL] [font=string] [path=string] [charset=string] [--verbose] [--quiet] Does the build use freetype compile flag? yes are d.font and d.text there? yes the scripts are just wrappers that do like: exec d.text $@ shrug. anyway, they aren't active; so we shouldn't advertize them; so I've added them to the ignore list in the script. problem solved ;) g.manual still works if anyone is curious. Perfect :) Well, I guess that the addition to the list in tools/build_html_index.sh is rather harmless (but if you don't think so we can revert that). that script is enough of an ugly PITA to follow without more noise... Hamish ps- what's up with r.li.daemon? the html page is on the no-G_parser() list; the Makefile says it's what becomes libgrass_rli.so, and main.c is named main.c.unused? former frontend to the library or stand-alone version? In the directory libgrass_rli.6.5.svn.so is used. I assume that main.c.unused serves as a template (maybe better name it as such?). Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] change in make for Mac causes errors in GRASS 6.5 compilation
Hi, Something changed since 8 February in the make files for Mac that is causing compiling GRASS 6.5 to fail in several places. It has to do with TclTk. I get the following errors and all seem to be related to the same thing. Errors in: /Users/cmbarton/grass_dev/grass6_src/lib/form /Users/cmbarton/grass_dev/grass6_src/db/drivers/ogr /Users/cmbarton/grass_dev/grass6_src/raster/r.watershed/front /Users/cmbarton/grass_dev/grass6_src/vector/v.digit /Users/cmbarton/grass_dev/grass6_src/visualization/nviz For ../lib/form, the detailed error is... cmb-MBP-2:grass6_src cmbarton$ cd /Users/cmbarton/grass_dev/grass6_src/ lib/form cmb-MBP-2:form cmbarton$ make gcc -L/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/ lib -arch i386 -Os -arch i386 -Os -o /Users/cmbarton/grass_dev/ grass6_src/dist.i386-apple-darwin9.6.0/etc/form/form OBJ.i386-apple- darwin9.6.0/form.o -lgrass_dbmiclient -lgrass_dbmibase -lgrass_gis - lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz - lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis - lgrass_datetime -lz -lgrass_datetime \ TCLTKLIBS = -framework Tcl -framework Tk -lz i686-apple-darwin9-gcc-4.0.1: TCLTKLIBS: No such file or directory i686-apple-darwin9-gcc-4.0.1: =: No such file or directory make: *** [/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple- darwin9.6.0/etc/form/form] Error 1 Other modules give similar detailed errors, referring to TCLTKLIBS In order to compile GRASS for TclTk aqua 8.5, I have to manually change platform make to have the line ... TCLTKLIBS = -framework Tcl -framework Tk Somehow this line is now causing problems. (I know that William has a symlink to aqua TclTk, but I cannot do this because it makes R-Commander fail. I need the x11 version there). So is there a new procedure? Is this a bug? Thanks Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #506: v.out.ascii segfault when exporting columns from the attribute table
On Tuesday 24 February 2009, GRASS GIS wrote:
#506: v.out.ascii segfault when exporting columns from the attribute table
--+
- Reporter: dylan| Owner: grass-dev@lists.osgeo.org Type:
defect | Status: new
Priority: major| Milestone: 6.5.0
Component: default | Version: svn-develbranch6
Resolution: |Keywords: v.out.ascii
Platform: Unspecified | Cpu: Unspecified
--+
- Comment (by hamish):
works for me.
{{{
/home/dylan/grass/spearfish60/PERMANENT/dbf//bugsites.dbf
}}}
I don't think it makes a difference, but //bugsites.dbf ?
Hamish
Yeah that did look kind strange... is that something I can fix with
db.connect?
Cheers,
Dylan
--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] change in make for Mac causes errors in GRASS 6.5 compilation
On Feb 25, 2009, at 6:16 PM, William Kyngesburye wrote: On Feb 25, 2009, at 5:29 PM, Michael Barton wrote: cmb-MBP-2:grass6_src cmbarton$ cd /Users/cmbarton/grass_dev/ grass6_src/lib/form cmb-MBP-2:form cmbarton$ make gcc -L/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple- darwin9.6.0/lib -arch i386 -Os -arch i386 -Os -o /Users/ cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/etc/form/ form OBJ.i386-apple-darwin9.6.0/form.o -lgrass_dbmiclient - lgrass_dbmibase -lgrass_gis -lgrass_datetime -lz -lgrass_gis - lgrass_datetime -lz -lgrass_dbmibase -lgrass_gis - lgrass_datetime -lz -lgrass_gis -lgrass_datetime -lz - lgrass_datetime \ TCLTKLIBS = -framework Tcl -framework Tk -lz i686-apple-darwin9-gcc-4.0.1: TCLTKLIBS: No such file or directory i686-apple-darwin9-gcc-4.0.1: =: No such file or directory make: *** [/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple- darwin9.6.0/etc/form/form] Error 1 Other modules give similar detailed errors, referring to TCLTKLIBS In order to compile GRASS for TclTk aqua 8.5, I have to manually change platform make to have the line ... TCLTKLIBS = -framework Tcl -framework Tk Somehow this line is now causing problems. I don't see any recent changes to the lib/form makefile that would do this. Somehow the whole line is getting inserted for $ (TCLTKLIBS) in the makefile. Almost like it's set in Platform.make like: TCLTKLIBS = TCLTKLIBS = -framework Tcl -framework Tk I'm blind. I guess I don't have even time to compile this correctly. Thanks for spotting this silly error. Michael ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] r.watershed not compiling
OK. Now that William has helped catch a stupid error on my part, I can report a real problem with compilation on the Mac. The new improved r.watershed is not compiling. Here is the error. Finished compilation: Wed Feb 25 20:40:50 MST 2009 make: *** [default] Error 1 cmb-MBP-2:grass6_src cmbarton$ cd /Users/cmbarton/grass_dev/grass6_src/ raster/r.watershed/front cmb-MBP-2:front cmbarton$ make gcc -I/Users/cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/ include -arch i386 -Os -DPACKAGE=\grassmods\ -I/Users/ cmbarton/grass_dev/grass6_src/dist.i386-apple-darwin9.6.0/include -o OBJ.i386-apple-darwin9.6.0/main.o -c main.c main.c: In function ‘main’: main.c:244: error: syntax error before ‘’ token make: *** [OBJ.i386-apple-darwin9.6.0/main.o] Error 1 cmb-MBP-2:front cmbarton$ I am very much looking forward to trying this in GRASS 6.5 and appreciate the effort to backport the multiflow direction improvements. I hope that this issue can be corrected. Michael___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.watershed not compiling
That was it. Thanks. Michael On Feb 25, 2009, at 9:11 PM, Hamish wrote: Michael wrote: main.c: In function ‘main’: main.c:244: error: syntax error before ‘’ token make: *** [OBJ.i386-apple-darwin9.6.0/main.o] Error 1 check for = in the source code from a svn merge conflict. Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] fixing lintian errors
Hi, now that grass 6.4rc3 has been thrown at debain's autobuilders a Lintian hygiene report is available: http://lintian.debian.org/maintainer/pkg-grass-de...@lists.alioth.debian.org.html#grass http://packages.qa.debian.org/g/grass.html of interest are: * the nviz2.2's tcl scripts being installed as executable; * etc/[dm|gm]/tksys.tcl and etc/gm/animate.tcl not quite sure if they are executable shell scripts or Tcl or some hybrid beast; * gui/wxpython/scripts/Makefile gets installed by mistake and a whole bunch of man page build warnings/errors. There is a complaint about gui/scripts/*.py shebanging python instead of python2.5 (matching the python pkg that the grass pkg depends on) That is for DebianGIS to patch as needed, but I guess we should be respecting what the user gave for $GRASS_PYTHON. I also notice that the main GRASS man page has lost the LOCATION/MAPSET text from the synopsis for some reason: NAME grass65 - The GRASS startup program SYNOPSIS grass65 [-] [-v] [-h | -help | --help] [-text | -gui | -tcltk | -wxpython]] [[[/]/] ] Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #508: hardcoded /dev/null
#508: hardcoded /dev/null
+---
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: 6.4.0 RCs
Keywords: wingrass /dev/null |Platform: MSWindows XP
Cpu: x86-32 |
+---
Hi,
{{{
imagery/i.cluster/main.c
raster/r.out.mpeg/main.c
raster/r.topmodel/misc.c
lib/gis/opencell.c G__open_cell_old()
}}}
all hardcode to /dev/null which doesn't exist on Windows.
perhaps
{{{
#ifdef __MINGW32__
#define NULLDEV NUL:
#else
#define NULLDEV /dev/null
#endif
}}}
or somesuch? (no idea)
d.ask and XDRIVER do too, but they don't work on MS Windows.
Hamish
--
Ticket URL: https://trac.osgeo.org/grass/ticket/508
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] [GRASS GIS] #509: wxgui: startup menu crunched on small display
#509: wxgui: startup menu crunched on small display +--- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: defect | Status: new Priority: minor | Milestone: 6.4.0 Component: wxGUI | Version: 6.4.0 RCs Keywords: |Platform: MSWindows 2K Cpu: x86-32 | +--- Hi, this is using 6.4.0rc3 from OSGeo4W on a ClassmatePC (mini-notebook) running Windows XP. The display on this thing is a 1024x600 9 LCD. the bottom buttons of the wx GUI startup get crunched up, especially when the taskbar is not in auto-hide mode (attached screenshot). It is still a bit crunched up if it has the full screen height to work with, but it is still overlapping the horizontal slider by 1-2mm. the tcl/tk one looks fine. also I notice the enter grass button is not greyed out when no mapset is selected, etc. as is the case with the tcl/tk startup gui. and you thought 800x600 was long dead Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/509 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] Re: [GRASS GIS] #500: GUI menu item to swtich GUIs
On Feb 25, 2009, at 6:56 PM, grass-dev-requ...@lists.osgeo.org grass-dev-requ...@lists.osgeo.org
wrote:
Date: Thu, 26 Feb 2009 01:56:34 -
From: GRASS GIS t...@osgeo.org
Subject: [GRASS-dev] Re: [GRASS GIS] #500: GUI menu item to swtich
GUIs
To: undisclosed-recipients:;
Message-ID: 049.a7d07addcd658c139b1cd756288a1...@osgeo.org
Content-Type: text/plain; charset=utf-8
#500: GUI menu item to swtich GUIs
--
+-
Reporter: hamish | Owner: grass-dev@lists.osgeo.org
Type: enhancement | Status: new
Priority: major| Milestone: 6.4.0
Component: default | Version: 6.4.0 RCs
Resolution: |Keywords: gui
Platform: All | Cpu: All
--
+-
Comment (by hamish):
I tried the following patch, it seemed to work from the commandline
with
--ui, but still not from d.m.
{{{
Index: gui/scripts/g.change.gui.sh
===
--- gui/scripts/g.change.gui.sh (revision 36060)
+++ gui/scripts/g.change.gui.sh (working copy)
@@ -41,6 +41,11 @@
exit 1
fi
+if [ ! -x `which $(basename $0)` ] ; then
+PATH=$PATH:$GISBASE/etc/gui/scripts
+export PATH
+fi
+
if [ $1 != @ARGS_PARSED@ ] ; then
exec g.parser $0 $@
fi
}}}
???
Running it from the wxPython GUI still needs to be tested by someone
please. Config - Working enviro - Change default GUI
Also, I was thinking it could be useful to add an entry after 'Help-
About
system' like 'Help-Show system environment' which would run set and
dump the results to the Output window. It would help in debugging.
Hamish
This is actually much easier just to build into each GUI menu than to
try and create a script that works in multiple ways and runs across
multiple platforms.
I just updated the tcltk GUI with a new menu item (under the configure
menu) to switch the default gui to wxpython in GRASS 6.5 svn. Please
check to see that it works OK across platforms. It should, but testing
is needed before it is ported to 6.4 RC4. Martin or I can add an
equivalent to the wxPython menu soon. Sorry that I've been too tied up
to help with this sooner.
Michael
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] large vector problems
Wouter Boasson wrote: Dear Markus, Markus and Jens, My MacBook survived the burn-in test :-) After 29 hours under full load, alternating processor and disk access limited, I got my mega-vector file cleaned. Thank you for the support and suggestions to solve my problems with the large vector cleaning operation! Glad to hear that it worked in the end! Although the dataset was cleaned, files of this size are virtually impossible to handle, especially as standard querying, extract and overlay operations with raster datasets simply take too much time. There are ways to improve both speed and memory consumption. There are hints in the source code and I have some ideas, but this is no easy task. The grass vector model is complex, changes need a lot of testing before they can be applied. And there are not that many developers working on the core grass vector libraries... This will only happen in grass7, I guess. Hopefully sometime this year... I'll post a few related issues with mega files that makes working with them very difficult. I'll post them as (separate) enhancements on trac, as they are in my opinion of major importance: -selecting a large vector map from a dropdown box in the wxPython GUI takes a long time -renaming this vector took 25 minutes (PostgreSQL access!) -v.extract is also incredibly slow -removing a vector file with an unreachable PostgreSQL database link does not work, not even in force mode -v.what consuming several GB of RAM only for querying a large vector map?? Some of the above operations could be improved, but it will take some time. -v.rast.stats suffers from setting masks, extracting polygons and querying, not usefull anymore for vector files this size, this is a particular slow operations Try the example script in the help page of r.univar.zonal, available in the grass-addons: http://grass.osgeo.org/wiki/GRASS_AddOns#r.univar.zonal It should be easy to modify it to your needs, it does something very similar to v.rast.stats, only faster. Best regards, Markus M ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] r.proj from GaussBoaga to UTM
Thank you markus, you're right, there's no datum definition: GRASS 6.3.0 (fassaGB):~ g.proj -w PROJCS[Transverse Mercator, GEOGCS[international, DATUM[unknown, SPHEROID[International_1924,6378388,297]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433]], PROJECTION[Transverse_Mercator], PARAMETER[latitude_of_origin,0], PARAMETER[central_meridian,9], PARAMETER[scale_factor,0.9996], PARAMETER[false_easting,150], PARAMETER[false_northing,0], UNIT[Meter,1]] but this is beacause I created a new location from the GUI start panel of GRASS by choosing the EPSG code button and selectiong the 3003 code which should be the one related to the GaussBoaga, Rome 1940 Monte Mario projections. Where am I wrong? It is not possible to create such a new location only by choosing the EPSG code? Thank you for helping me. Christian Tiso Il giorno 26/feb/09, alle ore 00:19, Markus Neteler ha scritto: On Wed, Feb 25, 2009 at 5:02 PM, Christian Tiso christian.t...@ing.unitn.it wrote: Hi, using command r.proj to reproject a raster topographic map from a Gauss Boaga location (EPSG:3003) to a UTM location (EPSG:32632) I obtain a shift error of the reprojected map of about 40-50m in south direction. It is related to the towgs84 bursa wolf parameters? Is this a known bug? I'm using Grass 6.3.0-2 on a Mac Intel with Moretti's Build binaries. please post g.proj -w I assume that the datum definition is lacking or wrong (towgs84). Markus ~ Christian Tiso, collaborator Department of Civil and Environmental Engineering University of Trento via Mesiano 77, I-38050 Trento, ITALY http://www.ing.unitn.it/dica phone: +39 0461 882610 fax: +39 0461 882672 E-mail: christian.t...@ing.unitn.it ~ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] large vector problems
Hello, reading this thread, and being sometimes concerned with large vector files (associated with big related tables), I wonder if it's worth manually creating indexes (on cat field) : can it be a effective way to speed up queries, or is the kink elsewhere, at the geometric level (data handled by grass, not the linked DBMS) ? Thank you, Vincent Le jeudi 26 février 2009 à 08:42 +0100, Markus Metz a écrit : Wouter Boasson wrote: Dear Markus, Markus and Jens, My MacBook survived the burn-in test :-) After 29 hours under full load, alternating processor and disk access limited, I got my mega-vector file cleaned. Thank you for the support and suggestions to solve my problems with the large vector cleaning operation! Glad to hear that it worked in the end! Although the dataset was cleaned, files of this size are virtually impossible to handle, especially as standard querying, extract and overlay operations with raster datasets simply take too much time. There are ways to improve both speed and memory consumption. There are hints in the source code and I have some ideas, but this is no easy task. The grass vector model is complex, changes need a lot of testing before they can be applied. And there are not that many developers working on the core grass vector libraries... This will only happen in grass7, I guess. Hopefully sometime this year... I'll post a few related issues with mega files that makes working with them very difficult. I'll post them as (separate) enhancements on trac, as they are in my opinion of major importance: -selecting a large vector map from a dropdown box in the wxPython GUI takes a long time -renaming this vector took 25 minutes (PostgreSQL access!) -v.extract is also incredibly slow -removing a vector file with an unreachable PostgreSQL database link does not work, not even in force mode -v.what consuming several GB of RAM only for querying a large vector map?? Some of the above operations could be improved, but it will take some time. -v.rast.stats suffers from setting masks, extracting polygons and querying, not usefull anymore for vector files this size, this is a particular slow operations Try the example script in the help page of r.univar.zonal, available in the grass-addons: http://grass.osgeo.org/wiki/GRASS_AddOns#r.univar.zonal It should be easy to modify it to your needs, it does something very similar to v.rast.stats, only faster. Best regards, Markus M ___ 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
