date:20151012

Re: [GRASS-dev] [GRASS GIS] #2755: Commandline switch "/S" is not working anymore

2015-10-12 Thread GRASS GIS

#2755: Commandline switch "/S" is not working anymore
---+-
  Reporter:  derseppel |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.0.1
 Component:  Installation  |Version:  7.0.1
Resolution:|   Keywords:  wingrass
   CPU:  Unspecified   |   Platform:  MSWindows 7
---+-
Changes (by martinl):

 * keywords:   => wingrass
 * milestone:   => 7.0.1


--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2755: Commandline switch "/S" is not working anymore

2015-10-12 Thread GRASS GIS

#2755: Commandline switch "/S" is not working anymore
---+-
  Reporter:  derseppel |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.0.2
 Component:  Installation  |Version:  7.0.1
Resolution:|   Keywords:  wingrass
   CPU:  Unspecified   |   Platform:  MSWindows 7
---+-
Changes (by martinl):

 * milestone:  7.0.1 => 7.0.2


--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2755: Commandline switch "/S" is not working anymore

2015-10-12 Thread GRASS GIS

#2755: Commandline switch "/S" is not working anymore
---+-
  Reporter:  derseppel |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:
 Component:  Installation  |Version:  7.0.1
Resolution:|   Keywords:
   CPU:  Unspecified   |   Platform:  MSWindows 7
---+-
Changes (by derseppel):

 * Attachment "Setup_window.PNG" added.


--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2755: Commandline switch "/S" is not working anymore

2015-10-12 Thread GRASS GIS

#2755: Commandline switch "/S" is not working anymore
--+-
 Reporter:  derseppel |  Owner:  grass-dev@…
 Type:  defect| Status:  new
 Priority:  normal|  Milestone:
Component:  Installation  |Version:  7.0.1
 Keywords:|CPU:  Unspecified
 Platform:  MSWindows 7   |
--+-
 When using the "WinGRASS-7.0.1-1-Setup.exe" with the Commandline parameter
 "/S" to perform a silent installation a window appears.

 This window is asking me if I wish to install the MS Visual C++ Packages
 (see attachment).

 With the old "WinGRASS-7.0.0-1-Setup.exe" everything works fine.

 IDK which default action should be applied here. For me it would be OK
 when the installer simply does not install any MS Visual C++ Packages.

 Best way would be (maybe a lot of work to do here) to check if the VC++
 Packages are installed and add them only if they are not.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Using a dynamic text in module header for parser

2015-10-12 Thread Blumentrath, Stefan

Hi,

I would like to fill:
#% options:
and
#% answer
in a parser option for a python script dynamically.  In particular I want to 
have tickboxes for available mapsets in the module GUI...

Meaning something like this  (but less complex / not interactive):
http://permalink.gmane.org/gmane.comp.gis.grass.gui/667
My amateur programming skills do unfortunately not allow me to really 
understand how to accomplish what Glynn describes in the post above...

I tried to generate and run a temporary python script from within my script 
like this:
def main():

answer = grass.mapsets(search_path = True)
available_mapsets = str(grass.mapsets())

