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

[Vaclav Petras]

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 files have been a real pain for maintaining interfaces
> for GRASS integration in Processing as well as the GRASS plugin. In
> addition, they make usage of AddOns practically impossible for most of the
> QGIS users.
>


There were already suggestions to change it in the past to something based
on "--interface-description", but it always hit various issues like those
things you mention below. However, I think that it is exactly what needs to
be done in any case because only that is sustainable and potentially also
reusable by other tools (besides QGIS). The reuse is quite interesting also
in the relation to the automatic import, export and temporary location (in
context of --exec or grass_session).



>
>
> However, for QGIS (and this is true for both integrations), the module UI
> was deliberately simplified by hiding / removing “advanced” option or
> splitting modules into “sub-types”.
>

Here the question is how important it is to do (keep) this or if perhaps
different solution would give better result. For example, splitting (in the
QGIS interface) r.slope.aspect to r.slope and r.aspect (and more) makes it
slower for the user to compute slope and aspect - 2x filling the form and
2x loading input data. Reorganization of r.slope.aspect interface may
result in more convenient form and shorter computation than the "r.slope +
r.aspect" solution.


> In addition not all modules could be meaningful added to the two QGIS
> integrations (e.g. temporal modules in Processing).
>


I think there needs to be a white list or back list. It seems analogous to
the "toolboxes" for wxGUI. All r3.* and t.* modules are out for QGIS, but I
think the rest needs to be hand picked. The limitation of the hand picking
is that it does not work for addons and custom modules in general.



> And finally, some require extra work on the QGIS side (like r.mapcalc).
>

We should address this ASAP in the process. Besides r.mapcalc, it is esp.
modules which output list of maps which are either time series (e.g.
r.sim.water with -t) or multiple results (e.g. r.texture method=asm,var
output=basename). (There is a discussion about this somewhere on the list.)
I'm not sure what is the current solution for i.* which take a group,
perhaps a list or a multiband file is good (?). In relation that, t.* and
r3.* modules could take and output a list of maps (multiband) as well.


>
>
> So, I would assume that a --qgis-descriptor solution would be most
> appropriate.
>

It can be "m.odule.name --qgis-descriptor" or "g.get.interface module=
m.odule.name format=qgis" which can take the general (or generalized)
--interface-description and transform it to what the processing adapter
tool needs (or it can be just part of the adapter).



> But that would still require additional work (beyond implementing a parser
> solution) if the principles for the GRASS module UI in QGIS should stay as
> it is, like:
>
> -  Tagging options and flags as advanced or basic/main/common
>

We already have the sections and also required parameters marked (in GUI),
so the question is why it is not enough. Perhaps just fixing that is enough
(for example description for each group). But of course if we say that the
requirement for QGIS alg is that there is less than 5 options and no flags,
then we need some additional system.


> (could be an opportunity to consolidate terminology in the module UI in
> GRASS as well)
>

I think one of the challenges brought up in the past was GRASS terminology
versus QGIS terminology. We don't have a comparison table for that, but we
have one for ArcGIS [1] and there are some obvious things like "vector map"
versus "vector layer" and than GRASS' "layer of vector map".

I can see 3 solutions: 1) ignore the differences, 2) come up with different
names (I think we have been there already), or 3) have a special
description field which is QGIS-friendly or OGC glossary compliant if
needed.

[1]
https://grasswiki.osgeo.org/wiki/Terminology_comparison_between_ArcGIS_and_GRASS_GIS


> -  Deciding which modules to use / exclude from QGIS (and how to
> mark them)
>

We have the "toolbox" mechanism to populate things in wxGUI, so the files
can be reused to create algorithm tree for QGIS. One needs to add the
modules there explicitly and then additionally find addons, but we do that
for wxGUI now.


> -  …
>
> Maybe also Ondrejs work could be useful here :
> https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI ?
>


Yes, for the QGIS GRASS plugin. I'm not sure how much the plugin is part of
this discussion. Not long ago, Radim worked on it a lot. Ondrej's work is
aimed at what the C++ plugin is aimed at and what wxGUI is aimed at - i.e.
it's a 

Re: [GRASS-dev] External providers in QGIS

[Martin Landa]

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
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[Stefan Blumentrath]

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
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Helmut Kudrnovsky]

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 improved in the future.
> 
> could be probably nice GSoC project too (GRASS provider in QGIS3). Ma

yes, that is part of the 'proactively thinking' what I mean. 

not all possible opportunities to improve things are considered
beforehand... 





-
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] External providers in QGIS

[Martin Landa]

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 probably nice GSoC project too (GRASS provider in QGIS3). Ma

-- 
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] External providers in QGIS

[Helmut Kudrnovsky]

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
> remain as QGIS cannot be built without). This raised a number of
> concerns, so PSC decided not to rush removing them from the upcoming 3.0
> release, and to open a wider discussions about this, involving all the
> interested parties, to find an optimal solution.
> If volunteers outside QGIS core team, ideally from the respective
> backends, could take the maintenance of these providers, not much would
> change for the end user. If not, this will mean effectively missing
> hundreds of algs from QGIS.
> I personally propose to reinstate the OTB plugin with Rashad (from OTB)
> as maintainer.
> QGIS.ORG will seek to support any decision made with funding where
> possible.
> Looking forward for your feedback.
> All the best.
> -- 
> Paolo Cavallini

thanks for the follow up on this discussion.

Is there already a concrete technical documention of requirements, methods,
API, interface etc by QGIS how alg providers work/should work/be maintained?

This may ease and accelerate to start a discussion in the communities of
algs providers like OTB, GRASS, SAGA and others how to proceed in this
inter-project challenge.

>If not, this will mean effectively missing 
>hundreds of algs from QGIS. 

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.



-
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] r.in.gdal changes range of values for sentinel bands (?)

[Markus Metz]

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.
>
> Computed Min/Max=15.000,17547.000
>
> Again, sorry for the noise and thanks for the -mm hint, MM :)

Good to hear that gdalinfo -mm and GRASS stats are indeed identical.

A hint: use r.info -s instead of r.univar -g for simple stats (number of
non-null cells, min, max, mean, stddev)  on the full raster map, it's
faster.

The reason why gdalinfo with and without -mm might report different values
is that some software creating raster datasets for some obscure reason
estimates min, max, mean, stddev and for some even more obscure reason
writes these estimates to metadata. At least regarding min, max one would
expect actual min, max, not some estimate with estimated min > actual min
and estimated max < actual max.

Markus M
>
> best,
> Vero
>
> 2018-02-05 20:54 GMT+01:00 Veronica Andreo :
>>
>> Forgot the list, sorry...
>>
>> ---
>>
>> Hi Markus,
>>
>> here the output of gdalinfo -mm for the same band reported earlier:
>>
>> gdalinfo -mm T21KZP_20171212T134159_B01.jp2
>> Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
>> Files: T21KZP_20171212T134159_B01.jp2
>> [...]
>>
>> Band 1 Block=192x192 Type=UInt16, ColorInterp=Gray
>>   Min=908.000 Max=1511.000   Computed Min/Max=934.000,6934.000
>>   Minimum=908.000, Maximum=1511.000, Mean=1138.806, StdDev=74.933
>>   Overviews: 915x915, 457x457, 228x228, 114x114
>>   Overviews: arbitrary
>>   Metadata:
>> STATISTICS_MAXIMUM=1511
>> STATISTICS_MEAN=1138.8064
>> STATISTICS_MINIMUM=908
>> STATISTICS_STDDEV=74.933459275813
>>   Image Structure Metadata:
>> COMPRESSION=JPEG2000
>> NBITS=15
>>
>> still differs a lot from what I get after importing into GRASS.
>>
>> System Info

>> GRASS version: 7.5.svn

>> GRASS SVN revision: r72203

>> Build date: 2018-01-01

>> Build platform: x86_64-pc-linux-gnu

>> GDAL: 2.1.3

>> PROJ.4: 4.9.3

>> GEOS: 3.6.1

>> SQLite: 3.20.1

>> Python: 2.7.14

>> wxPython: 3.0.2.0

>> Platform: Linux-4.14.14-200.fc26.x86_64-x86_64-with-fedora-26-Twenty_Six
>>
>> best,
>> Vero
>>
>>
>> 2018-02-05 19:49 GMT+01:00 Markus Metz :
>>>
>>>
>>>
>>> On Mon, Feb 5, 2018 at 1:14 PM, Veronica Andreo 
wrote:
>>> >
>>> > I tested also with 74 release branch... same result
>>> >
>>> > 2018-02-05 13:05 GMT+01:00 Veronica Andreo :
>>> >>
>>> >> Hi devs
>>> >>
>>> >> I'm testing Martin's new add-on, r.sentinel.import. I created an
UTM21S location for my data and imported them with:
>>> >>
>>> >> r.sentinel.import
input=Downloads/S2B_MSIL1C_20171212T134159_N0206_R124_T21KZP_20171212T201017.SAFE/GRANULE/L1C_T21KZP_A004011_20171212T134158/IMG_DATA/
>>> >>
>>> >> The problem arose when I tried to use i.color.enhance to display an
RGB: I got blank screens, so I thought there must be something with the
range of values.
>>> >>
>>> >> r.univar map=T21KZP_20171212T134159_B02@PERMANENT

>>> >> total null and non-null cells: 120560400
>>> >> total null cells: 0
>>> >> Of the non-null cells:
>>> >> --
>>> >> n: 120560400
>>> >> minimum: 15
>>> >> maximum: 17547
>>> >> range: 17532
>>> >> mean: 913.778
>>> >> mean of absolute values: 913.778
>>> >> standard deviation: 134.322
>>> >> variance: 18042.4
>>> >> variation coefficient: 14.6996 %
>>> >> sum: 110165471238
>>> >>
>>> >> that already seemed odd...
>>> >> I checked the original band2 jp2 file... Values are different...
>>> >>
>>> >> gdalinfo T21KZP_20171212T134159_B02.jp2
>>> >> Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
>>> >> Files: T21KZP_20171212T134159_B02.jp2
>>> >> ...
>>> >> Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Gray
>>> >>   Min=602.000 Max=1576.000
>>> >>   Minimum=602.000, Maximum=1576.000, Mean=916.799, StdDev=123.509
>>> >>   Overviews: 5490x5490, 2745x2745, 1372x1372, 686x686
>>> >>   Overviews: arbitrary
>>> >>   Metadata:
>>> >> STATISTICS_MAXIMUM=1576
>>> >> STATISTICS_MEAN=916.7992
>>> >> STATISTICS_MINIMUM=602
>>> >> STATISTICS_STDDEV=123.50943477872
>>> >>   Image Structure Metadata:
>>> >> COMPRESSION=JPEG2000
>>> >> NBITS=15
>>>
>>> Can you try again with gdalinfo -mm? This forces computation of the
actual min/max values, which can differ from what is stored in the metadata
(an approximation).
>>>
>>> There can also be something wrong with i.color.enhance
>>>
>>> Markus M
>>>
>>> >>
>>> >> Just to check, I imported with r.in.gdal and I'm getting exactly the
same as with r.sentinel.import.
>>> >>
>>> >> What am I doing wrong here? Why would r.in.gdal change values like
that? What else needs to be set? I don't remember to have this problem
before and it happens in all bands as far as I've checked.
>>> >>

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

[GRASS GIS]

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

Comment (by neteler):

 The group management has been discussed long time back, see also #70 and

 https://lists.osgeo.org/pipermail/grass-dev/2008-June/038371.html

 However, things can certainly be discussed and their technical feasibility
 be revisited again.

--
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] External providers in QGIS

[Paolo Cavallini]

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 without). This raised a number of
concerns, so PSC decided not to rush removing them from the upcoming 3.0
release, and to open a wider discussions about this, involving all the
interested parties, to find an optimal solution.
If volunteers outside QGIS core team, ideally from the respective
backends, could take the maintenance of these providers, not much would
change for the end user. If not, this will mean effectively missing
hundreds of algs from QGIS.
I personally propose to reinstate the OTB plugin with Rashad (from OTB)
as maintainer.
QGIS.ORG will seek to support any decision made with funding where possible.
Looking forward for your feedback.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

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

[GRASS GIS]

#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:  wontfix  |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by martinl):

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


Comment:

 OK, closing as wontfix.

--
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] #3489: integrate grass session lib

[GRASS GIS]

#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:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by wenzeslaus):

 Replying to [comment:4 zarch]:
 >
 > Replying to [ticket:3489 martinl]:
 > > it would be nice to integrate Python grass_session lib (1) into GRASS
 code base.
 >
 > However, for me the main advantage of `grass_session` library is that it
 is a "standard" python library, that is installed to the python
 interpreter as other libraries do.
 > Once that you have installed it, you can open your python interpreter
 and use it without the need of setting python paths, etc.

 Agreed. Although I'm not sure how to put it together with GRASS GIS
 libraries (in relation to code/distribution), the separate library
 promises better, more convenient, use for the end user.

 See also #2873 for an extensive discussion. One alternative solution is to
 put GRASS libraries (Python and C) on path (see #2873 and also #2424).

--
Ticket URL: 
GRASS GIS 

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

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

[Nikos Alexandris]

* 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: 'NoneType' object has no attribute 'tzinfo'.

This leads to something like a Python function expects a specific type of
data while it receives, as an input, another one.

The map is timestamped:

r.timestamp lst_LC81930282015116LGN00
26 Apr 2015 10:03:51

The timestamp file under `cell_misc/lst `, under the working Mapset, is
a valid file, i.e.

file LC81930282015116LGN00/cell_misc/lst/timestamp

returns

LC81930282015116LGN00/cell_misc/lst/timestamp: ASCII text

The computational region is all set, its univariate figures are computed
and printed on the command line, and, finally, the map draws normally on a
wx-Monitor.

This is one error that frequently comes up during analyses of tens
of thousands of Landsat 8 images.

I've set a short course on tracking what is where (using DEBUG=?
levels), but I think this is not the right choice.

Anyone an idea? Do I need to deeply debug this, using `pdb` for example?
Attached a outputs of g.region, g.proj, r.info, r.univar for and the
timestamp (file) of the map in question.



Just another, important, note. All single scenes/ as the one in question
here/ are processed separately, each in a dedicated docker container
based on debian(:latest).

I've seen some errors related to locale settings, when there was no
default UTF-8 preset.  Could this be something related?

Nikos


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

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

[Nikos Alexandris]

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 Python function expects a specific type of
data while it receives, as an input, another one.

The map is timestamped:

r.timestamp lst_LC81930282015116LGN00
26 Apr 2015 10:03:51

The timestamp file under `cell_misc/lst `, under the working Mapset, is
a valid file, i.e.

file LC81930282015116LGN00/cell_misc/lst/timestamp

returns

LC81930282015116LGN00/cell_misc/lst/timestamp: ASCII text

The computational region is all set, its univariate figures are computed
and printed on the command line, and, finally, the map draws normally on a
wx-Monitor.

This is one error that frequently comes up during analyses of tens
of thousands of Landsat 8 images.

I've set a short course on tracking what is where (using DEBUG=?
levels), but I think this is not the right choice.

Anyone an idea? Do I need to deeply debug this, using `pdb` for example?
Attached a outputs of g.region, g.proj, r.info, r.univar for and the
timestamp (file) of the map in question.

Thank you, Nikos

--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
name=WGS 84 / UTM zone 32N
datum=wgs84
ellps=wgs84
proj=utm
zone=32
no_defs=defined
unit=meter
units=meters
meters=1
projection=1
zone=32
n=5215815
s=4979985
w=499785
e=732015
nsres=30
ewres=30
rows=7861
cols=7741
cells=60852001
north=5215815
south=4979985
east=728115
west=496185
nsres=30
ewres=30
rows=7861
cols=7731
cells=60773391
datatype=DCELL
ncats=0
map=lst_LC81930282015116LGN00
mapset=lst
location=lst_193028
database=/eos/jeodpp/data/projects/INCA/LANDSAT_LST
date="Sat Jan 27 07:08:06 2018"
creator="vsyrris"
title="Land Surface Temperature (C)"
timestamp="26 Apr 2015 10:03:51"
units=Celsius
vdatum="none"
source1="LC81930282015116LGN00"
source2="Image courtesy of the U.S. Geological Survey"
description="Land Surface Temperature derived from a split-window algorithm. "
comments="eval(sw_lst_1 = -2.78009 + (1.01408 + 0.15833 * ((1 - 
tmp.788.0.avg_lse) / tmp.788.0.avg_lse ^ 2) + -0.34991 * (tmp.788.1.delta_lse / 
tmp.788.0.avg_lse ^ 2)) * ((tmp.788.4.brightness_temperature.10 + 
tmp.788.6.brightness_temperature.11) / 2) + (4.04487 + 3.55414 * ((1 - 
tmp.788.0.avg_lse) / tmp.788.0.avg_lse) + -8.88394 * (tmp.788.1.delta_lse / 
tmp.788.0.avg_lse ^ 2)) * ((tmp.788.4.brightness_temperature.10 - 
tmp.788.6.brightness_temperature.11) / 2) + 0.09152 * 
(tmp.788.4.brightness_temperature.10 - tmp.788.6.brightness_temperature.11) ^ 
2, sw_lst_2 = 11.00824 + (0.95995 + 0.17243 * ((1 - tmp.788.0.avg_lse) / 
tmp.788.0.avg_lse ^ 2) + -0.28852 * (tmp.788.1.delta_lse / tmp.788.0.avg_lse ^ 
2)) * ((tmp.788.4.brightness_temperature.10 + 
tmp.788.6.brightness_temperature.11) / 2) + (7.11492 + 0.42684 * ((1 - 
tmp.788.0.avg_lse) / tmp.788.0.avg_lse) + -6.62025 * (tmp.788.1.delta_lse / 
tmp.788.0.avg_lse ^ 2)) * ((tmp.788.4.brightness_temperature.10 - 
tmp.788.6.brightness_temperature.11) / 2) + -0.06381 * 
(tmp.788.4.brightness_temperature.10 - tmp.788.6.brightness_temperature.11) ^ 
2, sw_lst_12 = (sw_lst_1 + sw_lst_2) / 2, sw_lst_3 = 9.6261 + (0.96202 + 
0.13834 * ((1 - tmp.788.0.avg_lse) / tmp.788.0.avg_lse ^ 2) + -0.17262 * 
(tmp.788.1.delta_lse / tmp.788.0.avg_lse ^ 2)) * 
((tmp.788.4.brightness_temperature.10 + tmp.788.6.brightness_temperature.11) / 
2) + (7.87883 + 5.1791 * ((1 - tmp.788.0.avg_lse) / tmp.788.0.avg_lse) + 
-13.26611 * (tmp.788.1.delta_lse / tmp.788.0.avg_lse ^ 2)) * 
((tmp.788.4.brightness_temperature.10 - tmp.788.6.brightness_temperature.11) / 
2) + -0.07603 * (tmp.788.4.brightness_temperature.10 - 
tmp.788.6.brightness_temperature.11) ^ 2, sw_lst_23 = (sw_lst_2 + sw_lst_3) / 
2, sw_lst_4 = 0.61258 + (0.99124 + 0.10051 * ((1 - tmp.788.0.avg_lse) / 
tmp.788.0.avg_lse ^ 2) + -0.09664 * (tmp.788.1.delta_lse / tmp.788.0.avg_lse ^ 
2)) * ((tmp.788.4.brightness_temperature.10 + 
tmp.788.6.brightness_temperature.11) / 2) + (7.85758 + 6.86626 * ((1 - 
tmp.788.0.avg_lse) / tmp.788.0.avg_lse) + -15.00742 * (tmp.788.1.delta_lse / 
tmp.788.0.avg_lse ^ 2)) * ((tmp.788.4.brightness_temperature.10 - 
tmp.788.6.brightness_temperature.11) / 2) + -0.01185 * 
(tmp.788.4.brightness_temperature.10 - tmp.788.6.brightness_temperature.11) ^ 
2, sw_lst_34 = (sw_lst_3 + sw_lst_4) / 2, sw_lst_5 = -0.34808 + (0.98123 + 
0.05599 * ((1 - tmp.788.0.avg_lse) / tmp.788.0.avg_lse ^ 2) + -0.03518 * 
(tmp.788.1.delta_lse / tmp.788.0.avg_lse ^ 2)) * 
((tmp.788.4.brightness_temperature.10 + tmp.788.6.brightness_temperature.11) / 
2) + (11.96444 + 9.0671 * ((1 - tmp.788.0.avg_lse) / tmp.788.0.avg_lse) + 
-14.74085 * (tmp.788.1.delta_lse / tmp.788.0.avg_lse ^ 2)) * 
((tmp.788.4.brightness_temperature.10 - tmp.788.6.brightness_temperature.11) / 
2) + -0.20471 * 

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

[GRASS GIS]

#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:  i.group  |CPU:  All
 Platform:  All  |
-+-
 Using i.group on imagery groups in other mapsets unfortunately does not
 work.
 Seems to be a known limitation as I get the following error message:
 ERROR: Group must exist in the current mapset

 Would however be nice to be able to read groups from other mapsets, if
 non-modifying operations with i.group (l,s,g-flag) would be allowed...

 Tagging it as enhancement as behavior is deliberately as it is at the
 moment...

--
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] #3490: pygrass: improve error messages for table handling

[GRASS GIS]

#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:  |   Keywords:  pygrass,vector,SQLite
   CPU:  All |   Platform:  All
-+---

Comment (by sbl):

 See also: #3071 regarding effects of not quoting SQL identifiers...

--
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] #3490: pygrass: improve error messages for table handling

[GRASS GIS]

#3490: pygrass: improve error messages for table handling
---+-
 Reporter:  sbl|  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:
Component:  Python |Version:  unspecified
 Keywords:  pygrass,vector,SQLite  |CPU:  All
 Platform:  All|
---+-
 When I try to create a new vector map in pygrass where columns in the
 attribute table (SQLite) contain "." (e.g. "landsatIm.5")
 new.open() fails saying first that table exisits and then that it does not
 exist:

 {{{
 Traceback (most recent call last):
   File
 "/home/NINA.NO/stefan.blumentrath/.grass7/addons/scripts/i.pysptools.unmix",
 line 329, in 
 sys.exit(main())
   File
 "/home/NINA.NO/stefan.blumentrath/.grass7/addons/scripts/i.pysptools.unmix",
 line 272, in main
 new.open('w', tab_name=endmembers, tab_cols=cols)
   File
 
"/home/NINA.NO/stefan.blumentrath/grass-7.4.0svn/etc/python/grass/pygrass/vector/abstract.py",
 line 381, in open
 self.n_lines = self.table.n_rows()
   File
 
"/home/NINA.NO/stefan.blumentrath/grass-7.4.0svn/etc/python/grass/pygrass/vector/table.py",
 line 1053, in n_rows
 cur.execute(sql.SELECT.format(cols='Count(*)', tname=self.name))
 sqlite3.OperationalError: no such table: test_end
 }}}

 However, after a bit of troubleshooting, I realized that the dots were
 causing the issue.
 Would be helpful if pygrass could check for "GRASS compliant" column names
 and give more specific error messages. An alternative could be to support
 quoted identifiers throughout the code, but that is probably a too big
 effort (or something for GRASS 8?)...

--
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.in.gdal changes range of values for sentinel bands (?)

[Veronica Andreo]

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 :)

best,
Vero

2018-02-05 20:54 GMT+01:00 Veronica Andreo :

> Forgot the list, sorry...
>
> ---
>
> Hi Markus,
>
> here the output of gdalinfo -mm for the same band reported earlier:
>
> gdalinfo -mm T21KZP_20171212T134159_B01.jp2
> Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
> Files: T21KZP_20171212T134159_B01.jp2
> [...]
>
> Band 1 Block=192x192 Type=UInt16, ColorInterp=Gray
>   Min=908.000 Max=1511.000   Computed Min/Max=934.000,6934.000
>   Minimum=908.000, Maximum=1511.000, Mean=1138.806, StdDev=74.933
>   Overviews: 915x915, 457x457, 228x228, 114x114
>   Overviews: arbitrary
>   Metadata:
> STATISTICS_MAXIMUM=1511
> STATISTICS_MEAN=1138.8064
> STATISTICS_MINIMUM=908
> STATISTICS_STDDEV=74.933459275813
>   Image Structure Metadata:
> COMPRESSION=JPEG2000
> NBITS=15
>
> still differs a lot from what I get after importing into GRASS.
>
> System Info
>
> GRASS version: 7.5.svn
>
> GRASS SVN revision: r72203
>
> Build date: 2018-01-01
>
> Build platform: x86_64-pc-linux-gnu
>
> GDAL: 2.1.3
>
> PROJ.4: 4.9.3
>
> GEOS: 3.6.1
>
> SQLite: 3.20.1
>
> Python: 2.7.14
>
> wxPython: 3.0.2.0
>
> Platform: Linux-4.14.14-200.fc26.x86_64-x86_64-with-fedora-26-Twenty_Six
>
> best,
> Vero
>
>
> 2018-02-05 19:49 GMT+01:00 Markus Metz :
>
>>
>>
>> On Mon, Feb 5, 2018 at 1:14 PM, Veronica Andreo 
>> wrote:
>> >
>> > I tested also with 74 release branch... same result
>> >
>> > 2018-02-05 13:05 GMT+01:00 Veronica Andreo :
>> >>
>> >> Hi devs
>> >>
>> >> I'm testing Martin's new add-on, r.sentinel.import. I created an
>> UTM21S location for my data and imported them with:
>> >>
>> >> r.sentinel.import input=Downloads/S2B_MSIL1C_201
>> 71212T134159_N0206_R124_T21KZP_20171212T201017.SAFE/GRANULE/
>> L1C_T21KZP_A004011_20171212T134158/IMG_DATA/
>> >>
>> >> The problem arose when I tried to use i.color.enhance to display an
>> RGB: I got blank screens, so I thought there must be something with the
>> range of values.
>> >>
>> >> r.univar map=T21KZP_20171212T134159_B02@PERMANENT
>>
>> >> total null and non-null cells: 120560400
>> >> total null cells: 0
>> >> Of the non-null cells:
>> >> --
>> >> n: 120560400
>> >> minimum: 15
>> >> maximum: 17547
>> >> range: 17532
>> >> mean: 913.778
>> >> mean of absolute values: 913.778
>> >> standard deviation: 134.322
>> >> variance: 18042.4
>> >> variation coefficient: 14.6996 %
>> >> sum: 110165471238
>> >>
>> >> that already seemed odd...
>> >> I checked the original band2 jp2 file... Values are different...
>> >>
>> >> gdalinfo T21KZP_20171212T134159_B02.jp2
>> >> Driver: JP2OpenJPEG/JPEG-2000 driver based on OpenJPEG library
>> >> Files: T21KZP_20171212T134159_B02.jp2
>> >> ...
>> >> Band 1 Block=1024x1024 Type=UInt16, ColorInterp=Gray
>> >>   Min=602.000 Max=1576.000
>> >>   Minimum=602.000, Maximum=1576.000, Mean=916.799, StdDev=123.509
>> >>   Overviews: 5490x5490, 2745x2745, 1372x1372, 686x686
>> >>   Overviews: arbitrary
>> >>   Metadata:
>> >> STATISTICS_MAXIMUM=1576
>> >> STATISTICS_MEAN=916.7992
>> >> STATISTICS_MINIMUM=602
>> >> STATISTICS_STDDEV=123.50943477872
>> >>   Image Structure Metadata:
>> >> COMPRESSION=JPEG2000
>> >> NBITS=15
>>
>> Can you try again with gdalinfo -mm? This forces computation of the
>> actual min/max values, which can differ from what is stored in the metadata
>> (an approximation).
>>
>> There can also be something wrong with i.color.enhance
>>
>> Markus M
>>
>> >>
>> >> Just to check, I imported with r.in.gdal and I'm getting exactly the
>> same as with r.sentinel.import.
>> >>
>> >> What am I doing wrong here? Why would r.in.gdal change values like
>> that? What else needs to be set? I don't remember to have this problem
>> before and it happens in all bands as far as I've checked.
>> >>
>> >> Ah, I'm using trunk r72203
>> >>
>> >> Thanks in advance for any help :)
>> >>
>> >> Cheers,
>> >> Vero
>> >>
>> >>
>> >>
>> >
>> >
>> > ___
>> > 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