Re: [Qgis-developer] show grid on map canvas (similiar to grid used in composer) - strategy?

2012-05-13 Thread Bob and Deb
I wonder if http://grass.osgeo.org/wiki/Ps.output might give good ideas for
drawing a grid on the map canvas.

On Wed, May 9, 2012 at 2:00 PM, Etienne Tourigny wrote:

> Hi all,
>
> I would like to add support to draw a grid on the map canvas, in a way
> similar to what is done in the map composer (although perhaps without
> the annotations on the borders).
>
> What should be the approach used?
>
> 1) plugin or core?
> 2) rubberbands or basic plot functions triggered after mapCanvas update?
>
> I think both drawing strategies are possible using a plugin.
>
> It would be best to write in the core, assuming there is sufficient
> interest in this, but it will take time to trickle down to the stable
> version (an argument for making it a plugin).
>
> I know the current workaround is to create a vector grid with ftools,
> but that is a little clunky.
>
> Any thoughts?
> Etienne
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


[Qgis-developer] Re: show grid on map canvas (similiar to grid used in composer) - strategy?

2012-05-13 Thread Etienne Tourigny
Hi folks,

there have been a number of interesting suggestions, I will try to
summarize them this week.

I quickly put together a basic grid in the main map canvas, using the
interface and logic from the map composer.  I have decided to
implement the grid as a decoration and accordingly added an item to
the Decoration menu.  I have also improved the decorations management
to be able to draw the decorations in a particular order (with a new
class QgsDecorationItem), so that other decorations are on top of the
grid.

There is support for grid annotations, but only inside the map border
currently.  Line symbology is still basic (line width+color).

Basically I think there could be 2 concurrent and complementary ways
to implement grids:

1) basic grid in core, similar to what is already in the composer map
(and in my branch)
2) more refined grid(s) as plugin/vector layers, whose rendering order
can be fine-tuned

Those interested can have a look at my github branch:

https://github.com/etiennesky/Quantum-GIS/tree/decorationgrid

Etienne

On Wed, May 9, 2012 at 6:00 PM, Etienne Tourigny
 wrote:
> Hi all,
>
> I would like to add support to draw a grid on the map canvas, in a way
> similar to what is done in the map composer (although perhaps without
> the annotations on the borders).
>
> What should be the approach used?
>
> 1) plugin or core?
> 2) rubberbands or basic plot functions triggered after mapCanvas update?
>
> I think both drawing strategies are possible using a plugin.
>
> It would be best to write in the core, assuming there is sufficient
> interest in this, but it will take time to trickle down to the stable
> version (an argument for making it a plugin).
>
> I know the current workaround is to create a vector grid with ftools,
> but that is a little clunky.
>
> Any thoughts?
> Etienne
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Fwd: Threads in sextante

2012-05-13 Thread Etienne Tourigny
Victor,

I agree on all your points.

May I suggest to have a unique interface/approach that other existing
interfaces can benefit from (i.e. standalone gdaltools and ftools).

It seems that QProcess is an interesting candidate (and QThread when
not using external app.), because it works in both c++ and in pyqt
(ref. gdaltools) - plus there is already code inside qgis that uses
it.

my 2 centavos
Etienne

On Sun, May 13, 2012 at 6:13 PM, Victor Olaya  wrote:
> Here is my opinion on all that, in short:
>
> -The main idea of using threads is not now to execute multiplep
> algorithms at the same time, so we can remove a lot of complexity
> (like 2 processes writing the same file, as it was mentioned)
>
> -Implementing a canceling mechanism is going to be the greatest
> improvement once we have the threading stuff
>
> -So, for me, this is what should be done:
>
>  1)implementing the threading part
>  2) implement the cancelling mechanism (a responsive cancel button, etc)
>  3) modifying algorithm to respond to cancellin events.
>
> I think that would be more than enough for a first part, and it would
> be a great improvement for SEXTANTE
>
> Regards
>
> p.s. Just to let you know, I am leaving for Honduras tomorrow, and
> will be there working for 2 weeks, so I not might be very active on
> the lists during the next 15 days or so
>
> 2012/5/13 Marco Hugentobler :
>> Hi Alex
>>
>>
>>>Also I think about rewritting fTools in C++ and integrating its
>>>algorithms into QGIS
>>>analysis library. This makes tools a bit faster and will allow to use
>>>algorithms in
>>>plugins
>>
>> That would be a great enhancement and leverage the analysis library as a
>> whole.
>>
>> Regards,
>> Marco
>>
>>
>>
>>
>> On 13.05.2012 09:23, Alexander Bruy wrote:
>>>
>>> Hi Etienne,
>>>
>>> 2012/5/12 Etienne Tourigny:

 I stand corrected then - I guess I was confusing it with ftools, which
 is blocking and does not spawn a process.
 Any way ftools could be adapted to use the same approach as gdaltools?
