[Qgis-developer] QGIS Web Client improvements
a.neumann at carto.net
Fri Jan 3 05:33:13 PST 2014
Thank you for your initiative, Alessandro. My comments are inline.
Am 03.01.2014 13:06, schrieb Alessandro Pasotti:
> 2014/1/3 Bernhard Ströbl <bernhard.stroebl at jena.de>
>> Hi Alessandro,
> Hello Bernard, thanks for your comments!
>> new ideas are always welcome. I comment below
>> Am 03.01.2014 12:30, schrieb Alessandro Pasotti:
>>> 1. remove as many as possible hardcoded values from wsgi search scripts
>>> (even if I prefer Python I did a re-implementation in PHP of these
>>> scripts mainly because my customer needs them, this implementation has
>>> no hardcoded values, no need for special columns and almost no
>> +1 for the php implementation as on an average web server php is more
>> likely already installed than wsgi
>> Could you elaborate which hardcoded values and columns you removed?
> This is all the configuration you need:
> I removed:
> * the DB connection parameters (they are already in the project file)
> * the search table name (it's now the layer name)
> * the displaytext, and search_category fields
> The idea is that you should not have to modify your table and create any
> particular column to make it work (it might be usefult to do that in any
> case for performance reasons).
In my case I deliberately decoupled the search completely from the
project - as a I want a lot of search options always available,
regardless of the project, also if the search layer is not available in
Imagine a project only containing raster maps. You still want to be able
to search for addresses, parcel numbers, streets, buildings, etc.
without having to load all of these layers into the project.
BTW: there is an alternative search method that uses the builtin layers
already. See section 4.2 in
It uses QGIS server without any additional scripts necessary. It has a
"drill-down"-like interface which feels different from the other search
So please just make sure that both versions will work - the decoupled
search as it is now possible and your new idea of deriving search from
>> Be aware of SQL injection!
> Since most parameters are now taken directly from the project file, the
> only parameters that need to be passed on the URL are the search text, the
> layer name (which doesn't go directly in the query).
> I'm using PDO prepare statements whenever possible to avoid injections and
> a preg_replace to strip away everything potentially harmful.
>> 2. remove as many as possible hardcoded values from GlobalOptions.js and
>>> Customizations.js or try to guess smart defaults from ProjectSettings
>> which are you aiming at removing?
> Not much yet. First I want to get the map parameter from the query string:
> var project_map = Ext.urlDecode(window.location.search.substring(1)).map;
This is already possible - see the section on Apache URL rewriting where
the map name parameter is derived from the URL.
See section 4.2.2 at
> Then I would like to get layer from the ProjectSettings and automatically
> select layers for the reference map.
Again, there is a good reason to do it and there are reasons for not
doing it. In my case I again wanted to decouple the reference map from
the content of the QGIS project. The best reference map in my case was
to use a topographic map series with different scales. I also wanted to
use this reference map in a project where the reference maps layers
aren't present in the project - e.g. in a project about different
If you implement this in a configurable way, then I am fine with your
change - but make sure that the current behaviour of decoupled reference
map can be kept, if specified.
>> 3. resurrect the right panel (trying to solve the map reload issue) and
>>> make it optional
>> we were happy to have got rid of the right panel because the map always
>> redraws when it is opened. What info do you put in there?
> Ideally, I would like to have the option to configure and use an additional
> panel (south or east) to put one or all of the following accordion tabs:
> * the search results
> * the legend
> * the feature attributes
> I'm aware of the map resize->reload problem, I'm convinced that it can be
> solved (and I would like to see an option here too: fo simple maps someone
> maybe wants to keep the map resize active)
I am fine with that as long as it is configurable.
>> 3.1 make this info panel optionally available in the south area instead
>>> of the east one
>>> 4. implement HTML tooltips taken from the HTML tooltip templates used in
>>> QGIS desktop (done)
>>> 5. find a way to get reference map layers from ProjectSettings instead
>>> of hardcoding them
>> are you talking about the BGMaps?
> No, a discussed in point 2, I would like to have a way to (optionally)
> automatically guess the reference (mini-map) layers.
see my notes above for decoupled reference maps.
> First option would be: take all visible layers at start.
>> 6. this might be difficult or not possible: it would be nice to have an
>>> interactive legend so that the user can directly click on a legend item
>>> to filter->zoom to the features that match the selected legend item. I
>>> feel this would require changes to the server side too....
>> the legend as created with GetLegendGraphic is - well - a graphic. I
>> cannot see how you could implement this
If the legend graphic would be an intelligent SVG graphic (with some
metadata in the SVG elements) rather than a stupid PNG I could see this
as a possibility. It would need an extension in the GetLegendGraphic
request. Each legend object in an SVG legend could know its relation
with the rule or category and the user could interact with it.
There is already a filter parameter available that allow the filtering
of a layer. See
already implemented FILTER parameter it would be rather easy to implement.
I would be interested in this improvement myself. So maybe we could team
up with this. Would be useful to further discuss what we want to
accomplish with the interactive legend.
More information about the Qgis-developer