[Qgis-developer] API docs webpage Forbidden
Hi. I urgently need to use the head API doc (I need it for a 1.4 compliant plugin) but the web page shows a Forbidden message. Is there any mirror, or will it be solved soon? Thanks, Giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] API docs webpage Forbidden
Well done, thx. 2010/9/27 Jürgen E. j...@norbit.de: Hi Tim, On Mon, 27. Sep 2010 at 11:06:54 +0200, Tim Sutton wrote: Macho web folks - can we host this in our vm too? Done. I included the doxygen run in the debian nightly build script. The documentation is available on http://qgis.org/api now. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ 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] fake GPS
gpsfeed+ can sends output to a serial port. I suppose you could use a COM port redirector, like a null-modem emulator like [1], to pipe the output port into an input one. giovanni [1] http://sourceforge.net/projects/tty0tty/ 2010/10/1 Paolo Cavallini cavall...@faunalia.it: Il 01/10/2010 16:22, Norman Vine ha scritto: There are several open source gps simulators available for example http://gpsfeed.sourceforge.net/ yes, but this is through IP, and AFAICT the QGIS tool requires a serial connection. thanks. -- Paolo Cavallini: 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: [Qgis-developer] Raster providers
Thanks Radim! That was a feature I hoped to see since the first time I saw Qgis :) I'm going to check it out rigth now. giovanni 2010/11/5 Radim Blazek radim.bla...@gmail.com: Hi, I have created new branch 'raster-providers' for true raster providers support development which is my main task for the upcoming hackfest. It is not yet ready for testing. I have only submitted some initial work for passing data for rendering from providers to raster layer. I will appreciate, if you avoid changes in raster area in this period to make later merging easy. It involves especially src/app/qgsrasterlayerproperties.cpp src/core/raster/qgsrasterlayer.cpp src/core/raster/qgsrasterlayer.h src/core/raster/qgsrasterviewport.h src/core/qgsrasterdataprovider.cpp src/core/qgsrasterdataprovider.h src/providers/grass/ src/providers/wms/ Radim ___ 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] Raster providers
No problem Radim. I think having a rasterprovider layer is of big interest to be able to bind other kind of raster sources (i.e. VTK). What about GDAL? It's 'hard-coded' inside the rasterlayer, but I suppose it will become a raster provider implementation. Isn'it? 2010/11/5 Radim Blazek radim.bla...@gmail.com: I appreciate your interest, but as I said, it is not usable at the moment, with a lot of luck you can display GRASS integer map, but you have to set min/max manually to get reasonable colors. Radim On Fri, Nov 5, 2010 at 10:08 AM, G. Allegri gioha...@gmail.com wrote: Thanks Radim! That was a feature I hoped to see since the first time I saw Qgis :) I'm going to check it out rigth now. giovanni 2010/11/5 Radim Blazek radim.bla...@gmail.com: Hi, I have created new branch 'raster-providers' for true raster providers support development which is my main task for the upcoming hackfest. It is not yet ready for testing. I have only submitted some initial work for passing data for rendering from providers to raster layer. I will appreciate, if you avoid changes in raster area in this period to make later merging easy. It involves especially src/app/qgsrasterlayerproperties.cpp src/core/raster/qgsrasterlayer.cpp src/core/raster/qgsrasterlayer.h src/core/raster/qgsrasterviewport.h src/core/qgsrasterdataprovider.cpp src/core/qgsrasterdataprovider.h src/providers/grass/ src/providers/wms/ Radim ___ 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] REST services
I've given a look to the qgisrest plugin. When a text/plain response is given it tries to parse it as GeoJSON. Arcgis doesn't follow this standard, that's why you won't be able to use the returned object. Anyway, you could easily add support for it, implementing your own Format for qgisrest [1] giovanni [1] http://svn.reprojected.com/qgisplugins/trunk/qgisrest/vectorformats/Formats/ 2010/11/10 G. Allegri gioha...@gmail.com: Hi. As you know rest services are generics, and the semantics of arcgis server rest services responses must be known to parse them. The rest plugin, as far as I see, are generics too. You can easily query an arcgis service (i.e. rest/services/your_service/MapServer?f=pjson) and you simply receive the json response, but then you aren't able to use it to load the listed features in qgis. The arcgis rest services also permit to request an image response. The same as above, it doesn't follow any standard format, so the answer (afaik) is no, you can't load arcgis rest services response (neither vectors nor images) on Qgis. Maybe others have experimented with it... giovanni 2010/11/10 Aigars V aiga...@gmail.com: Hi. Is there a possibility to add ArcGIS REST services (ArcGIS Map service) to QGIS. There is a plugin - QGISRest (with lack of some documentation), but it looks that it works only to list info about this service but not to add any data ? Any suggestions ?? Thanks. ___ 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] REST services
Hi. As you know rest services are generics, and the semantics of arcgis server rest services responses must be known to parse them. The rest plugin, as far as I see, are generics too. You can easily query an arcgis service (i.e. rest/services/your_service/MapServer?f=pjson) and you simply receive the json response, but then you aren't able to use it to load the listed features in qgis. The arcgis rest services also permit to request an image response. The same as above, it doesn't follow any standard format, so the answer (afaik) is no, you can't load arcgis rest services response (neither vectors nor images) on Qgis. Maybe others have experimented with it... giovanni 2010/11/10 Aigars V aiga...@gmail.com: Hi. Is there a possibility to add ArcGIS REST services (ArcGIS Map service) to QGIS. There is a plugin - QGISRest (with lack of some documentation), but it looks that it works only to list info about this service but not to add any data ? Any suggestions ?? Thanks. ___ 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: Raster providers
Yes, it is. I've told the same to the Geotools guys ;) Nice because during holidays you remembered me about the approach Mapserer uses, and again I was wondering if it will ever be abopted in Geotools... Here it is :) giovanni 2011/1/10 Martin Dobias wonder...@gmail.com On Mon, Jan 10, 2011 at 9:49 AM, Radim Blazek radim.bla...@gmail.com wrote: Hi Marco, the code is quite ugly at moment, I still keep old pieces of code commented. Regarding the reprojection, I would like to implement the approximate reprojection (similar to mapserver you showed me) in QgsRasterDataProvider::readBlock and overwrite it only in WMS provider. GDAL warp is too slow (as expected) and no way to speed it up AFAIK. Btw. today GeoTools/GeoServer guys published a blog post about improving raster reprojection speed: http://geo-solutions.blogspot.com/2011/01/developers-corner-improving.html There's also a link to a more verbose 35-page tech report on this matter. From a brief look it's the same approach as used in MapServer. Martin ___ 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: Raster providers
What about an approach where the out-of-bound values are assigned the last value only if reprojection is used (and if the layer does not have a null value)? My two cents, from a user perspective. We're facing this dilemma with Geotools, where reprojected color mapped rasters (thorugh SLD) result with borders having the lower color from the SLD rastersymbolizer. This is a big problem for many users, and we have to reproject the raster before serving it. It would be very important to be able to manage nodata values for out-of-border pixels, to be able to manage transparency and avoid those ugly borders... giovanni 2011/1/18 Marco Hugentobler marco.hugentob...@sourcepole.ch Agreed, int to double conversion could be optimal. oops, that should be 'Agreed, int to double conversion could be problematic' Am Dienstag, 18. Januar 2011, um 09.19:23 schrieb Marco Hugentobler: I thought that if data type of the source is integer the provider could represent them as floating point. Byte can be represented as integer. Bad solution however. Agreed, int to double conversion could be optimal. This would be quite similar to your current approach, except that people will have the appropriate raster appearance if they don't use reproj. And if they do, they have an undesired border, but still the right colors in the raster area. Regards, Marco Am Montag, 17. Januar 2011, um 17.34:22 schrieb Radim Blazek: On Mon, Jan 17, 2011 at 10:06 AM, Marco Hugentobler marco.hugentob...@sourcepole.ch Using NaN sounds like a good idea and Qt has platform independent support for it (qIsNan co.). All other solutions I can think of seem to be more complicated (e.g. force a transparency value only if raster is reprojected). float + NaN for byte/int? This is not clear to me. Could you explain your approach for byte/int? I thought that if data type of the source is integer the provider could represent them as floating point. Byte can be represented as integer. Bad solution however. Radim -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ 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 in Win XP
If you're able to build QGis, you're able to build the plugins too, as QGis has already builtin plugins. Have a look to this folder [1]. My first trial was create a new folder in my project (in VS I mean) and setup the same structure of the other plugins. Giovanni [1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/plugins 2011/2/4 maaza mekuria sail...@yahoo.com I am repeating my question since it may not be , is it possible to build a plugin using WinXP and Visual Studio 2008 (I assume it is)? And is there any documentation on that? Or should one copy another plugin from the trunk and try to adopt it? Or should one resort to QT only for plugin development? Thank you, Maaza --- On *Thu, 2/3/11, maaza mekuria sail...@yahoo.com* wrote: From: maaza mekuria sail...@yahoo.com Subject: [Qgis-developer] plugin development in Win XP To: qgis-developer@lists.osgeo.org Date: Thursday, February 3, 2011, 7:24 PM I am struggling to build a plugin in QGIS. I was able to build the source and I could run QGIS. But I can not create a plugin. I tried to follow Dr. Marco Hugentobler's example from the compilation guide and since it is linux based I could not duplicate it in the windows env. no matter how I try to compile the sample I get one error after another. Right now the error message below is the latest one. Can any of you offer some direction? 1C:\SW\Src\qgis-trunk\src\gui\qgisinterface.h(54) : error C2470: 'QgisInterface' : looks like a function definition, but there is no parameter list; skipping apparent body 1c:\sw\src\qgis-trunk\src\core\qgis.h(32) : error C2470: 'QGis' : looks like a function definition, but there is no parameter list; skipping apparent body Maaza -Inline Attachment Follows- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.orghttp://mc/compose?to=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] Re: [saga-gis-developer] saga - qgis interface
It's a project we were thinking about a couple of years ago, but the project has stopped (we've had to move the founds to other projects) The approach was similar to yours, but I was thinking to a lower level binding: let saga odules read directly from Qgis in memory data structures, without having to import/export data. In the latter case our doubt was: if we have to do that we already have the saga gui! We didn't see the gain in having a qt module... other than having to open saga gis. I haven't investigated this too much, and maybe it's a lot of work to do it (C++ code to be written, etc.), but it would give a great value to such a module. Don't you think? Anyway, the first steps of having a python gui interface to saga-api is certainly foundamental. giovanni 2011/2/17 Johan Van de Wauw johan.vandew...@gmail.com On Thu, Feb 17, 2011 at 1:27 AM, Volker Wichmann wichm...@laserdata.atwrote: Hi Gianluca, My idea is to write a python code that will generate GUI dialogs completely on the fly without any hard coded parameter flags or .py files (SAGA has about 500 modules!). That is, you have a path where your SAGA modules (.so/.dll) reside and then your QGIS GUI will use the saga_api to generate the dialogs for the available modules on the fly. As far as I see, all you need is the following information: * module library name * module name * module (saga_cmd) parameter names * module parameter types That seems the best approach to me as well. I've attached a script which creates a saga_cmd call for most modules, which I once used to check if there are any obvious errors/memory leaks. As mentioned before, this script is the first thing I wrote in python, so sorry for any strange unnecessary constructions and/or errors, but it should give you an idea how to browse through the module libraries, modules and their parameters. All you would need is a generic python module which would generate the dialogs for QGIS using the saga_api on the fly and another python module which would use the information entered in these QGIS dialogs to call saga_cmd. But maybe I'm getting this wrong. Prior to jumping towards dialogs, perhaps it is useful to think about how you want to integrate saga and qgis: * how are module libraries and modules presented? In a menu or some type of module library? * which qt interface would you like to use to present the different type of parameters that saga has. This is really an important decision. I personally think that the way saga relies heavily on wxpropgrid to generate its interfaces is really nice. Someone who knows qt well may give some advice here what the best approach would be. If some kind of property grid is already used in qgis, I would certainly look to that. I really think this is one of the most important decisions - some modules have a lot of different parameters (eg [2]) and presenting them in an orderly way is quite a challenge. * which types of modules would you like to provide first? Shape or grid based modules? * how do you handle file conversions? Eg a geotiff is open in qgis. Prior to running this module, it will have to be converted to a .sgrd file (can be done with gdal)? In fact, if I would be starting this project, I would use this approach: 1. Create some type of menu/module library to show the saga modules 2. If these are opened show a very basic window showing a generated command line and a html box with the documentation of the module (eg [2]). At that point, you actually have nothing more than a nice way to browse through the saga modules from qgis, without any integration. But it offers a starting point. 3. If a good approach is found to generate the kind of property grid, you could switch to having a text box per parameter type. In a next step, some options may be converted to better suited interfaces, eg showing a list of grids present in qgis. At this point, I think development can be done by different people: someone is working on an interface for shapefiles, someone else on file conversion issues/... At this point, knowledge of the saga api is less important, and most work is done in python/qt. [1] http://www.saga-gis.org/saga_api_doc/html/parameters_8h.html#005312577c5ba61839e45f6a19b94218 [2] http://www.saga-gis.org/saga_modules_doc/grid_analysis/grid_analysis_19.html ___ 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?
Maaza, I think your approach doesn't help to give you a hand. The community cannot supply you the *time* you should invest in trying and, maybe, learning the necessary basics to do what you need. You shoud try and try and the, eventually, ask about things that go wrong. QGis plugins are C++, with some macros defined by Qt. Nothing more, nothing less (am I wrong?). If you're able to compile C++ code in Visual Studio, you don't need to rely on Cmakelist. It can help, because it makes a lot of work for you, and you can be inspired by other plugins. But you also can build and link the usual way. Have you read the QGIS Coding and Compilation Guide [1]? giovanni [1] http://download.osgeo.org/qgis/doc/manual/qgis-1.6.0_coding-compilation_guide_en.pdf 2011/2/18 maaza mekuria sail...@yahoo.com Can it be possible to create a minimalist plugin using c++ in Windows Visual C++ Express without using all the bells and whistles that are in the other plugins such as CMakelists? Your help may make a difference between using Python and C++. I was able to copy a Python plugin and easily adopt it to my own version of a plugin. I was able to add and remove GUI items by just editing the UI file. I want to do something similar using C++. Is it impossible for a new comer? Do I need a Computer Science degree to? But it should not be as they say Rocket science to write a little function. I promise if I get it to work, I will share it with those who are suffering the famine for information. I am not sure why there is lack of documentation on such a simple matter or may be it is not simple or it is esoteric because it is highly dependent on many secret doors and passageways. I confess my stubbornness to use C++ is due to the type of work being a bit intensive and I also have already a C++ code for it and I just need a nicer interface and data store that is free as in Free Chai inside QGIS. Anybody there listening to the call from QGIS (Quiet or Slow GIS) desert? Maaza ___ 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] PostGIS enhancements
The development version of QGIS, due shortly, is bringing us several I suppose you mean Postgis... giovanni important new features (see eg [0]). In particular, 3D and raster support. I know of the work being done on raster support through a plugin (which should be integrated in PostGIS manager IMHO), but I'm not aware of any work being done on supporting 3D features and functions directly. Is there anybody working on this, or planning to? All the best. -- http://www.faunalia.it/pc [0] http://www.postgis.us/downloads/ncgis2011/NCGISSDBPostGIS20_2011.pdf ___ 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] Raster on the fly
I can confirm the r15416 fixed that problem (windows 7 32bit). I'm doing test on a 21698x24674 ArcInfo Binary Grid raster. It took minutes to load, and several seconds for each pan/zoom... giovanni 2011/3/10 Jürgen E. j...@norbit.de Hi Radim, On Thu, 10. Mar 2011 at 11:21:48 +0100, Radim Blazek wrote: 32 or 64bit? If 64, could somebody test also 32bit? We don't have 64bit builds on Windows (at least I don't). Anyway, r15416 might fix the issue. Looks like mCoordinateTransform was deleted twice. One time just after the QgsRasterProjector was copied to myProjector and another time when myProjector went out of scope. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-20 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ 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] Raster providers
Radim, the round() you added in qgsgdalprovider causes problems for me on VC++ ( http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L664 ). Should we add something like: #define round(dbl) dbl = 0.0 ? (int)(dbl + 0.5) : ((dbl - (double)(int)dbl) = -0.5 ? (int)dbl : (int)(dbl - 0.5)) ? 2011/3/10 Radim Blazek radim.bla...@gmail.com I fact, I forgot to write a piece of logic, there is a shift. Radim On Thu, Mar 10, 2011 at 8:13 PM, Radim Blazek radim.bla...@gmail.com wrote: I have changed how GDAL provider reads the data, it should be fast again. BUT! I am not absolutely sure that resampling is perfect and the nearest neighbour is alway nearest. I dont think however that anybody could notice that in normal work. I would appreciate however if somebody with fresh brain could check the alignment fiddling. http://trac.osgeo.org/qgis/browser/trunk/qgis/src/providers/gdal/qgsgdalprovider.cpp#L529 More pointers - more crashes expected! Radim On Wed, Mar 9, 2011 at 8:30 PM, Giovanni Manghi giovanni.man...@gmail.com wrote: Hi, On Tue, 2011-03-08 at 20:17 +0100, Radim Blazek wrote: Merged to trunk. I'm testing the new raster capabilities of QGIS and I would like to have your opinion on a certain matter before eventually filing a ticket. I have a bunch of big tiff rasters ( 1gb, sometimes 2gb), with internal tiles and/or overviews. What I'm seeing is that now those rasters take quite a *lot* (making qgis not responsive for a while) to be rendered, before the merge it was all much quicker. As exemple: on QGIS 1.6 a 1.7gb geotiff with tiles and overviews opens in (more or less) 1 sec., in trunk now takes (more os less) 1 minute! After the raster show in the canvas, also opening its properties take a long time. Before the merge was immediate. Zooming and panning it is also much slower than before the merge. Overall it seems like that tiles and overviews are ignored or not read., but to me seems that also opening big tiffs ( 1gb) without internal tiles and/or overviews takes a *lot* more than before the merge. anyone experiencing the same? 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] Re: [GRASS-user] GRASS plugin
Furthermore, 52N is in java, which will make things only worse. Could you argue this sentence? Thanks, Giovanni In addition, this does not seem a short term solution, and I think we need something working smoothly *now*. All the best. -- Paolo Cavallini: 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: [Qgis-developer] SAGA Interface
I understand your point Paolo, and I can't contribute to C++ coding now, so I can't support it practically. But: - if Camilo can do it, he's welcome. I suppose he's conscious of what it means, also from a lon term support point of view... With GRASS module we have the same issues, am I wrong? - without a low-level interactions between QGis and SAGA, what is the real usefulness of this plugin? SAGA needs to be installed anyway (and it's easy), we already can import/export between the two's... Ok all the effort would be directed to avoid opening the SAGA interface. Mmm, I don't see such a great gain to justify the effort. Just two cents to share opinions. I'm just wondering giovanni 2011/3/31 Paolo Cavallini cavall...@faunalia.it On Wed, 30 Mar 2011 20:31:14 -0400, Camilo Polymeris cpolyme...@gmail.com wrote: Thanks for your comment. For those reasons and the ones I mentioned in the original mail, I think I'll be going the C++ route. Sorry to insist, but I think this is not a good choice. We already had experiance with several non-core C++ plugins, some of them extremely useful, and all of them are essentially unavailable to users. On the other hand, it is probably unfeasible to add a dependency on SAGA. The single argument that seems to favour Python is the greater availability of coders. Giovanni and Gianluca have responded to this mail saying they would work on a Python version. No other C++ coders interested, yet :( This should mean something, even though it is not the crucial issue. All the best. -- http://faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
You're right Camilo, python-saga bindings are available in source, as ready-to-use batch commands (saga_api_to_python_linux.sh and saga_api_to_python_win.bat): http://saga-gis.svn.sourceforge.net/viewvc/saga-gis/trunk/saga-gis/src/saga_core/saga_api/) to compile them through SWIG It means we have to provide them along the QGis-SAGA plugin by ourselves giovanni http://saga-gis.svn.sourceforge.net/viewvc/saga-gis/trunk/saga-gis/src/saga_core/saga_api/ 2011/3/31 Camilo Polymeris cpolyme...@gmail.com Sorry to insist, but I think this is not a good choice. We already had experiance with several non-core C++ plugins, some of them extremely useful, and all of them are essentially unavailable to users. On the other hand, it is probably unfeasible to add a dependency on SAGA. What I don't understand is: we'd have the same problems using python. There are, as far as I know, no Python-saga packages. Debian's libsaga[2], for instance, does *not* include python bindings. That means we'd have to compile ship the python-saga binding ourselves, anyway. Or am I missing something? Are you, Gianluca, using the command-line interface to saga or the python bindings? That former is very interesting as a compile-free option, but ultimately is limited to certain tasks and to having saga_cmd installed. Both options (command line and API) are not exclusive. Regards, Camilo [2] http://packages.debian.org/squeeze/amd64/libsaga/filelist ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SAGA Interface
I was out yesterday, and I'm glad to see how things are going on! Camilo, I've browsed your repo but I can't find the parts where saga_cmd is being called... I suppose I missed some files. The python road is way more easy to develop and mantain, of course. I only fear dealing with large datas, where import/export and back could be an issue... But ok, don't make things complex befaure the time. It can be a further improvement in case it required. have a good sunday, giiovanni 2011/4/3 Camilo Polymeris cpolyme...@gmail.com GUI: Any ideas? So far I think I'll just clone SAGA's. I think it would be good if you could follow either the GdalTools or the GRASS plugins approach. Here is a screenshot of what it looks right now: www.udec.cl/~cpolymeris/QGIS_Screenshot_04032011.png You think that's a good direction? Needs a lot of polish, of course. Should the dialog be modal? 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] SAGA Interface
About large files: I'm just worried by the overhead with data export and import between QGis and SAGA. That's why I was interested in a low level data structure binding between the two environments. But as I've said, it can be an improvements eventually, in case it will really result to be an issue... I hope your GSoC proposal will be accepted! I'm an earth scientist too (geologist), and I'm going thorugh the same way of you: passion for IT and OSS, and programming. Now I would like some more earth back in my daily work, but we can't have eveything! :) So good luck Camilo! I will support this project as much as I can. I don't have founded projects in this moment for that, but I will be happy to spare some of my free time on it. Back to the module. Are we sure that offering two options (with or without saga_api) is feasible? I mean from the point of view of the effort. Probably you have already investigated this... I was also wondeing about two points: - should the plugin accept only layers previously loaded in QGis? This is the way Sextante works inside Gvsig (I suppose you know it). It enables only the plugins that accept the type of layer actually loaded (eg, vector inputs, raster inputs, etc.). Another possibility is to let the user choose wether to use a layer already loaded or browse for it on the filesytem (or db, etc.). - would you provide the saga-python module with the plugin? We could offer it, specifying wich version of SAGA it was been built for, to help those users which can't build the plugin by their own... See you, giovanni 2011/4/3 Camilo Polymeris cpolyme...@gmail.com Hello OSgeo I have submitted a Google Summer* of Code student proposal to continue work on the SAGA to QGIS plugin I started coding. It is available through the GSoC page [3]. Any comments are welcome, (and mentors, too :) Regards, Camilo [3] http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/polymeris/1001 * boreal ___ 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
Wow Mohammed, that would be great! Orfeo Toolbox [1] is one of the most powerful and full-fledged image analysis libraries I've seen around. I hope it will be accepted, good luck! giovanni [1] http://www.orfeo-toolbox.org/otb/ 2011/4/7 Mohammed Rashad mohammedrasha...@gmail.com 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
[Qgis-developer] some notes on building SAGA and its python bindings under Windows (to test and use Qgis-SAGA plugin)
I sure some updated notes to compile SAGA and its Python APIs with VC 2008 Express. It skips some SAGA extensions, but it builds all the core and saga apis, both native and for Python. If you feel its usefull to help users to use the QGis-SAGA, you can use it and improve it... giovanni BUILDING SAGA WITH Visual Studio 2008 Express (2011).odt Description: application/vnd.oasis.opendocument.text ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: some notes on building SAGA and its python bindings under Windows (to test and use Qgis-SAGA plugin)
I've just realized that QGis uses Python 2.5, and it isn't possible (at least, straightforward/recomended) to build Python 2.5 extensions with VS 2008 (because Py 2.5 for Windows is being built with VS 2003). A solution is the use of MinGW... or recompile Qgis's Python support for version 2.6. giovanni 2011/4/11 G. Allegri gioha...@gmail.com I sure some updated notes to compile SAGA and its Python APIs with VC 2008 Express. It skips some SAGA extensions, but it builds all the core and saga apis, both native and for Python. If you feel its usefull to help users to use the QGis-SAGA, you can use it and improve it... giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: some notes on building SAGA and its python bindings under Windows (to test and use Qgis-SAGA plugin)
As soon as I find a minute for it, I will publish my experience on a wiki page (where? I will see...). The pages from SAGA to build it under Windows are a bit outdated, respect to the src contents. I will ask Conrad if it's possible to update them. In this case I can remove mine. giovanni 2011/4/13 Camilo Polymeris cpolyme...@gmail.com Hi Camilo. Could you please start a wiki page, accumulating the info so far? Thanks. Here is a short howto on building the SAGA Python API under linux: https://github.com/polymeris/qgis/wiki/How-to-install-the-SAGA-Pyton-API It is probably incomplete and my English is not the best, but it is a start. I don't have access to a Windows machine to test them for myself, but seems SAGA's website has decent instructions for that OS. I have inserted a link at the end of the wiki page. The rest of the wiki[1] is a collection of links to APIs and relevant discussions on lists/fora, mostly as a reference for myself. Regards, Camilo [1] https://github.com/polymeris/qgis/wiki/_pages ___ 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: some notes on building SAGA and its python bindings under Windows (to test and use Qgis-SAGA plugin)
On an unrelated note: Do you know if a particular python version is defined as target for QGIS plugins? I believe I read 2.3 somewhere, but can't find the source. I don't remember about a reference version. The Python libs shipped with Osgeo4w come from Python 2.5.2 Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: some notes on building SAGA and its python bindings under Windows (to test and use Qgis-SAGA plugin)
2011/4/13 G. Allegri gioha...@gmail.com On an unrelated note: Do you know if a particular python version is defined as target for QGIS plugins? I believe I read 2.3 somewhere, but can't find the source. I don't remember about a reference version. The Python libs shipped with Osgeo4w come from Python 2.5.2 PS: I hope they will be upgrated to 2.6 (at least). It would solve various problems, not only for Windows builds (VS 2008 express is free, otherwise MinGW is needed if one doesn't own a previous licensed compiler), but also for many third-party python libs which are going to be distributed only for Python 2.6 Camilo ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: MXD
2011/5/27 Sandro Santilli s...@keybit.net: On Fri, May 27, 2011 at 09:30:49AM +0100, Barry Rowlingson wrote: On Fri, May 27, 2011 at 2:06 AM, Noli Sicad nsi...@gmail.com wrote: Nice toolbox for ArcGIS to QGIS! Now, we can migrate all ArcGIS.mxd to QGIS.qgs. we? Only if you already have ArcGIS! :) Good point! Is the .mxd thing something portable ? And does the toolbox license allow it ? whar do you mean with portable? .mxd is a file project like .gqs. giovanni --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ 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 vs gvSIG
2011/6/23 jr.morre...@enoreth.net Is this fork going to stay in sync with gvsig's trunk or is it going its own seperate path ? I thought that after last year's talks about differences between your OA edition and the official (but not public) tree the situation would have improved. What are you referring to with the not public tree? Benjamin will answer officially, but the CE edition will try to keep the sync with the official trunk. At now the CE trunk contains a gvSIG 1.9 snapshot (the same of the OADE edition), but will be upgraded soon to gvSIG 1.11, which is the latest release. A critical moment will be the release of gvSIG 2.0, which will be a deep refactoring of the core code structure. When it will happen the development and maintanance forces should be split between the 1.1x series and the new... I cross my fingers! giovanni On Thu, 23 Jun 2011 09:21:25 +0100 (BST), Benjamin Ducke wrote: Hi Paolo (all) -- - Original Message - [SNIP] I didn't like their development model: AFAICT, there is a commercial association of all gvsig devs; this has a strong potential for a monopoly. That's precisely why a number of users and external developers, including myself, have now forked off the gvSIG Community Edition (CE). We are still in the process of building up the web infrastructure, but the mailing lists are already active and you can read up on progress in the list archives (the most active one is currently the community list): http://sourceforge.net/**projects/gvsigce/http://sourceforge.net/projects/gvsigce/ http://sourceforge.net/mail/?**group_id=343517http://sourceforge.net/mail/?group_id=343517 Cheers, Ben __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://lists.osgeo.org/mailman/listinfo/qgis-developer -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://lists.osgeo.org/mailman/listinfo/qgis-developer __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://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 vs gvSIG
Turning the discussion to a differences game there should be a lot to say, with pros and cons for both the softwares and communities. From my experience I would say that: - Qgis community processes are way much open then gvSIG. I think this depends on the fact that gvSIG was born with a public funding that has been won by a private agency (IVER company), and released as GPL. The result was a fast, black-box development that haven't given the right wieght to the community involvment. Many from the gvSIG community are aware that this has to be solved now, and while the TSC is working on this, others has chosen to fork it (fist as OADE and noe as CE) - gvSIG's (huge!) code base is changing quite rapidly, so some of its important extensions, provided by private companies, are not aligned to the latest release, and the next big refactoring (gvSIG 2.0) will need the extensions interface to gvSIG to be almost completely refactored. QGis API has reached much more stability, and this will help its maintance... - Two gvSIG pros: it's Java, so it's development is (from my point of view) easier then C++ for many power users and developers. And it's cross-platform. Ok, Java has its problems, we knoe, and it's under the Oracle brand. But I'm not sure Qt would make me sleep more relaxed... The second pro is that some of its features respond very well to some enterprise needs: Oracle Spatial works very fine, the Network extension (which needs to be updated now to the latest gvSIG) brings very good algorithms, the Sextante integration opens gvSIG to hundreds of processing algorithms and let users write scripts and models in an easy way... - Two QGis pros: the user experience is smoother then gvSIG's. I feel the UI more reactive and comfortable. The Python interface is powerful and permit everyone to write its own plugin easily, even if data processing can become unfeasible with big datas! But working at a lower level requires much more skills then Java... I think gvSIG commercial approach has lead to a bigger involvment of the private companies, bringing to the development of enterprise ready features (eg Oracle driver), so its approach is a double knife... Qgis is much more closer to the users, but it seems it hasn't been able (yet) to attract similar volumes of private companies in a virtuous process of collaboration to develop some of the features that makes gvSIG more acctractive for the enterprise level. There should be a lot more to write, but I stop here. I would like this cross project face to face discussion to continue. It can be of help for both the communities ;) giovanni 2011/6/23 Saber razmjoo...@faunalia.co.uk It now has turned into a gvsig mailing list :) From Qgis community's point of view, it will be great to absorb gvsig users and developers: Developers: qgis provides a more open approach to its development and its totally a community driven project. Users: qgis can potentially provide all the functions gvsig does. I have not used gvsig and can't say more about it. Paolo's email should be interpreted in ways qgis can be improved to replace gvsig. Both projects are free and open source but one is more! :) Cheers Saber jr.morre...@enoreth.net wrote: Is this fork going to stay in sync with gvsig's trunk or is it going its own seperate path ? I thought that after last year's talks about differences between your OA edition and the official (but not public) tree the situation would have improved. On Thu, 23 Jun 2011 09:21:25 +0100 (BST), Benjamin Ducke wrote: Hi Paolo (all) -- - Original Message - [SNIP] I didn't like their development model: AFAICT, there is a commercial association of all gvsig devs; this has a strong potential for a monopoly. That's precisely why a number of users and external developers, including myself, have now forked off the gvSIG Community Edition (CE). We are still in the process of building up the web infrastructure, but the mailing lists are already active and you can read up on progress in the list archives (the most active one is currently the community list): http://sourceforge.net/projects/gvsigce/ http://sourceforge.net/mail/?group_id=343517 Cheers, Ben ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information. ___ 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 for water
I'm very glad to know that some steps have been made to implement the OpenMI framework in Python. It will also help to share and integrate models with JGrass, which is OpenMI compliant too. I hope we will be able to read your full draft ;) Thanksm Giovanni 2011/6/27 Robert Szczepanek rob...@szczepanek.pl Hi Saber and Werner, I like this initiative, however an alternative to pure QGIS-oriented approach could be what I presented recently on GRASS meeting in Prague [1]. There is also brief pdf from presentation. I hope to present draft hydrological framework this Autumn. Concerning existing hydrological software and projects I found big diversity of solutions [2]. regards, Robert [1] http://geoinformatics.fsv.**cvut.cz/gwiki/Towards_open_** and_interoperable_**hydrological_libraryhttp://geoinformatics.fsv.cvut.cz/gwiki/Towards_open_and_interoperable_hydrological_library [2] http://openhydrology.org/**models http://openhydrology.org/models W dniu 27.06.2011 16:27, Saber Razmjooei pisze: Dear lists I have added a wiki page for hydrology and hydraulic (fluvial, coastal and urban drainage) modelling with QGIS: http://www.qgis.org/wiki/**Hydrology_%26_Hydraulic_**modelling#Hydraulicshttp://www.qgis.org/wiki/Hydrology_%26_Hydraulic_modelling#Hydraulics Feel free to add the software (proprietary or open source) you are using to carry out your water related modelling. Once we have a list, we can look into ways of developing plugins/tools to be able to use QGIS as platform to pre and post process GIS elements. Cheers Saber __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://lists.osgeo.org/mailman/listinfo/qgis-developer __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://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] Calling GRASS From a Python QGIS Script
The problem is probably related to the way the Subprocess module handles the
I/O inside the QGis python console. It's a problem I've read about various
times, and is specific of the Windows environemnt.
Two thread I recently read about this are [1] and [2], and both consider it
a Subprocess bug.
I hope to find some time to reproduce it...
giovanni
[1] http://bugs.python.org/issue3905
[2]
http://bytes.com/topic/python/answers/634409-subprocess-handle-invalid-error
2011/6/28 romain riviere romain.riviere@gmail.com
Hi all,
I'm using windows XP and QGIS 1.7 (classic installation, python 2.5, grass
6.4.1 ). My Goal is to create a QGIS plugin for complex network analysis
(TSP,steinman tree,...), using GRASS capabilities. It aims to be very
user-friendly, and cross-platform.
I'm trying to call GRASS from within a QGIS python plugin, but I get the
following error (python console module):
Code: (inspired by:
http://grass.osgeo.org/wiki/Working_with_GRASS_without_starting_it_explicitly
)
import os
import sys
gisbase = os.environ['GISBASE'] = r path to QGIS
sys.path.append(os.path.join(os.environ['GISBASE'], etc, python))
import grass.script as grass
Error:
import grass.script as grass
Traceback (most recent call last):
File input, line 1, in module
File C:/PROGRA~1/QUANTU~2/apps/qgis/./python\qgis\utils.py, line 283, in
_import
mod = _builtin_import(name, globals, locals, fromlist, level)
File C:\Program Files\Quantum GIS
Wroclaw\apps\grass\grass-6.4.1\etc\python\grass\script\__init__.py, line 1,
in module
from core import *
File C:/PROGRA~1/QUANTU~2/apps/qgis/./python\qgis\utils.py, line 283, in
_import
mod = _builtin_import(name, globals, locals, fromlist, level)
File C:\Program Files\Quantum GIS
Wroclaw\apps\grass\grass-6.4.1\etc\python\grass\script\core.py, line 1073,
in module
debug_level = int(gisenv().get('DEBUG', 0))
File C:\Program Files\Quantum GIS
Wroclaw\apps\grass\grass-6.4.1\etc\python\grass\script\core.py, line 514,
in gisenv
s = read_command(g.gisenv, flags='n')
File C:\Program Files\Quantum GIS
Wroclaw\apps\grass\grass-6.4.1\etc\python\grass\script\core.py, line 225,
in read_command
ps = pipe_command(*args, **kwargs)
File C:\Program Files\Quantum GIS
Wroclaw\apps\grass\grass-6.4.1\etc\python\grass\script\core.py, line 202,
in pipe_command
return start_command(*args, **kwargs)
File C:\Program Files\Quantum GIS
Wroclaw\apps\grass\grass-6.4.1\etc\python\grass\script\core.py, line 164,
in start_command
return Popen(args, **popts)
File C:\Program Files\Quantum GIS
Wroclaw\apps\grass\grass-6.4.1\etc\python\grass\script\core.py, line 55, in
__init__
startupinfo, creationflags)
File C:\PROGRA~1\QUANTU~2\apps\Python25\lib\subprocess.py, line 587, in
__init__
errread, errwrite) = self._get_handles(stdin, stdout, stderr)
File C:\PROGRA~1\QUANTU~2\apps\Python25\lib\subprocess.py, line 700, in
_get_handles
p2cread = self._make_inheritable(p2cread)
File C:\PROGRA~1\QUANTU~2\apps\Python25\lib\subprocess.py, line 745, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
WindowsError: [Error 6] The handle is invalid
I am pretty sure this is due to the Python Path, because the same code
works well in a classic python console (outside QGIS). But I'm not able to
resolve this issue. I haven't test yet, but I'm pretty sure it's working on
ubuntu.
Another Question:
Does anyone know how to import QGIS vector layer directly into GRASS ( as
v.in.ogr.qgis.loc from the GRASS Plugin)
Any help is welcome.
Romain,
*
*
___
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] Jython with QGIS
QGIS is written in C++, and supports (C)Python scripting. Even if a C++/Java binding is technically possible, IMHO it isn't a advisable. Natural softwares for Jyhon/Java development can be gvSIG, uDig, OpenJump, and the rest of the Java gfoss tools.. giovanni 2011/6/28 Ornélio Hinterholz Junior ohjrr2...@gmail.com ** Hi guys, Is there a way for developing in QGIS using Jython or Java? Thanks, Ornélio Hinterholz Junior ___ 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] Mu powerful kit to develop GUI-oriented, based on top of Python and Qt for QGIS plugin
Thanks Noli for the news... I hope to give it a look as soon as its hosting application will be working again. giovanni 2011/7/18 Noli Sicad nsi...@gmail.com Hi, I think this might be useful for creating GUI for Python QGIS plugins. Eric Jardim wrote: mu is a simple but powerful kit to develop GUI-oriented, based on top of Python and Qt. Code with Qt and Python with no boilerplates (it supports PyQt and PySide) * no pyuic * no connects/disconnects * no pyrcc * no compilation at all * clear and functional code * pure Python and Qt (no brands) * LGPL v3 licensing http://www.assembla.com/spaces/mu-dev 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] Native MS SQL 2008 Driver for QGIS
+1 for having these native spatial drivers. I don't know about MS SQL, for Oracle you cannot distribute the required proprietary lib, which is however freely downloadable from Oracle. In any case this is required by the OGR driver too. PS: The OGR Oracle driver is quite unusable at now. It's very slow, and Frank told me that it's because it was developed for specific requirements, and he's aware of the various potential improvements needed for a mor generic, fast, use... giovanni 2011/9/5 Paolo Cavallini cavall...@faunalia.it Il 05/09/2011 14:34, Marco Hugentobler ha scritto: I also think that a native QGIS provider (subclass of QgsVectorDataProvider) for MS SQL 2008 would be a great thing. The reason to go for a native driver Btw. a native oracle spatial provider would also be nice to have. Oracle spatial is (unfortunately) quite common here. I guess the main obstacle is with licencing: if QGIS has to be built against non-free libraries, the resulting object may have an hybrid licence, unsuitable for distribution. From a technical point of view, integration in the DB manager (and QGIS providers) Giuseppe is writing is IMHO the way to go. All the best. -- Paolo Cavallini: 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
[Qgis-developer] Qgis custom buil to read obfuscated data
I've been asked to create a custom qgis, to be distributed via CD/DVD along with some data (vector and raster) that should be only visible and usable thorugh the customized qgis and not by any other tool. Has somebody in this list ever had to manage this kind of obfuscation? giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qgis custom buil to read obfuscated data
@Sandro: it's a requirement I'm asked to implement, not an hypothesis to discuss. We can debate on the choice, but that's not my problem at now ;) @Niccolò: good point. Howevere one could write a non GPL piece of code (the minimum to keep the data undisclosable) and link qgis to it. Is it forbidden by GPL license? I don't think... 2011/9/15 Niccolo Rigacci nicc...@rigacci.org On Thu, Sep 15, 2011 at 12:14:37PM +0200, G. Allegri wrote: I've been asked to create a custom qgis, to be distributed via CD/DVD along with some data (vector and raster) that should be only visible and usable thorugh the customized qgis and not by any other tool. It will be an ineffective protection schema, by any means. Who will receive the custom QGIS has the right to get the sources too, and then the obfuscation schema on geodata is easly expolitable. -- Niccolo Rigacci Firenze - Italy Tel. ufficio: 055-0118525 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qgis custom buil to read obfuscated data
2011/9/15 Sandro Santilli s...@keybit.net On Thu, Sep 15, 2011 at 01:10:55PM +0200, G. Allegri wrote: @Sandro: it's a requirement I'm asked to implement, not an hypothesis to discuss. We can debate on the choice, but that's not my problem at now ;) Oh, I tought you was a free citizen, not a military. But wait, even the military can desert ! I'm a free citizen and I can refuse a contract, but this is not the point of my question Sandro. I've asked a technical opinion, not ethical. @Niccolò: good point. Howevere one could write a non GPL piece of code (the minimum to keep the data undisclosable) and link qgis to it. Is it forbidden by GPL license? I don't think... I think it is. Probably you're right. http://blog.milkingthegnu.org/2008/04/gpl-for-dummies.html --strk; () Free GIS Flash consultant/developer /\ http://strk.keybit.net/services.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] DB Manager release
Congratulations to all the developers. I've just seen the video and it looks really great! giovanni 2011/9/15 Paolo Cavallini cavall...@faunalia.it Hi all. Thanks to the hard work of Giuseppe Sucameli, the supervision of Martin Dobias, and the support of Google for its Summer of Code initiative, DB Manager is now available. DBManager's aim is to merge together some QGis DB plugins, e.g. PGManager, SLManager, RT_Sql_Layer. In this moment it works with both PostgreSQL and SQLite databases and it displays the list of tables, info about the selected table, table data and preview, but also allows to rename/delete tables through its GUI and run query on the selected database, so at this stage it replaces at all SLManager. Thanks to Mauricio De Paulo (mauriciodev), now DB Manager also supports PostGIS Rasters! The last DB Manager version has support to Import Vector Layer feature by drag'n'drop a layer from the QGis browser (or even DB Manager) to a database in the DBManager GUI. The Import Vector Layer feature allows to import/copy any vector layer QGis can load between different datasources, i.e. PostGIS/SpatiaLite databases and OGR files. It's available through the QgsVectorLayerImport class and it has just been merged in master branch. See [1] for an example of use. Faunalia is committed to support the development of this tool, and other DB plugin developers are welcome to join and merge their work, it this makes sense, to reduce confusion for users. Enjoy. [1] http://www.youtube.com/watch?v=bBe7WctSAXI -- Paolo Cavallini - Faunalia www.faunalia.eu See details at: www.faunalia.eu/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: [Qgis-developer] Qgis custom buil to read obfuscated data
Thanks for the brainstorming. I will bring the various usefull considerations to my collegues. I'll let you know about the policies that will be chosen, and consequently the road to achieve them. giovanni 2011/9/16 Martin Dobias wonder...@gmail.com On Fri, Sep 16, 2011 at 2:53 AM, John Patterson j...@henrygis.com wrote: I'd say that encryption is the answer here - hang the security on the key rather than the code. If the requirement is explicitly should be only visible and usable through the customized qgis and not by any other tool., then use GPG[1] or something[2] and add a File Load Encrypted Dataset dialog or some such. I would imagine this to be a reasonable solution. Even when the data is encrypted on disk, they are freely accessible within QGIS. The user has many opportunities how to access raw data: - save the layer to another format - copy all features to another layer - save the data in python console - save the data in a plugin Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgisMapserver - need to restart Apache on every project file change ?
I haven't found the time to setup a fresher qgismapserver, but looking at the source code in trunk I can't see what's causing this. It seems that, inside the fcgi loop, a configuration for a requested MAP confipath is searched inside the cache instance. In case it's found the result is directly returned, otherwise a new cache entry is created and returned. I would expect this should work, but before I will build the trunk version I would like to know if it's solved indeed. thanks, Giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QgisMapserver - need to restart Apache on every project file change ?
Thanks Marco, I supposed it watching the source code. But what about the need to reload apache if I send a different MAP request (i.e. a differnet configuration file)? It should work too, am I wrong? giovanni 2011/10/19 Marco Hugentobler marco.hugentob...@sourcepole.ch Hi Giovanni QGIS server uses the QFileSystemWatcher class ( http://doc.qt.nokia.com/4.7/qfilesystemwatcher.html) to check if a configuration file has changed. So in newer versions, changes to the published project files should be picked up without restarting apache. Regards, Marco Am Dienstag, 18. Oktober 2011, 19.23:28 schrieb G. Allegri: I haven't found the time to setup a fresher qgismapserver, but looking at the source code in trunk I can't see what's causing this. It seems that, inside the fcgi loop, a configuration for a requested MAP confipath is searched inside the cache instance. In case it's found the result is directly returned, otherwise a new cache entry is created and returned. I would expect this should work, but before I will build the trunk version I would like to know if it's solved indeed. thanks, Giovanni -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ 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] adding python interpreter to QGis mapserver to expose analysis routines
These days I'm studying the QGis server architecture, and I was wondering on using it beyond its WMS features. I suppose that exposing other functionalities through it's (fast)cgi interface is trivial, and being able to run python scripts from the qgis internal python interpreter coul be interesting. Some proprietary gis servers already let users publish scripts accessible through web services, and I imagine that it could be done through Qgis server too. Before going on, I would like to receive comments on this, and invetigate eventual blocking issues for this feature given the actual Qgis server architecture. Giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] adding python interpreter to QGis mapserver to expose analysis routines
I was thinking to both the ways: - expose geoprocessing directly through QGIS MS (either C++ plugins or Python plugins) - provide a Python mapscripting for QGIS MS (as you're saying) I think the two ways are complementary. The latter would let you control QGIS MS, and proxy requests, exactly the same as Mapserver/Mapscript. The first one would let you also expose code written for QGis Desktop. For example, you could expose the features provided by the Processing Framework (OTB, SAGA, etc.), or the code inside QGis Analysis. I think that practically a common architecture could respond to both the functionalities: add qgispython interface to Qgis MS, as it is available for Qgis Desktop. This way you can call Python from Qgis and viceversa. giovanni 2011/10/19 Radim Blazek radim.bla...@gmail.com I have a similar question, but not the same, if I got it. I am thinking about a possibility to write a wrapper around the QGIS mapserver in Python. I mean a possibility to process a request before it is passed to QGIS MS core and process result before it is sent back to client. Practically Python bindings for QGIS mapserver. Basically the same like UMN MapServer mapscript in Python. Are you planning something like that? Usually it is always necessary to add an additional functionality for each project and the possibility to do it in Python would be the best IMO. Radim On Wed, Oct 19, 2011 at 3:06 PM, G. Allegri gioha...@gmail.com wrote: These days I'm studying the QGis server architecture, and I was wondering on using it beyond its WMS features. I suppose that exposing other functionalities through it's (fast)cgi interface is trivial, and being able to run python scripts from the qgis internal python interpreter coul be interesting. Some proprietary gis servers already let users publish scripts accessible through web services, and I imagine that it could be done through Qgis server too. Before going on, I would like to receive comments on this, and invetigate eventual blocking issues for this feature given the actual Qgis server architecture. 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] 1.8 release?
I agree Martin, but I would hope that (at least) some of the major bugs reported for 1.7/1.7.1 will be solved before a new release. The risk is to provide new features, but loosing stability for the ones users are used to. giovanni 2011/10/19 Martin Dobias wonder...@gmail.com Hi devs looking at the amount of time (~6 months) and commits (~900) since the 1.7 release I am wondering whether it would not be reasonable to make also 1.8 release. Originally we wanted 1.7 to be the last 1.x feature release, however the master branch is in a good shape and no API breakage happened until now. Once we will start breaking things it will take some time (e.g. 6-9 months) until we will be able to release 2.0 and it would be a shame not to deliver the recent goodies for such a long time. This is an incomplete list of main new features in master branch since 1.7: - globe plugin - road graph plugin - zonal stats plugin - browser (dock widget + standalone app) - customization - lots of server updates - symbology: ellipses with data-defined fields, line patterns, point patterns - 64-bit feature ids - expressions instead of search strings - generic import layer - plenty of bugfixes and small improvements If there is a consensus I guess the release could happen soon, sometime in mid-November. Regards Martin ___ 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] Ma réponse de chargé d'étude en Région
Is it spam? 2011/10/19 Sémécurbe François francois.semecu...@insee.fr La crampe is Dead on Qgis I will be back in the future to kill all the pinguins!!! -Message d'origine- De : qgis-developer-boun...@lists.osgeo.org [mailto: qgis-developer-boun...@lists.osgeo.org] De la part de Martin Dobias Envoyé : mercredi 19 octobre 2011 17:31 À : qgis-dev Objet : [Qgis-developer] 1.8 release? Hi devs looking at the amount of time (~6 months) and commits (~900) since the 1.7 release I am wondering whether it would not be reasonable to make also 1.8 release. Originally we wanted 1.7 to be the last 1.x feature release, however the master branch is in a good shape and no API breakage happened until now. Once we will start breaking things it will take some time (e.g. 6-9 months) until we will be able to release 2.0 and it would be a shame not to deliver the recent goodies for such a long time. This is an incomplete list of main new features in master branch since 1.7: - globe plugin - road graph plugin - zonal stats plugin - browser (dock widget + standalone app) - customization - lots of server updates - symbology: ellipses with data-defined fields, line patterns, point patterns - 64-bit feature ids - expressions instead of search strings - generic import layer - plenty of bugfixes and small improvements If there is a consensus I guess the release could happen soon, sometime in mid-November. Regards Martin ___ 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] Ma réponse de chargé d'étude en Région
I know that you are a french statistician, but I don't understand the joke... and I don't want to. giovanni 2011/10/19 Sémécurbe François francois.semecu...@insee.fr ** No, it's private joke from a french statistician!! -- *De :* G. Allegri [mailto:gioha...@gmail.com] *Envoyé :* mercredi 19 octobre 2011 17:40 *À :* Sémécurbe François *Cc :* Martin Dobias; qgis-dev; Levy David *Objet :* Re: [Qgis-developer] Ma réponse de chargé d'étude en Région Is it spam? 2011/10/19 Sémécurbe François francois.semecu...@insee.fr La crampe is Dead on Qgis I will be back in the future to kill all the pinguins!!! -Message d'origine- De : qgis-developer-boun...@lists.osgeo.org [mailto: qgis-developer-boun...@lists.osgeo.org] De la part de Martin Dobias Envoyé : mercredi 19 octobre 2011 17:31 À : qgis-dev Objet : [Qgis-developer] 1.8 release? Hi devs looking at the amount of time (~6 months) and commits (~900) since the 1.7 release I am wondering whether it would not be reasonable to make also 1.8 release. Originally we wanted 1.7 to be the last 1.x feature release, however the master branch is in a good shape and no API breakage happened until now. Once we will start breaking things it will take some time (e.g. 6-9 months) until we will be able to release 2.0 and it would be a shame not to deliver the recent goodies for such a long time. This is an incomplete list of main new features in master branch since 1.7: - globe plugin - road graph plugin - zonal stats plugin - browser (dock widget + standalone app) - customization - lots of server updates - symbology: ellipses with data-defined fields, line patterns, point patterns - 64-bit feature ids - expressions instead of search strings - generic import layer - plenty of bugfixes and small improvements If there is a consensus I guess the release could happen soon, sometime in mid-November. Regards Martin ___ 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] adding python interpreter to QGis mapserver to expose analysis routines
That would ne a very interesting architecture Martin. Each Service would manage its on requirements, for example its own internal bindings to Python or whatever. I'm not sure about the fastgi nature of the services. The server has a an fcgi interface, ok, but the services should be indipendent from this specific interface. The Server could be deployed in a different fashion, but the services should ignore this. giovanni 2011/10/19 Martin Dobias wonder...@gmail.com Hi Giovanni and Radim On Wed, Oct 19, 2011 at 12:24 PM, G. Allegri gioha...@gmail.com wrote: I was thinking to both the ways: - expose geoprocessing directly through QGIS MS (either C++ plugins or Python plugins) - provide a Python mapscripting for QGIS MS (as you're saying) I think the two ways are complementary. The latter would let you control QGIS MS, and proxy requests, exactly the same as Mapserver/Mapscript. The first one would let you also expose code written for QGis Desktop. For example, you could expose the features provided by the Processing Framework (OTB, SAGA, etc.), or the code inside QGis Analysis. A nice low-level solution would be to introduce a new class to qgis_core library that would take care of fastcgi functionality (e.g. QgsFastCgiServer) and an abstract interface for web-based services (e.g. QgsFastCgiService) for communication between the fastcgi server and the concrete service. One or more services could be registered to the fastcgi server and it would redirect the request to the services. Our WMS server would be therefore become a service running on top of QgsFastCgiServer, the mapserver executable would just create fastcgi server instance, add WMS service and start the server. With QgsFastCgiServer developers could implement basically any functionality they want. A simple WPS service could be built on top of the processing framework. Or a service that first does some processing, then renders the map and returns it (this would be the MapScript equivalent, right?) To use python we would need python wrapper of the server and service classes, something that could be done very easily. The WMS service could be probably made extensible, too, but the number of possible use cases would be probably smaller in order to stay compatible with WMS standard. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] adding python interpreter to QGis mapserver to expose analysis routines
I imagine a plugin system, similar to Qgis Desktop, where every service is discovered/registered if available in certain library paths. For the Python side I see two features that could be supplied: - Provide a qgispython to the services that require it to run python scripting. We can reuse a code very similar (the same?) as in Qgis Desktop - Design a Python interface to control the Server. This would permit to write Python frontends to the server, and incorporate Qgis Server inside Python server projects giovanni 2011/10/20 Martin Dobias wonder...@gmail.com On Wed, Oct 19, 2011 at 7:17 PM, G. Allegri gioha...@gmail.com wrote: That would ne a very interesting architecture Martin. Each Service would manage its on requirements, for example its own internal bindings to Python or whatever. I'm not sure about the fastgi nature of the services. The server has a an fcgi interface, ok, but the services should be indipendent from this specific interface. The Server could be deployed in a different fashion, but the services should ignore this. Sure, it does not have to be bound specifically to FastCGI so that in future other gateway interfaces could be used. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] adding python interpreter to QGis mapserver to expose analysis routines
2011/10/20 Martin Dobias wonder...@gmail.com On Thu, Oct 20, 2011 at 4:00 PM, G. Allegri gioha...@gmail.com wrote: I imagine a plugin system, similar to Qgis Desktop, where every service is discovered/registered if available in certain library paths. I am not sure if such implicit (automatic) registration would be good. Imagine that you have several web services. You would like to run a public WMS server and also another bunch of services for a limited group of users. Having all the services available in both instances would not be very good - e.g. with a WMS server you may automatically provide WPS server. Looking at similar architectures, Geoserver seems to work this way, leaving to a security/configuration layer to enable and control the availability of the extensions. Anyway, we can avoid an automatic discovering, and control their exposure through a configuration system (eg a simple configurations file). For the Python side I see two features that could be supplied: - Provide a qgispython to the services that require it to run python scripting. We can reuse a code very similar (the same?) as in Qgis Desktop - Design a Python interface to control the Server. This would permit to write Python frontends to the server, and incorporate Qgis Server inside Python server projects As noted in an earlier mail this is mostly just a matter of providing wrappers for the server/service interfaces. I agree Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SVG preview in Print layout
I confirm, for qgis-dev and qgis compiled yesterday on Windows. giovanni 2011/10/21 Paolo Cavallini cavall...@faunalia.it Hi all. In very recent QGIS (compiled yesterday) when adding an image to a print layout, the generation of preview from SVG takes a very long time. Anyone confirms? 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-**developerhttp://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] Print layout: missing svg indicators
I confirm this behaviour too... giovanni 2011/10/21 Paolo Cavallini cavall...@faunalia.it Hi all. If I choose an svg indicator for the beginning and end of an arrow, nothing is shown. Anyone confirms? 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-**developerhttp://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] adding python interpreter to QGis mapserver to expose analysis routines
2011/10/21 Marco Hugentobler marco.hugentob...@sourcepole.ch Hi all It would be great to have a mapscript equivalent for QGIS server, so the possibility to modify the request before it arrives at QgsWMSServer class. GeoServer will provide WMS, WCS and WFS automatically for the data. That could also QGIS server do by default. But with the gateway interface QGIS could provide some custom services, maybe working properly only with some specific data. What would be the benefit of the gateway interface class compared to other services using FastCGI? E.g. if one want to build a WFS/WPS service with QGIS, the obvious solution would be to create qgis_wps_serv.fcgi or similar. Is it the idea to have shared service functionality on service level which is specific to QGIS services? I think that the main benefit would be having a single interface to manage, both on the side of fcgi configurations (eg Apache) and global, server, configurations. I imagine that one could expose some services depending on the overall configuration, or per user, or per domain, etc. Geoserver let services share functionalities, being beans managed by the server context available to any service. Anyway this could be a future feature (I suppose it would take not a small time to be designed and implemented), but having a single gateway opens to this possibility too. giovanni Regards, Marco Am Donnerstag, 20. Oktober 2011, 22.54:30 schrieb Martin Dobias: On Thu, Oct 20, 2011 at 5:40 PM, G. Allegri gioha...@gmail.com wrote: 2011/10/20 Martin Dobias wonder...@gmail.com On Thu, Oct 20, 2011 at 4:00 PM, G. Allegri gioha...@gmail.com wrote: I imagine a plugin system, similar to Qgis Desktop, where every service is discovered/registered if available in certain library paths. I am not sure if such implicit (automatic) registration would be good. Imagine that you have several web services. You would like to run a public WMS server and also another bunch of services for a limited group of users. Having all the services available in both instances would not be very good - e.g. with a WMS server you may automatically provide WPS server. Looking at similar architectures, Geoserver seems to work this way, leaving to a security/configuration layer to enable and control the availability of the extensions. Anyway, we can avoid an automatic discovering, and control their exposure through a configuration system (eg a simple configurations file). GeoServer will provide WMS, WCS and WFS automatically for the data. That could also QGIS server do by default. But with the gateway interface QGIS could provide some custom services, maybe working properly only with some specific data. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] adding python interpreter to QGis mapserver to expose analysis routines
With QGIS, a service can use any function in core/analysis library. Additionally, Python webservices might directly use qgis bindings and python plugin functionality by importing the relevant classes (correct me if I'm wrong). Is there a use-case where it is necessary to manage the functionality by a central server instance? I don't know what exactly the python bindings could add to the Qgis Mapserver. I feel that we can already build a python server app using the already available Qgis bindings... Well, things can be done in several (infinte?) different ways. Anyone can build its own service and deploy it, even using the Python Qgis bindings, avoiding the fcgi interface. I was thinking to a single gateway for the following reasons (which probably are strictly subjective): - avoid forcing the use of Python to deploy the services, and let users/developers use a common fcgi interface. As it is for Mapserver: you can use mapscripting, but you can call MS directly even for vendor specific requests (e.g. html templates). MS incorporates everything in a monolythic server, making it difficult to develop and deploy third-party features. - have a single register, as it is in Geoserver. With Geoserver every extension registers itself, and expose functionalities and the kind of requests (key/value pairs) it can manage. Anyway, the hypothesis 0 is to let eveyone build its own fcgi server, or python gateway ;) giovanni Regards, Marco Am Freitag, 21. Oktober 2011, 12.07:21 schrieb G. Allegri: 2011/10/21 Marco Hugentobler marco.hugentob...@sourcepole.ch Hi all It would be great to have a mapscript equivalent for QGIS server, so the possibility to modify the request before it arrives at QgsWMSServer class. GeoServer will provide WMS, WCS and WFS automatically for the data. That could also QGIS server do by default. But with the gateway interface QGIS could provide some custom services, maybe working properly only with some specific data. What would be the benefit of the gateway interface class compared to other services using FastCGI? E.g. if one want to build a WFS/WPS service with QGIS, the obvious solution would be to create qgis_wps_serv.fcgi or similar. Is it the idea to have shared service functionality on service level which is specific to QGIS services? I think that the main benefit would be having a single interface to manage, both on the side of fcgi configurations (eg Apache) and global, server, configurations. I imagine that one could expose some services depending on the overall configuration, or per user, or per domain, etc. Geoserver let services share functionalities, being beans managed by the server context available to any service. Anyway this could be a future feature (I suppose it would take not a small time to be designed and implemented), but having a single gateway opens to this possibility too. giovanni Regards, Marco Am Donnerstag, 20. Oktober 2011, 22.54:30 schrieb Martin Dobias: On Thu, Oct 20, 2011 at 5:40 PM, G. Allegri gioha...@gmail.com wrote: 2011/10/20 Martin Dobias wonder...@gmail.com On Thu, Oct 20, 2011 at 4:00 PM, G. Allegri gioha...@gmail.com wrote: I imagine a plugin system, similar to Qgis Desktop, where every service is discovered/registered if available in certain library paths. I am not sure if such implicit (automatic) registration would be good. Imagine that you have several web services. You would like to run a public WMS server and also another bunch of services for a limited group of users. Having all the services available in both instances would not be very good - e.g. with a WMS server you may automatically provide WPS server. Looking at similar architectures, Geoserver seems to work this way, leaving to a security/configuration layer to enable and control the availability of the extensions. Anyway, we can avoid an automatic discovering, and control their exposure through a configuration system (eg a simple configurations file). GeoServer will provide WMS, WCS and WFS automatically for the data. That could also QGIS server do by default. But with the gateway interface QGIS could provide some custom services, maybe working properly only with some specific data. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ
[Qgis-developer] negative value set for GCP srcY in Georeferncing Plugin - why?
The srcY coordinate is set with a negative value inside: https://github.com/qgis/Quantum-GIS/blob/master/src/plugins/georeferencer/qgsgcplistmodel.cpp#L128 I miss the logic of that... giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] forward transform of... error
Yes Giovanni, I've just seen it this morning :) It is QgsCoordinateTransform's fault, I suppose... giovanni 2011/10/29 Giovanni Manghi giovanni.man...@gmail.com Hi all, seems to me that in qgis-master (and also in 1.7.1 I think) there is a regression/bug that leads to have this error to pop up very easily forward transform of (-2202.92, 369.213) failed with error: latitude or longitude exceeded limits try for example open a new project in WGS84 (no OTFR) and add a raster in a projected CRS. The error pop ups when the mouse passes over the canvas, so it is useless to click ok as it continue to pop-up, unless dragging it out of the canvas, then enter the project properties and set the project CRS as the layer CRS or by enabling OTFR? Is anyone else seeing it? I can replicate on both Linux and Windows. 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] Re: Slow rendering of shapefile in python-qgis application
Just a technical curiosity: why pyqgis rendering should be slower then qgis? The loading and rendering are performed by the C++ code, and I don't see where python plays an inpacting role... giovanni 2011/11/22 Giovanni Manghi giovanni.man...@gmail.com it is much better now on qgis master/trunk, but performances have changed a lot lately http://hub.qgis.org/issues/1978#change-26447 On Tue, Nov 22, 2011 at 8:03 AM, leonidas leonidas_lia...@yahoo.gr wrote: Any news about that speed problem??? -- View this message in context: http://osgeo-org.1803224.n2.nabble.com/Slow-rendering-of-shapefile-in-python-qgis-application-tp6591319p7019678.html Sent from the qgis-developer mailing list archive at Nabble.com. ___ 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
[Qgis-developer] creating global actions (like macros)
Hi all, I don't know if this has been already suggested/asked before, and I don't know if it's already available somehow. I feel there is a hole between Layer Actions and Plugins, which various softwares fill with Macros (like OO StarBasic, Mapinfo's MapBasic, etc.). It would be nice to be able to write Macros, like in Actions, but on a application level and not bounded to a layer. The plus would be to let the user assign Macros to custom menu items... The last step would be being able to call plugin methods. Ok, one step at a time :) First question: have I missed this option, is it already available? Second question: what do you think about it? giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] creating global actions (like macros)
Hi Nathan, I don't mean using some derived BASIC language. The Macros should be the same as Action types (generic, python, etc.). The only difference being not bounded to layers, but available in a menu list. The menu could be a fixed Actions menu for the moment. In the future it could be a customizable option... giovanni 2012/3/1 Nathan Woodrow madman...@gmail.com Hi giovanni, Can you give me a use case for these Marcos? I have used MapBasic before but that is more like what QGIS provides via Python, although MapBasic can be a bit easier to learn due to it being a DSL[1] [1] http://en.wikipedia.org/wiki/Domain-specific_language - Nathan On Thu, Mar 1, 2012 at 8:12 PM, G. Allegri gioha...@gmail.com wrote: Hi all, I don't know if this has been already suggested/asked before, and I don't know if it's already available somehow. I feel there is a hole between Layer Actions and Plugins, which various softwares fill with Macros (like OO StarBasic, Mapinfo's MapBasic, etc.). It would be nice to be able to write Macros, like in Actions, but on a application level and not bounded to a layer. The plus would be to let the user assign Macros to custom menu items... The last step would be being able to call plugin methods. Ok, one step at a time :) First question: have I missed this option, is it already available? Second question: what do you think about it? 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] QGIS + Inkscape
I thinkg that working to the improvement of the Composer would be an important work. Anyway, like it happens with other GIS softwares, when you need to refine cartographic output for professional layouts you often need to use external softwares. I think the two routes are both important, but they have different targets: - improve the composer, to create good quality layouts and automate map books creations (there are a lot of things that could be refined, like reference maps, multiple frames management, etc.) - work on the GDAL level (SVG or PDF) to have the most information out from the GIS environment and obtain an unfinished product ready for higher level graphics work. I think they are complementary, and they depend on the scope of the needs. giovanni 2012/3/19 Andreas Neumann a.neum...@carto.net Hi, The first question that I had to ask myself in this thread: what is the reason why one wants to move from QGIS to Inkscape? Are there ways to improve QGIS so this extra step in a separate software isn't necessary any more? Would it be more useful to implement missing features in QGIS rather than spending a lot of time trying to let two separate software packages talk to each other? If you really want to work on improving the situation between QGIS and Inkscape I think it would be best to either: * work on SVG read/write support in GDAL (something along the lines of http://www.carto.net/svg/**utils/shp2svg/http://www.carto.net/svg/utils/shp2svg/- which is a bit outdated by now - the idea was to improve GDAL SVG support * improve the qtSVG libraries so QGIS can output more semantically rich SVG output (e.g. with layer names, text stays as text, include attribute data in a foreign namespace so that it can be displayed in Inkscape, improve the styling situation, etc.) I would be interested/available to discuss options and support your work in some ways if I can. Let us know what you decide! Andreas On Mon, 19 Mar 2012 09:20:01 +0100, Marco Hugentobler wrote: Hi Brylie A very good thing would be to improve the SVG export from the print composer. In fact, this would mean to improve the SVG export in the Qt libraries. And from this work, other Qt applications would automatically benefit as well (a large number of applications). Regards, Marco On 19.03.2012 02:40, Brylie Oxley wrote: Hello, My name is Brylie Oxley. I am a student at Sierra College in Nevada City, CA. I would like to apply for the GSoC program. I have been studying GIS at Sierra College, where the courses focus on proprietary tools. For libre GIS tools to be viable options, we need high quality cartographic tools. This is where I see Inkscape as an EXCELLENT candidate. I would like to make an extension for QGIS and/or Inkscape that would enable us to send data from QGIS directly to Inkscape. It would also be nice to be able to have Inkscape leverage the QGIS API to import data/layers into a cartographic project. I am glad to get any feedback regarding users' experiences sharing data between these two programs. I would also like to know what some of the components are that I can leverage to create a bridging extension/improved cartographic interface for QGIS. Thank you for your time and consideration, Brylie Oxley __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://lists.osgeo.org/mailman/listinfo/qgis-developer -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland __**_ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://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] gsoc 2012
Ok, that's what I supposed. We're talking about two different things: your framework and the geoprocessing framework that started some time ago. I don't know if Camilo (or others) are still working actively on that. I can imagine that your experience with the abstraction level development for SEXTANTE will be an important plus to the development of such a framework... And I hope the development will converge on one of the twos, otherwise it would a waste of resources. giovanni 2012/3/21 Sandro Santilli s...@keybit.net On Wed, Mar 21, 2012 at 07:03:25PM +0200, Alexander Bruy wrote: Hmm... so if I understand correctly now we have two frameworks: ProcessingFramework (developed last year by Camilo Polymeris) and SEXTANTE framework. I didn't tested SEXTANTE framework yet, but seems we should decide and leave only one framework to avoid confusing and duplication of work +1 It feels like driving drunk whenever starting qgis: every functionality is duplicated :D --strk; ,--o-. | __/ |Delivering high quality PostGIS 2.0 ! | / 2.0 |http://strk.keybit.net - http://vizzuality.com `-o--' ___ 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] gsoc 2012
The purpose of a geoprocessing framework was exactly that, unify the way algorithms get exposed to the user. Victor has given a big boost to this with SEXTANTE, and it should let the user mix the modules easily to set up processing flows from different algorithms... giovanni 2012/3/22 Alexander Bruy alexander.b...@gmail.com 2012/3/22 Alexander Bruy alexander.b...@gmail.com: Well, but what about GSoC and ideas related to QGIS Processing Framework? This thread was started from Sergey's GSoC proposal focused on extending QGIS Processing Framework with new algorithms. 2012/3/22 Werner Macho werner.ma...@gmail.com: Hi that's what i meant in my mail .. We should look after a solution to present everything (all algorythms) under one umbrella (one central point) sorted after functionality (or something else) .. It's always good to have more instruments to solve problems .. but you have to find (and activate) them.. So i still suggest to meet in lyon and decide howto deal with different frameworks .. Especially when Victor is coming to lyon .. and probably some other framework developers too .. I'd like to see many different approaches and solutions but only one place to find them all to work with.. -- Alexander Bruy -- Alexander Bruy ___ 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] Directions needed for GSOC Proposal
2012/3/26 Vincent Picavet vincent...@oslandia.com Hi, Le lundi 26 mars 2012 12:01:20, Paolo Cavallini a écrit : Il 26/03/2012 12:01, G. Allegri ha scritto: I think the GPL code is mandatory for the bridge, eventually. Not all the underlying code requires to be GPL. Am I wrong? I did some research on this, and the conclusion is that import is functionally and legally equivalent to linking during compilation, so everything that imports qgis must be GPL. Thanks for this explanation. I also would like to have a look to pages/articles on the topic. giovanni +1 I did some research as well, and came to the same conclusion. Studies have been done (by the zope group among others), and this is the general final statement. Vincent ___ 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] import proprietary code inside a python plugin
2012/3/26 Carson Farmer carson.far...@gmail.com Keep in mind it is only a problem if you plan on distributing your plugin... if it is just for internal use then I wouldn't worry about it :-p Well, it's for a customer, so it could be an issue... I totally respect the choice of the developers to use a GPL license, but I agree that an LGPL would cause lesser headaches to support interoperability... giovanni C On Mon, Mar 26, 2012 at 11:45 AM, G. Allegri gioha...@gmail.com wrote: I had to create a python plugin to obatin some interactions with the ESRI ArcGIS Geoprocessing python framework. To do that, I need to import ESRI's libraries in my plugin, which are clearly not GLP'd :) Following a previous thread on this topic, I wonder if it's legal from the side of QGis (obviously it is ok from the ArcGIS's side having a licence for it). giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Carson J. Q. Farmer Centre for GeoInformatics (CGI) School of Geography and Geosciences Irvine Building, University of St Andrews St Andrews, Fife, KY16 9AL Scotland, UK ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Directions needed for GSOC Proposal
Ok, it's clear now Vincent. The exception is only related to system libraries, while it doesn't apply to code that executes inside a GPL application (which doesn't provide the exception). 2012/3/26 G. Allegri gioha...@gmail.com Generally, you can link to a non-free library from a GPL code if you deliver your GPL code with a specific exception for that non-free library. I understand that you can link proprietary code IF you add a specific exception. I cannot grasp the point, but I give up for now. I will study it deeply, and ask more elucidations to a lawyer... If your code is already part of a GPL program (say QGIS), you have to redistribute your code under the same GPL licence, and you cannot add such an exception, therefore you cannot link to this non-free library. Of course in any (legally possible) case you want to be sure you have all the needed rights on the non-free library side. Keep in mind that a Python «import» is considered being a library link, and please do read the aforementionned FAQ, it contains all the necessary elements for you to fully understand the (difficult) matter. Vincent Le lundi 26 mars 2012 16:16:57, G. Allegri a écrit : I would really appreciate if you could explain me this point, seriously. giovanni 2012/3/26 G. Allegri gioha...@gmail.com I apologize for my ignorance, could you explain me the differences? You say that I cannot do an import in python to load ArcGIS code, but here you say that I can import/link proprietary code in GPL code.I see a contradiction here. I apologize again if I cannot get to the point... giovanni 2012/3/26 Paolo Cavallini cavall...@faunalia.it Il 26/03/2012 15:08, G. Allegri ha scritto: Have I misunderstood it? yes -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] import proprietary code inside a python plugin
Ah, Tim, it's getting clear. Thanks. The key point is distribution, as always with GPL. In my case I won't distribute the ESRI geoprocessing libraries, they're part of the ArcGIS distribution, which is only availbale to users having it installed on they're computers. The import satement will success only if the user have the ArcGIS product installed, otherwise it will fail. As a consequence I felt I could freely distribute my plugin as it doesn't strictly require the proprietary side to run. Doesn't GDAL do the same with ECW?! Ok GDAL are LGPL. Is this the key difference? Moreover it doesn't expose the QGis APIs to ArcGIS, and viceversa, so it only bridges the two world to interchange the data. giovanni 2012/3/26 Tim Sutton li...@linfiniti.com Hi On Mon, Mar 26, 2012 at 4:52 PM, G. Allegri gioha...@gmail.com wrote: Through the various considerations on this topic there are two positions the seems contradictory to me: I did some research on this, and the conclusion is that import is functionally and legally equivalent to linking during compilation, so everything that imports qgis must be GPL. [1] So if you plan to distribute although technically possible to link to a proprietary module, its not legall possible. then you can import/link proprietary code into gpl code, provided you have a license to do it. So if you have the license to ESRI etc. to use their libraries you are welcome to make yourself a QGIS frontend to ArcSomething, but you cant legally distribute that. They probably mean different things and they're not in contradiction. Being an important point to me, could you help in understanding it? Above is my understanding of those points anyway Regards Tim thanks a lot, Giovanni [1] http://lists.osgeo.org/pipermail/qgis-developer/2012-March/018976.html [2] http://lists.osgeo.org/pipermail/qgis-developer/2012-March/019000.html 2012/3/26 G. Allegri gioha...@gmail.com I think you're right but watch the reality from a worldwide point of view. I work mostly with foreign countries, not EU/USA. National offices and agencies budgets are far beyond the license fees, so they don't care for it very much. They pay yearly for something that already do the work they need, without having to do contracts for development, define requirements, etc. This is the reality. In my courses, even those based on ESRI software, I always introduce FOSS solutions. Sometimes it raises interest, most of times they don't care. They want the job done, and they don't pay for the license. That's it. Anyway, if I wouldn't think that (most) of times a free solution could be the best way, I wouldn't be here to talk about it ;) giovanni 2012/3/26 Sandro Santilli s...@keybit.net On Mon, Mar 26, 2012 at 03:31:53PM +0200, G. Allegri wrote: I totally agree with you, but reality is a bit different. Many agencies, corporates, etc. are not considering to leave they're infrastructure. It's their choice, they'll have to bear the consequences of that. I suggest solutions to interoperate, not to switch the whole thing. What I'm saying is that it just costs more. And rightly so. It is no interest of the free software users to make it any cheaper, IMHO. It would be easier, and a lot cheeper, if everybody talked one language. +1 But we have hundreads of languages in the world, and we have to deal with this. People grow up learning the language of their mothers. Nobody has to pay a license to _use_ that language. And anyone can learn. We're really not talking about the same thing. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Directions needed for GSOC Proposal
2012/3/26 Alex Mandel tech_...@wildintellect.com More specifically here's the compatibility list: http://www.gnu.org/licenses/license-list.html MIT -Expat or X11, most BSD, Apache 2, LGPL are all on the ok list. ^^^ This does not apply to plugins of QGIS which as a technical necessity must import QGIS. It does apply to libraries that QGIS wishes to include and import into QGIS. Exactly, indeed my plugin will be GPL, and will be distributed as it is. How could someone argue that it's illegal? I don't ditribute non-GPL code with it... giovanni Enjoy, Alex On 03/26/2012 12:40 PM, Alex Mandel wrote: SEXTANTE just needs to be a GPL compatible license, it does not need to be GPL itself, though the copy distributed with QGIS will be treated as GPL. (In effect it ends up being like a dual license). See the diagram on http://www.gnu.org/licenses/quick-guide-gplv3.html I would recommend LGPL otherwise people writing the SEXTANTE plugin for Arc might run into trouble. This would provide flexibility in what applications can use the library (much the way gdal/ogr shows up everywhere). This is quite different than the other issue being discussed which is the import of Arc into a QGIS plugin. To be clear yes people can do such things, and could import proprietary applications into their plugins, they just can't legally distribute it outside their company. Thanks, Alex On 03/26/2012 05:26 AM, G. Allegri wrote: I would keep it LGPL. I'm not interested in wrapping it in proprietary code, but to use proprietary code through SEXTANTE... giovanni 2012/3/26 Peter Borissow peter.boris...@yahoo.com Do you need to GPL all of SETANTE or just the glueware (e.g. QGIS plugin)? In otherwords, is there a way to keep the SEXTANTE core MIT or LGPL? -- *From:* Victor Olaya vola...@gmail.com *To:* cavall...@faunalia.it *Cc:* qgis-developer@lists.osgeo.org *Sent:* Monday, March 26, 2012 6:10 AM *Subject:* Re: [Qgis-developer] Directions needed for GSOC Proposal Then, I guess there is no discussion. As I said, in this case there is no difference from my point of view, so GPL is a good option for SEXTANTE 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] import proprietary code inside a python plugin
Ok, going through hyopthesis things are getting clear: my plugin is ok until it doesn't load something proprietary in its process space. As soon as it happens I must be able to provide the source of every code running in the same process. Right? giovanni 2012/3/26 Vincent Picavet vincent...@oslandia.com Hi, Le lundi 26 mars 2012 21:32:31, G. Allegri a écrit : Ah, Tim, it's getting clear. Thanks. The key point is distribution, as always with GPL. In my case I won't distribute the ESRI geoprocessing libraries, they're part of the ArcGIS distribution, which is only availbale to users having it installed on they're computers. The import satement will success only if the user have the ArcGIS product installed, otherwise it will fail. As a consequence I felt I could freely distribute my plugin as it doesn't strictly require the proprietary side to run. No you are wrong, as soon as your plugin is distributed and linked with arcgis, you have to licence everything as GPL and therefore provide sources. Doesn't GDAL do the same with ECW?! Ok GDAL are LGPL. Is this the key difference? Yes Moreover it doesn't expose the QGis APIs to ArcGIS, and viceversa, so it only bridges the two world to interchange the data. Bridging with an import is a link. If you want to exchange data, do it without the import and separate your modules. please re-read my post and mentionned the FSF faq. Everything is in there. Vincent giovanni 2012/3/26 Tim Sutton li...@linfiniti.com Hi On Mon, Mar 26, 2012 at 4:52 PM, G. Allegri gioha...@gmail.com wrote: Through the various considerations on this topic there are two positions the seems contradictory to me: I did some research on this, and the conclusion is that import is functionally and legally equivalent to linking during compilation, so everything that imports qgis must be GPL. [1] So if you plan to distribute although technically possible to link to a proprietary module, its not legall possible. then you can import/link proprietary code into gpl code, provided you have a license to do it. So if you have the license to ESRI etc. to use their libraries you are welcome to make yourself a QGIS frontend to ArcSomething, but you cant legally distribute that. They probably mean different things and they're not in contradiction. Being an important point to me, could you help in understanding it? Above is my understanding of those points anyway Regards Tim thanks a lot, Giovanni [1] http://lists.osgeo.org/pipermail/qgis-developer/2012-March/018976.html [2] http://lists.osgeo.org/pipermail/qgis-developer/2012-March/019000.html 2012/3/26 G. Allegri gioha...@gmail.com I think you're right but watch the reality from a worldwide point of view. I work mostly with foreign countries, not EU/USA. National offices and agencies budgets are far beyond the license fees, so they don't care for it very much. They pay yearly for something that already do the work they need, without having to do contracts for development, define requirements, etc. This is the reality. In my courses, even those based on ESRI software, I always introduce FOSS solutions. Sometimes it raises interest, most of times they don't care. They want the job done, and they don't pay for the license. That's it. Anyway, if I wouldn't think that (most) of times a free solution could be the best way, I wouldn't be here to talk about it ;) giovanni 2012/3/26 Sandro Santilli s...@keybit.net On Mon, Mar 26, 2012 at 03:31:53PM +0200, G. Allegri wrote: I totally agree with you, but reality is a bit different. Many agencies, corporates, etc. are not considering to leave they're infrastructure. It's their choice, they'll have to bear the consequences of that. I suggest solutions to interoperate, not to switch the whole thing. What I'm saying is that it just costs more. And rightly so. It is no interest of the free software users to make it any cheaper, IMHO. It would be easier, and a lot cheeper, if everybody talked one language. +1 But we have hundreads of languages in the world, and we have to deal with this. People grow up learning the language of their mothers. Nobody has to pay a license to _use_ that language. And anyone can learn. We're really not talking about the same thing. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release
Re: [Qgis-developer] Directions needed for GSOC Proposal
Ok, going through hyopthesis things are getting clear. I have answered Vincent o the other thread: my plugin is ok until it doesn't load something proprietary in its process space. As soon as it happens I must be able to provide the source of every code running in the same process. giovanni 2012/3/26 G. Allegri gioha...@gmail.com 2012/3/26 Alex Mandel tech_...@wildintellect.com More specifically here's the compatibility list: http://www.gnu.org/licenses/license-list.html MIT -Expat or X11, most BSD, Apache 2, LGPL are all on the ok list. ^^^ This does not apply to plugins of QGIS which as a technical necessity must import QGIS. It does apply to libraries that QGIS wishes to include and import into QGIS. Exactly, indeed my plugin will be GPL, and will be distributed as it is. How could someone argue that it's illegal? I don't ditribute non-GPL code with it... giovanni Enjoy, Alex On 03/26/2012 12:40 PM, Alex Mandel wrote: SEXTANTE just needs to be a GPL compatible license, it does not need to be GPL itself, though the copy distributed with QGIS will be treated as GPL. (In effect it ends up being like a dual license). See the diagram on http://www.gnu.org/licenses/quick-guide-gplv3.html I would recommend LGPL otherwise people writing the SEXTANTE plugin for Arc might run into trouble. This would provide flexibility in what applications can use the library (much the way gdal/ogr shows up everywhere). This is quite different than the other issue being discussed which is the import of Arc into a QGIS plugin. To be clear yes people can do such things, and could import proprietary applications into their plugins, they just can't legally distribute it outside their company. Thanks, Alex On 03/26/2012 05:26 AM, G. Allegri wrote: I would keep it LGPL. I'm not interested in wrapping it in proprietary code, but to use proprietary code through SEXTANTE... giovanni 2012/3/26 Peter Borissow peter.boris...@yahoo.com Do you need to GPL all of SETANTE or just the glueware (e.g. QGIS plugin)? In otherwords, is there a way to keep the SEXTANTE core MIT or LGPL? -- *From:* Victor Olaya vola...@gmail.com *To:* cavall...@faunalia.it *Cc:* qgis-developer@lists.osgeo.org *Sent:* Monday, March 26, 2012 6:10 AM *Subject:* Re: [Qgis-developer] Directions needed for GSOC Proposal Then, I guess there is no discussion. As I said, in this case there is no difference from my point of view, so GPL is a good option for SEXTANTE 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] import proprietary code inside a python plugin
Perfect. I find thinking in the terms of process space a clear criterior. This makes dynamic and static linking equivalent... So, going back to SEXTANTE, it can be given an LGPL license but it cannot use non-free code when used through Qgis, while it's free to do it when used through, e.g., ArcGIS. Please, tell me it's right, otherwise I end the day with another doubt! :) giovanni 2012/3/26 Vincent Picavet vincent...@oslandia.com Hi, Ok, going through hyopthesis things are getting clear: my plugin is ok until it doesn't load something proprietary in its process space. As soon as it happens I must be able to provide the source of every code running in the same process. Right? Right. Importing esri python module falls into that category. Vincent giovanni 2012/3/26 Vincent Picavet vincent...@oslandia.com Hi, Le lundi 26 mars 2012 21:32:31, G. Allegri a écrit : Ah, Tim, it's getting clear. Thanks. The key point is distribution, as always with GPL. In my case I won't distribute the ESRI geoprocessing libraries, they're part of the ArcGIS distribution, which is only availbale to users having it installed on they're computers. The import satement will success only if the user have the ArcGIS product installed, otherwise it will fail. As a consequence I felt I could freely distribute my plugin as it doesn't strictly require the proprietary side to run. No you are wrong, as soon as your plugin is distributed and linked with arcgis, you have to licence everything as GPL and therefore provide sources. Doesn't GDAL do the same with ECW?! Ok GDAL are LGPL. Is this the key difference? Yes Moreover it doesn't expose the QGis APIs to ArcGIS, and viceversa, so it only bridges the two world to interchange the data. Bridging with an import is a link. If you want to exchange data, do it without the import and separate your modules. please re-read my post and mentionned the FSF faq. Everything is in there. Vincent giovanni 2012/3/26 Tim Sutton li...@linfiniti.com Hi On Mon, Mar 26, 2012 at 4:52 PM, G. Allegri gioha...@gmail.com wrote: Through the various considerations on this topic there are two positions the seems contradictory to me: I did some research on this, and the conclusion is that import is functionally and legally equivalent to linking during compilation, so everything that imports qgis must be GPL. [1] So if you plan to distribute although technically possible to link to a proprietary module, its not legall possible. then you can import/link proprietary code into gpl code, provided you have a license to do it. So if you have the license to ESRI etc. to use their libraries you are welcome to make yourself a QGIS frontend to ArcSomething, but you cant legally distribute that. They probably mean different things and they're not in contradiction. Being an important point to me, could you help in understanding it? Above is my understanding of those points anyway Regards Tim thanks a lot, Giovanni [1] http://lists.osgeo.org/pipermail/qgis-developer/2012-March/018976.htm l [2] http://lists.osgeo.org/pipermail/qgis-developer/2012-March/019000.htm l 2012/3/26 G. Allegri gioha...@gmail.com I think you're right but watch the reality from a worldwide point of view. I work mostly with foreign countries, not EU/USA. National offices and agencies budgets are far beyond the license fees, so they don't care for it very much. They pay yearly for something that already do the work they need, without having to do contracts for development, define requirements, etc. This is the reality. In my courses, even those based on ESRI software, I always introduce FOSS solutions. Sometimes it raises interest, most of times they don't care. They want the job done, and they don't pay for the license. That's it. Anyway, if I wouldn't think that (most) of times a free solution could be the best way, I wouldn't be here to talk about it ;) giovanni 2012/3/26 Sandro Santilli s...@keybit.net On Mon, Mar 26, 2012 at 03:31:53PM +0200, G. Allegri wrote: I totally agree with you, but reality is a bit different. Many agencies, corporates, etc. are not considering to leave they're infrastructure. It's
Re: [Qgis-developer] Proposal: QGIS Processing Framework improvements
You've done a great work Camilo, and obviously it's always a good thing having multiple approaches to the things, because it can be a richness. I only wonder if those working on such frameworks could converge to a common effort, somehow. Probably you and Victor will desire to follow your own routes. In that case I hope the best results to both: we will have the opportunity to chose the best fitting solution ;) giovanni 2012/3/26 Camilo Polymeris cpolyme...@gmail.com Hello all, as you may know (or not), I participated in last year's GSoC with Quantum GIS, creating a Processing Framework, that allows the user access to data analysis tools from the GIS UI: http://polymeris.github.com/qgis/ The focus last year was on the general framework SAGA support. This was very well received, and we saw the addition of Orfeo as a backend. There are also plans to add support to further libraries to create a module workflow builder, a graphical interface to the interaction capabilities provided by the framework. The experience was very rewarding, so I'd like to apply again this year, with a project to improve on last year's work, adding multithreaded support, UI improvements SAGA support for the remaining modules. The full proposal can be seen at the GSoC page: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/polymeris/11002 Any comments are very welcome. 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] Re: import proprietary code inside a python plugin
I premit that I've already chosen a solution to bypass these issues: one, common library and two plugins, one for qgis and one for arcpy. The plugins will interact through pickling, sharing a common data structure from the common library. This is the easiest solution for me to deploy (no servers as with iPython or RabbitMQ). So, at the end, QGis + GPL + proprietary = illegal. But what about QGis + GPL + LGPL + proprietary? It's not a perversion, it's something that we already have: fTool + GDAL python bindings + ECW giovanni 2012/3/27 Alister Hood alister.h...@synergine.com Message: 4 Date: Mon, 26 Mar 2012 13:33:54 +0200 From: Tim Sutton li...@linfiniti.com I personnaly consider that libraries should not be under a GPL licence but a LGPL one, which keeps the opensource aspect while facilitating mixing with other softwares. GPL is fine with end user software built on top of LGPL libs. That said, it would require to relicence all qgis source code as LGPL with all contributors agreeing to the change. I don't think this will happen soon both for logistical reasons and philosophical - many of us who have contributed code to the project would object to the license switch. Since QGIS includes a server application now, perhaps you should consider relicensing under the *more* restrictive AGPL ;) Does anyone know about distributing *only source code* as *public domain* for a plugin which links with proprietary software? I think it would not be allowed, but I'm not sure. Alister ___ 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: import proprietary code inside a python plugin
2012/3/27 Paolo Corti pco...@gmail.com On Tue, Mar 27, 2012 at 9:07 AM, G. Allegri gioha...@gmail.com wrote: I premit that I've already chosen a solution to bypass these issues: one, common library and two plugins, one for qgis and one for arcpy. The plugins will interact through pickling, sharing a common data structure from the common library. This is the easiest solution for me to deploy (no servers as with iPython or RabbitMQ). Hi Giovanni as others suggested, you can not use arcpy for writing a QGIS plugin, if you are willing to deploy it as open source (ie it is not for your company internal use). QGIS plugins must be released as GPL. Are you considering to release your solution for the community? If not - as I think - you do not need to bother ;) Paolo, if I'm asking the questions is not for bothering. It's something important to me, both as a developer and a cunsoltor for my customers. If you fell this is not the right place to ask it, I will move to the FSF forums or the italian ASSOLI. fTool + GDAL python bindings + ECW same here, if you are willing to open your code to the community. For the same reason GDAL packages are not built with ecw support (same for file gdb, arcsde ecc ecc), but you must compile it for yourself if you need it. In osgeo4w the gdal-ecw DLLs are released binary compiled. I never needed to compile them by myself. Are you saying that osgeo4w is doing something incorrect? ciao p -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti skype: capooti ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: import proprietary code inside a python plugin
Ops. How QGis can use GDAL which uses ECW?! 1 - GDAL is LGPL 2 - it's imported by QGis, so it doesn't use QGis but is used by... 3 - osgeo4w bundles gdal-ecw DLL giovanni 2012/3/27 Noli Sicad nsi...@gmail.com QGis (GPL) + GPL + LGPL + proprietary = illegal. Any proprietary code added to GPL is illegal. Unless they re license the code as LGPL. Noli On 3/27/12, Paolo Corti pco...@gmail.com wrote: On Tue, Mar 27, 2012 at 9:07 AM, G. Allegri gioha...@gmail.com wrote: I premit that I've already chosen a solution to bypass these issues: one, common library and two plugins, one for qgis and one for arcpy. The plugins will interact through pickling, sharing a common data structure from the common library. This is the easiest solution for me to deploy (no servers as with iPython or RabbitMQ). Hi Giovanni as others suggested, you can not use arcpy for writing a QGIS plugin, if you are willing to deploy it as open source (ie it is not for your company internal use). QGIS plugins must be released as GPL. Are you considering to release your solution for the community? If not - as I think - you do not need to bother ;) fTool + GDAL python bindings + ECW same here, if you are willing to open your code to the community. For the same reason GDAL packages are not built with ecw support (same for file gdb, arcsde ecc ecc), but you must compile it for yourself if you need it. ciao p -- Paolo Corti Geospatial software developer web: http://www.paolocorti.net twitter: @capooti skype: capooti ___ 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: import proprietary code inside a python plugin
2012/3/27 Giovanni Manghi giovanni.man...@gmail.com On Tue, 2012-03-27 at 09:51 +0200, G. Allegri wrote: Ops. How QGis can use GDAL which uses ECW?! 3 - osgeo4w bundles gdal-ecw DLL I think there are no erdas libraries in the gdal-ecw package, it is just a bridge (sorry if it is not the right term) between gdal and the erdas libraries that the user must get and copy manually in his system. cheers Exactly, the same would happen with an LGPL bridge to ArcPy ;) *Forget Qgis for a moment* I create an LGPL library on top of arcpy. Stop Then, I release a GPL plugin for QGis that can import and use the above LGPL library. QGis + GPL imports an LGPL library and ONLY USE ITS CODE. The GPL doesn't import arcpy, nor use any proprietary code. giovanni -- Giovanni -- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: import proprietary code inside a python plugin
2012/3/27 Vincent Picavet vincent...@oslandia.com Hi, In osgeo4w the gdal-ecw DLLs are released binary compiled. I never needed to compile them by myself. Are you saying that osgeo4w is doing something incorrect? The gdal/ecw case is particularly complex, as the ECW licence changes regularly and is some kind of opensource but not really. As for YOUR specific case, I think you should have understood by now that it's not possible to use Arcgis inside a python plugin, whatever the energy you deploy to try to convince the world to the opposite. I don't want to convince anyone vincent :) I'm just exploring the various corner cases to understand precisely what can be done and what not. It simply sounds strange to me that, somehow, ECW closed source code can arrive into the QGis process space. It means there's a hole somewhere. Ok, ECW releases the headers as open source, but the underlying SDK algorithms and data structures aren't. It follows that SOMEHOW some proprietary code can infect the purity of the QGis process. You can give me all the reasons, but I suppose that if it happens for ECW it can be reproduced, SOMEHOW, for anything else. For my plugin I already have decided what to do. This is a general question now. If a Qgis user can leavarage a proprietary algorithm (ECW), anyway it happens, it can happen again :) giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-user] Re: [Qgis-developer] Oracle Spatial Driver
What about moving the founding to improve the Oracle driver inside GDAL? The OCI driver would need some refactoring, as it was stated time ago by Frank. This would provide a benefit also to the other sw using GDAL/OGR, and would solve the problem of the license (I suppose) giovanni 2012/3/30 haubourg regis.haubo...@eau-adour-garonne.fr Hi All, very interested in such a feature too! If you do it, don't forget to offer an access to attribute tables (non SDO ones) . many users just open a geographical table and a attribute table, and join them to map datas.. Régis -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Oracle-Spatial-Driver-tp4670299p4670680.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ 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-user] Re: [Qgis-developer] Oracle Spatial Driver
I agree Marco, this was a proposal in case the license issue cannot be solved... giovanni 2012/3/30 Marco Hugentobler marco.hugentob...@sourcepole.ch Hi This would provide a benefit also to the other sw using GDAL/OGR, and would solve the problem of the license (I suppose) Technically, I think it is better to write a native driver, because - the OGR model is not 100% identical with the QGIS one. E.g. one table can contain multiple geometry types, OGR has datasource/layer model, ... (probably more that I don't recall now). Providing a proper mapping between OGR model and QGIS model requires more effort than a native driver - more direct geometry transfer with native driver, thus better performance (with OGR driver, geometry is converted into OGR geometry first) Regards, Marco On 30.03.2012 11:49, G. Allegri wrote: What about moving the founding to improve the Oracle driver inside GDAL? The OCI driver would need some refactoring, as it was stated time ago by Frank. This would provide a benefit also to the other sw using GDAL/OGR, and would solve the problem of the license (I suppose) giovanni 2012/3/30 haubourg regis.haubo...@eau-adour-garonne.fr Hi All, very interested in such a feature too! If you do it, don't forget to offer an access to attribute tables (non SDO ones) . many users just open a geographical table and a attribute table, and join them to map datas.. Régis -- View this message in context: http://osgeo-org.1560.n6.nabble.com/Oracle-Spatial-Driver-tp4670299p4670680.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing listQgis-developer@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Churerstrasse 22, CH-8808 Pfäffikon SZ, switzerlandmarco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ 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] obtain QgisApplication instance reference inside python plugin?
Is there a way to reach the QgisApplication reference from a python plugin? The iface object is exposed by the application object, but afaik it doesn't expose it. I need to control some aspects of the application lifecycle, but I fear the plugin system is designed to not allow it... giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] Oracle Spatial Driver
I suppose we're talking about Oracle Spatial, otherwise I don't think it would worth it... giovanni 2012/4/3 jonathanmou...@warwickshire.gov.uk Just a quick general question - would this be an Oracle Spatial or an Oracle Locator driver? Because (for those who don't know), Oracle give quite a lot of their spatial stuff for free by way of Oracle Locator (it's included in Oracle Enterprise Edition), but there's a expensive extension called Oracle Spatial which adds a lot more functions. Ideally the driver would be able to use the Locator functionality without triggering the Spatial functionality unless that functionality is explicitly requested (Oracle have a weird licensing model - everything is enabled and you can't easily disable it; the onus is on the user not to use the extensions). My thoughts/observations anyway, but I'm not the one paying so... :-) Jonathan From:Andreas Neumann a.neum...@carto.net To:qgis-user qgis-u...@lists.osgeo.org, qgis-developer qgis-developer@lists.osgeo.org Date:30/03/2012 08:26 Subject:[Qgis-user] Oracle Spatial Driver Sent by:qgis-user-boun...@lists.osgeo.org -- Hi, The City of Dornbirn and the Province of Vorarlberg have an interest in getting an Oracle Spatial native driver developed for QGIS. They would finance the bulk of the development, but they are interested in other financial contributions if there are other interested commercial or governmental QGIS users with an interest in the access of Oracle databases. Please contact me if you have an interest in helping this project financially. We are not interested in small donations but in more substantial amounts in order not to complicate the billing process too much. Thanks, Andreas -- -- Andreas Neumann Böschacherstrasse 10A 8624 Grüt (Gossau ZH) Switzerland ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ 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] Extending SEXTANTE algorithms in QGIS (a new plugin/example)
The problem is solved changing: - import sextante.ftools.Buffer as buff + from sextante.ftools import Buffer as buff at [...]/sextante/ftools/FixedDistanceBuffer.py [12] At first sight It could be a problem with the overloaded _builtin_import inside Qgis's utils.py... But it's too late to investigate it :) giovanni 2012/4/3 Pedro Venâncio pedrongvenan...@yahoo.com Hi, Same problem here on Debian Squeeze. Best regards, Pedro Venâncio -- *From:* Paolo Cavallini cavall...@faunalia.it *To:* qgis-developer@lists.osgeo.org *Sent:* Tuesday, April 3, 2012 7:33 PM *Subject:* Re: [Qgis-developer] Extending SEXTANTE algorithms in QGIS (a new plugin/example) Il 03/04/2012 13:32, Victor Olaya ha scritto: Hi all As some people mentioned, is important to incorporate more algorithms into SEXTANTE to make it become some kind of standarized geoanalysis Upgrading throws errors: Impossibile caricare il plugin 'sextante' da ['/home/paolo/.qgis/python/plugins/GeoCoding', '/home/paolo/.qgis/python/plugins/sextante', '/home/paolo/.qgis/python/plugins/GeoCoding', '/home/paolo/.qgis/python/plugins/elevation', '/home/paolo/.qgis/python/plugins/cswclient', '/usr/share/qgis/python', '/home/paolo/.qgis/python', '/home/paolo/.qgis/python/plugins', '/usr/share/qgis/python/plugins', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-linux2', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/PIL', '/usr/lib/python2.7/dist-packages/gst-0.10', '/usr/lib/python2.7/dist-packages/gtk-2.0', '/usr/lib/pymodules/python2.7', '/usr/lib/python2.7/dist-packages/wx-2.8-gtk2-unicode', '.', '/home/paolo/.qgis/python/plugins/ziplayers/logic', '/home/paolo/.qgis/python/plugins/ziplayers/gui', '/usr/share/qgis/python/plugins/fTools/tools', '/home/paolo/.qgis/python/plugins/mmqgis/forms', '/home/paolo/.qgis/python/plugins/QuickMultiAttributeEdit/forms', '~/.qgis/python', '.', '.'] Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/qgis/utils.py, line 143, in loadPlugin __import__(packageName) File /usr/lib/python2.7/dist-packages/qgis/utils.py, line 309, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File /home/paolo/.qgis/python/plugins/sextante/__init__.py, line 1, in from sextante.SextantePlugin import SextantePlugin File /usr/lib/python2.7/dist-packages/qgis/utils.py, line 309, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File /home/paolo/.qgis/python/plugins/sextante/SextantePlugin.py, line 6, in from sextante.core.Sextante import Sextante File /usr/lib/python2.7/dist-packages/qgis/utils.py, line 309, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File /home/paolo/.qgis/python/plugins/sextante/core/Sextante.py, line 13, in from sextante.ftools.FToolsAlgorithmProvider import FToolsAlgorithmProvider File /usr/lib/python2.7/dist-packages/qgis/utils.py, line 309, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File /home/paolo/.qgis/python/plugins/sextante/ftools/FToolsAlgorithmProvider.py, line 21, in from sextante.ftools.FixedDistanceBuffer import FixedDistanceBuffer File /usr/lib/python2.7/dist-packages/qgis/utils.py, line 309, in _import mod = _builtin_import(name, globals, locals, fromlist, level) File /home/paolo/.qgis/python/plugins/sextante/ftools/FixedDistanceBuffer.py, line 12, in import sextante.ftools.Buffer as buff AttributeError: 'module' object has no attribute 'ftools' === and then: === Traceback (most recent call last): File /home/paolo/.qgis/python/plugins/plugin_installer/installer_gui.py, line 585, in upgradeAllClicked self.installPlugin(key, quiet=True) File /home/paolo/.qgis/python/plugins/plugin_installer/installer_gui.py, line 656, in installPlugin reloadPlugin(key) File /usr/lib/python2.7/dist-packages/qgis/utils.py, line 263, in reloadPlugin startPlugin(packageName) File /usr/lib/python2.7/dist-packages/qgis/utils.py, line 158, in startPlugin package = sys.modules[packageName] KeyError: u'sextante' === Thanks. -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Extending SEXTANTE algorithms in QGIS (a new plugin/example)
just reinstalling now work. mmm, it's curious. There were no changes to the code since yesterday evening. I would like to know what was wrong... Anyway, it works ;) giovanni -- Paolo Cavallini - Faunalia www.faunalia.eu Full contact details at www.faunalia.eu/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
[Qgis-developer] (prabable) bug in ellipsoid semi-minor axis calculation inside QgsDistanceArea
In Qgis the semi-minor axis of the ellipsoid is calculated [1] with: b = a - (f/a) where b = semi-minor axis a = semi-majot axis f = inverse flattening while it should be: b = a - (a/f) In Qgis the WGS84 semi-minor axis is 6378136,xxx while it should be 6356752.xxx This causes wrong distance calculations on ellipsoid as reported here: http://lists.osgeo.org/pipermail/qgis-user/2012-April/016535.html giovanni [1] http://trac.osgeo.org/qgis/browser/trunk/qgis/src/core/qgsdistancearea.cpp#L153 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: PyQGIS Auto-completion and Call Tips in Eric Python Editor
I would seriously consider upgrading the Python console, first of all to
support autocompletion. I suggested the incorporation of QScintilla a
couple of years ago, but it didn't raise much interest. A few weeks ago I
gave a look to iPython, and it's Qt console [1].
giovanni
[1] http://ipython.org/ipython-doc/dev/interactive/qtconsole.html
2012/4/9 Tim Sutton li...@linfiniti.com
Hi Larry
On Mon, Apr 9, 2012 at 5:20 AM, Larry Shaffer lar...@dakotacarto.com
wrote:
On Sun, Apr 8, 2012 at 7:48 PM, Larry Shaffer lar...@dakotacarto.com
wrote:
Hi,
I've successfully generated QScintilla2 API files for the QGIS Python
bindings and utility modules [0]. If you use the Eric4/5 Python editor
(or
another based on QScintilla2), you may be interested in installing and
compiling these APIs.
Seems a better approach, instead of changing SIPMacros.cmake, would be in
python/CMakeLists.txt [0]:
--- python/CMakeLists_orig.txt2012-02-19 13:41:41.0 -0700
+++ python/CMakeLists.txt2012-04-08 21:00:16.0 -0600
@@ -54,0 +55 @@
+set(SIP_EXTRA_OPTIONS ${PYQT4_SIP_FLAGS} -o -a
${CMAKE_BINARY_DIR}/python/qgis.core.api)
@@ -68,0 +70 @@
+set(SIP_EXTRA_OPTIONS ${PYQT4_SIP_FLAGS} -o -a
${CMAKE_BINARY_DIR}/python/qgis.gui.api)
@@ -79,0 +82 @@
+set(SIP_EXTRA_OPTIONS ${PYQT4_SIP_FLAGS} -o -a
${CMAKE_BINARY_DIR}/python/qgis.analysis.api)
This worked fine on compile, creating the same output as the
SIPMacros.cmake
edit. Each SIP_EXTRA_OPTIONS could be wrapped with a conditional based
on a
compile option for generating the APIs.
Two quick comments:
1) Could you submit your patch via github? If it is a cmake
conditional compilation I see no reason to exclude it from master -
others may have a different opinion.
2) What I would really *love* is to have QGIS api completion (and
other standard python modules if it is easy to achieve) in the built
in python console that is activeated from the QGIS plugins menu. I
often like to demo stuff to people using the python console and always
flap around trying to remember syntax. Obviously this would add a
qsctintilla dependency to QGIS core - how do others feel about this?
Given the other work you are busy with that dependency is probably
coming anyway
Regards
Tim
Regards,
Larry Shaffer
Dakota Cartography
Black Hills, South Dakota
[0] http://dl.dropbox.com/u/4058089/qgis/CMakeLists.txt
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
--
Tim Sutton - QGIS Project Steering Committee Member (Release Manager)
==
Please do not email me off-list with technical
support questions. Using the lists will gain
more exposure for your issues and the knowledge
surrounding your issue will be shared with all.
Visit http://linfiniti.com to find out about:
* QGIS programming and support services
* Mapserver and PostGIS based hosting plans
* FOSS Consulting Services
Skype: timlinux
Irc: timlinux on #qgis at freenode.net
==
___
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] GEOS geometry from QgsGeometry with the Python API?
Hi, I've just realized that the python api does't support the QgsGeometry.asGeos() method. I understand that it would require SIP to manage the marshalling and the bindings to GEOS too, so what is the best way to obtain a GEOS geometry from the QgsGeoemtry? I mean, is there something better then passing through the WKB representation and creating a GEOS instance from python? giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Trouble compiling qgis-server
It seems a SIP problem, maybe related to what discussed here: http://osgeo-org.1560.n6.nabble.com/build-error-td4350904.html I could compile with MSVC on Windows. giovanni 2012/4/17 Andrea Peri aperi2...@gmail.com Hi, today I update my qgis-server trunk version The cmake configuration was passed without problem so I guess there isn't any missing module. but when try to compille with make I see this error. --- Ignored 4167 untranslated source text(s) [ 83%] Built target translations Scanning dependencies of target compile_python_files [ 83%] Built target compile_python_files [ 83%] Generating analysis/sipanalysispart0.cpp, analysis/sipanalysispart1.cpp, analysis/sipanalysispart2.cpp, analysis/sipanalysispart3.cpp sip: Usage: sip [-h] [-V] [-a file] [-c dir] [-d file] [-e] [-g] [-I dir] [-j #] [-m file] [-p module] [-r] [-s suffix] [-t tag] [-w] [-x feature] [-z file] [file] make[2]: *** [python/analysis/sipanalysispart0.cpp] Error 1 make[1]: *** [python/CMakeFiles/python_module_qgis_analysis.dir/all] Error 2 make: *** [all] Error 2 [tomcat@copernico3 build-master]$ --- Any hint ? thx, -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ 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 tool for vector data merging proposal
Hi Viktor, I find your proposal very interesting. I've worked a lot on GRASS where data structures are topological, and with ArcGIS GeoDB where topological rules can be defined to keep geometrical integrity. I feel that this kind of tools are foundamental to supply sound data management. As you know Qgis supports basic topological controls for editing, but what we miss is something like the validation tools that we can find in OpenJUMP, or JCS (Java Conflation Suite) [1] . I feel that your project could help also in the direction of geometrical validation for a single layer. I think a reference data model for your project (like OGC/SFS, TC211, SQL/MM) should be provided. giovanni [1] http://www.vividsolutions.com/JCS/ 2012/4/17 Viktor Nagy a0smu...@gmail.com Hi All, I hope this isn't the wrong place for this announcement, though I also sent it to the soc list. It's a GSoC proposal. I'm Viktor Nagy, an MSc. student at the University of Szeged, Hungary. If you are interested, please have a look at my proposal about some advanced vector data merging. http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/a0smucig/1 Comments and suggestions are much appreciated! Cheers! Viktor ___ 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] GEOS geometry from QgsGeometry with the Python API?
Right, it would need some kung-fu across QGIS-GEOS python bindings. It was never really a top priority for me since QgsGeometry exposes the most important GEOS geometry algorithms. I would like to extend it, to include the linearref methods exposed by the C API: - GEOSInterpolate (- GEOSInterpolateNormalized) - GEOSProject (- GEOSProjectNormalized) and other buffer methods like GEOSSingleSidedBuffer That's probably the easiest thing right now. Internally, QgsGeometry is by default stored in WKB anyway. For now I will use the geos_c lib throug ctypes, but supporting some more GEOS C/API methods directly from C++ would remove a lot of overhead and would speed up performance, obviously. giovanni Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] GEOS geometry from QgsGeometry with the Python API?
Why don't you extent QgsGeometry API ? Because I'm not so much experienced with C++, and I'm scared :D But this could be a good occasion to get back to it ;) I will extend it on my github fork and send a push request as soon as I have it. giovanni --strk; ,--o-. | __/ |Delivering high quality PostGIS 2.0 ! | / 2.0 |http://strk.keybit.net - http://vizzuality.com `-o--' ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] CMAKE_BUILD_TYPE not available inside the cmake gui configuration?
I've seen in CMakeLists that the CMAKE_BUILD_TYPE is evaulated to set QGISDEBUG definition, but there's no entry inside the cmake list of options. I had to manually add it (and set it to RelWithDebInfo in my case) to obtain the Debug output enabled message. Am I doing something wrong? giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: CMAKE_BUILD_TYPE not available inside the cmake gui configuration?
No way, the VS solution doesn't keep the preprocessor directive... I keep on trying Inviato da dispositivo mobile Il giorno 21/apr/2012 18.12, G. Allegri gioha...@gmail.com ha scritto: I've seen in CMakeLists that the CMAKE_BUILD_TYPE is evaulated to set QGISDEBUG definition, but there's no entry inside the cmake list of options. I had to manually add it (and set it to RelWithDebInfo in my case) to obtain the Debug output enabled message. Am I doing something wrong? giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SpatialIndex error on qgis-server compiling
You need to install libspatialindex. (On Debian/Ubuntu apt-get install libspatialindex-dev) or set SPATIALINDEX_INCLUDE_DIR and SPATIALINDEX_LIBRARY to the right path. giohappy 2012/4/27 Andrea Peri aperi2...@gmail.com Hi, today I update my qgis-server from trunk, but in the cmake phase I see an error: CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: SPATIALINDEX_INCLUDE_DIR used as include directory in directory /home/archivio/tomcat/software/qgis/Quantum-GIS/src/core SPATIALINDEX_LIBRARY linked by target qgis_core in directory /home/archivio/tomcat/software/qgis/Quantum-GIS/src/core I use with_desktop = off with_mapserver = on with_binding = off. Any hints ? Thx, -- - Andrea Peri . . . . . . . . . qwerty àèìòù - ___ 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: build qgis in Windows - missing GEOS and PROJ.4
You also need to install those dev libs from osgeo4w. I had to set the proj lib path manually. I'm out of home, as soon as I'll be back to my pc I can share my notes. In the meanwhile I can only confirm that the build procedure for MSVC works fine for all the qgis components (also python bindings). giovanni Inviato da dispositivo mobile Il giorno 05/mag/2012 19.06, Etienne Tourigny etourigny@gmail.com ha scritto: Hi, I got it working last night when running form the osgeo4w shell (my mistake), but there were still a number of missing entries which I had to add (which are also installed by osgeo4w) PROJ_LIBRARY-NOTFOUND SPATIALINDEX_INCLUDE_DIR-NOTFOUND SPATIALINDEX_LIBRARY-NOTFOUND SPATIALITE_LIBRARY-NOTFOUND SQLITE3_LIBRARY-NOTFOUND I tried adding LIB_DIR to both the osgeo script and as a CMake entry, to no avail. Thanks Etienne thanks Etienne On Sat, May 5, 2012 at 1:32 PM, Tim Sutton li...@linfiniti.com wrote: Hi Are you sure you are launching cmake from in an osgeo4w shell? If you do that everything should *just work*. Also you should be able to set a LIB_DIR env var and the cmake find rules will look there for libs. So normally you should not need to tweak much in cmake other than fixing the paths for gnu utils. Regards Tim On Sat, May 5, 2012 at 3:23 AM, Etienne Tourigny etourigny@gmail.com wrote: It seems I had overlooked the osgeo4w /include and /lib directories, which contain all the necessary libs. However, how can things be setup so that cmake looks for all dependencies in the osgeo4w directory, instead of specifying each one manually? regards, Etienne On Fri, May 4, 2012 at 3:46 PM, Etienne Tourigny etourigny@gmail.com wrote: Hi all, following the Windows building instructions at [1] using VS2008 Express, cmake complains that I am missing GEOS and PROJ. I get GEOS_INCLUDE_DIR-NOTFOUND GEOS_LIBRARY-NOTFOUND PROJ_INCLUDE_DIR-NOTFOUND PROJ_LIBRARY-NOTFOUND The instructions do not say anything about building GEOS and PROJ.4 with Visual Studio (but there are instruction for building GEOS with MINGW)... [1] http://hub.qgis.org/projects/quantum-gis/repository/revisions/master/entry/INSTALL thanks Etienne ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ 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: build qgis in Windows - missing GEOS and PROJ.4
PROJ_LIBRARY: C:/OSGeo4W/lib/proj_i.lib SPATIALINDEX_LIBRARY: C:/OSGeo4W/lib/spatialindex_i.lib I didn't need to set sqlite3, because it finds it correctly as C:/OSGeo4W/lib/sqlite3_i.lib giovanni 2012/5/5 Etienne Tourigny etourigny@gmail.com Yes I did install them beforehand, the point is that they were not detected automatically. The spatialindex stuff is rather new (I thinks\), so there might need to be some improvements in the cmake files for Windows. Same for others which have been around for some time (proj,spatialite,sqlite) Etienne On Sat, May 5, 2012 at 2:24 PM, G. Allegri gioha...@gmail.com wrote: You also need to install those dev libs from osgeo4w. I had to set the proj lib path manually. I'm out of home, as soon as I'll be back to my pc I can share my notes. In the meanwhile I can only confirm that the build procedure for MSVC works fine for all the qgis components (also python bindings). giovanni Inviato da dispositivo mobile Il giorno 05/mag/2012 19.06, Etienne Tourigny etourigny@gmail.com ha scritto: Hi, I got it working last night when running form the osgeo4w shell (my mistake), but there were still a number of missing entries which I had to add (which are also installed by osgeo4w) PROJ_LIBRARY-NOTFOUND SPATIALINDEX_INCLUDE_DIR-NOTFOUND SPATIALINDEX_LIBRARY-NOTFOUND SPATIALITE_LIBRARY-NOTFOUND SQLITE3_LIBRARY-NOTFOUND I tried adding LIB_DIR to both the osgeo script and as a CMake entry, to no avail. Thanks Etienne thanks Etienne On Sat, May 5, 2012 at 1:32 PM, Tim Sutton li...@linfiniti.com wrote: Hi Are you sure you are launching cmake from in an osgeo4w shell? If you do that everything should *just work*. Also you should be able to set a LIB_DIR env var and the cmake find rules will look there for libs. So normally you should not need to tweak much in cmake other than fixing the paths for gnu utils. Regards Tim On Sat, May 5, 2012 at 3:23 AM, Etienne Tourigny etourigny@gmail.com wrote: It seems I had overlooked the osgeo4w /include and /lib directories, which contain all the necessary libs. However, how can things be setup so that cmake looks for all dependencies in the osgeo4w directory, instead of specifying each one manually? regards, Etienne On Fri, May 4, 2012 at 3:46 PM, Etienne Tourigny etourigny@gmail.com wrote: Hi all, following the Windows building instructions at [1] using VS2008 Express, cmake complains that I am missing GEOS and PROJ. I get GEOS_INCLUDE_DIR-NOTFOUND GEOS_LIBRARY-NOTFOUND PROJ_INCLUDE_DIR-NOTFOUND PROJ_LIBRARY-NOTFOUND The instructions do not say anything about building GEOS and PROJ.4 with Visual Studio (but there are instruction for building GEOS with MINGW)... [1] http://hub.qgis.org/projects/quantum-gis/repository/revisions/master/entry/INSTALL thanks Etienne ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ 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] keeping layer settings tab between layers and qgis sessions can cause problems when histogram tab is the last viewed
A complex object to say something simple :( When a user opens a layer settings window and hits a tab, the same tab index is kept when opening another layer settings, or in a new qgis sessions. I had a small raster layer, and I opened the histogram tab. The today I've opened a big raster layer, and opening the layer settings caused my pc running and running, till a complete qgis crash. I supposed it was something with the settings, so I opened the smalle raster, changed the tab to Style, then I was able to open the large raster settings It's corner case probably, and qgis shouldn't crash with huge raster histograms. Anyway, opening the layer settings to the frist tab would avoid heartbreaks :) giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] PostGIS Manager compatibility issue with PostGIS 2.0
DB Manager works fine. The plugins overlap, but they are contributed plugins, so it's up to the user choosing wether to use DB Manager or the others. My note was directed to the PG Manager mantainer... giovanni 2012/5/7 Salvatore Larosa lrssv...@gmail.com Il giorno lun, 07/05/2012 alle 10.58 +0200, G. Allegri ha scritto: When attempting to use the PM with a PostGIS 2.0 db I obtain the same error as in http://hub.qgis.org/issues/5201, caused by the deprecated postgis_user_stats() call. The plugin manager doesn't suggest updates to the PM. I haven't found the tracker for the plugin. Where is it located? Hi Giovanni, I can not even find it! However, taking advantage of your mail, I noticed a similarity (duplicates) between plugins PostGIS Manager, Spatialite Manager and RT_SQL Layer. IMO they should be removed. DBManager already does all of that! Am I wrong? All the Best, -SL -- Salvatore Larosa linkedIn: http://linkedin.com/in/larosasalvatore twitter: @lrssvt skype: s.larosa IRC: lrssvt ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Re: [Qgis-user] PostGIS Manager compatibility issue with PostGIS 2.0
Thanks Martin. I've already moved to DB Manager. This was just a note for PG Manager, being still available through repositories ;) giovanni 2012/5/7 Martin Dobias wonder...@gmail.com On Mon, May 7, 2012 at 3:25 PM, G. Allegri gioha...@gmail.com wrote: DB Manager works fine. The plugins overlap, but they are contributed plugins, so it's up to the user choosing wether to use DB Manager or the others. My note was directed to the PG Manager mantainer... As a maintainer of PostGIS Manager I would suggest you to move to DB Manager since I do not intend to maintain PG Manager and remove it completely in future. DB Manager is a viable replacement. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] SEXTANTE add folder/file browser TreeSettingItem for ConfigDialog?
I find it would be useful having a folder/file browser option inside a TreeSettingItem dedicated to folder/file paths configurations. giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] SEXTANTE decouple algorithm execution from GUI to run algs from CLI
Almost all the actual algorithms assume to be inside a QgisApplication. It's obvious, being born as QGis plugins. Anyway, I think it would be a good plus being able to run (most of) them from a CLI, given that SEXTANTE handles the layers I/O from filesystem. If I remove QtGui calls from my algorithms, they could be used from console, as far as I have an out-of-gui version of AlgorithmExecuter and QgsLayers. What do you think about this? giovanni ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] SEXTANTE decouple algorithm execution from GUI to run algs from CLI
Well, I don't mean to remove the possibility to interact with the GUI from the algorithms, rather I would abstract the interaction and route it to the GUI in case we are inside QGis GUI or to the console output if we are in a CLI... giovanni 2012/5/8 Etienne Tourigny etourigny@gmail.com Good idea - and have gui classes that call the algorithms. I don't know how many files/classes you have, but it might be a pain to separate the gui from the execution code if you have many algorithms. Etienne On Tue, May 8, 2012 at 8:58 AM, G. Allegri gioha...@gmail.com wrote: Almost all the actual algorithms assume to be inside a QgisApplication. It's obvious, being born as QGis plugins. Anyway, I think it would be a good plus being able to run (most of) them from a CLI, given that SEXTANTE handles the layers I/O from filesystem. If I remove QtGui calls from my algorithms, they could be used from console, as far as I have an out-of-gui version of AlgorithmExecuter and QgsLayers. What do you think about this? 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] keeping layer settings tab between layers and qgis sessions can cause problems when histogram tab is the last viewed
Etienne, I don't think it's a good design to introduce such rules inside
the code (switching ti the first tab in case the remembered tab is the
histogram's).
Having the user to explicitely force the reload of the histogram is what I
would expect to find inside the tab... Maybe with the option, through
settings, to ask for the histogram to be loaded automatically...
giovanni
2012/5/10 Nathan Woodrow madman...@gmail.com
Generally it is good practice that the UI remembers where the user left it
last time. In this case this has a bad user experience because of the slow
loading. My suggestion would be to just add a Load histogram button in
the histogram tab that loads the histogram rather then when the tab is
switched to. This way even if the histogram tab is remembered as the
current tab it will load like normal and user has to click Load histogram
to show it.
- Nathan
On Thu, May 10, 2012 at 10:49 AM, Etienne Tourigny
etourigny@gmail.com wrote:
I agree that this should not happen, should the default be always open
the first tab, or only when the histogram tab was previously selected?
Unfortunately there is no function in the provider API to know if
there is a cached histogram, so it would be better to never allow the
properties window to start on the histogram tab.
I have implemented this in a branch of mine to improve the histogram
tab, here is a snippet:
- tabBar-setCurrentIndex( settings.value(
/Windows/RasterLayerProperties/row ).toInt() );
+ int currentTabIndex = settings.value(
/Windows/RasterLayerProperties/row ).toInt();
+ // if current tab is disabled, use first tab
+ if ( ! tabBar-widget( currentTabIndex )-isEnabled() )
+currentTabIndex = 0;
+ // if current tab is histogram, use first tab (to avoid long
histogram queries)
+ // there is currently no way to know if there ia a cached histogram
int myHistogramTab = 6;
- if ( tabBar-currentIndex() == myHistogramTab )
- {
-refreshHistogram();
- }
+ if ( currentTabIndex == myHistogramTab )
+currentTabIndex = 0;
+ tabBar-setCurrentIndex( currentTabIndex );
Etienne
On Mon, May 7, 2012 at 10:15 AM, G. Allegri gioha...@gmail.com wrote:
A complex object to say something simple :(
When a user opens a layer settings window and hits a tab, the same tab
index
is kept when opening another layer settings, or in a new qgis sessions.
I had a small raster layer, and I opened the histogram tab.
The today I've opened a big raster layer, and opening the layer settings
caused my pc running and running, till a complete qgis crash.
I supposed it was something with the settings, so I opened the smalle
raster, changed the tab to Style, then I was able to open the large
raster
settings
It's corner case probably, and qgis shouldn't crash with huge raster
histograms. Anyway, opening the layer settings to the frist tab would
avoid
heartbreaks :)
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
