[Qgis-developer] URI

Marco Hugentobler marco.hugentobler at sourcepole.ch
Wed Jun 8 08:10:46 EDT 2011


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


More information about the Qgis-developer mailing list