Re: [GRASS-user] r.3.count.categories compression error -14

2020-07-16 Thread Olivier . C . Canon

Hi Markus,

no, I’m working on the same machine all the time. As external input  
data I use point cloud data in las-format that were generated with  
drone deploy. I had some trouble with the point clouds in the  
beginning, but I managed to convert them and load them in grass. The  
processing of the point clouds (rasterization, calculation of  
fragmentation index) works well now. I also use the DTM from  
Dronedeploy as base raster, but that shouldn’t have an effect on the  
rasterized point cloud.



Zitat von Markus Neteler :


Hi Olivier,

 schrieb am Do., 16. Juli 2020,
15:38:


Hello everyone,

I’m using the 3D-Forest-Fragementation Modul developed by Vaclav and
have produced a workflow for the calculation. It is working well and
I’m getting plausible results. While applying this workflow for my
whole study region (35 plots/regions) it only works for about 50 % of
the plots. The others fail at the step where I use
r3.count.categories. I can’t see the link respectively the difference
for this error. That’s why am asking for a hint:

I’m running Grass 7.8.2 (64 bit), Python 3.7.0, wxPython 4.0.7 on Windows
10

The problem occurs while running this command:

"r3.count.categories input=ff_mean_131_2 output=ff_mean_131_2_count
slices=ff_mean_131_2_slice --overwrite"

With this error:

"[…]
Raster map 22 Filename: ff_mean_131_2_slice_00022
Raster map 23 Filename: ff_mean_131_2_slice_00023
WARNING: ZSTD compression error -14: Unsupported frame parameter
ERROR: Error uncompressing raster data



Did you copy by chance the data from a different machine?

This error comes to mind:

https://lists.osgeo.org/pipermail/grass-user/2019-March/080180.html

Best
markusN


for row 43 of


ERROR: An error occurred while running r.mapcalc with expression:
ff_mean_131_2_count_0 = int(ff_mean_131_2_slice_1 == 0) + […]"

For each failing plot the error occurs in this step. The slices seem
to be generated correctly. I couldn’t see differences while displaying
them or comparing the raster metadata.
In the different plot its always another slice (2D Raster) and another
row where the uncompressing fails. I tried to reduce the plot-size and
found out, that the error occurs always in the same row of a plot. If
this row is excluded, it works fine.
That’s why I think it has nothing to do with missing space on disk, or
not enough calculating capacity.
Has someone an idea what’s the problem? Thanks very much!

Greetings,
Olivier



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




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

Re: [GRASS-user] r.3.count.categories compression error -14

2020-07-16 Thread Markus Neteler
Hi Olivier,

 schrieb am Do., 16. Juli 2020,
15:38:

> Hello everyone,
>
> I’m using the 3D-Forest-Fragementation Modul developed by Vaclav and
> have produced a workflow for the calculation. It is working well and
> I’m getting plausible results. While applying this workflow for my
> whole study region (35 plots/regions) it only works for about 50 % of
> the plots. The others fail at the step where I use
> r3.count.categories. I can’t see the link respectively the difference
> for this error. That’s why am asking for a hint:
>
> I’m running Grass 7.8.2 (64 bit), Python 3.7.0, wxPython 4.0.7 on Windows
> 10
>
> The problem occurs while running this command:
>
> "r3.count.categories input=ff_mean_131_2 output=ff_mean_131_2_count
> slices=ff_mean_131_2_slice --overwrite"
>
> With this error:
>
> "[…]
> Raster map 22 Filename: ff_mean_131_2_slice_00022
> Raster map 23 Filename: ff_mean_131_2_slice_00023
> WARNING: ZSTD compression error -14: Unsupported frame parameter
> ERROR: Error uncompressing raster data


Did you copy by chance the data from a different machine?

This error comes to mind:

https://lists.osgeo.org/pipermail/grass-user/2019-March/080180.html

Best
markusN


for row 43 of
> 
> ERROR: An error occurred while running r.mapcalc with expression:
> ff_mean_131_2_count_0 = int(ff_mean_131_2_slice_1 == 0) + […]"
>
> For each failing plot the error occurs in this step. The slices seem
> to be generated correctly. I couldn’t see differences while displaying
> them or comparing the raster metadata.
> In the different plot its always another slice (2D Raster) and another
> row where the uncompressing fails. I tried to reduce the plot-size and
> found out, that the error occurs always in the same row of a plot. If
> this row is excluded, it works fine.
> That’s why I think it has nothing to do with missing space on disk, or
> not enough calculating capacity.
> Has someone an idea what’s the problem? Thanks very much!
>
> Greetings,
> Olivier
>
>
>
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] r.3.count.categories compression error -14

2020-07-16 Thread Olivier . C . Canon

Hello everyone,

I’m using the 3D-Forest-Fragementation Modul developed by Vaclav and  
have produced a workflow for the calculation. It is working well and  
I’m getting plausible results. While applying this workflow for my  
whole study region (35 plots/regions) it only works for about 50 % of  
the plots. The others fail at the step where I use  
r3.count.categories. I can’t see the link respectively the difference  
for this error. That’s why am asking for a hint:


I’m running Grass 7.8.2 (64 bit), Python 3.7.0, wxPython 4.0.7 on Windows 10

The problem occurs while running this command:

"r3.count.categories input=ff_mean_131_2 output=ff_mean_131_2_count  
slices=ff_mean_131_2_slice --overwrite"


With this error:

"[…]
Raster map 22 Filename: ff_mean_131_2_slice_00022
Raster map 23 Filename: ff_mean_131_2_slice_00023
WARNING: ZSTD compression error -14: Unsupported frame parameter
ERROR: Error uncompressing raster data for row 43 of  

ERROR: An error occurred while running r.mapcalc with expression:  
ff_mean_131_2_count_0 = int(ff_mean_131_2_slice_1 == 0) + […]"


For each failing plot the error occurs in this step. The slices seem  
to be generated correctly. I couldn’t see differences while displaying  
them or comparing the raster metadata.
In the different plot its always another slice (2D Raster) and another  
row where the uncompressing fails. I tried to reduce the plot-size and  
found out, that the error occurs always in the same row of a plot. If  
this row is excluded, it works fine.
That’s why I think it has nothing to do with missing space on disk, or  
not enough calculating capacity.

Has someone an idea what’s the problem? Thanks very much!

Greetings,
Olivier



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

Re: [GRASS-user] v.to.db in GRASS 7.8 requires 'overwrite' if column exists but flag is invalid

2020-07-16 Thread Helmut Kudrnovsky
Mira Kattwinkel wrote
> Dear list,
> 
> 
> in GRASS 7.8 v.to.db creates a new column in contrast to previous 
> versions where it column had to exist before.
> 
> According to the manual "If the /column/ exists, the *--overwrite* flag 
> is required to overwrite it". However, this flag does not exist. Hence, 
> if the column is present, it is not upated, giving:
> 
> ERROR: Column 
> 
>  exists. To overwrite, use the --overwrite flag
> 
> When useing "overwrite", it gives:
> 
> Invalid flag value: overwrite
> 
> 
> Another issue is that even if the flag would work, it would no longer be 
> compatible with previous versions that also do not know the flag but 
> need the column to exist.
> 
> 
> Can anybody please advice me what to do?


yes there was a change in the module behaviour, see

https://github.com/OSGeo/grass/issues/770

I had the same issue.

regarding using this new behaviour in scripts, see e.g.

https://github.com/OSGeo/grass-addons/commit/943d9c72a51716608f6a358a40dd114e38eaa9cf

on the command line, just add --overwrite,

e.g. v.to.db --overwrite map=soils type=centroid option=area
columns=area_size unit=h

but in the v.to.db GUI, there is no overwrite available.

please open an issue about that.



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

[GRASS-user] v.to.db in GRASS 7.8 requires 'overwrite' if column exists but flag is invalid

2020-07-16 Thread Mira Kattwinkel

Dear list,


in GRASS 7.8 v.to.db creates a new column in contrast to previous 
versions where it column had to exist before.


According to the manual "If the /column/ exists, the *--overwrite* flag 
is required to overwrite it". However, this flag does not exist. Hence, 
if the column is present, it is not upated, giving:


ERROR: Column  exists. To overwrite, use the --overwrite flag

When useing "overwrite", it gives:

Invalid flag value: overwrite


Another issue is that even if the flag would work, it would no longer be 
compatible with previous versions that also do not know the flag but 
need the column to exist.



Can anybody please advice me what to do?


Thanks,

Mira


--
Dr. Mira Kattwinkel
Quantitative Landscape Ecology
iES Landau, Institute for Environmental Sciences
University of Koblenz-Landau
Fortstraße 7
76829 Landau
Germany
Phone: + 49 6341 280-31553
Office: Building I, Room 2.02

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