Re: [QGIS-Developer] lack of conflation tools

[Vincent Picavet via QGIS-Developer]

Hi,

Geospatial data conflation is not an easy task, and usually depends on :

- the input data

- desired output

- semantics

- conflation based mainly on semantics( / attribute data ), topology or purely 
geometric

Note that semantic and topology-based methods are much more robusts than 
geometry-based ones.

In any case, there is no magic workflow and the method has to be adapted to the 
specific context.

I contributed to an implementation based on PostGIS quite a long time ago :

https://docplayer.fr/8718145-Appariement-de-graphes-de-reseau-avec-postgis.html 
( in french ).

There could be some generic algorithms which could be made available in QGIS 
processing to ease creation of workflows for conflation ( e.g. node 
fingerprints, geometry local correspondance search  ).

Get in touch if you are interested in developing some.

Vincent


On 30/05/2024 11:46, PIERRE Sylvain via QGIS-Developer wrote:


Hi devs and  qgis power users,

After investigating I can arg that there’s a lack of conflation tools in QGIS 
like such existing for Esri  :

https://proceedings.esri.com/library/userconf/proc17/tech-workshops/tw_513-105.pdf

Is there some plan or something I miss for doing such task in QGIS ?

Thanks

**



Sylvain PIERRE**

Chef de projet système d’information

Direction des Systèmes d’Information et du Développement Numérique

Service Projets et Ingénierie Numérique

*Collectivité européenne d’Alsace*

Tél : 03 88 76 68 88

sylvain.pie...@alsace.eu 

www.alsace.eu 

facebook twitter 
insta 


___
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-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 <mailto:vincent.pica...@oslandia.com> 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  <mailto:apaso...@gmail.com>> 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 <http://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
> <mailto: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 <http://www.itopen.it>
> ___
> 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
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 
> 
> -- 
> Saber Razmjooei
> www.lutraconsulting.co.uk <http://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

Re: [Qgis-developer] Continuous Integration / Testing with TravisCI

[Vincent Picavet]

Hello,

Le mardi 18 novembre 2014 16:05:57, Tim Sutton a écrit :
 Hi
 
 On Tue, Nov 18, 2014 at 4:52 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:
  Hi all,
  
  You may have noticed that there is a new symbol on the qgis github page
  that (hopefully) says build passing. [1]
  
  The last week I have been busy with fixing tests for integration with
  Travis CI.
[...]
 ​Brilliant stuff Matthias! Now we need to agree to 'no new code without
 tests' as a formal requirement and we will be a long way down the road
 towards a more stable QGIS.

Great work Matthias ! Really good to see QGIS starting to keep up on the 
quality and industrialization side !

I second Tim on the mandatory tests with features, time to strengthen the 
rules for even more quality.

Vincent

 
 Regards
 
 Tim​
 
  Matthias
  
  [1] https://github.com/qgis/QGIS
  [2] http://travis-ci.org/
  [3] http://dash.orfeo-toolbox.org/index.php?project=QGIS
  
  ___
  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] Trouble with PostGis

[Vincent Picavet]

Hi Walter,

Note that if you want to troubleshoot PostGIS problems, you should look at the 
postgres side, not the QGIS one. It would have taken 10 minutes to get the 
problem here.

So :
* configure PostgreSQL server to output logs for every query
* rerun these queries with EXPLAIN in pgadmin / psql
* Use something like pgBadger to analyze your logs and find the bad queries

There are a lot of other PostgreSQL-related tools which can be useful for 
auditing, fine-tuning, troubleshooting PostgreSQL, but it is a bit off-scope 
for 
this list.

Vincent

Le mardi 4 novembre 2014 22:38:04, walter.nordmann a écrit :
 may be i got it. after purging and recreating idx_planet_boundary and
 idx_planet_admin_level the cursor-query is using those indices and
 performance is on.
 
 yes, i'm running vacuum analyze on a regular base and the last run was this
 morning.
 
 if the performance is going down again, i'll contact the postgres people.
 
 Thanks
 walter
 
 
 
 
 
 
 
 
 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/Trouble-with-PostGis-plugin-tp519p
 5171236.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

Re: [Qgis-developer] QEP/RFC sqlite virtual tables

[Vincent Picavet]

Hello,

Le mercredi 29 octobre 2014 08:34:11, Matthias Kuhn a écrit :
[...]
  limitations. Only power users knowing what is really happening underneath
  will know what function to use, which is bad in UX terms.
  A comparison is OGR CSV driver versus CSV plugin... User has to know that
  both tools are differents, behaves differently with a different
  providers. Nothing in the GUI let you know that except try-fail
  approach.
 
 The problem is that we have one proposal which can be available soon
 with lots of functionality and a not-too-hard implementation. But we/I
 lack knowledge if it performs well in every scenario and if it offers
 the possibility to optimize.

The thing is, we cannot forecast everything, and without a working prototype, 
we will probably never be able to determine the behaviour for every scenario, 
as we probably cannot imagine every scenario at all.

Premature optimization is the root of all evil.

At some point we need some working code to be able to start iterating over 
something real, more than trying to imagine a perfect plan and see nothing 
coming at the end.

QEP are there to make sure the global orientation and design is good and is 
coherent with the rest of the project. They cannot be fully exhaustive, and 
there will probably be other QEP regarding this feature set to enhance and fix 
the first implementation. 
We could even go back if this approach proves to fail. Failure is progress 
too.

Vincent

 
  BTW, I have the feeling you don't disagree at all but that we are digging
  one of the harder features of a GIS tool. IMHO, that really desserves
  discussions, prooves of concept.  Any other opinions in dev's?
 
 I also don't think it's disagreement, it's evaluation of risks/chances
 involved by either of the two.
 
 Best
 Matthias
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Please stop spamming commit logs!

[Vincent Picavet]

Hi,

Le lundi 13 octobre 2014 14:12:08, Nathan Woodrow a écrit :
[..]
 The reality is this:
 
 1) Some companies want to see it for record, or contract.
 2) It doesn't pollute the log
 3) It's at the bottom so you don't see it unless you do a full log (git log
 --oneline if you didn't know you can do that for short log)
 4) Does it really matter?
 5) The first line is all that really matters
 6) I like seeing that X feature at Y point was added/funded by Z company
 7) We can pull this information for the website to generate a page
 
 1) and 4) are the most important ones.

+7 to that :-)

Vincent

 
 
 On Mon, Oct 13, 2014 at 9:52 PM, Jonathan Moules
 j.mou...@hrwallingford.com
 
  wrote:
   Every single log line has the committer's GitHub name so it isn't
  
  anonymous.
  
  I know, but that also includes the paid-for devs; my point was that if
  QGIS wishes to highlight those paying for work with money, then
  highlighting those paying for work with time seems fair too.
  
  Other than that, I'm +1 your entire message and don't think anything of
  the sort should be in the logs!
  
  Cheers,
  Jonathan
  
  
  
  HR Wallingford and its subsidiaries uses faxes and emails for
  confidential and legally privileged business communications. They do not
  of themselves create legal commitments. Disclosure to parties other than
  addressees requires our specific consent. We are not liable for
  unauthorised disclosures nor reliance upon them.
  If you have received this message in error please advise us immediately
  and destroy all copies of it.
  
  HR Wallingford Limited
  Howbery Park, Wallingford, Oxfordshire, OX10 8BA, United Kingdom
  Registered in England No. 02562099
  
  
  ___
  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] Memory Layers - some proposals

[Vincent Picavet]

Hi Nathan, all,

Le jeudi 25 septembre 2014 09:56:58, Nathan Woodrow a écrit :
[..]

 IMO we could in the future use sqlite in memory datastore for the memory
 provider which gives us a lot more options and range.

Hugo is currently writing a QEP to exactly do that and as well address some 
issues regarding database features re-implementation.
He should publish it for review sooner or later.

This could help handle the memory layer topic, but actually is a wider issue.

Vincent

 
 Changing the format of the project file to something that isn't xml is a
 interesting idea however it's not something that should be rushed into
 without consideration so I think that is a very different topic.
 
 - Nathan
 
 On Thu, Sep 25, 2014 at 5:19 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:
  Hi,
  
  Please excuse my ignorance, but
  
  Why would you want a memory (as in RAM) layer when you want permanent
  data?
  
  For portability reasons?
  That's fine, but then we should offer a possibility to support
  portability support for a real geo-format (with spatial index and all
  the goodies). To stuff it into the project file there can be support
  from a plugin, but I would not vote for adding this to core.
  
  To me it seems that the current demand for this comes mainly from wrong
  expectations created by the name (and people subsequently loosing data).
  And we can fix the name.
  For the portability issue, I'd rather go the longer way but get it right.
  
  Regards
  Matthias
  
  ___
  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] Module dependencies

[Vincent Picavet]

Hi,

  I have some doubt on automatic installation of dependencies.
  This fear this will be a bad practice for security.
 
 Maybe a better solution would be to integrate the memory layer saving into
 core. It'd be a nice feature to have in any case.

+1.
Adding new Memory layers should definitly be part of the core, as well as auto-
saving for them.

Regards,

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

Re: [Qgis-developer] Module dependencies

[Vincent Picavet]

Hello,

Le mardi 23 septembre 2014 12:35:41, Régis Haubourg a écrit :
 Hi all,
 I didn't mention the option to port Mem Layer saver to core for two
 reasons: 
 - that doesn't solve the proble of general plugin dependencies

Actually the general plugin dependencies problem is a distribution problem, 
and should not be solved inside QGIS. We really do not want to reimplement a 
multi-platform package management software.

As stated before, auto-installing packages should also be done with great 
care, which is as well why package management software exist in the first 
place.

There are a few possibilities to improve the current situation :
* Make it clear for the user that additional packages are needed for a plugin, 
and show him a page explaining how to install them, according to its platform.

* Have a stricter policy on plugins regarding external dependencies (e.g. do 
not accept plugins in official repo which have dependencies on packages not 
included in osgeo4w, or default qgis binaries)

* Have these dependency informations available in the plugin's metadata

* Have a better plugin architecture, which makes it easier to deal with 
dependencies, using tools made for that purpose (i.e. make qgis plugins real 
python packages installable with pip install).

I think the main point is first to warn the user and guide him for further 
install steps, instead of getting python import failed errors.

 - we already discussed how to port Mem Layer Saver to core on list, and
 ended up to the conclusion that we needed to modify qgs format from a xml
 text file to a zip container of project properties + datas + resources
 (symbols svg for instance)
 
 Porting that plugin to core is allright to me, but we will make qgis the
 only soft to write data files along data project file, with high risks of
 data loss (because user will forget it or trash it). Do we really want it?
 
 + to port, only if we clearly understand the impacts. I would prefer a new
 qgs format.

Porting the new memory layer feature + promping the user to save unsaved 
memory layers when closing the project would already be a first step, without 
the need for data storage in qgis project file.

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

Re: [Qgis-developer] QuickOSM as default plugin for OSM data

[Vincent Picavet]

Hello,

Totally agree with Tim, especially for the Cancel button. Any large query made 
by mistake will just freeze QGIS and there is no way out except killing it.

Vincent

Le jeudi 4 septembre 2014 14:36:21, Tim Sutton a écrit :
 Hi
 
 On Thu, Sep 4, 2014 at 1:28 , Paolo Cavallini cavall...@faunalia.it
 
 wrote:
  Il 04/09/2014 13:24, Anita Graser ha scritto:
   Hi Matteo,
   Thanks for raising this issue! From my (user) perspective, I totally
   agree that QuickOSM is much more usable than the current core OSM
   functionality (which I cannot get to work properly at all). I cannot
   comment on the dev perspective too much though but it does not seem
   like the current OSM core plugin is the best technical solution
   either.
  
  I also agree that the mainstream solution is not quite usable to me,
  and reducing
  duplications is always good.
  So, if there are no good technical reasons to avoid this, I'd prefer
  to have QuickOSM
  in core, and current functions hidden or removed.
  Thanks.
 
 For me QuickOSM has basic usability issues that should be addressed
 before we consider this. e.g. no OK/Cancel/Help buttonbar. Also no
 clear button in quick query.
 
 Also in some ways it is even more hard to use than the built in
 offering of QGIS - QuickOSM requires detailed domain knowledge of the
 OSM schema which novice users simply won't have.
 
 I would like to see a bunch of presets available (like we have for
 roads and buildings in InaSAFE - see
 http://inasafe.org/en/user-docs/application-help/openstreetmap_downloader.h
 tml) which let you select a feature type and get it downloaded, a qml style
 applied and have the layer ready to use in QGIS.
 
 I believe QuickOSM would be a good platform to do this on but in my
 mind as it stands it does not yet make a good replacement.
 
 Regards
 
 Tim
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QEP or RFC?

[Vincent Picavet]

Hi,
I was more in favor of RFC at the beginning, but QEP will ease search on 
search engine.

So +1 for QEP.

Vincent

Le mercredi 3 septembre 2014 03:56:48, Martin Dobias a écrit :
 +1 for QEP
 
 Martin
 
 On Tue, Sep 2, 2014 at 8:01 PM, Larry Shaffer lar...@dakotacarto.com wrote:
  Hi,
  
  I need to start using the new QEP/RFC setup (today actually),
  specifically for some sponsored work. I don't want the sponsor to think
  the QGIS project is indecisive, so I propose a vote on the naming of the
  process, since there is some disagreement.
  
  QEP or RFC?
  
  +0 for QEP (I'm fine with RFC, as well).
  
  I think RFC is a bit dry, though universally understood. QEP should not
  confuse the public, since the dev group actually interested in using them
  is fairly small. QEP is clearly spelled out in the repo name. QEP shows
  a renewed configuration over the older, existing RFC process.
  
  Lastly, QEP pays homage to Python's PEP. I think QGIS would not be as
  popular as it is today if it were not for Python integration.
  
  Regards,
  
  Larry Shaffer
  Dakota Cartography
  Black Hills, South Dakota
  
  ___
  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] Python plugins mandatory metadata

[Vincent Picavet]

Hello,

  Il 25/08/2014 17:06, Tim Sutton ha scritto:
  I agree they should remain optional for now.
  
  After a few months of managing the plugin approval queue, I still
  do not understand what is the advantage of having plugins without
  a repo and bugtracker. I agree that a home page is not a
  necessity.
  
  +1 Moreover, plugins are GPL licenced, hence the source code should
  be shared when a plugin is distributed. Python is a script
  language, but still there are some source which should not go into
  the final plugin package (.ui files typically). Therefore, a plugin
  _must_ have a full source code available somewhere, and a
  repository is a logical place for this.
  
  Globally it is about improving the global quality of the software,
  and these steps are the basics a plugin developer should provide.
 
 Yes but there are always going to be exceptions to this and I dont
 believe we should make having these items a sticking point e.g.:
 
 * some one in a corporate environment can't easily make a website for
 the plugin they write
 * Someone in a coprporate environment works in a repo behind a firewall
 * a bug tracker is behind a corporate firewall

If someone wants to have a closed environment for their plugin / application 
development based on QGIS, then they can setup a closed plugin repository.

We are talking about enforcing rules on the official QGIS plugin repository, 
not 
the other ones, aren't we ?

 As Ale says, its not that we should encourage people not to have these
 things, but we should not penalise them for it unduly if they don't.

Free software is about open development, not only open licence. We enforce 
the licence, but it is from my point of view not enough to ensure a piece of 
code is called free software.

 I think there are other things that would be more interesting to
 mandate e.g.:
 
 * standardised documentation
 * HIG compliance
 * Including a license file

Both points are not mutually exclusive (nor exhaustive).

 I would still like to see us reach a point where we have 'best of
 breed', 'sanctioned' plugins, and the 'wild west' differentiated for
 the users.

One of the question I often hear is what are the best QGIS plugins ?. I 
would like to be able to answer this question with Official QGIS repository 
are 
all good.
Or maybe we want a QGIS official plugin repository, and a staging or 
contrib one, with different levels of rules and quality ?

Vincent

 
 Regards
 
 Tim
 
  Vincent ___
  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] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)

[Vincent Picavet]

Hi Andrea,

First of all, I tend to agree with Marco, where QEP should be voted when there 
is a general agreement on them. The PSC voting should therefore be enough.

As for you question about QEP vs funders.

Le lundi 25 août 2014 08:41:29, aperi2007 a écrit :
[snip]
 Also, AOAIK an important question is undrstand the limit of a RFC.
 Infact don't forget that the main enhancement are always covered by one
 or more funders.
 
 Tipically they ask an enhancement with some request themself.
 
 This RFC in the QGIS world is obviously after the real fund phase where
 the funders find the developer and contract him.
 So what mean that the RFC is submittable to the PSC ?
 If the PSC to accept the RFC required more changeables and these
 changeable require more fund, what happened ?
 
 Or this RFC could be submitted before to find the developer and fund him ?
 
 In this second situation, the RFC should be submited from the funders ?

What should happen is one of the three following scenarii :

* The funder works with a contractor which knows QGIS and the QEP process well 
enough to guarantee to the funder that the QEP will pass as-is, for the 
originally proposed amount. In this case, the contractor takes the risk.

* The funder provides the QEP and makes the discussions with the community 
until a general agreement is reached. Then the funder finds a company/developer 
to pass a contract for the development phase.

* The funder makes a first contract with a company/developer, to write the QEP 
and reach an agreement (or not). Once the QEP status is set (voted as is, 
voted modified, deferred, rejected), the funder can pass another contract with 
this company/developer (or another) to implement the QEP.

Vincent

 
 Thx,
 
 Andrea.
 
 Il 25/08/2014 07:42, Martin Dobias ha scritto:
  I had the same impression as Nyall. PSC is meant to steer direction of
  the whole project, not to deal with technical details of
  implementations in QEPs - after all, only 3 out of 7 positions are
  meant for developers. At the same time I understand that creating
  another developer committee would make things more complex.
  
  
  I think that voting on QEPs could be started when the QEP's author has
  impression that enough consensus was reached. Most projects also allow
  their RFCs to go to 'deferred' state if the proposal is too
  controversial.
 
 ___
 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] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)

[Vincent Picavet]

Hell,

 You speak of discussion with community.
 This is agreement, but the only important to be sure of the work is the
 PSC agreement.
 If after 2 weeks the PSC say nothing one could start with a contract
 for the development ?

As Marco said, and as it always has been the case in the QGIS project, the PSC 
vote should only be a confirmation of the community advice.
If the PSC vote is contrary to the general community agreement, then we have a 
problem with the PSC itself. It never has been the case AFAIK.
If the community do not generally agree, then there is a problem with the QEP, 
and it has to be either refined, or changed.

 Surely better could be have a +1 explicit from the PSC menbers on the
 docs before start the work.
The PSC is there to validate the community advice, based on the expertise of 
the latter. If you want to have a sense of agreement before writing a RFC, 
then ask the community.

 And how PSC vot need to say that the RFC is accepted ?
I think the QEP should be officially proposed to the PSC by the original 
author, 
and the PSC will have a certain amount of time (say 1 week ?) to vote.
This vote should reflect the community advice.
A lack of vote in the given time should lead to QEP validation.

 Please note also that a community discussion could bring far from the
 objective of the RFC.
 And forgot that only the PSC vote are relevant to say the RFC is
 accepted or not.
 
 Another question is:
 
 actually 4/7 of PSC are not technical.
 This mean that a RFC could be approved without that any one of
 technical comptents are say :
 ok it is compatible with actual QGIS, it don't break anything.
 Or evalute if what is potentially breakable is reasonable or not.

Once again, the PSC vote should only be a validation of the general community 
advice. The required technical competences are in the community at large, and 
the PSC knows to trust the community.

 My dubt is infact.  A compatibility break is a technical question ?
 I guess potentially no, because it is more on QGIS usability , but is
 technical when start to say:
 
 hey using this solution you break the past, instead if you use this
 other solution you don't break the past.
 
 Is not simply to evaluate this question, and without a QGIS developer
 expert is not easy to follow a RFC for a funder.

Then the funder hires a QGIS developer to follow the RFC and make report. 
That's my scenario 3.

Hope this clarify your questions. Others, do not hesitate to fix my 
understanding of the process if I am mistaken.

Vincent

 
 A.
 
 2014-08-25 10:54 GMT+02:00 Vincent Picavet vincent...@oslandia.com:
  Hi Andrea,
  
  First of all, I tend to agree with Marco, where QEP should be voted when
  there is a general agreement on them. The PSC voting should therefore be
  enough.
  
  As for you question about QEP vs funders.
  
  Le lundi 25 août 2014 08:41:29, aperi2007 a écrit :
  [snip]
  
  Also, AOAIK an important question is undrstand the limit of a RFC.
  Infact don't forget that the main enhancement are always covered by one
  or more funders.
  
  Tipically they ask an enhancement with some request themself.
  
  This RFC in the QGIS world is obviously after the real fund phase where
  the funders find the developer and contract him.
  So what mean that the RFC is submittable to the PSC ?
  If the PSC to accept the RFC required more changeables and these
  changeable require more fund, what happened ?
  
  Or this RFC could be submitted before to find the developer and fund him
  ?
  
  In this second situation, the RFC should be submited from the funders ?
  
  What should happen is one of the three following scenarii :
  
  * The funder works with a contractor which knows QGIS and the QEP process
  well enough to guarantee to the funder that the QEP will pass as-is, for
  the originally proposed amount. In this case, the contractor takes the
  risk.
  
  * The funder provides the QEP and makes the discussions with the
  community until a general agreement is reached. Then the funder finds a
  company/developer to pass a contract for the development phase.
  
  * The funder makes a first contract with a company/developer, to write
  the QEP and reach an agreement (or not). Once the QEP status is set
  (voted as is, voted modified, deferred, rejected), the funder can pass
  another contract with this company/developer (or another) to implement
  the QEP.
  
  Vincent
  
  Thx,
  
  Andrea.
  
  Il 25/08/2014 07:42, Martin Dobias ha scritto:
   I had the same impression as Nyall. PSC is meant to steer direction of
   the whole project, not to deal with technical details of
   implementations in QEPs - after all, only 3 out of 7 positions are
   meant for developers. At the same time I understand that creating
   another developer committee would make things more complex.
   
   
   I think that voting on QEPs could be started when the QEP's author has
   impression that enough consensus was reached. Most projects also allow

Re: [Qgis-developer] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)

[Vincent Picavet]

Le lundi 25 août 2014 11:42:12, Vincent Picavet a écrit :
 Hell,

I meant Hello, of course, no offence :-/
v.

 
  You speak of discussion with community.
  This is agreement, but the only important to be sure of the work is the
  PSC agreement.
  If after 2 weeks the PSC say nothing one could start with a contract
  for the development ?
 
 As Marco said, and as it always has been the case in the QGIS project, the
 PSC vote should only be a confirmation of the community advice.
 If the PSC vote is contrary to the general community agreement, then we
 have a problem with the PSC itself. It never has been the case AFAIK.
 If the community do not generally agree, then there is a problem with the
 QEP, and it has to be either refined, or changed.
 
  Surely better could be have a +1 explicit from the PSC menbers on the
  docs before start the work.
 
 The PSC is there to validate the community advice, based on the expertise
 of the latter. If you want to have a sense of agreement before writing a
 RFC, then ask the community.
 
  And how PSC vot need to say that the RFC is accepted ?
 
 I think the QEP should be officially proposed to the PSC by the original
 author, and the PSC will have a certain amount of time (say 1 week ?) to
 vote. This vote should reflect the community advice.
 A lack of vote in the given time should lead to QEP validation.
 
  Please note also that a community discussion could bring far from the
  objective of the RFC.
  And forgot that only the PSC vote are relevant to say the RFC is
  accepted or not.
  
  Another question is:
  
  actually 4/7 of PSC are not technical.
  This mean that a RFC could be approved without that any one of
  technical comptents are say :
  ok it is compatible with actual QGIS, it don't break anything.
  Or evalute if what is potentially breakable is reasonable or not.
 
 Once again, the PSC vote should only be a validation of the general
 community advice. The required technical competences are in the community
 at large, and the PSC knows to trust the community.
 
  My dubt is infact.  A compatibility break is a technical question ?
  I guess potentially no, because it is more on QGIS usability , but is
  technical when start to say:
  
  hey using this solution you break the past, instead if you use this
  other solution you don't break the past.
  
  Is not simply to evaluate this question, and without a QGIS developer
  expert is not easy to follow a RFC for a funder.
 
 Then the funder hires a QGIS developer to follow the RFC and make report.
 That's my scenario 3.
 
 Hope this clarify your questions. Others, do not hesitate to fix my
 understanding of the process if I am mistaken.
 
 Vincent
 
  A.
  
  2014-08-25 10:54 GMT+02:00 Vincent Picavet vincent...@oslandia.com:
   Hi Andrea,
   
   First of all, I tend to agree with Marco, where QEP should be voted
   when there is a general agreement on them. The PSC voting should
   therefore be enough.
   
   As for you question about QEP vs funders.
   
   Le lundi 25 août 2014 08:41:29, aperi2007 a écrit :
   [snip]
   
   Also, AOAIK an important question is undrstand the limit of a RFC.
   Infact don't forget that the main enhancement are always covered by
   one or more funders.
   
   Tipically they ask an enhancement with some request themself.
   
   This RFC in the QGIS world is obviously after the real fund phase
   where the funders find the developer and contract him.
   So what mean that the RFC is submittable to the PSC ?
   If the PSC to accept the RFC required more changeables and these
   changeable require more fund, what happened ?
   
   Or this RFC could be submitted before to find the developer and fund
   him ?
   
   In this second situation, the RFC should be submited from the funders
   ?
   
   What should happen is one of the three following scenarii :
   
   * The funder works with a contractor which knows QGIS and the QEP
   process well enough to guarantee to the funder that the QEP will pass
   as-is, for the originally proposed amount. In this case, the
   contractor takes the risk.
   
   * The funder provides the QEP and makes the discussions with the
   community until a general agreement is reached. Then the funder finds a
   company/developer to pass a contract for the development phase.
   
   * The funder makes a first contract with a company/developer, to write
   the QEP and reach an agreement (or not). Once the QEP status is set
   (voted as is, voted modified, deferred, rejected), the funder can pass
   another contract with this company/developer (or another) to implement
   the QEP.
   
   Vincent
   
   Thx,
   
   Andrea.
   
   Il 25/08/2014 07:42, Martin Dobias ha scritto:
I had the same impression as Nyall. PSC is meant to steer direction
of the whole project, not to deal with technical details of
implementations in QEPs - after all, only 3 out of 7 positions are
meant for developers. At the same time I understand that creating

Re: [Qgis-developer] Python plugins mandatory metadata

[Vincent Picavet]

Hello,

 Hi all.
 
 Il 25/08/2014 17:06, Tim Sutton ha scritto:
  I agree they should remain optional for now.
 
 After a few months of managing the plugin approval queue, I still do not
 understand what is the advantage of having plugins without a repo and
 bugtracker. I agree that a home page is not a necessity.

+1
Moreover, plugins are GPL licenced, hence the source code should be shared 
when a plugin is distributed. Python is a script language, but still there are 
some source which should not go into the final plugin package (.ui files 
typically). 
Therefore, a plugin _must_ have a full source code available somewhere, and a 
repository is a logical place for this.

Globally it is about improving the global quality of the software, and these 
steps are the basics a plugin developer should provide.

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

Re: [Qgis-developer] [Qgis-psc] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)

[Vincent Picavet]

Hi Nathan,

I was thinking the same way lately. QGIS has now plenty of feature, and while 
this is really great, our technical debt seems to be increasing a lot 
recently.
Having a formal process for major new features as MapServer and GDAL have, 
would allow to have a much more coherent way of developping qgis.
Strong +1 on the idea then.
Vincent

Le jeudi 21 août 2014 14:26:39, Nathan Woodrow a écrit :
 Hey all,
 
 I would like to raise something I have been considering for a while now. We
 are becoming a large project, in code and users, and there has been some
 recent issues of developers doing work only for there to be disagreements
 on the implementation. I would like resurrect the use of RFCs, or I think
 would should name them QEP (QGIS Enhancement Proposal because that sounds
 much cooler :)
 
 My thinking behind this was:
 
 - QGIS is picking up pace in popularity and use so we need something to
 formalise the future feature set and any improvements for the next version.
  Most people know the Python project uses the idea of PEPs in order to
 document what new major features are coming in X version and to explain the
 rational, or reasons .  I have found this handy to be able to look at
 detailed overview of why a feature made it or didn't, or when it might make
 it, or if ever.
 
 - This is more then just using the bug tracker to log future features. This
 is something where we can have more detail and then break it down into sub
 tasks which can live in the bug tracker but linked to the QEP (RFC).
 
 - The QEP should also have formal voting and discussion around the
 proposal. This should be limited to a small pool of developers.
 
 - The QEP could also list changes the API, or if breaking changes need to
 be made.
 
 - Things like how the new feature might fit into other future plans.
 
 - QEPs should list as much detail as possible in order to help everyone see
 the bigger picture with the feature or change.
 
 Another reason I was thinking about this was in order to consolidate major
 features and collaborate better. Emails are fine but get lost and forgotten
 very easily, the bug tracker is the same.  The QEP can link to the emails
 and tickets for future reference.  QEPs should be the central point for the
 feature linking to everything that is related.
 
 Tim has been using GitHub for inaSAFE RFCs and it looks good. IMO I would
 say we should use that.
 
 Thoughts?
 
 Nathan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Release plans

[Vincent Picavet]

Hi,

Le vendredi 27 juin 2014 09:47:55, Richard Duivenvoorde a écrit :
 On 27-06-14 08:45, Nyall Dawson wrote:
  Why can't we state that release is when windows + mac + ubuntu are
  ready?
  
  +1 from me.
 
 +1 from me with the combo:

Agree with this, and to Nathan's demands.

We should definitly get more information on our user base, gather statistics 
(anonymous, or through website stats), so that we can know what really matters 
to our users. We should not develop software for ourselves, but for people who 
really use it. And final polish is probably the most important part. Yes this 
includes taking care of the user, marketing, ergonomy, fine wording and many 
things developers do not want to do or are bad at doing.

 - source release is only announced on dev list
 
 - when wmu is packaged, we sent a mail to user/community list, update
 website and startup the marketing machine/twitter about it etc etc

+1 then.

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

Re: [Qgis-developer] QMAP in core?

[Vincent Picavet]

Hi Paolo,
Nathan will provide more information, but QMap has been superseded by Intramap 
ROAM, and is no longer developped. I think that Nathan still does some 
bugfixing for some people still using QMAP, but all new work is being done on 
ROAM  :
http://nathanw.net/2014/03/10/intramaps-roam---a-qgis-data-collection-app/
https://github.com/DMS-Aus/Roam
Not sure it would be a good thing to integrate it into core, as it is a 
separated application, and aims at specific platforms (tablets mainly).
Vincent

Le mardi 24 juin 2014 10:43:59, Paolo Cavallini a écrit :
 Hi all.
 Any palns to add http://nathanw2.github.io/qmap/ to master? I think it
 would be good for our users to have it straight away, without downloading
 a different application. I'm available to give a hand, in case it would be
 useful.
 All the best.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Fwd: Hackfest/ developers meeting in Spring 2015

[Vincent Picavet]

Hello,

Le jeudi 19 juin 2014 11:57:19, Victor Olaya a écrit :
 If for a future edition you need help with organizing a hackfest in Spain,
 i will be happy to help.
 
 Also, the french QGIS community seems to be rather active, so if anyone
 from it wants to do something here, I will be ready to help as much as I
 can. Just let me know about what i can do. I think both options (France,
 Spain) would be very good as future hackfest locations.

As for hosting a codesprint in France next year (or later), it is clearly 
doable. We could do it in Lyon again quite easily. Paris could be an option 
but is expensive and not that convenient for such an event, even if well 
connected.
We could probably easily organize something in Nantes as well, dynamic city 
with good opensource commitment, 2h from Paris by train.
If interested in any of these places, just ask, and the OSGeo-fr team will 
start to see if something great can be organized.

Vincent

 Until that happens, let's enjoy Denmark ;-)
 
 2014-06-19 11:50 GMT+02:00 Gino Pirelli lui...@gmail.com:
  victor
  
  I'm agree about the quality of the copenhagen offer, but remember that we
  (spain) loosed again the opportunity to host a hackfest due the fact that
  none answered from Girona to the offer do the hackfest there!
  
  :| we should plan to self-organize the hackfest using CENATIC (
  
  http://amtega.xunta.es/) or AMTEGA (http://amtega.xunta.es/) support
  
  see you
  
  Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com)
  
  On 19 June 2014 10:31, Victor Olaya vola...@gmail.com wrote:
  Awesome news! I really enjoyed the time I spend there for their QGIS
  course last April, and I cannot think of a better place for a GIS
  hackfest
  
  :-)
  
  2014-06-19 10:14 GMT+02:00 Paolo Cavallini cavall...@faunalia.it:
  
  Hi all.
  
  On behalf of Lene Fscher, from the University of Copenhagen, I'm
  inviting QGIS
  developers to the spring 2015 hackfest in Danmark.
  See below for details.
  Thanks Lene!
  All the best.
  
   Messaggio Inoltrato 
  This is an invitation to come to Denmark in May 2015 for Developers
  meeting and
  Hackfest – or what it is called J
  
  University of Copenhagen would like to be host for this event.
  
  Our department at the The Forest and Landscape College is situated in
  Nødebo – 40 km
  north of Copenhagen.
  
  In the week from 18.-22. May 2015
  
  We have room for 34 persons and a hostel nearby is more persons would
  like to
  participate.
  
  We have a very good canteen which can provide us with food and coffee
  https://www.facebook.com/SpisehusetSkovskolen
  
  We have rooms for working
  
  We have an organization for having arrangements like this
  
  We have students for testing – they are used to work with QGIS
  
  We have “Flækken” the students place for beer and relaxation
  
  And place for time off in the forest….
  
  It is easy to get here from Copenhagen.
  
  In April 2014, Victor Olaya and Martin Isenburg visited us for a
  workshop. Please ask
  Victor for his opinion about our campus could be a place for this
  event.
  
  http://ign.ku.dk/om/skovskolen/
  https://www.facebook.com/SkovOgLandkabsingenior
  
  Regards
  
  *Lene Fischer*
  Associate Professor
  
  *Department of Geosciences and Natural Resource Management*
  University of Copenhagen
  
  
  l...@ign.ku.dk mailto:l...@ign.ku.dk
  
  
  
  
  
  
  ___
  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] [Qgis-user] LIZMAP ERROR PRINT - HELP!

[Vincent Picavet]

Hello,

Le mercredi 11 juin 2014 10:25:36, Jürgen E. Fischer a écrit :
 Hi Andreas,
 
 On Wed, 11. Jun 2014 at 08:39:11 +0200, Andreas Neumann wrote:
  It is true that in some cases we need to improve to be more standards
  compliant. This is a group effort. Everybody can contribute. Removing
  GetPrint from GetCapabilities, or implementing in a standard compliant
  way, would help. We could still have it listed in GetProjectSettings.
 
 It's disputable if the current way is not compliant.
 
 Changing that might break clients that query the capabilities for the
 presense of GetPrint if we'd applied a (less-disputable ;)) compliant
 prefix (ie. GetPrint to qgis:GetPrint).
 
 Note that this would only apply to the name of the operation element in
 capabilities, the actual request wouldn't need to changed.
 
 So it's unclear to me if there are actually any clients that would break.

I do not think a lot of clients are relying on getprint being in capabilities.

 At least some already use GetProjectSettings, others might just imply
 GetPrint without checking GetCapabilities - both groups wouldn't be
 affected.

Probably the vast majority of users.

 The clients that check capabilities would just need to look for
 qgis:GetPrint instead or alternatively of GetPrint - and that should just
 be a trivial change, when 2.4 is deployed.
 
 Also there are probably not that many clients around that actually use
 GetPrint.

+1
Thanks for your reasonable, pragmatic and thoughtful contributions.

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

Re: [Qgis-developer] Opinion on plugin named prepair (and possible likes)

[Vincent Picavet]

Hello,

Would it be possible in any case to have the boost + CGAL dependencies 
Optional ?
These two libraries are really long to compile, and can therefore slow down 
the development workflow pretty hard.
As for having an internal boost / cgal source tree, there is a strong risk of 
divergence beetween the internal and external versions, and it makes bug 
reporting and identification much more difficult.

QGIS dependencies begins to be really huge, and this complicates a lot 
compilation and deployment.

Is there a chance for prepair to be refactored so that it only use C++/Qt/QGIS 
internals ? What part of Boost/CGAL is used in prepair ?

I like the modular approach much better, just as postgresql stack builder 
does. Having an independant prepair executable tool, which is command-line 
driven, can be really interesting for use outside of QGIS. And then it may be 
wrapped inside processing for QGIS integration ?

Keeping everything modular is really important Imho, and should not be driven 
by packaging issue, which can be sorted otherwise.

Vincent


Le vendredi 6 juin 2014 18:54:41, Larry Shaffer a écrit :
 Hi,
 
 On Fri, Jun 6, 2014 at 10:26 AM, Paolo Cavallini cavall...@faunalia.it
 
 wrote:
  Il 06/06/2014 18:24, Andrea Peri ha scritto:
   SFCGAL is a real hard to compile piece of software. Use it on qgis mean
  
  to
  
   transformer the qgis in a real hard to compile software .
  
  cgal is packaged in all mayor OSs, AFAIK, so no need to compile it.
  all the best.
 
 Not on Mac. But, there is already a formula in Homebrew, and a new one for
 SFCGAL [0,1].
 
 My concern, Mac-wise, is the Boost dependency. Here are the minimal
 Pros/Cons:
 
 Pros:
 
 * Adds prepair, which is awesome for repairing polygons.
 
 * Adds Boost, which will offer a very robust framework to new devs, who are
 not necessarily adept at Qt developing, for building new core algorithms
 and features.
 
 * Could *double* the number of devs working on project. For example, PDAL
 and PCL already use Boost, and other 3D/Lidar tools may as well.
 
 Cons:
 
 * Boost is a very large compile and install. Since the Mac QGIS.app is
 bundled, the more Boost is used, the more of it needs bundled, possibly
 making the base install of QGIS on Mac balloon to over 1+ GB. Maintaining a
 smaller internal src tree may be a good solution.
 
 * The more Boost is used within QGIS source (beyond just prepair), then
 there is more new devs have to learn to become accustomed to the codebase,
 i.e. C++, Qt, and also Boost.
 
 There are probably others; but, adding Boost into the QGIS source mix will
 be a large change, IMHO. I think it would ultimately be beneficial.
 
 [0]
 https://github.com/Homebrew/homebrew/blob/master/Library/Formula/cgal.rb
 [1]
 https://github.com/Homebrew/homebrew/blob/master/Library/Formula/sfcgal.rb
 
 Regards,
 
 Larry
 
  --
  Paolo Cavallini - www.faunalia.eu
  Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html
  ___
  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] Realease and blockers

[Vincent Picavet]

Hello,

Le vendredi 6 juin 2014 11:08:57, Paolo Cavallini a écrit :
 The new QGIS version will be released very soon. There are still 58
 blocking issues, growing. Some of them are quite nasty. I urge everybody,
 and especially those who use QGIS in large organization, saving tons of
 money previously spent in licences, to quickly invest a fraction of these
 savings into fixing some of these. With 1 million users, this seems a
 feasible target.

Could we make a more visible RC release on the website, encouraging testing ?

I think that our user are not used yet to our new release cycle. We really 
should educate them, and lower the barrier to RC testing and bug reporting. As 
for now, even installing the RCs is complicated, so is bug reporting.

What about modifying the RCs so that :
* we have a bug report feature in the help menu, allowing to create an osgeo 
user, search for bug and report if not found ?
* we add a splash-screen or a first pop-up window stating clearly that there is 
a need for bugfixes, and therefore a strong and quick need for funding ?
Maybe even adding links to supporting companies as stated on the website, so 
that users/clients can contact them directly, in addition to the sponsoring 
informations ?
* we add to this popup a big donate now button linking to paypal / flattr or 
whatever simple system for micro-donation, and a bitcoin address
* we propose to optionnally subscribe to a specific qgis-newsletter mailing 
list, where we can reach our userbase with RC download links, and funding 
requests (with a privacy protection + no spam statement)

This is a bit late for 2.4 of course, but this is IMHO a way to enlarge our 
tester base, as well as our funders.
What we need is not a different release cycle, but more education. Adopting  
more push-oriented communication methods seams the way to go.

My 2 cents,

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

Re: [Qgis-developer] Realease and blockers

[Vincent Picavet]

Hello,

Le vendredi 6 juin 2014 12:30:23, Nyall Dawson a écrit :
 On 06/06/2014 8:20 pm, Vincent Picavet vincent...@oslandia.com wrote:
  Could we make a more visible RC release on the website, encouraging
 testing ?
 
  I think that our user are not used yet to our new release cycle. We
  really should educate them, and lower the barrier to RC testing and bug
 reporting. As for now, even installing the RCs is complicated, so is bug
 reporting.
 
 I don't think the issue is just bug reporting for a RC though. As
 mentioned, we've already got a very long blocker list, which is still
 growing.
 I think a bigger issue is development resources and developer's time
 availability. At the current rate of bug closing we're very likely to still
 have a large number of these issues outstanding at the end of the month.

More bug reports, bug comments and better bug reports is already a lot of 
developer's time saved.
Having more testers (and regular testers) is as important as having developers 
to fix bugs.

My proposal was also more oriented towards getting users involved in all ways, 
and especially funding at Feature Freeze time.
Getting them to download, install and test more thoroughly the RCs, and using 
this media to incent them to fund the software do contribute to more 
developers time.

 I'm in favor of a longer freeze period for next release.

I am not sure that more non-paid developer time is a sustainable model.

Or it is a matter of going from a FF development model, to a more formal peer-
review commitfest model ( like http://rhaas.blogspot.fr/2011/03/commitfests-
and-meritocracy.html ).

There are many other ways to reduce bugs even before reaching feature freeze, 
some of them already discussed thoroughly here, I am just trying to find some 
easy, reachable and efficient means, which can of course be complementary to 
other means.

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

Re: [Qgis-developer] Realease and blockers

[Vincent Picavet]

Hi,

Le vendredi 6 juin 2014 13:34:12, Alexander Bruy a écrit :
 2014-06-06 13:16 GMT+03:00 Vincent Picavet vincent...@oslandia.com:
  Could we make a more visible RC release on the website, encouraging
  testing ?
  
  I think that our user are not used yet to our new release cycle. We
  really should educate them, and lower the barrier to RC testing and bug
  reporting. As for now, even installing the RCs is complicated, so is bug
  reporting.
 
 We already have a big banner at main page about RC and testing. Seems most
 users don't visit main page too often to notice it.

I tried with a standard user yesterday, watching him use the site to get 
qgis, and it was still _very_ complicated for him. He expected to click on a 
QGIS 2.4 preview download button and the download to begin immediatly, which 
is far from happening.

Instead, the small RC link leads to a page with a lot of links, he had 
difficulties to find the preview release (not knowing what a release 
candidate 
is), hesitating with osgeo4w download, then being redirected once again on the 
same page, lost in the web page, finally finding a small link to a dull page 
listing a lot of files (what the hell is a md5sum file ?? what is this 2.3 
version ?? where is the preview ?), of which he finally chose a random exe and 
installed it. Even I was totally lost trying to get the right file.

I think we can do much better.

Then it is a matter of advertising the preview at large : official call for 
testing from qgis project on osgeo mailing lists, twitter, linkedin, and if 
possible on a qgis-news mailing list where we have gathered a lot of user 
beforehand (with their approval of course).

Vincent


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

Re: [Qgis-developer] have aggregate/window expressions ever been discussed?

[Vincent Picavet]

Hello,

Le mercredi 28 mai 2014 19:29:21, Régis Haubourg a écrit :
 Hi,
 the points Matthias raises are really good points:
 - how much can we trust sqlite (the community doesn't seem too opened)? And
 how stable library versions are (we've had many troubles with spatialite
 versions)

SQLite is here to stay, it is embedded in almost every portable device and a 
strong and mature piece of code. Probably the most deployed database in the 
world.
SpatiaLite is indeed a different piece of cake in term of contribution openness 
and community. We can hope that GeoPackage development will end up 
rationalizing and optimizing development efforts on spatial SQLite-based 
solutions. We can also be part of this effort if needed.

 - having redundant ways of doing the same thing is one of biggest criticism
 of users here. An advanced user who knows each tool will know what to do.

There is a question of user interface and a question of stable and technically 
strong development. Redundant technical ways of doing the same thing can be 
hidden through carefully designed UI so that the user knows what use case 
should be done which way (and even do not realize there are other ways).

 those risks explain why current tests are feasibility tests only. We need
 those investigations to be aware of the limits of each possible approach.
Right.

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

Re: [Qgis-developer] have aggregate/window expressions ever been discussed?

[Vincent Picavet]

Hello,

Le mardi 27 mai 2014 16:06:55, Andreas Neumann a écrit :
 Hi all,
 
 I understand your concerns, but on the other hand - how would you treat
 all data sources equally well, if QGIS does not implement that stuff
 within QGIS for data providers that do not implement this? One could
 still write a QGIS expression to SQL compiler for those providers who
 support these functions (Matthias Kuhn proposed that).
 
 We will need these aggregate functions in forms for information purposes
 and in the print composer for generating reports. Having to write
 Postgis-Views would work for database pros. But let's not forget that
 not all of our users are database professionals and not all of the users
 have their data in Postgis.
 
 Personally, I don't care where these aggregate functions are implemented
 and executed, as long as they are easy to use and do not enforce the
 usage of a specific data format.

I would not be shocked if QGIS had an official local data format, allowing 
the 
user to get all features when using it, and other formats for 
interoperability.
I do not think that this would disturb users as :
* almost all software do this
* QGIS already behaves like this, with read-only data formats for examples
It would almost simplify the situation as in use the official format or accept 
limitations.

And of course having a GeoPackage-compatible format would be a win.
This kind of change could trigger a new major version though, to make it clear 
that this is an important change.

Vincent

 
 Andreas
 
 Am 27.05.2014 09:21, schrieb Vincent Picavet:
  Hello Andreas,
  
  Le mardi 27 mai 2014 10:28:13, Andreas Neumann a écrit :
  Hi,
  
  We would definitely need this functionality for our application modules
  - we need functions like min, max, mean, sum, average to work
  on 1:n relations.
  
  Now that we have relations in QGIS, I think that aggregate functions are
  a logical next step. Something to seriously consider in 2.6.
  
  As already stated before, I am worrying about current developments 
around
  a lot of features looking like database features :
  * Table joins
  * relations
  * SQL-like processing
  * .. including aggregates
  
  Implementing all these features on top of QGIS seems reinventing the
  wheel, and database wheels are particularly hard to design and implement
  well. I really think we should re-study the global design of such
  features to have a clear and clean strategy instead of stacking features
  on features, lacking coherency.
  
  As stated by Regis, basing this work on top of SQLite may be the best
  option, but more study has to be done and a general agreement is needed
  to go this way.
  
  Vincent
  
  Andreas
  
  Am 23.05.2014 17:34, schrieb G. Allegri:
  Recently I had to calculate the relative dimension of a polygon
  relative to the others of the same class. I know there are a lot of
  way to do it, inside and outside QGIS, but I wondered if field
  calculator (and expressions in general) couls be extended to accompish
  this kind of tasks.
  
  The approach would be something similar WINDOW functions in 
Postgresql
  [1], where for each record a new value will be calculated on the basis
  of other records (filtered or not).
  
  Has this ever been discussed? Is it something that could fit QGIS
  expressions?
  
  giovanni
  
  [1] http://www.postgresql.org/docs/9.1/static/tutorial-window.html
  
  
  
  ___
  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
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] have aggregate/window expressions ever been discussed?

[Vincent Picavet]

Hello Andreas,

Le mardi 27 mai 2014 10:28:13, Andreas Neumann a écrit :
 Hi,
 
 We would definitely need this functionality for our application modules
 - we need functions like min, max, mean, sum, average to work
 on 1:n relations.
 
 Now that we have relations in QGIS, I think that aggregate functions are
 a logical next step. Something to seriously consider in 2.6.

As already stated before, I am worrying about current developments around a 
lot of features looking like database features :
* Table joins
* relations
* SQL-like processing
* .. including aggregates

Implementing all these features on top of QGIS seems reinventing the wheel, 
and database wheels are particularly hard to design and implement well.
I really think we should re-study the global design of such features to have a 
clear and clean strategy instead of stacking features on features, lacking 
coherency.

As stated by Regis, basing this work on top of SQLite may be the best option, 
but more study has to be done and a general agreement is needed to go this 
way.

Vincent

 
 Andreas
 
 Am 23.05.2014 17:34, schrieb G. Allegri:
  Recently I had to calculate the relative dimension of a polygon relative
  to the others of the same class. I know there are a lot of way to do it,
  inside and outside QGIS, but I wondered if field calculator (and
  expressions in general) couls be extended to accompish this kind of
  tasks.
  
  The approach would be something similar WINDOW functions in Postgresql
  [1], where for each record a new value will be calculated on the basis
  of other records (filtered or not).
  
  Has this ever been discussed? Is it something that could fit QGIS
  expressions?
  
  giovanni
  
  [1] http://www.postgresql.org/docs/9.1/static/tutorial-window.html
  
  
  
  ___
  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] GDAL 1.11 new formats

[Vincent Picavet]

Hi Larry,

Le mercredi 7 mai 2014 20:51:53, Larry Shaffer a écrit :
 Hi,
 
 GDAL/OGR 1.11 offers several new OGR formats [0] that need support added in
 QGIS's source. I have added the OpenFileGDB format (because it was simple
 to do) [1], but don't have enough experience with the other database
 formats to add their support.
 
 * CartoDB : read/write support
 * GME (Google Map Engine) : read/write support
 * GPKG (GeoPackage): read-write support (vector part of the spec.)
 * SXF: read-only support
 * WALK : read-only support
 * WAsP .map : read-write support

Vincent Mora will be able to help adding in QGIS the necessary parts (if any) 
for the WAsP support, as he is the author of the GDAL driver.
Ping him to coordinate the effort.
Vincent

 
 Would anyone be willing to help add support for those? Looks like in
 addition to qgsogrprovider.cpp's createFilters( QString type ) that
 QgsVectorFileWriter::initMetaData() also needs updated.
 
 IMO, it would be good to then backport these to release-2.2 branch as well,
 so current users may benefit from the new formats. I could add my commit,
 but seems like it would be better to add full GDAL/OGR 1.11 support at once
 to that branch, excepting some formats if they will need more extensive
 support added first.
 
 [0] http://trac.osgeo.org/gdal/wiki/Release/1.11.0-News
 [1] https://github.com/qgis/QGIS/commit/a096cf4
 
 Regards,
 
 Larry
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin management

[Vincent Picavet]

Hello,

 I am adding my notes on the plugins to be approved directly on the
 django interface, using the About field. I encourage others to do the
 same. Comments have to be removed before publication.

As you already said, it would be great if such a reviewer comment feature 
would be available directly in the django interface.

 It would be useful to have a list of items to be checked for approval.

Some more items for code reviewing :
* english language used in code (comments, identifiers)
* good shape of source repository :
- no generated file in repository (ui_*.py, resources_rc.py, gen. help files…)
- good code organization (subfolders)
- code comments
- PEP8  Python/QGIS guidelines compliance
- a README file
- a LICENCE file (GPL2/GPL2+ mandatory)
* Licence compliancy wrt external dependencies (e.g. no import of commercial 
python module)
* No evil : track the obvious rm -Rf ~/ code

As for external dependencies, I think it should be clearly stated somewhere if 
the plugin has a need for non-free external dependency.
If some dependencies are not available in OSGeo4w Python, a clear indication 
of how to install them should be given.

Great review work from your part Paolo btw !
We will try to join the effort soon.

Vincent

 Here a few items:
 * no .pyc files (correct?)
 * virus scan (how to do it? could this be automatic on the server side?)
 * if special data are needed to test the functioning, a small sample
 should be added
 * the plugin should go to the appropriate menu (Vector, Raster, Web,
 Database).
 I'm also checking for:
 * the presence of bugtracker and code repo
 * correctness of links
 * installation and basic functioning.
 Anyone wants to add?
 The good news is that we now have only 9 unapproved plugins:
 * 5 are being worked on
 * for 2, authors are not responding
 * 1 has issues with licence
 * 1 is considered unsuitable by the author.
 All the best.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Adding plugins to core?

[Vincent Picavet]

Hello,

Le lundi 7 avril 2014 12:05:05, Nyall Dawson a écrit :
 On 7 April 2014 18:15, Vincent Picavet vincent...@oslandia.com wrote:
  A good solution though would be to remove google layers and only use OSM
  and mapbox layers, which begin to be on par in terms of quality.
 
 I'm pretty sure this is against MapBox's terms of service too, unless
 users were made to sign up for a MapBox account and had to add their
 individual API key to QGIS to unlock MapBox layers:
 You must have a Mapbox account to use Mapbox. You are required to
 register for an account before using the Service. Each request to the
 API must include your account's unique API identifier. Unauthorized
 use of any API identifier is prohibited. [1]

Right, I had not read this through. It would probably be much easier to get a 
specific authorization from MapBox than from Google though, given their open-
source orientation.

  Or let the user a
  deliberate way to add google layers (indicating a URL or something like
  this), warning him about the licence.
 
 Hmm... while this may be a workable solution to the licensing issue,
 wouldn't it be a step back in functionality anyway? We'd be trading
 having a good, working off-the-shelf third-party plugin for a crippled
 core version which takes user intervention to unlock the same
 features.

In any case, there are quite a lot of OSM based layers which can be used (HOT, 
OSM.fr, OpenCycleMap...). We can still enhance the plugin with those.
It would lack an aerial imagery layer though.

 I'm totally for adding essential plugins to core (or merging the
 functionality with reimplemented c++ versions), but I honestly don't
 know if it's workable to do this for the OpenLayers plugin.

Right, if we remove everything from the plugin except the TMS YXZ layers, we 
could also just have a better ergonomy for opening this kind of layers through 
GDAL, and have a predefined list of layers accessible on internet (even auto-
updatable by downloading the list).

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

Re: [Qgis-developer] User profiles

[Vincent Picavet]

Hello,

Le lundi 17 mars 2014 09:57:00, Paolo Cavallini a écrit :
 The idea is not new, but now may be the right time to discuss it again: I
 think usability of QGIS for several specialized uses (e.g. field work,
 digitizing, etc.) would be enhanced if it would be possible to load one of
 a series of preset profiles. In short I suggest to:
 * store not only icon Customization, as it is already possible, but also
 menu bars toggling and placement

+ plugin list if possible, with installed and activated plugins.
+ icon sets

 * prepare, with the help of power users, a series of profiles
 * ship them along with main QGIS.
 Opinions?

I personnaly think it is a great idea. It would actually be even better if 
users could create their own toolbars and save/share them.

Integrating UI custom settings sharing into the (future) django-powered QGIS 
resource sharing site would be great too.

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

Re: [Qgis-developer] [Qgis-user] IntraMaps Roam first release - Windows QGIS Data Collection

[Vincent Picavet]

Hello,
Thanks a lot Nathan for this work !
Note that we at Oslandia are working on a new PostGIS / Spatialite versionning 
and offline system, intended to be used by Roam to edit data offline and merge 
it 
with online PostGIS database.
A prototype should be opensourced in the next weeks/month. We will keep you 
posted.
Vincent

Le vendredi 7 mars 2014 07:32:42, Nathan Woodrow a écrit :
 Hi everyone,
 
 Just dropping a quick email out to let everyone know about a project I have
 been working on the last couple of months.
 
 Digital Mapping Solutions, and myself, would like to announce the first
 version of IntraMaps Roam - a simple, but flexible, Windows based data
 collection application built using Python and QGIS.
 
 IntraMaps Roam (or Roam for short) is a standalone, fully bundled, Python
 application that was created to do data collection with a QGIS backend.
  For those of you who have seen my QMap project I started a year or so ago
 you can consider this a reincarnation of that project. Most of the code has
 been reworked and using the QGIS libs gave me full flexibility in layout.
 
 The release page can be found at
 https://github.com/DMS-Aus/Roam/releases/tag/v2.0 and the wiki with all the
 information to get started at: https://github.com/DMS-Aus/Roam/wiki You can
 also take a look at the FAQ for the common questions:
 https://github.com/DMS-Aus/Roam/wiki/FAQ
 
 Roam has been a great exercise in using and bundling QGIS libs with a
 Python application.
 
 As Roam is based on PyQt and QGIS it is under the GPL2 license. Pull
 requests are welcome.
 
 Links:
 - https://github.com/DMS-Aus/Roam/releases/tag/v2.0
 - https://github.com/DMS-Aus/Roam/wiki
 - https://github.com/DMS-Aus/Roam/wiki/FAQ
 
 Happy mapping!
 
 Regards,
 Nathan
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Failing tests consider blockers

[Vincent Picavet]

Hello,

Le mercredi 19 février 2014 12:32:39, Martin Dobias a écrit :
[...]
 Agreed. If we decided to do time-based releases, let's do them as
 planned and not discuss the decision two days before the planned
 release...
 
 I think we should mainly reconsider which bugs should be marked as
 blockers. The current policy every regression is a blocker does not
 make sense to me. In my opinion a blocker is something that makes the
 software unusable for potentially large amount of users - in such case
 it makes sense to delay the release for few days (as an exception, not
 a rule).

