[Qgis-developer] Some notes of 2.2. OpenSuse 12.3 ""release"

[Kari Salovaara]

  
  
Hi,

thanks for all developers of huge and fantastic work again.
I've OpenSuse 12.3 updated about per midnight (GMT 24.2.2014 23:00).
and qgis2-2.2.0-6.1

I'd some notices of small "bugs". I was not able to use other
machinery so I don't know ..

1. Manage and Install Plugins ... -> Upgradeable ; I've two left
after I upgraded all others. 
mmqgis and Qgis2threejs




both tell "There is a new version available"
I've tried both Upgrade all and Upgrade plugin. Restarted QGIS and
tried again. They just won't want to be upgraded.

Then
  I uninstalled mmqgis and installed again. Now it has been upgraded
  but is again in the list of upgradeable. If You look the numbering
  where I expect the error lie ?

  Installed version: 2014.01.06 (in
  /home/kari/.qgis2/python/plugins/mmqgis)
  Available version: 2014.1.6 (in QGIS Official Plugin Repository)

- and uninstall->install>result was also

Installed
  version: 0.06 (in /home/kari/.qgis2/python/plugins/Qgis2threejs)
  Available version: 0.6 (in QGIS Official Plugin Repository)

- those
  leading zeroes ?
  


2. jp2 (Jpeg2000) files don't work/render at all. That was not a
surprise in OpenSuse. Have to force kill and restart qgis.

3. in About -> License is missing (totally white) ;)

Regards,
Kari

PS. Installation
QGIS version    2.2.0-Valmiera    QGIS code revision    exported
Compiled against Qt    4.8.4    Running against Qt    4.8.4
Compiled against GDAL/OGR    1.10.1    Running against GDAL/OGR   
1.10.1
Compiled against GEOS    3.4.2-CAPI-1.8.2    Running against GEOS   
3.4.2-CAPI-1.8.2 r3921
PostgreSQL Client Version    9.2.4    SpatiaLite Version    4.1.1
QWT Version    5.2.3    PROJ.4 Version    480
QScintilla2 Version    
-- 
Kari Salovaara
Hanko, Finland

"Volunteers do not necessarily have the time; they just have the heart." ~Elizabeth Andrew
  

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

Re: [Qgis-developer] Identify with Feature Form on QGIS 2.2

[Nathan Woodrow]

The workaround for this is to have the identify dialog docked which will
stop it opening over the top.   I have hidden mine behind the browser dock
so it doesn't show up all the time.

- Nathan


On Tue, Feb 25, 2014 at 12:09 PM, Nathan Woodrow wrote:

> hmmm that is a real bugger.  Yeah I think kind of thing warrants a bug fix
> release.  This will kill QGIS for most users who do data entry, which is
> most of the people I know.
>
> - Nathan
>
>
> On Tue, Feb 25, 2014 at 2:15 AM, matteo  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Confirmed. Debian 7.3 with qgis 2.3 master updated this morning.
>>
>> Matteo
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.12 (GNU/Linux)
>> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJTC2//AAoJEBy7UYf0gaEOZ8gIALX9YhsFuStCxtWJXYWz7/dd
>> X5OgRfOE8ikQax6+BMISu6jS8PL/9Gspq3RYnAWEUjAn4lSw2PIUmkReMPaGvA87
>> 52+fp4bl0+jMO5MRkIPOuPdEzebUrpRuaovm4lG/NsjA6xmyLVq/f6emqNIVnbxW
>> mxRWRzThIHnXLP0P1BlFaSXnlsl5UE86Z1vueitnHUiElqv6ptuAoDoC0ZcvTRN4
>> NjXh79biWwnFDGb38NJovoTF7ithJpIA+7wtjF5+swnr1FeMKtju3oZ/TmAX5Wfy
>> N0QdzaeeZSsMhV3fZyPKc70RdHi/R/Yj6qHogNzAByGafB7i9W49wVwxIIN0Af4=
>> =eaNf
>> -END PGP SIGNATURE-
>> ___
>> 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] Identify with Feature Form on QGIS 2.2

[Nathan Woodrow]

hmmm that is a real bugger.  Yeah I think kind of thing warrants a bug fix
release.  This will kill QGIS for most users who do data entry, which is
most of the people I know.

- Nathan


On Tue, Feb 25, 2014 at 2:15 AM, matteo  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Confirmed. Debian 7.3 with qgis 2.3 master updated this morning.
>
> Matteo
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Icedove - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTC2//AAoJEBy7UYf0gaEOZ8gIALX9YhsFuStCxtWJXYWz7/dd
> X5OgRfOE8ikQax6+BMISu6jS8PL/9Gspq3RYnAWEUjAn4lSw2PIUmkReMPaGvA87
> 52+fp4bl0+jMO5MRkIPOuPdEzebUrpRuaovm4lG/NsjA6xmyLVq/f6emqNIVnbxW
> mxRWRzThIHnXLP0P1BlFaSXnlsl5UE86Z1vueitnHUiElqv6ptuAoDoC0ZcvTRN4
> NjXh79biWwnFDGb38NJovoTF7ithJpIA+7wtjF5+swnr1FeMKtju3oZ/TmAX5Wfy
> N0QdzaeeZSsMhV3fZyPKc70RdHi/R/Yj6qHogNzAByGafB7i9W49wVwxIIN0Af4=
> =eaNf
> -END PGP SIGNATURE-
> ___
> 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] Multi-threading rendering merged to master

[Larry Shaffer]

Hi Martin,

This is just awesome work!

Unfortunately, all but the simplest labeling tests (default labels of mm
unit) fail, especially any that utilize labels in map units. In your
forthcoming detailed description of changes you mentioned, could you add
some info on what may have changed with regards to output resolution?

Sorry, I haven't read all previous list threads concerning your work yet.

I'm going to go back to a 2.2 build and work on a semi-complete suite of
labeling tests. Then, port the unit tests and control images to master, so
we can see the differences between then and post-multi-threading commits.

For now, labeling output is ~90% broken, resolution-wise, across all
outputs.

Regards,

Larry


On Mon, Feb 24, 2014 at 2:27 AM, Martin Dobias  wrote:

