Re: [GRASS-dev] Programmatically obtain GRASS colour ramps in Python

[Vaclav Petras]

Hi Pierre,

If you would turn this into a add-on module it could eventually became the
portable way to do that... Having this functionality makes sense.

Vaclav

On Mon, Sep 17, 2018 at 3:28 PM Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> r.colors manual says color ramps are saved in:
> $GISBASE/etc/colors/, so values could be read from there, I guess.
>
> And the parser can give you GUI access to the rules names with the
> G_OPT_M_COLR option:
> https://grass.osgeo.org/grass77/manuals/parser_standard_options.html
>
> Cheers
> Stefan
>
>
> -Original Message-
> From: grass-dev  On Behalf Of Markus
> Neteler
> Sent: mandag 17. september 2018 20:15
> To: Pierre Roudier 
> Cc: GRASS developers list 
> Subject: Re: [GRASS-dev] Programmatically obtain GRASS colour ramps in
> Python
>
> On Mon, Sep 17, 2018 at 4:17 AM Pierre Roudier 
> wrote:
> >
> > Hi all,
> >
> > I am trying to write a little Python extension wrapping r.color to use
> > different kind of strecthes,
> >
> > It should be pretty simple, basically just builkding rules on-the-fly
> > and pass them to r.color. But I can't quite seem how to retrieve the
> > GRASS color ramps details to create my ruleset.
> >
> > Is there any portable way to actually to actually passthe name of a
> > GRASS color ramp, and get the details (colours) of that colour ramp?
>
> Maybe you can find some code here:
>
> gui/wxpython/modules/colorrules.py
>
> best
> Markus
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Programmatically obtain GRASS colour ramps in Python

[Stefan Blumentrath]

r.colors manual says color ramps are saved in:
$GISBASE/etc/colors/, so values could be read from there, I guess.

And the parser can give you GUI access to the rules names with the
G_OPT_M_COLR option:
https://grass.osgeo.org/grass77/manuals/parser_standard_options.html

Cheers
Stefan


-Original Message-
From: grass-dev  On Behalf Of Markus Neteler
Sent: mandag 17. september 2018 20:15
To: Pierre Roudier 
Cc: GRASS developers list 
Subject: Re: [GRASS-dev] Programmatically obtain GRASS colour ramps in Python

On Mon, Sep 17, 2018 at 4:17 AM Pierre Roudier  wrote:
>
> Hi all,
>
> I am trying to write a little Python extension wrapping r.color to use 
> different kind of strecthes,
>
> It should be pretty simple, basically just builkding rules on-the-fly 
> and pass them to r.color. But I can't quite seem how to retrieve the 
> GRASS color ramps details to create my ruleset.
>
> Is there any portable way to actually to actually passthe name of a 
> GRASS color ramp, and get the details (colours) of that colour ramp?

Maybe you can find some code here:

gui/wxpython/modules/colorrules.py

best
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Programmatically obtain GRASS colour ramps in Python

[Markus Neteler]

On Mon, Sep 17, 2018 at 4:17 AM Pierre Roudier  wrote:
>
> Hi all,
>
> I am trying to write a little Python extension wrapping r.color to use
> different kind of strecthes,
>
> It should be pretty simple, basically just builkding rules on-the-fly
> and pass them to r.color. But I can't quite seem how to retrieve the
> GRASS color ramps details to create my ruleset.
>
> Is there any portable way to actually to actually passthe name of a
> GRASS color ramp, and get the details (colours) of that colour ramp?

Maybe you can find some code here:

gui/wxpython/modules/colorrules.py

best
Markus
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS-SVN] r73360 - grass/branches/releasebranch_7_6/scripts/r.import

[Markus Metz]

On Mon, Sep 17, 2018 at 3:39 PM Moritz Lennert 
wrote:
>
> Markus,
>
> Could you explain this ? Does this mean that the memory parameter in
> r.in.gdal is now automagic ? Or why doesn't it make sens to let the user
> define in r.import the memory size ?

Markus N and me were discussing this together: r73360 removes the 2047 MB
limit in r.import, nothing else. It is now possible in r.import to define
memory larger than 2047 MB. r.in.gdal has this limit only for GDAL 1.8 and
earlier and does the checks (r.in.gdal will take care of the memory answer).

Markus M

>
> Moritz
>
> On 17/09/18 15:30, svn_gr...@osgeo.org wrote:
> > Author: neteler
> > Date: 2018-09-17 06:30:25 -0700 (Mon, 17 Sep 2018)
> > New Revision: 73360
> >
> > Modified:
> > grass/branches/releasebranch_7_6/scripts/r.import/r.import.py
> > Log:
> > r.import: remove hardcoded memory limit (r.in.gdal will take care)
> >
> > Modified: grass/branches/releasebranch_7_6/scripts/r.import/r.import.py
> > ===
> > --- grass/branches/releasebranch_7_6/scripts/r.import/r.import.py
2018-09-17 13:29:35 UTC (rev 73359)
> > +++ grass/branches/releasebranch_7_6/scripts/r.import/r.import.py
2018-09-17 13:30:25 UTC (rev 73360)
> > @@ -39,7 +39,6 @@
> >   #% type: integer
> >   #% required: no
> >   #% multiple: no
> > -#% options: 0-2047
> >   #% label: Maximum memory to be used (in MB)
> >   #% description: Cache size for raster rows
> >   #% answer: 300
> >
> > ___
> > grass-commit mailing list
> > grass-com...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/grass-commit
> >
>
>
> ___
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3648: Error when using WMS on Windows

[GRASS GIS]

#3648: Error when using WMS on Windows
-+-
 Reporter:  annakrat |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.6.0
Component:  Python   |Version:  unspecified
 Keywords:  WMS  |CPU:  Unspecified
 Platform:  MSWindows 8  |
-+-
 When using r.in.wms (through the GUI or directly), I get:

 `Errno 10054 An existing connection was forcibly closed by the remote
 host.`

 The wms service is:

 
`https://services.nationalmap.gov/arcgis/services/USGSNAIPPlus/MapServer/WMSServer?`

 Looking at the code in wms_base.py
 
(https://trac.osgeo.org/grass/browser/grass/trunk/scripts/r.in.wms/wms_base.py#L270)

 it boils down to:


 {{{
 >>> from urllib2 import urlopen
 >>>
 
urlopen('https://services.nationalmap.gov/arcgis/services/USGSNAIPPlus/MapServer/WMSServer?=WMS=GetCapabilities=1.3.0')
 }}}

 which gives the error.

 When you paste the URL to browser, it works. Also r.in.wms with this wms
 service works on linux.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [GRASS-SVN] r73360 - grass/branches/releasebranch_7_6/scripts/r.import

[Moritz Lennert]

Markus,

Could you explain this ? Does this mean that the memory parameter in 
r.in.gdal is now automagic ? Or why doesn't it make sens to let the user 
define in r.import the memory size ?


Moritz

On 17/09/18 15:30, svn_gr...@osgeo.org wrote:

Author: neteler
Date: 2018-09-17 06:30:25 -0700 (Mon, 17 Sep 2018)
New Revision: 73360

Modified:
grass/branches/releasebranch_7_6/scripts/r.import/r.import.py
Log:
r.import: remove hardcoded memory limit (r.in.gdal will take care)

Modified: grass/branches/releasebranch_7_6/scripts/r.import/r.import.py
===
--- grass/branches/releasebranch_7_6/scripts/r.import/r.import.py   
2018-09-17 13:29:35 UTC (rev 73359)
+++ grass/branches/releasebranch_7_6/scripts/r.import/r.import.py   
2018-09-17 13:30:25 UTC (rev 73360)
@@ -39,7 +39,6 @@
  #% type: integer
  #% required: no
  #% multiple: no
-#% options: 0-2047
  #% label: Maximum memory to be used (in MB)
  #% description: Cache size for raster rows
  #% answer: 300

___
grass-commit mailing list
grass-com...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-commit




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

Re: [GRASS-dev] [GRASS GIS] #613: clean_temp: not safe for concurrent use

[GRASS GIS]

#613: clean_temp: not safe for concurrent use
--+--
  Reporter:  hamish   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.6.0
 Component:  Startup  |Version:  6.4.0 RCs
Resolution:  fixed|   Keywords:  clean_temp init grass.py
   CPU:  All  |   Platform:  All
--+--

Comment (by hamish):

 Replying to [comment:4 wenzeslaus]:
 > Note: There is another `clean_temp` at the end. My assumption is that
 the start
 > time one is meant to clean the mapset just in case.

 Yes exactly right, as the previous session may have ended uncleanly with a
 crash/kill/reboot.


 best,
 Hamish

-- 
Ticket URL: 
GRASS GIS 

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