[Qgis-developer] URI

[Radim Blazek]

JFYI,
I have extended QgsDataSourceURI with some generic methods setParam,
param, hasParam, encodedUri, setEncodedUri. QUrl is used to
encode/decode the URI.
I have used the new  QgsDataSourceURI for WMS so that various WMS
related hacks in QgisApp and QgsRasterLayer, browser etc could be
removed.

Radim

On Wed, Jun 8, 2011 at 2:10 PM, Marco Hugentobler
<marco.hugentobler at sourcepole.ch> wrote:
> Hi Radim
>
>> 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.
>
> This sounds reasonable to me.
>
>>Style hint or similar parameters could be add as
>>standard params to URI in future.
>
> What do you mean with 'style hint' in that context? A feature style that comes
> from the provider (e.g. kml, dxf)?
>
> Regards,
> Marco
>
> Am Montag, 6. Juni 2011, 17.32:07 schrieb 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
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> --
> Dr. Marco Hugentobler
> Sourcepole -  Linux & Open Source Solutions
> Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
> marco.hugentobler at sourcepole.ch http://www.sourcepole.ch
> Technical Advisor QGIS Project Steering Committee
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer