Re: [QGIS-Developer] [Qgis-psc] QGIS budget 2023 RFC

[Vincent Picavet (ml) via QGIS-Developer]

Hi Andreas, all,

On 24/11/2022 16:09, Andreas Neumann wrote:
[..]

We did not really discuss the hourly rates at the budget meeting.
From 2021 to 2022 we raised the hourly dev rates from 100 to 110 -
and the hourly documentation rates from 40 to 44. I know that both
rates are low. We can discuss raising them again.


My question was general, and actually includes all prices. I have no definite 
opinion on this topic, as it can be complicated given the disparity of 
inflation according to what price we are talking about, and also geographically 
speaking.


The plan for the two positions was not to have direct employees of
QGIS.ORG <http://QGIS.ORG>, but to use a proxy company, in our case
Kartoza, to act as the employer. Also - our budget does not allow
regular European or North-American salaries. With these limitations
at hand, we can use Kartoza as a proxy to hire employees in certain
parts of the world where the salaries we can offer can be attractive
- and where they have talented people to work on some of our issues
(sysadmin, documentation, etc.)


I have very mixed feelings about this, and it raises lots of questions we 
definitely have to clear out before establishing any process.

- Using a proxy company is very similar to me than having direct employees, if 
these positions have no clear limits of time and perimeter
- Using a proxy company instead of direct employees can be considered illegal 
according to local legislation. I do not know for Swiss law.
- How was Kartoza selected ? Was there an open process for other companies to 
apply ? Who decided and on what criteria ? The fact that the company owned by a 
member of QGIS PSC is selected is a big red flag for me, if the process is not 
fully transparent and fair for others.
- "our budget does not allow European or North-American salaries" : see below 
for the budget volume comments. But I have very mixed feelings about this statement : it 
sounds exactly like social dumping. I do not know what would be fair to select employees, 
and I recognize it to be a complex issue, but in some ways it does not feel right.
 

For the documentation part: Tim and Harrissou are involved in the
selection process of the candidates.


Is the process and selection committee documented somewhere ?


I agree that the grant budget with 10k is not very attractive. We
also discussed skipping it for one year. Not sure what is better ...

BTW: you can all help to find new sustaining members ... that would
increase our budget and would allow us to pay better hourly rates
...

I wish we had a larger budget at hand than the +/- 200k € we seem to
be able to attract each year. From certain countries where we know we
have a lot of QGIS users (France, Italy - just to name two of them)
there are not a lot of sustaining members or donations other than
from a few private persons and very small companies. Maybe companies
like yours could help us to get in touch with the larger companies
with a lot of QGIS users that could become new sustaining members ...
Do you think that would be possible?


First of all, complaining that our budget is too low is definitely not the way 
to consider the problem : QGIS.org budget will, by definition, **always** be 
too low compared to what we could need. Developing a software and managing a 
community is a boundless task and you can always find tasks and work packages 
to spend all the money you can imagine of.

I agree that QGIS.org could attract more sustaining members. I just hope you 
are not accusing Oslandia of not doing our job of proselitysm, QGIS community 
support, communication and globally QGIS.org and QGIS software contributions. 
We do our part for sure.

... And this is not the point, as I said the question I raise is not how to 
increase our budget, since the exact same issues will araise with a larger 
budget.

The questions are :
- A/ how do we use our existing budget for most important things to support
- B/ what our decisions processes are, where are they documented, and are they 
clear, transparent and fair

As for A, one of my take is that seeing the grant budget disappear this year is 
a pity, especially seeing other amounts dedicated to documentation for example.

As for B, I consider that there is a lot of progress to do to make recent 
decisions and actions clean and trustworthy.

Should we want to attract new sustaining members giving money to QGIS.org, we 
must have an exemplary behaviour in how we decide how to use this money.

Vincent




Andreas

On Thu, 24 Nov 2022 at 15:05, Vincent Picavet (ml) via QGIS-Developer
mailto:qgis-developer@lists.osgeo.org>> wrote:

Hello,

Thanks for sharing the budget with the community.

A few questions / remarks : - in most countries, we can see a general
inflation, having consequences on every kind of costs ( hosting,
salaries…). Did you take this context into account when preparing the
budget, especially when basing planned 2023 costs on actual 2022
cost

Re: [QGIS-Developer] [Qgis-psc] QGIS budget 2023 RFC

[Vincent Picavet (ml) via QGIS-Developer]

Hello,

Thanks for sharing the budget with the community.

A few questions / remarks :
- in most countries, we can see a general inflation, having consequences on 
every kind of costs ( hosting, salaries…). Did you take this context into 
account when preparing the budget, especially when basing planned 2023 costs on 
actual 2022 costs ?
- the cut on Grant budget is really hard. With a "reasonable" mean budget of 5K 
per grant, this would mean 2 grants only this year. It sounds more or less like the end 
of the grant program. Who would candidate if chances to be selected are really low ? 
Wouldn't there be a way to mitigate it a bit, through various smaller budget reductions 
to other budget lines ? The increase in documentation contribution is huge compared to 
the grant decrease. I fear that we loose grants as a mean to attract new core developers.

My most important remark is about "allow for a regular small salary .. for one person on each 
item". Disclaimer : I am quite strongly against QGIS.org having employees. If we are in the 
process of having "regular workers" for qgis.org, then we really have to work hard on :
- having a clear, written and transparent process for how to select these people
- .. process including a fair way for anyone to candidate
I may have missed some communications, but I have not seen this in place up to 
now. This is definitely something we have to put in place before having some 
internal troubles.

Best regards,
Vincent

On 24/11/2022 12:07, Marco Bernasocchi wrote:

Hi all, we prepared the QGIS budget for 2023 and would like to have
feedback before submitting it to the voting members for approval. You
can directly leave comments in the file [1].

Please let us have any Feedback until December 4th. On december 7th
we'll send the budget for vote.

Cheers Marco

[1]
https://docs.google.com/spreadsheets/d/1WyoZCKOehNhU5YB4pFPOuiJbie1mUmMPiq8YW7qyez0/edit?usp=sharing


 -- Marco Bernasocchi

QGIS.org Chair OPENGIS.ch CEO http://berna.io 

___ Qgis-psc mailing
list qgis-...@lists.osgeo.org 
https://lists.osgeo.org/mailman/listinfo/qgis-psc


___
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] ECW flags

[Vincent Picavet (ml)]

Hi Walter,

Be careful with ECW SDK licence, which requires an OEM licence for any use in a
Server software component.

See for example :
https://community.hexagongeospatial.com/t5/APOLLO-ECW-Q-A/License-for-reading-or-writing-ECW-in-third-party-software/ta-p/34074#

This may have changed since 2019, but I doubt it.

In any case, I would rather recommend using an alternate format, with free and
opensource format and drivers.

Best regards,
Vincent

On 23/01/2021 16:21, Walter Lorenzetti wrote:
> Thanks Jurgen.. I'd like to listem something different :(
> 
> So I've to compile it :(
> 
> W
> 
> Il 23/01/21 16:12, Jürgen E. Fischer ha scritto:
>> Hi Walter,
>>
>> On Sat, 23. Jan 2021 at 16:02:13 +0100, Walter Lorenzetti wrote:
>>> a question: QGIS-server 3.10.14 for Ubuntu it was compile with ECW flags or
>>> not?
>> By default qgis server is built with SERVER_SKIP_ECW TRUE for debian/ubuntu 
>> and
>> in osgeo4w.
>>
>>
>> Jürgen
>>
> -- 
> 
> Walter Lorenzetti phD
> email: lorenze...@gis3w.it
> skype: aiki74
> twitter:w_lorenzetti 
> g+:aiki74 
> Tel/Cell: (+39) 347-6597931
> Viale Verdi 24 - 51016 Montecatini Terme (PT)
> Nuovi corsi QGIS e GFOSS 
> 
> 
> 
> ___
> 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] Plugin licensing requirements

[Vincent Picavet (ml)]

Hi,

On 07/01/2021 10:43, Nyall Dawson wrote:
> On Thu, 7 Jan 2021 at 19:13, Topi Tjukanov  wrote:
[..]
>> So if this really is a requirement, should this be enforced somehow and
>> checked when plugins are accepted to the official repository?
> 
> Agreed, but keep in mind that it's a little tricky sometimes. A plugin ONLY
> has to make the modules which import QGIS classes GPL (and consequently any
> other modules which import these modules). It is entirely possible to
> separate plugins into two isolated components, a non-GPL "core" layer which
> does NOT use any QGIS modules, and a GPL layer which imports both the QGIS
> modules and the non-gpl core. (This is how the licensed SLYR plugin works,
> for reference).

I would not bet any cent on these assertions. Would you have any serious
references supporting this ?

The GPL licence makes the code "viral" through the notion of "link". For Python
module, it is through import. A link is bidirectionnal, and therefore your whole
package if distributed is considered GPL.

As far as I know, the only way to have a GPL/proprietary coexistence is to have
distinct processes and inter-process communication ( through files, web
interfaces... ). And it can be even trickier if there are strong dependencies
between modules, which can be interpreted as "derived product" or "link", even
if there is no link as in "library link" between the modules.

Best regards,
Vincent


> 
> So to enforce this in some circumstances you'd need to check file-by-file,
> which is going to be time-consuming.
> 
> Nyall
> 
> 
>> 
>> Kind regards, Topi Tjukanov Gispo Oy 
>> ___ 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 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 manual

[Vincent Picavet (ml)]

Hi all,

On 21/04/2020 18:03, Paolo Cavallini wrote:
>
>
> Il 21/04/20 17:41, Gerald Kogler ha scritto:
>> © 2020 Oslandia.
>>
>> Maybe I should ask them to donate this post to QGIS Documentation? Or
>> better to make a short resume and link to their post?
>
> I think the first option is preferable

Thanks you for pointing out potential IP rights.

I hereby give you the right to freely to use the content of this blog article
for any documentation. Consider the article under CC-0 licence, so that it will
fit any doc licence.

You can credit us somewhere, it will be welcome, but not mandatory.

Thank you for your documentation efforts !

Best regards,
vincent



___
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] [Qgis-psc] Position on Qt wrt The QT Company announcements

[Vincent Picavet (ml)]

Hi,

On 09/04/2020 22:39, Even Rouault wrote:
[..]
> But whatever the outcome of the apparently cool discussions within the board 
> of
> the KDE Free Qt foundation between the KDE e.v and QT Company 
> representatives, I
> don't think a statement of support from QGIS.org to the open source side of 
> the
> QT project would hurt.

+1 to this too

> As far as which body to officially support, this is a bit difficult. As the
> board of the KDE Free Qt foundation is made of 2 representatives from KDE e.V
> and 2 from The QT Company, it seems difficult to imagine that it would 
> continue
> to exist as such, or be still relevant, in the event The QT company would
> execute their 12-month-delay plan. And before financially supporting the KDE
> Free Qt foundation or whatever other body would represent best the interests 
> of
> a FOSS QT (I guess a new body gathering together KDE, KDAB and all other 
> parties
> would be more relevant in the event a FOSS QT fork would be needed), we should
> probably have a look at its current finances/budget (from a quick search,
> couldn't find one regarding KDE Free Qt foundation, apart from the 200 000 KRO
> founding capital mentionned in their status [1])

Thanks for raising this point, this would indeed be something to look at
carefully. I agree in case of a fork, the governance model would be transformed,
and I hope the new organization and related awaited transparency would make the
financing choice easy to do.

But we are not there yet.

