Re: [GRASS-dev] [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

Dear all, I'm answering here rather than the "[GRASS-dev] External providers in QGIS" thread since here we have the technical discussion already. I'm also removing grass-user list. On Mon, Feb 5, 2018 at 3:56 PM, Stefan Blumentrath < stefan.blumentr...@nina.no> wrote: > > The text descriptor

Re: [GRASS-dev] External providers in QGIS

2018-02-06 23:34 GMT+01:00 Helmut Kudrnovsky : > yes, that is part of the 'proactively thinking' what I mean. draft of idea added [1]. Feel free to improve/extend :-) Ma [1] https://trac.osgeo.org/grass/wiki/GSoC/2018#ImproveGRASSintegrationinQGIS3 -- Martin Landa

[GRASS-dev] New addon: i.pysptools.unmix

Dear all, I just committed a new addon (i.pysptools.unmix) which is a wrapper around the endmember extraction and spectral unmixing functionality in the pysptools python library [1]. Feedback will be gladly received! Cheers Stefan [1]: https://pypi.python.org/pypi/pysptools

Re: [GRASS-dev] External providers in QGIS

Martin Landa wrote > Hi, > > 2018-02-06 23:12 GMT+01:00 Helmut Kudrnovsky > hellik@ > : >> this is part of QGIS success and this question has also to be answered by >> the QGIS community. >> >> This may be an indication that OSGeo's inter-project communication should >> be >> proactively

Re: [GRASS-dev] External providers in QGIS

Hi, 2018-02-06 23:12 GMT+01:00 Helmut Kudrnovsky : > this is part of QGIS success and this question has also to be answered by > the QGIS community. > > This may be an indication that OSGeo's inter-project communication should be > proactively improved in the future. could be

Re: [GRASS-dev] External providers in QGIS

Hi Paolo, pcav wrote > Hi all, > following the discussion on qgis-dev ML: > https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html > it has been proposed to remove all external providers (namely OTB, > already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will >

Re: [GRASS-dev] r.in.gdal changes range of values for sentinel bands (?)

On Tue, Feb 6, 2018 at 10:25 AM, Veronica Andreo wrote: > > Sorry, sorry... that was a different band... I realize now. So, for the record, no issues, > gdalinfo -mm T21KZP_20171212T134159_B02.jp2 > reports the same range as the one I see after importing in grass. > >

Re: [GRASS-dev] [GRASS GIS] #3491: i.group cannot read from other mapsets

#3491: i.group cannot read from other mapsets --+- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: Component: Imagery |Version: unspecified

[GRASS-dev] External providers in QGIS

Hi all, following the discussion on qgis-dev ML: https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html it has been proposed to remove all external providers (namely OTB, already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will remain as QGIS cannot be built

Re: [GRASS-dev] [GRASS GIS] #3489: integrate grass session lib

#3489: integrate grass session lib --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: closed Priority: normal | Milestone: 7.6.0 Component: Python |Version: svn-trunk Resolution:

Re: [GRASS-dev] [GRASS GIS] #3489: integrate grass session lib

#3489: integrate grass session lib --+- Reporter: martinl | Owner: grass-dev@… Type: task | Status: new Priority: normal | Milestone: 7.6.0 Component: Python |Version: svn-trunk Resolution:

Re: [GRASS-dev] Failure to register map in an STRDS (due to a faulty timestamp?)

* Nikos Alexandris [2018-02-06 16:17:19 +0100]: Dear list, among a set of timestamped raster maps, one fails to register in an STRDS. I.e., when trying to register this single raster map t.register --o input=lst map=lst_LC81930282015116LGN00 returns ERROR:

[GRASS-dev] Failure to register map in an STRDS (due to a faulty timestamp?)

Dear list, among a set of timestamped raster maps, one fails to register in an STRDS. I.e., when trying to register this single raster map t.register --o input=lst map=lst_LC81930282015116LGN00 returns ERROR: 'NoneType' object has no attribute 'tzinfo'. This leads to something like a

[GRASS-dev] [GRASS GIS] #3491: i.group cannot read from other mapsets

#3491: i.group cannot read from other mapsets -+- Reporter: sbl | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: Component: Imagery |Version: unspecified Keywords:

Re: [GRASS-dev] [GRASS GIS] #3490: pygrass: improve error messages for table handling

#3490: pygrass: improve error messages for table handling -+--- Reporter: sbl | Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: Component: Python |Version: unspecified Resolution:

[GRASS-dev] [GRASS GIS] #3490: pygrass: improve error messages for table handling

#3490: pygrass: improve error messages for table handling ---+- Reporter: sbl| Owner: grass-dev@… Type: defect | Status: new Priority: normal | Milestone: Component:

Re: [GRASS-dev] r.in.gdal changes range of values for sentinel bands (?)

Sorry, sorry... that was a different band... I realize now. So, for the record, no issues, gdalinfo -mm T21KZP_20171212T134159_B02.jp2 reports the same range as the one I see after importing in grass. Computed Min/Max=15.000,17547.000 Again, sorry for the noise and thanks for the -mm hint, MM :)