Re: [GRASS-dev] Busy SQLITE db

[Markus Neteler]

Hi Luca,

On Mon, May 4, 2020 at 10:47 AM Luca Delucchi  wrote:
>
> Hi all,
>
> I'm facing the problem with Busy SQLITE db using GRASS 7.8 in a HPC system.

Which file system do you use?

> Reading other problems like that I saw a Metz answer [0] and another
> from Luis [1] but I'm not able to fix the problem. Now the mapset is
> unusable with vector.
>
> Do you have any idea how to solve the problem and where it come from?
>
> g.remove type=vector name=nuts2_lst_2003_daily -f
> Removing vector 
> WARNING: Busy SQLITE db, already waiting for 10 seconds...
> WARNING: Busy SQLITE db, already waiting for 20 seconds...

Do you use NFS by chance?

ciao,
markusN

> [0] 
> http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html
> [1] 
> https://gis.stackexchange.com/questions/321986/grass-what-to-do-when-the-sqlite-database-becomes-busy
>
> --
> ciao
> Luca
>
> www.lucadelu.org

-- 
Markus Neteler, PhD
https://www.mundialis.de - free data with free software
https://grass.osgeo.org
https://courses.neteler.org/blog
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Busy SQLITE db

[Luca Delucchi]

On Mon, 4 May 2020 at 11:18, Stefan Blumentrath
 wrote:
>
> Ciao Luca,
>

Ciao Stefan,

> If you have stale processes e.g. on cluster nodes that have the DB opened 
> this may occur.
>

first time it happen---

> Also the file system can have an impact (e.g. writing to an SQLite DB on a 
> CIFS file system from Linux is simply impossible). But that should give a 
> different error message.
>
> So I would look for hanging processes... And you could try to copy the 
> mapset, remove the old one and rename the copy back...
>
yes, I would avoid this, but it worked

> Cheers
> Stefan
>

-- 
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] [GRASS GIS] #3913: new feature band reference breaks space time vector datasets

[GRASS GIS]

#3913: new feature band reference breaks space time vector datasets
---+-
  Reporter:  mmetz |  Owner:  grass-dev@…
  Type:  defect| Status:  closed
  Priority:  blocker   |  Milestone:  8.0.0
 Component:  Temporal  |Version:  svn-trunk
Resolution:  fixed |   Keywords:  image collections,stvds
   CPU:  All   |   Platform:  All
---+-
Changes (by martinl):

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


-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Calling all imagery (especially i.maxlik and i.smap) users

[Veronica Andreo]

Hi Māris,

Yes, with GRASS 8 in the horizon, this is the right time to change some
things.

[...]

> #1 Should there be subgroups at all?
> There has been a call to completely eliminate subgroups [1] and stick
> only with groups. If you are using subgroups, this is the right moment
> to share your user story (and not hypothetical one!).
>

I do not use subgroups at all, indeed I'm mostly annoyed by modules asking
for subgroups, too. Moreover, in the hypothetical case of using subgroups
to store for example only bands, indices, textures, etc., some very useful
addons like r.learn.ml do not consider subgroups, hence I'd still need to
create different groups anyway.
I'm totally in favour of removing subgroups.


> #2 Should i.maxlik add its output to the group?
> Current implementation of i.maxlik adds classification result to the
> input group [2]. This prevents use of i.maxlik with imagery group from
> other mapset. I would vote to remove such feature. If you have a use
> case where such functionality is needed, speak now, or forever hold
> your peace.
>

+1 for removal of this behaviour too


> #3 Should signature files be handled similarly to raster colors?
> i.cluster, i.gensig and i.gensigset write signature files to imagery
> subrgoup. This is not possible if group is located in other mapset. My
> proposal — handle signatures as raster colours — signatures are always
> saved in current mapset. Thus signatures created for a group in other
> mapset would be not visible in other mapsets.
>

Fully agree with Sajid here

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

Re: [GRASS-dev] [GRASS GIS] #3913: new feature band reference breaks space time vector datasets

[GRASS GIS]

#3913: new feature band reference breaks space time vector datasets
---+-
  Reporter:  mmetz |  Owner:  grass-dev@…
  Type:  defect| Status:  new
  Priority:  blocker   |  Milestone:  8.0.0
 Component:  Temporal  |Version:  svn-trunk
Resolution:|   Keywords:  image collections,stvds
   CPU:  All   |   Platform:  All
---+-

Comment (by annakrat):

 This can be closed, right? The PR is merged.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] Let's talk about releases - 7.8.3, 7.10, 8.0

[Vaclav Petras]

On Thu, Apr 30, 2020 at 9:59 PM Vaclav Petras  wrote:

> Dear users and devs,
>
> I though it would be a good idea to video meet next week and talk about
> what would be the best way of releasing GRASS GIS in the future. As always,
> both contributors and users are invited to share ideas and opinions.
>
> ...
>
> PS: If you are answering to this email, I cross posted it to both user and
> dev mailing lists, so you may want to take care to reply to just one
> mailing list.
>

Scenario 2 on the following page is my attempt to capture the main scenario
we talked about during the call. Thanks to all who participated!

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

Re: [GRASS-dev] [release planning] GRASS GIS 7.8.3

[Nicklas Larsson]

Hi,

> On 5 May 2020, at 11:19, Markus Neteler  wrote:
> 
> Hi,
> 
> the GRASS GIS 7.8.3 release is out:
> 
> https://github.com/OSGeo/grass/releases/tag/7.8.3

the 7.8.3 is now available for mac on MacPorts [1]. It would be good if this 
could be mentioned on the download section [2].

Thanks a lot to all of you grass-devs!

/Nicklas



[1] https://www.macports.org, https://ports.macports.org/port/grass7/summary

[2] https://grass.osgeo.org/download/software/mac-osx/
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] Let's talk about releases - 7.8.3, 7.10, 8.0

[Maris Nartiss]

Thanks, Vaclav, for taking initiative into your hands. Please send us
approximate time of the new startup screen discussion meeting.

All best,
Māris.

otrd., 2020. g. 5. maijs, plkst. 21:10 — lietotājs Vaclav Petras
() rakstīja:
>
> New URL (Zoom):
>
> https://ncsu.zoom.us/j/95921808290?pwd=UnVOa0VHN2gvbWJLbDExNEJ4TWU3Zz09
> ___
> 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] Calling all imagery (especially i.maxlik and i.smap) users

[Maris Nartiss]

Hello lists (sorry for cross-posting),
as GRASS 8 starts to look less Duke Nukem Forever (a.k.a. never), it
is a chance to change some things in imagery part. Thus if you heavy
relay on imagery part of GRASS GIS, please find some time to give
small feedback.

GRASS 7.8.0 imagery groups gained functionality of fully qualified
maps and thus could be used from other mapsets, still some issues
popped up.

#1 Should there be subgroups at all?
There has been a call to completely eliminate subgroups [1] and stick
only with groups. If you are using subgroups, this is the right moment
to share your user story (and not hypothetical one!).

#2 Should i.maxlik add its output to the group?
Current implementation of i.maxlik adds classification result to the
input group [2]. This prevents use of i.maxlik with imagery group from
other mapset. I would vote to remove such feature. If you have a use
case where such functionality is needed, speak now, or forever hold
your peace.

#3 Should signature files be handled similarly to raster colors?
i.cluster, i.gensig and i.gensigset write signature files to imagery
subrgoup. This is not possible if group is located in other mapset. My
proposal — handle signatures as raster colours — signatures are always
saved in current mapset. Thus signatures created for a group in other
mapset would be not visible in other mapsets.

Thank you in advance for your feedback,
Māris.

1. https://trac.osgeo.org/grass/ticket/3440
2. https://trac.osgeo.org/grass/ticket/3525
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] [GRASS GIS] #3440: imagery groups and subgroups: get rid of subgroups?

[GRASS GIS]

#3440: imagery groups and subgroups: get rid of subgroups?
--+--
  Reporter:  mmetz|  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  normal   |  Milestone:  8.0.0
 Component:  Imagery  |Version:  svn-trunk
Resolution:   |   Keywords:  imagery, group, subgroup
   CPU:  All  |   Platform:  All
--+--

Comment (by marisn):

 (Copypasta from G8 discussion page)
 One of options could be auto creating some "magic" subgroups as i.e.
 "_all" - all raster maps in a group (aka if subgroup is not set, use all
 maps from group); "_initial" - only imported remote sensing layers (equals
 "_all" if no new maps are added later); "RGB" - if source is RGB or RGB
 can be defined (I would love to be able to have an option to choose a
 group in d.rgb and get RGB subgroup selected as a default instead of
 searching for separate channels — would require to keep channel metadata
 on import)

-- 
Ticket URL: 
GRASS GIS 

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