Re: [QGIS-Developer] Issue running processing model from Python

[Nyall Dawson]

On 26 April 2018 at 17:14, Andreas Neumann  wrote:
> Hi,
>
> Issue solved - turned out that the layer in the project file was renamed (by
> a colleague) and hence processing could not find the feature source. All
> works fine now. Silly me!
>
> However, the processing error message was really misleading and had no
> indication that it could not find the layer. Nyall is going to fix the error
> message - thanks!

Hi Andreas,

Should be fixed by https://github.com/qgis/QGIS/pull/6874 . I'd
greatly value a test of that branch with the invalid project/model
combination to confirm that you get a helpful error message.

Nyall

>
> Sorry about the noise - it is a classic "beginners mistake" ;-)
>
> Andreas
>
> On 2018-04-25 12:19, Tom Chadwin wrote:
>
> Sorry, not having worked with models, I don't know. Only thing I wonder is
> whether it is a problem to have colons in a dictionary key
> (native:orderbyexpression_1:Ausgabedatei).
>
> 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

Re: [QGIS-Developer] R provider for QGIS 3 - any interest?

[Nyall Dawson]

On 26 April 2018 at 22:10, Barry Rowlingson
 wrote:
> As a long-time R spatial developer and QGIS user I'll be glad to help out -
> but time-poor at work for now. "Helping out" may be more  like "making
> unreasonable suggestions" and "finding annoying bugs".

Don't undersell yourself... these would be very valuable contributions!

> For example, can we find a more efficient way to transfer data from QGIS to
> R? Can the new `sf` packages in R work with the data straight out of QGIS'
> memory? I *think* the `sf` package stores vector data in GDALs native C++
> objects, and if QGIS is doing that too then we *might* be able to get access
> from QGIS and R if we write the R plugin as a C/C++ module that dynamically
> links with the shareable libR.so.

I've (very roughly) looked into this, and I also believe it should be
possible to directly create R data frames from QGIS layers. Then we'd
just need to add a "R console" to QGIS, and boom! Awesome spatial
statistical analysis tool directly within QGIS!

Nyall

>
> The current R processing plugin  converts QGIS layers to shapefiles, reads
> them into a new R process. On occasion I've hit problems with shapefile
> limitations (field name length, usually) that make my scripts fail. Maybe it
> should go via geopackage instead.
>
> Should it create `sp` objects on the R side or `sf` objects? This could be
> controllable in the R processing script headers, so it can be set on a
> per-script basis.
>
> I'll stop now...
>
> Barry
>
>
>
>
>
>
> On Thu, Apr 26, 2018 at 9:42 AM, Aurelio Pires  wrote:
>>
>> +1
>>
>> Thanks,
>>
>>
>> On 2018-04-26 07:40, Paolo Cavallini wrote:
>> > Hi all,
>> >
>> > Il 26/04/2018 05:08, Nyall Dawson ha scritto:
>> >> I'm VERY interested in seeing this resurrected. I'm available to
>> >> mentor this task if someone else wants to take ownership of the plugin
>> >> and do the port, OR alternatively I'd be happy for North Road to do
>> >> the porting ourselves and take over maintenance if someone can fund
>> >> this work.
>> > that's good news. So starting a crowdfunding campaign seems a good way
>> > to go, unless there is a bigger sponsor; do you agree?
>> > All the best, and 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
>
>
>
> ___
> 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] Using memory layer in Processing with SAGA and GRASS

[Nyall Dawson]

On 26 April 2018 at 17:31, Benjamin Ducke  wrote:
>
>
> In the case of GRASS, this is a more complicated matter.
> GRASS uses a fully topological vector format and all
> input data will go through rigorous topology testing
> by default. The more intermediate steps, the higher
> the risk that data will get crippled in the process.
> Note that GRASS now has an alternative way of linking
> to external data instead of importing it:
>
> https://grass.osgeo.org/grass74/manuals/v.external.html
>
> So perhaps it would be a good idea for the QGIS GRASS
> provider to offer v.external as an alternative to
> v.in.ogr for piping QGIS vector layers into the GRASS
> backend (however, read "NOTES" on the page cited above!).

This was already done in 3.0 - if you check Processing Options, Grass
provider, there's a setting to use v.external instead of v.in.ogr.
It's on by default.

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] Parameters for QgsProcessingParameterRasterDestination

[Nyall Dawson]

On 27 April 2018 at 01:26, C Hamilton  wrote:
> Where do I find the format for the parameters of the processing description
> files. I have figured out  some of them, but for
> QgsProcessingParameterRasterDestination I would like to set it as optional
> and to skip it by default. This is the string that I have.
>
> QgsProcessingParameterRasterDestination|uncertainty|Name of uncertainty
> output map|None|True

They are directly mapped to the arguments given to the constructor for
QgsProcessingParameterRasterDestination:

https://qgis.org/api/classQgsProcessingParameterRasterDestination.html#aabd2f826354f38db8d9d47767d0015cd

Currently, to set the output to skipped by default, you need to call
setCreateByDefault(False) on the created parameter. So unfortunately
you can't set the parameter as skip-by-default from the grass
description files. https://github.com/qgis/QGIS/pull/6873 adds the
argument to the constructor, so when that PR is merged you'll be able
to do this by adding an extra bool argument to the end of the
parameter definition string in the description file.

Nyall


>
> This almost does it, but it does not set it to "Skip Output".
>
> 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
___
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 tests for SAGA

[Nyall Dawson]

On 26 April 2018 at 20:32, matteo  wrote:
> Hi devs,
>
> I found some broken SAGA algorithms (just the name of the parameters).
> Just one simple question: are the SAGA tests resurrected? I see the test
> file is available again:
>
> https://github.com/qgis/QGIS/commit/41a27f700ff7806cfe29490a757959adfd4f324b#diff-c567084a3d3994247ea380ed2549
>
> is it worth to add other tests or this is still a work in progress?

Yes please! The SAGA tests are enabled for both master and 3.0 Travis
builds, so more tests would be greatly appreciated.

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] Strange style rendering GEOS errors... can you confirm?

[Nyall Dawson]

On 27 April 2018 at 06:27, Luigi Pirelli  wrote:
> spam the log and reduce a lot the rendering time... it takes seconds for few
> polygons. ç

True...

Not sure what a good solution is here. Those geos warnings are often
very handy to see and for users to be aware of.

Got any ideas?

Nyall



>
> cheers
>
> 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 26 April 2018 at 05:00, Nyall Dawson  wrote:
>>
>> On 24 April 2018 at 21:06, Luigi Pirelli  wrote:
>> > Hi a colleague passed me a gpkg with a style that introduce GEOS
>> > exceptions
>> > during rendering... what? geos errors for a style?
>>
>> That's not unheard of - e.g. a line layer rendered using a simple line
>> style with an offset applied is using GEOS to offset the lines. A lot
>> of other symbology settings also call out to QgsGeometry methods which
>> use GEOS under the hood.
>>
>> Is this causing an actual error, or just spamming the log?
>>
>> 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] Suggestion for improved macOS build compatibility testing

[Nyall Dawson]

On 27 April 2018 at 03:58, Tom Elwertowski  wrote:
> Hi all,
>
> Both yesterday and today, the macOS build failed due to missing CMake
> INCLUDE specifications.

Should be fixed in master now.

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] Strange style rendering GEOS errors... can you confirm?

[Luigi Pirelli]

spam the log and reduce a lot the rendering time... it takes seconds for
few polygons. ç

cheers

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 26 April 2018 at 05:00, Nyall Dawson  wrote:

> On 24 April 2018 at 21:06, Luigi Pirelli  wrote:
> > Hi a colleague passed me a gpkg with a style that introduce GEOS
> exceptions
> > during rendering... what? geos errors for a style?
>
> That's not unheard of - e.g. a line layer rendered using a simple line
> style with an offset applied is using GEOS to offset the lines. A lot
> of other symbology settings also call out to QgsGeometry methods which
> use GEOS under the hood.
>
> Is this causing an actual error, or just spamming the log?
>
> 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] Suggestion for improved macOS build compatibility testing

[Matthias Kuhn]

Hi Tom,

Sorry to hear that. In the past we had macOS continuous integration
tests in place but had to disable them, because the package manager used
there (homebrew) was breaking dependencies unpredictably (I don't think
that's unexpected news for you if you are building on mac though ;) )

There is no "verification machine" on linux, but there is a docker
image. However I am not sure how easy it is to modify this image put
headers in different folders and make all the executables (xxx-config)
return the modified paths - while keeping the infrastructure maintainable.

Alternatively, I would very much like to get the mac builds back up and
running. I don't think we can do this again with the upstream homebrew
repo since we don't want our pull requests flagged erroneous for
external problems. The best alternative I see is, that we need a curated
list of formulae in a separate repository, which would not only help the
testing but potentially also the release process. Would you be
interested in taking a lead on this?

Best regards

Matthias


On 04/26/2018 07:58 PM, Tom Elwertowski wrote:
> Hi all,
>
> Both yesterday and today, the macOS build failed due to missing CMake
> INCLUDE specifications.
>
> MacOS puts each framework in a separate directory while Linux merges
> everything into /usr/local. Thus, Linux commits will compile when a
> new dependency is added as long as some other dependency already
> specifies /usr/local.
>
> Here is an idea that would help macOS build compatibility. Place each
> dependency on the verification build machine in a separate directory
> such as
> /usr/local/gdal-2.2.3/
> /usr/local/geos-3.6.1/
>
> This would make commits fail upfront on Linux if CMake INCLUDES needed
> by macOS were missing.
>
> Tom
> ___
> 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
>

-- 
Matthias Kuhn
matth...@opengis.ch 
+41 (0)76 435 67 63 
OPENGIS.ch Logo 
___
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] Suggestion for improved macOS build compatibility testing

[Tom Elwertowski]

Hi all,

Both yesterday and today, the macOS build failed due to missing CMake 
INCLUDE specifications.


MacOS puts each framework in a separate directory while Linux merges 
everything into /usr/local. Thus, Linux commits will compile when a new 
dependency is added as long as some other dependency already specifies 
/usr/local.


Here is an idea that would help macOS build compatibility. Place each 
dependency on the verification build machine in a separate directory such as

/usr/local/gdal-2.2.3/
/usr/local/geos-3.6.1/

This would make commits fail upfront on Linux if CMake INCLUDES needed 
by macOS were missing.


Tom
___
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] Parameters for QgsProcessingParameterRasterDestination

[C Hamilton]

Where do I find the format for the parameters of the processing description
files. I have figured out  some of them, but for
QgsProcessingParameterRasterDestination I would like to set it as optional
and to skip it by default. This is the string that I have.

QgsProcessingParameterRasterDestination|uncertainty|Name of uncertainty
output map|None|True

This almost does it, but it does not set it to "Skip Output".

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] R provider for QGIS 3 - any interest?

[Barry Rowlingson]

As a long-time R spatial developer and QGIS user I'll be glad to help out -
but time-poor at work for now. "Helping out" may be more  like "making
unreasonable suggestions" and "finding annoying bugs".

For example, can we find a more efficient way to transfer data from QGIS to
R? Can the new `sf` packages in R work with the data straight out of QGIS'
memory? I *think* the `sf` package stores vector data in GDALs native C++
objects, and if QGIS is doing that too then we *might* be able to get
access from QGIS and R if we write the R plugin as a C/C++ module that
dynamically links with the shareable libR.so.

The current R processing plugin  converts QGIS layers to shapefiles, reads
them into a new R process. On occasion I've hit problems with shapefile
limitations (field name length, usually) that make my scripts fail. Maybe
it should go via geopackage instead.

Should it create `sp` objects on the R side or `sf` objects? This could be
controllable in the R processing script headers, so it can be set on a
per-script basis.

