loading points layer via delimited text file (CSV format) results in first point placed at coordinate x=0, y=0

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)
Original Redmine Issue: 7688
Affected QGIS version: master
Redmine category:data_provider

---

The recent set of improvements for the delimited text file layer is fantastic. Refinements on CSV support is most welcome.

I just noticed an important issue with CSV support: first point extracted from first row is wrongly located at coordinate x=0, y=0 irrespective of the x and y value. The subsequent points / rows have proper coordinates.

To reproduce, open the attached CSV file, and note the first point being placed at coordinate 0,0.

---

• 1366683657.csv (Mathieu Pellerin - nIRV)

[qgib]

Author Name: Chris Crook (@ccrook)

---

Thanks .. will look at this urgently!!

[qgib]

Author Name: Chris Crook (@ccrook)

---

Thanks .. will look at this urgently!!

Ok, I've looked at the file. I only get one record at 0,0, which is at line 114 in the input file (#=4869, row 85 in a spreadsheet), and that is indeed at 0,0. Can you confirm that it is the first record that appears to be at 0,0 when you look at the file?

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

For me, the record that is being placed at 0,0 is item #6460, row 2 in spreadsheet.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

Ok, I've looked at the file. I only get one record at 0,0, which is at line 114 in the input file (#=4869, row 85 in a spreadsheet), and that is indeed at 0,0. Can you confirm that it is the first record that appears to be at 0,0 when you look at the file?

here too

[qgib]

Author Name: Chris Crook (@ccrook)

---

Odd that I can't reproduce this. Couple of questions:

1. What is the code revision that you have built (Help|About)
2. What platform, compiler, etc are you running on
3. Are you saying also that the point on line 114 is not plotting at 0,0? If not, can you determine where it is plotting.
   Thanks
   Chris

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

Oh wow, that's super odd. Here's why I had a different result from you: I had the "[x] open feature form, if a single feature is identified" checked. I've unchecked it, and the story gets more confusing, but partly compatible with your observations:

• If I click on the single dot with the 'identity feature' tool, the identify results window does show point #=4869 as being the one placed at 0,0
• However, if I then open the feature form of the selected point (expend the (action) node and click on the 'view feature form' item), I see the attributes for point #=6460

Odd, very odd. As for your questions, I'm running a osgeo4w nightly build, revision 3bd21bc.

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

The reason why we had different observations was probably because you were seeing attributes from the identity result window, while I was seeing attributes from the feature form window. Why these two are not the same given a same point is simply scary :) good this issue seems to be revealing a more fundamental problem.

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

nirvn - wrote:

The reason why we had different observations was probably because you were seeing attributes from the identity result window, while I was seeing attributes from the feature form window. Why these two are not the same given a same point is simply scary :) good this issue seems to be revealing a more fundamental problem.

I can confirm this behavior and that is obviously something that has to be tagged as blocker. For now I'll tag this ticket as blocker, if after it is found that it is not the cause of the problem then please lower the priority and raise this issue with another ticket and/or in the dev mailing list.

NOTE: when clicking with the identify tool on the "wrong" point, the coordinate that shows in the "derived" category are almost all the times wrong (very far from 0,0) and every time different from th previous identify operation. This does not seems to happen for the other points.

---

• priority_id was changed from Normal to Severe/Regression

[qgib]

Author Name: Chris Crook (@ccrook)

---

Thanks for clarification - I'll investigate from the point of view of the delimited text provider, in case something weird is happening in that.

[qgib]

Author Name: Chris Crook (@ccrook)

---

Ok - problem is that QgsFeatureRequest::FilterFid option was never implemented in the delimited text iterator, so whenever a specific feature is requested it will return the first feature :-( Easy fix, will upload patch shortly once I've built some test cases.

Thanks for identifying and detailing this problem.

[qgib]

Author Name: Chris Crook (@ccrook)

---

I've submitted a pull request (#558) to fix this, plus test cases to ensure that it stays fixed!
Thanks again.

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

Chris, that was fsst :) is the pull request also fixing the 0, 0 placement issue?

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

oh I see, just re checked attached csv, the point is placed correctly, it's lat / lon are zeroes. I was misled into thinking otherwise because of feature form fetching wrong data.

[qgib]

Author Name: Chris Crook (@ccrook)

---

Yup, that's it. The placement was all fine, its just the feature form was always fetching the first feature (I think it would have done that for any point!)

[qgib]

Author Name: Chris Crook (@ccrook)

---

• pull_request_patch_supplied was changed from 0 to 1

[qgib]

Author Name: Mathieu Pellerin - nIRV (Mathieu Pellerin - nIRV)

---

Verified as fixed, thanks Chris.

---

• status_id was changed from Open to Closed
• resolution was changed from to fixed