N k Sent from my iPhone
> On Nov 6, 2018, at 16:46, [email protected] wrote: > > Send grass-user mailing list submissions to > [email protected] > > To 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > When 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 <[email protected]> > To: Frank David <[email protected]> > Cc: grass-user <[email protected]> > Subject: Re: [GRASS-user] partial vector copy to smaller territory > Message-ID: > <CAG+h=FHPYBEjA3d8Jcp=hz-7nMfpp3_JCfA_iQA=2aygmz6...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > >> On Tue, Nov 6, 2018 at 4:03 PM Frank David <[email protected]> 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 <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>> >>>>> Le 02/11/2018 à 14:43, Markus Metz a écrit : >>>>> >>>>> >>>>> >>>>> On Fri, Nov 2, 2018 at 11:58 AM Frank David <[email protected] >>>> <mailto:[email protected]>> wrote: >>>>>> >>>>>> Le 31/10/2018 à 20:57, Markus Metz a écrit : >>>>>> >>>>>> Hi Frank, >>>>>> >>>>>> On Wed, Oct 31, 2018 at 1:39 PM Frank David >>>> <[email protected] <mailto:[email protected]>> 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-tvldlmkVw3 >>>>> >>>>> First 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 with > > db.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 <[email protected]> > To: Rich Shepard <[email protected]> > Cc: grass-user <[email protected]> > Subject: Re: [GRASS-user] v.colors usage > Message-ID: > <CAG+h=ffwr3n+kwy2ig6tv6ixe1k4-zsyqwd0+93bhgr+dze...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Tue, Nov 6, 2018 at 5:56 PM Rich Shepard <[email protected]> > 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.txt >> >> What might be going on here with 7.7.svn (r73645)? > > 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 > -------------- 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 <[email protected]> > To: GRASS user list <[email protected]> > Subject: [GRASS-user] Vector points behaving strangely after using > v.what.vect > Message-ID: > <cadiroyfd+_r6pocbf0s2xfxapq_pgilw4xdk+b-x2kvjuy7...@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 <[email protected]> > To: [email protected] > Subject: Re: [GRASS-user] v.colors usage > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=US-ASCII; format=flowed > >> On 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 <[email protected]> > To: grass-user <[email protected]> > Subject: Re: [GRASS-user] v.colors usage > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=US-ASCII; format=flowed > >> On 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, > > 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_col > > Adding 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 > [email protected] > https://lists.osgeo.org/mailman/listinfo/grass-user > > ------------------------------ > > End of grass-user Digest, Vol 151, Issue 13 > ******************************************* _______________________________________________ grass-user mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-user
