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

[Jamille Haarloo]

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:
v.db.dropcolumn map=nvTrainingset_test2019_clean@LUP1 columns=code

ERROR: Error while executing: 'CREATE TEMPORARY TABLE
nvTrainingset_test2019_clean_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_n
brmean DOUBLE PRECISION, IDM4_median_nbrstddev DOUBLE'
ERROR: Deleting column failed

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

Re: [GRASS-user] Report on r.mapcalc issue

[Veronica Andreo]

Hi

I don't have 7.4.4 here, but I get expected results both from command line
and GUI in grass 7.6 (new stable release) and development version...
No idea, what might have gone wrong at your end.

I tested like this:
r.mapcalc "test = 164 / 10.0"
r.info test

cheers,
vero



El vie., 15 feb. 2019 a las 17:28, Pilafin ()
escribió:

> Hi everyone,
> I'm using Grass 7.4.4 on Windows 7 to perform a simple operation (division
> by 10.0) of a raster map using r.mapcalc gui and I noticed that the
> obtained
> results are not correct, e.g. 164 / 10.0 = 15 instead of 16.4.
> I tried to do the same operation with Grass 6.4 and it went fine.
> Then I switched to Grass 7.4.4 again and I tried to use the command line,
> and it gives the correct results.
>
> I think there is a problem in the r.mapcalc gui, has someone else
> encountered this strange behavior?
>
>
> P.S.: In the following lines, the results of a query on a point:
>
> est, nord: 2.85667275343, 42.3684893758
> DTM@DTM:
>   color: 072:022:104
>   value: 164
> DTM_grass7@DTM:
>   color: 072:020:103
>   value: 15
> DTM_grass6@DTM:
>   color: 072:022:104
>   value: 16.4
> DTM_grass7_cmd@DTM:
>   color: 072:022:104
>   value: 16.4
>
>
>
> --
> 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 mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

Re: [GRASS-user] Report on r.mapcalc issue

[Andrea Balotti]

Hi,
I tested using 7.4.4 on Win10 and worked as expected using the gui. I 
tested:

r.mapcalc expression="new_map = integer_map / 10.0"
r.info map=new_map

returns: "Data Type:    DCELL " and query on one point gives the 
expected value.


If is not a problem of setting properly g.region before r.mapcalc, I 
have no idea of what can cause your wrong result.

cheers,

Andrea Balotti

Il 15/02/2019 17:28, Pilafin ha scritto:

Hi everyone,
I'm using Grass 7.4.4 on Windows 7 to perform a simple operation (division
by 10.0) of a raster map using r.mapcalc gui and I noticed that the obtained
results are not correct, e.g. 164 / 10.0 = 15 instead of 16.4.
I tried to do the same operation with Grass 6.4 and it went fine.
Then I switched to Grass 7.4.4 again and I tried to use the command line,
and it gives the correct results.

I think there is a problem in the r.mapcalc gui, has someone else
encountered this strange behavior?


P.S.: In the following lines, the results of a query on a point:

est, nord: 2.85667275343, 42.3684893758
DTM@DTM:
   color: 072:022:104
   value: 164
DTM_grass7@DTM:
   color: 072:020:103
   value: 15
DTM_grass6@DTM:
   color: 072:022:104
   value: 16.4
DTM_grass7_cmd@DTM:
   color: 072:022:104
   value: 16.4



--
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 mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user

[GRASS-user] Report on r.mapcalc issue

[Pilafin]

Hi everyone,
I'm using Grass 7.4.4 on Windows 7 to perform a simple operation (division
by 10.0) of a raster map using r.mapcalc gui and I noticed that the obtained
results are not correct, e.g. 164 / 10.0 = 15 instead of 16.4.
I tried to do the same operation with Grass 6.4 and it went fine.
Then I switched to Grass 7.4.4 again and I tried to use the command line,
and it gives the correct results.

I think there is a problem in the r.mapcalc gui, has someone else
encountered this strange behavior?


P.S.: In the following lines, the results of a query on a point:

est, nord: 2.85667275343, 42.3684893758
DTM@DTM:
  color: 072:022:104
  value: 164
DTM_grass7@DTM:
  color: 072:020:103
  value: 15
DTM_grass6@DTM:
  color: 072:022:104
  value: 16.4
DTM_grass7_cmd@DTM:
  color: 072:022:104
  value: 16.4 



--
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

Re: [GRASS-user] get the shifted minimum from a raster series

[Micha Silver]

  
  
Hello Frank:


On 2/7/19 3:16 PM, Frank David wrote:


  
  I forgot one thing to well understand my wish. Each viewshed
raster is a r.series (250-sum) of 250 r.viewshed with 2m target
and 0 upto 250m terrain height. So each raster gives the hidden
height of a building (250m max) anywhere on the region from a
specific point of view. The purpose is to get the area of hidden
wind turbine from roads for a specific wind turbine height.
  Cheers,
  Frank



A friend and I were working on an idea some months ago that might
  be of interest. Not the same as your project but the method I used
  is similar.


The search and rescue teams here are interested to see what areas
  were actually visible after they finish searching along a certain
  route, and what areas were not seen at all. I used the same
  approach as you, creating a series of overlapping r.viewshed
  intermediate rasters. 


After seeing your post, I have added new input parameters for
  minimum and maximum values of overlap. The user can enter percents
  of minimum or maximum viewshed overlaps. Suppose I put in 20 as
  the minimum, then only those pixels with at least 20% of the total
  number of viewsheds will be shown. Similarly, if I enter 80 as the
  maximum, then only those pixels with less than 80% of the maximum
  number of viewsheds will appear in the final raster. 



If you are on Gitlab, you can clone the files: No documentation
  yet :-(
https://gitlab.com/tsvibar/route_viewshed


If you do adopt any of this script, I'd appreciate to hear of any
  bugs or suggestions for improvement. If the script raises any
  interest, I'll add it to the Addons.


Regards,
Micha




   
  Le 07/02/2019 à 12:48, Frank David a
écrit :
  
  

Hi,
Thanks for your reply. I can have numerous raster (several
  hundreds). I want to find a minimum but with a tolerance, it's
  why I want to be able to shift the value. In fact I want to
  sort the value of my all input raster for each x,y cell and
  get the second or third, or any position in the sorted list,
  to build my output raster. My application is to get the area
  not visible from a road (I did 1600 viewshed raster from the
  roads every 250m). I want a tolerance in order that one point
  of view (top of hill) does not reduce too much the hidden
  area. To do so, a fixed number of my point of view (20%) does
  not reduce the hidden area. The result is the area is hidden
  from 80% of the road.

I already wrote a python script that read all rasters for
  each x,y cell and make a array(), sort the array values, and
  build a raster. It works on reasonable number of cell, but
  seems to fails with large number of cells. I'm not a
  programmer !

I wondered if this kind of treatment exists already in Grass.
  

If somebody wants to hemps me to develop this, I could be
  nice. But I think it could be an improvement of r.series
  function.
Sorry for my bad english, I hope you have understand my
  wishes !

Cheers
Frank

Le 07/02/2019 à 12:04, Veronica
  Andreo a écrit :


  
  Hi Ken,


There isn't any build-in function for that
  in grass, afaik. Depending on how long is your series, you
  could shift the map list you use in each run and then use
  r.univar on each output from r.series to get the minimum
  and by comparison, get the second minimum of the series of
  maps (a scalar). 


However, if what you need is a map of second
  minimums per pixel, I believe that might require some
  programming for a new function... Do you know any other
  software which has this function? Maybe, if there's such
  thing in Python for example, it could be recycled or used
  with grass maps in a script... Dunno, just thinking out
  loud


best,
Vero
  
  
  
El jue., 7 feb. 2019 07:16, Ken Mankoff 
  escribió:

Hi
  Frank,
  
  On 2019-02-07 at 08:27 +0100, Frank David 
  wrote...
  > I try to find how to get the shifted minimum value of
  a series of
  > raster map. I want to shift by one, or more, the
   

Re: [GRASS-user] Uploading NumPy array as a new column to a vector map

[Markus Neteler]

Hi,

Am Do., 14. Feb. 2019, 15:50 hat César Augusto Ramírez Franco <
caesar...@gmail.com> geschrieben:

> Greetings,
>
> I have a municipality polygon layer with a poverty index (percent) and a
> population count, I'm multiplying them to visualize the vulnerability for
> each municipality, due to the distribution of that new variable I want to
> compute the logarithm, which is not possible in sqlite,
>

Yes but there is an extension for this.

See
https://grasswiki.osgeo.org/wiki/Build_SQLite_extension_on_Linux

It may solve the issue.

Best
Markus



so I tried reading the column with numpy and issuing a np.log10(). I'm
> happy with the result, but how can I get this new numpy array to a new
> column in the vector map in a simple way?
>
> This is what I already have:
>
> #!/usr/bin/env python
>
> import grass.script as gs
> import numpy as np
> import matplotlib.pyplot as plt
>
> nbi_pob = np.array(gs.vector_db_select("muniant", columns =
> "nbi_pob")["values"].values()).astype(float).squeeze()
>
> plt.hist(nbi_pob)
> plt.show()
>
> log_nbi_pob = np.log10(nbi_pob)
>
> plt.hist(log_nbi_pob)
> plt.show()
>
> I'm trying to introduce this kind of analysis to students who are not
> familiar nor proficient with programming (this is an GIS introductory
> course) so the numpy bit is already complex enough to them, and I'd like to
> avoid using for loops with cursors to achieve this.
>
> Is there a simple solution to this?
>
> --
> *César Augusto Ramírez Franco*
> ___
> 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] Uploading NumPy array as a new column to a vector map

[Micha Silver]

  
  

On 2/14/19 4:49 PM, César Augusto
  Ramírez Franco wrote:


  
  

  Greetings,

I have a municipality polygon layer with a poverty index
(percent) and a population count, I'm multiplying them to
visualize the vulnerability for each municipality, due to
the distribution of that new variable I want to compute the
logarithm, which is not possible in sqlite, so I tried
reading the column with numpy and issuing a np.log10(). I'm
happy with the result, but how can I get this new numpy
array to a new column in the vector map in a simple way?

This is what I already have:

#!/usr/bin/env
  python
  
  import grass.script as gs
  import numpy as np
  import matplotlib.pyplot as plt
  
  nbi_pob = np.array(gs.vector_db_select("muniant", columns
  = "nbi_pob")["values"].values()).astype(float).squeeze()
  
  plt.hist(nbi_pob)
  plt.show()
  
  log_nbi_pob = np.log10(nbi_pob)
  
  plt.hist(log_nbi_pob)
  plt.show()

I'm trying to introduce this kind of analysis to students
who are not familiar nor proficient with programming (this
is an GIS introductory course) so the numpy bit is already
complex enough to them, and I'd like to avoid using for
loops with cursors to achieve this.
  

  



I also can't think of any simple way to do this. However
  PostgreSQL does have a log() function. So if you migrate your
  backend DB to PostgreSQL you should be able to do (not tested):


gs.run_command('v.db.addcolumn', map_="muniant",
  column="log_nbi_pob DOUBLE")
gs.run_command('v.to.db', map_="muniant", column="log_nbi_pob",
  query="log(nbi_pob)")


But I must say that it seems strange that you are introducing
  numpy, matplotlib and the GRASS python interface to students who
  don't yet have the basic tools of programming, such as 'for'
  loops. Isn't this is a case of "putting the wagon in front of the
  horse"?? :-)






  

  
Is there a simple solution to this?
  
  
  -- 
  

  

  

  

  César Augusto Ramírez Franco

  

  

  

  

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

-- 
Micha Silver
Ben Gurion Univ.
Sde Boker, Remote Sensing Lab
cell: +972-523-665918
  

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