[GRASS-dev] [gdal-dev] RFC 73 merged in master / PROJ master required

[Helmut Kudrnovsky]

fyi
[https://lists.osgeo.org/pipermail/gdal-dev/2019-January/049681.html]


--
All,

RFC 73 work has now been merged into master. Currently GDAL build
and runtime now depends on PROJ master

More details of the past month work at:
https://erouault.blogspot.com/2019/01/srs-barn-raising-8th-report-ready-for.html

Let me underline its conclusion:
"""As all those changes done those last months deeply impact SRS related
functionnality in GDAL and PROJ, we rely now on your careful testing to
spot the inevitable issues that have not yet been detected by their
respective automatic regression test suites. The earlier they are detected,
the easier they will be fixable, in particular if they impact the API."""

Even

-- 
--



-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Migration to git, use addons as test case?

[Nikos Alexandris]

A bit late, my "outsider" view, even if some points are known/repeatedly
discussed:

- I prefer gitlab

- Pragmatically, however, github is still "bigger"

- Allow me (to reiterate) please: it is important to "open-up" to as many
 contributors, any kind of, as possible--thus, a decentralised
 repository is the way to go.  Perhaps I am not that attached to SVN to
 know it well, but I shouldn't be worried or need to check
 multiple times each time I decide to commit something (in my case, the
 Add-ons repository). I can break local GRASS GIS repositories as
 many times without worries core developers will accept if and when they
 judge some request is ready for merging in.

- If the PSC decides for an in-house solution (i.e. OSGeo's
 infrastructure or else), consider perhaps some additional workload,
 to implement/integrate authorisation and login mechanisms, or similar,
 stuff that all "big" players have seamlessly working.


On/Off-topic:

- Add-ons should be only accepted along with some basic unit test

- Please consider also using new ways of interacting: slack or similar?

Cheers, Nikos


* Stefan Blumentrath  [2019-01-27 10:37:02
* +]:


Hi again,


Having browsed some of the historical discussion and arguments made,
moving to gitlab.com seems like a natural choice to me personally
nowadays (with github beeing bought by Microsoft). If we (and equally
important also OSGeo) see a significant advantage of hosting it in
OSGeo infrastructure it seems to be doable to import/export projects
that way.

If competetive copy-left solutions (like e.g. sr.ht or gitea) emerge
and there pop up push factors to leave gitlab.com pluss hosting on
OSGeo infrastructure is considered robust enough I would expect
migration tools will be developed / provided (like import / export
functions in gitlab).


So, I would be happy with a PSC decision on git hosting to speed up the
process (as I in fact don have strong opinions here), but if you want
to collect user and developer perspectives in advance, the drafted
google-forms-survey could be launched as soon as on Monday (tomorrow),
if of interest.


Cheers

Stefan

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

Re: [GRASS-dev] Fwd: [OSGeo-Discuss] FOSS4G 2019 Bucharest Call for Contributions Open

[Luca Delucchi]

On Fri, 25 Jan 2019 at 11:49, Moritz Lennert
 wrote:
>
> Who else will come to Bucharest ? Anyone willing to (co-)organise a
> workshop ?
>

I will but I cannot choose the dates yet. I can help to co-organise...

> What topics would users find the most useful for a workshop ?
>

temporal series
remote sensing
classification

??

> Moritz
>


-- 
ciao
Luca

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

Re: [GRASS-dev] [GRASS GIS] #3502: v.proj location not set in dialog

[GRASS GIS]

#3502: v.proj location not set in dialog
+-
  Reporter:  balagates  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.2.4
 Component:  wxGUI  |Version:  7.4.0
Resolution: |   Keywords:  v.proj location
   CPU:  OSX/Intel  |   Platform:  MacOSX
+-

Comment (by balagates):

 I created a small test program in Python to examine wx.ComboBox() events
 (attached).  This confirms my suspicions that on my macOS system changing
 the value of the ComboBox value through the pulldown menu only generates a
 wx.EVT_COMBOBOX event.  It does not generate a wx.EVT_TEXT event.  On my
 Ubuntu system changing the value of the ComboBox value through the
 pulldown menu generates both a wx.EVT_COMBOBOX event and wx.EVT_TEXT
 event.  When the text is manually edited by typing both systems generate a
 wx.EVT_TEXT for each keypress.

 The wxPython documentation at https://docs.wxpython.org/wx.ComboBox.html
 seems inconclusive about what events should be generated for each action.

 * EVT_COMBOBOX: Process a wxEVT_COMBOBOX event, when an item on the list
 is selected. Note that calling GetValue returns the new value of
 selection.
 * EVT_TEXT: Process a wxEVT_TEXT event, when the combobox text changes.

 I could interpret this both ways.  The fundamental question is whether
 these two events should be interpreted as:

 * EVT_COMBOBOX_CHANGE and EVT_TEXT_EDIT_CHANGE
 or
 * EVT_COMBOBOX_CHANGE and EVT_VALUE_CHANGE

 It is unclear if the wx intention was to generate a 1:1 mapping between
 change method and event.  Neither system generates any events when you use
 the ComboBox pulldown and select the element that is already selected.

 It would be interesting to see how this behaves on a Windows system,
 however, majority behavior probably doesn't imply correctness.

 In the Grass v.proj case I cannot see a common use for manually editing
 the values.  Sure, it might be quicker for someone with a long list of
 similarly named elements to manually edit, but I think the idea of
 populating the ComboBox is to avoid typing mistakes.

 Potentially this could affect the Grass Python GUI other places so it
 probably deserves more investigation.

-- 
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] #3502: v.proj location not set in dialog

