Re: [Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools

[Trevor Wiens]

I like the options of setting a preference for either GIS like operation or
CAD like operation. This does however tie into a larger issue of
configuration flexibility in QGIS.

I use QGIS when I teach GIS and new users are often overwhelmed by rows and
rows of tool bars. By default we can only set those one at a time soI wrote
the MyConfigs plugin so I could set a certain set of tools visible for when
I'm doing digitizing and a different configurations for different tasks.
Unfortunately to disable menus requires a reboot of the system. In my ideal
world the plugin I wrote would be made obsolete by the ability to define
task configurations of tool bars, menus and perhaps even tool behaviour.
This type of flexibility would be useful for teaching but also in day to
day use by keeping what you need close at hand and behaving as needed and
hiding the other stuff that can sometimes get in the way.

TSW
On Sep 26, 2014 3:28 PM, "Andrew"  wrote:

> I also would vote for option 3.  I do quite a bit of digitising/editing in
> QGIS.  I am used to the default behaviour though there are times i wish for
> the editing tools to act as Denis has proposed.  I think it makes sense for
> QGIS' default behaviour to be consistent for people coming from other GIS
> software. In my mind QGIS is foremost a GIS and should behave as such.  So
> i don't think 1 is a good option.  also, 2 sees like it could be
> confusing/frustrating.  I don't think its a matter of being afraid of
> change but rather of being consistent with the behaviour of other GIS
> software.  That being said there are times that i would appreciate having
> the editing behaviour Denis is suggesting and would be very interested in
> being able to choose.
>
> Andrew
>
> On Wed, Sep 24, 2014 at 11:27 PM, Denis Rouzaud 
> wrote:
>
>>
>> On 25.09.2014 08:02, Nathan Woodrow wrote:
>>
>> Hey Denis,
>>
>>  There is a 4th option of course and that is a key modifier for override
>> to do click-click.  I was planning on doing that a while ago when I thought
>> about the same thing.
>>
>>  So adding something like shift+click to enabled click-click mode.
>>
>>  Not sure if that is better but there is not a good way to change this
>> kind of thing.
>>
>>  - Nathan
>>
>>
>> Or we use the modifier for the drag'n'drop, if people like to keep a
>> button mouse pressed, they don't mind using one more key... just joking!
>>
>> Modifiers are a pain when you use the tools a lot.
>>
>> Anyway, if we do this, this can be combined with the options (solution 3)
>> Standard mode: simple click: drag'ndrop, shift: click-click
>> CAD mode: simple click: click-clcik, shift: drag'n'drop
>>
>>
>>
>>
>>
>> On Thu, Sep 25, 2014 at 3:46 PM, Denis Rouzaud 
>> wrote:
>>
>>>  Hi all,
>>>
>>> I'll try to summarize.
>>>
>>> *QEP*: I don't mind doing one, but I think it's a bit early since we
>>> are still discussing.
>>>
>>> *Problematic*: Drag'n'drop map tools prevent from enhancing CAD tools
>>> in QGIS. For this, it is *required *to add click-click to all map tools.
>>>
>>> *Other softwares:*
>>> CAD softwares use click-click actions while design and GIS (Mapinfo,
>>> what about ESRI?) use drag'n'drop.
>>> New users or even current users might be afraid of such a change.
>>>
>>> *Pros of methods:*
>>> Advantages of click-clik:
>>> * allow other actions to be done in the movement
>>> * allow cancelling the action (this was not pointed out yet)
>>> Advantages of drag'n'drop
>>> * More intuitive (for non-CAD users, which I believe is the majority)
>>>
>>> I see *3 (and a half) solutions* (thanks to Matthias for pointing some):
>>>
>>> 1.* Replace current* drag'n'drop to click-click
>>> + simplest solution to maintain
>>> - need time for new users to get used to this
>>>
>>> 2.* Enable both* click-clik and drag'n'drop: a short click will free
>>> the node/feature while a long click (*) will allow drag'n'drop.
>>> + both solutions are here
>>> - might be confusing for a "standard" user to make a short click and
>>> have a node moving without knowing what to do (although escape would cancel
>>> the thing)
>>>
>>> 3. Provide both behaviours and *choose which one to use in options*
>>> (e.g. enable CAD behaviour for map tools).
>>> + both solutions are here
>>> - behaviour not coherent along the different installations
>>>
>>> half solution: click-click in map tools, allow drag'n'drop in the main
>>> identify tool. Like *Microstation*.
>>> - this works only for move features (i.e. not feasible for rotate and
>>> node tools)
>>>
>>> Please comment these solutions, to see if there's a consensus.
>>> I'll start and vote for 1. ;)
>>>
>>>
>>> Cheers,
>>> Denis
>>>
>>>
>>> * The determination of what should be done is made on the distance in
>>> pixels from the press position to the release position. If it's small it is
>>> considered as a short. Time might also get into consideration: if you
>>> long-click but don't move it could be considered as cancel.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 24.09.2014 10:56, Deni

Re: [Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools

[Andrew]

I tested the editing tools in ArcMap 10.2 and moving nodes and features is
drag and drop.

a

On Wed, Sep 24, 2014 at 10:46 PM, Denis Rouzaud 
wrote:

>  Hi all,
>
> I'll try to summarize.
>
> *QEP*: I don't mind doing one, but I think it's a bit early since we are
> still discussing.
>
> *Problematic*: Drag'n'drop map tools prevent from enhancing CAD tools in
> QGIS. For this, it is *required *to add click-click to all map tools.
>
> *Other softwares:*
> CAD softwares use click-click actions while design and GIS (Mapinfo, what
> about ESRI?) use drag'n'drop.
> New users or even current users might be afraid of such a change.
>
> *Pros of methods:*
> Advantages of click-clik:
> * allow other actions to be done in the movement
> * allow cancelling the action (this was not pointed out yet)
> Advantages of drag'n'drop
> * More intuitive (for non-CAD users, which I believe is the majority)
>
> I see *3 (and a half) solutions* (thanks to Matthias for pointing some):
>
> 1.* Replace current* drag'n'drop to click-click
> + simplest solution to maintain
> - need time for new users to get used to this
>
> 2.* Enable both* click-clik and drag'n'drop: a short click will free the
> node/feature while a long click (*) will allow drag'n'drop.
> + both solutions are here
> - might be confusing for a "standard" user to make a short click and have
> a node moving without knowing what to do (although escape would cancel the
> thing)
>
> 3. Provide both behaviours and *choose which one to use in options* (e.g.
> enable CAD behaviour for map tools).
> + both solutions are here
> - behaviour not coherent along the different installations
>
> half solution: click-click in map tools, allow drag'n'drop in the main
> identify tool. Like *Microstation*.
> - this works only for move features (i.e. not feasible for rotate and node
> tools)
>
> Please comment these solutions, to see if there's a consensus.
> I'll start and vote for 1. ;)
>
>
> Cheers,
> Denis
>
>
> * The determination of what should be done is made on the distance in
> pixels from the press position to the release position. If it's small it is
> considered as a short. Time might also get into consideration: if you
> long-click but don't move it could be considered as cancel.
>
>
>
>
>
>
>
> On 24.09.2014 10:56, Denis Rouzaud wrote:
>
> Hi all,
>
> There is somehow an inconsistency in the behaviour of the current editing
> map tools.
>
> Some, like add features, uses the left click to trigger the action.
> Others, like the node tool or move feature use press-pan-release mouse
> events:
> * mouse press to select the node/feature
> * mouse mouse to move it
> * mouse release sets the position.
>
> I would propose to standardise this and for the latter tools propose the
> following work flow:
> * left click enables the move
> * left click again to validate at position
> * or right click to cancel
>
> Why changing this?
>
> If you look at CAD software, they also use the proposed approach. And
> there's a reason for doing so, which is valid for QGIS too.
>
> We are looking at improving the CAD tools in QGIS. In this area, I
> recommend trying the fantastic CADinput plugin made by Olivier Dalang. The
> plugin works on top of any map tool and enables CAD tools for each of them.
>
> The problem with the press-pan-release map tools is that you can't truly
> interact while you are actually in the action of the map tool (holding the
> click):
> * you can't click anymore and this prevents from using intermediate points
> (you have to use the tool several times and repeat the operation as many
> times as intermediate points you need)
> * it is not really user friendly to have to press keys while holing the
> click
>
> This is why, changing the map tools behaviour is requested if we want to
> go further with CAD tools in QGIS.
>
> Regarding the future of CAD tools in QGIS, I am quite sure the plugin
> proposed by Olivier would be a good way to go for QGIS, but it still might
> be a bit early to integrate it in core. The idea is rather first to extend
> the API and propose ready to use methods, so it will be easy to implement
> your preferred solution in a plugin.
>
> But first, we need to standardise the map tools.
>
> So, the bottom line, any objection to changing the behaviour of:
> * edit node tool
> * move feature
> * rotate feature
> * move label
> * rotate label
> * any other press-pan-release map tool that I am not aware of
> ???
>
> Best wishes,
>
> Denis
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] standardisation of the editing map tools: modify behaviour of press-pan-release tools

[Andrew]

I also would vote for option 3.  I do quite a bit of digitising/editing in
QGIS.  I am used to the default behaviour though there are times i wish for
the editing tools to act as Denis has proposed.  I think it makes sense for
QGIS' default behaviour to be consistent for people coming from other GIS
software. In my mind QGIS is foremost a GIS and should behave as such.  So
i don't think 1 is a good option.  also, 2 sees like it could be
confusing/frustrating.  I don't think its a matter of being afraid of
change but rather of being consistent with the behaviour of other GIS
software.  That being said there are times that i would appreciate having
the editing behaviour Denis is suggesting and would be very interested in
being able to choose.

Andrew

On Wed, Sep 24, 2014 at 11:27 PM, Denis Rouzaud 
wrote:

>
> On 25.09.2014 08:02, Nathan Woodrow wrote:
>
> Hey Denis,
>
>  There is a 4th option of course and that is a key modifier for override
> to do click-click.  I was planning on doing that a while ago when I thought
> about the same thing.
>
>  So adding something like shift+click to enabled click-click mode.
>
>  Not sure if that is better but there is not a good way to change this
> kind of thing.
>
>  - Nathan
>
>
> Or we use the modifier for the drag'n'drop, if people like to keep a
> button mouse pressed, they don't mind using one more key... just joking!
>
> Modifiers are a pain when you use the tools a lot.
>
> Anyway, if we do this, this can be combined with the options (solution 3)
> Standard mode: simple click: drag'ndrop, shift: click-click
> CAD mode: simple click: click-clcik, shift: drag'n'drop
>
>
>
>
>
> On Thu, Sep 25, 2014 at 3:46 PM, Denis Rouzaud 
> wrote:
>
>>  Hi all,
>>
>> I'll try to summarize.
>>
>> *QEP*: I don't mind doing one, but I think it's a bit early since we are
>> still discussing.
>>
>> *Problematic*: Drag'n'drop map tools prevent from enhancing CAD tools in
>> QGIS. For this, it is *required *to add click-click to all map tools.
>>
>> *Other softwares:*
>> CAD softwares use click-click actions while design and GIS (Mapinfo, what
>> about ESRI?) use drag'n'drop.
>> New users or even current users might be afraid of such a change.
>>
>> *Pros of methods:*
>> Advantages of click-clik:
>> * allow other actions to be done in the movement
>> * allow cancelling the action (this was not pointed out yet)
>> Advantages of drag'n'drop
>> * More intuitive (for non-CAD users, which I believe is the majority)
>>
>> I see *3 (and a half) solutions* (thanks to Matthias for pointing some):
>>
>> 1.* Replace current* drag'n'drop to click-click
>> + simplest solution to maintain
>> - need time for new users to get used to this
>>
>> 2.* Enable both* click-clik and drag'n'drop: a short click will free the
>> node/feature while a long click (*) will allow drag'n'drop.
>> + both solutions are here
>> - might be confusing for a "standard" user to make a short click and have
>> a node moving without knowing what to do (although escape would cancel the
>> thing)
>>
>> 3. Provide both behaviours and *choose which one to use in options*
>> (e.g. enable CAD behaviour for map tools).
>> + both solutions are here
>> - behaviour not coherent along the different installations
>>
>> half solution: click-click in map tools, allow drag'n'drop in the main
>> identify tool. Like *Microstation*.
>> - this works only for move features (i.e. not feasible for rotate and
>> node tools)
>>
>> Please comment these solutions, to see if there's a consensus.
>> I'll start and vote for 1. ;)
>>
>>
>> Cheers,
>> Denis
>>
>>
>> * The determination of what should be done is made on the distance in
>> pixels from the press position to the release position. If it's small it is
>> considered as a short. Time might also get into consideration: if you
>> long-click but don't move it could be considered as cancel.
>>
>>
>>
>>
>>
>>
>>
>> On 24.09.2014 10:56, Denis Rouzaud wrote:
>>
>> Hi all,
>>
>> There is somehow an inconsistency in the behaviour of the current editing
>> map tools.
>>
>> Some, like add features, uses the left click to trigger the action.
>> Others, like the node tool or move feature use press-pan-release mouse
>> events:
>> * mouse press to select the node/feature
>> * mouse mouse to move it
>> * mouse release sets the position.
>>
>> I would propose to standardise this and for the latter tools propose the
>> following work flow:
>> * left click enables the move
>> * left click again to validate at position
>> * or right click to cancel
>>
>> Why changing this?
>>
>> If you look at CAD software, they also use the proposed approach. And
>> there's a reason for doing so, which is valid for QGIS too.
>>
>> We are looking at improving the CAD tools in QGIS. In this area, I
>> recommend trying the fantastic CADinput plugin made by Olivier Dalang. The
>> plugin works on top of any map tool and enables CAD tools for each of them.
>>
>> The problem with the press-pan-release map tools is that you can't truly
>> 

Re: [Qgis-developer] Memory Layers - some proposals

[Chris Crook]

Hi

I think this depends a bit upon your perception of the world.  As a developer 
you are aware that this is a memory layer, and so volatile by nature.

On the other hand as a user this is not necessarily a memory layer, it is just 
part of your project, and may have come from some plugin or process that didn't 
explicitly mention "memory layer".  So they expect their data to be saved when 
they close the project.

I don't think anyone could question whether or not QGIS should warn you if you 
are going to lose data.  It shouldn't casually discard information you have 
worked on.

So the only question in my mind is whether or not it can save the memory data 
without requiring you to save it to some GIS format.  I think the answer is 
that it should (but then I'm biased - I wrote the MemoryLayerSaver plugin to 
address this issue for myself).

Again from a user point of view I think this data is part of the project, so it 
makes sense to save it with the project.  It isn't necessarily something that 
is wanted for anything else.  So why would they be bothered with having to 
choose a format and file location to do so.

Secondly there is convenience.  Sometimes you just want to be able to save the 
project and switch to some other work without having to worry about all sorts 
of "are you sure" or deciding where to save bits that you thought were part of 
the project.

The MemoryLayerSaver plugin at the moment saves to a QDataStream - a completely 
unconventional format chosen for convenience as it minimizes the risks of 
altering data by moving to another format.  I think SQLite would be cleaner.  
However the main point of the memory layer is that it isn't used by anything 
else ... so I don't see this as a big drawback compared to the advantages of 
having the layers saved.

Cheers
Chrsi

From: Matthias Kuhn [matthias.k...@gmx.ch]
Sent: 25 September 2014 19:19
To: Nyall Dawson
Cc: qgis-developer
Subject: Re: [Qgis-developer] Memory Layers - some proposals

Hi,

Please excuse my ignorance, but

Why would you want a memory (as in RAM) layer when you want permanent data?

For portability reasons?
That's fine, but then we should offer a possibility to support
portability support for a real geo-format (with spatial index and all
the goodies). To stuff it into the project file there can be support
from a plugin, but I would not vote for adding this to core.

To me it seems that the current demand for this comes mainly from wrong
expectations created by the name (and people subsequently loosing data).
And we can fix the name.
For the portability issue, I'd rather go the longer way but get it right.

Regards
Matthias


This message contains information, which may be in confidence and may be 
subject to legal privilege. If you are not the intended recipient, you must not 
peruse, use, disseminate, distribute or copy this message. If you have received 
this message in error, please notify us immediately (Phone 0800 665 463 or 
i...@linz.govt.nz) and destroy the original message. LINZ accepts no 
responsibility for changes to this email, or for any attachments, after its 
transmission from LINZ. Thank You.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools

[Bob and Deb]

Hi All,

I like the idea of a switch between Graphic and CAD mode.  How about
putting a toggle button near the Render checkbox.  Then all users will know
which mode they are in.

-Bob (aka cgs_bob)
On Sep 24, 2014 11:49 PM, "Andreas Neumann"  wrote:

> Hi,
>
> I think we should be open-minded towards Denis ideas and not
> categorically reject any changes in curent behaviour. Enabling the CAD
> mode enables a lot of possibilities compared to the current mode.
>
> I am not a CAD expert either, but I am often impressed about how
> efficiently my Autocad colleagues can edit/construct data.
>
> Therefore I would support the option to switch between Graphics/CAD
> mode. There could even be a button in the editing toolbar switching
> between the two modes, though I would expect that people would like to
> stay in one mode most of the time, once they get used to either mode.
>
> From Denis proposals listed below I would prefer option 3 (Provide both
> behaviours and choose which one to use in options). The above suggested
> switch mode button or a modifier key could be added as well, though I
> see it as convenience and not absolutely necessary at the start.
>
> Andreas
>
> Am 25.09.2014 05:46, schrieb Denis Rouzaud:
> > Hi all,
> >
> > I'll try to summarize.
> >
> > *QEP*: I don't mind doing one, but I think it's a bit early since we are
> > still discussing.
> >
> > *Problematic*: Drag'n'drop map tools prevent from enhancing CAD tools in
> > QGIS. For this, it is *required *to add click-click to all map tools.
> >
> > *Other softwares:*
> > CAD softwares use click-click actions while design and GIS (Mapinfo,
> > what about ESRI?) use drag'n'drop.
> > New users or even current users might be afraid of such a change.
> >
> > *Pros of methods:*
> > Advantages of click-clik:
> > * allow other actions to be done in the movement
> > * allow cancelling the action (this was not pointed out yet)
> > Advantages of drag'n'drop
> > * More intuitive (for non-CAD users, which I believe is the majority)
> >
> > I see *3 (and a half) solutions* (thanks to Matthias for pointing some):
> >
> > 1.*Replace current* drag'n'drop to click-click
> > + simplest solution to maintain
> > - need time for new users to get used to this
> >
> > 2.*Enable both* click-clik and drag'n'drop: a short click will free the
> > node/feature while a long click (*) will allow drag'n'drop.
> > + both solutions are here
> > - might be confusing for a "standard" user to make a short click and
> > have a node moving without knowing what to do (although escape would
> > cancel the thing)
> >
> > 3. Provide both behaviours and *choose which one to use in options*
> > (e.g. enable CAD behaviour for map tools).
> > + both solutions are here
> > - behaviour not coherent along the different installations
> >
> > half solution: click-click in map tools, allow drag'n'drop in the main
> > identify tool. Like *Microstation*.
> > - this works only for move features (i.e. not feasible for rotate and
> > node tools)
> >
> > Please comment these solutions, to see if there's a consensus.
> > I'll start and vote for 1. ;)
> >
> >
> > Cheers,
> > Denis
> >
> >
> > * The determination of what should be done is made on the distance in
> > pixels from the press position to the release position. If it's small it
> > is considered as a short. Time might also get into consideration: if you
> > long-click but don't move it could be considered as cancel.
> >
> >
> >
> >
> >
> >
> > On 24.09.2014 10:56, Denis Rouzaud wrote:
> >> Hi all,
> >>
> >> There is somehow an inconsistency in the behaviour of the current
> >> editing map tools.
> >>
> >> Some, like add features, uses the left click to trigger the action.
> >> Others, like the node tool or move feature use press-pan-release mouse
> >> events:
> >> * mouse press to select the node/feature
> >> * mouse mouse to move it
> >> * mouse release sets the position.
> >>
> >> I would propose to standardise this and for the latter tools propose
> >> the following work flow:
> >> * left click enables the move
> >> * left click again to validate at position
> >> * or right click to cancel
> >>
> >> Why changing this?
> >>
> >> If you look at CAD software, they also use the proposed approach. And
> >> there's a reason for doing so, which is valid for QGIS too.
> >>
> >> We are looking at improving the CAD tools in QGIS. In this area, I
> >> recommend trying the fantastic CADinput plugin made by Olivier Dalang.
> >> The plugin works on top of any map tool and enables CAD tools for each
> >> of them.
> >>
> >> The problem with the press-pan-release map tools is that you can't
> >> truly interact while you are actually in the action of the map tool
> >> (holding the click):
> >> * you can't click anymore and this prevents from using intermediate
> >> points (you have to use the tool several times and repeat the
> >> operation as many times as intermediate points you need)
> >> * it is not really user friendly to have to press keys while holing

[Qgis-developer] mapRenderer.render(imagePainter)

[Geo DrinX]

Hello,

I noticed that using  the.render()function  with  pyQgis > 2.2
the labels are not  visible.

This is my test source code :


iface = qgis.utils.iface

mapRenderer = mapCanvas.mapRenderer()
mapRect = mapRenderer.extent()
width = mapRenderer.width()
height = mapRenderer.height()
srs = mapRenderer.destinationCrs()

# create output image and initialize it
image = QImage(QSize(width, height), QImage.Format_ARGB32)
image.fill(0)

#adjust map canvas (renderer) to the image size and render
imagePainter = QPainter(image)

zoom = 1
target_dpi = int(round(zoom * mapRenderer.outputDpi()))


mapRenderer.setOutputSize(QSize(width, height), target_dpi)

mapRenderer.render(imagePainter)
imagePainter.end()

xN = mapRect.xMinimum()
yN = mapRect.yMinimum()

nomePNG = ("TestImage")

input_file = out_folder + "/" + nomePNG + ".png"

image.save(input_file, "png")


Somebody can test it and confirm ?Perhaps ,  it was introduced some
other parameter for the labels ,  from 2.4 version ?


Thank you in advance

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

Re: [Qgis-developer] standardisation of the editing map tools: modify behaviour of press-pan-release tools

[Olivier Dalang]

Hello,

Thanks Denis for the initiative ;)

If we are to provide both behaviours, I'm strongly in favour of a user
preference rather than the modifier key. At some point, we'll want to use
modifier keys for other uses (lock orthogonal move, alternate tool mode,
etc.), and this will get very confusing.

To me, the reasons to implement a click-move-click behaviour becomes
evident when you have to edit a lot of features. It's much more effort to
achieve precision while holding the button (tension in the hand), you must
be a finger acrobat to pan/zoom while editing, and you can't answer the
phone neither ;)

Still, I'd suggest once the click-move-click feature is developed, all of
us try it for one week or so, and only then we decide whether we want to
provide both modes or not.


While on the topic of map tools, I was thinking of the following
improvements to the QgsMapTool class:

*1. Implement snapping directly in the QgsMapTool class rather than in each
subclass*
>From what I understand of the source, currently, more or less every
subclass of QgsMapTools provides it's own logic for snapping (or more
generally: for conversion from pixel coordinates click to map coordinates
click). In this context, I don't see how we can achieve cleanly a
cross-tool numerical input system.

*2. Implement pre-click highlighting of features/nodes/edges/rings/...
(depending on what the current tool accepts)*
This type of visual feedback will make editing much more intuitive. Take
the "move node" tool. It's only by mistake that user can learn that it also
acts on edges. Take the move tool : when two features overlap, you have no
idea on which feature you'll act. Etc. This could also be done directly in
QgsMapTool, so that we are sure it's consistent across tools.

Think at how easy it would then be to develop other map tools : almost only
the tool logic, and no boilerplate code at all. What do you think ?


Best regards,

Olivier



On Sep 25, 2014 8:49 AM, "Andreas Neumann"  wrote:

> Hi,
>
> I think we should be open-minded towards Denis ideas and not
> categorically reject any changes in curent behaviour. Enabling the CAD
> mode enables a lot of possibilities compared to the current mode.
>
> I am not a CAD expert either, but I am often impressed about how
> efficiently my Autocad colleagues can edit/construct data.
>
> Therefore I would support the option to switch between Graphics/CAD
> mode. There could even be a button in the editing toolbar switching
> between the two modes, though I would expect that people would like to
> stay in one mode most of the time, once they get used to either mode.
>
> From Denis proposals listed below I would prefer option 3 (Provide both
> behaviours and choose which one to use in options). The above suggested
> switch mode button or a modifier key could be added as well, though I
> see it as convenience and not absolutely necessary at the start.
>
> Andreas
>
> Am 25.09.2014 05:46, schrieb Denis Rouzaud:
> > Hi all,
> >
> > I'll try to summarize.
> >
> > *QEP*: I don't mind doing one, but I think it's a bit early since we are
> > still discussing.
> >
> > *Problematic*: Drag'n'drop map tools prevent from enhancing CAD tools in
> > QGIS. For this, it is *required *to add click-click to all map tools.
> >
> > *Other softwares:*
> > CAD softwares use click-click actions while design and GIS (Mapinfo,
> > what about ESRI?) use drag'n'drop.
> > New users or even current users might be afraid of such a change.
> >
> > *Pros of methods:*
> > Advantages of click-clik:
> > * allow other actions to be done in the movement
> > * allow cancelling the action (this was not pointed out yet)
> > Advantages of drag'n'drop
> > * More intuitive (for non-CAD users, which I believe is the majority)
> >
> > I see *3 (and a half) solutions* (thanks to Matthias for pointing some):
> >
> > 1.*Replace current* drag'n'drop to click-click
> > + simplest solution to maintain
> > - need time for new users to get used to this
> >
> > 2.*Enable both* click-clik and drag'n'drop: a short click will free the
> > node/feature while a long click (*) will allow drag'n'drop.
> > + both solutions are here
> > - might be confusing for a "standard" user to make a short click and
> > have a node moving without knowing what to do (although escape would
> > cancel the thing)
> >
> > 3. Provide both behaviours and *choose which one to use in options*
> > (e.g. enable CAD behaviour for map tools).
> > + both solutions are here
> > - behaviour not coherent along the different installations
> >
> > half solution: click-click in map tools, allow drag'n'drop in the main
> > identify tool. Like *Microstation*.
> > - this works only for move features (i.e. not feasible for rotate and
> > node tools)
> >
> > Please comment these solutions, to see if there's a consensus.
> > I'll start and vote for 1. ;)
> >
> >
> > Cheers,
> > Denis
> >
> >
> > * The determination of what should be done is made on the distance in
> > pixels from the press posi

Re: [Qgis-developer] Get QGIS project EPSG code

[PIERRE Sylvain]

Yes, I missunderstood  
postgisSrid
 () method which in fact return EPSG code (not sure of that but in my case 
postgissrid and EPSG code are equal...)


De : Denis Rouzaud [mailto:denis.rouz...@gmail.com]
Envoyé : vendredi 26 septembre 2014 14:00
À : PIERRE Sylvain; QGIS Developer
Objet : Re: [Qgis-developer] Get QGIS project EPSG code

Then iface.mapCanvas().mapRenderer().destinationCrs() should do the job, no?

On 26.09.2014 13:53, PIERRE Sylvain wrote:
Thanks

It should works, but...
I'm working with 2.2 API and mapSettings doesn't exist for this release.
I should have to migrate my devs (for other reasons ;-)

Sylvain

De : Denis Rouzaud [mailto:denis.rouz...@gmail.com]
Envoyé : vendredi 26 septembre 2014 13:43
À : PIERRE Sylvain; QGIS Developer
Objet : Re: [Qgis-developer] Get QGIS project EPSG code

Hi,

iface.mapCanvas().mapSettings().destinationCrs()

Cheers,

Denis
On 26.09.2014 13:31, PIERRE Sylvain wrote:
Hello,

PyQGIS question:
I just want to get EPSG code set at project level when on-the-fly reprojection 
is active.
I suppose it should be available in destinationCrs() properties from 
mapRenderer, but nothing found.

Any idea?

Thanks

Sylvain





___

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] [ANNOUNCE] 2.5 feature freeze begun

[Jürgen E . Fischer]

Hi,

I'd like to remind everyone that the 2.5 development cycle ended at 12:00
UTC. We are now in feature freeze on the road to the 2.6 release on 2014-10-24
http://www.timeanddate.com/countdown/generic?p0=1440&iso=20141024T12&year=2014&month=10&day=24&hour=12&min=0&sec=0&msg=2.6%20Release
(almost 27 days away; see also roadmap
).

Now *we*, *the community*, need to prepare QGIS for release. No new features
will be added anymore. *Users*, if not already begun, should now start
extensive testing of master and report bugs on the hub .
*Developers* should move their focus from creating new features to fixing bugs.
*Translators* can can continue their work.

The nightly builds of QGIS testing available for Windows
, Linux (Debian
 and Ubuntu
) and Mac
OS  are now
effectively snapshots of what's going to be released.  Except of course for the
bugs that are going to be fixed until release day.  For Windows there will also
be weekly release candidates of the standalone installer
.

Lets keep up working together to make 2.6 another great release.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode 



signature.asc
Description: Digital signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [Processing] v.voronoi test shouldn't be logged

[Victor Olaya]

good idea. Let's put it in my TODO list for the HF ;-)

