Timeline for QGIS one to many join issue
Current License: CC BY-SA 4.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 17, 2019 at 17:17 | comment | added | Julija M | All the features have more than 1 material analysed, and because they are residential and non-residential buildings they all will have more or less the same materials. In the end there is total of material stock which does not correspond to the original calculations | |
| Aug 17, 2019 at 17:15 | comment | added | Julija M | Then I got another set of data (csv) from a fellow, which contained objects/polygons/structures (same multiple IDs as in shapefile) with assigned representative materials intensities (amounts) to each structure (as said above in comment they are not the same in shape or height therefore different quantities). As the IDs are not unique for each polygon QGIS merges them using only first ID. But I need to avoid that so my amounts from excel matches the one when joined to QGIS. I am not sure if I am explaining ti correctly anymore :( | |
| Aug 17, 2019 at 17:13 | comment | added | Julija M | @Cory, not exactly. The IDs do not have anything with materials. They represent ID for each polygon/structure. Shapefile is provided by municipality. Why they have same IDs for multiple structures? Because on 1 parcel (1 owner) there are multiple structures but they all have the same ID, as they are connected to that same parcel/owner. In the shapefile there are only attributes as building type, district, height, area etc. | |
| Aug 17, 2019 at 16:45 | comment | added | Kartograaf | OK I think I understand what is happening. Some of your features in the shapefile are made from more than one type of material, so the ID numbers for those features occur multiple times in the output tables. Does this sound correct? | |
| Aug 17, 2019 at 16:23 | comment | added | Julija M | @Cory still the same | |
| Aug 17, 2019 at 16:10 | history | edited | Kartograaf | CC BY-SA 4.0 |
added 60 characters in body
|
| Aug 17, 2019 at 16:06 | comment | added | Kartograaf | @JulijaM Try it again now that I changed the merge operation to make it exclude the extra rows. | |
| Aug 17, 2019 at 16:05 | history | edited | Kartograaf | CC BY-SA 4.0 |
added 60 characters in body
|
| Aug 17, 2019 at 15:05 | comment | added | Julija M | And I tried all of these options <datasciencemadesimple.com/join-in-r-merge-in-r> but still the same duplicated rows | |
| Aug 17, 2019 at 10:28 | comment | added | Julija M | I already tried duplicate and unique, but it does not seem to work | |
| Aug 17, 2019 at 9:48 | comment | added | Julija M | @Cory when I merge the file I have 120 892 entries not 84000. Which makes my materials doubled, and again is something I want to avoid. Any other ideas? | |
| Aug 16, 2019 at 22:31 | history | edited | Kartograaf | CC BY-SA 4.0 |
added 111 characters in body
|
| Aug 16, 2019 at 22:19 | comment | added | Kartograaf | @Vince you are right, I changed the code to recommend an R-only solution. | |
| Aug 16, 2019 at 22:18 | history | edited | Kartograaf | CC BY-SA 4.0 |
deleted 16 characters in body
|
| Aug 16, 2019 at 22:10 | comment | added | Kartograaf | @JulijaM When you create a shapefile in ESRI's shapefile format (.shp), there are some other files that are created alongside it. Namely, an index file (.shx) and a d-base table (.dbf). The table can be edited according to your desired additions in a more manipulable format (i.e. .csv), then rewritten as a .dbf table so that the main shapefile (.shp) will reflect the changes. | |
| Aug 16, 2019 at 21:31 | history | edited | csk | CC BY-SA 4.0 |
added 6 characters in body
|
| Aug 16, 2019 at 21:17 | comment | added | Vince | @csk Big difference on 84k fields vs. 84k rows, but using Excel on a shapefile's dBase file is still a recipe for disaster, especially in the hands of a novice -- too many opportunities to corrupt/reorder the row count and completely lose association between features and attributes. I didn't downvote, but I can't upvote either. | |
| Aug 16, 2019 at 20:05 | comment | added | Julija M | @Cory what do you mean dbf file? I am not sure about d-base file, I am mac user. | |
| Aug 16, 2019 at 19:47 | comment | added | csk | @vince Given the clarifications in the comments above (IE that this data has only 15 columns, not 84000) is this now a viable solution? | |
| Aug 15, 2019 at 20:45 | comment | added | Vince | dBase-III has a documented limit of 100 fields and a hard limit of 255 fields. It is not possible to write 84,000+ fields to a shapefile. There's also a 4000 byte transfer buffer limit on the dBase specification, so even if that many fields were permitted, they couldn't be wider than 0.38 bits each. | |
| Aug 15, 2019 at 20:30 | review | First posts | |||
| Aug 16, 2019 at 9:41 | |||||
| Aug 15, 2019 at 20:28 | history | answered | Kartograaf | CC BY-SA 4.0 |