Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Newcomb, Doug]

On Wed, May 9, 2018 at 4:02 PM, Markus Neteler  wrote:

> On Wed, May 9, 2018 at 9:37 PM, Newcomb, Doug 
> wrote:
> > On Wed, May 9, 2018 at 3:21 PM, Markus Neteler 
> wrote:
> >>
> >> Doug,
> >>
> >> On Wed, May 9, 2018 at 9:17 PM, Newcomb, Doug 
> >> wrote:
> >> > Markus,
> >> > Liblas reads LAS version 1.2 , which is limited to 4.2 billion points.
> >>
> >> I see. But "count" states 297.683.873 which is way less points?
> >
> > Good question
> >
> >> > You have to compile liblas with an older version of laszip .
> >>
> >> Uhm, why an _older_ version?
> >
> > The API to LASzip changed with version 3.   I use LASzip 2.2.0 compiled
> with
> > liblas from 2013 and have no problems so far.   https://laszip.org/ The
> most
> > recent version of 3  was for version 1.4 of the LAS spec.
> >
> > You need to compile current pdal and current  liblas with different
> versions
> > of the Laszip library .
>
> On that machine is PDAL-1.7.0 (wit patches) which requires laszip 3.2.x.
>
> So, to compile liblas with an older laszip would be tricky.
>

On the machine I am using for this  , I have compiled the old laszip as the
system laszip library and compile but do not install the newer one.  I then
point pdal to the directory with the newer version when compiling it.  So
far, that seems to work.


>
> > pdal used to output version 1.2 of las data by default . I t worked fine
> for
> > me at version 1.6 . I have not checked if that is the case with version
> > 1.7.1 .  1.7 had a bug which required a quick bugfix to 1.7.1, by the
> way. (
> > I do not recall the bug off of the top of my head.)
>
> The solution would be the implementation of r.in.pdal:
> https://trac.osgeo.org/grass/ticket/3515


>
> to get rid of liblas which is not developed any more.


> And/or package laz-perf sigh, so many hours already spent on
> packaging...
>
> Markus
>
>
Doug

-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Markus Neteler]

On Wed, May 9, 2018 at 9:37 PM, Newcomb, Doug  wrote:
> On Wed, May 9, 2018 at 3:21 PM, Markus Neteler  wrote:
>>
>> Doug,
>>
>> On Wed, May 9, 2018 at 9:17 PM, Newcomb, Doug 
>> wrote:
>> > Markus,
>> > Liblas reads LAS version 1.2 , which is limited to 4.2 billion points.
>>
>> I see. But "count" states 297.683.873 which is way less points?
>
> Good question
>
>> > You have to compile liblas with an older version of laszip .
>>
>> Uhm, why an _older_ version?
>
> The API to LASzip changed with version 3.   I use LASzip 2.2.0 compiled with
> liblas from 2013 and have no problems so far.   https://laszip.org/ The most
> recent version of 3  was for version 1.4 of the LAS spec.
>
> You need to compile current pdal and current  liblas with different versions
> of the Laszip library .

On that machine is PDAL-1.7.0 (wit patches) which requires laszip 3.2.x.

So, to compile liblas with an older laszip would be tricky.

> pdal used to output version 1.2 of las data by default . I t worked fine for
> me at version 1.6 . I have not checked if that is the case with version
> 1.7.1 .  1.7 had a bug which required a quick bugfix to 1.7.1, by the way. (
> I do not recall the bug off of the top of my head.)

The solution would be the implementation of r.in.pdal:
https://trac.osgeo.org/grass/ticket/3515

to get rid of liblas which is not developed any more.

And/or package laz-perf sigh, so many hours already spent on packaging...

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

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Newcomb, Doug]

On Wed, May 9, 2018 at 3:21 PM, Markus Neteler  wrote:

> Doug,
>
> On Wed, May 9, 2018 at 9:17 PM, Newcomb, Doug 
> wrote:
> > Markus,
> > Liblas reads LAS version 1.2 , which is limited to 4.2 billion points.
>
> I see. But "count" states 297.683.873 which is way less points?
>
Good question


>
> > You have to compile liblas with an older version of laszip .
>
> Uhm, why an _older_ version?
>

The API to LASzip changed with version 3.   I use LASzip 2.2.0 compiled
with liblas from 2013 and have no problems so far.   https://laszip.org/
The most recent version of 3  was for version 1.4 of the LAS spec.

You need to compile current pdal and current  liblas with different
versions of the Laszip library .


> thanks
> Markus
>
>
pdal used to output version 1.2 of las data by default . I t worked fine
for me at version 1.6 . I have not checked if that is the case with version
1.7.1 .  1.7 had a bug which required a quick bugfix to 1.7.1, by the way.
( I do not recall the bug off of the top of my head.)




Doug




-- 
Doug Newcomb
USFWS
551F Pylon Dr
Raleigh, NC
919-856-4520 ext. 14 doug_newc...@fws.gov
-

*NOTE: This email correspondence and any attachments to and from this
sender is subject to the Freedom of Information Act (FOIA) and may be
disclosed to third parties.*​
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Markus Neteler]

Doug,

On Wed, May 9, 2018 at 9:17 PM, Newcomb, Doug  wrote:
> Markus,
> Liblas reads LAS version 1.2 , which is limited to 4.2 billion points.

I see. But "count" states 297.683.873 which is way less points?

> You have to compile liblas with an older version of laszip .

Uhm, why an _older_ version?

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

Re: [GRASS-dev] [EXTERNAL] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[Newcomb, Doug]

Markus,
Liblas reads LAS version 1.2 , which is limited to 4.2 billion points.  You
have to compile liblas with an older version of laszip .

Doug

On Wed, May 9, 2018 at 3:05 PM, GRASS GIS  wrote:

> #3560: r.in.lidar: error to open valid LAZ file
> +-
>  Reporter:  neteler |  Owner:  grass-dev@…
>  Type:  defect  | Status:  new
>  Priority:  normal  |  Milestone:  7.4.1
> Component:  Raster  |Version:  svn-releasebranch74
>  Keywords:  r.in.lidar  |CPU:  Unspecified
>  Platform:  All |
> +-
>  We currently fail to import a larger LiDAR file (LAZ)
>
>  {{{
>  pdal info dom1l_fp_tr_gebiet.laz > meta.txt
>  head -n 300 meta.txt
>  {
>"filename": "dom1l_fp_tr_gebiet.laz",
>"pdal_version": "1.7.0 (git-version: Release)",
>"stats":
>{
>  "bbox":
>  {
>"EPSG:4326":
>{
>  "bbox":
>  {
>"maxx": 7.311614961,
>"maxy": 50.83646173,
>"maxz": 344.69,
>"minx": 7.196437705,
>"miny": 50.78981976,
>"minz": 56.12
>  },
>  "boundary": {
>  "coordinates" :
>  [
>  [
>  [
>  7.198168120001,
>  50.78981976
>  ],
>
>  ...
> "statistic":
>  [
>{
>  "average": 377073.6011,
>  "count": 297683873,
>  "kurtosis": -4.436009717e+18,
>  "maximum": 381000,
>  "minimum": 373000,
>  "name": "X",
>  "position": 0,
>  "skewness": 5.047057151e+17,
>  "stddev": 1853.891145,
>  "variance": 3436912.377
>},
>  }}}
>
>  This file was created with "pdal merge" from several LAZ tiles.
>
>  Now, the import fails without any specific explanation:
>
>  {{{
>  GRASS 7.4.1svn (lidar):/scratch/kaldauen_klassifikation >
>
>  r.in.lidar imput=dom1l_fp_tr_gebiet.laz out=bla
>  FEHLER: Unable to open file 
>  as a LiDAR point cloud
>
>  g.gisenv set="DEBUG=3"
>  r.in.lidar imput=dom1l_fp_tr_gebiet.laz out=bla
>  D1/3: G_set_program_name(): r.in.lidar
>  D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika
>  D2/3: G_file_name(): path = /home/mundialis/grassdata/
> lidar/anika/cell/bla
>  D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/WIND
>  D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/WIND
>  D2/3: file open: read (mode = r)
>  D2/3: G__read_Cell_head
>  D2/3: G__read_Cell_head_array
>  D3/3: region item: proj:   99
>  D3/3: region item: zone:   0
>  D3/3: region item: north:  5631000
>  D3/3: region item: south:  5628000
>  D3/3: region item: east:   379002
>  D3/3: region item: west:   375000
>  D3/3: region item: cols:   1334
>  D3/3: region item: rows:   1000
>  D3/3: region item: e-w resol:  3
>  D3/3: region item: n-s resol:  3
>  D3/3: region item: top:1.000
>  D3/3: region item: bottom: 0.000
>  D3/3: region item: cols3:  1334
>  D3/3: region item: rows3:  1000
>  D3/3: region item: depths: 1
>  D3/3: region item: e-w resol3: 3
>  D3/3: region item: n-s resol3: 3
>  D3/3: region item: t-b resol:  1
>  FEHLER: Unable to open file 
>  as a LiDAR point cloud
>  D1/3: G_set_program_name(): g.gisenv
>  D3/3: G_option_to_separator(): key = separator -> sep = '/'
>  }}}
>
>  To be sure, a check if liblas was compiled with LAZ support:
>
>  {{{
>  ldd `which r.in.lidar`
>  linux-vdso.so.1 (0x7fff91df4000)
>  libgrass_raster.7.4.1svn.so =>
>  /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
>  gnu/lib/libgrass_raster.7.4.1svn.so  0x7f225909b000)
>  libgrass_gis.7.4.1svn.so =>
>  /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
>  gnu/lib/libgrass_gis.7.4.1svn.so (0x7f2258e42000)
>  libm.so.6 => /lib64/libm.so.6 (0x7f2258af7000)
>  libgrass_gproj.7.4.1svn.so =>
>  /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
>  gnu/lib/libgrass_gproj.7.4.1svn.so (0x7f22588ec000)
>  liblas.so.3 => /lib64/liblas.so.3 (0x7f225862b000)
>  liblas_c.so.3 => /lib64/liblas_c.so.3 (0x7f22583f4000)
>  libboost_program_options.so.1.64.0 =>
>  /lib64/libboost_program_options.so.1.64.0 (0x7f2258179000)
>  ...
>  libboost_regex.so.1.64.0 => /lib64/libboost_regex.so.1.64.0
>  (0x7f225454c000)
>  libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f22541c5000)
>  libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2253fae000)
>  librt.so.1 => /lib64/librt.so.1 (0x7f2253da6000)
>  libpthread.so.0 => /lib64/libpthread.so.0 (0x7f2253b88000)
>  libarmadillo.so.7 => /lib64/libarmadillo.so.7 (0x7f225397f000)
>  libpoppler.so.68 => /lib64/libpoppler.so.68 

[GRASS-dev] [GRASS GIS] #3560: r.in.lidar: error to open valid LAZ file

[GRASS GIS]

#3560: r.in.lidar: error to open valid LAZ file
+-
 Reporter:  neteler |  Owner:  grass-dev@…
 Type:  defect  | Status:  new
 Priority:  normal  |  Milestone:  7.4.1
Component:  Raster  |Version:  svn-releasebranch74
 Keywords:  r.in.lidar  |CPU:  Unspecified
 Platform:  All |
+-
 We currently fail to import a larger LiDAR file (LAZ)

 {{{
 pdal info dom1l_fp_tr_gebiet.laz > meta.txt
 head -n 300 meta.txt
 {
   "filename": "dom1l_fp_tr_gebiet.laz",
   "pdal_version": "1.7.0 (git-version: Release)",
   "stats":
   {
 "bbox":
 {
   "EPSG:4326":
   {
 "bbox":
 {
   "maxx": 7.311614961,
   "maxy": 50.83646173,
   "maxz": 344.69,
   "minx": 7.196437705,
   "miny": 50.78981976,
   "minz": 56.12
 },
 "boundary": {
 "coordinates" :
 [
 [
 [
 7.198168120001,
 50.78981976
 ],

 ...
"statistic":
 [
   {
 "average": 377073.6011,
 "count": 297683873,
 "kurtosis": -4.436009717e+18,
 "maximum": 381000,
 "minimum": 373000,
 "name": "X",
 "position": 0,
 "skewness": 5.047057151e+17,
 "stddev": 1853.891145,
 "variance": 3436912.377
   },
 }}}

 This file was created with "pdal merge" from several LAZ tiles.

 Now, the import fails without any specific explanation:

 {{{
 GRASS 7.4.1svn (lidar):/scratch/kaldauen_klassifikation >

 r.in.lidar imput=dom1l_fp_tr_gebiet.laz out=bla
 FEHLER: Unable to open file 
 as a LiDAR point cloud

 g.gisenv set="DEBUG=3"
 r.in.lidar imput=dom1l_fp_tr_gebiet.laz out=bla
 D1/3: G_set_program_name(): r.in.lidar
 D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika
 D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/cell/bla
 D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/WIND
 D2/3: G_file_name(): path = /home/mundialis/grassdata/lidar/anika/WIND
 D2/3: file open: read (mode = r)
 D2/3: G__read_Cell_head
 D2/3: G__read_Cell_head_array
 D3/3: region item: proj:   99
 D3/3: region item: zone:   0
 D3/3: region item: north:  5631000
 D3/3: region item: south:  5628000
 D3/3: region item: east:   379002
 D3/3: region item: west:   375000
 D3/3: region item: cols:   1334
 D3/3: region item: rows:   1000
 D3/3: region item: e-w resol:  3
 D3/3: region item: n-s resol:  3
 D3/3: region item: top:1.000
 D3/3: region item: bottom: 0.000
 D3/3: region item: cols3:  1334
 D3/3: region item: rows3:  1000
 D3/3: region item: depths: 1
 D3/3: region item: e-w resol3: 3
 D3/3: region item: n-s resol3: 3
 D3/3: region item: t-b resol:  1
 FEHLER: Unable to open file 
 as a LiDAR point cloud
 D1/3: G_set_program_name(): g.gisenv
 D3/3: G_option_to_separator(): key = separator -> sep = '/'
 }}}

 To be sure, a check if liblas was compiled with LAZ support:

 {{{
 ldd `which r.in.lidar`
 linux-vdso.so.1 (0x7fff91df4000)
 libgrass_raster.7.4.1svn.so =>
 /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
 gnu/lib/libgrass_raster.7.4.1svn.so  0x7f225909b000)
 libgrass_gis.7.4.1svn.so =>
 /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
 gnu/lib/libgrass_gis.7.4.1svn.so (0x7f2258e42000)
 libm.so.6 => /lib64/libm.so.6 (0x7f2258af7000)
 libgrass_gproj.7.4.1svn.so =>
 /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
 gnu/lib/libgrass_gproj.7.4.1svn.so (0x7f22588ec000)
 liblas.so.3 => /lib64/liblas.so.3 (0x7f225862b000)
 liblas_c.so.3 => /lib64/liblas_c.so.3 (0x7f22583f4000)
 libboost_program_options.so.1.64.0 =>
 /lib64/libboost_program_options.so.1.64.0 (0x7f2258179000)
 ...
 libboost_regex.so.1.64.0 => /lib64/libboost_regex.so.1.64.0
 (0x7f225454c000)
 libstdc++.so.6 => /lib64/libstdc++.so.6 (0x7f22541c5000)
 libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x7f2253fae000)
 librt.so.1 => /lib64/librt.so.1 (0x7f2253da6000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x7f2253b88000)
 libarmadillo.so.7 => /lib64/libarmadillo.so.7 (0x7f225397f000)
 libpoppler.so.68 => /lib64/libpoppler.so.68 (0x7f22534da000)
 libjson-c.so.2 => /lib64/libjson-c.so.2 (0x7f22532cf000)
 libfreexl.so.1 => /lib64/libfreexl.so.1 (0x7f22530c6000)
 libgeos_c.so.1 => /lib64/libgeos_c.so.1 (0x7f2252e95000)
 libwebp.so.7 => /lib64/libwebp.so.7 (0x7f2252c27000)
 ...
 /home/mundialis/software/grass74_svn/dist.x86_64-pc-linux-
 gnu/lib/libgrass_rtree.7.4.1svn.so (0x7f2248669000)
 libbz2.so.1 => /lib64/libbz2.so.1 (0x7f2248458000)
 

Re: [GRASS-dev] GSoC introduction Roberta Fagandini

[Markus Neteler]

On Wed, May 9, 2018 at 10:58 AM, Moritz Lennert
 wrote:
> On 09/05/18 09:41, Roberto Marzocchi wrote:
>>
>> Hi Roberta and Moritz!
>>
>> SCHEMA: Roberta has already written the rules in the schema, but I think
>> you need to open it with a google drive app called diagram.io
>> 
>
> Right, a  lot of hoops to jump through to finally being able to see it, but
> I got there. I'm not much of a user of Google services... ;-)

Alternative: https://www.draw.io/  (we use it a lot, just keep the
resulting XML file yourself or share it yourself)

> But IMHO the schema would be more helpful if it contained the actual rules.
> For example, in the cloud detection procedure, it says "First rule:
> blue-green-red", but this does not provide the actual decision rule. This
> would be helpful to have.

Yes...

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

[GRASS-dev] GSoC project for cloud and shadow detection - request of feedback

[Roberta Fagandini]

Hi all!

I'd like to share with you my GSoC project about an automatic procedure for
the detection of clouds and shadows in Sentinel 2 images.
I'm very interested in knowing what the community thinks of it, so any
suggestion, help, idea, opinion is welcome!

Below you can find the links to my GSoC proposal [0], wiki page [1]
and github repository [2].
Here's [3] the link to the workflow schema of the procedure
(unfortunately it is necessary to open it with a google drive app,
diagram.io [4], to see all the pages).

Thanks in advance for your time and feedback!

Roberta

[0]
https://docs.google.com/document/d/1mQyouqbHGHugn5DjEDZI3hc1eU_bT_b0qLJPPwkt_hk/edit?usp=sharing
[1] https://trac.osgeo.org/grass/wiki/GSoC/2018/CloudsAndShadowsDetection
[2] https://github.com/RobiFag/GRASS_clouds_and_shadows
[3]
https://drive.google.com/file/d/1KYEKvNBurBFHw1xUTLjM0PW80Z-7br81/view?usp=sharing
[4] http://diagram.io/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] GSoC introduction Roberta Fagandini

[Roberta Fagandini]

2018-05-09 13:04 GMT+02:00 Moritz Lennert :

> On 09/05/18 12:46, Roberta Fagandini wrote:
>
>> Hi Moritz and Roberto!
>> As you may already know I sent the email to the PSC list asking for write
>> access to the GRASS-Addons-SVN repository.
>>
>
> Yes, thank you.
>
>
>> 2018-05-09 10:58 GMT+02:00 Moritz Lennert > >:
>>
>> On 09/05/18 09:41, Roberto Marzocchi wrote:
>>
>> Hi Roberta and Moritz!
>>
>> SCHEMA: Roberta has already written the rules in the schema, but
>> I think you need to open it with a google drive app called
>> diagram.io  
>>
>>
>> Right, a  lot of hoops to jump through to finally being able to see
>> it, but I got there. I'm not much of a user of Google services... ;-)
>>
>> This app is not so bad but if you know a better tool, please let me know
>> :-)
>>
>
> I don't know much in terms of online tools in general, so don't worry,
> just keeping using what works for you.
>
>
>>
>> But IMHO the schema would be more helpful if it contained the actual
>> rules. For example, in the cloud detection procedure, it says "First
>> rule: blue-green-red", but this does not provide the actual decision
>> rule. This would be helpful to have.
>>
>>
>> I have just added all the rules.
>>
>
> Thanks !
>
> Not sure I understand, though:
>
> (blue > 0.08(blue))
>
> will always be true. Or do you mean
>
> (blue > 0.08)
>
> ?
>
>
Sorry, I misspelled the rule..the right meaning is (blue > 0.08 *
max(blue)), I missed the max () function but I have already corrected the
schema.


>
> I would send the new email to the list if you agree.
>>
>
> +1
>
> Is there any keyword to be inserted in the mail subject in order to
>> require feedback or hints?
>>
>
> You should definitely start a new thread. Mention your project theme and
> explicitely state that it is a request for feedback.


Ok thank you, I'll send the email after lunch!

Roberta


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

Re: [GRASS-dev] GSoC introduction Roberta Fagandini

[Moritz Lennert]

On 09/05/18 12:46, Roberta Fagandini wrote:

Hi Moritz and Roberto!
As you may already know I sent the email to the PSC list asking for 
write access to the GRASS-Addons-SVN repository.


Yes, thank you.



2018-05-09 10:58 GMT+02:00 Moritz Lennert >:


On 09/05/18 09:41, Roberto Marzocchi wrote:

Hi Roberta and Moritz!

SCHEMA: Roberta has already written the rules in the schema, but
I think you need to open it with a google drive app called
diagram.io  


Right, a  lot of hoops to jump through to finally being able to see
it, but I got there. I'm not much of a user of Google services... ;-)

This app is not so bad but if you know a better tool, please let me know :-)


I don't know much in terms of online tools in general, so don't worry, 
just keeping using what works for you.





But IMHO the schema would be more helpful if it contained the actual
rules. For example, in the cloud detection procedure, it says "First
rule: blue-green-red", but this does not provide the actual decision
rule. This would be helpful to have.


I have just added all the rules. 


Thanks !

Not sure I understand, though:

(blue > 0.08(blue))

will always be true. Or do you mean

(blue > 0.08)

?


I would send the new email to the list 
if you agree.


+1

Is there any keyword to be inserted in the mail subject in 
order to require feedback or hints?


You should definitely start a new thread. Mention your project theme and 
explicitely state that it is a request for feedback.


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

Re: [GRASS-dev] GSoC introduction Roberta Fagandini

[Roberta Fagandini]

Hi Moritz and Roberto!
As you may already know I sent the email to the PSC list asking for write
access to the GRASS-Addons-SVN repository.

2018-05-09 10:58 GMT+02:00 Moritz Lennert :

> On 09/05/18 09:41, Roberto Marzocchi wrote:
>
>> Hi Roberta and Moritz!
>>
>> SCHEMA: Roberta has already written the rules in the schema, but I think
>> you need to open it with a google drive app called diagram.io <
>> http://diagram.io>
>>
>
> Right, a  lot of hoops to jump through to finally being able to see it,
> but I got there. I'm not much of a user of Google services... ;-)
>

This app is not so bad but if you know a better tool, please let me know :-)


>
> But IMHO the schema would be more helpful if it contained the actual
> rules. For example, in the cloud detection procedure, it says "First rule:
> blue-green-red", but this does not provide the actual decision rule. This
> would be helpful to have.


I have just added all the rules. I would send the new email to the list if
you agree. Is there any keyword to be inserted in the mail subject in order
to require feedback or hints?

Thanks!
Roberta


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

Re: [GRASS-dev] Regarding testing

[Luca Delucchi]

On 8 May 2018 at 07:39, Sanjeet  wrote:
>
> Hi Anna,
>

Hi,

> I made some minor changes in 'utils.py' in lib/python/script and
> 'test_utils.py' in its testsuite.
> https://github.com/sanjeetbhatti/FullSupportPython3/blob/master/patch.diff
>
> The Python 3's bytes cannot contain ASCII literal characters,
> therefore I can't seem to test it as such, I encoded it first before
> checking for an assertion, which I am not sure is a correct way to do
> so as we are ensuring that we do not pass any bytes with ASCII literal
> characters.

could be this a problem with languages using strange accent mark?
We had and have problem with some languages in translations

> Same thing is in test_start_command_functions.py.
> Moreover, I generalized the encode and decode functions by using
> string conversion for int and float values.
>
> Please let me know if this is the correct way to go about it.
>

It seems correct to me, but please Anna answer

> Thanks
> --
> Sanjeet Bhatti



-- 
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] GSoC introduction Roberta Fagandini

[Moritz Lennert]

On 09/05/18 09:41, Roberto Marzocchi wrote:

Hi Roberta and Moritz!

SCHEMA: Roberta has already written the rules in the schema, but I think 
you need to open it with a google drive app called diagram.io 



Right, a  lot of hoops to jump through to finally being able to see it, 
but I got there. I'm not much of a user of Google services... ;-)


But IMHO the schema would be more helpful if it contained the actual 
rules. For example, in the cloud detection procedure, it says "First 
rule: blue-green-red", but this does not provide the actual decision 
rule. This would be helpful to have.


Moritz

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

Re: [GRASS-dev] GSoC introduction Roberta Fagandini

[Roberto Marzocchi]

Hi Roberta and Moritz!

SCHEMA: Roberta has already written the rules in the schema, but I think
you need to open it with a google drive app called diagram.io

New mail to GRASS-DEV : +1

R



2018-05-08 18:10 GMT+02:00 Roberta Fagandini :

> Hi Moritz and Roberto!
> Here [0] you can find the updated version of the project wiki page!
> Tomorrow I'll better detail the procedure schema and then I'll share
> everything with the grass dev list asking for feedback.
> At the same time, I want to follow the procedure for access to the
> GRASS-Addons-SVN repository (maybe another thing to do during the bonding
> period ).
>
> Roberta
>
> [0] https://trac.osgeo.org/grass/wiki/GSoC/2018/CloudsAndShadowsDetection
>
> 2018-05-08 13:42 GMT+02:00 Moritz Lennert :
>
>> On 08/05/18 13:38, Roberta Fagandini wrote:
>>
>>>
>>>
>>> 2018-05-08 9:59 GMT+02:00 Moritz Lennert >> >:
>>> Thanks ! I think the most interesting part would actually be the
>>> details of the two detection procedures, so it would be good to
>>> detail them :-).
>>>
>>>
>>> Yes, I will add all the rules from the procedure file. Then I'd like to
>>> send a new mail with all the links related to the project (wiki, github and
>>> schema) to the grass dev list asking for feedback, hints, etc. What do you
>>> think?
>>>
>>
>>
>> Good idea.
>>
>> :-)
>>
>> Moritz
>>
>
>
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3223: r.info displays wrong timestamp after t.rast.series with a where clause

[GRASS GIS]

#3223: r.info displays wrong timestamp after t.rast.series with a where clause
--+-
  Reporter:  veroandreo   |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  normal   |  Milestone:  7.4.1
 Component:  Default  |Version:  svn-trunk
Resolution:  fixed|   Keywords:  r.info
   CPU:  Unspecified  |   Platform:  Linux
--+-
Changes (by veroandreo):

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


Comment:

 Replying to [comment:5 neteler]:
 > Please close the ticket if issue is solved.
 I had left it open because there's an open question (see comment 3).
 However, since the issue is fixed, I close it now. Re-open if needed.

-- 
Ticket URL: 
GRASS GIS 

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