[QGIS-Developer] why stop work python.exe in pyqgis standalone script anytime?

2017-07-08 Thread xristosss20
i want to create a simple standalone pyqgis script but i have some
Unexpectedly errors.

here my .bat file :

@echo off
SET OSGEO4W_ROOT=C:\OSGeo4W
call "%OSGEO4W_ROOT%"\bin\o4w_env.bat
call "%OSGEO4W_ROOT%"\apps\grass\grass-7.2.1\etc\env.bat
@echo off
path
%PATH%;%OSGEO4W_ROOT%\apps\qgis\bin;%OSGEO4W_ROOT%\apps\grass\grass-7.2.1\lib
set QGIS_PREFIX_PATH=%OSGEO4W_ROOT:\=/%/apps/qgis
SET PYCHARM="C:\Program Files\JetBrains\PyCharm 2017.1.4\bin\pycharm.exe"

set PYTHONPATH=%PYTHONPATH%;%OSGEO4W_ROOT%\apps\qgis\python;
set PYTHONPATH=%PYTHONPATH%;%OSGEO4W_ROOT%\apps\Python27\Lib\site-packages;

set QGISPATH=%OSGEO4W_ROOT%\apps\qgis

start "PyCharm aware of QGIS" /B %PYCHARM% %*
first i try to see if processing tool work nice.

here the code :

def test1():
qgs = QgsApplication([],True)
QgsApplication.setPrefixPath("C:/OSGeo4W/apps/qgis", True)
qgs.initQgis()
sys.path.append('C:/OSGeo4W/apps/qgis/python/plugins')
import processing
from processing.core.Processing import Processing
Processing.initialize()
print processing.alglist()
qgs.exitQgis()
test1()
work fine i take the list correct

after i try to see if work algorithm where i want

here the code :

def slope():
qgs = QgsApplication([],True)
QgsApplication.setPrefixPath("C:/OSGeo4W/apps/qgis", True)
qgs.initQgis()
sys.path.append('C:/OSGeo4W/apps/qgis/python/plugins')
import processing
from processing.core.Processing import Processing
Processing.initialize()
print processing.alghelp('gdalogr:slope')
qgs.exitQgis()

slope()
and i take this message :

C:\OSGeo4W\bin\python.exe C:/Users/username/PycharmProjects/untitled/test.py
ALGORITHM: Slope
INPUT 
BAND 
COMPUTE_EDGES 
ZEVENBERGEN 
AS_PERCENT 
SCALE 
OUTPUT 


None

Process finished with exit code 0
but anytime to try to run some script with complete code like this :

from qgis.core import QgsApplication
import sys
from qgis.core import QgsRasterLayer
from PyQt4.QtCore import QFileInfo


def slope(raster_path,slope_path):
qgs = QgsApplication([],True)
QgsApplication.setPrefixPath("C:/OSGeo4W/apps/qgis", True)
qgs.initQgis()
sys.path.append('C:/OSGeo4W/apps/qgis/python/plugins')
import processing
from processing.core.Processing import Processing
Processing.initialize()
fileInfo=QFileInfo(raster_path)
baseName=fileInfo.baseName()
rLayer = QgsRasterLayer(fileInfo.filePath(), baseName)
   
processing.runalg('gdalogr:slope',rLayer,1.0,True,True,False,1.0,slope_path)
qgs.exitQgis()

raster_path="C:/Users/username/Desktop/dem.tif"
slope_path="C:/Users/username/Desktop/slope.tif"
slope(raster_path,slope_path)
then before finish script the python.exe stop running :

 

and i take this message in pycharm :

C:\OSGeo4W\bin\python.exe
C:/Users/username/PycharmProjects/untitled/test1.py

Process finished with exit code -1073741819 (0xC005)
that message i take for all scripts with different python code and specific
different algorithms if i want to run it standalone using pycharm editor.

any idea why python.exe stop work anytime ?



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/why-stop-work-python-exe-in-pyqgis-standalone-script-anytime-tp5327125.html
Sent from the QGIS - Developer mailing list archive at Nabble.com.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 3.0 beta

2017-07-08 Thread Jürgen E . Fischer
Hi Richard,

On Sat, 08. Jul 2017 at 12:43:48 +0200, Richard Duivenvoorde wrote:
> Just for clarity, there IS already a possibility to test/view current
> master (3.0 development version == 2.99) for Windows users:
> 
> Either download the latest weekly 2.99 standalone installer from:
> http://qgis.org/downloads/weekly/
> 
> OR use
> 
> OSGeo4W package manager and install the "qgis-dev: QGIS nightly build of
> the development branch"

OR qgis-full-dev which also depends on a bunch of additional useful packages.

> AND to see the most info, ALSO install "qgis-dev-pdb: Debugging symbols
> for QGIS nightly build of the development branch"

AND now alos on qgis-dev-pdb.   PLUS qgis-full-dev is the base of the weekly
NSIS package.


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: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] rule based style copy+paste bug

2017-07-08 Thread zrx
Hello,

Excuse me for posting to the developers list, as I am not a QGIS developer, but 
the bug tracker seems to be even more difficult to access.

I'd like to call your attention a problem present at least since 2.16, and 
which is still there in 2.18.10 :

I have an approximately 50 years period of data to be presented geographically, 
and each year's corresponding layer should be able to be turned on/off. I 
created the first year's layer, then tried to copy+paste it, and modify the 
year in each layer's rule. The problem is that the pasted layers don't seem to 
be independent. It looks like they are created by some kind of shallow copy, 
thus sharing some of their attributes and data fields, like visibility for 
example.

Please correct this, or give me some hint if I make something wrong. Thanks in 
advance,
Peter
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [UI] Close the Data Source Manager after loading a layer or not?

2017-07-08 Thread Anita Graser
On Sat, Jul 8, 2017 at 12:33 PM, Richard Duivenvoorde 
wrote:
>
> PS I think there is another option somewhere to which has "Keep dialog
> open after", but I could not find it easily where I saw that.
>


​In Processing, you can define if the dialog should stay open after a tool
has finished successfully.

I always enable that because I usually want to check the log output.

Anita​
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 3.0 beta

2017-07-08 Thread Richard Duivenvoorde
On 08-07-17 11:48, Wondimagegn Tesfaye wrote:
> Dear Mattias, 
> 
> Thank you for the hard work! This is a good approach. Starting to
> testing the beta before the feature freeze is good to incorporate more
> feedback from the users and developers.

Just for clarity, there IS already a possibility to test/view current
master (3.0 development version == 2.99) for Windows users:

Either download the latest weekly 2.99 standalone installer from:
http://qgis.org/downloads/weekly/

OR use

OSGeo4W package manager and install the "qgis-dev: QGIS nightly build of
the development branch"
AND to see the most info, ALSO install "qgis-dev-pdb: Debugging symbols
for QGIS nightly build of the development branch"

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] [UI] Close the Data Source Manager after loading a layer or not?

2017-07-08 Thread Richard Duivenvoorde
Hi,

During some testing of current master/2.99 I use the Data Source Manager
dialog (one button to load them all) often to load just one layer or
service.

For this use-case (which is: the user just opens one layer and wants to
do something with it) it would be best when the dialog just closes itself.

Off course if you are creating a big project with a lot of layers, you
want the dialog to stay open until you are ready...

I was thinking: is it an idea to give the dialog a checkbox 'Close
Dialog after opening datasource'? So a user (like me) will have it
always close immediately and when you are recreating a bigger project it
can stay open?

Thoughts?

Regards,

Richard Duivenvoorde

PS I think there is another option somewhere to which has "Keep dialog
open after", but I could not find it easily where I saw that.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 3.0 beta

2017-07-08 Thread Wondimagegn Tesfaye
Dear Mattias,

Thank you for the hard work! This is a good approach. Starting to testing
the beta before the feature freeze is good to incorporate more feedback
from the users and developers.

Regards,
Wondimagegn

On Jul 8, 2017 11:13, "Matthias Kuhn"  wrote:

> Hi all,
>
> Not too far away we will enter feature freeze for QGIS 3.0 and will be
> trying to polish the next release as much as possible.
>
> During this time, a lot of testing will need to be done in order to be
> able to best spend the bugfixing time. There are a handful of people who
> regularly test nightlies and report bugs (thanks!).
>
> I wonder if it's possible to attract more testers for the next release
> by providing a "beta".
>
> I think releasing a version labelled "beta" at the beginning of the
> feature freeze (and another one half way through) will make more people
> aware of the upcoming release. This can lead to additional important
> testing from audience which otherwise would only "test" the final
> release (with a lower acceptance of bugs). Besides that, I think it will
> also be a good signal for devs to start porting plugin code and a very
> good preparation for end users marketing-wise.
>
> It will be best served with a blog post explaining how critical the
> bugfixing phase is for a release and how resources for this are allocated.
>
> It's just an idea I had in mind for some time. Does anyone dislike it?
>
> Thanks
> Matthias
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] FOSS4G Europe in Paris next week

2017-07-08 Thread kimaidou
Hi all

I will be present too !

2017-07-05 16:36 GMT+02:00 Yves Jacolin :

> Régis,
>
> I will be present all week so even for the code sprint!
>
> Y.
> On mercredi 5 juillet 2017 16:16:46 CEST Régis Haubourg wrote:
> > Hi all,
> > within two weeks  the FOSS4G Europe is held near Paris at the National
> > Geographic Institute School (ENSG) from tuesday 18th to 22nd of July.
> >
> > Will some of QGIS developers or other involved parties be there? That
> would
> > be nice to meet some of you.
> >
> >
> > Concerning QGIS, there will be some interesting talks or workshops:
> >
> > - GML application schema made easy in GDAL/OGR and QGIS workshop
> > - Lizmap workshop
> >
> > - QGIS server refactoring for QGIS 3 - talk
> > - Data Processing with QGIS -talk
> >
> >
> > See you there!
> >
> > Cheers
> > Régis (and all the Oslandia Team)
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 3.0 beta

2017-07-08 Thread Richard Duivenvoorde
On 08-07-17 10:13, Matthias Kuhn wrote:
> Hi all,
> 
> Not too far away we will enter feature freeze for QGIS 3.0 and will be
> trying to polish the next release as much as possible.
> 
> During this time, a lot of testing will need to be done in order to be
> able to best spend the bugfixing time. There are a handful of people who
> regularly test nightlies and report bugs (thanks!).
> 
> I wonder if it's possible to attract more testers for the next release
> by providing a "beta".
> 
> I think releasing a version labelled "beta" at the beginning of the
> feature freeze (and another one half way through) will make more people
> aware of the upcoming release. This can lead to additional important
> testing from audience which otherwise would only "test" the final
> release (with a lower acceptance of bugs). Besides that, I think it will
> also be a good signal for devs to start porting plugin code and a very
> good preparation for end users marketing-wise.
> 
> It will be best served with a blog post explaining how critical the
> bugfixing phase is for a release and how resources for this are allocated.
> 
> It's just an idea I had in mind for some time. Does anyone dislike it?

Yep, I was thinking about something like this too: BUT there is always
the tension between willing to show and test a new version AND giving
the average user an as stable possible QGIS to work with.
So either work with some beta's OR consider 3.0 (and 3.2?) more or less
as versions which will have some growing pains? Though that is hard to
sell to the average user I think...

Other wild ideas:
- call 3.0 something like: Beta, Troje or Atlantis ;-)

And do a lot of communication that people should really test it in the
actual/real workflows to catch actual usability issues. But also... do
keep in mind that due to the changes in api's, code, Qt, Python etc etc
it is more likely that things will break or crash.

Yesterday I hit the first crash screen (on a Windows machine):

https://files.gitter.im/qgis/QGIS/kjUe/image.png
(ended up as https://issues.qgis.org/issues/16810 by the way)

Nice work, Nathan!

And looking at it, 3.0/beta should probably also have debug info so the
Stack Trace is as descriptive as possible?

Regards,

Richard Duivenvoorde

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS 3.0 beta

2017-07-08 Thread Matthias Kuhn
Hi all,

Not too far away we will enter feature freeze for QGIS 3.0 and will be
trying to polish the next release as much as possible.

During this time, a lot of testing will need to be done in order to be
able to best spend the bugfixing time. There are a handful of people who
regularly test nightlies and report bugs (thanks!).

I wonder if it's possible to attract more testers for the next release
by providing a "beta".

I think releasing a version labelled "beta" at the beginning of the
feature freeze (and another one half way through) will make more people
aware of the upcoming release. This can lead to additional important
testing from audience which otherwise would only "test" the final
release (with a lower acceptance of bugs). Besides that, I think it will
also be a good signal for devs to start porting plugin code and a very
good preparation for end users marketing-wise.

It will be best served with a blog post explaining how critical the
bugfixing phase is for a release and how resources for this are allocated.

It's just an idea I had in mind for some time. Does anyone dislike it?

Thanks
Matthias
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Value entry using comma as decimal separator?

2017-07-08 Thread Richard Duivenvoorde
On 08-07-17 01:11, Nyall Dawson wrote:

> It's a trivial change to make to get the spin boxes to accept the
> local decimal separator, but this would prevent users entering "5.5"
> in those locales.
> 
> Can someone from one of these affected regions let me know what the
> correct behavior should be? I don't want to make the change if it
> breaks entry of 5.5 and that's the standard used in those locales.

My personal view:

In The Netherlands we also use comma as a decimal separator (don't most
european countries do?), and though I never use the Dutch locale myself,
I know ALL governmental organisations I've been run the Dutch
QGIS/localse just because Windows there is in Dutch (and set the Dutch
locale).

I also know in the Spreadsheet world this gives A LOT of trouble because
most average users are not even aware what 'locale' they are using... So
people sending a us-locale spreadsheet to a dutch-locale user is often
in trouble

This makes for example so that in modern Banking web applications they
check and you can use both , and . as decimal separator (probably there
is some heuristic in which they check:
- if there is only one type of separator
- if there is one, and it is just 2 position from the end
- it is used as decimal separator
etc etc
But... that is easier when you are only doing currency numbers...

I would not try to fight this locale war, or try to be smarter then
Qt/Windows:
IF people use a 'comma'-locale, they should use comma.
IF they do not like that: use us-locale

It is the same problem with the character encoding in shapefiles. People
are not aware of what they do, but 'we' as part of the Qt or Windows
should not try to be smarter then that world we are part of.

Untill the rest of the world come to their senses and start using the
comma as separator, use 24hr clocks (well preferably 100...), meters,
kilograms etc etc...

Regards,

Richard Duivenvoorde
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Value entry using comma as decimal separator?

2017-07-08 Thread Frank Sokolic

On 08/07/2017 01:11, Nyall Dawson wrote:

Hi all,

Following on from this conversation:
https://lists.osgeo.org/pipermail/qgis-developer/2017-July/049227.html

it seems we have issues in the qt5 builds under locales which use
commas as decimal separators. Under these locales entering a value
like "5,5"  in a spin box (such as those used in the symbol layer
properties) , then moving focus away from the widget, will discard the
changes.

I know *nothing* about what's the expected behavior here, but a quick
google search leads me to believe that most software follow QGIS'
approach and require users to always use ".", regardless of the locale
(e.g. [1]). Is this correct?

It's a trivial change to make to get the spin boxes to accept the
local decimal separator, but this would prevent users entering "5.5"
in those locales.

Can someone from one of these affected regions let me know what the
correct behavior should be? I don't want to make the change if it
breaks entry of 5.5 and that's the standard used in those locales.

Nyall

1. 
https://ux.stackexchange.com/questions/74369/is-a-decimal-comma-used-in-data-entry


Hi Nyall,

I'm in South Africa where the comma is the official decimal separator. 
If I set my locale to South Africa ZAF (both on Ubuntu Linux and 
Windows) then a comma is expected as the decimal separator. However, I 
have met very few people in South Africa who actually use a comma, or 
even know that it is our "official" decimal separator. Everyone uses a 
decimal point.


This leads to problems in QGIS, however. I'm using QGIS Master on Ubuntu 
17.04 set to locale ZAF and if, for example, I want to change a stroke 
width in the Styling Dock then this is what happens:


- I initially see the default stroke width displayed as 0,26 Millimeter.

- If I change the value by using the spinner all is fine. One click up 
and the value changes to 0,46.


- If I try type in a number such as 0,8 and push enter/tab the number is 
automatically changed to Hairline.


- If, instead, I type in the number with a decimal point 0.8 the number 
is accepted but the decimal point is automatically changed to a comma.


This is confusing, to say the least. The number has to be entered with a 
point but is displayed with a comma. For me the ideal would be to use a 
decimal point throughout and ditch the comma.


Frank.


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer