Re: [GRASS-dev] WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

Moritz Lennert wrote >> >> FWIW I'm in favour for keeping it. >> >> although winGRASS is able to run without it, there are some nice and for >> daily life useful gnu tools coming with msys (e.g. grep ...), IMO it >> doesn't harm to ship it with winGRASS. > > http://sourceforge.net/projects/unxuti

Re: [GRASS-dev] WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

Moritz Lennert wrote > On 24/10/14 04:20, Vaclav Petras wrote: >> >> On Thu, Oct 23, 2014 at 7:08 PM, Glynn Clements >> < > glynn@.plus > glynn@.plus > >> wrote: >> >> >> Vaclav Petras wrote: >> >> > I'm afraid we have an issue with what we want. Do we want to remove >> msys

Re: [GRASS-dev] WinGRASS71svn using Windows shell (not bourne shell) thogh MSYS is installed

Glynn Clements wrote > Helmut Kudrnovsky wrote: > >> AFAIR years ago there was some issue with the g.mkfontcap run during >> installation which needed msys in %path%. > > g.mkfontcap is a binary executable; I have no idea why it would need > MSys. > > --

Re: [GRASS-dev] weren't r.stream going to core? was: r.stream.* problems on Ubuntu when installed via g.extensions

Martin Landa wrote > Hi, > > 2014-11-01 1:07 GMT+01:00 Markus Neteler < > neteler@ > >: > > [...] > >> Future fixes in trunk (i.e. GRASS GIS 7.1.svn) may be backported to >> Addons at this point. > > we could probably also remove these modules from trunk and maintain > them on one place only

[GRASS-dev] r.stream.*-addons not built for winGRASS

hi, recently the r.stream.*-modules were moved to addons. a quick look at http://wingrass.fsv.cvut.cz/grass71/addons/grass-7.1.svn/logs/ shows that onlyr.stream.basins is built as g.extension-downloadable addon. I've checked C:\OSGeo4W\src\grassaddons\grass7\raster\Makefile all modules se

Re: [GRASS-dev] r.stream.*-addons not built for winGRASS

Helmut Kudrnovsky wrote > hi, > > recently the r.stream.*-modules were moved to addons. > > a quick look at > http://wingrass.fsv.cvut.cz/grass71/addons/grass-7.1.svn/logs/ shows that > only r.stream.basins is built as g.extension-downloadable addon. the same is valid

Re: [GRASS-dev] r.stream.*-addons not built for winGRASS

Helmut Kudrnovsky wrote > hi, > > recently the r.stream.*-modules were moved to addons. > > a quick look at > http://wingrass.fsv.cvut.cz/grass71/addons/grass-7.1.svn/logs/ shows that > only r.stream.basins is built as g.extension-downloadable addon. > > I'

[GRASS-dev] grass7 addon python script - finishes in normal and --verbose mode, but not in --quiet mode

tested here with: GRASS Version: 7.1.svn GRASS SVN Revision: 62712 Erstellungsdatum: 2014-11-12 Build Platform: i686-pc-mingw32

Re: [GRASS-dev] grass7 addon python script - finishes in normal and --verbose mode, but not in --quiet mode

Anna Petrášová wrote >> >> but in --quiet mode it fails with: >> >> v.fixed.segmentpoints --quiet vector=iselflipped@myricaria cat=1 >> dir=C:\tmp\grassscript distance=25000 >> Traceback (most recent call last): >> File "C:\Users\myricaria\AppData\Roaming\GRASS7\addons/scr >> ipts/v.fixed.segment

Re: [GRASS-dev] G_OPT_R_MAP vs G_OPT_R_INPUT

NikosAlexandris wrote > What is the difference between G_OPT_R_MAP and G_OPT_R_INPUT? Which and > why should I prefer for my script(s)? > > Is there a step-by-step run-through of all options for composing header > definitions? > > -- > Nikos > ___ >

Re: [GRASS-dev] Adding a suffix for output raster map names

NikosAlexandris wrote > Is there a pygrass function to isolate the a raster map's basename from > the Mapset part? Looking for it... > > Nikos > ___ > grass-dev mailing list > grass-dev@.osgeo > http://lists.osgeo.org/mailman/listinfo/grass-dev this

Re: [GRASS-dev] grass7 addon python script - finishes in normal and --verbose mode, but not in --quiet mode

Anna Petrášová wrote >> >> grass.read_command('r.info', map='elevation', flags='g', quiet=True) >> >> and it gives output as expected. >> > > It's because of the header line: > cat|length > 1|572.767146965659 > > but in quiet mode you get: > > 1|572.767146965659 > > so I would suggest set quiet

[GRASS-dev] epsg code stored anywhere and used by v.out.ogr/r.out.gdal?

Hi, if the location is created by an epsg code, is the epsg code stored anywhere in the location? if yes can be the epsg-code-representation of the projection used by v.out.ogr/r.out.gdal instead of the grass gis representation of the projection? - best regards Helmut -- View this message

Re: [GRASS-dev] epsg code stored anywhere and used by v.out.ogr/r.out.gdal?

Martin Landa wrote > Hi, > > 2014-11-16 9:58 GMT+01:00 Markus Neteler < > neteler@ > >: >> It is sometimes stored in the PROJ_INFO file. > > in the recent versions of GRASS 7 it should be stored in PROJ_EPSG > file. If not than it's a bug. > > Martin tested with GRASS Version: 7.1.svn

Re: [GRASS-dev] epsg code stored anywhere and used by v.out.ogr/r.out.gdal?

>> if yes can be the epsg-code-representation of the projection used by >> v.out.ogr/r.out.gdal instead of the grass gis representation of the >> projection? > >Often not since it may lack datum parameters. a quick test case: data available at https://www.tirol.gv.at/data/datenkatalog/umwelt/gewa

[GRASS-dev] v.what.rast in a python script causes "grass.exceptions.CalledModuleError"

hi, I've a addon script: http://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.habitat.dem which calls v.what.rast http://trac.osgeo.org/grass/browser/grass-addons/grass7/vector/v.habitat.dem/v.habitat.dem.py#L297 this gives following error: -- Upload DEM zonal statisti

Re: [GRASS-dev] v.what.rast in a python script causes "grass.exceptions.CalledModuleError"

attached a script with only the v.rast.stat part for a quick test v.py it fails also. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/v-what-rast-in-a-python-script-causes-grass-exceptio

Re: [GRASS-dev] v.what.rast in a python script causes "grass.exceptions.CalledModuleError"

>Thanks for finding this, we were adjusting the scripts to the new python error handling and we made a >mistake in errorcode, fixed in r63302 and backported. thanks for the fix. - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/v-what-rast-in-a-pyth

Re: [GRASS-dev] v.proj: line densification added for reprojection error minimization

>The result (see screenshot, maybe an extreme example but yet helpful >to show the improvement) shows how nicely the projection is performed >now (green color is new output). >Please benchmark this with other GIS... attached, done with a GIS from redmont

Re: [GRASS-dev] v.proj: line densification added for reprojection error minimization

Helmut Kudrnovsky wrote >>The result (see screenshot, maybe an extreme example but yet helpful >>to show the improvement) shows how nicely the projection is performed >>now (green color is new output). >>Please benchmark this with other GIS... > > attached, done

Re: [GRASS-dev] v.proj: line densification added for reprojection error minimization

>> > >Good - but is that the default or requires extra tricks/knowledge? 2 steps with 2 different tools are needed: (1) densify polygon line, (2) reproject to new SRS; and of course the knowledge that large p

Re: [GRASS-dev] v.proj: line densification added for reprojection error minimization

> And how about QGIS? the same, 2 steps are needed: (1) densify data, (2) reproject vector - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/v-proj-line-densification-added-for-reprojection-error-minimization-tp5177786p5177825.html Sent from the Gra

Re: [GRASS-dev] How to calculate log() in v.db.update with SQLite backend?

Markus Neteler wrote >> >> Works. > > Submitted to trunk in r63238. Please test (tomorrow) also on Windows > if possible (the name will be something like libsqlitefunctions.dll > which you need to provide to v.db.select). any idea where to find/to get libsqlitefunctions.dll for testing? -

Re: [GRASS-dev] On integrating i.fusion.hpf into i.pansharpen

NikosAlexandris wrote > On 20.12.2014 20:43, Yann Chemin wrote: > >> Would it make sense to let it be separate? > > For me that is the easiest. But it would be nice to gather algorithms > of a kin to one place, make grass more attractive, compact and > integrated. > > > Thank you Yann. Plea

Re: [GRASS-dev] How to calculate log() in v.db.update with SQLite backend?

Markus Neteler wrote > On Sat, Dec 20, 2014 at 5:49 PM, Helmut Kudrnovsky < > hellik@ > > wrote: >> Markus Neteler wrote >>>> >>>> Works. >>> >>> Submitted to trunk in r63238. Please test (tomorrow) also on Windows >>> if po

Re: [GRASS-dev] How to calculate log() in v.db.update with SQLite backend?

>should we add a note to the manual where extension-functions.c could be downloaded >(https://www.sqlite.org/contrib) and how it is compiled (on windows)? or somewhere in the wiki? wiki entry added: http://grasswiki.osgeo.org/wiki/Build_SQLite_extension_on_windows - best regards Helmut -

[GRASS-dev] r.slope.aspect: one pixel less in the output at the border shrinks region extent in further calculations

hi devs, I've added a script [1] with following calculations ideas: - do some calculations with r.slope.aspect output - coarse the resolution (but meet the DEM extent) - do some calculations with r.slope.aspect output at the coarser resolution - coarse the resolution again (but meet the DEM exte

Re: [GRASS-dev] r.slope.aspect: one pixel less in the output at the border shrinks region extent in further calculations

Helmut Kudrnovsky wrote > hi devs, > > I've added a script [1] with following calculations ideas: > > - do some calculations with r.slope.aspect output > - coarse the resolution (but meet the DEM extent) > - do some calculations with r.slope.aspect output at the coars

Re: [GRASS-dev] r.slope.aspect: one pixel less in the output at the border shrinks region extent in further calculations

Hi Pietro, >this is not a bug. I unterstand the same. my question is more about how to implemented the mentioned iterative algorithm which uses coarser resolution by each step and how to avoid an extent shrinking of e.g. about 400m with the coarsest resolution. - best regards Helmut -- Vi

Re: [GRASS-dev] r.slope.aspect: one pixel less in the output at the border shrinks region extent in further calculations

Dear Helena, > I believe that any reasonable estimate is better than the current > shrinking region (in r.flow we just > propagate the same values to the edges), but that does not seem to be the > consensus. I agree with you that a reasonable estimate is better than the current situation. I'v

Re: [GRASS-dev] [GRASS-SVN] r63958 - grass/trunk/scripts/v.to.lines

hi Anna, > The motivation is probably that the input map name is used to construct > temporary map names, > so you want to avoid the mapset part there. yes, that's the point; tested with winGRASS: -- v.to.lines --verbose input=geodetic_pts@PERMANENT output=geodetic_pts_lines P

[GRASS-dev] (win)GRASS compiling:

hi, I've just compiled winGRASS7.0.0 RC1, compilation went without errors. although by scanning the log, I've found e.g. Status: Parsing c:\users\myrica~1\appdata\local\temp\tmp0piwel.h Error: c:\\osgeo4w\\bin\\../lib/gcc/mingw32/4.7.2/../../../../include/sys/types.h:27: Syntax error at '__time3

[GRASS-dev] [GRASS-SVN] r64254 - grass-addons/grass7/imagery/i.spec.sam

>Removed: > grass-addons/grass7/imagery/i.spec.sam/err.h > grass-addons/grass7/imagery/i.spec.sam/machine.h > grass-addons/grass7/imagery/i.spec.sam/matrix.h > grass-addons/grass7/imagery/i.spec.sam/matrix2.h > grass-addons/grass7/imagery/i.spec.sam/meminfo.h >Modified: > grass-addons/g

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

> > > I find the fact that GRASS does not provide a default >> > projection system, but forces the user to think about projection from the >> > start, one of its strengths, both for work and for teaching. >>> >> On of it strenghts, yes. But I have been teaching GRASS a lot to GIS >>

Re: [GRASS-dev] raster.dll problem

Anna Petrášová wrote > Hi, > > one student has problems running grass7 beta4. She keeps getting: > > Could not load DLL C:\Program Files\Intergraph\ERDAS Imagine > 2014\usr\lib\Win32Release\FileFilters\raster.dll: The module was not > found. > > I couldn't find anything helpful. She gets this wh

Re: [GRASS-dev] Making start of GRASS GIS easier for newcomers

>** >1) Run GRASS launch script => GUI opens directly > >2) Have entries in the 'File'-Menu to > >- 'Open existing location' >- 'Create new location' >- 'Creat new mapset' >- 'Manage locations and mapsets' (could also replace the two last > entries) > >3) Whe

Re: [GRASS-dev] osgeo4w package for GRASS 7

Martin Landa wrote > Hi, > > in the light of GRASS 7.0.0 release I would suggest to change current > OSGeo4W package naming convention from: > > (option a) > > * grass70 to grass7 (version 7.0.0) > * grass70-dev to grass7-dev (version 7.0.1svn) > * grass71-dev to grass-trunk-dev (7.1.svn) > > o

Re: [GRASS-dev] osgeo4w package for GRASS 7

Markus Neteler wrote > On Sat, Feb 21, 2015 at 6:17 PM, Martin Landa < > landa.martin@ > > wrote: >> to summarize OSGeo4W proposal: >> >> * `grass` will be 7.0.0 >> * `grass6` will be 6.4.4 (hopefully soon 6.4.5) >> * `grass-svn` will be 7.0.1svn (*) >> * `grass-trunk-svn` will be 7.1svn >> * `gr

Re: [GRASS-dev] osgeo4w package for GRASS 7

wenzeslaus wrote > On Sat, Feb 21, 2015 at 12:17 PM, Martin Landa < > landa.martin@ > > > wrote: > >> 2015-02-21 17:49 GMT+01:00 Martin Landa < > landa.martin@ > >: >> >> Except for grass6-dev: does it really make sense to still publish a >> -dev >> >> version of grass6 ? In my thinking we wil

[GRASS-dev] grass7 commands in QGIS processing

see: http://lists.osgeo.org/pipermail/qgis-developer/2015-February/036845.html there seems to be missing some g7 commands in QGIS processing. anything we could help? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/grass7-commands-in-QGIS-process

[GRASS-dev] grass 7 QGIS plugin

fyi, taken from http://lists.osgeo.org/pipermail/qgis-developer/2015-February/036851.html --- Olá todos, I'am already preparing crowdfunding campaign for GRASS plugin upgrade. It will include: - qgisgrasslib upgrade to GRASS 7 - single build with both GRASS 6 and 7 (GRAS

[GRASS-dev] grass addon sync to github

Hi devs, I have a few g7-addons in grass svn and I want to put them also in github. do you know any script/tool to sync addons in svn with github? - best regards Helmut -- View this message in context: http://osgeo-org.1560.x6.nabble.com/grass-addon-sync-to-github-tp5190784.html Sent from

[GRASS-dev] the meaning/the need of the variable GISRC?

hi devs, this question is related to Ticket #2448 [1] [2] says: GISRC name of .grass7/rc file. Defines the system wide value while in a GRASS session. from the ticket [3]: "One other thing is that it is not clear to me what changed that now GISRC variable is required but it was not before.

Re: [GRASS-dev] grass addon sync to github

Luca Delucchi wrote > On 1 March 2015 at 22:54, Helmut Kudrnovsky < > hellik@ > > wrote: >> Hi devs, >> > > Hi Helmut, > >> I have a few g7-addons in grass svn and I want to put them also in >> github. >> >> do you know any script/too

[GRASS-dev] 'utf8' codec can't decode byte 0xf6 in position 8: invalid start byte

hi, tested with GRASS Version: 7.1.svn GRASS SVN revision: 64858 Build date: 2015-03-15 Build platform: i686-pc-mingw32

Re: [GRASS-dev] 'utf8' codec can't decode byte 0xf6 in position 8: invalid start byte

> I tested winGRASS r64873, no problems with English locale, I switched to German too, still no problems. tested with System Info GRASS Version: 7.1.svn GRASS SVN revisio

Re: [GRASS-dev] 'utf8' codec can't decode byte 0xf6 in position 8: invalid start byte

>I tested winGRASS r64873, no problems with English locale, I switched to German too, still no problems. interesting: _no_ problems with commands like e.g.: g.region g.mapset g.access g.gisenv g.extension problems with commands like e.g.: r.slope.aspect d.vect r.watershed r.neigbhours v.parall

Re: [GRASS-dev] R in winGRASS

Anna Petrášová wrote > Hi, > > I am having troubles with running R in winGRASS. I installed R using this > tutorial: > http://www.r-bloggers.com/installing-rcpp-on-windows-7-for-r-and-c-integration/ > > In normal windows command line, it works. In GRASS session, I get this > when > running R: >

Re: [GRASS-dev] R in winGRASS

Anna Petrášová wrote > On Mon, Mar 16, 2015 at 6:05 PM, Anna Petrášová < > kratochanna@ > > > wrote: > >> Hi, >> >> I am having troubles with running R in winGRASS. I installed R using this >> tutorial: >> >> http://www.r-bloggers.com/installing-rcpp-on-windows-7-for-r-and-c-integration/ >> >> I

[GRASS-dev] g.gui.animation in winG7.0: error messages

hi, using g.gui.animation -> add space-time data set or series of map layers I'll get error messages in the windows command line: C:\>Process Process-2: Traceback (most recent call last): File "C:\OSGEO4~2\apps\Python27\lib\multiprocessing\process.py", line 258, in _bootstrap self.run()

[GRASS-dev] [Qgis-developer] GRASS regions

FYI http://lists.osgeo.org/pipermail/qgis-developer/2012-April/019781.html > To achieve this, we have to solve the problem of how to use grass regions, > a very useful concept for subsetting an analysis or changing its > resolution. As I'm having to do with topology in PostGIS I'm very interest

[GRASS-dev] Re: [Qgis-developer] GRASS regions [grass topology inside PostGIS2.0]

again FYI from the qgis-dev-ml: http://lists.osgeo.org/pipermail/qgis-developer/2012-May/019894.html >On Fri, Apr 27, 2012 at 02:36:41PM +0200, Patrick S. wrote: > >> @strk: Do you know of projects/options to implement the grass topology >> inside PostGIS2.0? > >Markus Neteler mentioned that Mart

[GRASS-dev] [Qgis-developer] Adding GRASS modules

FYI from the qgis-dev-ml http://lists.osgeo.org/pipermail/qgis-developer/2012-May/019990.html and a howto for a qgis-grass-sextante-plugin: http://sextante.googlecode.com/svn/trunk/soft/bindings/qgis-plugin/src/sextante/grass/grass.txt <> Hi all. <> Now that sextante is in full swing, I think r

[GRASS-dev] Re: PIxel-wise regression contribution

>I would like to contribute a script that I have used in my research to >the broader field. The script carries out linear regression, except >that rather than using two rasters for the x and y variables, it uses >any number of pairs of rasters, allowing the regression to be carried >out across a t

[GRASS-dev] Re: PIxel-wise regression contribution

>I am not sure from the documentation how to do this. I have an >osgeo-userid, but no write access to the addons list (I assume). I >would be grateful if you would point me in the right direction. just ask for addons-write-access in the dev-ML (and giving your osgeo-userid), that's all. -

Re: [GRASS-dev] NBR tool for Landsat 7 images

hi >Just writing to share with the community a little python script for GRASS 6.4 we developed at the Instituto >de Información Territorial del Estado de Jalisco, in México. The purpose of the script is to obtain the NBR >(Normalized Burn Ratio) out of a Landsat 7 image without the hassle of pas

Re: [GRASS-dev] limits of r.patch

hi margherita, >I probably am requiring too much, but this is just for sharing an experience. I've just imported in GRASS >1573 ASTER GDEM tiles, using r.external, and everything seemed to be OK. Then I ran: > >GRASS 6.4.3svn (ASTER_GDEM):~ > r.patch in=`g.mlist pat=AST* sep=,` out=aster_gdem >ERR

Re: [GRASS-dev] limits of r.patch

hi, >r.external input=/home/leomarg/Desktop/aster/mosaic.vrt output=mosaic > >Projection of input dataset and current location appear to match >Importing band 1 of 1... >ERROR 4: `ASTGTM_N33E000_dem_lzw.tif' does not exist in the file system, >and is not recognised as a supported dataset name.

Re: [GRASS-dev] limits of r.patch

>ERROR 4: `ASTGTM_N33E000_dem_lzw.tif' does not exist in the file system, >and is not recognised as a supported dataset name. what says gdalinfo about ASTGTM_N33E000_dem_lzw.tif? - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/limits-of-r-patch-tp49

Re: [GRASS-dev] limits of r.patch

>what says gdalinfo about ASTGTM_N33E000_dem_lzw.tif? oh, I've meant: gdalinfo mosaic.vrt - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/limits-of-r-patch-tp4988265p4988833.html Sent from the Grass - Dev mailing list archive at Nabble.com. ___

Re: [GRASS-dev] limits of r.patch

>>what says gdalinfo about ASTGTM_N33E000_dem_lzw.tif? > >oh, I've meant: gdalinfo mosaic.vrt tested here now with some aster-tiles: C:\data\gisdata\asterdem\Tiles_201102121133>gdalinfo asterdem.vrt Driver: VRT/Virtual Raster Files: asterdem.vrt C:\data\gisdata\asterdem\Tiles_201102121

Re: [GRASS-dev] locale problem solved - but have suggestion

>What do you think? Does Windows use these variables or a different set? tested here with a osgeo4w-wingrass7 in win7-64bit(german). switching gui-languages (C,fr,es,it,de,jp,...) and starting gui are working. - best regards Helmut -- View this message in context: http://osgeo-org.1560.n

Re: [GRASS-dev] replace r.in.wms by r.in.wms2 (in trunk)

>To enable testing... tested here with osgeo4w-wingrass7, r52472, win7-64bit(german) and the examples from the manual [1], region is set to greater alpine region in europe: g.region -p projection: 3 (Latitude-Longitude) zone: 0 datum: wgs84 ellipsoid: wgs84 north: 48:30:07N south

Re: [GRASS-dev] locale problem solved - but have suggestion

I'm changing the GUI preferences, no change on windows system level - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/locale-problem-solved-but-have-suggestion-tp4991699p4992304.html Sent from the Grass - Dev mailing list archive at Nabble.com. _

Re: [GRASS-dev] WinGRASS 6.4.3/6.5 binary???

the binaries (nightly builds) for wingrass6.4.3svn are in: Http://wingrass.fsv.cvut.cz/grass64 the binaries for wingrass6.5svn seems to be broken since a few days, see http://wingrass.fsv.cvut.cz/grass65/logs/ - best regards Helmut -- View this message in context: http://osgeo-org.1560

Re: [GRASS-dev] [GRASS-user] new wxGUI feature: Map Swipe

hi Anna, >I would like to backport it soon, of course. Is there a chance someone >could test it on Windows first? (adding dev list) great work! I've tested it here a little bit by using the nc-sample dataset and the latest available osgeo4w-wingrass7. the rasters are elevation and ortho_2001_

Re: [GRASS-dev] [GRASS-user] new wxGUI feature: Map Swipe

>> I've tested it here a little bit by using the nc-sample dataset and the >> latest available osgeo4w-wingrass7. > >I have added a NC sample dataset based Landsat example to >http://grass.osgeo.org/wiki/WxGUI_Map_Swipe nice example, little correction done. >One observation: if you hand-write a (

Re: [GRASS-dev] too many branches

>even the GRASS website [0] gets confused about all those branches. >GRASS 6.4.3, the next stable release, is currently hidden under GRASS >6.4.2, current stable. Therefore there should be 4, not 3 sections: >6.4.2, 6.4.3, 6.5, 7.0. This is however IMHO too much, confusing for >users and a maintena

Re: [GRASS-dev] too many branches

>... so the idea to start a GRASS 7 release branch would address that nicely. +1 Helmut - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/too-many-branches-tp4996931p4997161.html Sent from the Grass - Dev mailing list archive at Nabble.com. __

Re: [GRASS-dev] command dialog notebook styles

hi Anna, >Styles were tested on Ubuntu 10.04 (Gnome), information how styles >look like on Windows and Mac (including comparison to other >applications) is appreciated. is there any related wiki-page, where screenshots (i.e. windows, etc.) can be uploaded? Helmut - best regards Helmut --

Re: [GRASS-dev] command dialog notebook styles

>is there any related wiki-page, where screenshots (i.e. windows, etc.) can be uploaded? tested here in osgeo4w-wingrass7 in a win7-64bit-box. only listleft works, in the other two no input is possible. Helmut http://osgeo-org.1560.n6.nabble.com/file/n4998104/notebookstyle_windows_listleft.png

Re: [GRASS-dev] command dialog notebook styles

>One more question, all the tabs are empty? Command output and manual >tab are created separately so there could be some difference. fancygreen => all tabs with content, manual ok basicleft => all tabs with content, but no manual the other two => all tabs empty, no manual - best regards

Re: [GRASS-dev] command dialog notebook styles

>That's bad. I am not able to test it. Are you able to switch the tabs? >Maybe it's some problem with refreshing. I tried to google some >windows specific problems with wx.Notebook but I haven't found >anything interesting. switching between tabs possible, but no effect. saving the new configura

Re: [GRASS-dev] command dialog notebook styles

>tested here in osgeo4w-wingrass7 in a win7-64bit-box. a turned up basicleft would be nice. http://osgeo-org.1560.n6.nabble.com/file/n4998123/notebookstyle_windows_basicleft_turnedup.png notebookstyle_windows_basicleft_turnedup.png - best regards Helmut -- View this message in context:

Re: [GRASS-dev] command dialog notebook styles

>tested here in osgeo4w-wingrass7 in a win7-64bit-box. a basicleft turned up would be nice. http://osgeo-org.1560.n6.nabble.com/file/n4998114/notebookstyle_windows_basicleft_turnedup.png notebookstyle_windows_basicleft_turnedup.png - best regards Helmut -- View this message in context:

Re: [GRASS-dev] adding volume layer in 6.4.3 and 7 binaries

>In the Windows binaries for 6.4.3 and 7. and in Michael's binaries for >6.4.3 when I try to add a 3D raster >to Map layers I get the following error (see bellow) and the dialog >does not open. tested here on the latest osgeo4w-wingrass6.4.3.svn, confirmed: Traceback (most recent call last): Fi

Re: [GRASS-dev] adding volume layer in 6.4.3 and 7 binaries

hi, >Unable to fetch interface description for command >'d.rast3d'. >Details: [Errno 2] No such file or directory here on windows, it is in C:\OSGeo4W\apps\grass\grass-6.4.3svn\etc\wxpython\scripts\d.rast3d.py - best regards Helmut -- View this message in context: http://osgeo-org.1560

Re: [GRASS-dev] command dialog notebook styles

hi, >> fancygreen => all tabs with content, manual ok >> basicleft => all tabs with content, but no manual > >manual should work now for the 'list left' style (but i hope we can >come up with some better name...) the manual works now. >> the other two => all tabs empty, no manual > >I did some c

[GRASS-dev] Fwd: Re: R + grass7

fyi a question regarding an "translation" (flags,parameter) table between grass6x and grass7.Helmut Original-Nachricht Datum: Wed, 29 Aug 2012 14:35:37 +0200 (CEST)Von: Roger Bivand An: Helmut Kudrnovsky Betreff: Re: R + grass7 On Wed, 29 Aug 2012, Helmut Kudrno

Re: [GRASS-dev] command dialog notebook styles

>Please test it again, I've just did some changes which (I hope) should help. tested with osgeo4w-wingrass-7.0.svn-r52994 now all styles are working. http://osgeo-org.1560.n6.nabble.com/file/n4998974/capture_001_31082012_083539.png capture_001_31082012_083539.png http://osgeo-org.1560.n6.nabbl

[GRASS-dev] compiling relbrand64 fails on windows

tested here in the osgeo4w-environment on a WinVista-32bit-box, svn-checkout today: GRASS GIS compilation log - Started compilation: Fri Aug 31 15:48:36 GMT 2012 -- Errors in: /osgeo4w/usr/src/grass643svn/lib/form /osgeo4w/usr/src/grass643svn/lib/vector/diglib /osgeo4w/usr/

Re: [GRASS-dev] compiling relbrand64 fails on windows

>tested here in the osgeo4w-environment on a WinVista-32bit-box, svn-checkout today: now tested on my Win7-64bit-box, the same also here: GRASS GIS compilation log - Started compilation: Fri Aug 31 17:20:04 GMT 2012 -- Errors in: /osgeo4w/usr/src/grass_relbranch64/lib/for

Re: [GRASS-dev] compiling relbrand64 fails on windows

>The "o" indicates that SHLIB_LD is empty, while the missing ".dll" >suffix indicates that SHLIB_SUFFIX is empty. > >I have no idea why it would only affect these specific libraries; or >are you doing an incremental build (no "make clean")? completely fresh svn-checkout and then following the ins

Re: [GRASS-dev] compiling relbrand64 fails on windows

>$ gcc --version >gcc.exe (GCC) 3.4.5 (mingw-vista special r3) $ make --version GNU Make 3.81 - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/compiling-relbrand64-fails-on-windows-tp4999094p4999280.html Sent from the Grass - Dev mailing list arc

[GRASS-dev] g.region rast3d fails in WinGrass

tested with osgeo4w-wingrass6.5.svn and slovakia3d-data set: g.region --verbose rast3d=precip3d.500z50@PERMANENT G3d_readWindow: unable to find [\grassdata/slovakia3d/user1/windows3d/\grassdata/slovakia3d/PERMANENT/grid3/precip3d.500z50/cellhd]. ERROR: Ungültige Region

Re: [GRASS-dev] g.region rast3d fails in WinGrass

>tested with osgeo4w-wingrass6.5.svn and slovakia3d-data set: with DEBUG=3 g.region --verbose rast3d=precip3d.500z50@PERMANENT D2/3: G__read_Cell_head D2/3: G__read_Cell_head_array D3/3: region item: proj: 0 D3/3: region item: zone: 0 D3/3: region item: n

[GRASS-dev] load 3d-vector in 3d-view mode fails in wingrass

tested with osgeo4w-wingrass6.5.svn/6.4.3svn and slovakia3d-data set: g.region -p vect=precip3d@PERMANENT projection: 0 (x,y) zone: 0 north: 5492305 south: 5294826 west: 4193437 east: 4603765 nsres: 499.94683544 ewres:

Re: [GRASS-dev] improving v.in.wms

>but to me OWSLib looks like it has much more python goodness in it, > http://pypi.python.org/pypi/OWSLib in the osgeo4w-wingrass-build-environment: (http://download.osgeo.org/osgeo4w/versions.html) owslib, 0.3-1 - best regards Helmut -- View this message in context: http://osgeo-org.1

[GRASS-dev] compiling error wingrass7 in temporal gis

hi, osgeo4w-build-environment, win7-64-bit svn r53310 GRASS GIS compilation log - Started compilation: Wed Oct 3 18:13:55 GMT 2012 -- Errors in: /osgeo4w/usr/src/grass_trunk/temporal/t.create [...] -- myricaria@MYRICARIA-HP /osgeo4w/usr/src/grass_trunk/temporal/t.create

Re: [GRASS-dev] compiling error wingrass7 in temporal gis

>and also a windows error-message pops up: > >"sqlite3-rtree-geometry-callback" not found in the dll "sqlite3.dll" see: http://groups.google.com/group/spatialite-users/tree/browse_frm/month/2012-01/34ee9c1bb7072bac?rnum=91&_done=/group/spatialite-users/browse_frm/month/2012-01?&pli=1 - be

Re: [GRASS-dev] compiling error wingrass7 in temporal gis

in >see: > >http://groups.google.com/group/spatialite-users/tree/browse_frm/month/2012-01 >/34ee9c1bb7072bac?rnum=91&_done=/group/spatialite-users/browse_frm/month/2012-01?&pli=1 PATCH PROPOSAL FOR THE NEXT UPDATE (3.0.2) == invert the default behavior for

Re: [GRASS-dev] compiling error wingrass7 in temporal gis

FYI >in osgeo4w it's sqlite 3.0.1 and upcoming will be SpatiaLite 4.0.0 https://www.gaia-gis.it/fossil/libspatialite/wiki?name=4.0.0-RC1 https://www.gaia-gis.it/fossil/libspatialite/wiki?name=switching-to-4.0 - best regards Helmut -- View this message in context: http://osgeo-org.1560.

Re: [GRASS-dev] compiling error wingrass7 in temporal gis

>see: > >http://groups.google.com/group/spatialite-users/tree/browse_frm/month/2012-01 >/34ee9c1bb7072bac?rnum=91&_done=/group/spatialite-users/browse_frm/month/2012-01?&pli=1 > osgeo4w-ticket opened: https://trac.osgeo.org/osgeo4w/ticket/305 - best regards Helmut -- View this message in

[GRASS-dev] v.to.db - slope: which default unit?

from the manual of v.to.db http://grass.osgeo.org/grass64/manuals/html64_user/v.to.db.html slope: slope steepness of vector line or boundary any idea which is default unit of the calculated slope? units=string Units mi(les),f(eet),me(ters),k(ilometers),a(cres),h(ectares),r(adians),d(egre

Re: [GRASS-dev] working on a add on to calculate MESS

>I would also like to know what else is needed in case I want to add it to the addon wiki. see http://grass.osgeo.org/wiki/GRASS_AddOns#Adding_something_new http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository it would be nice to have it in the addons, so n

Re: [GRASS-dev] dateutil dependency killing GRASS 7

>Since >dateutil causes obviously so much trouble on Mac OS and Windows (i >wasn't aware of that since i am an ignorant Linux person) i will only >add it if it works on these systems out of the box. regarding the windows-side of the world, within osgeo4w, dateutil is available by matplotlib and a

Re: [GRASS-dev] dateutil dependency killing GRASS 7

>So it comes on Mac but not on Windows? concerning windows, it's there in the osgeo4w-(build)-environment offered by matplotlib. - best regards Helmut -- View this message in context: http://osgeo-org.1560.n6.nabble.com/dateutil-dependency-killing-GRASS-7-tp5009133p5010816.html Sent from t

Re: [GRASS-dev] Fwd: [osgeo4w] #305: sqlite/spatialite: "sqlite3-rtree-geometry-callback" not found in the dll "sqlite3.dll"

>Here a GRASS 7 question: > >-- Forwarded message -- >From: OSGeo4W <[hidden email]> >Date: Sat, Oct 27, 2012 at 8:47 PM >Subject: Re: [osgeo4w] #305: sqlite/spatialite: >"sqlite3-rtree-geometry-callback" not found in the dll "sqlite3.dll" forwarded from the spatialite-ML: > in

Re: [GRASS-dev] Fwd: [osgeo4w] #305: python/sqlite: "sqlite3-rtree-geometry-callback" not found in "C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll"

>1. Pick up the DLL from the directory in which the >.exe that is linked against it resides. that seems to be the problem here: (1) C:\OSGeo4W\apps\Python27\DLLs\sqlite3.dll => python's own shipped sqlite3.dll (2) C:\OSGeo4W\bin\sqlite3.dll => osgeo4w-package first found is (1) the error rai

Re: [GRASS-dev] installing r.modis fails

hi Paulo, >ERROR: No module named rmodislib >make[1]: *** [r.modis.download.tmp.html] Error 1 >ERROR: No module named rmodislib >make[1]: *** [r.modis.import.tmp.html] Error 1 >Installing... the addons-wiki [1] says: [...] It uses the pyModis library and the MODIS Reprojection Tool software to

<    1   2   3   4   5   6   7   8   9   10   >