[QGIS-Developer] Plugin [270] Geospatial Simulation approval notification.

[noreply]

Plugin Geospatial Simulation approval by pcav.
The plugin version "[270] Geospatial Simulation 1.3" is now approved
Link: http://plugins.qgis.org/plugins/geospatialsimulation/
___
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] Tackling Postgis layers connection recover

[Paolo Cavallini]

Agreed, a long standing annoying issue. Thanks for taking it.
Cheers.

Il 4 febbraio 2019 23:32:39 CET, Nyall Dawson  ha 
scritto:
>On Tue, 5 Feb 2019 at 05:54, Timothé Perez
> wrote:
>>
>> Hello qgis-devs,
>>
>> This is my first message here and first contribution to QGIS, so I
>thank you in advance for being indulgent and do not hesitate to correct
>me on any mistake I will make.
>> I didn't want to jump right into proposing my patch "as is" in a PR
>as I'm new to this project, so first I wanted to discuss about it to
>make sure I got it right.
>>
>> Here's a recap of what I have found so far (sorry if it's a bit
>long):
>>
>> I'm using QGIS 3.4 with a PostgreSQL database to store layers and I'm
>facing the same issue as described in
>https://issues.qgis.org/issues/20170 : unrecoverable PostgreSQL
>connections.
>>
>> I have cloned the repo and started to dig, as it is really annoying
>because it forces you to abandon your changes and close and reopen your
>project.
>
>Upfront, thanks for the great attitude. This is one of the MOST
>effective ways to get bugs fixed... rolling up your sleeves and fixing
>them yourself!
>
>> To reproduce the problem, the simplest way is to spin a local
>PostgreSQL database with postgis and create a table with just a serial
>and a geometry:
>>  CREATE TABLE foo (id serial primary key, geometry GEOMETRY(POINT,
>4326));
>>
>> Open it in QGIS, create several features, save them then simply
>restart the PostgreSQL service so that all connections are forced to be
>closed.
>> QGIS logs will display that the connections to PostgreSQL were lost
>but recovered and features will still be accessible.
>>
>> However if I start editing the layer by adding a feature and then
>call save, it will fail:
>>
>> 2019-02-04T19:11:30 CRITICALLayer foo : PostGIS error while
>adding features: FATAL: terminating connection due to administrator
>command
>>  la connexion au serveur a été coupée de façon inattendue
>>   Le serveur s'est peut-être arrêté anormalement avant ou
>durant le
>>   traitement de la requête.
>>
>> 2019-02-04T19:11:30 WARNINGCommit errors : Could not commit
>changes to layer foo
>> 2019-02-04T19:11:34 CRITICALLayer foo : PostGIS error while
>adding features: no result buffer
>> 2019-02-04T19:11:34 WARNINGCommit errors : Could not commit
>changes to layer foo
>>
>> My only option is to cancel my edits and reload the project to regain
>full access to the db.
>>
>> So in fact this problem has 2 causes: (time to dig in the C++ code)
>>
>*snip*
>>
>> I am willing to propose a PR if my fixes make sense and are
>acceptable, this will fix an annoying issue.
>
>They both sound reasonable to me, and yes, valuables fixes for an
>annoying issues! Looking forward to the PRs! (One request: please file
>these as two separate PRs, so both fixes can be discussed and reviewed
>independently.)
>
>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

-- 
Sorry for being short___
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] Find unmaintained plugins

[Thomas Baumann]

Hi Paolo,
I opened a ticket now:

https://issues.qgis.org/issues/21164

Regards,
Thomas



Am Sa., 2. Feb. 2019, 08:30 hat Paolo Cavallini 
geschrieben:

> Thanks for your offer of help. I agree that the mail should be sent only
> for plugins not updated in the last (3? 6? 9?) months.
> Could you please start filling up a ticket on
> https://issues.qgis.org/issues
> so we can define specs resulting from this thread and start implementing
> it?
> Cheers.
>
> On 01/02/19 22:40, Thomas Baumann wrote:
> > Hi Paolo,
> >
> > sounds like a good idea to send a reminder once a year to the maintainer
> > and mark plugins as unmaintained if no feedback is received.
> >
> > I am available to help implementing it.
> >
> > Regards,
> > Thomas
> >
> >
> > Am Fr., 1. Feb. 2019, 19:01 hat Paolo Cavallini  > > geschrieben:
> >
> > Hi Thomas,
> >
> > On 01/02/19 13:53, Thomas Baumann wrote:
> >
> > > I made the experience that there are QGIS-plugins which are not
> > > maintained anymore.
> > > Example:
> > >
> >
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Rectangles-Ovals-Digitizing-plugin-deprecated-td5366686.html
> > >
> > > Recently I asked some maintainers if they have plans to update
> their
> > > plugins to be QGIS3-ready because I was willing to update them if
> the
> > > maintainer wouldn't do it... but again I got the impression that
> some
> > > plugins are not maintained anymore.
> > > Example:
> > > https://github.com/NathanW2/selection-sets/issues/5
> > >
> > > Now that there is the change from QGIS2 to QGIS3 some unmaintained
> > > plugins will just dissapear like through a "natural selection".
> But in
> > > one or two years there could again be lots of unmaintained plugins
> > which
> > > could have bugs that slow down qgis or make them unstable like it
> > > happened with the Rectangles-Ovals-Digitizing-plugin (
> > > https://github.com/vinayan/RectOvalDigitPlugin/issues/6 ).
> > >
> > > Wouldn't it make sense to check once a year if all plugins are
> still
> > > maintained?
> > >
> > > You could for example use something like LimeSurvey (
> > > https://www.limesurvey.org/community ) and ask every maintainer to
> > > respond if they still feel responsible for the plugin. In the
> > backend of
> > > Limesurvey you have a database with the responses so it should be
> > quite
> > > easy to automatically synchronize the results with your
> > repository-items.
> > > This way the unmaintained plugins could be marked as deprecated if
> no
> > > response is sent back.
> >
> > thanks a lot for your suggestion. I agree that the move to QGIS 3
> > automatically purges old unmaintained code, but this does not solve
> > entirely the issue.
> > In short do you suggest we should run a survey once a year, sending
> it
> > to the list of plugin maintainers, and marking as deprecated all
> plugins
> > for which we do not receive a positive response?
> > I would be a bit skeptical, as many plugins are still useful even if
> not
> > actively maintained. An alternative would be to add to our Django
> app an
> > automatic reminder to be sent to maintainer, asking to confirm they
> > maintenance; in absence of a feedback, we could mark it as
> unmaintained,
> > and make this visible to users, so they have the options of adopting
> it,
> > supporting it, or stopping using it before it actually stops working.
> > How does it sound? in case you agree on this or a modified version of
> > it, would you be available to help implementing this?
> > All the best.
> > --
> > Paolo Cavallini - www.faunalia.eu 
> > QGIS.ORG  Chair:
> > http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org  QGIS-Developer@lists.osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>
___
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] Tackling Postgis layers connection recover

[Nyall Dawson]

On Tue, 5 Feb 2019 at 05:54, Timothé Perez  wrote:
>
> Hello qgis-devs,
>
> This is my first message here and first contribution to QGIS, so I thank you 
> in advance for being indulgent and do not hesitate to correct me on any 
> mistake I will make.
> I didn't want to jump right into proposing my patch "as is" in a PR as I'm 
> new to this project, so first I wanted to discuss about it to make sure I got 
> it right.
>
> Here's a recap of what I have found so far (sorry if it's a bit long):
>
> I'm using QGIS 3.4 with a PostgreSQL database to store layers and I'm facing 
> the same issue as described in https://issues.qgis.org/issues/20170 : 
> unrecoverable PostgreSQL connections.
>
> I have cloned the repo and started to dig, as it is really annoying because 
> it forces you to abandon your changes and close and reopen your project.

Upfront, thanks for the great attitude. This is one of the MOST
effective ways to get bugs fixed... rolling up your sleeves and fixing
them yourself!

> To reproduce the problem, the simplest way is to spin a local PostgreSQL 
> database with postgis and create a table with just a serial and a geometry:
>  CREATE TABLE foo (id serial primary key, geometry GEOMETRY(POINT, 4326));
>
> Open it in QGIS, create several features, save them then simply restart the 
> PostgreSQL service so that all connections are forced to be closed.
> QGIS logs will display that the connections to PostgreSQL were lost but 
> recovered and features will still be accessible.
>
> However if I start editing the layer by adding a feature and then call save, 
> it will fail:
>
> 2019-02-04T19:11:30 CRITICALLayer foo : PostGIS error while adding 
> features: FATAL: terminating connection due to administrator command
>  la connexion au serveur a été coupée de façon inattendue
>   Le serveur s'est peut-être arrêté anormalement avant ou durant 
> le
>   traitement de la requête.
>
> 2019-02-04T19:11:30 WARNINGCommit errors : Could not commit changes 
> to layer foo
> 2019-02-04T19:11:34 CRITICALLayer foo : PostGIS error while adding 
> features: no result buffer
> 2019-02-04T19:11:34 WARNINGCommit errors : Could not commit changes 
> to layer foo
>
> My only option is to cancel my edits and reload the project to regain full 
> access to the db.
>
> So in fact this problem has 2 causes: (time to dig in the C++ code)
>
*snip*
>
> I am willing to propose a PR if my fixes make sense and are acceptable, this 
> will fix an annoying issue.

They both sound reasonable to me, and yes, valuables fixes for an
annoying issues! Looking forward to the PRs! (One request: please file
these as two separate PRs, so both fixes can be discussed and reviewed
independently.)

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

Re: [QGIS-Developer] Convert arcgis style file to qgis style file

[Andreas Neumann]

Hi Shane,

Yes - absolutely.

Have a look at 
https://north-road.com/2019/02/04/announcing-our-slyr-funding-drive/


This initiative was announced by Nyall today, but there is already 
existing work that his current proposal builds on. So Nyall already has 
collected a lot of knowledge around the reverse engineering of the 
undocumented ArcGIS .lyr and .mxd formats.


You can discuss details with Nyall and you are welcome to join the effort.

Greetings,

Andreas

Am 04.02.19 um 19:31 schrieb Shane Carey:

Hi,

Just wondering is there anything in the pipeline (plugin) to convert 
arcgis style file to qgis style file?

Thanks
--
Le gach dea ghui,
*/Shane Carey/*
*/GIS and Data Solutions Consultant/*

___
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] Find unmaintained plugins

[Stefan Keller]

Hi,

Am Mo., 4. Feb. 2019 um 17:07 Uhr schrieb Thomas Baumann <
rdbath.regiod...@gmail.com>:

> But at the same time you have to see that buggy unmaintained plugins can
> cause a lot of frustration to users.
> I have made the experience that problems caused by such plugins are also
> actually very bad for the reputation of qgis.
>

I also see a need to inform users about buggy or not-working plugins.
Obviously the votes are not having this effect (since they only increase?).

But "maintained" does not mean "bug-free"  - as you all know e.g. from
commercial SW ;-).
And open source SW dev and maintenance in ones leisure time does not get
better when you get an flaq "unmaintained" on your plugin.

I'm thinking along the line to allow comments in the repo
http://plugins.qgis.org (always with mandatory info about version of
plugin, OS, etc.).
And in almost any  case, we need more maintainer (sic!) efforts to maintain
the plugin repo.

:Stefan

Am Mo., 4. Feb. 2019 um 17:07 Uhr schrieb Thomas Baumann <
rdbath.regiod...@gmail.com>:

> Hi,
> I can understand concerns about not wanting to discourage maintainers.
>
> But at the same time you have to see that buggy unmaintained plugins can
> cause a lot of frustration to users.
> I have made the experience that problems caused by such plugins are also
> actually very bad for the reputation of qgis.
> (Because most of the users (and the deciders in a company) won't
> differentiate between qgis "core" and the plugins which are distributed
> over the official(!) repository. From their point of view qgis is just
> buggy.)
>
> I think it's just fair to inform the user if a plugin is still maintained
> or not and to be honest I don't quite understand why it should be too hard
> to click on a confirmation-link once a year to prove that you still
> maintain a plugin.
>
> If the maintainer does not want to respond or does not find the time to
> click the link than I guess it just reflects the fact that the plugin isn't
> maintained by this person anymore.
>
>
> For qgis 2.18 there were more than 800 plugins in the official repository
> and I guess that in some years there could be even more plugins available
> for qgis 3.
>
> I think it will be hard to keep qgis3 stable and performant if buggy
> unmaintained plugins won't be sorted out or at least marked as unmaintained.
>
> Regards,
> Thomas
>
>
>
>
>
>
>
>
> Am Mo., 4. Feb. 2019, 15:25 hat Tim Sutton  geschrieben:
>
>> Hi
>>
>>
>> On 04 Feb 2019, at 00:30, Nyall Dawson  wrote:
>>
>> On Mon, 4 Feb 2019 at 00:57, Matthias Kuhn  wrote:
>>
>>
>> Hi Paolo
>>
>> On 2/3/19 1:39 PM, Paolo Cavallini wrote:
>>
>> Hi Matthias,
>>
>> On 03/02/19 10:17, Matthias Kuhn wrote:
>>
>> Marking a plugin as "unmaintained" or "deprecated" is a heavy action
>> which may discourage developers and make even useful plugins disappear.
>>
>>
>> deprecated yes, unmaintained not necessarily. We could just let the user
>> know, perhaps suggesting a way to solve this, without removing them for
>> the list of available plugins (just like the Featured tag).
>>
>>
>> Then I misunderstood the goal of this proposal, sorry.
>>
>> I was imagining myself looking through a plugin list of a software of
>> which I am an ordinary user and seeing a plugin tagged as
>> "unmaintained". This would make me think it's unreliable, outdated and
>> unstable and hence not recommended.
>>
>>
>> I think this actually IS the intention here.
>>
>> But, as you've pointed out, no activity =/= unmaintained, as sometimes
>> no activity just means bug free and feature complete. In this case I
>> think it's fine to require developers to respond to a quick "is this
>> still maintained" survey in order to avoid the flag.
>>
>>
>> And sometimes even if the plugin is unmaintained it is still useful to
>> lots of people (even if it has a few known bugs)…..
>>
>> I’m not sure if flagging plugins as unmaintained is always so nice.. I
>> would favour an approach where we could just list plugins in the plugin
>> manager based on the date of their last release, most recent first so that
>> you can see old versus new
>>
>> Definitely -1 here on removing plugins that are orphaned unless they are
>> part of a security / data integrity risk. Many people may have built up
>> specific workflows around the existence of a particular plugin or two and
>> there is no need to break this for people even if the plugin is orphaned…
>>
>> Regards
>>
>> Tim
>>
>>
>>
>> —
>>
>>
>>
>>
>>
>>
>>
>> *Tim Sutton*
>>
>> *Co-founder:* Kartoza
>> *Ex 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: 

[QGIS-Developer] Tackling Postgis layers connection recover

[Timothé Perez]

Hello qgis-devs,

This is my first message here and first contribution to QGIS, so I thank you in 
advance for being indulgent and do not hesitate to correct me on any mistake I 
will make.
I didn't want to jump right into proposing my patch "as is" in a PR as I'm new 
to this project, so first I wanted to discuss about it to make sure I got it 
right.

Here's a recap of what I have found so far (sorry if it's a bit long):

I'm using QGIS 3.4 with a PostgreSQL database to store layers and I'm facing 
the same issue as described in https://issues.qgis.org/issues/20170 : 
unrecoverable PostgreSQL connections.

I have cloned the repo and started to dig, as it is really annoying because it 
forces you to abandon your changes and close and reopen your project.

To reproduce the problem, the simplest way is to spin a local PostgreSQL 
database with postgis and create a table with just a serial and a geometry:
 CREATE TABLE foo (id serial primary key, geometry GEOMETRY(POINT, 4326)); 

Open it in QGIS, create several features, save them then simply restart the 
PostgreSQL service so that all connections are forced to be closed.
QGIS logs will display that the connections to PostgreSQL were lost but 
recovered and features will still be accessible.

However if I start editing the layer by adding a feature and then call save, it 
will fail:

2019-02-04T19:11:30 CRITICALLayer foo : PostGIS error while adding 
features: FATAL: terminating connection due to administrator command
 la connexion au serveur a été coupée de façon inattendue
  Le serveur s'est peut-être arrêté anormalement avant ou durant le
  traitement de la requête.

2019-02-04T19:11:30 WARNINGCommit errors : Could not commit changes to 
layer foo
2019-02-04T19:11:34 CRITICALLayer foo : PostGIS error while adding 
features: no result buffer
2019-02-04T19:11:34 WARNINGCommit errors : Could not commit changes to 
layer foo

My only option is to cancel my edits and reload the project to regain full 
access to the db.

So in fact this problem has 2 causes: (time to dig in the C++ code) 

First:

The QgsPostgresProvider::connectionRO() method does not offer a proper way to 
reset the connection when the connection was lost; therefore every SELECT after 
a connection was lost will  cause the Q_ASSERT to fail in  
src/providers/postgres/qgspostgresconn.cpp, line 86 and will promptly crash my 
debug build of QGIS.

Let's take for example QgsPostgresProvider::featureCount(): it checks 
connectionRO in case it is null, but doesn't check if the connection is still 
valid and will call connectionRO()->PQexec( sql ) in any case. Now PQexec is 
indeed checking the connection status, but will not try to reset the connection 
and will simply return a nullptr, which is then passed to 
QgsPostgresResult::PQgetvalue and will cause the assert to fail. 

Note that PQexecNR is properly handling checks on the status and will call 
PQreset, resulting in a successful re-connection and request to Postgresql ( 
that's why other connections are not affected and can recover) but PQexecNR is 
never called on ConnectionRO, so the connection remains staled.

I see 2 paths to fix this issue:

- Implement a check in  QgsPostgresProvider::connectionRO()  that will call a 
new QgsPostgresConn::PQreset method  which in turn call libpq PQreset on its 
mConn attribute, resulting in a proper connection reset. As ConnectionRO is 
const, we can't simply create a new connection so we can only reset the 
existing one. 

- Implement the same logic as in PQexecNR to handle reset in case of staled 
connection, ie add a retry flag and a call to libpq PQreset.

I quickly tried the first approach and it fixed the issue; however this does 
not provide an automatic retry mechanism on the first failure, so maybe the 
second one is better.


Now the second cause:

I couldn't understand why QGIS was emitting a SELECT statement before an 
INSERT, and the answer is simple:

2019-02-04T19:11:34 WARNINGConnection error: SELECT 
nextval('foo_id_seq'::regclass) returned 1 [FATAL: terminating connection due 
to administrator command

Right before the INSERT query ( which would otherwise work), QGIS makes a 
SELECT to get the default value for the primary key field.

The culprit here is a bad condition in the optimization in  
QgsPostgresProvider::addFeatures when it checks for a PK field which is using a 
sequence: it only checks if the value is not null, but as a primary key in not 
null by definition, QGIS automatically sets the not null constraint and default 
to the SQL default of nextval('foo_id_seq'::regclass). So in fact the 
optimization is never used and a SELECT is issued. Adding a check to ensure 
value does not start with next_val  fixes the issue and the optimization is 
used.


I am willing to propose a PR if my fixes make sense and are acceptable, this 
will fix an annoying issue.

Thanks in advance for your 

Re: [QGIS-Developer] Find unmaintained plugins

[Paolo Cavallini]

Hi all,

On 04/02/19 15:25, Tim Sutton wrote:

>> On 04 Feb 2019, at 00:30, Nyall Dawson > > wrote:
>>
>> On Mon, 4 Feb 2019 at 00:57, Matthias Kuhn > > wrote:

>>> On 2/3/19 1:39 PM, Paolo Cavallini wrote:
 Hi Matthias,

 On 03/02/19 10:17, Matthias Kuhn wrote:

> Marking a plugin as "unmaintained" or "deprecated" is a heavy
> action which may discourage developers and make even useful plugins
> disappear.

 deprecated yes, unmaintained not necessarily. We could just let the user
 know, perhaps suggesting a way to solve this, without removing them for
 the list of available plugins (just like the Featured tag).
>>>
>>> Then I misunderstood the goal of this proposal, sorry.
>>>
>>> I was imagining myself looking through a plugin list of a software of
>>> which I am an ordinary user and seeing a plugin tagged as
>>> "unmaintained". This would make me think it's unreliable, outdated and
>>> unstable and hence not recommended.
>>
>> I think this actually IS the intention here.
>>
>> But, as you've pointed out, no activity =/= unmaintained, as sometimes
>> no activity just means bug free and feature complete. In this case I
>> think it's fine to require developers to respond to a quick "is this
>> still maintained" survey in order to avoid the flag.

yes, thanks for making this point more clear

> And sometimes even if the plugin is unmaintained it is still useful to
> lots of people (even if it has a few known bugs)…..
> 
> I’m not sure if flagging plugins as unmaintained is always so nice.. I
> would favour an approach where we could just list plugins in the plugin
> manager based on the date of their last release, most recent first so
> that you can see old versus new

this also makes sense, even though there are plugins that are updated
very frequently without this meaning they are especially useful

> Definitely -1 here on removing plugins that are orphaned unless they are
> part of a security / data integrity risk. Many people may have built up
> specific workflows around the existence of a particular plugin or two
> and there is no need to break this for people even if the plugin is
> orphaned…

agreed

Thanks
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
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] Find unmaintained plugins

[Paolo Cavallini]

Hi Werner,

On 04/02/19 16:05, Werner Macho wrote:
> Hi,
> 
> I also dislike the idea of removing plugins completely, as already
> pointed oout sometimes a plugin "just works" and there is no real
> maintenance needed.
> Also - even it is not maintained anymore the code inside can still be
> useful to create something new out of it. And without seeing the plugin
> everything would have to be invented again.
> 
> so -1 from my side for  removing plugins that are orphaned unless they
> are part of a security / data integrity risk too. 

I don't think anybody wants to *remove* a plugin, just eventually tag it
to make it clear its situation to the user, or at worst deprecate it.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
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] Find unmaintained plugins

[Paolo Cavallini]

Hi Sandro,

On 04/02/19 16:39, Sandro Santilli wrote:

> Could the GUI invite users to _become_ maintainers ?

wording should be careful here, not to confuse users. Something like
"Can you write Python code? Please consider adopting this plugin" with a
pointer to instructions etc.
Thanks for the suggestion. Better start noting it down somewhere (a
QEP?), not to miss the many ideas tha are coming.
Cheers.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
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] Convert arcgis style file to qgis style file

[Shane Carey]

Hi,

Just wondering is there anything in the pipeline (plugin) to convert arcgis
style file to qgis style file?
Thanks
-- 
Le gach dea ghui,
*Shane Carey*
*GIS and Data Solutions Consultant*
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [390] HTP Geoprocessor approval notification.

[noreply]

Plugin HTP Geoprocessor approval by pcav.
The plugin version "[390] HTP Geoprocessor 1.1" is now unapproved
Link: http://plugins.qgis.org/plugins/htpgeoprocessor/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [390] HTP Geoprocessor unapproval notification.

[noreply]

Plugin HTP Geoprocessor unapproval by pcav.
The plugin version "[390] HTP Geoprocessor 1.0" is now unapproved
Link: http://plugins.qgis.org/plugins/htpgeoprocessor/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [390] HTP Geoprocessor approval notification.

[noreply]

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

[QGIS-Developer] Plugin [1462] Repair Lines Connections approval notification.

[noreply]

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

[QGIS-Developer] Plugin [1628] GxABT - FixLambert72 approval notification.

[noreply]

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

[QGIS-Developer] Plugin [1628] GxABT - FixLambert72 approval notification.

[noreply]

Plugin GxABT - FixLambert72 approval by pcav.
The plugin version "[1628] GxABT - FixLambert72 0.1 Experimental" is now 
approved
Link: http://plugins.qgis.org/plugins/fix_lambert72/
___
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] Find unmaintained plugins

[Thomas Baumann]

Hi,
I can understand concerns about not wanting to discourage maintainers.

But at the same time you have to see that buggy unmaintained plugins can
cause a lot of frustration to users.
I have made the experience that problems caused by such plugins are also
actually very bad for the reputation of qgis.
(Because most of the users (and the deciders in a company) won't
differentiate between qgis "core" and the plugins which are distributed
over the official(!) repository. From their point of view qgis is just
buggy.)

I think it's just fair to inform the user if a plugin is still maintained
or not and to be honest I don't quite understand why it should be too hard
to click on a confirmation-link once a year to prove that you still
maintain a plugin.

If the maintainer does not want to respond or does not find the time to
click the link than I guess it just reflects the fact that the plugin isn't
maintained by this person anymore.


For qgis 2.18 there were more than 800 plugins in the official repository
and I guess that in some years there could be even more plugins available
for qgis 3.

I think it will be hard to keep qgis3 stable and performant if buggy
unmaintained plugins won't be sorted out or at least marked as unmaintained.

Regards,
Thomas








Am Mo., 4. Feb. 2019, 15:25 hat Tim Sutton  geschrieben:

> Hi
>
>
> On 04 Feb 2019, at 00:30, Nyall Dawson  wrote:
>
> On Mon, 4 Feb 2019 at 00:57, Matthias Kuhn  wrote:
>
>
> Hi Paolo
>
> On 2/3/19 1:39 PM, Paolo Cavallini wrote:
>
> Hi Matthias,
>
> On 03/02/19 10:17, Matthias Kuhn wrote:
>
> Marking a plugin as "unmaintained" or "deprecated" is a heavy action which
> may discourage developers and make even useful plugins disappear.
>
>
> deprecated yes, unmaintained not necessarily. We could just let the user
> know, perhaps suggesting a way to solve this, without removing them for
> the list of available plugins (just like the Featured tag).
>
>
> Then I misunderstood the goal of this proposal, sorry.
>
> I was imagining myself looking through a plugin list of a software of
> which I am an ordinary user and seeing a plugin tagged as
> "unmaintained". This would make me think it's unreliable, outdated and
> unstable and hence not recommended.
>
>
> I think this actually IS the intention here.
>
> But, as you've pointed out, no activity =/= unmaintained, as sometimes
> no activity just means bug free and feature complete. In this case I
> think it's fine to require developers to respond to a quick "is this
> still maintained" survey in order to avoid the flag.
>
>
> And sometimes even if the plugin is unmaintained it is still useful to
> lots of people (even if it has a few known bugs)…..
>
> I’m not sure if flagging plugins as unmaintained is always so nice.. I
> would favour an approach where we could just list plugins in the plugin
> manager based on the date of their last release, most recent first so that
> you can see old versus new
>
> Definitely -1 here on removing plugins that are orphaned unless they are
> part of a security / data integrity risk. Many people may have built up
> specific workflows around the existence of a particular plugin or two and
> there is no need to break this for people even if the plugin is orphaned…
>
> Regards
>
> Tim
>
>
>
> —
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex 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] Find unmaintained plugins

[Sandro Santilli]

On Mon, Feb 04, 2019 at 04:05:53PM +0100, Werner Macho wrote:

> I also dislike the idea of removing plugins completely, as already pointed
> oout sometimes a plugin "just works" and there is no real maintenance
> needed.
> Also - even it is not maintained anymore the code inside can still be
> useful to create something new out of it. And without seeing the plugin
> everything would have to be invented again.

Could the GUI invite users to _become_ maintainers ?

--strk;
___
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] Find unmaintained plugins

[Werner Macho]

Hi,

I also dislike the idea of removing plugins completely, as already pointed
oout sometimes a plugin "just works" and there is no real maintenance
needed.
Also - even it is not maintained anymore the code inside can still be
useful to create something new out of it. And without seeing the plugin
everything would have to be invented again.

so -1 from my side for  removing plugins that are orphaned unless they are
part of a security / data integrity risk too.

regards
Werner

On Mon, Feb 4, 2019 at 3:25 PM Tim Sutton  wrote:

> Hi
>
>
> On 04 Feb 2019, at 00:30, Nyall Dawson  wrote:
>
> On Mon, 4 Feb 2019 at 00:57, Matthias Kuhn  wrote:
>
>
> Hi Paolo
>
> On 2/3/19 1:39 PM, Paolo Cavallini wrote:
>
> Hi Matthias,
>
> On 03/02/19 10:17, Matthias Kuhn wrote:
>
> Marking a plugin as "unmaintained" or "deprecated" is a heavy action which
> may discourage developers and make even useful plugins disappear.
>
>
> deprecated yes, unmaintained not necessarily. We could just let the user
> know, perhaps suggesting a way to solve this, without removing them for
> the list of available plugins (just like the Featured tag).
>
>
> Then I misunderstood the goal of this proposal, sorry.
>
> I was imagining myself looking through a plugin list of a software of
> which I am an ordinary user and seeing a plugin tagged as
> "unmaintained". This would make me think it's unreliable, outdated and
> unstable and hence not recommended.
>
>
> I think this actually IS the intention here.
>
> But, as you've pointed out, no activity =/= unmaintained, as sometimes
> no activity just means bug free and feature complete. In this case I
> think it's fine to require developers to respond to a quick "is this
> still maintained" survey in order to avoid the flag.
>
>
> And sometimes even if the plugin is unmaintained it is still useful to
> lots of people (even if it has a few known bugs)…..
>
> I’m not sure if flagging plugins as unmaintained is always so nice.. I
> would favour an approach where we could just list plugins in the plugin
> manager based on the date of their last release, most recent first so that
> you can see old versus new
>
> Definitely -1 here on removing plugins that are orphaned unless they are
> part of a security / data integrity risk. Many people may have built up
> specific workflows around the existence of a particular plugin or two and
> there is no need to break this for people even if the plugin is orphaned…
>
> Regards
>
> Tim
>
>
>
> —
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex 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] Find unmaintained plugins

[Tim Sutton]

Hi


> On 04 Feb 2019, at 00:30, Nyall Dawson  wrote:
> 
> On Mon, 4 Feb 2019 at 00:57, Matthias Kuhn  > wrote:
>> 
>> Hi Paolo
>> 
>> On 2/3/19 1:39 PM, Paolo Cavallini wrote:
>>> Hi Matthias,
>>> 
>>> On 03/02/19 10:17, Matthias Kuhn wrote:
>>> 
 Marking a plugin as "unmaintained" or "deprecated" is a heavy action which 
 may discourage developers and make even useful plugins disappear.
>>> 
>>> deprecated yes, unmaintained not necessarily. We could just let the user
>>> know, perhaps suggesting a way to solve this, without removing them for
>>> the list of available plugins (just like the Featured tag).
>> 
>> Then I misunderstood the goal of this proposal, sorry.
>> 
>> I was imagining myself looking through a plugin list of a software of
>> which I am an ordinary user and seeing a plugin tagged as
>> "unmaintained". This would make me think it's unreliable, outdated and
>> unstable and hence not recommended.
> 
> I think this actually IS the intention here.
> 
> But, as you've pointed out, no activity =/= unmaintained, as sometimes
> no activity just means bug free and feature complete. In this case I
> think it's fine to require developers to respond to a quick "is this
> still maintained" survey in order to avoid the flag.

And sometimes even if the plugin is unmaintained it is still useful to lots of 
people (even if it has a few known bugs)…..

I’m not sure if flagging plugins as unmaintained is always so nice.. I would 
favour an approach where we could just list plugins in the plugin manager based 
on the date of their last release, most recent first so that you can see old 
versus new

Definitely -1 here on removing plugins that are orphaned unless they are part 
of a security / data integrity risk. Many people may have built up specific 
workflows around the existence of a particular plugin or two and there is no 
need to break this for people even if the plugin is orphaned…

Regards

Tim

> 

—








Tim Sutton

Co-founder: Kartoza
Ex 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] Plugin [1377] TlugProcessing approval notification.

[noreply]

Plugin TlugProcessing approval by pcav.
The plugin version "[1377] TlugProcessing 2.7.1" is now approved
Link: http://plugins.qgis.org/plugins/TlugProcessing/
___
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] A Coruña meeting travel support

[Andreas Neumann]

Hi, 


If you plan to visit the A Coruña dev meeting and would like to get
travel support, please do not forget to fill in the form at
https://goo.gl/forms/YKm5fo7ll5GfQEJI3 


Reimbursement of travel cost will be done during or shortly after the
meeting. 


In order to make life easier for me, it would be great if you would send
me ONE SINGLE PDF with the following information: 

1. Your name and address 

2. Your IBAN number and SWIFT code 

3. A list of items you want to get reimbursed and their cost 

4. The total cost 

5. All of your invoices/receipts 


PLEASE, PLEASE: do not send me many different jpeg files, but combine
everything into one single PDF file. This can be easily done in
LibreOffice, or using one of the free PDF tools, such as PDFSAM or
similar. There are also online services that allow to combine different
PDF and jpegs into one single PDF. 


Thanks a lot for your collaboration - looking forward to meet you in A
Coruña! 

Greetings, 


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

[QGIS-Developer] Plugin [1616] Hqgis approval notification.

[noreply]

Plugin Hqgis approval by pcav.
The plugin version "[1616] Hqgis 0.3.4 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/Hqgis/
___
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] Jupyter Console Plugin for QGIS?

[Luigi Pirelli]

I agree Nyall, can you imagine a ipython qtconsole where having kernel for
each supported languages?
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
*
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
* Hire me: http://goo.gl/BYRQKg
**


On Sun, 3 Feb 2019 at 23:36, Nyall Dawson  wrote:

> On Fri, 1 Feb 2019 at 06:03, Alessandro Pasotti 
> wrote:
> >
> > Stefan,
> >
> > this is actually a very good idea, I've started something similar a few
> years ago, but its scope was limited to embedding the IPython console
> inside QGIS, the plugin is available here:
> https://plugins.qgis.org/plugins/IPyConsole/
> >
> > It is based on QtConsole.
> >
> > Perhaps it could be a starting point, IIRC Luigi also explored this
> possibility while we were working together in Boundless.
>
> Thinking out-loud, but it would be nice if we had some way to abstract
> consoles and have some common interface for them.
>
> Beside the current python console and some 3rd party plugins like the
> IPython console, I would very much like to see an embedded "terminal"
> console and interactive R console...
>
> Super bonus points if I can access these via a Quake style ~ shortcut ;)
>
> Nyall
>
> >
> >
> >
> >
> > On Thu, Jan 31, 2019 at 8:11 PM Stefan Keller 
> wrote:
> >>
> >> Hi,
> >>
> >> August 2017 Tim S. blogged about "Plotting the future of QGIS" [1] and
> >> mentioned as no. 1. "We need to beef up the analytical capabilities in
> >> QGIS". There he asked "why not provide both a Jupyter Notebook"
> >> embedded into QGIS and pointed to options to integrate the Jupyter Qt
> >> console [2]. QGIS/Jupyter integration has been mentioned 2017 as
> >> possible GSoC but then can't see other activities.
> >>
> >> So what is your opinion about writing a QGIS Python Plugin which
> >> allows to run Python notebooks an accesses the QGIS processing power
> >> (e.g. using Qt's  RichJupyterWidget).
> >>
> >> Any developments or thoughts on this?
> >>
> >> :Stefan
> >>
> >> [1] https://blog.qgis.org/2017/08/25/plotting-the-future-of-qgis/
> >> [2]
> https://qtconsole.readthedocs.io/en/stable/#embedding-the-qtconsole-in-a-qt-application
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> >
> > --
> > Alessandro Pasotti
> > w3:   www.itopen.it
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Plugin [1197] Geometry Wrapper approval notification.

[noreply]

Plugin Geometry Wrapper approval by pcav.
The plugin version "[1197] Geometry Wrapper 0.3 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/GeoWrap/
___
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] Jupyter Console Plugin for QGIS?

[Luigi Pirelli]

I would thing it carefully, mainly to avoid to involve someone to works on
something that we are not sure it could work! and I can investigate only
after the UserConf (hopefully)

If there is a implementation possibility? I would be happy to mentor.

Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
*
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
* Hire me: http://goo.gl/BYRQKg
**


On Sun, 3 Feb 2019 at 12:20, Stefan Keller  wrote:

> Am So., 3. Feb. 2019 um 11:00 Uhr schrieb Luigi Pirelli  >:
> > I hadn't time to investigate, but 1.5y ago I challenged various talented
> devs and none found a solution...
> > But having a well focused GSoC probably could help :)
>
> So ;-) , do we have a good idea for GSoC 2019 - and a mentor (you)?
> My contribution could be use and test cases...
>
> :Stefan
>
> Am So., 3. Feb. 2019 um 11:00 Uhr schrieb Luigi Pirelli  >:
> >
> > There were already a past GSoC focused on something similar... But
> oriented to use qgis as back end for mapping only.
> >
> > IMHO a GSoC should be on remove (if possible) at console ernel sharing
> limitation when embedded.. Not specifically a qgis oriented stuff.
> > I hadn't time to investigate, but 1.5y ago I challenged various talented
> devs and none found a solution... But having a well focused GSoC probably
> could help :)
> >
> > On Sunday, 3 February 2019, Stefan Keller  wrote:
> >>
> >> A Jupyter Console QGIS Plugin would probably be a good "Google Summer
> >> of Code 2019 Idea"?
> >> https://github.com/qgis/QGIS/wiki/Google-Summer-of-Code-2019-Ideas
> >>
> >> :Stefan
> >>
> >> Am Do., 31. Jan. 2019 um 23:07 Uhr schrieb Luigi Pirelli <
> lui...@gmail.com>:
> >> >
> >> > I already wrote many times about QT Console limitations to interact
> with external kernels... I dind't know about RichJupyterWidget and I'm not
> updated about qt console evlution.
> >> >
> >> > IMHO if it works would be great... since 1.5y ago it was not possible.
> >> >
> >> > Luigi Pirelli
> >> >
> >> >
> **
> >> > * LinkedIn: https://www.linkedin.com/in/luigipirelli
> >> > * Stackexchange:
> http://gis.stackexchange.com/users/19667/luigi-pirelli
> >> > * GitHub: https://github.com/luipir
> >> > * Mastering QGIS 2nd Edition:
> >> > *
> https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
> >> > * Hire me: http://goo.gl/BYRQKg
> >> >
> **
> >> >
> >> >
> >> > On Thu, 31 Jan 2019 at 21:03, Alessandro Pasotti 
> wrote:
> >> >>
> >> >> Stefan,
> >> >>
> >> >> this is actually a very good idea, I've started something similar a
> few years ago, but its scope was limited to embedding the IPython console
> inside QGIS, the plugin is available here:
> https://plugins.qgis.org/plugins/IPyConsole/
> >> >>
> >> >> It is based on QtConsole.
> >> >>
> >> >> Perhaps it could be a starting point, IIRC Luigi also explored this
> possibility while we were working together in Boundless.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> On Thu, Jan 31, 2019 at 8:11 PM Stefan Keller 
> wrote:
> >> >>>
> >> >>> Hi,
> >> >>>
> >> >>> August 2017 Tim S. blogged about "Plotting the future of QGIS" [1]
> and
> >> >>> mentioned as no. 1. "We need to beef up the analytical capabilities
> in
> >> >>> QGIS". There he asked "why not provide both a Jupyter Notebook"
> >> >>> embedded into QGIS and pointed to options to integrate the Jupyter
> Qt
> >> >>> console [2]. QGIS/Jupyter integration has been mentioned 2017 as
> >> >>> possible GSoC but then can't see other activities.
> >> >>>
> >> >>> So what is your opinion about writing a QGIS Python Plugin which
> >> >>> allows to run Python notebooks an accesses the QGIS processing power
> >> >>> (e.g. using Qt's  RichJupyterWidget).
> >> >>>
> >> >>> Any developments or thoughts on this?
> >> >>>
> >> >>> :Stefan
> >> >>>
> >> >>> [1] https://blog.qgis.org/2017/08/25/plotting-the-future-of-qgis/
> >> >>> [2]
> https://qtconsole.readthedocs.io/en/stable/#embedding-the-qtconsole-in-a-qt-application
> >> >>> ___
> >> >>> QGIS-Developer mailing list
> >> >>> QGIS-Developer@lists.osgeo.org
> >> >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> >>> Unsubscribe:
> https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Alessandro Pasotti
> >> >> w3:   www.itopen.it
> >> >> ___
> >> >> 

Re: [QGIS-Developer] proj6 to be and QGIS...

[Paolo Cavallini]

Hi Nyall,

On 03/02/19 23:37, Nyall Dawson wrote:

> The good news is that North Road received funding for this (and other
> related improvements) last week, thanks to the Australian ICSM and the
> team behind the GDA2020 projection.
> 
> More on this later this week.

Great news, keep us informed.
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
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