Enhancement: Server connections list

[nmtoken]

It would be nice if the the server connections list could use the existing QGIS WCS list rather than require a separate listing.

[eox-cs1]

Hey, sorry, but I don't know where and how the internal WCS stores its data. If you could give me hint then I can have a look at it. Maybe this is possible, maybe not. ciao

[nmtoken]

In the C++ API it's accessed using qgswcssourceselect I think, QGIS/src/providers/wcs/ . I'm not sure if you can convert to python and call it that way.

The actual information is stored in the QGIS global settings (which for Windows is in the registry) so for example the branch is _HKEY_CURRENTUSER\Software\QGIS\QGIS2\Qgis\connections-wcs

and an entry might look like:

[HKEY_CURRENT_USER\Software\QGIS\QGIS2\Qgis\connections-wcs\EMODnet (MapServer on ogcdev)]
"url"="http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?"
"ignoreGetMapURI"="false"
"ignoreAxisOrientation"="false"
"invertAxisOrientation"="false"
"smoothPixmapTransform"="false"
"dpiMode"=dword:00000007
"referer"=""

In the python console I can get at these values with:

// Looking at how you might get at the WCS connections in QGIS using python
// Native format for Windows is the registry
// such as: HKEY_CURRENT_USER\Software\QGIS\QGIS2\Qgis\connections-wcs\EMODnet (MapServer on ogcdev)

from PyQt4.QtCore import QSettings
settings = QSettings(QSettings.NativeFormat, QSettings.UserScope, 'QGIS', 'QGIS2')
// test this is correct by getting all settings
print settings.allKeys()

settings.value('/Qgis/connections-wcs/EMODnet (MapServer on ogcdev)/url')
// Gives:
// u'http://194.66.252.155/cgi-bin/BGS_EMODnet_bathymetry/ows?'

[eox-cs1]

Hi nmtoken, thanks for this helpful insight.
As a Unix fan I would rather stick with a separate text-file, since this is easy editable/readable and does not interfere with possible changes applied to the main setting of future QGIS versions. In addition it seems that there is additional information required to be supplied which is of no relevance to the plugin.

In the long run I would assume that the QgsWcsClient2 might once get obsolete i.e. that the internal WCS will be able to handle WCS2.0 & the EO-WCS extensions (as has happend to the WMS plugin). Until then I'd rather put my effort into enhancing the plugin e.g. adding coverage extension information in the GetCapabilities window, get rid of lxml, adding the new WCS-standard extensions, username/password support and other stuff like that. But that's only my point of view (and my limited time budget). In any case you are more than welcome to join the work. ciao

[nmtoken]

In *nix the default location is an .ini file I think; but I don't this really matters, as by using the API the location of the setting is platform independent I think.

Completely understand limited time constraints, and higher priorities, just thought it would be nice additional feature. I should as you suggest though see if I can add it to the code myself :)

[eox-cs1]

.ini would be windows, in *nix the usual would be a .conf or maybe a .cfg, located inside either the program directory or under /etc. I guess you're probably right about the API. As said I like text files for their easy readability/editing and even relocation/sharing to other machines/people. Would the API provide these possibilities?

So what do you expect to be the big benefit of using the API (beside not having double server url entries).

[nmtoken]

Though you say besides having double entries, this is important because nobody wants to maintain multiple entries ~ other plug-ins may/could also want to uses these same resource URLs, for example a WCPS plugin could, (yes I know one already exists and doesn't use this resource yet :()

As the global settings sit outside of the deployed code it allows updates to happen without (or with a lower likelihood of) loosing the settings. I've updated QGIS many times and my resources lists haven't been lost yet.

Using the API means one less hurdle for integrating the code into the QGIS master,at some point in the future.

[eox-cs1]

Not losing entries during update/re-installation is a good point too. I have noted that to my TODO list. "less hurdle for integrating" - if I'm not totally wrong QGIS is written in C not python so it would be a complete redevelopment anyway. I'm not really convinced though and from my point of view there are more important things which should be done first. But if you feel it is important to you - go on and do it.
Of course your input would be appreciated for other issues too. ciao