date:20190110

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

2019-01-10 Thread Anna Petrášová

On Thu, Jan 10, 2019 at 7:08 AM Maris Nartiss  wrote:

> trešd., 2019. g. 9. janv., plkst. 18:47 — lietotājs Markus Neteler
> () rakstīja:
> >
> > On Wed, Jan 9, 2019 at 4:01 PM Maris Nartiss 
> wrote:
> > ...
> > > Too late. Python is already broken (I had to fix my scripts;
> > > previously working tests are now broken). Do not expect your 7.2/7.4
> > > Python scripts to work with 7.6/7.8 without modifications (depends on
> > > functionality in use).
> >
> > This is weird. Can you elaborate?
> Unfortunately I just fixed my code and moved on (as transitioning to
> Python 3 has to be done). But here are two examples from the top of my
> head:
> https://trac.osgeo.org/grass/ticket/3707
> grass.script.parse now returns unicode strings, previously – byte
> strings (too lazy to search for a specific revision when it was
> introduced). Took a while to understand why calls to an external
> library started to fail.
>

All the recent Python3 changes are in 7.8 only. Pietro did some Python 3
changes early on (not sure which version), unfortunately these were not
clearly communicated. In general, all Python API functions should now
(since 7.8) return unicode (for both Python 2 and 3), because that's what
users would expect with python 3.

It's hard to know exactly how much work is still needed, because tests
cover just part of the codebase. GUI is mostly working, some issues might
come up for less used components, but these are mostly easy to fix, some of
the issues are due to the switch to wxPython 4 (wxPython 3 doesn't support
Python3). Python components with ctypes need more work. PyGRASS is getting
there, tests should be mostly running (not doctests), but there is more
work with temporal framework. Add-ons will probably need some small
adjustments, but I haven't looked at that. Of course, I am testing only
linux now.

Anna

>
> > > Still – it is not so bad – some Python parts never have been working
> > > correctly anyway ;-)
> >
> > Please open ticket(s) if you want to see it fixed.
> This is really tricky as for many aspects of GRASS Python code there
> are no working examples in the GRASS source or add-ons and thus it is
> hard to understand if it is broken or just "I'm holding it the wrong
> way" ;-)
> I'll try to come up with a test case for raster.history, as it is one
> of things I can not get working at the moment.
>
> > Markus
> Māris.
> ___
> 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] [release planning] GRASS GIS 7.8.0 with Python3 support

2019-01-10 Thread Maris Nartiss

trešd., 2019. g. 9. janv., plkst. 18:47 — lietotājs Markus Neteler
() rakstīja:
>
> On Wed, Jan 9, 2019 at 4:01 PM Maris Nartiss  wrote:
> ...
> > Too late. Python is already broken (I had to fix my scripts;
> > previously working tests are now broken). Do not expect your 7.2/7.4
> > Python scripts to work with 7.6/7.8 without modifications (depends on
> > functionality in use).
>
> This is weird. Can you elaborate?
Unfortunately I just fixed my code and moved on (as transitioning to
Python 3 has to be done). But here are two examples from the top of my
head:
https://trac.osgeo.org/grass/ticket/3707
grass.script.parse now returns unicode strings, previously – byte
strings (too lazy to search for a specific revision when it was
introduced). Took a while to understand why calls to an external
library started to fail.

> > Still – it is not so bad – some Python parts never have been working
> > correctly anyway ;-)
>
> Please open ticket(s) if you want to see it fixed.
This is really tricky as for many aspects of GRASS Python code there
are no working examples in the GRASS source or add-ons and thus it is
hard to understand if it is broken or just "I'm holding it the wrong
way" ;-)
I'll try to come up with a test case for raster.history, as it is one
of things I can not get working at the moment.

> Markus
Māris.
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

[GRASS-dev] [GRASS GIS] #3729: Python export in Graphical modeler does not refrect global overwrite flag

2019-01-10 Thread GRASS GIS

#3729: Python export in Graphical modeler does not refrect global overwrite flag
-+-
 Reporter:  martinl  |  Owner:  grass-dev@…
 Type:  defect   | Status:  new
 Priority:  normal   |  Milestone:  7.6.0
Component:  wxGUI|Version:  svn-trunk
 Keywords:  gmodeler |CPU:  Unspecified
 Platform:  Unspecified  |
