Re: [Qgis-developer] Plugin Development C++ Windows - Any response?
Hello, Having written some C++ plugins (for Orfeo Toolbox), I have some feedback to give. The current recommended procedure is to have a source build of qgis, add your plugin inside qgis source tree, hack a QGis CMakeLists to add the new plugin dir, and recompile Qgis. In my opinion, a better approach is to build them as external project. The idea is to be able to build a plugin on top of a prebuilt Qgis (libqgis-dev on ubuntu/debian, and the OSGeo4W build on windows) That's what I have set up for the plugins I wrote, but ran into the following problem : - There is no FindQgis.cmake or QGisConfig.cmake exported in the qgis development package (either OSGeo4W or ubuntu/debian), so importing QGis inside a CMake project must be done "by hand". It's ok with the QGis include path and the path to libqgis_core. But you have to take care of importing Qt also, which should be done by a FindQgis.cmake - I had to hack some QGis #define to make it build on windows (GUI_EXPORT and CORE_EXPORT). Again, this should be handled by a ADD_DEFINITION inside a FindQgis.cmake One other thing : it would be nice if the C++ plugins could be loaded from another directory than the official one. Let's say I wrote a bunch of plugins for a specific software, I would like to store them in their own directory instead of messing up with the official plugins. Maybe it's already supported but I don't know how to do it... Regards, Julien Le 23/02/2011 14:12, Barend Gehrels a écrit : Hi, Yes as Martin notes, and as I mentioned in my last email in this thread "If you are able to use linux, you can even more easily just use the plugin_builder.py script in that src/plugins directory and it will generate for you a 'hello world' C++ plugin." Perhaps the linux part is not relevant though as you should be able to use it on widows with python, but I've never tried. As an interesting history note, we have had a plugin builder script (in one form or another) in QGIS for c++ plugins from very early on in the life of QGIS's plugin support. On Windows the plugin_builder.py works also perfectly. Regards, Barend ___ 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
Re: [Qgis-developer] Plugin Development C++ Windows - Any response?
Hello,
I'm a little late, but still :
Le 23/02/2011 22:13, Tim Sutton a écrit :
Hi
On Wed, Feb 23, 2011 at 8:05 PM, Julien Malik wrote:
Hello,
Having written some C++ plugins (for Orfeo Toolbox), I have some feedback to
give.
The current recommended procedure is to have a source build of qgis, add
your plugin inside qgis source tree, hack a QGis CMakeLists to add the new
plugin dir, and recompile Qgis.
In my opinion, a better approach is to build them as external project.
The idea is to be able to build a plugin on top of a prebuilt Qgis
(libqgis-dev on ubuntu/debian, and the OSGeo4W build on windows)
That's what I have set up for the plugins I wrote, but ran into the
following problem :
- There is no FindQgis.cmake or QGisConfig.cmake exported in the qgis
development package (either OSGeo4W or ubuntu/debian), so importing QGis
inside a CMake project must be done "by hand". It's ok with the QGis include
path and the path to libqgis_core. But you have to take care of importing Qt
also, which should be done by a FindQgis.cmake
I added the FindQGIS cmake file that I wrote for openModeller some
years ago into qgis/src/cmake
Nice !
Will it make its way into the binary packages (more exactly the
libqgis-dev package) ?
In external projects, I'd like to do find_package(QGIS), but i don't
want to include the FindQGIS file in the external project sources.
For example, this is what we do for an application written on top of OTB :
http://hg.orfeo-toolbox.org/Monteverdi/file/f4f1c170dec6/CMakeLists.txt#l74
The OTB exports these main CMake files in the dev package :
/usr/lib/otb/UseOTB.cmake
/usr/lib/otb/OTBConfig.cmake
The INCLUDE(${OTB_USE_FILE}) command is used to add the include dirs,
compiler definitions, etc...
The idea of separating the find_package and the actual
include_directories/add_definitions seems nice to me.
With all the possibilities offered by QGis, there might be different
"use file" (for plugins, for applications built on top of QGis lib, ...)
- I had to hack some QGis #define to make it build on windows (GUI_EXPORT
and CORE_EXPORT). Again, this should be handled by a ADD_DEFINITION inside a
FindQgis.cmake
One other thing : it would be nice if the C++ plugins could be loaded from
another directory than the official one.
Ok I added support for this - see the bottom of the general options
tab in QGIS Options dialog.
Available in trunk as of r15250.
I have only tested on linux but it should work on linux& mac too.
I just seen it after an source update, I'll test it soon.
But what I would have expected is different : something like a
ld.conf.so.d directory, where simple text files contain paths to other
directories.
If we manage to have a working otb-qgisplugins debian package, I'd like
it to just drop a file in this directory, containing something like
/usr/lib/otb/qgisplugins.
The advantages I see :
- at install time, the package would just drop a file in this directory,
and would not install all the files inside the qgis plugin dir.
- uninstalling the package would be just a matter of deleting this
little text file
- those steps would be run for all users automatically
Having two layers (one system layer/ one per-user layer as you
implemented it) seems useful at first sight.
Do you think it could complicate things too much ?
Some time maybe you can return the favour and help me to get my otb
plugins to compile properly - I never did get them to build by
following the instructions on your wiki I'd have to write back to
this list with more specifics of the problem first though.
No problem. Drop a mail on our list and we will try to help.
Best regards,
Julien
Regards
Tim
Let's say I wrote a bunch of plugins for a specific software, I would like
to store them in their own directory instead of messing up with the official
plugins. Maybe it's already supported but I don't know how to do it...
Regards,
Julien
Le 23/02/2011 14:12, Barend Gehrels a écrit :
Hi,
Yes as Martin notes, and as I mentioned in my last email in this
thread "If you are able to use linux, you can even more easily just
use the plugin_builder.py script in that src/plugins directory and it
will generate for you a 'hello world' C++ plugin."
Perhaps the linux part is not relevant though as you should be able to
use it on widows with python, but I've never tried. As an interesting
history note, we have had a plugin builder script (in one form or
another) in QGIS for c++ plugins from very early on in the life of
QGIS's plugin support.
On Windows the plugin_builder.py works also perfectly.
Regards, Barend
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis
Re: [Qgis-developer] hackfest in Lisbon
Dear hackers, As a member of the Orfeo Toolbox "core" development team, I propose to join you at the next HackFest in Lisbon. This would be a great occasion to discuss with you about : - the image processing needs in QGis, and how they can eventually be fulfilled by OTB. - the UI / end-user application needs of OTB users, for which we feel Qgis is a very serious option. I could show to those interested what we've done with QGis recently, and will be glad to get some direct feedback. Also, I know there is currently a huge initiative on raster providers, and that it's been an idea to have an OTB implementation supporting streaming, in memory images, etc... . We did not follow the latest devs very closely, but that would be a good occasion to exchange ideas, and maybe get my hand on some code around this. As OTB is primarily a C++ library, I'm also particularly interested in the C++ plugin functionnalities of Qgis, so if you need some help to add functionnalities to them, this might also be something I can work on. Does the idea suit you ? Regards, Julien Le 05/02/2011 19:12, Giovanni Manghi a écrit : Hi all, Jurgen, Paolo, Why should anyone if the date is not set yet? Maybe there should have been a deadline for the doodle page. You're right. Anyway, 15-17.4 seems set now. Who closes the doodle page and fixes the date on the wiki page? The Doodle was set to make possible choose the best dates for you devs (and was asked by you). I didn't realized it was a problem. In any case the "core" devs have already voted and so I'll close the Doodle. The dates will be then 15-17.4 and very soon I'll come out with news (definitive venue, hotels/hostels, info about transportations, etc.) on the wiki page. If there are no last minute changes the venue will be just a couple of km away from the International airport, near the centre of the city, served by metro. Cheers -- Giovanni -- ___ 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
Re: [Qgis-developer] hackfest in Lisbon
Hi, See you there then ! Regards, Julien Le 08/03/2011 18:35, Tim Sutton a écrit : Hi Julien On Tue, Mar 8, 2011 at 7:28 PM, Julien Malik wrote: Dear hackers, As a member of the Orfeo Toolbox "core" development team, I propose to join you at the next HackFest in Lisbon. This would be a great occasion to discuss with you about : - the image processing needs in QGis, and how they can eventually be fulfilled by OTB. - the UI / end-user application needs of OTB users, for which we feel Qgis is a very serious option. I could show to those interested what we've done with QGis recently, and will be glad to get some direct feedback. Also, I know there is currently a huge initiative on raster providers, and that it's been an idea to have an OTB implementation supporting streaming, in memory images, etc... . We did not follow the latest devs very closely, but that would be a good occasion to exchange ideas, and maybe get my hand on some code around this. As OTB is primarily a C++ library, I'm also particularly interested in the C++ plugin functionnalities of Qgis, so if you need some help to add functionnalities to them, this might also be something I can work on. Does the idea suit you ? Please come!!! :-) Look forward to seeing you there! Regards Tim Regards, Julien Le 05/02/2011 19:12, Giovanni Manghi a écrit : Hi all, Jurgen, Paolo, Why should anyone if the date is not set yet? Maybe there should have been a deadline for the doodle page. You're right. Anyway, 15-17.4 seems set now. Who closes the doodle page and fixes the date on the wiki page? The Doodle was set to make possible choose the best dates for you devs (and was asked by you). I didn't realized it was a problem. In any case the "core" devs have already voted and so I'll close the Doodle. The dates will be then 15-17.4 and very soon I'll come out with news (definitive venue, hotels/hostels, info about transportations, etc.) on the wiki page. If there are no last minute changes the venue will be just a couple of km away from the International airport, near the centre of the city, served by metro. Cheers -- Giovanni -- ___ 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Lisbon hackfe.....er...meeting: Townhall Meeting Proposal and Agenda
Hello all, Yes I really hope to have some time to present you what OTB can do, to talk with you about what OTB could do for QGis and what would be the best way to do it. I fear for the moment I won't be the most efficient Qgis bug hunter as you all will be ;) It would be great if those of you interested in OTB would have a little time at the beginning of the HF (let's say during friday). Cheers, Julien Le 07/04/2011 14:18, Giovanni Manghi a écrit : Hi all, Julien Malik of the OTB project is willingly to do a presentation of the Orfeo Toolbox and describe the current state of the different initiatives to integrate it into QGIS. I added his presentation in the townhall meeting program http://www.qgis.org/wiki/5._QGIS_Hackfest_in_Lisbon_2011#Townhall_Meeting cheers -- Giovanni -- On Wed, 2011-03-30 at 15:14 +0200, Tim Sutton wrote: Hi I would like to propose we hold another 'townhall meeting' at the hackfest where we can discuss any broad ranging issues pertinent to anyone involved in the project. If you have other agenda items (or don't like the starting list I added), please update the wiki page accordingly. I added a 'Town hall meeting' [1] section to the Lisbon meeting page and added 'moving to GIT' as an agenda item. I also started this page [2] , where I encourage other proponents of moving to git to add their thoughts (and those who don't like the idea to add theirs). [1] http://www.qgis.org/wiki/5._QGIS_Hackfest_in_Lisbon_2011#Townhall_Meeting [2] http://www.qgis.org/wiki/MovingToGIT Regards Tim ___ 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
Re: [Qgis-developer] qgis orfeo GSoC
Hello Mohammed, This is great you seem to have a lot of ideas ! All this work you propose to achieve are good improvements to both Qgis and OTB. Julien Le 07/04/2011 16:00, Mohammed Rashad a écrit : http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/rashad/1 any comments are always welcome -- Thanks && Regards Rashad ___ 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
Re: [Qgis-developer] QGIS Processing Framework
Hello, I'm currently publishing what we have (the specs we made and the code of our "new" framework), so that we can see what can be merged and how. More extensive inputs and reaction to current ideas this afternoon... Julien Le 27/04/2011 11:30, Paolo Cavallini a écrit : Il giorno mer, 27/04/2011 alle 11.20 +0200, Martin Dobias ha scritto: into C++ and add Python bindings. The idea is not to waste time with writing and rewriting various c++ classes when the API is not clear yet. Consider this as a suggestion, not a command how to do it :-) Agreed; it will also be much easier for interested people to follow the work. Advanced parameters: some modules may allow users set lots of parameters. Although this is handy, many times the default values work well and only few basic parameters are changed regularly. It should be possible to mark some parameters as advanced and they would be hidden by default, they would show up after clicking a checkbox or a button. Right, this works very well with GRASS modules. Categorization: currently we are starting to face some trouble with ... This list of processing modules should later get some advanced functionality like searching, favourite modules or even attaching most used modules on a toolbar, but that is something for the future, we are not expecting you to do that during the summer :-) A simple tree listing tags and modules assigned to them will suffice. I personally like and use the filtering option of GRASS plugin a lot, and find this the best option for all users except possibly for the very first-timers. Running modules from scripts: you probably have that in mind but let's Right, this is very important, also to be able to add extra options etc. Any news from OTB people? Their input is important. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
Hi Camilo, Hi all, First of all congratulation for your GSoC project ! Some apologies for the delay in my response, we are approaching the next OTB release so I'm busy on fixing little stuff/builds here and there. Please don't expect real time answers in the next week or two. But it's nice to see you left the starting blocks a while ago :) For OTB we are developing a "module" framework also, with auto-generated interface. As I told people at the HF, we have made a first step with our last 3.8 release, but are not satisfied enough with the GUI part, so we are currently revamping the core to add a lot of functionnalities. Our ideas/wish-list is summed up here : http://wiki.orfeo-toolbox.org/index.php/OTB-Wrapper The current code for what we want to push into QGis is here (please note that it is in development, i've completed the first usefull app just after the HackFest) : http://hg.orfeo-toolbox.org/OTB-Wrapper Don't hesitate to ask me for help to build it if you need. Some general comments : [1] We should be very careful about not being limited by "too much genericity". The SAGA and GRASS modules have each their own design/parameter types/inner but also outer logic. On the OTB side, we have some liberty since we are currently working on them, but we have some plans to integrate them in other tools, possibly benefiting from their additional possibilities (the pipeline capabilities of Monteverdi for example). We have some ideas for making the GUI as dynamic as possible (and it is with their Qt/Qgis implementation that we plan to have the most full-featured GUI) but I guess other libs will have capabilities that we don't have. Trying to fit everyone in the same framework will be hard : either each library (SAGA/GRASS/OTB) will only use a subset of the provided functionnalities, either we will end up taking the common factor of all libs and everyone will feel limited. I'm worried than we fall into one of these two pitfalls. Please do not impose to much constraints ! Reactions very welcome on this point ! What seems reasonable to me at first sight : - using similar widgets for similar functionnalities/parameter types, maybe with base classes to reuse (but again make them really high level !). - having a common way to call the modules - all in all, make them all look the same This will give the user the illusion that they all comes from the same library, but will give each implementation the necessary liberty to fine tune their GUIs using the specificities of their library/internal "module" framework. We have the chance of being in a similar phase of development for both project, so i'm sure we will find the right common ground. By the way, after SAGA, Grass and OTB, maybe someone will consider Ossim : they also have a similar framework for modules with autogenerated interfaces, to do raster processing. Seeing Maxim presenting a Qgis classification plugin based on OpenCV, maybe you will also end up with some OpenCV modules in the future... [2] Chaining modules from different libraries seems a little ambitious to me, but this would be awesome ! As you said Camilo, I think we can leave pipelining out as a first step. We are not really focusing on that part now neither, though the current implementation should allow this. [3] You seem to consider parameter validation only in an independent way From our experience it is insufficient (for example, absolute default values is not enough). How we plan to solve this (trying to keep it simple also...), is to give our modules 3 main entry points : - description of the parameters - a global method to update all the parameters, called as soon as one parameter is changed - an execution method Let's imagine a simple orthorectification application with the following params : - input/output image - the output CRS - output origin, size, and spacing We want the origin, size and spacing to be auto-computed each time the input or CRS changes If CRS changes from UTM to WGS84, we expect the outputorigin units/display to also change from meter to degree, for example. [4] (related to [3]) Our first working-and-usefull application in this new framework we're building shows also dynamic parameters list in the GUI (see the screenshot on the Wiki). It is a smoothing application with 3 modes: Median, Gaussian, Anisotropic Filtering. Each mode has associated params. Median and Gaussian needs a radius, Anisotropic Filtering needs a time step and a number of iterations. So below the combobox, the widget displayed depend on the combobox value. [5] The model we imagined for the parameter list will be a tree more than a flat list. A group of parameters is just one node of the tree, containing a parameters list, where each parameter can also be a group of parameters. Please find also some other more specific comments below : Le 27/04/2011 11:20, Martin Dobias a écrit : Hi Camilo On Tue, Apr 26, 2011 at 9:46 PM,
Re: [Qgis-developer] QGIS Processing Framework
Looks very good, and in principle similar to what I was doing (or trying to do) with SAGA, see github repo. But, from what I can tell, is very OTB-specific. I am not sure how we can integrate this into a common framework. We will find a way... I feel in general QGIS should handle the GUI part. That makes the framework usable in non-GUI contexts and only dependant on QtCore (the non-QGIS side, I mean). In my test code I used a QFormLayout, populated with Widgets according to the type of the parameters alone. (screenshot linked from the "QGIS Processing Framework" page) I should look into this QFormLayout... I'm still a Qt newbie, and in no way a GUI specialist so input on the good classes to use is warmly welcome. I imagined the particular implementations using the existing Plugin mechanism and thus having access to QgisInterface anyway, if really necessary. I'd like this framework to keep some of the freedom of the current QGis plugin system, where you can almost do what you want. I feel this is how anything will become integrable in Qgis. Trying to fit everyone in the same framework will be hard : either each library (SAGA/GRASS/OTB) will only use a subset of the provided functionnalities, either we will end up taking the common factor of all libs and everyone will feel limited. I'm worried than we fall into one of these two pitfalls. Please do not impose to much constraints ! Reactions very welcome on this point ! IMO, it is this genericity that would enable the different implementations to talk to each other... inter-library pipelining being possible if the parameter (including I/O) types match. Compare the list of parameters for OTB and SAGA: https://github.com/polymeris/qgis/wiki/List-of-parameters I think a common ground can be found for most cases, while retaining the ability to specify implementation-specific types. That allows consistency in the user interface and easier scripting (no need to worry about how each implementation handles each data type). From my point of view, the Qgis common ground is all about : - getting raster/vector layers as input, and producing raster/vector layer as output. - having a Qt based interface using widgets which are as similar as possible when they represent similar concepts, which fit Qgis UI guidelines - having Python interfaces The rest seems implementation-specific to me. Do we really want to add a bunch of other "Qgis data types" ? To say it differently : Forget SAGA! Forget OTB! Think QGis! It would be nice to have some inputs from the GRASS gurus for example, a software I don't know much. I guess this is again another complete set of parameter types. [2] Chaining modules from different libraries seems a little ambitious to me, but this would be awesome ! As you said Camilo, I think we can leave pipelining out as a first step. We are not really focusing on that part now neither, though the current implementation should allow this. I think chaining modules is possible if input/ouput formats are well defined. At least in a crude "execute module A, convert data, execute module B" way. Yes ! At least I see that (easily?) possible for raster/vector layers I/O. [3] You seem to consider parameter validation only in an independent way From our experience it is insufficient (for example, absolute default values is not enough). How we plan to solve this (trying to keep it simple also...), is to give our modules 3 main entry points : - description of the parameters - a global method to update all the parameters, called as soon as one parameter is changed - an execution method Let's imagine a simple orthorectification application with the following params : - input/output image - the output CRS - output origin, size, and spacing We want the origin, size and spacing to be auto-computed each time the input or CRS changes If CRS changes from UTM to WGS84, we expect the outputorigin units/display to also change from meter to degree, for example. Yes, very important point. One possibility would be to use signals to connect the framework to each parameter's validator (to change constraints) and to the module (to add/remove parameters, as per [4]) [4] (related to [3]) Our first working-and-usefull application in this new framework we're building shows also dynamic parameters list in the GUI (see the screenshot on the Wiki). It is a smoothing application with 3 modes: Median, Gaussian, Anisotropic Filtering. Each mode has associated params. Median and Gaussian needs a radius, Anisotropic Filtering needs a time step and a number of iterations. So below the combobox, the widget displayed depend on the combobox value. [5] The model we imagined for the parameter list will be a tree more than a flat list. A group of parameters is just one node of the tree, containing a parameters list, where each parameter can also be a group of parameters. Ok. A generic list type could be defined as parameter type. Perhaps implemented with QList
Re: [Qgis-developer] QGIS Processing Framework
Hi Martin ! The point is actually not to provide every possible parameter type in the framework. IMO we should have a base "parameter" type with several common types such as integer, string, vector layer, enumeration. Such types are used widely and QGIS would come with default edit widgets for them. Then, each library might require some additional parameter types that might also require special editing widgets. The plugin implementing support for such library will provide these types and editing widgets, however they will stay opaque for QGIS. So in the result QGIS will just know there is a parameter and it will know what widget to show in the form, nothing more. Of course such custom types would not be usable across various libraries, but that fine. OK, it seems a good balance. Is this good time to begin laying down this list somewhere ? Any idea about how to handle the 'non Qgis supported' parameters types for the Python API ? . Here QGIS would provide default GUI for a module based on the description, with the possibility for the developer to improve the basic behavior using Qt signals and slots for a better user experience. Are signals and slots sufficient ? Maybe being able to provide a subclass of the default Qgis supported widgets would be cool ? Therefore I tend to think about the whole procesing framework in two levels: 1. backend - similar to WPS: an interface for description of modules, querying the modules and running them 2. gui - built on top of the backend, enhancing the usability and experience for the user: In the GUI part there are endless possibilities how to improve the experience: the developer might want to add a preview for a module that does some raster processing. Or the developer might add interactive rectangle selection from map canvas for choosing a region of interest for the analysis. Maybe doing band selection and region of interest selection on input rasters is general enough to be supported by the framework I completely agree that many times the dependencies between the parameters are far too complex to be modelled in a declarative way. I hope my answer above clarifies this: you as a developer of the orthorectification module would be allowed to watch for changes in the form (using Qt signals) and update other parameters - or do whatever you want. Yes it's more clear. We should consider not only being able to update the parameters values, but also the GUI part (changing some widget settings, eventually even changing the widget class somehow ?). [5] The model we imagined for the parameter list will be a tree more than a flat list. A group of parameters is just one node of the tree, containing a parameters list, where each parameter can also be a group of parameters. Well, I'm a bit afraid of trees of parameters. Would that be really necessary for OTB? Don't worry too much, we are not planning to have 42 nested level of parameters... Having "groups" of parameters is a need. If I'm not wrong, SAGA has this also (it's called Node). Camilo ? Also we want to have parameters shown only depending on a combobox value, for example. So a choice parameter value is declared with both what to show in the combobox, and an associated "parameter group". Please see at the end of http://wiki.orfeo-toolbox.org/index.php/OTB-Wrapper. If in this group you have another choice parameter, you end up with a tree... If you have a good idea to model that in a simpler way, I'll take it. Flat parameter model, but the GUI can rearrange/show/hide them dynamically ? I'm OK with the idea of limiting this to 2 levels max for example (no groups inside groups). Best regards, Julien ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
Hello, I have the same opinion as Martin and Paolo. From our point of view, WPS services would just be another place to wrap our modules. Anyway, I agree with the fact that there shall be a lot of ideas to get inspiration from, so that : - WPS services can be integrated in the Qgis framework out of the box - Any Qgis processing modules can be wrapped in a future "Qgis WPS server" (?) - We can reuse all the good ideas from the WPS standard Le 29/04/2011 10:45, Soeren Gebbert a écrit : Hello Martin, ... I agree that all these are very good reasons for having WPS support in QGIS. It makes sense in a lot of use cases. Still I do not think we should concentrate exclusively on WPS services for processing for several reasons: - the community creates lots of handy plugins, many of them are used for processing. It is not just SAGA, OTB, GRASS or OSSIM that could use the framework - we are speaking about many more possible modules that probably will never be implemented as WPS services. - WPS servers are IMHO not really widespread yet(?). Surely you can install your own on a local computer but I don't think that an average user is able to manage it with few clicks. And not everyone has access to a fast server in basement. IMHO installing a WPS server with different back-ends is no magic. The web server, the WPS server and the back-ends can be bundled and installed as easy as QGIS with all its plugins and libraries and third party dependencies. This is technically no problem and IMHO the 52North guys are able to provide such an out of the box solution. - usability matters - a lot of work can be done by only editing few parameters and running the process, but there are plenty of cases where more interactivity is desired as mentioned also by Julien and Camilo: that could be a complex dependency between input parameters or a possibility for interactive picking of points from map canvas. With WPS you can chain very complex processes with complex dependencies, the interface description is in this case very powerful. You are indeed totally right that its not possible to have interaction with in principle state-less WPS processes. But you can have interaction between processes with the intermediate generated results in a process chain. This is a question of how to design process chains with interaction and how specialized the available processes are. The reasons above make me believe that we shouldn't depend exclusively on WPS. In my vision WPS should be simply another provider of processing modules next to SAGA, OTB or various other smaller plugins. WPS itself simply cannot deliver the rich user interface that we would like to provide. This is a good point. Maybe you can use the WPS specification as the base technology and extend it with additional features which will not break compatibility. Then you will use an OGC standard and you will be able to integrate WPS processes out of the box in the much more powerful framework with the possibility of chaining any kind of processes? You will still need wrapper for each software you want to integrate to wrap there interface into the abstract QGIS process framework. So the design of a really powerful abstract process framework providing interaction and stuff is a lot of work and needs plenty of knowledge about all the software which might be integrated as processes in QGIS. To get an idea of the amount of work: Several very intelligent people have designed the WPS specification and they needed several years to version 1.0.0. My main concern is the manpower which is needed to implement AND maintain such a framework as well as the wrapper and binding for other software packages. For example the GRASS GIS integration in QGIS. If there is nobody in the GRASS GIS or QGIS community who is willingly to take responsibility and time to maintain, update and extend it, it will be unusable in the future or it will depend on an obsolete or buggy GRASS GIS version. I am absolutely not against a cool abstract process framework in QGIS, but i would like to bring some IMHO important considerations into discussion. Best regards Soeren Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
Hello, Some final thoughts before the week end : - Even though its clear that the main objective is to have this framework well integrated in Qgis, it would be nice if it could be accessed without running Qgis, at least for the "back end" part. Being able to access it through a standard Python shell would be very usefull. I think it converges with Paolo's idea of having a scriptable Qgis. - Having the backend accessible through a C/C++ interface would then be great , so that we can access it not only from Python, but also from other non-Python-compatible langages/applications (say Java for example, to be able to integrate it in current state of the art WPS implementations) - Being able to run each module GUI independently, outside Qgis, would be nice also. Less sure on this one... At least not the priority. For the OTB modules we have some other target applications where we would like to push our modules. I'm now seeing things in a much wider scope thanks to this discussion, and I'm telling myself we should handle things one step above : it is probably the Qgis framework that we will want to wrap in other applications. As already said, using as much manpower as possible from the open source community is important so that it becomes a success story. Maybe those points are obvious to all of you, just wanted to mention them to be sure. And I know : one step at a time ;) Best regards, Julien Le 29/04/2011 13:15, Paolo Cavallini a écrit : Il giorno ven, 29/04/2011 alle 12.43 +0200, Julien Malik ha scritto: Anyway, I agree with the fact that there shall be a lot of ideas to get inspiration from, so that : - WPS services can be integrated in the Qgis framework out of the box - Any Qgis processing modules can be wrapped in a future "Qgis WPS server" (?) - We can reuse all the good ideas from the WPS standard Agreed, this makes a lot of sense. All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
Hi ! Yes, you are correct, the processing.Plugin class does nothing -- does no harm either, but agree on removing it. If it does nothing, then it does harm that I'm obliged to inherit from it ;) Also remove the arguments from the processing. Module constructor, and have e.g. saga.Module override paramters(), name(), tags(), etc, so that the relevant code only gets executed when necessary. Each plugin would then be responsible for registering/deregistering it's modules. Either passing a list or a callback to the framework. I'd like that. On the provenance: I just had the saga implementation add a 'saga' tag to every module. I think that's the simplest solution. It doesn't show up currently, because, every module having that tag it is deemed irrelevant by the framework. OK for now I think. - about the gui part : should it be possible to create the specific widget for a parameter for which the framework does not provide a default ? i think so. Maybe it would make sense that each ModuleInstance can be queried for the widget, a default implementation being provided for all standard types. Even for the standard provided widgets, it could be nice to be able to simply subclass them to add our own things (not sure about this). Implement parameter.widget(value) in a subclass if you want custom widgets. That function should get called by processingplugin.Dialog.widgetByType(), if present. Haven't tried it yet, though. OK I did not understand this part of the code in the first place, now I know ! It's me there not being used to all the Python magic yet. Open for discussion if you think this is not the best way to handle this. Seems like a good start. I'll give it a try - is there a need for keeping 2 modules (processing and processingplugin) ? can a plugin depend on another plugin (in my otb plugin can I "import processingplugin") ? if yes, putting everything in one plugin will make it more easy to distribute a version of the code (as long as it is python...). But, YOU introduced 'processingplugin'! :D I think it is a good idea to keep them both: QGIS plugins are inherently GUI-related, they have a initGui method, after all. But, the QGIS processing framework should work in a GUI agnostic way, so that it will be useful in other environments, too. Having processing for the logic& processingplugin for the GUI, forces us to keep both aspects separated. Perhaps the names are too similar, confusing... rename processingplugin to processingPanel or processingGUI or something? I was only mentioning the fact that there is now one part in a plugin, and one part in qgis core. Could there be two plugins ? It will be more easy for others to give it a try. - the panel should be more tied to the framework singleton : when a new plugin is loaded/unloaded, it should be possible to update the Panel for example (putting the gui initialization outside of the Panel constructor may help) I am not sure of what you mean: I precisely tried to separate the framework from the panel. What would be A Good Thing, I think, is reimplementing the panel with QTreeView and the framework as a ItemModel. That way the panel would get updated whenever the framework changes. What do you think? This was my point : having a "two way" connection between those. - the panel does not provide an easy way to differenciate between the different implementations (saga/otb...). Maybe a tag could be used for it, or maybe it should be given a different meaning (like the "main tag"). For later, you might want to add an easy way to enable/disable all the OTB/Saga/Gdal/ by just clicking on an icon ? Agree: tags. Standard tags for now, I think. If we see the need to introduce 'special tags' we can always do that later. Will be ok for now. - I/O : how will this be handled ? I'm asking this related to the recent mails with interest for providing ossim image chains in Qgis. If it must support module chaining, then there is a need for an abstraction of the i/o mechanism. is it the qgis dataproviders ? a module can take a raster/vector dataprovider as input and can output a raster/vector dataprovider ? Yes, qgis dataproviders, I think. Perhaps alternatives later. This is, IMO, one of the most dificult aspects remaining to define. I'd love to hear some thoughts from the Qgis gurus about this. Note that I had defined 'roles' for parameters: input, output& option, feedback. Input& output would contain dataproviders, while option& feedback contain other variables, e.g. integers, strings, etc. The later are read-only from the frameworks point of view, just a way to pass messages or simple results to the user. There also is the special 'state' option paramter, which controls the ModuleInstance's, well, state (running, paused, stopped, etc.) Julien ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS Processing Framework
Hi all,
Reading a thread on qgis-users from yesterday ("Sextante library"), I
discovered the existence of a Python library called Traits :
http://code.enthought.com/projects/traits/
I read
http://code.enthought.com/projects/traits/docs/html/tutorials/traits_ui_scientific_app.html
and came out with a "Are we reinventing the wheel ?" feeling.
Has anybody some experience in using this library ?
Is it usable in QGis (it already has a PyQt GUI backend) ? Any
limitation coming to mind ?
Could it be the background on which the QGis Processing Framework is built ?
I don't know at what point it can be customized, if it will fit to all
the requirements, but it surely adresses the same needs.
Julien
Le 29/04/2011 17:54, Camilo Polymeris a écrit :
On Fri, Apr 29, 2011 at 7:31 AM, Julien Malik wrote:
Hi Martin !
The point is actually not to provide every possible parameter type in
the framework. IMO we should have a base "parameter" type with several
common types such as integer, string, vector layer, enumeration. Such
types are used widely and QGIS would come with default edit widgets
for them.
Then, each library might require some additional parameter types that
might also require special editing widgets. The plugin implementing
support for such library will provide these types and editing widgets,
however they will stay opaque for QGIS. So in the result QGIS will
just know there is a parameter and it will know what widget to show in
the form, nothing more. Of course such custom types would not be
usable across various libraries, but that fine.
OK, it seems a good balance.
Yes. Sounds good.
Is this good time to begin laying down this list somewhere ?
I am still trying to keep this thing updated with the insights from
this thread, at least, things I think there is somewhat of a
consensus.
https://github.com/polymeris/qgis/wiki/QGIS-Processing-Framework
Anyone is welcome to edit the page.
Any idea about how to handle the 'non Qgis supported' parameters types for
the Python API ?
Keep them opaque. Implementation responsible for supplying python
functions to handle them, if desired.
. Here QGIS would provide
default GUI for a module based on the description, with the
possibility for the developer to improve the basic behavior using Qt
signals and slots for a better user experience.
Are signals and slots sufficient ?
Maybe being able to provide a subclass of the default Qgis supported widgets
would be cool ?
Both, but in general signals should be enough, I think. Most
parameters are enumerations, numeric values, etc. after all.
Therefore I tend to think about the whole procesing framework in two
levels:
1. backend - similar to WPS: an interface for description of modules,
querying the modules and running them
2. gui - built on top of the backend, enhancing the usability and
experience for the user:
Agreed. GUI on the QGIS side, unless necessary.
Maybe doing band selection and region of interest selection on input rasters
is general enough to be supported by the framework
I was calling the later a "Rect" parameter.
This is a list of parameters I think could be supported by the
framework (much more thought can be put into it, this is just a
starting point):
Raster = OTB Image = SAGA Grid
Vector = OTB vector data = SAGA Shape
URL = OTB File name = OTB Directory name = SAGA FilePath
String = OTB String = SAGA String = SAGA Text = default for
everything not covered
Boolean = OTB Boolean = SAGA Bool
Number = OTB Numeric = OTB Radius = SAGA Int = SAGA Double
Enumeration = OTB Choice = SAGA Choice
Tuple = OTB Origin = OTB Size = SAGA Range
Rect = OTB Region = SAGA Rect
Point = OTB Point/Index = SAGA Point
List = OTB Parameter group = SAGA Grid List, Shapes_List, etc.
(from https://github.com/polymeris/qgis/wiki/List-of-parameters)
I completely agree that many times the dependencies between the
parameters are far too complex to be modelled in a declarative way. I
hope my answer above clarifies this: you as a developer of the
orthorectification module would be allowed to watch for changes in the
form (using Qt signals) and update other parameters - or do whatever
you want.
Yes, exactly! I have updated my "mock-up API" to reflect this.
Yes it's more clear.
We should consider not only being able to update the parameters values, but
also the GUI part (changing some widget settings, eventually even changing
the widget class somehow ?).
You could actually even remove parameters and add others, change the
state of the module, etc. Everything that is possible in other
contexts. Then fire a signal to tell the framework to re-read what
has changed.
If I'm not wrong, SAGA has this also (it's called Node). Camilo ?
You are right.
Also we want to have parameters shown only depending on a combobox value,
for example.
So a choice parameter value is dec
Re: [Qgis-developer] QGIS Processing Framework
One point somewhere in this thread was about having (in the future) the framework in core, implemented in C++, with a Python binding on top of it. This would go against it, but I'm not sure now whether the C++ side is a must-have or not. All the tools listed for possible inclusion in this framework are either in Python or have Python wrapper on top of them (I was claiming for C++ support in the past, this is now history, and the OTB-Qgis glue can and will be done in Python). Julien Le 21/06/2011 13:40, Camilo Polymeris a écrit : On Tue, Jun 21, 2011 at 7:28 AM, Noli Sicad wrote: It seems that PyQT is probably just new. Hence, we have not heard about this, "Currently, the supported GUI toolkits are wxPython and PyQt. While both toolkits funtion with Traits, integration with wxPython is currently more complete. All future development, however, will focus on supporting PyQt." I think we would mostly interact with trait's GUI abstraction, anyways. So we could start development& hope that later PyQt support will improve (so that we don't depend on wxWidgets). [...] I had the same feeling, but I do not know that project. Any stronger opinions? I don't think it would be to hard to switch to traits (looks quite similar to our design), I'll wait a few days to see if someone more experienced chimes before taking a decision. There may be hidden limitations or complexities we are not considering. In the meanwhile focus on converting the module tree to MVC. Regards, 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
Re: [Qgis-developer] QGIS crashes when loading Traits from Python console. [Was: QGIS Processing Framework]
Hello, Same here on Ubuntu Maverick. The package can be imported in a standalone interpreter (python or ipython) I start qgis, runs the "Python console", do the "import enthought.traits.api" : crash. Julien Le 28/06/2011 17:41, Camilo Polymeris a écrit : On Mon, Jun 27, 2011 at 3:59 PM, Camilo Polymeris wrote: Given that there are no objections& I have studied the traits docs without finding any reason against it, I'll start migration of the framework. Having trouble with that.. QGIS segfaults when I try to load any of the modules in enthought.traits, e.g.: import enthought.traits.api When running the import through pdb it seems to hang. Can someone please confirm? Thanks, Camilo Confirmed, it crashes with Loaded symbols for /usr/lib/python2.7/dist-packages/enthought/traits/ctraits.so Reading symbols from /usr/lib/python2.7/dist-packages/enthought/traits/protocols/_speedups.so...(no debugging symbols found)...done. Loaded symbols for /usr/lib/python2.7/dist-packages/enthought/traits/protocols/_speedups.so Core was generated by `/usr/bin/qgis.bin'. Program terminated with signal 11, Segmentation fault. #0 0x7f3bf98764c8 in ?? () from /usr/lib/python2.7/dist-packages/enthought/traits/protocols/_speedups.so traits from official deb package. All the best. -- Paolo Cavallini: http://www.faunalia.it/pc Yes. Same here. No idea what those _speedups.so could be... Any ideas? Can't continue if we don't solve this. Regards, Camilo debian, Traits v 3.0.0 Program received signal SIGSEGV, Segmentation fault. 0x7fffd22c56b4 in ?? () from /usr/lib/python2.6/dist-packages/enthought/traits/protocols/_speedups.so bt #0 0x7fffd22c56b4 in ?? () from /usr/lib/python2.6/dist-packages/enthought/traits/protocols/_speedups.so #1 0x7fffd22c7e7d in ?? () from /usr/lib/python2.6/dist-packages/enthought/traits/protocols/_speedups.so #2 0x7fffe1aeaf80 in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #3 0x7fffe1aeccc0 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #4 0x7fffe1aeaffb in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #5 0x7fffe1aeccc0 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #6 0x7fffe1aeaffb in PyEval_EvalFrameEx () from /usr/lib/libpython2.6.so.1.0 #7 0x7fffe1aeccc0 in PyEval_EvalCodeEx () from /usr/lib/libpython2.6.so.1.0 #8 0x7fffe1aecd92 in PyEval_EvalCode () from /usr/lib/libpython2.6.so.1.0 #9 0x7fffe1afe0d2 in PyImport_ExecCodeModuleEx () from /usr/lib/libpython2.6.so.1.0 #10 0x7fffe1b0099e in ?? () from /usr/lib/libpython2.6.so.1.0 #11 0x7fffe1b017df in ?? () from /usr/lib/libpython2.6.so.1.0 #12 0x7fffe1b01a6f in ?? () from /usr/lib/libpython2.6.so.1.0 #13 0x7fffe1b020b0 in ?? () from /usr/lib/libpython2.6.so.1.0 #14 0x7fffe1b02604 in PyImport_ImportModuleLevel () from /usr/lib/libpython2.6.so.1.0 #15 0x7fffe1ae4baf in ?? () from /usr/lib/libpython2.6.so.1.0 ___ 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
Re: [Qgis-developer] Re: Rethinking the testing and release procedure of QGIS
Hello, Last month, Julien Malik mentioned about Sikuli ( http://sikuli.org/ http://sikuli.org/ ). I've had a preliminary look at the documentation and it may have potential. I will not have time to try it for a few weeks, but the possibility of developing scripts to exercise QGIS without any knowledge of, or access to, the code looks useful. If I get chance to develop any tests, I'll give an update. A nice recent article about it here : http://www.insight-journal.org/browse/publication/822 CMake/CTest integration, and some feedback from the developers about the advantages and limitations. Julien ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WPS plugin not connecting (proxy?)
Hi Paolo, I remember having some difficulties too with proxy settings and the WPS plugin. I did not look at the code, but the WPS plugin honors the http_proxy env var setting. Also, I'm wondering whether it should always honor the QGis proxy settings (nor the http_proxy env var) : for my use case, I'm trying to reach a WPS server inside my LAN, while I need proxy settings to access the web (plugin installation, etc...). Maybe each server configured in the plugin should have an associated local/remote boolean setting. Strange as it can be, for my "LAN case", the GetCapabilities and DescribeProcess calls works, but http_proxy must be correctly unset only for ExecuteProcess request to work correctly. Cheers, Julien Le 14/10/2011 14:24, Paolo Cavallini a écrit : Hi all. I set up the proxy in qgis, and everything is working, except for the Elevation plugin (as I already wrote) and WPS plugin: do they both use another method for accessing the web, bypassing the proxy setting? All the best. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Announcing the OrfeoToolbox plugin
Hello all, We are pleased to announce the availability of the OrfeoToolbox [1] Qgis plugin. This plugin is based on the already available "Processing Manager" plugin [2], which can also provide access to the SAGA modules. It's a Python plugin which can be installed through the Python Plugin Installer (but need a required OTB Python package installed on your system). The plugin is hosted in the Faunalia repository, next to the "Processing Manager" and the "SAGA Module interface" plugins. Installation instructions for the backend Python package are given in [3]. In particular, an OSGeo4W-compatible binary is provided on a nightly basis at [4], so Windows users can install and test it in a few minutes. Testing it on Linux involves more work (see [3]), but we are working on providing Ubuntu binary packages to ease the installation process on this platform. The plugin provides access to a set of modules wrapping different kind of functionnalities of the Orfeo Toolbox. As of now, modules are available to perform the following tasks : - P+XS Pan Sharpening - Orthorectification - Optical Calibration - KMeans clustering - SVM Supervised Classification - Mean Shift segmentation - Change Detection (Multivariate Alteration Detector algorithm) - Hyperspectral data unmixing - Filtering (mean, gaussian, anisotropic diffusion) - Raster conversion and scaling This is only the beginning and new modules will be added regularly to expose most of the OTB functionnalities in easy to use application modules. Many thanks to Camilo for providing the Processing Manager Framework, and to Paolo and Giuseppe for helping on the plugin packaging. We will be glad to hear your feedback ! Best regards, Julien [1] http://www.orfeo-toolbox.org/otb/ [2] https://github.com/polymeris/qgis/wiki [3] http://wiki.orfeo-toolbox.org/index.php/Quantum_GIS_access_to_OTB_applications [4] http://www.orfeo-toolbox.org/packages/nightly/latest/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] 2 versions of Processing Framework Manager
Hello Agus, The version to use is of course the last one : 0.26. I don't see several versions in the plugin installer. The directory in which the 'Processing Framework Manager' is installed has been renamed recently, from processingplugin to processingmanager. This may be the root of the problem. Can you double-check your $HOME/.qgis/python/plugins directory ? After installing the 0.26 version, you should not see any directory named "processingplugin". Just "processingmanager". If so, maybe just deleting it will make the 0.21 reference go away. Julien Le 19/10/2011 08:05, Agustin Lobo a écrit : I see 2 versions of Processing Framework Manager, the 0.26 installs fine on 1.7.1 (ubuntu 10.04 LTS binaries from ubuntugis-unstable) but the 0.21 issues this error: Couldn't load plugin saga due an error when calling its classFactory() method Traceback (most recent call last): File "/usr/lib/python2.6/dist-packages/qgis/utils.py", line 138, in startPlugin plugins[packageName] = package.classFactory(iface) File "/home/alobo/.qgis/python/plugins/saga/__init__.py", line 76, in classFactory from plugin import SAGAPlugin File "/usr/lib/python2.6/dist-packages/qgis/utils.py", line 283, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File "/home/alobo/.qgis/python/plugins/saga/plugin.py", line 31, in import processingmanager.processing as processing File "/usr/lib/python2.6/dist-packages/qgis/utils.py", line 283, in _import mod = _builtin_import(name, globals, locals, fromlist, level) ImportError: No module named processingmanager.processing I assume I just have to uninstall 0.21 (the plugin gets installed despite the error, which is unusual) Agus ___ 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
[Qgis-developer] Re: [Qgis-user] Announcing the OrfeoToolbox plugin
Hello, Following on this recent annoucement, the necessary OrfeoToolbox binaries to run the modules in Qgis are available in the OSGeo4W distribution. It is now straightforward to get the OrfeoToolbox up and running in Qgis on Windows machines. Installation instructions [1] have been updated to reflect this. Thanks to the OSGeo4W team to make this possible ! Best regards, Julien [1] http://wiki.orfeo-toolbox.org/index.php/Quantum_GIS_access_to_OTB_applications#Notes_for_Windows_users Le 18/10/2011 12:42, Julien Malik a écrit : Hello all, We are pleased to announce the availability of the OrfeoToolbox [1] Qgis plugin. This plugin is based on the already available "Processing Manager" plugin [2], which can also provide access to the SAGA modules. It's a Python plugin which can be installed through the Python Plugin Installer (but need a required OTB Python package installed on your system). The plugin is hosted in the Faunalia repository, next to the "Processing Manager" and the "SAGA Module interface" plugins. Installation instructions for the backend Python package are given in [3]. In particular, an OSGeo4W-compatible binary is provided on a nightly basis at [4], so Windows users can install and test it in a few minutes. Testing it on Linux involves more work (see [3]), but we are working on providing Ubuntu binary packages to ease the installation process on this platform. The plugin provides access to a set of modules wrapping different kind of functionnalities of the Orfeo Toolbox. As of now, modules are available to perform the following tasks : - P+XS Pan Sharpening - Orthorectification - Optical Calibration - KMeans clustering - SVM Supervised Classification - Mean Shift segmentation - Change Detection (Multivariate Alteration Detector algorithm) - Hyperspectral data unmixing - Filtering (mean, gaussian, anisotropic diffusion) - Raster conversion and scaling This is only the beginning and new modules will be added regularly to expose most of the OTB functionnalities in easy to use application modules. Many thanks to Camilo for providing the Processing Manager Framework, and to Paolo and Giuseppe for helping on the plugin packaging. We will be glad to hear your feedback ! Best regards, Julien [1] http://www.orfeo-toolbox.org/otb/ [2] https://github.com/polymeris/qgis/wiki [3] http://wiki.orfeo-toolbox.org/index.php/Quantum_GIS_access_to_OTB_applications [4] http://www.orfeo-toolbox.org/packages/nightly/latest/ ___ 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] Dash broken?
Hi all, This should do the trick : https://github.com/qgis/QGIS/pull/3550 Regards, Julien On 30/09/2016 12:06, Jürgen E. Fischer wrote: Hi Nyall, On Fri, 30. Sep 2016 at 19:28:02 +1000, Nyall Dawson wrote: Looks like https://dash.orfeo-toolbox.org/index.php?project=QGIS is broken at the moment. None of the newer builds are showing even though the results are successfully submitted. Argh, the logs from the debian nightlies were not uploaded for the different reason - I thought I found the cause, but they would still not show... Anyone know who looks after this? Hm, IIRC that was introduced at the hackfest in Lisbon by Julien Malik. Jürgen ___ 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] otb debs available
Yes we have a PPA for OTB binaries. Please check http://www.orfeo-toolbox.org/SoftwareGuide/SoftwareGuidech2.html#x14-240002.1.3 The ppa is https://launchpad.net/~otb/+archive/orfeotoolbox-stable Best, Julien Le 16/04/2012 00:41, Tim Sutton a écrit : Hi On Sun, Apr 15, 2012 at 11:38 AM, Paolo Cavallini wrote: Hi all. I'm enjoying sextante and otb immensely, so I've packaged otb and uploaded to my repo: debhttp://int.faunalia.it/~paolo/debian testing/ In case someone needs it. It is compiled on clean testing, with just gdal from experimental (1.9.0-1~exp2). Thanks a lot to the otb team for helping in packaging (especially Sebastien Dinot and Julien Malik). Are these available for Ubuntu GIS somewhere too? Thanks Tim Enjoy. All the best. -- Paolo Cavallini See: http://www.faunalia.it/pc ___ 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
Re: [Ubuntu] Re: [Qgis-developer] otb debs available
Hi,
Le 16/04/2012 02:57, Alex Mandel a écrit :
I believe the hold up previously was a libtiff linking issue in gdal
which should be resolved now. I'll look into testing and copying from
the otb ppa to the ubuntugis repo.
When developing the OTB->Sextante->Qgis bridge during the HackFest, I
was using qgis 1.7.4 from ubuntugis-unstable ppa, and otb from our own ppa.
It works since we took a different approach than before and now Sextante
is calling the OTB command line tools ('otb-bin' package).
Previously we used the otb python bindings, so qgis and otb were loaded
in the same process, and this is where we hit the issue with
libtiff/libgeotiff. I confirm this issue is fixed with gdal 1.9, but
gdal 1.9 is not available (yet ?) for all the distro.
Now, it should just work.
I believe it is safe to copy the otb packages into ubuntugis-unstable.
It works ok for the "otb inside sextante inside qgis" project.
Cheers,
Julien
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Sextante bug categories
Hi, I just updated the categories name to differenciate between backend related issues and pure sextante issues. I personnally don't like "General", does not really mean anything. Do we miss a "Core" category ? Any better proposition ? Julien Le 17/04/2012 13:33, Victor Olaya a écrit : Great! Thanks! El día 17 de abril de 2012 13:31, Paolo Cavallini escribió: Hi all. I've added categories to the Sextante bug tracker[0]. I think this will improve the management of the tickets. Please feel free to add or suggest other categories, and do not forget to add them to the tickets. All the best. -- Paolo Cavallini See: http://www.faunalia.it/pc [0] http://hub.qgis.org/projects/sextante/issues ___ 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SEXTANTE backends
Hi, Does the Qgis plugin system support dependency between plugin ? Now that there is (already !) a lot of backends integrated directly into the core plugin, I guess there will be more and more people proposing improvements. I think moving to a DVCS would help, so that people can "pull-request" you, with all the advantages of dvcs : lower down patch work for you, honor contributors in the code base by preserving authoring, help for work on more mid/long-term feature before integration into your reference repository, etc... If my understanding is ok, the redmine instance can host a git repository, at the cost of two mouse clicks. Victor, others, what's your opinion on this ? About integration of the binaries, as discussed at the HF, I'm afraid this would be impossible to maintain. Probably even impossible to do at all. It makes no sense on linux where the habit is to install software system-wide through the package manager. My opinion is that it is a packager-related issue, and should not interfere with the plugin deployment. Even for windows, a package can be a bit more than just a zip to unzip. You'll be reimplementing osgeo4w-setup inside your plugin if you take that road. For windows, I see there is already a "qgis-grass-plugin" osgeo4w package. Maybe there could be a qgis-sextante-providers package, sort of virtual package depending on all the necessary packages for sextante backends ? Then, if it proves usefull and stable enough, it could even be integrated in the standalone qgis installer so that people downloading qgis out of osgeo4w also can get saga/otb/... easily ? Someone would need to step up to provide and maintain a saga osgeo4w package [1]. The rest of the current sextante backends are already packaged. Such "sextante" virtual package is something which is doable on Debian-based distros (I don't know anything about non-Debian-based linux...) Julien [1] http://trac.osgeo.org/osgeo4w/ticket/273 Le 17/04/2012 13:56, Victor Olaya a écrit : that is a question that should be discussed. Algorihtm providers in SEXTANTE can be turned off, so I would prefer to have them all together, since the size is rather small, and to activate them within SEXTANTE. However, there is already a mechanism for creating plugins that connect their algorithms into SEXTANTE, for those who prefer to develop them outside of SEXTANTE and distribute them separately as well. As I said, in the case of small plugins, it should not be a problem to include them in SEXTANTE. The main issue I see is related to providers using external apps and how to distribute them. I think that this should also be discussed. For now, I will keep all the backends and algorithms that I develop in one single plugin along with the SEXTANTE core. If other developers want their algorithms also included there, just tell me. And if someone creates its own provider as an external plugin, it should be clearly stated that it requires SEXTANTE, so people can install it in advance and also can search for SEXTANTE-based plugins. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [OSSIM] [Qgis-developer] Re: Fwd: Creating a Python plugin for OSSIM-QGIS
No not really. An ossim integration into sextante makes much sense. OTB only uses a subpart of the ossim core lib (the sensor modeling aspects) We do not use all their image-rendering algorithms. Julien Le 22/04/2012 18:29, cavall...@faunalia.it a écrit : OTB people should know better than anybody else. All the best. --- http://faunalia.it/pc Sent from mobile, sorry for being short - Reply message - Da: "Victor Olaya" A: "Paolo Cavallini" Cc: Oggetto: [OSSIM] [Qgis-developer] Re: Fwd: Creating a Python plugin for OSSIM-QGIS Data: dom, apr 22, 2012 10:14 >> > Please also remember that OSSIM is embedded in OTB, currently usable > through SEXTANTE. > And yes, an OSSIM provider would be very good to have. > All the best. > I did not know that. Then having OSSIM algorithms in SEXTANTE might be a bit redundant, right? Regards ___ 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
Re: [Qgis-developer] Sextante - OTB plugin and SAR data
Hi Noli Monteverdi is not "OTB for MacOSX". Monteverdi is one desktop application with some OTB functionnalities in it. This is unrelated to the Qgis/Sextante interface. To use OTB from Qgis on MacOSX, you will need to compile OTB from sources. Instructions can be found in [1] and [2]. Especially, you need to set BUILD_APPLICATIONS to ON. Regards, Julien [1] http://www.orfeo-toolbox.org/SoftwareGuide/SoftwareGuidech2.html#x14-270002.2 [2] http://www.orfeo-toolbox.org/SoftwareGuide/SoftwareGuidech32.html#x61-43200032.4 Le 27/08/2012 09:52, Noli Sicad a écrit : How do you install this Sextante - OTB plugin? The first thing you have to do is to install OTB, then if you are using Sextante on Linux nothing to do anymore. path to binaries are automatically found and algs should work, while on Windows you have to configure it. In "options and configuration" menu, you find what you need! As I mentioned, this is Mac OS X. I installed Monteverdi-1.12 (which is OTB for Mac OS X). It has a Resources/lib/otb and Resources/MacOS folders. /lib/otb folder is where the dynamic libraries is located. /MacOS folder has the other libraries (e.g. libgeos.dylib, etc.). Any suggestion how to organise (e.g copy these libraries)? How to you compile OTB in Linux? http://www.orfeo-toolbox.org/otb/download.html I can compile this in Mac OS X. Note that MacOS X is just like linux system. The system look like this: /usr/local/bin /usr/local/library /usr/loca/include How do you install the QGIS Sextante OTB plugin in Linux? Noli ___ 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
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Hi Noli, For MacOSX, the easier path I know of is to use MacPort to install all the needed dependencies. With MacPort, install the following : expat, curl, tiff, geotiff, jpeg, gdal, mercurial, cmake, etc (I may have missed a few) Grab this ctest script : http://hg.orfeo-toolbox.org/OTB-DevUtils/file/21ee66ab6fd3/Config/leod/leod-OTB-Nightly-macport_light.cmake And customize it : - change CTEST_SITE and CTEST_BUILDNAME to whatever you like - change CTEST_SOURCE_DIRECTORY and point to where you extracted the OTB sources - change CTEST_BINARY_DIRECTORY and point it to where the build file will live - change CMAKE_INSTALL_PREFIX to the path where OTB will be installed after successfull build - in the CTEST_INITIAL_CACHE part, you might want to change to : BUILD_TESTING:BOOL=OFF BUILD_EXAMPLES:BOOL=OFF BUILD_APPLICATIONS:BOOL=ON OTB_WRAP_PYTHON:BOOL=OFF OTB_WRAP_QT:BOOL=OFF OTB_WRAP_JAVA:BOOL=OFF to reduce the build time. Then from a shell, start : ctest -S -VV Go to your build dir and type "make install" Then look in CMAKE_INSTALL_PREFIX/bin and you should be able to launch an OTB application (otbcli_Something scripts) Then in Sextante configuration, you should set : -"OTB command line tools" option to CMAKE_INSTALL_PREFIX/bin -"OTB applications folder" option to CMAKE_INSTALL_PREFIX/lib/otb And you're good to go. Good luck, Julien Le 27/08/2012 13:42, Noli Sicad a écrit : Hi, Has anybody using Mac OS X managed to install OTB in Mac OS X and installed the QGIS OTB python plugin? Noli On 8/27/12, Noli Sicad wrote: Hi Julien, Thanks for your reply. Now, how to use cmake on InsightToolkit-4.2.0? There is no instruction how to I install ITK (i.e. InsightToolkit-4.2.0) using cmake? Anybody how to know how to install ITK? (I installed cmake already for Mac OS X.) Thanks, Noli ___ 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
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Le 28/08/2012 06:30, Noli Sicad a écrit :
Hi Julien,
Disregard my last question, my last posting. I got confuse with the
"macport" reference in the script.
I read the script again and I got it now, almost.
I see I don't need to hg clone manually since it will be pulling the
nightly build
###
execute_process( COMMAND ${CTEST_HG_COMMAND} pull
http://hg.orfeo-toolbox.org/OTB-Nightly
WORKING_DIRECTORY "${CTEST_SOURCE_DIRECTORY}"
OUTPUT_VARIABLE PULL_RESULT
ERROR_VARIABLEPULL_RESULT )
file(WRITE ${PULL_RESULT_FILE} ${PULL_RESULT} )
Yep, remove those lines.
OK. I changed the source and binary directories to:
##
SET (CTEST_SOURCE_DIRECTORY "/Users/nsicadl/Dashboard/nightly/OTB-Release/src")
SET (CTEST_BINARY_DIRECTORY "/Users/nsicad/Dashboard/nightly/OTB-Release/build")
##
Do I need to create these directories (manually) before running the script?
CTEST_SOURCE_DIRECTORY is where you checked out the sources (or untar them), so
it must exists.
CTEST_BINARY_DIRECTORY : i don't remember, just try
I would like to change this line (below) to something else - not "OTB-macport"?
CMAKE_INSTALL_PREFIX:STRING=$ENV{HOME}/Dashboard/nightly/OTB-Release/install/OTB-macport
Can I do this like this?,
Of course, put anything you like there.
##
CMAKE_INSTALL_PREFIX:STRING=$ENV{HOME}/Dashboard/nightly/OTB-Release/install/OTB-mtn_lion
##
Would this be fine?
Yes
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Hi William, Le 28/08/2012 04:35, William Kyngesburye a écrit : Noli, I started looking at this to see what needs to be done to use my frameworks. First, FLTK. To compile on 10.8, you will need a recent FLTK 1.3 checkout. The current MacPort version (r9650) compiles fine on 10.8, but not the official release. Also note that compiling the OTB-FLTK bridge is not necessary for using OTB from QGis. So OTB_USE_VISU_GUI=OFF is fine when configuring OTB. You need the dev 1.3.x source, for updates to support the new libpng in my UnixImageIO framework. You also need my FreeType framework (not part of the QGIS requirements). This configuration is just minimal - no tests/examples. I'm not sure if some of the options are needed for a static build, though may be if you want the examples. (the build system is messy - checking for things twice, ignoring what I give it, ...) in a Terminal, in the fltk source folder: mkdir build-snow cd build-snow cmake -Wno-dev -D CMAKE_INSTALL_PREFIX=/usr/local \ -D CMAKE_BUILD_TYPE=MinSizeRel \ -D CMAKE_OSX_ARCHITECTURES="x86_64" \ -D OPTION_BUILD_EXAMPLES=OFF \ -D HAVE_FREETYPE_H=/Library/Frameworks/FreeType.framework/Headers/freetype.h \ -D FREETYPE_PATH=/Library/Frameworks/FreeType.framework/Headers/config \ -D LIB_png=/Library/Frameworks/UnixImageIO.framework \ .. I'm working on OTB now. I'll get back to you when I figure that out, probably in a day or two. Excellent ! Thanks ! Julien ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Hi William, We are not losing much when using the command line interface. Using the OTB-Python wrappers we could have a better progress reporting, but it is minor. On the other hand, we run into packaging/dependencies hell when trying to link Qgis and OTB together. With the current state of the gdal package on some platform (debian/ubuntu), it would crash. Also, we are clear of potential licensing issue (compatibility between cecill and gpl licence) with this setup. So let's say it is a good solution for now... Victor might have more arguments on this. Best, Julien Le 28/08/2012 04:42, William Kyngesburye a écrit : On Aug 27, 2012, at 8:17 AM, Julien Malik wrote: OTB_WRAP_PYTHON:BOOL=OFF OTB_WRAP_QT:BOOL=OFF OTB_WRAP_JAVA:BOOL=OFF If we're using this in Sextante, a python module package for QGIS, don't we want the python wrappers? Seems silly that Sextante devs would ignore a direct python interface to OTB. - William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Noli, Le 29/08/2012 06:14, Noli Sicad a écrit : Hi William, Thanks having a go with this. I am using Mountain Lion (10.8.1). Would it help if I am going to create this folder, /Developer/SDKs and copy the MacOSX10.8.sdk from Xcode? The end result would be like this (below) for the directory -D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.8.sdk" # Now, I did this. ### Nolis-MacBook-Pro:OTB nsicad$ mkdir build Nolis-MacBook-Pro:OTB nsicad$ cd build Nolis-MacBook-Pro:build nsicad$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local -D CMAKE_BUILD_TYPE=MinSizeRel -D CMAKE_OSX_ARCHITECTURES="x86_64" -D CMAKE_OSX_DEPLOYMENT_TARGET="10.8" -D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.8.sdk" -D OTB_WRAP_QT=OFF -D OTB_WRAP_JAVA=OFF -D OTB_WRAP_PYTHON=OFF -D BUILD_APPLICATIONS=ON -D OTB_USE_VISU_GUI=OFF -D TIFF_LIBRARY=/Library/Frameworks/UnixImageIO.framework -D GEOTIFF_LIBRARY=/Library/Frameworks/UnixImageIO.framework -D JPEG_LIBRARY=/Library/Frameworks/UnixImageIO.framework -D USE_OPENMP=OFF -D CMAKE_INSTALL_NAME_DIR=/usr/local/lib/otb CMake Error: The source directory "/Users/nsicad/Documents/Work_1new/OTB/build/CMAKE_INSTALL_NAME_DIR=/usr/local/lib/otb" does not exist. Specify --help for usage, or press the help button on the CMake GUI. Nolis-MacBook-Pro:build nsicad$ ## Do have any idea why I am getting this error ? CMake Error: The source directory "/Users/nsicad/Documents/Work_1new/OTB/build You are missing the last argument in the cmake command line, specifying the source directory. Read again the command line provided by William, and don't miss the ".." Julien ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Hi Noli, Check the cmake variables and verify they point to actual directories. You are getting this error since the cmake variable you are using are not defined. Julien Le 29/08/2012 07:33, Noli Sicad a écrit : Hi Julien, I tried your script and I got this error (below) Noli ## Last login: Wed Aug 29 15:07:22 on ttys011 Nolis-MacBook-Pro:OTB nsicad$ ctest -S otb.cmake -VV * Extra verbosity turned on Reading Script: /Users/nsicad/Documents/Work_1new/OTB/otb.cmake CMake Error at otb.cmake:100 (ctest_empty_binary_directory): ctest_empty_binary_directory called with incorrect number of arguments CMake Error at otb.cmake:104 (ctest_start): ctest_start binary directory not specified. Specify binary directory as an argument or set CTEST_BINARY_DIRECTORY SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB/build SetCTestConfigurationFromCMakeVariable:HGCommand:CTEST_HG_COMMAND SetCTestConfiguration:HGCommand:/usr/local/bin/hg SetCTestConfigurationFromCMakeVariable:HGUpdateOptions:CTEST_HG_UPDATE_OPTIONS SetCTestConfiguration:HGUpdateOptions:-C SetCTestConfiguration:BuildDirectory:/Users/nsicad/Documents/Work_1new/OTB SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB/build Cannot create directory /Testing/Temporary Cannot create log file: LastUpdate.log Updating the repository: /Users/nsicad/Documents/Work_1new/OTB/build Cannot find UpdateCommand configuration key. CMake Error at otb.cmake:106 (file): file Internal CMake error when trying to open file: /CMakeCache.txt for writing. SetCTestConfiguration:BuildDirectory:/Users/nsicad/Documents/Work_1new/OTB SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB/build Cannot instantiate test handler ctest_configure CMake Error at otb.cmake:107 (ctest_configure): ctest_configure CMakeLists.txt file does not exist [/Users/nsicad/Documents/Work_1new/OTB/build/CMakeLists.txt] CMake Error at otb.cmake:108 (ctest_read_custom_files): ctest_read_custom_files called with incorrect number of arguments SetCTestConfiguration:MakeCommand:/usr/bin/make -j8 -i -k SetCTestConfiguration:BuildDirectory:/Users/nsicad/Documents/Work_1new/OTB SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB/build Build project MakeCommand:/usr/bin/make -j8 -i -k Cannot create directory /Testing/Temporary Cannot create log file: LastBuild.log Cannot create build log file Run command: "/usr/bin/make" "-j8" "-i" "-k" Each symbol represents 1024 bytes of output. '!' represents an error and '*' a warning. !make: *** No targets specified and no makefile found. Stop. Size of output: 0K Command exited with the value: 2 Current Tag empty, this may mean NightlyStartTime / CTEST_NIGHTLY_START_TIME was not set correctly. Or maybe you forgot to call ctest_start() before calling ctest_configure(). Cannot create build XML file Error in read script: /Users/nsicad/Documents/Work_1new/OTB/otb.cmake Nolis-MacBook-Pro:OTB nsicad$ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Hi, First please change the CTEST_SITE variable in the script (put something as "noli" or whatever), otherwise you will overwrite my submissions to [1]. It seems like you have internet access issue (see errors at the end of the script, maybe missing "http_proxy" env var) so your build results did not get to the dashboard this time... Also please change "ctest_start(Nightly)" to "ctest_start(Experimental)". About your gdal issue, look in the script for the section where GDAL* variables are set : GDALCONFIG_EXECUTABLE:FILEPATH=/opt/local/bin/gdal-config GDAL_CONFIG:FILEPATH=/opt/local/bin/gdal-config GDAL_INCLUDE_DIR:STRING=/opt/local/include GDAL_LIBRARY:FILEPATH=/opt/local/lib/libgdal.dylib And customize this to match William's framework. Maybe it's just about changing "/opt" (macport install location) to "/usr/local" (William's framework location) You have to find where the "gdal-config" executable is on your system. Do the same for GEOTIFF*, TIFF* and JPEG* variables. For the other ones (EXPAT, CURL) cmake shall find the OSX version itself. Julien [1] http://dash.orfeo-toolbox.org/index.php?project=OTB Le 29/08/2012 10:26, Noli Sicad a écrit : Hi Julien, OK. Check the cmake variables and verify they point to actual directories. You are getting this error since the cmake variable you are using are not defined. I inserted this: SET (CTEST_BINARY_DIRECTORY "/Users/nsicad/Documents/Work_1new/OTB/build") I got gdal problem as well (see logs below). Thanks. Noli ### Nolis-MacBook-Pro:OTB nsicad$ ctest -S otb.cmake -VV * Extra verbosity turned on Reading Script: /Users/nsicad/Documents/Work_1new/OTB/otb.cmake SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB SetCTestConfiguration:BuildDirectory:/Users/nsicad/Documents/Work_1new/OTB/build Run dashboard with model Nightly Source directory: /Users/nsicad/Documents/Work_1new/OTB Build directory: /Users/nsicad/Documents/Work_1new/OTB/build Reading ctest configuration file: /Users/nsicad/Documents/Work_1new/OTB/CTestConfig.cmake SetCTestConfigurationFromCMakeVariable:NightlyStartTime:CTEST_NIGHTLY_START_TIME SetCTestConfiguration:NightlyStartTime:20:00:00 CEST SetCTestConfigurationFromCMakeVariable:Site:CTEST_SITE SetCTestConfiguration:Site:leod.c-s.fr SetCTestConfigurationFromCMakeVariable:BuildName:CTEST_BUILD_NAME SetCTestConfiguration:BuildName:MacOSX10.8-Release Site: leod.c-s.fr Build name: MacOSX10.8-Release Determine Nightly Start Time Specified time: 20:00:00 CEST Use Nightly tag: 20120828-1800 SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB SetCTestConfigurationFromCMakeVariable:HGCommand:CTEST_HG_COMMAND SetCTestConfiguration:HGCommand:/usr/local/bin/hg SetCTestConfigurationFromCMakeVariable:HGUpdateOptions:CTEST_HG_UPDATE_OPTIONS SetCTestConfiguration:HGUpdateOptions:-C SetCTestConfiguration:BuildDirectory:/Users/nsicad/Documents/Work_1new/OTB/build SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB Updating the repository: /Users/nsicad/Documents/Work_1new/OTB Use HG repository type Old revision of repository is: 0bbc4e4c5374 New revision of repository is: 0bbc4e4c5374 Gathering version information (one . per revision): SetCTestConfiguration:BuildDirectory:/Users/nsicad/Documents/Work_1new/OTB/build SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB SetCTestConfiguration:ConfigureCommand:"/Applications/CMake 2.8-8.app/Contents/bin/cmake" "-GUnix Makefiles" "/Users/nsicad/Documents/Work_1new/OTB" SetCTestConfiguration:BuildDirectory:/Users/nsicad/Documents/Work_1new/OTB/build SetCTestConfiguration:SourceDirectory:/Users/nsicad/Documents/Work_1new/OTB Configure project Configure with command: "/Applications/CMake 2.8-8.app/Contents/bin/cmake" "-GUnix Makefiles" "/Users/nsicad/Documents/Work_1new/OTB" Run command: "/Applications/CMake 2.8-8.app/Contents/bin/cmake" "-GUnix Makefiles" "/Users/nsicad/Documents/Work_1new/OTB" Each . represents 1024 bytes of output .-- The C compiler identification is GNU 4.2.1 -- The CXX compiler identification is GNU 4.2.1 -- Checking whether C compiler has -isysroot -- Checking whether C compiler has -isysroot - yes -- Checking whether C compiler supports OSX deployment target flag -- Checking whether C compiler supports OSX deployment target flag - yes -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Checking whether CXX compiler has -isysroot -- Checking whether CXX compiler has -isysroot - yes -- Checking whether CXX compiler supports OSX deployment target flag -- Checking whether CXX compiler supports OSX deployment target flag - yes -- Check for working CXX compiler: /usr/bin/g++ -- Check for working CXX compiler: /usr/bin/g++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX comp
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Hi, Le 29/08/2012 11:22, Noli Sicad a écrit : Hi Julien, Yes, I will do these things that you mentioned below. Meanwhile, I just test William's script with some addtion for the GDAL. Here is part of the logs. Nolis-MacBook-Pro:build nsicad$ cmake -D CMAKE_INSTALL_PREFIX=/usr/local -D CMAKE_BUILD_TYPE=MinSizeRel -D CMAKE_OSX_ARCHITECTURES="x86_64" -D CMAKE_OSX_DEPLOYMENT_TARGET="10.8" -D CMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.8.sdk" -D OTB_WRAP_QT=OFF -D OTB_WRAP_JAVA=OFF -D OTB_WRAP_PYTHON=OFF -D BUILD_APPLICATIONS=ON -D OTB_USE_VISU_GUI=OFF -D GDALCONFIG_EXECUTABLE:FILEPATH=/Library/Frameworks/GDAL.framework/unix/bin/gdal-config -D GDAL_CONFIG:FILEPATH=/Library/Frameworks/GDAL.framework/unix/bin/gdal-config -D GDAL_INCLUDE_DIR:STRING=/Library/Frameworks/GDAL.framework/unix/include -D GDAL_LIBRARY:FILEPATH=/Library/Frameworks/GDAL.framework/unix//lib/libgdal.dylib -D TIFF_LIBRARY=/Library/Frameworks/UnixImageIO.framework -D GEOTIFF_LIBRARY=/Library/Frameworks/UnixImageIO.framework -D JPEG_LIBRARY=/Library/Frameworks/UnixImageIO.framework -D USE_OPENMP=OFF -D CMAKE_INSTALL_NAME_DIR=/usr/local/lib/otb .. -- Repository status : -- Mercurial version is 2.3 -- Repository revision is 0bbc4e4c5374 -- No files modified locally -- Importing GDAL... -- Found GDAL: /Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib -- GDAL includes : /Library/Frameworks/GDAL.framework/unix/include -- GDAL library : /Library/Frameworks/GDAL.framework/unix/lib/libgdal.dylib -- GDAL version is 1.9.1 -- Testing if GDAL has tiff-- no -- Testing if GDAL has geotiff -- no -- Testing if GDAL has jpeg-- no -- Testing if GDAL has OGR -- yes -- Performing Test CHECK_GDALOPEN_SYMBOL -- Performing Test CHECK_GDALOPEN_SYMBOL - Failed CMake Warning at CMake/ImportGdal.cmake:210 (MESSAGE): CHECK_GDALOPEN_SYMBOL test failed : your platform exhibits a gdal/geotiff conflict. This is a test which fails on some linux distros (ubuntu/debian). I've never seen it fail on a Mac. And as William's framework is built with external geotiff, this should not fail. Might be a missing DYLD_LIBRARY_PATH (the test actually runs an executable during configuration). Anyway, proceed further with the compilation. It should be ok, this is just a warning. William, what is it the GDAL have this nos e.g. -- Testing if GDAL has tiff-- no -- Testing if GDAL has geotiff -- no -- Testing if GDAL has jpeg-- no This is OK. It means gdal does not exposes tiff and geotiff symbols. This does not mean gdal does not have the tiff/jpeg driver. Julien ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Hi ! Le 30/08/2012 04:41, William Kyngesburye a écrit : On Aug 29, 2012, at 9:18 PM, Noli Sicad wrote: Hi William and Julien, This one does not work. -D GDAL_CONFIG=/Library/Frameworks/GDAL.framework/Programs/gdal-config I guess GDAL_CONFIG is the wrong option ## However, this one works with still no support. -D GDALCONFIG_EXECUTABLE:FILEPATH=/Library/Frameworks/GDAL.framework/Programs/gdal-config and GDALCONFIG_EXECUTABLE is the correct one. Please set both for the moment. I don't remember why there are two variables for the same thing. I'll try to clarify that in the next OTB release and keep only one variable, and make FindGDAL.cmake recognize William's framework automagically. We are currently using the default FindGDAL provided by cmake. Anyway, I just make and make install. I wonder how important is support for Tiff, GeoTiff, JPEG in GDAL affects OTB. As Julien mentioned, this is just testing whether GDAL has TIFF/GeoTIFF/JPEG *libraries* built into it and exposed as libraries. It does not mean GDAL does not support these formats. I don't think you can build GDAL without these formats in the first place. OK, needs some clarification too, I agree the message is not clear enough. No need to do that - OTB has an internal copy, see your cmake log: -- Importing ITK... -- Using ITK internal version Actually, OTB cannot build with external ITK version in its current state. The only thing we really need as external library is GDAL, which you get from William's framework. For the rest, default system libraries should be ok (expat, curl...), and internal version for the rest is ok too. Julien ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Sextante - OTB plugin and SAR data in Mac OS X
Hi again, Le 30/08/2012 08:55, Noli Sicad a écrit : Do I need to run some of these binaries to get the SEXTANTE OTB Plugin working. Yes that is what Sextante/OTB uses. Better check first that you have installed everything properly, and can actually process some images with it. Then in Sextante configuration, you should set : -"OTB command line tools" option to CMAKE_INSTALL_PREFIX/bin -"OTB applications folder" option to CMAKE_INSTALL_PREFIX/lib/otb What file (python file?), I am looking to see these parameters? No, in the menu Analysis->Sextante option and configuration Julien ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
