Re: [QGIS-Developer] Analytics on plugin downloads

[Paolo Cavallini]

Hola Pedro,
Il 09/02/2018 02:23, Pedro Camargo ha scritto:
>          As I continue the development of AequilibraE (a plugin focused
> on tools for transportation modelling), I wish I had access to
> statistics on who has downloaded the plugin (e.g. Google Analytics). 
> That would help me see what the audience is and, hopefully, gauge better
> where to put efforts on.
> 
> Is that something that other people also see as useful?  If so, is that
> technically possible? Is that planned in any ways?

while I understand it is useful to know our user better, I'm not sure we
want to allow collecting data on them; previous discussions on this
subject resulted in a clear "no" from most if not all parties involved.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Help system

[Paolo Cavallini]

Il 09/02/2018 08:29, matteo ha scritto:

> so the provider issue is fixed. Now from the doc side, we have to change
> the section headers so that they match the unique id of the algorithms
> in the code. Did I understand it correctly?
> 
> Many thanks again

Thanks a lot Nyall.
Who can change to doc side of it? Need help?
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Help system

[matteo]

Hi Nyall,


>> PR at https://github.com/qgis/QGIS/pull/6298
>>
>> Feedback on this approach is welcome, but I think fixing in the code
>> is correct vs fixing via redirects.

that's great! thanks for the PR!

> Just a heads-up: I've noticed while testing the above PR that while it
> fixes the native/3d/qgis issue, there's an issue with how the anchor
> links in the docs have been named.
> 
> E.g.
> 
> https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/database.html#import-into-spatialite
> 
> should actually be
> 
> https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/database.html#importintospatialite
> 
> Using the algorithm id and not its name. The id is unique,
> non-translated, and guaranteed to be set for the lifetime of 3.x, but
> algorithm names are translated, can be tweaked and refined and are not
> locked.
> 
> With the above PR the help directs to the URL using an id based
> anchor, so the anchors themselves in the docs should be updated to fix
> this.

so the provider issue is fixed. Now from the doc side, we have to change
the section headers so that they match the unique id of the algorithms
in the code. Did I understand it correctly?

Many thanks again

Matteo

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Server] Is QGIS Server 3 fast yet ? the 2018-02-06

[Nyall Dawson]

On 9 February 2018 at 03:29, Saber Razmjooei
 wrote:
> I think the performance could be related to this:
> https://issues.qgis.org/issues/17809
>

I spent some time today looking into this issue. The end result was
https://github.com/qgis/QGIS/pull/6300, but it's mostly
micro-optimisations and definitely not of the order of 50% like the
report describes.

I can only think it's a speed regression somewhere in Qt itself...

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Help system

[Nyall Dawson]

On 9 February 2018 at 11:32, Nyall Dawson  wrote:
> On 9 February 2018 at 03:01, Paolo Cavallini  wrote:
>> Il 08/02/2018 13:57, Richard Duivenvoorde ha scritto:
>>
>>> my 2cts: try to fix it either by fixing the code that creates the url
>>> for the  1. Help system URL (even if that would need a switch from
>>> native->qgis or so)..
>>> OR by just plain renaming those directories in the manual (2. doc URL)
>>> (as in Sphinx the links are never the the real html names, but to those
>>> ref-id's). Note that renaming files or directories means changing
>>> paths/resourcenames for transifex too.
>>>
>>> only if all fails I would start to create redirects, as in my experience
>>> these are very hard to maintain, especially when they need to work
>>> between different kind of QGIS versions
>>
>> agreed fully. as agreed upon during latest PSC meeting, the matter
>> should better be solved before Q3 release: it's such a pity having help
>> and not being able to display it to users.
>> I would ask Richard, who is familiar with the structure, to decide for
>> the best solution, and ask the most appropriate person to implement it.
>> QGIS:ORG has some limited resources to implement it if necessary.
>> Thanks again.
>
> PR at https://github.com/qgis/QGIS/pull/6298
>
> Feedback on this approach is welcome, but I think fixing in the code
> is correct vs fixing via redirects.

Just a heads-up: I've noticed while testing the above PR that while it
fixes the native/3d/qgis issue, there's an issue with how the anchor
links in the docs have been named.

E.g.

https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/database.html#import-into-spatialite

should actually be

https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/database.html#importintospatialite

Using the algorithm id and not its name. The id is unique,
non-translated, and guaranteed to be set for the lifetime of 3.x, but
algorithm names are translated, can be tweaked and refined and are not
locked.

With the above PR the help directs to the URL using an id based
anchor, so the anchors themselves in the docs should be updated to fix
this.

Nyall

>
> Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Nyall Dawson]

On 9 February 2018 at 00:20, Moritz Lennert
 wrote:
> On 08/02/18 15:08, Nikos Alexandris wrote:
>>
>> I guess, there are numerous cases like this one. What would,
>> effectively, mean a removal of external providers (in this case GRASS
>> GIS)?
>
>
> Let's make it clear once and for all: noone is speaking about the complete
> removal of external providers. The issue is where, how and by whom they
> should be maintained, i.e. within the QGIS core code base, or as plugins.
>

Yes, this is a great point. I think this discussion has got
sidetracked with some misunderstandings.

Here's the situation as I see it:


The past
---

We (the QGIS project) have struggled to keep a bunch of providers
stable and available with the base QGIS install, and the current
maintainers (Alex and Victor, others) have (understandably) struggled
with the burden of maintaining these alone and the time commitment
required to do so. Users have been frustrated by breakage which occurs
when the algorithms they depend on break due to changes in underlying
libraries for which the processing providers have not been adapted.

Despite this, I'd say overall it's worked OK-ish up to now, but
definitely with lots of room for improvement.

-
The goals
-

I think everyone involved is in agreement that processing's strength
comes when there's many providers available and it's able to tie
together processes regardless of which provider or library they come
from. So I'd say our common goals are:

1. Encourage development of as many processing providers as possible
2. Make it easy for developers to create and maintain these providers
3. Make it easy for users to be able to use the providers
4. Make everything stable and painfree for users

Any disagreements? No? Good ;)

So if we agree that those are the end goals, we should be using them
to drive this discussion.

---
The questions
---

The open, debatable questions are:

- Which is the best approach for allowing easy maintenance of
providers (*regardless* of whether the provider is maintained by the
core QGIS team or a 3rd party)? Is it keeping the code in the master
codebase and locking to QGIS releases, or publishing via plugins and
having independent release schedules? Which approach will encourage
more active maintenance of these providers and share the burden of
this maintenance?

- Who should be responsible for maintaining the providers? Should
maintenance be done by the QGIS core developer team or by 3rd parties?

- How do we make these tools available for ALL interested users? How
can we ensure that 3rd party dependencies are always available and
have a consistent feature set, regardless of which platform the user
is running? Does having the QGIS team or 3rd parties maintain the
provider help make the tools more readily available? Does having the
providers in master or plugins make the 3rd party dependencies more
readily available or not?

- How can we ensure that providers are well tested and don't break
with changes in QGIS OR from 3rd party library updates? Does having
the QGIS team or 3rd parties affect this stability? Does having the
providers in master or plugins affect this stability?

- Is it a core requirement that 3rd party providers are installed with
EVERY QGIS install, or is it acceptable to require interested users to
manually install the tools which they find useful? If the second
option is preferred, then how can we ensure that users are aware of
the availability of these tools?

- Does it make it easier for everyone involved if we just delete all
the python bindings for processing and only allow core, native, c++
algorithms, and merge all our codebases into a single unified
QGIS+SAGA+GRASS+OTB+R mega package? (I joke... ;)

This isn't an easy discussion, but please, let's keep the discussion
civil, factual, and informed, and driven by the above goals.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Analytics on plugin downloads

[Pedro Camargo]

Hi,
 As I continue the development of AequilibraE (a plugin focused on
tools for transportation modelling), I wish I had access to statistics on
who has downloaded the plugin (e.g. Google Analytics).  That would help me
see what the audience is and, hopefully, gauge better where to put efforts
on.

Is that something that other people also see as useful?  If so, is that
technically possible? Is that planned in any ways?

Cheers,
Pedro
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Server] Is QGIS Server 3 fast yet ? the 2018-02-06

[Martin Dobias]

Hi Rene-Luc

On Thu, Feb 8, 2018 at 7:58 PM, René-Luc Dhont  wrote:
>
> The problem with Apache is that the QGIS Server processes are regularly
> reset. So the QGIS Server cache is regularly cleaned, and the project is
> regularly reloaded. So the project is not loading every time a request is
> being made but some time.

Any idea why the QGIS processes are regularly reset? mod_fcgi has
config option FcgidMaxRequestsPerProcess that terminates FastCGI
process after processing certain number of requests, but that should
be zero (= disabled) by default. Then there is FcgidProcessLifeTime
option which is set to 1 hour by default, so it should not really
affect the tests.

Or is it possible that the processes crash sometimes and that is why
they are restarted?

Cheers
Martin
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Open attribute table dialog Parsingerror

[luna]

Hi,
I want update my Plugin for QGis 2.14.
My "AttributeTable" Button works but I get a Note in the upper corner:
"Parsingerror: syntax error, unexpected $end"

I don't know why because the AttributeTable pop up. But the Note is
annoying.
The sourcecode via Python is simple:
self.iface.showAttributeTable(self.iface.activeLayer())

Does somebody has any idea?
That was not the case in the previous version 2.8

Thanks
luna



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Server] Is QGIS Server 3 fast yet ? the 2018-02-06

[René-Luc Dhont]

Hi Andreas,

The problem with Apache is that the QGIS Server processes are regularly 
reset. So the QGIS Server cache is regularly cleaned, and the project is 
regularly reloaded. So the project is not loading every time a request 
is being made but some time.


I have opened an issue to have min, max and median requests time to have 
a better idea of the performances. But I have no skill in SCALA and 
Gatling to propose a PR.


It will be great to test other Web Server like Nginx/Supervisor or 
Tornado embedding QGIS Server.


Regards,
René-Luc

Le 08/02/2018 à 15:59, Andreas Neumann a écrit :


Hi René Luc,

Good points. I also had a look at these stats and was disappointed.

So I agree that it would be worth-wile working on improving the 
performance of QGIS server version 3.


On the QgsProject loading performance issue: is this only an issue at 
the first loading of the project or every time a request is being made?


Definitely I would welcome a submission at the next round of QGIS 
grants to further study the issues and improve perfomance were possible.


Thanks for your thoughts,

Andreas

On 2018-02-08 15:19, René-Luc Dhont wrote:


Hi Devs,

I have made some analyse of the performances data generated by 
CampToCamp test platform.
The data are downloadable here 
https://gmf-test.sig.cloud.camptocamp.net/ms_perfs/
And the tests are based on this docker-pull: 
https://github.com/camptocamp/ms_perfs


The QGIS Server docker used for these tests are based on the Kartoza 
one updated by CampToCamp
https://github.com/kartoza/docker-qgis-server It is based on Apache 
Server and FCGI.


The data comes from OpenStreetMap and are stored in a 
PostgreSQL/PostGIS database.
One type of request is tested, GetMap. Varoious number of 
simultaneous users and various scale

are tested.

To give an answer to the question : Is QGIS Server 3 fast yet ? , I 
only used the values for 10 simultaneous

users.

If the reference to the question is QGIS Server 2: QGIS Server 3 is 
NOT faster even with the trust option activated in the project.
QGIS Server 3 is always slower than QGIS Server 2, when only one 
layer is requested.
In the tests, QGIS Sever 3 is faster than QGIS Server 2 with 
multi-layers and complex styles.


This result can be easily explain by the new way QGIS Server is 
loaded project. QGIS Server 3 uses the QgsProject class, so all the
project : layers and layouts are loaded even if only one layer is 
requested.


About the trust project option, the results are a little bit 
disappointing. The performances are not always better than without.
For higher scale (1° by 800px), requests are slower, but for lower 
scale (0.015625° by 800px), they are faster.


Now if we consired GeoServer-jai as a reference, QGIS Server 3 is 
slower in lower sacle (0.03125° by 800px)

Now if we consired Mapserver as a reference, QGIS Server 3 is slower!

We have to test some configuration:
* disable simplify local
* change simplify max scale

Points of enhancement have to be explored :
* Faster QgsProject loading based on project parsing
* Simplify configuration at layer level
* Completing trust option

Regards,
René-Luc
* Enhance simplification

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org 
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer





___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Server] Is QGIS Server 3 fast yet ? the 2018-02-06

[René-Luc Dhont]

Hi Régis

Le 08/02/2018 à 17:12, Régis Haubourg a écrit :

Hi René Luc,
thanks a lot for starting that analysis!

Do you plan to be in Madeira? Elaborating a complete test suite 
together would be perfectly fitted for that task .


I could not be in Madeira. But we can discuss about perf test suite.



Some questions:

- Trust option is only there to not query datasource when this one has 
no metadata for PK and extent. So it should only make sense to compare 
the first getcapabilities or project load with and without trust 
option. Other following requests should not have any impact, so we 
need to make sure the platform is not measuring something else in the 
differences you note. So I don't see what you mean by "completing" the 
trust option. Can you be more explicit ?


Trust option can be usefull with Apache. When you use QGIS Server with 
Apache, the QGIS Server processes are regularly reset. So the QGIS 
Server cache is regularly cleaned, and the project is regularly 
reloaded. So the trust option can affect all the request not only 
GetCapabilities.
So the average time request is affected by trust option, but I was 
thinking that this option make QGIS Server 3 faster at all scale and 
it's not the case for high scale.
I have open an issue to request min,max, median requests time to have an 
idea of the time needed to load project.




- Is the test  platform requesting wms layer groups, and did you test 
the multithread rendering? How many cores? How many cores really 
available when testing?


The platform requesting layers, not layer groups and multithreading 
rendering has been activated. the environnment variables are:

    QGIS_SERVER_PARALLEL_RENDERING: "true"
   QGIS_SERVER_MAX_THREADS: 8