>>>
>>> most fTools functions already implemented as threaded, but there are some
>>> minor issues. I work on improving processes handing in fTools, and several
>>> tools already don't block main QGIS window, has non-modal dialogs and
>>> allows
>>> to cancel running process.
>>>
>>> Also I think about rewritting fTools in C++ and integrating its
>>> algorithms into QGIS
>>> analysis library. This makes tools a bit faster and will allow to use
>>> algorithms in
>>> plugins
>>>
>>
>>
>> --
>> 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 mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] Fwd: Threads in sextante

2012-05-13 Thread Victor Olaya
Here is my opinion on all that, in short:

-The main idea of using threads is not now to execute multiplep
algorithms at the same time, so we can remove a lot of complexity
(like 2 processes writing the same file, as it was mentioned)

-Implementing a canceling mechanism is going to be the greatest
improvement once we have the threading stuff

-So, for me, this is what should be done:

  1)implementing the threading part
  2) implement the cancelling mechanism (a responsive cancel button, etc)
  3) modifying algorithm to respond to cancellin events.

I think that would be more than enough for a first part, and it would
be a great improvement for SEXTANTE

Regards

p.s. Just to let you know, I am leaving for Honduras tomorrow, and
will be there working for 2 weeks, so I not might be very active on
the lists during the next 15 days or so

2012/5/13 Marco Hugentobler :
> Hi Alex
>
>
>>Also I think about rewritting fTools in C++ and integrating its
>>algorithms into QGIS
>>analysis library. This makes tools a bit faster and will allow to use
>>algorithms in
>>plugins
>
> That would be a great enhancement and leverage the analysis library as a
> whole.
>
> Regards,
> Marco
>
>
>
>
> On 13.05.2012 09:23, Alexander Bruy wrote:
>>
>> Hi Etienne,
>>
>> 2012/5/12 Etienne Tourigny:
>>>
>>> I stand corrected then - I guess I was confusing it with ftools, which
>>> is blocking and does not spawn a process.
>>> Any way ftools could be adapted to use the same approach as gdaltools?
>>
>> most fTools functions already implemented as threaded, but there are some
>> minor issues. I work on improving processes handing in fTools, and several
>> tools already don't block main QGIS window, has non-modal dialogs and
>> allows
>> to cancel running process.
>>
>> Also I think about rewritting fTools in C++ and integrating its
>> algorithms into QGIS
>> analysis library. This makes tools a bit faster and will allow to use
>> algorithms in
>> plugins
>>
>
>
> --
> 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] Fwd: Threads in sextante

2012-05-13 Thread Marco Hugentobler

Hi Alex

>Also I think about rewritting fTools in C++ and integrating its
>algorithms into QGIS
>analysis library. This makes tools a bit faster and will allow to use
>algorithms in
>plugins

That would be a great enhancement and leverage the analysis library as a 
whole.


Regards,
Marco



On 13.05.2012 09:23, Alexander Bruy wrote:

Hi Etienne,

2012/5/12 Etienne Tourigny:

I stand corrected then - I guess I was confusing it with ftools, which
is blocking and does not spawn a process.
Any way ftools could be adapted to use the same approach as gdaltools?

most fTools functions already implemented as threaded, but there are some
minor issues. I work on improving processes handing in fTools, and several
tools already don't block main QGIS window, has non-modal dialogs and allows
to cancel running process.

Also I think about rewritting fTools in C++ and integrating its
algorithms into QGIS
analysis library. This makes tools a bit faster and will allow to use
algorithms in
plugins




--
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] Re: Welcome to 4 QGIS students in Google Summer of Code 2012

2012-05-13 Thread Evgeniy Pashentsev
Hello

I am that Eugenpaul doing vector layer generalization. Happy
to be accepted, but it is also quite a responsibility, so I am
feeling a very special mix of emotions right now. You may
remember my proposal, but the work plan has been changed
a bit, so I will briefly tell you what I have decided to do after
several conversations with my mentor, Alexander Bruy.
1. My first aim now is to implement generalization for a
collection of objects keeping their topological relations.
Current implementation handles only one feature and avoids
new intersections as a result of generalization. I'll take its
base algorithm, the Douglas-Peucker, and add tracking of
connected edges of the neighboring objects.
2. Then I will implement the on-the-fly generalization to
speed up rendering. According to some tests done by
Alexander [0], a simple distance threshold routine followed by
the Douglas-Peucker algorithm shows significant reduction
of the rendering time, especially with complex style lines.
3. Then I will look into the render cache realization. It is the
right way of speeding up rendering, maybe there is a way to
improve it.
4. At last, if I will have enough time, I'll try to adapt existing
feature cache patch to the last QGIS version.
Everything is planned to be supported by unit tests.
All the progress will be described in the blog [1].
If you have any ideas on how to do these things better,
please let me know.

[0]
https://picasaweb.google.com/lh/photo/avPtza_JMMdA5bkcOAr61tBgozyHltVoaaGmEBdHNL4
 - shows dependence of rendering time on the number of lines
and their style, "+gen" shows rendering time with on-the-fly
simplification
[1] http://blogs.gis-lab.info/ugnpaul/

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


Re: [Qgis-developer] Displaying help for Python plugins

2012-05-13 Thread Larry Shaffer
Hi Alexander,

On Sun, May 13, 2012 at 3:03 AM, Alexander Bruy wrote:

> Hi all,
>
> regarding to PyQGIS CookBook [0] plugin documentation can
> be written as HTML files and to open help developer should
> use method showPluginHelp() from qgis.utils module.
>
> In same time showPluginHelp() used deprecated method openURL()
> from QgsInterface class [1]. And as I can see there are no alternatives
> for this method. So what is best solution for displaying Python plugin
> help in long-term period? Use showPluginHelp() as suggested in
> cookbook or implement own method directly in plugins?
>
> [0] http://www.qgis.org/pyqgis-cookbook/plugins.html#documentation
> [1]
> http://qgis.org/api/classQgisInterface.html#374a28be05fac25b26f271f7ff19cd6d
>

You can use QDesktopServices [0] in lieu of QGIS openURL(), but I think you
probably know this already:

QtGui.QDesktopServices.openUrl(QUrl(some_url))

As part of my Plugin Editor tools, I have designed a lightweight web
browser for displaying HTML help. It allows you to load pre-defined
bookmarks, and has several useful tools for viewing help and tutorials from
within plugins, but does not support several 'normal' browser features,
like downloads.

It is the first PyQGIS shared widget in the sister plugin to Plugin Editor,
called Plugin Library. The idea behind the Library is to offer, via a PyQt
GUI, a method to demo and browse available shared widgets, modules and
snippets. Once the Library is installed, it acts like a PyQGIS virtual
Python environment, from which other developers can use to import its
different components into their plugins. It is an attempt to share code
amongst Python plugin developers (without bothering the C++ coders to
include into the GUI core), speed the development of plugins, and offer
users similar GUIs across plugins (like a help browser).

I'm not done with the Library plugin, but I am pretty much done with the
first version of Help Browser (except for its help :^). Please download it
and try it out, if you like [1]. Right now, it is just a package, but will
later be a sub-package of the Library, accessible with:

from plugin_library.widgets.help_browser.help_browser \
import HelpBrowser

I have only tested it on Mac (10.7 and 10.6.8). Currently, on Mac with QGIS
1.8, any access to external web sites crashes QGIS. Works locally, though.

[0] http://qt-project.org/doc/qt-4.8/qdesktopservices.html
[1] http://dl.dropbox.com/u/4058089/qgis/help_browser.zip

Regards,

Larry Shaffer
Dakota Cartography
Black Hills, South Dakota
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] How to iterate over the vertices of a geometry from python

2012-05-13 Thread Nathan Woodrow
Sure.

You can use:

for v in geom.asPolyline():
print v.x(), v.y()

asPolyline returns QVector which is
just a List of QgsPoints in Python.  Access like normal

- Nathan

On Sun, May 13, 2012 at 9:48 PM, Ricardo Filipe Soares Garcia da
 wrote:
> Hi list
>
> I'm trying to translate and rotate a geometry using python, in order
> to create parallel lines.
>
> For the translation I could use QgsGeometry's translate() method, but
> for the rotation I haven't found a ready-made solution. So my current
> strategy is to individually rotate each vertex, according to a
> specified angle and length. For this i'd like to iterate over the
> geometry's vertices.
>
> The problem seems to be that the api methods that return vertex
> coordinates (vertexAt(), adjacentVertices, ...) always return a value
> even if the specified vertex index is wrong. For example, if I use a
> geometry with 5 vertices and call:
>
> geometry.vertexAt(100)
>
> -> (0,0)
>
> I cannot know if there is a vertex placed at the (0, 0) coordinates or
> if there is no vertex at all.
> Is there some way to iterate over a geometry's vertices? Or maybe get
> an exception when asking for an invalid one?
>
> Thanks
>
>
> --
> ___ ___ __
> Ricardo Garcia Silva
> ___
> 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] How to iterate over the vertices of a geometry from python

2012-05-13 Thread Ricardo Filipe Soares Garcia da
Hi list

I'm trying to translate and rotate a geometry using python, in order
to create parallel lines.

For the translation I could use QgsGeometry's translate() method, but
for the rotation I haven't found a ready-made solution. So my current
strategy is to individually rotate each vertex, according to a
specified angle and length. For this i'd like to iterate over the
geometry's vertices.

The problem seems to be that the api methods that return vertex
coordinates (vertexAt(), adjacentVertices, ...) always return a value
even if the specified vertex index is wrong. For example, if I use a
geometry with 5 vertices and call:

geometry.vertexAt(100)

-> (0,0)

I cannot know if there is a vertex placed at the (0, 0) coordinates or
if there is no vertex at all.
Is there some way to iterate over a geometry's vertices? Or maybe get
an exception when asking for an invalid one?

Thanks


-- 
___ ___ __
Ricardo Garcia Silva
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] how to create a new geometry from an existing one with python

2012-05-13 Thread Ricardo Filipe Soares Garcia da
Thanks
I got it working now!
I now have a different doubt, regarding geometry vertex iteration
(sending another e-mail with it).

On Sun, May 13, 2012 at 9:24 AM, Martin Dobias  wrote:
> Hi Ricardo
>
> On Sun, May 13, 2012 at 1:39 AM, Ricardo Filipe Soares Garcia da
>  wrote:
>> [...]
>>
>> # python code
>>
>> line_geometry =
>> qgis.utils.iface.mapCanvas().currentLayer().selectedFeatures()[-1].geometry()
>>
>> # approach 1
>> new_geometry = QgsGeometry(line_geometry)
>
> This approach is correct (and other seems to be fine, too). The
> problem is elsewhere: you are being bitten by this bug:
> http://hub.qgis.org/issues/777
>
> Basically the problem is that the feature containing the line_geometry
> gets deleted when the first line is executed. So your line_geometry
> contains an invalid pointer leading to these strange errors. To
> overcome this, store the list of features and then access it without
> problems...
>
> Regards
> Martin



-- 
___ ___ __
Ricardo Garcia Silva
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


[Qgis-developer] Displaying help for Python plugins

2012-05-13 Thread Alexander Bruy
Hi all,

regarding to PyQGIS CookBook [0] plugin documentation can
be written as HTML files and to open help developer should
use method showPluginHelp() from qgis.utils module.

In same time showPluginHelp() used deprecated method openURL()
from QgsInterface class [1]. And as I can see there are no alternatives
for this method. So what is best solution for displaying Python plugin
help in long-term period? Use showPluginHelp() as suggested in
cookbook or implement own method directly in plugins?

[0] http://www.qgis.org/pyqgis-cookbook/plugins.html#documentation
[1] http://qgis.org/api/classQgisInterface.html#374a28be05fac25b26f271f7ff19cd6d

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


Re: [Qgis-developer] how to create a new geometry from an existing one with python

2012-05-13 Thread Martin Dobias
Hi Ricardo

On Sun, May 13, 2012 at 1:39 AM, Ricardo Filipe Soares Garcia da
 wrote:
> [...]
>
> # python code
>
> line_geometry =
> qgis.utils.iface.mapCanvas().currentLayer().selectedFeatures()[-1].geometry()
>
> # approach 1
> new_geometry = QgsGeometry(line_geometry)

This approach is correct (and other seems to be fine, too). The
problem is elsewhere: you are being bitten by this bug:
http://hub.qgis.org/issues/777

Basically the problem is that the feature containing the line_geometry
gets deleted when the first line is executed. So your line_geometry
contains an invalid pointer leading to these strange errors. To
overcome this, store the list of features and then access it without
problems...

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


Re: [Qgis-developer] Fwd: Threads in sextante

2012-05-13 Thread Alexander Bruy
Hi Etienne,

2012/5/12 Etienne Tourigny :
> I stand corrected then - I guess I was confusing it with ftools, which
> is blocking and does not spawn a process.
> Any way ftools could be adapted to use the same approach as gdaltools?

most fTools functions already implemented as threaded, but there are some
minor issues. I work on improving processes handing in fTools, and several
tools already don't block main QGIS window, has non-modal dialogs and allows
to cancel running process.

Also I think about rewritting fTools in C++ and integrating its
algorithms into QGIS
analysis library. This makes tools a bit faster and will allow to use
algorithms in
plugins

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