with tempfile.NamedTemporaryFile(delete = False) as s:
s.write('''#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Here comes the full module with header for the parser
#% options: ''' + str(','.join(available_mapsets))
...
''')
startcmd = 'python ' + s.name
os.system(startcmd)
os.remove(s.name)

But that way the GUI never starts, when I call the outer script from GRASS and 
it seems that option never get parsed...

Any hints how to proceed?

Thanks for helping in advance.

Stefan


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Using a dynamic text in module header for parser

2015-10-12 Thread Blumentrath, Stefan

Hi again,

Now I found out that the parser section in the inner python script was not 
formated properly.

However, when I now call the inner script with '--ui' I get an error:
Unable to fetch interface description for command 'tmpjksdfjiol'

Details:
Try to set up GRASS_ADDON_PATH or GRASS_ADDON_BASE variable.

It was neither possible to run the script using grass.run_command() (on 
Windows).

Cheers
Stefan



From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of 
Blumentrath, Stefan
Sent: 12. oktober 2015 11:36
To: GRASS developers list (grass-dev@lists.osgeo.org) 

Subject: [GRASS-dev] Using a dynamic text in module header for parser

Hi,

I would like to fill:
#% options:
and
#% answer
in a parser option for a python script dynamically.  In particular I want to 
have tickboxes for available mapsets in the module GUI...

Meaning something like this  (but less complex / not interactive):
http://permalink.gmane.org/gmane.comp.gis.grass.gui/667
My amateur programming skills do unfortunately not allow me to really 
understand how to accomplish what Glynn describes in the post above...

I tried to generate and run a temporary python script from within my script 
like this:
def main():

answer = grass.mapsets(search_path = True)
available_mapsets = str(grass.mapsets())

with tempfile.NamedTemporaryFile(delete = False) as s:
s.write('''#!/usr/bin/env python
# -*- coding: utf-8 -*-
# Here comes the full module with header for the parser
#% options: ''' + str(','.join(available_mapsets))
...
''')
startcmd = 'python ' + s.name
os.system(startcmd)
os.remove(s.name)

But that way the GUI never starts, when I call the outer script from GRASS and 
it seems that option never get parsed...

Any hints how to proceed?

Thanks for helping in advance.

Stefan


___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] installing v.mapcalc fails

2015-10-12 Thread Glynn Clements

Markus Neteler wrote:

>  wrote:
> ...
> > Sorry for the late follow up. The add-on installs now. When trying to run
> > it, however, nothing happens.
> 
> It does not have a parser (yet?), so I suppose it reads from stdin.

Yes.

But it doesn't have any code to read or write GRASS vectors, either. 
v.mapcalc appears to be a work-in-progress which hasn't actually made
noticeable progress since it was added.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

2015-10-12 Thread Glynn Clements

Vaclav Petras wrote:

> I like the idea of a separate header but I would leave the implementation
> in lib/gmath. Or is this going too much against how other libraries are
> done? I'm also not sure how the prefixes should work, but these seems OK
> since there are functions with same prefix (G_) in several libraries.

Having separate headers for self-contained sections of a library isn't
an issue.

Ideally, if a localised section of a library has dependencies not
required for the rest of the library, that section is a candidate for
being a separate library (so that a lack of the dependency only
disables the features which require it, rather than the entire
library).

But this isn't rigorously followed (e.g. libgis has compile-time
dependencies on iconv, pthread, regex, and zlib, even though each of
those libraries is only used for isolated features).

> Having la.h as a separate header would conveniently hide the compilation
> issue on that Debian server.
> 
> So, should I remove la.h from gmath.h?

I think so.

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

2015-10-12 Thread GRASS GIS

#2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc 
speed
--+---
  Reporter:  sprice   |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.1.0
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  ZLIB LZ4 ZSTD
   CPU:  OSX/Intel|   Platform:  MacOSX
--+---

Comment (by glynn):

 Replying to [comment:13 wenzeslaus]:

 > My question is if it wouldn't be more advantageous to create some
 wrapper which would take the all necessary inputs including compression
 type and do the necessary switches and format specific things.

 Agreed.

 In practical terms, there are only two distinct cases: uncompressed (where
 the size of the data read or written matches the size of the data stored
 in the file) and compressed (where the sizes differ). Everything else is
 just options.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GRASS will not not find laslib

2015-10-12 Thread Glynn Clements

Markus Neteler wrote:

> > But it has been obsoleted by wxpyimgview (a wxPython version), so I
> > see no reason not to simply remove it (and the wxWidgets configure
> > checks as well).
> 
> Sounds reasonable for trunk.

Done in r66476 (wximgview) and r66477 (wxWidgets configure checks).

The latter may have an impact upon macosx/app/Makefile, which
references MACOSX_ARCHS_WXPYTHON (which no longer exists).

-- 
Glynn Clements 
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2419: v.distance: hole considered as nearest area

2015-10-12 Thread GRASS GIS

#2419: v.distance: hole considered as nearest area
--+-
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  6.4.6
 Component:  Vector   |Version:  svn-releasebranch64
Resolution:  fixed|   Keywords:  v.distance holes
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by mlennert):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Replying to [comment:4 neteler]:
 > Replying to [comment:1 mmetz]:
 > > Fixed in r61987,8.
 >
 > Can the ticket be closed?

 Yes, sorry, must have forgotten about this.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2756: wxGUI CTRL+CAPS LOCK make the command line prompt font size smaller

2015-10-12 Thread GRASS GIS

#2756: wxGUI CTRL+CAPS LOCK make the command line prompt font size smaller
+-
 Reporter:  elena   |  Owner:  grass-dev@…
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:
Component:  wxGUI   |Version:  7.0.1
 Keywords:  |CPU:  x86-32
 Platform:  All |
+-
 In Win 7, but also tried in Fedora by Markus N.

 I erroneously entered the combination CTRL + CAPS LOCK while writing in
 the command line prompt in the Layer Manager and suddenly the font size
 became smaller. Keeping on doing CTRL+CAPS LOCK it became smaller and
 smaller.
 You can solve it only by doing CTRL+ "+"

 Thus:
 * CTRL + CAPS LOCK and CTRL + "-" the font size (of Layer Manager, command
 line prompt) becomes smaller
 * CTRL+ "+" the font size becomes bigger

 I don't know if it could be better to add it to this page [=#point1 (1)],
 or to create a keyboard bindings page, or whatever to do.

 Hope to be helpful.

 Thanks,

 Elena Mezzini

 [=#point1 (1)]https://grass.osgeo.org/grass70/manuals/wxGUI.html#keyboard-
 short-cuts

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

2015-10-12 Thread GRASS GIS

#2757: r.import: ERROR: Input raster map is outside current region
-+-
 Reporter:  neteler  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.0.2
Component:  Python   |Version:  svn-trunk
 Keywords:  r.import |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Both in trunk and relbranch70 (r66401 for a needed backport) I face a
 problem with r.import:


 {{{
 # get Bioclim data
 wget
 http://biogeo.ucdavis.edu/data/climate/worldclim/1_4/grid/cur/bio_2-5m_bil.zip
 # unpack bioclim1
 unzip bio_2-5m_bil.zip bio1.bil bio1.hdr
 # check
 gdalinfo bio1.bil
 Driver: EHdr/ESRI .hdr Labelled
 Files: bio1.bil
bio1.hdr
 Size is 8640, 3600
 Coordinate System is:
 GEOGCS["WGS 84",
 DATUM["WGS_1984",
 SPHEROID["WGS 84",6378137,298.257223563,
 AUTHORITY["EPSG","7030"]],
 TOWGS84[0,0,0,0,0,0,0],
 AUTHORITY["EPSG","6326"]],
 PRIMEM["Greenwich",0,
 AUTHORITY["EPSG","8901"]],
 UNIT["degree",0.0174532925199433,
 AUTHORITY["EPSG","9108"]],
 AUTHORITY["EPSG","4326"]]
 Origin = (-180.0003354,90.028)
 Pixel Size = (0.0416667,-0.0416667)
 Corner Coordinates:
 Upper Left  (-180.000,  90.000) (180d 0' 0.00"W, 90d 0' 0.00"N)
 Lower Left  (-180.000, -60.000) (180d 0' 0.00"W, 60d 0' 0.00"S)
 Upper Right ( 180.000,  90.000) (180d 0' 0.00"E, 90d 0' 0.00"N)
 Lower Right ( 180.000, -60.000) (180d 0' 0.00"E, 60d 0' 0.00"S)
 Center  (  -0.000,  15.000) (  0d 0' 0.00"W, 15d 0' 0.00"N)
 Band 1 Block=8640x1 Type=Int16, ColorInterp=Undefined
   Min=-278.000 Max=319.000
   NoData Value=-


 # The goal is to reproject and import just
 # the NC portion of the Bioclim1 map:

 GRASS 7.1.svn (nc_spm_08_grass7): > g.region -dp
 projection: 99 (Lambert Conformal Conic)
 zone:   0
 datum:  nad83
 ellipsoid:  a=6378137 es=0.006694380022900787
 north:  32
 south:  1
 west:   12
 east:   935000
 nsres:  500
 ewres:  500
 rows:   620
 cols:   1630
 cells:  1010600

 GRASS 7.1.svn (nc_spm_08_grass7): > r.import input=bio1.bil
 output=bioclim1 resample=bilinear extent=region resolution=region
 Proceeding with import of 1 raster bands...
 WARNING: Fixing subtle input data rounding error of north boundary
  (2.84217e-14>2.8e-07)
 Importing raster map ...
  100%
 Estimated target resolution for input band : 4021.79
 Reprojecting ...
 ERROR: Input raster map is outside current region
 ERROR: Unable to to reproject raster 


 # while I don't really know what -n means:
 GRASS 7.1.svn (nc_spm_08_grass7): > r.import input=bio1.bil
 output=bioclim1 resample=bilinear extent=region resolution=region -n
 Proceeding with import of 1 raster bands...
 WARNING: Fixing subtle input data rounding error of north boundary
  (2.84217e-14>2.8e-07)
 Importing raster map ...
  100%
 Estimated target resolution for input band : 4021.79
 Reprojecting ...

 GRASS 7.1.svn (nc_spm_08_grass7): > r.info -r bioclim1
 min=-nan
 max=-nan
 }}}

 The import of the requested map subset is not working.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

2015-10-12 Thread GRASS GIS

#2757: r.import: ERROR: Input raster map is outside current region
--+-
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.0.2
 Component:  Python   |Version:  svn-trunk
Resolution:   |   Keywords:  r.import
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by annakrat):

 I added r.in.gdal's -l flag, it works then, although I don't actually know
 what went wrong there.

--
Ticket URL: 
GRASS GIS 

___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

2015-10-12 Thread Dylan Beaudette

Hi,

Over the last couple of years I have noticed a very strange raster
corruption (?) issues when using r.series, and now more recently,
t.rast.series. Typically, I'll generate a large number of maps with
r.sun or t.rast.mapcalc and then aggregate the series with r.series or
t.rast.series. About 50% of the time the command runs as expected, the
other half of the time r.series or t.rast.series gives me an error
like this:

Error reading raster data for row xxx (testmap)

After this error, I can no longer perform any kind of operation on map
"testmap" without the dreaded Error reading raster data for row xxx...

The situation was worse when using a MASK map, possibly related to a
similar (fixed?) issue discussed in this thread:

http://lists.osgeo.org/pipermail/grass-dev/2015-July/075627.html

Within that thread, Glynn mentioned that this type of error was
probably related to pthreads and concurrent processes. The temporary
fix entailed:

export WORKERS=0

I have tried this on my machine but the results are the same,
non-deterministic corruption (?) of one input to r.series or
t.rast.series.

I have encountered this error on several disks, mirrored HDDs, single
HDD, and now on an SSD. I don't think that this is a disk problem,
rather, something that r.series or t.rast.series is "doing" to the
files it operates on.

Is there some possibility that one of these commands is leaving a file
"open" or in some kind of intermediate state that prevents subsequent
commands from accessing the file?

I'll try to create a sample dataset to send over. In the meantime is
there any kind of diagnostic information that I can report back with?

Thanks,
Dylan
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] installing v.mapcalc fails

2015-10-12 Thread Vaclav Petras

On Mon, Oct 12, 2015 at 6:24 AM, Glynn Clements 
wrote:
>
> Markus Neteler wrote:
>
> >  wrote:
> > ...
> > > Sorry for the late follow up. The add-on installs now. When trying to
run
> > > it, however, nothing happens.
> >
> > It does not have a parser (yet?), so I suppose it reads from stdin.
>
> Yes.
>
> But it doesn't have any code to read or write GRASS vectors, either.
> v.mapcalc appears to be a work-in-progress which hasn't actually made
> noticeable progress since it was added.

Then I suggest to remove it from the Makefile parent directory and also
disable it in the addons build scripts if there is something more needed
than r66406 [1] which is blacklisting it somehow already. It does not
fulfill what user would expect (at least some functionality). Those who
want to continue development will get it through svn.

I'm not sure happened [2] with the v.mapcalc implemented as a test case in
GSoC [3] and if the functionality can be still used. But this seems like a
good alternative to the code in addons.

Vaclav

[1] https://trac.osgeo.org/grass/changeset/66406
[2] https://lists.osgeo.org/pipermail/grass-dev/2013-October/065908.html
[3]
https://grasswiki.osgeo.org/wiki/GRASS_GSoC_2013_Temporal_GIS_Algebra_for_raster_and_vector_data_in_GRASS#v.mapcalc
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #2755: Commandline switch "/S" is not working anymore

Re: [GRASS-dev] [GRASS GIS] #2755: Commandline switch "/S" is not working anymore

Re: [GRASS-dev] [GRASS GIS] #2755: Commandline switch "/S" is not working anymore

[GRASS-dev] [GRASS GIS] #2755: Commandline switch "/S" is not working anymore

[GRASS-dev] Using a dynamic text in module header for parser

Re: [GRASS-dev] Using a dynamic text in module header for parser

Re: [GRASS-dev] installing v.mapcalc fails

Re: [GRASS-dev] [GRASS-SVN] r66413 - grass-addons/grass7/vector/v.kriging

Re: [GRASS-dev] [GRASS GIS] #2750: LZ4 when writing raster rows; better than double I/O bound r.mapcalc speed

Re: [GRASS-dev] GRASS will not not find laslib

Re: [GRASS-dev] [GRASS GIS] #2419: v.distance: hole considered as nearest area

[GRASS-dev] [GRASS GIS] #2756: wxGUI CTRL+CAPS LOCK make the command line prompt font size smaller

[GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

Re: [GRASS-dev] [GRASS GIS] #2757: r.import: ERROR: Input raster map is outside current region

[GRASS-dev] Error reading raster data for row xxx (only when using r.series and t.rast.series)

Re: [GRASS-dev] installing v.mapcalc fails

16 matches

Site Navigation

Mail list logo

Footer information