I think we should first elaborate a common reference test suite and 
couple a system monitoring at the same time to be sure we don't have 
external noise in the tests, and find system bottlenecks. Then only we 
can consider some conclusions over development priorities I think.


The platform provided by camptomcamp is a good start and some 
enhancement has been already opened :

* test GetCapabilties
* test GetFeatureInfo
* test with labels

And we have multi options to test:
* with and without multithreading
* with and without local simplification (for postgres)
* with and without data projection (here form EPSG:4326 to EPSG:3857)

And we have other server configuration to test
* Nginx/Supervisor
* Embedding QGIS Server in Tornado or other Python server



Many thanks !

Régis




Regards,
René-Luc

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Server] Is QGIS Server 3 fast yet ? the 2018-02-06

[Saber Razmjooei]

I think the performance could be related to this:
https://issues.qgis.org/issues/17809

Regards
Saber

On 8 Feb 2018 16:34, "Paolo Cavallini"  wrote:

Hi all,

Il 08/02/2018 15:59, Andreas Neumann ha scritto:

> Definitely I would welcome a submission at the next round of QGIS grants
> to further study the issues and improve perfomance were possible.

+1
merci René
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [678] Multi-distance buffer approval notification.

[noreply]

Plugin Multi-distance buffer approval by pcav.
The plugin version "[678] Multi-distance buffer 2.2.2" is now approved
Link: http://plugins.qgis.org/plugins/MultiDistanceBuffer/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Help system

[Paolo Cavallini]

Il 08/02/2018 13:57, Richard Duivenvoorde ha scritto:

> my 2cts: try to fix it either by fixing the code that creates the url
> for the  1. Help system URL (even if that would need a switch from
> native->qgis or so)..
> OR by just plain renaming those directories in the manual (2. doc URL)
> (as in Sphinx the links are never the the real html names, but to those
> ref-id's). Note that renaming files or directories means changing
> paths/resourcenames for transifex too.
> 
> only if all fails I would start to create redirects, as in my experience
> these are very hard to maintain, especially when they need to work
> between different kind of QGIS versions

agreed fully. as agreed upon during latest PSC meeting, the matter
should better be solved before Q3 release: it's such a pity having help
and not being able to display it to users.
I would ask Richard, who is familiar with the structure, to decide for
the best solution, and ask the most appropriate person to implement it.
QGIS:ORG has some limited resources to implement it if necessary.
Thanks again.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1191] Tempus approval notification.

[noreply]

Plugin Tempus approval by pcav.
The plugin version "[1191] Tempus 1.1.0" is now approved
Link: http://plugins.qgis.org/plugins/tempus_qgis/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 15:49, Nikos Alexandris ha scritto:
> * Moritz Lennert  [2018-02-08 15:20:14
> +0100]:
> 
>> On 08/02/18 15:08, Nikos Alexandris wrote:
>>> I guess, there are numerous cases like this one. What would,
>>> effectively, mean a removal of external providers (in this case GRASS
>>> GIS)?
>>
>> Let's make it clear once and for all: noone is speaking about the
>> complete removal of external providers. The issue is where, how and by
>> whom they should be maintained, i.e. within the QGIS core code base,
>> or as plugins.
> 
> 
> Thank you the heads-up Moritz.

true, but removal from core would mean the external plugin has to be
created, maintained, tested, and documented by someone. If this is
missing, the external plugin simply wil not appear. This is what
happened with R. Once a provider is out and unmaintained, it becomes
less visible, and less likely to attract attention. The work to bring it
back to life, with all the above, will be much higher than when in core,
and increasing over time.
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 13:43, Rashad Kanavath ha scritto:

> But aside all decision making stuff, can you check what is to be done in
> this PR?
> https://github.com/qgis/QGIS/pull/6272
> It is something worthy a discussion and not a plugin or not. I was
> asking because QGIS 3 is near and diff is not that big.
> If there is something extra need to be done to get this merged, I would
> happy to hear about it.

agreed, this is an important and urgent point.
please some qgis dev could check this?
thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Paolo Cavallini]

Il 08/02/2018 10:31, Rashad Kanavath ha scritto:

> I don't know what these developers are going to do with a bugfix after a
> new release. That's some kind of mystery unsolved to me.

we are doing regular point releases, an approach which has proven very
successful IMHO

> I hope there will be zero bugs after releases.

I hope you are joking :)

All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1364] UMEP approval notification.

[noreply]

Plugin UMEP approval by pcav.
The plugin version "[1364] UMEP 1.2" is now approved
Link: http://plugins.qgis.org/plugins/UMEP/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1305] Calidad-CAR approval notification.

[noreply]

Plugin Calidad-CAR approval by pcav.
The plugin version "[1305] Calidad-CAR 1.0.2" is now approved
Link: http://plugins.qgis.org/plugins/CalidadCAR/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [server] Status and Roadmap

[Paolo Cavallini]

Great news, merci Régis.
IMHO it is not important to set priorities: both standards and
performances are important, for different reasons, and implementing one
will not interfere with the other - just different actors will be involved.
I'm sure both will receive higher support from PSC and QGIS community as
a whole, especially power users.
All the best.

Il 08/02/2018 17:20, Régis Haubourg ha scritto:
> 
>>
>>  * One blocker for WFS was the performance of spatial filter, in
>> 2.x, they were not forwarded to the database when possible, and
>> implied reading the whole layer in memory before doing the spatial
>> query on the QGIS side. Anyone knows if it's still the case? 
>>
> 
> No changes here. You just have to specify a QGIS2.ini or QGIS3.ini
> to speficy this.
> René-Luc,
> 
>  
> I probably missed something. Are you refering to the taking advantage of
> the setting "Evaluate expressions on QGIS side when possible" ?
> 
> 
> Good points. OGC certification is certainly important and would help
> us market QGIS server to potential users. On the other hand - for me
> personally - improving performance to bring it at least back to the
> same level like version 2 (if not better) is of much higher priority.
> 
> Thanks for having a look at how certification may work.
> 
> Let's talk about it in Madeira.
> 
> Yep, I agree on the priorities too, we are in an estimating stage for
> Orange. I bet the thread anbout performance can push this one upper on
> the todo list :)
> Let's sprint that in Madeira.
> 
> Cheers
> Régis
> 
> 
> 2018-02-08 16:07 GMT+01:00 Andreas Neumann  >:
> 
> Hi Régis,
> 
> Good points. OGC certification is certainly important and would help
> us market QGIS server to potential users. On the other hand - for me
> personally - improving performance to bring it at least back to the
> same level like version 2 (if not better) is of much higher priority.
> 
> Thanks for having a look at how certification may work.
> 
> Let's talk about it in Madeira.
> 
> Andreas
> 
> On 2018-02-08 11:25, Régis Haubourg wrote:
> 
>> Hi all,
>>
>> As you know, QGIS server has been fully refactored for QGIS 3.
>>
>> Now some big enterprises are starting to rely on it in production
>> environment and would like to consolidate again QGIS server.
>>
>> I have some informations and questions :
>>
>>
>> # OGC certification
>>
>> I got in touch with the OGC certification team, in the aim of
>> getting official certification, since we pass all WMS 1.3.0 tests.
>> If we seek a reference implementation status on behalf of OSGEO
>> and QGIS.org, there should be no fees, that's great news.
>> The process must be renewed every year.
>> We started the online testing process here:
>> http://cite.opengeospatial.org/teamengine
>> . It's failing
>> currently, probably because of IP redirections we need to fix in
>> our reference server (the one used by the continuous integration
>> system)
>>  
>> We are asked to start evaluating WFS conformity too, but that
>> should be a bit painful since there is no API in TeamEngine to
>> make continuous integration, and online platform is not
>> responding. So I'm not confident we'll have quick results here.
>>
>> If everything goes well, I think QGIS can be certified soon! I
>> think this will be very interesting to advertise in the doc and
>> website.
>>
>> The OGC team seems really happy to see QGIS getting in the
>> certification loop, and suggest we also try to certify QGIS as a
>> client. If anyone has worked in that area, that would be nice to
>> join efforts.
>>  
>>
>> # Performance
>>
>>  * We are still interested in having performance measure reference
>> and ideally have performance driven development with a continuous
>> integration system. Yves, is there anything new on your side?
>>
>>  * One blocker for WFS was the performance of spatial filter, in
>> 2.x, they were not forwarded to the database when possible, and
>> implied reading the whole layer in memory before doing the spatial
>> query on the QGIS side. Anyone knows if it's still the case? 
>>
>>
>>
>> all the best
>> Régis
>>  
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org 
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> 
>> Unsubscribe:
>> https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> 
> 
> 
> 
> 
> 
> ___
> QGIS-Developer mailing list
> 

Re: [QGIS-Developer] [Server] Is QGIS Server 3 fast yet ? the 2018-02-06

[Régis Haubourg]

Hi René Luc,
thanks a lot for starting that analysis!

Do you plan to be in Madeira? Elaborating a complete test suite together
would be perfectly fitted for that task .

Some questions:

- Trust option is only there to not query datasource when this one has no
metadata for PK and extent. So it should only make sense to compare the
first getcapabilities or project load with and without trust option. Other
following requests should not have any impact, so we need to make sure the
platform is not measuring something else in the differences you note. So I
don't see what you mean by "completing" the trust option. Can you be more
explicit ?

- Is the test  platform requesting wms layer groups, and did you test the
multithread rendering? How many cores? How many cores really available when
testing?

I think we should first elaborate a common reference test suite and couple
a system monitoring at the same time to be sure we don't have external
noise in the tests, and find system bottlenecks. Then only we can consider
some conclusions over development priorities I think.

Many thanks !

Régis




2018-02-08 15:19 GMT+01:00 René-Luc Dhont :

> Hi Devs,
>
> I have made some analyse of the performances data generated by CampToCamp
> test platform.
> The data are downloadable here https://gmf-test.sig.cloud.
> camptocamp.net/ms_perfs/
> And the tests are based on this docker-pull:
> https://github.com/camptocamp/ms_perfs
>
> The QGIS Server docker used for these tests are based on the Kartoza one
> updated by CampToCamp
> https://github.com/kartoza/docker-qgis-server It is based on Apache
> Server and FCGI.
>
> The data comes from OpenStreetMap and are stored in a PostgreSQL/PostGIS
> database.
> One type of request is tested, GetMap. Varoious number of simultaneous
> users and various scale
> are tested.
>
> To give an answer to the question : Is QGIS Server 3 fast yet ? , I only
> used the values for 10 simultaneous
> users.
>
> If the reference to the question is QGIS Server 2: QGIS Server 3 is NOT
> faster even with the trust option activated in the project.
> QGIS Server 3 is always slower than QGIS Server 2, when only one layer is
> requested.
> In the tests, QGIS Sever 3 is faster than QGIS Server 2 with multi-layers
> and complex styles.
>
> This result can be easily explain by the new way QGIS Server is loaded
> project. QGIS Server 3 uses the QgsProject class, so all the
> project : layers and layouts are loaded even if only one layer is
> requested.
>
> About the trust project option, the results are a little bit disappointing.
> The performances are not always better than without.
> For higher scale (1° by 800px), requests are slower, but for lower scale (
> 0.015625° by 800px), they are faster.
>
> Now if we consired GeoServer-jai as a reference, QGIS Server 3 is slower
> in lower sacle (0.03125° by 800px)
> Now if we consired Mapserver as a reference, QGIS Server 3 is slower!
>
> We have to test some configuration:
> * disable simplify local
> * change simplify max scale
>
> Points of enhancement have to be explored :
> * Faster QgsProject loading based on project parsing
> * Simplify configuration at layer level
> * Completing trust option
>
> Regards,
> René-Luc
> * Enhance simplification
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Server] Is QGIS Server 3 fast yet ? the 2018-02-06

[Andreas Neumann]

Hi René Luc, 

Good points. I also had a look at these stats and was disappointed. 

So I agree that it would be worth-wile working on improving the
performance of QGIS server version 3. 

On the QgsProject loading performance issue: is this only an issue at
the first loading of the project or every time a request is being made? 

Definitely I would welcome a submission at the next round of QGIS grants
to further study the issues and improve perfomance were possible. 

Thanks for your thoughts, 

Andreas 

On 2018-02-08 15:19, René-Luc Dhont wrote:

> Hi Devs,
> 
> I have made some analyse of the performances data generated by CampToCamp 
> test platform.
> The data are downloadable here 
> https://gmf-test.sig.cloud.camptocamp.net/ms_perfs/
> And the tests are based on this docker-pull: 
> https://github.com/camptocamp/ms_perfs
> 
> The QGIS Server docker used for these tests are based on the Kartoza one 
> updated by CampToCamp
> https://github.com/kartoza/docker-qgis-server It is based on Apache Server 
> and FCGI.
> 
> The data comes from OpenStreetMap and are stored in a PostgreSQL/PostGIS 
> database.
> One type of request is tested, GetMap. Varoious number of simultaneous users 
> and various scale 
> are tested.
> 
> To give an answer to the question : Is QGIS Server 3 fast yet ? , I only used 
> the values for 10 simultaneous
> users.
> 
> If the reference to the question is QGIS Server 2: QGIS Server 3 is NOT 
> faster even with the trust option activated in the project.
> QGIS Server 3 is always slower than QGIS Server 2, when only one layer is 
> requested.
> In the tests, QGIS Sever 3 is faster than QGIS Server 2 with multi-layers and 
> complex styles.
> 
> This result can be easily explain by the new way QGIS Server is loaded 
> project. QGIS Server 3 uses the QgsProject class, so all the 
> project : layers and layouts are loaded even if only one layer is requested.
> 
> About the trust project option, the results are a little bit disappointing. 
> The performances are not always better than without.
> For higher scale (1° by 800px), requests are slower, but for lower scale 
> (0.015625° by 800px), they are faster.
> 
> Now if we consired GeoServer-jai as a reference, QGIS Server 3 is slower in 
> lower sacle (0.03125° by 800px)
> Now if we consired Mapserver as a reference, QGIS Server 3 is slower!
> 
> We have to test some configuration:
> * disable simplify local
> * change simplify max scale
> 
> Points of enhancement have to be explored :
> * Faster QgsProject loading based on project parsing 
> * Simplify configuration at layer level
> * Completing trust option
> 
> Regards,
> René-Luc
> * Enhance simplification
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] [Server] Is QGIS Server 3 fast yet ? the 2018-02-06

[René-Luc Dhont]

Hi Devs,

I have made some analyse of the performances data generated by 
CampToCamp test platform.
The data are downloadable here 
https://gmf-test.sig.cloud.camptocamp.net/ms_perfs/
And the tests are based on this docker-pull: 
https://github.com/camptocamp/ms_perfs


The QGIS Server docker used for these tests are based on the Kartoza one 
updated by CampToCamp
https://github.com/kartoza/docker-qgis-server It is based on Apache 
Server and FCGI.


The data comes from OpenStreetMap and are stored in a PostgreSQL/PostGIS 
database.
One type of request is tested, GetMap. Varoious number of simultaneous 
users and various scale

are tested.

To give an answer to the question : Is QGIS Server 3 fast yet ? , I only 
used the values for 10 simultaneous

users.

If the reference to the question is QGIS Server 2: QGIS Server 3 is NOT 
faster even with the trust option activated in the project.
QGIS Server 3 is always slower than QGIS Server 2, when only one layer 
is requested.
In the tests, QGIS Sever 3 is faster than QGIS Server 2 with 
multi-layers and complex styles.


This result can be easily explain by the new way QGIS Server is loaded 
project. QGIS Server 3 uses the QgsProject class, so all the

project : layers and layouts are loaded even if only one layer is requested.

About the trust project option, the results are a little bit 
disappointing. The performances are not always better than without.
For higher scale (1° by 800px), requests are slower, but for lower scale 
(0.015625° by 800px), they are faster.


Now if we consired GeoServer-jai as a reference, QGIS Server 3 is slower 
in lower sacle (0.03125° by 800px)

Now if we consired Mapserver as a reference, QGIS Server 3 is slower!

We have to test some configuration:
* disable simplify local
* change simplify max scale

Points of enhancement have to be explored :
* Faster QgsProject loading based on project parsing
* Simplify configuration at layer level
* Completing trust option

Regards,
René-Luc
* Enhance simplification
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] SSL cert problem WIndows: OGR or osgeo certificate install issue?

[Jeff McKenna]

Hi Richard,

(good test!)

I've tested on Windows 10 through OGR using MS4W 3.2.3, which includes 
the latest ca-cert bundle, and an updated libcurl, here are the results:


(note that by running the command "setenv.bat" it automagically sets the 
CURL_CA_BUNDLE variable)


https://gist.github.com/jmckenna/1d4d2c741236f44cc91299dd487fb647

Thanks for sharing this test.




(latest MS4W:  http://ms4w.com )

-jeff




--
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/




On 2018-02-08 6:52 AM, Richard Duivenvoorde wrote:


Can I pull some attention to:
https://issues.qgis.org/issues/17947

On windows it is not possible (both 2.18 and master) to pull a geojson
via https into QGIS.

Given REST interfaces becoming more and more popular I think this is an
important issue.

But I'm not sure if it is a OGR problem (given ogrinfo  also
fails), or it is a local windows certificate problem.
There is no problem on Linux here with me.

Tried to start a fresh config too.

Can windows people confirm if
https://duif.net/Testing_QGIS1.geojson
fails? While
http://duif.net/Testing_QGIS1.geojson
is ok?

Regards,

Richard

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [server] Status and Roadmap

[René-Luc Dhont]

Hi Régis,

My answers in the body of your email

Le 08/02/2018 à 11:25, Régis Haubourg a écrit :

Hi all,

As you know, QGIS server has been fully refactored for QGIS 3.

Now some big enterprises are starting to rely on it in production 
environment and would like to consolidate again QGIS server.


I have some informations and questions :


# OGC certification

I got in touch with the OGC certification team, in the aim of getting 
official certification, since we pass all WMS 1.3.0 tests.
If we seek a reference implementation status on behalf of OSGEO and 
QGIS.org, there should be no fees, that's great news.

The process must be renewed every year.
We started the online testing process here: 
http://cite.opengeospatial.org/teamengine. It's failing currently, 
probably because of IP redirections we need to fix in our reference 
server (the one used by the continuous integration system)


We are asked to start evaluating WFS conformity too, but that should 
be a bit painful since there is no API in TeamEngine to make 
continuous integration, and online platform is not responding. So I'm 
not confident we'll have quick results here.


If everything goes well, I think QGIS can be certified soon! I think 
this will be very interesting to advertise in the doc and website.


The OGC team seems really happy to see QGIS getting in the 
certification loop, and suggest we also try to certify QGIS as a 
client. If anyone has worked in that area, that would be nice to join 
efforts.



# Performance

 * We are still interested in having performance measure reference and 
ideally have performance driven development with a continuous 
integration system. Yves, is there anything new on your side?


I have made a first analyse and I will send an email to the mailing-list.



 * One blocker for WFS was the performance of spatial filter, in 2.x, 
they were not forwarded to the database when possible, and implied 
reading the whole layer in memory before doing the spatial query on 
the QGIS side. Anyone knows if it's still the case?




No changes here. You just have to specify a QGIS2.ini or QGIS3.ini to 
speficy this.





all the best
Régis



___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Help system

[Richard Duivenvoorde]

On 08-02-18 08:50, matteo wrote:
> Hi devs,
> 
> I want to share a super brief summary of the brainstorming we had on
> this topic. I think it is better to speak about it in Madeira with all
> the interested people.
> 
> There are some small issues with the Help system and Processing (sphinx
> related): that is, URLs build from the Help system are (sometimes)
> different from those generated from Sphinx.
> 
> Differences are:
> 
> * Help system build URL with providerId/groupId/algorithmName.html
> * provider "native" is not present in sphinx
> * Help system concatenates words (eventually) while sphinx puts `-`
> between words
> 
> At the end, for some algorithm, we have documentation already merged,
> but unreachable from the UI of Processing, e.g.:
> 
> 1. Help system URL:
> 
> https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/native/vectoroverlay.html#lineintersections
> 
> 2. doc URL:
> 
> https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/vector_overlay_tools.html#line-intersections
> 
> I hope interested people can jump in this discussion on share some thoughts!

Hi Matteo,

my 2cts: try to fix it either by fixing the code that creates the url
for the  1. Help system URL (even if that would need a switch from
native->qgis or so)..
OR by just plain renaming those directories in the manual (2. doc URL)
(as in Sphinx the links are never the the real html names, but to those
ref-id's). Note that renaming files or directories means changing
paths/resourcenames for transifex too.

only if all fails I would start to create redirects, as in my experience
these are very hard to maintain, especially when they need to work
between different kind of QGIS versions

Regards,

Richard Duivenvoorde
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Thu, Feb 8, 2018 at 11:32 AM, Victor Olaya  wrote:

>
>
>>
>> OTB's proposed solution was that plugin or provider algorithm if
>> activated can find otb installation. If not found, there is code which will
>> download and install otb packages and configure it for users.
>>
>
> I still don't see why this cannot be done if OTB provider is a separate
> plugin. Users can install a plugin with the provider, and then that
> provider can have the logic to automatically download OTB, install it, or
> do whatever is needed in case OTB is not found already installed.
>
> I think is is good to educate our users a little bit. We are talking about
> people that will be using complex algorithms for performing advanced
> analysis. I guess we can expect that they can install a plugin themselves
> and it is not a traumatic experience for them... Looks like installing a
> separate plugin it's some sort of cruel chinese torture...when it takes
> just 3 mouse clicks.
>
> I agree with Giovanni, there is no need to provide something that has
> everything installed out-of the box. Also, take into account that reading
> the files that contain the algorithm descriptions takes time (plus, there
> might be some additional checks performed when populating the toolbox).
> People not doing analysis should not have to suffer that extra loading
> time...
>

QGIS increases no of algorithms for a provider. It is simple as that. OTB
has less than 80 applications and coming to QGIS, it will be 100 or 150.
(no interest to count them in qgis)
 And OTB was reading descriptor from xml which is going to be now csv like
others.
Given all that info, I won't be surprised if it takes more time in future
because of new algorithms added to providers. If QGIS was reading proper
way or even open to accepting fixes.

The entire proposal/request to put back OTB was that decision was made on
OLD code. when the update code is there, it has less problems.
Based on concerns raised by other developers no matter if you can fix it,
they can't be put back. This single point was fueling this and other
threads.
Also discussion wasn't started with "why no providers are included?". It
was why some of them are removed even if there is an offer to help!

I don't care enough to continue this discussion about plugin or not plugin.

But aside all decision making stuff, can you check what is to be done in
this PR?
https://github.com/qgis/QGIS/pull/6272
It is something worthy a discussion and not a plugin or not. I was asking
because QGIS 3 is near and diff is not that big.
If there is something extra need to be done to get this merged, I would
happy to hear about it.


> About the R plugin not being available now...well, it's in a separate repo
> and can be adapted to QGIS 3, packaged and published. No one has taken care
> of that, it's true, but that only means we have no R support. If the R
> provider was be in core, it would mean that we would have a dead or
> malfunctioning provider being shipped with QGIS. That is a much worse
> option. And I dont see why, if someone is willing to fix that R provider,
> having it in core will make it easier.
>
> Cheers!
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Setting snapping settings via Python

[Laure-Hélène Bruneton]

Thank you so very much !!!

QgsProject.instance().writeEntry('Digitizing', '/SnappingMode', 'advanced')
QgsProject.instance().snapSettingsChanged.emit()

This did the trick for me. I'm so surprised the answer wasn't easy to
find...



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] SSL cert problem WIndows: OGR or osgeo certificate install issue?

[Richard Duivenvoorde]

Can I pull some attention to:
https://issues.qgis.org/issues/17947

On windows it is not possible (both 2.18 and master) to pull a geojson
via https into QGIS.

Given REST interfaces becoming more and more popular I think this is an
important issue.

But I'm not sure if it is a OGR problem (given ogrinfo  also
fails), or it is a local windows certificate problem.
There is no problem on Linux here with me.

Tried to start a fresh config too.

Can windows people confirm if
https://duif.net/Testing_QGIS1.geojson
fails? While
http://duif.net/Testing_QGIS1.geojson
is ok?

Regards,

Richard
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Help system

[Tom Chadwin]

If there is no easy proper fix for this, URL rewriting could handle it - I
don't know what server software is being used, but it should be possible.

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Victor Olaya]

>
> OTB's proposed solution was that plugin or provider algorithm if activated
> can find otb installation. If not found, there is code which will download
> and install otb packages and configure it for users.
>

I still don't see why this cannot be done if OTB provider is a separate
plugin. Users can install a plugin with the provider, and then that
provider can have the logic to automatically download OTB, install it, or
do whatever is needed in case OTB is not found already installed.

I think is is good to educate our users a little bit. We are talking about
people that will be using complex algorithms for performing advanced
analysis. I guess we can expect that they can install a plugin themselves
and it is not a traumatic experience for them... Looks like installing a
separate plugin it's some sort of cruel chinese torture...when it takes
just 3 mouse clicks.

I agree with Giovanni, there is no need to provide something that has
everything installed out-of the box. Also, take into account that reading
the files that contain the algorithm descriptions takes time (plus, there
might be some additional checks performed when populating the toolbox).
People not doing analysis should not have to suffer that extra loading
time...

About the R plugin not being available now...well, it's in a separate repo
and can be adapted to QGIS 3, packaged and published. No one has taken care
of that, it's true, but that only means we have no R support. If the R
provider was be in core, it would mean that we would have a dead or
malfunctioning provider being shipped with QGIS. That is a much worse
option. And I dont see why, if someone is willing to fix that R provider,
having it in core will make it easier.

Cheers!
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] [server] Status and Roadmap

[Régis Haubourg]

Hi all,

As you know, QGIS server has been fully refactored for QGIS 3.

Now some big enterprises are starting to rely on it in production
environment and would like to consolidate again QGIS server.

I have some informations and questions :


# OGC certification

I got in touch with the OGC certification team, in the aim of getting
official certification, since we pass all WMS 1.3.0 tests.
If we seek a reference implementation status on behalf of OSGEO and
QGIS.org, there should be no fees, that's great news.
The process must be renewed every year.
We started the online testing process here:
http://cite.opengeospatial.org/teamengine. It's failing currently, probably
because of IP redirections we need to fix in our reference server (the one
used by the continuous integration system)

We are asked to start evaluating WFS conformity too, but that should be a
bit painful since there is no API in TeamEngine to make continuous
integration, and online platform is not responding. So I'm not confident
we'll have quick results here.

If everything goes well, I think QGIS can be certified soon! I think this
will be very interesting to advertise in the doc and website.

The OGC team seems really happy to see QGIS getting in the certification
loop, and suggest we also try to certify QGIS as a client. If anyone has
worked in that area, that would be nice to join efforts.


# Performance

 * We are still interested in having performance measure reference and
ideally have performance driven development with a continuous integration
system. Yves, is there anything new on your side?

 * One blocker for WFS was the performance of spatial filter, in 2.x, they
were not forwarded to the database when possible, and implied reading the
whole layer in memory before doing the spatial query on the QGIS side.
Anyone knows if it's still the case?



all the best
Régis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Thu, Feb 8, 2018 at 10:15 AM, Stefan Blumentrath <
stefan.blumentr...@nina.no> wrote:

> Hi,
>
> Regarding the negative effect of algorithms getting lost I fully agree
> with you Paolo.
>
> However, it might simplify the discussion if we try separate user
> experience and development (and packaging) solutions as well as means and
> ends...
>
> Aim should be to have the different back-ends available for user in a way
> that is as straight forward as possible. From my point of view that
> includes that possibly available providers are not hidden from users who
> just install bare QGIS. If they want to activate them, but don`t have the
> backends installed (and possibly a plugin) then they should get a notice
> that they have to install them (and I don`t see a problem with installing
> provider + plugin compared to just provider).
>

OTB's proposed solution was that plugin or provider algorithm if activated
can find otb installation. If not found, there is code which will download
and install otb packages and configure it for users.


> And if that sort of user experience is guaranteed I - as a user - would
> not care about where the code is maintained (in QGIS core, in the provider
> core, or in a separate plugin). My impression is that Victors arguments for
> an out-of-core solution are very valid, esp. given effects of the
> independent release cycles of the backends and QGIS on packaging needs (at
> least for the GRASS plugin).
> The only difference I see is that additional packages would be needed for
> a plugin solution. But that is probably not too bad or even an advantage...
>
> Finally, if there is interest in keeping the processing integration alive
> (and it obviously is) having it in an independent repo should not be a show
> stopper. Only negative effect I can see is that this produces additional
> repos, where access rights have to be managed. But that should not be a
> major issue either...
>
> Cheers
> Stefan
>
> P.S.: Just a pity that this discussion starts after medspx just put down
> all this work:
> https://github.com/qgis/QGIS/pull/5603
> https://github.com/qgis/QGIS/pull/5968
> https://github.com/qgis/QGIS/pull/5426
>
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
> Paolo Cavallini
> Sent: torsdag 8. februar 2018 09.04
> To: G. Allegri 
> Cc: qgis-developer ;
> saga-gis-develo...@lists.sourceforge.net; grass-dev <
> grass-...@lists.osgeo.org>; Victor Olaya 
> Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
>
> Hi all,
> I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
> for serious, comprehensive GIS analysis work. Full stop.
> Missing one specific alg, even if not used daily, means having to switch
> to other software.
> We have already removed R provider: even if used by a tiny minority, and
> certainly not perfect, the previous situation was better than the current
> one, without the option of using R from QGIS.
> I think we have to be extra cautious on this ground.
> All the best.
>
> Il 07/02/2018 19:07, G. Allegri ha scritto:
>
> > - from my experience - comprising years of feedbacks from the courses
> > I teach - the most frequently used algs are available within the GDAL
> > and QGIS algs list
> >
> > - a few generic and widely used algs are from GRASS and SAGA. We would
> > miss them - out of the box - but it could also be an opportunity to
> > port them. For examples v.to.points, transects, profiles.
> > Anyway we would have the plugins for GRASS and SAGA, in case...
> >
> > - specific algs are for specialized users. Here I think plugins are
> > best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added
> > to the list, consistently with the others approach.
> >
> > I appreciate a lot the work from Richard, I hope this discussion is
> > not understood as to belittle its effort!
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[G. Allegri]

What I ment is that, from my perspective, we shouldn't seek to make QGIS a
do-it-all software by default, because the GIS/EO/RS/Data Analysis fields
are so wide that, from that point of view, everything could go into QGIS
and it would be an overwhelmin experience for users.
Any generic sw I know offers extensions, plugins, for specialized use
cases.  From my experience a user prefers few tools that match their needs,
instead of digging into a long list of (mostly) obscure algs...

Anyway, I don't want to stress on this...
Giovanni

2018-02-08 10:15 GMT+01:00 Stefan Blumentrath :

> Hi,
>
> Regarding the negative effect of algorithms getting lost I fully agree
> with you Paolo.
>
> However, it might simplify the discussion if we try separate user
> experience and development (and packaging) solutions as well as means and
> ends...
>
> Aim should be to have the different back-ends available for user in a way
> that is as straight forward as possible. From my point of view that
> includes that possibly available providers are not hidden from users who
> just install bare QGIS. If they want to activate them, but don`t have the
> backends installed (and possibly a plugin) then they should get a notice
> that they have to install them (and I don`t see a problem with installing
> provider + plugin compared to just provider).
>
> And if that sort of user experience is guaranteed I - as a user - would
> not care about where the code is maintained (in QGIS core, in the provider
> core, or in a separate plugin). My impression is that Victors arguments for
> an out-of-core solution are very valid, esp. given effects of the
> independent release cycles of the backends and QGIS on packaging needs (at
> least for the GRASS plugin).
> The only difference I see is that additional packages would be needed for
> a plugin solution. But that is probably not too bad or even an advantage...
>
> Finally, if there is interest in keeping the processing integration alive
> (and it obviously is) having it in an independent repo should not be a show
> stopper. Only negative effect I can see is that this produces additional
> repos, where access rights have to be managed. But that should not be a
> major issue either...
>
> Cheers
> Stefan
>
> P.S.: Just a pity that this discussion starts after medspx just put down
> all this work:
> https://github.com/qgis/QGIS/pull/5603
> https://github.com/qgis/QGIS/pull/5968
> https://github.com/qgis/QGIS/pull/5426
>
> -Original Message-
> From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of
> Paolo Cavallini
> Sent: torsdag 8. februar 2018 09.04
> To: G. Allegri 
> Cc: qgis-developer ;
> saga-gis-develo...@lists.sourceforge.net; grass-dev <
> grass-...@lists.osgeo.org>; Victor Olaya 
> Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS
>
> Hi all,
> I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
> for serious, comprehensive GIS analysis work. Full stop.
> Missing one specific alg, even if not used daily, means having to switch
> to other software.
> We have already removed R provider: even if used by a tiny minority, and
> certainly not perfect, the previous situation was better than the current
> one, without the option of using R from QGIS.
> I think we have to be extra cautious on this ground.
> All the best.
>
> Il 07/02/2018 19:07, G. Allegri ha scritto:
>
> > - from my experience - comprising years of feedbacks from the courses
> > I teach - the most frequently used algs are available within the GDAL
> > and QGIS algs list
> >
> > - a few generic and widely used algs are from GRASS and SAGA. We would
> > miss them - out of the box - but it could also be an opportunity to
> > port them. For examples v.to.points, transects, profiles.
> > Anyway we would have the plugins for GRASS and SAGA, in case...
> >
> > - specific algs are for specialized users. Here I think plugins are
> > best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added
> > to the list, consistently with the others approach.
> >
> > I appreciate a lot the work from Richard, I hope this discussion is
> > not understood as to belittle its effort!
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 6:25 PM, Paolo Cavallini 
wrote:

> Il 07/02/2018 11:18, Victor Olaya ha scritto:
> > I dont see the advantage in having providers in core.
>
> I see the following:
> * tests (already available in our infrastructure)
> * translations
> * more exposure
> * documentation
>
> > And if there is an
> > advantage, it's clearly not in how easy it is going to be to maintain
> > the plugin.
>
> until now it has been maintained somehow; if more resources are needed,
> we can find a way
>
> > If the people responsible of a given backend (like OTB) are
> > going to maintain it (which makes sense), why putting it in core where
> > they don't have write access?
>
> why not granting them write access?
>
That would still need users *waiting* for QGIS release for fix in algo is
what I understood from other parts of discussion.
I don't know what these developers are going to do with a bugfix after a
new release. That's some kind of mystery unsolved to me.
I hope there will be zero bugs after releases.


>
> > Better in a separate repo. Also, they can
> > release whenever there are changes, without having to wait for a new
> > release. That way, the plugin will always be in sync with new releases
> > of the backend app.
>
> this is certainly true; AFAICT OTB people has proposed a solution


> > If we put them in core...why putting only this big ones (which in some
> > cases require installing external apps manually by the user), and not
> > put other plugins that exist and contain Processing providers?
>
> I'd be in favour of adding anything important for users.
>
> Thanks for your thoughts.
>
> When in Madeira we can have a discussion about this. It would be good if
> all interested parties could meet, locally and remotely.
>
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Stefan Blumentrath]

Hi,

Regarding the negative effect of algorithms getting lost I fully agree with you 
Paolo.

However, it might simplify the discussion if we try separate user experience 
and development (and packaging) solutions as well as means and ends...

Aim should be to have the different back-ends available for user in a way that 
is as straight forward as possible. From my point of view that includes that 
possibly available providers are not hidden from users who just install bare 
QGIS. If they want to activate them, but don`t have the backends installed (and 
possibly a plugin) then they should get a notice that they have to install them 
(and I don`t see a problem with installing provider + plugin compared to just 
provider).

And if that sort of user experience is guaranteed I - as a user - would not 
care about where the code is maintained (in QGIS core, in the provider core, or 
in a separate plugin). My impression is that Victors arguments for an 
out-of-core solution are very valid, esp. given effects of the independent 
release cycles of the backends and QGIS on packaging needs (at least for the 
GRASS plugin).
The only difference I see is that additional packages would be needed for a 
plugin solution. But that is probably not too bad or even an advantage...

Finally, if there is interest in keeping the processing integration alive (and 
it obviously is) having it in an independent repo should not be a show stopper. 
Only negative effect I can see is that this produces additional repos, where 
access rights have to be managed. But that should not be a major issue either...

Cheers
Stefan

P.S.: Just a pity that this discussion starts after medspx just put down all 
this work:
https://github.com/qgis/QGIS/pull/5603
https://github.com/qgis/QGIS/pull/5968
https://github.com/qgis/QGIS/pull/5426

-Original Message-
From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Paolo 
Cavallini
Sent: torsdag 8. februar 2018 09.04
To: G. Allegri 
Cc: qgis-developer ; 
saga-gis-develo...@lists.sourceforge.net; grass-dev 
; Victor Olaya 
Subject: Re: [GRASS-dev] [QGIS-Developer] External providers in QGIS

Hi all,
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable for 
serious, comprehensive GIS analysis work. Full stop.
Missing one specific alg, even if not used daily, means having to switch to 
other software.
We have already removed R provider: even if used by a tiny minority, and 
certainly not perfect, the previous situation was better than the current one, 
without the option of using R from QGIS.
I think we have to be extra cautious on this ground.
All the best.

Il 07/02/2018 19:07, G. Allegri ha scritto:

> - from my experience - comprising years of feedbacks from the courses 
> I teach - the most frequently used algs are available within the GDAL 
> and QGIS algs list
> 
> - a few generic and widely used algs are from GRASS and SAGA. We would 
> miss them - out of the box - but it could also be an opportunity to 
> port them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
> 
> - specific algs are for specialized users. Here I think plugins are 
> best suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added 
> to the list, consistently with the others approach.
> 
> I appreciate a lot the work from Richard, I hope this discussion is 
> not understood as to belittle its effort!

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
grass-dev mailing list
grass-...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [GRASS-dev] External providers in QGIS

[Rashad Kanavath]

On Wed, Feb 7, 2018 at 7:07 PM, G. Allegri  wrote:

> I'm much more in favour for out of core providers, for the same reasons
> reported by Victor. Having only GDAL and QGIS algorithms in core will
> reduce the number of available algorithms out of the box, but:
>
> - from my experience - comprising years of feedbacks from the courses I
> teach - the most frequently used algs are available within the GDAL and
> QGIS algs list
>

Do you have these toolboxes installed during training? OTB, SAGA, GRASS
etc..
OTB is focused on remote sensing. Unless you have a training or course that
area, your statistics on them being not needed is pretty unreliable. Don't
you think?
What QGIS uses to run a classification/segmentation algorithm without OTB
and GRASS GIS.


> - a few generic and widely used algs are from GRASS and SAGA. We would
> miss them - out of the box - but it could also be an opportunity to port
> them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
>
> - specific algs are for specialized users. Here I think plugins are best
> suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
> list, consistently with the others approach.
>
> I appreciate a lot the work from Richard, I hope this discussion is not
> understood as to belittle its effort!
>
> my 2 cents...
> Giovanni
>
> Il 7 feb 2018 18:25, "Paolo Cavallini"  ha scritto:
>
>> Il 07/02/2018 11:18, Victor Olaya ha scritto:
>> > I dont see the advantage in having providers in core.
>>
>> I see the following:
>> * tests (already available in our infrastructure)
>> * translations
>> * more exposure
>> * documentation
>>
>> > And if there is an
>> > advantage, it's clearly not in how easy it is going to be to maintain
>> > the plugin.
>>
>> until now it has been maintained somehow; if more resources are needed,
>> we can find a way
>>
>> > If the people responsible of a given backend (like OTB) are
>> > going to maintain it (which makes sense), why putting it in core where
>> > they don't have write access?
>>
>> why not granting them write access?
>>
>> > Better in a separate repo. Also, they can
>> > release whenever there are changes, without having to wait for a new
>> > release. That way, the plugin will always be in sync with new releases
>> > of the backend app.
>>
>> this is certainly true; AFAICT OTB people has proposed a solution
>>
>> > If we put them in core...why putting only this big ones (which in some
>> > cases require installing external apps manually by the user), and not
>> > put other plugins that exist and contain Processing providers?
>>
>> I'd be in favour of adding anything important for users.
>>
>> Thanks for your thoughts.
>>
>> When in Madeira we can have a discussion about this. It would be good if
>> all interested parties could meet, locally and remotely.
>>
>> All the best.
>> --
>> Paolo Cavallini - www.faunalia.eu
>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> grass-dev mailing list
> grass-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/grass-dev
>



-- 
Regards,
   Rashad
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] External providers in QGIS

[Paolo Cavallini]

Hi all,
I disagree heartily: without GRASS and SAGA QGIS is currently unsuitable
for serious, comprehensive GIS analysis work. Full stop.
Missing one specific alg, even if not used daily, means having to switch
to other software.
We have already removed R provider: even if used by a tiny minority, and
certainly not perfect, the previous situation was better than the
current one, without the option of using R from QGIS.
I think we have to be extra cautious on this ground.
All the best.

Il 07/02/2018 19:07, G. Allegri ha scritto:

> - from my experience - comprising years of feedbacks from the courses I
> teach - the most frequently used algs are available within the GDAL and
> QGIS algs list
> 
> - a few generic and widely used algs are from GRASS and SAGA. We would
> miss them - out of the box - but it could also be an opportunity to port
> them. For examples v.to.points, transects, profiles.
> Anyway we would have the plugins for GRASS and SAGA, in case...
> 
> - specific algs are for specialized users. Here I think plugins are best
> suited (OTB, R, TauDEM, etc.). Tomorrow a new sw could be added to the
> list, consistently with the others approach.
> 
> I appreciate a lot the work from Richard, I hope this discussion is not
> understood as to belittle its effort!

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer