N k
Sent from my iPhone
On Nov 6, 2018, at 16:46, grass-user-request@lists.osgeo.org wrote:
Send grass-user mailing list submissions to
grass-user@lists.osgeo.orgTo subscribe or unsubscribe via the World Wide Web, visit
https://lists.osgeo.org/mailman/listinfo/grass-user
or, via email, send a message with subject or body 'help' to
grass-user-request@lists.osgeo.orgYou can reach the person managing the list at
grass-user-owner@lists.osgeo.orgWhen replying, please edit your Subject line so it is more specific
than "Re: Contents of grass-user digest..."Today's Topics:
1. Re: partial vector copy to smaller territory (Markus Metz)
2. Re: v.colors usage (Markus Metz)
3. Vector points behaving strangely after using v.what.vect
(Jamille Haarloo)
4. Re: v.colors usage (Rich Shepard)
5. Re: v.colors usage (Rich Shepard)----------------------------------------------------------------------
Message: 1
Date: Tue, 6 Nov 2018 21:36:43 +0100
From: Markus Metz <markus.metz.giswork@gmail.com>
To: Frank David <frank.david@geophom.fr>
Cc: grass-user <grass-user@lists.osgeo.org>
Subject: Re: [GRASS-user] partial vector copy to smaller territory
Message-ID:
<CAG+h=FHPYBEjA3d8Jcp=hz-7nMfpp3_JCfA_iQA=2aYgMz6OXw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"On Tue, Nov 6, 2018 at 4:03 PM Frank David <frank.david@geophom.fr> wrote:
Le 05/11/2018 à 14:23, Frank David a écrit :
Le 02/11/2018 à 22:27, Markus Metz a écrit :
On Fri, Nov 2, 2018 at 6:32 PM Frank David <frank.david@geophom.fr
<mailto:frank.david@geophom.fr>> wrote:Le 02/11/2018 à 14:43, Markus Metz a écrit :
On Fri, Nov 2, 2018 at 11:58 AM Frank David <frank.david@geophom.fr
<mailto:frank.david@geophom.fr>> wrote:
Le 31/10/2018 à 20:57, Markus Metz a écrit :
Hi Frank,
On Wed, Oct 31, 2018 at 1:39 PM Frank David
<frank.david@geophom.fr <mailto:frank.david@geophom.fr>> wrote:
Hello Vero,
Thanks for your reply. It took almost one hour to extract my
area (I guess because of topology). I do the same with Qgis from a
shape in less than 10 minutes (but with several operations)... it's
may be a bad idea to have a so heavy vector map in Grass...this kind of operation could be much faster in latest GRASS 7.4
than in any previous versions. Which GRASS version are you using?
Hello Markus,
I'm using 7.4.1 on debian9
But my grass db folder is on a small server (Synology NAS), so
may be the network makes slow down the operation ?
This is possible, but it should not slow it down that much: 10 min
vs 1 hour
Can you provide a link to the vector from which you want to extract
a small area, and the command you used to extract a small area? Maybe
there is scope for optimization.Markus,
The data is CorineLandCover for france. You can download 400mo here
https://we.tl/t-tvldlmkVw3First I have imported the shape in PERMANENT
and I do : v.extract --verbose input=CLC12_FR_RGF@PERMANENT
where=CODE_12 IN (111,112,131,311,312,313,324) output=clc12
Hope it helps you...
import of the shapefile with v.in.ogr takes here 5 minutes
v.extract takes here 27 seconds instead of 1 hour"here" means a laptop with Intel Core i7 4th generation and standard
SATA SSD, i.e. no fancy new high-speed system at all.I am afraid this does not help you. What could take long is writing
attributes, depending on the database connection. I am using the
default sqlite database.You could use top to check if v.extract is running at 100%.
Hello Markus,
Thank you for your help.
I'm trying to do again the operation on local machine. I want fisrt,
create a vector with only selected data (on full France area). But
I've met a problem with v.extract.v.extract --overwrite --verbose input=CLC12_FR_RGF@PERMANENT type=area
where=CODE_12 IN (111,112,121,311,312,313,324)
output=CLC12_FR_RGF_BOISBATI@PERMANENT
Loading categories from table <CLC12_FR_RGF>...
DBMI-DBF erreur de pilote :
SQL parser error (syntax error, unexpected NAME processing
'IN') in statement:
SELECT cat FROM CLC12_FR_RGF WHERE CODE_12 IN
(111,112,121,311,312,313,324)
Unable to open cursor.
DBMI-DBF erreur de pilote :
SQL parser error (syntax error, unexpected NAME processing
'IN') in statement:
SELECT cat FROM CLC12_FR_RGF WHERE CODE_12 IN
(111,112,121,311,312,313,324)
Unable to open cursor.
ERROR: Unable select records from table <CLC12_FR_RGF>It looks that grass does not recognized "IN" sql condition. If I force
layer=-1, it runs bur the output vector is the same as input one.Am I wrong somewhere ? I use Grass 7.4.2 on debian9.
Thank you for your help.
Frank
Hi,
I've repeated the operation v.in.ogr and v.extract with success on
different grass mapset, but I get always the same error (on v.extract :
see above) only with one of my local grass mapset (PERMANENT). I do not
understand what happens...In the current mapset, the default database connection must not be DBF. You
can reset the default database connection to sqlite withdb.connect -d
After that verify with
db.connect -p
that sqlite is indeed the default database connection.Now you can repeat with v.in.ogr + v.extract
Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20181106/90cc5ea3/attachment-0001.html>------------------------------
Message: 2
Date: Tue, 6 Nov 2018 21:54:39 +0100
From: Markus Metz <markus.metz.giswork@gmail.com>
To: Rich Shepard <rshepard@appl-ecosys.com>
Cc: grass-user <grass-user@lists.osgeo.org>
Subject: Re: [GRASS-user] v.colors usage
Message-ID:
<CAG+h=FFwr3N+KWY2ig6TV6ixe1k4-zSYqwd0+93BhGr+dZE9mQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"On Tue, Nov 6, 2018 at 5:56 PM Rich Shepard <rshepard@appl-ecosys.com>
wrote:On Sat, 3 Nov 2018, Rich Shepard wrote:
Where have I made the syntactical mistake?
This is interesting. In the ../scripts directory, along with the grass
script, is a file called 'rules.txt' with perms 644. Adding a rules=option
to the v.colors command removed the rgb_col data type error and replaced
it
with two errors: 1) not finding a column in the table and 2) an inability
to
read the rules.txt file:
v.colors -c map=stations use=attr column=howmany rules=rules.txt
rgb_col=bin_col --o
ERROR: Column <howmany> not found in table <stations>
/home/rshepard/documents/white-papers/geochemistry/willamette-river-mercury/scripts/grass-display-sample-sites.sh:
line 12: /scripts/rules.txt: No such file or directory
For error 1:
db.describe tab=stations
...
column:howmany
description:
type:INTEGER
len:4
scale:0
precision:0
default:
nullok:yes
select:?
update:?For error 2:
$ ll rules.txt
-rw-r--r-- 1 rshepard users 187 Nov 6 08:34 rules.txtWhat might be going on here with 7.7.svn (r73645)?
Please check v.db.connect map=stations -p
and
db.connect -pIs the table attached to the map stations really in the default database?
Markus M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20181106/cebd44cf/attachment-0001.html>------------------------------
Message: 3
Date: Tue, 6 Nov 2018 17:59:22 -0300
From: Jamille Haarloo <j.r.haarloo@gmail.com>
To: GRASS user list <grass-user@lists.osgeo.org>
Subject: [GRASS-user] Vector points behaving strangely after using
v.what.vect
Message-ID:
<CADiROyfd+_R6pOCBF0S2xfxApQ_pGiLw4xDK+b-X2kVjUY78iQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"Hello all,
I created a vector points map in Grass with information on ecosystem
characteristics based on various sources. This was to be used as input to
create a training-set of a vector segment map with statistics for
classification.
I tried to copy the cat- values of the segments to the points- map based on
location as intermediate step by using v.what.vect. But this was not
successful - Not all cat- values of the points vector map was updated,
about 70% was. I tried then to update another (empty) column with the
segment cat-values which also worked partially - it worked for most of the
remaining which is about 25% of the total records and for non of the 70%.
Now I notice that the records of the updated cat-values are behaving
strangely. I can see the points in the map display, but if I highlight them
in the table they are not highlighted in the map display. When I click to
zoom to highlighted feature, I end-up somewhere else where it shouldn't be.
Also when I try to extract, copy or export the data, there seems to be
disconnect between the attribute values and the location of the points.
This happens with the ones of which the cat-values was updated, about 70%
of the records. When simply displayed, without other operations, it looks
fine and complete.Is there a way to repair this disconnect?
Best,
Jamille
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20181106/932073d7/attachment-0001.html>------------------------------
Message: 4
Date: Tue, 6 Nov 2018 13:34:39 -0800 (PST)
From: Rich Shepard <rshepard@appl-ecosys.com>
To: grass-user@lists.osgeo.org
Subject: Re: [GRASS-user] v.colors usage
Message-ID:
<alpine.LNX.2.20.1811061334120.13405@salmo.appl-ecosys.com>
Content-Type: text/plain; charset=US-ASCII; format=flowedOn Tue, 6 Nov 2018, Markus Metz wrote:
Please check v.db.connect map=stations -p
and
db.connect -p
Is the table attached to the map stations really in the default database?Markus M,
db.connect -p
driver: pg
database: willamette-river-hg
schema: group:Well, well, well. Here's the problem:
v.db.connect map=stations -p
Vector map <stations> is connected by:
layer <1/stations> table <stations> in database
</home/rshepard/data/grassdata/willamette_basin/mercury/sqlite/sqlite.db>
through driver <sqlite> with key <cat>How can stations be seen in the default sqlite database when db.connect
shows the table in the postgres database? What else is db.connect doing if
it allows grass commands to ignore what it reports and defaults to the
sqlite one?I thought db.connect used the database to which it reported being
connected.How do I remove the sqlite stations table so grass sees it in the
connected postgres database?Thanks!
Rich
------------------------------
Message: 5
Date: Tue, 6 Nov 2018 13:46:34 -0800 (PST)
From: Rich Shepard <rshepard@appl-ecosys.com>
To: grass-user <grass-user@lists.osgeo.org>
Subject: Re: [GRASS-user] v.colors usage
Message-ID:
<alpine.LNX.2.20.1811061335030.13405@salmo.appl-ecosys.com>
Content-Type: text/plain; charset=US-ASCII; format=flowedOn Tue, 6 Nov 2018, Markus Metz wrote:
Please check v.db.connect map=stations -p
and
db.connect -pIs the table attached to the map stations really in the default database?
Markus M,
When I run db.colums without specifying the driver does grass display the
columns in the sqlite or postgres table?db.columns table=stations
site_nbr
site_name
lon
lat
easting
northing
start_date
end_date
howmany
bin_colAdding the driver 'sqlite' suggests that db.columns sees the postgres
table:db.columns table=stations driver=sqlite
WARNING: Table <stations> not found in database <willamette-river-hg> using
driver <sqlite>So, if the db.* modules look in the postgres database tables, why does the
v.db.* modules look in the sqlite table instead? And, trying to rewire the
attribute table for the stations map from sqlite to postgres fails:v.db.connect map=stations driver=pg table=stations -o
ERROR: Column <cat> not found in table <stations>
All suggestions welcome.
Regards,
Rich
------------------------------
Subject: Digest Footer
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user------------------------------
End of grass-user Digest, Vol 151, Issue 13
*******************************************