[Qgis-developer] URI

[Radim Blazek]

On Wed, May 25, 2011 at 1:39 PM, Giuseppe Sucameli <sucameli at faunalia.it> wrote:
> On Wed, May 25, 2011 at 9:37 AM, Radim Blazek <radim.blazek at gmail.com>
>> Some possible solutions:
>> 1) minimal:
>>  - add WMS additional params somehow to URI + parsing in WMS provider
>> (it is not clear to me why it was not done this way when WMS was
>> implemented)
>> 2) maximal A:
>>  - use QUrl for all providers with providers key as scheme
>> 3) maximal B:
>>  - use modified QgsDataSourceURI (it is not generic, works with set
>> of known params only) for all params including provider key

> The 3) would be also good.
> An alternative would be use QgsDataSourceURI like a container for QUri, in
> this manner we can define our interface to access the uri informations.

It seems also the best to me.

>>  - how the QGIS should recognize layer type of a dropped URI? Should
>> it be a param in URI or the QGIS should recognize that from a provider
>> key (asking provider)?
>
> IMHO no, it should be the provider which takes care of this.

But we have addVectorLayer/addRasterLayer, so QgisApp has to know
before the type of layer. Is it necessary? Could we have simply
addLayer() which adds correct layer type according to type returned by
provider for given URI?

On Thu, May 26, 2011 at 1:27 PM, Marco Hugentobler
> It seems to me QUrl is designed for network addresses. Ok, it would be
> possible to abuse some properties and interpret the query string param/values
> as the provider parameters. However, it seems cleaner to me to enhance
> QgsDataSourceURI with what we need (so +1 for 3) ). Network based providers
> can still use QUrl internally.

Yes, QUrl probably is not sufficient, but it can be used for
encoding/decoding inside QgsDataSourceURI as suggested by Giuseppe.

On Sat, May 28, 2011 at 12:01 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
> 2 or 3 would be my choices with slight preference to 2 since
> everything can be encoded into QUrl, so we do not have to
> implement/improve custom parsing (as would be necessary in option 3).
> For simple creation of URIs we can provide functions that would
> generate the QUrl instances easily.

Again, I would use QUrl methods for parsing and encoding as mentioned above.


I think, that we may forget about generic URI syntax
(http://en.wikipedia.org/wiki/URI_scheme#Generic_syntax) or even about
registered schemes
(http://en.wikipedia.org/wiki/URI_scheme#Official_IANA-registered_schemes).

I would suggest a QgsDataSourceURI with two types of params. One type
whould be set/recognized by a provider to set/get provider specific
data source URI params, for example setParam(key, val) and
getParam(key). All parts of URI would be stored as params so that for
example host name of WMS URI would be stored as "host" param not as a
special part of URI.

The second type of params would be known to QGIS but not to provider.
Methods like setStandardParam() / getStandardParam() would set / get
some standard parameters, for example setStandardParam("provider",
"WMS") would set provider key, which would be encoded in URI string as
"_provider=wms" (with underscore to distinguish standard params).
Layer type could also be a standard param if we find it necessary to
be a part of URI. Style hint or similar parameters could be add as
standard params to URI in future.

Radim