I also agree with Nyall that technically, impacts on QGIS would not necessarily
be big. Having a more open Qt project, with easier contributions and bugfixing
could help QGIS though.
But generally speaking QGIS, as a big and successful opensource project, now
also has the responsibility to voice opinions and defend Opensource / libre
software models of organization whenever they are at stake in its ecosystem.

It seems like this is a good time to do it.

Best regards,

Vincent
___
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] Position on Qt wrt The QT Company announcements

[Vincent Picavet (ml)]

Hi all, PSC,

Olaf Schmidt-Wishhöfer from KDE project has made a statement yesterday about a
really concerning situation regarding the OpenSource state of Qt.

https://mail.kde.org/pipermail/kde-community/2020q2/006098.html

TL;DR : using the argument of COVID-19 crisis, The Qt Company wants to restrict
a lot the opensource version of Qt, with a 12 months publishing delay even for
security patches.


Relations between The Qt Company and the OpenSource community degraded vastly
over the last month, and what was a balanced governance and economical situation
tends towards a stuck situation, with all OpenSource Qt users at risk of being
deeply affected.

The KDE Free Qt foundation is currently the organization defending free and
opensource access to Qt.

https://kde.org/community/whatiskde/kdefreeqtfoundation.php

Given that QGIS is probably one of the most distributed Qt-based software
solution in the world, I think that we should take position in this situation.

My Opinion is that QGIS.org should clearly express a full support to the KDE
Free Qt Foundation, and send them an official public message.

I also think that if the situation evolves to a point where a Qt Fork becomes
the only viable solution to continue to have a free and opensource Qt project
with a balanced and open governance, then QGIS.org should also contribute to
financing the KDE Free Qt foundation yearly, so that they are able to hire
maintainers for the library.

I think that these points are decisions to be made by the PSC, and that there is
a certain urgency to do it.

Best regards,
Vincent Picavet
___
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] Pointcloud install for Travis ?

[Vincent Picavet (ml)]

Hello,

On 28/11/2019 14:23, Sandro Santilli wrote:
> On Thu, Nov 28, 2019 at 01:54:58PM +0100, Sandro Santilli wrote:
[..]
> 
> A docker image with pointcloud would be oslandia/pggis which
> is sourced in Vincent's github space:
> https://github.com/vpicavet/docker-pggis
> That one is more generally aimed at being a "gis" oriented
> database, but was not touched for 4 years, so not sure it is
> a good candidate.>
> Vincent (in Cc): are you still interested in maintaining
> that project ? I see a pr from you is pending since June,
> and is adding PostgreSQL 11 and PostGIS 2.5, as the ones
> QGIS currently uses from the kartoza image...

Sorry I missed the thread.. There is a version18 branch, with up-to-date
components. Not merged into master yet, but tested and ready to use.

No problem to use it, and the maintenance burden on this docker image is
light, so I can try to keep it updated with latest versions, or custom
ones on a qgis branch if necessary.

> I've given Vincent's image a try as part of my PR
> https://github.com/qgis/QGIS/pull/33118

Keep me posted if you need help, and if your tests are ok, I can merge
version18 into master.

Best regards,
Vincent

___
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] On github, gitlab, and imperialist nations screwing us all over...

[Vincent Picavet (ml)]

Hi Nyall, all,

On 01/08/2019 06:26, Nyall Dawson wrote:
> Well, I've got to say upfront that we WERE warned about the dangers of
> this happening by members of our community, and now the worst IS
> happening and Github has started blocking access to projects from
> certain regions.
> 
> See https://www.linuxinsider.com/story/86154.html, but long story
> short, GitHub is now blocking users in Crimea, Cuba, Iran, North Korea
> and Syria from accessing its services to comply with U.S. trade
> control laws. I'm unsure if we're directly affected yet by this, but
> the wording on Github's notice is very vague: " GitHub MAY allow users
> in or ordinarily resident in countries and territories subject to U.S.
> sanctions to access CERTAIN free GitHub.com services for PERSONAL
> COMMUNICATIONS " (emphasis added by me).
> 
> What can/should we do in response to this?

While the impact of this decision is still very minor for us right now,
as you say it is a very good illustration on how putting us in a vendor
lock-in situation is bad.

I would say that it is not too late to re-work on a self-hosted GitLab
instance, which would be more future-proof. That would need a great deal
of efforts though, and would require specific funding for the
forthcoming non-funny tasks.

At Oslandia, we would be willing to help, if it is the path chosen by
the community.

A Git mirror would be great of course, but does not solve the full problem.

And personally, this kind of attack against free information and
knowledge is a concern, for sure.

Best regards,
Vincent

> 
> Note that it ALSO applies to gitlab.com, who are also subject to the
> same trade laws, so moving to gitlab ISN'T a possible solution (unless
> we self-host).
> 
> I think at the least we could/should endorse an official, read-only
> repo mirror which isn't affected by the trade laws, e.g.
> https://git.osgeo.org/gitea/qgis/QGIS would be a great candidate
> (unless osgeo is also affected by the same ruling, which they could
> easily be, given that they are US based too) . An official mirror
> would at least ensure that users in these regions can access the
> existing source.
> 
> Does this development concern anyone else?
> 
> 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 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] FOSS4G CFP proposals around QGIS

[Vincent Picavet (ml)]

Hello,

On 15/04/2019 13:48, Andreas Neumann wrote:
> Thanks Vincent.
> 
> What would be the content of a "State of QGIS" talk? It would obviously
> not be possible to present all improvements in QGIS from the past year.
> Would this be more like a "behind the scenes" talk where mainly issues
> around community, organization, infrastructure, challenges we face, etc.
> would be discussed?

No idea, I just read this comment from the CfP :

"""
FOSS4G is the international geospatial community’s event, thus the main
selection of talks will be done through the open community voting
process. The highest-scored ones will automatically be included in the
program, while the others will be reviewed by the FOSS4G 2019 Bucharest
volunteer Program Committee. Its members will make sure that the
conference program will be well-balanced, diverse and they will make
sure that every OSGeo project will have a “State of ” kind of presentation.
"""

As for features, Marco's presentation will be relevant. It may be
interesting to have something more project-oriented to have a general
overview, with QGIS.ORG status, project dynamics, etc.

We can also ask the program committee to know exactly what they would
want to hear.

Regards,
Vincent


> 
> Good to see that you will cover server/web client.
> 
> I had a quick exchange with Lutra regarding a 3D and mesh workshop.
> Obviously this would overlap with your 3D with Postgis and QGIS
> workshop. Would it still make sense to submit two proposals?
> 
> Greetings,
> Andreas
> 
> On 2019-04-15 12:22, Vincent Picavet (ml) wrote:
> 
>> Hello Andreas,
>>
>> On 15/04/2019 12:17, Andreas Neumann wrote:
>>> Today is the last day submitting workshop and presentation proposals.
>>>
>>> I wonder who/what was already submitted, so I could potentially help to
>>> fill in gaps?
>>>
>>> I could submit something around "tips with layouts/atlas/reports"
>>> (including usage of variables and expressions).
>>>
>>> How about
>>>
>>>   * QGIS server improvements (OGC validation, etc.)
>>>   * Behind the scenes of QGIS.ORG (it was presented in Dresden at
>>> FOSSGIS by Anita and in A Coruna by myself; but I think not yet at a
>>> FOSS4G conf)
>>>   * QGIS 3D (Lutra-guys - are you participating?)
>>>
>>> How about doing a workshop around 3D and mesh rendering?
>>
>> We have submitted these talks ( or nearly ;-) related to QGIS :
>> - Running QGIS Server in production
>> - OS Tools for geology based on QGIS and PostGIS
>> - (no title yet) : a talk about QGIS adoption, market maturity and
>> evolution of the project
>>
>> And the following workshops :
>> - 3D in PostGIS and QGIS
>> - QGIS Server and QWC2
>>
>> I have read that the LOC wants talks "State of XXX" for all OSGeo
>> projects. Has someone already submitted a "State of QGIS" talk ?
>>
>> Best regards,
>> Vincent
>>
> 

___
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] FOSS4G CFP proposals around QGIS

[Vincent Picavet (ml)]

Hello,

On 15/04/2019 13:55, Saber Razmjooei wrote:
> @Vincent Picavet  could you let us
> know if your workshop is about QGIS 3d, so we can submit another
> proposal for mesh layer?

No mesh layer in our proposed workshop. We only deal with 3D objects
supported by PostGIS. QGIS is used to visualize results of PostGIS
queries with 3D operators, and we will probably show a tour of QGIS 3D
capabilities to start with.

Regards,
Vincent

> 
> Thanks
> Saber
> 
> 
> On Mon, 15 Apr 2019 at 12:50, Alessandro Pasotti  > wrote:
> 
> 
> Hi
> 
> I submitted a workshop proposal about QGIS Server and Python.
> 
> Basically the same I did in La Coruña.
> 
> 
> On Mon, Apr 15, 2019 at 12:17 PM Andreas Neumann
> mailto:a.neum...@carto.net>> wrote:
> 
> Hi,
> 
> Today is the last day submitting workshop and presentation
> proposals.
> 
> I wonder who/what was already submitted, so I could potentially
> help to fill in gaps?
> 
> I could submit something around "tips with
> layouts/atlas/reports" (including usage of variables and
> expressions).
> 
> How about
> 
>   * QGIS server improvements (OGC validation, etc.)
>   * Behind the scenes of QGIS.ORG  (it was
> presented in Dresden at FOSSGIS by Anita and in A Coruna by
> myself; but I think not yet at a FOSS4G conf)
>   * QGIS 3D (Lutra-guys - are you participating?)
> 
> How about doing a workshop around 3D and mesh rendering?
> 
> Thanks for your replies and greetings,
> 
> Andreas
> 
> ___
> 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
> 
> 
> 
> -- 
> Alessandro Pasotti
> w3:   www.itopen.it 
> ___
> 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
> 
> 
> 
> -- 
> Saber Razmjooei
> www.lutraconsulting.co.uk 
> +44 (0)7568 129733
> 
> ___
> 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] FOSS4G CFP proposals around QGIS

[Vincent Picavet (ml)]

Hello Andreas,

On 15/04/2019 12:17, Andreas Neumann wrote:
> Today is the last day submitting workshop and presentation proposals.
> 
> I wonder who/what was already submitted, so I could potentially help to
> fill in gaps?
> 
> I could submit something around "tips with layouts/atlas/reports"
> (including usage of variables and expressions).
> 
> How about
> 
>   * QGIS server improvements (OGC validation, etc.)
>   * Behind the scenes of QGIS.ORG (it was presented in Dresden at
> FOSSGIS by Anita and in A Coruna by myself; but I think not yet at a
> FOSS4G conf)
>   * QGIS 3D (Lutra-guys - are you participating?)
> 
> How about doing a workshop around 3D and mesh rendering?

We have submitted these talks ( or nearly ;-) related to QGIS :
- Running QGIS Server in production
- OS Tools for geology based on QGIS and PostGIS
- (no title yet) : a talk about QGIS adoption, market maturity and
evolution of the project

And the following workshops :
- 3D in PostGIS and QGIS
- QGIS Server and QWC2

I have read that the LOC wants talks "State of XXX" for all OSGeo
projects. Has someone already submitted a "State of QGIS" talk ?

Best regards,
Vincent

___
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] Anyone have ci setup for a QGIS plugin on GitLab?

[Vincent Picavet (ml)]

Hello Nyall,

On 21/10/2018 11:34, Nyall Dawson wrote:
> I'm wondering if anyone's aware of any QGIS plugins which are hosted
> on gitlab which have a CI workflow setup.
> 
> There's quite a number of plugins which have this on github/Travis
> infrastructure (using the available QGIS docker containers) which are
> easy to use as a template, but I'm not able to find any similar
> existing setups for gitlab CI.
> 
> Can anyone point me toward any?

On GitLab.com there are at least these ones using CI/CD pipelines :
https://gitlab.com/mst-gko/qupiter
https://gitlab.com/mst-gko/grukos
https://gitlab.com/iac/occfinder/pipelines

FYI, MST-GKO is the Danish Environmental Protection Agency for
Groundwater Mapping.

Best regards,

Vincent

___
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] Last call for switching to github issue tracker

[Vincent Picavet (ml)]

Hello,

A bit late to the party, and I think for such an important matter it is
good to wait a bit to hear more voices.

I have mixed feelings about switching to a new issue manager without the
history for QGIS3, and will not argue here for a specific roadmap.


But I think the GitHub vs GitLab debate in case of switching is still open.

On 18/01/2018 18:34, Denis Rouzaud wrote:
>> What is next?
>> A loomio vote for this?
>
> So I would suggest raising a vote on the motion:
>
> “We should adopt GitHub issues for reporting issues in 3.0 and
> restrict Redmine for the management of issues in QGIS 2.x”.
>
>
> Great. Will you take care of it?
>
>

I would rather tend to go to GitLab for the following reasons :
- interface quite similar to GitHub
- login on GitLab.com is possible with a GitHub account
- (personal opinion) much more pleasant to use than GitHub
- Full OpenSource Community edition ( no vendor lock-in)
- Faster development than GitHub
- Much better CI management

Concerning last point, we are currently working at Oslandia on GitLab CI
for QGIS on Windows, and generally for OSGeo4W packages, in order to be
able to deliver better packages for QGIS and related softwares.

There is still a lot to do, but we see GitLab as being much more
powerful than GitHub in this area, and it would be much easier to
publish our CI work for the community if QGIS were hosted on GitLab.

Regards,

Vincent




> After there are no more active 2.x releases, we make the Redmine
> tracker read only and keep it around as an archive. We could put
> into the GitHub issue template: “Only use this tracker for 3.x
> related issues” and similar message on Redmine indicating that it
> should only be used for 2.x issues. It will unfortunately leave us
> in the position where you need to check to issue trackers for your
> issue which is going to suck a bit.
> 
> Regards
> 
> Tim
> —
> 
> 
> KartozaNewLogoThumbnail.jpg
> 
> 
> 
> 
> *Tim Sutton*
> 
> *Co-founder:* Kartoza
> *Project chair:* QGIS.org 
> 
> Visit http://kartoza.com  to find out about
> open source:
> 
> Desktop GIS programming services
> Geospatial web development
> GIS Training
> Consulting Services
> 
> *Skype*: timlinux 
> *IRC:* timlinux on #qgis at freenode.net 
> 
> 
> 
> ___
> 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] QGIS 3D: looking below the terrain model

[Vincent Picavet (ml)]

Hello,

On 14/12/2017 08:02, Andreas Neumann wrote:
> Hi Nyall,
> 
> nice that we agree on both ;-)
> 
> I will start collecting a wish-list on 3D and we can do a crowd funding
> to address selected issues. Or we could do another QGIS grant on 3D
> improvements.

I would rather spend QGIS.ORG money on important bugfixing for QGIS 3.
QGIS Grant applications should be directed to the work nobody wants to
fund initially, or for proof-of-concept or kickstart of new features.

I have no doubt we will find people and organizations willing to fund
features for 3D improvement.

Regards,

Vincent

> 
> Andreas
> 
> On 2017-12-13 23:06, Nyall Dawson wrote:
> 
>> On 14 December 2017 at 00:31, Andreas Neumann > > wrote:
>>
>>> However, one issue I have is that the terrain rendering disappears when I
>>> look below the terrain model surface - which isn't so nice for a caver or
>>> geologist. Is this also an issue about culling? Would it be possible to
>>> enable the rendering of the backside of the terrain surface?
>>
>> I agree that this is desirable. Geotechs will also very quickly be
>> demanding this feature in order to visualise boreholes correctly!
>>
>>> The other issue I have is that tilting is somehow locked at the
>>> horizon. I
>>> can look down on the terrain and then rotate the whole model until I look
>>> sideway into the model, but than the rotation is blocked. I cannot rotate
>>> any further so that my camera gets below the surface and that I could
>>> move
>>> below the surface and look up towards the terrain. I guess this makes
>>> a lot
>>> of sense for people who do not need to explore things below the terrain
>>> surface, but for geologists or cavers, it would be great if this
>>> rotation/tilting blocking could be disabled somehow.
>>
>> I'd suggest this should be an option in the 3d view configuration. I
>> agree it's a valid use case, but for most users it may be unwanted.
>>
>> 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 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] QgsServer and 3d tiles

[Vincent Picavet (ml)]

Hello,

On 09/11/2017 16:49, G. Allegri wrote:
> Hi Vincent,
> I agree tiled static data can, and should, be served as static content
> but what I meant was having something like Tilestache, GeoWebCache,
> MapCache, etc.. They're meant to render and cache on the fly, or
> preseeding the tileset.
> 
> My question raised from the fact that QGIS 3D renderer could be a common
> base to produce terrain meshes (a la Cesium) and 3D tiles, both for the
> desktop 3D viewer and for a cached tileset to be served through HTTP.

I would rather have a dedicated terrain mesh generator first, which
could be embedded in QGIS 3D later on. Generating a terrain mesh is a
data processing action, not a rendering one. We should tackle the
problem in this order, or we will end up with code less efficient and
less generic.

> QgsServer could use the same code base to populate the cache, but this
> doesn't prevent having a Processing tool (ore whatever) doing the work
> in advance.

I think we agree on the general issue, but have a different point of
view on the design process. We should converge at some point :-)

> You're working with gltf. What about OGC I3S?

I3S is, like other examples, a standard pushed by ESRI for ESRI
products. It has been designed by ESRI and pushed forward to OGC
community standard in a desire not to adopt 3D tiles.
I do not say that I3S is a bad technical standard. But it is just
another effort from ESRI to favor its own specific formats instead of
collaborating on a real "community" standard.

It is therefore not a strong incentive to dedicate efforts for an
opensource implementation.
If there was funding for it, we could implement it too, as the
specifications are open. But priority goes to 3DTiles as far as we are
concerned.

Regards,
Vincent




> 
> giovanni
> 
> Il 9 nov 2017 16:29, "Vincent Picavet (ml)" <vincent...@oslandia.com
> <mailto:vincent...@oslandia.com>> ha scritto:
> 
> Hello,
> 
> On 03/11/2017 21:04, G. Allegri wrote:
> > What if we had a QgsServer service dedicates to serving 3d tiles for
> > Cesium or iTowns?
> > Is anybody working on this?
> 
> At Oslandia, we work on 3D topics a lot, and 3d tiles in particular. We
> are implementing 3D Tiles support in iTowns, and several components to
> serve this format as webservices.
> 
> E.g. :
> - https://github.com/Oslandia/building-server
> <https://github.com/Oslandia/building-server>
> - https://github.com/Oslandia/lopocs
> <https://github.com/Oslandia/lopocs>
> 
> I do not think having QGIS Server serving 3D tiles is a really good
> idea.
> 
> First, 3D tiles is a format ( and protocol) to serve tiles of objects in
> a mostly static way. Therefore, what would be interesting is for QGIS to
> have a way to export data as 3d Tiles. These tiles can then be served
> with a simple HTTP server, no need for a QGIS Server component.
> 
> Moreover, there are a lot of use cases where we want to serve 3D Tiles
> without using QGIS at all. Component-oriented architecture is better
> than monolithic software.
> 
> What I see as best approach would be to mutualize as much code as
> possible regarding 3D tiles in py3dtiles :
> https://github.com/Oslandia/py3dtiles
> <https://github.com/Oslandia/py3dtiles>
> 
> Using this module, we can write a 3dtile exporter, as a Processing
> module for example. We already have some draft code to do that for some
> data sets.
> Then, we could have an independant 3D tiles server reusing py3dtiles, or
> integrate this as QGIS Server module if we want.
> 
> We would be happy to work on these subjects and share our experience on
> all 3D-related topics. Funding is also very welcome.
> 
> But for now, I think we should focus on releasing QGIS3 in a usable
> state. We have waited for too long, and there is still work to achieve
> to stabilize the release.
> 
> 3D features can wait a bit more, even if call for interest, needs,
> funding and collaboration is welcome.
> 
> Best regards,
> Vincent
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> <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] QgsServer and 3d tiles

[Vincent Picavet (ml)]

Hello,

On 09/11/2017 16:49, G. Allegri wrote:
> Hi Vincent,
> I agree tiled static data can, and should, be served as static content
> but what I meant was having something like Tilestache, GeoWebCache,
> MapCache, etc.. They're meant to render and cache on the fly, or
> preseeding the tileset.
> 
> My question raised from the fact that QGIS 3D renderer could be a common
> base to produce terrain meshes (a la Cesium) and 3D tiles, both for the
> desktop 3D viewer and for a cached tileset to be served through HTTP.

I would rather have a dedicated terrain mesh generator first, which
could be embedded in QGIS 3D later on. Generating a terrain mesh is a
data processing action, not a rendering one. We should tackle the
problem in this order, or we will end up with code less efficient and
less generic.

> QgsServer could use the same code base to populate the cache, but this
> doesn't prevent having a Processing tool (ore whatever) doing the work
> in advance.

I think we agree on the general issue, but have a different point of
view on the design process. We should converge at some point :-)

> You're working with gltf. What about OGC I3S?

I3S is, like other examples, a standard pushed by ESRI for ESRI
products. It has been designed by ESRI and pushed forward to OGC
community standard in a desire not to adopt 3D tiles.
I do not say that I3S is a bad technical standard. But it is just
another effort from ESRI to favor its own specific formats instead of
collaborating on a real "community" standard.

It is therefore not a strong incentive to dedicate efforts for an
opensource implementation.
If there was funding for it, we could implement it too, as the
specifications are open. But priority goes to 3DTiles as far as we are
concerned.

Regards,
Vincent




> 
> giovanni
> 
> Il 9 nov 2017 16:29, "Vincent Picavet (ml)" <vincent...@oslandia.com
> <mailto:vincent...@oslandia.com>> ha scritto:
> 
> Hello,
> 
> On 03/11/2017 21:04, G. Allegri wrote:
> > What if we had a QgsServer service dedicates to serving 3d tiles for
> > Cesium or iTowns?
> > Is anybody working on this?
> 
> At Oslandia, we work on 3D topics a lot, and 3d tiles in particular. We
> are implementing 3D Tiles support in iTowns, and several components to
> serve this format as webservices.
> 
> E.g. :
> - https://github.com/Oslandia/building-server
> <https://github.com/Oslandia/building-server>
> - https://github.com/Oslandia/lopocs
> <https://github.com/Oslandia/lopocs>
> 
> I do not think having QGIS Server serving 3D tiles is a really good
> idea.
> 
> First, 3D tiles is a format ( and protocol) to serve tiles of objects in
> a mostly static way. Therefore, what would be interesting is for QGIS to
> have a way to export data as 3d Tiles. These tiles can then be served
> with a simple HTTP server, no need for a QGIS Server component.
> 
> Moreover, there are a lot of use cases where we want to serve 3D Tiles
> without using QGIS at all. Component-oriented architecture is better
> than monolithic software.
> 
> What I see as best approach would be to mutualize as much code as
> possible regarding 3D tiles in py3dtiles :
> https://github.com/Oslandia/py3dtiles
> <https://github.com/Oslandia/py3dtiles>
> 
> Using this module, we can write a 3dtile exporter, as a Processing
> module for example. We already have some draft code to do that for some
> data sets.
> Then, we could have an independant 3D tiles server reusing py3dtiles, or
> integrate this as QGIS Server module if we want.
> 
> We would be happy to work on these subjects and share our experience on
> all 3D-related topics. Funding is also very welcome.
> 
> But for now, I think we should focus on releasing QGIS3 in a usable
> state. We have waited for too long, and there is still work to achieve
> to stabilize the release.
> 
> 3D features can wait a bit more, even if call for interest, needs,
> funding and collaboration is welcome.
> 
> Best regards,
> Vincent
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> <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] QgsServer and 3d tiles

[Vincent Picavet (ml)]

Hello,

On 03/11/2017 21:04, G. Allegri wrote:
> What if we had a QgsServer service dedicates to serving 3d tiles for
> Cesium or iTowns?
> Is anybody working on this?

At Oslandia, we work on 3D topics a lot, and 3d tiles in particular. We
are implementing 3D Tiles support in iTowns, and several components to
serve this format as webservices.

E.g. :
- https://github.com/Oslandia/building-server
- https://github.com/Oslandia/lopocs

I do not think having QGIS Server serving 3D tiles is a really good idea.

First, 3D tiles is a format ( and protocol) to serve tiles of objects in
a mostly static way. Therefore, what would be interesting is for QGIS to
have a way to export data as 3d Tiles. These tiles can then be served
with a simple HTTP server, no need for a QGIS Server component.

Moreover, there are a lot of use cases where we want to serve 3D Tiles
without using QGIS at all. Component-oriented architecture is better
than monolithic software.

What I see as best approach would be to mutualize as much code as
possible regarding 3D tiles in py3dtiles :
https://github.com/Oslandia/py3dtiles

Using this module, we can write a 3dtile exporter, as a Processing
module for example. We already have some draft code to do that for some
data sets.
Then, we could have an independant 3D tiles server reusing py3dtiles, or
integrate this as QGIS Server module if we want.

We would be happy to work on these subjects and share our experience on
all 3D-related topics. Funding is also very welcome.

But for now, I think we should focus on releasing QGIS3 in a usable
state. We have waited for too long, and there is still work to achieve
to stabilize the release.

3D features can wait a bit more, even if call for interest, needs,
funding and collaboration is welcome.

Best regards,
Vincent
___
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] Plans for next QGIS releases

[Vincent Picavet (ml)]

Hi Paolo,

Please excuse me if I missed something, but I am quite surprised, not by
the decisions themselves, but the process of these decisions.

I have seen no call for meeting, no message to the list to gather
advices, no mention to voting members neither of this IRC meeting happening.
The topic is really important and has deep consequences for all of our
users, funders, developers. The least we can do is ask them for their
advice and feedback. This kind of autocratic top-bottom decisions is
definitely not the way I would expect the QGIS community to behave.

Sorry for the rant, and again I may have missed something ( but I
re-checked all emails from PSC, dev and users ML, my #qgis logs, and saw
nothing). Let's keep the community involved in decision processes and
take care about how we communicate together, please.

Vincent

On 20/02/2017 11:17, Paolo Cavallini wrote:
> Hi all,
> during a fast and productive IRC meeting today we have come out with a
> proposal for the management of current and future versions of QGIS:
> 
> * retire 2.14 in June 2017
> * 2.18 becomes LTR from June 2017 to 2018
> * 3.0 feature freeze in July 2017
> * release 3.0 in Sept 2017
> * release 3.2 as next LTR in release 3.0 + 4 Months (eta June 2018).
> 
> Of course we know that some of you will have different preferences and
> constraints, but we believe this is the best compromise we can reach
> now. Please let us know if you have strong opposition to this, or good
> argument to change. Nothing is carved in stone, but it will be good to
> give our users and devs a perspective on what they can expect.
> 
> All the best.
> 

___
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] Discussion on the QGIS grant proposals

[Vincent Picavet (ml)]

On 22/09/2016 12:15, Paolo Cavallini wrote:
[..]
> 
> One other important point: the reason I originally proposed the grant
> programme was to recognize the huge volunteer work several people are
> donating to the project, and to help keeping their motivation high.
> 
> My suggestion is therefore to prioritize the projects by the people you
> feel/know have contributed most to the project until now.

I disagree with this. A grant application is meant to give money for a
certain work. The background of the person applying for a grant has to
be taken into account for selection, for sure. But the grant itself
should be related to a work, and not to previous contributions.

If we want to recognize volunteer work and previous donations to the
project, then let's create a "QGIS contributor of the year prize" with a
dedicated amount of money offered, and vote for one every year. This
would be a nice way to keep people motivated.
But misusing a grant for work in this sense seems unfair to me.

Vincent
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] standard way for custom plugin python dependencies

[Vincent Picavet (ml)]

Hi,


On 22/09/2016 14:43, Alessandro Pasotti wrote:
> On Thu, Sep 22, 2016 at 2:37 PM, Akbar Gumbira  > wrote:
[..]
> @Jachym: AFAIK, most plugins now just ship the needed libraries
> along with it or ask the users to install them. There are some
> libraries that are already shipped into QGIS from the core python
> plugins (e.g jinja), you might want to check if what you need is
> there already.
> 
> A new metadata (external_deps: text) field was introduced for this
> purpose but there is nothing implemented inside QGIS for now:
> https://github.com/qgis/QGIS-Django/commit/6546a2ab54fd01b6e94b921b610c31b619e99979#diff-536e872043014a84818f87dc640b2d4d
> 
> A common pattern seems shipping dependencies with the plugin as Python eggs.

New Python Wheels and Pypi now support binary packages. This becomes a
really useful and convenient tool to install dependencies, with
multi-platform support, without even having a compiler installed.

Making QGIS Python plugins as Python modules would allow to use all pip
and pypi insfrastructure really easily.

The proposed osgeo4w grant application by Jef could include the low
level required changes necessary to introduce this behaviour. Right now
pip is distributed by default in OSGeo4w, but since not all OSGeo4w
python modules are installed through pip (but through specific exe
installers), this may lead to installation problems ( names conflicts e.g.).

If this work is done, there still will be some work on the QGIS python
plugin interface, but _not_ reimplementing a package management system
in QGIS and use pip instead could be a good option.

Regards,
Vincent
> 
>  
> 
> On Sep 22, 2016 19:14, "Matthias Kuhn"  > wrote:
> 
> Hi Jachym,
> 
> Unfortunately not. This has been discussed and is something that
> will
> certainly be added at some point but so far nobody implemented it
> (basically because of its cross-platform nature I think).
> 
> Your possibilities are:
> 
>  * Document and print nice warnings
>  * Ship the dependency packaged with your plugin
>  * Fix it by adding dependency management in QGIS
> 
> Cheers
> Matthias
> 
> On 09/22/2016 02:08 PM, Jachym Cepicky wrote:
> > Hi all,
> >
> > we've developed an (python) plugin for QGIS, which is somehow
> using
> > (among others) nice "requests" python library. We use it the
> standard way
> >
> > import requests
> >
> > But when we distributed the plugin to other computers, it
> turned out,
> > they do not have it installed.
> >
> > Is there any standard way, how to distribute dependencies
> along with
> > python plugin? Something in metadata.txt? Some requirements file?
> >
> > Thanks
> >
> > Jachym
> >
> >
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> 
> > List info:
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> > Unsubscribe:
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> >
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> 
> List info:
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> Unsubscribe:
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org 
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> 
> 
> -- 
> Alessandro Pasotti
> w3:   www.itopen.it 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: 

Re: [Qgis-developer] Discussion on the QGIS grant proposals

[Vincent Picavet (ml)]

Hello,

Thanks Andreas for raising this topic and clearing up facts and giving
your position.
I agree 100% with what you stated, and I do think this is something
which should be emphasized much more, if not even constrained.

Some more notes below.

On 22/09/2016 08:14, Neumann, Andreas wrote:
> [..] Now comes my personal position/opinion - note that this is not
> the official opinion of the QGIS.ORG board.
Same here

> I would personally welcome, if this round of the QGIS grants program 
> could focus on the QGIS 3.0 release.

This is indeed the main challenge for QGIS in the coming months.
Focusing on all aspects of making QGIS3 a real thing should be our top
priority when confronted to choices.

> I personally also think that the QGIS grants program, at least at
> the current time, should not pay for development of new features (at
> least not features visible in the GUI for the users). These features
> can be "relatively easy" funded by companies and government
> organizations out there. So our limited QGIS.ORG funds should be
> rather spent a) to community work or b) infrastructure work or c)
> development work in the core of QGIS, such as API modifications, code
> redesign - stuff that isn't really visible to the users, but
> essential for the success of the project.

From a developer's company point of view, I can only applause to this.
We have numerous demands for new features with paid contract, and the
global pace of feature development in QGIS is really fast. The very
large majority of them are funded by clients.
Meanwhile, all tasks like refactoring, code cleaning, bug triaging,
infrastructure and long term core development efforts are really
difficult to get funded. Public sector organization generally can't pay
for this due to public tender bid constraints, and generally end-users
do not realize that this kind of work is at the same time necessary and
time consuming.
In my opinion, the role of QGIS organization, hence the QGIS Grant
program, is to compensate for this disequilibrium.

> Documentation and PyQT documentation work is already budgeted in our 
> annual budget. The money for 2016 hasn't even been spent for both
> items. So I think we should first use the budgeted money for such
> work. I think that user and developer documentation should be an
> ongoing effort and should be supported every year, und budgeted every
> year as such. We can increase the documentation budget positions next
> year, should it be necessary. In reality, it was more a lack of
> people willing to do the work, rather than a lack of funding. So, I
> am happy to see some proposals around documentation and developer
> documentation - so it seems that we have some volunteers. I just
> suggest that we consider documentation work separately and do it
> anyway - regardless of the outcome of the voting on these items.

Documentation is crucial, and I am also fully in favor of having a
dedicated yearly budget to improve it. It should be stated in the QGIS
grant application call too.

> Several proposals have a very limited local focus, only useful to
> one single country, or a very limited subset of our users. I suggest
> that such proposals could best be financed by local user groups or
> interest groups. It can't be the purpose of the QGIS grants program
> to finance such projects.

+1 also

Since I have more or less the same priority list as Andreas, I will also
add a few comments below.

> ---
> 
> Here is my own personal list of priorities:

In my own priority order :

> ​11)​ Introduce everything necessary for QGIS3 to OSGeo4W
> 
> The majority of our users are on Windows (like it or not). This is
> the platform that matters most in our user base. The introduction of
> QGIS 3.0 means porting everything to newer libraries and means a lot
> of work. This should be one of our main priorities. Jürgen does it
> works silently in the background many days of work each year that go
> unnoticed. Jürgen usually only hears complaints if something fails -
> maybe not so much praise. Having Windows nightly builds and releases
> early on in the life cycle of QGIS 3.x means that it can be well
> tested. So - also really important to our project.

This is to me the most important item for QGIS3. Jef does a huge work,
something difficult and not the most passionating thing to work on. We
do need to have the platform stable and ready as soon as possible to
have feedback on QGIS 3 very early in the release process.

> ​18)​ QGIS 3 ticket handling and API refactoring
> 
> This is really time critical, and past discussions around QGIS 3.0
> has shown that there is a lack of project management work and
> coordination. I regard this proposal as very useful for the QGIS 3.0
> release.

Disclaimer : This proposal is by Oslandia
We proposed this item exactly because we observed that we were lacking
project management efforts, and especially regarding the QGIS3 release.
Having time 

Re: [Qgis-developer] issue move to gh stalled

[Vincent Picavet (ml)]

Hello,

Just a note to say that SAC is currently testing an OSGeo GitLab
instance. It is on a temporary server, but may be used freely and can be
used for testing and migration purpose.

What is currently lacking is not setup time, but instead :
* a decision from OSGeo's community on what we do want to use as a
modern software hosting platform
* a maintainance team
* a better server for the definitive setup

I think that if QGIS is willing to migrate to GitLab, using this
opportunity to join forces with current SAC effort would be great.
CCed to Bjorn and Sandro who currently lead the testing effort.

You can already give it a try here (latest GitLab version) :
https://git.osgeo.org/gitlab/

Vincent

Just a On 27/08/2016 13:47, Tudor Barascu wrote:
> Hi all,
> 
> I am volunteering to install, do maintenance if you'll go the gitlab
> way. I would have said this from the start but I didn't notice that such
> a discussion was taking place. I am positive that I would manage this I
> have good enough experience with system administration and I'm actually
> maintaning a gitlab private instance for about 2 years now.
> Although I can manage it on my own it would be very nice if somebody
> else would also be involved.
> I can also help with migrating the issues from redmine to gitlab.
> 
> Regards,
> Tudor
> 
> PS. I think gitlab would be the better option
> 
> 
> On Saturday, August 27, 2016 12:00 PM, Andreas Neumann
>  wrote:
> 
> 
> Hi Denis,
> We had a look at hosted solutions (for Gitlab and for Redmine) - but
> most of them had been too expensive for our case - they have a limit on
> the number of users that can be associated with a project, or other
> limits like file sizes/total project size, etc.
> Running our own gitlab instance would have been an option, but no one
> volunteered to take on the task of permanently maintaining the
> infrastructure, e.g. dealing with security issues/patching/upgrading,
> spammers, deal with the evil guys out on the web. Maybe if we can find
> someone who wants to take on the task (ideally more than one person), we
> could reconsider to use a self-hosted gitlab.
> Note that the new Redmine instance has some integration with github.
> Jürgen, Richard or Pirmin can tell you the details.
> 
> What is so bad with Redmine? And exactly what integration with github
> are you missing? Maybe Redmine can do this integration.
> 
> Andreas
> 
> Am 26.08.2016 um 23:03 schrieb Denis Rouzaud:
>> Hi all,
>> Being part of the unhappy, I would like to ask if you have considered
>> running our own gitlab instance or using a gitlab service?
>> To me integrated solution should be a hard requirement.
>> If we have to maintain something like Redmine, why not gitlab. It
>> seems you can categorize issues.
>> Denis
>>
>> Le ven. 26 août 2016 22:24, Andreas Neumann > > a écrit :
>>
>> Hi,
>>
>> The issue tracker was discussed almost 1.5h at the board meeting - and
>> it wasn't a clear and unanimous decision. Some board members
>> (including
>> me) also changed their minds during the discussion. Apparently not all
>> core devs were happy with the quite limited filtering and structuring
>> options that github offers. The issue tracker is certainly quite
>> limited, compared to other issue tracker offerings. Offering only
>> labels
>> is quite limited. In addition, migrating all the existing tickets from
>> Redmine to Github turned out to be non-trivial - and we don't want to
>> loose the old issues.
>>
>> Finally, it is probably good that we are in control of the issues and
>> that it runs on free software. The board knows that not all people are
>> happy with this decision but one cannot make everyone happy ... we
>> hope
>> that the "unhappy" people can still live with the renewed (and faster)
>> Redmine.
>>
>> The issues are migrated to the newest Redmine version and on a
>> dedicated
>> machine rented by QGIS.ORG  to ensure good
>> performance. This should make
>> dealing with issues much more pleasant and more performant.
>>
>> Big thanks to Jürgen, Richard and Pirmin for dealing with the Redmine
>> migration.
>>
>> Andreas
>>
>> Am 26.08.2016 um 22:08 schrieb Marco Bernasocchi:
>> > .
>> >
>> >
>> >> I was under the impression that we were leaning towards to
>> migrating
>> >> to GH issues tracker.
>> >> What was the main reason behind choosing Redmine again? technical
>> >> issues? lack of time to solve them? Will the migration to a new
>> >> Redmine version be effortless?
>> >>
>> > Me too. I'm still convinced that this is a _very_ sub optimal
>> solution for everybody.
>> > Pity we really want to stick with something that forces us
>> continuing having two different, non integrated tools where one
>> could have done it in a great way.
>>   

Re: [Qgis-developer] Moving towards QGIS3?

[Vincent Picavet (ml)]

Hi,

Thanks Paolo for raising this.

I do think we should :
- set a definite release objective for 3.0 ( date / content)
- minimize the risk of not reaching this goal

On 23/08/2016 16:34, Paolo Cavallini wrote:
> Hi all,
> reading the list at:
> https://github.com/qgis/qgis3.0_api/issues
> it seems to me that some items have already been addressed, some maybe
> even fixed. Could you confirm which ones are still valid?

This list is a good start for gathering what is needed for 3.0. It is
named QGIS3_api, so I imagine that it only contains modifications we
want in the API ? It would be good to have a full list of things we want
to have for 3.0.

> Should we prioritize the remaining items, or redefine them as
> necessary|useful|nice to have, so we know the minimum set to complete
> for 3.0 release?

It would be great if we could :
- have a full list of things we would like to see in 3.0, and especially :
  - API breaks
  - Code refactoring
- Then qualify them as necessary/useful/nice to have, discussing in the
tickets whenever assigned labels are not trivial to set or not everybody
agrees
- Then get an approximation of time/funding needed for necessary issues
(at least these ones)
- ...so that we can secure funding for the necessary issues ( at least).
Maybe through the Grant Program or QGIS.org funds ?
- ...so we can communicate with confidence on a 3.0 release date

First steps are to be done by the developers, the sooner the better.
How does that sound to you ? seems doable ? Nice way to proceed ? Do we
have alternative strategies ?

We do need to have a clear communication on the 3.0, and be confident in
it. I do think releasing in Feb. 2017 is doable, but we should state
this, so that users can be prepared, and developers continue to work
towards this aim.
If we have a better idea of the effort needed, then we can improve our
developement efforts, our (own) funding effort, and improve external
fundraising if needed.

My 2 cents,

Vincent



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Report 5 - QGIS Symbology Sharing Tools

[Vincent Picavet (ml)]

Hello,


On 27/06/2016 12:41, Matthias Kuhn wrote:
> On 06/27/2016 11:32 AM, Akbar Gumbira wrote:
>> Thanks for the feedback. Unfortunately raw URL is only provided for a
>> single file, not a directory.
> 
> Couldn't all the files be downloaded individually?
> This will result in a couple of additional requests, but I'm not sure
> this is something to worry about.
> The main question would then be, where the client could retrieve the
> file list (paths relative). Generating this list could be part of the
> upload script.

I may be late to the party, but I really do not get the point of using
git here for data retrieval.
And furthermore, I wouldn't want QGIS to have a hard dependency on git,
which is a developer tool users are not supposed to have installed by
default.

If you want to focus on the client part of the feature and not implement
a resource server, maybe a simpler approach would be better for a start.

Why not having a metadata file (JSON or XML) listing the resources
provided by the repository, and then the raw files at specified urls.
All of this served by a bare HTTP server, no more no less.
If some want to manage versioning of the resources and use github for
that, they can use the site generation tool (github pages) to do so.
Easy and lightweight. Or if we do not want to depend on a proprietary
platform, just generate the metadata+data files on any HTTP hosting
platform.
And we can later write a full resource server in our language of choice
to dynamically serve resources and metadata.

My 2 cents, sorry if this has been discussed before.

Vincent

> 
>> As one repository could have many
>> collections (collection is a directory containing resources), with git
>> protocol, there are 2 ways downloading a single collection from a
>> repository: git sparse checkout and git archive. Sparse checkout is not
>> supported in Dulwich nor in Pygit2 (a Python wrapper using libgit2). And
>> with the 2nd option, Github doesn't allow git archive.
>>
>> One other alternative (which I am exploring now) is to clone a
>> repository the first time user downloads a collection from that
>> repository, and next time user downloads other collections from that
>> repository, we just need to update and pull that repository. This is
>> more efficient compared to downloading the whole repository (using zip
>> url) every time user wants to download a collection.
> 
> Is the plan to mainly have users create their own repositories (and then
> manually enter the path to them in the style manager - or have a
> repository of repositories :) )?
> Or to have one main repository with many collections (like currently
> with the plugins)?
> 
> If it's the first, I wouldn't care too much about the couple of extra
> bytes downloaded.
> If it's the second, that may result in some huge download and disk space
> consumption caused by one or a few collections.
> 
> Cheers
> Matthias
> 
>>
>> We came to the decision that one repository could have many collections
>> in the first place as it doesn't make sense  (we thought) for users to
>> create one repository only for one collection.
>>
>> Cheers
>>
>> On Sun, Jun 26, 2016 at 7:50 PM, Matthias Kuhn > > wrote:
>>
>> Hi Akbar,
>>
>> thanks a lot for the update, I especially liked the video, this makes it
>> a lot easier for the audience (at least me :) ) to get an impression of
>> the status quo. Good job so far!
>>
>> Concerning dulwich, did you checkout the #dulwich IRC channel and the
>> mailing list which are mentioned in the project's readme [1] ?
>>
>> What exactly are the efficiency problems you are referring to? Maybe
>> it's also worth looking into downloading individual files over http
>> instead of the whole .zip file (raw.githubusercontent.com
>> ), that also
>> allows doing partial downloads if you don't need a complete repository
>> and you know which files you want.
>>
>> Looking forward to hearing more of this project, keep up the good work!
>>
>> Matthias
>>
>> [1] https://github.com/jelmer/dulwich#help
>>
>> On 06/26/2016 07:10 PM, Akbar Gumbira wrote:
>> > Hi,
>> >
>> > I made a video of the progress so
>> > far: https://www.youtube.com/watch?v=OmJ2Vh3a63U
>> >
>> >
>> > *What did you get done this week?*
>> >
>> >   * Saving the metadata of the collections to local as a cache (after
>> > some operations like adding/removing/deleting repository) so that
>> > when user doesn't have internet, (s)he will still be able to browse
>> > collection.
>> >   * Filtering collections with custom QSortFilterProxyModel to allow
>> > filtering based on author, name, description, etc.
>> >   * Fix unicode problem (The problem is when parsing the metadatafile.
>> > Using ConfigParser it was read as str. Changed it to
>> > SafeConfigParser with 

Re: [Qgis-developer] QGIS compiling with Qt5 and Python3 on Debian

[Vincent Picavet (ml)]

Hello,

On 26/05/2016 19:31, Paolo Cavallini wrote:
> Hi all,
> I was finally able to compile, install, and run (thanks Matthias!) the
> above on a clean virtual machine. I've added the list of necessary
> packages to the INSTALL doc in master. Others please try and report.
> In case someone would need it, I can upload the VM somewhere.

Good news !
Do you have a Vagrant file we could use (and publish) to generate the VM
directly ?

Vincent

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin licence

[Vincent Picavet (ml)]

Hi,

On 25/05/2016 12:39, Even Rouault wrote:
[...]
> The only cases where it makes sense in practice to have a plugin under a 
> permissive license are :
[...]
> - a more reasonable use case would be a plugin that would be compatible of 
> QGIS and another proprietary GIS through some abstraction layer of their 
> different APIs. The core of your plugin could then be permissively licensed 
> to 
> be compatible of both licensing models.

Another thing to keep in mind is that PyQt is also GPLv2.
Therefore if you want to make any call to PyQt, you would also have to
do the same work of having an abstraction layer on top of it, which
would be a pain.
This use case therefore makes less sense when you base your work on
PyQt. Or you have to buy a commercial licence from Riverbank for PyQt.

Using PySide to ease licence issues in this case may be something we
would have to think about, now that there will be support for it again.

Vincent


> 
> 
> 
>>
>> On Wed, 25 May 2016 8:01 pm Paolo Cavallini  wrote:
>>> Il 25/05/2016 11:42, Tom Chadwin ha scritto:
 I guess I am just sceptical that GPL's requirement for GPL licensing of
 a product, purely by virtue of importing the first product as a
 library, is likely to hold much legal weight.
>>>
>>> We asked for legal advice, and that was the official response.
>>> All the best.
>>>
>>> --
>>> Paolo Cavallini - www.faunalia.eu
>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin licence

[Vincent Picavet (ml)]

Hi,

On 25/05/2016 14:07, Tom Chadwin wrote:
> Vincent Picavet (ml) wrote
>> A grey area would be for example if you were using a QWebEngine
>> component in your Python Plugin, directly calling javascript functions
>> of the Javascript library from your Python code.
>> In that case I really do not know if it would be considered a link in
>> the GPL sense.
>>
>> But for your use case with code generation it is really clear.
> 
> A QWebView is used in the GUI as a preview window, and loads in the
> libraries. So it directly uses them, in that the generated output JS is
> loaded by Python into the QWebView. That sounds potentially like a "link" to
> me (apologies for not thinking of that before - I didn't appreciate its
> relevance).

I would say that while you just load the HTML in a QWebView, this is not
a link : the embedded web client loads the HTML file and interprets it,
independently of your code. I'd say you are still safe here, and I would
still consider the generated pages as data for from your plugin point of
view.

If you would call a javascript function from Python through a direct
code binding I would say it may be considered a link. But this is my own
personal interpretation. This is where we enter a grey zone, and I do
not have any online resource to point to in this case.
If you want to know more on this, I know some IP lawyers specialized in
OpenSource who may help.

For me your use case is still safe and non-binding. Furthermore, it is
pretty common with all softwares loading HTML documentation from within
an embedded browser, and I have never seen any licence trouble arising
with this.

Vincent

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin licence

[Vincent Picavet (ml)]

Hello,

On 25/05/2016 11:42, Tom Chadwin wrote:
> Vincent Picavet (ml) wrote
>> I may be wrong, but if qgis2web is like qgis2three, it generates
>> projects containing OL3 or leaflet code ?
>> In this case, there is no code link between the Python plugin and
>> Leaflet nor OL3
> 
> Yes, this is how it works. However, the code it generates *does* link to the
> other libraries in code. I think it would therefore be egregious to say no
> link exists between the Python code and the third-party JS libraries.

The term "link" is very subtle, and is key to the issue here. There is
absolutely no "link" in the sense of the GPL between your Python module
and the code you generate. The generated code can be considered as data
for your plugin ( template, replacement values).

For compiled code, the definition of a link is quite easy, and much more
complicated for script languages. The Plone project has done a deep
analysis some time ago and concluded that a "import" in Python is
considered a link in the sense of the GPL.

A grey area would be for example if you were using a QWebEngine
component in your Python Plugin, directly calling javascript functions
of the Javascript library from your Python code.
In that case I really do not know if it would be considered a link in
the GPL sense.

But for your use case with code generation it is really clear.

> Also, as I say, qgis2web redistributes those other libraries.
No problem neither, keep them with the original licence.

> I appreciate that, as you say, the other libs are largely licensed more
> permissively, and compatibly with QGIS - MIT/two-clause BSD.

Yes, this leads to much lesser complications.

> I guess I am just sceptical that GPL's requirement for GPL licensing of a
> product, purely by virtue of importing the first product as a library, is
> likely to hold much legal weight.
> 
> Anyway, to clarify, the advice is that GPLv2+ is the only acceptable licence
> - not even v3+?

As even noted, you could use a more permissive licence ( MIT, BSD ), but
the real use cases are rare.
As for using GPLv3 ( or later, which is the same right now ), it is more
complicated. QGIS being GPLv2+, it would be compatible. But you would
not be allowed to distribute that package ( QGIS & your GPLv3 plugin)
with any other piece of software which would be GPLv2 only, as GPLv2 and
GPLv3 are not compatible. Bad idea therefore.

Usual disclaimer : I'm not a lawyer, but still studied these issues a lot.

Vincent

> 
> Thanks for your patience and opinions
> 
> Tom
> 
> 
> 
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/License-Summary-tp5006354p5268117.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin licence

[Vincent Picavet (ml)]

Hi,

On 25/05/2016 12:39, Even Rouault wrote:
[..]
> 
> 
> Technically you could licence the plugin with any license you want, but as 
> soon you execute it against QGIS, it must be compatible of GPL v2+, since it 
> is a derived work of QGIS GPLv2 code, and thus it must convey the same rights 
> and obligations offered and constrained by the GPLv2 license.
> So you could also licence it under X/MIT, BSD 2/3 clauses or which ever other 
> free licences that are compatible with GPLv2+.
> It cannot be under a proprietary license, because GPLv2 would impose to have 
> access to the source code.
> 
> The only cases where it makes sense in practice to have a plugin under a 
> permissive license are :
> - imagine that someone would reimplement a QGIS alternative that would have 
> the same API as QGIS but would be more permissively licensed, then it could 
> make sense to have your plugin under that permissive license.
> - a more reasonable use case would be a plugin that would be compatible of 
> QGIS and another proprietary GIS through some abstraction layer of their 
> different APIs. The core of your plugin could then be permissively licensed 
> to 
> be compatible of both licensing models.
> 
> 

I do agree with this analysis.

Note that as for the Nvidia case mentionned, the Linux kernel has an
exception to GPL for proprietary modules. Not sure it plays a role on
the issue you mentionned, but it may be a strong difference with other
software which do not have this exception.

Vincent



> 
>>
>> On Wed, 25 May 2016 8:01 pm Paolo Cavallini  wrote:
>>> Il 25/05/2016 11:42, Tom Chadwin ha scritto:
 I guess I am just sceptical that GPL's requirement for GPL licensing of
 a product, purely by virtue of importing the first product as a
 library, is likely to hold much legal weight.
>>>
>>> We asked for legal advice, and that was the official response.
>>> All the best.
>>>
>>> --
>>> Paolo Cavallini - www.faunalia.eu
>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin licence

[Vincent Picavet (ml)]

Hello,

On 25/05/2016 10:41, Tom Chadwin wrote:
> Of course, since qgis2web is middleware, its licence also has to be
> compatible with Leaflet, Openlayers 3, and their respective plugins, none of
> which are GPL. Since the plugin bundles and distributes these libraries, I
> would say complying with their licences is of greater importance than
> complying with QGIS, which is not distributed with the plugin.
> 
> Not trying to start an argument - I just want to do the right thing by the
> creators of all the software on which mine is built.

I may be wrong, but if qgis2web is like qgis2three, it generates
projects containing OL3 or leaflet code ?
In this case, there is no code link between the Python plugin and
Leaflet nor OL3, and therefore no compatibility problem. You can keep
the original licences for these libraries and their respective plugins.

But the Python code for your plugin has to be GPLv2 as soon as you do an
"import qgis.core" and you distribute the plugin.

Furthermore, since OL3 and LeafLet are BSD-licenced, there actually is
no issue since this licence is compatible with GPL. You can link GPL
code to MIT or BSD without problem.

Vincent
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin licence

[Vincent Picavet (ml)]

Hi Tom,

QGIS is GPLv2+
A a Python import is considered being equivalent to a dynamic link, it
triggers the "share-alike" clause of the GPL.
Therefore all QGIS plugins must be licenced as GPLv2+ if they are
distributed.

Vincent

On 23/05/2016 17:12, Tom Chadwin wrote:
> I know that a QGIS plugin has to be open-source for the plugin to be included
> in the QGIS plugins repo. However, are there any further
> requirements/limitations on which open-source licence to choose for plugins?
> I was leaning towards MIT, but Riccardo (author of qgis2leaf) rightly
> suggested that I clarify if there is any position from QGIS on this?
> 
> Thanks
> 
> Tom
> 
> 
> 
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/License-Summary-tp5006354p5267793.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [WIP] slider to zoom canvas like a magnifier

[Vincent Picavet (ml)]

Hi,


On 11/04/2016 09:02, Paul Blottiere wrote:
> Announcing WIP for a slider providing a way to zoom the canvas, like a
> magnifier does.
> 
> A use case is for example to facilitate the manual placement of small
> labels.
> 
> A way to set up this tool is planned too (minimum, maximum and step).
> 
> Let me know if you have any comments.

Note that this feature would also include a default global value, so
that users on 4K+ screens can set it to avoid pixel-sized element being
too small.

Vincent

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] zip file uploads allowed on github issues?!

[Vincent Picavet (ml)]

Hello,

On 09/03/2016 19:50, Tim Sutton wrote:
> Hi
[...]
> Yes really great news! +1 for moving to GitHub issues ASAP.

Do we have a plan to try not breaking tickets references in commit
entries ? Any idea on how to handle this issue ?

Vincent

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Adding new provider for QGIS

[Vincent Picavet (ml)]

Hi,

Last but not least, make sure that all your code can be actually
distributed under a GPLv2+ licence. This means that the people who wrote
the code are ok with this, and also that you do not use any
non-compatible external code.

Vincent

On 25/01/2016 21:57, David Adler wrote:
> We would like to add a DB2 provider to QGIS so that QGIS users can
> access spatial tables on DB2 for LUW and DB2 for z/OS.
> 
> We have implemented and tested much of this based on an existing
> database provider.
> 
> What is the mechanism to have this reviewed and approved?
> 
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QEP - Proposal for QGIS 3.0 after 2.14

[Vincent Picavet (ml)]

Hi Nyall,

You just beat me on the same email a few minutes away :-)

> - Get PSC to vote on and accept
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/29 . Needs
> to be done ASAP so that we're all agreed that 2.14 is the last 2.0
> series release.

+1

> - Decide on the timing for 3.0. Specifically, will the normal
> scheduled release after 2.14 be skipped to allow for a longer
> development cycle for 3.0. Regarding this, my opinion is that we NEED
> the longer cycle to allow room for the (non Qt5/python 3.0) related
> changes which we can ONLY make for an API breaking release. There's
> already a long list at https://github.com/qgis/qgis3.0_api/issues, and
> I suspect this is only scratching the surface. Without sufficient time
> for devs to address these API related issues we'll be stuck with the
> limitations of the current API for another 2-3 years.

+1

> Anyway, can we please lock in point 1 above so that we can move the
> discussion on to timing?

+1 for approving point 1 ASAP.

Vincent

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QTraffic: I would never accept a plugin that I'm author ; )

[Vincent Picavet (ml)]

Hello,

I second Tim on both points.

Vincent

On 02/12/2015 10:38, Tim Sutton wrote:
> Hi Luigi
> 
> 
>> On 02 Dec 2015, at 05:43, Luigi Pirelli > > wrote:
>>
>> Hi qgis devs
>>
>> I just published the QTraffic plugin... It's a plugin developed for
>> the Coimbra university (Portugal) that I finished some months ago.
>>
>> I had ethical problem publishing it, because it contain a windows
>> executable (the algorithm developed by the University team) that I'not
>> able to verify directly.
>> I worked to convince to publish the code since the beginning of the
>> project, but because it's a research project they are still in
>> experimental phase testing and calibrating it. So they don't want to
>> have a "official" release of the code before to have it deeply tested.
>> Deep testing depends of accessibility of the plugin, so I published it.
>> During Gran Canaria hackfest I asked to some core developer if it was
>> correct to publish it, and all give me the ok.
>> I'm still not sure of this decision, and at least I want to be
>> transparent about this.
>>
>> I'm sincerely confident that the executable code (Fortran code) will
>> be sooner or later published, what I don't know is when and in what
>> form and with what license... but I'm confident that it will be a open
>> license.
>>
>> please ask more info or do pressure to the official code
>> maintainer(s): qtraffic_supp...@uc.pt 
>>
> 
> For my part I have concerns both from licensing and from exposing our
> users to potential harm point of view.
> 
> * In the first case (which is probably not as well defined) I don’t
> think it is good to ship code from the official repo where the licensing
> is indeterminate, and which potentially conflicts with QGIS licensing
> itself.
> * In the second case, shipping a binary from the official repo gives us
> no opportunity to inspect the code to ensure that it is not doing
> something potentially harmful to the users computer.
> 
> My suggestion would be to publish it under a third party repo and
> encourage users to test it from there.
> 
> Regards
> 
> Tim
> 
> 
> 
>> Regards
>>
>> Luigi Pirelli
>>
>> **
>> * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
>> * LinkedIn: https://www.linkedin.com/in/luigipirelli
>> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
>> * GitHub: https://github.com/luipir
>> * Mastering QGIS:
>> https://www.packtpub.com/application-development/mastering-qgis
>> **
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> 
> Tim Sutton
> QGIS Project Steering Committee Member
> t...@qgis.org 
> 
> 
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Project quality discussion

[Vincent Picavet (ml)]

Hello,

On 07/11/2015 00:08, Nyall Dawson wrote:
> On 7 Nov 2015 12:22 AM, "Hugo Mercier"  > wrote:
>> - if a company with no core developer wants to ensure a new feature is
>> accepted, it should pay another core developer for the reviewing part.
>> Ideally the money should go to the project and the project would decide
>> what core developer(s) to pay.
[..Snip.]

> It also means the entire project becomes 100% dependant on financing. At
> the moment a huge chunk (probably the majority) of QGIS work is
> volunteer or via non-funded contributions.

As far as I know this statement is totally wrong. The vast majority of
QGIS work is done via paid people during work hours. This is definitly
not volunteering, neither non-funded.
Some work may not be _directly_ funded, but it it still paid work :
researchers, consultant, people who develop plugins to help their jobs
may not be paid directly to do specific QGIS improvement. But all the
work they do on it is part of their global job.

They are indeed students, week-end programmers and other fully
benevolent volunteers who do a great job in QGIS, but it is IMHO very
far from being a majority.
And paying them to work on QGIS also is a way to value their work and
improve quality, not make the project $$$-dependant.

Vincent


> Couldn't this just be worked out by sponsored devs/companies on a case
> by case basis? Eg if timing is critical then line up a reviewer for
> speedy review prior to quoting for work and factor into their original
> quote the cost for this.
> 
> Nyall
> 
>>
>> - writing a QEP before adding a new feature is a good way to increase
>> its acceptance. But some people have to review it. We may come to the
>> same process to pay for QEP reviews.
>>
>> - at which point we rely on volunteer work is not yet clear. But the
>> current guess is: still too much. Having a better idea of the ratio
>> between free work and paid work would be profitable for the project: it
>> would allow to make clear what the reality of an open source project
>> like QGIS is and that too much free work is not sustainable. Paolo's
>> mail is about that. The goal is to (begin to) separate clearly what is
>> the part of free work and the part of paid work in the project.
>>
>> - see on the PSC side if it is possible to pay some people to handle
>> global maintenance : PR triage, reviews, small bug fixes and so on. It
>> does not have to be only one developer.
>>
>> Thanks for participating in this discussion.
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Project quality discussion

[Vincent Picavet (ml)]

Hello,

On 07/11/2015 00:08, Nyall Dawson wrote:
> On 7 Nov 2015 12:22 AM, "Hugo Mercier"  > wrote:
>> - if a company with no core developer wants to ensure a new feature is
>> accepted, it should pay another core developer for the reviewing part.
>> Ideally the money should go to the project and the project would decide
>> what core developer(s) to pay.
[..Snip.]

> It also means the entire project becomes 100% dependant on financing. At
> the moment a huge chunk (probably the majority) of QGIS work is
> volunteer or via non-funded contributions.

As far as I know this statement is totally wrong. The vast majority of
QGIS work is done via paid people during work hours. This is definitly
not volunteering, neither non-funded.
Some work may not be _directly_ funded, but it it still paid work :
researchers, consultant, people who develop plugins to help their jobs
may not be paid directly to do specific QGIS improvement. But all the
work they do on it is part of their global job.

They are indeed students, week-end programmers and other fully
benevolent volunteers who do a great job in QGIS, but it is IMHO very
far from being a majority.
And paying them to work on QGIS also is a way to value their work and
improve quality, not make the project $$$-dependant.

Vincent


> Couldn't this just be worked out by sponsored devs/companies on a case
> by case basis? Eg if timing is critical then line up a reviewer for
> speedy review prior to quoting for work and factor into their original
> quote the cost for this.
> 
> Nyall
> 
>>
>> - writing a QEP before adding a new feature is a good way to increase
>> its acceptance. But some people have to review it. We may come to the
>> same process to pay for QEP reviews.
>>
>> - at which point we rely on volunteer work is not yet clear. But the
>> current guess is: still too much. Having a better idea of the ratio
>> between free work and paid work would be profitable for the project: it
>> would allow to make clear what the reality of an open source project
>> like QGIS is and that too much free work is not sustainable. Paolo's
>> mail is about that. The goal is to (begin to) separate clearly what is
>> the part of free work and the part of paid work in the project.
>>
>> - see on the PSC side if it is possible to pay some people to handle
>> global maintenance : PR triage, reviews, small bug fixes and so on. It
>> does not have to be only one developer.
>>
>> Thanks for participating in this discussion.
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org 
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin Dependencies

[Vincent Picavet (ml)]

Hello,

On 05/11/2015 09:50, Richard Duivenvoorde wrote:
> On 05-11-15 04:56, Tim Sutton wrote:
>[...]
>>> I'm afraid that by using a much more complicate system (such as
>>> setuptools), would solve some problem for the (few) complex plugins
>>> and create a lot of problems and increase the barrier for the vast
>>> majority of simpler plugin authors.
> 
> I agree with Tim, unless we come up with a very simple way, this will
> not solve the problem: "non tech savvy users cannot setup their python
> environment for some complex plugi".

You are right, but this should be taken the other way round : how do we
add sugar onto a powerful system, to make it accessible for
non-that-tech people.
This is clearly doable and would be an ideal solution.
The proposals from Victor and all to create a set of functions to help
writing plugins is already a good start in that direction for the code part.
We should be able to do the same for the development environment part.

I think there are much more end-users which are annoyed by dependency
problems than new plugin writers not willing to setup en environment.
Dependency problems are hard whatever we do, and we should definitely
rely on the experience of others for this.



> The different module versions problem I do not see as a practical
> problem, most times python can work with higher versions. Let's keep it
> the responsibility of the plugin builders to keep up with versions of
> their modules.

Yes the plugin versions dependencies should be left to the plugin
writer. Dealing with one application using various versions of a module
for various plugins will just lead to "DLL Hell", multiple duplication
of modules and behaviour inconsistencies for the end user.

I think we should build on top of well-defined and bullet-proof tools
the Python world has to offer, and focus on adding simple ways for a
newcomer to start with development. It is not a question of overhead, it
is a question of interface.

Vincent

> I still think just copy the modules into the plugin is easiest (although
> redundant).
> And if you cannot package the lib with your plugin because of OS
> problems: documentation is the answer...
> 
> Somebody with this insights, maybe can write a chapter about python path
> magics and how QGIS works with that?
> 
> Regards,
> 
> Richard
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] A common set of functions for QGIS plugins

[Vincent Picavet (ml)]

Hello Victor,

A definite +1 on this.
Also maybe a parent QGISPlugin class all plugins would inherit from ?

As a side note on plugin, but important, Hugo intends at the hackfest to
propose and discuss having plugins be Python modules, so that we can use
PIP to deal with module and plugins dependencies.
This would solve this problem and let us use common Python tools, be it
on the plugin side, or the module management side, and ease packaging
also for the distributions.

Vincent

On 02/11/2015 23:53, Nathan Woodrow wrote:
> Hey Victor,
> 
> Just added you with write access to my project if you want.  I don't
> really mind if you wanted to work on the same one together.  My
> motivations were the same as you in the end.  Mainly just flesh
> something out in a sandbox and then we can add it to core once we have
> it nutted out.
> 
> Regards,
> 
> On Tue, Nov 3, 2015 at 8:43 AM, Victor Olaya  > wrote:
> 
> Hey Nathan
> 
> I knew about your project...but forgot about it :-) Sorry for that.
> 
> What would you suggest doing? merging them maybe? I like that idea. In
> the end, the plan is just to have a sandbox to add those functions and
> eventually move them to core (btw, qgis.py sounds good to me...)
> 
> I can make a PR to your repo if you think it is a good idea, and we
> keep on working there.
> 
> Let me know also if you have ideas about what to add to fill those
> modules with useful stuff
> 
> Cheers!
> 
> 2015-11-02 14:29 GMT+01:00 Nathan Woodrow  >:
> > Hey Victor,
> >
> > Working on the same kind of thing over here:
> > https://github.com/NathanW2/parfait
> >
> > IMO I would rather see a new module and not put it in qgis.utils. 
> Something
> > like qgis.py or qgis.wrappers or something like that that.
> >
> > - Nathan
> >
> > On Mon, Nov 2, 2015 at 11:20 PM, Victor Olaya  > wrote:
> >>
> >> >
> >> > I'm in two minds as to whether it would be a good thing to have an
> >> > 'official' one. While I can see the use, surely if these things are
> >> > useful
> >> > then they should be included in the mainline API with proper API
> >> > guarantees?
> >> > I'm not sure I'd want to rely on a library that doesn't have an API
> >> > guarantee, and if you're making the guarantee then why not in
> core? If
> >> > they
> >> > are *required* for a plugin to be accepted, then they must be
> in core
> >> > and
> >> > have an API guarantee.
> >> >
> >>
> >> My ideas is definitely to put this into core (that's what I wrote in
> >> my email when i detailed the plans that i have for this), but I have
> >> started it as a separate repo to make it easier to collaborate and to
> >> start moving ASAP.
> >>
> >> I could write a QEP with this idea, get it approved, throw a bunch of
> >> empty py modules in qgis.utils and then start working, but I like to
> >> first do some work, get people into it, and then do the bureucracy to
> >> pass this to core (I am sure no one will say no to this once a nice
> >> collection of functions is ready)
> >>
> >> I will wait for other people to voice their opinion, and if most
> >> people agree on going taht other way, I have nothing against it
> >> ___
> >> Qgis-developer mailing list
> >> Qgis-developer@lists.osgeo.org
> 
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] A common set of functions for QGIS plugins

[Vincent Picavet (ml)]

Hello Victor,

A definite +1 on this.
Also maybe a parent QGISPlugin class all plugins would inherit from ?

As a side note on plugin, but important, Hugo intends at the hackfest to
propose and discuss having plugins be Python modules, so that we can use
PIP to deal with module and plugins dependencies.
This would solve this problem and let us use common Python tools, be it
on the plugin side, or the module management side, and ease packaging
also for the distributions.

Vincent

On 02/11/2015 23:53, Nathan Woodrow wrote:
> Hey Victor,
> 
> Just added you with write access to my project if you want.  I don't
> really mind if you wanted to work on the same one together.  My
> motivations were the same as you in the end.  Mainly just flesh
> something out in a sandbox and then we can add it to core once we have
> it nutted out.
> 
> Regards,
> 
> On Tue, Nov 3, 2015 at 8:43 AM, Victor Olaya  > wrote:
> 
> Hey Nathan
> 
> I knew about your project...but forgot about it :-) Sorry for that.
> 
> What would you suggest doing? merging them maybe? I like that idea. In
> the end, the plan is just to have a sandbox to add those functions and
> eventually move them to core (btw, qgis.py sounds good to me...)
> 
> I can make a PR to your repo if you think it is a good idea, and we
> keep on working there.
> 
> Let me know also if you have ideas about what to add to fill those
> modules with useful stuff
> 
> Cheers!
> 
> 2015-11-02 14:29 GMT+01:00 Nathan Woodrow  >:
> > Hey Victor,
> >
> > Working on the same kind of thing over here:
> > https://github.com/NathanW2/parfait
> >
> > IMO I would rather see a new module and not put it in qgis.utils. 
> Something
> > like qgis.py or qgis.wrappers or something like that that.
> >
> > - Nathan
> >
> > On Mon, Nov 2, 2015 at 11:20 PM, Victor Olaya  > wrote:
> >>
> >> >
> >> > I'm in two minds as to whether it would be a good thing to have an
> >> > 'official' one. While I can see the use, surely if these things are
> >> > useful
> >> > then they should be included in the mainline API with proper API
> >> > guarantees?
> >> > I'm not sure I'd want to rely on a library that doesn't have an API
> >> > guarantee, and if you're making the guarantee then why not in
> core? If
> >> > they
> >> > are *required* for a plugin to be accepted, then they must be
> in core
> >> > and
> >> > have an API guarantee.
> >> >
> >>
> >> My ideas is definitely to put this into core (that's what I wrote in
> >> my email when i detailed the plans that i have for this), but I have
> >> started it as a separate repo to make it easier to collaborate and to
> >> start moving ASAP.
> >>
> >> I could write a QEP with this idea, get it approved, throw a bunch of
> >> empty py modules in qgis.utils and then start working, but I like to
> >> first do some work, get people into it, and then do the bureucracy to
> >> pass this to core (I am sure no one will say no to this once a nice
> >> collection of functions is ready)
> >>
> >> I will wait for other people to voice their opinion, and if most
> >> people agree on going taht other way, I have nothing against it
> >> ___
> >> Qgis-developer mailing list
> >> Qgis-developer@lists.osgeo.org
> 
> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> 
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] What's your view on QGIS plugins that connect to non-GPL software?

[Vincent Picavet (ml)]

Hello Crispin,

On 08/09/2015 14:10, Crispin Cooper wrote:
> Hi qgis-developers,
> I produce my own network analysis software sDNA (www.cardiff.ac.uk/sdna
> ).  It currently runs as a plugin for
> ArcGIS or Autocad, from the command line, with a standalone GUI, or
> through a Python API. 
> We would like to create a QGIS plugin that allows people to use sDNA
> from inside QGIS.  sDNA is free but not open source, still I believe
> this can be done within the terms of the GPL by running sDNA in a
> separate process with pipe or file communication.  That said, I’d like
> to know whether a plugin that loosely connects to proprietary software
> would be welcome in the first place.

Some (almost 100%) sure things :
* a Python "import" means GPL "contamination"
* Calling an external process communicating through pipe or file does
not imply GPL contamination

I would say that it is safe to have a qgis plugin calling a proprietary
external process.
That said, I also think that your external process should not be a
necessary part to run your software, otherwise it may be considered as a
strong connection or inclusion, and be subject to GPL contamination. If
it is optional, no problem. This specific point has to be verified
though, not 100% sure.

Vincent
> 
>  
> 
> What are your thoughts?
> 
>  
> 
> Best regards
> 
>  
> 
> Crispin
> 
>  
> 
> -- 
> 
> Dr Crispin Cooper
> 
> Sustainable Places Research Institute, Cardiff University
> 
> 33 Park Place, Cardiff CF10 3BA
> 
> Tel. +44 (0) 29 2087 6072 / ext. 76072
> 
>  
> 
> 
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS indexing data when editing

[Vincent Picavet (ml)]

Hello,

30s freeze is something which seems rather unpleasant for the user.

Could we imagine to do the indexing in background ?

And maybe indexing only what is currently in the user's extent, if this
is not what is currently done ?

Indexing a whole layer for editing seems a no-go. We should maybe have a
way to get the user to use the indexing tools only when zoomed in ?

Vincent

On 13/08/2015 07:38, Denis Rouzaud wrote:
 Dear Nicolas,
 
 The indexing is used for snapping in the application.
 It takes a few sec when enable the first tool, but snapping is much
 faster later on.
 
 Best wishes,
 Denis
 
 On 08/12/2015 02:30 PM, Doctor Who wrote:
 Hello,

 I'm using QGIS 2.10.1 and 2.8.3 with PostGreSQL 9.3 and PostGIS 2.5 under
 Linux openSUSE 13.2 64bits.
 A strange things appear since i've move from PostGreSQL 9.1 - 9.3

 Each time I open a layer for editing, when I selected any tools (node
 tools
 or creation entity tools), QGIS freeze about 30 sec and display 'indexing
 data' progress bar. (memory of my computer grow up in same time)
 After that, I could editing my data, close it and reopen editing session
 whithout any problem or any crash.
 But if I close my project and reopen it, again indexing data when I
 want to
 edit a layer.

 I've seen that new thing under a small layer (90 entities) and bigger one
 (about 250 000 objects), same things for Polygon or Point geometry.
 I've a primary key constraint and a spatial index.

 Have you already see that somewhere else ? I can't find why as it never
 happens before.

 Best regards,

 Nicolas



 -
 -- 

 GIS administrator in Urban Agency of the Greater Amiens

 Founder and main administrator of forumSIG

   --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/QGIS-indexing-data-when-editing-tp5219525.html

 Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
 
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 2.8.2?

[Vincent Picavet - ML]

Hello,

Le mercredi 29 avril 2015, 08:11:57 Paolo Cavallini a écrit :
 Il 29/04/2015 08:07, kimaidou ha scritto:
  auto-update feature
  
   a la Firefox, but a simple warning could be a great addition IMHO.
 +1

Having a RSS feed on the website, with all released versions 
(stable/nightly/whatever) could be a generic tool.
Then a short QGIS feature reading this feed and warning the user would be 
great.

Vincent

-- 
Vincent Picavet - Gérant Oslandia
www.oslandia.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Strange behaviour in feature ids when editing PostGIS layer

[Vincent Picavet - ML]

Hello,

Le samedi 28 février 2015, 04:43:53 Régis Haubourg a écrit :
 Hi,
 well pgadmin sets table view in readonly mode if no Primary Key is defined..
 That is more than a good practice from a DBA point of view, I wouldn't be
 against such a constraint for tables. We should raise some user warning
 when connecting to PG, so that users don't get confuzed
 Another point, what about views that do not have PK (but may be editable) ?

If you talk about auto-updateable views, you can track back the original table 
and check it for PK, as the PostgreSQL doc says :
The view must have exactly one entry in its FROM list, which must be a table 
or another updatable view.
There could still be a problem though if the PK from the original table is not 
selected in the view. This could be checked too.

More generally, it would be great to be able to override this behaviour if the 
user provides a unique and not null column name.
There are cases when triggers, rules and other mechanisms would require this 
and are not easily automatically detectable.

Vincent


 Cheers
 Régis
 
 
 
 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/Strange-behaviour-in-feature-ids-when-e
 diting-PostGIS-layer-tp5185929p5190614.html Sent from the Quantum GIS -
 Developer mailing list archive at Nabble.com.
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Vincent Picavet - Gérant Oslandia
www.oslandia.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Compression in libpq?

[Vincent Picavet - ML]

Hi,

Another option is to use SSL, which since version 0.9.8 uses compression by 
default. In this case you do not need any specific software neither tunnels.

SSH tunnels are a good solution too though. 
Setting up a VPN with compression activated is another option.

Just be aware that compressing compressed data is useless, so better choose a 
single option and stick to it.

Vincent

Le vendredi 13 février 2015, 11:18:23 Jean-Roc Morreale a écrit :
 The connections are made through KiTTY which create a ssh tunnel, all
 the applications then connect to the distant postgresql server like a
 local one with the bonus of encryption, compression and no application
 specific setup (even if I would love having an unblocked 5432 port).
 
 Le 2015-02-13 10:35, Andreas Neumann a écrit :
  Hi Jean-Roc,
  
  Thanks about this hint. I am vaguely aware about this option with pg
  connections through ssh with gzip. But I did not try it. Do you have
  any pointers how to set this up?
  
  Anyway - having this built in to our existing software without having
  to set up ssh connections would be a big plus.
  
  Thanks,
  Andreas
  
  On 13.02.2015 10:31, Jean-Roc Morreale wrote:
  Andreas, did you you try to setup these connection over ssh ? ssh -C
  uses gzip
  
  Le 2015-02-13 10:26, Andreas Neumann a écrit :
  Hi,
  
  Just came across this:
  
  http://michael.otacoo.com/postgresql-2/postgres-9-5-feature-highlight-pg
  lz-compression-libpqcommon/ This read is very technical.
  
  Question: does this mean that a future libpq will support
  compression?
  I think this would be very interesting for us, esp. if you work with
  PostgreSQL connections through slower network connections. I always
  found remote Postgis connections that are not on the same LAN quite
  slow.
  
  Any comments?
  
  Andreas
 
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Vincent Picavet - Gérant Oslandia
www.oslandia.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Certification IRC meeting, Thrus 12 Feb, 2015

[Vincent Picavet - ML]

Hello,

Le vendredi 6 février 2015, 17:34:46 Tim Sutton a écrit :
 Hi All
 
 We will be holding a meeting on IRC to discuss QGIS training and
 certification on Thursday 12 Feb 2015 and 14h00 GMT in the channel
 #qgis-certification.
 
 If you have ideas about a certification programme for QGIS, please come
 along and join us, or submit your ideas but email for discussion in the
 meeting!

I will not be there tomorrow, and I just wanted to remind the points raised 
last June which were important to me.

* The Certification Authority should be an independant, non-profit org, either 
OSGeo, or QGIS association
* The certification platform should be under the CA responsibility but its 
operation be contracted to a private org after an open tender bid. The 
platform operator should not be allowed to give training.
* The exam content should be under the responsibility of the CA, but it could 
be initially contracted to a private org after an open tender bid [1]
* There should be an open process to apply as a certified trainer, allowing 
to advertise certification training and invigilate exams
* Certification should have either a fixed cost, or a cost relative to the 
GNP/mean salary of the country of origin of the trainee [2]

[1] I would rather have an open collective process to build the exams, but 
could be harder to setup.
[2] I would prefer the second option

Questions :
- do we want certified trainers or certified training companies ?

That's mainly the points on my side, and I would be happy to see all of this 
take place.

Vincent

-- 
Vincent Picavet - Gérant Oslandia
www.oslandia.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer