Re: [GRASS-dev] Try GRASS GIS online: CoCalc - cocalc.com

[Markus Neteler]

On Fri, Aug 16, 2019 at 3:41 PM Markus Neteler  wrote:
> On Fri, Aug 16, 2019 at 11:14 AM Stefan Blumentrath
>  wrote:
> >
> > BTW, now also the GUI is installed.
> >
> > They replied very quickly to my request… And the size of CoCal is likely 
> > due to their apparent concept of offering “everything” by default…
>
> ... where would I find GRASS GIS on CoCal? I don't see it (yet) on their 
> page...

Meanwhile it is visible:

https://cocalc.com/doc/software-executables.html#Grass

Next: convince them to update to 7.8 :-)
Stefan, maybe you could contact them again?

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

Re: [GRASS-dev] [GRASS GIS] #4009: 'where' option in v.to.rast can select wrong feature for raster attribute, in areas where features overlap

[GRASS GIS]

#4009: 'where' option in v.to.rast can select wrong feature for raster 
attribute,
in areas where features overlap
+-
  Reporter:  florisvdh  |  Owner:  grass-dev@…
  Type:  defect | Status:  new
  Priority:  normal |  Milestone:  7.8.3
 Component:  Vector |Version:  svn-releasebranch76
Resolution: |   Keywords:  v.to.rast sql where
   CPU:  x86-64 |   Platform:  Linux
+-

Comment (by mmetz):

 I think I have a fix for this bug, but I would like to test the fix first
 with your data. Can you provide a small spatial extract of your data that
 can be used to reproduce the problem? Thanks!

-- 
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] #3990: v.to.db: add a way to control output precision

[GRASS GIS]

#3990: v.to.db: add a way to control output precision
--+-
  Reporter:  jidanni  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  trivial  |  Milestone:  7.8.3
 Component:  Database |Version:  unspecified
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 While I am not sure if it is worth it to cut off precision, it could be
 done in a way as v.out.ascii offers it:

 {{{
   precision   Number of significant digits (floating point only)
   options: 0-32
   default: 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] [GRASS GIS] #3992: v.import man page should say what -f's ro, rw, and rw+ are

[GRASS GIS]

#3992: v.import man page should say what -f's ro, rw, and rw+ are
--+-
  Reporter:  jidanni  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  trivial  |  Milestone:  7.8.3
 Component:  Docs |Version:  git-releasebranch78
Resolution:   |   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-

Comment (by neteler):

 For reference, the output is

 {{{
 v.import -f
 Supported formats:
  PCIDSK (rw+): PCIDSK Database File
  netCDF (rw+): Network Common Data Format
  JP2OpenJPEG (rw): JPEG-2000 driver based on OpenJPEG library
  JPEG2000 (rw): JPEG-2000 part 1 (ISO/IEC 15444-1), based on Jasper
 library
  PDF (rw+): Geospatial PDF
 ...
 }}}

 The `ro`, `rw`, and `rw+` may come from GDAL/OGR. Since v.import is a
 wrapper around v.in.ogr, the related source code is this (main.c):

 {{{
 if (GDALGetMetadataItem(hDriver, GDAL_DCAP_CREATE, NULL))
 pszRWFlag = "rw+";
 else if (GDALGetMetadataItem(hDriver, GDAL_DCAP_CREATECOPY,
 NULL))
 pszRWFlag = "rw";
 else
 pszRWFlag = "ro";
 }}}

 In GDAL itself I cannot find `pszRWFlag`, so no idea what it does and if
 it is still relevant...

 One reference seems to be this:
 https://gdal.org/api/raster_c_api.html#c.GDAL_DCAP_CREATECOPY

 I agree that the meaning of `ro`, `rw`, and `rw+` should be explained in
 the manual pages of r/v.import and r.in.gdal/v.in.ogr.

-- 
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] #3991: m.measure: mention square feet

[GRASS GIS]

#3991: m.measure: mention square feet
--+-
  Reporter:  jidanni  |  Owner:  grass-dev@…
  Type:  defect   | Status:  closed
  Priority:  trivial  |  Milestone:  7.8.3
 Component:  Docs |Version:  git-releasebranch78
Resolution:  fixed|   Keywords:  m.measure
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

 * keywords:   => m.measure
 * status:  new => closed
 * resolution:   => fixed


Comment:

 It works:

 {{{
 GRASS 7.8.2dev (nc_spm_08):~ > m.measure units=meters
 coordinates=922000,2106000,923000,2106000,923000,2107000,922000,2107000
 Length:  3000.00 meters
 Area:100.00 square meters

 GRASS 7.8.2dev (nc_spm_08):~ > m.measure units=feet
 coordinates=922000,2106000,923000,2106000,923000,2107000,922000,2107000
 Length:  9842.519685 feet
 Area:10763910.416710 square feet
 }}}

 Manual updated accordingly.

-- 
Ticket URL: 
GRASS GIS 

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

Re: [GRASS-dev] any special reason why choice of raster compression method is done via environmental variable ?

[Markus Metz]

On Tue, Dec 10, 2019 at 6:47 AM Moritz Lennert 
wrote:
>
> On 9/12/19 22:50, Markus Metz wrote:
> >   Hi Moritz,
> >
> > On Wed, Dec 4, 2019 at 10:28 AM Moritz Lennert
> > mailto:mlenn...@club.worldonline.be>>
wrote:
> >  >
> >  > Hi Markus,
> >  >
> >  > In recent days, I've been confronted several times with the issue of
> >  > people trying to share data among themselves, but using different
> >  > versions of GRASS, and so raster data compressed in a more recent
> >  > version of GRASS was not usable in an older version of GRASS.
> >  >
> >  > Now, I agree that generally the solution is to tell people to use the
> >  > latest and greatest, but this is not always possible / it is not
> >  > necessarily highest on the list of priorities of people to see how
they
> >  > can install the latest version of GRASS within their particular
> > environment.
> >  >
> >  > Obviously, those with the latest version of GRASS can simple
recompress
> >  > using ZLIB. However, compression method is defined as an environment
> >  > variable. This is somewhat daunting to many MS Windows users out
there.
> >  > Is there any specific reason that lead to the choice of not using a
> >  > parameter to allow the choice of compression method (possibly to
> >  > override a default that is still defined by an environment variable)
?
> >
> > Such a parameter would need to be added to every module creating raster
> > output.
>
> My request is more linked to use cases where one would like to share
> data (e.g. with r.pack) with other GRASS GIS users who do not
> necessarily have access to the same compression method, not necessarily
> to changing the default compression method. I was just wondering whether
> it might be easily possible to just implement r.compress method= as a
> quick way to recompress a specific map with a chosen method, overriding
> the default method. Currently, to do that, you have to change the
> default method by changing the env variable, run r.compress, then change
> the variable back to the value one wishes generally to use as default.

recompressing an existing raster map seems like a waste of time. Why not
compress it in the first place with the appropriate method?

Recompressing an existing map with a chosen method via r.compress method=XY
means that a new raster map should not be compressed with the default
method but another supported method. This would require a new function in
lib/raster like Rast_open_new_compression_method() that overrides the
default compression method. Of course this is possible, but it requires
substantial changes to lib/raster.

About the use cases:
People want to share a mapset: in this case all GRASS raster maps should be
compressed with the most compatible compression method (ZLIB). Currently,
this can be done with an env var. Alternatively, a new mechanism via
g.gisenv could be established.
Another option could be to set the default compression method per mapset,
to be stored in in the mapset's VAR file, to be set with e.g. r.compress
method=.

The point is that it is fairly easy to set a suitable compression method
before the raster lib is initialized, and there are different possible
mechanisms apart from the current method using an env var that are easy to
implement.

> Obviously, you can always just export as tiff and share that, but that
> just feels less elegant. Anyway, this is probably somewhat of a luxury
> problem :-)

This only a luxury problem if you don't need to care about processing speed
and disk usage. The different compression methods by now available in GRASS
allow for optimization for speed (LZ4) or for optimization for disk usage
(BZIP2 for larger CELL maps). An easy (easier) way to set the compression
method seems reasonable.

Markus M

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

Re: [GRASS-dev] [GRASS GIS] #3993: v.import: document snap=-1

[GRASS GIS]

#3993: v.import: document snap=-1
--+-
  Reporter:  jidanni  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  closed
  Priority:  trivial  |  Milestone:  7.8.3
 Component:  Docs |Version:  unspecified
Resolution:  fixed|   Keywords:
   CPU:  Unspecified  |   Platform:  Unspecified
--+-
Changes (by neteler):

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


Comment:

 Good point, I have added

 "The default value of snap=-1 means that no snapping will be done."

 https://github.com/OSGeo/grass/commit/fabfb08b3054d26f37e15fbe0d5159047deb5c78

-- 
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] #3582: Removing a Mapset from inside a GRASS GIS session

[GRASS GIS]

#3582: Removing a Mapset from inside a GRASS GIS session
---+---
  Reporter:  Nikos Alexandris  |  Owner:  grass-dev@…
  Type:  enhancement   | Status:  new
  Priority:  normal|  Milestone:  7.8.3
 Component:  Default   |Version:  unspecified
Resolution:|   Keywords:  mapset, remove, delete, erase
   CPU:  Unspecified   |   Platform:  Unspecified
---+---

Comment (by neteler):

 Replying to [comment:1 jidanni]:
 > And mentioned on grass7.html, which tells one how to create them from
 > the command line, but forgets to then add how to remove them!

 If you can, please suggest an edit (PR) here:

 https://github.com/OSGeo/grass/blob/master/lib/init/grass7.html

-- 
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] #3987: Some pages missing from the Full Index

[GRASS GIS]

#3987: Some pages missing from the Full Index
--+
  Reporter:  jidanni  |  Owner:  grass-dev@…
  Type:  enhancement  | Status:  new
  Priority:  trivial  |  Milestone:  7.8.3
 Component:  Docs |Version:  unspecified
Resolution:   |   Keywords:  index keywords
   CPU:  Unspecified  |   Platform:  Unspecified
--+

Comment (by neteler):

 Pls check the modified full index creation to include "variables" etc:

 https://github.com/OSGeo/grass/pull/258

-- 
Ticket URL: 
GRASS GIS 

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