from:"Mathieu Pellerin"

[Qgis-developer] Improper vertical spacing in legend (Ticket #3605), need to revert changeset 15242 (by mhugent) to fix issue

2011-03-24 Thread Mathieu Pellerin

Greetings,

Few weeks ago, QGIS trunk started rendering composer's legend with
odd/unneeded vertical spaces (see http://trac.osgeo.org/qgis/ticket/3605 for
a screenshot of issue).

I believe the problem is caused by changset 15242, applied by mhugent 4
weeks ago. The changset pulled the currentYCoord += mLayerSpace code out
of the if ( !layerItem-text().isEmpty() ). This goes against QGIS' logic
allowing for empty layer title string to skip the layer title printing in
legend.

It'd be good to revert this change prior to the release of QGIS 1.7.

Regards to the QGIS team, you're doing a great job.

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

[Qgis-developer] Re: something went terribly wrong with reprojected rasters in the last 72 hours

2011-05-06 Thread Mathieu Pellerin

Radim,

Any chance you can apply this quick fix to a 1.7 build prior to final
release?

Math
On May 2, 2011 6:56 PM, Radim Blazek radim.bla...@gmail.com wrote:
 The patch is simple, we have to wait for new repository

 --- src/core/qgsrasterprojector.cpp (revision 15861)
 +++ src/core/qgsrasterprojector.cpp (working copy)
 @@ -130,7 +130,7 @@
 mSrcExtent = QgsRectangle( myPoint.x(), myPoint.y(), myPoint.x(),
 myPoint.y() );
 for ( int i = 0; i  mCPRows; i++ )
 {
 - for ( int j = 1; j  mCPCols - 1; j++ )
 + for ( int j = 0; j  mCPCols; j++ )
 {
 myPoint = mCPMatrix[i][j];
 mSrcExtent.combineExtentWith( myPoint.x(), myPoint.y() );

 Radim

 On Mon, May 2, 2011 at 1:29 PM, Mathieu Pellerin nirvn.a...@gmail.com
wrote:
 Greetings Radim Blazek,

 I'm forwarding you an email sent to the qgis-developer list hoping it can
 speed up a major raster rendering issue emerging days before the 1.7
 release.

 Please find attached to this email a rendered map showing the issue. I
 believe it might have been caused by r15845 or r15846, both applied by
you a
 few days ago. Others seem to draw the same conclusions
 (http://lists.osgeo.org/pipermail/qgis-developer/2011-May/014148.html).

 Hope it can be of help to you in resolving this issue.

 Thanks for all the hard work you and the other developers are putting
into
 QGIS, it's an amazing piece of software.

 Math

 -- Forwarded message --
 From: Mathieu Pellerin nirvn.a...@gmail.com
 Date: Mon, May 2, 2011 at 11:27 AM
 Subject: something went terribly wrong with reprojected rasters in the
last
 72 hours
 To: qgis-developer@lists.osgeo.org


 Greetings,

 QGIS' trac login is timing out on me so going through the mailing list
until
 it allows me to file in a proper issue report.

 A change applied on QGIS within the last 72 hours resulted in messy
 rendering of reprojected rasters. From what I can see, starting at
pixel's
 column 50%+1, QGIS just keeps repainting the same pixels again and again
 (see attached rendering).

 This should probably be fixed prior to releasing of 1.7 : )

 Cheers.

 Math


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

Re: [Qgis-developer] 1.8 release?

2011-10-20 Thread Mathieu Pellerin

For what it's worth, I'd also appreciate a 1.8 release, with the expression
based labeling (https://github.com/qgis/Quantum-GIS/pull/51) included : )

Math

On Thu, Oct 20, 2011 at 1:58 PM, Werner Macho werner.ma...@gmail.comwrote:

 Hi!
 I'd vote for a 1.8 release meeting at the hackfest - clean out the
 most annoying bugs and release a Zürich Release shortly after the
 Hackfest ;)


 On Thu, Oct 20, 2011 at 8:49 AM, Marco Hugentobler
 marco.hugentob...@sourcepole.ch wrote:
  Hi all
 
  +1
  I'm also in favor of a 1.8 release. I've been asked several times by
 users
  when the new features will be available in a release.
 
  before or after the HF?
 
  Before seems a bit short-termed. Don't know if this is possible?
 
  Regards,
  Marco
 
 
  Am Mittwoch, 19. Oktober 2011, 18.04:03 schrieb Paolo Cavallini:
  Il 19/10/2011 17:31, Martin Dobias ha scritto:
   If there is a consensus I guess the release could happen soon,
   sometime in mid-November.
 
  +1
  before or after the HF?
 
 
  --
  Dr. Marco Hugentobler
  Sourcepole -  Linux  Open Source Solutions
  Churerstrasse 22, CH-8808 Pfäffikon SZ, Switzerland
  marco.hugentob...@sourcepole.ch http://www.sourcepole.ch
  Technical Advisor QGIS Project Steering Committee
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
 
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Qgis-developer] new regression on to-be 1.8: crs attribution on newly loaded layer broken

2012-05-14 Thread Mathieu Pellerin

Something's seriously wrong with CRS attribution for newly added layers in
qgis-master (soon to be 1.8). I have no idea what is happening, however the
steps below will reproduce the issue:

1) Add moeareas.shp (uploaded as attachment in issue 5598:
http://hub.qgis.org/issues/5598) to a QGIS project
2) Open the Properties dialog and go to the General tab
3) Take note of the custom CRS applied to the layer

The above shapefile's coordinate reference system is EPSG:3148, defined as
follow:
+proj=utm +zone=48 +a=6377276.345 +b=6356075.41314024
+towgs84=198,881,317,0,0,0,0 +units=m +no_defs

The custom CRS created by qgis 1.8 when loading the above shapefile:
+proj=utm +zone=48 +a=6377276.345 +b=6356075.41314024 +units=m +no_defs

QGIS 1.7.x correctly attributes the newly loaded layer its proper CRS
(EPSG:3148); QGIS 1.8 however creates the custom CRS with the exact same
projection settings (minus the +towgs84). Something must be wrong in the
CRS attribution algorithm / function.

This issue leads to misalignment with on-the-fly re-projection projects in
which WGS84 layers  UTM layers are mixed together.

It's a pretty serious regression from 1.7.x and it's present on windows and
linux. Issue reported: http://hub.qgis.org/issues/5598.

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

Re: [Qgis-developer] Merging of incompatible changes

2012-10-24 Thread Mathieu Pellerin

In the region I'm working in (Southeast Asia), QuantumGIS' adoption rate is
quickly rising, in big part due to fact that ArcGIS doesn't properly
support UTF-8.

Keeping these new adopters passionate about QGIS - as well as increasing
user base - with an healthy release cycle is IMO really important. There
are so many good new features that have been pushing into 1.9, kind of
hurts to think it won't be available to a larger crowd until mid 2013.

One way forward would be to put official 2.0 milestones out. For e.g.,
before merging the threading work, it might be good to release a QGIS 2.0
beta 1 to the public. There are net advantages in doing so:
- Prevents long period of inactivity in-between official release for those
who do not want to work with nightly builds
- By making a more accessible development build (i.e. more people will
download a standalone beta installer than a nightly build), you'll get
more feedback and users testing the code
- Easing pressure of releasing a new QGIS version, giving more time for dev
plans

QGIS would go from two to three flavors: i) official version, ii) beta
version, iii) day-to-day dev build.

Math

On Wed, Oct 24, 2012 at 8:52 PM, haubourg 
regis.haubo...@eau-adour-garonne.fr wrote:

 Hi All,
 As Martin asked, could we know more about 2.0 roadmap planning and feature
 list?
 My concern is that we deployed QGIS in prod for 300 users, but we still
 miss
 some bugfixes and features to definitly switch. As long as I maintain two
 GIS solutions, I have double work, and I can't dedicate more time to QGIS.
 I would like to support prioritary issues before feature freeze. In the
 other hand, I can't wait until end of 2013 to fix 1.8 issues (raster print
 KO.. for example). We also just supported, with others of you, great tools
 like Atlas.. If a stable version with it is not released within a year,
 users will start to get annoyed, and will tend to use master for production
 use.. which is not a good target for any of us.

 So what is the community plan?
 What should we do as users and sponsors?  Should we ask (and support) a 1.8
 bugfix release if 2.0 target moves again? Should we support a 1.9 release
 for 2013 spring, and let major API changes for 2.0 be planned to end of
 2013?  Does community have enough ressources to release a 1.9?

 Please tell us, we love QGIS and its community.. but we also like very much
 stability and visibility (and the captive users in my corp' too)
 Régis





 --
 View this message in context:
 http://osgeo-org.1560.n6.nabble.com/Merging-of-incompatible-changes-tp5010325p5010839.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] Webpage

2012-11-13 Thread Mathieu Pellerin

Greetings,

Speaking of website improvement, I've just dropped in a proposal for a
refined - and more importantly _vector-based_ - QGIS logo here:
http://hub.qgis.org/issues/6688

I've tried to stick to the original logo as much as possible as clearly
many people are emotionally attached to the current logo. Hopefully, the
proposal also refines the logo with more subtle lightning.

Having QGIS' website use _one_ standard logo throughout (i.e. header logo,
download button logo, etc.) would already be a nice improvement.

Hope this can be of use to the project.

Cheers,

Math


On Wed, Nov 14, 2012 at 5:48 AM, Tim Sutton li...@linfiniti.com wrote:

 Hi

 Yes I have seen it. With no disrespect to the GRASS folks I think it has
 enough problems that I would not like to copy it on our site. My
 (hopefully) constructive criticisms:

 * its very busy
 * it doesnt have good whitespace balance e.g. module of the day box with
 screenshots box floating to the right
 * I love jquery but jquery css is looking old already
 * there are too many underlines [ ]   and other characters that
 distract attention and make it look not so friendly
 * the panels on the left (search, latest news, map) should have been put
 to the right
 * there is too much white space in the heading area
 * the logo really needs a refresh
 * the heavy green bars distract your eye away from the content
 * there are too many different font sizes and font styles
 * the drop down menus feel visually disconnected from the tabs the spring
 from and menus from tabs just feels kinda wierd

 In short it could really use a designer to introduce balance, correct
 emphasis and remove distractions

 As such I would not be supportive of using it for our site I suggest to
 wait for the sphinx theme based on bootstrap to come out and then start
 moving our web content into that. We will do some customisations for the
 QGIS front page and Richard has been making awesome progress in getting a
 well put together bootstrap based sphinx theme in place for us when we can
 then skin using any bootstrap theme (e.g. checkout some of the themes at
 http://bootswatch.com/).

 So -1 from me

 Regards

 Tim


 On Wed, Nov 14, 2012 at 12:14 AM, Werner Macho werner.ma...@gmail.comwrote:

 Hi there!

 Anyone seen the new GRASS Webpage?
 I really like the clean and intuitive style with lots of information
 presented clearly on the top page ..
 Probably we can adapt it to our new webpage?
 It even looks good on mobile phones ..

 Opinions on that?

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




 --
 Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
 ==
 Please do not email me off-list with technical
 support questions. Using the lists will gain
 more exposure for your issues and the knowledge
 surrounding your issue will be shared with all.

 Visit http://linfiniti.com to find out about:
  * QGIS programming and support services
  * Mapserver and PostGIS based hosting plans
  * FOSS Consulting Services
 Skype: timlinux
 Irc: timlinux on #qgis at freenode.net
 ==

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


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

Re: [Qgis-developer] Webpage

2012-11-14 Thread Mathieu Pellerin

Vincent,

Re modern-looking and professional, the above proposal tries to improve the
situation there. I believe it does so successfully, but then again it's my
subjective opinion :)

I think the not professional might be in big part due to the absence of
high resolution versions of the logo to be used for launcher icons and
documentation (see
http://download.osgeo.org/qgis/doc/manual/qgis-1.7.0_user_guide_en.pdf).
The fact that the proposal is vector-based allows ppl to blow up the logo
to very large scales for training session posters, be used on t-shirts,
etc. I think that should help improve QGIS' branding / image.

Also, the proposal isn't one that pushes for a revolution, just an
incremental refinement so that there can be a easily reachable agreement on
using it to improve situation quickly (especially needed for better linux
integration, see screenshots attached to the issue). A completely new logo
might still be desirable down the road, that ain't for me to decide :)


On Wed, Nov 14, 2012 at 3:34 PM, Vincent Picavet vincent...@oslandia.comwrote:

 Hi,

  Speaking of website improvement, I've just dropped in a proposal for a
  refined - and more importantly _vector-based_ - QGIS logo here:
  http://hub.qgis.org/issues/6688
 
  I've tried to stick to the original logo as much as possible as clearly
  many people are emotionally attached to the current logo. Hopefully, the
  proposal also refines the logo with more subtle lightning.
 
  Having QGIS' website use _one_ standard logo throughout (i.e. header
 logo,
  download button logo, etc.) would already be a nice improvement.
 
  Hope this can be of use to the project.

 Concerning the logo, could we have a definitive and community-based poll or
 contest on the 2.0 version logo ?

 I know the current one has supporters, and it has been there for a long
 time,
 charged with emotion and all. I like it for that reason too, but it is
 definitly not professional neither modern-looking.
 I get this remark quite often during training session, and it is quite sad
 for
 the QGIS «branding» as a professionnal and serious tool.

 Vincent

 
  Cheers,
 
  Math
 
  On Wed, Nov 14, 2012 at 5:48 AM, Tim Sutton li...@linfiniti.com wrote:
   Hi
  
   Yes I have seen it. With no disrespect to the GRASS folks I think it
 has
   enough problems that I would not like to copy it on our site. My
   (hopefully) constructive criticisms:
  
   * its very busy
   * it doesnt have good whitespace balance e.g. module of the day box
 with
   screenshots box floating to the right
   * I love jquery but jquery css is looking old already
   * there are too many underlines [ ]   and other characters that
   distract attention and make it look not so friendly
   * the panels on the left (search, latest news, map) should have been
 put
   to the right
   * there is too much white space in the heading area
   * the logo really needs a refresh
   * the heavy green bars distract your eye away from the content
   * there are too many different font sizes and font styles
   * the drop down menus feel visually disconnected from the tabs the
 spring
   from and menus from tabs just feels kinda wierd
  
   In short it could really use a designer to introduce balance, correct
   emphasis and remove distractions
  
   As such I would not be supportive of using it for our site I suggest to
   wait for the sphinx theme based on bootstrap to come out and then start
   moving our web content into that. We will do some customisations for
 the
   QGIS front page and Richard has been making awesome progress in
 getting a
   well put together bootstrap based sphinx theme in place for us when we
   can then skin using any bootstrap theme (e.g. checkout some of the
   themes at http://bootswatch.com/).
  
   So -1 from me
  
   Regards
  
   Tim
  
   On Wed, Nov 14, 2012 at 12:14 AM, Werner Macho
 werner.ma...@gmail.comwrote:
   Hi there!
  
   Anyone seen the new GRASS Webpage?
   I really like the clean and intuitive style with lots of information
   presented clearly on the top page ..
   Probably we can adapt it to our new webpage?
   It even looks good on mobile phones ..
  
   Opinions on that?
  
   kind regards
   Werner
   ___
   Qgis-developer mailing list
   Qgis-developer@lists.osgeo.org
   http://lists.osgeo.org/mailman/listinfo/qgis-developer
  
   --
   Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
   ==
   Please do not email me off-list with technical
   support questions. Using the lists will gain
   more exposure for your issues and the knowledge
   surrounding your issue will be shared with all.
  
   Visit http://linfiniti.com to find out about:
* QGIS programming and support services
* Mapserver and PostGIS based hosting plans
* FOSS Consulting Services
  
   Skype: timlinux
   Irc: timlinux on #qgis at freenode.net

Re: [Qgis-developer] Multicolumn legends in print composer

2012-11-14 Thread Mathieu Pellerin

I can confirm both issues raised by Andreas.

Beyond that, very useful feature.


On Wed, Nov 14, 2012 at 5:11 PM, Andreas Neumann a.neum...@carto.netwrote:

 Hi,

 Thanks to Radim we now have multi-column legends in print composer. This
 was one of my long-time feature requests - but it never got to the top
 of my requests so that we could pay for the work.

 Generally it works great, but I noticed two strange behaviors:

 * when having only one column (default) - the background rectangle is
 way too small, not covering the full bouding box of the legend
 * when going beyong 4 columns, QGIS gets really slow, hangs or crashes.

 Did other test the new multicolumn legends?

 Thanks Radim for your work!

 Andreas
 ___
 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] Announce QTiles plugin

2012-12-30 Thread Mathieu Pellerin

This is probably the best gift given out this christmas : )

Alexander, quick question, does QTiles render the tiles in the CRS defined
by the project, or does it automatically switches to the Google Mercator?

Best,

Math


On Wed, Dec 26, 2012 at 9:24 PM, G. Allegri gioha...@gmail.com wrote:

 Wow, thanks for this very useful Christmas gift!
 I'm gonna test it next days for a real application ;-)

 giovanni

 Sent from Nexus
 Il giorno 26/dic/2012 14:25, Alexander Bruy alexander.b...@gmail.com
 ha scritto:

 Hi all and sorry for cross-posting,

 we (NextGIS) are pleased to announce QTiles plugin for QGIS.

 QTiles designed to generate raster tiles from QGIS projects according
 to the Slippy Map specification [0] and supports two output types:
 directory and ZIP-archive.

 You can get plugin from official repo (don't forget to enable
 experimental plugins). Comments and bugreports are welcome.

 Merry Christmas and happy New Year!

 [0] http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

 --
 Alexander Bruy
 ___
 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] Announce QTiles plugin

2012-12-30 Thread Mathieu Pellerin

Alex, alright, should have looked at the source code before asking
something that could be answered quite easily. :)

Few comments and observations after playing with the plugin this morning:
- QTiles currently renders tiles without applying antialiasing, resulting
in jagged lines. IMO, disabling antialiasing should be optional, maybe
through a checkbox in the rendering option window. I've enabled
antialiasing by adding painter.setRenderHint(QPainter.Antialiasing) below
line 167 in titlingthread.py
- The tile background color is hardcoded to be white (line 165,
titlingthread.py); it might be better to take the background color from the
project's background color setting? The project I used to test out QTiles
has a gray background color set through the project settings, and the
QTiles white background got me going huh? for a minute :)
- As it stands, the labelling rendering is kind of a mess. I understand
this isn't something that can be fixed at the QTiles level. Might be worth
coordinating with Larry Shafter to see whether there are quick fixes that
could be applied to improve things.
- To take care of some of the label cut-off, would it be possible for you
to not only render the 256x256 tile, but instead do something like this:
render a 3 x 3 matrix of 256 x 256 tiles, and save only the central 256 x
256 region as the PNG tile. It wouldn't take care of all label issues, but
it'd help reduce it.
- One other thing that could be done at the QTiles level is to warn users
when it detects that polygon layer(s) are using most problematic
labelling settings (i.e. I'm thinking here of relying on centroid of
visible polygon centroid, which results in labels duplicated many, many
times for each tiles with big polygons, such as provincial / district
boundaries)

Other than that, I'm loving it more and more ;)

Math



On Mon, Dec 31, 2012 at 8:46 AM, Mathieu Pellerin nirvn.a...@gmail.comwrote:

 This is probably the best gift given out this christmas : )

 Alexander, quick question, does QTiles render the tiles in the CRS defined
 by the project, or does it automatically switches to the Google Mercator?

 Best,

 Math


 On Wed, Dec 26, 2012 at 9:24 PM, G. Allegri gioha...@gmail.com wrote:

 Wow, thanks for this very useful Christmas gift!
 I'm gonna test it next days for a real application ;-)

 giovanni

 Sent from Nexus
 Il giorno 26/dic/2012 14:25, Alexander Bruy alexander.b...@gmail.com
 ha scritto:

 Hi all and sorry for cross-posting,

 we (NextGIS) are pleased to announce QTiles plugin for QGIS.

 QTiles designed to generate raster tiles from QGIS projects according
 to the Slippy Map specification [0] and supports two output types:
 directory and ZIP-archive.

 You can get plugin from official repo (don't forget to enable
 experimental plugins). Comments and bugreports are welcome.

 Merry Christmas and happy New Year!

 [0] http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

 --
 Alexander Bruy
 ___
 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] Announce QTiles plugin

2012-12-31 Thread Mathieu Pellerin

One more thing, it would be very useful to offer users the possibility of
having transparent background (i.e. no white or project setting background
filling color).


On Mon, Dec 31, 2012 at 10:47 AM, Mathieu Pellerin nirvn.a...@gmail.comwrote:

 Alex, alright, should have looked at the source code before asking
 something that could be answered quite easily. :)

 Few comments and observations after playing with the plugin this morning:
 - QTiles currently renders tiles without applying antialiasing, resulting
 in jagged lines. IMO, disabling antialiasing should be optional, maybe
 through a checkbox in the rendering option window. I've enabled
 antialiasing by adding painter.setRenderHint(QPainter.Antialiasing) below
 line 167 in titlingthread.py
 - The tile background color is hardcoded to be white (line 165,
 titlingthread.py); it might be better to take the background color from the
 project's background color setting? The project I used to test out QTiles
 has a gray background color set through the project settings, and the
 QTiles white background got me going huh? for a minute :)
 - As it stands, the labelling rendering is kind of a mess. I understand
 this isn't something that can be fixed at the QTiles level. Might be worth
 coordinating with Larry Shafter to see whether there are quick fixes that
 could be applied to improve things.
 - To take care of some of the label cut-off, would it be possible for you
 to not only render the 256x256 tile, but instead do something like this:
 render a 3 x 3 matrix of 256 x 256 tiles, and save only the central 256 x
 256 region as the PNG tile. It wouldn't take care of all label issues, but
 it'd help reduce it.
 - One other thing that could be done at the QTiles level is to warn users
 when it detects that polygon layer(s) are using most problematic
 labelling settings (i.e. I'm thinking here of relying on centroid of
 visible polygon centroid, which results in labels duplicated many, many
 times for each tiles with big polygons, such as provincial / district
 boundaries)

 Other than that, I'm loving it more and more ;)

 Math



 On Mon, Dec 31, 2012 at 8:46 AM, Mathieu Pellerin nirvn.a...@gmail.comwrote:

 This is probably the best gift given out this christmas : )

 Alexander, quick question, does QTiles render the tiles in the CRS
 defined by the project, or does it automatically switches to the Google
 Mercator?

 Best,

 Math


 On Wed, Dec 26, 2012 at 9:24 PM, G. Allegri gioha...@gmail.com wrote:

 Wow, thanks for this very useful Christmas gift!
 I'm gonna test it next days for a real application ;-)

 giovanni

 Sent from Nexus
 Il giorno 26/dic/2012 14:25, Alexander Bruy alexander.b...@gmail.com
 ha scritto:

 Hi all and sorry for cross-posting,

 we (NextGIS) are pleased to announce QTiles plugin for QGIS.

 QTiles designed to generate raster tiles from QGIS projects according
 to the Slippy Map specification [0] and supports two output types:
 directory and ZIP-archive.

 You can get plugin from official repo (don't forget to enable
 experimental plugins). Comments and bugreports are welcome.

 Merry Christmas and happy New Year!

 [0] http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

 --
 Alexander Bruy
 ___
 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] Multicolumn legends in print composer

2013-02-18 Thread Mathieu Pellerin

Radim,

Following up on your implementation of the nice legend's multicolumn
feature. I've noticed two regression (one of which I've filed a bug
already).

1) The right-side box spacing is now miscalculated as it fails to add the
icon label space value. Issue 7099 (http://hub.qgis.org/issues/7099) has
been filed with more details and a accompanying screenshot.

2) There also was a regression in the way vertical spacing is calculate
between layer items and layers. An old issue, 3605, highlighted a similar
visual problem which was fixed in revision 08c88575 (
http://hub.qgis.org/projects/quantum-gis/repository/revisions/08c885759bd280339605ea07a221ab20f7dfdb75/diff/).
Long story short, layers with no titles are often used as part of a group
of layer items. As such, the solution found in the cited revision was to
take into account the layer item vertical spacing to the layer vertical
spacing. The multicolumn appear to have regressed this. I can open an issue
with screenshots if necessary.

Mathieu

On Sun, Nov 18, 2012 at 12:10 AM, Radim Blazek radim.bla...@gmail.comwrote:

On Wed, Nov 14, 2012 at 11:11 AM, Andreas Neumann a.neum...@carto.net
wrote:
Hi,

Thanks to Radim we now have multi-column legends in print composer.

Thanks to Régis and Agence de l'eau Adour as it was already mentioned by
others.

This
was one of my long-time feature requests - but it never got to the top
of my requests so that we could pay for the work.

Generally it works great, but I noticed two strange behaviors:

* when having only one column (default) - the background rectangle is
way too small, not covering the full bouding box of the legend

Width? Fixed.

* when going beyong 4 columns, QGIS gets really slow, hangs or crashes.

Splitting of layers into columns is not that easy as it seems to be.
It is a special sort of bin packing problem (NP-hard). Maybe it has
its own name? I have used brute force because:
- I thought that the number of layer will never be too big
- implementaion of heuristic algorithm for such a marginal feature
seemed to be overkill
- suboptimal solution could look quite bad

You proved immediately that I was wrong. How many layers do you have?
70 I have read somewhere? My original idea was to calculate number of
possibilities first and decide if heuristic should be used. Now it
seems a necessity.

Maybe I am wrong and there is a simple solution? Well, I did not know
at the beginning that I am going to solve combinatorial exercises.

Regarding the crash, I was quite careful, using value() where there
was minimum suspicion that it could run out of range. Many
combinations should not mean allocation of a lot of memory, just more
computational time. Only one combination is always evaluated at time.
Does it seem to be a memory allocation problem or out of list bounds?
Could you send me backtrace off list?

Please follow/comment http://hub.qgis.org/issues/1841

Radim

Did other test the new multicolumn legends?

Thanks Radim for your work!

Andreas
___
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] New OpenStreetMap integration

2013-02-28 Thread Mathieu Pellerin

Martin,

Nice, glad the OSM download/import support is being worked on.

I've just tried to import two OSM files: one which I had saved through
JOSM, and the other one downloaded just now via your Download OSM Data
dialogue. With both files, QGIS fails to import data with this error:

Failed to import OSM data:

Error executing SQL command:

wrong number of arguments to function InitSpatialMetadata()

SQL:

SELECT InitSpatialMetadata('WGS84')


Running on a osgeo4win master build (revision 3e8be6c).


Best,


Mathieu



On Fri, Mar 1, 2013 at 4:35 AM, Martin Dobias wonder...@gmail.com wrote:

 Hi all

 so finally I have pushed my initial work on OpenStreetMap integration
 to master... d'oh I have missed The Open Data Day (Feb 23) by few
 days! The idea is to completely replace the current OpenStreetMap
 provider and plugin. As announced in the list before, the new OSM
 support is read-only and right now I have no plans to add editing
 functionality. Editing would mean a _lot_ of work - map tools,
 tracking of changes, conflict resolution - and there are already great
 programs for editing OSM data.

 If you would like to test the new stuff, go to menu Vector 
 OpenStreetMap. No need to enable any plugins. The workflow should be:
 0. get OSM XML file (from web or download in GUI)
 1. import XML file to a SQLite topology database (once)
 2. export SpatiaLite layers from topology with a fixed set of tags -
 attributes

 Integrated download uses Overpass API, so you should be able to
 download data from any extent size. The download server in GUI is
 currently fixed to overpass-api.de. When using download, make sure to
 set high timeout (Options  Network  Timeout for network requests) -
 currently there's a problem with QGIS network manager - it will time
 out after the fixed time even if the data is being continuously
 received.

 The work is by no means complete, there are various pieces missing,
 though it should be already usable. Some features I would like to add:
 - advanced download queries (e.g. filtering by tags)
 - filtering on export (e.g. export only railroads, only restaurants)
 - python bindings
 - support for relations
 - identification GUI (e.g. see all tags, even those not exported)

 There is a low-level API in qgis analysis library which should allow
 3rd party tools/plugins do some work with OSM data (currently
 QgsOSMDownload, QgsOSMXmlImport and QgsOSMDatabase classes).

 Please let me know what do you think about it or if you encounter any bugs.

 I will be removing the OSM provider+plugin very soon. This is another
 piece from the master plan for removal of old symbology (OSM provider
 implements a renderer based on old symbology).

 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

Re: [Qgis-developer] New OpenStreetMap integration

2013-03-03 Thread Mathieu Pellerin

Martin, the InitSpatialMetadat() error is gone, and things are working
quite nicely.

For the record, this new OSM support fixed a very irritating bug from the
old implementation: closed way roundabouts are imported as lines! Big bonus.

Playing around with it, I was wondering whether - for the sake of offering
a better user experience - the import topology from XML and export topology
to spatialite  should be merged into one action. Realistically, my guess is
very few QGIS users will want to _only_ do an import to topology step.
Merging both into one would simplify things for the average Joe.

In that regard, it might also be good to offer (via a checkbox?) to
automatically load the resulting spatialite line / polygon db into the
active project.

Beyond that, it's working like a charm.

M



On Fri, Mar 1, 2013 at 2:25 PM, Martin Dobias wonder...@gmail.com wrote:

 On Fri, Mar 1, 2013 at 5:45 AM, Mathieu Pellerin nirvn.a...@gmail.com
 wrote:
  Martin,
 
  Nice, glad the OSM download/import support is being worked on.
 
  I've just tried to import two OSM files: one which I had saved through
 JOSM,
  and the other one downloaded just now via your Download OSM Data
 dialogue.
  With both files, QGIS fails to import data with this error:
 
  Failed to import OSM data:
 
  Error executing SQL command:
 
  wrong number of arguments to function InitSpatialMetadata()
 
  SQL:
 
  SELECT InitSpatialMetadata('WGS84')

 That's presumably the problem Borys had - should be fixed in master now.

 Martin

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

Re: [Qgis-developer] Feature freeze commencing the ides of March

2013-03-04 Thread Mathieu Pellerin

The new diagrams engine is solid, working better than the old one in all
the scenarios I've met. It's only weakness is that it doesn't play well
with the PAL engine.

M


On Tue, Mar 5, 2013 at 2:10 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:

 On 03/05/2013 08:06 AM, Alexander Bruy wrote:

 On Tue, 5 Mar 2013 01:28:30 +0100
 Martin Dobias wonder...@gmail.com wrote:

  I would also like to finally remove old symbology - whether being fully
 replaced by features in new symbology or not - otherwise we will need to
 live the whole 2.x release cycle with old symbology.

 But what about other duplicate things like old labeling and
 diagrams? As I understand Marco works on improving new symbology
 (data-defined settings) so old one can be removed too. Regarding
 diagrams, if I'm not wrong, new implementation has same features
 as old and can replace it smoothly.

  Diagrams should be ready for 2.0. The code has been merged about half a
 year ago.

 __**_
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://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] Multicolumn legends in print composer

2013-03-13 Thread Mathieu Pellerin

Radim,

Thanks for fixing the width issue.

Regarding layers with no titles and the need for treating the space like a
layer item, see http://hub.qgis.org/issues/3605. We've discussed this with
Marco Hugentobler back then and came up with a nice compromise.

Beyond being a regression as it stands (i.e. legends from 1.8 projects will
have visible vertical spacing issues), here's a simple scenario in picture:
http://hub.qgis.org/attachments/3161/legend-simple-scenario.jpg (the
spacing should be equal for all companies, as well as btween roads and
railways.

Having no layer title is a way to regroup many layers under one layer name
(i.e. having 5 shapefile polygons representing different ago-industrial
crops might nicely be represented under one layer title even though the
items are in five different physical shapefiles).

Math

On Wed, Mar 13, 2013 at 5:31 PM, Radim Blazek radim.bla...@gmail.comwrote:

On Tue, Feb 19, 2013 at 4:48 AM, Mathieu Pellerin nirvn.a...@gmail.com
wrote:
Radim,

Following up on your implementation of the nice legend's multicolumn
feature. I've noticed two regression (one of which I've filed a bug
already).

Fixed.

2) There also was a regression in the way vertical spacing is calculate
between layer items and layers. An old issue, 3605, highlighted a similar
visual problem which was fixed in revision 08c88575
(
http://hub.qgis.org/projects/quantum-gis/repository/revisions/08c885759bd280339605ea07a221ab20f7dfdb75/diff/
).
Long story short, layers with no titles are often used as part of a
group of
layer items. As such, the solution found in the cited revision was to
take
into account the layer item vertical spacing to the layer vertical
spacing.
The multicolumn appear to have regressed this. I can open an issue with
screenshots if necessary.

Layers with no titles? Is it a hack to avoid the layer title to be
drawn in the legend for single symbol layers? Wouldn't it be better to
modify composer legend so that single symbol layers will be drawn
without separated layer title above symbol and the layer title text
will be used as the symbol label?

Radim

Mathieu

On Sun, Nov 18, 2012 at 12:10 AM, Radim Blazek radim.bla...@gmail.com
wrote:

On Wed, Nov 14, 2012 at 11:11 AM, Andreas Neumann a.neum...@carto.net
wrote:
Hi,

Thanks to Radim we now have multi-column legends in print composer.

Thanks to Régis and Agence de l'eau Adour as it was already mentioned by
others.

This
was one of my long-time feature requests - but it never got to the top
of my requests so that we could pay for the work.

Generally it works great, but I noticed two strange behaviors:

* when having only one column (default) - the background rectangle is
way too small, not covering the full bouding box of the legend

Width? Fixed.

* when going beyong 4 columns, QGIS gets really slow, hangs or
crashes.

Maybe I am wrong and there is a simple solution? Well, I did not know
at the beginning that I am going to solve combinatorial exercises.

Please follow/comment http://hub.qgis.org/issues/1841

Radim

Did other test the new multicolumn legends?

Thanks Radim for your work!

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

Re: [Qgis-developer] Multicolumn legends in print composer

2013-03-14 Thread Mathieu Pellerin

What's described below is cool, would work out just fine : ) having this
alongside groups would work perfectly, probably even better than hack-ish
status of the past.

On Thu, Mar 14, 2013 at 4:05 PM, Régis Haubourg
regis.haubo...@eau-adour-garonne.fr wrote:

Hi,

+1 with Radim. Such hacks do produce inconsistencies and bugs not
compatible with collaborative coding. IMHO, we need clean coding in QGIS.

A feature already asked I remember could solve both issues. Some of us
asked that for layers having single symbol style, symbol in legend should
be drawn on the same line as layer’s title (like in Arcgis or mapinfo).
http://hub.qgis.org/issues/6960

** **

Using groups will then help reaching Mathieu’s goal?

Opinions?

** **

I’m ready to put that in a contract if needed

Régis

** **

*De :* Radim Blazek-2 [via OSGeo.org] [mailto:ml-node+[hidden
email]http://user/SendEmail.jtp?type=nodenode=5040290i=0]

*Envoyé :* jeudi 14 mars 2013 09:47
*À :* HAUBOURG
*Objet :* Re: Multicolumn legends in print composer

** **

IMO, using empty layer title to achieve grouping of items from
multiple layers into a single layer (group) is just a workaround. If
it was working for some reason in previous versions (probably because
there was no difference between layer and item spacing) it does not
mean that we must add new and new hacks to the code to support it
forever.

I am not convinced that removing layer space if the layer title is
empty (
http://hub.qgis.org/projects/quantum-gis/repository/revisions/08c8857/diff/src/core/composer/qgscomposerlegend.cpp)

is good. It is a hack to support your need but it introduces another
bug and inconsistency because other user may require hidden layer
titles (if empty) but still keeping layer spacing.

A clean solution could be to add a new group Road Railways with
roads and railways layers inside and implement something like flatten
sublayers check box for the group, which would put items of all
sublayers directly into the group, ignoring layer titles.

Radim

On Wed, Mar 13, 2013 at 1:30 PM, Mathieu Pellerin [hidden
email]http://user/SendEmail.jtp?type=nodenode=5040281i=0
wrote:

Radim,

Thanks for fixing the width issue.

Regarding layers with no titles and the need for treating the space like
a
layer item, see http://hub.qgis.org/issues/3605. We've discussed this
with
Marco Hugentobler back then and came up with a nice compromise.

Beyond being a regression as it stands (i.e. legends from 1.8 projects
will
have visible vertical spacing issues), here's a simple scenario in
picture:
http://hub.qgis.org/attachments/3161/legend-simple-scenario.jpg (the
spacing
should be equal for all companies, as well as btween roads and railways.

Having no layer title is a way to regroup many layers under one layer
name
(i.e. having 5 shapefile polygons representing different ago-industrial
crops might nicely be represented under one layer title even though the
items are in five different physical shapefiles).

Math

On Wed, Mar 13, 2013 at 5:31 PM, Radim Blazek [hidden
email]http://user/SendEmail.jtp?type=nodenode=5040281i=1

wrote:

On Tue, Feb 19, 2013 at 4:48 AM, Mathieu Pellerin [hidden
email]http://user/SendEmail.jtp?type=nodenode=5040281i=2

wrote:
Radim,

Following up on your implementation of the nice legend's multicolumn
feature. I've noticed two regression (one of which I've filed a bug
already).

1) The right-side box spacing is now miscalculated as it fails to add
the
icon label space value. Issue 7099 (http://hub.qgis.org/issues/7099)
has
been filed with more details and a accompanying screenshot.

Fixed.

2) There also was a regression in the way vertical spacing is
calculate
between layer items and layers. An old issue, 3605, highlighted a
similar
visual problem which was fixed in revision 08c88575

(
http://hub.qgis.org/projects/quantum-gis/repository/revisions/08c885759bd280339605ea07a221ab20f7dfdb75/diff/).

Long story short, layers with no titles are often used as part of a
group of
layer items. As such, the solution found in the cited revision was to
take
into account the layer item vertical spacing to the layer vertical
spacing.
The multicolumn appear to have regressed this. I can open an issue
with
screenshots if necessary.

Radim

Mathieu

On Sun, Nov 18, 2012 at 12:10 AM, Radim Blazek [hidden
email]http://user/SendEmail.jtp?type=nodenode=5040281i=3

wrote:

On Wed, Nov 14, 2012 at 11:11 AM, Andreas Neumann [hidden

Re: [Qgis-developer] feature-freeze exception -- blend modes and transparency for composer items

2013-04-01 Thread Mathieu Pellerin

Nyall, those are really great additions.
When you have a minute, you should look at a blend modes issue I spotted
and described over here: http://hub.qgis.org/issues/7461

Cheers.

Math
On 1 Apr 2013 18:14, Nyall Dawson nyall.daw...@gmail.com wrote:

 Hi all,

 I realise I missed the feature freeze by a couple of hours, but I'm
 hoping an exception can be made for this pull request:

 https://github.com/qgis/Quantum-GIS/pull/493

 Basically, this adds blending modes for composer items (in line with
 the recent addition of blend modes for layers  labels). It also adds
 a transparency slider for composer items which can be used to control
 the opacity of the items.

 It'd be a nice feature to have in 2.0 if an exception is possible!

 Cheers,
 Nyall
 ___
 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] Old symbology removed in master

2013-04-08 Thread Mathieu Pellerin

Re texture fill, does the svg fill support bitmap within svg?

M
On 8 Apr 2013 13:25, Andreas Neumann a.neum...@carto.net wrote:

Hi Martin,

Thank you for your work on removing the old symbology stuff.

Marco is working on data-defined symbology and it is already in master.
These are now all on the symbol level as you may want different rotations
for each component of a combined symbol. Also the units are now more
fine-grained. As an exaple you can define a size in map units and the
outline in mm.

I agree that the texture for fill style is obsolete as we have the line
and point pattern editors and SVG patterns.

Andreas

On Mon, 8 Apr 2013 00:38:37 +0200, Martin Dobias wrote:

just a quick note that old symbology API has been removed: QgsRenderer
(+ implementations), QgsSymbol and few others are gone. Projects using
old symbology still can be loaded and old symbology will be
automatically converted to new symbology (just in memory, so if you do
not save the project it will continue using old symbology). There are
few things that are currently not being converted properly to new
symbology:
- data-defined rotation / scale / symbol name - TODO
- map units flag for point symbol - TODO
- texture for fill style - no equivalent in new symbology (svg fill is
better anyway)
- continuous color renderer - no equivalent in new symbology
(graduated symbol renderer may be used instead)
- composer - legend items for old symbology are ignored and need to be
recreated manually

Old labeling has been kept as-is - there's not so much code involved
(basically just one class, QgsLabel) so it's not such hot topic within
the API cleanup.

I am aware that few unit tests related to rendering got broken, I will
fix them soon. (btw. there are few failing tests not related to the
symbology changes: qgis_atlascompositiontest, qgis_composerhtmltest)

How do others feel about dropping V2 postfix from new symbology
classes for QGIS 2.0? E.g. QgsSymbol instead of QgsSymbolV2. I would
like to see those removed to keep the API clean.

Regards
Martin
__**_
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://lists.osgeo.org/mailman/listinfo/qgis-developer

--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
__**_
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/**mailman/listinfo/qgis-**developerhttp://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] fTools and GdalTools: sextante vs original plugins

2013-04-16 Thread Mathieu Pellerin

There might be a way to make most people happy here.

I find the vector menu a nice ui shortcut for useful functions. If sextante
relevant functions are at par (or better), couldn't the vector menu items
stay, which would please many, and when clicked triggers sextante's
function dialogue? Victor? Same thing could happen with vector menu too.
Sextante's analysis toolbar is super useful but might be a throwback for
some if vector / raster menu functions disappear.

On human resource (coders and testers) and maintenance angles, keeping to
mechanism to do same thing is an obvious waste.

M
On 16 Apr 2013 23:53, Victor Olaya vola...@gmail.com wrote:

My opinion on this (clearly biased, of course), is that the argument
of not making sense to look for algorithms under a menu called
sextante is not a very strong one. First, the menu is called
Analysis (which makes much more sense that looking for processes in
something called vector, since that is much more generic).
Second, I think that SEXTANTE is not much different than GDAL or
GRASS, since they are all acronyms.

But, as I said, I have a biased opinion...and I might be too used to
the name :-)

All ideas (thanks Anita for your ones!) about what is missing in
SEXTANTE to fully replace those independent plugins, are welcome

Regards
Victor

2013/4/16 Anita Graser anitagra...@gmx.at:
Hi,

I know this thread has been silent for a while but I think it's
important to
bring it up once more.
I'm currently trying to develop some materials and wondering if they
should
cover ftools/GDAL or Sextante mainly. Currently, it sounds like it is
certain that Sextante will be around in future versions while the future
of
ftools/GDAL tools is less certain.

I don't care much about ftools. I don't like having to create new
Shapefiles
every time I run an algorithm. I never managed to remember which tool is
in
which submenu.

In case of GDAL tools, I see the advantage of being able to copy the GDAL
code.

In Sextante, it's easy to find the tools by name and the results can be
temporal layers. So I strongly disagree with previous arguments that
Sextante is not valuable from a user perspective.

Even if we don't reach a consensus whether both menus and toolbox should
be
around permanently, could someone please confirm what will be the
situation
in 2.0? Are there any plans to remove anything for the release? Have any
decisions been made for after 2.0 yet?

Thanks and best wishes,
Anita

--
View this message in context:
http://osgeo-org.1560.x6.nabble.com/fTools-and-GdalTools-sextante-vs-original-plugins-tp5041430p5047360.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

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

Re: [Qgis-developer] fTools and GdalTools: sextante vs original plugins

2013-04-17 Thread Mathieu Pellerin

Anita, yep, remove code for ftool functions that are in sextante but keep
vector menu shortcuts.
On 17 Apr 2013 12:42, Anita Graser anitagra...@gmx.at wrote:

 On Wed, Apr 17, 2013 at 3:19 AM, Mathieu Pellerin nirvn.a...@gmail.comwrote:

 There might be a way to make most people happy here.

 I find the vector menu a nice ui shortcut for useful functions. If
 sextante relevant functions are at par (or better), couldn't the vector
 menu items stay, which would please many, and when clicked triggers
 sextante's function dialogue? Victor? Same thing could happen with vector
 menu too. Sextante's analysis toolbar is super useful but might be a
 throwback for some if vector / raster menu functions disappear.

 On human resource (coders and testers) and maintenance angles, keeping to
 mechanism to do same thing is an obvious waste.

 I see. So you'd suggest to keep only Sextante code (where duplicates
 exist!) but provide shortcuts from the menu? I'd +1 that.
 I've been testing a variety of functions in the menus and in Sextante over
 the last days and there are always some broken ones. Neither package is
 without major bugs today.
 We need to get it together for 2.0 and that's easier if we can focus on
 one.

 Best wishes,
 Anita



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

Re: [Qgis-developer] fTools and GdalTools: sextante vs original plugins

2013-04-17 Thread Mathieu Pellerin

Paolo, imo decision of looking into this option for 2.0 vs 2.1 should be
primarily driven by quality. If qgis can offer better  quality in vector
functions by maintaining the two mechanism for 2.0 then it should be
deferred to 2.1. If the opposite is true, then might be worth for Victor to
weight in and state whether such proposal can be achieved for 2.0.

M
On 17 Apr 2013 13:14, Paolo Cavallini cavall...@faunalia.it wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 17/04/2013 07:42, Anita Graser ha scritto:

  I see. So you'd suggest to keep only Sextante code (where duplicates
 exist!) but
  provide shortcuts from the menu? I'd +1 that.
  I've been testing a variety of functions in the menus and in Sextante
 over the last
  days and there are always some broken ones. Neither package is without
 major bugs
  today.
  We need to get it together for 2.0 and that's easier if we can focus on
 one.

 Hi all.
 My proposal:
 * leave the duplication for 2.0
 * go towards removing it for 2.1, *only* when a full testing framework is
 in place,
 and we are *sure* everythiong is working properly
 * leave shortcuts for the most commonly used functions (maybe a poll can
 help here),
 and possibly an option add to shortcut menu for the user
 * leave the commandline available for the programs that allow running it
 straight
 away (gdal, grass, saga, ?), so users can reuse them in scripts etc.
 All the best.
 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlFuPaYACgkQ/NedwLUzIr4s0QCeJzjM/G4tJChlrV0NEyuBFOXb
 O8UAoIzjcBObUuEhcJFca2uf55BDNAcg
 =n3af
 -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

[Qgis-developer] sextante: missing GRASS pan sharpening function (i.fusion.brovey)

2013-04-21 Thread Mathieu Pellerin

Victor,

Would it be possible for you to add GRASS' pan sharpening function
(i.fusion.brovey) to sextante? I'm sure that'll make more than one guy
happy :)

Keep up the good work, lots of very nice tweaks to sextante lately.

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

Re: [Qgis-developer] sextante: missing GRASS pan sharpening function (i.fusion.brovey)

2013-04-22 Thread Mathieu Pellerin

Paolo, nice, didn't know it was that easy to add new functions.

I gave it a go, but something's wrong as the output raster isn't
created. It might have to do with the fact that i.fusion.brovey
doesn't seem to have a raster's output parameter. Instead, and
somewhat unique to this i. function, it has an outputprefix parameter
(see http://grass.osgeo.org/grass64/manuals/i.fusion.brovey.html).
I've tried to simply use that parameter as a placeholder for
sextante's OutputRaster syntax, but it doesn't seem to work.

Victor, do you know what's happening here? Here's the
i.fusion.brovey.txt syntax being used (and failing ATM):

i.fusion.brovey
i.fusion.brovey - Brovey transform to merge multispectral and high-res
panchromatic channels.
Imagery (i.*)
ParameterRaster|ms1|Name of input raster map (green: tm2 / qbird_green
/ spot1)|False
ParameterRaster|ms2|Name of input raster map (NIR: tm4 / qbird_nir /
spot2)|False
ParameterRaster|ms3|Name of input raster map (MIR; tm5 / qbird_red /
spot3)|False
ParameterRaster|pan|Name of input raster map (etmpan / qbird_pan /
spotpan)|False
ParameterBoolean|-l|LANDSAT sensor|False
ParameterBoolean|-q|QuickBird sensor|False
ParameterBoolean|-s|SPOT sensor|False
OutputRaster|outputprefix|Prefix of output raster |False


Math

On Mon, Apr 22, 2013 at 12:01 PM, Paolo Cavallini cavall...@faunalia.it wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 22/04/2013 04:31, Mathieu Pellerin ha scritto:
 Victor,

 Would it be possible for you to add GRASS' pan sharpening function
 (i.fusion.brovey) to sextante? I'm sure that'll make more than one guy
 happy :)

 Keep up the good work, lots of very nice tweaks to sextante lately.

 Hi Mathieu,
 please have a look to:
 https://github.com/qgis/Quantum-GIS/blob/master/python/plugins/sextante/grass/grass.txt
 It is reasonably easy to add command yourself. If successful, you can send 
 the file
 to Victor, or better issue a pull request for it.
 Thanks!
 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlF0xD0ACgkQ/NedwLUzIr7eQACeNZp1Zb7N+3CqsUZmDz0YKCBG
 b1QAnRZX645dJOGRIhZYwlfzPy/CU8aO
 =7wPK
 -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

[Qgis-developer] serious regression out of new vector api needs attention prior to 2.0

2013-04-23 Thread Mathieu Pellerin

Greetings,

I've filed an issue over the weekend which IMO is a really serious
regression which shouldn't be left unresolved prior to the imminent
2.0 release.

Long story short, when a layer symbology is set to categorized,
graduated, or rule-based, all features will disappear when editing
feature(s) on that layer (by moving feature or one of its vertex). If
the user then leave the edit mode (saving changes or not), all
features will reappear.

When features disappear, an error pops up in the log window saying
Already active iterator on this provider was closed.

Data itself is not impacted, but it's a super scary behavior for the
average user. It got me to cancel edits many, many times before I
understood what was happening.

Issue filed can be reached here: http://hub.qgis.org/issues/7660

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

Re: [Qgis-developer] Feature freeze exception?

2013-04-25 Thread Mathieu Pellerin

Since blend modes are found everywhere else
(vector,raster,label,composer items), an exception to allow addition
of blend mode on the only remaining gap would make sense.

On Fri, Apr 26, 2013 at 9:56 AM, Nathan Woodrow madman...@gmail.com wrote:
 +1 from me.


 On Fri, Apr 26, 2013 at 12:46 PM, Nyall Dawson nyall.daw...@gmail.com
 wrote:

 I realise we're well and truly past feature freeze now, but I've had a
 few requests for adding a blend mode option to the map overview
 control. This would be a very small, uncomplicated addition. If I code
 it up, is there any chance for permission to commit it to 2.0 now?

 Nyall
 ___
 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] Logo Update

2013-04-30 Thread Mathieu Pellerin

New logos withdrawn.

My 2 cents:

I feel like design #50 is overly generic. Simply logos are good, but
wondering whether this one went on the road of simplification to the
extreme, leaving a logo with a *slight* gap in meaningfulness. There could
be ways to remedy to that while keeping overall design intact. Maybe by
having some sort of faux-3d on the green triangle using gradients to make
it more like an arrow.

#338 has much more identify, both hinting at GIS and cooperativeness of
open source project. The color palette could be improved (maybe dark gray
or black for text, and a tango color scheme based colors for hands?), as
well as making GIS a bit smaller, moving up, and allow space for 'desktop,
android, etc.'.

Math





On Wed, May 1, 2013 at 6:02 AM, Nathan Woodrow madman...@gmail.com wrote:

 New logos have been submitted from Larry.

 Feedback?

 - Nathan


 On Wed, May 1, 2013 at 8:33 AM, skampus 
 stefano.cam...@regione.piemonte.it wrote:

 if i can say my opinion, my preference go to #338

 s.



 --
 View this message in context:
 http://osgeo-org.1560.x6.nabble.com/Logo-Update-tp5050419p5050555.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


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

Re: [Qgis-developer] New values available for plugin installer

2013-05-01 Thread Mathieu Pellerin

Re total download showing oldest plugins, might be nice to offer another
indicator based on total download _for the last four weeks_, that would
reflect better current interest.

Four weeks is arbitrary, could be eight, or two :)
On 2 May 2013 07:34, Olivier Dalang olivier.dal...@gmail.com wrote:

 Wouldn't a featured/recommended/staff pick (or call it whatever you
 like) flag be a good idea too ? Those would be plugin which are good and
 useful for most of the users (not too specific).

 It would make it easier to find the best plugins, since when sorting by
 rating, you can't distinguish good plugins for general usage from good
 plugins which are very specific, and when sorting by downloads, you'll
 mostly find good and old plugins, but not good and new plugins.


 2013/5/1 Paolo Cavallini cavall...@faunalia.it

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 01/05/2013 09:50, Borys Jurgiel ha scritto:

  I'm thinking if sorting by just average_vote is the best option. Maybe
  better use a more complex rank computed from average_vote and
 downloads or
  average_vote and rating_votes. Do anybody has any ideas for such
 rank?

 We (Alessandro with limited help from myself) tried to develop one, but
 it proved
 more tricky than expected. Ideas welcome, try a few tests to see if they
 are
 reasonable. In practical application.
 All the best.
 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlGAzBMACgkQ/NedwLUzIr77VQCgmYgeRgyMwksKo7H1mcEnFQn1
 FmsAnAgimnpJd8WLy1dG+SUvgO2rBCsg
 =fZRW
 -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


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

Re: [Qgis-developer] New values available for plugin installer

2013-05-01 Thread Mathieu Pellerin

Might be worth adding to server a one month log for plugins download and
come up with that stat.
On 2 May 2013 12:44, Alessandro Pasotti apaso...@gmail.com wrote:

 2013/5/2 Mathieu Pellerin nirvn.a...@gmail.com

 Re total download showing oldest plugins, might be nice to offer another
 indicator based on total download _for the last four weeks_, that would
 reflect better current interest.

 Four weeks is arbitrary, could be eight, or two :)

 Hi,

 Unfortunately this is not possible at the moment: we do not record each
 single download but just increment a counter.

 --
 Alessandro Pasotti
 w3:   www.itopen.it

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

Re: [Qgis-developer] Logo Update

2013-05-03 Thread Mathieu Pellerin

#419 looks really nice. The bevel / gradients need to be a tiny more
discrete, but the overall feeling and direction is great.


On Fri, May 3, 2013 at 5:05 PM, Nyall Dawson nyall.daw...@gmail.com wrote:

 #412 and #419 look great -- they're my favourites of the contest so far!

 Nyall
 ___
 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] Size scale field not working with centroid fill

2013-05-06 Thread Mathieu Pellerin

Alexandre,

Might be linked to this issue: http://hub.qgis.org/issues/7738  -- centroid
fill always use map unit even when set to millimetres.

Mathieu
On 6 May 2013 18:09, Alexandre Neto senhor.n...@gmail.com wrote:

 Hello all,

 Using Size scale field does not seam to be  working with centroid fill,
 both in 1.8 and master. Is this intended?

 Does anyone know if there is a feature\bug ticket for it? I could not find
 one.

 Alexandre Neto

 ___
 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] Creating a pool of maps showcasing QGIS upcoming v2.0 features

2013-05-06 Thread Mathieu Pellerin

Greetings all,

As we are fast approaching the day QGIS v2.0 will be release, I thought it
might be useful to create a public pool of nice maps showcasing some of the
new features that'll be available in v2.0. That should help writing release
notes (as visual examples of features will be readily available) as well as
being a nice PR effort to attract new users.

I believe quite a few of us QGIS users, as well as developers, have by now
moved on to using QGIS 1.9 to produce maps. As such, we might already have
a pretty good number of already-made maps exemplifying what's coming in
v2.0. Anita has already posted a couple of nice blog posts with photos, so
did Nyall. It'd be a matter of regrouping the maps under one umbrella.

A Flickr group has been set up over here:
http://www.flickr.com/groups/2244553@N22/

Nathan and I already uploaded a couple of maps. The concept would be to add
maps and a description highlighting the new features (see
http://www.flickr.com/photos/60284107@N00/8715653609/in/pool-2244553@N22for
example).

To upload to the Flickr group, it requires a Flickr account, which
shouldn't be too troublesome as one can link its yahoo or gmail account to
log in.

Is this something you guys would be interested in participating to?

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

Re: [Qgis-developer] Creating a pool of maps showcasing QGIS upcoming v2.0 features

2013-05-06 Thread Mathieu Pellerin

Yep, Nathan's right, let's keep this to rendered maps (via Save image
as... or the Composer). There's plenty to show there :)


On Tue, May 7, 2013 at 11:46 AM, Nathan Woodrow madman...@gmail.com wrote:

 I think it's a great idea, hence why I have already added a map of my own
 :)

 This could also come in handy for local user groups to do Map Walls by
 having some images to pick from, full credits given of course.

 I would ask though that no one upload screens shots of the application
 itself.  Keep screenshots for the manual.  This is meant to be just maps
 that have been created using QGIS.

 Regards,
 Nathan


 On Tue, May 7, 2013 at 2:41 PM, Mathieu Pellerin nirvn.a...@gmail.comwrote:

 Greetings all,

 As we are fast approaching the day QGIS v2.0 will be release, I thought
 it might be useful to create a public pool of nice maps showcasing some of
 the new features that'll be available in v2.0. That should help writing
 release notes (as visual examples of features will be readily available) as
 well as being a nice PR effort to attract new users.

 I believe quite a few of us QGIS users, as well as developers, have by
 now moved on to using QGIS 1.9 to produce maps. As such, we might already
 have a pretty good number of already-made maps exemplifying what's coming
 in v2.0. Anita has already posted a couple of nice blog posts with photos,
 so did Nyall. It'd be a matter of regrouping the maps under one umbrella.

 A Flickr group has been set up over here:
 http://www.flickr.com/groups/2244553@N22/

 Nathan and I already uploaded a couple of maps. The concept would be to
 add maps and a description highlighting the new features (see
 http://www.flickr.com/photos/60284107@N00/8715653609/in/pool-2244553@N22for 
 example).

 To upload to the Flickr group, it requires a Flickr account, which
 shouldn't be too troublesome as one can link its yahoo or gmail account to
 log in.

 Is this something you guys would be interested in participating to?

 Mathieu Pellerin



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

Re: [Qgis-developer] Creating a pool of maps showcasing QGIS upcoming v2.0 features

2013-05-07 Thread Mathieu Pellerin

I believe photos posted within Flickr Groups can be seen without need to
log in (see for e.g. http://www.flickr.com/groups/theleague/pool/). That
being said, it doesn't seem to work for the Flickr QGIS Group set up
earlier today. It might have to do an incubation time required before
Flickr opens the pool to everyone? I'll investigate reason why this is
happening today or tomorrow.

In the meantime, feel free add member status to group to see the
(hopefully) growing number of maps. :)

Math



On Tue, May 7, 2013 at 12:54 PM, Paolo Cavallini cavall...@faunalia.itwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 07/05/2013 06:46, Nathan Woodrow ha scritto:
  I think it's a great idea, hence why I have already added a map of my
 own :)

 Great initiative.
 Am I right that without logging in, only one map can be seen?
 All the best.

 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlGIlysACgkQ/NedwLUzIr7IHQCcDbi16hKpYd0KQXoMAarEMhIM
 VRgAn3mwLSVPbdr70q9LltzQQ8A+hjCf
 =1MID
 -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] Creating a pool of maps showcasing QGIS upcoming v2.0 features

2013-05-07 Thread Mathieu Pellerin

Alright, the problem is with my account, it's been inactive for too long
and it's considering my photos as suspect for the next few days. Nathan has
an active account, hence his map(s) showing when not a member.

Math


On Tue, May 7, 2013 at 1:48 PM, Mathieu Pellerin nirvn.a...@gmail.comwrote:

 I believe photos posted within Flickr Groups can be seen without need to
 log in (see for e.g. http://www.flickr.com/groups/theleague/pool/). That
 being said, it doesn't seem to work for the Flickr QGIS Group set up
 earlier today. It might have to do an incubation time required before
 Flickr opens the pool to everyone? I'll investigate reason why this is
 happening today or tomorrow.

 In the meantime, feel free add member status to group to see the
 (hopefully) growing number of maps. :)

 Math



 On Tue, May 7, 2013 at 12:54 PM, Paolo Cavallini cavall...@faunalia.itwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 07/05/2013 06:46, Nathan Woodrow ha scritto:
  I think it's a great idea, hence why I have already added a map of my
 own :)

 Great initiative.
 Am I right that without logging in, only one map can be seen?
 All the best.

 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlGIlysACgkQ/NedwLUzIr7IHQCcDbi16hKpYd0KQXoMAarEMhIM
 VRgAn3mwLSVPbdr70q9LltzQQ8A+hjCf
 =1MID
 -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] Creating a pool of maps showcasing QGIS upcoming v2.0 features

2013-05-09 Thread Mathieu Pellerin

Paolo, that issue has been fixed, thanks to flickr's quick response. The
flickr group now shows all six maps without need to be a member.

Thanks to Anita for having posted some of her QGIS 2.0-dependent maps in
the last few days.

Mathieu


On Tue, May 7, 2013 at 12:54 PM, Paolo Cavallini cavall...@faunalia.itwrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Il 07/05/2013 06:46, Nathan Woodrow ha scritto:
  I think it's a great idea, hence why I have already added a map of my
 own :)

 Great initiative.
 Am I right that without logging in, only one map can be seen?
 All the best.

 - --
 Paolo Cavallini - Faunalia
 www.faunalia.eu
 Full contact details at www.faunalia.eu/pc
 Nuovi corsi QGIS e PostGIS: http://www.faunalia.it/calendario
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAlGIlysACgkQ/NedwLUzIr7IHQCcDbi16hKpYd0KQXoMAarEMhIM
 VRgAn3mwLSVPbdr70q9LltzQQ8A+hjCf
 =1MID
 -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 2.0 and beyond

2013-05-28 Thread Mathieu Pellerin

As a first step, could we all individually go to the hub and review our
blockers to possibly remove some blockers that are not crucial to a 2.0
release or dups of previous reports? That would facilitate Giovanni's job.

Also, while ideally a product should be shipped regression-free, this needs
to be balanced with a practical need to actually release a product in a
timely fashion too. People are - at least in Southeast Asia - expecting a
major update of QGIS by mid 2013, and IMO that expectation should be
matched as closely as humanly possible.

Balancing things out would mean let's not ship QGIS with 100 open blockers,
but let's not wait six more months until we reach an elusive 0 blockers :)

M


On Wed, May 29, 2013 at 5:23 AM, Tim Sutton li...@linfiniti.com wrote:

 Hi

 On Wed, May 29, 2013 at 12:11 AM, Giovanni Manghi
 giovanni.man...@faunalia.pt wrote:
  Hi Tim,
 
 
  Giovanni could you do a triage of the blocker issue queue - it seems
  like some could be removed (e.g. http://hub.qgis.org/issues/7619
  could be closed?).
 
 
  yes I can, but (full time) not until later *next* week as I'm Cape
  Verde to give an extensive QGIS training course.
 

 Thanks Giovanni!

 Regards

 Tim

  cheers!



 --
 Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
 ==
 Please do not email me off-list with technical
 support questions. Using the lists will gain
 more exposure for your issues and the knowledge
 surrounding your issue will be shared with all.

 Visit http://linfiniti.com to find out about:
  * QGIS programming and support services
  * Mapserver and PostGIS based hosting plans
  * FOSS Consulting Services
 Skype: timlinux
 Irc: timlinux on #qgis at freenode.net
 ==
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

Re: [Qgis-developer] QGIS 2.0 and beyond

2013-06-02 Thread Mathieu Pellerin

Glad to hear you guys will meet on the 2.0 release. In the hope it can help
your meeting, I'd like to share my 2 cents as a QGIS evangelist in
Southeast Asia. Note, I'm running on QGIS master, so the argument below
isn't out of self-interest ;o)

In the beginning of March 2013, Tim announced a proposed release schedule
over the mailing list [1] which stated June 7, 2012 as date of release.
Developers generally agreed around this schedule and process moved forward.
In the meantime, QGIS end users and evangelists who keep track of
development were left with a general sense of mid-2013 as QGIS 2.0 release,
with all its glorious new features and fixes.

When doing workshops, presentation on QGIS  and discussing about it, by
end of June was the best answer I - and surely many other QGIS evangelists
praising QGIS out there - could give to people both excited about what's
coming.

But more importantly, this was a tentative dates when technical limitations
and issues would be dealt with when planning forward. For e.g. in Southeast
Asia, the broken state of Unicode shapefile encoding in QGIS 1.8 got many
people to think twice about adoption. These issues were balanced out with
an estimated date of delivery for 2.0 and plans have been drawn for QGIS
adoptions in NGOs, ministries, public offices, etc.

And this brings us to now. It seems inevitable that QGIS will have to be
delayed. IMO, QGIS must insure the delay is as short as possible, to avoid
negative impact on current end users expecting new features and issues
fixed, as well as not being an obstacle to further adoption by missing an
important deadline.

Beyond the 80+ blockers currently listed, which could be dealt with in
relatively short amount of time and focus, a SIP upgrade proposal is the
other main delayer. The argument for a delay to include the SIP upgrade
is that, since the needed new vector API broke the plugins, and the SIP
upgrade would also break plugins, the two should occur at the same time not
to piss off plugin developers with too many breakages along the line.
That's a valid argument, no question there, but shouldn’t be the only
weighting factor, nor should it open the door to an absence of hard
deadlines.

I feel that for the SIP upgrade to be considered so late in the release
process, it should be considered within _reasonable confines_ to avoid
un-managed, harmful delays. Ideally, something along the lines of merged
by this coming Sunday or delayed to post 2.0. If the attempt at upgrading
SIP is turning out to be more complex and take longer than a hard
commit-to-master deadline, it IMO should be postponed on practical grounds
of avoiding impact on QGIS end users and adoption.

Alright, I don't claim having a perfect understanding of the bigger picture
at play here, and I'm not intimately familiar with the source code, so
disregard what's not proper. :) Still hope the above point of view, from a
person trying to push for more QGIS adoption, can be of help.

Regards

Mathieu

[1] http://lists.osgeo.org/pipermail/qgis-developer/2013-March/024685.html






On Mon, Jun 3, 2013 at 4:24 AM, Tim Sutton li...@linfiniti.com wrote:

 Hi

 Thanks very much Giovanni. We are holding a PSC meeting tomorrow to
 plan the release strategy and your revisions will come in handy for
 that.

 Regards

 Tim

 On Sun, Jun 2, 2013 at 11:30 AM, Giovanni Manghi
 giovanni.man...@faunalia.pt wrote:
  Giovanni could you do a triage of the blocker issue queue - it seems
  like some could be removed (e.g. http://hub.qgis.org/issues/7619
  could be closed?).
 
  I checked the queue and cleaned it as much as possible.
 
  There is a small list of tickets that probably can be closed(*), but
  the other 71 are pretty much confirmed (almost all regressions). There
  is a bit of everything, big issues with edit tools, wfs client, ftools
  (many with memory leaks), printing, etc.
 
 
  (*)
  http://hub.qgis.org/issues/6383
 
  http://hub.qgis.org/issues/6978
 
  http://hub.qgis.org/issues/7458
 
  http://hub.qgis.org/issues/7940
 
  http://hub.qgis.org/issues/7668
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer



 --
 Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
 ==
 Please do not email me off-list with technical
 support questions. Using the lists will gain
 more exposure for your issues and the knowledge
 surrounding your issue will be shared with all.

 Visit http://linfiniti.com to find out about:
  * QGIS programming and support services
  * Mapserver and PostGIS based hosting plans
  * FOSS Consulting Services
 Skype: timlinux
 Irc: timlinux on #qgis at freenode.net
 ==
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] QGIS 2.0 and beyond

2013-06-02 Thread Mathieu Pellerin

So what's the hard deadline for SIP, this coming weekend?




On Mon, Jun 3, 2013 at 11:18 AM, Nathan Woodrow madman...@gmail.com wrote:

 On Mon, Jun 3, 2013 at 2:08 PM, Mathieu Pellerin nirvn.a...@gmail.comwrote:

 I feel that for the SIP upgrade to be considered so late in the release
 process, it should be considered within _reasonable confines_ to avoid
 un-managed, harmful delays. Ideally, something along the lines of merged
 by this coming Sunday or delayed to post 2.0. If the attempt at
 upgrading SIP is turning out to be more complex and take longer than a hard
 commit-to-master deadline, it IMO should be postponed on practical grounds
 of avoiding impact on QGIS end users and adoption.


 This is the current plan.  Victor is working on updating sextante this
 week, and Alex is working on fTools, noone has put their hands up for the
 others (DBManger, mapserver export) yet but I will try my hand at them if I
 get time.

 The SIP update must happen now or it can't happen in the future without
 breaking everything yet again, and that will do more damage to the project
 then some slight breakages in plugins while they update to 2.0.  The SIP
 update is a easy one, for the core code base and plugin authors, and I only
 have to check one thing with Martin before I will merge it into master
 (after most of the core plugins are done).

 - Nathan

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

Re: [Qgis-developer] QGIS Logo

2013-07-14 Thread Mathieu Pellerin

+1  for agreeing on a logo across the board.

If vector proposal agreed, it'd also be a good opportunity to add high
resolution icons for application shortcuts on Win / Linux / OSX. By 2013,
qgis is the only low res icon on my desktop :)
On 14 Jul 2013 19:43, Nathan Woodrow madman...@gmail.com wrote:

 Hey all,

 In order to close another blocking issue off the list I would like to
 propose that we run with the vector version of the current logo that has
 been created in http://hub.qgis.org/issues/6688.
 This logo still looks the same but being vector will look much nicer. The
 logo is currently used on Facebook, Google+, Flickr, GIS.SE, and looks
 pretty good.

 After 2.0 is out and we form a design group we can look at a more revamped
 logo.

 If everyone is happy with this logo I will go though and update all the
 old logos with the new vector version so we can close that ticket.

 - Nathan

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

2013-08-11 Thread Mathieu Pellerin

Small reminder: neither the QGIS application shortcut (on linux and windows
OSes) nor the logo used in the About QGIS window are using the above
mentioned SVG.


On Mon, Aug 12, 2013 at 4:29 AM, Nathan Woodrow madman...@gmail.com wrote:

 Hey Alex,

 We are going with the svg that is assigned to that ticket for this release.

 - Nathan



 On Sun, Aug 11, 2013 at 11:27 PM, Alexander Bruy alexander.b...@gmail.com
  wrote:

 Hi all,

 what is the final decision on this?

 On Sun, Jul 14, 2013 at 10:43:26PM +1000, Nathan Woodrow wrote:
  Hey all,
 
  In order to close another blocking issue off the list I would like to
  propose that we run with the vector version of the current logo that has
  been created in http://hub.qgis.org/issues/6688.
  This logo still looks the same but being vector will look much nicer.
 The
  logo is currently used on Facebook, Google+, Flickr, GIS.SE, and looks
  pretty good.
 
  After 2.0 is out and we form a design group we can look at a more
 revamped
  logo.
 
  If everyone is happy with this logo I will go though and update all the
 old
  logos with the new vector version so we can close that ticket.

 --
 Alexander Bruy



 ___
 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 Browser icon

2013-09-02 Thread Mathieu Pellerin

Larry,

+1 for working out some visual distinction between QGIS and QGIS Browser.
That said, the proposed canvas-below-icon might be confusing. If I was a
first time user, I'd bet on the canvas icon being the main application to
make maps, versus it being a browser-only supporting application.

What about having a couple of canvases below the QGIS icon instead of one
to suggest browsing through many items?

M


On Mon, Sep 2, 2013 at 12:49 PM, Larry Shaffer lar...@dakotacarto.comwrote:

 Hi,

 While updating the Mac icons I needed to update the one for QGIS Browser
 as well. So, I put one together [0][1].

 Please let me know if this can be used for 2.0 release. If so, I'll commit
 it.

 [0] http://drive.dakotacarto.com/qgis/qgis-browser_icon.png
 [1] http://drive.dakotacarto.com/qgis/qgis-browser_icon_dock.png

 Regards,

 Larry

 ___
 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 2.0.0 Final Tagged - call for packaging

2013-09-08 Thread Mathieu Pellerin

Tim, the visual changelog draft is excellent, excellent resource for QGIS
evangelists out there. I'd re-think the new labeling engine screenshot,
maybe a map screenshot featuring shield and drop shadow instead of the
configuration dialog (which is shown in the data-defined labeling section
anyways)?

Good job,

M


On Mon, Sep 9, 2013 at 9:38 AM, Tim Sutton li...@linfiniti.com wrote:

 Dear QGIS devs  packagers

 --- Note to casual readers ---

 Please do not pre-announce this release - give the packagers and release
 team a chance to do their thing so that people hearing about the release
 have a fair chance of finding a package, reading all our press material
 etc.

 Especially for this release, I would like to coincide the release
 announcement with the launch of our new web site which the community team
 and opengeo have been working really hard at. So please wait until we are
 ready to announce before blogging, tweeting, etc, about the new release.

 --- End note ---

 I have tagged QGIS 2.0.0 for release. The branch can be checked out
 like this (as a tracking branch)

 git clone git://github.com/qgis/Quantum-GIS.git
 git branch --track release-2_0 origin/release-2_0
 git checkout release-2_0

 Or (to check out the final tagged version made a few hours ago):

 git fetch
 git checkout final-2_0_0

 The tag is signed with my GPG key:

 user: Tim Sutton (QGIS Key) t...@linfiniti.com
 1024-bit DSA key, ID 97626237, created 2007-07-19

 Source tarballs can be obtained from here:

 http://qgis.org/downloads/qgis-2.0.0.tar.bz2
 http://qgis.org/downloads/qgis-2.0.0.tar.bz2.md5

 Packagers:

 Please hold your packages until you hear more from me so that we can
 coordinate the release announcement with the new web site announcement. I
 expect that will be at the end of this week or over the weekend coming.

 Some notes:

 - Please do not commit anything to the 2_0_0 branch except packaging
 related tweaks pending further notification from myself or Juergen.
 - If you make a package please be so kind as to update the download wiki
 page at http://www.qgis.org/wiki/Download with the details of your
 package (taking into account the hold-until-the-site-is-ready note above).
 - If you are able to make packages for unlisted platforms / distros
 please discuss your plans on this thread so that we can avoid duplication
 of effort.
 - I would like to make the release announcement next week, so it will be
 great to have as many packages as possible ready by then.
 - GIT master is open again for general commits - please seek guidance
 from Marco Hugentobler (PSC Code Manager) if you are planning any major
 code changes.
 - Juergen Fischer (incoming PSC Release Manager) will be managing the
 release process for future releases, so please follow his lead in terms of
 code freeze etc in master.

 Many thanks to all the developers, testers, bug fixers, bug reporters,
 document writers, translators and users that help to make QGIS 2.0.0 a
 reality!

 Lastly can I call on the release team (or any interested people) to help
 to put together visual changelog (link below), press announcements etc.
 ready for the release date? I will send you an email when the packages are
 ready and you can start broadcasting announcements.

 Visual Changelog Page: http://changelog.linfiniti.com/version/1/ (this is
 the site for drafting the release, the final release content will be on the
 official QGIS web site). Please contact me if you would like to contribute
 to the changelog and I will give you the needed permissions.


 Best regards


 --
 Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
 ==
 Please do not email me off-list with technical
 support questions. Using the lists will gain
 more exposure for your issues and the knowledge
 surrounding your issue will be shared with all.

 Irc: timlinux on #qgis at freenode.net
 ==

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

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

Re: [Qgis-developer] QGIS 2.0.0 Final Tagged - call for packaging

2013-09-08 Thread Mathieu Pellerin

Re labels, I meant something like this:
http://imgur.com/jUndyYK,JHgeT39#0http://imgur.com/jUndyYK,JHgeT39#0

Could also be worth showing a more radical example of layer blending, such
as:
http://imgur.com/jUndyYK,JHgeT39#1http://imgur.com/jUndyYK,JHgeT39#1

I'm not suggesting the above two images should be used, merely referring to
those as alternatives to relying on a user interface as screenshot to
showcase feature X,Y,Z

M



On Mon, Sep 9, 2013 at 11:13 AM, Mathieu Pellerin nirvn.a...@gmail.comwrote:

 Tim, the visual changelog draft is excellent, excellent resource for QGIS
 evangelists out there. I'd re-think the new labeling engine screenshot,
 maybe a map screenshot featuring shield and drop shadow instead of the
 configuration dialog (which is shown in the data-defined labeling section
 anyways)?

 Good job,

 M


 On Mon, Sep 9, 2013 at 9:38 AM, Tim Sutton li...@linfiniti.com wrote:

 Dear QGIS devs  packagers

 --- Note to casual readers ---

 Please do not pre-announce this release - give the packagers and release
 team a chance to do their thing so that people hearing about the release
 have a fair chance of finding a package, reading all our press material
 etc.

 Especially for this release, I would like to coincide the release
 announcement with the launch of our new web site which the community team
 and opengeo have been working really hard at. So please wait until we are
 ready to announce before blogging, tweeting, etc, about the new release.

 --- End note ---

 I have tagged QGIS 2.0.0 for release. The branch can be checked out
 like this (as a tracking branch)

 git clone git://github.com/qgis/Quantum-GIS.git
 git branch --track release-2_0 origin/release-2_0
 git checkout release-2_0

 Or (to check out the final tagged version made a few hours ago):

 git fetch
 git checkout final-2_0_0

 The tag is signed with my GPG key:

 user: Tim Sutton (QGIS Key) t...@linfiniti.com
 1024-bit DSA key, ID 97626237, created 2007-07-19

 Source tarballs can be obtained from here:

 http://qgis.org/downloads/qgis-2.0.0.tar.bz2
 http://qgis.org/downloads/qgis-2.0.0.tar.bz2.md5

 Packagers:

 Please hold your packages until you hear more from me so that we can
 coordinate the release announcement with the new web site announcement. I
 expect that will be at the end of this week or over the weekend coming.

 Some notes:

 - Please do not commit anything to the 2_0_0 branch except packaging
 related tweaks pending further notification from myself or Juergen.
 - If you make a package please be so kind as to update the download wiki
 page at http://www.qgis.org/wiki/Download with the details of your
 package (taking into account the hold-until-the-site-is-ready note above).
 - If you are able to make packages for unlisted platforms / distros
 please discuss your plans on this thread so that we can avoid duplication
 of effort.
 - I would like to make the release announcement next week, so it will be
 great to have as many packages as possible ready by then.
 - GIT master is open again for general commits - please seek guidance
 from Marco Hugentobler (PSC Code Manager) if you are planning any major
 code changes.
 - Juergen Fischer (incoming PSC Release Manager) will be managing the
 release process for future releases, so please follow his lead in terms of
 code freeze etc in master.

 Many thanks to all the developers, testers, bug fixers, bug reporters,
 document writers, translators and users that help to make QGIS 2.0.0 a
 reality!

 Lastly can I call on the release team (or any interested people) to help
 to put together visual changelog (link below), press announcements etc.
 ready for the release date? I will send you an email when the packages are
 ready and you can start broadcasting announcements.

 Visual Changelog Page: http://changelog.linfiniti.com/version/1/ (this
 is the site for drafting the release, the final release content will be on
 the official QGIS web site). Please contact me if you would like to
 contribute to the changelog and I will give you the needed permissions.


 Best regards


 --
 Tim Sutton - QGIS Project Steering Committee Member (Release  Manager)
 ==
 Please do not email me off-list with technical
 support questions. Using the lists will gain
 more exposure for your issues and the knowledge
 surrounding your issue will be shared with all.

 Irc: timlinux on #qgis at freenode.net
 ==

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



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

Re: [Qgis-developer] Suppress rendering of small features

2013-09-12 Thread Mathieu Pellerin

Could this be done using a rule-based expression through the creation of a
variable that returns the pixel-size area of a polygon / pixel-size length
of a line?


On Thu, Sep 12, 2013 at 3:28 PM, Matthias Kuhn matthias.k...@gmx.ch wrote:

 Hi,

 How would you define small? I guess something can already be done with
 scale based visibility, but that needs preprocessing of the data and
 assigning some kind of size class.

 On Don 12 Sep 2013 08:51:43 CEST, Andreas Neumann wrote:
  Hi,
 
  Another interesting thing would be to simplify features when you zoom
  out. Maybe simplifying would be quicker than rendering thousands of
  unnecessary vertices. Optionally this could also be outsourced to the
  database - many databases support simplification on the db level. I
  don't know if it would really speed up things. One would have to test.

 I did a preliminary analysis for this.
 I created a view on a postgis DB containing ~17000 line features with
 the geometry column simplified to 10m in the view.

 *Non Simplified*
 ./output/bin/qgis_bench --iterations 20 --width 1024 --height 768
 bench-full.qgs
 iterations: 20
 total_avg: 0.4246
 total_max: 0.657
 total_maxdev: 0.2324
 total_min: 0.407
 total_stdev: 0.0535176606364665

 *Simplified*
 ./output/bin/qgis_bench --iterations 20 --width 1024 --height 768
 bench-simplified.qgs
 iterations: 20
 total_avg: 0.09615
 total_max: 0.098
 total_maxdev: 0.001849998
 total_min: 0.095
 total_stdev: 0.000792148975887722

 0.42 / 0.09 is more than 400% performance improvement for this simple
 case.

 The results of course depend heavily on the particular setting, but I
 think this looks indeed like a road we should have a look into.

 (Setup: PostGIS 2.0.3 in a kvm virtual machine on the same physical
 machine. No styling at all took place on the layer)

 Matthias

 
  Andreas
 
 
 
  Am 12.09.2013 07:57, schrieb aperi2007:
  Not always is preferrable to suppress the small features.
  Often in our rendering we prefere to substitute a small rendering of
  kind polygon with a point rendering at lowest scales.
 
  This is possible using the Rule-Rendering
  also is possible to use the rule-rendering to define a rule that in a
  scale interval and with a dimension interval the feature is render using
  a point rendering and change in a polygon rendering when the scale grow.
 
  Andrea.
 
  On 12/09/2013 02:13, Nyall Dawson wrote:
  Hi all,
 
  I've been chatting with Nathan about adding a feature to QGIS which
  would allow suppression of rendering features smaller than a set
  threshold for vector layers. (There's already a similar function in
  the labelling engine Suppress labeling of features smaller than).
  This feature would come in handy for me for several tables which
  contain a wide range of very small - very large features, which cause
  slow rendering at small scales.
 
  I'm just checking that if I code this up it's not going to be
  duplicated effort - Nathan is under the impression that someone else
  has been talking about adding something similar. Is there currently
  any plans for a feature like this, or should I get started?
 
  Nyall
 
 
 
 
 
  ___
  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


 ___
 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] Roadmap for 2.2

2013-11-04 Thread Mathieu Pellerin

As others have pointed out, there's already a substantial amount of new
features in qgis master. Beyond what was mentioned above, there's: world
file on qgis composer export, expression based {categorized, graduated}
symbology, notable improvements in the spatialite  postegresql drivers,
improvement to plugin manager etc.

That's on top of a number of bug fixes following public adoption of qgis
2.0, which Nyall was offering to look at and backport to 2.0 branch.

Question: is there already enough to justify a qgis 2.2 Christmas release?
The master branch is quite stable at the moment, wouldn't need as much of a
cool down period as 2.0 required.

Just a thought :)

M
On 5 Nov 2013 02:29, Andreas Neumann a.neum...@carto.net wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Hi,

 Marco Hugentobler is working on DXF export and there are also label
 speed improvements in the pipeline that did not make it into 2.0

 Nyall is working on improving the print composer to behave better like
 a DTP/graphic application, including better navigation in the print
 composer view, selecting and manipulating multiple elements at once,
 etc. Nyall also included a new symbology option for gradients.

 Matthias included his work on database relations - which is already in
 master for you to test.

 Victor and Alex are continuously improving processing.

 I am sure there is much more.

 So there is already a lot of interesting work in the pipeline for QGIS 2.2

 Andreas

 Am 04.11.2013 20:01, schrieb Paolo Cavallini:
  Il 04/11/2013 19:51, Jrgen E. Fischer ha scritto:
 
  Not yet - at least as far as I know.
 
  wouldn't it a good time to do it now then? :) thanks.
  ___ Qgis-developer
  mailing list Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
 

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

 iQEcBAEBAgAGBQJSd/WDAAoJELiCsGDopvBChMYH/1XxRpOUgqlLzeQA/C7uq6lD
 MMlWF3ESTHvU6JqUumRZSMLcHGtaUw8TSqk1v6CUeTg9HVG82YrEi8y4yMzcxsPg
 HtLKlOE9wemGluH1GLc7XXUTltHpt/PApj4ZbAPaOfjpGvYMyV0aK4lftP7OhP9K
 TC/KGwgeqqGYxBeuKymgUw0To8cg+rLFn3AHmfsuLWL0GmsFIXtVHKEJ7o1C5Jaf
 +KXn7yNskZvt/uHLa5RuG59EVRDKZozlJyYtDUK2om6c2rRyR3q7FwMo2DnYTGvY
 cHMzAGPvNS0NKxyZCnFACakdBwIWu2mQSIiJa2gciMJrnI10TLpdnfOfCeq5lDg=
 =LkSv
 -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] Legend for proportionnal symbols and expression based symbols

2013-12-04 Thread Mathieu Pellerin

Now that's just gorgeous.

On Wed, Dec 4, 2013 at 7:13 PM, Nyall Dawson nyall.daw...@gmail.com wrote:

I haven't had a chance to properly plan this out, but something which
has been playing in the back of my mind is the idea of table
legends. Take a look at the legend in this map:
http://www.cartogrammar.com/images/vba/cervical_cancer.jpg
I'm thinking the user could specify the variable which is changed
along each axis, along with the min/max value for that axis and number
of rows/columns for the table. Then the classes would be generated
automatically (maybe equal ranges? equal count? user specified?) and
the symbol automatically generated for each cell in the table.

The size and spacing of each cell could be user controlled, so that
this type of legend would also work for symbol layers.

As I said, I haven't really sat down to work out exactly how this
would work yet... it's just a rough idea which I've been toying with!

Nyall

On 4 December 2013 22:34, Denis Rouzaud denis.rouz...@gmail.com wrote:
Hi régis,

Martin Dobias will make a proposal soon for a legend refactoring.
You should see with him how to let those things happen in the future in
the
new legend.

Cheers,

Denis

On 04. 12. 13 12:08, Régis Haubourg wrote:

Hi All,
we have a long lasting problem with proportionnal legends in QGIS. It
gets
more problematic with V2, as those maps are so beautiful and popular.

I'm starting some brainstorming to clarify fonctionnal specifications
what
we actually want to have legends in layers registry and composer
working.

Here are some exemples of what I would love to see in legends:
- [0] proportionnal circles or square with 1 to 5 classes
- [1] proportionnal symbols AND colors

Now that we have expressions everywhere, we probably will have to handle
legends differently than in other GIS, where legend is generated once,
when
user tune symbology. Let me explain:

- user can now define expressions for size, color, rotation, border
width...
for any sub-marker (1 to n) of a symbol.
- Moreover, we can use conditionnal expressions, and scale dependent
conditions ($scale variable).
- QGIS is also a server, we need to be able to generate legends working
on
really displayed datas.

Conclusion, It now is impossible to correctly pre-generate the legend by
analysing symbology properties.

Does this sound possible to developpers to explore some other way? We
could
read real dataset to collect informations to build a legend, and
eventually
do some statistical classification to get discrete classes from
continuous
data?

We could do that on live or on-demand update maybe.

My idea was to collect rendered object in current canvas and current
scale.
BUT.. we can face discrete data - some kind of SELECT DISTINCT can do
the
trick - , OR continuous data - we need then to do some statistical
classification to reduce the legend to 1 - 10 classes to get it
readable.
We also need some intelligence in those statistical classifications:
- round values to keep it readable
- display separate classes only if size or color distance is long
enough
so
that human eye sees some difference on screen. ie: do not display for
classes if symbol size varies from 0.5 to 0.7...
- add some options in GUI to choose number of classes, type of legend
rendering..
- keep the classification process fast (subset of data with random
sampling?)
- test all use cases, I'm mostly thinking of points symbols, but lines
and
polygons must not be forgotten.

I'm sure plenty of scientists have already been theorizing all this. Any
opinions? Could this be an idea for GSoC or other kind of training
course?

I'll be pleased to get feedback from the community.

Cheers
Régis

[0] http://kelsocartography.com/blog/?p=2224
[1] http://www.geoclip.fr/img/bicol.jpg

--
View this message in context:

http://osgeo-org.1560.x6.nabble.com/Legend-for-proportionnal-symbols-and-expression-based-symbols-tp5092635.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
___
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] Can we deactivate the Select datum transformations dialog by default?

2014-01-20 Thread Mathieu Pellerin

+1, for two reasons:
* the advances function isn't needed for many types of qgis users
* the UI would benefit from re arrangements to make it more friendly when
users run into it (ie a short paragraph above list box to explain what this
is about, like with the crs selector)
On 21 Jan 2014 06:09, Nathan Woodrow madman...@gmail.com wrote:

 +1

 - Nathan


 On Tue, Jan 21, 2014 at 9:06 AM, Alexandre Neto senhor.n...@gmail.comwrote:

 +1 to deactivate the dialog by default.

 Tho the dialog is quite usefull, I can imagine people getting frustrated
 for not understanding what is that dialog for. Those who understand can
 find it elsewhere.

 Alexandre Neto


 On Mon, Jan 20, 2014 at 10:32 PM, Giovanni Manghi 
 giovanni.man...@faunalia.pt wrote:

  I suggest to deactivate the Select datum transformations dialog by
 default.

 +1 agree
 ___
 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

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

Re: [Qgis-developer] On the fly simplication of point layers

2014-01-20 Thread Mathieu Pellerin

Also, that logic can only be applied for fully opaque point symbols. As
soon as you have a semi transparent symbol, the repetition of points over a
same map pixel does matter and needs to be preserved.
On 21 Jan 2014 07:46, A Huarte ahuart...@yahoo.es wrote:

 Ok, I will study it


 If you have time and inclination this would be great (note feature freeze
 starts in 4 days). A logical starting may be to only return one point per
 map pixel though I am not sure if you can push that kind of logic over to
 provider side very easily.

 Regards

 Tim




   --
  *De:* Tim Sutton li...@linfiniti.com
 *Para:* A Huarte ahuart...@yahoo.es
 *CC:* qgis-developer qgis-developer@lists.osgeo.org
 *Enviado:* Lunes 20 de enero de 2014 22:57
 *Asunto:* Re: [Qgis-developer] On the fly simplication of point layers

 Hi


 On Mon, Jan 20, 2014 at 11:47 PM, A Huarte ahuart...@yahoo.es wrote:

 done:
 https://github.com/qgis/QGIS/pull/1093

 This patch hides the simplification rendering tab for point layers, now
 it is not supported (internally I am not trying to simplify point layers)
 . Thanks Tim!

 About if there is a use case for point simplification, I know one, (gvSIG
  + dielmo open lidar) use it for load extreme big point layers as LiDAR LAS
 files are.

 It know the code in java and I think easy migrate to QGIS. Basically, It
 ignore points by distance in a similar style as the current simplifier
 classes.


 Sorry I see my original email was not very clear - I meant if there was a
 use case for point simplification as *currently implemented in master* - I
 fully agree that filtering proximal points would be a good performance
 booster, as would providing a point clustering capability.



 If you think good for QGIS I think but I can imlement it


 That would be great! Thanks for your pull request.

 Regards

 Tim


 .
 Alvaro

   --
  *De:* Tim Sutton li...@linfiniti.com
 *Para:* qgis-developer qgis-developer@lists.osgeo.org
 *Enviado:* Lunes 20 de enero de 2014 21:29
 *Asunto:* [Qgis-developer] On the fly simplication of point layers

 Ok I guess you can see where I am going to go with this email :-) Is there
 any point to allowing users to simplify point layers? Alvaro, can your
 remove the point rendering tab in layer properties (and I guess check
 internally that you are not trying to simplify point layers)? Or is there a
 use case for point simplification that I am not getting?

 Regards

 Tim

 --
 Tim Sutton - 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: timlinux on #qgis at freenode.net
 ==

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





 --
 Tim Sutton - 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: timlinux on #qgis at freenode.net
 ==





 --
 Tim Sutton - 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: timlinux on #qgis at freenode.net
 ==



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

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

Re: [Qgis-developer] On the fly simplication of point layers

2014-01-22 Thread Mathieu Pellerin

Tim, I think that type of simplification should not be activated by
default. The risks of users just not knowing what's going on is high.

The discarding should be activated via check box when desired.
On 21 Jan 2014 12:01, Tim Sutton li...@linfiniti.com wrote:

 Hi

 Sent from my mobile
 On 21 Jan 2014 3:10 AM, Mathieu Pellerin nirvn.a...@gmail.com wrote:
 
  Also, that logic can only be applied for fully opaque point symbols. As
 soon as you have a semi transparent symbol, the repetition of points over a
 same map pixel does matter and needs to be preserved.

 Agreed but in that case surely you would just disable simplification?

 Regards

 Tim
 
  On 21 Jan 2014 07:46, A Huarte ahuart...@yahoo.es wrote:
 
  Ok, I will study it
 
 
  If you have time and inclination this would be great (note feature
 freeze starts in 4 days). A logical starting may be to only return one
 point per map pixel though I am not sure if you can push that kind of logic
 over to provider side very easily.
 
  Regards
 
  Tim
 
 
 
 
  
  De: Tim Sutton li...@linfiniti.com
  Para: A Huarte ahuart...@yahoo.es
  CC: qgis-developer qgis-developer@lists.osgeo.org
  Enviado: Lunes 20 de enero de 2014 22:57
  Asunto: Re: [Qgis-developer] On the fly simplication of point layers
 
  Hi
 
 
  On Mon, Jan 20, 2014 at 11:47 PM, A Huarte ahuart...@yahoo.es
 wrote:
 
  done:
  https://github.com/qgis/QGIS/pull/1093
 
  This patch hides the simplification rendering tab for point layers,
 now it is not supported (internally I am not trying to simplify point
 layers). Thanks Tim!
 
  About if there is a use case for point simplification, I know one,
 (gvSIG  + dielmo open lidar) use it for load extreme big point layers as
 LiDAR LAS files are.
 
  It know the code in java and I think easy migrate to QGIS.
 Basically, It ignore points by distance in a similar style as the current
 simplifier classes.
 
 
  Sorry I see my original email was not very clear - I meant if there
 was a use case for point simplification as *currently implemented in
 master* - I fully agree that filtering proximal points would be a good
 performance booster, as would providing a point clustering capability.
 
 
 
  If you think good for QGIS I think but I can imlement it
 
 
  That would be great! Thanks for your pull request.
 
  Regards
 
  Tim
 
 
  .
  Alvaro
 
  
  De: Tim Sutton li...@linfiniti.com
  Para: qgis-developer qgis-developer@lists.osgeo.org
  Enviado: Lunes 20 de enero de 2014 21:29
  Asunto: [Qgis-developer] On the fly simplication of point layers
 
  Ok I guess you can see where I am going to go with this email :-)
 Is there any point to allowing users to simplify point layers? Alvaro, can
 your remove the point rendering tab in layer properties (and I guess check
 internally that you are not trying to simplify point layers)? Or is there a
 use case for point simplification that I am not getting?
 
  Regards
 
  Tim
 
  --
  Tim Sutton - 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: timlinux on #qgis at freenode.net
  ==
 
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
 
 
 
 
 
  --
  Tim Sutton - 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: timlinux on #qgis at freenode.net
  ==
 
 
 
 
 
  --
  Tim Sutton - 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: timlinux on #qgis at freenode.net
  ==
 
 
 
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer

___
Qgis-developer 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?

2014-02-23 Thread Mathieu Pellerin

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?

Math



On Sun, Feb 23, 2014 at 5:06 PM, Jürgen E. j...@norbit.de wrote:

 Hi Larry,

 On Sat, 22. Feb 2014 at 14:33:11 -0700, Larry Shaffer wrote:
  How about for a set period of time, only commits that devs think can
 readily
  be ported to the 2.2.0 branch are 'allowed' on master? With any code
 changes,
  which would make porting changes/fixes over to the 2.2.0 branch
 difficult,
  submitted via pull requests. Maybe for two weeks?

  I think if code is committed to core that steamrolls over the means of
  providing a reasonably timed bug-fix update, it becomes that much harder
 to
  do so. I also think much user frustration may stem from that vicious
 cycle,
  and we have an opportunity to fix that *right now*.

  Don't get me wrong. I like the new release schedule. Just looking for
 ways
  to make it as beneficial for users as it is for devs/packagers.

 Our agreement was to not do point releases.  And not because stable
 release are
 a bad thing, but just acknowleding the fact that we don't have the
 resources to
 do everything.  The more we wasted on releases, the more we loose on
 feature
 work.

 Maybe we should just emphasize more that the four weeks before the release
 are
 not a pure developer thing.  If users want good releases, they should
 verify
 that master is ok before it get released - and not start testing right
 after
 the release.  Of course all testing is welcome, but testing after the
 release
 only contributes to the next release.

 So blocking development for another two weeks to backport stuff to a branch
 that - unless in the undesired event that something severe wasn't spotted
 in
 the four weeks before the release - won't ever be released, doesn't make
 sense
 to me.

 The next release is 117[1] days away.  That might sound far away, but I bet
 it's sooner than we think.


 Jürgen

 [1]
 http://www.timeanddate.com/countdown/generic?iso=20140620T12p0=1440msg=QGIS+2.4+Release

 --
 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] Multi-threading rendering merged to master

2014-02-23 Thread Mathieu Pellerin

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

Math



On Sun, Feb 23, 2014 at 10:02 PM, Martin Dobias wonder...@gmail.com wrote:

 Hi all

 this is a short note about the fact that multi-threaded rendering has
 now landed in master, so from now on, you should be able to enojy
 better experience when browsing your map (especially the fact that you
 can keep using QGIS as usual even if rendering continues in the
 background).

 By default the parallel rendering is not enabled (yet) - to enable it
 please go to options  Rendering and check the appropriate option.
 There is another new option that lets you setup how often the map
 canvas should be refreshed while being rendered.

 If you find anything that used to work for you and now it does not, do
 not hesitate to let me know. I hope the merge has not ruined your
 Sunday :-)

 Another, more technically oriented mail will follow later.

 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

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

2014-02-23 Thread Mathieu Pellerin

Just to be clear, I don't think QGIS can handle more than one pre release.
The list of terminologies was just there as a pick one name you like :)
On 24 Feb 2014 13:22, Denis Rouzaud denis.rouz...@gmail.com wrote:


 On 24. 02. 14 03:17, Mathieu Pellerin wrote:

 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

 +1
 I always thought there is not enough publicity made to encourage testing
 the master build.
 Advertising for beta and release candidate sounds like a good  idea.

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

2014-02-24 Thread 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. j...@norbit.de 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?

2014-02-24 Thread 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 nirvn.a...@gmail.comwrote:

 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. j...@norbit.de 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] Multi-threading rendering merged to master

2014-02-26 Thread Mathieu Pellerin

Happy to report that following Martin's last commit (
https://github.com/qgis/QGIS/commit/daf1e0b6881cdb77df6f6a9dc988ad92e0f9019d),
I cannot see any issues with vector/raster layer rendering, as well as
labelling. All renders like 2.2, except the user experience is 10 times
better :)

Larry, I'm pretty sure your labeling tests will mostly turn green now.

Math


On Wed, Feb 26, 2014 at 3:59 PM, Martin Dobias wonder...@gmail.com wrote:

 Hi Larry

 On Tue, Feb 25, 2014 at 5:55 AM, Larry Shaffer lar...@dakotacarto.com
 wrote:
  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?

 I am sorry about that, but I am sure we can sort it out in the next
 few days. Mathieu has done a great job testing post-MTR rendering and
 reporting regressions, just today he has added #9661 and #9662 - maybe
 these are the issues causing the tests fail.

 The main change is that doing size/width calculations should get
 simpler now, because the scale factor and raster scale factor are
 now always equal to one (so we do not need to use them anymore) and
 there is just one true DPI (instead of two DPIs - painter DPI and
 scene DPI). I know that labeling had to do some voodoo to get the
 rendering right, I remember updating that code, but maybe I missed
 some pieces

 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

Re: [Qgis-developer] Renaming Save Style - Save Properties (Vector layer dialog)

2014-03-02 Thread Mathieu Pellerin

I like where it's going. Re check boxes, I'd love to see intelligent
switch buttons beyond check all uncheck all. A check styling only
(symbology + label) button, a check non - style only button would be
really useful. Like some media players do to check audio only vs video 
audio.
On 2 Mar 2014 19:11, Nathan Woodrow madman...@gmail.com wrote:

 The only thing I am missing in this mockup is the ability to
 check/uncheck all checkboxes. It is kind of boring having to uncheck a
 lot of checkboxes if just want the styling or labeling.


 Just an implementation detail.  That is something I would add.

 - Nathan


 On Sun, Mar 2, 2014 at 10:06 PM, Andreas Neumann a.neum...@carto.netwrote:

 Hi Nathan,

 Yes - I like the idea of a separate tab for import/export of layer
 properties.

 I guess the Save style would then be renamed to Save Property?

 The only thing I am missing in this mockup is the ability to
 check/uncheck all checkboxes. It is kind of boring having to uncheck a
 lot of checkboxes if just want the styling or labeling.

 Cool - looking forward to these improvements!

 Andreas

 Am 02.03.2014 11:58, schrieb Nathan Woodrow:
  Andreas,
 
  Something like this is what I was thinking. (With a better UI of course)
 
  http://i.imgur.com/2XbNqlp.png
 
  - Nathan
 
 
  On Sun, Mar 2, 2014 at 9:45 PM, Nathan Woodrow madman...@gmail.com
 wrote:
 
  Hey Andreas,
 
  I'm not 100% yet.I'm not sure what it is but I really hate the Load
  Style../Save Style buttons at the bottom of the dialog.  I was
 thinking a
  new page in the properties dialog would be better with the title
  Import/Export.  For me this would mean not having a open another
 dialog,
  which I really don't like the idea of, and we have more room to play
 with.
 
  One of my goals is to be able to export just the style part in order to
  expand the Style Manager to handle prebuilt styles.  I was planning on
  adding some Save and Load buttons on the style tab that would just
 load the
  style information from the .qml file.
 
  - Nathan
 
 
  On Sun, Mar 2, 2014 at 9:39 PM, Andreas Neumann a.neum...@carto.net
 wrote:
 
  Hi,
 
  How do you envisage to implement this?
 
  Personally I would think it would be useful to have an export dialogue
  where the user can choose (with checkboxes or a list widget) which
  properties he wants to export:
 
  * General properties (like the filtering, encoding, layer alias, scale
  dependent visibility, CRS )
  * Style properties
  * Labeling properties
  * Field properties (incl. display field properties)
  * Actions
  * Joins and Relations (see the new relations manager that Matthias
  recently introduced)
  * Diagrams
  * Metadata
 
  As a shortcut one should be able to export all at once without having
 to
  press all checkboxes.
 
  ---
 
  When importing, the importer of the layer properties should list what
 is
  available in the .qml file and offer just the available bits of the
  layer properties. Again - a short cut to import all layer properties
  would be useful.
 
  Thanks,
  Andreas
 
  Am 01.03.2014 15:42, schrieb Anita Graser:
  Hi Michael,
 
  Am 01.03.2014, 15:55 Uhr, schrieb kimaidou kimai...@gmail.com:
  I also think it could be great to have a button
  save style. But the latest should not lie in the bottom of the
 layer
  dialog, but instead in the Style tab only, to avoid confusion.
 
  +1
 
  By the way, having a save style button could also lead to the
  ability of
  saving/restoring more than one style for each layer (via a combo box
  for
  the restore button), which could be great too.
 
  This could work quite well. Do you think the Save style button
 could
  be a simple button with the save icon or do we need a labeled button?
 
  Best wishes,
  Anita
 
 
 
 
 
  Regards,
  Michael
 
 
  2014-03-01 15:01 GMT+01:00 Régis Haubourg 
  regis.haubo...@eau-adour-garonne.fr:
 
  Hi Nathan I agree with your proposal of renaming style by
 properties.
  Users don't understand they also inherit labels, metadata and so on
  when
  loading a style.
 
  By the way, I think some improvements can be made for reloading
 style
  use
  case. Problem occurs (maybe occured, didn't check recently) when
 user
  want
  to transfer graduated or single value style classes from one
 column to
  another. Copying style from another table often leads to that
  situation,
  where field or expression is not in target table.   I know this
 can be
  tricky since graduated classes are in autosync with numeric data.
  Another issue occurs when geometry type is not the same. Maybe we
  could
  save
  at least color when reapplying style (from point to polygon for
  instance).
  This was my small thread highjack ;-)
  Cheers,
 
  Régis
 
 
 
 
 
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer
 
 
 
 



 ___
 Qgis-developer mailing list

Re: [Qgis-developer] Using PostGIS on a slow connection

2014-03-03 Thread Mathieu Pellerin

Martin, maybe render caching should be turned/forced on by default on qgis
master builds right now so there can be a higher of ppl using it and
reporting possible regressions? If it's now smooth and problem-free
following mtr merge, it can be left on by default for final 2.4 release.
On 3 Mar 2014 19:43, Martin Dobias wonder...@gmail.com wrote:

 Hi Paolo

 On Mon, Mar 3, 2014 at 7:18 PM, Paolo Cavallini cavall...@faunalia.it
 wrote:
  Il 27/02/2014 03:17, Martin Dobias ha scritto:
 
  Paolo: make sure you have render caching turned on. Deactivating (and
  activating again) a layer should be immediate. Of course, if you pan
  the map or zoom in/out, everything will be re-rendered.
 
  Hi Martin,
  thanks for this. It helps, but my question remains: why should we reload
  data, just to *disable* a layer from the legend?

 In order to remove a layer from a map, you simply need to redraw the
 whole map _without_ that layer. The render caching helps by recording
 image of each layer separately, so removing a layer from legend
 requires just combining the rendered images together without the
 removed one - without having to redraw also other layers. Maybe we
 should just make render caching default.

 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

Re: [Qgis-developer] Deactivating multi-threaded rendering - Was: QGIS' TimeManager plugin in action

2014-04-05 Thread Mathieu Pellerin

Seems code will have to move away from a timer and instead trigger
rendering on determined timeout which will trigger another timeout upon
renderJobFinish if timemanager is playing / exporting.

MRT has greatly improved interaction with timemanager time slider btw.

M
On 6 Apr 2014 05:30, Anita Graser anitagra...@gmx.at wrote:

 Am 06.04.2014, 00:08 Uhr, schrieb Nathan Woodrow madman...@gmail.com:

  Yeah there is a renderComplete() or renderJobFinsihed.  I think you need
 to
 use renderJobFinished.


 Thanks!
 The process is currently controlled by a timer object. Do you know what's
 best practice to combine a time + waiting for a signal?

 Best wishes,
 Anita






 - Nathan


 On Sun, Apr 6, 2014 at 8:05 AM, Anita Graser anitagra...@gmx.at wrote:

  Hi Nathan,

 Am 05.04.2014, 22:54 Uhr, schrieb Nathan Woodrow madman...@gmail.com:

  What iisues do you have with your time manager and MTR?



 The export image series does not work properly anymore: it sometimes
 saves
 before the map is done rendering.

 Maybe there's some signal I could use?

 Best wishes,
 Anita




  t



  Nathan
 On 06/04/2014 1:11 am, Anita Graser anitagra...@gmx.at wrote:

  Hi,


 Are there plans to let plugins (which are not working well with
 multi-threaded rendering) deactivate the feature when needed?

 Thanks and best wishes,

 Anita


 Am 04.04.2014, 05:44 Uhr, schrieb Mathieu Pellerin 
 nirvn.a...@gmail.com
 :

  Hmm, is there no way to deactivate MTR? As far as I understand, while
 we

 can de-activate multi-core rendering, the general multi-threaded
 rendering
 can't be turned off.


 On Thu, Apr 3, 2014 at 7:32 PM, Anita Graser 
 anita.graser...@gmail.com
 
 wrote:

  Hi Mathieu,


 I'm aware of some issues caused by multi-threaded rendering. If
 deactivated, TimeManager should work as always. I currently don't
 have
 time to look into adjusting it to the multi-threaded rendering.

 Best wishes,
 Anita


 On Thu, Apr 3, 2014 at 2:02 AM, Mathieu Pellerin 
 nirvn.a...@gmail.com
 
 wrote:
  Any progress upgrading timemanager to be qgis 2.3 compatible?
 
  On 2 Apr 2014 23:34, Anita Graser anita.graser...@gmail.com
 wrote:
 
  Hi Mathieu,
 
  Thanks for sharing! That's a really well done video on a difficult
 topic.
  I've added it to the Time Manager Youtube playlist as well.
 
  Best wishes,
  Anita
 
 
 
 
  Am 01.04.2014, 08:41 Uhr, schrieb Mathieu Pellerin 
 nirvn.a...@gmail.com:
 
  Greetings Anita,
 
  I've just finished a spacial project that relied on your
 TimeManager
  plugin
  to produce a time-lapse of recorded land conflicts in Cambodia
 over
 13
  years: http://licadho-cambodia.org/video.php?perm=46
 
  Sharing as I think you might appreciate seeing the great fruits
 your
 tool
  can produce.
 
  Cheers,
 
  Math
 
 
 
  --
  anitagraser.com



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



 --
 anitagraser.com



 --
 anitagraser.com

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

Re: [Qgis-developer] How to get renderComplete painter reference

2014-04-06 Thread Mathieu Pellerin

Anita, just saw you commited a fix. Thanks!

May I suggest a small improvement? You should calculate the time it took,
in ms, to render canvas and deduce that ms value from the
animationFrameLength ms value in your singleShot call:

QTimer.singleShot(self.animationFrameLength,self.playAnimation)

Currently if you have a 1000ms frame length and canvas rendering takes
500ms, each frame will last 1500ms. Deducing the 500ms canvas rendering
time from frame length will fix this.  If rendering ms  frame length ms,
that'd allow you to skip singleShot and render next frame immediately.

Cheers and thanks again.

Math
On 6 Apr 2014 23:08, Anita Graser anitagra...@gmx.at wrote:

 Hi,

 I need the painter from the renderComplete signal? Could you help me with
 the correct syntax?
 I have:

self.iface.mapCanvas().renderComplete.connect(self.
 waitAfterRenderComplete)

 and

def waitAfterRenderComplete(self, painter):

 but waitAfterRenderComplete does not receive a painter.

 Thanks and best wishes,
 Anita


 --
 anitagraser.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] Adding plugins to core?

2014-04-07 Thread Mathieu Pellerin

Also, when it comes to OSM, IMO proper TMS support should be what is
(eventually) offered as implemented feature to users. That'd allow for OSM
basemaps to also export properly in qgis composer. OpenLayer' layers not
exporting well in qgis composer is a pretty big limitation.

Maybe a simple UI to wrap around GDAL's internal TMS support?

M


On Mon, Apr 7, 2014 at 5:05 PM, Nyall Dawson nyall.daw...@gmail.com wrote:

 On 7 April 2014 18:15, Vincent Picavet vincent...@oslandia.com wrote:
 
  A good solution though would be to remove google layers and only use OSM
 and
  mapbox layers, which begin to be on par in terms of quality.

 I'm pretty sure this is against MapBox's terms of service too, unless
 users were made to sign up for a MapBox account and had to add their
 individual API key to QGIS to unlock MapBox layers:
 You must have a Mapbox account to use Mapbox. You are required to
 register for an account before using the Service. Each request to the
 API must include your account's unique API identifier. Unauthorized
 use of any API identifier is prohibited. [1]

  Or let the user a
  deliberate way to add google layers (indicating a URL or something like
 this),
  warning him about the licence.

 Hmm... while this may be a workable solution to the licensing issue,
 wouldn't it be a step back in functionality anyway? We'd be trading
 having a good, working off-the-shelf third-party plugin for a crippled
 core version which takes user intervention to unlock the same
 features.

 I'm totally for adding essential plugins to core (or merging the
 functionality with reimplemented c++ versions), but I honestly don't
 know if it's workable to do this for the OpenLayers plugin.

 Nyall

 [1] https://www.mapbox.com/tos/
 ___
 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] new plugin Load TMS Layer

2014-04-07 Thread Mathieu Pellerin

Nice, few comments (based on my previous uses of the GDAL TMS mini-driver):
- your plugin should make sure the loaded layer is assigned the proper
projection (mostly pseudo-mercator); failing to do so will leave must users
unable to understand why the TMS rendering fails
- that would also switch OTF reprojection on when needed
- consider adding TMS of the Global Forest Change (see
http://www.earthenginepartners.appspot.com/science-2013-global-forest for
data source, and
https://www.flickr.com/photos/60284107@N00/11096344994/in/pool-qgis-screenshotsfor
in-QGIS example)

The GDAL TMS driver is in many ways a superior solution to OpenLayers; it
works perfectly fine with the multi-thread rendering, can be exported via
qgis composer, caches the tiles, etc.

Math



On Tue, Apr 8, 2014 at 4:45 AM, Etienne Tourigny etourigny@gmail.comwrote:

 I have put together a simple plugin to load a number of TMS layers using
 the GDAL TMS mini-driver [1]. I see it as a simple alternative to the more
 complete OpenLayers plugin.

 Code is at github for now [2]. Any suggestions are welcome (including
 plugin name). Also if you have any other working examples please let me
 know.

 Supported layers are OSM, Google, and other examples given in [1] (except
 those that don't work).

 Tested with QGIS 2.2 and master. Rendering of labels is not the best but
 it seems better with master.

 [1] http://www.gdal.org/frmt_wms.html
 [2] https://github.com/etiennesky/loadtmslayer


 cheers
 Etienne

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

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

Re: [Qgis-developer] [Qgis-user] [ANNOUNCE] 2.3 feature freeze begun

2014-05-24 Thread Mathieu Pellerin

The next weekly build could be spinned as a technical preview build and
advertised on the homepage / blog / social media. No additional efforts
required on the build front, just a bit of public PR.

Math
On 24 May 2014 16:16, Anita Graser anitagra...@gmx.at wrote:

 How about adding the call for testers to the front page carousel?

 I think I also remember a discussion about a news bar at the top of
 the front page (right under the menu) where we could add important
 temporary information such as a call for testers.

 Best wishes,
 Anita

 On Sat, May 24, 2014 at 9:52 AM, Lene Fischer l...@ign.ku.dk wrote:
  Hi Richard,
 
  I would suggest to use the Get involved- page
  http://qgis.org/en/site/getinvolved/index.html
 
  Eg. : We need testpersons for the next version -  Install the latest
  version - new every week
 
  Report bug at  mailinglist/Bugreport and then an example in how to
  report a bug.
 
 
 
 
 
  Regards
 
  Lene Fischer
 
 
 
  -
 
  Hi Michael/Lene,
 
 
 
  if one of you writes down a text file with the information, instructions
 and
  links in it and sent it to me, that would be great.
 
  I will then create a page in the website for it.
 
 
 
  Any idea where a suitable place is?
 
 
 
  Regards,
 
 
 
  Richard Duivenvoorde
 
 
 
 
 
 
 
  ___
  Qgis-user mailing list
  qgis-u...@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-user
 ___
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/mailman/listinfo/qgis-developer

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

Re: [Qgis-developer] Question on inverted polygon renderer

2014-06-17 Thread Mathieu Pellerin

Here's a quick example of what the combination of inverted polygon and
shapeburst fill can do: http://i.imgur.com/7n6rxJx.jpg

Since shapeburst fill can use map-based units, the outer glows-like
effect of polygons can be spatially relevant, i.e. in the above map, the
glow could represent a specific distance, 2km, within which a growing
impact on local population is to be expected.

Math


On Tue, Jun 17, 2014 at 4:15 AM, Nyall Dawson nyall.daw...@gmail.com
wrote:


 On 17/06/2014 6:44 am, Régis Haubourg 
 regis.haubo...@eau-adour-garonne.fr wrote:
 
  inverted style + shapeburst give crazy cool rendering!

 A quick tip if you're using shapeburst with inverted polygons - you must
 have the shade to a set distance option selected, and set a relatively
 small distance. Otherwise you'll see shading from the canvas edges (refs
 #10570, #9757).

 Mathieu Pellerin also has some nice examples of inverted shapeburst fills
 used to shade the exterior of polygons in a thematic map - i'm not sure if
 he's posted them on the flickr group yet.

 Nyall

 ___
 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] Four month cycle too fast

2014-06-19 Thread Mathieu Pellerin

I just want to clarify one thing about this discussion: we are not speaking
about delaying the 2.4 release, which users are expecting in the next 48
hours, right?

The current state of QGIS master could probably be better, but it's not
worse than 2.2 (of course, that's a perception based on my workflows). So,
please :), whether the release cycle needs to to be adjusted, or not, it
shouldn't be decided and change within 48 hours of a publicly known release
date. As much as bugs are a big issue for end users, being consistent with
the user base is also pretty important.

Math






On Thu, Jun 19, 2014 at 1:34 PM, Andreas Neumann a.neum...@carto.net
wrote:

 Hi,

 At the Swiss QGIS user meeting yesterday there were some discussions
 whether people can cope with the 4 month release schedule and there were
 a number of users who said that this way too fast for them. By the time
 they could properly test a release, the next release is already there.

 Bigger organizations (government organizations and bigger companies)
 have to test a release, package it with IT, test again. They often can't
 install QGIS themselves (don't have installation privileges) but have to
 ask IT to do it for them. This is a time-consuming process.

 I would propose to try a six month release cycle with two months feature
 freeze for testing (see also my previous mail about a request for more
 time for testing/bug fixing). Even a yearly release cycle would be fine,
 if there could be a bug-fix release.

 PostgreSQL has a yearly release cycle and it works really well I think -
 both for them as a project and for us as customers.

 Andreas



 ___
 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] Announcing the release of QGIS 2.4 'Chugiak'

2014-06-27 Thread Mathieu Pellerin

Congratulations to all involved, once again QGIS has leaped forward with a
bunch of new features.

That said, the test the release candidate on qgis.org should be replaced
by enjoy the new version :)
On 28 Jun 2014 07:57, Jürgen E. j...@norbit.de 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.4 'Chugiak'.

 The new release contains a lot of new features, tweaks and enhancements.
  The
 most noticible improvement is probably the long awaited multithreaded
 rendering, that lets QGIS leave a much more responsive impression.

 This is second 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.   This time the testing phase was
 especially
 fruitful and was therefore extended by a week. Thanks to all the tester for
 their time and good reports.

 The source code and binaries for Windows, Debian, Fedora and Ubuntu are
 already
 available via the large download link on our home page: http://qgis.org.
  More
 packages will follow as soon as the package maintainers finish their work.
 Please revisit the page if your platform is not available yet.


 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:
 G.A.I.A. mbH (http://www.gaia-mbh.de/)
 State of Vorarlberg (http://www.vorarlberg.at)

 Bronze Sponsors:
 ArguSoft GmbH  Co KG (http://argusoft.de)
 Dr.-Ing Claas Leiner, http://www.eschenlaub.de
 Molitec (http://www.molitec.it/)
 OPENRUNNER, http://www.openrunner.com/

 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/2.4.0/
 *


 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

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

Re: [Qgis-developer] No symbol renderer... thoughts?

2014-06-30 Thread Mathieu Pellerin

I'd vote for the last option as it'd be compatible with rule based
symbology, which could be useful when coupled with the [x] show layer count
(simple eg creating a ELSE rule with a no-symbol layer to keep track of nb
of features not rendered.).

Math
On 30 Jun 2014 19:38, Nyall Dawson nyall.daw...@gmail.com wrote:

 Hi all,

 I find I'm often adding layers to a map solely for labelling, and
 having to set the symbology for these layers to a 100% transparent
 symbol so that the features themselves aren't shown.

 This seems rather hacky and inefficient, since QGIS is still rendering
 these feature, they just aren't being shown. Consequently, I'd like to
 add a better method for having layers with no visible features.

 As far as I can see, there's three possible options for this:
 - Add a no symbols renderer.
 - Allow the first symbol layer to be removed, so that a symbol can
 have no layers
 - Add no fill/no line/no marker symbol layers

 What would be the preferred solution, from a design and UX view? I'm
 leaning toward the no symbols renderer option myself, but thought
 I'd seek feedback before digging into this.

 Nyall
 ___
 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] No symbol renderer... thoughts?

2014-06-30 Thread Mathieu Pellerin

Ahh, one learns everyday. When checked, are the labels still drawn?
On 1 Jul 2014 06:36, Nathan Woodrow madman...@gmail.com wrote:

 I'd vote for the last option as it'd be compatible with rule based
 symbology, which could be useful when coupled with the [x] show layer count
 (simple eg creating a ELSE rule with a no-symbol layer to keep track of nb
 of features not rendered.).


 You can already have no symbol for a rule.  Just untick the Symbol
 checkbox in the rule properties.

 - Nathan


 On Tue, Jul 1, 2014 at 12:32 AM, Mathieu Pellerin nirvn.a...@gmail.com
 wrote:

 I'd vote for the last option as it'd be compatible with rule based
 symbology, which could be useful when coupled with the [x] show layer count
 (simple eg creating a ELSE rule with a no-symbol layer to keep track of nb
 of features not rendered.).

 Math
 On 30 Jun 2014 19:38, Nyall Dawson nyall.daw...@gmail.com wrote:

 Hi all,

 I find I'm often adding layers to a map solely for labelling, and
 having to set the symbology for these layers to a 100% transparent
 symbol so that the features themselves aren't shown.

 This seems rather hacky and inefficient, since QGIS is still rendering
 these feature, they just aren't being shown. Consequently, I'd like to
 add a better method for having layers with no visible features.

 As far as I can see, there's three possible options for this:
 - Add a no symbols renderer.
 - Allow the first symbol layer to be removed, so that a symbol can
 have no layers
 - Add no fill/no line/no marker symbol layers

 What would be the preferred solution, from a design and UX view? I'm
 leaning toward the no symbols renderer option myself, but thought
 I'd seek feedback before digging into this.

 Nyall
 ___
 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] Do we need a single select map tool?

2014-07-01 Thread Mathieu Pellerin

+1
On 1 Jul 2014 18:55, Nathan Woodrow madman...@gmail.com wrote:

 Hey,

 I would like to propose that we remove the single select map tool.

 Main reason to remove is its function is redundant as the rectangle select
 does a single point select if you don't drag i.e single click.  I live in
 rectangle select mode 99% of the time and never have any issues.

 As the rectangle select can already do both actions I don't really see the
 need to keep both tools when one would suffice.

 Thoughts?

 - Nathan

 ___
 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] Do we need a single select map tool?

2014-07-01 Thread Mathieu Pellerin

So maybe we could change the default selection tool to rectangle? One of
the first thing I personally always do when using a fresh qgis (with
default settings) is to change selection tool to rectangle for the reason
Nathan raised this thread.
On 1 Jul 2014 19:38, Nyall Dawson nyall.daw...@gmail.com wrote:


 On 01/07/2014 9:55 pm, Nathan Woodrow madman...@gmail.com wrote:
 
  Hey,
 
  I would like to propose that we remove the single select map tool.
 
  Main reason to remove is its function is redundant as the rectangle
 select does a single point select if you don't drag i.e single click.  I
 live in rectangle select mode 99% of the time and never have any issues.
 
  As the rectangle select can already do both actions I don't really see
 the need to keep both tools when one would suffice.

 -1 from me. No scientific reason why, but it would just seem wrong to me
 to always use the rectangular selection tool.

 Nyall

 ___
 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] Proposal: move the Remove layer(s) button

2014-09-05 Thread Mathieu Pellerin

Greetings,

I'd like to circulate a UX proposal and see how people react.

For a very long time, QGIS' Layers toolbar has featured a Remove layer(s)
button. I have seen two issues with the button:
- Its placement becomes really odd when plugins add button(s) to the Layers
toolbar (for e.g. the New Memory Layer plugin as pictured here [
http://imgur.com/CEcIC3K,QvUzrti ])
- It can only remove vector/raster layers, won't remove groups

With the recent improvements done by Martin Dobias on the legend, and in
particular with his addition of a layer panel embedded toolbar, I propose
that:
- The Remove layer(s) button be moved to the layer panel embedded toolbar
[ http://imgur.com/CEcIC3K,QvUzrti#1 ]
- The button functionally is improved so it can also deal with the removal
of group(s)

Alternatively, we could get rid of the button altogether since layers and
groups can be removed via right click or keyboard shortcut, but I suspect
the touch screen based users might object.

Any objection to moving the button to the new layers toolbar?

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

Re: [Qgis-developer] Proposal: move the Remove layer(s) button

2014-09-06 Thread Mathieu Pellerin

I don't think you should comparing adding group/dataset against deleting a
group/dataset legend layer. The latter is already unified via either a
single keyboard shortcut and a single mouse right-click - remove action.
On 6 Sep 2014 13:04, aperi2007 aperi2...@gmail.com wrote:

  Hi,
 I guess in a GIS oriented product
 Is necessary to avoid to mix the interface characteristics (the group is
 an interface object) and the data characteristics (the shapefile is not an
 interface object).

 I guess more beter if add/remove dataset is separated phisically from
 add/remove a group.

 The dataset is a phicical think. The shapefile is using separately from
 the qgis project.
 The group is not separately from qgis project.

 I guess is good question to have a remove group but avoiding to have a
 only button ADD Everything or an only button Remove everything

 Also I guess is important to help to understand when we are on dataset
 (physical) and when we are on interface (logical).

 Regards,

 A.

 Il 06/09/2014 07:10, Mathieu Pellerin ha scritto:

 Greetings,

 I'd like to circulate a UX proposal and see how people react.

  For a very long time, QGIS' Layers toolbar has featured a Remove
 layer(s) button. I have seen two issues with the button:
  - Its placement becomes really odd when plugins add button(s) to the
 Layers toolbar (for e.g. the New Memory Layer plugin as pictured here [
 http://imgur.com/CEcIC3K,QvUzrti ])
  - It can only remove vector/raster layers, won't remove groups

  With the recent improvements done by Martin Dobias on the legend, and in
 particular with his addition of a layer panel embedded toolbar, I propose
 that:
  - The Remove layer(s) button be moved to the layer panel embedded
 toolbar [ http://imgur.com/CEcIC3K,QvUzrti#1 ]
  - The button functionally is improved so it can also deal with the
 removal of group(s)

  Alternatively, we could get rid of the button altogether since layers
 and groups can be removed via right click or keyboard shortcut, but I
 suspect the touch screen based users might object.

  Any objection to moving the button to the new layers toolbar?

  Math


 ___
 Qgis-developer mailing 
 listQgis-developer@lists.osgeo.orghttp://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] Proposal: move the Remove layer(s) button

2014-09-06 Thread Mathieu Pellerin

* note: there is no keyboard shortcut to delete a group, doh. :)




On Sat, Sep 6, 2014 at 1:12 PM, Mathieu Pellerin nirvn.a...@gmail.com
wrote:

 I don't think you should comparing adding group/dataset against deleting a
 group/dataset legend layer. The latter is already unified via either a
 single keyboard shortcut and a single mouse right-click - remove action.
 On 6 Sep 2014 13:04, aperi2007 aperi2...@gmail.com wrote:

  Hi,
 I guess in a GIS oriented product
 Is necessary to avoid to mix the interface characteristics (the group is
 an interface object) and the data characteristics (the shapefile is not an
 interface object).

 I guess more beter if add/remove dataset is separated phisically from
 add/remove a group.

 The dataset is a phicical think. The shapefile is using separately from
 the qgis project.
 The group is not separately from qgis project.

 I guess is good question to have a remove group but avoiding to have a
 only button ADD Everything or an only button Remove everything

 Also I guess is important to help to understand when we are on dataset
 (physical) and when we are on interface (logical).

 Regards,

 A.

 Il 06/09/2014 07:10, Mathieu Pellerin ha scritto:

 Greetings,

 I'd like to circulate a UX proposal and see how people react.

  For a very long time, QGIS' Layers toolbar has featured a Remove
 layer(s) button. I have seen two issues with the button:
  - Its placement becomes really odd when plugins add button(s) to the
 Layers toolbar (for e.g. the New Memory Layer plugin as pictured here [
 http://imgur.com/CEcIC3K,QvUzrti ])
  - It can only remove vector/raster layers, won't remove groups

  With the recent improvements done by Martin Dobias on the legend, and in
 particular with his addition of a layer panel embedded toolbar, I propose
 that:
  - The Remove layer(s) button be moved to the layer panel embedded
 toolbar [ http://imgur.com/CEcIC3K,QvUzrti#1 ]
  - The button functionally is improved so it can also deal with the
 removal of group(s)

  Alternatively, we could get rid of the button altogether since layers
 and groups can be removed via right click or keyboard shortcut, but I
 suspect the touch screen based users might object.

  Any objection to moving the button to the new layers toolbar?

  Math


 ___
 Qgis-developer mailing 
 listQgis-developer@lists.osgeo.orghttp://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] Heads-up: Code freeze starts on 2014-09-26 (4 days)

2014-09-22 Thread Mathieu Pellerin

Thanks for the reminder Jürgen.

Tim, could you create a visual changelog page for the upcoming 2.6 release?
We can start now to append the new features so it can be as complete as
possible.

M
On 22 Sep 2014 19:00, Jürgen E. j...@norbit.de wrote:

 Hi,

 I'd like to remind everyone that the 2.5 development cycle ends on next
 friday,
 2014-09-29[1] (4 days away), we'll go into feature freeze and start the 2.6
 release cycle in which we'll do testing, bugfixing, translating and release
 preparations instead of feature development for the 2.6 release.

 Please merge your new features before 2014-09-26 and prepare to start
 testing.
 The 2.6 release will be on 2014-10-24[2] (32 days away).

 See also [3]


 Jürgen

 [1]
 http://www.timeanddate.com/countdown/generic?p0=1440iso=20140926T12year=2014month=9day=26hour=12min=0sec=0msg=2.5%20Code%20Freeze
 [2]
 http://www.timeanddate.com/countdown/generic?p0=1440iso=20141024T12year=2014month=10day=24hour=12min=0sec=0msg=2.6%20Release
 [3] http://qgis.org/en/site/getinvolved/development/index#road-map.html

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

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)

 iQIVAwUBVCAPUBBsJ9SQbsVUAQKybg/+IwlT7UKi8cXaY0I2+AVR5BXtYnmQNVOq
 iCSBwgkR6x41gfA6/PVZ19/MkXAEpgxwASk9vTLVgy03ucYs+LdPFAYbTmjR6tKs
 MyB3GTSpcceAXDTwn6MYbat0PwTsJHGsCmUYbMalrjMzZ/Dob1V1RWhAtZ0eByKl
 kQzJe+L/vdXQ96sHmLsXTUdUT6KnF7A1jopjeA6S9OOq4tgjAdne3/EitBu5dw7q
 ICd/vH1RzPBxO2SnKlP+mXe+mQ8pDUqXwPIjBYju8f9ja6utsViU33gxXGJn+Xgf
 QsOUpAnrOGnQ5EzB4KE6kgebMMflsweuoydRF14x3QI9WjJ7mzU+4Tv5RIKSpp/2
 6sDx3yRl8uC9GqFZnpPKQ+fP4cHT6sbNfw6apTFH5Tsngj8Uj4U/DUPCoJBqbZnu
 50SMVQS+sxy3QaFeQkPwXBlt9PBp48alBUbo/l6ZWQcaGxqR5dzB70aqpTciMXZK
 cYZZZNz993ACC2pz8RWy62XcNZMT0pqgoiNtOiWM6hanGXyyXL3KkPDzGqMXim1J
 WFN7YVZvj/YKZBcLHG6/8scfq6qyYiEeD8xN9XSR+A6p1hnR1qNAfM/5/cTKYJpO
 lnTqHkbfCJckXw1DGc7b9Tu7JoXMMDe9xzaIMgxHfM3ECwIdZBecs9cXRSmMeui8
 /m/YajfhqfE=
 =npZd
 -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] Module dependencies

2014-09-23 Thread Mathieu Pellerin

+1 to get new memory layer and memory layer saver plugins into core. Memory
layers are a very cool  useful function of qgis, all of its basic
functionality should be in core.
On 23 Sep 2014 15:04, Nyall Dawson nyall.daw...@gmail.com wrote:


 On 23/09/2014 5:46 pm, Andrea Peri aperi2...@gmail.com wrote:
 
  Hi Paolo,
 
  I have some doubt on automatic installation of dependencies.
  This fear this will be a bad practice for security.
 

 Maybe a better solution would be to integrate the memory layer saving into
 core. It'd be a nice feature to have in any case.

 Nyall

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

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

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

2014-09-24 Thread Mathieu Pellerin

Regarding the saving aspect of it, IMO it needs to be worked out. I've had
a couple of users over here already reporting data loss with the
following scenario:
1. Open his/her project
2. Copies one polygon from a large dataset and pastes is as a new memory
layer (very useful feature introduced in QGIS 2.x)
3. Styles the memory layer, and saves the project
4. The next day, when he/she re-opens the project, the polygon is gone

Throughout the above mentioned workflow, there was never _any_ indication
that the pasted memory layer would not be saved when saving the project.

If QGIS further ease access to memory layers via incorporating the new
memory layer function into the core (which I hope its done :) ), and decide
against saving across project session, then there must be a UX to deal with
that, instead of silently killing the data of the memory layer(s). One way
forward would be to have a warning upon closing a project that has
non-saveable memory layers to warn the users. That warning should offer for
users to save the memory layers onto a proper format (possibly like the
missing layer dialog, with a list of all the memory layers and an input to
add the saved file location/name).

Math

On Thu, Sep 25, 2014 at 4:07 AM, Martin Dobias wonder...@gmail.com wrote:

 Hi Nyall

 On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson nyall.daw...@gmail.com
 wrote:
  Hi all,
 
  The recent discussion around memory layers in another thread has started
 me
  thinking about the best way to expose them more readily to users.
 
  As such, I've opened a pull request which ports Borys Jurgiel's New
 Memory
  Layer plugin to core (PR #1591). Hopefully this can be merged for 2.6.
 It's
  more or less a direct port - I've left it without the ability to specify
  fields at creation time as I believe that field creation would indicate
 that
  we are encouraging users to store real data in these layers, which is
  something we should avoid.

 Cool - from time to time it is handy to make a memory layer for some
 temporary data and having to use a plugin / python console for the
 creation is suboptimal...

  What I'm thinking though is that we should rename memory layers within
 the
  UI. The name suggests that they are remembered, and conveys more of a
  permanent feel.
 
  I think that for 2.6 we could rename them to temporary scratch layers,
 and
  then for 2.6 (after we port the memory layer saving plugin/decide on a
  suitable format for saving them) drop the  temporary part of this
 name. So
  they'll be just scratch layers.

 I like the name scratch layer - and I wouldn't mind having it from
 2.6 even without the temporary part although there is no saving for
 it. (Saving is still a bit controversial for me as we would
 inadvertently create another vector file format - unless we would ask
 user to save the layer data into one of OGR supported formats or
 spatialite DB.)

 Cheers
 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

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

2014-09-24 Thread Mathieu Pellerin

Thoughts:
- I don't think warning should be occurring when creating a memory layer
(that is when pasting as new layer, when adding the result of a processing
algorithm as memory layer, or creating a blank memory layer)
- I don't think the user should be able to disable the warning message
(which imo should be a dialog with saving shortcuts), the resulting data
loss is too critical; it's like opening a project with missing layers, qgis
doesn't (and shouldn't) allow for this dialog to be skipped
- IMO best to have: a/ a message bar when saving project while in an
ongoing session, and a missing layer-like warning dialog when closing
project
On 25 Sep 2014 12:15, Denis Rouzaud denis.rouz...@gmail.com wrote:


 On 25.09.2014 04:02, Mathieu Pellerin wrote:

Regarding the saving aspect of it, IMO it needs to be worked out. I've
 had a couple of users over here already reporting data loss with the
 following scenario:
  1. Open his/her project
 2. Copies one polygon from a large dataset and pastes is as a new memory
 layer (very useful feature introduced in QGIS 2.x)
  3. Styles the memory layer, and saves the project
  4. The next day, when he/she re-opens the project, the polygon is gone

  Throughout the above mentioned workflow, there was never _any_ indication
 that the pasted memory layer would not be saved when saving the project.

  If QGIS further ease access to memory layers via incorporating the new
 memory layer function into the core (which I hope its done :) ), and decide
 against saving across project session, then there must be a UX to deal with
 that, instead of silently killing the data of the memory layer(s). One way
 forward would be to have a warning upon closing a project that has
 non-saveable memory layers to warn the users. That warning should offer for
 users to save the memory layers onto a proper format (possibly like the
 missing layer dialog, with a list of all the memory layers and an input to
 add the saved file location/name).

 I would be in favor of a warning when first create a memory layer. The
 warning would say you can't save them except from using a plugin. And,
 there would be a checkbox do not display this warning anymore.




  Math

 On Thu, Sep 25, 2014 at 4:07 AM, Martin Dobias wonder...@gmail.com
 wrote:

 Hi Nyall

 On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson nyall.daw...@gmail.com
 wrote:
  Hi all,
 
  The recent discussion around memory layers in another thread has
 started me
  thinking about the best way to expose them more readily to users.
 
  As such, I've opened a pull request which ports Borys Jurgiel's New
 Memory
  Layer plugin to core (PR #1591). Hopefully this can be merged for 2.6.
 It's
  more or less a direct port - I've left it without the ability to specify
  fields at creation time as I believe that field creation would indicate
 that
  we are encouraging users to store real data in these layers, which is
  something we should avoid.

 Cool - from time to time it is handy to make a memory layer for some
 temporary data and having to use a plugin / python console for the
 creation is suboptimal...

  What I'm thinking though is that we should rename memory layers
 within the
  UI. The name suggests that they are remembered, and conveys more of a
  permanent feel.
 
  I think that for 2.6 we could rename them to temporary scratch
 layers, and
  then for 2.6 (after we port the memory layer saving plugin/decide on a
  suitable format for saving them) drop the  temporary part of this
 name. So
  they'll be just scratch layers.

 I like the name scratch layer - and I wouldn't mind having it from
 2.6 even without the temporary part although there is no saving for
 it. (Saving is still a bit controversial for me as we would
 inadvertently create another vector file format - unless we would ask
 user to save the layer data into one of OGR supported formats or
 spatialite DB.)

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




 ___
 Qgis-developer mailing 
 listQgis-developer@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-developer



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

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

2014-09-25 Thread Mathieu Pellerin

Possibly although that'd clutter that space. Renaming Memory Layers to
Temporary Layers would also give a good clue.

That said, I must say I quite enjoy using the memory layer saver, I'd be
sad to see this function not making it into core.

Martin raised an important issue re format. What about saving memory layer
data as GeoJSON within the qgis project file? That's a solution that is
compatible with the project file's xml format.

Thoughts on that?
On 25 Sep 2014 13:03, Nathan Woodrow madman...@gmail.com wrote:

 What about a icon in the legend to note that it it's not going to be saved?

 - Nathan

 On Thu, Sep 25, 2014 at 3:57 PM, Mathieu Pellerin nirvn.a...@gmail.com
 wrote:

 Thoughts:
 - I don't think warning should be occurring when creating a memory layer
 (that is when pasting as new layer, when adding the result of a processing
 algorithm as memory layer, or creating a blank memory layer)
 - I don't think the user should be able to disable the warning message
 (which imo should be a dialog with saving shortcuts), the resulting data
 loss is too critical; it's like opening a project with missing layers, qgis
 doesn't (and shouldn't) allow for this dialog to be skipped
 - IMO best to have: a/ a message bar when saving project while in an
 ongoing session, and a missing layer-like warning dialog when closing
 project
 On 25 Sep 2014 12:15, Denis Rouzaud denis.rouz...@gmail.com wrote:


 On 25.09.2014 04:02, Mathieu Pellerin wrote:

Regarding the saving aspect of it, IMO it needs to be worked out.
 I've had a couple of users over here already reporting data loss with the
 following scenario:
  1. Open his/her project
 2. Copies one polygon from a large dataset and pastes is as a new memory
 layer (very useful feature introduced in QGIS 2.x)
  3. Styles the memory layer, and saves the project
  4. The next day, when he/she re-opens the project, the polygon is gone

  Throughout the above mentioned workflow, there was never _any_
 indication that the pasted memory layer would not be saved when saving the
 project.

  If QGIS further ease access to memory layers via incorporating the new
 memory layer function into the core (which I hope its done :) ), and decide
 against saving across project session, then there must be a UX to deal with
 that, instead of silently killing the data of the memory layer(s). One way
 forward would be to have a warning upon closing a project that has
 non-saveable memory layers to warn the users. That warning should offer for
 users to save the memory layers onto a proper format (possibly like the
 missing layer dialog, with a list of all the memory layers and an input to
 add the saved file location/name).

 I would be in favor of a warning when first create a memory layer. The
 warning would say you can't save them except from using a plugin. And,
 there would be a checkbox do not display this warning anymore.




  Math

 On Thu, Sep 25, 2014 at 4:07 AM, Martin Dobias wonder...@gmail.com
 wrote:

 Hi Nyall

 On Thu, Sep 25, 2014 at 3:31 AM, Nyall Dawson nyall.daw...@gmail.com
 wrote:
  Hi all,
 
  The recent discussion around memory layers in another thread has
 started me
  thinking about the best way to expose them more readily to users.
 
  As such, I've opened a pull request which ports Borys Jurgiel's New
 Memory
  Layer plugin to core (PR #1591). Hopefully this can be merged for
 2.6. It's
  more or less a direct port - I've left it without the ability to
 specify
  fields at creation time as I believe that field creation would
 indicate that
  we are encouraging users to store real data in these layers, which is
  something we should avoid.

 Cool - from time to time it is handy to make a memory layer for some
 temporary data and having to use a plugin / python console for the
 creation is suboptimal...

  What I'm thinking though is that we should rename memory layers
 within the
  UI. The name suggests that they are remembered, and conveys more of a
  permanent feel.
 
  I think that for 2.6 we could rename them to temporary scratch
 layers, and
  then for 2.6 (after we port the memory layer saving plugin/decide on
 a
  suitable format for saving them) drop the  temporary part of this
 name. So
  they'll be just scratch layers.

 I like the name scratch layer - and I wouldn't mind having it from
 2.6 even without the temporary part although there is no saving for
 it. (Saving is still a bit controversial for me as we would
 inadvertently create another vector file format - unless we would ask
 user to save the layer data into one of OGR supported formats or
 spatialite DB.)

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




 ___
 Qgis-developer mailing 
 listQgis-developer@lists.osgeo.orghttp://lists.osgeo.org/mailman/listinfo/qgis-developer

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

2014-09-25 Thread Mathieu Pellerin

Nyall, I don't think there's a compatibility issue with memory layers.
Those are by their nature QGIS-dependant data, the same way ArcGIS can't
simply open a .qgs project file, a .qml layer properties file, etc.

One of the nice feature of memory layers (and its sister plugin memory
layer saver) is the fact that they are embedded within .qgs project files.
It should stay that way (which using GeoJSON within the XML structure of an
.qgs file would do). Transforming the .qgs project file into a zip
container would probably be a huge project driven by greater needs than
memory layers :)

Re Temporary Layers, I find it slightly better than Scratch Layer for non
native English speakers (i.e. more to the point in simple English :) ).

M



On Thu, Sep 25, 2014 at 1:38 PM, Nyall Dawson nyall.daw...@gmail.com
wrote:


 On 25/09/2014 4:27 pm, Mathieu Pellerin nirvn.a...@gmail.com wrote:
 
  Possibly although that'd clutter that space.

 Not really- it could be handled in the same way as the editing icon is at
 the moment. That doesn't take up any extra room as it replaces the style
 swatch.

 
  That said, I must say I quite enjoy using the memory layer saver, I'd be
 sad to see this function not making it into core.
 
  Martin raised an important issue re format. What about saving memory
 layer data as GeoJSON within the qgis project file? That's a solution that
 is compatible with the project file's xml format.

 I think the issue is more with compatibility with other programs. That's
 why a zip/archive style project file which stores memory layers in an
 existing standard format (eg geojson) was suggested.

 Nyall

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

Re: [Qgis-developer] Please stop spamming commit logs!

2014-10-10 Thread Mathieu Pellerin

Considering that one of QGIS' main source of funding for development is
through financial sponsorship of _independent_ developers, I'd be very
careful not to take decisions that would hurt that ecosystem without asking
those independent developers the reasoning behind leaving a trace in the
commit log of who/what financially paid for feature XYZ.

For e.g., this could actually be a requirement of sponsors when it comes to
financial audits (i.e., what better audit proof that budgeted money went to
pay for specific improvement(s) of an open source project than a trace in
the said open source project's commit logs).

Beyond that, I find that as long as the sponsored by / funded by
one-liner is a the very end of the commit log, it doesn't hurt the ease of
readability of the commit logs via github or git log.

The home page footer sponsors are listing the QGIS project sponsors, not
sponsors who paid for independent developers to improve code and add new
features. Please correct me if I'm wrong.

M


On Fri, Oct 10, 2014 at 3:23 PM, Alessandro Pasotti apaso...@gmail.com
wrote:

 2014-10-10 10:09 GMT+02:00 Lene Fischer l...@ign.ku.dk:

  I agree to Nyall –

 We need sponsors. And sponsors don´t want to be in footnotes fontsize 6.5


 Agreed, see the footer the home page

 http://www.qgis.org/it/site/



  Right now I´ve started to get sponsors to the next
 developer/usermeeting in Denmark. And I´m sure sponsors will not be
 satisfied to be put into an appendix.

 I think these small textnotes in the mail are harmless


 Sorry, I don't follow you: I was talking about commit logs.


 --
 Alessandro Pasotti
 w3:   www.itopen.it

 ___
 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] weekly build problem

2014-10-14 Thread Mathieu Pellerin

Rename your .qgis2 folder in your user profile directory (eg
c:\users\my_name\.qgis2) to something else to try a vanilla qgis
configuration. If speed goes back to normal, problem lies with a plugin, or
less likely a non-default qgis setting.

M
On 15 Oct 2014 12:52, Stott, James fmro...@fylkesmannen.no wrote:

  Are there any plugins that could be causing this problem? Seeing as the
 problem exists over 2 different versions of QGIS I would recommend checking.



 I have had similar (think it was with version 2 and 2.2) and the problem
 was solved by turning off all plugins. I was then able to add the plugins
 in again one by one to find the plugin causing the problem.



 *Fra:* qgis-developer-boun...@lists.osgeo.org [mailto:
 qgis-developer-boun...@lists.osgeo.org] *På vegne av* Angie Rudolph
 *Sendt:* 15. oktober 2014 01:17
 *Til:* qgis-developer@lists.osgeo.org
 *Emne:* [Qgis-developer] weekly build problem



 I installed the windows weekly build on 9/26/14 and QGIS has been behaving
 poorly ever since.  When I add
 a simple shapefile, stored on my local hard drive, turning the layer off
 an on takes up to 10 seconds.

 I have since tried to uninstall the weekly build and install a stable
 version of QGIS (2.4) but the problem now remains.

 Is there something else that needs to be uninstalled such as visual C++,
 etc?



  --

 Angie Rudolph, GISP

 Greenwood Mapping, Inc.

 c:(208)-201-5699



 ___
 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] 2.6: first overview

2014-11-02 Thread Mathieu Pellerin

Niccola,

With regards to point 1  2, you would increase the chance of those issues
being fixed (and help QGIS) by filing tickets at hub.qgis.org . Be as
descriptive as you can, provide steps to reproduce what affects you; that
should be enough to get a developer to look into it. Sample data source 
project file leading to issue a bonus.

M
On 3 Nov 2014 05:16, Niccolò Marchi sciurusurba...@hotmail.it wrote:

  Hi all,

 just few things I'm experiencing with 2.6:



-

*Attribute Table*: modifying the content of a cell, it needs to save
and reopen the table to see it updated...normal behaviour?
-

*Crash*: different types. Usually closing the project, QGIS ends up
with a minidump or the MS error window The software stopped to work etc
etc. This happens closing .qgs from 2.2 with or without saving to 2.6
version. Sometimes also while working. Attached you can find the .dmp
(shall I upload them? I don't know how to deal with). Actually it's a quite
annoying issue...
-

*Corrupt layers*: the table appears but double-clicking the source it
doesn't open the explorer as in 2.2; it only allows to modify the folder
destination as text. Is that the new behavior?
-

*Translation **(**ITA**)*: just few oversights:
-

   color selection panel: incolla co*ll*ore
   -

   modify widget properties: il widget di *modica* può...


  Is there anyone with the same issues? I'm working with W8.1 64bit and
 QGIS standalone.


  As always: thank you all for your work!


  All the best,


  Nic

 ___
 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] issues in QGIS 2.6 when saving/working with projects saved in previous QGIS releases

2014-11-07 Thread Mathieu Pellerin

I'm wondering whether it has to do with a composer legend item crasher that
Martin fixed days ago.

Are users sharing the project files that make qgis crash?
On 7 Nov 2014 20:53, Giovanni Manghi giovanni.man...@faunalia.pt wrote:

 Hi all,

 we are getting quite a lot of feedback (in the tracker, lists,
 directly, etc.) from users that are getting crashes in QGIS 2.6 when
 working/saving projects made with previous QGIS releases, ex:

 http://hub.qgis.org/issues/11593

 http://hub.qgis.org/issues/11592

 and others.

 Any one was able to find a pattern that would allow to track the
 source of the issue?

 cheers

 -- Giovanni --
 ___
 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] issues in QGIS 2.6 when saving/working with projects saved in previous QGIS releases

2014-11-07 Thread Mathieu Pellerin

IMO, this is serious enough to package a 2.6.1 release speedily. There are
enough ppl out there that don't backup their documents on a regular basis
for this bug to be hugely problematic.
On 8 Nov 2014 00:49, Martin Dobias wonder...@gmail.com wrote:

 On Fri, Nov 7, 2014 at 9:11 PM, Mathieu Pellerin nirvn.a...@gmail.com
 wrote:
  I'm wondering whether it has to do with a composer legend item crasher
 that
  Martin fixed days ago.
 
  On 7 Nov 2014 20:53, Giovanni Manghi giovanni.man...@faunalia.pt
 wrote:
 
  http://hub.qgis.org/issues/11593

 Indeed it is the same nasty bug. Mathieu discovered it and I have
 fixed it in master few days ago, now the fix is also in release-2.6
 branch.

 Unfortunately it is really an ugly one as it not only crashes, but
 also clears the project file as the crash happens during the save :-(

 Regards
 Martin

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

Re: [Qgis-developer] Composer... current status and the way forward?

2014-11-07 Thread Mathieu Pellerin

Nyall,

Please, let's not go down the road of two options to do the same thing (ala
double symbology  double labelling engine era of qgis 1.x)

Nor can we leave users' previously saved composers broken.

So #2 seems to be the wining option.

A fundamental change like that would go very well with a name change too.

Every move that gets us closer to having non mm units is worth the sweat :)
On 7 Nov 2014 18:38, Nyall Dawson nyall.daw...@gmail.com wrote:

 Hi all,

 I'm seeking feedback about the best way to move forward with QGIS' map
 composer. I'm currently running up against some large issues with the
 current design and API of composer which are holding back important
 features and fixes. Some of these issues include:

 - there's too much composer logic tied up in app and gui. This makes
 it very difficult for plugins to manipulate and export compositions
 without duplicating large blocks of code
 - there's too much item-specific logic and handling scattered through
 QgsComposition, QgsComposerView and QgsComposer. This makes it
 impossible to have features like plugin generated item types, and
 makes maintenance difficult.
 - everything is coded to expect measurements and sizes in mm. I can't
 (nicely) add support for other units without breaking api or resorting
 to a lot of hacks
 - same for mixed page sizes and orientations within a single
 composition, this requires an api break to implement cleanly
 - I need to totally break composer api in order to fix the instability
 in undo/redo commands (see http://hub.qgis.org/issues/11371)
 - QgsComposition should not require a QgsMapSettings/QgsMapRenderer.
 This should instead be set individually for map items. Doing so would
 pave the way for features such as reprojection support for individual
 map items.
 - the composer is full is deprecated methods and legacy api

 I've slowly come to the conclusion that the way forward is to move to
 a bunch of new classes, much like what was done with symbologyV2. If
 https://github.com/qgis/QGIS-Enhancement-Proposals/pull/9 passes then
 these would be named QgsLayout, QgsLayoutDesigner, etc. If not, well,
 I'll have to resort to QgsCompositionV2, etc.

 The potential problem with this approach is how to handle the GUI and
 existing projects. As far as I can see, there's a few options:
 1. Expose both the existing composer and the new layout designer to
 users. Composers aren't automatically upgraded to layouts. This
 approach means that existing PyQgis code and plugins will still
 function for existing projects, but at the expense of a confusing
 experience for users.
 2. Add all the new layout classes and keep the existing composer
 classes. Composer would NOT be exposed in the GUI and compositions are
 upgraded to layouts when projects are opened. This approach means that
 standalone python code would still operate, but plugins or code which
 are designed to be run from within QGIS would no longer function.
 3. Move totally to the new layout classes and remove all composer
 classes (unlikely)

 I'm leaning toward option 2, but what are you thoughts? What's the
 best approach to move forward? Obviously I'll submit all this as a QEP
 when the plans are finalised, but for now I'm just after advice on the
 preferred approach.

 Nyall
 ___
 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] Stability (2.8 LTS) vs development (3.0), a proposed way forward

2014-11-09 Thread Mathieu Pellerin

Guys,

The recent thread Nyall kick-started with his  “QGIS 3.0?” email got me to
think about the eternal stability vs. development dilemma it (re-)exposed
through the conversation.

More specifically, it got me to brainstorm on the best way forward for QGIS
at this juncture and whether there's a way to accommodate both the folks
calling for a 2.8 LTS version, and others in need for space to further
develop and expand QGIS' capability.

And, I might just have found a way to do so. Here's the proposal, in a
couple of points:

- We make the 2.8 development cycle “fix and refinement”-only, and reduce
the cycle's length to 6 to 8 weeks;
- The reduced cycle will help everyone's focus on the above goal;
- We append the freed 8-10 weeks to the subsequent development cycle, which
would become QGIS 3.0;
- The expanded cycle will help give space to develop some of the exciting
features being cooked by developers (Nyall's Layouts, Marco's Geometry
redesign, etc.) and bulletproof those.

This, IMHO, caters to both groups demanding stability and space for
development. It doesn't discourage or delay too much the grand scheme
changes, and pushes out a 2.8 version focused on stability through a
shorter cycle focusing on delivering a perfected tool.

The above proposal does require a momentary lapse of the nice 4-month
release cycle rhythm which the QGIS has successfully maintained for three
releases now. But, it might actually be what's needed at this very time.
Plus, the length of the two cycles stays the same, 8 months.

Comments? I'm obviously particularly interested in what Jürgen has to say :)

Cheers

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

Re: [Qgis-developer] Stability (2.8 LTS) vs development (3.0), a proposed way forward

2014-11-10 Thread Mathieu Pellerin

Anita,

Thanks for pointing out QEP#4, I wasn't aware of it. Tim has done an
impressive work there.

The above-mentioned QEP is a long term thing, what I was suggesting is a
very short term (i.e. 2 cycles) proposal to try and satisfy the current
needs for stability and devlopment momentum. I also am familiar with the
discussion surrounding the 4 month cycle dates having been carefully
chosen, hence why I was thinking that redistributing weeks within the
context of two cycles wouldn't break that on the long term (i.e., by the
end of the proposed two cycles, we're still 8 months from now, etc.)

Math


On Mon, Nov 10, 2014 at 2:11 PM, Anita Graser anitagra...@gmx.at wrote:

 Are you aware of QEP3? Please read Tim's suggestion. There are good
 reasons for this stable 4 month cycle at exactly the current release times
 of the year.

 Best wishes
 Anita
 On Nov 10, 2014 5:57 AM, Geo DrinX geodr...@gmail.com wrote:

 Yes yes yes.

 +1

 but also +999 :)


 Roberto

 2014-11-10 2:27 GMT+01:00 Mathieu Pellerin nirvn.a...@gmail.com:

 Guys,

 The recent thread Nyall kick-started with his  “QGIS 3.0?” email got me
 to think about the eternal stability vs. development dilemma it
 (re-)exposed through the conversation.

 More specifically, it got me to brainstorm on the best way forward for
 QGIS at this juncture and whether there's a way to accommodate both the
 folks calling for a 2.8 LTS version, and others in need for space to
 further develop and expand QGIS' capability.

 And, I might just have found a way to do so. Here's the proposal, in a
 couple of points:

 - We make the 2.8 development cycle “fix and refinement”-only, and
 reduce the cycle's length to 6 to 8 weeks;
 - The reduced cycle will help everyone's focus on the above goal;
 - We append the freed 8-10 weeks to the subsequent development cycle,
 which would become QGIS 3.0;
 - The expanded cycle will help give space to develop some of the
 exciting features being cooked by developers (Nyall's Layouts, Marco's
 Geometry redesign, etc.) and bulletproof those.

 This, IMHO, caters to both groups demanding stability and space for
 development. It doesn't discourage or delay too much the grand scheme
 changes, and pushes out a 2.8 version focused on stability through a
 shorter cycle focusing on delivering a perfected tool.

 The above proposal does require a momentary lapse of the nice 4-month
 release cycle rhythm which the QGIS has successfully maintained for three
 releases now. But, it might actually be what's needed at this very time.
 Plus, the length of the two cycles stays the same, 8 months.

 Comments? I'm obviously particularly interested in what Jürgen has to
 say :)

 Cheers

 Math

 ___
 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] Heatmap renderer: caching possible?

2014-11-26 Thread Mathieu Pellerin

Hmm, handling a cache for the heatmap renderer would probably be quite
challenging. Let's say a temporary raster heatmap is created to ease
panning, you'd have to re do this every time the zoom level is changed. You
could decide to cache as many temporary raster hearmaps as zoom levels
requested by the user during a session, but that'd probably be a memory
nightmare both in terms of nb of zoom levels and resolution of temporary
raster at high level values. All of that cache would also have to be
revoked as soon as the dataset is modified.

In cases where a cache is needed, your probably better off with a formal
raster heatmap.
On 27 Nov 2014 05:49, Andreas Neumann a.neum...@carto.net wrote:

 Hi,

 I tried the new heatmap renderer in QGIS master. It works nicely.

 I wonder if we could introduce a caching mechanism in a temporary raster
 layer to speed up zooming and panning? The idea would be to recreate the
 heatmap every time the project is loaded and then cache it while the
 project is open. At least as an option. For small data or smaller search
 radius the live behaviour would still work well, but for larger data sets
 of larger search radius, such a cache raster would speed things up
 significantly, especially in a server scenario.

 Would such a cache be technically possible and useful?

 Andreas
 ___
 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] Ugly jumping maps while zooming

2014-12-22 Thread Mathieu Pellerin

Thanks for fixing the jumping issue for non-rotated canvas.

That said, I'm wondering whether the rotation feature should be exposed in
the status bar unless all of the basic canvas interactions are taught how
to deal with rotation (which inc. flawless zoom / pan experience and
probably  north arrow decoration as it really doesn't look good for qgis to
have rotated map with a broken north arrow).

Maybe if you believe you can't commit more time n energy on this for 2.8,
the status bar item can be moved to project settings? I'm a fan of the
feature, so hoping it'll stay n improve.

M
On Mon, Dec 22, 2014 at 09:07:32AM +, Ziegler Stefan wrote:

 The jumping is gone when there is no rotation.

Thanks for testing. Martin merged the fix into master.

 But it has some strange behaviour when drawing the zooming rectangle
 with a rotated map (see attached image).

Known (by me) issue. I thought I also filed a ticket for this but could
not find it now, can you do that yourself ? Please add the rotation
tag in the report.

Generally speaking, there are many places that need to learn about core
rotation. Searching the tracker for issues with rotation tag is a good
starting point.

I've only had enough fundings to add the core support. I'll work on fixing
any regression in absence of rotation (like the jumping one) but will not
approach further enhancements until I either have some spare time or find
more sponsors.

--strk;

  ()   Free GIS  Flash consultant/developer
  /\   http://strk.keybit.net/services.html
___
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] Ugly jumping maps while zooming

2014-12-23 Thread Mathieu Pellerin

To be fair to all, there should probably be an agreed upon understanding on
what would need fixing/implementing for the rotation feature to sticik
prior to 2.8, and if it can't be achieved by then revert the commits until
next dev cycle?

I can't be the judge of that, senior devs needed :)
On 23 Dec 2014 19:06, Nathan Woodrow madman...@gmail.com wrote:

  I agree with Paolo, and also see the value of Sandro's argument that
 developing such functionality in a branch get's much less
 testing/viewing and is very hard to merge back. Myself I only had a
 serious look at it when it was in master...

 Sometimes it's not about other people testing, sometimes it's about having
 time for other developers to review the code, even just by eyeing it over,
 before it is merged in.  Other people might be able to pick up things that
 you might miss and save you the effort of bug fixing it later, or you might
 be doing it completely wrong to start with.

 Sometimes it is also about not having a feature until it is ready, some
 things just need to wait until they are ready.

 I also understand that sometimes things seem simple but lead to more
 issues then you expect, we have all been there, however that is why we have
 testing branches  It makes the user experience in QGIS a lot nicer.

 I am in no way against the feature, it is a good one, in fact I have a use
 for it in Roam, and I do not wish to undermine Sandro's efforts rotation is
 a big task, however as it has the possibility of introducing regressions it
 should be treated with care - also merging a feature in and then trying to
 get more funding for bugs is IMO not a cool move.

 If you write code that has small impact, import/export bookmarks for
 example, I don't care if something like that is merged right in, small foot
 print, small use case, easy fix, but for something that touches a major
 core part of the code I think reviews should be done.

 - Nathan

 On Tue Dec 23 2014 at 8:10:18 PM Richard Duivenvoorde rdmaili...@duif.net
 wrote:

 On 23-12-14 08:06, Paolo Cavallini wrote:
  Hi Nyall,
 
  Il 22/12/2014 23:47, Nyall Dawson ha scritto:
 
  I disagree - while there may be an issue with the difficulty of getting
  wide testing of pull requests, the solution isn't to allow broken code
  into master.
 
  You're right, we're big boys now, must behave. However:
  * the code is in good shape, not broken; works smoothly in a variety of
  situations
  * it opens a whole set of new and exciting applications, e.g. live
  tracking, drone monitoring, etc.
  * there are unsupported functions, as pointed out
  * if we remove it from master, it will soon become unmergeable, and will
  probably get lost; it happened several times in the past that what we
  left out of the door was never recovered.
  Overall, I still believe keeping it, but letting conscious users
  activate it when necessary, is a good compromise.
  In the meantime, we can start raising funds to complete the set of
  necessary features (I do not think it's a huge amount of work, once the
  money is found we have time to implement these for 2.8).
  All the best, and thanks for your thoughts.

 I agree with Paolo, and also see the value of Sandro's argument that
 developing such functionality in a branch get's much less
 testing/viewing and is very hard to merge back. Myself I only had a
 serious look at it when it was in master...

 So as long as we can hide it for normal users (even without tickbox, we
 can make a cli-option for it :-) ), AND nothing is broken I'm in favour
 of letting it in master.

 I think Sandro should hide the spinbox in the statusbar for now, and
 nay-sayers should now try to find bugs related to rotation work?

 There is a PSC-meeting on 2th januari, let's make the final decision
 there.

 Regards,

 Richard Duivenvoorde
 ___
 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

[Qgis-developer] Virtual column joins

2015-01-22 Thread Mathieu Pellerin

Greetings,

Earlier this week, I ran into the need to do a temporary join between two
datasets that would have relied on a virtual column. It however seems that
QGIS is unable to do so as the virtual colum did not appear in the list of
available columns to use to establish a join.

Is that a known limitation or an implementation issue?

Best

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

Re: [Qgis-developer] Rotation status and PSC meeting

2015-01-15 Thread Mathieu Pellerin

Sandro, Nyall,

Discussing this with Martin earlier today, he came up with a test patch to
see what would happen if the code was blindly modified to use
QgsMapSettings' setRotation() function. The result is interesting, it
actually _mostly_ works (see attached patch):
- before the patch, rotating the map composer of 45 degrees looked like
this: http://i.imgur.com/8e88VZf.png
- applying the patch, rotating the map composer of 45 degrees now looks
like this: http://i.imgur.com/VudbYrn.png

The map rotation without the patch shows the current limitations, namely
undesired rotated label, undesired rotated symbology, etc.

With the patch applied, the label is horizontal, and my centroid triangle
symbology's orientation is respected. There is however an issue with the
calculation of the rotated map extend leading to a slightly misplaced map
overview polygon on the larger map as well as a slight misalignment of the
grid.

Regarding the map overview issue, this got me to think that instead of
having a map visibility extend calculation code in the composer map item,
the QgsMapSettings object should have a function that returns a visible
extend polygon (in WKT string, or whatever). That would simplify and
bulletproof the code in many places beyond the composer map item.

Food for thoughts.

Math

On Fri, Jan 16, 2015 at 9:00 AM, Mathieu Pellerin nirvn.a...@gmail.com
wrote:

 Sandro,

 The last few weeks has been a nice leap forward when it comes to your
 rotation feature, congratulation on that.

 IMO, based on the improvements, it's worth considering _removing the
 activation option altogether_ from the preference window. I can't see
 any stability and usability issue that would warrant disabling it.

 That said, in my view, a basic composer support (i.e. map item's
 rotation feature) should be moved at the top of your priority list.
 Right now, the benefits of your rotation work _cannot_ be exported
 outside of the QGIS canvas, which IMO is a serious limitation. In most
 of my QGIS workflows, the final cartographic products are exported
 through the composer to obtain an high resolution file that can be
 printed out (i.e. I can't just go save the canvas as an image :) ).
 Not having map items make use of your rotation feature is a
 significant restriction.

 Cheers, and thanks again for the work,

 Math


 On Thu, Jan 15, 2015 at 9:59 PM, Sandro Santilli s...@keybit.net wrote:
  I've spent more time on rotation (only partially funded), fixing:
 
   - Label pre-rotation (#11814)
   - North Arrow Decoration (#11818)
   - Grid decoration (#11817)
 
  Leftover issues (open for funding):
 
   - Plugin layers (#11900) -- needs feedback
   - Overview map (#11862) -- minor, IMHO
   - Composer support (#11912) -- wish ?
   - Atlas doesn't consider map rotation when setting scale (#11954)
 
  Please report any other issue that might arise with rotation enabled
  and properly tag it with the rotation label.
 
  I'd like to partecipate to the PSC meeting tomorrow but it is only
  possible for me before 18:00 CET. I hadn't found the schedule here:
  http://hub.qgis.org/wiki/17/PSC_Meeting_16_January_2015
  At what time do you plan to meet ?
 
  --strk;
 
()   Free GIS  Flash consultant/developer
/\   http://strk.keybit.net/services.html
  ___
  Qgis-developer mailing list
  Qgis-developer@lists.osgeo.org
  http://lists.osgeo.org/mailman/listinfo/qgis-developer

diff --git a/src/core/composer/qgscomposermap.cpp 
b/src/core/composer/qgscomposermap.cpp
index 3f0a29f..a811a02 100644
--- a/src/core/composer/qgscomposermap.cpp
+++ b/src/core/composer/qgscomposermap.cpp
@@ -202,6 +202,7 @@ QgsMapSettings QgsComposerMap::mapSettings( const 
QgsRectangle extent, const QS
   jobMapSettings.setMapUnits( ms.mapUnits() );
   jobMapSettings.setBackgroundColor( Qt::transparent );
   jobMapSettings.setOutputImageFormat( ms.outputImageFormat() );
+  jobMapSettings.setRotation( mEvaluatedMapRotation );
 
   //set layers to render
   QStringList theLayerSet = layersToRender();
@@ -362,9 +363,9 @@ void QgsComposerMap::paint( QPainter* painter, const 
QStyleOptionGraphicsItem* i
 painter-save();
 
 painter-translate( mXOffset, mYOffset );
-painter-translate( xTopLeftShift, yTopLeftShift );
-painter-rotate( mEvaluatedMapRotation );
-painter-translate( xShiftMM, -yShiftMM );
+//painter-translate( xTopLeftShift, yTopLeftShift );
+//painter-rotate( mEvaluatedMapRotation );
+//painter-translate( xShiftMM, -yShiftMM );
 painter-scale( scale, scale );
 painter-drawImage( 0, 0, mCacheImage );
 
@@ -413,9 +414,9 @@ void QgsComposerMap::paint( QPainter* painter, const 
QStyleOptionGraphicsItem* i
 double yTopLeftShift = ( cExtent.yMaximum() - rotationPoint.y() ) * 
mapUnitsToMM();
 painter-save();
 painter-translate( mXOffset, mYOffset );
-painter-translate( xTopLeftShift, yTopLeftShift );
-painter-rotate( mEvaluatedMapRotation );
-painter

Re: [Qgis-developer] Rotation status and PSC meeting

2015-01-15 Thread Mathieu Pellerin

Sandro,

The last few weeks has been a nice leap forward when it comes to your
rotation feature, congratulation on that.

IMO, based on the improvements, it's worth considering _removing the
activation option altogether_ from the preference window. I can't see
any stability and usability issue that would warrant disabling it.

That said, in my view, a basic composer support (i.e. map item's
rotation feature) should be moved at the top of your priority list.
Right now, the benefits of your rotation work _cannot_ be exported
outside of the QGIS canvas, which IMO is a serious limitation. In most
of my QGIS workflows, the final cartographic products are exported
through the composer to obtain an high resolution file that can be
printed out (i.e. I can't just go save the canvas as an image :) ).
Not having map items make use of your rotation feature is a
significant restriction.

Cheers, and thanks again for the work,

Math


On Thu, Jan 15, 2015 at 9:59 PM, Sandro Santilli s...@keybit.net wrote:
 I've spent more time on rotation (only partially funded), fixing:

  - Label pre-rotation (#11814)
  - North Arrow Decoration (#11818)
  - Grid decoration (#11817)

 Leftover issues (open for funding):

  - Plugin layers (#11900) -- needs feedback
  - Overview map (#11862) -- minor, IMHO
  - Composer support (#11912) -- wish ?
  - Atlas doesn't consider map rotation when setting scale (#11954)

 Please report any other issue that might arise with rotation enabled
 and properly tag it with the rotation label.

 I'd like to partecipate to the PSC meeting tomorrow but it is only
 possible for me before 18:00 CET. I hadn't found the schedule here:
 http://hub.qgis.org/wiki/17/PSC_Meeting_16_January_2015
 At what time do you plan to meet ?

 --strk;

   ()   Free GIS  Flash consultant/developer
   /\   http://strk.keybit.net/services.html
 ___
 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] Status of 2.8.1 offering on QGIS website

2015-02-27 Thread Mathieu Pellerin

Greetings,

I got contacted by a student yesterday asking whether 2.8 was out. He knew
of release date and visited website but only saw 2.6.1.

Would be good to update website ASAP.

Cheers

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

Re: [Qgis-developer] Qt4-Qt5 timeline: Qt4's status and Qt4's webkit removal in Stretch

2015-05-10 Thread Mathieu Pellerin

That's a pretty serious drawback. If there's no way around this, we need to
make sure composer labels are improved (and hopefully plug in the canvas
label drawing engine to the composer labels).

M

On Sun, May 10, 2015 at 4:19 PM, Nyall Dawson nyall.daw...@gmail.com
wrote:

 On 10 May 2015 at 18:51, Matthias Kuhn matth...@opengis.ch wrote:

  The other issue is that there's a rather big dependency on QtWebkit
  currently. We are struggling already with that on Android.
  Alternatives
  * QtWebEngine is the future but only available starting from Qt 5.4. So
  this is not an option now.
  * QLabel/QML: Where it's only used for richtext, a QLabel can be used.
  Where there's javascript involved it may be worth investigating the use
  of QML.

 This change also affects composer in a big way, in that it's no longer
 possible to have a HTML composer item. QtWebEngine has no support for
 rendering using a QPainter, and without this ability we lose the
 possibility of vector rendering of HTML content. Hopefully this is
 addressed before QWebPage is removed from Qt5, but I honestly doubt it
 will be.

 I'm not sure what our alternatives are. We could fall back to using
 QLabel and it's limited subset of HTML, or ..? In the meantime, I'd
 suggest not relying too heavily on HTML content in compositions!

 Nyall
 ___
 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] Potentially serious performance regression in new geometry - should 2.10 be delayed?

2015-06-22 Thread Mathieu Pellerin

Out of curiosity, how long of a delay do you estimate would be needed to
fix things? 4 weeks, 8 weeks?
On 23 Jun 2015 09:09, Nyall Dawson nyall.daw...@gmail.com wrote:

 Hi all,

 Unfortunately, we've become aware of a serious performance regression
 caused by the new geometry engine. Basically, the situation is that for all
 geometry operations which rely on geos (think buffers, splits, spatial
 relation operations such as intersects and within,... ) the geometry now
 needs to be converted into a geos representation with *every* operation. In
 the old geometry engine this conversion was done once, and the result
 stored so that follow up operations would not need to recalculate it. This
 potentially has huge impacts on the performance of common tasks such as
 selecting all features which intersect a geometry.

 I've had a look, and unfortunately it's not trivial to fix this. I think
 the correct solution to this is to:

 - make QgsGeometryEngine accept and return QgsGeometry containers, not
 QgsAbstractGeometryV2
 - store the generated geos representation of geometries within
 QgsGeometryPrivate inside the QgsGeometry container. This way it will be
 reusable between different geometry operations, and shared when QgsGeometry
 objects are copied. This will also have the benefit that if a geometry is
 prepared using geos then subsequent geos operations performed on that
 QgsGeometry and its shared copies will be much faster.
 - make QgsGeometry a friend class of QgsGeo, so that it can access
 QgsGeometryPrivate to retrieve or set the geos representation of the
 geometry as required

 An alternative (short term) solution would be to just cache the geos
 representation when geometry operations are called through the older
 QgsGeometry modification/relationship operations. This would be easier, but
 means that the API of QgsGeometryEngine will be stuck with the current
 design, and we won't be able to properly fix this until breaking the api
 for 3.0.

 Either way, I doubt this can be addressed within the remaining 3 days we
 have until release. Should we delay to address this? Release with the
 regression? Or am I missing something and there's an easier solution we
 could implement? Or even possibly this additional cost of recalculating the
 geos representation is trivial and can be ignored (maybe someone could test
 this with a little repeated intersection script)?

 Thoughts?

 Nyall

 ___
 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] Testing a new chat room for QGIS at https://gitter.im/qgis

2015-06-12 Thread Mathieu Pellerin

Whether logged in or not, visiting the link says You've tried to
access *qgis's
private* organization room and you do not belong to this organization.



On Sat, Jun 13, 2015 at 11:48 AM, Tim Sutton t...@qgis.org wrote:

 Hi All


 If anyone is interested, I started a chat room for QGIS at
 https://gitter.im/qgis - it is a modern take on IRC and provides a
 similar experience to HipChat or Slack - you can paste images into the
 chat, use markdown to format your messages and it has web, desktop and
 mobile clients (Win / OS X / Linux / Android / IOS). You need a github
 account to sign in - we look forward to chatting to anyone interested in
 testing it out!

 Regards




 Tim Sutton
 QGIS Project Steering Committee Member
 t...@qgis.org





 ___
 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] Layers and Browser dock widget icons

2015-05-28 Thread Mathieu Pellerin

Larry,

As Nyall mentioned, icon size of the dock tool button will go back to 16 x
16 by default. That'll make things look the same as before.

That said, the border on the buttons (no present on other OSes) aren't very
nice. It might be worth adding a style specifically for os x to remove
those.
On 29 May 2015 05:37, Nyall Dawson nyall.daw...@gmail.com wrote:


 On 29 May 2015 5:55 am, Larry Shaffer lar...@dakotacarto.com wrote:
 
  Hi,
 
  The new icons for the Layers and Browser docks look good, but now the
 sizing and spacing looks awkward when compared to the main toolbars (see 0,
 1 screen snaps), especially on Mac. What's the likelihood that we can
 switch those over from QToolButtons to a actions on a QToolBar instead for
 the upcoming release? These docks would then look similar to the Console's
 QToolBar (see either screen snap).

 There's some discussion on the pull request regarding this, see:

 https://github.com/qgis/QGIS/pull/2071#issuecomment-106283486

 The plan is to drop the icon/button sizes down a level (should then match
 the previous appearance).

 Nyall

 ___
 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] Layers and Browser dock widget icons

2015-05-29 Thread Mathieu Pellerin

I'd say the related changes committed within the last 72 hours helped a lot
in that regard. For one, the icon refresh moved away from 16 x 16 png icons
to SVG graphics. In addition, the icon size for dock tool buttons are now
taking into account the user preferred icon size.

On Fri, May 29, 2015 at 3:05 PM, Alessandro Pasotti apaso...@gmail.com
wrote:

 Please consider HiDPI screens when planning icon sizes, at least they
 should be configurable, there is still a settings option for icon sizes.

 At the HF we discussed about the different options, one is to add options
 like

 very small
 small
 normal
 big
 huge

 instead of the px size, this should scale nicely converting sizes to
 actual pixels according to DPI.




 2015-05-29 2:34 GMT+02:00 Mathieu Pellerin nirvn.a...@gmail.com:

 Larry,

 As Nyall mentioned, icon size of the dock tool button will go back to 16
 x 16 by default. That'll make things look the same as before.

 That said, the border on the buttons (no present on other OSes) aren't
 very nice. It might be worth adding a style specifically for os x to remove
 those.
 On 29 May 2015 05:37, Nyall Dawson nyall.daw...@gmail.com wrote:


 On 29 May 2015 5:55 am, Larry Shaffer lar...@dakotacarto.com wrote:
 
  Hi,
 
  The new icons for the Layers and Browser docks look good, but now the
 sizing and spacing looks awkward when compared to the main toolbars (see 0,
 1 screen snaps), especially on Mac. What's the likelihood that we can
 switch those over from QToolButtons to a actions on a QToolBar instead for
 the upcoming release? These docks would then look similar to the Console's
 QToolBar (see either screen snap).

 There's some discussion on the pull request regarding this, see:

 https://github.com/qgis/QGIS/pull/2071#issuecomment-106283486

 The plan is to drop the icon/button sizes down a level (should then
 match the previous appearance).

 Nyall

 ___
 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




 --
 Alessandro Pasotti
 w3:   www.itopen.it

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

Re: [Qgis-developer] QEP - Proposal for QGIS 3.0 after 2.14

2015-10-23 Thread Mathieu Pellerin

As Jürgen said, it's essentially the same. Yet... :)

I also think branching off 2.14 LTR now is slightly preferable. On a
psychological level, as the heavy development of new features has in the
past mostly taken place on the master branch, it'd make it clearer to devs
that the heavy feature development takes place there, and not on the 2.14
LTR branch.

Alternatively, we could branch off 2.14 LTR very early on,  like in a
month's time. That would give a preparatory period for new packages for
osgeo4w etc.
On 24 Oct 2015 06:24, "Nyall Dawson"  wrote:

> On 24 October 2015 at 07:26, Jürgen E.  wrote:
> > Hi,
> >
> > On Thu, 22. Oct 2015 at 08:47:26 +1100, Nyall Dawson wrote:
> >> Why not:
> >
> > - Branch off a qt5 branch from master now and start with porting
> > - continue as usual with master to produce 2.14
> > - branch 2.14 off and release it in four month
> > - then merge the qt5 branch into master (aka 2.15)
> > - finally branch 3.0 off and release it in eight month
> >
> > Essentially the same - but with the benefit for me that the nightlies and
> > packaging scripts can continue as is - and there are four more month to
> get the
> > dependencies in place (ie. Qt5, PyQt5, Python3 in OSGeo4W).
>
>
> Sorry Jürgen, when I was thinking more about this I realised I also
> should have also included you in the potential list of devs who
> could/should be funded by QGIS org to complete this work. I realise
> that this is a considerable task to get all the dependencies ready
> too! Apologies for that, and no slight was intended by not mentioning
> this earlier.
>
> My concern with this approach would be that we'd need to make sure
> it's known that major changes aren't acceptable for 2.14. If 2.14 was
> branched off from master early then this would be immediately evident,
> but if not then we need to make it well known to devs that the usual
> rules don't apply during the 2.14 cycle...
>
> Also in the ideal world we'd have the Qt5/python 3 test builds
> available asap so that people can start testing/porting plugins. But
> understandably this isn't an easy task.
>
> Otherwise, I'd also be happy with this approach.
>
> Nyall
>
>
>
>
>
> >
> >
> > 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
> >
> > ___
> > 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

1 2 3 >

1 - 100 of 273 matches

Mail list logo