Re: [Qgis-developer] Channel network and drainage basins/ DLL file “gdal_MrSID.dll

[Tom Chadwin]

Do you have different Saga/GDAL versions? 



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Channel-network-and-drainage-basins-DLL-file-gdal-MrSID-dll-tp5302246p5302259.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] When to start converting our plugins?

[Neumann, Andreas]

Hi, 

Jürgen is the release manager and ultimately proposes/decides when to
release 3.0. So I don't know what his opinion is. 

My personal opinion is in line with Nyall. Core devs should have enough
time to properly prepare everything and do at least the API
changes/redesign/refactoring properly. After 3.0 there won't be API
breaks for a longer time, so it is better to have enough time to do
things properly. 

A double dev cycle, followed by a double test cycle (testing and bug
fixing) would be useful. If we stick with the four month release cycle
with a double dev cycle this could mean a feature freeze somewhere
around May and a release after a two month test/bug fixing period
somewhere around July. Just a very rough idea, and not discussed with
the core devs and Jürgen ... 

Thoughts? 

Andreas 

On 2017-01-05 23:57, Nyall Dawson wrote:

> On 6 January 2017 at 03:43, Tom Chadwin  wrote: 
> 
>> Hello all
>> 
>> Amazing work going on for QGIS3 - I'm in awe of you all (as always).
>> 
>> I've been getting more and more nervous about how easy it will be to convert
>> my plugin, so yesterday I started to have a go. With lots of help from
>> Matthias (huge thanks, as ever!), I got a good way through the process. I
>> think I can now do it. I certainly don't feel so nervous.
>> 
>> However, Nyall pointed out that there is still a lot of change to come to
>> the API. I'm happy to abandon the work I've done so far, as it has achieved
>> its aim of getting me familiar with what the job will entail.
>> 
>> So, my question is, when would be the best time to start the actual
>> conversion of our plugins? Is there going to be an obvious time in QGIS3
>> development for this to happen? Can it be announced on the list?
> 
> I'd say just before/after feature freeze. There's still some very
> large API changes in store, eg Martin's current refactoring of the
> project and map layers will likely have large impact on your plugin,
> and I'd hate to see you have to "port twice". By the time feature
> freeze comes into play the large API changes will all have been locked
> in (or have to wait till 4.0!).
> 
> There's no time frame for this yet, but I'll fight hard against any
> plans for a release before mid-year.
> 
> Nyall
> 
>> Thanks
>> 
>> Tom
>> 
>> -
>> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
>> --
>> View this message in context: 
>> http://osgeo-org.1560.x6.nabble.com/When-to-start-converting-our-plugins-tp5302167.html
>> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

Re: [Qgis-developer] Will Processing in QGIS 3 support parallelization?

[Neumann, Andreas]

Hi Nyall, 

Interesting. 

Your "thinking aloud" - is this something that would have to wait for
QGIS 4x or could this be interested in 3.x already? Just wondering ... 

>From a user point of view it would be very interesting to have
processing within a layer in update mode without having to create
separate new layers. Also, of course, the parallelization option (for
certain algorithms where feasible). 

Andreas 

On 2017-01-06 00:11, Nyall Dawson wrote:

> On 3 January 2017 at 18:19, Anita Graser  wrote: 
> 
>> Hi,
>> 
>> I'm currently writing a script that could benefit a lot from
>> parallelization. Will Processing in QGIS 3 provide parallelization support?
>> Or is it better to look into how to achieve parallelization independent of
>> Processing, e.g. using Python's multiprocessing library?
> 
> Depends what you're after. When processing is ported to the new task
> manager framework then algorithms will be able to run in parallel
> (where possible). Eg a buffer for one layer can run while a transform
> occurs on another layer.
> 
> If you're after parallelization *within* a single algorithm (Eg
> buffering features using multiple threads) then I'm unaware of any
> plans in place to handle this.
> 
> * That said read on for some thinking aloud
> 
> I think when we port the guts of processing over to c++ then this will
> become relatively straightforward. I'd see this happening:
> - algorithms which operate feature-by-feature inherit a special
> algorithm subclass (say "QgsFeatureBasedAlgorithm" or something) and
> override some base class "QgsFeature processFeature( QgsFeature )"
> method. Eg a buffer alg will implement this to buffer the passed
> feature's geometry and return a new modified feature.
> - QgsFeatureBasedAlgorithm could take advantage of something like
> QtConcurrent::mappedReduced to call processFeature on multiple threads
> and use the result function to write out the results for each
> processFeature call. Nice and (theoretically) easy way to gain
> multithreaded algorithms, and it would be simple to adapt many
> existing algorithms to this (buffer, centroid, transform, translate,
>  Basically anything which operates on each feature in isolation).
> 
> The side benefit of this refactoring would allow something I've wanted
> for a while - a way for processing algorithms to modify a selection
> inside a layer "in place". Eg select a bunch of polygons, run the
> buffer alg on the selection (not sure of the best UI to expose this!)
> and each selected feature will be buffered. Currently there's no easy
> way to do this in QGIS - you've got to run the alg on a selection and
> get a new layer, then delete the selection, and finally copy features
> back from the new output layer to the source layer. Yuck.
> 
> Nyall
> 
>> Thank you and best wishes,
>> Anita
>> 
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

Re: [Qgis-developer] When to start converting our plugins?

[Bernhard Ströbl]

Hi Tom,

would be great to have your and anybody else's experiences and how tos 
available for reference by then. Is there a website where people can 
contribute?


Bernhard

Am 06.01.2017 um 00:23 schrieb Tom Chadwin:

Nyall Dawson wrote

I'd say just before/after feature freeze.


Sounds sensible. Any ideas on how long between beginning of feature freeze
and release? Could be *a lot* of plugin devs pleading for help from QGIS
devs.

Thanks again

Tom






__ Information from ESET Mail Security, version of virus signature 
database 14724 (20170106) __

The message was checked by ESET Mail Security.
http://www.eset.com


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

[Qgis-developer] Channel network and drainage basins/ DLL file “gdal_MrSID.dll

[Lene Fischer]

Algorithm Channel network and drainage basins starting...

io_gdal 0 -TRANSFORM -INTERPOL 0 -GRIDS 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\483ce22722a4416eb2237bbcce8bba48\FilledDEM.sgrd"
 -FILES "C:/Users/nkx236/Documents/QGIS_Olea/watershed/FilledDEM2.tif"

ta_channels "Channel Network and Drainage Basins" -DEM 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\483ce22722a4416eb2237bbcce8bba48\FilledDEM.sgrd"
 -THRESHOLD 5 -DIRECTION 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\cc40facb1fcc450cb561ba0f7dd986f4\DIRECTION.sdat"
 -CONNECTION 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\79c7f097ffc94ff496877f8bd5a031d3\CONNECTION.sdat"
 -ORDER 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\1eed588961424d2db7f4d835a7c9f72c\ORDER.sdat"
 -BASIN 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\ca1bbe1febf2411da8cda102d3fb6352\BASIN.sdat"
 -SEGMENTS "C:/Users/nkx236/Documents/QGIS_Olea/watershed/channels5.shp" 
-BASINS "C:/Users/nkx236/Documents/QGIS_Olea/watershed/drainage5.shp" -NODES 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\a22b05dd659a499ca34eaa518ad9bf86\NODES.shp"



C:\PROGRA~1\QGIS2~1.16\bin>set SAGA=C:/PROGRA~1/QGIS2~1.16/apps\saga



C:\PROGRA~1\QGIS2~1.16\bin>set SAGA_MLB=C:/PROGRA~1/QGIS2~1.16/apps\saga\modules



C:\PROGRA~1\QGIS2~1.16\bin>PATH=C:\PROGRA~1\QGIS2~1.16\apps\Python27\lib\site-packages\Shapely-1.2.18-py2.7-win-amd64.egg\shapely\DLLs;C:\PROGRA~1\QGIS2~1.16\apps\Python27\DLLs;C:\PROGRA~1\QGIS2~1.16\apps\Python27\lib\site-packages\numpy\core;C:\PROGRA~1\QGIS2~1.16\apps\qgis\bin;C:\PROGRA~1\QGIS2~1.16\apps\grass\grass-7.0.4\lib;C:\PROGRA~1\QGIS2~1.16\apps\grass\grass-7.0.4\bin;C:\PROGRA~1\QGIS2~1.16\apps\Python27\Scripts;C:\PROGRA~1\QGIS2~1.16\bin;C:\Windows\system32;C:\Windows;C:\Windows\WBem;C:/PROGRA~1/QGIS2~1.16/apps\saga;C:/PROGRA~1/QGIS2~1.16/apps\saga\modules



C:\PROGRA~1\QGIS2~1.16\bin>saga_cmd io_gdal 0 -TRANSFORM -INTERPOL 0 -GRIDS 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\483ce22722a4416eb2237bbcce8bba48\FilledDEM.sgrd"
 -FILES "C:/Users/nkx236/Documents/QGIS_Olea/watershed/FilledDEM2.tif"

ERROR 1: Can't load requested DLL: 
C:\PROGRA~1\QGIS2~1.16\apps\saga\dll\gdal_MrSID.dll

127: The specified procedure could not be found.





ERROR 1: Can't load requested DLL: 
C:\PROGRA~1\QGIS2~1.16\apps\saga\dll\gdal_MrSID.dll

127: The specified procedure could not be found.





_



# ## # ##

### ### ## ###

### # ## ##  # ##

### # ## # #

# # ## # # ##

_



_

library path: C:\PROGRA~1\QGIS2~1.16\apps\saga\modules\io_gdal.dll

library name: Import/Export - GDAL/OGR

tool name : GDAL: Import Raster

author : O.Conrad (c) 2007 (A.Ringeler)

_







Parameters





Grids: No objects

Files: "C:/Users/nkx236/Documents/QGIS_Olea/watershed/FilledDEM2.tif"

Transformation: yes

Interpolation: Nearest Neighbor





loading: C:/Users/nkx236/Documents/QGIS_Olea/watershed/FilledDEM2.tif







Driver: GTiff



Bands: 1



Rows: 15578



Columns: 7994







Transformation:



x' = 881887.358794 + x * 0.399987 + y * 0.00



y' = 6123496.077786 + x * 0.00 + y * -0.399987





loading band [1/1]

Hi,

One of my phd students are working with a SAGA "Channel network and drainage 
basins”

He wrote this to me - and I have tried to solve the problem by re-install QGIS 
- but nothing seems to work. At my computer it´s OK

Can someone try to “translate” the problem:



I cannot execute the “Channel network and drainage basins” plug in. A problem 
in Saga with the DLL file “gdal_MrSID.dll” seems to be the cause. Attached is a 
screendrop of the dialogue box and a script from the log. My ‘filled DEM’ seems 
fine.



I am using Qgis 2.18.2, but have also tried an earlier version 2.16 something, 
with the same result. I use it on a Dell Latitude E6530 with 4 GB RAM and an i5 
2.60 GHz processor operated with a 64-bit Windows 7 Enterprise system.



Sincerely,

Jonas











C:\PROGRA~1\QGIS2~1.16\bin>saga_cmd ta_channels "Channel Network and Drainage 
Basins" -DEM 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\483ce22722a4416eb2237bbcce8bba48\FilledDEM.sgrd"
 -THRESHOLD 5 -DIRECTION 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\cc40facb1fcc450cb561ba0f7dd986f4\DIRECTION.sdat"
 -CONNECTION 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\79c7f097ffc94ff496877f8bd5a031d3\CONNECTION.sdat"
 -ORDER 
"C:\Users\nkx236\AppData\Local\Temp\processing9c62242c21ca4504a2eb350d242142cc\1eed588961424d2db7f4d835a7c9f72c\ORDER.sdat"
 

Re: [Qgis-developer] When to start converting our plugins?

[Nyall Dawson]

On 6 January 2017 at 09:51, Mathieu Pellerin  wrote:
> Tom,
>
> While Nyall's right to point out further API disruption on the horizon, your
> exercise isn't in vain since the plugin adjustments you've figured out will
> still be needed when porting season will open.

That's true for some changes (such as python 3, Qt 5), but there's no
gaurantee that 3.0 breaks within PyQGIS won't be changed later in the
3.0 cycle.

So yes, this *is* a good time to port to python 3, Qt5, PyQt5 so long
as you don't do major refactoring which may be affected by the PyQGIS
api!

Nyall

>
> If you have time, you should write a blog post somewhere to detail this
> experience of yours, I'm sure it'll be useful to many.
>
> M
>
> On Jan 6, 2017 06:23, "Tom Chadwin"  wrote:
>>
>> Nyall Dawson wrote
>> > I'd say just before/after feature freeze.
>>
>> Sounds sensible. Any ideas on how long between beginning of feature freeze
>> and release? Could be *a lot* of plugin devs pleading for help from QGIS
>> devs.
>>
>> Thanks again
>>
>> Tom
>>
>>
>>
>> -
>> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
>> --
>> View this message in context:
>> http://osgeo-org.1560.x6.nabble.com/When-to-start-converting-our-plugins-tp5302167p5302225.html
>> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] When to start converting our plugins?

[Marco Bernasocchi]

I've already updated a rather large plugin some months ago. and created
a compatibilty layer plugin. have a look here

http://www.opengis.ch/2016/09/19/qgis2-compatibility-plugin/


ciao
On 06.01.2017 00:51, Mathieu Pellerin wrote:
> If you have time, you should write a blog post somewhere to detail this
> experience of yours, I'm sure it'll be useful to many. 

-- 
Marco Bernasocchi
OPENGIS.ch - berna.io - 27summits.ch



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

Re: [Qgis-developer] When to start converting our plugins?

[Mathieu Pellerin]

Tom,

While Nyall's right to point out further API disruption on the horizon,
your exercise isn't in vain since the plugin adjustments you've figured out
will still be needed when porting season will open.

If you have time, you should write a blog post somewhere to detail this
experience of yours, I'm sure it'll be useful to many.

M

On Jan 6, 2017 06:23, "Tom Chadwin"  wrote:

> Nyall Dawson wrote
> > I'd say just before/after feature freeze.
>
> Sounds sensible. Any ideas on how long between beginning of feature freeze
> and release? Could be *a lot* of plugin devs pleading for help from QGIS
> devs.
>
> Thanks again
>
> Tom
>
>
>
> -
> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> --
> View this message in context: http://osgeo-org.1560.x6.
> nabble.com/When-to-start-converting-our-plugins-tp5302167p5302225.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] When to start converting our plugins?

[Tom Chadwin]

Nyall Dawson wrote
> I'd say just before/after feature freeze.

Sounds sensible. Any ideas on how long between beginning of feature freeze
and release? Could be *a lot* of plugin devs pleading for help from QGIS
devs.

Thanks again

Tom



-
Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon 
--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/When-to-start-converting-our-plugins-tp5302167p5302225.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS setup with Qt 5 on mac

[Nyall Dawson]

On 1 January 2017 at 09:41, Larry Shaffer  wrote:

> Yep: https://github.com/Homebrew/homebrew-core/pull/8306
>
> Qt5 is now the default, since ~ yesterday, and `qt` and `pyqt` are now
> aliases to Qt5 formulae. I've pushed some fixes, please `brew update` try
> again.

Thanks Larry - that worked perfectly!

>
> Please try following the dev tutorial, once you have it building. Any
> feedback appreciated (using the github issue tracker there).
>
> https://github.com/qgis/homebrew-qgisdev/tree/master/development

Will do - it's not my machine, so I only get occasional access. I'll
let you know when I've given it a test.

Nyall


>
> Regards,
>
> Larry Shaffer
> Dakota Cartography
> Black Hills, South Dakota
>
>>
>>
>> Nyall
>>
>>
>>
>>
>>
>> >
>> > Takes ~ 18-20 mins to build on a newer Mac with 8 cores. There is a long
>> > pause when compiling src/core/qgsxmlutils.cpp (not sure why it happens
>> > only
>> > for a Homebrew formula).
>> >
>> > Note: there are definitely macOS-related bugs in the resultant QGIS.app.
>> > Please report them as QGIS bugs, unless you think it is related to the
>> > formula, then report on github tracker for homebrew-qgisdev repo.
>> >
>> > If you have the time, please test this and contribute however you can.
>> > Thanks!
>> >
>> > I am working on a 'qgis3-travis' formula, specific for use in main QGIS
>> > source tree Travis CI testing. Also working on an updated tutorial for
>> > using
>> > Qt Creator 4.1, etc. to develop on QGIS source based upon these formulae
>> > Homebrew dependencies (much easier now).
>> >
>> > Regards,
>> >
>> > Larry Shaffer
>> > Dakota Cartography
>> > Black Hills, South Dakota
>> >
>> > On Thu, Nov 17, 2016 at 6:55 PM, Larry Shaffer 
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> Quick update. Success! I've finally built QGIS 3 master branch off of
>> >> unmodified Homebrew dependencies, though had to edit several bits of
>> >> source
>> >> code and pull some hair out.
>> >>
>> >> QGIS version: 2.99.0-Master
>> >> QGIS code revision: 6727ea7
>> >> Compiled against: Qt 5.7.0
>> >> Running against Qt: 5.7.0
>> >> Compiled against GDAL/OGR: 2.1.2
>> >> Running against GDAL/OGR: 2.1.2
>> >> Compiled against GEOS: 3.5.0-CAPI-1.9.0
>> >> Running against GEOS: 3.5.0-CAPI-1.9.0 r4084
>> >> PostgreSQL Client Version: 9.6.1
>> >> SpatiaLite Version: 4.3.0a
>> >> QWT Version: 6.1.3
>> >> PROJ.4 Version: 493
>> >> QScintilla2 Version: 2.9.3
>> >> This copy of QGIS writes debugging output.
>> >>
>> >> and Python 3.5.2.
>> >>
>> >>
>> >> http://drive.dakotacarto.com/qgis/qgis3-master_homewbrew-macos-10.11.png
>> >>
>> >> It's take me a bit more time to commit proper changes, create the
>> >> qgis3-dev formula and add the docs for:
>> >>
>> >> https://github.com/qgis/homebrew-qgisdev
>> >>
>> >> Is anyone else already developing QGIS 3 master on Mac?
>> >>
>> >> Regards,
>> >>
>> >> Larry Shaffer
>> >> Dakota Cartography
>> >> Black Hills, South Dakota
>> >>
>> >> On Tue, Nov 8, 2016 at 1:02 PM, Rouzaud Denis 
>> >> wrote:
>> >>>
>> >>> Hi Larry,
>> >>>
>> >>> Thanks a lot for tackling this!
>> >>> Glad to read it’ll land soon, but no pressure ;)
>> >>>
>> >>> Cheers,
>> >>> Denis
>> >>>
>> >>>
>> >>> On 8 Nov 2016, at 18:13, Larry Shaffer  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> On Sun, Nov 6, 2016 at 7:23 PM, Etienne Trimaille
>> >>>  wrote:
>> 
>>  Thanks David and Matthias for providing some feedbacks about QGIS 3
>>  on
>>  mac.
>>  I also would like QGIS 3 compiling on mac.
>> 
>>  I hope you will update the install.md on the repo when you will have
>>  a
>>  working workflow ? Thanks
>> >>>
>> >>>
>> >>> I have been preparing Homebrew and OSGeo4Mac 'taps' for this move and
>> >>> am
>> >>> now focusing on QGIS 3 formulae, probably starting on Thursday or
>> >>> Friday. I
>> >>> hope to have everything building and docs completed by the end of the
>> >>> weekend.
>> >>>
>> >>> The new formulae will not be hosted in OSGeo4Mac or Homebrew (at least
>> >>> not until there are stable releases), but in a specific tap for QGIS
>> >>> development and Travis CI support:
>> >>>
>> >>> https://github.com/qgis/homebrew-qgisdev
>> >>>
>> >>> So, look for changes there as things progress. Please contribute or
>> >>> post
>> >>> bug reports there for those dev formulae or docs, once they are
>> >>> available.
>> >>>
>> >>> Regards,
>> >>>
>> >>> Larry Shaffer
>> >>> Dakota Cartography
>> >>> Black Hills, South Dakota
>> >>>
>> 
>>  2016-11-01 1:22 GMT+07:00 Matthias Kuhn :
>> >
>> > Hi Diane and welcome aboard,
>> >
>> > I also didn't manage to compile master on osx yet.
>> >
>> > Some more information can be found here also:
>> >
>> >
>> >
>> > https://github.com/OSGeo/homebrew-osgeo4mac/pull/146#issuecomment-254011621
>> >
>> > I think most of 

Re: [Qgis-developer] Will Processing in QGIS 3 support parallelization?

[Nyall Dawson]

On 3 January 2017 at 18:19, Anita Graser  wrote:
> Hi,
>
> I'm currently writing a script that could benefit a lot from
> parallelization. Will Processing in QGIS 3 provide parallelization support?
> Or is it better to look into how to achieve parallelization independent of
> Processing, e.g. using Python's multiprocessing library?

Depends what you're after. When processing is ported to the new task
manager framework then algorithms will be able to run in parallel
(where possible). Eg a buffer for one layer can run while a transform
occurs on another layer.

If you're after parallelization *within* a single algorithm (Eg
buffering features using multiple threads) then I'm unaware of any
plans in place to handle this.



* That said read on for some thinking aloud

I think when we port the guts of processing over to c++ then this will
become relatively straightforward. I'd see this happening:
- algorithms which operate feature-by-feature inherit a special
algorithm subclass (say "QgsFeatureBasedAlgorithm" or something) and
override some base class "QgsFeature processFeature( QgsFeature )"
method. Eg a buffer alg will implement this to buffer the passed
feature's geometry and return a new modified feature.
- QgsFeatureBasedAlgorithm could take advantage of something like
QtConcurrent::mappedReduced to call processFeature on multiple threads
and use the result function to write out the results for each
processFeature call. Nice and (theoretically) easy way to gain
multithreaded algorithms, and it would be simple to adapt many
existing algorithms to this (buffer, centroid, transform, translate,
 Basically anything which operates on each feature in isolation).

The side benefit of this refactoring would allow something I've wanted
for a while - a way for processing algorithms to modify a selection
inside a layer "in place". Eg select a bunch of polygons, run the
buffer alg on the selection (not sure of the best UI to expose this!)
and each selected feature will be buffered. Currently there's no easy
way to do this in QGIS - you've got to run the alg on a selection and
get a new layer, then delete the selection, and finally copy features
back from the new output layer to the source layer. Yuck.

Nyall





>
> Thank you and best wishes,
> Anita
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] When to start converting our plugins?

[Nyall Dawson]

On 6 January 2017 at 03:43, Tom Chadwin  wrote:
> Hello all
>
> Amazing work going on for QGIS3 - I'm in awe of you all (as always).
>
> I've been getting more and more nervous about how easy it will be to convert
> my plugin, so yesterday I started to have a go. With lots of help from
> Matthias (huge thanks, as ever!), I got a good way through the process. I
> think I can now do it. I certainly don't feel so nervous.
>
> However, Nyall pointed out that there is still a lot of change to come to
> the API. I'm happy to abandon the work I've done so far, as it has achieved
> its aim of getting me familiar with what the job will entail.
>
> So, my question is, when would be the best time to start the actual
> conversion of our plugins? Is there going to be an obvious time in QGIS3
> development for this to happen? Can it be announced on the list?

I'd say just before/after feature freeze. There's still some very
large API changes in store, eg Martin's current refactoring of the
project and map layers will likely have large impact on your plugin,
and I'd hate to see you have to "port twice". By the time feature
freeze comes into play the large API changes will all have been locked
in (or have to wait till 4.0!).

There's no time frame for this yet, but I'll fight hard against any
plans for a release before mid-year.

Nyall



>
> Thanks
>
> Tom
>
>
>
> -
> Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
> --
> View this message in context: 
> http://osgeo-org.1560.x6.nabble.com/When-to-start-converting-our-plugins-tp5302167.html
> Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] reading GRIB data

[Paolo Cavallini]

Il 05/01/2017 17:07, Even Rouault ha scritto:
...
> That's a defect of the driver I'm aware of. It should expose those as
> subdatasets to fit the model of a GDAL dataset.

BTW, width seems approx right, height is badly wrong.
All the best.

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

Re: [Qgis-developer] reading GRIB data

[Paolo Cavallini]

Il 05/01/2017 17:07, Even Rouault ha scritto:
...
> That's a defect of the driver I'm aware of. It should expose those as
> subdatasets to fit the model of a GDAL dataset.

Thanks for checking. If there is anything I can do, please do not
hesitate. Could we check zyGrib approach? It seems smooth there.
All the best.

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

Re: [Qgis-developer] reading GRIB data

[Paolo Cavallini]

Il 05/01/2017 16:31, Even Rouault ha scritto:
> This is a bit vague as a description of issues ;-) gdalinfo reports on
> datasets would be a start. GRIB support is generally a pain due to the
> diversity of the format.

Hi Even,
sorry for being vague - I hoped I was just missing something obvious,
and an howto was already available. Life is mostly more complicated :)
So, symptoms:
* the grib is loaded with a custom CRS:
 * Generated CRS (+proj=longlat +a=6371200 +b=6371200 +no_defs)
* it occupies a thin vertical stretch, from about 1.86884,-1418.31515 to
about 18.142,67.489
* colours are obviously not understandable
* the bands are superimposed, as if it was an RGB file, not
understanding the multiband structure of GRIB
* a series of warning is issued, of the type:
Warning 1: Band 895 of GRIB dataset is 33x23, while the first band and
dataset is 65x45.  Georeferencing of band 895 may be incorrect, and data
access may be incomplete.
* gdalinfo reports:
Driver: GRIB/GRIdded Binary (.grb)
Files: data
   data.aux.xml
Size is 65, 45
Coordinate System is:
GEOGCS["Coordinate System imported from GRIB file",
DATUM["unknown",
SPHEROID["Sphere",6371200,0]],
PRIMEM["Greenwich",0],
UNIT["degree",0.0174532925199433]]
Origin = (1.875,67.509)
Pixel Size = (0.250,-33.0180001)
Corner Coordinates:
Upper Left  (   1.875,  67.509) (  1d52'30.00"E, 67d30'32.40"N)
Lower Left  (   1.875,   -1418.301) (  1d52'30.00"E,Invalid angle)
Upper Right (  18.125,  67.509) ( 18d 7'30.00"E, 67d30'32.40"N)
Lower Right (  18.125,   -1418.301) ( 18d 7'30.00"E,Invalid angle)
Center  (  10.000,-675.396) ( 10d 0' 0.00"E,Invalid angle)
Band 1 Block=65x1 Type=Float64, ColorInterp=Undefined
  Description = 0[-] var10 (reserved)
  Min=0.000 Max=100.000
  Minimum=0.000, Maximum=100.000, Mean=37.745, StdDev=41.769
  Metadata:
GRIB_COMMENT=Total cloud cover [%]
GRIB_ELEMENT=TCDC
GRIB_FORECAST_SECONDS=10800 sec
GRIB_REF_TIME=1440050400 sec UTC
GRIB_SHORT_NAME=0-var10
GRIB_UNIT=[%]
GRIB_VALID_TIME=1440061200 sec UTC
STATISTICS_MAXIMUM=100
STATISTICS_MEAN=37.745299145299
STATISTICS_MINIMUM=0
STATISTICS_STDDEV=41.768590202144
Band 2 Block=65x1 Type=Float64, ColorInterp=Undefined
...
* zyGrib opens and displays the same file just fine.
All the best, and thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] reading GRIB data

[Even Rouault]

On jeudi 5 janvier 2017 14:46:34 CET Paolo Cavallini wrote:
> ll,
> according to http://www.gdal.org/frmt_grib.html GDAL, thus QGIS, should
> be able to read GRIB data. I did a bit of testing and I cannot get
> meaningful results, apparently because of projections and colour table
> issues. Has someone experience on this, and can you point me to an howto?

Paolo,

This is a bit vague as a description of issues ;-) gdalinfo reports on datasets 
would be 
a start. GRIB support is generally a pain due to the diversity of the format.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] reference relation widget - filter by expressions and spatial relations?

[Régis Haubourg]

Hi, 
I'm trying to allow a user to set a relation from reference relation widget. 
I can't find a way to filter candidates by a spatial expression such
map_canvas extent, or better by distance. 
Currently, I have to set the list to read only so that user can't display a
dropdown list of thousands of features, which kills QGIS. User only have the
choice to use the map pointer tool, or use "link it" plugin. 
I saw Alessandro's work for value relation filtering with form "value
relation plugin" , which works great with a python function. 
The same feature for reference relation widget would be cool.

Dreaming of the perfect tool, I even think of these features:
- display name on expression with the ability to compute distance between
current object and candidate
- display on the fly a curved arrow rubberband between selected relation and
current feature, to have a visual feedback before saving (already in link it
plugin)

Is there anyone working on that area? 
Cheers
Régis




-
--
Régis Haubourg
GIS administrator and project manager
Administrateur de données géographiques et chef de projet SIG
Agence de l'eau Adour-Garonne 

--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/reference-relation-widget-filter-by-expressions-and-spatial-relations-tp5302113.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] reading GRIB data

[Paolo Cavallini]

Hi all,
according to http://www.gdal.org/frmt_grib.html GDAL, thus QGIS, should
be able to read GRIB data. I did a bit of testing and I cannot get
meaningful results, apparently because of projections and colour table
issues. Has someone experience on this, and can you point me to an howto?
Thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Raster: multiply causes NULLs to be painted in black?

[Paolo Cavallini]

Hi all,
on current master, if I load a coloured TIFF, it is displayed correctly.
If I change the blending mode to Multiply, the NULLs (0s) are displayed
black, and they remain black even if I switch back to Blending=Normal.
On 2.18, the same TIFF is displayed as expected.
Sample image available. Should I open a ticket?
All the best.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer