Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
Adding CSVT file reading - using CSVT file alongside data file to det…
…ermine field types
- Loading branch information
Showing
13 changed files
with
384 additions
and
18 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
bdcc01e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added feature to avoid problems Régis Hauberg found with current behaviour of provider which automatically assigns field types, which created problems joining data when the field type was not the desired type. See discussion at:
http://lists.osgeo.org/pipermail/qgis-developer/2013-May/026255.html
WIth this change the provider will look for a OGR CSV driver compliant .csvt file alongside the data file, and read field types from that if it exists. In fact it looks for a file with extension the same as the datafile, with a "t" added, so for a .txt file it will see if there is matching .txtt file, and so on.
While it is late to add a feature I see this as adding a lot of value with minimal impact on anything else. It adds one extra translation string (but only seen in the message log), and some text in the help delimited text provider help file. Other than that the changes are all within the provider code. There is no UI change in this.
This does not cover the much greater feature set that Régis is discussing, but it does address a significant weakness in the provider.
bdcc01e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if there is no csvt file?
bdcc01e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi Nathan
Just the same as before, it infers field types based on the content. Also if there is a csvt file, but the content is incorrect. Basically only changes the behaviour if there is a valid CSVT.
Cheers
Chris
bdcc01e
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff. Just checking :)