Re: [GRASS-user] raster pixel value

2019-03-14 Thread Nikos Alexandris 

Markus Metz:


With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).


I wonder if `-0` flag would make sense to be GDAL-compliant.
I created a Pull Request (in `grass-ci`) for a minor update in the manual.

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

Re: [GRASS-user] raster pixel value

2019-03-14 Thread Nikos Alexandris 


Francois Chartier:


I am asking a question on the fundamentals not on a particular example on
how the value within a raster cell is determined when multiple vector data
points are located within a raster cell footprint.
I use RST mostly and sometimes IDW for vector data points.


Nikos Alexandris:


Then, from https://grass.osgeo.org/grass76/manuals/rasterintro.html:

"Raster input maps are automatically cropped/padded and rescaled (using
nearest-neighbour resampling) to match the current region."


[..]

Here a visual example using this
ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map in a GRASS GIS Location:
```
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/
r.in.gdal input=OCDENS_M_sl1_5km_ll.tif output=OCDENS_M_sl1_5km_ll
```

Select a random point and grow over it a 10^2 box
```
center_n=37.176279; center_e=22.839542 ;offset=0.25
g.region -g \
 e=$(echo $center_e + $offset |bc) \
 w=$(echo $center_e - $offset |bc) \
 s=$(echo $center_n - $offset |bc) \
 n=$(echo $center_n + $offset |bc) \
 res=0.05

projection=3
zone=0
n=37.426279
s=36.926279
w=22.589542
e=23.089542
nsres=0.05
ewres=0.05
rows=10
cols=10
cells=100
```

Clean file receiving the rendering, then draw the map’s cell values
```
d.erase
d.rast.num OCDENS_M_sl1_5km_ll@PERMANENT text_color=red grid_color=gray
```
Here https://i.imgur.com/2L9dWgX.png red are the original values.

Upscale
```
g.region -g res=0.1

projection=3
zone=0
n=37.426279
s=36.926279
w=22.589542
e=23.089542
nsres=0.1
ewres=0.1
rows=5
cols=5
cells=25
```

And over-draw the "new" map
```
d.rast.num OCDENS_M_sl1_5km_ll@PERMANENT text_color=blue grid_color=blue
```
Here https://i.imgur.com/bYgH6io.png blue are the resampled values.

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

Re: [GRASS-user] raster pixel value

2019-03-14 Thread Nikos Alexandris 

* Markus Metz  [2019-03-14 17:07:49 +0100]:


On Thu, Mar 14, 2019 at 3:16 PM Nikos Alexandris 
wrote:


Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:
```
gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433],
AUTHORITY["EPSG","4326"]]
Origin = (-180.000,87.375)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-180.000,  87.370) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.000, -61.980) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.000,  87.370) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.000, -61.980) (180d 0' 0.00"E, 61d58'48.00"S)
Center  (   0.000,  12.695) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
  NoData Value=-32768
```

and GRASS GIS
```
# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x
```

Comparing a few single pixels via:
```
while read LINE;do
set -- $LINE
echo " ($1,$2)
echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1

$2)"

echo "GRASS: $3"
echo
done < stats_x_head
```

gives
```
 (2930,77)
GDAL:  2090
GRASS: 2096

 (2931,77)
GDAL:  2055
GRASS: 2090

 (2932,77)
GDAL:  2063
GRASS: 2055

 (2933,77)
GDAL:  2093
GRASS: 2063

 (2934,77)
GDAL:  2240
GRASS: 2093

 (2935,77)
GDAL:  2332
GRASS: 2240

 (2936,77)
GDAL:  2296
GRASS: 2332

 (2937,77)
GDAL:  2253
GRASS: 2296

 (2938,77)
GDAL:  2179
GRASS: 2253

 (2939,77)
GDAL:  2115
GRASS: 2179
```

Why these differences?


With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).


Updated:
```
while read LINE ;do
   set -- ${LINE}
   echo " ($1,$2)"
   echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $(echo $1 - 1 
|bc) $(echo $2 - 1 |bc))"
   echo "GRASS: ${3}"
   echo
done < stats_x_head
```

