Okay, first of all, thanks once again for all the patience and the huge amount of help. I&#39;m now quite a bit further and just wanted to report back on how it all worked out so that people in similar quandries will be able to deal :) It doesn&#39;t work all the way yet, but at least I&#39;m a lot closer now. Unfortunately there is a question at the end, but I&#39;m going to ask it in the Postgres list too. I&#39;m sure they&#39;re as helpful as our community.<br>

<br><div class="gmail_quote">2011/11/27 Micha Silver <span dir="ltr">&lt;<a href="mailto:micha@arava.co.il">micha@arava.co.il</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="direction:ltr" bgcolor="#FFFFFF" text="#000000">Maybe I&#39;m not explaining well. v.db.join is usually for joining a
    table (non-spatial, *not* a GRASS vector) to an existing vector map.
    Typically you&#39;d have a map with nothing but &quot;cat&quot; values, and a
    table with an &quot;id&quot; column matching the &quot;cat&quot; values. You can use any
    pair of columns to match the features from the map to the rows from
    the table (as long as they are unique). However you can not have any
    column in the attrib that already exists in the map&#39;s table.<br></div></blockquote><div>Okay, so I guess the solution is really making sure that the data matches redundancy standards. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="direction:ltr" bgcolor="#FFFFFF" text="#000000">
    <br>
    It still seems to me the easiest method for your case would be to
    export all your GRASS vectors totally to a PostGIS database. Then
    create in PostGIS the views you want with whatever columns you
    want.  You&#39;ll only need to work out the access permissions to your
    database. From the &quot;ident&quot; failure you mentioned some mails back,
    it&#39;s a misconfiguration in pg_hba.conf. You need lines at the top
    something like<br>
    local  all  all trust<br>
    host all all <a href="http://127.0.0.1/32" target="_blank">127.0.0.1/32</a> trust  </div></blockquote><div>Good idea. I&#39;ve now set all the local accesses to trust. I know that&#39;s probably not the most safe thing, but on the other hand, nobody can physically access my computer except for the people I work with, so it should be okay. Plus, I&#39;m using the computer currently as a development machine. Interestingly enough, it only worked after I&#39;d edited pg_hba.conf to trust IPv6 connections. Does GRASS use IPv6?</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="direction:ltr" bgcolor="#FFFFFF" text="#000000"> </div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="direction:ltr" bgcolor="#FFFFFF" text="#000000">
    Jump over to the PostGIS maillist or check the PostgreSQL
    documentation for better help.</div></blockquote></div>I&#39;ll do that. I hope I can get some more help there, but in the meantime I&#39;m definitely grateful for the tons of help I&#39;ve gotten in the GRASS list.<div>

<br></div><div>Current status:</div><div><ol><li>Once I set the DB to trust IPv6 connections to localhost GRASS could upload the vectors to PostGIS. Incidentally, these vectors were then also available in Geoserver after trusting IPv4 connections to localhost. Very interesting. QGIS apparently uses a local connection, which is why I never really had the idea of letting IPv4/6 access the DB. The whole time the password and username were correct, so it was kind of confusing, but oh well. That&#39;s solved for now.</li>

<li>I tried exporting the attribute tables of the &quot;spatially joined&quot; tables into PostGIS, but for some reason GRASS didn&#39;t export anything. It said that I hadn&#39;t requested to export the geometries and should verify the &#39;type&#39; parameter, which is nonexistent in that db.out.ogr. I ended up just leaving that alone because those tables were already contained in the Postgres DB, even though they were still associated with the vectors in GRASS.</li>

<li>I then exported the building vectors with the nice smooth boundaries to PostGIS using v.out.ogr. No problem after turning on IPv6 trust. I deleted the duplicate columns from the tables I wanted to join to and tried using v.db.join, but got the following error:<br>

ERROR:  more than one row returned by a subquery used as an expression<br>Really strange, because I&#39;d used v.distance with dmax=0 on the centroids, updating the centroids with the values of the areas they lay in, so that it seemed unlikely that they would have multiple rows returned by that query. I came up with what I thought was a solution, but it only worked on two rows:</li>

<li>Rather than using v.db.join I did an SQL query in pgsql:<br><span class="Apple-style-span" style="font-family: &#39;Courier New&#39;; font-size: 13px; white-space: pre-wrap; ">ALTER TABLE alk_flaechen ADD COLUMN globalstra float, ADD COLUMN dachflaech float, ADD COLUMN nutzflaech float;
</span><span class="Apple-style-span" style="font-family: &#39;Courier New&#39;; font-size: 13px; white-space: pre-wrap; ">UPDATE alk_flaechen SET nutzflaech = (SELECT DISTINCT nutzflaech FROM gebaeude_nutzflaeche WHERE gebaeude_nutzflaeche.alk_cat=<a href="http://alk_flaechen.cat">alk_flaechen.cat</a>);
</span><span class="Apple-style-span" style="font-size: 13px; white-space: pre-wrap; "><font class="Apple-style-span" face="&#39;Courier New&#39;">UPDATE alk_flaechen SET dachflaech = (SELECT DISTINCT dachflaech FROM gebaeude_dachflaeche WHERE gebaeude_dachflaeche.alk_cat=<a href="http://alk_flaechen.cat">alk_flaechen.cat</a>);
</font></span><span class="Apple-style-span" style="white-space: pre-wrap; "><font class="Apple-style-span" face="&#39;Courier New&#39;" style="font-size: 13px; ">
</font><font class="Apple-style-span" face="arial, helvetica, sans-serif">So far, so good, but then...
</font></span><span class="Apple-style-span" style="white-space: pre-wrap; "><font class="Apple-style-span" face="arial, helvetica, sans-serif">
</font><font class="Apple-style-span" face="&#39;Courier New&#39;">UPDATE alk_flaechen SET globalstra = (SELECT DISTINCT globalstra FROM gebaeude_globalstrahlung WHERE gebaeude_globalstrahlung.alk_cat=<a href="http://alk_flaechen.cat">alk_flaechen.cat</a>);
</font></span><span class="Apple-style-span" style="font-family: &#39;Courier New&#39;; white-space: pre-wrap; ">ERROR:  more than one row returned by a subquery used as an expression</span></li></ol><div style="background-color: transparent; ">

<div style="background-color: transparent; "><span style="background-color: transparent; vertical-align: baseline; white-space: pre-wrap;"><font class="Apple-style-span" face="&#39;Courier New&#39;"><br></font></span></div>

<div style="background-color: transparent; "><span style="background-color: transparent; vertical-align: baseline; white-space: pre-wrap;"><font class="Apple-style-span" face="arial, helvetica, sans-serif">I have no clue why that&#39;s the case, and I can&#39;t for the life of me find anything on Google at all about how I should fix it. This error occurs consistently with that table, but not with the other tables, and as far as I can understand it should be impossible, because it&#39;s constructed so that only one value is returned. Nonetheless, that&#39;s the way it is.</font></span></div>

<div style="background-color: transparent; "><span style="background-color: transparent; vertical-align: baseline; white-space: pre-wrap;"><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></span></div>

<div style="background-color: transparent; "><span style="background-color: transparent; vertical-align: baseline; white-space: pre-wrap;"><font class="Apple-style-span" face="arial, helvetica, sans-serif">Anyway, I&#39;ll pass this on to the Postgres people, but if anybody else has an idea, it would be really nice... In the end, all I want is a table joined by attributes, which is an easy thing with every other GIS I know. I&#39;m not meaning to say that it can&#39;t be done in GRASS - I&#39;m just saying that it&#39;s GOT to be possible, since I&#39;ve never crossed the boundaries of GRASS&#39; capabilities before, no matter how hard I&#39;ve tried ;) Thanks again!</font></span></div>

<div style="background-color: transparent; "><span style="background-color: transparent; vertical-align: baseline; white-space: pre-wrap;"><font class="Apple-style-span" face="arial, helvetica, sans-serif"><br></font></span></div>

<div style="background-color: transparent; "><span style="background-color: transparent; vertical-align: baseline; white-space: pre-wrap;"><font class="Apple-style-span" face="arial, helvetica, sans-serif">Daniel</font></span></div>

</div></div>