+1 to all this

It will probably take some time for all of us devs to take good habits of 
fixing blockers as soon as possible. It will probably also encourage funders to 
give money to developers to fix them before the release.
At the end, it should be a better solution to keep strict fixed releases, and 
should enforce code quality.
One way to ensure this is to work seriously on tests as well.


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

Re: [Qgis-developer] Filter on joined tables

[Vincent Picavet]

Hello,

Le vendredi 14 février 2014 11:11:42, Martin Dobias a écrit :
 On Fri, Feb 14, 2014 at 4:36 PM, Hugo Mercier hugo.merc...@oslandia.com 
[...]
 
 I think there should be a switch in the GUI allowing the user to do
 filtering with native query (if supported by provider) or with
 QgsExpression (always supported, allows joined attributes in join).
 For simple cases the QgsExpression filter could be even translated to
 provider's native subset query for greater efficiency.

On a side note, there seems to be currently a lot of new features coming in 
QGIS which look like database features. Join tables, relations, filtering, 
indexing ... 

We should probably take a moment of reflection sometime to think about it from 
a general point of view. We do not want to reimplement a database inside QGIS, 
as we already have an embedded one (SQLite/Spatialite), but we want to keep as 
general as possible in terms of format combinations and features available in 
QGIS.
Some rules for development architecture on this topic would be great to have, 
to avoid code complexity and (potentially bad) reimplementation of existing 
features.

Not that I have a good solution ready, but just to raise the subject for 
discussion. Do not hesitate to start a new thread if you think it is worth it.

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

Re: [Qgis-developer] one email address for plugin approvers

[Vincent Picavet]

Hello,

Le jeudi 13 février 2014 12:15:24, Richard Duivenvoorde a écrit :
...[snip]...
 Approval:
 
 1) your plugin will not be public until it is approved by a set of
 community approvers
 2) give approvers some time to do this (after 2 weeks just email to...)
 3) to approve we check that (checklist):
[...]
 - has a proper license ( which one? and info about that??)

There is no choice on the licence a plugin can be distributed under : a python 
import is considered a link, therefore the import qgis.core is enough to 
propagate the GPL licence to the plugin.
There may be some other files under different licences though, namely sample 
data, documentation or whatever else is not concerned by the link and GPL 
contamination.

Vincent

 - supports english language
 - does not duplicate of existing functionality or plugin, unless there
 is a very good reason (plz provide this reason in the description or
 metadata)
 
 For the first point (orange block) can we standardize on Github? Can we
 ask from the average plugin author to put his code on Github? Because
 then an author has both an issuetracker and either a README or a wiki.
 
 Then here:
 
 http://www.qgis.org/en/docs/pyqgis_developer_cookbook/plugins.html#plugin-m
 etadata-table
 
 AND in the plugin code, make repository a required property, and keep
 homepage and tracker optional. BUT that should be enforced in the plugin
 repo code then.
 
 
 Is this clear enough?
 Please comment/rewrite in a way that I can copy it into the website.
 
 Regards,
 
 Richard Duivenvoorde
 
 
 ___
 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 and 3D

[Vincent Picavet]

Hello Giuliano,

As for now, there is no support for 3D in QGIS, be it for visualization, or 
internally.

If you want to have some 3D features for your GIS you can :
* use qgis2threejs to visualize layers on top of a MNT with a WebGL browser
* Use the 3D features of grass through QGIS
* Use latest PostGIS versions, which allow you to manipulate 3D objects.
PostGIS + SFCGAL lets you do some computations on 3D objects with SQL. You can 
send SQL commands from within QGIS. See this video for an example and 
visualization of 3D objects with Horao (QGIS plugin to view PostGIS 3D 
objects) :
http://vimeo.com/74869530

There will probably be at some point an effort to support 3D objects in the low 
level QGIS code, and Marco already worked a bit on it I think. But this is a 
heavy-lifting task and a lot more work and funding are needed. Maybe Marco can 
elaborate a bit more on this.

Vincent

Le vendredi 24 janvier 2014 12:46:55, giulianc51 a écrit :
 hi all,
 
 I'm new to the QGIS;
 
 I like to explore the capabilities of QGIS towards 3D performances,
 I intend vector 3D;
 
 I think of:
 - visualization (orthogonal, axonometric and perspective views)
 - sections (along with any plane, canonic or skew)
 - volume and surface calculation
 and so on;
 
 I know that these operations are already possibile with raster layers
 and I did'nt intend to propose a flame for the primality of vector
 and/or raster;
 
 I think only to analyze and eventually build some tools for managing 3D
 models, leaving to the user the choice of vector / raster selection;
 
 I think that the possibility of managing, georeferencing and analyse
 point clouds from laserscanner, sfm, etc, could be an interesting
 chance;
 
 From that point of view I'm curious of the presence in the QGIS API of
 some features 3D: Line3D, Point3D, QgsTINInterpolator, Vector3D;
 because I dont know the C/C++ and I can't see the original
 documentation, where can I find some documentation in pythonish mode
 (the pyqgis cookbook doesnt treat that subject) ? Which are the
 development purposes about 3D?
 
 sorry for my bad english, thanks in advance, best regards,
 
 giuliano curti
 melegnano, milano, italia
 
 ___
 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-UX] option to disable font vectorization in labels

[Vincent Picavet]

Hello,

Le mardi 21 janvier 2014 21:45:16, Nyall Dawson a écrit :
 On 22/01/2014 4:56 am, Anita Graser anitagra...@gmx.at wrote:
  Am 21.01.2014, 10:24 Uhr, schrieb Vincent Mora vincent.m...@oslandia.com
  
  - a composer option: you make the choice when you export to svg, in this
 case you don't see the result until you open the svg
  Thanks for addressing this issue!
  For me, the most obvious place to put this option would be in the print
 composer. Maybe close to the print as raster option?
 
 I'm not a huge fan of this option, given that I'd like to keep the composer
 window as clear of clutter as possible. I think output format specific
 options like these (and saving svg to layers) should be put into a separate
 dialog which appears after the save file dialog. Much like how
 gimp/Photoshop/illustrator etc show a jpg quality dialog after choosing to
 save a file as jpg. The settings could either be remembered globally or per
 output filename.

-1 for another dialog window. It makes the user have to set another step to 
export before having a result. If you want to export the same composition work 
multiple times with different file names you would have to set this every time.
If you want QGIS to remember the settings, the user should have set it 
somewhere specifically. UX simplification is good, magic things happening 
behind 
the scene are not.
Generally im am more in favor of a configure first, then execute way of 
working than the opposite.
An intermediate solution could be to have an extended save as dialog box, 
with some options on the side.

 My ultimate goal (I was going to run this by the ux list) is to move
 infrequently used settings like resolution, page size/orientation, print as
 raster, etc and the atlas settings to their own composition properties
 dialog and then remove the need for the composition and atlas panels. Any
 thoughts on this?

Same, more dialog boxes is a -1 for me, panels are quick and convenient, and 
give a fast overview of things.
An option to hide or reduce them on the side would be preferable imho.

Only my personal opinion for what it's worth.


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

Re: [Qgis-developer] [QGIS-Server] Adding Web Processing Service, partially funded

[Vincent Picavet]

Hello,

Le vendredi 20 décembre 2013 09:06:06, Pirmin Kalberer a écrit :
[..]
   The final goal is to execute QGIS-Processing Server-side.
   
   The first step was to run QGIS-Processing headless. I made a pull
   request which needs review and test.
   https://github.com/qgis/QGIS/pull/1031
 
 Really great news!

Other question : do you rely on qgis.core only then for QGIS processing now ?

   Next steps: developing the WPS interface and executing algorithms
   server side.
  
  Are you going to reuse the excellent PyWPS framework, or build a specific
  one ?
 
 A simple but powerful solution would be to implement an export to PyWPS
 Python code similar to the existing Python export.

+1 for that, simple, flexible and powerful. And Unix spirit too :-)
If we want tighter integration, it is a matter of packaging PyWPS with QGIS.
Or implement a way of sending bundled WPS scripts from QGIS to a PyWPS server.

As for performances, I think having python for serving WPS is not damaging, 
since the performances issues are more related to the algorithms 
implementation than the WPS server itself.

Vincent

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

Re: [Qgis-developer] [QGIS-Server] Adding Web Processing Service, partially funded

[Vincent Picavet]

Hello,


Le jeudi 19 décembre 2013 12:11:21, René-Luc D'Hont a écrit :
[..]
 The final goal is to execute QGIS-Processing Server-side.
 
 The first step was to run QGIS-Processing headless. I made a pull request
 which needs review and test.
 https://github.com/qgis/QGIS/pull/1031
 
 Next steps: developing the WPS interface and executing algorithms server
 side.

Are you going to reuse the excellent PyWPS framework, or build a specific one ?

Do you plan to integrate the WPS modules selection and settings directly 
inside the Processing interface or with a specific one ?

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

Re: [Qgis-developer] Minimum qt version - bumping to 4.6?

[Vincent Picavet]

Hello,

Le vendredi 15 novembre 2013 05:14:00, Martin Dobias a écrit :
[..]
  It's probably reasonable to bump Qt version once per year, so in 2014 if
  CentOS/Redhat 7 comes out I expect it will have something newer (4.7+)
 
 I do not like the idea of being held back from upgrading minimal
 requirements by one distribution. I think it is fairly reasonable to
 expect that only older software will work with older distributions.
 Moreover, I guess the share of CentOS/Redhat users is quite low even
 just among linux users because it is mainly server oriented. And even
 then those users should not have trouble installing newer Qt from
 third-party packages.
 
 Finally, newer versions of Qt are also more stable - with a release of
 new minor Qt version the older branch typically stops receiving
 further bugfixes.

+1 to that !
Let's bump QT version and walk ahead.

Vincent

 
 Regards
 Martin
 ___
 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] Roadmap for 2.2

[Vincent Picavet]

Hello,

Le mardi 5 novembre 2013 01:24:55, Nathan Woodrow a écrit :
 It would be cool if we could do a Christmas release for 2.2 and then we can
 look at things like multithreading for the next one.  I don't think trying
 to rush in something like multithreading is a good idea as there is a bit
 that can go wrong with that kind of thing.

+1
Release soon, release often.
We should take advantage of this consolidation period to release a good and 
stable 2.2 version for Christmas. That should give us time to consolidate a 
2.3 with important core change like multithreading.
There is enough new features and enhancements in master just now to justify a 
release.
If the multithreading branch is worked on before christmas, we could release a 
2.3 alpha not long after 2.2 and gather some testers to have it stable after a 
few RCs.

Vincent


 
 - Nathan
 
 On Tue, Nov 5, 2013 at 10:22 AM, Mathieu Pellerin 
nirvn.a...@gmail.comwrote:
  As others have pointed out, there's already a substantial amount of new
  features in qgis master. Beyond what was mentioned above, there's: world
  file on qgis composer export, expression based {categorized, graduated}
  symbology, notable improvements in the spatialite  postegresql drivers,
  improvement to plugin manager etc.
  
  That's on top of a number of bug fixes following public adoption of qgis
  2.0, which Nyall was offering to look at and backport to 2.0 branch.
  
  Question: is there already enough to justify a qgis 2.2 Christmas
  release? The master branch is quite stable at the moment, wouldn't need
  as much of a cool down period as 2.0 required.
  
  Just a thought :)
  
  M
  
  On 5 Nov 2013 02:29, Andreas Neumann a.neum...@carto.net wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
  
  Hi,
  
  Marco Hugentobler is working on DXF export and there are also label
  speed improvements in the pipeline that did not make it into 2.0
  
  Nyall is working on improving the print composer to behave better like
  a DTP/graphic application, including better navigation in the print
  composer view, selecting and manipulating multiple elements at once,
  etc. Nyall also included a new symbology option for gradients.
  
  Matthias included his work on database relations - which is already in
  master for you to test.
  
  Victor and Alex are continuously improving processing.
  
  I am sure there is much more.
  
  So there is already a lot of interesting work in the pipeline for QGIS
  2.2
  
  Andreas
  
  Am 04.11.2013 20:01, schrieb Paolo Cavallini:
   Il 04/11/2013 19:51, Jrgen E. Fischer ha scritto:
   Not yet - at least as far as I know.
   
   wouldn't it a good time to do it now then? :) thanks.
   ___ Qgis-developer
   mailing list Qgis-developer@lists.osgeo.org
   http://lists.osgeo.org/mailman/listinfo/qgis-developer
  
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
  
  iQEcBAEBAgAGBQJSd/WDAAoJELiCsGDopvBChMYH/1XxRpOUgqlLzeQA/C7uq6lD
  MMlWF3ESTHvU6JqUumRZSMLcHGtaUw8TSqk1v6CUeTg9HVG82YrEi8y4yMzcxsPg
  HtLKlOE9wemGluH1GLc7XXUTltHpt/PApj4ZbAPaOfjpGvYMyV0aK4lftP7OhP9K
  TC/KGwgeqqGYxBeuKymgUw0To8cg+rLFn3AHmfsuLWL0GmsFIXtVHKEJ7o1C5Jaf
  +KXn7yNskZvt/uHLa5RuG59EVRDKZozlJyYtDUK2om6c2rRyR3q7FwMo2DnYTGvY
  cHMzAGPvNS0NKxyZCnFACakdBwIWu2mQSIiJa2gciMJrnI10TLpdnfOfCeq5lDg=
  =LkSv
  -END PGP SIGNATURE-
  ___
  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] Roadmap for 2.2

[Vincent Picavet]

Le mardi 5 novembre 2013 11:23:11, Jürgen E. Fischer a écrit :

 Anyway, the 4 months would be split into three months of development and
 one month for testing, bugfixing, translating and release preparations in
 a freeze period.
Great to have a fixed time release plan ! Definite +1 for that !

Do you think that it will need a commitfest period, when ready features 
would be merged into trunk before the one-month testing ? (That's how the 
linux kernel or PostgreSQL work).

Or would it be the responsibility of the commiters to only accept PR whenever 
the proposed feature is complete, tested and documented during the 3 months ?

The situation we do not want is a wrong evaluation of development time for a 
feature, which would as a consequence be only partly commited to trunk when 
the three months period of development ends.
 
 So if everyone knows beforehand when the next release will happen, new
 things can be scheduled to be introduced into a certain release slot. 
 Things that take more than one slot, should go into a seperate branch and
 merged when they are ready.
Ok, then the question is, do we merge regularly, or at a fixed time in the 
development cycle.

[..]

 Does jan/may/sep sound preferable?  feb/jun/oct or mar/jul/nov or
 apr/aug/dec any better?  Any preference on the week or weekday such a
 release should happen (eg. 3rd friday of the month)?

Better not have a release in august because of summer holidays.
feb/jun/oct would be my favorite.

 [..]

 Opinions?

Great move :-)

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

Re: [Qgis-developer] What about OpenGL renderding ?

[Vincent Picavet]

Hello,

Le jeudi 24 octobre 2013 09:54:06, kimaidou a écrit :
[..]

 In web mapping contexts, major improvements are made in 2D vector rendering
 speed by using WebGl technology, such as in upcoming OpenLayers 3. As a
 user point of view, improvement seems huge compared to classical DOM or
 more advanced CANVAS renderer.
 
 What about using graphic card to help improve rendering performance in QGIS
 ? Would this help a lot, or at the contrary would this be a dead-end ?

We would probably begin with porting QGIS to QT5, as OpenGL support has been 
added to QT5 and improved in 5.1.
See for example : 
http://qt-project.org/doc/qt-5.0/qtopengl/2dpainting.html

Otherwise, reimplementing an pure OpenGL rendering engine seems a big effort.
And we still would want to have a classic renderer for non-accelerated 
hardware.

One really interesting thing is that it would open the door for viewing 3D 
objects in QGIS. As for now to be able to see PostGIS 3D objects we had to 
develop our own external 3D viewer (horao). For that to happen we would need 
real 3D geometry support in QGIS too.

 I have seen the funding for having a multi-threaded rendering, this is why
 this idea came in mind. In twitter, Pirmin told me Marco made some advanced
 test. What were the conclusions ?

Interested in preliminary results as well.

Vincent

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

Re: [Qgis-developer] vector rendering improvement patch

[Vincent Picavet]

Hello,

Le mardi 22 octobre 2013 12:19:28, A Huarte a écrit :
 I have implemented the improvement of rendering in a new ad-hoc
 featureIterator with the possibility that each vector-provider implements
 its own method of pre-simplification. The performance is the same as the
 first version I developed (~3x faster :-)). It also implements the
 simplification of geometries in the OGR-provider pre-fetch the features.
 It improves the post-simplification around 5%. I think that this branch is
 ready por test! :-)

That's good news !

Is it configurable in the interface for each layer independantly ? 

It should probably be, as according to the style applied to the geometries, 
the simplification could be something we want for some layers and not for 
others.
A checkbox in the layer properties dialog could be interesting. 

Then we would have to decide if we want it activated by default or not for 
dataproviders supporting it. We could have a global option for that default 
too.

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

Re: [Qgis-developer] vector rendering improvement patch

[Vincent Picavet]

Hello,

Le mardi 22 octobre 2013 14:03:53, Andreas Neumann a écrit :
 Hi,
 
 Thank you for your work!
 
 Yes - I think it should be configurable. 

A use case is for example when a line of symbol symbology is used, with a 
symbol on each vertex. Simplifying the geometry, even when it is not 
supposed to be visible, could have undesired consequences on display.

 It should also automatically be
 turned off if a layer is in edit mode.
+1

Vincent

 
 Just my opinion,
 Andreas
 
 Am 22.10.2013 14:01, schrieb A Huarte:
  Hello Vincent!
  For now, it is not configurable, automatically applies to all vector
  layer to be painted.
  
  I think that the userneed not configure this, of course, if dev-community
  suggests, will be as you say! :-)
  
  Is it configurable in the interface for each layer independantly ? It
  should probably be, as according to the style applied to the
  geometries, the simplification could be something we want for some
  layers and not for others. A checkbox in the layer properties dialog
  could be interesting. Then we would have to decide if we want it
  activated by default or not for dataproviders supporting it. We could
  have a global option for that default too. Vincent
  
  
  ___
  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] QGIS 2 64bits, is it stable ?

[Vincent Picavet]

Hello,

Le jeudi 3 octobre 2013 13:13:10, Sandro Santilli a écrit :
 On Thu, Oct 03, 2013 at 12:00:05PM +0100, Jonathan Moules wrote:
  Assuming it's not already done, I'd suggest that requiring Unit Tests for
  all new features should be mandatory for a Pull Request/patch to be
  accepted into QGIS. In the long term that would hopefully help alleviate
  the significant number of regressions that we're seeing in 2.0.
 
 +1
 
 Of course providing tests will only be effective when there's also a rule
 of not accepting changes beaking any of the tests, and that's only
 effective when there's a continuous monitoring of testsuite runs. All of
 that is likely yet to be defined by the new Testing and QA Manager.

And another +1. It's time to focus on code quality to reduce bugs and 
maintainance costs, for which it is always difficult to find funding.
We need more unit test, more code quality dashboards and much stricter rules 
relative to what code has to be accepted into master.
A PostgreSQL-like code inclusion workflow, with commitfest and review, could be 
something interested, to be discussed.

On the funding side, for information, public administrations, at least in 
france, cannot pay for a time based contract. Estimating how much time a bug 
fix could take is a really hard task (except if you fixed the bug already). 
This 
is a problem both for company willing to fix bug for paid contracts and for 
public administrations wanting to finance bugs, and can explain the funding 
situation related to maintainance and bugfixing.

Vincent

 Speaking of which, the psc page describes the roles but there's no link
 to the currently appointed person for each role:
 http://www.qgis.org/en/site/getinvolved/governance/organisation/psc.html
 (nor links to contextualize the path that brings there from the homepage)
 
 --strk;
 
  Jonathan
  
  On 3 October 2013 11:51, Régis Haubourg
  regis.haubo...@eau-adour-garonne.fr
  
   wrote:
   
   Hi Matthias. agreed.
   How to fund, this is the question. I have budget (at least at the
   moment). I haven't been able to spend it completly in 2.0 release
   sprint because all goes too fast for classical contract, where I'm
   constrained to pay for a specific work (debug or feature).
   Please be warned to public finances are not good in europe, and every
   unconsumed budget can be erased.
   Sponsoring should be a way to finance infrastructure consolidation, but
   in current rules, sponsoring can't be oriented.
   
   I need help from the community to have a serious real use case unit
   test suite. I'm ready to fund a part if PSC gives an infrastructure
   and a manager. If no work canvas is given, I'm sure I won't have any
   successfull commercial proposal to such a funding.
   
   I also kindly ask other funders to systematically include unit test
   developpement for every new feature.
   
   Again today, I found 3 regressions, hard to find. I thought once 2.0
   was out, I could spend less time testing, and more time working. It's
   still not the case.
   
   Again, you gave a lot unpaid work, when I was struggling to find a way
   to spend some..
   Hope we'll find a way.
   Régis
 
 ___
 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] Vienna CodeSprint 2014 - OSGeo C-tribe

[Vincent Picavet]

Hi all,

I know you are heading to Brighton for the codesprint, but it's not a reason 
not to think about future gathering of C/C++ OSGeo developers :-)

The annual C-tribe OSGeo codesprint will take place in Europe in 2014 !
I think it is the first time it is held outside of the American continent.

The meeting will take place in Vienna, March 24-28 2014. It will probably last 
the full week.

It is a really good opportunity for the QGIS developers to meet and work 
closely with other OSGeo projects developers, so as to better integrate our 
tools.

If you are interested to come, please add yourself to the list on the 
dedicated wiki page :

http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014#Participants

Stephan Meißl is in charge of the organization, and you can subscribe to (and 
read the archives to know more) the mailing list : tospr...@lists.osgeo.org

The original message :
http://lists.osgeo.org/pipermail/tosprint/2013-August/000454.html

The mailing list page : 
http://lists.osgeo.org/pipermail/tosprint/

The codesprint is also looking for sponsors, so do not hesitate to give a hand 
and contact Stephan ( step...@meissl.name )

I hope to see a lot of you there, leading OpenSource GIS stacks to new 
horizons :-)

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

Re: [Qgis-developer] QGIS 2.0.1 Final Tagged - call for packaging

[Vincent Picavet]

Le mercredi 11 septembre 2013 13:49:39, Alexander Bruy a écrit :
 BTW, should we rename out GitHub repository? It still
 Quantum-GIS not QGIS

+1
Generally, since the name changed officially, we should do a Quantum Hunting 
party, so that the transition is made faster and users do not get confused.
Vincent

 
 2013/9/11 Tim Sutton li...@linfiniti.com:
  Dear QGIS devs  packagers
  
  This is a copy and paste of my previous email for the 2.0 release, but
  with details added for the 2.0.1 bugfix. The bugfix addresses concerns
  about the missing swisstopo acknowledgement for the splash screen map
  and in the process introduces a few small cleanups and bug fixes, plus
  an update for spanish translations.
  
  Note that I will be travelling to Brighton now so any further point
  releases will need to be made when I arrive (of course they won't be
  needed right?).
  
  Packagers, please discard packaging effors on 2.0.0 and focus rather on
  2.0.1. Updated content follows:
  
  --- Note to casual readers ---
  
  Please do not pre-announce this release - give the packagers and release
  team a chance to do their thing so that people hearing about the release
  have a fair chance of finding a package, reading all our press material
  etc.
  
  Especially for this release, I would like to coincide the release
  announcement with the launch of our new web site which the community team
  and opengeo have been working really hard at. So please wait until we are
  ready to announce before blogging, tweeting, etc, about the new release.
  
  --- End note ---
  
  I have tagged QGIS 2.0.1 for release. The branch can be checked out like
  this (as a tracking branch)
  
  git clone git://github.com/qgis/Quantum-GIS.git
  git branch --track release-2_0 origin/release-2_0
  git checkout release-2_0
  
  Or (to check out the final tagged version made a few hours ago):
  
  git fetch
  git checkout final-2_0_1
  
  The tag is signed with my GPG key:
  
  user: Tim Sutton (QGIS Key) t...@linfiniti.com
  1024-bit DSA key, ID 97626237, created 2007-07-19
  
  Source tarballs can be obtained from here:
  
  http://qgis.org/downloads/qgis-2.0.1.tar.bz2
  http://qgis.org/downloads/qgis-2.0.1.tar.bz2.md5
  
  Packagers:
  
  Please hold your packages until you hear more from me so that we can
  coordinate the release announcement with the new web site announcement. I
  expect that will be at the end of this week or over the weekend coming.
  
  Some notes:
  
  - Please do not commit anything to the 2_0 branch except packaging
  related tweaks pending further notification from myself or Juergen.
  - If you make a package please be so kind as to update the download wiki
  page at http://www.qgis.org/wiki/Download with the details of your
  package (taking into account the hold-until-the-site-is-ready note
  above). - If you are able to make packages for unlisted platforms /
  distros please discuss your plans on this thread so that we can avoid
  duplication of effort.
  - I would like to make the release announcement next week, so it will be
  great to have as many packages as possible ready by then.
  - GIT master is open again for general commits - please seek guidance
  from Marco Hugentobler (PSC Code Manager) if you are planning any major
  code changes.
  - Juergen Fischer (incoming PSC Release Manager) will be managing the
  release process for future releases, so please follow his lead in terms
  of code freeze etc in master.
  
  Many thanks to all the developers, testers, bug fixers, bug reporters,
  document writers, translators and users that help to make QGIS 2.0 a
  reality!
  
  Lastly can I call on the release team (or any interested people) to help
  to put together visual changelog (link below), press announcements etc.
  ready for the release date? I will send you an email when the packages
  are ready and you can start broadcasting announcements.
  
  Visual Changelog Page: http://changelog.linfiniti.com/version/1/ (this is
  the site for drafting the release, the final release content will be on
  the official QGIS web site). Please contact me if you would like to
  contribute to the changelog and I will give you the needed permissions.
  
  
  Best regards
  
  --
  Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
  ==
  Please do not email me off-list with technical
  support questions. Using the lists will gain
  more exposure for your issues and the knowledge
  surrounding your issue will be shared with all.
  
  Irc: timlinux on #qgis at freenode.net
  ==
  
  ___
  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 2.0.0 Final Tagged - call for packaging

[Vincent Picavet]

Hi Tim, all,

Le lundi 9 septembre 2013 04:38:14, Tim Sutton a écrit :
[..]
 Visual Changelog Page: http://changelog.linfiniti.com/version/1/ (this is
 the site for drafting the release, the final release content will be on the
 official QGIS web site). Please contact me if you would like to contribute
 to the changelog and I will give you the needed permissions.

We should clearly state in the Changelog as well that Quantum GIS officially 
changed its name to QGIS !

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

Re: [Qgis-developer] Ubuntu QGIS Master package

[Vincent Picavet]

Hi Jurgen,

 On Tue, 06. Aug 2013 at 09:34:08 +1200, Jeremy Palmer wrote:
  But the Ubuntu GIS unstable doesn't include master builds does it?
 
 Right.  Is there anything wrong with our ubuntugis nightly builds?

Any chance to have raring added to it ?

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

Re: [Qgis-developer] [Qgis-user] Synergy of QGIS Enterprise and QGIS 2.0/Master branch

[Vincent Picavet]

Hello,


Le vendredi 5 juillet 2013 11:13:47, Werner Macho a écrit :
 Hi!
 
 My suggestion to solve that kind of problems would be to just have a
 
 something|. based on QGIS

+1 for that, clear and efficient.

Vincent

 
 but I appreciate the appearance of the enterprise QGIS and hope that
 it will QGIS itself some push to be more known by companies ..
 
 regards
 Werner
 
 
 On Fri, Jul 5, 2013 at 11:07 AM, Giuseppe Sucameli
 
 brush.ty...@gmail.com wrote:
  Hi all,
  
  On Fri, Jul 5, 2013 at 9:13 AM, Pirmin Kalberer pi...@sourcepole.com
  
  wrote:
   Pirmin what happens if / when QGIS project itself wants to release
   QGIS Enterprise version - or another company? Maybe it would be
   better to call
   it 'Sourcepole GIS' or something to make it clear that it is not an
   official QGIS product but an official Sourcepole product?
  
  I think a completely different name of a new GIS which is very
  similar to
  QGIS could be more confusion than one or many QGIS variants.
  
  I agree with Pirmin, a product with a completely different name sounds
  like a new GIS software.
  In addition, not keeping the relation with the QGIS project may damage
  the project itself in the long run.
  
  Why do not put the company name in the front, something like
  Sourcepole QGIS Cloud/Enterprise?
  This makes everything more clear and allows others companies, but mainly
  the QGIS project itself, to create its own version.
  
  Just my 2 cents.
  
   Also (out of curiosity) what is to stop one of your clients cloning
   the private source tree that you provide and then making that
   publicly available - or just pushing it back in to the mainstream
   QGIS tree? i.e. do
   you realise any real long term benefit from keeping the tree private
   in the
   first place?
  
  We didn't think a lot about publishing our source code branch, yet. So
  this
  could happen anytime. The question why clients do not publish sources of
  commercial FOSS software is hard to answer. Maybe it's a question of
  loality?
  
  Regards
  Pirmin
  
  [1] http://en.wikipedia.org/wiki/Commercial_open_source_applications
  
   On Mon, Jul 1, 2013 at 2:50 PM, Nathan Woodrow madman...@gmail.com
   
   wrote:
On Mon, Jul 1, 2013 at 9:25 PM, Yves Jacolin (Free)
  
  yjaco...@free.frwrote:
My understanding is that it is a commercial service, so you don't
have
any
licence.

No.  It's still GPL.

Any support docs, or training sourcepole provide however are not.
Only the
QGIS software bit part

- Nathan

___
Qgis-user mailing list
qgis-u...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-user
  
  --
  Pirmin Kalberer
  Sourcepole  -  Linux  Open Source Solutions
  http://www.sourcepole.com
  
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
  
  --
  Giuseppe Sucameli
  
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
 
 ___
 Qgis-user mailing list
 qgis-u...@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-user
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] New feature's needed, create geometry from attribute

[Vincent Picavet]

Hi Regis, all,

You can also open a CSV with X.Y coordinates with a VRT file describing the 
geometry component. You could automatically generate and load such a VRT with 
an interface to guide the user.

Vincent

Le lundi 1 juillet 2013 09:48:00, HAUBOURG a écrit :
 Hi all, let me precise the need:
 Numerical vertex edit and wkt plugin are usefull when dealing with one
 geometry. Geom calculation with field update can create eventually a WKB,
 but it's absolutely not user friendly, and there is actually no way to
 load a layer from that in a file based layer.
 
 Think of a user getting a excel or calc spreadsheet with XY inside. The
 only way to import it directly as a spatial layer (not talking about using
 sqlite or postgis.. too complex for common users not even aware of data
 source types) is too export it to csv and import it with delimited text
 plugin. That is always a pain since no tool exports csv in the same way
 when dealing with numerical / text types, decimal separators... XLS, calc,
 dbf do type correctly fields and avoid any file conversion (if no formula
 or problem in field names today). Importing directly the datasource, and
 being able to spatialize it afterwards , only if needed (join pure
 attribute data is also a use case), would be nice.
 
 So is the need for my corp.
 My question : I would like to avoid data duplication (again) , is that
 feasible using pluginlayerType in python API todayu, or do I need some
 core modifications ? Of course, that need to be reloaded correctly with a
 project file.
 
 Régis
 
 
 
 
 Cordialement,
 Régis Haubourg
 ---
 - Régis Haubourg
 
 Administrateur de données Géographiques
 Département des Systèmes d'Information (DCSI)
 Agence de l'eau Adour Garonne
 90 rue du Férétra,
 31078 Toulouse Cedex4
 Tél: 05 61 36 82 58
 Mail:
 regis.haubo...@eau-adour-garonne.frmailto:regis.haubourg@eau-adour-garonn
 e.fr [cid:image002.jpg@01CE5BAA.92C70ED0]
 http://www.eau-adour-garonne.frhttp://www.eau-adour-garonne.fr/
 
 Accédez aux données sur l'eau  :
 http://adour-garonne.eaufrance.fr/
 
 De : kimaidou [mailto:kimai...@gmail.com]
 Envoyé : dimanche 30 juin 2013 22:00
 À : Anita Graser
 Cc : Alexander Bruy; qgis-developer; HAUBOURG
 Objet : Re: [Qgis-developer] New feature's needed, create geometry from
 attribute
 
 Hi
 What about using the field calculator ? I think I have seen a method in the
 geometry tools : something like geomfromwkt ? If needed, we could simply
 add a way to modifiy the features geometry with the field calculator, and
 it will do the trick.
 
 
 2013/6/30 Anita Graser anitagra...@gmx.atmailto:anitagra...@gmx.at
 The Quick WKT plugin does something very similar.
 Anita
 
 On Sun, Jun 30, 2013 at 3:06 PM, Alexander Bruy
 alexander.b...@gmail.commailto:alexander.b...@gmail.com wrote: Hi,
 what about NumericalVertexEdit plugin? If I understand correctly, it do
 what you need.
 
 2013/6/30 Régis Haubourg regis.haubourg@eau-adour-
garonne.frmailto:regis.haubo...@eau-adour-garonne.fr:
  Hi all,
  After some training courses here, a very common use case is not satisfied
  easily:
  
  The only entry to create geometry from text (XY or WKT) is the delimited
  text plugin.
  It appears that having a separate fonction create point like in Mapinfo
  or Arcgis would be really handy, and could avoid the need of csv import.
  
  I was thinking of making a plugin for this, but I'm wondering what is the
  best approach.
  
   1- duplicate layer into a memory layer. Easy, requires MemoryLayerSaver
   to
  
  make data persistent, is not dynamic with datasource.
  
   2- create a pluginLayer? I'm not sure it will do what I need. I would
   like
  
  the project to keep a reference to the datasource (xls, whatever ogr/
  postgres/ sqlite/ spatialite) and replace or create geometry on load by
  reading XY columns or WKT column.
  
  Is that feasable in a plugin,  as a proof of concept, or does it require
  core classes modifications (C++ work , so I won't do it by myself)
  
  Thanks for your tips,
  Régis
 
 --
 Alexander Bruy
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.orgmailto:Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer
 
 
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.orgmailto: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