Re: [Qgis-developer] new plugin repo online
Il giorno mer, 23/02/2011 alle 00.47 -0800, Alex Mandel ha scritto: That feature has been discussed, is way down at the bottom of the todo list but is quite possible. We are looking for python programmers to try and implement it in django if you are interested in helping. I do not quite agree it's a low priority issue: we found the publishing process rather painful, and error prone. We use a bash script for this, it can be used until a py program comes out. 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
Re: [Qgis-developer] Raster providers
Hi Radim I did some testing too. Having otf projection is coool! Id did run into some problems with my paletted image[1] though. If I open the image in QGIS default session (i.e. no OTF projection) it displays fine [2]. If I enabled OTF Projection (using 900913 Google Mercator) the image displays as all grey [3]. If I set the CRS to the native image projection (EPSG:32734), the image does not show at all. I still need to test with other image types properly but thought I would give you this feedback so long. Also I noted that for greyscale images they always seem to load with min 0 / max 0 and I have to manually go into properties to load them from the layer. [1] http://linfiniti.com/downloads/Toposheet.tif.bz2 [2] http://imgur.com/JHOvt [3] http://imgur.com/NxB7z By the way if anyone else is using git-svn and wanting to test Radims branch, this was the process I used to add it as a local and remote branch in my local repo: git config --add svn-remote.raster-providers.url https://svn.osgeo.org/qgis/branches/raster-providers git config --add svn-remote.raster-providers.fetch :refs/remotes/raster-providers git svn fetch raster-providers -r 15231 git checkout -b raster-providers -t raster-providers git svn rebase raster-providers Thanks to Juergen for pointing me to the relevant crannie in the internet that showed how to do that. Regards Tim On Mon, Feb 21, 2011 at 4:04 PM, Radim Blazek radim.bla...@gmail.com wrote: Hi have fixed some known problems: - short data types are represented by longer types to get space for nulls (the problem Marco found) - avoid statistics calculation on raster load (reported by John C. Tull) - properties are enabled according provider capabilities Please test. Radim ___ 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] QGIS discussion on GIS Group on LinkedIn
Hi Nice discussion to read! Thanks for the heads up! Regards Tim On Thu, Feb 24, 2011 at 1:11 AM, Bruce, Bob (CON) bob.br...@gov.mb.ca wrote: Have the QGIS developers been following this? You can access the discussion at: http://www.linkedin.com/groups/Giving-Quantum-GIS-try-wondered-49657.S.42748827?view=srchtype=discussedNewsgid=49657item=42748827type=membertrk=eml-anet_dig-b_pd-ttl-cn Bob ** ** Bob Bruce, FEC, P.Eng. Geomatics Support Engineer ** bbr...@gov.mb.ca Manitoba Lands and Geomatics Branch, ** work # (204) 945-6636 1007 Century Street, ** FAX # (204) 945-1365 Winnipeg, Manitoba, Canada, R3H 0W4 ** ** The Manitoba Centre for: ** Cadastral Topographical Mapping, and Remote Sensing ** See us on the Web at: http://www.gov.mb.ca/conservation/geomatics/ ** and: http://www.gov.mb.ca/conservation/geomatics/cada_mapping/index.html ** Check out our digital maps at: http://mli2.gov.mb.ca/ ** and WMS: http://mlidata.gov.mb.ca/wms/request.aspx ** ___ 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] Plugins re-organization
Hi all, I think that organizing better plugins in menus it's the way to go waiting for the new toolbox. At the last Hackfest in Polland we went along this way creating the Database menu as it reduced the number of plugins in the Plugin menu and it have made easier to find a plugin. In this moment mostly of the plugins have only one action button, but the current implementation create for each plugin a submenu. So, why do not think about a better plugins organization? I think about few shallow changes. For example, we could re-organize plugins in Database menu just creating some main sub-classes named as the databases' spatial extensions: PostGIS, SpatiaLite, Oracle Spatial, ... Obviously there are some plugins which are out because either general-purpose or manage more database's type. The same for the Plugins menu, creating for example Editing, Loading, ... We discussed something like this yet, I remember, but I'm unable to find the previous thread. Furthermore, this plugins re-organization could be useful also for the new toolbox. Ideas, thoughts and opinions are very welcome. Regards. -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] RE: [Qgis-user] Plugins re-organization
Hi, Hi all, I think that organizing better plugins in menus it's the way to go waiting for the new toolbox. For example, we could re-organize plugins in Database menu just creating some main sub-classes named as the databases' spatial extensions: PostGIS, SpatiaLite, Obviously there are some plugins which are out because either general-purpose or manage I thin that many menu levels is good for new users because it organize things. But for advanced users it slows things because you have to navigate all the menu levels to reach the tool that you want. I have two suggestions:1)A side panel with the plugins tree.2)Detachable menus, like the older TCL/TK versions of GRASS. Or like the the buttons in OpenOffice that have sub-options. Best. -- Giuseppe Sucameli ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] RE: [Qgis-user] Plugins re-organization
Oh, sorry, my last message went with Giuseppe signature. My mistake. It's: Pablo Torres Carreira From: pablotcarre...@hotmail.com To: qgis-u...@lists.osgeo.org; qgis-developer@lists.osgeo.org Subject: RE: [Qgis-user] Plugins re-organization Date: Thu, 24 Feb 2011 10:38:28 -0300 CC: Hi, Hi all, I think that organizing better plugins in menus it's the way to go waiting for the new toolbox. For example, we could re-organize plugins in Database menu just creating some main sub-classes named as the databases' spatial extensions: PostGIS, SpatiaLite, Obviously there are some plugins which are out because either general-purpose or manage I thin that many menu levels is good for new users because it organize things. But for advanced users it slows things because you have to navigate all the menu levels to reach the tool that you want. I have two suggestions:1)A side panel with the plugins tree.2)Detachable menus, like the older TCL/TK versions of GRASS. Or like the the buttons in OpenOffice that have sub-options. Best. -- Giuseppe Sucameli ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] iteration over raster
Hello, I would like to write a qgis python plugin, which modifies cell values based on the values of their surrounding neighbors. But how can I iterate over a raster layer in order to read the value of each raster cell (and its surrounding neighbors)? Is there any method querying raster cell values for i in range (1, numberofrows) for j in range (1, numberofcolumns) value=??? #read cell value of cell[i j] Thank you very much in advance. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] Plugins re-organization
Hi Pablo, On Thu, Feb 24, 2011 at 2:38 PM, Pablo Carreira pablotcarre...@hotmail.comwrote: I think that organizing better plugins in menus it's the way to go waiting for the new toolbox. For example, we could re-organize plugins in Database menu just creating some main sub-classes named as the databases' spatial extensions: PostGIS, SpatiaLite, Obviously there are some plugins which are out because either general-purpose or manage I thin that many menu levels is good for new users because it organize things. But for advanced users it slows things because you have to navigate all the menu levels to reach the tool that you want. I do not quite agree. In this moment you must always navigate at least 2 levels (Database-PluginMenuName- PluginAction), instead after the reorganization you would navigate at least 2 levels and 3 sometimes only: 2 levels if the plugin add only one button (Database-SubMenuName-PluginAction) 3 levels if the plugin have more than one button (Database-SubMenuName- PluginMenuName-PluginAction) In fact there're only few plugins which have more than one button in their menu. New users can find a plugins in a easier way, but also advanced users with a lot of installed plugins. Moreover advanced users use almost always the toolbar button to access a plugin. I have two suggestions: 1)A side panel with the plugins tree. This is the toolbox purpose, a panel with plugins. Waiting for it, this simple reorganization is friendly not with new users only. 2)Detachable menus, like the older TCL/TK versions of GRASS. Or like the the buttons in OpenOffice that have sub-options. Also this solution requires some work, instead my aim is to make it easier with no effort. Cheers. -- Giuseppe Sucameli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] iteration over raster
AFAIK in QGIS API there are no methods for modifying raster cells. To learn about querying raster values look at qgsmaptoolidentify.cpp file in QGIS source tree. If you want not only read pixel values but modify them, look at GDAL and NumPy. On Thu, 24 Feb 2011 16:36:01 +0100 andr...@gmx.de wrote: Hello, I would like to write a qgis python plugin, which modifies cell values based on the values of their surrounding neighbors. But how can I iterate over a raster layer in order to read the value of each raster cell (and its surrounding neighbors)? Is there any method querying raster cell values for i in range (1, numberofrows) for j in range (1, numberofcolumns) value=??? #read cell value of cell[i j] Thank you very much in advance. -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Alexander Bruy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] RE: [Qgis-user] Plugins re-organization
Hi, In this moment you must always navigate at least 2 levels, instead after the reorganization you would navigate at least 2 levels and 3 sometimes only: 2 levels if the plugin add only one button (Database-SubMenuName-PluginAction) 3 levels if the plugin have more than one button (Database-SubMenuName-PluginMenuName-PluginAction) In fact there're only few plugins which have more than one button in their menu. You are right. For plugins like 'Postgis Manager' and 'RT_SQL' there are and will be only 2 levels. But it will be much cleaner. Taking into account what Alister Hood said:I seldom use most plugins, I had an other idea for plugins organization, not necessarily to be implemented now: The plugin manager could have customizable Plugin Sets, so when you change the Plugin Set it disable and enables a collection of plugins. Something like the Layers States Manager in AutoCad (it could be Plugin States Manager).or like the concept of workspaces, or perspectives like in Eclipse IDE. Regards, Pablo. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Re: [Qgis-user] Plugins re-organization
How about having a menu that shows the most recently used plugins? I use that feature a lot when I use GIMP. -Bob On Thu, Feb 24, 2011 at 10:36 AM, Pablo Carreira pablotcarre...@hotmail.com wrote: Hi, In this moment you must always navigate at least 2 levels, instead after the reorganization you would navigate at least 2 levels and 3 sometimes only: 2 levels if the plugin add only one button (Database-SubMenuName-PluginAction) 3 levels if the plugin have more than one button (Database-SubMenuName-PluginMenuName-PluginAction) In fact there're only few plugins which have more than one button in their menu. You are right. For plugins like 'Postgis Manager' and 'RT_SQL' there are and will be only 2 levels. But it will be much cleaner. Taking into account what Alister Hood said: I seldom use most plugins, I had an other idea for plugins organization, not necessarily to be implemented now: The plugin manager could have customizable Plugin Sets, so when you change the Plugin Set it disable and enables a collection of plugins. Something like the Layers States Manager in AutoCad (it could be Plugin States Manager). or like the concept of workspaces, or perspectives like in Eclipse IDE. Regards, Pablo. ___ 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] QGIS discussion on GIS Group on LinkedIn
Il giorno mer, 23/02/2011 alle 17.11 -0600, Bruce, Bob (CON) ha scritto: Have the QGIS developers been following this? You can access the discussion at: http://www.linkedin.com/groups/Giving-Quantum-GIS-try-wondered-49657.S.42748827?view=srchtype=discussedNewsgid=49657item=42748827type=membertrk=eml-anet_dig-b_pd-ttl-cn Thank you, Bob. Pity for the bad report about frequent crashes. In fact I also had similar reports, although infrequently, about particular (win) machines crashing very often, whereas similar ones were rather stable. I suppose specific installation details are to blame. All the best. -- http://www.faunalia.it/pc ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RE: [Qgis-user] Plugins re-organization
I thin that many menu levels is good for new users because it organize things. But for advanced users it slows things because you have to navigate all the menu levels to reach the tool that you want. I have two suggestions:1)A side panel with the plugins tree. 2)Detachable menus, like the older TCL/TK versions of GRASS. Or like the the buttons in OpenOffice that have sub-options. 1+ The detachable menus might look like ArcGIS toolbox. Screenshot of the ArcGIS toolbox http://complexnetgis.wordpress.com/install/ Noli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RE: [Qgis-user] Plugins re-organization
The detachable menus might look like ArcGIS toolbox. Screenshot of the ArcGIS toolbox http://complexnetgis.wordpress.com/install/ Not the red boxes of hell :( Am I the only one who hates them? Regards, Anita ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RE: [Qgis-user] Plugins re-organization
On 2/25/11, Anita Graser anitagra...@gmx.at wrote: The detachable menus might look like ArcGIS toolbox. Screenshot of the ArcGIS toolbox http://complexnetgis.wordpress.com/install/ Not the red boxes of hell :( Am I the only one who hates them? I am only talking about the collapsible menu tree (i.e. collapsible listbox) in ArcGIS toolbox to organise the plugin menu and you can resize and move around. I hate the implementation and dialogs of ArcGIS Toolbox as well. Noli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] RE: [Qgis-user] Plugins re-organization
Am 24.02.2011, 22:48 Uhr, schrieb Noli Sicad nsi...@gmail.com: On 2/25/11, Anita Graser anitagra...@gmx.at wrote: The detachable menus might look like ArcGIS toolbox. Screenshot of the ArcGIS toolbox http://complexnetgis.wordpress.com/install/ Not the red boxes of hell :( Am I the only one who hates them? I am only talking about the collapsible menu tree (i.e. collapsible listbox) in ArcGIS toolbox to organise the plugin menu and you can resize and move around. I hate the implementation and dialogs of ArcGIS Toolbox as well. As long as it stays optional, such a collapsible menu tree could be useful. It should be optional because having two vertical areas (layer list + collapsible plugin menu tree) will take up a lot of screen space. Anita ___ 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?
I like your idea Julien. It does not make sense to have to store all of QGIS source files for a c++ plugin to work. I think the libraries that need to be referenced should be found identified so that one may be able to just build (compile and link) the dll independently of the rest of the QGIS source. I was able to find out why my QGIS compile failed. It appears to me that when I uninstalled Python version 2.6 and installed 2.7 something went wrong. I reinstalled Python 2.6 and now I am able to use cmake and configure and generate with out any error messages. I am thankful for your help and prayers, I might add. Now that I also heard that there is a build_plugin.py file that could ease my pain of creating a plugin, I am looking at it. Does it need to be run from with QGIS or what? Just trying to break the C++ plugin barrier, Maaza --- On Wed, 2/23/11, Julien Malik julien.ma...@c-s.fr wrote: From: Julien Malik julien.ma...@c-s.fr Subject: Re: [Qgis-developer] Plugin Development C++ Windows - Any response? To: Barend Gehrels bar...@xs4all.nl Cc: qgis-developer@lists.osgeo.org Date: Wednesday, February 23, 2011, 1:05 PM Hello, Having written some C++ plugins (for Orfeo Toolbox), I have some feedback to give. The current recommended procedure is to have a source build of qgis, add your plugin inside qgis source tree, hack a QGis CMakeLists to add the new plugin dir, and recompile Qgis. In my opinion, a better approach is to build them as external project. The idea is to be able to build a plugin on top of a prebuilt Qgis (libqgis-dev on ubuntu/debian, and the OSGeo4W build on windows) That's what I have set up for the plugins I wrote, but ran into the following problem : - There is no FindQgis.cmake or QGisConfig.cmake exported in the qgis development package (either OSGeo4W or ubuntu/debian), so importing QGis inside a CMake project must be done by hand. It's ok with the QGis include path and the path to libqgis_core. But you have to take care of importing Qt also, which should be done by a FindQgis.cmake - I had to hack some QGis #define to make it build on windows (GUI_EXPORT and CORE_EXPORT). Again, this should be handled by a ADD_DEFINITION inside a FindQgis.cmake One other thing : it would be nice if the C++ plugins could be loaded from another directory than the official one. Let's say I wrote a bunch of plugins for a specific software, I would like to store them in their own directory instead of messing up with the official plugins. Maybe it's already supported but I don't know how to do it... Regards, Julien Le 23/02/2011 14:12, Barend Gehrels a écrit : Hi, Yes as Martin notes, and as I mentioned in my last email in this thread If you are able to use linux, you can even more easily just use the plugin_builder.py script in that src/plugins directory and it will generate for you a 'hello world' C++ plugin. Perhaps the linux part is not relevant though as you should be able to use it on widows with python, but I've never tried. As an interesting history note, we have had a plugin builder script (in one form or another) in QGIS for c++ plugins from very early on in the life of QGIS's plugin support. On Windows the plugin_builder.py works also perfectly. Regards, Barend ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
