[GRASS-dev] v.out.ogr: speed up
Hi, I have added OGR transactions support to v.out.ogr to speed up export to OGR datasources which supports transactions. Using `geodetic_pts` from `nc_spm_08` (~30k points), exporting to PostGIS $ time v.out.ogr dsn=PG:dbname=pgis_grass input=geodetic_pts format=PostgreSQL type=point --o Before: real4m37.795s user0m8.201s sys 0m4.752s After (r45912): real0m11.499s user0m3.856s sys 0m1.728s Available in GRASS 6.5+, backport marked for 6.4.2. Testing welcomed. 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
[GRASS-dev] Re: [GRASS GIS] #181: tac command missing in OSX
#181: tac command missing in OSX +--- Reporter: kyngchaos | Owner: hamish Type: defect | Status: closed Priority: minor | Milestone: 6.4.1 Component: Bash | Version: 6.3.0 Resolution: fixed |Keywords: v.in.garmin, v.in.mapgen, v.in.lines Platform: MacOSX | Cpu: Unspecified +--- Changes (by martinl): * component: Default = Bash -- Ticket URL: https://trac.osgeo.org/grass/ticket/181#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] G_error()
Hi all, I would propose adding non-fatal error reporting function to gislib. New G_error() would act in the similar way as G_fatal_error() except of calling exit(). Currently if you want to report error message without calling exit() you need to use G_warning() instead. 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] r.what/d.what.rast on the map display
Hi, 2011/4/8 roberto marzocchi roberto.marzoc...@gmail.com anyone have esperience of how running r.what or d.what rast on the *Map Display* from the shell? I am developing an user friendly interface for a GRASS script and I want digitalize two points without using v.digit, but in a more user-friendly (perhaps...) procedure. are you referring to wxGUI Map Displays? Currently there is quite incomplete support for scripting. The goal is to implement d.mon for wxGUI Map Displays in GRASS 7. Anyway there some scripts available, currently unmaintained [1] ... Martin [1] http://trac.osgeo.org/grass/browser/grass/trunk/gui/scripts/p.mon.py -- 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
[GRASS-dev] GRASS 7 wxGUI typos ?
In the grass7 wxGUI there are two instances of parentframe = self which should probably read parent = self right? They are in gdialogs.py L1247 and mcalc_builder.py L570 and give python errors like unexpected keyword argument 'parentframe' ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #1342: grass.core.find_program() problem with ssh and other
#1342: grass.core.find_program() problem with ssh and other ---+ Reporter: lucadelu | Owner: grass-dev@… Type: defect| Status: closed Priority: normal| Milestone: 7.0.0 Component: Python| Version: svn-trunk Resolution: invalid |Keywords: python find_program Platform: Linux | Cpu: Unspecified ---+ Changes (by lucadelu): * status: new = closed * resolution: = invalid Comment: Replying to [comment:1 glynn]: In order for find_program() to work, you need to find some invocation which returns a zero exit status (indicating success). If running the command with --help is considered an error (non-zero exit status), you'll need to find some other option. E.g. for ssh, you can use ssh -V. Ok, thanks it works for me -- Ticket URL: http://trac.osgeo.org/grass/ticket/1342#comment:2 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] Please support the GRASS GIS Community Sprint 2011!
*Please support the GRASS GIS Community Sprint 2011!* Are you using GRASS GIS for your professional work? Does GRASS help you to perform your spatial data analysis? Want to give back? *The event!* You are invited to support an upcoming event to make GRASS even better. At the GRASS Community Sprint 2011 in Prague, a group of developers and users will meet to improve the software, manuals and web site. This meeting is open to all interested participants. Details of the GRASS Community Sprint 2011 at: http://grass.osgeo.org/wiki/GRASS_Community_Sprint_Prague_2011 *How is the money used?* Based on sponsorship support, we plan to offer in kind support (food etc), and, if the budget allows, also partial travel grants may become possible. Here we plan to share the remaining funds in order to cover a percentage of travel costs for each participant. While we are hoping to receive donations especially from companies which benefit from using GRASS, we certainly welcome small donations as well. *Please give back *and* donate now* at http://grass.osgeo.org/donation.php ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G_error()
Martin wrote: I would propose adding non-fatal error reporting function to gislib. New G_error() would act in the similar way as G_fatal_error() except of calling exit(). Currently if you want to report error message without calling exit() you need to use G_warning() instead. Hi, can you provide an example of for when it would be useful? under what conditions is an error non-fatal? i.e. when would it be preferable over simply using G_important_message(ERROR: ...) ? Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Release 6.4.1
On Mon, Apr 11, 2011 at 9:25 PM, Markus Neteler nete...@osgeo.org wrote: Hi all, On Tue, Apr 5, 2011 at 4:30 PM, Martin Landa landa.mar...@gmail.com wrote: Hi, 2011/4/1 Markus Neteler nete...@osgeo.org: dear GRASS devs, I would vote for releasing 6.4.1 within few days, max. one week. RC2 has been released in March 17, some bugs has been fixed since RC2. Currently we have two blockers [1], both going to be closed. I am +1 on this. perfect, currently we are waiting only for one blocker [1]. Martin [1] http://trac.osgeo.org/grass/ticket/1335 ... fixed, so time to release 6.4.1! Please help to finish http://trac.osgeo.org/grass/wiki/Release/6.4.1-News and (not yet there) http://grass.osgeo.org/announces/announce_grass641.html http://grass.osgeo.org/announces/announce_grass641.txt Then we can announce... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] G_error()
Martin Landa wrote: I would propose adding non-fatal error reporting function to gislib. New G_error() would act in the similar way as G_fatal_error() except of calling exit(). Currently if you want to report error message without calling exit() you need to use G_warning() instead. If the issue doesn't prevent the program from operating, is it really an error? Or is this intended for the case where you want to separate reporting from termination? -- Glynn Clements gl...@gclements.plus.com ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] v.to.db azimuth from LL
Hi, is there any reason not to exit with a fatal error if the user tries to run v.to.db option=azimuth from a lat/lon location? (the result is useless) an alternative is to use libproj to calculate forward and backward azimuth geodesic angles, and send that to two DB columns. Until that is done, I would have it G_fatal_error() at the end of v.to.db's parse_command_line(). ?, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
