Re: [Qgis-developer] QEP about Multimap support for QGIS
Hi Alvaro, I'd also like to see that in QGis 3. I'm developing a plugin that needs this functionality to visualize/edit features in the vertical "plane" an it looks/behave pretty much the same (except for a separate dock widget for the layer tree of the second and third map). The plugin is going to be used in three different projects, so lots of use cases for this feature IMO. +1 for a QEP Vincent. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Building plugin for Print Composer
Le 08/08/2015 11:19, Nyall Dawson a écrit : On 7 Aug 2015 6:58 pm, Vincent Mora vincent.m...@oslandia.com mailto:vincent.m...@oslandia.com wrote: Hi all, I need to add graphs generated by a plugin to compositions. I'm considering to develop a PluginComposerItem in the same spirit as PluginLayers, adding/removing a button in the toolbar when the plugin is registered/removed. Hi Nyall, Just a warning that similar work is already underway - adding a composer item type registry so that plugins can register their own custom item types. Thanks for the warning. Are you referring to QEP#9 or to something else ? What is the status of the work that is underway ? What is the planned time-frame ? Is there a branch somewhere that I can base my work on / contribute to ? We need a composer plugin item for a customer project with a deadline in November. We have planned a few days of dev to contribute that and we'd rather put those efforts in a long term solution. It's an extensive work though, because composer has a lot of hard coded handling of all the existing item types (checkout all the item specific methods in QgsComposition/QgsComposerView). That's why this work is tied up with the layouts/reporting framework refactor. I've seen that, and I'm not sure I see why it prevents the introduction of a plugin item (+registry) that would be used as a base class for python objects to draw in a frame that is part of a composition. V. Nyall Is that what was needed in your cases, or was a more general approach required (like the qgis plugin mechanism, being able to access the interface) ? V. Le 22/06/2015 18:05, G. Allegri a écrit : The suggestion from John is exactly what we did too. And we also built a chart composer... It would be great to have the means to know what other teams are working to. It would save a lor of time and money and, probably, get better software from a shared effort ;) giovanni Il 22/giu/2015 19:31, John Gitau gka...@gmail.com mailto:gka...@gmail.com ha scritto: Hi Jakob, A workaround would be to have a plugin that creates a new composer view object: custom_composer = self.iface.createNewComposer(My Composer) Then get a reference to the main window in the composer view: main_window = custom_composer.composerWindow() Then you can either add a new toolbar (and required actions) or append an action to the main toolbar. Have a look at the ComposerWrapper class for something similar we implemented for designing charts in the composer: https://gist.github.com/gkahiu/06a43a589f9441736397 Hope this is helpful. Cheers, John On Mon, Jun 22, 2015 at 2:07 PM, G. Allegri gioha...@gmail.com mailto:gioha...@gmail.com wrote: You can act on it but you can't custom gui widgets to the Composer interface. I cannot check the code right know. I listen to a specific (existing) composition opening but if I remember correctly you can watch the Composer opening too. Il 22/giu/2015 17:19, Jakob Lanstorp jlanst...@gmail.com mailto:jlanst...@gmail.com ha scritto: Hi Giovanni, thanks for the update. Another solution would be to catch the event when a user starts an existing print composer. Cannot in doc for the pyqgis API find anything for this. Anyone who know is one can listens for a print composer to startup by the user and act on it. - Jakob Lanstorp -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Building-plugin-for-Print-Composer-tp5212187p5212221.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto:Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto: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] Bug in symbol size data-defined override
On 08/06/2015 15:46, Andreas Neumann wrote: I agree - a rename to size assistant or sizing assistant would be useful. In my opinion, the new solution is not harder to find than the old solution - which was pretty hard to find and even more disconnected to the actual symbol than the new solution. I agree, it is still a bit hidden, but it belongs to the expression - that's why the current solution isn't bad. I made a PR on QGIS-Documentation yesterday to show the assistant and explain how to access it. Hope that helps. The reason it's a bit hidden is that the DD-button is now everywhere in the Style interface, so the user will get used to the concept, and data-defined for the Size field seemed quite obvious to me. The user can also use the 'Graduated by size' to have varying size symbols, there it's more visible. The idea behind the generic assistant name in the DD-menu is that DD-button are related to a field in the gui (here Size, so Size-assistant) and we may want other DD-assitants in the future (setting-up a color expression, font expression, or a marker shape expression would benefit from that). That beeing said, we can add an icon beside the DD-button to launch the assistant (e.g. magic wand with the appropriate tooltip, or circles with increasing diameters). Andreas On 08.06.2015 15:26, Régis Haubourg wrote: Alexandre Neto wrote Not sure if data-defined override for Symbol Size should even be connected to the size-scale method, since in this case it should simply override the symbol size value. In master UI refactoring, area or diameter selector disappeared, and we now have an assistant for that. Expressions directly typed refer to size (diameter) and are no more influence by this modifier. The scale method will gently disappear from the code, the default is now ScaleDiameter and cannot be changed. The expression for the size is not composed anymore with a sqrt. The only thing that may be misleading is that features with size expressions that evaluate to NULL will be drawn with the default size (due to fixing symbols with DD-fields not being drawn in preview and legend). If it's an unwanted behaviour, then using coalesce(size_expression, 0) for the size expression will fix that easily enough. Vincent. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Bug in symbol size data-defined override
On 05/06/2015 16:46, Alexandre Neto wrote: I'm still at 2.8.1 (I have no administrator permissions on this machine) Using data-defined override on a marker symbol does not seem to be working as it should. Comparing a layer where the marker size is set to 50 and another where we use 50 as an expression in data-defined override, they do not look the same, and I guess they should. Can anyone can confirm this, whether in 2.8 or in master? Is the size-scale method set to Diameter ? If it's not the case (i.e. scale method area), then a square root is applied if the size is defined by an expression. Cheers, V. Thanks, 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
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
Re: [Qgis-developer] Data-defined buttons for en masse size and rotation
Hi Regis, Here is a PR for one element of this feature https://github.com/qgis/QGIS/pull/1853 It's only the ground work, so you have no GUI to help you setup the expression for the size rotation, but you can use scale_exp and scale_linear to define your value range and the corresponding symbol size range. It works for line width too. The legend's symbol does dissapear though, but I believe it's due to the data defined size. I'll work on the legend to have something meaningful when using size expressions. If you can recompile the branch and give feedback, it will be welcome. Thanks, V. On 21/01/2015 14:46, Régis Haubourg wrote: Hi Vincent, good to know, thanks Régis Vincent Mora wrote On 20/01/2015 22:51, Anita Graser wrote: Hi Régis, Thanks a lot for all the details! On Mon, Jan 19, 2015 at 9:30 PM, Régis Haubourg lt; regis.haubourg@ gt; wrote: - when using the GUI assistant or the graduated classification, we will enable a legend for mapcanvas and composer 's legend. That legend will be of this type [0] This will certainly be a nice addition. Will it work with all kinds of point markers? Or only simple markers? If my design works as expected, it should even work for lines width. [0] http://s14.postimage.org/3jr9kcmgh/muesure.png Best wishes, Anita ___ Qgis-developer mailing list Qgis-developer@.osgeo http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@.osgeo http://lists.osgeo.org/mailman/listinfo/qgis-developer -- View this message in context: http://osgeo-org.1560.x6.nabble.com/Data-defined-buttons-for-en-masse-size-and-rotation-tp5181954p5182855.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] Data-defined buttons for en masse size and rotation
On 20/01/2015 22:51, Anita Graser wrote: Hi Régis, Thanks a lot for all the details! On Mon, Jan 19, 2015 at 9:30 PM, Régis Haubourg regis.haubo...@eau-adour-garonne.fr wrote: - when using the GUI assistant or the graduated classification, we will enable a legend for mapcanvas and composer 's legend. That legend will be of this type [0] This will certainly be a nice addition. Will it work with all kinds of point markers? Or only simple markers? If my design works as expected, it should even work for lines width. [0] http://s14.postimage.org/3jr9kcmgh/muesure.png Best wishes, Anita ___ 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] Data-defined buttons for en masse size and rotation
On 19/01/2015 21:04, Anita Graser wrote: Hi Vincent, On Mon, Jan 19, 2015 at 11:20 AM, Vincent Mora vincent.m...@oslandia.com wrote: The changes are illustrated in the attached files. Thanks a lot for the mockups! I don't have the Continuous size assistant right now, but it will be a dialog with a selection of the scale function (Flannery, Area, Linear) with a preview (a legend) on the side. That sounds like a good idea. You mentioned that Flannery will be the recommended function. What's your reasoning behind that? Concerning the area scale function, I'm always wondering if it assumes square or circle area. The name Continuous size assistant seems a little difficult to understand. I probably wouldn't know what to expect of such a tool without giving it a test run. Maybe the context menu entry could simply be Configure data-defined size. I'll post a mockup as soon as I get out of the ground work (adding en masse expression for size and rotation). The dialog will propose some buttons to auto-set the function parameters (minValue and maxValue) by analyzing the data. Will it be possible to select different percentiles? I don't understand what you mean by different percentiles. Can you explain it a bit to me so I can put it in :) en masse Concerning the term en masse itself, I also wonder if it's the most easily to understand term. Maybe we could be talking about the master size and master rotation but probably some native speaker could suggest a clear and simple name for this feature. I looked it up an it appears to be a french expression that is used in english. But as a french native I'm certainly not the best judge for that. A native speaker advice will be welcome. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Data-defined buttons for en masse size and rotation
Hi all, As an attempt to Improve GUI consistency UX for data-defined style (#9881) I'm planing to add a data-defined button[1] to the en masse size and rotation changing fields [2]. This could *replace* the scaling factor, scaling method and rotation available in the 'Advanced' menu. After that a graphical assistant (accessible from the data-defined button) will be developed to help the user define the scale-function (preview the various symbol sizes). I'd like to have your impression on that change, especially on the *replace*, and comment on the plan below. Thanks, V. [1] QgsDataDefinedButton: the button already in the Label properties for data-defined properties. [2] What I call the en masse size and rotation fields are the fields Size and Rotation displayed at the Marker level for simple symbol and the popup for size in the graduated, categorized and rule-based symbologies (I plan to add rotation there too). Data defined property buttons will be added to the en masse change fields for single symbol, graduated, categorized and rule-based symbologies. This is especially useful to be able to use scaling functions to define the size of the scaled symbols: - Flannery (recommanded): scale_exp( variable, minValue, maxValue, minSize, maxSize, 0.57 ) - Area : scale_exp( variable, minValue, maxValue, minSize, maxSize, 0.5 ) - Linear : scale_linear( variable, minValue, maxValue, minSize, maxSize ) Using an expression at the en masse level will set expressions for all symbols composing the marker. The behavior will be the same as with size and rotation changing: the expression will be the one of the last symbol in the marker, others markers will be scaled/rotated relative to the last marker. For the size, if the scalling method is area, the scale factor will be put inside the sqrt(). If size/rotation are defined by expressions/fields, those definitions will be lost. Definition: en masse expression pattern: - Size with scale method Area - `sqrt( expression )` for the last symbol of the marker - `sqrt( symbolSize/lastSymbolOfTheMarkerSize * expression )` for other symbols - Size with scale method Linear - `expression` for the last symbol of the marker - `(symbolSize/lastSymbolOfTheMarkerSize) * expression` for other symbols - Rotation - `expression` for the last symbol of the marker, - `expression + (symbolRotation - lastSymbolOfTheMarkerRotation)` for other symbols Disabling en masse will disable all size/rotation expressions for markers composing the symbol if they match the en masse expressions pattern. Note that the data-defined expression at this en masse level will only be set (yellow highlight) if the size/scale expression of all the symbols composing the marker match the en masse expression pattern. To avoid functionality duplication the scale and rotation could be removed from the 'Advanced menu'. This will simplify the symbology classes. To ensure backward compatibilities of old project files, the following scaling/rotation expression can be defined using old scale/rotation parameters to ensure the same rendered map: - For size - newSymbolSizeExpression = sqrt( oldScaleExpression * oldSymbolSizeOrSizeExpression ) or - newSymbolSizeExpression = oldScaleExpression * oldSymbolSizeOrSizeExpression - For rotation: - newSymbolRotationExpression = oldRotationExpression + oldSymbolRotationOrRotationExpression As a result, if expressions are used for the symbol size/rotation in addition to scalling/rotation of the marker, the replaced expressions (with scale/rotation included) may not match the en masse expression pattern and the data defined button will not be highlighted. This seems to be a minor and rare inconvenience since it will happen for project with scaled/rotated markers composed of multiple symbols with different data-defined size/rotation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Symbology api
Hi Martin, On 03/10/2014 21:10, Martin Dobias wrote: Hi Vincent On Fri, Oct 3, 2014 at 1:10 PM, Vincent Moravincent.m...@oslandia.com wrote: We can use expressions to make the single symbol layer behave: - graduated : properties are continuous functions of attributes, - categorized or rule based : properties are discrete function of attributes The user interfaces for categorized, graduated, rule-based could remain the same, it's just that it would generate the expressions for the single symbol instead of configuring as specific class. Several categories could be defined to affect various parameters (color and size are the first use case). Can you tell me if the idea is sound ? If I understand correctly, you propose to use single symbol renderer with expressions (for color and for size) in places where we currently use graduated/categorized renderers. Is that correct? Yes, it is correct. Although the marker, which can be composed of several simple symbols, seems to be a better base. If it is, how would it handle the case where symbols of individual classes are completely different? (not just varying in size/color) A discrete function can handle the shape (it is already a parameter that can be defined by an expression). A little complexity comes with composed symbols (markers): in a given layer, different markers (from different classes) may be composed of a different number of symbols, but if we handle the 'null' case for the shape, then the number of symbols for a marker is only a max, and markers with less symbols will be handled just fine. It would be also good to check the impact on the rendering performance - maybe if more than just few classes are used, the evaluation with expressions could slow things down significantly. (the expression engine could enjoy some performance improvements). The performance issue is definitely a concern. I can think of some strategies to avoid a systematic evaluation of expressions for all features, but they imply some sort of classification, so I'm not sure it's a net gain on the code complexity front. So I would prefer keeping the approach simple (i.e. evaluate expressions for all features) and profile the code to see if expression evaluation can be improved. I've made a preliminary test with graduated color (5 classes) one the one hand and continuous color defined by expression on the other hand. For 250k points, this gives roughly a factor 2 loss for rendering time (5sec for graduated, 10sec for expressions). I think this is rather encouraging. Do you think this 2x loss is a killer for this approach (considering the improvements that can be made to expression evaluation) ? Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Symbology api
Hi all, While thinking about the interface of categorized and graduated symbology with varying size (instead of color) I had an idea to reduce the code complexity in src/core/symbology-ng (~15% less code). Since it changes the symbology API, I'd like your input on that: At the moment we deal with categorized, graduated, rule-based and single symbol with different classes. At the same time the single symbol allows to use expressions for all symbol properties. We can use expressions to make the single symbol layer behave: - graduated : properties are continuous functions of attributes, - categorized or rule based : properties are discrete function of attributes The user interfaces for categorized, graduated, rule-based could remain the same, it's just that it would generate the expressions for the single symbol instead of configuring as specific class. Several categories could be defined to affect various parameters (color and size are the first use case). Can you tell me if the idea is sound ? V. PS: (implementation detail) Data defined properties are treated as a special case in the symbology classes. Since a constant is a valid expression, why not avoid this special treatment and have properties being always expressions in the symbology classes ? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Fwd: Style widget ergonomics
Hi all, It would be nice to have the same interface for data defined properties in the 'Style' widget and in the 'Labels' widget. The 'Labels' widget has a small icon on the side of each property that allows to specify a field or expression. The 'Style' widget has the 'Advanced' combobox and the 'Symbol selector' has the big button 'Data defined properties...' The 'Labels' small icon is my preferred option. It could be added beside the symbol selector properties. This would replace both the 'Advanced' comboboxes and 'Data defined properties...' button. A step further would be to link this icon with the text/button/combo of the property it's related to. If the text/button/combo is big enough, the field/expression could take its place (easier to see than overing over the yellowed icon). If the text/button/combo is too small, it could be grayed out. I would be happy to have your feedback. V. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] WFS provider without cache broken
On 26/05/2014 18:07, Martin Dobias wrote: Hi Vincent On Mon, May 26, 2014 at 9:57 PM, Vincent Mora vincent.m...@oslandia.com wrote: Hi, The WFS data provider seems broken when not-cached. As far I can see QgsWFSProvider::getFeatures( const QgsFeatureRequest request ) is never called, and it's where the special case of uri with BBOX (i.e. non-cached) is dealt with. True. I guess I must have broken that while implementing support for MTR :-/ The feature request from the vector layer goes through QgsWFSFeatureSource where cached features are stored. I think that a big part of the code in QgsWFSProvider should go in QgsWFSFeatureSource in order to cleanly fix the problem. Can I have a second opinion on that before working on in this direction ? Not sure what do you mean by 'big part of the code' but I guess you are referring to the routines that download WFS data and transform them to a map of features. Yes. Currently the 'feature source' classes in all providers are merely meant as a pure storage of information needed for iterating, with no logic inside, and they are typically deleted when iterators are closed. Because of that I would suggest moving any logic regarding data retrieval to wfs feature iterator implementation. Agreed, that precises what I had in mind. Thanks. I'll work from that and propose a design. Cheers, V. In any case that code should not be in provider class. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] WFS provider without cache broken
Hi, The WFS data provider seems broken when not-cached. As far I can see QgsWFSProvider::getFeatures( const QgsFeatureRequest request ) is never called, and it's where the special case of uri with BBOX (i.e. non-cached) is dealt with. The feature request from the vector layer goes through QgsWFSFeatureSource where cached features are stored. I think that a big part of the code in QgsWFSProvider should go in QgsWFSFeatureSource in order to cleanly fix the problem. Can I have a second opinion on that before working on in this direction ? Thanks, VM. PS: I updated https://hub.qgis.org/issues/9444 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Error installing nightly debs
Same error with yesterday nigthly on ubuntu 14.04. A quick temp fix is to uninstall python-qgis, finish the upgrade and reinstall python-qgis. On 19/05/2014 17:39, Paolo Cavallini wrote: Il 19/05/2014 08:16, Paolo Cavallini ha scritto: Hi all. Installing qgis-nightly from deb http://qgis.org/debian-nightly sid main results in an error: I still get an error after https://github.com/qgis/QGIS/commit/74392f7823536c5fa5b6b57b912ec698ff0b6839 Preparing to unpack .../libqgispython2.3.0_2.3.0+git20140519+2ff79d3~unstable1_amd64.deb ... Unpacking libqgispython2.3.0 (2.3.0+git20140519+2ff79d3~unstable1) ... Selecting previously unselected package python-qgis-common. Preparing to unpack .../python-qgis-common_2.3.0+git20140519+2ff79d3~unstable1_all.deb ... Unpacking python-qgis-common (2.3.0+git20140519+2ff79d3~unstable1) ... Preparing to unpack .../python-qgis_2.3.0+git20140519+2ff79d3~unstable1_amd64.deb ... Unpacking python-qgis (2.3.0+git20140519+2ff79d3~unstable1) ... dpkg: error processing archive /var/cache/apt/archives/python-qgis_2.3.0+git20140519+2ff79d3~unstable1_amd64.deb (--unpack): trying to overwrite '/usr/lib/libqgispython.so.2.3.0', which is also in package libqgispython2.3.0 2.3.0+git20140519+2ff79d3~unstable1 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/python-qgis_2.3.0+git20140519+2ff79d3~unstable1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: Setting up libqgispython2.3.0 (2.3.0+git20140519+2ff79d3~unstable1) ... Setting up python-qgis-common (2.3.0+git20140519+2ff79d3~unstable1) ... All the best, and thanks. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [QGIS-UX] option to disable font vectorization in labels
After the discussion with Larry on PR 1096, it apears that font as font
(i.e. non vectorized) will be the default soon (when the bugs are fixed).
The font vectorization is a nice option though, to create portable pdf/svg.
In PR 1092, I added an option to group layers in the svg, this option is
a checkbox at the bottom of the Save as svg dialog. I think font
vectorization ('Export text as ouline') would fit nicely right next to
it. This way it does cluttet the composer tabs, you make the choice at
the moment it should be made, and it's not an additional step (specific
dialog after you chose your file name).
On 22/01/2014 11:27, Vincent Picavet wrote:
Hello,
Le mardi 21 janvier 2014 21:45:16, Nyall Dawson a écrit :
On 22/01/2014 4:56 am, Anita Graser anitagra...@gmx.at wrote:
Am 21.01.2014, 10:24 Uhr, schrieb Vincent Mora vincent.m...@oslandia.com
- a composer option: you make the choice when you export to svg, in this
case you don't see the result until you open the svg
Thanks for addressing this issue!
For me, the most obvious place to put this option would be in the print
composer. Maybe close to the print as raster option?
I'm not a huge fan of this option, given that I'd like to keep the composer
window as clear of clutter as possible. I think output format specific
options like these (and saving svg to layers) should be put into a separate
dialog which appears after the save file dialog. Much like how
gimp/Photoshop/illustrator etc show a jpg quality dialog after choosing to
save a file as jpg. The settings could either be remembered globally or per
output filename.
-1 for another dialog window. It makes the user have to set another step to
export before having a result. If you want to export the same composition work
multiple times with different file names you would have to set this every time.
If you want QGIS to remember the settings, the user should have set it
somewhere specifically. UX simplification is good, magic things happening behind
the scene are not.
Generally im am more in favor of a configure first, then execute way of
working than the opposite.
An intermediate solution could be to have an extended save as dialog box,
with some options on the side.
My ultimate goal (I was going to run this by the ux list) is to move
infrequently used settings like resolution, page size/orientation, print as
raster, etc and the atlas settings to their own composition properties
dialog and then remove the need for the composition and atlas panels. Any
thoughts on this?
Same, more dialog boxes is a -1 for me, panels are quick and convenient, and
give a fast overview of things.
An option to hide or reduce them on the side would be preferable imho.
Only my personal opinion for what it's worth.
Vincent
___
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] Viewing SpatiaLite views in QGis
http://www.gaia-gis.it/gaia-sins/spatialite-cookbook/html/sp-view.html
recommend to insert spatial view in *views_geometry_columns.*
Note: I had problems trying to use OGC_FID instead of ROWID as the PK
for the view.
On 23/01/2014 09:26, Geo DrinX wrote:
Hello all,
I noticed a strange behavior in QGis when I am viewing SpatiaLite views.
These are my steps:
1) I have some SpatiaLite tables, that have Geometry field. For
example:
CREATE TABLE Poligoni (
PK_UID INTEGER PRIMARY KEY AUTOINCREMENT,
field1 TEXT,
Note TEXT, geometry POLYGON)
2) I create a SpatiaLite view, that performs some spatial opetation,
i.e. an intersection
CREATE VIEW intersecato as
SELECT b.field1as field1, b.field2 AS field2, a.field3 AS
field3,
ST_area (a.Geometry) AS area, b.arec as arec,
intersection (a.Geometry, b.Geometry) as Geometry
FROM Poligoni a, otherTable b
where
ST_intersects (a.Geometry, b.Geometry) = 1
order by field1
3) I insert into geometry_columns a record for the view:
insert into geometry_columns values
('intersecato','geometry',3,2,3003,0)
4) I execute a query into SpatiaLite_gui to control that some record
exists.
And... they exist. :)
5) I go to QGis (2.0.1 Dufour, Windows, Linux or MacOSX :) and
connect to SpatiaLite DB.
6) I insert my tables and view in Layer list.
We, now I see all the layers, as those corresponding to the tables, as
that correspond to my SpatiaLite view. But, this one do not display
the correct records in the attribute panel: in this case, I only have
a list of many NULL, and selecting a record, all records are
selected :(
Do you have any explanation for this?
Also I tried to add a PK_UID in the view definition, but the result
remains the same.
Thank you for any help
Regards
Roberto
___
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 build error in visual studio
This is apparently due to a difference in implementation of std::swap. Sorry for that. This should fix the problem: https://github.com/qgis/QGIS/pull/1106 On 23/01/2014 18:42, A Huarte wrote: Hi dev, now I have updated my master repository, I can not build QGIS in visual studio. May be this commit ? https://github.com/qgis/QGIS/commit/e8205c98c938b60569c30d5c0bbec3acab1f441a I get these errors... 2 qgssinglesymbolrendererv2.cpp 2c:\Archivos de programa\Microsoft Visual Studio 10.0\VC\include\utility(102): error C2248: 'QScopedPointerT::QScopedPointer' : cannot access private member declared in class 'QScopedPointerT' 2 with 2 [ 2 T=QgsSymbolV2 2 ] 2 D:\TFS_OSGeo\SIT\SIG_SDK\OSGeo\OSGeo4W\include\qt4\QtCore/qscopedpointer.h(170) : see declaration of 'QScopedPointerT::QScopedPointer' 2 with 2 [ 2 T=QgsSymbolV2 2 ] 2 ..\..\..\QGIS\src\core\symbology-ng\qgssinglesymbolrendererv2.cpp(59) : see reference to function template instantiation 'void std::swapQScopedPointerT(_Ty ,_Ty )' being compiled 2 with 2 [ 2 T=QgsSymbolV2, 2 _Ty=QScopedPointerQgsSymbolV2 2 ] 2c:\Archivos de programa\Microsoft Visual Studio 10.0\VC\include\utility(103): error C2248: 'QScopedPointerT::operator =' : cannot access private member declared in class 'QScopedPointerT' 2 with 2 [ 2 T=QgsSymbolV2 2 ] 2 D:\TFS_OSGeo\SIT\SIG_SDK\OSGeo\OSGeo4W\include\qt4\QtCore/qscopedpointer.h(170) : see declaration of 'QScopedPointerT::operator =' 2 with 2 [ 2 T=QgsSymbolV2 2 ] 2c:\Archivos de programa\Microsoft Visual Studio 10.0\VC\include\utility(104): error C2248: 'QScopedPointerT::operator =' : cannot access private member declared in class 'QScopedPointerT' 2 with 2 [ 2 T=QgsSymbolV2 2 ] 2 D:\TFS_OSGeo\SIT\SIG_SDK\OSGeo\OSGeo4W\include\qt4\QtCore/qscopedpointer.h(170) : see declaration of 'QScopedPointerT::operator =' 2 with 2 [ 2 T=QgsSymbolV2 2 ] 2c:\Archivos de programa\Microsoft Visual Studio 10.0\VC\include\utility(102): error C2248: 'QScopedPointerT::QScopedPointer' : cannot access private member declared in class 'QScopedPointerT' 2 with 2 [ 2 T=QgsExpression 2 ] 2 D:\TFS_OSGeo\SIT\SIG_SDK\OSGeo\OSGeo4W\include\qt4\QtCore/qscopedpointer.h(170) : see declaration of 'QScopedPointerT::QScopedPointer' 2 with 2 [ 2 T=QgsExpression 2 ] 2 ..\..\..\QGIS\src\core\symbology-ng\qgssinglesymbolrendererv2.cpp(60) : see reference to function template instantiation 'void std::swapQScopedPointerT(_Ty ,_Ty )' being compiled 2 with 2 [ 2 T=QgsExpression, 2 _Ty=QScopedPointerQgsExpression 2 ] 2c:\Archivos de programa\Microsoft Visual Studio 10.0\VC\include\utility(103): error C2248: 'QScopedPointerT::operator =' : cannot access private member declared in class 'QScopedPointerT' 2 with 2 [ 2 T=QgsExpression 2 ] 2 D:\TFS_OSGeo\SIT\SIG_SDK\OSGeo\OSGeo4W\include\qt4\QtCore/qscopedpointer.h(170) : see declaration of 'QScopedPointerT::operator =' 2 with 2 [ 2 T=QgsExpression 2 ] 2c:\Archivos de programa\Microsoft Visual Studio 10.0\VC\include\utility(104): error C2248: 'QScopedPointerT::operator =' : cannot access private member declared in class 'QScopedPointerT' 2 with 2 [ 2 T=QgsExpression 2 ] 2 D:\TFS_OSGeo\SIT\SIG_SDK\OSGeo\OSGeo4W\include\qt4\QtCore/qscopedpointer.h(170) : see declaration of 'QScopedPointerT::operator =' 2 with 2 [ 2 T=QgsExpression 2 ] 2 qgscategorizedsymbolrendererv2.cpp 2c:\Archivos de programa\Microsoft Visual Studio 10.0\VC\include\utility(102): error C2248: 'QScopedPointerT::QScopedPointer' : cannot access private member declared in class 'QScopedPointerT' 2 with 2 [ 2 T=QgsSymbolV2 2 ] 2 D:\TFS_OSGeo\SIT\SIG_SDK\OSGeo\OSGeo4W\include\qt4\QtCore/qscopedpointer.h(170) : see declaration of 'QScopedPointerT::QScopedPointer' 2 with 2 [ 2 T=QgsSymbolV2 2 ] 2 ..\..\..\QGIS\src\core\symbology-ng\qgscategorizedsymbolrendererv2.cpp(59) : see reference to function template instantiation 'void std::swapQScopedPointerT(_Ty ,_Ty )' being compiled 2 with 2 [ 2 T=QgsSymbolV2, 2 _Ty=QScopedPointerQgsSymbolV2 2 ] 2c:\Archivos de programa\Microsoft Visual Studio 10.0\VC\include\utility(103): error C2248: 'QScopedPointerT::operator =' : cannot access private member declared in class 'QScopedPointerT' 2 with
[Qgis-developer] option to disable font vectorization in labels
Hi all, I'm working on improving svg export from composer. The aim is to be able to fine tune maps in a vector graphics editor (e.g. Illustrator or Inkscape). I already added an option to have each map layer in an different svg group that will be recognized by Inkscape as a layer (https://github.com/qgis/QGIS/pull/1092). Now I'd like to have text (especially labels) exported as text and not as paths. At the moment text is vectorized (drawn with QPainter::drawPath) for understandable portability reasons. While this can remain the default, an option would be a nice addition and solve http://hub.qgis.org/issues/3975. The option must be passed to QgsPalLabeling (tested, works at lest for simple cases). The question is where to put this option ? So far I think of 3 places: - a global project option: you will see the result in the canvas as you work - a layer label option: in this case you have to change the behavior for each layer - a composer option: you make the choice when you export to svg, in this case you don't see the result until you open the svg Suggestion ? Thanks, V. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] svg output in composer
Hi, I'd like to improve the svg output of the composer, specifically: (1) - put each layers in a separate svg group (2) - fix #3975 (maybe with an option vectorise fonts yes/no to avoid breaking things in labelling) To realize (1) I need to have some kind of action when the rendering of a layer starts. I'm considering the emission of a signal in qgsmaprenderer.cpp loop so that the impact on the rest of the code is minimal. I'll then have to create a custom QPaintDevice (based on QSvgGenator code) that will insert group tags in the svg when the signal is emmited. I'm a bit worried in case of multi-threaded rendering since the layers are rendered in parallel, can someone give me some insight on this point ? Is the multi-threaded/serial rendering dependent on the QPaintDevice beeing used ? For (2) some insight from those who are familiar with the labeling would save me a lot of time. Comments on the soundness of the design (or lack of it) are very welcome. Cheers, and Happy new year to all. V. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] No Zoom to selected point
I observed the same behavior (qgis master) with two points alligned on x (a very simple layer indeed). On 02/12/2013 12:15, Bernhard Ströbl wrote: Dear devs, today I stumbled on a strange behaviour when zoooming to a point. To reproduce: load a point layer, select one feature in the table and click Zoom to selection. The result is the same as if clicking Pan map to Selection, i.e the map is panned but not zoomed. I _think_ this is because the bounding box of the selected feature has a width and height of 0. Try iface.activeLayer().boundingBoxOfSelected().width()/.height() in the Python console. Geometrically speaking this is correct but as the zoom to selected function builds on a bounding box with width/height 0 the outcome for the user is bad. My suggestion would be to define a small rectangle around the bounding boxes' center if it has size 0 in the zoomToSelected function. Tried with QGIS 2.0.1 and current master Shall I file a ticket for this? Bernhard __ Information from ESET Mail Security, version of virus signature database 9119 (20131202) __ The message was checked by ESET Mail Security. http://www.eset.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] Thanks for the hackfest
First hackfest for me. I liked it. Thank you very much for the organization. V. On 20/09/2013 13:40, Matthias Kuhn wrote: I would also like you all very much for the organisation of this great event. I enjoyed it very much. Especially the lunch in the end was amazing. Do we have the videos online somewhere already? Hope to see you again. Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Suppress rendering of small features
Hi, I did something somewhat similar to solve #4819 in Jully (Identify Features tool is slow with complex/big features) and Matthias asked me to do the same thing for the rubber-band. In polygon contours, points that are less than a pixel apart from the previous point are not drawn. That improved (dramatically) the rendering speed. Vincent On 12/09/2013 13:03, Sandro Santilli wrote: On Thu, Sep 12, 2013 at 08:51:43AM +0200, Andreas Neumann wrote: Hi, As I understand, the feature to suppress small/large features would be optional. 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've done this for mapnik and it worked pretty nicely: http://blog.cartodb.com/post/20163722809/speeding-up-tiles-rendering --strk; ___ 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 API: get attribute values from a PostGIS layer
On 17/07/2013 23:28, Vincent Mora wrote:
Hi Stephan,
We modified the postgis-workshop tutorial for qgis plugin development
to use the new python api of qgis 1.9, there are examples of feature
access in there:
https://github.com/Oslandia/postgis-workshop
Wrong link, sorry, the actual tutorial is here now
https://github.com/Oslandia/QGIS-workshop
Cheers,
Vincent.
On 17/07/2013 21:13, Stéphane Henriod wrote:
Dear all
I am trying to get into the new 2.0 API and am still facing issues
for very basic stuff: getting the values of the attributes out of a
PostGIS layer.
Basically, it works (with the almost same code) in the Qgis python
console, but I don't manage to get it to work in a stand-alone script.
What I have so far is a PostGIS layer, that I load with:
/uri = QgsDataSourceURI()
uri.setConnection('localhost', '5432', 'db_name', 'user_name',
'password')
uri.setDataSource('my_schema', 'my_table', 'the_geom')
my_layer = QgsVectorLayer(uri.uri(),'myhospitals','postgres')
/
A quick test shows me that the layer has been successfully loaded:
/if not my_layer.isValid():
print Layer failed to load!
else:
print Layer loaded successfully
/
I would assume that
/for elem in my_layer.getFeatures():/
/print elem.attributes()/
should return the attributes in a usable format but, instead, I get:
/
/
/[PyQt4.QtCore.QVariant object at 0xad37aca4,
PyQt4.QtCore.QVariant object at 0xad37acdc, None,
PyQt4.QtCore.QVariant object at 0xad37ad14]/
/[PyQt4.QtCore.QVariant object at 0xad37aca4,
PyQt4.QtCore.QVariant object at 0xad37acdc,
PyQt4.QtCore.QVariant object at 0xad37ad14,
PyQt4.QtCore.QVariant object at 0xad37ad4c]/
/[PyQt4.QtCore.QVariant object at 0xad37aca4,
PyQt4.QtCore.QVariant object at 0xad37acdc,
PyQt4.QtCore.QVariant object at 0xad37ad14,
PyQt4.QtCore.QVariant object at 0xad37ad4c]/
/[PyQt4.QtCore.QVariant object at 0xad37aca4,
PyQt4.QtCore.QVariant object at 0xad37acdc,
PyQt4.QtCore.QVariant object at 0xad37ad14,
PyQt4.QtCore.QVariant object at 0xad37ad4c]/
Does anyone have an idea where the problem could lie?
For those who speak French, the question is posted here as well:
http://www.forumsig.org/showthread.php/37178-Nouvelle-API-r%C3%A9cup%C3%A9rer-les-valeurs-attributaires
I am using Qgis 1.9.0 with Python 2.7 on Ubuntu 13.04
Thanks in advance for ideas and comments...
Cheers
Stéphane
--
Le mot progrès n'aura aucun sens tant qu'il y aura des enfants
malheureux -- Albert Einstein
A journey does not need reasons. Before long, it proves to be reason
enough in itself. One thinks that one is going to make a journey, yet
soon it is the journey that makes or unmakes you. -- Nicolas Bouvier
Photos de voyages, photos de montagne: http://www.henriod.info
http://www.henriod.info/
___
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] highlighting features
Hi, I'm working on issue 4819 and noticed that when a feature is selected, the pan is fast even with complex polygons whereas the pan slows down a lot when features are highlighted. My best guesses for the difference is: 1) pan operation use cached image for rendering in rendereV2 2) rendering style and/or pipeline is sufficiently different to cause delays (this would explain why refresh after pan drag/drop takes 4sec with highlighted feature, while cached image refresh takes only 2sec otherwise) The fix I can think about for this are either: 1) to introduce caching in QgsHighlight (therefore adding substantial complexity to this class). 2) to add the parameter highlighted (along with selected) to QgsFeatureRendererV2::renderFeature and get rid of QgsHighlight altogether (or at least deprecate it). What is the best option: caching in QgsHighlight, modifying renderFeature, or something I did not think about ? Thanks, V. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New API: get attribute values from a PostGIS layer
Hi Stephan,
We modified the postgis-workshop tutorial for qgis plugin development to
use the new python api of qgis 1.9, there are examples of feature access
in there:
https://github.com/Oslandia/postgis-workshop
Cheers,
Vincent.
On 17/07/2013 21:13, Stéphane Henriod wrote:
Dear all
I am trying to get into the new 2.0 API and am still facing issues for
very basic stuff: getting the values of the attributes out of a
PostGIS layer.
Basically, it works (with the almost same code) in the Qgis python
console, but I don't manage to get it to work in a stand-alone script.
What I have so far is a PostGIS layer, that I load with:
/uri = QgsDataSourceURI()
uri.setConnection('localhost', '5432', 'db_name', 'user_name',
'password')
uri.setDataSource('my_schema', 'my_table', 'the_geom')
my_layer = QgsVectorLayer(uri.uri(),'myhospitals','postgres')
/
A quick test shows me that the layer has been successfully loaded:
/if not my_layer.isValid():
print Layer failed to load!
else:
print Layer loaded successfully
/
I would assume that
/for elem in my_layer.getFeatures():/
/print elem.attributes()/
should return the attributes in a usable format but, instead, I get:
/
/
/[PyQt4.QtCore.QVariant object at 0xad37aca4,
PyQt4.QtCore.QVariant object at 0xad37acdc, None,
PyQt4.QtCore.QVariant object at 0xad37ad14]/
/[PyQt4.QtCore.QVariant object at 0xad37aca4,
PyQt4.QtCore.QVariant object at 0xad37acdc,
PyQt4.QtCore.QVariant object at 0xad37ad14,
PyQt4.QtCore.QVariant object at 0xad37ad4c]/
/[PyQt4.QtCore.QVariant object at 0xad37aca4,
PyQt4.QtCore.QVariant object at 0xad37acdc,
PyQt4.QtCore.QVariant object at 0xad37ad14,
PyQt4.QtCore.QVariant object at 0xad37ad4c]/
/[PyQt4.QtCore.QVariant object at 0xad37aca4,
PyQt4.QtCore.QVariant object at 0xad37acdc,
PyQt4.QtCore.QVariant object at 0xad37ad14,
PyQt4.QtCore.QVariant object at 0xad37ad4c]/
Does anyone have an idea where the problem could lie?
For those who speak French, the question is posted here as well:
http://www.forumsig.org/showthread.php/37178-Nouvelle-API-r%C3%A9cup%C3%A9rer-les-valeurs-attributaires
I am using Qgis 1.9.0 with Python 2.7 on Ubuntu 13.04
Thanks in advance for ideas and comments...
Cheers
Stéphane
--
Le mot progrès n'aura aucun sens tant qu'il y aura des enfants
malheureux -- Albert Einstein
A journey does not need reasons. Before long, it proves to be reason
enough in itself. One thinks that one is going to make a journey, yet
soon it is the journey that makes or unmakes you. -- Nicolas Bouvier
Photos de voyages, photos de montagne: http://www.henriod.info
http://www.henriod.info/
___
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
