[QGIS-Developer] Plugin [1391] Asistente LADM_COL approval notification.
Plugin Asistente LADM_COL approval by pcav. The plugin version "[1391] Asistente LADM_COL 1.6.3" is now approved Link: http://plugins.qgis.org/plugins/asistente_ladm_col/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Questions wrt. problems with empty layers
On Fri, May 10, 2019 at 5:04 PM Richard Duivenvoorde
wrote:
> Hi,
>
> Just tried with a Geoserver (2.15) I have running here.
>
> Moved a shp file with 1 feature in a postgis db, created a wfs service
> for it and loaded in QGIS, styled it etc: fine.
>
> Removed the (one) feature from the table, retarted Geoserver, and had a
> look into the requests QGIS is firing [0].
>
> QGIS first does a GetCapabilities request:
>
> /geoserver/wfs?SERVICE=WFS=GetCapabilities=2.0.0,1.1.0,1.0.0
>
> Then a describefeature request (to determine the type):
>
>
> geoserver/wfs?SERVICE=WFS=DescribeFeatureType=2.0.0=test:wfspointPostgis
>
> That one responses with
>
> type="gml:PointPropertyType"/>
>
> So Geoserver (still?) knows about the geometry type of the table.
> Not sure if that is cached? But it is available in the
> 'geometry_columns'-view of Postgis (stating type=POINT).
>
> And QGIS keeps the styling, even after several restarts/reloads.
>
> One thing I can think of: is that the postgis table does not have a type
> defined, with someting like:
> geom geometry
> instead of
> geom geometry(Point,28992),
> what I see when the table created via QGIS...
>
> Could it be that
> - geoserver cannot determine the type?
>
> To test I created a minimal table:
> CREATE TABLE public.testgeoms
> (
> id integer,
> geom geometry,
> fid integer NOT NULL DEFAULT nextval('testgeoms_fid_seq'::regclass),
> CONSTRAINT foo PRIMARY KEY (fid)
> )
>
> At that moment the geometry_columns view shows type=GEOMETRY
> So (I think) without data, geoserver can never determine the type, hence
> shows:
> type="gml:GeometryPropertyType"/>
> in the DescribeFeatureType response...
>
> And indeed if I then empty the table, and reopen the project the
> WFS-point layer shows an 'img', as it cannot style the zero features.
> AND it does not have type info?
>
> So (confirmed) having that layer with zero (of unknown type) features,
> QGIS forgets the style...
>
> Is that a bug?
>
>
QGIS styles are bound to geometry types, it the type is unknown there is
not much we can do something similar happens for bad/broken layers.
For that implementation I'm storing the original XML layer style that can
be re-applied in case the "bad layer" is fixed, maybe we can re-use that
mechanism for this use case.
> IF you create the layers with a feature TYPE (geom
> geometry(Point,28992)) then the type will show up in the
> 'geometry_columns'-view and then in the describefeature response.
>
> Without that knowledge QGIS retrieves NO type information (via the
> describefeature) upon loading of the project/layer and (apparently)
> forgets the type in the layer???
>
> Does it work with you if you put the type in the table definitions in
> Postgis (so they show up in the 'geometry_columns'-view)?
> With me it does, but I just did a quick test.
>
> Else I would create an issue for it or let somebody dive into this...
>
> Regards,
>
> Richard Duivenvoorde
>
>
> [0] https://github.com/rduivenvoorde/qgisnetworklogger/tree/model_rewrite
>
>
> On 09/05/2019 22.22, Bo Victor Thomsen wrote:
> > Hi Lars and other members of this list..
> >
> > I feel somewhat obligated to help Lars since it's a problem he has
> > inherited from me. (Sorry about that...)
> >
> > To sum it up:
> >
> > If QGIS connects to a WFS based layer from Geoserver using an existing
> > project with styled layers and one or more layers containing /zero/
> > objects, QGIS can't determine the object type (point, line-string,
> > polygon...) for those layers. QGIS will not show legends and promptly
> > forget any layer information stored in the project related to the
> > object-type, ex. styling information.
> >
> > And what is worse - this is a permanent situation: If you save the
> > project in the above-mentioned state and reopen it at a later time -
> > where the layers /now/ contains objects - QGIS has forgotten the styling
> > and other information, so the layers stays invisible and without the
> > former styling.
> >
> > (long posting...)
> >
> > I've done some tests to determine the root cause of this problem:
> >
> > * Setup of a Postgres database /and /a SQL Server database.
> >
> > * Loaded the same MapInfo-dataset twice into each database, called
> > them tableA and tableB, and populated the meta-table
> > "dbo.geometry_columns" with the correct information for tableA and
> > tableB in SQLServer.
> >
> > * Installed a fresh Geoserver 2.15 and MapServer TinyOWS WFS-T server
> >
> > * Setup a Workspace in Geoserver with 4 layers: tableA and -B from
> > SQLServer and the same tables from Postgres using WFS.
> >
> > * In Geoserver, the datastore definition for the SQLServer tables has
> > a pointer to the "dbo.geometry_columns" meta-table.
> >
> > * Setup of TinyOWS with tableA and -B from Postgres
> >
> > * And lastly: Made a project in QGIS 3.4.7 /Windows 64bit with the 6
> > WFS layers:
> >
> > o tableA is shown 3 times:
> >
> > 1. From
Re: [QGIS-Developer] Questions wrt. problems with empty layers
Hi,
Just tried with a Geoserver (2.15) I have running here.
Moved a shp file with 1 feature in a postgis db, created a wfs service
for it and loaded in QGIS, styled it etc: fine.
Removed the (one) feature from the table, retarted Geoserver, and had a
look into the requests QGIS is firing [0].
QGIS first does a GetCapabilities request:
/geoserver/wfs?SERVICE=WFS=GetCapabilities=2.0.0,1.1.0,1.0.0
Then a describefeature request (to determine the type):
geoserver/wfs?SERVICE=WFS=DescribeFeatureType=2.0.0=test:wfspointPostgis
That one responses with
So Geoserver (still?) knows about the geometry type of the table.
Not sure if that is cached? But it is available in the
'geometry_columns'-view of Postgis (stating type=POINT).
And QGIS keeps the styling, even after several restarts/reloads.
One thing I can think of: is that the postgis table does not have a type
defined, with someting like:
geom geometry
instead of
geom geometry(Point,28992),
what I see when the table created via QGIS...
Could it be that
- geoserver cannot determine the type?
To test I created a minimal table:
CREATE TABLE public.testgeoms
(
id integer,
geom geometry,
fid integer NOT NULL DEFAULT nextval('testgeoms_fid_seq'::regclass),
CONSTRAINT foo PRIMARY KEY (fid)
)
At that moment the geometry_columns view shows type=GEOMETRY
So (I think) without data, geoserver can never determine the type, hence
shows:
in the DescribeFeatureType response...
And indeed if I then empty the table, and reopen the project the
WFS-point layer shows an 'img', as it cannot style the zero features.
AND it does not have type info?
So (confirmed) having that layer with zero (of unknown type) features,
QGIS forgets the style...
Is that a bug?
IF you create the layers with a feature TYPE (geom
geometry(Point,28992)) then the type will show up in the
'geometry_columns'-view and then in the describefeature response.
Without that knowledge QGIS retrieves NO type information (via the
describefeature) upon loading of the project/layer and (apparently)
forgets the type in the layer???
Does it work with you if you put the type in the table definitions in
Postgis (so they show up in the 'geometry_columns'-view)?
With me it does, but I just did a quick test.
Else I would create an issue for it or let somebody dive into this...
Regards,
Richard Duivenvoorde
[0] https://github.com/rduivenvoorde/qgisnetworklogger/tree/model_rewrite
On 09/05/2019 22.22, Bo Victor Thomsen wrote:
> Hi Lars and other members of this list..
>
> I feel somewhat obligated to help Lars since it's a problem he has
> inherited from me. (Sorry about that...)
>
> To sum it up:
>
> If QGIS connects to a WFS based layer from Geoserver using an existing
> project with styled layers and one or more layers containing /zero/
> objects, QGIS can't determine the object type (point, line-string,
> polygon...) for those layers. QGIS will not show legends and promptly
> forget any layer information stored in the project related to the
> object-type, ex. styling information.
>
> And what is worse - this is a permanent situation: If you save the
> project in the above-mentioned state and reopen it at a later time -
> where the layers /now/ contains objects - QGIS has forgotten the styling
> and other information, so the layers stays invisible and without the
> former styling.
>
> (long posting...)
>
> I've done some tests to determine the root cause of this problem:
>
> * Setup of a Postgres database /and /a SQL Server database.
>
> * Loaded the same MapInfo-dataset twice into each database, called
> them tableA and tableB, and populated the meta-table
> "dbo.geometry_columns" with the correct information for tableA and
> tableB in SQLServer.
>
> * Installed a fresh Geoserver 2.15 and MapServer TinyOWS WFS-T server
>
> * Setup a Workspace in Geoserver with 4 layers: tableA and -B from
> SQLServer and the same tables from Postgres using WFS.
>
> * In Geoserver, the datastore definition for the SQLServer tables has
> a pointer to the "dbo.geometry_columns" meta-table.
>
> * Setup of TinyOWS with tableA and -B from Postgres
>
> * And lastly: Made a project in QGIS 3.4.7 /Windows 64bit with the 6
> WFS layers:
>
> o tableA is shown 3 times:
>
> 1. From SQLServer through GeoServer;
> 2. From Postgres through GeoServer
> 3. From Postgres through Tiny-WFS
>
> o tableB is shown 3 times using the same setup as tableA
>
> All 6 layers in QGIS was shown correctly and the object type for all
> layers was recognized.
>
> After this I /deleted/ all rows from tableB in /both/ MS-SQLServer and
> in Postgres and reopened the same QGIS project:
>
> * The layer showing (the zero objects) tableB from SQLServer through
> GeoServer was not in order.
> * The 5 other layers was shown correctly. Legends was correct and
> styling was not deleted
>
> I'm drawing the following conclusion:
>
> *
[QGIS-Developer] FIELDS_TO_COPY syntax for native:joinattributestable
Hi, I'm trying to figure out the syntax for using native:joinattributestable in the modeller. Specifically, I'd like to specify the FIELDS_TO_COPY parameter. I know from the Processing history, that the correct syntax is : FIELDS_TO_COPY: ['NAME','USE'] but no matter how I try to enter the field names into to modeller GUI, I always end up with either everything mashed into one field name, e.g. FIELDS_TO_COPY: 'NAME,USE' or escaped: FIELDS_TO_COPY: '[\'NAME\',\'USE\']' What's the correct way to specify the "Layer 2 fields to copy" in the modeler GUI? Regards, Anita ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Should we create a list for admin sys discussions and infrastructure monitoring?
Hi all, at Oslandia we are currently pushing the OGC compliance test suite, the performance test suite and some demo stuff QWC2 on qgis officiel servers. We need to monitor those tools that produce daily reports and send mails in case of failure of the tools We don't want to flood the developper's mailing list with such messages, so we are wondering what would be the best place to send those notifications? For the particular case of the OGC compliance test, we also now have messages in case of regressions. Those messages should are not wired with Travis PR workflow, so we need to raise the information probably on the developper mailing list. Is there anything already set up somewhere we are not aware of? I think centralizing notification and having a dashbooard to monitot the status of all the infrastructure would be nice. Thanks for your hints! Best regards Régis ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Broken links to PDF manuals
Ok, fixed now, thanks Harrissou! Richard On 10/05/2019 08.30, Nyall Dawson wrote: > Hey list, > > Can anyone confirm for me that the link to download PDF versions of > the QGIS manual is currently broken? From > https://www.qgis.org/en/docs/index.html the link leads to > https://docs.qgis.org/3.4/en/en/QGIS-3.4-UserGuide-en.pdf, which > returns a 404. > > There's also links under https://docs.qgis.org/3.4/en/docs/ to the > PDF, which point across to https://docs.qgis.org/testing/pdf/ -- but > that link redirects back to https://docs.qgis.org/testing/en/docs/ and > not the actual PDFs (it's also redirected from the 3.4 docs to the > testing ones) > > Nyall > ___ > QGIS-Developer mailing list > QGIS-Developer@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Print Layout continuously crashing
I recompiled QGIS withe debug information (thanks Mathieu) and the gist is now updated with hopefully more information Cheers Matteo ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Broken links to PDF manuals
I am fond of PDFs. In some situations, I find them more convenient to read, and I often use the PDFs for text search on the complete "document". So, -1 for removing the PDFs. Håvard On 10.05.2019 10:11, Paolo Cavallini wrote: Hi Richard, On 10/05/19 08:59, Richard Duivenvoorde wrote: Are these actually used? Because when busy testing new sphinx/templates/Make/Build of docs I was thinking about getting rid of pdf. But instead go for the 'zipped' docs route, which can be viewed in QGIS itself. (though if pdf build 'just keep working' and are needed, we can keep on building them) I have seen often pdf being printed - apparently people like to read on paper. On the other hand, I believe we should discourage this, bot for environmental and for practical purposes (a printed manual becomes obsolete soon, and people keep on reading old stuff instead of upgrading to the new version). So I'd be a mild +1 for removing the pdfs. Cheers. ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Can I backport bugfix with UI updates and fixing QGIS Server regression
Hi René On 10/05/19 10:31, René-Luc Dhont wrote: > Hi devs, > > I am still waiting for a review about fixing 2 issues in printing for > QGIS and QGIS Server 3.4 LTR. https://github.com/qgis/QGIS/pull/9692 > > This PR wil fix an issue https://issues.qgis.org/issues/19500 `Layout > export - raster divided into tiles, edges evident in pdf/svg`. This > issue has been identifed in version 3.2 and has been fixed in 3.6. > This PR will also fix a regression in QGIS Server `Printing selection in > PDF and SVG`. The selection is already printed in image output. > > The next LTR will be released in 10 mounths. QGIS Server 3.6, which > already have the fix, is not available on Debian Stretch because it > requires Qt 5.9 and Debian Buster will be freezed in 8 mounths. So the > QGIS server regression will not be available since the end of 2019. > > I will appreciate a decision about this fix. Do you think QGIS Server > users have to wait for the next LTR or Debian Buster release ? I believe it is very important to keep the LTR server in good shape, and fix whatever is possible. Do you (or anybody else) have reasons to suspect these fixes could be harmful or have side effects? Cheers. -- Paolo Cavallini - www.faunalia.eu QGIS.ORG Chair: http://planet.qgis.org/planet/user/28/tag/qgis%20board/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Can I backport bugfix with UI updates and fixing QGIS Server regression
Hi devs, I am still waiting for a review about fixing 2 issues in printing for QGIS and QGIS Server 3.4 LTR. https://github.com/qgis/QGIS/pull/9692 This PR wil fix an issue https://issues.qgis.org/issues/19500 `Layout export - raster divided into tiles, edges evident in pdf/svg`. This issue has been identifed in version 3.2 and has been fixed in 3.6. This PR will also fix a regression in QGIS Server `Printing selection in PDF and SVG`. The selection is already printed in image output. The next LTR will be released in 10 mounths. QGIS Server 3.6, which already have the fix, is not available on Debian Stretch because it requires Qt 5.9 and Debian Buster will be freezed in 8 mounths. So the QGIS server regression will not be available since the end of 2019. I will appreciate a decision about this fix. Do you think QGIS Server users have to wait for the next LTR or Debian Buster release ? Reagrds, René-Luc Le 19/04/2019 à 09:34, René-Luc Dhont a écrit : Hi devs, I have cherry-picked the changes I have tested it without regressions or issues. Now I need some review to merge and fix 2 issues. https://github.com/qgis/QGIS/pull/9692 Regards, René-Luc Le 17/04/2019 à 14:18, René-Luc Dhont a écrit : Hi devs, Thanks Paolo for your agreement. I'd like to fix the QGIS Sever regression before friday and the version 3.4.7 released. So I'd like to have other point of view about backporting : [needs-docs][layouts] Add checkbox to disable raster tiling for PDF/SVG exports https://github.com/qgis/QGIS/pull/9016 and finalizing Fix regression server print selection pdf release 3.4 https://github.com/qgis/QGIS/pull/9692 Thanks. René-Luc Le 12/04/2019 à 12:06, Paolo Cavallini a écrit : Hi René, On 12/04/19 12:05, René-Luc Dhont wrote: I would like to know if I can backport all the commits made by Nyall to fix issue 19500 even if it updates the User Interface ? +1 from my side, but obviously Nyall has the final word on this. Thanks. ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Broken links to PDF manuals
Hi Richard, On 10/05/19 08:59, Richard Duivenvoorde wrote: > Are these actually used? > Because when busy testing new sphinx/templates/Make/Build of docs I was > thinking about getting rid of pdf. But instead go for the 'zipped' docs > route, which can be viewed in QGIS itself. > (though if pdf build 'just keep working' and are needed, we can keep on > building them) I have seen often pdf being printed - apparently people like to read on paper. On the other hand, I believe we should discourage this, bot for environmental and for practical purposes (a printed manual becomes obsolete soon, and people keep on reading old stuff instead of upgrading to the new version). So I'd be a mild +1 for removing the pdfs. Cheers. -- Paolo Cavallini - www.faunalia.eu QGIS.ORG Chair: http://planet.qgis.org/planet/user/28/tag/qgis%20board/ ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Print Layout continuously crashing
Hi all, with a very simple layout template (1 point layer, OSM Tile), no fancy things around, when I try to open the layout after the project has benn saved and the layout is also saved, QGIS crashes after a few seconds with this stack trace: https://gist.github.com/ghtmtt/b2258693f03abd441b726a8d7e534d15 Tested on Debian Sid, with QGIS 3.4 (installed from package), QGIS 3.6 compiled and QGIS 3.7 compiled. Has anyone some suggestion? Cheers Matteo ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Broken links to PDF manuals
The link is http://docs.qgis.org/3.4/pdf/en/QGIS-3.4-UserGuide-en.pdf but that redirects to https://docs.qgis.org/3.4/en/en/QGIS-3.4-UserGuide-en.pdf The same happens to different language versions: http://docs.qgis.org/3.4/pdf/nl/QGIS-3.4-UserGuide-nl.pdf redirects to https://docs.qgis.org/3.4/en/nl/QGIS-3.4-UserGuide-nl.pdf Michel -Oorspronkelijk bericht- Van: QGIS-Developer Namens Nyall Dawson Verzonden: vrijdag 10 mei 2019 8:30 Aan: qgis-developer Onderwerp: [QGIS-Developer] Broken links to PDF manuals Hey list, Can anyone confirm for me that the link to download PDF versions of the QGIS manual is currently broken? From https://www.qgis.org/en/docs/index.html the link leads to https://docs.qgis.org/3.4/en/en/QGIS-3.4-UserGuide-en.pdf, which returns a 404. There's also links under https://docs.qgis.org/3.4/en/docs/ to the PDF, which point across to https://docs.qgis.org/testing/pdf/ -- but that link redirects back to https://docs.qgis.org/testing/en/docs/ and not the actual PDFs (it's also redirected from the 3.4 docs to the testing ones) Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Broken links to PDF manuals
On 10/05/2019 08.30, Nyall Dawson wrote: > Hey list, > > Can anyone confirm for me that the link to download PDF versions of > the QGIS manual is currently broken? From > https://www.qgis.org/en/docs/index.html the link leads to > https://docs.qgis.org/3.4/en/en/QGIS-3.4-UserGuide-en.pdf, which > returns a 404. Hi Nyall, Yep, working on it, we ( Harrissou :-) ) rearranged the convoluted apache configuration for documentation (was full of redirects/rewrites). But we missed the pdf. Will show up soon. Are these actually used? Because when busy testing new sphinx/templates/Make/Build of docs I was thinking about getting rid of pdf. But instead go for the 'zipped' docs route, which can be viewed in QGIS itself. (though if pdf build 'just keep working' and are needed, we can keep on building them) Regards, Richard Duivenvoorde ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] Broken links to PDF manuals
confirmed over her -- Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
[QGIS-Developer] Broken links to PDF manuals
Hey list, Can anyone confirm for me that the link to download PDF versions of the QGIS manual is currently broken? From https://www.qgis.org/en/docs/index.html the link leads to https://docs.qgis.org/3.4/en/en/QGIS-3.4-UserGuide-en.pdf, which returns a 404. There's also links under https://docs.qgis.org/3.4/en/docs/ to the PDF, which point across to https://docs.qgis.org/testing/pdf/ -- but that link redirects back to https://docs.qgis.org/testing/en/docs/ and not the actual PDFs (it's also redirected from the 3.4 docs to the testing ones) Nyall ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] adding vertices to digitize session via python
Hello again, nevermind, figured it out. just casting the map tool to QgsMapToolCapture does the trick: from qgis.core import QgsPointXY from qgis.gui import QgsMapTool, QgsMapToolCapturefrom qgis.PyQt import sipmapToolCapture = sip.cast(iface.mapCanvas().mapTool(), QgsMapToolCapture) mapToolCapture.addVertex(QgsPointXY(1,2)) Cheers Jonas On 09.05.2019 12:55, Jonas wrote: Hi, is there a way to add vertices to the rubberband when the user currently digitizes a feature via the python API? For example when adding a line feature, the user has already created a few vertices of a line via the rubber band. now i want to add the next vertex of that rubber band via python. I do NOT want to end the users action to create the feature, or add vertices to already existing features. I think that would mean calling addVertex() on a QgsMapToolCapture-object. However i cannot find a way to retrieve a QgsMapToolCapture-object from the current mapTool. Is there a way to do this? Thanks Jonas ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [QGIS-Developer] QGIS 2.18/3.6 produces incorrect wordfiles
Il giorno gio 9 mag 2019 alle ore 16:07 Luca Manganelli < luca.mangane...@comune.trento.it> ha scritto: > I've noticed that, from Print Composer and saving to JPG with wordfile, the last file is incorrect. There are blank linkes between numbers and after last number two empty line. > See the example in the bug report: > https://issues.qgis.org/issues/22039 Wow! Thank you, Jürgen for fixing this bug so fast! :-) ___ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