-+-
 Steps to reproduce:

 1. Open model in Graphical modeler
 2. Enable global overwrite options in `Model->Properties`
 3. Go to `Python editor` tab and pres Run
 4. Run Python script again (fails on existing data)

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] r.estimap.recreation add-on licensed by the European Commission

2019-01-10 Thread Nikos Alexandris

Dear Paulo,

thank you for your interest. The documentation (still) deserves some
love and I will update it as soon as I can.

I tried to design the module after the algorithm but still give it
a lot of flexibility. Such that one can, exactly, use
other sources of input maps (i.e. a land use map other than the
"default" CORINE).

I am working to ensure the add-on will work under Windows (it does for
me and expectedly it will work in general) as well as to enable easy
access to it via QGIS.

I wish you and all Love and Beautiful Moments in 2019.

Nikos

* Paulo van Breugel [2018-12-31 12:27:39 +0100]:

Daar Nikos,

This looks like a very interesting addon, thanks. The documentation on
gitlab provides a clear example too, great. I'll give it a try in the
coming days.

I am curious how easy it will be to use this to make potential maps
for other types of land use. Reading the article on ESTIMAP might give
me a better idea ;-).

Cheers and, as we are near the end of 2018… a Happy New year

Paulo

On December 31, 2018 11:08:55 AM Nikos Alexandris
wrote:

Dear community,

I am contented to announce the decision by the European Commission [0]
to release the GRASS GIS add-on `r.estimap.recreation` [1] as Open Source
Software under the European Union Public Licence (EUPL).

[0]
https://gitlab.com/natcapes/r.estimap.recreation/blob/master/C_2018_8970_F1_COMMISSION_DECISION_EN_V3_P1_1006093.PDF
[1] https://gitlab.com/natcapes/r.estimap.recreation

In addition, the add-on shall be distributed under the GNU General Public
License (v2 or later) if that becomes a requirement for its distribution
through the official GRASS GIS Add-ons repository [2].

[2] https://grass.osgeo.org/download/addons/

I cordially thank Pedro Malaquias (Legal Officer, Central IP Service of the
European Commission, Joint Research Centre) for his support and deep
knowledge on the licensing issues to make this happen.

Re: [GRASS-dev] [GRASS GIS] #3669: graphical modeler: export UI definitions into Python script

2019-01-10 Thread GRASS GIS

#3669: graphical modeler: export UI definitions into Python script
--+-
  Reporter:  martinl  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  wxGUI|Version:  svn-trunk
Resolution:   |   Keywords:  modeler, python, ui
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by pesekon2):

 * Attachment "gmodeler_python_parameterization.diff" added.

 graphical modeler: export UI definitions into Python script

-- 
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 GIS] #3726: special characters in psmap scalebar unit

2019-01-10 Thread GRASS GIS

#3726: special characters in psmap scalebar unit
--+-
  Reporter:  1266 |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:
 Component:  Default  |Version:  svn-releasebranch76
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by mlennert):

 Replying to [ticket:3726 1266]:
 > special characters are not correctly displayed for psmap module
 scalebar.
 > For example:
 > scalebar s
 > units kilometers
 > ...
 > does not display special characters of kilom[è]tres in french.

 Just guessing here, but could it be that the translated strings (po files)
 are in UTF-8 while ps.map expects all strings to be iso-8859-1 ? In
 [https://trac.osgeo.org/grass/browser/grass/trunk/ps/ps.map/do_scalebar.c#L193
 do_scalebar.c] there is:


 {{{
 193 else if(sb.units == SB_UNITS_KM)
 194 strcpy(num, _("kilometers"));
 }}}

 so kilometers is translated and that's why you automatically get the non-
 ascii characters, but in a different encoding than the one expected.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.0 with Python3 support

[GRASS-dev] [GRASS GIS] #3729: Python export in Graphical modeler does not refrect global overwrite flag

Re: [GRASS-dev] r.estimap.recreation add-on licensed by the European Commission

Re: [GRASS-dev] [GRASS GIS] #3669: graphical modeler: export UI definitions into Python script

Re: [GRASS-dev] [GRASS GIS] #3726: special characters in psmap scalebar unit

6 matches

Site Navigation

Mail list logo

Footer information