Thanks!

2014-09-26 13:31 GMT+02:00 G. Allegri :

> Every time a GRASS alorithm is run the following log appears:
>
>
> processing.runalg("grass:v.voronoi","C:/OSGeo4W/apps/qgis/./python/plugins\\processing\\tests\\data\\points.shp",False,False,"270778.60198,270855.745301,4458921.97814,4458983.8488",-1,0.0001,0,None)
>
> I suppose it depends on the test at line
> https://github.com/giohappy/QGIS/blob/master/python/plugins/processing/algs/grass/GrassUtils.py#L371
>
> It's run every time an algorithm's dialog is opened:
> https://github.com/giohappy/QGIS/blob/master/python/plugins/processing/algs/grass/GrassAlgorithm.py#L491
>
> If a different strategy to test GRASS cannot be found we could at least
> disable the test from being logged because it's definetly counterintuitive
> for a user to understand why it's there. Initially I thought it was a bug
> or an error during the executions of my algorithms...
>
> Giovanni
>
> --
> Giovanni Allegri
> http://about.me/giovanniallegri
> Twitter: https://twitter.com/_giohappy_
> blog: http://blog.spaziogis.it
> GEO+ geomatica in Italia http://bit.ly/GEOplus
>
> ___
> 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] Memory Layers - some proposals

[Vincent Picavet]

Hi Nathan, all,

Le jeudi 25 septembre 2014 09:56:58, Nathan Woodrow a écrit :
[..]

> IMO we could in the future use sqlite in memory datastore for the memory
> provider which gives us a lot more options and range.

Hugo is currently writing a QEP to exactly do that and as well address some 
issues regarding database features re-implementation.
He should publish it for review sooner or later.

This could help handle the memory layer topic, but actually is a wider issue.

Vincent

> 
> Changing the format of the project file to something that isn't xml is a
> interesting idea however it's not something that should be rushed into
> without consideration so I think that is a very different topic.
> 
> - Nathan
> 
> On Thu, Sep 25, 2014 at 5:19 PM, Matthias Kuhn  wrote:
> > Hi,
> > 
> > Please excuse my ignorance, but
> > 
> > Why would you want a memory (as in RAM) layer when you want permanent
> > data?
> > 
> > For portability reasons?
> > That's fine, but then we should offer a possibility to support
> > portability support for a real geo-format (with spatial index and all
> > the goodies). To stuff it into the project file there can be support
> > from a plugin, but I would not vote for adding this to core.
> > 
> > To me it seems that the current demand for this comes mainly from wrong
> > expectations created by the name (and people subsequently loosing data).
> > And we can fix the name.
> > For the portability issue, I'd rather go the longer way but get it right.
> > 
> > Regards
> > Matthias
> > 
> > ___
> > 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] Get QGIS project EPSG code

[Denis Rouzaud]

Then iface.mapCanvas().mapRenderer().destinationCrs() should do the job, no?


On 26.09.2014 13:53, PIERRE Sylvain wrote:


Thanks

It should works, but…

I’m working with 2.2 API and mapSettings doesn’t exist for this release.

I should have to migrate my devs (for other reasons ;-)

Sylvain

*De :*Denis Rouzaud [mailto:denis.rouz...@gmail.com]
*Envoyé :* vendredi 26 septembre 2014 13:43
*À :* PIERRE Sylvain; QGIS Developer
*Objet :* Re: [Qgis-developer] Get QGIS project EPSG code

Hi,

iface.mapCanvas().mapSettings().destinationCrs()

Cheers,

Denis

On 26.09.2014 13:31, PIERRE Sylvain wrote:

Hello,

PyQGIS question:

I just want to get EPSG code set at project level when on-the-fly
reprojection is active.

I suppose it should be available in destinationCrs() properties
from mapRenderer, but nothing found.

Any idea?

Thanks

Sylvain




___

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] Get QGIS project EPSG code

[PIERRE Sylvain]

Thanks

It should works, but...
I'm working with 2.2 API and mapSettings doesn't exist for this release.
I should have to migrate my devs (for other reasons ;-)

Sylvain

De : Denis Rouzaud [mailto:denis.rouz...@gmail.com]
Envoyé : vendredi 26 septembre 2014 13:43
À : PIERRE Sylvain; QGIS Developer
Objet : Re: [Qgis-developer] Get QGIS project EPSG code

Hi,

iface.mapCanvas().mapSettings().destinationCrs()

Cheers,

Denis
On 26.09.2014 13:31, PIERRE Sylvain wrote:
Hello,

PyQGIS question:
I just want to get EPSG code set at project level when on-the-fly reprojection 
is active.
I suppose it should be available in destinationCrs() properties from 
mapRenderer, but nothing found.

Any idea?

Thanks

Sylvain




___

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] Get QGIS project EPSG code

[Denis Rouzaud]

Hi,

iface.mapCanvas().mapSettings().destinationCrs()

Cheers,

Denis

On 26.09.2014 13:31, PIERRE Sylvain wrote:


Hello,

PyQGIS question:

I just want to get EPSG code set at project level when on-the-fly 
reprojection is active.


I suppose it should be available in destinationCrs() properties from 
mapRenderer, but nothing found.


Any idea?

Thanks

Sylvain



___
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] [Processing] v.voronoi test shouldn't be logged

[G. Allegri]

Every time a GRASS alorithm is run the following log appears:

processing.runalg("grass:v.voronoi","C:/OSGeo4W/apps/qgis/./python/plugins\\processing\\tests\\data\\points.shp",False,False,"270778.60198,270855.745301,4458921.97814,4458983.8488",-1,0.0001,0,None)

I suppose it depends on the test at line
https://github.com/giohappy/QGIS/blob/master/python/plugins/processing/algs/grass/GrassUtils.py#L371

It's run every time an algorithm's dialog is opened:
https://github.com/giohappy/QGIS/blob/master/python/plugins/processing/algs/grass/GrassAlgorithm.py#L491

If a different strategy to test GRASS cannot be found we could at least
disable the test from being logged because it's definetly counterintuitive
for a user to understand why it's there. Initially I thought it was a bug
or an error during the executions of my algorithms...

Giovanni

-- 
Giovanni Allegri
http://about.me/giovanniallegri
Twitter: https://twitter.com/_giohappy_
blog: http://blog.spaziogis.it
GEO+ geomatica in Italia http://bit.ly/GEOplus
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Get QGIS project EPSG code

[PIERRE Sylvain]

Hello,

PyQGIS question:
I just want to get EPSG code set at project level when on-the-fly reprojection 
is active.
I suppose it should be available in destinationCrs() properties from 
mapRenderer, but nothing found.

Any idea?

Thanks

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

[Qgis-developer] [FEATURE][QGIS-Server] Legend filtering based on map in GetPrint Request

[René-Luc Dhont]

Hi devs,

Code freeze starts today and I have a new feature for QGIS-Server to be 
reviewed.
I opened a pull-request and assigned it to @mhugent but if someone else 
like @wonder-sk can validate it, I'll merge it.


This pull-request has be made for Legend filtering based on map in 
GetPrint Request


The legend in composition was fixed and did not represent the layers in 
the map.
With the work made by @wonder-sk  on 
layer-tree and QgsComposerLegend users will be able
to configure composer legend as based on all the project layer tree with 
auto-update

model or filtered by map.
This commit reused these two QgsComposerLegend's properties to filter it 
based on map in

GetPrint Request

The issue #4003 qgis_mapserver getPrint legend options can be closed.

Regards,
René-Luc D'Hont
3Liz
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer