<p dir="ltr">How about using Field in the VRT instead of using a CSVT? <br>
</p>
<div class="gmail_quote">On May 25, 2013 12:16 PM, "Chris Crook" <<a href="mailto:ccrook@linz.govt.nz">ccrook@linz.govt.nz</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Ok, I hadn't really thought about the browser much .. so far I've not used it much myself and nor have most of the people I work with.<br>
<br>
It certainly creates a challenge with delimited text files generally, as they don't have any inherent spatial intelligence. So just dragging them to the map without a intermediate dlalog is going to be limiting. Which I guess is where you are coming from with the CSVT/VRT file idea. Seeing it in the browser makes it much clearer to me.<br>
<br>
I think it may be better to extend the CSVT idea than use VRT. The advantage of CSVT is that it is implicitly associated with the data file. The VRT file could be anywhere, and have any name - the user would be selecting the VRT file rather than the CSV file with the actual data. It seems more intuitive to me to be selecting the data file.<br>
<br>
The CSVT file is also analagous to metadata files that are alongside images (eg world files), so there is a good precedent.<br>
<br>
Perhaps the way to go is to add more functionality to the CSVT file (to incorporate the features of the VRT/DLT driver). I wonder if the place to do the work is in GDAL/OGR, rather than in QGIS? Once the capabilities are there, then the QGIS dialog would just be a way of writing the csvt file if you wanted to...<br>
<br>
So we would be looking at something more like a VRT file in content (though perhaps not XML in terms of end user accessibility) but automatically associated with the file by its name, rather than the other way round as in the VRT file.<br>
<br>
If we were doing that, then we might want to use something a bit more identifiable than just adding a 't' to the file name. Maybe adding an extension like .gmd (geographic metadata) would be better. Also much easier to identify with confidence in the browser, particularly since we wouldn't just be using data files with .csv extensions.<br>
<br>
Cheers<br>
Chris<br>
<br>
_______________________________________<br>
From: HAUBOURG [<a href="mailto:regis.haubourg@eau-adour-garonne.fr">regis.haubourg@eau-adour-garonne.fr</a>]<br>
Sent: 25 May 2013 22:20<br>
To: Chris Crook<br>
Subject: RE : Delimited text enchancements<br>
<br>
Hi Chris,<br>
you are right, reading csvt is enough at the moment, and merging spreadsheet with ogr data source in one only dialog might be complex and need prototyping. In the other end, we have growing toolbars with more an more datasources, and many users switch to browser panel. I'm trying to have QGIS as simple as possible for the end users I manage here, and few of them have advanced informatic skills.<br>
<br>
I think I will first hire someone to prototype things as you suggest and submit it to community. Work is important if we want that all access (drag-drop / browser / toolbar menu) lead to same behaviour, but it's necessary.<br>
<br>
Thanks again, I see things more clearly now.<br>
Régis<br>
<br>
________________________________________<br>
De : Chris Crook [<a href="mailto:ccrook@linz.govt.nz">ccrook@linz.govt.nz</a>]<br>
Date d'envoi : samedi 25 mai 2013 00:42<br>
À : HAUBOURG<br>
Objet : RE: Delimited text enchancements<br>
<br>
Hi Régis<br>
<br>
Don't get too excited, I just said I wouldn't start looking at it till then!!!<br>
<br>
As it turns out, not true. I figured out overnight that adding reading the csvt file is a very small safe change, so I've pushed it up to master. Hope no one minds - my first real commit since being given the privilege.<br>
<br>
So the provider will read .csvt files (or .xxxt files, basically the data file name with a 't' appended to it).<br>
<br>
A long way short of the ideas you were talking about, but a start.<br>
<br>
On your question about a unified vector dialog, I'm not sure. I guess it may be good to mock something up in python first. If I understand correctly you are wanting to add spreadsheets etc to the dialog, and manage the OGR drivers as well. The dlt txt dialog is already busy with just it's own stuff, so I'm not sure how it would work. Maybe something similar to the way renderers are handled, so each file type has its own widget. Also the OGR/dlt txt options are different, so that could be challenging.<br>
<br>
My thinking so far is more about improving the dlt txt dialog so that it is easy to select all the options at once, or have them read from a metadata file if one is present...<br>
<br>
Cheers<br>
Chris<br>
________________________________________<br>
From: HAUBOURG [<a href="mailto:regis.haubourg@eau-adour-garonne.fr">regis.haubourg@eau-adour-garonne.fr</a>]<br>
Sent: 25 May 2013 02:02<br>
To: Chris Crook<br>
Subject: RE: Delimited text enchancements<br>
<br>
Hi Chris,<br>
I wish I had some time to help you coding . That's faster than contracting!<br>
What is your opinion about a unified vector dialog? If I start a call for offers, I must at least be sure community agrees..<br>
Régis<br>
<br>
> -----Message d'origine-----<br>
> De : Chris Crook [mailto:<a href="mailto:ccrook@linz.govt.nz">ccrook@linz.govt.nz</a>]<br>
> Envoyé : vendredi 24 mai 2013 08:40<br>
> À : HAUBOURG<br>
> Objet : RE: Delimited text enchancements<br>
><br>
> Hi Régis<br>
><br>
> I meant to say that I'm short of time for the next few of weeks but I'll<br>
> probably start on a first cut of the CSVT enhancements we discussed after<br>
> that as it will be really useful for me too. It won't make 2.0 of course, as you<br>
> noted ...<br>
><br>
> Cheers<br>
> Chris<br>
><br>
> This message contains information, which is confidential and may be subject<br>
> to legal privilege. If you are not the intended recipient, you must not peruse,<br>
> use, disseminate, distribute or copy this message. If you have received this<br>
> message in error, please notify us immediately (Phone 0800 665 463 or<br>
> <a href="mailto:info@linz.govt.nz">info@linz.govt.nz</a>) and destroy the original message. LINZ accepts no<br>
> responsibility for changes to this email, or for any attachments, after its<br>
> transmission from LINZ. Thank You.<br>
<br>
<br>
This message contains information, which is confidential and may be subject to legal privilege. If you are not the intended recipient, you must not peruse, use, disseminate, distribute or copy this message. If you have received this message in error, please notify us immediately (Phone 0800 665 463 or <a href="mailto:info@linz.govt.nz">info@linz.govt.nz</a>) and destroy the original message. LINZ accepts no responsibility for changes to this email, or for any attachments, after its transmission from LINZ. Thank You.<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>