> Hi Mathieu
>
> On Mon, Feb 24, 2014 at 9:52 AM, Mathieu Pellerin 
> wrote:
> > Martin,
> >
> > Fantastic work; I knew to expect a better rendering experience, yet I was
> > caught by surprise at how much of a positive difference it makes.
> >
> > Few things from my 10-minutes play with it:
> > * The map overview extend is broken, its extend goes way, way beyond the
> > extend of the sum of all the layers in a given project
>
> In my quick test everything seems to work fine, I will need more
> details about the issue - feel free to file a bug report.
>
> > * The 'xxx' option doesn't seem to be taken into consideration, the
> parallel
> > rendering is always activated on my machine irrespective of whether I
> > checked the box or not.
>
> Works fine for me... but there are two different concepts:
> 1. rendering in background - GUI is responsive even while the map is
> being rendered - this is always on
> 2. parallel vs sequential rendering - in sequential mode, there is
> just one job that renders everything - in parallel mode, the job is
> split into several jobs (one job per map layer) and jobs can therefore
> use multiple cores
>
> Are you sure you are not referring to point 1?
> Also, it is worth noting that parallel rendering may bring
> improvements only when there is more than one layer to render.
>
> > * Half of the times I exited QGIS, the application process was not
> > terminating and this error message was thrown: "*** Error in
> > `/home/webmaster/apps/bin/qgis': corrupted double-linked list: 0x0a0680f0
> > ***"; I had to manually kill the process
>
> I had this problem too - due to some garbage in the build directory
> (incompatible plugin DLLs). Try to run QGIS with --noplugins option.
> But better do a clean build.
>
> Regards
> Martin
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Still can't select features prior to dissolve

[Michael McInnis]

// This works 

from osgeo import ogr

canvas =
qgis.utils.iface.mapCanvas()

allLayers = canvas.layers()

for i in allLayers: i.selectAll(); print i.name(); print
i.selectedFeatureCount()
(In the python Console)
Above you use the current layer (i) to i.selectAll();
How do you do a selection using attribute values such as 
i.selectFeatures("LWFLAG" != 'P')
to set the selected features for the dissolve function?
qgis.analysis.QgsGeometryAnalyzer.dissolve?4(QgsVectorLayer,
QString, bool onlySelectedFeatures=True, int uniqueIdField=-1) -> bool
Michael McInnis
6033 44th Ave. N.E.
Seattle, WA 98115
206 517-4701  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [32] Value Tool approval notification.

[noreply]

Plugin Value Tool approval by etourigny.
The plugin version "[32] Value Tool 0.8.2" is now approved
Link: http://plugins.qgis.org/plugins/valuetool/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Post-release period of portable commits only?

[Larry Shaffer]

Hi,

On Mon, Feb 24, 2014 at 7:41 AM, Filipe Dias  wrote:

> How about making a formal announcement (mailing list, website, wiki etc)
> telling
> the users that QGIS version 2.X is in feature freeze and therefore is
> sufficiently
>
stable to be tested by end users? This may increase the number of testers.
>
>
As an end user that uses QGIS for production, this is the only time I work
> with QGIS Master.
>

On Mon, Feb 24, 2014 at 8:54 AM, Jürgen E.  wrote:
-- 8<--snip

> Ok, seriously, I should probably emphasize in the freeze announcement, that
> it's mainly the users that are supposed to test the daily prereleases and
> weekly release candidates and report problems, while the developers work on
> reproducing and fixing already known or newly reported bugs.
>
> And the warnings on the download page should be changed to say, that
> testing
> nightly builds in the development phase are different thing than the daily
> prereleases in the freeze phase.
>


I think those two posts really do sum it up. The project just needs to
communicate better with the user community that the weeks between the
feature freeze and release are their chance to make a difference, by
testing the 'release candidate' (or whatever it going to be called), or be
prepared to wait 4 months.

+1  I'm all for these changes. I don't think the idea I proposed in the
original post is any better, excepting the inclusion of a larger user base,
which still doesn't mean better testing, though.

If the majority of users 'know' that they have several weeks every 4 months
to directly affect change/bugs right before a release, that should be good
enough.

Also, would be good to list that right on the Roadmap schedule [0], e.g.:

WEEK  DATE  EVENT
21 23.02.3  freeze begins, release candidate


[0] http://qgis.org/en/site/getinvolved/development/index.html#road-map


Regards,

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

Re: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released

[Tom Kralidis]

Hi Stefan: great idea! FYI there is discussion on this at
https://github.com/geopython/MetaSearch/pull/31#issuecomment-35818883,
the output of which we'll place on the MetaSearch w.r.t. how to get
your CSW added to default connections.  If someone can put out a call
to qgis-user, that would be great.

On Mon, Feb 24, 2014 at 3:54 AM, Blumentrath, Stefan
 wrote:
> Hi Tom,
>
> I see you started collecting Meta Data Catalogues (at least on national 
> scale) for the default services in the plugin.
>
> I like the idea very much. What about asking (QGIS) users explicitly to 
> provide addresses for their countries? Such a collection would be really 
> valuable (especially for people working across borders) and maybe also of 
> interest for other projects as there are already comparable initiatives on 
> collecting information on available data:
> http://wiki.osgeo.org/wiki/Geodata_Discovery_Working_Group
> http://grasswiki.osgeo.org/wiki/Global_datasets
>
> What do you think?
>
> Cheers,
> Stefan
>
>
> -Original Message-
> From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom Kralidis
> Sent: 19. februar 2014 13:00
> To: Blumentrath, Stefan
> Cc: qgis-developer@lists.osgeo.org
> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released
>
>
> Hi Stefan: thanks for the info.  This is the dreaded metadata "link types" 
> issue.
>
> If possible, can you open an issue on this so we can discuss this in the 
> ticket?
>
> Thanks
>
> ..Tom
>
> On Wed, 19 Feb 2014, Blumentrath, Stefan wrote:
>
>> Date: Wed, 19 Feb 2014 11:54:04 +
>> From: "Blumentrath, Stefan" 
>> To: Tom Kralidis 
>> Cc: "qgis-developer@lists.osgeo.org" 
>> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0
>> released
>>
>> Done.
>>
>> BTW, the problem that I could not add WMS / WFS is likely to be on the CSW 
>> side and not the client side, cause it worked for some WMS...
>>
>> I was using the CSW for "official" map data in Norway provided by geonorge:
>> http://www.geonorge.no/geonetwork/srv/no/csw?
>>
>> There are several / many WMS listed which cannot be added... Would you mind 
>> double checking if this is a server-side problem?
>>
>> Cheers
>> Stefan
>>
>> -Original Message-
>> From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom
>> Kralidis
>> Sent: 19. februar 2014 12:32
>> To: Blumentrath, Stefan
>> Cc: qgis-developer@lists.osgeo.org
>> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0
>> released
>>
>>
>> Hi Stefan: thanks for the info/kind words.  Yes, can you file a ticket at 
>> https://github.com/geopython/MetaSearch/issues/new with the steps taken, so 
>> we can reproduce and fix the issue.
>>
>> Thanks
>>
>> ..Tom
>>
>>
>> On Wed, 19 Feb 2014, Blumentrath, Stefan wrote:
>>
>>> Date: Wed, 19 Feb 2014 08:06:59 +
>>> From: "Blumentrath, Stefan" 
>>> To: Tom Kralidis ,
>>> "qgis-developer@lists.osgeo.org" 
>>> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0
>>> released
>>>
>>> Hi Tom,
>>>
>>> Thank you (and your team) very much for this excellent plugin! Very 
>>> valuable!
>>>
>>> I tested version 0.1.1 (in QGIS 2.0.1 on Win7) and love it already.
>>>
>>> Adding WMS/WCS/WFS however does not seem to be active yet, and using the 
>>> "back" arrows throws an error:
>>> Traceback (most recent call last):
>>>  File 
>>> "C:\Users\ninsbl/.qgis2/python/plugins\MetaSearch\dialogs\maindialog.py", 
>>> line 572, in navigate
>>>if res == QMessageBox.Ok:
>>> UnboundLocalError: local variable 'res' referenced before assignment
>>>
>>> Should I file a ticket?
>>>
>>> Still the plugin is already very useful and personally I think it should 
>>> make it to QGIS core in the long run!
>>>
>>> So, thanks again,
>>> Stefan
>>>
>>> -Original Message-
>>> From: qgis-developer-boun...@lists.osgeo.org
>>> [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Tom
>>> Kralidis
>>> Sent: 18. februar 2014 21:16
>>> To: qgis-developer@lists.osgeo.org
>>> Subject: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0
>>> released
>>>
>>>
>>> The MetaSearch team announces the release of MetaSearch 0.1.0.
>>>
>>> The 0.1.0 release marks the initial offering of a CSW client for QGIS 2, 
>>> with significant features to enable plug and play interoperability with OGC 
>>> CSW services.
>>>
>>> - find and bind functionality allowing users to discover and add
>>> layers from WMS, WFS, WCS, or WMTS services dynamically to the map
>>> - template-based service and record metadata view, allowing for
>>> custom templating of responses
>>> - visual footprint of CSW results
>>> - display of all metadata access links, allowing users to
>>> click/download data to add to QGIS
>>> - spatial and aspatial querying of CSW services
>>>
>>> Version 0.1.0 represents a significant engineering effort to bring CSW 
>>> support for QGIS 2, make the codebase sustainable/extensible and easy for 
>>> developers and documentation teams to make

Re: [Qgis-developer] PyQT - How to get layer sending attributeValueChanged signal?

[HAUBOURG]

 A followup:
I had my class inherit from QObject (first time doing that for me) and I catch 
the sender correctly. 
Strangely, I catch the signal twice, so maybe inherinting from QObject triggers 
another signalk somewhere.. 
Cheers


> -Message d'origine-
> De : Matthias Kuhn [mailto:matthias.k...@gmx.ch]
> Envoyé : lundi 24 février 2014 15:21
> À : HAUBOURG
> Cc : qgis-developer@lists.osgeo.org
> Objet : Re: [Qgis-developer] PyQT - How to get layer sending
> attributeValueChanged signal?
> 
> Hi Régis
> 
> Calling sender() in your SLOT should return the QgsVectorLayer object There
> is also QSignalMapper [1] which has a cleaner concept, but it looks as if this
> will on the one hand help you to identify the source layer, but you will loose
> any other parameters, what's probably not your intent.
> 
> Best
> Matthias
> 
> [1] http://qt-project.org/doc/qt-4.8/qsignalmapper.html
> 
> On Mon 24 Feb 2014 02:57:37 PM CET, Régis Haubourg wrote:
> > Hi,
> > I would like to catch the layer or layer id that is sending
> > attributeValueChanged signal.
> > This signal carries only  QgsFeatureId fid, int idx, const QVariant & )
> 
> >
> > Any idea how to do this in a clean way?
> >
> > Cheers,
> > Régis
> >
> >
> >
> > --
> > View this message in context:
> > http://osgeo-org.1560.x6.nabble.com/PyQT-How-to-get-layer-sending-
> attr
> > ibuteValueChanged-signal-tp5105532.html
> > Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
> > ___
> > Qgis-developer mailing list
> > Qgis-developer@lists.osgeo.org
> > http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> 

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

Re: [Qgis-developer] Post-release period of portable commits only?

[Ivan Mincik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> Ok, seriously, I should probably emphasize in the freeze announcement,
> that it's mainly the users that are supposed to test the daily prereleases
> and weekly release candidates and report problems, while the developers
> work on reproducing and fixing already known or newly reported bugs.
> 
> And the warnings on the download page should be changed to say, that
> testing nightly builds in the development phase are different thing than
> the daily prereleases in the freeze phase.
> 
> 
> Jürgen
> 

Jürgen, at first thank you for your work as a developer and RM.

Time based releases are very good decision.

I think that clear separation of nightly builds after a feature freeze from
regular nightly builds (even if they are technically same) followed by loud
public announcements will surely help to catch more bugs.

Even if there is a no man power to maintain bugfix releases, please support
people to commit backported fixes to release branches. I think many people
realized importance of these bug releases and will offer a hand. I vote for
Sandro's work flow - if there is at least one commit from latest minor release
and at least 14 days of silence - release just a source code. Other things
will follow upon volunteer base.


- -- 
Ivan Minčík
ivan.min...@gmail.com   GPG: 0x79529A1E  http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.skGPG: 0xD714B02C  http://imincik.github.io/0xD714B02C.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTC3IbAAoJEPfdLsR5Upoee0AIAI/zVrB5YiEV4dqR/BUx5/HF
YX7ml6wNL+utmALAH+w06Ilzkem/4fLHk4IdWgjuTH/goSkypQeZF6vchrphc/zC
frSpoSdQ3/ls+CemTQQv2aRkE3R3y91qMlx4mVrI0/i3WobjEsSvjWOEyjcaoG+b
9lBpY+6jHyrUpRP+fu0tE2fE0dE3+i660YpWYNeGHX66uFNEBfVhDhkDXdkuGxXV
25F+g32fD3C+koeA1ynqpht2tcrzOYnnAmmoerH5Z9cS1f+SwoomAjJGmnrnED1D
VDfvS3mWKAaOpjy7N0FSrAyAQ7tLnOXuY3AQriokI3eBivjQ+uRfAUFgp+FQtDI=
=BmOT
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Identify with Feature Form on QGIS 2.2

[matteo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Confirmed. Debian 7.3 with qgis 2.3 master updated this morning.

Matteo
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJTC2//AAoJEBy7UYf0gaEOZ8gIALX9YhsFuStCxtWJXYWz7/dd
X5OgRfOE8ikQax6+BMISu6jS8PL/9Gspq3RYnAWEUjAn4lSw2PIUmkReMPaGvA87
52+fp4bl0+jMO5MRkIPOuPdEzebUrpRuaovm4lG/NsjA6xmyLVq/f6emqNIVnbxW
mxRWRzThIHnXLP0P1BlFaSXnlsl5UE86Z1vueitnHUiElqv6ptuAoDoC0ZcvTRN4
NjXh79biWwnFDGb38NJovoTF7ithJpIA+7wtjF5+swnr1FeMKtju3oZ/TmAX5Wfy
N0QdzaeeZSsMhV3fZyPKc70RdHi/R/Yj6qHogNzAByGafB7i9W49wVwxIIN0Af4=
=eaNf
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] PyQT - How to get layer sending attributeValueChanged signal?

[Régis Haubourg]

Hi Matthias, 
thanks for the pointer. My plugin main class does not inherits from anything
and I get the following error:

 line 173, in labelLayerModified
sender = self.sender()
AttributeError: EasyCustomLabeling instance has no attribute 'sender'

Should I inherit my class from a higher QT or PyQt4 object, and which one? 

Cheers
Régis




--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/PyQT-How-to-get-layer-sending-attributeValueChanged-signal-tp5105532p5105587.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Post-release period of portable commits only?

[Jürgen E . Fischer]

Hi Jonathan,

On Mon, 24. Feb 2014 at 14:17:44 +, Jonathan Moules wrote:
> > Why not?  We're talking about a feature freezed period!?  The nightly build
> > is a snapshot what what will get release.  Where do you see a difference?

> I think it's a perception thing.
> "Nightly build" in my mind always means "bleeding edge may or may not work,
> use at own risk." I'm aware that doesn't always mean "*it will crash your
> computer, burn down your house, and spend your life savings on questionable
> drugs*", but it's certainly not what I see as a synonym for "stable" either.

Sure, but that doesn't change that it's a misperception.

It more like "This is what we're going to release soon - it's not too bad and
it's getting better every day, but if you don't try it and report problems,
it's your responsibility if the release later eats your kids". ;)
 
> Every time I see a nightly, it always comes with a big scary caveat (QGIS
> does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This
> trains users not to use them. Taking one of the nightlies and re-branding it
> to something more amicable would get more folks to test it. Just copy and
> paste it and rename the file. :-)

Or just remove all those wimpy warnings.  It's in the smallprint (GPL) anyway.
The users can not tests all they want, we still can't even be made responsible
if the release does not eat kids. ;)

Ok, seriously, I should probably emphasize in the freeze announcement, that
it's mainly the users that are supposed to test the daily prereleases and
weekly release candidates and report problems, while the developers work on
reproducing and fixing already known or newly reported bugs.

And the warnings on the download page should be changed to say, that testing
nightly builds in the development phase are different thing than the daily
prereleases in the freeze phase.


Jürgen

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


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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

Re: [Qgis-developer] Post-release period of portable commits only?

[Jonathan Moules]

Slightly deviating from the topic, but I'm quite fond of the GeoServer
release process; they're revamping a little to offer better Long Term
Support:
http://geoserver.org/display/GEOS/GSIP+107+-+Extended+Release+Schedule

I feel a similar system would solve most of QGIS' release problems:
- Bugfix releases
- LTS (if/when required)
- Predictable releases (though now fixed by QGIS)
- Clear test releases (betas and release candidates)

In comparison the QGIS release system feels... haphazard I guess is the
best word.

I know the common complaint is a lack of a resources, but QGIS has far more
resources than GeoServer - both in number of developers and the existence
of a "general fund".

Just thought I'd put it out there.
Cheers,
Jonathan


On 24 February 2014 14:41, Filipe Dias  wrote:

> How about making a formal announcement (mailing list, website, wiki etc)
> telling the users that QGIS version 2.X is in feature freeze and therefore
> is sufficiently stable to be tested by end users? This may increase the
> number of testers.
>
> As an end user that uses QGIS for production, this is the only time I work
> with QGIS Master.
>
>
> On Mon, Feb 24, 2014 at 2:17 PM, Jonathan Moules <
> jonathanmou...@warwickshire.gov.uk> wrote:
>
>>
>>
>>>  Why not?  We're talking about a feature freezed period!?  The nightly
>>> build
>>> is a snapshot what what will get release.  Where do you see a difference?
>>>
>>
>> I think it's a perception thing.
>> "Nightly build" in my mind always means "bleeding edge may or may not
>> work, use at own risk." I'm aware that doesn't always mean "*it will
>> crash your computer, burn down your house, and spend your life savings on
>> questionable drugs*", but it's certainly not what I see as a synonym for
>> "stable" either.
>>
>> Every time I see a nightly, it always comes with a big scary caveat (QGIS
>> does too - http://www.qgis.org/en/site/forusers/alldownloads.html ).
>> This trains users not to use them. Taking one of the nightlies and
>> re-branding it to something more amicable would get more folks to test it.
>> Just copy and paste it and rename the file. :-)
>>
>> Cheers,
>> Jonathan
>>
>>
>>>
>>>
>>> > Very few average user will install a nightly development build, but
>>> you get
>>> > an higher chance of getting a broader number of people (that interacts
>>> with
>>> > QGIS in different ways) to test out your product before it's released.
>>>
>>> Why should it matter if we call it "weekly snapshot", "nightly build" or
>>> "prerelease"?   It's the same thing, just the tag is different.  And
>>> installation is essential as easy as installing the stable release.
>>>
>>>
>>> > It also helps channel what your describing as noise (i.e. users running
>>> > into problems) into a better managed call for people to test and
>>> report.
>>> > The noise will happen no matter what. But it might make some sense to
>>> > trigger some of that noise (valid bugs and "invalid" RTFM cases)
>>> _before_
>>> > you release your final version via a pre-release social media and news
>>> site
>>> > "try this pre-release build" :)
>>>
>>> > It's really more a matter of presentation to the users than of actual
>>> work.
>>>
>>> Exactly.  And that's what I meant with noise: "tada, there's a new weekly
>>> snapshot/prerelease/nightly build" - not users running into problems.
>>>  Because
>>> I see that as the only significant difference to what we already have.
>>>
>>>
>>> Jürgen
>>>
>>> --
>>> Jürgen E. Fischer norBIT GmbH   Tel.
>>> +49-4931-918175-31
>>> Dipl.-Inf. (FH)   Rheinstraße 13Fax.
>>> +49-4931-918175-50
>>> Software Engineer D-26506 Norden
>>> http://www.norbit.de
>>> QGIS PSC member (RM)  Germany  IRC: jef on
>>> FreeNode
>>>
>>> --
>>> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
>>> Rheinstrasse 13, 26506 Norden
>>> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>>>
>>> ___
>>> Qgis-developer mailing list
>>> Qgis-developer@lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
>>
>> This transmission is intended for the named addressee(s) only and may
>> contain sensitive or protectively marked material up to RESTRICTED and
>> should be handled accordingly. Unless you are the named addressee (or
>> authorised to receive it for the addressee) you may not copy or use it, or
>> disclose it to anyone else. If you have received this transmission in error
>> please notify the sender immediately. All email traffic sent to or from us,
>> including without limitation all GCSX traffic, may be subject to recording
>> and/or monitoring in accordance with relevant legislation.
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>

-- 
This transmission is intended for the named addressee(s) only and m

Re: [Qgis-developer] Identify with Feature Form on QGIS 2.2

[Randal Hale]

Confirm on ubuntu 12.04 LTS from the UbuntuGIS PPA


-
Randal Hale, GISP
North River Geographic Systems, Inc
http://www.northrivergeographic.com
423.653.3611 rjh...@northrivergeographic.com

twitter:rjhale
http://about.me/rjhale

On 02/24/2014 09:38 AM, Andreas Neumann wrote:

Hi,

Yes - I can confirm that on Windows (OSGeo4W). Very annoying. I don't
know when this bug was introduced - too bad I did not see it before the
release.

With this bug present I cannot roll out QGIS 2.2 in my organization -
sad - it means I have to wait another 4 months to maybe have a useful
release. We really need these 2.2x releases fixing the most urgent bugs.

Andreas

Am 24.02.2014 07:06, schrieb Denis Rouzaud:

On 23. 02. 14 19:48, Pedro Venâncio wrote:

Hi,

Identify with "Open feature form, if a single feature is identified"
opens both Feature Form and Identify Results window.

Anyone confirms?

I confirm.
Very annoying!
Would be worth a 2.2.1 ...
___
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] Identify with Feature Form on QGIS 2.2

[Andreas Neumann]

Hi,

Yes - I can confirm that on Windows (OSGeo4W). Very annoying. I don't
know when this bug was introduced - too bad I did not see it before the
release.

With this bug present I cannot roll out QGIS 2.2 in my organization -
sad - it means I have to wait another 4 months to maybe have a useful
release. We really need these 2.2x releases fixing the most urgent bugs.

Andreas

Am 24.02.2014 07:06, schrieb Denis Rouzaud:
> 
> On 23. 02. 14 19:48, Pedro Venâncio wrote:
>> Hi,
>>
>> Identify with "Open feature form, if a single feature is identified"
>> opens both Feature Form and Identify Results window.
>>
>> Anyone confirms?
> I confirm.
> Very annoying!
> Would be worth a 2.2.1 ...
> ___
> 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] Post-release period of portable commits only?

[Filipe Dias]

How about making a formal announcement (mailing list, website, wiki etc)
telling the users that QGIS version 2.X is in feature freeze and therefore
is sufficiently stable to be tested by end users? This may increase the
number of testers.

As an end user that uses QGIS for production, this is the only time I work
with QGIS Master.


On Mon, Feb 24, 2014 at 2:17 PM, Jonathan Moules <
jonathanmou...@warwickshire.gov.uk> wrote:

>
>
>>  Why not?  We're talking about a feature freezed period!?  The nightly
>> build
>> is a snapshot what what will get release.  Where do you see a difference?
>>
>
> I think it's a perception thing.
> "Nightly build" in my mind always means "bleeding edge may or may not
> work, use at own risk." I'm aware that doesn't always mean "*it will
> crash your computer, burn down your house, and spend your life savings on
> questionable drugs*", but it's certainly not what I see as a synonym for
> "stable" either.
>
> Every time I see a nightly, it always comes with a big scary caveat (QGIS
> does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This
> trains users not to use them. Taking one of the nightlies and re-branding
> it to something more amicable would get more folks to test it. Just copy
> and paste it and rename the file. :-)
>
> Cheers,
> Jonathan
>
>
>>
>>
>> > Very few average user will install a nightly development build, but you
>> get
>> > an higher chance of getting a broader number of people (that interacts
>> with
>> > QGIS in different ways) to test out your product before it's released.
>>
>> Why should it matter if we call it "weekly snapshot", "nightly build" or
>> "prerelease"?   It's the same thing, just the tag is different.  And
>> installation is essential as easy as installing the stable release.
>>
>>
>> > It also helps channel what your describing as noise (i.e. users running
>> > into problems) into a better managed call for people to test and report.
>> > The noise will happen no matter what. But it might make some sense to
>> > trigger some of that noise (valid bugs and "invalid" RTFM cases)
>> _before_
>> > you release your final version via a pre-release social media and news
>> site
>> > "try this pre-release build" :)
>>
>> > It's really more a matter of presentation to the users than of actual
>> work.
>>
>> Exactly.  And that's what I meant with noise: "tada, there's a new weekly
>> snapshot/prerelease/nightly build" - not users running into problems.
>>  Because
>> I see that as the only significant difference to what we already have.
>>
>>
>> Jürgen
>>
>> --
>> Jürgen E. Fischer norBIT GmbH   Tel.
>> +49-4931-918175-31
>> Dipl.-Inf. (FH)   Rheinstraße 13Fax.
>> +49-4931-918175-50
>> Software Engineer D-26506 Norden
>> http://www.norbit.de
>> QGIS PSC member (RM)  Germany  IRC: jef on
>> FreeNode
>>
>> --
>> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
>> Rheinstrasse 13, 26506 Norden
>> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> This transmission is intended for the named addressee(s) only and may
> contain sensitive or protectively marked material up to RESTRICTED and
> should be handled accordingly. Unless you are the named addressee (or
> authorised to receive it for the addressee) you may not copy or use it, or
> disclose it to anyone else. If you have received this transmission in error
> please notify the sender immediately. All email traffic sent to or from us,
> including without limitation all GCSX traffic, may be subject to recording
> and/or monitoring in accordance with relevant legislation.
> ___
> Qgis-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] Rendering feature symbol when feature is not visible

[Jordi Torres]

Hi all,

I'm trying to render marker symbols that are bigger than the feature
geometry bounding box. When the feature is not visible (because it is out
of the current extent) the symbol isn't rendered.

I think the code in the draw method of qgsvectorlayer.cpp is:


QgsFeatureIterator fit = getFeatures( QgsFeatureRequest()

.setFilterRect(
rendererContext.extent() )

.setSubsetOfAttributes( attributes ) );


Ok, this is a expected behaviour, but is there anyway (using C++ API) to
change this behaviour without extending QgsVectorLayer?  I suppose that if
I could pass the renderContext with the whole layer extent it would do the
trick.


Any suggestions or ideas?


Thanks in advance.




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

Re: [Qgis-developer] PyQT - How to get layer sending attributeValueChanged signal?

[Matthias Kuhn]

Hi Régis

Calling sender() in your SLOT should return the QgsVectorLayer object
There is also QSignalMapper [1] which has a cleaner concept, but it 
looks as if this will on the one hand help you to identify the source 
layer, but you will loose any other parameters, what's probably not 
your intent.


Best
Matthias

[1] http://qt-project.org/doc/qt-4.8/qsignalmapper.html

On Mon 24 Feb 2014 02:57:37 PM CET, Régis Haubourg wrote:

Hi,
I would like to catch the layer or layer id that is sending
attributeValueChanged signal.
This signal carries only  QgsFeatureId fid, int idx, const QVariant & ) 


Any idea how to do this in a clean way?

Cheers,
Régis



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/PyQT-How-to-get-layer-sending-attributeValueChanged-signal-tp5105532.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



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

Re: [Qgis-developer] Post-release period of portable commits only?

[Jonathan Moules]

>  Why not?  We're talking about a feature freezed period!?  The nightly
> build
> is a snapshot what what will get release.  Where do you see a difference?
>

I think it's a perception thing.
"Nightly build" in my mind always means "bleeding edge may or may not work,
use at own risk." I'm aware that doesn't always mean "*it will crash your
computer, burn down your house, and spend your life savings on questionable
drugs*", but it's certainly not what I see as a synonym for "stable" either.

Every time I see a nightly, it always comes with a big scary caveat (QGIS
does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This
trains users not to use them. Taking one of the nightlies and re-branding
it to something more amicable would get more folks to test it. Just copy
and paste it and rename the file. :-)

Cheers,
Jonathan


>
>
> > Very few average user will install a nightly development build, but you
> get
> > an higher chance of getting a broader number of people (that interacts
> with
> > QGIS in different ways) to test out your product before it's released.
>
> Why should it matter if we call it "weekly snapshot", "nightly build" or
> "prerelease"?   It's the same thing, just the tag is different.  And
> installation is essential as easy as installing the stable release.
>
>
> > It also helps channel what your describing as noise (i.e. users running
> > into problems) into a better managed call for people to test and report.
> > The noise will happen no matter what. But it might make some sense to
> > trigger some of that noise (valid bugs and "invalid" RTFM cases) _before_
> > you release your final version via a pre-release social media and news
> site
> > "try this pre-release build" :)
>
> > It's really more a matter of presentation to the users than of actual
> work.
>
> Exactly.  And that's what I meant with noise: "tada, there's a new weekly
> snapshot/prerelease/nightly build" - not users running into problems.
>  Because
> I see that as the only significant difference to what we already have.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
> Software Engineer D-26506 Norden
> http://www.norbit.de
> QGIS PSC member (RM)  Germany  IRC: jef on FreeNode
>
> --
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify the sender immediately. All email traffic sent to or from us, 
including without limitation all GCSX traffic, may be subject to recording 
and/or monitoring in accordance with relevant legislation.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] PyQT - How to get layer sending attributeValueChanged signal?

[Régis Haubourg]

Hi, 
I would like to catch the layer or layer id that is sending
attributeValueChanged signal. 
This signal carries only  QgsFeatureId fid, int idx, const QVariant & ) 


Any idea how to do this in a clean way? 

Cheers, 
Régis



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/PyQT-How-to-get-layer-sending-attributeValueChanged-signal-tp5105532.html
Sent from the Quantum GIS - Developer mailing list archive at Nabble.com.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [387] Processing approval notification.

[noreply]

Plugin Processing approval by alexbruy.
The plugin version "[387] Processing 2.-20131120 Experimental" is now unapproved
Link: http://plugins.qgis.org/plugins/processing/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Plugin [387] Processing unapproval notification.

[noreply]

Plugin Processing unapproval by alexbruy.
The plugin version "[387] Processing 2.-20131029 Experimental" is now unapproved
Link: http://plugins.qgis.org/plugins/processing/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Announcing the release of QGIS 2.2

[Jonathan Moules]

Excellent work, thanks guys.

Just a thought, but as part of the release process (I'm guessing there's a
big list of things to do somewhere) I'd suggest updating the "Affected
Version" on redmine to whatever the newest version is. There's no 2.2.0 on
there currently.

Cheers,
Jonathan


On 22 February 2014 08:58, Jürgen E.  wrote:

> QGIS is a user friendly Open Source Geographic Information System
> that runs on Linux, Unix, Mac OSX, and Windows.
>
> We are very pleased to announce the release of QGIS 2.2 'Valmiera'.  The
> emphasis on this release has been very much on polish and performance - we
> have
> added many new features, tweaks and enhancements to make the user interface
> more consistent and professional looking (and hopefully easier to use). The
> composer (used for creating print ready maps) has had a lot of work done
> to it
> to make it a more viable platform for creating great cartographic outputs.
>
> This is first release following our new four month release schedule that is
> meant to make new features and bugfixes available quicker and the
> development
> and new releases more predictable.
>
> In order to streamline the release process, we only release the source code
> today.  The binaries will be created in close succession by the individual
> package maintainers.  The source code is and the binaries soon will be
> available via the large download link on our home page: http://qgis.org
>
> If there is not yet a binary package for your platform on the above page,
> please check back regularly as packagers push out their work and the
> download page will reflect the new packages.
>
>
> A word of thanks to our contributors, donors and sponsors
> --
>
> QGIS is a largely volunteer driven project, and is the work of a dedicated
> team
> of developers, documenters and supporters. We extend our thanks and
> gratitude
> for the many, many hours people have contributed to make this release
> happen.
> Many companies and organizations contribute back their improvements to
> QGIS and
> fund development of new features when they use it as their platform, and
> we are
> grateful for this and encourage others to do the same! We would also like
> to
> thank our sponsors and donors for helping to promote our work through their
> financial contributions. Our current sponsors are (QGIS Sponsorship is
> valid
> for one year):
>
> Gold Sponsor:
> Asia Air Survey (http://www.asiaairsurvey.com/)
>
> Silver Sponsor:
> State of Vorarlberg (http://www.vorarlberg.at)
> G.A.I.A. mbH (http://www.gaia-mbh.de/)
>
> Bronze Sponsors:
> ArguSoft GmbH & Co KG (http://argusoft.de)
> Molitec (http://www.molitec.it/)
>
> A current list of donors who have made financial contributions large and
> small to the project can be seen here:
>
> http://qgis.org/en/site/about/sponsorship.html#list-of-donors
>
> If you would like to make a donation or sponsor our project, please visit
> *http://qgis.org/en/site/about/sponsorship.html#sponsorship* . QGIS is
> Free software and you are under no obligation to do so. Sponsoring QGIS
> helps
> us to fund our six monthly developer meetings, maintain project
> infrastructure
> and fund bug fixing efforts
>
> Visual tour of the new release:
> --
>
> You can find a list of highlighted changes and new features listed on the
> detailed release announcement available here:
>
> *
> http://changelog.linfiniti.com/qgis/version/21/
> *
>
>
> Give us your feedback:
> --
>
> We welcome your feedback - please visit our issue tracker if you encounter
> an issue with the new release:
>
> http://hub.qgis.org/
>
> Please consult the existing issues there before filing any new ones.
>
>
> Happy QGISing!
>
> Regards,
>
> The QGIS Team!
>
>
>
> --
> Jürgen E. Fischer - QGIS Project Steering Committee Member
> ==
> 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.
>
> IRC: jef on #qgis at freenode.net
> ==
>
> --
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>

-- 
This transmission is intended for the named addressee(s) only and may 
contain sensitive or protectively marked material up to RESTRICTED and 
should be handled accordingly. Unless you are the named addressee (or 
authorised to receive it for the addressee) you may not copy or use it, or 
disclose it to anyone else. If you have received this transmission in error 
please notify th

Re: [Qgis-developer] [QGIS Mapserver] is QgsFilter ever used in GetFeatureInfo?

[G. Allegri]

Hi Ivan,
so ILIKE works bad in QGIS Desktop too? I will test it.

Can you confirm QgsFilter is not being used (mmm... where is it ever used
now?)

giovanni
Il 24/feb/2014 14:41 "Ivan Mincik"  ha scritto:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 02/24/2014 01:45 PM, G. Allegri wrote:
> > In an old feature request from me [1] I was suggesting to add LIKE/ILIKE
> > filter to GetFeatureInfo FILTER allowed params. Trying to follow the path
> > of the request, it seems that the filter is simply appended to layer
> > subsetstring as it is. QgsFilters' aren't being used, right?
>
> LIKE was just added in
>
> https://github.com/qgis/QGIS/commit/ddc0f87f3e9113f4aeb693c46e446ed5eed7474d
>
> ILIKE was not working as we expected, therefore we didn't included it.
>
>
> - --
> Ivan Minčík
> ivan.min...@gmail.com   GPG: 0x79529A1E
> http://imincik.github.io/0x79529A1E.key
> ivan.min...@gista.skGPG: 0xD714B02C
> http://imincik.github.io/0xD714B02C.key
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJTC0uQAAoJEPfdLsR5UpoeDcwH/jKD8nAraEaUNd7VSgOfxoWk
> eHBLD7ChyHlFtDxUXy3/9YCftBcQtKwCL7FEQPywUvOz2sXqnybwehhpsRyPabaf
> V8AMLT5fr4nqKInANATiPRVaCHmQ0CoaL+MIzPJZgCu5enDJ6p+JBDOmq8kbfFCQ
> d5gkwhxUDwK7U9PlGjeELjUMl6ZOnlvllpzjrFGvc+UdpzGxGkKspAjhz/9tFaqn
> jv8pbN89Q7re5mf+NsGwJDXmnmBpessXAC7N70copO1mvic53dhcoOsZY8X6stqn
> F3j9990QnPMzRocog5OCiWOocBbyV+hZbdWqhVZXY+k7FNrodNihTPz6t3bjUkE=
> =BbG1
> -END PGP SIGNATURE-
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] [QGIS Mapserver] is QgsFilter ever used in GetFeatureInfo?

[Ivan Mincik]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/24/2014 01:45 PM, G. Allegri wrote:
> In an old feature request from me [1] I was suggesting to add LIKE/ILIKE 
> filter to GetFeatureInfo FILTER allowed params. Trying to follow the path
> of the request, it seems that the filter is simply appended to layer
> subsetstring as it is. QgsFilters' aren't being used, right?

LIKE was just added in
https://github.com/qgis/QGIS/commit/ddc0f87f3e9113f4aeb693c46e446ed5eed7474d

ILIKE was not working as we expected, therefore we didn't included it.


- -- 
Ivan Minčík
ivan.min...@gmail.com   GPG: 0x79529A1E  http://imincik.github.io/0x79529A1E.key
ivan.min...@gista.skGPG: 0xD714B02C  http://imincik.github.io/0xD714B02C.key
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTC0uQAAoJEPfdLsR5UpoeDcwH/jKD8nAraEaUNd7VSgOfxoWk
eHBLD7ChyHlFtDxUXy3/9YCftBcQtKwCL7FEQPywUvOz2sXqnybwehhpsRyPabaf
V8AMLT5fr4nqKInANATiPRVaCHmQ0CoaL+MIzPJZgCu5enDJ6p+JBDOmq8kbfFCQ
d5gkwhxUDwK7U9PlGjeELjUMl6ZOnlvllpzjrFGvc+UdpzGxGkKspAjhz/9tFaqn
jv8pbN89Q7re5mf+NsGwJDXmnmBpessXAC7N70copO1mvic53dhcoOsZY8X6stqn
F3j9990QnPMzRocog5OCiWOocBbyV+hZbdWqhVZXY+k7FNrodNihTPz6t3bjUkE=
=BbG1
-END PGP SIGNATURE-
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Datum transformations

[Anita Graser]

On Mon, Feb 24, 2014 at 1:35 PM, Leyan  wrote:
> On 02/24/2014 05:45 PM, Marco Hugentobler wrote:
>>> - GUI: have a tab in project properties where non-default datum
>>> transforms would be managed - instead of requiring the user to select
>>> the datum transform immediately when the layer was added (and without
>>> being able to change the decision later)
>>
>> I don't have a strong opinion if it should be in project properties or if
>> the user should be asked immediately. The immediate selection has been
>> implemented following the behaviour of a commercial GIS. However, the
>> possibility to change it later easily does also sound good to me.
>>
>> Btw., congratulations to the merge of the multithreading branch!
>>
>> Regards,
>> Marco
>
> Hi Marco,
>
> I struggled quite a lot with the interface of a very famous commercial GIS
> on this issue, I believe there is a real possibility to do better here ! I
> think it is essential to allow the user to change the transformation later
> easily, maybe somewhere linked from the CRS choice ? That's where I would go
> as a user.
>
> I was also wondering how you see the relationship between CRS and datum
> transformation. I use CRSs (all the Beijing54 CRS) which already have a
> +towgs84 defined in their definition, but several towgs84 coefficients are
> offered when loading the layer. It is confusing to have to answer that, and
> if something else than the default coefficients is chosen, the result is
> incompatible with the proj4 definition. Should we strip these CRS
> definitions of the towgs84 coefficients (which were only meant for a small
> area initially, so are not valid everywhere)?

Please note the following related issue:
http://hub.qgis.org/issues/9396 "deactivate the Select datum
transformations dialog by default"

Maybe the ticket has to be reopened?

Best wishes,
Anita
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Datum transformations

[Marco Hugentobler]

Hi Leyan

>I struggled quite a lot with the interface of a very famous commercial 
GIS on this issue, I believe there is a real possibility to do better 
here ! I think it is essential to allow the >user to change the 
transformation later easily, maybe somewhere linked from the CRS choice 
? That's where I would go as a user.


He, he, I bet it is the same GIS :-)

>I was also wondering how you see the relationship between CRS and 
datum transformation. I use CRSs (all the Beijing54 CRS) which already 
have a +towgs84 defined in their >definition, but several towgs84 
coefficients are offered when loading the layer. It is confusing to have 
to answer that, and if something else than the default coefficients is 
chosen, >the result is incompatible with the proj4 definition. Should we 
strip these CRS definitions of the towgs84 coefficients (which were only 
meant for a small area initially, so are not >valid everywhere)?


Do you mean we should strip the towgs84 parameters from 
tbl_srs.parameters or do you mean to deprecate/remove entries from 
tbl_datum_transform?


>Also, do you see a need to allow to define a custom datum 
transformation, or do you think it is enough that user can create a 
custom CRS with different towgs84 parameters?


It is possible to add new entries to tbl_datum_transform to create 
custom datum transformations. Yes, it would be more convenient to have a 
gui for that, even if I don't know how often it will be used. You might  
judge it better since you obviously have to deal often with CRS issues.


Regards,
Marco


On 24.02.2014 13:35, Leyan wrote:

On 02/24/2014 05:45 PM, Marco Hugentobler wrote:




- GUI: have a tab in project properties where non-default datum
transforms would be managed - instead of requiring the user to select
the datum transform immediately when the layer was added (and without
being able to change the decision later)



I don't have a strong opinion if it should be in project properties 
or if the user should be asked immediately. The immediate selection 
has been implemented following the behaviour of a commercial GIS. 
However, the possibility to change it later easily does also sound 
good to me.


Btw., congratulations to the merge of the multithreading branch!

Regards,
Marco

Hi Marco,

I struggled quite a lot with the interface of a very famous commercial 
GIS on this issue, I believe there is a real possibility to do better 
here ! I think it is essential to allow the user to change the 
transformation later easily, maybe somewhere linked from the CRS 
choice ? That's where I would go as a user.


I was also wondering how you see the relationship between CRS and 
datum transformation. I use CRSs (all the Beijing54 CRS) which already 
have a +towgs84 defined in their definition, but several towgs84 
coefficients are offered when loading the layer. It is confusing to 
have to answer that, and if something else than the default 
coefficients is chosen, the result is incompatible with the proj4 
definition. Should we strip these CRS definitions of the towgs84 
coefficients (which were only meant for a small area initially, so are 
not valid everywhere)?


Also, do you see a need to allow to define a custom datum 
transformation, or do you think it is enough that user can create a 
custom CRS with different towgs84 parameters?


Regards,

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



--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, 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] Plugin [32] Value Tool approval notification.

[noreply]

Plugin Value Tool approval by etourigny.
The plugin version "[32] Value Tool 0.8.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/valuetool/
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] [QGIS Mapserver] is QgsFilter ever used in GetFeatureInfo?

[G. Allegri]

In an old feature request from me [1] I was suggesting to add LIKE/ILIKE
filter to GetFeatureInfo FILTER allowed params.
Trying to follow the path of the request, it seems that the filter is
simply appended to layer subsetstring as it is. QgsFilters' aren't being
used, right?

giovanni

[1] http://hub.qgis.org/issues/6294

-- 
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

Re: [Qgis-developer] Datum transformations

[Leyan]

On 02/24/2014 05:45 PM, Marco Hugentobler wrote:




- GUI: have a tab in project properties where non-default datum
transforms would be managed - instead of requiring the user to select
the datum transform immediately when the layer was added (and without
being able to change the decision later)



I don't have a strong opinion if it should be in project properties or 
if the user should be asked immediately. The immediate selection has 
been implemented following the behaviour of a commercial GIS. However, 
the possibility to change it later easily does also sound good to me.


Btw., congratulations to the merge of the multithreading branch!

Regards,
Marco

Hi Marco,

I struggled quite a lot with the interface of a very famous commercial 
GIS on this issue, I believe there is a real possibility to do better 
here ! I think it is essential to allow the user to change the 
transformation later easily, maybe somewhere linked from the CRS choice 
? That's where I would go as a user.


I was also wondering how you see the relationship between CRS and datum 
transformation. I use CRSs (all the Beijing54 CRS) which already have a 
+towgs84 defined in their definition, but several towgs84 coefficients 
are offered when loading the layer. It is confusing to have to answer 
that, and if something else than the default coefficients is chosen, the 
result is incompatible with the proj4 definition. Should we strip these 
CRS definitions of the towgs84 coefficients (which were only meant for a 
small area initially, so are not valid everywhere)?


Also, do you see a need to allow to define a custom datum 
transformation, or do you think it is enough that user can create a 
custom CRS with different towgs84 parameters?


Regards,

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

Re: [Qgis-developer] Processing - bug when editing an open model ?

[kimaidou]

Hi,
I just opened a ticket for this bug : https://hub.qgis.org/issues/9632


2014-02-19 14:54 GMT+01:00 kimaidou :

> Hi all,
>
> Before reporting a bug, I would like to know if it is not already
> reported. I am using QGIS 2.0.3 with Processing plugin experimental version
> 2.0-20131120 (Ubuntu)
>
> When I create a graphical model from scratch, everything works fine. I can
> save the model and run it.
>
> But whenever I try to open an existing model, then modify one of the algo
> and apply modifications with the OK button, the interface freezes
> completely. I then need to kill QGIS to get out of it which is very bad in
> case you have not saved the project...
>
> Has anyone reported this or should I fill a new bug ?
>
> Regards,
> Michael
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Which compiler for a c++ QGIS custom app

[Jürgen E . Fischer]

Hi Denis,

On Mon, 24. Feb 2014 at 12:10:53 +0100, Rouzaud Denis wrote:
> I installed Visual Studio Express 2013, and it seems the compiler given with
> (version 12.0) is not compliant with Qt libs from the osgeo package.

Right, if you want to use Qt from OSGeo4W you need to you the same compiler as
the one used to build Qt.That is 2008 for 32bit and 2010 for 64bit.


Jürgen

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


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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

Re: [Qgis-developer] Which compiler for a c++ QGIS custom app

[Rouzaud Denis]

Thanks a lot  Nathan, this brought me further!

On 24 Feb 2014, at 12:14, Nathan Woodrow  wrote:

> The supported version is VS 2008.  I have never tried building with anything 
> else.
> 
> - Nathan
> 
> 
> On Mon, Feb 24, 2014 at 9:10 PM, Rouzaud Denis  
> wrote:
> Hi Jürgen,
> 
> On 21 Feb 2014, at 16:24, Jürgen E. Fischer  wrote:
> 
>> But QGIS and Qt in OSGeo4W is built with Visual C++ not MinGW.  You can't use
>> OSGeo4W's Qt with MinGW.
> 
> I installed Visual Studio Express 2013, and it seems the compiler given with 
> (version 12.0) is not compliant with Qt libs from the osgeo package.
> 
> Do you know if I should I restrict to a given version of the compiler? Which 
> one has been used for building osgeo’s qt lib?
> I saw that Nathan is using version 9.0.
> 
> Thanks a lot,
> 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] Which compiler for a c++ QGIS custom app

[Nathan Woodrow]

The supported version is VS 2008.  I have never tried building with
anything else.

- Nathan


On Mon, Feb 24, 2014 at 9:10 PM, Rouzaud Denis wrote:

> Hi Jürgen,
>
> On 21 Feb 2014, at 16:24, Jürgen E. Fischer  wrote:
>
> But QGIS and Qt in OSGeo4W is built with Visual C++ not MinGW.  You can't
> use
> OSGeo4W's Qt with MinGW.
>
>
> I installed Visual Studio Express 2013, and it seems the compiler given
> with (version 12.0) is not compliant with Qt libs from the osgeo package.
>
> Do you know if I should I restrict to a given version of the compiler?
> Which one has been used for building osgeo's qt lib?
> I saw that Nathan is using version 9.0.
>
> Thanks a lot,
> 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] Which compiler for a c++ QGIS custom app

[Rouzaud Denis]

Hi Jürgen,

On 21 Feb 2014, at 16:24, Jürgen E. Fischer  wrote:

> But QGIS and Qt in OSGeo4W is built with Visual C++ not MinGW.  You can't use
> OSGeo4W's Qt with MinGW.

I installed Visual Studio Express 2013, and it seems the compiler given with 
(version 12.0) is not compliant with Qt libs from the osgeo package.

Do you know if I should I restrict to a given version of the compiler? Which 
one has been used for building osgeo’s qt lib?
I saw that Nathan is using version 9.0.

Thanks a lot,
Denis___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Datum transformations

[Marco Hugentobler]

Hi Martin

>if some code in QGIS creates coordinate transform
>without using transform provided by map renderer, it will be created
>without the chosen datum transform and will therefore provide
>incorrect results

There is a lot of code and plugins that rely on the assumption that a 
coordinate transformation is fully defined by source crs and destination 
crs. I agree it is not an ideal situation, however that assumption is 
simply not correct  and it probably takes some time until all places are 
changed. I remember having changed that for QgsVectorFileWriter, but 
other places (e.g. measuring tool) still behaves not correct.



I guess there is still a question what to do in cases when there are
more layers with the same CRS but with different datum transforms - I
am not sure how well the current implementation handles that case (if

there is a datum transform defined in options, it will be used for all
layers with given CRS)


This is my main concern regarding caching of datum transformation. It is 
very important to have the possibility to control the datum 
transformation for each layer individually. E.g. it is quite common to 
load a layer twice with different datum transformations to see the 
difference. This was actually my main visual test during implementation, 
so I'm quite sure it works in 2.2 (or at least it was when I tested that 
last time). In case a user defines  a default transformation, he accepts 
that it will be silently used for all layers (and there is still the 
possibility to delete that in options).



- GUI: have a tab in project properties where non-default datum
transforms would be managed - instead of requiring the user to select
the datum transform immediately when the layer was added (and without
being able to change the decision later)



I don't have a strong opinion if it should be in project properties or 
if the user should be asked immediately. The immediate selection has 
been implemented following the behaviour of a commercial GIS. However, 
the possibility to change it later easily does also sound good to me.


Btw., congratulations to the merge of the multithreading branch!

Regards,
Marco


On 24.02.2014 06:03, Martin Dobias wrote:

Hi (Marco)

I have some suggestions for the implementation of datum transforms in
QGIS and I would like to hear your opinion about them.

In the 2.2 release, as far as I understand the logic is implemented like this:
- map renderer emits a signal asking for datum transform choice
- map canvas catches the signal and provides either the default
(defined in options) or asks the user in a dialog - and sends this
information back to map renderer
- map renderer stores the information about datum transforms and does
loading/saving in project file
- map renderer provides access to coordinate transforms (with correct
datum transform info)

The main issue I see here is the fact that in case of non-default
datum transforms - if some code in QGIS creates coordinate transform
without using transform provided by map renderer, it will be created
without the chosen datum transform and will therefore provide
incorrect results. This can lead to subtle bugs (for example,
QgsVectorFileWriter will not use the defined datum transforms, causing
offsets in reprojected data). Changing all the possible places where
coordinate transform may be used to call
QgsMapRenderer::transformation() seems impractical.

What do you think about:
- using QgsCoordinateTransformCache internally by
QgsCoordinateTransform anytime a new transform should be instantiated
- keeping the datum transform information in a helper class
(loaded/saved by project) and using it directly by
QgsCoordinateTransform - so any QGIS code will use the correct datum
transform
- GUI: have a tab in project properties where non-default datum
transforms would be managed - instead of requiring the user to select
the datum transform immediately when the layer was added (and without
being able to change the decision later)

Currently the datum transforms do not work at all in master after the
merge of MTR because the QgsMapRenderer class is not used for
rendering anymore. Before trying to do anything in that area I would
like to hear your input.

I guess there is still a question what to do in cases when there are
more layers with the same CRS but with different datum transforms - I
am not sure how well the current implementation handles that case (if
there is a datum transform defined in options, it will be used for all
layers with given CRS) and how much we need such functionality.

Regards
Martin



--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
Technical Advisor QGIS Project Steering Committee

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

Re: [Qgis-developer] Post-release period of portable commits only?

[Jürgen E . Fischer]

Hi Mathieu,

On Mon, 24. Feb 2014 at 15:42:19 +0700, Mathieu Pellerin wrote:
> Nightly builds (or weekly snapshots for that matter) are very different
> from a publicized, pre-release preview build. With a prepared pre-release
> preview, users are at least expecting that basic functioning will work,
> that's something  the nightly builds simply can't guarantee by the nature
> of what those are.

Why not?  We're talking about a feature freezed period!?  The nightly build
is a snapshot what what will get release.  Where do you see a difference?


> Very few average user will install a nightly development build, but you get
> an higher chance of getting a broader number of people (that interacts with
> QGIS in different ways) to test out your product before it's released.

Why should it matter if we call it "weekly snapshot", "nightly build" or
"prerelease"?   It's the same thing, just the tag is different.  And
installation is essential as easy as installing the stable release.


> It also helps channel what your describing as noise (i.e. users running
> into problems) into a better managed call for people to test and report.
> The noise will happen no matter what. But it might make some sense to
> trigger some of that noise (valid bugs and "invalid" RTFM cases) _before_
> you release your final version via a pre-release social media and news site
> "try this pre-release build" :)

> It's really more a matter of presentation to the users than of actual work.

Exactly.  And that's what I meant with noise: "tada, there's a new weekly
snapshot/prerelease/nightly build" - not users running into problems.  Because
I see that as the only significant difference to what we already have.


Jürgen 

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


-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502

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

Re: [Qgis-developer] Multi-threading rendering merged to master

[Martin Dobias]

Hi Mathieu

On Mon, Feb 24, 2014 at 9:52 AM, Mathieu Pellerin  wrote:
> Martin,
>
> Fantastic work; I knew to expect a better rendering experience, yet I was
> caught by surprise at how much of a positive difference it makes.
>
> Few things from my 10-minutes play with it:
> * The map overview extend is broken, its extend goes way, way beyond the
> extend of the sum of all the layers in a given project

In my quick test everything seems to work fine, I will need more
details about the issue - feel free to file a bug report.

> * The 'xxx' option doesn't seem to be taken into consideration, the parallel
> rendering is always activated on my machine irrespective of whether I
> checked the box or not.

Works fine for me... but there are two different concepts:
1. rendering in background - GUI is responsive even while the map is
being rendered - this is always on
2. parallel vs sequential rendering - in sequential mode, there is
just one job that renders everything - in parallel mode, the job is
split into several jobs (one job per map layer) and jobs can therefore
use multiple cores

Are you sure you are not referring to point 1?
Also, it is worth noting that parallel rendering may bring
improvements only when there is more than one layer to render.

> * Half of the times I exited QGIS, the application process was not
> terminating and this error message was thrown: "*** Error in
> `/home/webmaster/apps/bin/qgis': corrupted double-linked list: 0x0a0680f0
> ***"; I had to manually kill the process

I had this problem too - due to some garbage in the build directory
(incompatible plugin DLLs). Try to run QGIS with --noplugins option.
But better do a clean build.

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

Re: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released

[Blumentrath, Stefan]

Hi Tom,

I see you started collecting Meta Data Catalogues (at least on national scale) 
for the default services in the plugin.

I like the idea very much. What about asking (QGIS) users explicitly to provide 
addresses for their countries? Such a collection would be really valuable 
(especially for people working across borders) and maybe also of interest for 
other projects as there are already comparable initiatives on collecting 
information on available data:
http://wiki.osgeo.org/wiki/Geodata_Discovery_Working_Group
http://grasswiki.osgeo.org/wiki/Global_datasets

What do you think?

Cheers,
Stefan
 

-Original Message-
From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom Kralidis
Sent: 19. februar 2014 13:00
To: Blumentrath, Stefan
Cc: qgis-developer@lists.osgeo.org
Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released


Hi Stefan: thanks for the info.  This is the dreaded metadata "link types" 
issue.

If possible, can you open an issue on this so we can discuss this in the ticket?

Thanks

..Tom

On Wed, 19 Feb 2014, Blumentrath, Stefan wrote:

> Date: Wed, 19 Feb 2014 11:54:04 +
> From: "Blumentrath, Stefan" 
> To: Tom Kralidis 
> Cc: "qgis-developer@lists.osgeo.org" 
> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
> released
> 
> Done.
>
> BTW, the problem that I could not add WMS / WFS is likely to be on the CSW 
> side and not the client side, cause it worked for some WMS...
>
> I was using the CSW for "official" map data in Norway provided by geonorge:
> http://www.geonorge.no/geonetwork/srv/no/csw?
>
> There are several / many WMS listed which cannot be added... Would you mind 
> double checking if this is a server-side problem?
>
> Cheers
> Stefan
>
> -Original Message-
> From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom 
> Kralidis
> Sent: 19. februar 2014 12:32
> To: Blumentrath, Stefan
> Cc: qgis-developer@lists.osgeo.org
> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
> released
>
>
> Hi Stefan: thanks for the info/kind words.  Yes, can you file a ticket at 
> https://github.com/geopython/MetaSearch/issues/new with the steps taken, so 
> we can reproduce and fix the issue.
>
> Thanks
>
> ..Tom
>
>
> On Wed, 19 Feb 2014, Blumentrath, Stefan wrote:
>
>> Date: Wed, 19 Feb 2014 08:06:59 +
>> From: "Blumentrath, Stefan" 
>> To: Tom Kralidis ,
>> "qgis-developer@lists.osgeo.org" 
>> Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
>> released
>>
>> Hi Tom,
>>
>> Thank you (and your team) very much for this excellent plugin! Very valuable!
>>
>> I tested version 0.1.1 (in QGIS 2.0.1 on Win7) and love it already.
>>
>> Adding WMS/WCS/WFS however does not seem to be active yet, and using the 
>> "back" arrows throws an error:
>> Traceback (most recent call last):
>>  File 
>> "C:\Users\ninsbl/.qgis2/python/plugins\MetaSearch\dialogs\maindialog.py", 
>> line 572, in navigate
>>if res == QMessageBox.Ok:
>> UnboundLocalError: local variable 'res' referenced before assignment
>>
>> Should I file a ticket?
>>
>> Still the plugin is already very useful and personally I think it should 
>> make it to QGIS core in the long run!
>>
>> So, thanks again,
>> Stefan
>>
>> -Original Message-
>> From: qgis-developer-boun...@lists.osgeo.org
>> [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Tom 
>> Kralidis
>> Sent: 18. februar 2014 21:16
>> To: qgis-developer@lists.osgeo.org
>> Subject: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 
>> released
>>
>>
>> The MetaSearch team announces the release of MetaSearch 0.1.0.
>>
>> The 0.1.0 release marks the initial offering of a CSW client for QGIS 2, 
>> with significant features to enable plug and play interoperability with OGC 
>> CSW services.
>>
>> - find and bind functionality allowing users to discover and add 
>> layers from WMS, WFS, WCS, or WMTS services dynamically to the map
>> - template-based service and record metadata view, allowing for 
>> custom templating of responses
>> - visual footprint of CSW results
>> - display of all metadata access links, allowing users to 
>> click/download data to add to QGIS
>> - spatial and aspatial querying of CSW services
>>
>> Version 0.1.0 represents a significant engineering effort to bring CSW 
>> support for QGIS 2, make the codebase sustainable/extensible and easy for 
>> developers and documentation teams to make contributions.  Longer term plans 
>> include:
>>
>> - supporting other catalog APIs (CKAN, etc.)
>> - making MetaSearch part of QGIS core
>> - transifex localization
>> - display thumbnail/browse images
>>
>> We are looking for feedback and testers for the plugin.  Comments, bugs, 
>> features/enhancements are welcome (IRC, GitHub issue tracker, etc.).
>>
>> The full list of enhancements and bug fixes is available at 
>> https://github.com/geopython/MetaSearch/issues?milestone=1&page=1&sta
>> t
>> e=closed
>>
>> The 

Re: [Qgis-developer] Post-release period of portable commits only?

[Mathieu Pellerin]

-but you get an higher chance of getting a broader number of people (that
interacts with QGIS in different ways) to test out your product before it's
released.
+but you get an higher chance of getting a broader number of people (that
interacts with QGIS in different ways) to test out your product before it's
released *with an official beta/preview build*.

:)


On Mon, Feb 24, 2014 at 3:42 PM, Mathieu Pellerin wrote:

> Nightly builds (or weekly snapshots for that matter) are very different
> from a publicized, pre-release preview build. With a prepared pre-release
> preview, users are at least expecting that basic functioning will work,
> that's something  the nightly builds simply can't guarantee by the nature
> of what those are. Very few average user will install a nightly development
> build, but you get an higher chance of getting a broader number of people
> (that interacts with QGIS in different ways) to test out your product
> before it's released.
>
> It also helps channel what your describing as noise (i.e. users running
> into problems) into a better managed call for people to test and report.
> The noise will happen no matter what. But it might make some sense to
> trigger some of that noise (valid bugs and "invalid" RTFM cases) _before_
> you release your final version via a pre-release social media and news site
> "try this pre-release build" :)
>
> It's really more a matter of presentation to the users than of actual
> work. As you point out Jef, you guys already have the infrastructure that
> produces weekly standalone builds, and daily packages.
>
> Math
>
>
>
>
>
> On Mon, Feb 24, 2014 at 2:40 PM, Jürgen E.  wrote:
>
>> Hi Mathieu,
>>
>> On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:
>> > That reminds me of someone mentioning in a ticket of a 2.0 issue
>> resolved
>> > against qgis 2.1 that he'd wait (angrily?) having fix backported into a
>> > (mythical) 2.0.x update rather than him moving to 2.2 and having to deal
>> > with possible regressions. I was thinking at the time that this sounds
>> to
>> > me like a flawed behavior by some QGIS users, an egg or chicken
>> situation.
>> > How are regressions fixed if users are not doing their parts in
>> uncovering
>> > and reporting them.
>> >
>> > That led me to think there might be a very low-cost, high reward
>> behavior
>> > QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
>> > candidate,tech preview,etc.} builds (from master, no need to branch out
>> > really) are pushed out to osgeo4w & linux and quite loudly advertised
>> (blog
>> > posts, social media, etc.) to get as many users as possible to test
>> drive
>> > it. The users' feedback would enrich the 4-weeks period when developers
>> are
>> > to be focused on bug-fixing only.
>> >
>> > Thoughts? Was that already suggested and declined?
>>
>> What's the difference to the nightly builds and the weekly standalone
>> snapshot
>> for Windows - except for the noise of course?
>>
>>
>> Jürgen
>>
>> --
>> Jürgen E. Fischer norBIT GmbH   Tel.
>> +49-4931-918175-31
>> Dipl.-Inf. (FH)   Rheinstraße 13Fax.
>> +49-4931-918175-50
>> Software Engineer D-26506 Norden
>> http://www.norbit.de
>> QGIS PSC member (RM)  Germany  IRC: jef on
>> FreeNode
>>
>> --
>> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
>> Rheinstrasse 13, 26506 Norden
>> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>>
>> ___
>> Qgis-developer mailing list
>> Qgis-developer@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Post-release period of portable commits only?

