Re: [Qgis-developer] GeoPackage: Vector layer save as... support
Hi
On 05 Jun 2015, at 05:53, Stefan Keller sfkel...@gmail.com wrote:
Hi,
Can somebody explain, if there is a problem when GeoPackage is being
added as writable driver (see also this feature request [1])?
I'm not sure but it seems that it's mainly inserting following snippet
to core/qgsvectorfilewriter.cpp, specifially
QgsVectorFileWriter::driverMetadata, after line 2272 [2]:
else if ( driverName.startsWith( GeoPackage ) )
{
longName = GeoPackage;
trLongName = QObject::tr( GeoPackage );
glob = *.gpkg;
ext = gpkg;
}
That would be a very good addition (assuming it works as expected)! Please make
a pull request with your proposed change.
Regards
Tim
Yours, S.
[1] https://hub.qgis.org/issues/12187
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
—
Tim Sutton
Visit http://kartoza.com http://kartoza.com/ to find out about open source:
* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee
Kartoza is a merger between Linfiniti and Afrispatial
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] GeoPackage: Vector layer save as... support
Hi,
Can somebody explain, if there is a problem when GeoPackage is being
added as writable driver (see also this feature request [1])?
I'm not sure but it seems that it's mainly inserting following snippet
to core/qgsvectorfilewriter.cpp, specifially
QgsVectorFileWriter::driverMetadata, after line 2272 [2]:
else if ( driverName.startsWith( GeoPackage ) )
{
longName = GeoPackage;
trLongName = QObject::tr( GeoPackage );
glob = *.gpkg;
ext = gpkg;
}
Yours, S.
[1] https://hub.qgis.org/issues/12187
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Fwd: Stats functions in QGIS
Il 04/06/2015 15:46, Niccolò Marchi ha scritto: if possible, I'm interested in understanding which kind of stats you are planning to include in core. Indeed, here I'm looking for someone who can help me to update SDA4PP plugin and, in case, avoid to duplicate the efforts. Is there also an idea about optimizing geo-statistics tools? like merging the two interpolation tools, or those connected to DEM analyses and geomorphological analyses within raster menu or adding new features? Hi Niccolò, I believe the general idea is to consolidate all analyses in the Processing plugin. All the best. -- Paolo Cavallini - www.faunalia.eu QGIS PostGIS courses: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Data-defined symbol size is not backwards compatible to 2.8.2
Hi Andreas, On 02/06/2015 16:07, Andreas Neumann wrote: I found another issue with the new scaling method: For multi level point symbols we need to be able to define the scaling on the symbol level. However, when adding it on the symbol level, the same rule applies both on the parent marker and on the individual symbol level. What if one part of the symbol should be scaled differently than the other? We really need this to work on the indivual symbol levels, not on the parent marker - or at least make it optional that it scales the parent as well. The marker size/rotation expression don' not actually exists, like the marker size/rotation. You can define different size/rotation expressions at the symbol level. Each symbol can have it's own variation. It's only in the particular case where the scale/rotation expressions of all symbols composing a marker preserve the aspect ratio of the symbol that it is recognized as a marker expression and displayed as such. As it works currently, I get a very different rendering in the map, compared to the preview in the legend ;-( Can you file a bug repport for this if it's not fixed by https://github.com/qgis/QGIS/pull/2111 ? Thanks, V. Andreas On 02.06.2015 15:53, Andreas Neumann wrote: Hi, Thanks for explaining. The assistant is very nice and a welcome improvement! Thanks for investing and working on it. I had an issue that I had a size defined in 2.8.x with scaling by area which, when opened in QGIS master displayed much bigger. Once I changed that in 2.8x to scale by diameter the symbol sizes are identical in master. So there seems to be an issue with converting scale by area symbol sizes from 2.8 over to QGIS master. Should I open a bug report or is one open already? Thanks, Andreas On 01.06.2015 20:05, Régis Haubourg wrote: Hi, here are the ideas behind this work, Nyall (code reviewer) and Vincent (author) could explain implentation choices more than me (funder): - get a more consistent UI with data defined widgets, and not advanced fields. That way, size is in one place only. - offer an assistant on size varying common expression. You will find it at the bottom of the drop down widget. It computes max value from field or expression and allows normal user to do what other GIS do. - That assistant offer legend previsualisation, and generates a legend for map and composer. I wish we have a legend for any expression... - During implementation, we understood that symbol size was a multiplication factor of size varying factor. That implied that it was impossible to predict final screen size. The new implementation clears that up. - offer a size varying graduated renderer, allowing the use of classifications algorithms - offer a legend for diagrams (yes!) IMHO, we need to read previous versions correctly, but that sometimes need to read all features to retroengineer a size expression. Vincent have planned to polish that now that feature freeze is made. All that needs testing of course. I'm not totally satisfied with the assistant shortcut, hidden inside the size varying widget. If someone have a better UI idea.. Hope that helps clarifying those changes. Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Data-defined-symbol-size-is-not-backwards-compatible-to-2-8-2-tp5208256p5208525.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
[Qgis-developer] isSelected expression operator - Request for comments
Hi at all, I just added a feature request: https://hub.qgis.org/issues/12879 regarding adding a isSelected (or something else) operator in the expression editor. I ask the community to comment this request to find the best solution. the idea in the request is here reproduced: Many times, I received the request to have a smart styling for selected features. The main reason is to have a smart visualization of selected feature is in case of: * they are too crowded * if would be necessary to have a special style for selected feature (e.g. highlight the selected and blur the others) In this moment styling of selected feature is: 1) limited to color and transparency setting 2) can be styled adding custom function that retrieve if the feature is selected the solution 1, obviously, does not satisfy requirement the solution 2 has two drawback: A) the custom function have to know the layer id (blocked in the expression) to get selected features and check if the current feature is selected or not B) the loop described in A is really time consuming with a large amount of features during Nodebo, Andreas and Nyall confirmed that there is no other way to style selected features How to solve technically: I asked to Martin if were possible to add some kind of contextual operator that allow the feature knows at what layer it belongs to (and something more)... Martin said that, going up to the layer data (not thread safe), could introduce problems during MT rendering. He points out that is selected state of the feature is already available to the feature, and it should only be published. He suggested to ask to Nyall to integrate this feature because he is was working on styling in that moment (for 2.10) Nyall pointed out that this feature can be added after 2.10 because we were too near feature freeze, so it could be added for 2.12 and 2.11 dev version for testing. this is the state of the art. regarding a sophisticated way to style selected features regards, Luigi Pirelli ** * LinkedIn: https://www.linkedin.com/in/luigipirelli * Elance: https://www.elance.com/s/edit/luigipirelli/ * GitHub: https://github.com/luipir * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli * Mastering QGIS: https://www.packtpub.com/application-development/mastering-qgis ** ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QWC Highlight feature not working from urlrewrite search
hello, I am trying to obtain highlighting by urlrewrite search and configured GlobalOptions.js in url rewrite search part as follows: highlightFeature: true, highlightLabel: 'my column', //selectionLayer: 'mylayer', selectionZoom: 0, doZoomToExtent: true wms request turns out as follows: http://qgis-web-client.localhost/wms/prg?LAYERS=terreni%2Cfabbricati%2CPIANI%20PARTICOLAREGGIATI%2CCONFINE%2C390070%2C390110%2C390120OPACITIES=255,255,255,255,255,255,255FORMAT=image%2FpngTRANSPARENT=FALSEDPI=96VERSION=1.3.0EXCEPTIONS=INIMAGESERVICE=WMSREQUEST=GetMapSTYLES=CRS=EPSG%3A23033HIGHLIGHT_GEOM=MULTIPOLYGON(((382338.19%204615777.86%2C382339.09%204615777.84%2C382347.99%204615777.52%2C382353.89%204615742.68%2C382359.55%204615709.82%2C382355.4%204615709.14%2C382349.86%204615708.39%2C382338.19%204615777.86)))HIGHLIGHT_SYMBOL=%3CStyledLayerDescriptor%3E%3CUserStyle%3E%3CName%3EHighlight%3C%2FName%3E%3CFeatureTypeStyle%3E%3CRule%3E%3CName%3ESymbol%3C%2FName%3E%3CPolygonSymbolizer%3E%3CFill%3E%3CSvgParameter%20name%3D%22fill%22%3E%23FF%3C%2FSvgParameter%3E%3CSvgParameter%20name%3D%22fill-opacity%22%3E0.3%3C%2FSvgParameter%3E%3C%2FFill%3E%3CStroke%3E%3CSvgParameter%20name%3D%22stroke%22%3E%23FF%3C%2FSvgParameter%3E%3CSvgParameter%20name%3D%22stroke-width%22%3E2%3 C%2FSvgParameter%3E%3C%2FStroke%3E%3C%2FPolygonSymbolizer%3E%3C%2FRule%3E%3C%2FFeatureTypeStyle%3E%3C%2FUserStyle%3E%3C%2FStyledLayerDescriptor%3EHIGHLIGHT_LABELSTRING=235HIGHLIGHT_LABELSIZE=12HIGHLIGHT_LABELCOLOR=%23FFHIGHLIGHT_LABELBUFFERCOLOR=%23FFHIGHLIGHT_LABELBUFFERSIZE=1BBOX=382226.38939542,4615708.39,382471.35060458,4615777.86WIDTH=1079HEIGHT=306 but image doesn't show the polygon highlighted... any clue? thank you -- Dott. Agr. Giuseppe De Marco RSPP settore ATECO 1 Cell./Mobile: +39 3935041115 Fax.: +39 07751850973 PEC: giuseppe.de_ma...@epap.conafpec.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Questions regarding new geometry engine
Hi Nyall Firstly, I *think* that there's an issue with the inheritance of some of the classes. Specifically QgsMultiLineStringV2 and QgsMultiPolygonV2. Currently both of these derive from QgsGeometryCollectionV2, but I think they should derive from QgsMultiCurveV2 and QgsMultiSurfaceV2. This would seem logical to me since QgsLineStringV2 derives from QgsCurveV2 and QgsPolygonV2 derives from QgsCurvePolygonV2. It also would match with how I understand the OGC simple features access specification describes (see 6.1.8.1 - MultiCurve should be non-instantiable, 6.1.9 multiline is a multicurve, and 6.1.13.1 and 6.1.14 for the corresponding multisurface/multipolygon types). What's your thoughts? Yes, in the ISO and OGC models, MultiPolygon inherits from MultiSurface and MultiLineString from MultiCurve. The implementation of the geometryV2 classes differs a bit compared to the model, because most methods are implemented on GeometryCollection level (e.g. in the ISO model, length() and area() are not in the collection class). So there is little practical relevance if QgsMultiPolygon is derived from MultiSurface (and overwrites all its methods) or from GeometryCollection. One exception is the segmentize() method. By default (straight geometries), this is equal to a normal clone(). As MultiSurface needs to overwrite it (may contain curved geometries), MultiPolygon would need to overwrite it again with the default behaviour if it was derived from MultiSurface. MultiCurve should be non-instantiable In the OGC model, it is non-instantiable. In the ISO model (which is relevant here), it is left to the implementation if it is instantiable or not. Regards, Marco On 03.06.2015 09:05, Marco Hugentobler wrote: Hi Nyall Thanks for your input. I'll back in the office tomorrow and can give you more detailed answers to the technical questions. To the technical issues: Yes, I plan to fix them in the next time, but definitely before release ( fixed #12857 and started to look at #12836 already). I think you should focus on other bugs, otherwise we risk to do the same work twice. Regards, Marco Am 02.06.2015 um 23:34 schrieb Nyall Dawson: Hi Marco (also cc-ing dev list) I've been looking over the new geometry engine and it's really nice stuff. It's fantastic to have this in QGIS and it's a huge improvement over the old geometry class. Thank you! I have a couple of questions regarding this which I'm hoping you can clarify for me. Firstly, I *think* that there's an issue with the inheritance of some of the classes. Specifically QgsMultiLineStringV2 and QgsMultiPolygonV2. Currently both of these derive from QgsGeometryCollectionV2, but I think they should derive from QgsMultiCurveV2 and QgsMultiSurfaceV2. This would seem logical to me since QgsLineStringV2 derives from QgsCurveV2 and QgsPolygonV2 derives from QgsCurvePolygonV2. It also would match with how I understand the OGC simple features access specification describes (see 6.1.8.1 - MultiCurve should be non-instantiable, 6.1.9 multiline is a multicurve, and 6.1.13.1 and 6.1.14 for the corresponding multisurface/multipolygon types). What's your thoughts? Secondly, are you able to share your plans for bug fixing leading up to 2.10? There's a number of serious regressions following this work, and I'm wondering if I should be focusing on these during the sponsored bug fixing or whether you plan to tackle them before release? The biggest issues I see are: - #12836 : layers fail to render - unfiled: I get a lot of unknown exceptions when working with geometries. I can reproduce this consistently by trying to use the reshape tool on a polygon, or by rotating a map within the canvas or a composer. - #12843: simplify tool broken - i noticed there's also a number of stubbed methods in geometry with todo comments (eg QgsGeometry::buffer ). If you can share your plans then I can plan my work accordingly. Again, thanks again for this fantastic work! Nyall -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Data-defined symbol size is not backwards compatible to 2.8.2
Yep, I have it too. Will file a ticket. Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Data-defined-symbol-size-is-not-backwards-compatible-to-2-8-2-tp5208256p5209109.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] backported fixes
On 06/04/2015 10:43 AM, Sandro Santilli wrote:
On Wed, Jun 03, 2015 at 11:09:45PM +0200, Matthias Kuhn wrote:
On 06/03/2015 10:11 PM, Sandro Santilli wrote:
On Wed, Jun 03, 2015 at 09:43:31PM +0200, Matthias Kuhn wrote:
The ticket system sounds like a good place to manage this information.
In comparison to the commit in master the ticket can be altered later
on. And is referenced from the commit in master if that's the starting
point of the search.
Further it has a nice box showing commits including messages which
relate to that ticket. So if the commit message says backported to
2.8.3 all the information is there. And it's a minimal effort for the
developer.
What do you think?
The log of the backporting commit, you mean ?
Isn't the information possibly derivable from the branch name ?
Not specifying anything would be the minimum possible effort for
developer :)
`git branch --contains {sha}` should return release-2_8 for a backported
commit.
Only if the commit was merged. Does not work with cherry-picked or otherwise
rebased commits (very frequent, and personally I prefer those).
The master's commit hash not. But at the time that one is pushed to the
repository and hence evaluated by the plugin hook we don't know if it's
backported.
However, if you leave the Fixes # message in place it will
generate a new hash when backported (cherry-picked), which will be
linked in the ticket as well and return release-2_8 when evaluated by
the tracker.
The downside of this approach is that we do know that it's fixed in
release-2_8 but not in which point release. So if I fix something today
it says fixed in 2.8 but to be precise it should say fixed in 2.8.3.
But I have no idea how this plugin works and who maintains it :)
Whatever the plugin does, it necessarely fetch commits of all branches
(or it would not be able to find out about cherry-picked commits in the
stable branch).
Right now the user should have all the info, as long as the commit log
references the ticket. And the redmine plugin would also have them all,
so there's no need to ask developers to do anything more than referencing
the ticket (thus the importance, IMHO, to _require_ tickets exist for any
commits into the stable branch).
--strk;
We could also go the other way and take the release-2_8 branch history
as canonical source for fixes/Changelog.
That would be
* 100% accurate
* Contain information about the fix
* Have a link to the ticket if one exists.
For me the two things are different:
* The changelog (with fixes that *may* have a ticket attached)
* The ticket that should contain information about on which branches it
has been resolved
Matthias
signature.asc
Description: OpenPGP digital signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] backported fixes
On Wed, Jun 03, 2015 at 11:09:45PM +0200, Matthias Kuhn wrote:
On 06/03/2015 10:11 PM, Sandro Santilli wrote:
On Wed, Jun 03, 2015 at 09:43:31PM +0200, Matthias Kuhn wrote:
The ticket system sounds like a good place to manage this information.
In comparison to the commit in master the ticket can be altered later
on. And is referenced from the commit in master if that's the starting
point of the search.
Further it has a nice box showing commits including messages which
relate to that ticket. So if the commit message says backported to
2.8.3 all the information is there. And it's a minimal effort for the
developer.
What do you think?
The log of the backporting commit, you mean ?
Isn't the information possibly derivable from the branch name ?
Not specifying anything would be the minimum possible effort for
developer :)
`git branch --contains {sha}` should return release-2_8 for a backported
commit.
Only if the commit was merged. Does not work with cherry-picked or otherwise
rebased commits (very frequent, and personally I prefer those).
But I have no idea how this plugin works and who maintains it :)
Whatever the plugin does, it necessarely fetch commits of all branches
(or it would not be able to find out about cherry-picked commits in the
stable branch).
Right now the user should have all the info, as long as the commit log
references the ticket. And the redmine plugin would also have them all,
so there's no need to ask developers to do anything more than referencing
the ticket (thus the importance, IMHO, to _require_ tickets exist for any
commits into the stable branch).
--strk;
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Data-defined symbol size is not backwards compatible to 2.8.2
Hi, I noticed that my problem with the invalid scaling only occurs if I use layers from old QGIS versions (2.8). If I create a new layer with new symbology, this works fine. So, definitely a migration issue from old project versions, esp. if scale by area was active. Thanks, Andreas On 02.06.2015 16:07, Andreas Neumann wrote: I found another issue with the new scaling method: For multi level point symbols we need to be able to define the scaling on the symbol level. However, when adding it on the symbol level, the same rule applies both on the parent marker and on the individual symbol level. What if one part of the symbol should be scaled differently than the other? We really need this to work on the indivual symbol levels, not on the parent marker - or at least make it optional that it scales the parent as well. As it works currently, I get a very different rendering in the map, compared to the preview in the legend ;-( Andreas On 02.06.2015 15:53, Andreas Neumann wrote: Hi, Thanks for explaining. The assistant is very nice and a welcome improvement! Thanks for investing and working on it. I had an issue that I had a size defined in 2.8.x with scaling by area which, when opened in QGIS master displayed much bigger. Once I changed that in 2.8x to scale by diameter the symbol sizes are identical in master. So there seems to be an issue with converting scale by area symbol sizes from 2.8 over to QGIS master. Should I open a bug report or is one open already? Thanks, Andreas On 01.06.2015 20:05, Régis Haubourg wrote: Hi, here are the ideas behind this work, Nyall (code reviewer) and Vincent (author) could explain implentation choices more than me (funder): - get a more consistent UI with data defined widgets, and not advanced fields. That way, size is in one place only. - offer an assistant on size varying common expression. You will find it at the bottom of the drop down widget. It computes max value from field or expression and allows normal user to do what other GIS do. - That assistant offer legend previsualisation, and generates a legend for map and composer. I wish we have a legend for any expression... - During implementation, we understood that symbol size was a multiplication factor of size varying factor. That implied that it was impossible to predict final screen size. The new implementation clears that up. - offer a size varying graduated renderer, allowing the use of classifications algorithms - offer a legend for diagrams (yes!) IMHO, we need to read previous versions correctly, but that sometimes need to read all features to retroengineer a size expression. Vincent have planned to polish that now that feature freeze is made. All that needs testing of course. I'm not totally satisfied with the assistant shortcut, hidden inside the size varying widget. If someone have a better UI idea.. Hope that helps clarifying those changes. Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Data-defined-symbol-size-is-not-backwards-compatible-to-2-8-2-tp5208256p5208525.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] backported fixes
On Thu, Jun 04, 2015 at 11:06:31AM +0200, Matthias Kuhn wrote: However, if you leave the Fixes # message in place it will generate a new hash when backported (cherry-picked), which will be linked in the ticket as well and return release-2_8 when evaluated by the tracker. The downside of this approach is that we do know that it's fixed in release-2_8 but not in which point release. So if I fix something today it says fixed in 2.8 but to be precise it should say fixed in 2.8.3. True, we don't know about the future (who does?). What we can know, though, is which release came out from that branch last: $ git describe final-2_8_2-9-gea447e7 So, 2.8.2 was the latest, and we (a plugin?) may assume 2.8.3 will be the next. I don't like the version in the commit log because if you further cherry-pick that commit in another branch it brings with it the target version info which doesn't really belong to the change. In postgis I often cherry-pick commits from svn-trunk to svn-21 to svn-20 ... We could also go the other way and take the release-2_8 branch history as canonical source for fixes/Changelog. That's surely the most detailed and correct info. For me the two things are different: * The changelog (with fixes that *may* have a ticket attached) * The ticket that should contain information about on which branches it has been resolved Agreed. So back to Paolo's request: On Wed, Jun 03, 2015 at 06:29:36PM +0200, Paolo Cavallini wrote: My aim was to give normal users an easy way of discovering whether they can expect a fix in the next LTR release, or if they have to head for next release. I think normal user refer to a fix by looking at a ticket, so this whole discussion should be about making retriving the info from the ticket easier. For sure the first step is _ensuring_ that any fix has a ticket. Then, the ticket should allow containing information about versions in which the fix was committed. Either using the existing Target Version field (which would need to be turned into an array or represent the Minimum Target Version), or adding a new field. --strk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] backported fixes
On 06/04/2015 11:26 AM, Sandro Santilli wrote: On Thu, Jun 04, 2015 at 11:06:31AM +0200, Matthias Kuhn wrote: However, if you leave the Fixes # message in place it will generate a new hash when backported (cherry-picked), which will be linked in the ticket as well and return release-2_8 when evaluated by the tracker. The downside of this approach is that we do know that it's fixed in release-2_8 but not in which point release. So if I fix something today it says fixed in 2.8 but to be precise it should say fixed in 2.8.3. True, we don't know about the future (who does?). What we can know, though, is which release came out from that branch last: $ git describe final-2_8_2-9-gea447e7 So, 2.8.2 was the latest, and we (a plugin?) may assume 2.8.3 will be the next. I don't like the version in the commit log because if you further cherry-pick that commit in another branch it brings with it the target version info which doesn't really belong to the change. In postgis I often cherry-pick commits from svn-trunk to svn-21 to svn-20 ... I did an example: http://hub.qgis.org/issues/12867 Agreed. So back to Paolo's request: On Wed, Jun 03, 2015 at 06:29:36PM +0200, Paolo Cavallini wrote: My aim was to give normal users an easy way of discovering whether they can expect a fix in the next LTR release, or if they have to head for next release. I think normal user refer to a fix by looking at a ticket, so this whole discussion should be about making retriving the info from the ticket easier. For sure the first step is _ensuring_ that any fix has a ticket. Then, the ticket should allow containing information about versions in which the fix was committed. Either using the existing Target Version field (which would need to be turned into an array or represent the Minimum Target Version), or adding a new field. --strk; -1 I don't open tickets for bugs which I fixed and found no ticket. I am too lazy. I'd rather have a solution that merges the commit log and the ticket information into a single, good-looking changelog. Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGis 2.8.2 download build for windows
Hi With what version of MS Visual Studio is QGis 2.8.2 build , that is available for download? Regards Theuns Heydenrych ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Data-defined symbol size is not backwards compatible to 2.8.2
Issue created here http://hub.qgis.org/issues/12876 http://hub.qgis.org/issues/12876 with sample data and project files for testing purposes. Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Data-defined-symbol-size-is-not-backwards-compatible-to-2-8-2-tp5208256p5209138.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] Fwd: Stats functions in QGIS
hi Alexander and Nyall, hi all, if possible, I'm interested in understanding which kind of stats you are planning to include in core. Indeed, here I'm looking for someone who can help me to update SDA4PP plugin and, in case, avoid to duplicate the efforts. Is there also an idea about optimizing geo-statistics tools? like merging the two interpolation tools, or those connected to DEM analyses and geomorphological analyses within raster menu or adding new features? Thank you in advance. All the best, Niccolò ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
