[Qgis-user] Classification uses full range of values from joined attribute table

[Ramon Andiñach]

> On 10 Nov 2013, at 4:14, Lee Hachadoorian <Lee.Hachadoorian+L at gmail.com> wrote:
> 
> I am joining a spatial layer (from PostGIS) with an attribute (aspatial) table (also from PostGIS). There are more rows in the attribute table than in the spatial table. After I do the join, I open the attribute, and it only displays rows in the spatial table (i.e., this is an INNER JOIN, or maybe a LEFT JOIN, I didn't test tables with unmatched attribute rows. The point being, there are no attribute rows with unmatched rows from the spatial table).
> 
> But when I style the layer, if I choose one of the columns from the joined attribute table and classify the values (I was using graduated symbology for a numeric field), the classes that are produced are based on the entire range of values from the attribute table, i.e., the classification is not honoring the fact that the join result omits many of the rows from the attribute table. Since, in the case I tested, the field values for those rows which match features in the spatial layer only cover a small part of the total range, the resulting map has all the features falling into fewer classes than specified (e.g., there are 5 classes in the data, but only 2 colors on the map).
> 
> First, I should ask whether I am doing anything wrong here, or if people can confirm this behavior. Second, I cannot find a specific feature request related to this at hub.qgis.org, so is this already an tracked issue that I just wasn't able to find? Third, do others agree that this is unexpected behavior?

Other than the styling problem that sounds about normal. 

I can't replicate the styling issue with a shape file and csv (I don't have a PostGIS layer to hand). It might be something PostGIS specific and you will need someone who knows more about PostGIS to confirm this. 

Out if curiosity, why not do the join inside the database and then look at the joined table in QGIS?
I'm pretty sure you have better control on the join in the DB than in QGIS. 

-ramon. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20131110/f625858e/attachment.html>