[Qgis-developer] QGIS Web Client improvements

[Alessandro Pasotti]

2014/1/3 Andreas Neumann <a.neumann at carto.net>

> Hi,
>
> Thank you for your initiative, Alessandro. My comments are inline.
>


Hello Andreas, thanks for your clarifications, my comments follow.


>
> 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!
>
> [...]

> >
> > This is all the configuration you need:
> > https://github.com/elpaso/QGIS-Web-Client/blob/master/php/config.php
> >
> > 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
> the project.
>
> 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.
>
>
I see you point, I believe that both should be possible but I suspect that
the zero-configuration approach should come first.
This because this way you have a working installation with less
configuration, you can always override the default behaviour to have more
complex search options.



> BTW: there is an alternative search method that uses the builtin layers
> already. See section 4.2 in
> https://raw.github.com/qgis/QGIS-Web-Client/master/README
>
> It uses QGIS server without any additional scripts necessary. It has a
> "drill-down"-like interface which feels different from the other search
> method.
>

I saw this search feature, and I'm using both (the Python-wsgi/PHP one and
GetFeatureInfo) as they are both useful, I see them as a "generic search"
and an "advanced search", we need both.


>
> 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
> the project.
>


Yes, absolutely agreed, my intention is to add features without breaking
the already existing (and yet amazing) features.



>
> >> 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.
> >
> >
> >>
> >>
>
[...]

>
> > 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
> orthoimages.
>
> 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.
>
>
Again, I see you point :)
But again, I'm asking myself which is the easier/simple option to satisfy
the vast majority of use cases, I would by default start with the option
that works out of the box without the need to configure anything.
Then, show how to completely customize the reference map.

The overall feeling I've got  starting with QGIS Web Client is that the
search feature and reference map in QGIS Web Client start with the more
complex scenario and require too much user configuration to make it work
(even worse: the search requires a particular table structure and column
names!), on the contrary, we should start with the simplest scenario and
try to make it work with minimal configuration, then show a way to do the
most complicated things.


[...]


> >
> >>  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
>
> http://hub.qgis.org/projects/quantum-gis/wiki/QGIS_Server_Tutorial#FILTER-parameter
>
> If an SVG graphics (with a bit of Javascript) could be coupled with the
> 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.
>


Great that you're in!

The simplest approach I see is to use the RULE parameter to
GetLegendGraphic to download the individual image for each class, then
build the legend on the client with a small Python/PHP helper.

An SVG image would also fit and would not require an additional Python/PHP
helper as long as the SVG has hooks to add js functionality to the legend
items.

Another option is to do some mapserver-like templating.

What about filing a ticket for this feature and moving the discussion there?


-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20140103/71200576/attachment.html>