Bug report #7688

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

Added by Mathieu Pellerin - nIRV over 11 years ago. Updated over 11 years ago.

Status:Closed
Priority:Severe/Regression
Assignee:-
Category:Data Provider
Affected QGIS version:master Regression?:No
Operating System: Easy fix?:No
Pull Request or Patch supplied:Yes Resolution:fixed
Crashes QGIS or corrupts data:No Copied to github as #:16604

Description

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 Magnifier (31.9 KB) Mathieu Pellerin - nIRV, 2013-04-23 09:29 PM

History

#1 Updated by Chris Crook over 11 years ago

Thanks .. will look at this urgently!!

#2 Updated by Chris Crook over 11 years ago

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?

#3 Updated by Mathieu Pellerin - nIRV over 11 years ago

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

#4 Updated by Giovanni Manghi over 11 years ago

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

#5 Updated by Chris Crook over 11 years ago

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

#6 Updated by Mathieu Pellerin - nIRV over 11 years ago

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.

#7 Updated by Mathieu Pellerin - nIRV over 11 years ago

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.

#8 Updated by Giovanni Manghi over 11 years ago

  • Priority changed from Normal to Severe/Regression

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.

#9 Updated by Chris Crook over 11 years ago

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

#10 Updated by Chris Crook over 11 years ago

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.

#11 Updated by Chris Crook over 11 years ago

I've submitted a pull request (https://github.com/qgis/Quantum-GIS/pull/558) to fix this, plus test cases to ensure that it stays fixed!
Thanks again.

#12 Updated by Mathieu Pellerin - nIRV over 11 years ago

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

#13 Updated by Mathieu Pellerin - nIRV over 11 years ago

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.

#14 Updated by Chris Crook over 11 years ago

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!)

#15 Updated by Chris Crook over 11 years ago

  • Pull Request or Patch supplied changed from No to Yes

#16 Updated by Mathieu Pellerin - nIRV over 11 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

Verified as fixed, thanks Chris.

Also available in: Atom PDF