[GRASS-dev] Fwd: References and wiki pages on how to call functions and modules from GRASS with Python
Dear all, I have experience on running and developing Python scripts and running them inside GRASS but, now I wanted to call grass modules from external python scripts (without having to be launching and running GRASS. Is this possible? if yes, can someone point me out a wiki link or entry on mnual or tutorial that I can use to : - setup - and do a few tests I have already installed in a Linux machine a GRASS-dev version. Thank you Regards, Luisa ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: References and wiki pages on how to call functions and modules from GRASS with Python
Hi Luisa, On Wed, Jul 3, 2013 at 8:46 AM, Luisa Peña luisapena1...@gmail.com wrote: Dear all, I have experience on running and developing Python scripts and running them inside GRASS but, now I wanted to call grass modules from external python scripts (without having to be launching and running GRASS. Is this possible? yes, it is possible: http://grasswiki.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly Pietro ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #2010: r.in.wms2 fails to install on 6.x
#2010: r.in.wms2 fails to install on 6.x ---+ Reporter: hamish | Owner: grass-dev@… Type: defect | Status: new Priority: major | Milestone: 6.4.4 Component: Addons | Version: svn-releasebranch64 Keywords: r.in.wms2 |Platform: Linux Cpu: All| ---+ Comment(by turek): Hi Hamish, thanks for the fixes. I have ported back to G7 most of them (r56991, r56992 and r56993). So far the name of the o flag remains. In description of s flag there is written: Skip requests for fully transparent data I am not sure if it is correct description. If this flag is not present, the data are fetched also with transparent layer (if available). Otherwise you can use bgcolor param with this flag and specify color for these transparent areas. The o was chosen as abbreviation for opaque. Spaces between options are still kept, it seems more clear to me than one block of ~20 options. But it also can be changed. Stepan -- Ticket URL: https://trac.osgeo.org/grass/ticket/2010#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] [GRASS GIS] #2010: r.in.wms2 fails to install on 6.x
#2010: r.in.wms2 fails to install on 6.x
---+
Reporter: hamish | Owner: grass-dev@…
Type: defect | Status: new
Priority: major | Milestone: 6.4.4
Component: Addons | Version: svn-releasebranch64
Keywords: r.in.wms2 |Platform: Linux
Cpu: All|
---+
Comment(by hamish):
Replying to [comment:3 turek]:
Hi Hamish,
thanks for the fixes. I have ported back to G7 most of them
I hope you found them useful, if they are bad you don't have to listen to
me, it's your module after all. :)
So far the name of the o flag remains.
In description of s flag there is written:
Skip requests for fully transparent data
I am not sure if it is correct description. If this flag is not
present, the data are fetched also with transparent layer (if
available). Otherwise you can use bgcolor param with this flag
and specify color for these transparent areas.
I misunderstood it then, in one of the TWMS/r.out.kml script I have
somewhere it checks if the returned tile is all-white and skips
warping/mosaicking that so that part of the background becomes NULL not
255. Is the idea to make a complete rectangle instead of missing tiles in
the corners? I was wondering how the bgcolor option fit in. If that
supports standard GRASS colors you might consider adding:
{{{
#% gisprompt: old,color_none,color
}}}
so from the module GUI the user gets the color-picking tool.
The o was chosen as abbreviation for opaque.
I prefer to avoid -o,-q,-v as option letters if there are others
available, since it is easy for users to confuse them with --o,--q,--v.
fwiw I also like to avoid -l, -1, and -I, but for certain-font reasons.
Spaces between options are still kept, it seems more clear to me
than one block of ~20 options. But it also can be changed.
shrug, author's choice; the convention elsewhere is compressed but it
doesn't change the running of the script at all so just cosmetic, and I
agree it gets a bit hard to read when there are many options. Don't fear
the whitespace. :)
a couple observations/wishes:
* wx: switching from 1.1.1 to 1.3.0 clears selection and resizes window
height?
* wx: how about being able to filter the list like the location wizard
has for projection type Search? (often the servers have 50+ layers to
search)
* support for png8 image format? (like qgis has)
* I get an error when BGCOLOR is unset, does the spec require it or just
a picky WMS server?
{{{ ServiceException
BGCOLOR incorrectly specified (0xRRGGBB format expected)
/ServiceException/ServiceExceptionReport
}}}
* module gui: Interpolation type isn't part of the server request. -
Optional gui tab?
Also, I'm seeing a unicode error vs. layer Title string in the 6.4.3svn's
r.in.wms1's wxGUI wrapper. It's not to do with r.in.wms2.py, so I'll post
that to the -dev ML.
regards,
Hamish
ps- the WMS/WFS I'm using to test with:
http://wiki.openstreetmap.org/wiki/New_Zealand/Imagery
--
Ticket URL: https://trac.osgeo.org/grass/ticket/2010#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] #2010: r.in.wms2 fails to install on 6.x
I wrote: Also, I'm seeing a unicode error vs. layer Title string in the 6.4.3svn's r.in.wms1's wxGUI wrapper. It's not to do with r.in.wms2.py, so I'll post that to the -dev ML. details on.. the WMS/WFS I'm using to test with: http://wiki.openstreetmap.org/wiki/New_Zealand/Imagery In 6.4.3svn wxGUI File - import raster - r.in.wms (wrapper) I'm getting the following error when the parsed list of WMS layer Titles contains a non-ascii char, in this case on of them contains a long -- hyphen. Any ideas on a quick fix? It didn't like , unicode = True where I put it. All's well in trunk. Traceback (most recent call last): File /home/hamish/src/grass/svn/grass65/dist.x86_64 -unknown-linux-gnu/etc/wxpython/modules/ogc_services.py, line 216, in OnConnect self.list.LoadData(layers) File /home/hamish/src/grass/svn/grass65/dist.x86_64 -unknown-linux-gnu/etc/wxpython/modules/ogc_services.py, line 273, in LoadData self.SetItemText(lchild, title, 1) File /usr/lib64/python2.6/dist- packages/wx-2.8-gtk2-unicode/wx/gizmos.py, line 647, in SetItemText return _gizmos.TreeListCtrl_SetItemText(*args, **kwargs) UnicodeDecodeError : 'ascii' codec can't decode byte 0xe2 in position 36: ordinal not in range(128) thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] --with-opencl without a GPU
Maciek pisze: Thanks for sharing this. Unless anyone has more input I'll try to put this information together on the GRASS WiKi in the coming days. I hope I got it right: http://grasswiki.osgeo.org/grass-wiki/index.php?title=GPUaction=historysubmitdiff=19076oldid=18745. my only small comments would be *.so library names are linux-specific (well maybe FreeBSD too, I'm not sure), the exact library name is different on Mac (but automatically installed there so users don't have to worry about it), and that soon* the FOSS video drivers will have OpenCL support on linux, and it's good to future-proof the wording used on the wiki. :) [*] http://dri.freedesktop.org/wiki/GalliumCompute/ Linux + Intel graphics you need a Xeon chip for driver GPU support currently. not really relevant to the wiki page until we see a GRASS + OpenCL build for Windows (..could happen?), but the funny thing is that for MS Windows the opposite is true, only GPU support for the i7 chip not Xeon. Performance is probably not so great for the Ivy Bridge chips, but it's good as an already-there learning platform. thanks, Hamish ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] wingrass7 nightly builds broken
For the last two days, the nightly builds for trunk are broken. Configure fails [0] with [...] checking whether to use regex... yes checking for location of regex includes... checking for regex.h... no configure: error: *** Unable to locate regex includes. I guess some osgeo4w update moved or removed regex? Markus M [0] http://wingrass.fsv.cvut.cz/grass70/logs/log-r56987-632/package.log ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] wingrass7 nightly builds broken
Hi Markus, On Wed, 03. Jul 2013 at 20:17:46 +0200, Markus Metz wrote: I guess some osgeo4w update moved or removed regex? AFAICT no. apps/msys/include/regex.h is in still in msys-1.0.11-13 (and that's from Apr 13th). Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de committ(ed|ing) to QGISIRC: jef on FreeNode -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Status of r.cva?
Note that r.cva is really just a convenient way of
calling r.los multiple times and adding the results
for a cumulative viewshed analysis. You can get
the same net result by using r.los or r.viewshed
and r.mapcalc. As far as I recall, the earth curvature
correction is also identical across all modules.
Best,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke AT fastmail.fm
On Wed, Jul 3, 2013, at 1:51, Hamish wrote:
Nikos wrote:
a friend needs to use r.cva [0,1] (and r.viewshed [2]). What is the status
of
this add-on? Does it also work in G7? Only in G64 and previous releases?
...
[0] Link https://svn.osgeo.org/grass/grass-addons/grass6/raster/r.cva/
does not exist anymore!
[1] only here: http://www.ucl.ac.uk/~tcrnmar/GIS/r.cva.html ?
As I understand it, Mark's employer (university) would not let him
release the work as GPL-compatible. Otherwise the module would have
replaced r.los in the main GRASS source distribution years ago, and
their institution would have been cited many many times from it, but
oh well, he tried a number of times to convince them.
Considering universities like Johns Hopkins and Columbia literally
generate billions of dollars licensing IP (typically bio-med), and
how underfunded most educational institutions are, you can understand
a bit why the suits at other universities around the world have a
hard time seeing very far past the $ signs for anything and everything.
:-/
Hamish
___
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] Status of r.cva?
On Wednesday 03 of July 2013 20:52:29 Benjamin Ducke wrote: Note that r.cva is really just a convenient way of calling r.los multiple times and adding the results for a cumulative viewshed analysis. You can get the same net result by using r.los or r.viewshed and r.mapcalc. As far as I recall, the earth curvature correction is also identical across all modules. Best, Ben Essential! Thanks, Nikos [rest deleted] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] [GRASS GIS] #1742: WXGUI layer manager window doesn't show all menubar entries
#1742: WXGUI layer manager window doesn't show all menubar entries -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI| Version: svn-releasebranch64 Keywords: |Platform: Linux Cpu: Unspecified | -+-- Comment(by wenzeslaus): ''This is not going to be fixed soon, especially if it affects only some systems and some languages, so for now I just recap solutions.'' == Possible solutions == === Fix the system library === * fix the system GUI library * we can say that the system library handles long menus in the wrong way (hides items withou notifying a user) * hidden items itself are in fact not problem of GRASS but of the system GUI library (maybe it is a problem of wxPython/wxWidgets but probably not) === Single window GUI === * redesign the wxGUI to big single window which can have a long menu * this would solve it, but we still want to have current multi window GUI and for this the problem would be still present === Bigger Layer Manager window === * make Layer Manager window bigger * no point in this, width is needed for menubar (and toolbars) but usually not for the content itself === Abbreviations === * use abbreviations in the menu (in English? in translations? optionally?) === Shorter menu === * create a shorter menu (but what shall be omitted?) * create a shorter menu using toolboxes for yourself * possible now, see [http://grass.osgeo.org/grass70/manuals/wxGUI.toolboxes.html user manual page] * only workaround, each affected user must do it -- Ticket URL: http://trac.osgeo.org/grass/ticket/1742#comment:10 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] #1742: WXGUI layer manager window doesn't show all menubar entries
#1742: WXGUI layer manager window doesn't show all menubar entries -+-- Reporter: marisn | Owner: grass-dev@… Type: defect | Status: new Priority: critical | Milestone: 7.0.0 Component: wxGUI| Version: svn-releasebranch64 Keywords: |Platform: Linux Cpu: Unspecified | -+-- Comment(by hamish): Hi, some 2c comments: * IMO abbreviations should be avoided in almost all situations. the learning curve and new jargon is hard enough to decipher already, especially for non-native speakers trying to figure out what a 4-5 letter non-word is supposed to mean. * re. looks ok on Unity: it's one window manager among many, in one distro among many, of one operating system among several. Maybe it has a big market share for us, but I wouldn't think to design anything around it or suggest it to anyone as a solution to the menu error. * it's important. we should make it work on all languages. (missing tabs in module guis is another related issue, the filled triangle is hard to see) * my vote for a quick fix is to start by making the layer manager starting width a bit bigger (module guis too). (also good for the output window/tab) see also ctrl-t tile window wish/patch: #2004 * Please, for the love of all that is good an right in the world: don't name the personal menu as My Favorites. Anything but that. (mmph, Custom?) thanks, Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/1742#comment:11 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] #820: r.in.wms doesn't work in WinGRASS installer distribution
#820: r.in.wms doesn't work in WinGRASS installer distribution ---+ Reporter: ddalimonte | Owner: hamish Type: defect | Status: new Priority: major | Milestone: 6.4.4 Component: Projections/Datums | Version: svn-releasebranch64 Keywords: r.in.wms, wingrass, cs2cs |Platform: MSWindows XP Cpu: All| ---+ Comment(by hamish): re. cs2cs + grid paths, it is still a problem with the latest nightly build. if you are on wingrass and using grass 6.x and using a datum transform grid file in your projection definition, m.proj fails. (and so r.in.wms.sh too) two issues: - the path to the +nadgrids file should be quoted (see proj4 ticket # 218) - msys is messing up the path string (the g.message '/' expansion problem). possible aid for the second issue in init.sh and r.in.wms.sh's wms_request with dos2unix_path(), but I don't know if that helps here or not until the quoting issue gets fixed. Hamish -- Ticket URL: https://trac.osgeo.org/grass/ticket/820#comment:51 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