[Mathieu Pellerin]

Nightly builds (or weekly snapshots for that matter) are very different
from a publicized, pre-release preview build. With a prepared pre-release
preview, users are at least expecting that basic functioning will work,
that's something  the nightly builds simply can't guarantee by the nature
of what those are. Very few average user will install a nightly development
build, but you get an higher chance of getting a broader number of people
(that interacts with QGIS in different ways) to test out your product
before it's released.

It also helps channel what your describing as noise (i.e. users running
into problems) into a better managed call for people to test and report.
The noise will happen no matter what. But it might make some sense to
trigger some of that noise (valid bugs and "invalid" RTFM cases) _before_
you release your final version via a pre-release social media and news site
"try this pre-release build" :)

It's really more a matter of presentation to the users than of actual work.
As you point out Jef, you guys already have the infrastructure that
produces weekly standalone builds, and daily packages.

Math





On Mon, Feb 24, 2014 at 2:40 PM, Jürgen E.  wrote:

> Hi Mathieu,
>
> On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:
> > That reminds me of someone mentioning in a ticket of a 2.0 issue resolved
> > against qgis 2.1 that he'd wait (angrily?) having fix backported into a
> > (mythical) 2.0.x update rather than him moving to 2.2 and having to deal
> > with possible regressions. I was thinking at the time that this sounds to
> > me like a flawed behavior by some QGIS users, an egg or chicken
> situation.
> > How are regressions fixed if users are not doing their parts in
> uncovering
> > and reporting them.
> >
> > That led me to think there might be a very low-cost, high reward behavior
> > QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
> > candidate,tech preview,etc.} builds (from master, no need to branch out
> > really) are pushed out to osgeo4w & linux and quite loudly advertised
> (blog
> > posts, social media, etc.) to get as many users as possible to test drive
> > it. The users' feedback would enrich the 4-weeks period when developers
> are
> > to be focused on bug-fixing only.
> >
> > Thoughts? Was that already suggested and declined?
>
> What's the difference to the nightly builds and the weekly standalone
> snapshot
> for Windows - except for the noise of course?
>
>
> Jürgen
>
> --
> Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
> Software Engineer D-26506 Norden
> http://www.norbit.de
> QGIS PSC member (RM)  Germany  IRC: jef on FreeNode
>
> --
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer