[QGIS-Developer] Call for Grant Proposals 2019

[Anita Graser]

Dear QGIS Community

Our first three rounds of Grant Proposals were a great success. We are very
pleased to announce the fourth round of grants is now available to QGIS
contributors.

Please read the QGIS.ORG blog post for details:
http://blog.qgis.org/2019/05/06/qgis-grants-4-call-for-grant-proposals-2019/

Regards,
Anita Graser
___
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] To Qt or not to Qt? This is the question.

[Alessandro Pasotti]

Hi,

please have a look to https://github.com/qgis/QGIS/pull/9832

I think it's a good opportunity to start (or re-start in case i missed it)
a discussion about:

1. introducing new libraries where QT already provides an implementation
when there is a good reason to
2. using STL and other "modern C++" idioms and deviate from QT when there
is a good reason to

In the particular case of this PR I started from the consideration that
generating json "manually" by string concatenation was not a good idea
because it is error prone and not particularly efficient.
So i started by using QJson* from QT but it was not only very slow but also
it used an ugly syntax.

Moreover, json is becoming the preferred format especially for OGC API
(wfs3) and it is therefore important that we have a solid, efficient and
easy to use library for our json operations.

But, the library that IMO suited best the needs is not from the QT
ecosystem, for example, it uses std::string instead of QString, this is not
a problem for QGIS server because it already has overrides that take C
strings through QIODevive (note that despite the small overhead for the
conversion to/from QString, the new json implementation is still faster
than QJson).
To avoid unnecessary QString<->srd::string conversions, there will probably
be more server-specific overrides in the future.

Even if I started this work with the server in mind, similar considerations
will probably apply to some extent to the desktop as well.

The STL discussion is somewhat related (deviating from QT) but it is an
independent topic, I think we already started to deviate from QT when we
introduced std::unique_ptr, but I'd really like to go further and see more
automatic memory management and more usage of something like (a bit verbose
without typedefs):

std::unique_ptr>>

This of course introduce problems with SIP bindings but this is another
story and we could start by using those idioms for internal implementation
and not for the API.

I'd be interested in what you guys think about these topics, I'm pretty
sure you have also thought about it some times.

Thanks in advance for your feedback!

-- 
Alessandro Pasotti
w3:   www.itopen.it
___
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 virtual layer incredibly slow

[Hugo Mercier]

Hi Andreas and Totò,

Thanks for the confirmation.

I agree this is not well documented. Even the small section in the
manual is a bit ... enigmatic :-/

Andreas' suggestion to have a link in the GUI to the manual seems good.
This, with a bit more explanations in the manual :) I'll see what I can do.

Totò: yes, this hidden column is always there when you create a virtual
layer. An alternative would have been to do as Spatialite does, by
joining on another special table
(https://www.gaia-gis.it/fossil/libspatialite/wiki?name=SpatialIndex),
but I find it even worse.

For something as "transparent" as we have in PostGIS, I think we would
need a query rewriter: something that parses the input SQL query and add
references to _search_frame_ for spatial predicates. That would require
to be compliant with the different SQLite versions (that may have little
differences in their support of SQL) or to ship a fixed version of
SQLite with QGIS.

On 02/05/2019 18:42, Totò Fiandaca wrote:
> Hi Hugo  
> but the _search_frame_ is always usable ?? or only in special cases?
> 
> Il giorno gio 2 mag 2019 alle ore 17:18 Andreas Neumann
> mailto:a.neum...@carto.net>> ha scritto:
> 
> Hi Hugo,
> 
> Indeed  - when I add the test against the _search_frame_ - everthing
> works almost equally fast than within Postgis. Certainly now the
> virtual
> layer suddenly becomes useful and fast enough for us.
> 
> But to be honest - I would never have guessed that. I was searching for
> the "&&" operator that was necessary in the old days of Postgis (the
> bounding box test). Is this something similar?
> 
> Perhaps there should be a visible hint for that in the Virtual layer
> creation dialogue? Googling for it reveals a section in the manual ;-)
> 
> https://docs.qgis.org/3.4/en/docs/user_manual/managing_data_source/create_layers.html#use-of-indexes
> 
> Would be useful to add a button to the dialogue - a button like
> "Performance hints" that would open this section in the manual.
> 
> Many thanks - you will make my colleagues happy! I told them they have
> to do everything in Postgis and not mix data formats.
> 
> Matteo and Toto: can you try if that helps in your cases as well? Would
> be interesting to know.
> 
> Greetings,
> 
> Andreas
> 
> PS: with the 40 seconds before I thought - well - I as a slow human
> might be even faster than that stupid computer. Who knows ... I could
> have been faster! Now with Hugos hint is also a sub-second query.
> 
> Am 02.05.19 um 16:36 schrieb Hugo Mercier:
> > Hi,
> >
> > One big difference between spatialite and PostGIS is that PostGIS is
> > able to use spatial indexes transparently, while spatialite cannot.
> >
> > Could you try with something like " ... AND lie._search_frame_ =
> > tbap.geometry" ?
> >
> >
> > On 02/05/2019 11:02, Andreas Neumann wrote:
> >> Hi,
> >>
> >> One of my colleagues created a QGIS project where they loaded a
> parcel
> >> layer with approx. 24000 polygons (data source Postgis) and another
> >> layer with 3 polygons representing project perimeters of contruction
> >> sites. That second layer is in a Geopackage.
> >>
> >> Now they want to select all parcels that are intersecting the project
> >> perimeters.
> >>
> >> The query is straightforward:
> >>
> >> SELECT lie.nummer_grundstueck, lie.gemeinde, tbap.bemerkungen,
> lie.geometry
> >> FROM lie_liegenschaft lie, tba_projektperimeter tbap
> >> WHERE ST_Intersects(lie.geometry, tbap.geometry)
> >>
> >> Now the problem is: this query (24000 parcels, 3 project
> perimeters) is
> >> just incredibly slow: about 40 seconds. In a Postgis view this
> would be
> >> way less then a second! The worst thing: that virtual layer is
> updated
> >> with each and every zoom and pan. Is there no way to cache a
> virtual layer?
> >>
> >> Can I do something to speed up our virtual layer? The parcel
> layer only
> >> chanes once a month and the perimeters only occasionally, so it
> would be
> >> best to cache the result within a QGIS session, because there are no
> >> changes in the geometries of both layers expected.
> >>
> >> I understand that virtual layers somehow have to transfer all data
> >> formats (through ogr) into SpatiaLite or SQLite to do the query, but
> >> this is really way too slow for real world usage in my opinion
> (unless I
> >> do something wrong in our query).
> >>
> >> If you have any ideas how to speed up virtual layers in QGIS it
> would be
> >> much appreciated.
> >>
> >> Thanks,
> >> Andreas
> >>
> >>
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org
> 
> >> List 

[QGIS-Developer] Plugin [1659] ORS Tools approval notification.

[noreply]

Plugin ORS Tools approval by pcav.
The plugin version "[1659] ORS Tools 1.0.6" is now approved
Link: http://plugins.qgis.org/plugins/ORStools/
___
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] how to make sure QGIS3 is always started by calling qgis.bat and not qgis.exe?

[Thomas Baumann]

Hello QGIS-Devs,

I recently asked a question on gis.stackexchange about how to make sure
that QGIS3 is always started by calling the qgis.bat file:
https://gis.stackexchange.com/questions/321108/check-whether-qgis3-was-started-by-qgis-bat-or-qgis-exe

( The reason why I want to make sure that qgis.bat is used is that I have
added a md5-check which checks the startup.py in the users profile path
against the current startup.py I want to rollout on all clients.)

One idea which was posted on stackexchange was to intentially break the
connection between qgis.exe and the *.env/*.var files qgis expects to find
in order to make sure QGIS can obly be started by calling the qgis.bat file.

I am just wondering if it is safe to use QGIS3 without the information in
the *.env and *.var files or is this rather a bad idea?

Any other ideas how to make sure everyone uses the current startup.py?


regards,

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