[GRASS-user] grass-user Digest, Vol 151, Issue 13
Markos Kapes
mkapes at sas.upenn.edu
Tue Nov 6 14:22:27 PST 2018
N k
Sent from my iPhone
> On Nov 6, 2018, at 16:46, grass-user-request at lists.osgeo.org wrote:
>
> Send grass-user mailing list submissions to
> grass-user at lists.osgeo.org
>
> 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
> grass-user-request at lists.osgeo.org
>
> You can reach the person managing the list at
> grass-user-owner at lists.osgeo.org
>
> 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 <markus.metz.giswork at gmail.com>
> To: Frank David <frank.david at geophom.fr>
> Cc: grass-user <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] partial vector copy to smaller territory
> Message-ID:
> <CAG+h=FHPYBEjA3d8Jcp=hz-7nMfpp3_JCfA_iQA=2aYgMz6OXw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>> On Tue, Nov 6, 2018 at 4:03 PM Frank David <frank.david at 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 at geophom.fr
>>>> <mailto:frank.david at 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 at geophom.fr
>>>> <mailto:frank.david at 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 at geophom.fr <mailto:frank.david at 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-tvldlmkVw3
>>>>>
>>>>> First I have imported the shape in PERMANENT
>>>>>
>>>>> and I do : v.extract --verbose input=CLC12_FR_RGF at 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 at PERMANENT type=area
>>> where=CODE_12 IN (111,112,121,311,312,313,324)
>>> output=CLC12_FR_RGF_BOISBATI at 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 <markus.metz.giswork at gmail.com>
> To: Rich Shepard <rshepard at appl-ecosys.com>
> Cc: grass-user <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] v.colors usage
> Message-ID:
> <CAG+h=FFwr3N+KWY2ig6TV6ixe1k4-zSYqwd0+93BhGr+dZE9mQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Tue, Nov 6, 2018 at 5:56 PM Rich Shepard <rshepard at 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.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 <j.r.haarloo at gmail.com>
> To: GRASS user list <grass-user at lists.osgeo.org>
> Subject: [GRASS-user] Vector points behaving strangely after using
> v.what.vect
> Message-ID:
> <CADiROyfd+_R6pOCBF0S2xfxApQ_pGiLw4xDK+b-X2kVjUY78iQ at 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 at appl-ecosys.com>
> To: grass-user at lists.osgeo.org
> Subject: Re: [GRASS-user] v.colors usage
> Message-ID:
> <alpine.LNX.2.20.1811061334120.13405 at salmo.appl-ecosys.com>
> 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 <rshepard at appl-ecosys.com>
> To: grass-user <grass-user at lists.osgeo.org>
> Subject: Re: [GRASS-user] v.colors usage
> Message-ID:
> <alpine.LNX.2.20.1811061335030.13405 at salmo.appl-ecosys.com>
> 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
> grass-user at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-user
>
> ------------------------------
>
> End of grass-user Digest, Vol 151, Issue 13
> *******************************************
More information about the grass-user
mailing list