QGIS » QGIS Application

Confirmed also on linux.

Fixed in changeset 0498c955469effadc6691032b65d663821cf5bf1.

Patch applied in 0498c95546

I get an empty table using 1.7.4 under ubuntu 10.04 (from ubuntugis-unstable binaries).
See attached files.

Is there any news about this problem?

I'm trying Union both in 1.7.4 and 1.9.90-Alpha QGIS code revision
f3b78ef, in a Windows XP computer.

Union is not working correctly, it unions the geometries but looses
some attributes in the process.

See the attached files. Has you can see in the union5.shp attributes the polygon2 remaining (the part that doesn't intersect the other) have incorrect attributes.

Hi Alexandre,

the resulting table of attributes looks like the attached image (I'm using master on both linux and windows). It seems fine to me. Can you leave feedback? cheers.

Alexandre Neto wrote:

Is there any news about this problem?

I'm trying Union both in 1.7.4 and 1.9.90-Alpha QGIS code revision
f3b78ef, in a Windows XP computer.

Union is not working correctly, it unions the geometries but looses
some attributes in the process.

See the attached files. Has you can see in the union5.shp attributes the polygon2 remaining (the part that doesn't intersect the other) have incorrect attributes.

Union should have an option to integrate those fields with the same name
in the new table (i.e., an option to do what mmqgis/Transefer/Merge layers does).
(Merge layers is an ambiguous term).
In other words, if vector layer dum1 has fields A,B,C and vector layer dum2 has fields
A,B,D, the new option should create a table with fields A,B,C,D
Note that in most cases, the user wants to make union of layers with the same fields in
their tables (i.e., both dum1 and dum2 have fields A,B,C and the result (with this option activated) should have
fields A,B,C as well (currently it is A,B,C,A1,B1,C1), which is rarely what the user wants/expects

Agus

alobo - wrote:

Union should have an option to integrate those fields with the same name
in the new table (i.e., an option to do what mmqgis/Transefer/Merge layers does).
(Merge layers is an ambiguous term).
In other words, if vector layer dum1 has fields A,B,C and vector layer dum2 has fields
A,B,D, the new option should create a table with fields A,B,C,D
Note that in most cases, the user wants to make union of layers with the same fields in
their tables (i.e., both dum1 and dum2 have fields A,B,C and the result (with this option activated) should have
fields A,B,C as well (currently it is A,B,C,A1,B1,C1), which is rarely what the user wants/expects

Hi Agus,

so how the attributes values should be in the merged columns? concatenated? or the user should have the option to choose to keep the "A" column from a specific table?

In any case I see this request as a feature request, not as a bug, so I would open a separate ticket and re-close this one.

alobo - wrote:

Union should have an option to integrate those fields with the same name
in the new table (i.e., an option to do what mmqgis/Transefer/Merge layers does).
(Merge layers is an ambiguous term).
In other words, if vector layer dum1 has fields A,B,C and vector layer dum2 has fields
A,B,D, the new option should create a table with fields A,B,C,D
Note that in most cases, the user wants to make union of layers with the same fields in
their tables (i.e., both dum1 and dum2 have fields A,B,C and the result (with this option activated) should have
fields A,B,C as well (currently it is A,B,C,A1,B1,C1), which is rarely what the user wants/expects

Agus

Hi Agus, see my other comment. This should be filed as a feature request. Cheers.

Hi all,

the union command works fine now with small testcases, I tested with two polygons having one overlap: everything is ok.

But in a more complex scenario I run into the following problem:

1) I union two layers: buffered streams (multipart, id 9000) and buffered birdnests (id 1 and 2). Both ID fields are called "id".
2) After the union, all id values end up in the id column, the the second id field (id_1) remains empty. This way, you can't distinguish overlapping from non-overlapping features using ID's. See attached screenshot01.
3) When I convert the multipart streams layer to single part and assign different names to the id fields, things look ok, except for one overlapping feature which gets both id's. I have no clue why this happens (see screenshot02).

I have tested this on mac and windows (qgis 1.8.0). It looks to me as if the union command still has some issues, or am I doing something wrong?

Cheers, Bernd

Hi Salvatore,
thanks for your quick reply. The test datasets are not big, please find them enclosed (the buffered streams as multi- and single part, and the buffered nests). I'm looking forward to hearing about your test results.

Cheers, Bernd

I can confirm!
The result expected of "streams_f_bufd" UNION "nests_f_buf_single" should be:

id    |    id_1
----------------
9000  |    1
9000  |    2
9000  |    NULL
1     |    NULL
2     |    NULL

QGIS continues to give overlapping polygons after a second union processing. I've tested it with fTools 0.6.2. As a curious note, neither the polygon overlapping function of sextante and saga produced acceptable results after the second running of "complete" intersection in saga plugin and union algorithm using sextante.

You can see this easily applying transparency to the resultant layer. In that way you can detect overlapping polygons in a single layer. That must not exist as a result of a union function.

Making "fake" simple polygons work fine. I made three fake polygons, very simple with some holes though. The third union process using fTools worked fine.

Enclosed are original shapefiles for anybody that would have interest in this important issue.

Ivan Santiago wrote:

QGIS continues to give overlapping polygons after a second union processing. I've tested it with fTools 0.6.2. As a curious note, neither the polygon overlapping function of sextante and saga produced acceptable results after the second running of "complete" intersection in saga plugin and union algorithm using sextante.

the tool is not wrong, in fact if you see in detail (see attached screenshot) the two polygons that seems wrong after the union are not identical in the input layers, there is a very small difference, something like 0.4 mm... but this makes them two non identical, overlapping polygons...

merging with #7708