[GRASS GIS]

#3502: v.proj location not set in dialog
+-
  Reporter:  balagates  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.2.4
 Component:  wxGUI  |Version:  7.4.0
Resolution: |   Keywords:  v.proj location
   CPU:  OSX/Intel  |   Platform:  MacOSX
+-
Changes (by balagates):

 * Attachment "wx_combo_events.py" added.

 wx.ComboBox behavior test program

-- 
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] #3745: gunittest reporter message improvement

[GRASS GIS]

#3745: gunittest reporter  message improvement
--+---
  Reporter:  neteler  |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.8.0
 Component:  Tests|Version:  svn-trunk
Resolution:   |   Keywords:  python, gunittest
   CPU:  All  |   Platform:  All
--+---
Changes (by neteler):

 * Attachment "gunittest_reporter.diff" added.

 Attempt to improve gunittest reporter msgs

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] [GRASS GIS] #3745: gunittest reporter message improvement

[GRASS GIS]

#3745: gunittest reporter  message improvement
---+-
 Reporter:  neteler|  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:  7.8.0
Component:  Tests  |Version:  svn-trunk
 Keywords:  python, gunittest  |CPU:  All
 Platform:  All|
---+-
 I tried to improve the unit test reporting message with a small detail:
 adding
 the amount of total tests. My attempt is the attached patch but it doesn't
 really work:

 {{{
 test_v_rast_stats from ./scripts/v.rast.stats failed (3 tests out of 6
 failed)
 test_what_strds from ./scripts/v.what.strds failed (1 test out of 1
 failed)
 ...
 test.t.vect.list from ./temporal/t.vect.list failed
 test.t.merge from ./temporal/t.merge failed
 test.t.vect.observe.strds.relative from ./temporal/t.vect.observe.strds
 failed
 test.t.vect.observe.strds from ./temporal/t.vect.observe.strds failed
 test_snap from ./temporal/t.snap failed (6 tests out of 6 failed)
 test_raster_algebra from ./temporal/t.rast.algebra failed (77 tests
 out of 40 failed)
 ...
 }}}

 In any case, the percentage might be better but no idea how to extract
 that.

-- 
Ticket URL: 
GRASS GIS 

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