[QGIS-Developer] SAGA release 7.3 (new LTR)

[Johan Van de Wauw]

Hi all,

SAGA has released a 7.3 version at the end of june, and I intend to keep a
stable branch based on this release, and drop support of the old branch
(which was not maintained well).
I am aware of the next-gen processing plugin at
https://plugins.qgis.org/plugins/processing_saga_nextgen/ which now targets
7.2, but wonder if we should not consider switching to this version also in
the normal processing plugin.

I'll be at FOSS4G later this month, so perhaps this is a good time to
implement/discuss some of these changes?

Kind regards,
Johan
___
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] [GRASS-dev] External providers in QGIS

[Johan Van de Wauw]

On Thu, Feb 15, 2018 at 6:22 PM, Anita Graser  wrote:

>
>
> On Sun, Feb 11, 2018 at 8:52 AM, Paolo Cavallini 
> wrote:
>
>> Il 10/02/2018 14:38, Anita Graser ha scritto:
>> > Since Madeira is just around the corner, let's organize a round table
>> > discussion on this issue. I've started a section here:
>> > https://github.com/qgis/QGIS/wiki/DeveloperMeetingMadeira201
>> 8#future-of-processing-providers
>> > Please add yourself to the list if you are interested in participating
>> > on-site or remotely. We'll then try to find a time slot that works for
>> > everyone.
>>
>> thanks Anita for setting it up.
>> Please all interested parties add your name to the list.
>>
>
> ​The currently suggested time is Feb 23rd 10:30 UTC+00.
>
> ​So far, we have six people signed up. Please get in touch if the time
> doesn't work for someone. We should be able to find a slot that's possible
> for all six.
>
> I'll try to join as well.

Kind Regards,
Johan
___
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-user] QGIS 2.18.11 - Problem with SAGA installation: unsupported SAGA version found.

[Johan Van de Wauw]

Other than 2.3.x to be correct (the others (2.3.0 /2.3.1 ) should work as well)

On Tue, Aug 8, 2017 at 7:26 AM, Alexandre Neto  wrote:
> Hi Calvin,
>
> Due to frequent changes in SAGA algorithms, that forced frequent updates to
> processing, it was decided to only support SAGA's long-term release. So, if
> you a version of SAGA other than 2.3.2, that might be the problem.
>
> Alexandre Neto
>
>
> A seg, 7/08/2017, 21:14, C Hamilton  escreveu:
>>
>> I realized that the SAGA routines were not showing up in the processing
>> tool box of the OSGeo4W 64 Windows QGIS 2.18.11 installation. The Processing
>> message is:
>>
>> Problem with SAGA installation: unsupported SAGA version found.
>>
>> Anyone else have this problem?
>>
>> Thanks,
>>
>> Calvin
>> ___
>> Qgis-user mailing list
>> qgis-u...@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
> --
> Alexandre Neto
> -
> @AlexNetoGeo
> http://sigsemgrilhetas.wordpress.com
> http://gisunchained.wordpress.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

[Qgis-developer] running processing tests for processing algorithms on windows

[Johan Van de Wauw]

Hi all,

One of my colleagues would like to write some unit tests for processing.
We were able to create some testfiles, but we failed to find an easy
way to run the testsuite on windows. Anyone a hint on the best way to
proceed?

Kind Regards,
Johan
___
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] zoo-kernel vs processing

[Johan Van de Wauw]

From the mail "status of qgis 3":
* Porting core of Processing to C++ (Nyall)

I wonder if anyone has had a look to the zoo project [1] which under
the hood is doing many things similar to processing.

Kind Regards,
Johan
[1]http://www.zoo-project.org/docs/kernel/what.html#first-class-wps-server
___
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] Improving Processing help files

[Johan Van de Wauw]

Hello matteo,

For the SAGA algorithms, the logical first place to update the
documentation would be in SAGA itself. It will be reviewed by the people
developing SAGA and can be synced to QGis
Our git repository is here:
https://sourceforge.net/p/saga-gis/code/ci/master/tree/ or you can use my
github mirror as well [1] if you prefer that workflow.

I'm available for help to get you started, or you can contact us through
saga-gis-develo...@lists.sourceforge.net

Kind Regards,
Johan
[1] https://github.com/johanvdw/SAGA-gis-git-mirror

On Tue, Dec 20, 2016 at 11:34 AM, Alexander Bruy 
wrote:

> Hi Matteo,
>
> IMHO better to defer this until we decide general approach for
> dealing with help. See:
>
> https://github.com/qgis/qgis3.0_api/issues/62
> https://github.com/qgis/qgis3_UIX_discussion/issues/15
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/51
>
> 2016-12-20 12:31 GMT+02:00 matteo :
> > Hi guys,
> >
> > I'm currently running some tests on QGIS3 - Processing and I just want
> > to share my idea.
> >
> > At the moment, for almost all the core algorithms, there is a small
> > lateral tab with a brief summary help.
> > Help is taken (please correct me) from qgis.yaml file within the help
> > folder of processing.
> >
> > IMHO, we can in some way improve the helping tab situation. My ideas are:
> >
> > * re-enabling a help tab (next to Log) where we can be more discursive
> > about the algorithm leaving there the side help tab
> > * IMHO, really important could be to enable the adding of images, this
> > can really help a lot (think of how faster is to understand with a
> > description linked to images)
> > * for external algorithms (SAGA but also GDAL) it would be really useful
> > to have some kind of help (SAGA) and some more descriptive help (GDAL)
> >
> >
> > What do you think about it? Could be difficult to extend a kind of rst
> > like syntax to build the helping tabs?
> >
> >
> > Obviously I can help (a little with the code and more with testing and
> > adding description)
> >
> >
> > Thanks to all!
> >
> >
> > Matteo
> > ___
> > 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
>
>
>
> --
> Alexander Bruy
> ___
> 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] SAGA and TauDEM algs in QGIS from KingChaos package

[Johan Van de Wauw]

Can you check if you have the same error when using saga_cmd without
using processing?

@William: Which compiler was used for saga on mac os x? We had an
issue with gcc6 - this looks similar. It is fixed in trunk and in
(upcoming) 2.3.2 release of SAA.

Kind Regards,
Johan

On Sun, Nov 20, 2016 at 7:15 PM, William Kyngesburye
 wrote:
> The version I bundle is 2.2.3, not 2.3.x, and is supported by Processing.
>
> I get the segfault when I try, details tell me it's happening when SAGA tries 
> to get the projection info from the file.  I don't know how to fix this, and 
> it's not a QGIS problem but a SAGA problem.  I wonder if SAGA 2.2.x is not 
> fully compatible with GDAL 2.1, I did see an initial item in the SAGA 2.2.0 
> changelog mentioning GDAL 2 compatibility that "was not complete", but no 
> other changes in later versions specifically about improving GDAL 2 
> compatibility.
>
>> On Nov 20, 2016, at 10:21 AM, Salvatore Larosa  wrote:
>>
>> On Sun, Nov 20, 2016 at 4:13 PM, Sebastiaan Couwenberg
>>  wrote:
>>> On 11/20/2016 04:11 PM, Salvatore Larosa wrote:
 I have installed 2.14.8 from William Kyngesburye's packages, all ok. I
 noticed that almost all the algs of SAGA and TauDEM do not work.
>>>
>>> http://hub.qgis.org/issues/13279
>>>
>>> SAGA changes its API too often, and QGIS has not been adapted to work
>>> with the SAGA 2.3.x LTS releases yet.
>>
>> Thank you for your quick reply.
>> The issue is a segfault here and OSX package (QGIS LTR 2.14.8) bundled
>> with SAGA 2.2.3.
>> Anyway I don't see a syntax command error as mentioned from the issue
>> which seems was fixed, at least for the 2.2.x version.
>>
>> Best Regards,
>> -SL
>>
>> --
>> Salvatore Larosa
>> linkedIn: http://linkedin.com/in/larosasalvatore
>> twitter: @lrssvt
>> skype: s.larosa
>> IRC: lrssvt on freenode
>> ___
>> 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
>
> -
> William Kyngesburye 
> http://www.kyngchaos.com/
>
> Earth: "Mostly harmless"
>
> - revised entry in the HitchHiker's Guide to the Galaxy
>
>
> ___
> 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] [Qgis-tr] Translation of QGIS Processing algorithm parameters

[Johan Van de Wauw]

Saga contains logic to translate the gui and modules, including german. See
the txt files here:
https://sourceforge.net/p/saga-gis/code/ci/master/tree/saga-gis/src/saga_core/saga_gui/res/

Translation should not happen in QGIS but in SAGA. We could definitely look
at how the translated strings of SAGA can pop up in processing. Please
contact us at the mailing list:
https://sourceforge.net/p/saga-gis/mailman/saga-gis-developer/ if you would
like to work on this.

Kind Regards,
Johan

On Wed, Sep 14, 2016 at 5:14 PM, DelazJ  wrote:

> (Forwarding to QGIS-Developer)
>
> Hi,
> Germán, I neither can find any of these strings.
>
> Devs, is that normal to not have texts from processing algorithms GUI not
> available in Transifex while the algorithm name itself is available (e.g.,
> Ordinary Kriging ...) to translation?
>
> Regards,
> Harrissou
>
> 2016-09-14 16:02 GMT+02:00 Germán Carrillo :
>
>> Transifex Webtranslation page for QGIS is on
>> https://www.transifex.com/qgis/
>>
>>
>> Hi Werner,
>>
>> thanks for your reply.
>>
>> I'm particularly interested in translating parameters of some SAGA
>> algorithms inside QGIS Processing GUI (e.g., [1]). However, I cannot find
>> the strings in Transifex (QGIS Desktop). Do you know what's the way to go?
>>
>> Regards,
>>
>> Germán
>> 
>> [1] http://downloads.tuxfamily.org/tuxgis/tmp/saga_algorithm
>> _parameters.png
>>
>> 2016-09-14 5:38 GMT-05:00 Werner Macho :
>>
>>> Transifex Webtranslation page for QGIS is on
>>> https://www.transifex.com/qgis/
>>>
>>> Hi!
>>>
>>> Sorry for the delay,
>>> Usually the language coordinators accept the people in their language
>>> (to at least speak to each other and better coordinate).
>>> Sometimes it can take some time (if the coordinator is on holiday or
>>> something like this).
>>> But if it takes more than a month it would be nice to inform me so that
>>> I can try to get in contact. If a language coordinator is not active
>>> anymore we have to search for a new one.
>>>
>>> But for now you should be accepted.
>>>
>>> kind regards and thanks for offering your help.
>>>
>>> Werner
>>>
>>> On 13/09/16 15:29, Germán Carrillo wrote:
>>> > Transifex Webtranslation page for QGIS is on
>>> https://www.transifex.com/qgis/
>>> >
>>> >
>>> >
>>> > Hi All,
>>> >
>>> > I'd like to join the Spanish-language team for QGIS Desktop
>>> translation.
>>> >
>>> > I've already signed-up in Transifex, but haven't received any
>>> > confirmation e-mail (even pressing the button 'resend confirmation
>>> > e-mail'). Tried changing the e-mail address with no success.
>>> >
>>> > My aim is to translate SAGA algorithm parameters in the QGIS Processing
>>> > GUI. Am I on the right track or is translation of QGIS Processing
>>> > algorithms done differently?
>>> >
>>> >
>>> > Regards,
>>> >
>>> > Germán
>>> > --
>>> > ---
>>> >|\__
>>> > (:>__)(
>>> >|/
>>> > Soluciones Geoinformáticas Libres
>>> > http://geotux.tuxfamily.org/
>>> > http://twitter.com/GeoTux2
>>> > http://about.me/germancarrillo
>>> >
>>> > 
>>> >
>>> >
>>> > ___
>>> > QGIS-Translators mailing list
>>> > qgis...@lists.osgeo.org
>>> > http://lists.osgeo.org/mailman/listinfo/qgis-tr
>>> >
>>> ___
>>> QGIS-Translators mailing list
>>> qgis...@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-tr
>>
>>
>>
>>
>> --
>> ---
>>|\__
>> (:>__)(
>>|/
>> Soluciones Geoinformáticas Libres
>> http://geotux.tuxfamily.org/
>> http://twitter.com/GeoTux2
>> http://about.me/germancarrillo
>>
>> 
>>
>> ___
>> QGIS-Translators mailing list
>> qgis...@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-tr
>>
>
>
> ___
> 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] saga 2.3.0 rc1 released - please help testing!

[Johan Van de Wauw]

Hi QGis devs,

Saga has just released the first RC candidate for version 2.3.0 [1]. For
those missing the earlier discussions, our goal is to make 2.3.x a long
term stable branch, ideal for eg using in processing.

This also means that now is an ideal time to test saga and report any
problems back, so we can still fix them before the 2.3 release.

One issue which was mentioned on this list, that saga_cmd only worked with
shapefiles [2] has been resolved: you can now pass other files supported by
ogr [3]. This could be very interesting for processing.

Kind Regards,
Johan

[1 ]https://sourceforge.net/p/saga-gis/mailman/message/35175078/

[2]
https://lists.osgeo.org/pipermail/qgis-developer/2016-June/042990.html
[3] https://sourceforge.net/p/saga-gis/mailman/message/35146184/
___
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] Geocoding plugin: a good case for merge

[Johan Van de Wauw]

On Thu, Jun 9, 2016 at 10:26 AM, Paolo Cavallini  wrote:

> IMO it would be fare preferable to have a general mechanism, better in
> core, and let people add their services there.
> So the question:
> * given the variety of geocoding services, si this feasible and would it
> make sense?
> * is any of the geocoding plugin developer willing to take this?
> All the best, and thanks.
> --
I don't think such a library should be specific to QGis. Plenty of use
cases  outside QGis. There already is a geocoder python project:
https://pypi.python.org/pypi/geocoder

Maybe that is a starting point?
___
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] Fwd: Cannot install QGIS anymore on debian stretch.... gdal-abi-2-0-2 absent ...any workarounds please

[Johan Van de Wauw]

Hello Gérard,

Forwarding your question to the debian gis mailing list where it is more
appropriate.
We have just had a gdal transition (to version 2.1).

Kind Regards,
Johan
-- Forwarded message --
From: Gérard Vidal 
Date: Fri, Jun 3, 2016 at 12:31 PM
Subject: [Qgis-developer] Cannot install QGIS anymore on debian stretch
gdal-abi-2-0-2 absent ...any workarounds please
To: Qgis-developer@lists.osgeo.org


Hi all,

after an  update/upgrade  of my debian stretch QGIS got uninstalled and it
is not any more possible to install it due to missing dependencies on
gdal-abi-2-0-2
gdal-abi-2-1-0 is virtual package provided by libgdal20


I am using the standard repo :
deb http://qgis.org/debian/ stretch main

Can you please change the dependencies or tell me what to do

Thanks
-- 
Gérard Vidal
Chargé de mission normes et veille technologique et numériques auprès du
Directeur de l'IFÉ.
Université de Lyon : IFÉ / ENS de Lyon 15 Parvis rené Descartes 69342 Lyon
Cedex07.
tel : [+33] (0)4 26 73 12 60.
[image: onglet] [image: logos]