which gives
```
(2930,77)
GDAL:  2096
GRASS: 2096

(2931,77)
GDAL:  2090
GRASS: 2090

(2932,77)
GDAL:  2055
GRASS: 2055

(2933,77)
GDAL:  2063
GRASS: 2063

(2934,77)
GDAL:  2093
GRASS: 2093

(2935,77)
GDAL:  2240
GRASS: 2240

(2936,77)
GDAL:  2332
GRASS: 2332

(2937,77)
GDAL:  2296
GRASS: 2296

(2938,77)
GDAL:  2253
GRASS: 2253

(2939,77)
GDAL:  2179
GRASS: 2179
```
Danke Markus!



Markus M


Nikos


# meta

GRASS 7.7.svn (2019)
libgis Revision: 74118
libgis Date: 2019-02-21 10:38:28 +0100 (Thu, 21 Feb 2019)

GDAL 2.3.1, released 2018/06/22
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user


--
Nikos Alexandris | Remote Sensing & Geomatics
GPG Key Fingerprint 6F9D4506F3CA28380974D31A9053534B693C4FB3 
___

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

Re: [GRASS-user] raster pixel value

2019-03-14 Thread Markus Metz 
On Thu, Mar 14, 2019 at 3:16 PM Nikos Alexandris 
wrote:
>
> Following up, why are there differences between GDAL and GRASS GIS in
> the following example?
>
> This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
> raster map, subject to `gdalinfo`:
> ```
> gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
> Driver: GTiff/GeoTIFF
> Files: OCDENS_M_sl1_5km_ll.tif
> Size is 7200, 2987
> Coordinate System is:
> GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433],
> AUTHORITY["EPSG","4326"]]
> Origin = (-180.000,87.375)
> Pixel Size = (0.050,-0.050)
> Corner Coordinates:
> Upper Left  (-180.000,  87.370) (180d 0' 0.00"W, 87d22'12.00"N)
> Lower Left  (-180.000, -61.980) (180d 0' 0.00"W, 61d58'48.00"S)
> Upper Right ( 180.000,  87.370) (180d 0' 0.00"E, 87d22'12.00"N)
> Lower Right ( 180.000, -61.980) (180d 0' 0.00"E, 61d58'48.00"S)
> Center  (   0.000,  12.695) (  0d 0' 0.00"E, 12d41'42.00"N)
> Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
>   NoData Value=-32768
> ```
>
> and GRASS GIS
> ```
> # create a new Location
> grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/
>
> # projection info
> g.proj -g
>
> name=WGS 84
> datum=wgs84
> ellps=wgs84
> proj=ll
> no_defs=defined
> epsg=4326
> unit=degree
> units=degrees
> meters=1.0
>
> # raster info
> r.info -g OCDENS_M_sl1_5km_ll
>
> north=87.37
> south=-61.98
> east=180
> west=-180
> nsres=0.05
> ewres=0.05
> rows=2987
> cols=7200
> cells=21506400
> datatype=CELL
> ncats=0
>
> # report non-NULL cells and their x, y grid location
> r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x
> ```
>
> Comparing a few single pixels via:
> ```
> while read LINE;do
> set -- $LINE
> echo " ($1,$2)
> echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1
$2)"
> echo "GRASS: $3"
> echo
> done < stats_x_head
> ```
>
> gives
> ```
>  (2930,77)
> GDAL:  2090
> GRASS: 2096
>
>  (2931,77)
> GDAL:  2055
> GRASS: 2090
>
>  (2932,77)
> GDAL:  2063
> GRASS: 2055
>
>  (2933,77)
> GDAL:  2093
> GRASS: 2063
>
>  (2934,77)
> GDAL:  2240
> GRASS: 2093
>
>  (2935,77)
> GDAL:  2332
> GRASS: 2240
>
>  (2936,77)
> GDAL:  2296
> GRASS: 2332
>
>  (2937,77)
> GDAL:  2253
> GRASS: 2296
>
>  (2938,77)
> GDAL:  2179
> GRASS: 2253
>
>  (2939,77)
> GDAL:  2115
> GRASS: 2179
> ```
>
> Why these differences?

With r.stats -x, indexing starts with 1 (first row is 1).
With gdallocationinfo, indexing starts with 0 (first row is 0).

Markus M
>
> Nikos
>
>
> # meta
>
> GRASS 7.7.svn (2019)
> libgis Revision: 74118
> libgis Date: 2019-02-21 10:38:28 +0100 (Thu, 21 Feb 2019)
>
> GDAL 2.3.1, released 2018/06/22
> ___
> 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] raster pixel value

2019-03-14 Thread Nikos Alexandris 

* Nikos Alexandris  [2019-03-14 15:11:51 +0100]:


Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:
```
gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
  DATUM["WGS_1984",
  SPHEROID["WGS 84",6378137,298.257223563,
  AUTHORITY["EPSG","7030"]],
  AUTHORITY["EPSG","6326"]],
  PRIMEM["Greenwich",0],
  UNIT["degree",0.0174532925199433],
  AUTHORITY["EPSG","4326"]]
Origin = (-180.000,87.375)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-180.000,  87.370) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.000, -61.980) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.000,  87.370) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.000, -61.980) (180d 0' 0.00"E, 61d58'48.00"S)
Center  (   0.000,  12.695) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
NoData Value=-32768
```

and GRASS GIS
```
# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/



# projection info
g.proj -g



name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0


Something I did do, but forgot to copy-paste here:
```
g.region raster=OCDENS_M_sl1_5km_ll -g

projection=3
zone=0
n=87.37
s=-61.98
w=-180
e=180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
```

Nikos


# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0


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

Re: [GRASS-user] raster pixel value

2019-03-14 Thread Nikos Alexandris 

Following up, why are there differences between GDAL and GRASS GIS in
the following example?

This ftp://ftp.soilgrids.org/data/aggregated/5km/OCDENS_M_sl1_5km_ll.tif
raster map, subject to `gdalinfo`:
```
gdalinfo OCDENS_M_sl1_5km_ll.tif -nogcp -nomd -norat -noct -nofl
Driver: GTiff/GeoTIFF
Files: OCDENS_M_sl1_5km_ll.tif
Size is 7200, 2987
Coordinate System is:
GEOGCS["WGS 84",
   DATUM["WGS_1984",
   SPHEROID["WGS 84",6378137,298.257223563,
   AUTHORITY["EPSG","7030"]],
   AUTHORITY["EPSG","6326"]],
   PRIMEM["Greenwich",0],
   UNIT["degree",0.0174532925199433],
   AUTHORITY["EPSG","4326"]]
Origin = (-180.000,87.375)
Pixel Size = (0.050,-0.050)
Corner Coordinates:
Upper Left  (-180.000,  87.370) (180d 0' 0.00"W, 87d22'12.00"N)
Lower Left  (-180.000, -61.980) (180d 0' 0.00"W, 61d58'48.00"S)
Upper Right ( 180.000,  87.370) (180d 0' 0.00"E, 87d22'12.00"N)
Lower Right ( 180.000, -61.980) (180d 0' 0.00"E, 61d58'48.00"S)
Center  (   0.000,  12.695) (  0d 0' 0.00"E, 12d41'42.00"N)
Band 1 Block=7200x1 Type=Int16, ColorInterp=Gray
 NoData Value=-32768
```

and GRASS GIS
```
# create a new Location
grass -c OCDENS_M_sl1_5km_ll.tif /geoyeux/grassdb/global/soil_grids/

# projection info
g.proj -g

name=WGS 84
datum=wgs84
ellps=wgs84
proj=ll
no_defs=defined
epsg=4326
unit=degree
units=degrees
meters=1.0

# raster info
r.info -g OCDENS_M_sl1_5km_ll

north=87.37
south=-61.98
east=180
west=-180
nsres=0.05
ewres=0.05
rows=2987
cols=7200
cells=21506400
datatype=CELL
ncats=0

# report non-NULL cells and their x, y grid location
r.stats OCDENS_M_sl1_5km_ll -n -x > stats_x
```

Comparing a few single pixels via:
```
while read LINE;do
   set -- $LINE
   echo " ($1,$2)
   echo "GDAL:  $(gdallocationinfo -valonly OCDENS_M_sl1_5km_ll.tif $1 $2)"
   echo "GRASS: $3"
   echo
done < stats_x_head
```

gives
```
(2930,77)
GDAL:  2090
GRASS: 2096

(2931,77)
GDAL:  2055
GRASS: 2090

(2932,77)
GDAL:  2063
GRASS: 2055

(2933,77)
GDAL:  2093
GRASS: 2063

(2934,77)
GDAL:  2240
GRASS: 2093

(2935,77)
GDAL:  2332
GRASS: 2240

(2936,77)
GDAL:  2296
GRASS: 2332

(2937,77)
GDAL:  2253
GRASS: 2296

(2938,77)
GDAL:  2179
GRASS: 2253

(2939,77)
GDAL:  2115
GRASS: 2179
```

Why these differences?

Nikos


# meta

GRASS 7.7.svn (2019)
libgis Revision: 74118
libgis Date: 2019-02-21 10:38:28 +0100 (Thu, 21 Feb 2019)

GDAL 2.3.1, released 2018/06/22
___
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Error while executing: 'CREATE TEMPORARY TABLE...

2019-03-14 Thread Markus Metz 
On Thu, Mar 14, 2019 at 3:44 AM Jamille Haarloo 
wrote:
>
> Just tested:
>
> (Wed Mar 13 23:42:59 2019)

> v.db.dropcolumn map=nvTrainingset_new2019@LUP1
columns=Uitleg2,SegUitleg,x22kcluster,x12kcluster,x17kcluster,x8kcluster,xkcluster
> ERROR: Error while executing: 'CREATE TEMPORARY TABLE
nvTrainingset_new2019_backup(cat INTEGER, compact_circle DOUBLE PRECISION,
DV2_mean DOUBLE PRECISION, DV2_stddev DOUBLE PRECISION, DV2_variance DOUBLE
PRECISION, DV2_coeff_var DOUBLE PRECISION, DV2_first_quart DOUBLE
PRECISION, DV2_median DOUBLE PRECISION, DV2_third_quart DOUBLE PRECISION,
DV2_perc_90 DOUBLE PRECISION, DV4_mean DOUBLE PRECISION, DV4_stddev DOUBLE
PRECISION, DV4_variance DOUBLE PRECISION, DV4_coeff_var DOUBLE PRECISION,
DV4_first_quart DOUBLE PRECISION, DV4_median DOUBLE PRECISION,
DV4_third_quart DOUBLE PRECISION, DV4_perc_90 DOUBLE PRECISION, IDM2_mean
DOUBLE PRECISION, IDM2_stddev DOUBLE PRECISION, IDM2_variance DOUBLE
PRECISION, IDM2_coeff_var DOUBLE PRECISION, IDM2_first_quart DOUBLE
PRECISION, IDM2_median DOUBLE PRECISION, IDM2_third_quart DOUBLE PRECISION,
IDM2_perc_90 DOUBLE PRECISION, IDM4_mean DOUBLE PRECISION, IDM4_stddev
DOUBLE PRECISION, IDM4_variance DOUBLE PRECISION, IDM4_coeff_var DOUBLE
PRECISION, IDM4_first_quart DOUBLE PRECISION, IDM4_median DOUBLE PRECISION,
IDM4_third_quart DOUBLE PRECISION, IDM4_perc_90 DOUBLE PRECISION, W2_mean
DOUBLE PRECISION, W2_stddev DOUBLE PRECISION, W2_variance DOUBLE PRECISION,
W2_coeff_var DOUBLE PRECISION, W2_first_quart DOUBLE PRECISION, W2_median
DOUBLE PRECISION, W2_third_quart DOUBLE PRECISION, W2_perc_90 DOUBLE
PRECISION, W4_mean DOUBLE PRECISION, W4_stddev DOUBLE PRECISION,
W4_variance DOUBLE PRECISION, W4_coeff_var DOUBLE PRECISION, W4_first_quart
DOUBLE PRECISION, W4_median DOUBLE PRECISION, W4_third_quart DOUBLE
PRECISION, W4_perc_90 DOUBLE PRECISION, neighbors_count DOUBLE PRECISION,
compact_circle_nbrmean DOUBLE PRECISION, compact_circle_nbrstddev DOUBLE
PRECISION, DV2_mean_nbrmean DOUBLE PRECISION, DV2_mean_nbrstddev DOUBLE
PRECISION, DV2_stddev_nbrmean DOUBLE PRECISION, DV2_stddev_nbrstddev DOUBLE
PRECISION, DV2_variance_nbrmean DOUBLE PRECISION, DV2_variance_nbrstddev
DOUBLE PRECISION, DV2_coeff_var_nbrmean DOUBLE PRECISION,
DV2_coeff_var_nbrstddev DOUBLE PRECISION, DV2_first_quart_nbrmean DOUBLE
PRECISION, DV2_first_quart_nbrstddev DOUBLE PRECISION, DV2_median_nbrmean
DOUBLE PRECISION, DV2_median_nbrstddev DOUBLE PRECISION,
DV2_third_quart_nbrmean DOUBLE PRECISION, DV2_third_quart_nbrstddev DOUBLE
PRECISION, DV2_perc_90_nbrmean DOUBLE PRECISION, DV2_perc_90_nbrstddev
DOUBLE PRECISION, DV4_mean_nbrmean DOUBLE PRECISION, DV4_mean_nbrstddev
DOUBLE PRECISION, DV4_stddev_nbrmean DOUBLE PRECISION, DV4_stddev_nbrstddev
DOUBLE PRECISION, DV4_variance_nbrmean DOUBLE PRECISION,
DV4_variance_nbrstddev DOUBLE PRECISION, DV4_coeff_var_nbrmean DOUBLE
PRECISION, DV4_coeff_var_nbrstddev DOUBLE PRECISION,
DV4_first_quart_nbrmean DOUBLE PRECISION, DV4_first_quart_nbrstddev DOUBLE
PRECISION, DV4_median_nbrmean DOUBLE PRECISION, DV4_median_nbrstddev DOUBLE
PRECISION, DV4_third_quart_nbrmean DOUBLE PRECISION,
DV4_third_quart_nbrstddev DOUBLE PRECISION, DV4_perc_90_nbrmean DOUBLE
PRECISION, DV4_perc_90_nbrstddev DOUBLE PRECISION, IDM2_mean_nbrmean DOUBLE
PRECISION, IDM2_mean_nbrstddev DOUBLE PRECISION, IDM2_stddev_nbrmean DOUBLE
PRECISION, IDM2_stddev_nbrstddev DOUBLE PRECISION, IDM2_variance_nbrmean
DOUBLE PRECISION, IDM2_variance_nbrstddev DOUBLE PRECISION,
IDM2_coeff_var_nbrmean DOUBLE PRECISION, IDM2_coeff_var_nbrstddev DOUBLE
PRECISION, IDM2_first_quart_nbrmean DOUBLE PRECISION,
IDM2_first_quart_nbrstddev DOUBLE PRECISION, IDM2_median_nbrmean DOUBLE
PRECISION, IDM2_median_nbrstddev DOUBLE PRECISION, IDM2_third_quart_nbrmean
DOUBLE PRECISION, IDM2_third_quart_nbrstddev DOUBLE PRECISION,
IDM2_perc_90_nbrmean DOUBLE PRECISION, IDM2_perc_90_nbrstddev DOUBLE
PRECISION, IDM4_mean_nbrmean DOUBLE PRECISION, IDM4_mean_nbrstddev DOUBLE
PRECISION, IDM4_stddev_nbrmean DOUBLE PRECISION, IDM4_stddev_nbrstddev
DOUBLE PRECISION, IDM4_variance_nbrmean DOUBLE PRECISION,
IDM4_variance_nbrstddev DOUBLE PRECISION, IDM4_coeff_var_nbrmean DOUBLE
PRECISION, IDM4_coeff_var_nbrstddev DOUBLE PRECISION,
IDM4_first_quart_nbrmean DOUBLE PRECISION, IDM4_first_quart_nbrstddev
DOUBLE PRECISION, IDM4_median_nbrmean
> DOUBLE PRECISION, IDM4_median_nbrstddev DOUBLE PRECIS'
> ERROR: Deleting column failed

The sql command is still truncated to 4096 characters. Are you sure you are
using latest GRASS 7.6 or 7.7 from svn? For me it works in trunk with more
than 4096 characters.

Markus M

>
> On Fri, Mar 8, 2019 at 4:25 PM Markus Metz 
wrote:
>>
>>
>>
>> On Thu, Mar 7, 2019 at 6:35 PM Markus Neteler  wrote:
>> >
>> > Hi,
>> >
>> > On Sat, Feb 16, 2019 at 12:28 AM Jamille Haarloo 
wrote:
>> > >
>> > > Dear Grass community,
>> > >
>> > > I don't have any success with removal of columns from a vector file
I am working with, while adding columns has not been a problem.
>> > >
>> > > output:
>> > >

Re: [GRASS-user] Error while executing: 'CREATE TEMPORARY TABLE...

2019-03-14 Thread st_kiefer 
Hi Jamille,

just for couriosity. How many columns holds the vectorset?

In fact from a database perspective I would rather choose to keep only 
geometry-related data or metadata direct with the vectorset. Concerning the 
column names I would suspect there rather should be a bunch of attribute tables 
to join to the vectorset. From a database perspective one usualy tries to 
normalize the database structure, i.e. break down tables to avoid redundancies.

For example names like DV2_median, DV4_median, IDM2_median, IDM4_median seem to 
me as you could create 4 separate tables each with a column "median" (and other 
columns like "first_quart" an so on). Then you join the tables by a key-column 
(most probably "cat").

In that case you avoid probable redundancies and keep tables small which 
results in avoiding DB-driver issues because of to small 
query-(/command-)buffer, respective datatype restrictions (of the buffer). 
Which seems the cause of your actual troubles.

If that could be a feasible approach in your case it might avoid what you 
described.

Best regards.

Stefan

> Jamille Haarloo  hat am 14. März 2019 um 03:44 
> geschrieben:
> 
> Just tested:
> 
> (Wed Mar 13 23:42:59 2019)
>   
> v.db.dropcolumn map=nvTrainingset_new2019@LUP1 
> columns=Uitleg2,SegUitleg,x22kcluster,x12kcluster,x17kcluster,x8kcluster,xkcluster
> ERROR: Error while executing: 'CREATE TEMPORARY TABLE 
> nvTrainingset_new2019_backup(cat INTEGER, compact_circle DOUBLE PRECISION, 
> DV2_mean DOUBLE PRECISION, DV2_stddev DOUBLE PRECISION, DV2_variance DOUBLE 
> PRECISION, DV2_coeff_var DOUBLE PRECISION, DV2_first_quart DOUBLE PRECISION, 
> DV2_median DOUBLE PRECISION, DV2_third_quart DOUBLE PRECISION, DV2_perc_90 
> DOUBLE PRECISION, DV4_mean DOUBLE PRECISION, DV4_stddev DOUBLE PRECISION, 
> DV4_variance DOUBLE PRECISION, DV4_coeff_var DOUBLE PRECISION, 
> DV4_first_quart DOUBLE PRECISION, DV4_median DOUBLE PRECISION, 
> DV4_third_quart DOUBLE PRECISION, DV4_perc_90 DOUBLE PRECISION, IDM2_mean 
> DOUBLE PRECISION, IDM2_stddev DOUBLE PRECISION, IDM2_variance DOUBLE 
> PRECISION, IDM2_coeff_var DOUBLE PRECISION, IDM2_first_quart DOUBLE 
> PRECISION, IDM2_median DOUBLE PRECISION, IDM2_third_quart DOUBLE PRECISION, 
> IDM2_perc_90 DOUBLE PRECISION, IDM4_mean DOUBLE PRECISION, IDM4_stddev DOUBLE 
> PRECISION, IDM4_variance DOUBLE PRECISION, IDM4_coeff_var DOUBLE PRECISION, 
> IDM4_first_quart DOUBLE PRECISION, IDM4_median DOUBLE PRECISION, 
> IDM4_third_quart DOUBLE PRECISION, IDM4_perc_90 DOUBLE PRECISION, W2_mean 
> DOUBLE PRECISION, W2_stddev DOUBLE PRECISION, W2_variance DOUBLE PRECISION, 
> W2_coeff_var DOUBLE PRECISION, W2_first_quart DOUBLE PRECISION, W2_median 
> DOUBLE PRECISION, W2_third_quart DOUBLE PRECISION, W2_perc_90 DOUBLE 
> PRECISION, W4_mean DOUBLE PRECISION, W4_stddev DOUBLE PRECISION, W4_variance 
> DOUBLE PRECISION, W4_coeff_var DOUBLE PRECISION, W4_first_quart DOUBLE 
> PRECISION, W4_median DOUBLE PRECISION, W4_third_quart DOUBLE PRECISION, 
> W4_perc_90 DOUBLE PRECISION, neighbors_count DOUBLE PRECISION, 
> compact_circle_nbrmean DOUBLE PRECISION, compact_circle_nbrstddev DOUBLE 
> PRECISION, DV2_mean_nbrmean DOUBLE PRECISION, DV2_mean_nbrstddev DOUBLE 
> PRECISION, DV2_stddev_nbrmean DOUBLE PRECISION, DV2_stddev_nbrstddev DOUBLE 
> PRECISION, DV2_variance_nbrmean DOUBLE PRECISION, DV2_variance_nbrstddev 
> DOUBLE PRECISION, DV2_coeff_var_nbrmean DOUBLE PRECISION, 
> DV2_coeff_var_nbrstddev DOUBLE PRECISION, DV2_first_quart_nbrmean DOUBLE 
> PRECISION, DV2_first_quart_nbrstddev DOUBLE PRECISION, DV2_median_nbrmean 
> DOUBLE PRECISION, DV2_median_nbrstddev DOUBLE PRECISION, 
> DV2_third_quart_nbrmean DOUBLE PRECISION, DV2_third_quart_nbrstddev DOUBLE 
> PRECISION, DV2_perc_90_nbrmean DOUBLE PRECISION, DV2_perc_90_nbrstddev DOUBLE 
> PRECISION, DV4_mean_nbrmean DOUBLE PRECISION, DV4_mean_nbrstddev DOUBLE 
> PRECISION, DV4_stddev_nbrmean DOUBLE PRECISION, DV4_stddev_nbrstddev DOUBLE 
> PRECISION, DV4_variance_nbrmean DOUBLE PRECISION, DV4_variance_nbrstddev 
> DOUBLE PRECISION, DV4_coeff_var_nbrmean DOUBLE PRECISION, 
> DV4_coeff_var_nbrstddev DOUBLE PRECISION, DV4_first_quart_nbrmean DOUBLE 
> PRECISION, DV4_first_quart_nbrstddev DOUBLE PRECISION, DV4_median_nbrmean 
> DOUBLE PRECISION, DV4_median_nbrstddev DOUBLE PRECISION, 
> DV4_third_quart_nbrmean DOUBLE PRECISION, DV4_third_quart_nbrstddev DOUBLE 
> PRECISION, DV4_perc_90_nbrmean DOUBLE PRECISION, DV4_perc_90_nbrstddev DOUBLE 
> PRECISION, IDM2_mean_nbrmean DOUBLE PRECISION, IDM2_mean_nbrstddev DOUBLE 
> PRECISION, IDM2_stddev_nbrmean DOUBLE PRECISION, IDM2_stddev_nbrstddev DOUBLE 
> PRECISION, IDM2_variance_nbrmean DOUBLE PRECISION, IDM2_variance_nbrstddev 
> DOUBLE PRECISION, IDM2_coeff_var_nbrmean DOUBLE PRECISION, 
> IDM2_coeff_var_nbrstddev DOUBLE PRECISION, IDM2_first_quart_nbrmean DOUBLE 
> PRECISION, IDM2_first_quart_nbrstddev DOUBLE PRECISION, IDM2_median_nbrmean 
> DOUBLE PRECISION,