Re: [GRASS-dev] G79: working with image collections and Sentinel-2

2019-11-21 Thread Markus Neteler
On Fri, Nov 22, 2019 at 1:01 AM Veronica Andreo  wrote:
> El jue., 21 nov. 2019 18:40, Markus Neteler  escribió:
>>
>> Hi,
>>
>> I have successfully imported a series of Sentinel-2 scenes using
>> i.sentinel.download and i.sentinel.import (with the recent fixes yet
>> manually patched into it).
>>
>> Now I want to register them:
>>
>> t.create type=strds temporaltype=absolute \
>>  output=openeo_bolzano_S2 \
>>  title="Sentinel-2 scenes Bolzano" \
>>  description="Dataset with Sentinel-2 scenes covering Bolzano"
>>
>> # created by i.sentinel.import
>> head /mnt/geodata/openeo_bolzano/s2_t_register.csv
>> T32TPS_20180618T101021_B12|2018-06-18 10:17:33.781000|S2_12
>> T32TPS_20180618T101021_B04|2018-06-18 10:17:33.781000|S2_4
>> T32TPS_20180618T101021_B09|2018-06-18 10:17:33.781000|S2_9
>> T32TPS_20180618T101021_B08|2018-06-18 10:17:33.781000|S2_8
>> T32TPS_20180618T101021_B8A|2018-06-18 10:17:33.781000|S2_8A
>> T32TPS_20180618T101021_B06|2018-06-18 10:17:33.781000|S2_6
>> T32TPS_20180618T101021_B01|2018-06-18 10:17:33.781000|S2_1
>> T32TPS_20180618T101021_B03|2018-06-18 10:17:33.781000|S2_3
>> T32TPS_20180618T101021_B11|2018-06-18 10:17:33.781000|S2_11
>> T32TPS_20180618T101021_B07|2018-06-18 10:17:33.781000|S2_7
>>
>> # here I updated successfully the existing TGRASS DB with the yet unmerged
>> # t.upgrade script (https://github.com/OSGeo/grass/pull/130)
>> t.register input=openeo_bolzano_S2
>> file=/mnt/geodata/openeo_bolzano/s2_t_register.csv
>>
>> So far so nice, but:
>>
>> t.rast.list openeo_bolzano_S2
>> name|mapset|start_time|end_time
>> T32TPS_20180606T102019_B01|openeo_bolzano|2018-06-06 10:25:12.692000|None
>> T32TPS_20180606T102019_B02|openeo_bolzano|2018-06-06 10:25:12.692000|None
>> T32TPS_20180606T102019_B03|openeo_bolzano|2018-06-06 10:25:12.692000|None
>> ...
>>
>> ... the band names are gone - can anyone confirm?
>> I am using a recent G79.
>
>
> I haven't tested, but are you sure t.rast.list now lists band references by 
> default if they exist? Because that looks like a normal t.rast.list output to 
> me
>
> What if you use:
>
> t.rast.list openeo_bolzano_S2 columns=name,band_reference,start_time
>
> Does that work?

Unfortunately not:

GRASS 7.9.dev (utm32n_32632):~ > t.rast.list openeo_bolzano_S2
columns=name,band_reference,start_time
...
ERROR: Value  out of range for parameter 
Legal range:
id,name,creator,mapset,temporal_type,creation_time,start_time,end_time,north,south,west,east,nsres,ewres,cols,rows,number_of_cells,min,max

Indeed, that column isn't foreseen as an answer to columns:
https://grass.osgeo.org/grass79/manuals/t.rast.list.html

> And what does t.info openeo_bolzano_S2 give?

t.info openeo_bolzano_S2
 + Space Time Raster Dataset -+
 ||
 + Basic information -+
 | Id:  openeo_bolzano_S2@openeo_bolzano
 | Name: .. openeo_bolzano_S2
 | Mapset:  openeo_bolzano
 | Creator: ... root
 | Temporal type: . absolute
 | Creation time: . 2019-11-21 21:24:17.024278
 | Modification time:.. 2019-11-21 21:25:05.446855
 | Semantic type:.. mean
 + Absolute time -+
 | Start time:. 2018-06-06 10:25:12.692000
 | End time:... 2018-06-21 10:23:16.629000
 | Granularity: 1 second
 | Temporal type of maps:.. point
 + Spatial extent +
 | North:.. 5200020.0
 | South:.. 5090220.0
 | East:..  709800.0
 | West:... 60.0
 | Top: 0.0
 | Bottom:. 0.0
 + Metadata information --+
 | Raster register table:..
raster_map_register_b9c38e48a9074528a0c5d928ccd9c8aa
 | North-South resolution min:. 10.0
 | North-South resolution max:. 60.0
 | East-west resolution min:... 10.0
 | East-west resolution max:... 60.0
 | Minimum value min:.. 0.0
 | Minimum value max:.. 1929.0
 | Maximum value min:.. 1600.0
 | Maximum value max:.. 28002.0
 | Aggregation type:... None
 | Number of registered bands:. 13
 | Number of registered maps:.. 91
 |
 | Title:
 | Sentinel-2 scenes Bolzano
 | Description:
 | Dataset with Sentinel-2 scenes covering Bolzano
 | Command history:
 | # 2019-11-21 21:24:17
 | t.create type="strds" temporaltype="absolute"
 | output="openeo_bolzano_S2" title="Sentinel-2 scenes Bolzano"
 | description="Dataset with Sentinel-2 scenes covering Bolzano"
 | # 2019-11-21 21:25:05
 | t.register input="openeo_bolzano_S2"
 | file="/mnt/geodata/openeo_bolzano/s2_t_register.csv"
 |
 

Re: [GRASS-dev] [GRASS GIS] #3980: Error Reading list of LiDAR files in r.in.lidar 7.6.1, 7.8.1 on Windows 10

2019-11-21 Thread GRASS GIS
#3980: Error Reading list of LiDAR files in r.in.lidar 7.6.1, 7.8.1 on Windows 
10
---+
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.8.2
 Component:  Default   |Version:  git-releasebranch78
Resolution:|   Keywords:  Python input file list
   CPU:  x86-64|   Platform:  MSWindows
---+

Comment (by marisn):

 Check the version of libLAS as there where bugs in its C API causing
 segfaults:\\
 https://github.com/libLAS/libLAS/pull/168 \\
 https://github.com/libLAS/libLAS/pull/173

-- 
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] #3980: Error Reading list of LiDAR files in r.in.lidar 7.6.1, 7.8.1 on Windows 10

2019-11-21 Thread GRASS GIS
#3980: Error Reading list of LiDAR files in r.in.lidar 7.6.1, 7.8.1 on Windows 
10
---+
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.8.2
 Component:  Default   |Version:  git-releasebranch78
Resolution:|   Keywords:  Python input file list
   CPU:  x86-64|   Platform:  MSWindows
---+

Comment (by wenzeslaus):

 The error (below) seems unrelated to r.in.lidar becasue it is not coming
 from there since it is GUI related (this is Python traceback with wxpython
 involved, r.in.lidar is C). Do you observe it only with `r.in.lidar
 file=...`? What are the steps leading to this error?

 {{{
 ...
  7.8\gui\wxpython\core\gconsole.py", line 306, in write

 self.message += line.split(':', 1)[1].strip() + '\n'

 IndexError?: list index out of range
 }}}

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] G79: working with image collections and Sentinel-2

2019-11-21 Thread Veronica Andreo
El jue., 21 nov. 2019 18:40, Markus Neteler  escribió:

> Hi,
>
> I have successfully imported a series of Sentinel-2 scenes using
> i.sentinel.download and i.sentinel.import (with the recent fixes yet
> manually patched into it).
>
> Now I want to register them:
>
> t.create type=strds temporaltype=absolute \
>  output=openeo_bolzano_S2 \
>  title="Sentinel-2 scenes Bolzano" \
>  description="Dataset with Sentinel-2 scenes covering Bolzano"
>
> # created by i.sentinel.import
> head /mnt/geodata/openeo_bolzano/s2_t_register.csv
> T32TPS_20180618T101021_B12|2018-06-18 10:17:33.781000|S2_12
> T32TPS_20180618T101021_B04|2018-06-18 10:17:33.781000|S2_4
> T32TPS_20180618T101021_B09|2018-06-18 10:17:33.781000|S2_9
> T32TPS_20180618T101021_B08|2018-06-18 10:17:33.781000|S2_8
> T32TPS_20180618T101021_B8A|2018-06-18 10:17:33.781000|S2_8A
> T32TPS_20180618T101021_B06|2018-06-18 10:17:33.781000|S2_6
> T32TPS_20180618T101021_B01|2018-06-18 10:17:33.781000|S2_1
> T32TPS_20180618T101021_B03|2018-06-18 10:17:33.781000|S2_3
> T32TPS_20180618T101021_B11|2018-06-18 10:17:33.781000|S2_11
> T32TPS_20180618T101021_B07|2018-06-18 10:17:33.781000|S2_7
>
> # here I updated successfully the existing TGRASS DB with the yet unmerged
> # t.upgrade script (https://github.com/OSGeo/grass/pull/130)
> t.register input=openeo_bolzano_S2
> file=/mnt/geodata/openeo_bolzano/s2_t_register.csv
>
> So far so nice, but:
>
> t.rast.list openeo_bolzano_S2
> name|mapset|start_time|end_time
> T32TPS_20180606T102019_B01|openeo_bolzano|2018-06-06 10:25:12.692000|None
> T32TPS_20180606T102019_B02|openeo_bolzano|2018-06-06 10:25:12.692000|None
> T32TPS_20180606T102019_B03|openeo_bolzano|2018-06-06 10:25:12.692000|None
> ...
>
> ... the band names are gone - can anyone confirm?
> I am using a recent G79.
>

I haven't tested, but are you sure t.rast.list now lists band references by
default if they exist? Because that looks like a normal t.rast.list output
to me

What if you use:

t.rast.list openeo_bolzano_S2 columns=name,band_reference,start_time

Does that work? And what does t.info openeo_bolzano_S2 give?

HTH,
Vero


> Thanks,
> 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] G79: working with image collections and Sentinel-2

2019-11-21 Thread Markus Neteler
Hi,

I have successfully imported a series of Sentinel-2 scenes using
i.sentinel.download and i.sentinel.import (with the recent fixes yet
manually patched into it).

Now I want to register them:

t.create type=strds temporaltype=absolute \
 output=openeo_bolzano_S2 \
 title="Sentinel-2 scenes Bolzano" \
 description="Dataset with Sentinel-2 scenes covering Bolzano"

# created by i.sentinel.import
head /mnt/geodata/openeo_bolzano/s2_t_register.csv
T32TPS_20180618T101021_B12|2018-06-18 10:17:33.781000|S2_12
T32TPS_20180618T101021_B04|2018-06-18 10:17:33.781000|S2_4
T32TPS_20180618T101021_B09|2018-06-18 10:17:33.781000|S2_9
T32TPS_20180618T101021_B08|2018-06-18 10:17:33.781000|S2_8
T32TPS_20180618T101021_B8A|2018-06-18 10:17:33.781000|S2_8A
T32TPS_20180618T101021_B06|2018-06-18 10:17:33.781000|S2_6
T32TPS_20180618T101021_B01|2018-06-18 10:17:33.781000|S2_1
T32TPS_20180618T101021_B03|2018-06-18 10:17:33.781000|S2_3
T32TPS_20180618T101021_B11|2018-06-18 10:17:33.781000|S2_11
T32TPS_20180618T101021_B07|2018-06-18 10:17:33.781000|S2_7

# here I updated successfully the existing TGRASS DB with the yet unmerged
# t.upgrade script (https://github.com/OSGeo/grass/pull/130)
t.register input=openeo_bolzano_S2
file=/mnt/geodata/openeo_bolzano/s2_t_register.csv

So far so nice, but:

t.rast.list openeo_bolzano_S2
name|mapset|start_time|end_time
T32TPS_20180606T102019_B01|openeo_bolzano|2018-06-06 10:25:12.692000|None
T32TPS_20180606T102019_B02|openeo_bolzano|2018-06-06 10:25:12.692000|None
T32TPS_20180606T102019_B03|openeo_bolzano|2018-06-06 10:25:12.692000|None
...

... the band names are gone - can anyone confirm?
I am using a recent G79.

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

Re: [GRASS-dev] unsupported temporal database in grass79-dev

2019-11-21 Thread Markus Neteler
Hi Martin,

On Thu, Sep 26, 2019 at 8:34 AM Markus Neteler  wrote:
> On Thu, Sep 5, 2019 at 4:04 PM Veronica Andreo  wrote:
> > El jue., 5 sept. 2019 a las 15:47, Martin Landa () 
> > escribió:
> >> čt 5. 9. 2019 v 15:43 odesílatel Veronica Andreo  
> >> napsal:
> >> > I do not understand what this really means in terms of what I have to 
> >> > do. I have many many time series, some with tens of thousands of maps 
> >> > (Gb's of data) and I find it really annoying to be forced to export all 
> >> > of them to then import again. Is this really what I need to do?? Isn't 
> >> > there a simpler way??
> >>
> [...]
> >> It would be nice to implement automated upgrade logic. Something like
> >>
> >> t.connect -u
> >>
> >> would do magic upgrade of current TGIS DB from version 2 to 3
> >
> > This would be great indeed; I was actually hoping for something like this. 
> > I gues I won't be using grass79dev until such thing exists... :-(
>
> Did anyone test Martin's efforts at:
>
> https://github.com/OSGeo/grass/pull/130
>
> It provides a new upgrade script and updates.

I just tested it, it works fine. thanks!

I would suggest to merge it (the question is where to put the helper
script t.upgrade?)

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

Re: [GRASS-dev] [GRASS GIS] #3980: Error Reading list of LiDAR files in r.in.lidar 7.6.1, 7.8.1 on Windows 10

2019-11-21 Thread GRASS GIS
#3980: Error Reading list of LiDAR files in r.in.lidar 7.6.1, 7.8.1 on Windows 
10
---+
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.8.2
 Component:  Default   |Version:  git-releasebranch78
Resolution:|   Keywords:  Python input file list
   CPU:  x86-64|   Platform:  MSWindows
---+

Comment (by dnewcomb):

 Sorry, forgot to add that r.in.lidar never completes.

-- 
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] #3980: Error Reading list of LiDAR files in r.in.lidar 7.6.1, 7.8.1 on Windows 10

2019-11-21 Thread GRASS GIS
#3980: Error Reading list of LiDAR files in r.in.lidar 7.6.1, 7.8.1 on Windows 
10
+-
 Reporter:  dnewcomb|  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:  7.8.2
Component:  Default |Version:  git-releasebranch78
 Keywords:  Python input file list  |CPU:  x86-64
 Platform:  MSWindows   |
+-
 I suspect that this is a windows limitation, since I have had no issues on
 Linux.  When running r.in.lidar on  Windows 10 64 bit computer using an
 input text file with 1870 lines



 Exception in thread Thread-29:
 Traceback (most recent call last):
   File "C:\Program Files\GRASS GIS
 7.8\Python37\lib\threading.py", line 917, in
 _bootstrap_inner
 self.run()
   File "C:\Program Files\GRASS GIS
 7.8\gui\wxpython\core\gconsole.py", line 162, in run
 self.resultQ.put((requestId, self.requestCmd.run()))
   File "C:\Program Files\GRASS GIS
 7.8\gui\wxpython\core\gcmd.py", line 606, in run
 self._redirect_stream()
   File "C:\Program Files\GRASS GIS
 7.8\gui\wxpython\core\gcmd.py", line 635, in
 _redirect_stream
 self.stderr.write(line)
   File "C:\Program Files\GRASS GIS
 7.8\gui\wxpython\core\gconsole.py", line 306, in write
 self.message += line.split(':', 1)[1].strip() + '\n'
 IndexError: list index out of range

 This occurs on both 7.6.1 and 7.8.1 for windows

-- 
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] #3979: G79: problem with i.sentinel.import and importer.write_metadata()

2019-11-21 Thread GRASS GIS
#3979: G79: problem with i.sentinel.import and importer.write_metadata()
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.sentinel.import, image
   CPU:  |  collections
  Unspecified|   Platform:  Unspecified
-+-

Comment (by neteler):

 Replying to [comment:8 sbl]:
 > Hm, I think I have a hunch. Can you try to
 > 1) delete all SAFE directories (or use a different unzip dir)
 > 2) run i.sentinel.import again and see if the error remains?

 Bingo! Now it ran through, finally.

 > If you don`t link (l-flag) the unpacked SAFE dirs should actually be
 removed automatically...

 I didn't use -l this time.

 > If they are present, i.sentinel.import does not unpack again (anymore
 after my changes). If an import is interrupted it may lead to issues like
 yours...

 I see. May I suggest that, if present, the SAFE directory be actually
 removed before unpacking? Less confusion :-)

 Rationale: it may happen then a `i.sentinel.import` job is interrupted, be
 by the user, for disk-full reasons or whatever else might occur...

-- 
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] #3979: G79: problem with i.sentinel.import and importer.write_metadata()

2019-11-21 Thread GRASS GIS
#3979: G79: problem with i.sentinel.import and importer.write_metadata()
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.sentinel.import, image
   CPU:  |  collections
  Unspecified|   Platform:  Unspecified
-+-

Comment (by sbl):

 Hm, I think I have a hunch. Can you try to
 1) delete all SAFE directories (or use a different unzip dir)
 2) run i.sentinel.import again and see if the error remains?

 If you don`t link (l-flag) the unpacked SAFE dirs should actually be
 removed automatically...

 If they are present, i.sentinel.import does not unpack again (anymore
 after my changes). If an import is interrupted it may lead to issues like
 yours...

-- 
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] #3979: G79: problem with i.sentinel.import and importer.write_metadata()

2019-11-21 Thread GRASS GIS
#3979: G79: problem with i.sentinel.import and importer.write_metadata()
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.sentinel.import, image
   CPU:  |  collections
  Unspecified|   Platform:  Unspecified
-+-

Comment (by neteler):

 Replying to [comment:6 martinl]:
 > What is content of `/mnt/geodata/openeo_bolzano/` dir?

 {{{
 root@d07d7993f8ce:/src/actinia_core# ls -la /mnt/geodata/openeo_bolzano/
 total 5083276
 drwxr-xr-x  7 root root  4096 Nov 21 10:42 .
 drwxr-xr-x 13 1002 1002  4096 Nov 19 12:09 ..
 -rw-r--r--  1 1002 1002 98304 Nov 19 12:07 openeo_bolzano.gpkg
 -rw-r--r--  1 root root 778891069 Nov 19 12:10
 S2A_MSIL1C_20180608T101021_N0206_R022_T32TPS_20180608T135059.zip
 -rw-r--r--  1 root root 666971053 Nov 19 12:10
 S2A_MSIL1C_20180611T102021_N0206_R065_T32TPS_20180611T123241.zip
 drwxr-xr-x  7 root root  4096 Nov 19 12:31
 S2A_MSIL1C_20180618T101021_N0206_R022_T32TPS_20180618T135619.SAFE
 -rw-r--r--  1 root root 855084777 Nov 19 12:10
 S2A_MSIL1C_20180618T101021_N0206_R022_T32TPS_20180618T135619.zip
 drwxr-xr-x  7 root root  4096 Nov 19 12:31
 S2A_MSIL1C_20180621T102021_N0206_R065_T32TPS_20180621T140615.SAFE
 -rw-r--r--  1 root root 800185372 Nov 19 12:10
 S2A_MSIL1C_20180621T102021_N0206_R065_T32TPS_20180621T140615.zip
 drwxr-xr-x  7 root root  4096 Nov 19 12:31
 S2B_MSIL1C_20180606T102019_N0206_R065_T32TPS_20180606T172808.SAFE
 -rw-r--r--  1 root root 730499111 Nov 19 12:10
 S2B_MSIL1C_20180606T102019_N0206_R065_T32TPS_20180606T172808.zip
 drwxr-xr-x  5 root root  4096 Nov 19 12:34
 S2B_MSIL1C_20180613T101019_N0206_R022_T32TPS_20180613T122213.SAFE
 -rw-r--r--  1 root root 574563063 Nov 19 12:11
 S2B_MSIL1C_20180613T101019_N0206_R022_T32TPS_20180613T122213.zip
 drwxr-xr-x  7 root root  4096 Nov 19 12:31
 S2B_MSIL1C_20180616T102019_N0206_R065_T32TPS_20180616T154713.SAFE
 -rw-r--r--  1 root root 798910322 Nov 19 12:11
 S2B_MSIL1C_20180616T102019_N0206_R065_T32TPS_20180616T154713.zip
 -rw-r--r--  1 root root   434 Nov 19 11:58 s2_L1C_scenes.csv
 }}}

-- 
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] #3979: G79: problem with i.sentinel.import and importer.write_metadata()

2019-11-21 Thread GRASS GIS
#3979: G79: problem with i.sentinel.import and importer.write_metadata()
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.sentinel.import, image
   CPU:  |  collections
  Unspecified|   Platform:  Unspecified
-+-

Comment (by martinl):

 What is content of `/mnt/geodata/openeo_bolzano/` dir?

-- 
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] #3979: G79: problem with i.sentinel.import and importer.write_metadata()

2019-11-21 Thread GRASS GIS
#3979: G79: problem with i.sentinel.import and importer.write_metadata()
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.sentinel.import, image
   CPU:  |  collections
  Unspecified|   Platform:  Unspecified
-+-

Comment (by neteler):

 My system here is based on the mundialis GRASS GIS 7.9/PDAL/Python 3
 docker image (Ubuntu).

 I have added, since it is a key error, added a print statement:

 {{{
 WARNING: Raster map  already exists and will
 be
  overwritten
 Importing raster map ...
  100%
 Writing metadata to maps...
 dict_keys(['timestamp', 'SATELLITE', 'CLOUDY_PIXEL_PERCENTAGE',
 'DEGRADED_MSI_DATA_PERCENTAGE', 'ZENITH_ANGLE_0', 'AZIMUTH_ANGLE_0',
 'ZENITH_ANGLE_9', 'AZIMUTH_ANGLE_9', 'ZENITH_ANGLE_10', '
 AZIMUTH_ANGLE_10', 'ZENITH_ANGLE_1', 'AZIMUTH_ANGLE_1', 'ZENITH_ANGLE_2',
 'AZIMUTH_ANGLE_2', 'ZENITH_ANGLE_3', 'AZIMUTH_ANGLE_3', 'ZENITH_ANGLE_4',
 'AZIMUTH_ANGLE_4', 'ZENITH_ANGLE_5', 'AZIM
 UTH_ANGLE_5', 'ZENITH_ANGLE_6', 'AZIMUTH_ANGLE_6', 'ZENITH_ANGLE_7',
 'AZIMUTH_ANGLE_7', 'ZENITH_ANGLE_8', 'AZIMUTH_ANGLE_8', 'ZENITH_ANGLE_11',
 'AZIMUTH_ANGLE_11', 'ZENITH_ANGLE_12', 'AZIMUT
 H_ANGLE_12', 'MEAN_SUN_ZENITH_GRID_ANGLE', 'MEAN_SUN_AZIMUTH_GRID_ANGLE',
 'MEAN_SUN_ZENITH_ANGLE', 'MEAN_SUN_AZIMUTH_ANGLE'])
 dict_keys(['timestamp', 'SATELLITE', 'CLOUDY_PIXEL_PERCENTAGE',
 'DEGRADED_MSI_DATA_PERCENTAGE', 'ZENITH_ANGLE_0', 'AZIMUTH_ANGLE_0',
 'ZENITH_ANGLE_9', 'AZIMUTH_ANGLE_9', 'ZENITH_ANGLE_10', '
 AZIMUTH_ANGLE_10', 'ZENITH_ANGLE_1', 'AZIMUTH_ANGLE_1', 'ZENITH_ANGLE_2',
 'AZIMUTH_ANGLE_2', 'ZENITH_ANGLE_3', 'AZIMUTH_ANGLE_3', 'ZENITH_ANGLE_4',
 'AZIMUTH_ANGLE_4', 'ZENITH_ANGLE_5', 'AZIM
 UTH_ANGLE_5', 'ZENITH_ANGLE_6', 'AZIMUTH_ANGLE_6', 'ZENITH_ANGLE_7',
 'AZIMUTH_ANGLE_7', 'ZENITH_ANGLE_8', 'AZIMUTH_ANGLE_8', 'ZENITH_ANGLE_11',
 'AZIMUTH_ANGLE_11', 'ZENITH_ANGLE_12', 'AZIMUT
 H_ANGLE_12', 'MEAN_SUN_ZENITH_GRID_ANGLE', 'MEAN_SUN_AZIMUTH_GRID_ANGLE',
 'MEAN_SUN_ZENITH_ANGLE', 'MEAN_SUN_AZIMUTH_ANGLE'])
 dict_keys(['timestamp', 'SATELLITE', 'CLOUDY_PIXEL_PERCENTAGE',
 'DEGRADED_MSI_DATA_PERCENTAGE', 'ZENITH_ANGLE_0', 'AZIMUTH_ANGLE_0',
 'ZENITH_ANGLE_9', 'AZIMUTH_ANGLE_9', 'ZENITH_ANGLE_10', '
 AZIMUTH_ANGLE_10', 'ZENITH_ANGLE_1', 'AZIMUTH_ANGLE_1', 'ZENITH_ANGLE_2',
 'AZIMUTH_ANGLE_2', 'ZENITH_ANGLE_3', 'AZIMUTH_ANGLE_3', 'ZENITH_ANGLE_4',
 'AZIMUTH_ANGLE_4', 'ZENITH_ANGLE_5', 'AZIM
 UTH_ANGLE_5', 'ZENITH_ANGLE_6', 'AZIMUTH_ANGLE_6', 'ZENITH_ANGLE_7',
 'AZIMUTH_ANGLE_7', 'ZENITH_ANGLE_8', 'AZIMUTH_ANGLE_8', 'ZENITH_ANGLE_11',
 'AZIMUTH_ANGLE_11', 'ZENITH_ANGLE_12', 'AZIMUT
 H_ANGLE_12', 'MEAN_SUN_ZENITH_GRID_ANGLE', 'MEAN_SUN_AZIMUTH_GRID_ANGLE',
 'MEAN_SUN_ZENITH_ANGLE', 'MEAN_SUN_AZIMUTH_ANGLE'])
 dict_keys(['timestamp', 'SATELLITE', 'CLOUDY_PIXEL_PERCENTAGE',
 'DEGRADED_MSI_DATA_PERCENTAGE', 'ZENITH_ANGLE_0', 'AZIMUTH_ANGLE_0',
 'ZENITH_ANGLE_9', 'AZIMUTH_ANGLE_9', 'ZENITH_ANGLE_10', '
 AZIMUTH_ANGLE_10', 'ZENITH_ANGLE_1', 'AZIMUTH_ANGLE_1', 'ZENITH_ANGLE_2',
 'AZIMUTH_ANGLE_2', 'ZENITH_ANGLE_3', 'AZIMUTH_ANGLE_3', 'ZENITH_ANGLE_4',
 'AZIMUTH_ANGLE_4', 'ZENITH_ANGLE_5', 'AZIM
 UTH_ANGLE_5', 'ZENITH_ANGLE_6', 'AZIMUTH_ANGLE_6', 'ZENITH_ANGLE_7',
 'AZIMUTH_ANGLE_7', 'ZENITH_ANGLE_8', 'AZIMUTH_ANGLE_8', 'ZENITH_ANGLE_11',
 'AZIMUTH_ANGLE_11', 'ZENITH_ANGLE_12', 'AZIMUT
 H_ANGLE_12', 'MEAN_SUN_ZENITH_GRID_ANGLE', 'MEAN_SUN_AZIMUTH_GRID_ANGLE',
 'MEAN_SUN_ZENITH_ANGLE', 'MEAN_SUN_AZIMUTH_ANGLE'])
 [...]
 dict_keys(['timestamp', 'SATELLITE', 'CLOUDY_PIXEL_PERCENTAGE',
 'DEGRADED_MSI_DATA_PERCENTAGE', 'ZENITH_ANGLE_0', 'AZIMUTH_ANGLE_0',
 'ZENITH_ANGLE_9', 'AZIMUTH_ANGLE_9', 'ZENITH_ANGLE_10',
 'AZIMUTH_ANGLE_10', 'ZENITH_ANGLE_1', 'AZIMUTH_ANGLE_1', 'ZENITH_ANGLE_2',
 'AZIMUTH_ANGLE_2', 'ZENITH_ANGLE_3', 'AZIMUTH_ANGLE_3', 'ZENITH_ANGLE_4',
 'AZIMUTH_ANGLE_4', 'ZENITH_ANGLE_5', 'AZIMUTH_ANGLE_5', 'ZENITH_ANGLE_6',
 'AZIMUTH_ANGLE_6', 'ZENITH_ANGLE_7', 'AZIMUTH_ANGLE_7', 'ZENITH_ANGLE_8',
 'AZIMUTH_ANGLE_8', 'ZENITH_ANGLE_11', 'AZIMUTH_ANGLE_11',
 'ZENITH_ANGLE_12', 'AZIMUTH_ANGLE_12', 'MEAN_SUN_ZENITH_GRID_ANGLE',
 'MEAN_SUN_AZIMUTH_GRID_ANGLE', 'MEAN_SUN_ZENITH_ANGLE',
 'MEAN_SUN_AZIMUTH_ANGLE'])
 Traceback (most recent call last):
   File "/root/.grass7/addons/scripts/i.sentinel.import", line 505, in
 
 sys.exit(main())
   File "/root/.grass7/addons/scripts/i.sentinel.import", line 489, in main
 importer.write_metadata()
   File "/root/.grass7/addons/scripts/i.sentinel.import", line 407, in
 write_metadata
 meta = ip_meta[ip]
 KeyError: 'S2B_MSIL1C_20180613T101019_N0206_R022_T32TPS_20180613T122213'
 }}}


 PS: No, 7.8.x does not contain image collection support.

-- 
Ticket URL: 

Re: [GRASS-dev] [GRASS GIS] #3979: G79: problem with i.sentinel.import and importer.write_metadata()

2019-11-21 Thread GRASS GIS
#3979: G79: problem with i.sentinel.import and importer.write_metadata()
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.sentinel.import, image
   CPU:  |  collections
  Unspecified|   Platform:  Unspecified
-+-

Comment (by sbl):

 That`s odd indeed. I cannot reproduce the error with exactly the same
 scene and both trunk and 7.8 on Fedora 30.

 With an older version of trunk:
 {{{
 g.version -rge
 version=7.9.dev
 date=2019
 revision=400349708
 build_date=2019-08-31
 build_platform=x86_64-pc-linux-gnu
 build_off_t_size=8
 libgis_revision=0
 libgis_date="?"
 proj4=5.2.0
 gdal=2.3.2
 geos=3.7.1
 sqlite=3.26.0
 }}}

 as well as a fresh compiled one and 7.8.1:
 {{{
 g.version -rge
 version=7.8.1RC1
 date=2019
 revision=exported
 build_date=2019-11-11
 build_platform=x86_64-redhat-linux-gnu
 build_off_t_size=8
 libgis_revision=0
 libgis_date="?"
 proj=5.2.0
 gdal=2.3.2
 geos=3.7.1
 sqlite=3.26.0
 }}}

 I have no issues with i.sentinel.import with that scene.

 Maybe the download was not 100% OK?
 Do you have other scenes in that directory?

 BTW, does 7.8 support band references?

-- 
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] #3979: G79: problem with i.sentinel.import and importer.write_metadata()

2019-11-21 Thread GRASS GIS
#3979: G79: problem with i.sentinel.import and importer.write_metadata()
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.sentinel.import, image
   CPU:  |  collections
  Unspecified|   Platform:  Unspecified
-+-

Comment (by neteler):

 I added the pdb debugger there:

 {{{
 > /root/.grass7/addons/scripts/i.sentinel.import(407)write_metadata()
 -> meta = ip_meta[ip]
 (Pdb) ip
 'S2A_MSIL1C_20180608T101021_N0206_R022_T32TPS_20180608T135059'
 (Pdb) ip_meta[ip]
 {'timestamp': datetime.datetime(2018, 6, 8, 10, 17, 26, 568000),
 'SATELLITE': 'S2A', 'CLOUDY_PIXEL_PERCENTAGE': '63.2363',
 'DEGRADED_MSI_DATA_PERCENTAGE': '0', 'ZENITH_ANGLE_0': '6.87463083682177',
 'AZIMUTH_ANGLE_0': '106.678480338394', 'ZENITH_ANGLE_9':
 '6.92095256322843', 'AZIMUTH_ANGLE_9': '106.766469213864',
 'ZENITH_ANGLE_10': '6.6711378900598', 'AZIMUTH_ANGLE_10':
 '106.075220597716', 'ZENITH_ANGLE_1': '6.60472703969214',
 'AZIMUTH_ANGLE_1': '105.531721669131', 'ZENITH_ANGLE_2':
 '6.64725248700114', 'AZIMUTH_ANGLE_2': '105.80797975942',
 'ZENITH_ANGLE_3': '6.69114850385045', 'AZIMUTH_ANGLE_3':
 '106.033552825819', 'ZENITH_ANGLE_4': '6.72593186902208',
 'AZIMUTH_ANGLE_4': '106.198282849613', 'ZENITH_ANGLE_5':
 '6.76337836610513', 'AZIMUTH_ANGLE_5': '106.292239966037',
 'ZENITH_ANGLE_6': '6.79969827918603', 'AZIMUTH_ANGLE_6':
 '106.408451382071', 'ZENITH_ANGLE_7': '6.62125461003938',
 'AZIMUTH_ANGLE_7': '105.678569152871', 'ZENITH_ANGLE_8':
 '6.83898070776319', 'AZIMUTH_ANGLE_8': '106.505396826378',
 'ZENITH_ANGLE_11': '6.74365826507417', 'AZIMUTH_ANGLE_11':
 '106.342330082536', 'ZENITH_ANGLE_12': '6.83298026030892',
 'AZIMUTH_ANGLE_12': '106.566283022332', 'MEAN_SUN_ZENITH_GRID_ANGLE':
 26.24232325141777, 'MEAN_SUN_AZIMUTH_GRID_ANGLE': 149.15294328922496,
 'MEAN_SUN_ZENITH_ANGLE': '26.2423240875397', 'MEAN_SUN_AZIMUTH_ANGLE':
 '149.1529063561'}
 }}}

 No idea - I don't see the issue

-- 
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] #3944: Manage access to mapsets gui missing checkboxes

2019-11-21 Thread GRASS GIS
#3944: Manage access to mapsets gui missing checkboxes
---+-
  Reporter:  dnewcomb  |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  normal|  Milestone:  7.8.2
 Component:  Default   |Version:  git-releasebranch78
Resolution:|   Keywords:  gui mapset access
   CPU:  x86-64|   Platform:  MSWindows
---+-

Comment (by neteler):

 See https://github.com/OSGeo/grass/pull/204

-- 
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] #3979: G79: problem with i.sentinel.import and importer.write_metadata()

2019-11-21 Thread GRASS GIS
#3979: G79: problem with i.sentinel.import and importer.write_metadata()
-+-
  Reporter:  neteler |  Owner:  grass-dev@…
  Type:  defect  | Status:  new
  Priority:  normal  |  Milestone:
 Component:  Imagery |Version:  svn-trunk
Resolution:  |   Keywords:  i.sentinel.import, image
   CPU:  |  collections
  Unspecified|   Platform:  Unspecified
-+-

Comment (by neteler):

 Thanks for your efforts but still...:

 {{{
 Importing raster map ...
  100%
 Writing metadata to maps...
 Traceback (most recent call last):
   File "/root/.grass7/addons/scripts/i.sentinel.import", line 503, in
 
 sys.exit(main())
   File "/root/.grass7/addons/scripts/i.sentinel.import", line 487, in main
 importer.write_metadata()
   File "/root/.grass7/addons/scripts/i.sentinel.import", line 406, in
 write_metadata
 meta = ip_meta[ip]
 KeyError: 'S2B_MSIL1C_20180613T101019_N0206_R022_T32TPS_20180613T122213'
 GRASS 7.9.dev (utm32n_32632): >
 }}}

-- 
Ticket URL: 
GRASS GIS 

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