___
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


signature.asc
Description: PGP 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] (Yet again) SAGA support badly broken in QGIS

[Johan Van de Wauw]

On Thu, Jun 2, 2016 at 3:09 PM, Bas Couwenberg  wrote:
> I notice a distinct lack of consideration for the SAGA LTR effort.
>
> That removes the need to incorporate SAGA into QGIS, and provides a stable
> API for 3rd parties to work with.
>
> I suggest to support the LTR effort by Johan van de Wauw, and only consider
> incorporating SAGA into QGIS if the LTR effort proves to not resolve the
> integration issues.
>
Thanks for reminding everyone Bas,

Perhaps some more info on our plans:
We plan to have a 2.3.0 release soon. This would be the first "LTR"
release, where we (I) will guarantee that no API changes will happen
in versions 2.3.x . This would be an ideal series for including in
QGis and Debian. I'll be maintaining it as long as QGis uses it.

We will also be moving to git as I believe this will help contributors
to send in patches (and helps maintaining a stable branch).

Anyway, this also means that now is the ideal time to tell us about
features you are missing as we can still have them in the LTR branch.
I've seen the question from Victor about using other filetypes from
the command line. That would be a great one to include.

As a final note: it looks like a lot of people care about SAGA. If you
do, join our list and discussions and perhaps try to contribute
somewhere (documentation, tests, bugreports). I'm convinced some
positive vibes from the QGis community will convince the core SAGA
devs that more collaboration is useful. Arrogantly saying that
something is not as you would like it does not help in that respect.

Kind Regards,
Johan
___
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] (Yet again) SAGA support badly broken in QGIS

[Johan Van de Wauw]

> On Wed, Jun 1, 2016 at 2:16 PM, Neumann, Andreas 
> wrote:
>>
>> If you guys think about integrating SAGA closer into QGIS, could we also fix
>> the issue that SAGA is currently limited to reading Shapefiles for vector
>> input? Probably a lot of work - but would this be feasible?
>
> After last year's hackfest in Nodebo just out of curiosity I was
> looking at the feasibility of replacing SAGA's native shapefile
> support by OGR. IMHO it is feasible - not something for a rainy
> afternoon, but maybe a project for 2-3 weeks of developer time. All
> work with shapefiles is done by API calls to saga core, so it would be
> a matter of reimplementing a part of the API. Similarly, raster access
> could be adapted to use GDAL. We could even use directly QGIS API for
> vector/raster access if we chose even tighter integration.

SAGA already can use OGR instead of just shapefiles. By using the
module io_gdal you can load a file through OGR into memory, do your
analysis and save using the same module to any ogr file.
It does not have to be a shape file. In the gui, try dragging and
dropping an OGR supported file on saga or go through
geoprocessing>file>gdal/ogr import.

The same thing is true for raster files. There is not much error
handling if you try exotic formats, but when used correctly it works.

It will still load everything in memory again. Directly using the QGIS
api will be harder (especially when changes are made), but there are
not too many things you can do with vector/raster data. I guess most
of the required methods are probably implemented.

>
> I think integrating SAGA tightly into QGIS would be very beneficial
> for both projects:
> - QGIS would finally have a native analysis engine, ending the long
> time struggle with changing parameter names, data conversions, CRS
> issues, algorithm naming (e.g. raster vs grid), duplication of
> algorithms etc.
> - SAGA source code would get more eyes of developers (increasing
> quality and bringing in new algorithms) and users. SAGA devs could
> focus more on algorithms as GUI side would be handled by QGIS.

Best first step would be including saga-gis-developer list in this thread.

Kind Regards,
Johan
___
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] SEXTANTE for QGIS has been released

[Johan Van de Wauw]

2012/4/12 Pedro Venâncio :
> Hi Salvatore,
>
> Thank you very much, it works now on terminal!
>
>
> However, still can not run any SAGA tool from the SEXTANTE plugin...

> In the terminal it works with exactly the same syntax as SEXTANTE:
>
> pedro@debian-amilo:~$ saga_cmd libshapes_polygons "Polygon Centroids" 
> -POLYGONS "/home/pedro/Limpezas/caop_2011_pinhel.shp" -CENTROIDS 
> "/home/pedro/sextante/outputs_centroids.shp"

Try setting the environment variable SAGA_MLB prior to starting qgis. EG:
SAGA_MLB=/usr/lib/saga qgis
or
export SAGA_MLB=/usr/lib/saga
qgis

>
>
>
> By running the command directly in the terminal, it gives an error by the 
> fact that the module is "Create graticule" and not "Create Graticule" (case 
> sensitive).
>
> Then, there are some parameters in the syntax that does not match the 
> accepted SAGA_CMD sintax. And the module only works like this:
>

This is because you use an older version of SAGA than the version
sextante was build against.

You should try running the latest version of saga. I'll have a look if
I can bring it to the backports archive.In the mean time you can just
try to build the version from unstable yourself..Don't hesistate
contacting me if you have any troubles. There are quite some
advantages in the new version:
- export SAGA_MLB is no longer needed. You can still use it though if
you have custom build modules.
- many modules have changed syntax
- it is much better tested on linux
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: Module piping GUI [Was: analytical workflow]

[Johan Van de Wauw]

On Thu, Sep 29, 2011 at 12:51 PM, Camilo Polymeris  wrote:

> Two main possible designs for this GUI came up:
>
> Either, a "connect-the-boxes"-style GUI (a graph):
>> http://www.gvsig.com/files/images/screenshots/gvSIG_Sextante_02.png
>
> or, a patchbay-style GUI:
>
>>> http://ubuntu.allmyapps.com/data/q/j/qjackctl-jack-control/UBUNTU-9.04/qjackctlPatchbayForm1.png

I understand the first one (graph) immediately.
I have no clue how the second one works with the lines across two
lists. From a usability perspective I'd choose the first one.

If the GUI interface is an issue, I think you can also generate a
similar tree structure from the DAGs :
Flow accumulation
+Watersheds
++Elevation: Raster layer1
++Channel Network
+++Elevation:...
+++Other option:...
++other input

In fact this is also the format you get in SAGA when you look to the
history of the file. I've attached a small example.

Perhaps this is what you ment with patchbay style, but I still don't
get what the lines mean, and why some properties would be on the left
or right.

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

Re: [Qgis-developer] analytical workflow

[Johan Van de Wauw]

Sextante has a nice modeler tool - it may be a good example how it could work:
http://www.gvsig.com/files/images/screenshots/gvSIG_Sextante_02.png

AFAIK it also handles saga (although most modules were reimplemented
in java) and even grass modules.

In fact Sextante is already a processing toolbox - it is written in
java  so I'm not sure if it could be integrated in qgis, but if a new
framework is built in c++/python, it is nevertheless very interesting
to see which design decision they took.

Johan

On Tue, Aug 23, 2011 at 9:45 PM, Camilo Polymeris  wrote:
>> I agree with martin - such a Modeler could be a great improvement but
>> I assumed it would be somethink like the WxGUI_Modeler ..
>
> Yes, I also imagine something similar.
> But, I prefer more ordered layouts, where you have all outputs in a
> column on the left side, and all inputs in a column on the right side.
> In between all connections displayed as lines of different color
> depending on parameter type and such.
>
> A bit like qjackctl's patchbay:
> http://ubuntu.allmyapps.com/data/q/j/qjackctl-jack-control/UBUNTU-9.04/qjackctlPatchbayForm1.png
>
> It looks tidier and would also be a bit easier to implement than
> free-floating boxes.
>
> On the logic side:
> For input and output the most flexible would be to use python scripts.
> Of course, it is harder than e.g. XML, and there would be limits to
> what python code it would understand on input. But still, I think it
> is the best option.
>
> The user would then have the option of saving these "workflow presets"
> and using them like any regular module.
>
> Camilo
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: [saga-gis-developer] SAGA Interface for QGIS - Final GSoC Report

[Johan Van de Wauw]

Perhaps try removing these libtool helper files (*.la). You don't need
them anyway.

Johan

On Sun, Aug 21, 2011 at 8:03 AM, Rainer Hurling  wrote:
> On 21.08.2011 03:02 (UTC+1), Camilo Polymeris wrote:
>> Hello everyone,
>
> Hello Camilo,
>
>> I am happy to say that this week saw many improvements in the QGIS
>> Processing Framework and the interface to SAGA.
>
> thank you very much for this important framework and interface.
>
> I am SAGA GIS and Quantum GIS on FreeBSD. Both work well on this
> platform as standalones, but there is a real problem when using QGIS
> with the SAGA Module Interface.
>
> SAGA GIS is built with python bindings, so it supports python scripting
> (tested). QGIS has installed the Processing Framework Manager and is
> restarted. After installing the SAGA Module Interface and restarting
> QGIS the following message appears on the shell in an endless loop. QGIS
> hangs on showing the logo and tries to load modules.
>
> 
> 07:34:39: Error: /usr/local/lib/saga/libtin_tools.la: invalid file
> format07:34:39: Error: /usr/local/lib/saga/libtin_tools.la: invalid file
> format07:34:39: Error: /usr/local/lib/saga/libtin_tools.la: invalid file
> format07:34:39: Error: /usr/local/lib/saga/libtin_tools.la: invalid file
> format07:34:39: Error: /usr/local/lib/saga/libtin_tools.la: invalid file
> format07:34:39: Error: /usr/local/lib/saga/libtin_tools.la: invalid file
> format07:34:39: Error: /usr/local/lib/saga/libtin_tools.la: invalid file
> format07:34:39: Error: /usr/local/lib/saga/libtin_tools.la: invalid file
> format[..snip..]
> 
>
> QGIS is not usable for me with the SAGA Module Interface installed, so I
> have to remove the SAGA plugin from .qgis directory.
>
> Do you have any hint what is going on here?
>
> Your help is really appreciated.
> Rainer Hurling
>
>
>> Primarily, raster input and output works now, thanks to help from SAGA
>> developer Volker Wichmann. Single band local QGIS rasters are
>> transparently converted to SAGA format using GDAL, processed, and
>> imported back into QGIS. Many things could be improved and features
>> added, but the basic functionality is there.
>>
>> To assess the progress of the interface, I have written a small
>> script, which checks module support, as determined by parameter
>> implementation. The programmatically collected stats, indicating
>> support for 170 modules (40%) are published in the Module Support[1]
>> wiki page, while the Tested Modules[2] page, maintained by Paolo,
>> contains a list of SAGA modules that have actually been tested.
>>
>> Work on a settings dialog has started. It is still unclear how many
>> and which settings should be left to the user. Also on the GUI side,
>> an about dialog was implemented, which displays the new processing
>> icon by Robert Szczepanek.
>>
>> In an effort to be consistent with the QGIS terminology, the string
>> "raster" is now automatically substituted for instances of "grid" in
>> each SAGA module's text: Names, tags, parameters and descriptions.
>>
>> Less visible to the user, but still important, the SAGA code has been
>> refactored a little. Work is still pending on this issue.
>> Additionally, the plugin's objects are now managed in a cleaner way.
>>
>> Validator and default value bugs have been fixed. Further testing is 
>> necessary.
>>
>> Finally, due to rising interest in interfacing other libraries (GRASS,
>> OTB) I have published the API documentation[3] on the framework and
>> started writing a Developer's Tutorial[4].
>>
>> Google Summer of Code 2011 is almost over, but it is my intention to
>> continue maintaining this software, first focusing on polishing the
>> available code and later adding more features: Support for further
>> parameter types, interactive modules, and module instance
>> serialization, among many other proposed.
>>
>>
>> Best regards&  thanks a lot for the help,
>>
>>
>> Camilo
>>
>> [1] https://github.com/polymeris/qgis/wiki/Module-Support
>> [2] https://github.com/polymeris/qgis/wiki/Tested-Modules
>> [3] http://polymeris.github.com/qgis/processing.html
>> [4] https://github.com/polymeris/qgis/wiki/Developer%27s-Tutorial
>
>
> --
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
> ___
> saga-gis-developer mailing list
> saga-gis-develo...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/saga-gis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS Processing Framework

[Johan Van de Wauw]

On Fri, Jul 8, 2011 at 7:46 AM, MALIK Julien  wrote:

> As I can remember, SAGA has a "gdal/ogr" importer module for inputs, and the
> output should be simple also as the saga file format is supported by gdal.

Since gdal 1.7 saga is indeed supported. And although saga has a
gdal/ogr input module, I think it is a better idea to use qgis to save
to sgrd/sdat or shape rather than letting saga do it: since the file
opened succesfully in qgis, and perhaps some changes were made,
exporting should not cause issues. On the other hand saga might have
problems opening some of these files (I'm not aware of examples - but
at least in theory it makes sense).

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

Re: [Qgis-developer] Data exchange between QGIS and SAGA [was: QGIS Processing Framework]

[Johan Van de Wauw]

On Thu, Jul 7, 2011 at 10:36 AM, Johan Van de Wauw
 wrote:
> On Wed, Jul 6, 2011 at 7:30 PM, Camilo Polymeris  wrote:
>>
>> One of the most important and difficult remaining parts is data
>> exchange (raster & vector). I have been studying SAGA's API [4], but
>> am not sure how to handle it & would appreciate comment from people
>> more familiar with it.
>>
I forgot to mention it, but it may be useful to look at the way
sextante implemented a saga plugin:
http://sextantegis.blogspot.com/2011/04/big-changes-in-sextante.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Data exchange between QGIS and SAGA [was: QGIS Processing Framework]

[Johan Van de Wauw]

On Wed, Jul 6, 2011 at 7:30 PM, Camilo Polymeris  wrote:
>
> One of the most important and difficult remaining parts is data
> exchange (raster & vector). I have been studying SAGA's API [4], but
> am not sure how to handle it & would appreciate comment from people
> more familiar with it.
>
> Do you think it would be easier (or cleaner) to interface SAGA's
> relevant data structures to QGIS' dataproviders or layer structures?
> For comparison, see the QGIS API docs.[5]
>
Camilo,

I think the only feasible way, definitely on short term, is saving
every needed qgis data-object on disk in saga's native file format
(shp for vector data, sgrd/sdat for raster data(requires gdal 1.7)),
running the saga module (like you would do if you were running the
command line version) and then opening the resulting files in qgis.
You could use the api to find out which objects in qgis may be passed
to saga, eg make sure that only polygon vectors show up as an option
in the dialog, but for actually passing the data, I think you should
write to the disk.
I think the same will be true for many other processing frameworks,
and I even noticed that when I calculate voronoi polygons in qgis I
have to save my files prior to running, so even here it seems to work
like that.
Direct access of the files like they are loaded in qgis would most
likely require non-obvious changes in the saga api, which -imho- go
outside the scope of your project, certainly if you want to have a
general processing framework.
It is also a non-essential feature: it may be added later if the
plugin is successful, with the 'write to disk method' as a safe
fallback option.

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

Re: [Qgis-developer] Re: MeteoIO

[Johan Van de Wauw]

On Mon, Jun 27, 2011 at 8:40 PM, Mathias Bavay  wrote:

> Hi!
>
> [sorry I missed the beginning of the discussion: I was not registered yet]
>
> So, when I proposed you to talk about things from MeteoIO that could
> possibly be interesting for QGIS, I had the following in mind:
>*the calculation of solar irradiance on the ground, with terrain
> shadowing. Here, we are not talking about the (unfortunately) standard
> (pseudo)shading that is usually done in GIS (ie: adding shadows to highlight
> the terrain contours), but real shading. The radiation would only be valid
> for clear sky (we can not easily get the cloud information), but it would
> provide a valid potential solar irradiance information for a given
> date+time. We could easily also provide a yearly/montly/daily potential
> average solar irradiance layer.
>*we also offer a bunch of spatial interpolation algorithms (the kriging
> is not yet 100% finished, but almost). These are the tools that you need to
> transform point measurements in distributed values over a DEM (we use it for
> meteorological parameters, the whole thing was initially invented for
> mining)
>

Just a quick note: both (real shading, kriging) are already implemented in
SAGA GIS. If a good plugin is available for saga, perhaps better to focus on
other functionality.
Anyway, let's hope that a processing framework leads to less duplicated code
in the long term.

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

Re: [Qgis-user] Re: [Qgis-developer] qgis-saga-python bindings in ubuntu

[Johan Van de Wauw]

On Thu, Jun 23, 2011 at 11:10 AM, Agustin Lobo wrote:

> Is it possible to install the python bindings for a saga installation
> from binaries friom ubuntugis-unstable?
>
>
I'm currently busy uploading the new versions. After uploading it will take
approximately one hour to compile.
Once this is done the package you are looking for is called: python-saga


Also, while I do have the ubuntugis-unstable repository in the
> synaptic list, synaptic finds saga 2.05+dfsg-0.1~lucid
> while 
> https://launchpad.net/~ubuntugis/+archive/ubuntugis-unstable
> lists saga 2.0.6+dfsg-0~lucid. Why?
>

Because it was uploaded but (for some reason) did not compile. Not your
fault.


>
> Thanks
> Agus
>
>
> -- Forwarded message --
> From: MALIK Julien 
> Date: 2011/6/23
> Subject: [Qgis-user] Re: [Qgis-developer] qgis-saga-python bindings in
> ubuntu
> To: "cavall...@faunalia.it" 
> Cc: qgis-user , qgis-developer
> , agustin.l...@ija.csic.es
>
>
> For ubuntu, you are probably looking for this :
> https://launchpad.net/~johanvdw
>
> Julien
>
> Quoting "cavall...@faunalia.it" :
>
> > A debian plugin is under preparation. Otherwise you'll have to build it
> yourself.
> > All the best.
> >
> > http://faunalia.it/pc
> >
> > - Reply message -
> > Da: "Agustin Lobo" 
> > A: "qgis-user" , "qgis-developer" <
> qgis-developer@lists.osgeo.org>
> > Oggetto: [Qgis-developer] qgis-saga-python bindings in ubuntu
> > Data: gio, giu 23, 2011 07:04
> >
> >
> > Does anyone know if there is any way to get the required (by the qgis
> > saga plugin) python bindings for the binary distribution of
> > saga for debian and ubuntu?
> >
> > Thanks
> >
> > Agus
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
>
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
>
> ___
> Qgis-user mailing list
> qgis-u...@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] SAGA Interface

[Johan Van de Wauw]

On Sat, Apr 2, 2011 at 12:28 AM, Camilo Polymeris  wrote:
>>> What I don't understand is: we'd have the same problems using python.
>>> There are, as far as I know, no Python-saga packages.
>>> Debian's libsaga[2], for instance, does *not* include python bindings.
>>> That means we'd have to compile & ship the python-saga binding
>>> ourselves, anyway. Or am I missing something?
>>
>> This should be solved from the saga side, providing a package for it.
>
> That could be an option, yes. But they haven't done it, and I don't
> know if they would be interested. One of us could step up and offer
> packaging to SAGA, but I am not that experienced in packaging issues
> and distro-related complications.
> The saga wiki suggest using saga_cmd through python, which would need
> no recompilation, but would limit us to non-interactive plugins. Maybe
> that isn't so much of an issue, and would be easier.
Excuse me for replying on such an old mail, but I only noticed this
mail now (you should really have asked this on the debian-gis or saga
developer list): the next debian package will include python support.
In fact you can already get a source package with python-saga support
from my launchpad page:
https://launchpad.net/~johanvdw/+archive/sagacvs
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface

[Johan Van de Wauw]

On Sat, Feb 19, 2011 at 1:09 AM, Volker Wichmann  wrote:
> Hi Gianluca,

> Another issue which has to be solved is that of the "Grid System" parameter.
> As you most likely know, most of the SAGA grid modules require all grids to
> be processed within the same grid system. In case this is true for a module,
> I see two possibilities:
>
> (1) check this after you converted from GeoTiff to sgrd and before you call
> saga_cmd
>
> (2) leave the check to saga_cmd and catch the return error message
I think there is an even better 3d option: derive it from the geotiff
(or other) file. Unless you have one of those rare files which have
nonsquare grid cells, it is perfectly possible to derive the origin
and grid cell size.
A 4th approach is doing what sextante is doing afaik: resample the
grids if they don't match.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Re: [saga-gis-developer] saga - qgis interface

[Johan Van de Wauw]

On Thu, Feb 17, 2011 at 1:27 AM, Volker Wichmann wrote:

> Hi Gianluca,
> My idea is to write a python code that will generate GUI
> dialogs completely on the fly without any hard coded parameter flags or
> .py files (SAGA has about 500 modules!). That is, you have a path where
> your SAGA modules (.so/.dll) reside and then your QGIS GUI will use the
> saga_api to generate the dialogs for the available modules on the fly.
> As far as I see, all you need is the following information:
> * module library name
> * module name
> * module (saga_cmd) parameter names
> * module parameter types
>
That seems the best approach to me as well. I've attached a script which
creates a saga_cmd call for most modules, which I once used to check if
there are any obvious errors/memory leaks. As mentioned before, this script
is the first thing I wrote in python, so sorry for any strange unnecessary
constructions and/or errors, but it should give you an idea how to browse
through the module libraries, modules and their parameters.


> All you would need is a generic python module which would generate the
> dialogs for QGIS using the saga_api on the fly and another python module
> which would use the information entered in these QGIS dialogs to call
> saga_cmd. But maybe I'm getting this wrong.
>

Prior to jumping towards dialogs, perhaps it is useful to think about how
you want to integrate saga and qgis:
* how are module libraries and modules presented? In a menu or some type of
module library?
* which qt interface would you like to use to present the different type of
parameters that saga has. This is really an important decision. I personally
think that the way saga relies heavily on wxpropgrid to generate its
interfaces is really nice. Someone who knows qt well may give some advice
here what the best approach would be. If some kind of property grid is
already used in qgis, I would certainly look to that. I really think this is
one of the most important decisions - some modules have a lot of different
parameters (eg [2]) and presenting them in an orderly way is quite a
challenge.
* which types of modules would you like to provide first? Shape or grid
based modules?
* how do you handle file conversions? Eg a geotiff is open in qgis. Prior to
running this module, it will have to be converted to a .sgrd file (can be
done with gdal)?

In fact, if I would be starting this project, I would use this approach:
1. Create some type of menu/module library to show the saga modules
2. If these are opened show a very basic window showing a generated command
line and a html box with the documentation of the module (eg [2]). At that
point, you actually have nothing more than a nice way to browse through the
saga modules from qgis, without any integration. But it offers a starting
point.
3. If a good approach is found to generate the kind of property grid, you
could switch to having a text box per parameter type. In a next step, some
options may be converted to better suited interfaces, eg showing a list of
grids present in qgis. At this point, I think development can be done by
different people: someone is working on an interface for shapefiles, someone
else on file conversion issues/... At this point, knowledge of the saga api
is less important, and most work is done in python/qt.

[1]
http://www.saga-gis.org/saga_api_doc/html/parameters_8h.html#005312577c5ba61839e45f6a19b94218
[2]
http://www.saga-gis.org/saga_modules_doc/grid_analysis/grid_analysis_19.html
import sys, os, fnmatch, saga_api
##
print '# SAGA API version: '+saga_api.SAGA_API_Get_Version()
print ''

modulepath= '/usr/lib/saga/'
libraries = os.listdir(modulepath)
mlb = saga_api.CSG_Module_Library()

def printparameter(p):
print '#' +str( p.is_Input())+str(p.is_Output())+str(p.Get_Type())+' '+p.Get_Identifier()+p.Get_Name()
print '# '+p.Get_Description()
for i in range(p.Get_Children_Count()):
printparameter(p.Get_Child(i))

def parseparams(p, libnr):
s=''
if not p.is_Optional():
if p.Get_Type()==saga_api.PARAMETER_TYPE_Int:
s='-'+p.Get_Identifier()+':'+str(1)
if p.Get_Type()==saga_api.PARAMETER_TYPE_Double:
s='-'+p.Get_Identifier()+':'+str(1)
if p.Get_Type()==saga_api.PARAMETER_TYPE_Grid and p.is_Input():
s='-'+p.Get_Identifier()+':'+'esmall.sgrd'
if p.Get_Type()==saga_api.PARAMETER_TYPE_Grid_List and p.is_Input():
s='-'+p.Get_Identifier()+':'+'esmall.sgrd'
if p.Get_Type()==saga_api.PARAMETER_TYPE_Grid and p.is_Output():
s='-'+p.Get_Identifier()+':'+'out'+str(libnr)+p.Get_Identifier()+'.sgrd'
if p.Get_Type()==saga_api.PARAMETER_TYPE_Shapes and p.is_Input():
s='-'+p.Get_Identifier()+':'+'smallpoints.sgrd'
return s

for fmlb in libraries:
if fnmatch.fnmatch(fmlb, '*.so'):
print '## Module library: ' + fmlb
mlb.Create(saga_api.CSG_String(modulepath+fml