Re: [GRASS-dev] [GRASS GIS] #3815: compression: libzstd should be a default config and a requirement if ZSTD is default compression method

[GRASS GIS]

#3815: compression: libzstd should be a default config and a requirement if ZSTD
is default compression method
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  compression zstd zlib
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by wenzeslaus):

 Problems reported between Oct 31, 2019 and now:

 * [https://lists.osgeo.org/pipermail/grass-dev/2019-December/093800.html
 ZSTD error]
 * [https://lists.osgeo.org/pipermail/grass-dev/2020-May/094351.html ZSTD
 compression error on Windows]

 Generally speaking, changing the default in minor version became challenge
 for users sharing data (locations, packs) with other users
 ([https://lists.osgeo.org/pipermail/grass-dev/2019-December/093802.html
 ...choice of raster compression method...]) since the requirement was
 version 7.6 compiled //with newly introduced ZSTD//. Expected issues
 between major versions, but not minor ones.

 Even more problems were created by compatibility issues between different
 ZSTD versions.

-- 
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] #3815: compression: libzstd should be a default config and a requirement if ZSTD is default compression method

[GRASS GIS]

#3815: compression: libzstd should be a default config and a requirement if ZSTD
is default compression method
--+---
  Reporter:  mlennert |  Owner:  grass-dev@…
  Type:  defect   | Status:  new
  Priority:  normal   |  Milestone:  7.6.2
 Component:  Raster   |Version:  svn-trunk
Resolution:   |   Keywords:  compression zstd zlib
   CPU:  Unspecified  |   Platform:  Unspecified
--+---

Comment (by neteler):

 For the record: in G7.8 and master ZSTD is the default compression:

 *
 https://github.com/OSGeo/grass/blob/releasebranch_7_8/lib/gis/compress.c#L126
 * https://github.com/OSGeo/grass/blob/master/lib/gis/compress.c#L126

 As we didn't get any complaints with that, I suggest to keep it as is.

-- 
Ticket URL: 
GRASS GIS 

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

[GRASS-dev] Week 6 report: Creation of a new GRASS GIS startup mechanism

[L.Kladivova]

Hello Community,




I am sending my report for Week 6 (July 6-July 12). The report can also be
found in the project wiki: https://trac.osgeo.org/…dow
(https://trac.osgeo.org/grass/wiki/GSoC/2020/StartupWindow).





1) What did I complete this week?


I am finalizing the PR Add multiple GRASS databases (see ​https://github.
com/OSGeo/grass/pull/761(https://github.com/OSGeo/grass/pull/761), ​https://
github.com/OSGeo/grass/issues/741(https://github.com/OSGeo/grass/issues/741)
). This PR changes tree.py quite significantly and also adds the new toolbar
button for adding the existing GRASS database. Simultaneously, I have
finished the bigger PR related to new Rename and Delete actions of Location
and Mapset (see ​https://github.com/OSGeo/grass/pull/771
(https://github.com/OSGeo/grass/pull/771), ​https://github.com/OSGeo/grass/
issues/710(https://github.com/OSGeo/grass/issues/710)).





2) What am I going to achieve for next week?


I would finalize on the PR Add multiple GRASS databases (see ​https://
github.com/OSGeo/grass/pull/761(https://github.com/OSGeo/grass/pull/761), ​
https://github.com/OSGeo/grass/issues/741
(https://github.com/OSGeo/grass/issues/741)) and merge the above-mentioned
PRs. I would also start to work on other issues related mainly to the Data
Catalog:

   * Add new location action to database node in Data tab (see ​https://
   github.com/OSGeo/grass/issues/747
   (https://github.com/OSGeo/grass/issues/747))
   * Distinguish label and name of nodes (see ​https://github.com/OSGeo/
   grass/issues/780(https://github.com/OSGeo/grass/issues/780))
   * Add functionality to load only data from the current mapset in the Data
   tree (see ​https://github.com/OSGeo/grass/issues/749
   (https://github.com/OSGeo/grass/issues/749))
   * Startup screen: Distinguish mapsets by ownership and lock (see ​
   https://github.com/OSGeo/grass/issues/714
   (https://github.com/OSGeo/grass/issues/714))


3) Is there any blocking issue?
No, it is not.




Regards,
Linda Kladivova___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

Re: [GRASS-dev] New GUI startup: Next steps in GSoC and beyond

[Helmut Kudrnovsky]

Hi Vaclav, all,


wenzeslaus wrote
> Testing the Location Wizard and Data tab in
> GRASS GIS (from master branch) is also a good way.

just tested master with

GRASS Version: 7.9.dev  
Code revision: e321f7589
Build date: 2020-07-11  
Build platform: x86_64-w64-mingw32  
GDAL: 3.0.4 
PROJ: 6.3.2 
GEOS: 3.8.1 
SQLite: 3.29.0  
Python: 3.7.0   
wxPython: 4.0.7 
Platform: Windows-10-10.0.19041-SP0 (OSGeo4W) 

nice work!

maybe something for beyond GSoC: 

EPSG is reworking their data models [1] and website/web services:

"Following the publication of the revised ISO 19111:2019 data model, IOGP is
in the process of upgrading the EPSG data model. The changes to the data
model being applied to the v10.0 EPSG Dataset and Dataset available via the
Beta Site are:

- Identification of dynamic datums and of CRSs based on these. For datums
and CRSs affected by this change, there will be no changes to existing EPSG
codes.

- Addition of a new construct of ‘datum ensemble’. A datum ensemble groups
together successive realizations of a datum as one. Some CRSs will be
associated with a datum ensemble rather than a single datum. These will
include the generic WGS 84 CRSs (EPSG CRS codes 4326 [geographic 2D], 4979
[geographic 3D] and 4978 [geocentric]). Existing EPSG codes will be
unchanged.

- Addition of a new CRS subtype ‘derived projected’. The term is from the
ISO model and is consistent with other terms in the model, but is a
misnomer. It is a CRS which is based upon an existing projected CRS, so
‘derived from projected’ would be a more accurate description. Many seismic
bin grids are defined relative to a projected CRS – others are defined
independently and later referenced to a projected CRS. Examples of both
approaches will be included in the upgraded dataset.

- Some CRS, datum or coordinate operation entities will be associated with
multiple ‘usages’ – scope/extent (area) pairings."

new PROJ library versions (>=7 AFAIK) will be considering partly these
changes.

a GeoRepository API [2] will be available to query the official EPSG
database.

in future it may be worth to link to the offical EPSG web services/database
instead to epsg.io.

[1] https://epsg.org/data-model-changes.html
[2] https://apps.epsg.org/api/swagger/ui/index





-
best regards
Helmut
--
Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html
___
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev