Re: [Qgis-developer] pb with change attribute value in QGIS 2.6
Any ideas please to troubleshoot this problem? De : qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] De la part de Nejia Envoyé : mardi 25 novembre 2014 16:51 À : qgis-developer@lists.osgeo.org Objet : [Qgis-developer] pb with change attribute value in QGIS 2.6 Hi, I have a tool that allow to edit attribute of features (only one attribute): 1- I select the feature by click on it: vectorLayer->getFeatures( QgsFeatureRequest().setFilterRect( tSelectRect ).setFlags( QgsFeatureRequest::ExactIntersect )) 2- Modify the attribute 3- Validate attribute change : vectorLayer->changeAttributeValue( fId(), iField, newValue,oldValue ); The attribute change in attribute table but not on the label (layer is labeled with the attribute) and in the identify result dialog. I compile my plugin with libraries of Qgis 2.6 shipped with OSGeo4W, if I use libraries of QGIS that I build from sources it work without any problem. I compiled the same plugin with libraries of QGIS 2.4 shipped with OSGeo4W and it worked fine. Regards Nejia ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Replacing Extent with Center in QgsMapSettings (for rotation)
On 28.11.2014 10:41, Sandro Santilli wrote: By "scale" I mean "resolution", that is how many source units fit in a pixel. I see, then it makes sense to go with scale / resolution. Regards, Marco -- 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] Replacing Extent with Center in QgsMapSettings (for rotation)
On Fri, Nov 28, 2014 at 10:25:30AM +0100, Marco Hugentobler wrote: > Hi Sandro > > >which togheter with a scale and a rotation could be > >used to derive the visible extent. > > How would scale be defined for maps in degrees (witout constant > scale on the map)? By "scale" I mean "resolution", that is how many source units fit in a pixel. The meaning of a source unit is left to the spatial projection; map distortions issues are in no way attempted to be solved by this change. > Alternatively, there could be a rectangle (four corner points) > instead of a bounding box. To represent an "area of interest", in alternative to "center & resolution" ? It would be a 4 vertices polygon, rather than a "rectangle" (the term is already taken for objects that are defined as being not-rotated). Would such "area of interest" be then restricted to have only right angles ? It could still sound arbitrary to allow rotation but not map projection distortion... it should be analyzed what's the actual usability of such configuration. For sure a "rotating rectangle" would encode all of center, rotation and scale (the latter being dependent on output). But does it make sense for an "area of interest" to include rotation ? --strk; > On 27.11.2014 18:36, Sandro Santilli wrote: > >I've finally handled to get a correctly rendered rotated map > >(git://github.com/strk/QGIS.git "rotation" branch) but more work > >will be needed to correctly get the source data extent and output > >rectangle for clipping purpose. > > > >As I continue working in the branch, I can't stop thinking that > >the QgsMapSetting class should be refactored to move away from > >the concept of "extent" as a defining setting. > > > >Currently, callers set the map's "extent", which togheter with > >the output viewport size is used to derive the scale and the > >"visible extent" (see QgsMapSettings::updateDerived). > > > >Once the concept of rotation is added, the meaning of "extent" > >becomes very confusing. What does it represent, exactly ? > > > >The only "stable" concept you can derive from the extent is its > >center, which togheter with a scale and a rotation could be > >used to derive the visible extent. > > > >OpenLayers indeed has center, rotation and scale as the defining > >parameters of a view: http://openlayers.org/en/v3.0.0/apidoc/ol.View.html > > > >In this scenario, panning would move the center, retaining scale > >and rotation. Zooming would change scale, retaninig rotation and center > >(combined zoom+pan could still be used). Rotation would retain the > >scale and center. > > > >Right now the class has mExtent and a mVisibleExtent members, > >with the new configuration only the "visible extent" would make sense, > >and could always be computed given an output size (currently also > >a member of the class). > > > >How would you see a transition toward this new configuration ? > > > >If you want to follow the progress for rotation support, there's > >a pull request for it: https://github.com/qgis/QGIS/pull/1700 > > > >--srk; ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Replacing Extent with Center in QgsMapSettings (for rotation)
Hi Sandro which togheter with a scale and a rotation could be used to derive the visible extent. How would scale be defined for maps in degrees (witout constant scale on the map)? Alternatively, there could be a rectangle (four corner points) instead of a bounding box. Regards, Marco On 27.11.2014 18:36, Sandro Santilli wrote: I've finally handled to get a correctly rendered rotated map (git://github.com/strk/QGIS.git "rotation" branch) but more work will be needed to correctly get the source data extent and output rectangle for clipping purpose. As I continue working in the branch, I can't stop thinking that the QgsMapSetting class should be refactored to move away from the concept of "extent" as a defining setting. Currently, callers set the map's "extent", which togheter with the output viewport size is used to derive the scale and the "visible extent" (see QgsMapSettings::updateDerived). Once the concept of rotation is added, the meaning of "extent" becomes very confusing. What does it represent, exactly ? The only "stable" concept you can derive from the extent is its center, which togheter with a scale and a rotation could be used to derive the visible extent. OpenLayers indeed has center, rotation and scale as the defining parameters of a view: http://openlayers.org/en/v3.0.0/apidoc/ol.View.html In this scenario, panning would move the center, retaining scale and rotation. Zooming would change scale, retaninig rotation and center (combined zoom+pan could still be used). Rotation would retain the scale and center. Right now the class has mExtent and a mVisibleExtent members, with the new configuration only the "visible extent" would make sense, and could always be computed given an output size (currently also a member of the class). How would you see a transition toward this new configuration ? If you want to follow the progress for rotation support, there's a pull request for it: https://github.com/qgis/QGIS/pull/1700 --srk; () ASCII ribbon campaign -- Keep it simple ! /\ http://strk.keybit.net/rants/ascii_mails.txt ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux & Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Replacing Extent with Center in QgsMapSettings (for rotation)
Hi Sandro, I think you have a valid point, and hope that other core devs will chime in. I'm also wondering about this kind of use cases outside the geo world, like how do they do that in the CAD world, 3D world or rendering world? And what about non-ortogonal projections which do not have a square extent either? Regards, Richard Duivenvoorde On 27-11-14 18:36, Sandro Santilli wrote: > I've finally handled to get a correctly rendered rotated map > (git://github.com/strk/QGIS.git "rotation" branch) but more work > will be needed to correctly get the source data extent and output > rectangle for clipping purpose. > > As I continue working in the branch, I can't stop thinking that > the QgsMapSetting class should be refactored to move away from > the concept of "extent" as a defining setting. > > Currently, callers set the map's "extent", which togheter with > the output viewport size is used to derive the scale and the > "visible extent" (see QgsMapSettings::updateDerived). > > Once the concept of rotation is added, the meaning of "extent" > becomes very confusing. What does it represent, exactly ? > > The only "stable" concept you can derive from the extent is its > center, which togheter with a scale and a rotation could be > used to derive the visible extent. > > OpenLayers indeed has center, rotation and scale as the defining > parameters of a view: http://openlayers.org/en/v3.0.0/apidoc/ol.View.html > > In this scenario, panning would move the center, retaining scale > and rotation. Zooming would change scale, retaninig rotation and center > (combined zoom+pan could still be used). Rotation would retain the > scale and center. > > Right now the class has mExtent and a mVisibleExtent members, > with the new configuration only the "visible extent" would make sense, > and could always be computed given an output size (currently also > a member of the class). > > How would you see a transition toward this new configuration ? > > If you want to follow the progress for rotation support, there's > a pull request for it: https://github.com/qgis/QGIS/pull/1700 > > --srk; > > () ASCII ribbon campaign -- Keep it simple ! > /\ http://strk.keybit.net/rants/ascii_mails.txt > ___ > 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] Letter of recommendation
Dear Julia, I suspect your email is more suited to other mailing lists. However, sisnce you appear to do serious business based on QGIS, please consider supporting its development to assure a brighter future to the project and, as a consequence, to your business as well. Please contact me in private if you are interested. All the best. Il 28/11/2014 09:54, j...@giap.pl ha scritto: > Our leading > software in this area of our work is QGIS. We chose this particular software > mainly > due to its simplicity, intuitive interface, big variety of plugins. And of > course > unlimited access. -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Letter of recommendation
November 28, 2014 To whom it may concern: I am writing to recommend you the services of Gospodarczy Instytut Analiz Przestrzennych (Institute of Spatial Economic Analysis). We are a small company from Warsaw mainly interested in GIS, local planning and cartography. Our leading software in this area of our work is QGIS. We chose this particular software mainly due to its simplicity, intuitive interface, big variety of plugins. And of course unlimited access. Although QGIS is undeniably one of the most simple in use software than most of available currently softwares, we observed that during our work with local government on plans and studies, local officials have problems obtaining the software on their own. Our cooperation with local governments is becoming more intense due to the adoption of the EU INSPIRE Directive. This will enforce local officials to learn to operate the software fluently. Therefore, we decided to organize trainings of software support, which have a relatively great popularity. Our trainings contribute to increase knowledge about QGIS and geographic information systems in general. Thanks to your support, the scope of our activities can be enlarged, which may also become advantageous for you. Placing on the website of QGIS logo of our company, as recommended by developers, not only increase the prestige of our Institute, but will result in a further consequence in extending information about QGIS. We kindly ask you to consider our proposal. We wish you continued success in development of QGIS products. Yours faithfully, Julia Korcz Gospodarczy Instytut Analiz Przestrzennych ul. Dembowskiego 7/57 02-784 Warszawa Tel. 22-121-34-39 facebook.com/NaMapie GIAP - rozwiązania dla planowania przestrzennego SZKOLIMY--WSPIERAMY--DORADZAMY Jeżeli nie są Państwo zainteresowani otrzymywaniem wiadomości od GIAP proszę o odesłanie emaila w którego temacie będzie słowo NIE.___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Load zipped shapefiles with python
On 27-11-14 13:08, Ziegler Stefan wrote:
> Hi
>
> Is it possible to load zipped shapefiles with python? I have some zip files
> with several shapefiles in it. I tried something like this:
>
> vlayer = QgsVectorLayer("/vsizip/home/stefan/Downloads/2546.zip/lfp3.shp",
> LFP3, "ogr")
>
> But the layer is not valid.
Hi Stefan,
maybe you already figured out?
qgis.utils.iface.addVectorLayer("/vsizip//data/disk/home/richard/geodata/nl/autowegen.zip",
"wegen", "ogr")
loads a layer to me. Note though that you get the 'crs' popup in between.
vlayer =
QgsVectorLayer("/vsizip//data/disk/home/richard/geodata/nl/autowegen.zip",
"wegen", "ogr")
also works.
Note:
- /vsizip// <= double /
- "ogr" <= no capitals
(second argument is a string)
Regards,
Richard Duivenvoorde
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
