On 11/10/2013 05:41 AM, Ramon Andiñach
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.
I would have to disagree about it being normal. Not only does it not
conform to other well-known commercial products, but what about the
fact that in QGIS the attribute table does not display rows from the
join table that are unmatched in the base table? Why wouldn't the
user assume that the values used for styling would only be those
values visible in the attribute table?
Regarding whether this is a PostGIS issue, I have at this point
confirmed it with spatial::attribute table combinations of
PostGIS::PostGIS, PostGIS::CSV, shapefile::PostGIS, and
shapefile::CSV. Did you use layers where the subset of the data has
a significantly smaller range? In my case, the full data range of
the column from the attribute table is 1 - ~53,000, while the values
that appear in the geographic region of interest are only 10,000 -
15,000.
I do often do the join in-database, but for exploratory purposes I
don't want to always have to create database objects.
Best,
--Lee
|
