<html style="direction: ltr;">
<head>
<meta content="text/html; charset=windows-1255"
http-equiv="Content-Type">
<style>body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
</head>
<body style="direction: ltr;"
bidimailui-detected-decoding-type="preferred-charset"
bgcolor="#FFFFFF" text="#000000">
(Returning the discussion to the maillist)<br>
<br>
On 06/15/2012 03:58 PM, Rich Shepard wrote:
<blockquote
cite="mid:alpine.LNX.2.00.1206150546020.12466@salmo.appl-ecosys.com"
type="cite">On Fri, 15 Jun 2012, Micha Silver wrote:
<br>
<br>
<blockquote type="cite">Now that I think about it, I wonder how
hard it would be to add to v.in.db
<br>
an option to just reuse that same table as the attribute table
for the
<br>
newly created GRASS vector. I had a quick look at the code, and
it looks
<br>
doable (caveat: I'm not a c developer). Do you think this would
be a
<br>
important feature? After all, if you're working on the same
database, you
<br>
can just choose a different name for the new GRASS vector, and
it should
<br>
work...
<br>
</blockquote>
<br>
Micha,
<br>
<br>
I think it's a critical feature and should be the default rather
than an
<br>
option. When I recognized what was happening I was left with two
choices:
<br>
create a map/table with a new name and no attributes other than a
category
<br>
number and coordinates, or not create the map from coordinates in
the
<br>
existing table.
<br>
<br>
</blockquote>
<br>
v.in.db with a new name for the GRASS vector *should* reproduce all
columns from the original table into the new GRASS vector's
attribute table.<br>
<br>
<blockquote
cite="mid:alpine.LNX.2.00.1206150546020.12466@salmo.appl-ecosys.com"
type="cite"> How I read the v.in.db manual page (and the table
option) lead me to
<br>
believce the module's purpose is to create a vector map of points
based on
<br>
coordinates in an existing database table. This recognizes there
is an
<br>
existing table and the map would be created from it. The current
behavior is
<br>
use only the coordinates from the existing table and ignore all
other
<br>
attributes.
<br>
</blockquote>
<br>
I guess that v.in.db was designed to mirror all the other v.in.*
modules. Create both the geometry in GRASS and a new attribute table
as per db.connect.<br>
<br>
What might be even more attractive would be an option to link a
GRASS vector to a DB view. This would allow updating of the data
tables in the DB, and have the new values accessible from within
GRASS. I tried once without success. I don't think that v.db.connect
... layer=2 will work with a database view. Maybe someone on the
list with more experience can verify?<br>
<br>
<br>
<blockquote
cite="mid:alpine.LNX.2.00.1206150546020.12466@salmo.appl-ecosys.com"
type="cite">
<br>
A kludge would be to create the new map and table with a new
name, then
<br>
use the SQL UPDATE statement to copy the attributes from the
existing table
<br>
to the new one. This would be followed by DROP TABLE
<old_tablename>, then
<br>
ALTER TABLE <new_tablename> RENAME TO <old_tablename>.
<br>
<br>
</blockquote>
<br>
I think the easiest kludge might be to rename the original table to
some temp name *at the start*, then do v.in.db to whatever final
name you want for your GRASS vector. <br>
<br>
-- <br>
Micha<br>
<br>
<blockquote
cite="mid:alpine.LNX.2.00.1206150546020.12466@salmo.appl-ecosys.com"
type="cite">Rich
<br>
<br>
<br>
<br>
<br>
<br>
This mail was received via Mail-SeCure System.
<br>
<br>
<br>
</blockquote>
<p><br>
</p>
<br>
<pre class="moz-signature" cols="72">--
Micha Silver
GIS Consultant, Arava Development Co.
<a class="moz-txt-link-freetext" href="http://www.surfaces.co.il">http://www.surfaces.co.il</a></pre>
</body>
</html>