I'll stop now...

Barry






On Thu, Apr 26, 2018 at 9:42 AM, Aurelio Pires  wrote:

> +1
>
> Thanks,
>
>
> On 2018-04-26 07:40, Paolo Cavallini wrote:
> > Hi all,
> >
> > Il 26/04/2018 05:08, Nyall Dawson ha scritto:
> >> I'm VERY interested in seeing this resurrected. I'm available to
> >> mentor this task if someone else wants to take ownership of the plugin
> >> and do the port, OR alternatively I'd be happy for North Road to do
> >> the porting ourselves and take over maintenance if someone can fund
> >> this work.
> > that's good news. So starting a crowdfunding campaign seems a good way
> > to go, unless there is a bigger sponsor; do you agree?
> > All the best, and 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
>
___
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] Can we remove a confirmation dialog in Refactor Fields algorithm?

[Germán Carrillo]

Hi Arnaud,


the videos I included in the first message of this thread were recorded
using QGIS master. So, probably the PR you mentioned (which was merged in
2017) didn't fully fix it, since this specific dialog is still showing up
when closing the project.


Regards,

Germán

2018-04-26 3:58 GMT-05:00 Arnaud Morvan :

> Hello Germán
>
> Note that I've already fixed some related problems with
> https://github.com/qgis/QGIS/pull/4964
>
> Calling deleteLater should delete the dialog on next events processing.
> Do dialog and child widgets signals should be correctly disconnected.
>
> Arnaud
>
>
>
> Le 25/04/2018 à 16:55, Germán Carrillo a écrit :
>
> Hi All,
>
>
> In the Refactor Fields algorithm dialog there is an "Input layer" combo
> box. Each time the user selects one layer a modal dialog (message box)
> appears, letting her select whether the fields mapping should be reset or
> not. See image: [1].
>
>
> I'd like to ask you if we can get rid of such modal dialog for these
> reasons:
>
>
> 1) In general, it's good to avoid modal dialogs as they block workflows
> and hamper interaction.
>
> 2) Other algorithms don't use such dialog to warn users about potential
> changes in other widgets (e.g., field combo boxes dependng on the selected
> layer).
>
> 3) The dialog is only *useful* if the user clicks on the combo box by
> accident and wants to avoid resetting the mapping (a very specific use
> case). However, in that case the combo box shows that a new layer is
> selected, but the mapping won't correspond to it, which is confusing.
>
> 4) Follow these steps:
>
>   a. Open QGIS and load a vector layer.
>   b. Open the Refactor Fields dialog and press ESC to close it.
>   c. Add another vector layer to QGIS.
>   d. Close the QGIS project.
>
> As soon as you close the project (e.g., when you want to start a new one)
> the modal  dialog shows up :(  (see this short video [2]).
>
> 5) The dialog is triggered too many times when using the "Fields Mapper"
> widget in a custom Processing model (and triggering it from a plugin) (see
> this short video [3]).
>
>
>
> So, the question for you is: Can we get rid of it? I've created a PR for
> that :D [4].
>
>
> Regards,
>
> Germán
> ---
> [1] http://downloads.tuxfamily.org/tuxgis/tmp/ai/reset_field_mapping.png
> [2] http://downloads.tuxfamily.org/tuxgis/tmp/ai/
> gif_refactor_fields_qgis.mp4
> [3] http://downloads.tuxfamily.org/tuxgis/tmp/ai/gif_
> refactor_fields_plugin.mp4
> [4] https://github.com/qgis/QGIS/pull/6857
> --
> ---
>|\__
> (:>__)(
>|/
> Soluciones Geoinformáticas Libres
> http://geotux.tuxfamily.org/
> http://twitter.com/GeoTux2
> http://about.me/germancarrillo
>
> 
>
>
> ___
> QGIS-Developer mailing listqgis-develo...@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
>



-- 
---
   |\__
(:>__)(
   |/
Soluciones Geoinformáticas Libres
http://geotux.tuxfamily.org/
http://twitter.com/GeoTux2
http://about.me/germancarrillo


___
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 tests for SAGA

[matteo]

Hi devs,

I found some broken SAGA algorithms (just the name of the parameters).
Just one simple question: are the SAGA tests resurrected? I see the test
file is available again:

https://github.com/qgis/QGIS/commit/41a27f700ff7806cfe29490a757959adfd4f324b#diff-c567084a3d3994247ea380ed2549

is it worth to add other tests or this is still a work in progress?

Thanks

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

Re: [QGIS-Developer] Can we remove a confirmation dialog in Refactor Fields algorithm?

[Arnaud Morvan]

Hello Germán

Note that I've already fixed some related problems with 
https://github.com/qgis/QGIS/pull/4964


Calling deleteLater should delete the dialog on next events processing.
Do dialog and child widgets signals should be correctly disconnected.

Arnaud


Le 25/04/2018 à 16:55, Germán Carrillo a écrit :

Hi All,


In the Refactor Fields algorithm dialog there is an "Input layer" 
combo box. Each time the user selects one layer a modal dialog 
(message box) appears, letting her select whether the fields mapping 
should be reset or not. See image: [1].



I'd like to ask you if we can get rid of such modal dialog for these 
reasons:



1) In general, it's good to avoid modal dialogs as they block 
workflows and hamper interaction.


2) Other algorithms don't use such dialog to warn users about 
potential changes in other widgets (e.g., field combo boxes dependng 
on the selected layer).


3) The dialog is only *useful* if the user clicks on the combo box by 
accident and wants to avoid resetting the mapping (a very specific use 
case). However, in that case the combo box shows that a new layer is 
selected, but the mapping won't correspond to it, which is confusing.


4) Follow these steps:

  a. Open QGIS and load a vector layer.
  b. Open the Refactor Fields dialog and press ESC to close it.
  c. Add another vector layer to QGIS.
  d. Close the QGIS project.

As soon as you close the project (e.g., when you want to start a new 
one) the modal  dialog shows up :(  (see this short video [2]).


5) The dialog is triggered too many times when using the "Fields 
Mapper" widget in a custom Processing model (and triggering it from a 
plugin) (see this short video [3]).




So, the question for you is: Can we get rid of it? I've created a PR 
for that :D [4].



Regards,

Germán
---
[1] http://downloads.tuxfamily.org/tuxgis/tmp/ai/reset_field_mapping.png
[2] 
http://downloads.tuxfamily.org/tuxgis/tmp/ai/gif_refactor_fields_qgis.mp4
[3] 
http://downloads.tuxfamily.org/tuxgis/tmp/ai/gif_refactor_fields_plugin.mp4

[4] https://github.com/qgis/QGIS/pull/6857
--
---
   |\__
(:>__)(
   |/
Soluciones Geoinformáticas Libres
http://geotux.tuxfamily.org/
http://twitter.com/GeoTux2
http://about.me/germancarrillo




___
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] R provider for QGIS 3 - any interest?

[Aurelio Pires]

+1

Thanks,


On 2018-04-26 07:40, Paolo Cavallini wrote:

Hi all,

Il 26/04/2018 05:08, Nyall Dawson ha scritto:

I'm VERY interested in seeing this resurrected. I'm available to
mentor this task if someone else wants to take ownership of the plugin
and do the port, OR alternatively I'd be happy for North Road to do
the porting ourselves and take over maintenance if someone can fund
this work.

that's good news. So starting a crowdfunding campaign seems a good way
to go, unless there is a bigger sponsor; do you agree?
All the best, and 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

[QGIS-Developer] Plugin [1443] Frame Pixels approval notification.

[noreply]

Plugin Frame Pixels approval by pcav.
The plugin version "[1443] Frame Pixels 0.2 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/FramePixels/
___
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 [1409] iso4app approval notification.

[noreply]

Plugin iso4app approval by pcav.
The plugin version "[1409] iso4app 0.4 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/iso4app/
___
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] Using memory layer in Processing with SAGA and GRASS

[Benjamin Ducke]

Hi,

On 26/04/18 08:53, Nyall Dawson wrote:
> On 26 April 2018 at 16:42, matteo  wrote:
>> Hi Nyall,
>>
>>> No - neither SAGA nor GRASS have any concept of QGIS memory layers.
>>> You need to give them a disk-based file path to save their outputs to.

That's not quite accurate. Even if they did have
such a concept, it would be of no use in this
context.

SAGA and GRASS commands run as separate processes,
in their own address spaces. Any reasonably secure
operating system (let's generously include Windows
and macOS in that category), will make sure that
processes cannot simply manipulate each other's
memory.

So QGIS needs to create temporary files to pass
both input and output data to/from GRASS/SAGA.

An alternative would be to refactor all
GRASS/SAGA modules as library objects so that they
could run in the same address space as QGIS.
That would probably also involve creating a new
interface API for use by QGIS (or other "host GIS").

Note that we are talking about C/C++ binaries here.
So one would also need to inspect every single GRASS/SAGA
binary and library for memory leaks (which can currently
be ignored, because memory is freed by the OS as soon as
the GRASS/SAGA commands' process ends).

>>
>> ok, clear now why this was not working
>>
>>
>>> If you use a memory layer as an input to these algs it will also have
>>> to save it out to a disk based format, but this is done automatically
>>> by saving to a file in the temp folder. We could potentially do the
>>> same thing to allow SAGA/GRASS algs to output to a memory layer by
>>> first saving the output to a shp in the temp folder, then loading that
>>> file and copying the features to a memory layer. But it would be
>>> rather inefficient and counter productive - you're still being forced
>>> to loop over the disk-based format, so you're just adding extra
>>> processing for little gain.
>>
>> so within a script (or a Processing plugin) both input layer and output
>> one have to come from a disk saved file.
> 
> Not quite - the input layer doesn't *have* to, because processing will
> automatically save it to a disk file if required.

In the case of SAGA, all this auto-creating files
is not too bad, because SAGA uses simple shapefiles
for vector data.

In the case of GRASS, this is a more complicated matter.
GRASS uses a fully topological vector format and all
input data will go through rigorous topology testing
by default. The more intermediate steps, the higher
the risk that data will get crippled in the process.
Note that GRASS now has an alternative way of linking
to external data instead of importing it:

https://grass.osgeo.org/grass74/manuals/v.external.html

So perhaps it would be a good idea for the QGIS GRASS
provider to offer v.external as an alternative to
v.in.ogr for piping QGIS vector layers into the GRASS
backend (however, read "NOTES" on the page cited above!).

Best,

Ben

> 
> 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
> 



-- 
Dr. Benjamin Ducke
Deutsches Archäologisches Institut (DAI)
Zentrale Berlin, IT-Referat
* Projekt "Stunde Null" *
___
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 [1037] Kortforsyningen approval notification.

[noreply]

Plugin Kortforsyningen approval by pcav.
The plugin version "[1037] Kortforsyningen 1.4" is now approved
Link: http://plugins.qgis.org/plugins/Kortforsyningen/
___
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 [1280] Coordtransform approval notification.

[noreply]

Plugin Coordtransform approval by pcav.
The plugin version "[1280] Coordtransform 1.1" is now approved
Link: http://plugins.qgis.org/plugins/Coordtransform/
___
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] Issue running processing model from Python

[Andreas Neumann]

Hi, 

Issue solved - turned out that the layer in the project file was renamed
(by a colleague) and hence processing could not find the feature source.
All works fine now. Silly me! 

However, the processing error message was really misleading and had no
indication that it could not find the layer. Nyall is going to fix the
error message - thanks! 

Sorry about the noise - it is a classic "beginners mistake" ;-) 

Andreas 

On 2018-04-25 12:19, Tom Chadwin wrote:

> Sorry, not having worked with models, I don't know. Only thing I wonder is
> whether it is a problem to have colons in a dictionary key
> (native:orderbyexpression_1:Ausgabedatei).
> 
> 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