Re: [GRASS-user] d.mon vs g.gui

[Veronica Andreo]

Hi Tyler,

Yes, if you use d.mon plus d.vect or d.rast commands it takes a while to
load each map, you should do it one by one... indeed, d.mon interface is
not so cool for scripting visualizations, unless you use is as in
https://grass.osgeo.org/grass76/manuals/cairodriver.html. See also here:
https://gitpitch.com/veroandreo/grass-gis-conae/master?p=slides/05_temporal&grs=gitlab#/14/3.
Still if maps are heavy to load, I'm not sure how it will work. Others will
know better.

Another option for high quality cartography is ps.map or g.gui.psmap. You
can check the manual pages and grass wiki for examples. It is scriptable
and it provides nice features for creating maps. You spend time the first
time setting everything where you want it to be, but then just replace map
names and done (well, at least for rasters, that works nicely :)).

You cannot control de main Map Display from the GUI with d.vect and d.rast
from the terminal. It does work to run them from the Console tab in the
Layer Manager window, though.

HTH,
Vero

El vie., 10 may. 2019 a las 23:48, Tyler Smith ()
escribió:

> Hi,
>
> I'm an occasional GRASS user, currently working with GRASS 7.6 on Debian.
> Since I often go months between GRASS sessions, I like to work in text mode
> with scripts.  My scripts are useful 'cheatsheets' to figure out how to
> reproduce my work.
>
> However, I've noticed that the display that's available via `d.mon
> start=wx0` doesn't work as well as the visually identical display I can get
> with `g.gui`. For example, plotting large vector maps on `wx0` I often find
> I can't get multiple maps to display at once, or if I zoom or pan the
> display stops refreshing and I'm stuck with a blank screen. These problems
> don't occur with the g.gui system.
>
> Having just tediously transferred several complex `d.vect` commands from
> my script to the gui "add a vector map", I was hoping there was a way I
> could continue to enter my scripts at the terminal prompt, and have the
> display commands directed to the g.gui map window. If I open `g.gui` and
> try that, I get the following error:
>
> ERROR: Neither MONITOR (managed by d.mon command) nor
>GRASS_RENDER_IMMEDIATE (used for direct rendering) defined
>
> Is there anyway to combine the convenience of scripting at the terminal
> with the reliability of the g.gui display windows?
>
> Thanks,
>
> Tyler
>
> --
> plantarum.ca
> ___
> 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] turning sqlite journal off

[Nikos Alexandris]

* Markus Metz  [2019-05-15 22:55:13 +0200]:


On Tue, May 14, 2019 at 11:12 AM Panagiotis Mavrogiorgos 
wrote:


Hi Laura,

This thread seems to be related:

http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html

I also had a somewhat similar problem that was related to the VACUUM

command issued when closing a GRASS session (new session started before the
VACUUM of the previous session was finished)

If I understand this correctly, you are not supposed to concurrently use

the same sqlite database.

Yes, this is a limitation of sqlite, and the GRASS-internal sqlite driver
has been adapted accordingly as much as possible.


Nevertheless, concurrent reading is allowed.  Reading the discussion so
far, one may think that no concurrent use is possible at all.

See also https://sqlite.org/whentouse.html :

 "SQLite supports an unlimited number of simultaneous readers, but it
 will only allow one writer at any instant in time."

And in https://sqlite.org/lockingv3.html see 'SHARED'.
Also, https://stackoverflow.com/a/4060838/1172302.

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

Re: [GRASS-user] turning sqlite journal off

[Markus Metz]

On Tue, May 14, 2019 at 11:12 AM Panagiotis Mavrogiorgos 
wrote:
>
> Hi Laura,
>
> This thread seems to be related:
http://osgeo-org.1560.x6.nabble.com/SQLITE-db-locking-problem-td5182180.html
> I also had a somewhat similar problem that was related to the VACUUM
command issued when closing a GRASS session (new session started before the
VACUUM of the previous session was finished)
> If I understand this correctly, you are not supposed to concurrently use
the same sqlite database.

Yes, this is a limitation of sqlite, and the GRASS-internal sqlite driver
has been adapted accordingly as much as possible.

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

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Micha Silver]

  
  

On 15/05/2019 0:46, Veronica Andreo
  wrote:


  
  

  Hi all,
  
  
  I was working today with a very simple vector map which
corresponds to clusters (circular polygons) that overlap and
it is just fine that they overlap. So, i received a
shapefile with 3 of these clusters. Two of them overlaped.
When I import them into GRASS with v.import I get an extra
centroid and area where 2 of the polygons overlap. 
  
  
  
  Problem arises when I want to query a raster map with
those polygons since originally the attribute table
contained only 3 polygons (which is just fine). However,
v.what.rast will only upload values for 2 of those three
polygons because it finds 2 centroids with the same
category, AFAIU.
  
  

  



Here's how to get the raster values for all polygons (including
  those which are overlaps). It involves the somewhat non-intuitive
  process of creating another layer. I imported a simple polygon
  shapefile with three overlapping areas. Here are the categories:


micha@TP480:~$ v.category polys opt=report
  Layer/table: 1/polys
  type   count    min    max
  point  0  0  0
  line   0  0  0
  boundary   0  0  0
  centroid  12  1  3
  area   0  0  0
  face   0  0  0
  kernel 0  0  0
  all   12  1  3
  Layer: 2
  type   count    min    max
  point  0  0  0
  line   0  0  0
  boundary   0  0  0
  centroid   4  2  3
  area   0  0  0
  face   0  0  0
  kernel 0  0  0
  all    4  2  3


So, as you found, you get two layers, with all original areas
  split up at overlaps in layer 1, and just the overlap areas in
  layer 2.  Now add a third layer, with new category values
  (option=add):


micha@TP480:~$ v.category polys option=add layer=3
out=polys_3layers
Layer/table: 1/polys_3layers
  type   count    min    max
  point  0  0  0
  line   0  0  0
  boundary   0  0  0
  centroid  12  1  3
  area   0  0  0
  face   0  0  0
  kernel 0  0  0
  all   12  1  3
  Layer: 2
  type   count    min    max
  point  0  0  0
  line   0  0  0
  boundary   0  0  0
  centroid   4  2  3
  area   0  0  0
  face   0  0  0
  kernel 0  0  0
  all    4  2  3
  Layer: 3
  type   count    min    max
  point  0  0  0
  line   0  0  0
  boundary   0  0  0
  centroid   7  1  7
  area   0  0  0
  face   0  0  0
  kernel 0  0  0
  all    7  1  7


This gives me three layers, and the new layer 3 has individual
  cat values for each polygon. So I'm ready to add a database table
  and column to that layer for the raster value, and then run
  v.what.rast:

micha@TP480:~$ v.db.addtable polys_3layers layer=3
columns="rast_value DOUBLE"
micha@TP480:~$ v.what.rast polys_3layers rast=dem_4m
column=rast_value layer=3 type=centroid
  Reading features from vector map...
  Update vector attributes...
   100%
  v.what.rast complete. 7 records updated.
  micha@TP480:~$ v.db.select polys_3layers layer=3
  cat|rast_value
  1|488.3321
  2|492.7044
  3|481.2958
  4|498.173
  5|501.3336
  6|493.2202
  7|471.7223
  

Does this help?






  

  I tried with 

  

  v.clean input=clusters
  output=clusters_clean1 tool=break,rmdupl,rmsa,rmdac

  

  and 

  
  
  v.clean input=clusters
type=centroid output=clusters_clean2 tool=rmdupl
  
  
   

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Moritz Lennert]

On 14/05/19 23:46, Veronica Andreo wrote:

Hi all,

I was working today with a very simple vector map which corresponds to 
clusters (circular polygons) that overlap and it is just fine that they 
overlap. So, i received a shapefile with 3 of these clusters. Two of 
them overlaped. When I import them into GRASS with v.import I get an 
extra centroid and area where 2 of the polygons overlap.


Problem arises when I want to query a raster map with those polygons 
since originally the attribute table contained only 3 polygons (which is 
just fine). However, v.what.rast will only upload values for 2 of those 
three polygons because it finds 2 centroids with the same category, AFAIU.


I tried with

v.clean input=clusters output=clusters_clean1 tool=break,rmdupl,rmsa,rmdac

and

v.clean input=clusters type=centroid output=clusters_clean2 tool=rmdupl



If your overlap polygons are smaller than the cluser polygons, you could 
use v.clean rmarea with a relevant threshold.


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

Re: [GRASS-user] importing and cleaning overlapping polygons that are supposed to overlap

[Margherita Di Leo]

Ciao Vero,

shapefile is not a good choice in this case for exporting such geometry
because is not apt to store topological information. You may want to export
your dataset in a different format, e.g. geopackage.

Hope this helps,

On Tue, May 14, 2019 at 11:47 PM Veronica Andreo 
wrote:

> Hi all,
>
> I was working today with a very simple vector map which corresponds to
> clusters (circular polygons) that overlap and it is just fine that they
> overlap. So, i received a shapefile with 3 of these clusters. Two of them
> overlaped. When I import them into GRASS with v.import I get an extra
> centroid and area where 2 of the polygons overlap.
>
> Problem arises when I want to query a raster map with those polygons since
> originally the attribute table contained only 3 polygons (which is just
> fine). However, v.what.rast will only upload values for 2 of those three
> polygons because it finds 2 centroids with the same category, AFAIU.
>
> I tried with
>
> v.clean input=clusters output=clusters_clean1 tool=break,rmdupl,rmsa,rmdac
>
> and
>
> v.clean input=clusters type=centroid output=clusters_clean2 tool=rmdupl
>
> but nothing seemed to do the kind of cleaning I wanted. I ended up using
> brute force and removing the extra centroid manually in the GUI. That
> helped with v.what.rast (all cats in the attr table were updated) but part
> of the original and correct geometry was clearly gone. I am sure that's not
> the right combination nor the right way either.
>
> In the wiki [0], I only found this piece of text: "If the *input polygons
> have logical errors* You can investigate overlapping areas in the
> imported vector with 'd.vect
>  yourmap type=area
> layer=2' (only overlapping areas have a category in layer 2 after import).
> Additionally you may show the centroids of layer=2 to easier find tiny
> overlapping areas with 'd.vect
>  yourmap
> type=centroid layer=2'"
>
> However, it says nothing about how to proceed further as to keep correctly
> overlapping polygons, each with its own centroid and remove the duplicated
> ones that are generated when importing.
>
> Can someone please share the set of steps that should be followed in these
> cases? Maybe it's a silly question, but I'm more a raster person so I am
> very easily lost with vector issues.
>
> Thanks much in advance!
> Vero
>
> [0] https://grasswiki.osgeo.org/wiki/Vector_topology_cleaning
> ___
> grass-user mailing list
> grass-user@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user



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