Re: [QGIS-Developer] What to do about WFS test failures?

2018-09-03 Thread Jonathan Moules 
I'd suggest based on Tom's post that the work should include some sort 
of reliable way of testing the WFS client (and of course full test 
coverage) - I don't know if GeoServer is Docker-happy these days, but 
the default install in a VM should be sufficient for the task (it comes 
with test layers) - although GeoServer doesn't support WFS-T for writing.


Cheers,
Jonathan

On 03/09/2018 12:04, Régis Haubourg wrote:

Hi all,
I very much think that the WFS client is an really bad state, and is 
not really reliable, especially in WFS-T context.

The good news is that we just have been funded to refactor it !
The work should start in september and land in 3.6. I will let our 
dev's come here with more technical details about the goals. I hope we 
will also be able to take benefit of this to this the OGC compliancy 
of the client here.

Best regards,
Régis

Le lun. 3 sept. 2018 à 11:36, Tom Chadwin > a écrit :


I can't offer any helpful suggestions, but just to let you know I
finally had
to disable all my plugin WFS tests. I used to cope, by rerunning
failed
Travis runs, but by about three months ago, it seemed no longer
usable -
failure after failure.

I was using a third-party WFS, and perhaps I could have got round
this by
adding a WFS provider to the test docker image, but in this
plugin's case, I
didn't think it worth the significant effort to do so. The WM(T)S
tests also
use third-party sources and seem stable, so perhaps this wasn't the
underlying issue anyway.

If an improvement or solution could be found, it would be great to
reinstate
these tests.

Thanks

Tom



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



___
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 [1195] MPA Post-Hoc Accounting approval notification.

2018-09-03 Thread noreply 

Plugin MPA Post-Hoc Accounting approval by pcav.
The plugin version "[1195] MPA Post-Hoc Accounting 0.6 Experimental" is now 
approved
Link: http://plugins.qgis.org/plugins/MPAPostHocAccounting/
___
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] What to do about WFS test failures?

2018-09-03 Thread Nyall Dawson 
On Tue, 4 Sep 2018 at 05:50, Even Rouault  wrote:
>
> Régis,
>
> Not that I'm against improvements, all the contrary, but just wanted to
> underline that the provider was seriously refactored already in 2.16. Clearly
> the lack of WFS-T support for 1.1 and 2.0 in the scope of those enhancements
> can be a source of confusion currently for users. What do you have in mind as
> refactoring exactly ?

I'm with Even here... please, proceed with extreme caution.

We may be seeing issues with the WFS provider since 3.2, but I do not
think a full rewrite is needed/wanted here, and potentially will cause
many regressions given how finicky WFS servers are and how many
server-specific fixes have been required in the current
implementation.

Nyall


>
> Even
>
> > Hi all,
> > I very much think that the WFS client is an really bad state, and is not
> > really reliable, especially in WFS-T context.
> > The good news is that we just have been funded to refactor it !
> > The work should start in september and land in 3.6. I will let our dev's
> > come here with more technical details about the goals. I hope we will also
> > be able to take benefit of this to this the OGC compliancy of the client
> > here.
> > Best regards,
> > Régis
> >
> > Le lun. 3 sept. 2018 à 11:36, Tom Chadwin  a
> >
> > écrit :
> > > I can't offer any helpful suggestions, but just to let you know I finally
> > > had
> > > to disable all my plugin WFS tests. I used to cope, by rerunning failed
> > > Travis runs, but by about three months ago, it seemed no longer usable -
> > > failure after failure.
> > >
> > > I was using a third-party WFS, and perhaps I could have got round this by
> > > adding a WFS provider to the test docker image, but in this plugin's case,
> > > I
> > > didn't think it worth the significant effort to do so. The WM(T)S tests
> > > also
> > > use third-party sources and seem stable, so perhaps this wasn't the
> > > underlying issue anyway.
> > >
> > > If an improvement or solution could be found, it would be great to
> > > reinstate
> > > these tests.
> > >
> > > Thanks
> > >
> > > Tom
> > >
> > >
> > >
> > > -
> > > Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> > > --
> > > Sent from:
> > > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> > > ___
> > > QGIS-Developer mailing list
> > > QGIS-Developer@lists.osgeo.org
> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> 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] Popup window within Processing crashes QGIS

2018-09-03 Thread Nyall Dawson 
On Mon, 3 Sep 2018 at 23:09, C Hamilton  wrote:
>
> Nyall,
>
> I have been working on an alternative KML/KMZ importing tool and a tool to 
> expand HTML tables within the description field containing tag/value elements 
> into fields in the table.  The reason for another importer is that the GDAL 
> implementation is in some sense too smart. The situation is that if there are 
> many folders in a KML, QGIS imports each as a layer and is very slow at 
> importing or crashes during the import if there happens to be hundreds of 
> layers. This also happens using ArcGIS. I am assuming that both use GDAL and 
> in some respects GDAL tries to do too much. Consequently, I wrote this KML 
> plugin to import KML/KMZ files in the way we wanted them. The following is 
> the capability prior to processing.

Sounds handy -- I've hit this in the past too. Those HTML tables
inside KML really annoy me a lot.

> I have already converted this importer to processing. The second function 
> that expands HTML tables in the description field does a first pass to see if 
> there are any tables and makes note of the tags/fields to be created. It then 
> pops up a dialog box to allow the user to select what fields they want 
> expanded. They only way you could do this in processing, since I can't pop up 
> a selection box, is to expand all potential tags/fields, but the users don't 
> want to do this.

Ok, so in this case I'd suggest:
- Make sure your code is nicely partitioned, separating out the core
functionality from the gui component
- Add a "callback" type argument within your converter, which is used
to select which fields to import
- Make your plugin add both a processing algorithm AND the
non-processing, interactive action
- The processing algorithm sets a callback which returns ALL fields
always, with no user interaction. The Interactive action passes a
callback which shows the field selection dialog.

This gives approach gains you:
- A single unified code base, with clear gui/logic separation (so also
easy to write unit tests for)
- Makes the users who want an interactive choice happy
- Still exposes your functionality from within Processing for users
who want everything, or want to use this function within a model OR
from another plugin/Python script.

That's the "canonical" approach to take here.

Nyall

> I have debated whether I should make this a separate plugin in or add the 
> functionality to Lat Lon Tools. I already have conversion routines such as 
> MGRS conversion and "Plus Codes" in Lat Lon Tools. What are your thoughts? 
> Should this be added to Lat Lon Tools or a separate plugin?

Separate plugin -- they are very different functionalities, and
plugins work best when they expose "atomic" functions.

Nyall


>
> Calvin
>
>
> On Fri, Aug 31, 2018 at 5:06 PM, Nyall Dawson  wrote:
>>
>> On Fri, 31 Aug 2018 at 22:24, C Hamilton  wrote:
>> >
>> > Thanks Nyall!!! Unfortunately I was trying to make this a processing 
>> > routine when I shouldn't have. It is good to know the boundaries. This 
>> > function really requires user interactivity.
>>
>> Mind sharing the general function of the plugin? There may still be a
>> way to make this work within Processing.
>>
>> Regards,
>> Nyall
>>
>> >
>> > Calvin
>> >
>> > On Thu, Aug 30, 2018 at 9:27 PM, Nyall Dawson  
>> > wrote:
>> >>
>> >> On Thu, 30 Aug 2018 at 23:38, C Hamilton  wrote:
>> >> >
>> >> > I have an algorithm that during execution gathers information from the 
>> >> > data and then pops up a window for the user to select what the user 
>> >> > would like to do.
>> >> >
>> >> > Is this possible in the Processing framework? I have tried doing this 
>> >> > in processAlgorithm and it crashes QGIS. Here is how I call the popup 
>> >> > window.
>> >>
>> >> No - this is not supported and goes against the very fundamental
>> >> design of Processing. Argggh! ;)
>> >>
>> >> But seriously, Processing was designed with the intention that all
>> >> user choices are made up-front. This allows algorithms to be nicely
>> >> executed inside of models, without the model halting mid-way waiting
>> >> for user input. It also allows algorithms, scripts, models, etc to be
>> >> run from headless environments such as console scripts.
>> >>
>> >> In this case, you're getting a crash because you're trying to create
>> >> GUI components from your algorithm which is being executed in a
>> >> background thread. This is a big no-no in Qt land, and usually results
>> >> in a crash.
>> >>
>> >> Nyall
>> >>
>> >>
>> >> > fieldsDialog = SelectionDialog(self.tableFeatures)
>> >> > fieldsDialog.exec_()
>> >> > items = fieldsDialog.selected
>> >> >
>> >> > Here is the beginning of the SelectionDialong class.
>> >> >
>> >> > class SelectionDialog(QDialog, FIELDS_CLASS):
>> >> > def __init__(self, feat, parent=None):
>> >> > super(SelectionDialog, self).__init__(parent)
>> >> > self.setupUi(self)
>> >> >
>> >> > Prior to Processing I passed in iface

Re: [QGIS-Developer] Python ResourceWarning: unclosed file in Processing Plugin

2018-09-03 Thread Nyall Dawson 
On Tue, 4 Sep 2018 at 02:56, Martin Isenburg  wrote:
>
> Hello,
>
> as soon as I run any of my LAStools plugin scripts I get the WARNING 
> "ResourceWarning" about an "unclosed file" shown below in the Python warning 
> window. I use the call "output = subprocess.Popen()" to get the stderr 
> output from the process so I can push it to the console once the subprocess 
> is complete with the feedback.pushConsoleInfo(output.decode("utf-8")). Is it 
> bad? Can I fix it? Should I ignore it?
>
> Complete code:
>
> https://github.com/rapidlasso/LAStoolsPluginQGIS3/blob/master/LAStools/LAStoolsUtils.py
>
> Regards.
>
> Martin
>
> 2018-09-03T18:34:08 WARNING
> warning:C:/Users/isenburg/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\LAStools\LAStoolsUtils.py:60:
>  ResourceWarning:
>
>  unclosed file
>
>  traceback: File 
> "C:/Users/isenburg/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\LAStools\LAStoolsPipelines\flightlinesToDTMandSpikeFreeDSM.py",
>  line 82, in processAlgorithm
>   LAStoolsUtils.runLAStools(commands, feedback)
>   File 
> "C:/Users/isenburg/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\LAStools\LAStoolsUtils.py",
>  line 60, in runLAStools
>   output = subprocess.Popen(commandline, shell=True, 
> stdout=subprocess.PIPE, stdin=open(os.devnull), stderr=subprocess.STDOUT, 
> universal_newlines=False).communicate()[0]

I think you need a:

output.wait()

after this line. See
https://stackoverflow.com/questions/23279941/closing-stdin-in-subprocess-popen

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] What to do about WFS test failures?

2018-09-03 Thread Jeremy Palmer 
I agree WFS 3.0 is a much better implementation and it would be great if a
implementation is started soon to track the current standards development.
However, we still have (and will have for a long time) a user need to
support WFS 1.0 and 2.0 - so this still needs to be deal with.

On Tue, Sep 4, 2018 at 8:32 AM Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com> wrote:

> What about starting with/focusing on WFS 3? The new version is really
> cleaner and seems much more efficient.
> The current WFS implementation in QGIS is much better than previous
> versions, even if sometimes making a virtual OGR file il the only way to
> use some services. There are really bad server implementations out there,
> additionally an automated solution struggles against misleading and lazy
> XML informations. This is a broken idea or at least one that asks for close
> cooperation between server and client.
> Just my remaining cent.
> c
>
>
> On Mon, Sep 3, 2018 at 10:01 PM, Jeremy Palmer 
> wrote:
>
>> Can I also add that the refactoring that was funded in 2.16 added tests,
>> paging support, filter query builder and dynamic caching. There is now a
>> lot of complexity in the driver due to the complexity of WFS server
>> implementations and the standard, plus the multi-threading code. If a
>> refactor is proposed I would be against anything that doesn't deal current
>> use cases and edge cases which have already been implemented. Maybe some
>> analysis of the failed tests is the first place to start. WFS-T is a side
>> issue to that.
>>
>> Cheers,
>> Jeremy
>>
>>
>> On Tue, Sep 4, 2018 at 7:51 AM Régis Haubourg 
>> wrote:
>>
>>> Hi Even, thanks for pointing that, I missed that history.
>>> I'll ask the dev's for the detailed improvements planned, I dont' have
>>> any detail currently (sorry for that)
>>> Régis
>>>
>>> Le lun. 3 sept. 2018 à 21:29, Even Rouault 
>>> a écrit :
>>>
 Régis,

 Not that I'm against improvements, all the contrary, but just wanted to
 underline that the provider was seriously refactored already in 2.16.
 Clearly
 the lack of WFS-T support for 1.1 and 2.0 in the scope of those
 enhancements
 can be a source of confusion currently for users. What do you have in
 mind as
 refactoring exactly ?

 Even

 > Hi all,
 > I very much think that the WFS client is an really bad state, and is
 not
 > really reliable, especially in WFS-T context.
 > The good news is that we just have been funded to refactor it !
 > The work should start in september and land in 3.6. I will let our
 dev's
 > come here with more technical details about the goals. I hope we will
 also
 > be able to take benefit of this to this the OGC compliancy of the
 client
 > here.
 > Best regards,
 > Régis
 >
 > Le lun. 3 sept. 2018 à 11:36, Tom Chadwin  a
 >
 > écrit :
 > > I can't offer any helpful suggestions, but just to let you know I
 finally
 > > had
 > > to disable all my plugin WFS tests. I used to cope, by rerunning
 failed
 > > Travis runs, but by about three months ago, it seemed no longer
 usable -
 > > failure after failure.
 > >
 > > I was using a third-party WFS, and perhaps I could have got round
 this by
 > > adding a WFS provider to the test docker image, but in this
 plugin's case,
 > > I
 > > didn't think it worth the significant effort to do so. The WM(T)S
 tests
 > > also
 > > use third-party sources and seem stable, so perhaps this wasn't the
 > > underlying issue anyway.
 > >
 > > If an improvement or solution could be found, it would be great to
 > > reinstate
 > > these tests.
 > >
 > > Thanks
 > >
 > > Tom
 > >
 > >
 > >
 > > -
 > > Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
 > > --
 > > Sent from:
 > > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
 > > ___
 > > QGIS-Developer mailing list
 > > QGIS-Developer@lists.osgeo.org
 > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
 > > Unsubscribe:
 https://lists.osgeo.org/mailman/listinfo/qgis-developer


 --
 Spatialys - Geospatial professional services
 http://www.spatialys.com

>>> ___
>>> 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] What to do about WFS test failures?

2018-09-03 Thread Carlo A. Bertelli (Charta s.r.l.) 
What about starting with/focusing on WFS 3? The new version is really
cleaner and seems much more efficient.
The current WFS implementation in QGIS is much better than previous
versions, even if sometimes making a virtual OGR file il the only way to
use some services. There are really bad server implementations out there,
additionally an automated solution struggles against misleading and lazy
XML informations. This is a broken idea or at least one that asks for close
cooperation between server and client.
Just my remaining cent.
c


On Mon, Sep 3, 2018 at 10:01 PM, Jeremy Palmer  wrote:

> Can I also add that the refactoring that was funded in 2.16 added tests,
> paging support, filter query builder and dynamic caching. There is now a
> lot of complexity in the driver due to the complexity of WFS server
> implementations and the standard, plus the multi-threading code. If a
> refactor is proposed I would be against anything that doesn't deal current
> use cases and edge cases which have already been implemented. Maybe some
> analysis of the failed tests is the first place to start. WFS-T is a side
> issue to that.
>
> Cheers,
> Jeremy
>
>
> On Tue, Sep 4, 2018 at 7:51 AM Régis Haubourg 
> wrote:
>
>> Hi Even, thanks for pointing that, I missed that history.
>> I'll ask the dev's for the detailed improvements planned, I dont' have
>> any detail currently (sorry for that)
>> Régis
>>
>> Le lun. 3 sept. 2018 à 21:29, Even Rouault 
>> a écrit :
>>
>>> Régis,
>>>
>>> Not that I'm against improvements, all the contrary, but just wanted to
>>> underline that the provider was seriously refactored already in 2.16.
>>> Clearly
>>> the lack of WFS-T support for 1.1 and 2.0 in the scope of those
>>> enhancements
>>> can be a source of confusion currently for users. What do you have in
>>> mind as
>>> refactoring exactly ?
>>>
>>> Even
>>>
>>> > Hi all,
>>> > I very much think that the WFS client is an really bad state, and is
>>> not
>>> > really reliable, especially in WFS-T context.
>>> > The good news is that we just have been funded to refactor it !
>>> > The work should start in september and land in 3.6. I will let our
>>> dev's
>>> > come here with more technical details about the goals. I hope we will
>>> also
>>> > be able to take benefit of this to this the OGC compliancy of the
>>> client
>>> > here.
>>> > Best regards,
>>> > Régis
>>> >
>>> > Le lun. 3 sept. 2018 à 11:36, Tom Chadwin  a
>>> >
>>> > écrit :
>>> > > I can't offer any helpful suggestions, but just to let you know I
>>> finally
>>> > > had
>>> > > to disable all my plugin WFS tests. I used to cope, by rerunning
>>> failed
>>> > > Travis runs, but by about three months ago, it seemed no longer
>>> usable -
>>> > > failure after failure.
>>> > >
>>> > > I was using a third-party WFS, and perhaps I could have got round
>>> this by
>>> > > adding a WFS provider to the test docker image, but in this plugin's
>>> case,
>>> > > I
>>> > > didn't think it worth the significant effort to do so. The WM(T)S
>>> tests
>>> > > also
>>> > > use third-party sources and seem stable, so perhaps this wasn't the
>>> > > underlying issue anyway.
>>> > >
>>> > > If an improvement or solution could be found, it would be great to
>>> > > reinstate
>>> > > these tests.
>>> > >
>>> > > Thanks
>>> > >
>>> > > Tom
>>> > >
>>> > >
>>> > >
>>> > > -
>>> > > Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
>>> > > --
>>> > > Sent from:
>>> > > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
>>> > > ___
>>> > > QGIS-Developer mailing list
>>> > > QGIS-Developer@lists.osgeo.org
>>> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>>
>>> --
>>> Spatialys - Geospatial professional services
>>> http://www.spatialys.com
>>>
>> ___
>> 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
>



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
QGIS-Developer mailing list
QGIS-Dev

Re: [QGIS-Developer] What to do about WFS test failures?

2018-09-03 Thread Jeremy Palmer 
Can I also add that the refactoring that was funded in 2.16 added tests,
paging support, filter query builder and dynamic caching. There is now a
lot of complexity in the driver due to the complexity of WFS server
implementations and the standard, plus the multi-threading code. If a
refactor is proposed I would be against anything that doesn't deal current
use cases and edge cases which have already been implemented. Maybe some
analysis of the failed tests is the first place to start. WFS-T is a side
issue to that.

Cheers,
Jeremy

On Tue, Sep 4, 2018 at 7:51 AM Régis Haubourg 
wrote:

> Hi Even, thanks for pointing that, I missed that history.
> I'll ask the dev's for the detailed improvements planned, I dont' have any
> detail currently (sorry for that)
> Régis
>
> Le lun. 3 sept. 2018 à 21:29, Even Rouault  a
> écrit :
>
>> Régis,
>>
>> Not that I'm against improvements, all the contrary, but just wanted to
>> underline that the provider was seriously refactored already in 2.16.
>> Clearly
>> the lack of WFS-T support for 1.1 and 2.0 in the scope of those
>> enhancements
>> can be a source of confusion currently for users. What do you have in
>> mind as
>> refactoring exactly ?
>>
>> Even
>>
>> > Hi all,
>> > I very much think that the WFS client is an really bad state, and is not
>> > really reliable, especially in WFS-T context.
>> > The good news is that we just have been funded to refactor it !
>> > The work should start in september and land in 3.6. I will let our dev's
>> > come here with more technical details about the goals. I hope we will
>> also
>> > be able to take benefit of this to this the OGC compliancy of the client
>> > here.
>> > Best regards,
>> > Régis
>> >
>> > Le lun. 3 sept. 2018 à 11:36, Tom Chadwin  a
>> >
>> > écrit :
>> > > I can't offer any helpful suggestions, but just to let you know I
>> finally
>> > > had
>> > > to disable all my plugin WFS tests. I used to cope, by rerunning
>> failed
>> > > Travis runs, but by about three months ago, it seemed no longer
>> usable -
>> > > failure after failure.
>> > >
>> > > I was using a third-party WFS, and perhaps I could have got round
>> this by
>> > > adding a WFS provider to the test docker image, but in this plugin's
>> case,
>> > > I
>> > > didn't think it worth the significant effort to do so. The WM(T)S
>> tests
>> > > also
>> > > use third-party sources and seem stable, so perhaps this wasn't the
>> > > underlying issue anyway.
>> > >
>> > > If an improvement or solution could be found, it would be great to
>> > > reinstate
>> > > these tests.
>> > >
>> > > Thanks
>> > >
>> > > Tom
>> > >
>> > >
>> > >
>> > > -
>> > > Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
>> > > --
>> > > Sent from:
>> > > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
>> > > ___
>> > > QGIS-Developer mailing list
>> > > QGIS-Developer@lists.osgeo.org
>> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com
>>
> ___
> 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] What to do about WFS test failures?

2018-09-03 Thread Régis Haubourg 
Hi Even, thanks for pointing that, I missed that history.
I'll ask the dev's for the detailed improvements planned, I dont' have any
detail currently (sorry for that)
Régis

Le lun. 3 sept. 2018 à 21:29, Even Rouault  a
écrit :

> Régis,
>
> Not that I'm against improvements, all the contrary, but just wanted to
> underline that the provider was seriously refactored already in 2.16.
> Clearly
> the lack of WFS-T support for 1.1 and 2.0 in the scope of those
> enhancements
> can be a source of confusion currently for users. What do you have in mind
> as
> refactoring exactly ?
>
> Even
>
> > Hi all,
> > I very much think that the WFS client is an really bad state, and is not
> > really reliable, especially in WFS-T context.
> > The good news is that we just have been funded to refactor it !
> > The work should start in september and land in 3.6. I will let our dev's
> > come here with more technical details about the goals. I hope we will
> also
> > be able to take benefit of this to this the OGC compliancy of the client
> > here.
> > Best regards,
> > Régis
> >
> > Le lun. 3 sept. 2018 à 11:36, Tom Chadwin  a
> >
> > écrit :
> > > I can't offer any helpful suggestions, but just to let you know I
> finally
> > > had
> > > to disable all my plugin WFS tests. I used to cope, by rerunning failed
> > > Travis runs, but by about three months ago, it seemed no longer usable
> -
> > > failure after failure.
> > >
> > > I was using a third-party WFS, and perhaps I could have got round this
> by
> > > adding a WFS provider to the test docker image, but in this plugin's
> case,
> > > I
> > > didn't think it worth the significant effort to do so. The WM(T)S tests
> > > also
> > > use third-party sources and seem stable, so perhaps this wasn't the
> > > underlying issue anyway.
> > >
> > > If an improvement or solution could be found, it would be great to
> > > reinstate
> > > these tests.
> > >
> > > Thanks
> > >
> > > Tom
> > >
> > >
> > >
> > > -
> > > Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> > > --
> > > Sent from:
> > > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> > > ___
> > > QGIS-Developer mailing list
> > > QGIS-Developer@lists.osgeo.org
> > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
___
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] What to do about WFS test failures?

2018-09-03 Thread Even Rouault 
Régis,

Not that I'm against improvements, all the contrary, but just wanted to 
underline that the provider was seriously refactored already in 2.16. Clearly 
the lack of WFS-T support for 1.1 and 2.0 in the scope of those enhancements 
can be a source of confusion currently for users. What do you have in mind as 
refactoring exactly ?

Even

> Hi all,
> I very much think that the WFS client is an really bad state, and is not
> really reliable, especially in WFS-T context.
> The good news is that we just have been funded to refactor it !
> The work should start in september and land in 3.6. I will let our dev's
> come here with more technical details about the goals. I hope we will also
> be able to take benefit of this to this the OGC compliancy of the client
> here.
> Best regards,
> Régis
> 
> Le lun. 3 sept. 2018 à 11:36, Tom Chadwin  a
> 
> écrit :
> > I can't offer any helpful suggestions, but just to let you know I finally
> > had
> > to disable all my plugin WFS tests. I used to cope, by rerunning failed
> > Travis runs, but by about three months ago, it seemed no longer usable -
> > failure after failure.
> > 
> > I was using a third-party WFS, and perhaps I could have got round this by
> > adding a WFS provider to the test docker image, but in this plugin's case,
> > I
> > didn't think it worth the significant effort to do so. The WM(T)S tests
> > also
> > use third-party sources and seem stable, so perhaps this wasn't the
> > underlying issue anyway.
> > 
> > If an improvement or solution could be found, it would be great to
> > reinstate
> > these tests.
> > 
> > Thanks
> > 
> > Tom
> > 
> > 
> > 
> > -
> > Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> > --
> > Sent from:
> > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
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 [1526] LAStools approval notification.

2018-09-03 Thread noreply 

Plugin LAStools approval by pcav.
The plugin version "[1526] LAStools 1.0" is now approved
Link: http://plugins.qgis.org/plugins/LAStools/
___
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-developer] OTB and LiDAR tools as separate plugins

2018-09-03 Thread matteo 
Hi Martin,

glad that I could had helped you ;)

Cheers

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

[QGIS-Developer] Python ResourceWarning: unclosed file in Processing Plugin

2018-09-03 Thread Martin Isenburg 
Hello,

as soon as I run any of my LAStools plugin scripts I get the WARNING
"ResourceWarning" about an "unclosed file" shown below in the Python
warning window. I use the call "output = subprocess.Popen()" to get the
stderr output from the process so I can push it to the console once the
subprocess is complete with
the feedback.pushConsoleInfo(output.decode("utf-8")). Is it bad? Can I fix
it? Should I ignore it?

Complete code:

https://github.com/rapidlasso/LAStoolsPluginQGIS3/blob/master/LAStools/LAStoolsUtils.py

Regards.

Martin

2018-09-03T18:34:08 WARNING
warning:C:/Users/isenburg/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\LAStools\LAStoolsUtils.py:60:
ResourceWarning:

 unclosed file

 traceback: File
"C:/Users/isenburg/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\LAStools\LAStoolsPipelines\flightlinesToDTMandSpikeFreeDSM.py",
line 82, in processAlgorithm
  LAStoolsUtils.runLAStools(commands, feedback)
  File
"C:/Users/isenburg/AppData/Roaming/QGIS/QGIS3\profiles\default/python/plugins\LAStools\LAStoolsUtils.py",
line 60, in runLAStools
  output = subprocess.Popen(commandline, shell=True,
stdout=subprocess.PIPE, stdin=open(os.devnull), stderr=subprocess.STDOUT,
universal_newlines=False).communicate()[0]
___
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-developer] OTB and LiDAR tools as separate plugins

2018-09-03 Thread Martin Isenburg 
Hello,

my question was answered at the QGIS hackfest by Matteo Ghetta with a
DataPlotly code snippet. (-: You can add your own entries into the
"Processing Settings" menu under the "Providers" section by following the
example below in your own Provider class.

from processing.core.ProcessingConfig import Setting, ProcessingConfig

class LAStoolsProvider(QgsProcessingProvider):

def __init__(self):
QgsProcessingProvider.__init__(self)

def load(self):
ProcessingConfig.settingIcons[self.name()] = self.icon()
ProcessingConfig.addSetting(Setting(self.name(),
'LASTOOLS_ACTIVATED', 'Activate', True))
ProcessingConfig.addSetting(Setting(self.name(), 'LASTOOLS_FOLDER',
'LAStools folder', "C:\LAStools", valuetype=Setting.FOLDER))
ProcessingConfig.addSetting(Setting(self.name(), 'WINE_FOLDER',
'Wine folder', "", valuetype=Setting.FOLDER))
ProcessingConfig.readSettings()
self.refreshAlgorithms()
return True

def unload(self):
ProcessingConfig.removeSetting('LASTOOLS_ACTIVATED')
ProcessingConfig.removeSetting('LASTOOLS_FOLDER')
ProcessingConfig.removeSetting('WINE_FOLDER')
pass

def isActive(self):
return ProcessingConfig.getSetting('LASTOOLS_ACTIVATED')

def setActive(self, active):
ProcessingConfig.setSettingValue('LASTOOLS_ACTIVATED', active)


def loadAlgorithms(self):
   [...]

and you can always query those settings with code snippets such as

from processing.core.ProcessingConfig import ProcessingConfig
from processing.tools.system import isWindows

@staticmethod
def hasWine():
wine_folder = ProcessingConfig.getSetting("WINE_FOLDER")
return (wine_folder is not None) and (wine_folder != "")

@staticmethod
def LAStoolsPath():
lastools_folder = ProcessingConfig.getSetting("LASTOOLS_FOLDER")
if isWindows():
wine_folder = ""
else:
wine_folder = ProcessingConfig.getSetting("WINE_FOLDER")
if (wine_folder is None) or (wine_folder == ""):
folder = lastools_folder
else:
folder = wine_folder + "/wine " + lastools_folder
return folder

Regards,

Martin


On Fri, Aug 24, 2018 at 7:11 PM Martin Isenburg 
wrote:

> Hello,
>
> when the LAStools toolboxes were part of the "built-in" scripts of
> Processing I had was able to have two entries (i.e. the folder path to the
> "Wine" and the "LAStools" installation) in the "Processing Settings" menu
> under the "Providers" section. You can see as an example how GRASS still
> has such options in the attached screen shot. How can I place these two
> options back there now that I load the LAStools toolboxes as Processing
> plugins?
>
> Off for beers at the Zanzi-bar ... (-;
>
> Martin
>
> On Thu, Aug 23, 2018 at 8:26 PM, Alexander Bruy 
>> wrote:
>>
>>> Hi Martin,
>>>
>>> It is up to you how to distribute your plugin. You can publish it in
>>> QGIS Official
>>> plugins repository, or setup your own repository as many other
>>> developers do.
>>> It is even possible to share just a ZIP with the plugin via web-site,
>>> pretty much
>>> similar to how LAStools distributed.
>>>
>>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Processing Script addLayerToLoadOnCompletion

2018-09-03 Thread matteo 
Hi Håvard,

I knew that param has been replaced with parameters..

Anyway, removing parameters is not solving the problem

Thanks

Matteo

On 09/03/2018 06:07 PM, Havard Tveite wrote:
> "parameters=" should be removed in the run method.
> 
> Håvard
___
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 [1402] Calculate Geometry approval notification.

2018-09-03 Thread noreply 

Plugin Calculate Geometry approval by pcav.
The plugin version "[1402] Calculate Geometry 0.4" is now approved
Link: http://plugins.qgis.org/plugins/CalculateGeometry/
___
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] Processing Script addLayerToLoadOnCompletion

2018-09-03 Thread matteo 
Hi all,

I was thinking to add a small example of addLayerToLoadOnCompletion
function to the ScriptTemplate of Processing. The code is the following:

buffered_layer = processing.run("native:buffer", parameters={
'INPUT': dest_id,
'DISTANCE': 1,
'SEGMENTS': 5,
'END_CAP_STYLE': 0,
'JOIN_STYLE': 0,
'MITER_LIMIT': 2,
'DISSOLVE': False,
'OUTPUT': 'memory:'
}, context=context, feedback=feedback)['OUTPUT']

feedback.pushDebugInfo(str(dest_id))

context.addLayerToLoadOnCompletion(buffered_layer.source(),
context.LayerDetails(
name='new_layer',
project=context.project()
))

but Processing always throws this error:

The following layers were not correctly
generated.Polygon?crs=EPSG:3003&field=ID:long(10)&field=fk:string(254)&field=ROTAZ:long(10)&field=DIMENS:long(10)&field=ETICHETTA:string(254)&field=VALORE:long(10)&field=T_MIN:double(20,5)&field=T_MAX:double(20,5)&field=PIOGGIA:double(20,5)&field=LARGH:double(20,5)&field=LUNG:double(20,5)&field=assex:string(254)&field=assey:string(254)&field=colore:string(38)&field=xlab:double(10,2)&field=ylab:double(10,2)&field=raster:double(23,15)&field=raster_1:double(23,15)&field=raster_2:double(23,15)&uid={685540af-711d-462b-a9d0-9b00af4c2f6a}You
can check the 'Log Messages Panel' in QGIS main window to find more
information about the execution of the algorithm.


Am I missing something?

Thanks for any suggestion

Matteo



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

[QGIS-Developer] Plugin [537] IDECanarias approval notification.

2018-09-03 Thread noreply 

Plugin IDECanarias approval by pcav.
The plugin version "[537] IDECanarias 3.1.2" is now approved
Link: http://plugins.qgis.org/plugins/IDECanarias/
___
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 [1524] MzS Tools approval notification.

2018-09-03 Thread noreply 

Plugin MzS Tools approval by pcav.
The plugin version "[1524] MzS Tools 0.4 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/MzSTools/
___
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 [1246] go2mapillary approval notification.

2018-09-03 Thread noreply 

Plugin go2mapillary approval by pcav.
The plugin version "[1246] go2mapillary 2.1" is now approved
Link: http://plugins.qgis.org/plugins/go2mapillary/
___
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] Popup window within Processing crashes QGIS

2018-09-03 Thread C Hamilton 
Nyall,

I have been working on an alternative KML/KMZ importing tool and a tool to
expand HTML tables within the description field containing tag/value
elements into fields in the table.  The reason for another importer is that
the GDAL implementation is in some sense too smart. The situation is that
if there are many folders in a KML, QGIS imports each as a layer and is
very slow at importing or crashes during the import if there happens to be
hundreds of layers. This also happens using ArcGIS. I am assuming that both
use GDAL and in some respects GDAL tries to do too much. Consequently, I
wrote this KML plugin to import KML/KMZ files in the way we wanted them.
The following is the capability prior to processing.

https://github.com/NationalSecurityAgency/qgis-kmltools-plugin

The biggest difference between the native import and this one is that
rather than create multiple layers for each folder of KMLs, I create one
point layer, one line layer and one polygon layer if required. I add an
additional field that contains the folder structure for each feature.This
makes the import very quick.

I have already converted this importer to processing. The second function
that expands HTML tables in the description field does a first pass to see
if there are any tables and makes note of the tags/fields to be created. It
then pops up a dialog box to allow the user to select what fields they want
expanded. They only way you could do this in processing, since I can't pop
up a selection box, is to expand all potential tags/fields, but the users
don't want to do this. They want to select which fields they want added and
they may not know which tags they want until they look at the list. This is
why I wont be able to do it in processing.

I have debated whether I should make this a separate plugin in or add the
functionality to Lat Lon Tools. I already have conversion routines such as
MGRS conversion and "Plus Codes" in Lat Lon Tools. What are your thoughts?
Should this be added to Lat Lon Tools or a separate plugin?

Calvin


On Fri, Aug 31, 2018 at 5:06 PM, Nyall Dawson 
wrote:

> On Fri, 31 Aug 2018 at 22:24, C Hamilton  wrote:
> >
> > Thanks Nyall!!! Unfortunately I was trying to make this a processing
> routine when I shouldn't have. It is good to know the boundaries. This
> function really requires user interactivity.
>
> Mind sharing the general function of the plugin? There may still be a
> way to make this work within Processing.
>
> Regards,
> Nyall
>
> >
> > Calvin
> >
> > On Thu, Aug 30, 2018 at 9:27 PM, Nyall Dawson 
> wrote:
> >>
> >> On Thu, 30 Aug 2018 at 23:38, C Hamilton 
> wrote:
> >> >
> >> > I have an algorithm that during execution gathers information from
> the data and then pops up a window for the user to select what the user
> would like to do.
> >> >
> >> > Is this possible in the Processing framework? I have tried doing this
> in processAlgorithm and it crashes QGIS. Here is how I call the popup
> window.
> >>
> >> No - this is not supported and goes against the very fundamental
> >> design of Processing. Argggh! ;)
> >>
> >> But seriously, Processing was designed with the intention that all
> >> user choices are made up-front. This allows algorithms to be nicely
> >> executed inside of models, without the model halting mid-way waiting
> >> for user input. It also allows algorithms, scripts, models, etc to be
> >> run from headless environments such as console scripts.
> >>
> >> In this case, you're getting a crash because you're trying to create
> >> GUI components from your algorithm which is being executed in a
> >> background thread. This is a big no-no in Qt land, and usually results
> >> in a crash.
> >>
> >> Nyall
> >>
> >>
> >> > fieldsDialog = SelectionDialog(self.tableFeatures)
> >> > fieldsDialog.exec_()
> >> > items = fieldsDialog.selected
> >> >
> >> > Here is the beginning of the SelectionDialong class.
> >> >
> >> > class SelectionDialog(QDialog, FIELDS_CLASS):
> >> > def __init__(self, feat, parent=None):
> >> > super(SelectionDialog, self).__init__(parent)
> >> > self.setupUi(self)
> >> >
> >> > Prior to Processing I passed in iface.mainWindow() as the parent. Is
> there a proper parent in Processing to pass? Perhaps this is the reason it
> is crashing.
> >> >
> >> > class SelectionDialog(QDialog, FIELDS_CLASS):
> >> > def __init__(self, iface, feat):
> >> > super(SelectionDialog, self).__init__(iface.mainWindow())
> >> > self.setupUi(self)
> >> >
> >> > Thanks,
> >> >
> >> > Calvin
> >
> >
>
___
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] The gitter bridge doesn't support private messaging, or inviting to rooms.

2018-09-03 Thread Tom Chadwin 
I was literally about to post this same message - I've left the QGIS Gitter
room because of the issue.

Thanks, Harrissou

Tom



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

[QGIS-Developer] The gitter bridge doesn't support private messaging, or inviting to rooms.

2018-09-03 Thread DelazJ 
Hi,

Can someone give a look to this annoying message that floods the gitter
chat and makes it unusable and disturbing (with wrong notifications),
please?

Thanks.
___
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] What to do about WFS test failures?

2018-09-03 Thread Régis Haubourg 
Hi all,
I very much think that the WFS client is an really bad state, and is not
really reliable, especially in WFS-T context.
The good news is that we just have been funded to refactor it !
The work should start in september and land in 3.6. I will let our dev's
come here with more technical details about the goals. I hope we will also
be able to take benefit of this to this the OGC compliancy of the client
here.
Best regards,
Régis

Le lun. 3 sept. 2018 à 11:36, Tom Chadwin  a
écrit :

> I can't offer any helpful suggestions, but just to let you know I finally
> had
> to disable all my plugin WFS tests. I used to cope, by rerunning failed
> Travis runs, but by about three months ago, it seemed no longer usable -
> failure after failure.
>
> I was using a third-party WFS, and perhaps I could have got round this by
> adding a WFS provider to the test docker image, but in this plugin's case,
> I
> didn't think it worth the significant effort to do so. The WM(T)S tests
> also
> use third-party sources and seem stable, so perhaps this wasn't the
> underlying issue anyway.
>
> If an improvement or solution could be found, it would be great to
> reinstate
> these tests.
>
> Thanks
>
> Tom
>
>
>
> -
> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> --
> Sent from:
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
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] What to do about WFS test failures?

2018-09-03 Thread Tom Chadwin 
I can't offer any helpful suggestions, but just to let you know I finally had
to disable all my plugin WFS tests. I used to cope, by rerunning failed
Travis runs, but by about three months ago, it seemed no longer usable -
failure after failure.

I was using a third-party WFS, and perhaps I could have got round this by
adding a WFS provider to the test docker image, but in this plugin's case, I
didn't think it worth the significant effort to do so. The WM(T)S tests also
use third-party sources and seem stable, so perhaps this wasn't the
underlying issue anyway.

If an improvement or solution could be found, it would be great to reinstate
these tests.

Thanks

Tom



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

[QGIS-Developer] Plugin [629] Networks approval notification.

2018-09-03 Thread noreply 

Plugin Networks approval by pcav.
The plugin version "[629] Networks 2.0.3" is now approved
Link: http://plugins.qgis.org/plugins/networks/
___
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