Re: [GRASS-dev] communication of community sprint decisions

[Vaclav Petras]

On Mon, Jan 13, 2020 at 3:00 PM Markus Neteler  wrote:

> On Mon, Jan 13, 2020 at 8:22 PM Vaclav Petras 
> wrote:
> > On Sat, Jan 11, 2020 at 6:10 AM Markus Neteler 
> wrote:
> >> Hi Prague-2019 sprinters, all,
> >>
> >> On Fri, Dec 20, 2019 at 8:52 AM Vaclav Petras 
> wrote:
> >> > On Wed, Dec 18, 2019 at 9:44 AM Veronica Andreo 
> wrote:
> >> >>
> >> >>
> >> >> I've been reading the discussion page at:
> https://grasswiki.osgeo.org/wiki/Talk:GRASS_GIS_Community_Sprint_Prague_2019
> and I see that we should open new bug reports or feature requests directly
> in GitHub. When does this decision start to take effect?
> >> >>
> >> >> I think it is important to communicate this broadly to the user
> community through grass-user list
> >> >
> >> >
> >> > Yes. I wrote it there and what I meant by putting this into
> "Decisions made" section is that we made that decision, but it won't happen
> until the steps are done, i.e. until we allow opening issues on GitHub,
> disallow opening new issues on Trac, and announce this on mailing lists.
> >>
> >> Shall we go for this? What do you think?
> >> I would like to see GH issues enabled now.
> >
> >
> > The plan assumes that Trac allows removing the privilege to create
> tickets for all users, but leaving tickets editable. Can you please check
> that?
>
> We could change it to this:
>
> [X] TICKET_VIEW
> [  ] TICKET_CREATE
> [X] TICKET_MODIFY
>

Sounds right.


>
> > Perhaps even the New Ticket in top menu bar could be replaced by link to
> GitHub for those used to Trac, but that's a low priority.
>
> That seems to be easy:
>
> https://trac.edgewall.org/wiki/TracInterfaceCustomization#CustomNavigationEntries


Great!


> Let's go for it!
>

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

Re: [GRASS-dev] Does it exist a fast way to know the type of raster without using r.info

[Taïs]

Hi again,

I think I did something wrong and was trying to run r.info at the same 
time that the raster was overwriting.


I just make a new attempt and r.info runs fast, as expected.

Sorry to bother you guys.

You can consider this topic close.

Le 13/01/20 à 15:13, Taïs a écrit :

Hi all,

The add-on r.zonal.classes uses r.info to check if the provided 
rasters are in CELL because r.stats require a CELL raster as input.


The problem is that for heavy raster, running r.info takes ages 
compared to r.stats and thus create a bottleneck.


I'm looking for another to get the info about the type of raster 
(CELL, FCELL,...) which will be much faster. Some of you have any idea ?


Thanks

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

[GRASS-dev] [GRASS GIS] #4020: r.in.lidar / v.in.lidar missing in Ubunutgis package

[GRASS GIS]

#4020: r.in.lidar / v.in.lidar missing in Ubunutgis package
---+-
 Reporter:  sbl|  Owner:  grass-dev@…
 Type:  defect | Status:  new
 Priority:  normal |  Milestone:
Component:  Packaging  |Version:  unspecified
 Keywords:  Ubuntugis  |CPU:  All
 Platform:  Linux  |
---+-
 Ubunutgis package for GRASS GIS 7.8 is build without liblas support, thus
 r.in.lidar / v.in.lidar modules are missing.

 See:
 https://launchpadlibrarian.net/455539996/buildlog_ubuntu-bionic-
 amd64.grass_7.8.2-1~bionic1_BUILDING.txt.gz
 (and search for dh_auto_configure).

 Note that dependencies (I guess liblas-dev) are not installed prior to
 configuration either.

 See: https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-
 unstable/+sourcepub/10345798/+listing-archive-extra for available liblas
 packages from UbuntuGIS unstable.

-- 
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] #4020: r.in.lidar / v.in.lidar missing in Ubunutgis package

[GRASS GIS]

#4020: r.in.lidar / v.in.lidar missing in Ubunutgis package
+-
  Reporter:  sbl|  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Packaging  |Version:  unspecified
Resolution: |   Keywords:  Ubuntugis
   CPU:  All|   Platform:  Linux
+-

Comment (by Bas Couwenberg):

 libLAS is deprecated and PDAL should be used instead, the
 [https://liblas.org/ libLAS website] documents this:
 > As of 2018, libLAS has been replaced by the [https://pdal.io/ PDAL]
 project and it is in hibernation or maintenance mode. libLAS does not
 provide support for LAS or LAZ 1.4, which PDAL does. PDAL also provides
 support for many more formats, the notion of
 [https://www.pdal.io/pipeline.html PDAL pipelines], Python support, and
 has packages for OSGeo4W, !Docker/Ubuntu/Alpine, and OSX Homebrew.
 Additionally, libLAS’ Python capabilities are much better expressed by the
 pure-Python [http://laspy.org laspy] library, and if manipulating LAS data
 in Python is your ultimate desire, use that instead of libLAS.

 The liblas package has been from Debian, and hence the grass package is
 only built with pdal. Because the grass package in UbuntuGIS uses the same
 source as Debian it likewise no longer supports liblas.

 While liblas is still available in Ubuntu bionic, their next LTS (focal)
 won't have it either as it was removed in eoan.

 Functionality provided by *.in.lidar should be ported to their *.in.pdal
 counterparts or port *.in.lidar to use PDAL instead of libLAS.

-- 
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] #4020: r.in.lidar / v.in.lidar missing in Ubunutgis package

[GRASS GIS]

#4020: r.in.lidar / v.in.lidar missing in Ubunutgis package
+-
  Reporter:  sbl|  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:
 Component:  Packaging  |Version:  unspecified
Resolution: |   Keywords:  Ubuntugis
   CPU:  All|   Platform:  Linux
+-

Comment (by neteler):

 Replying to [comment:1 Bas Couwenberg]:
 > Functionality provided by *.in.lidar should be ported to their *.in.pdal
 counterparts or port *.in.lidar to use PDAL instead of libLAS.

 Yes.

 See also https://github.com/OSGeo/grass/pull/61 ("WIP r.in.pdal - PDAL-
 based version of r.in.lidar") ... to be completed and extended to
 v.in.lidar.

-- 
Ticket URL: 
GRASS GIS 

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