[QGIS-Developer] Announcement: OSGeo selected as an umbrella organisation for GSoC 2019

[Werner Macho]

Dear QGIS community,
(and sorry for crossposting)

we’re pleased to announce that OSGeo has been selected as an umbrella
organisation for Google Summer of Code (GSoC) 2019.

@Mentors: In the coming days, we admins will be inviting the mentors
that have filled the form [1]. If you want to be a mentor and haven’t
filled the form yet, please do it *ASAP*.

@All members of the community: be prepared and responsive in the
coming days to welcome students and answer their inquiries. From
Google admins: “Students who engage with their organization early (and
often) are more likely to be accepted and then succeed. We encourage
you to get to know the students and help them get to know you! Please
continue to flesh out your ideas lists and documentation over the next
few weeks.”

Please, forward this email to your developer and community mailing list.

@Students:
According to the official timeline [2], student application period
will be March 25, 2019 - April 9, 2019.

For your convenience, this year you can also download the proposal
template from [3]. After filling the template and detailing the
proposal, it must be submitted following the guidelines given by
Google.

Remember to submit your proposal well in advance, so that you can make
the most out of the feedback from mentors and the community at large
and refine your proposal until final deadline. Read the application
instructions here [4]. The same page contains all the info you need
before taking action, read it all carefully! Good luck everyone!

We admins will be available as always at ,
however, consider using public channels if the topic is not sensitive,
i.e. soc mailing list [5]

We are looking forward to working with you towards another awesome
edition of GSoC!

Kind regards
OSGeo GSoC admins

About GSoC

GSoC [6] is a global program by Google aiming at bringing new
developers to open source organizations. OSGeo’s participation as an
umbrella organization dates back to 2007 edition. Curious to know
more? Browse our wiki pages [7].

[1] https://goo.gl/forms/jMvPl7ns2NG1BL6Q2
[2] https://summerofcode.withgoogle.com/how-it-works/#timeline
[3] https://github.com/OSGeo/gsoc/blob/master/proposal_template.md
[4] 
https://wiki.osgeo.org/wiki/Google_Summer_of_Code_Recommendations_for_Students#Application_instructions
[5] https://lists.osgeo.org/mailman/listinfo/soc
[6] https://summerofcode.withgoogle.com/
[7] https://wiki.osgeo.org/wiki/Category:Google_Summer_of_Code
___
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] Plugin [750] Magnetic Declination approval notification.

[noreply]

Plugin Magnetic Declination approval by pcav.
The plugin version "[750] Magnetic Declination 2.0.1" is now approved
Link: http://plugins.qgis.org/plugins/MagneticDeclination/
___
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] 3.6 changelog

[Paolo Cavallini]

Agreed, an important addition - thanks Andreas!

On 26/02/19 22:06, Andreas Neumann wrote:
> Hi,
> 
> There is also the spreadsheet with the bug fixes done during the paid
> bug fixing effort:
> 
> https://docs.google.com/spreadsheets/d/1F6v4g8Ayb3wIt73rxFKD8h4B95MaTwt-eDit8YvReB0/edit#gid=145548804
> 
> I remember that in older Visual changelog we included them as well.
> 
> Can we do that again? It would give the effort some visibility.
> 
> Can I include that myself and if yes - how?

-- 
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] 3.6 changelog

[Richard Duivenvoorde]

On 27/02/2019 04.41, Nyall Dawson wrote:
> On Tue, 26 Feb 2019 at 17:32, Andrea Aime  
> wrote:
>> Hi Nyall,
>> looking at the changelog I don't see the raster SLD export.
>> We have a guide and screenshots here:
>> https://docs.geoserver.org/latest/en/user/styling/qgis/index.html#exporting-raster-symbology

> This wasn't an intentional omission, it was just committed after I'd
> already populated the list.

To All Devs, Funders and Users,

If you know (or you did) something new is created: just add it yourself.

The changelog is not something that is compiled together by a select
group of devs/psc or so.
Everybody can make a login and add his/her favorite piece!

It's easier for us to take out double items then to add something we are
not even aware of :-)

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] 3.6 changelog

[Nyall Dawson]

On Tue, 26 Feb 2019 at 17:32, Andrea Aime  wrote:
>
> Hi Nyall,
> looking at the changelog I don't see the raster SLD export.
> We have a guide and screenshots here:
> https://docs.geoserver.org/latest/en/user/styling/qgis/index.html#exporting-raster-symbology

This wasn't an intentional omission, it was just committed after I'd
already populated the list.

Nyall

>
> I'm also happy to contribute bits to the document directly, if I have enough 
> access to do so...
> could I do a PR somewhere for example?
>
> Cheers
> Andrea
>
> On Mon, Feb 4, 2019 at 7:39 AM Nyall Dawson  wrote:
>>
>> Hi all,
>>
>> Just the usual release-is-closing-in-fix-your-changelog-entries notification.
>>
>> I've added everything from the git log to
>> http://changelog.qgis.org/en/qgis/version/3.6.0/, the entries just
>> need polishing and screenshots now.
>>
>> 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
>
>
>
> --
>
> Regards, Andrea Aime == GeoServer Professional Services from the experts! 
> Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf 
> Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) 
> phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 
> http://www.geo-solutions.it http://twitter.com/geosolutions_it 
> --- Con riferimento alla 
> normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento 
> generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza 
> inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) 
> è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati 
> dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a 
> cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se 
> potesse darmene notizia. This email is intended only for the person or entity 
> to which it is addressed and may contain information that is privileged, 
> confidential or otherwise protected from disclosure. We remind that - as 
> provided by European Regulation 2016/679 “GDPR” - copying, dissemination or 
> use of this e-mail or the information herein by anyone other than the 
> intended recipient is prohibited. If you have received this email by mistake, 
> please notify us immediately by telephone or e-mail.
___
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] WMTS/XYZ on high DPI screens

[Nyall Dawson]

On Wed, 27 Feb 2019 at 02:24, Martin Dobias  wrote:

> Other solution would be to introduce a new flag for WMTS/XYZ layers
> where users could set native DPI. By default this flag would be
> disabled, but for services like OSM one could explicitly set their DPI
> to 96 and get the tiles scaled accordingly. This would need an update
> of raster block request API as well where we would also need to
> specify output DPI in addition to output width/height (but that should
> not be a big deal).
>

So I'm guessing this setting would apply in print layouts too?
Regardless of the output resolution, it would be exported as though
it's at 96 dpi?

I have a vague feeling that Sourcepole's albiero fork implemented
something similar to this... some possibly related commits are

https://github.com/sourcepole/kadas-albireo/commit/09bb1c82f296f736ce8ecc07f03b03fc5861ddd3
https://github.com/sourcepole/kadas-albireo/commit/09a4cb0bac5fe8a6c2563f811171804044c60d65
https://github.com/sourcepole/kadas-albireo/commit/09bb1c82f296f736ce8ecc07f03b03fc5861ddd3

Nyall


> This solution could also work nicely with services that provide
> high-res tiles (using 512x512 for each tile instead of 256x256) -
> right now QGIS thinks they are 256x256 so instead of a magnifying
> glass one needs a microscope - you can try it [1]. Setting explicitly
> DPI of high-res tiles to 192 DPI should also fix also that issue.
>
> My only worry is if this setting is not going to be too difficult to
> use for ordinary users... But maybe a combo box would make the choice
> easier: "Normal resolution (96 DPI)" / "High resolution (192 DPI)" /
> "Custom resolution" (with a spin box).
>
> Are there any opinions / ideas how to deal with that?
>
> Cheers
> Martin
>
> [1] https://tile.osmand.net/hd/{z}/{x}/{y}.png
> ___
> 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

[QGIS-Developer] QEP 140: QGIS Processing standalone executable

[Nyall Dawson]

Hi all,

Just a heads up for a newly filed QEP regarding a standalone tool for
executing QGIS Processing algorithms outside of the desktop GUI
application. Read the full details and comment here:

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/140

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] New Doxygen policies

[Nyall Dawson]

Hi all,

Following the merge of https://github.com/qgis/QGIS/pull/9269, this is
a notice regarding new practices regarding doxygen comments which
should be adhered to in all 3.8+ code.

The PR introduces some doxygen macro values, TRUE, FALSE and NULLPTR
(all caps). These should be used when dox mention true, false or
nullptr literal values, instead of "true", "false" or "nullptr". E.g.

 /*
  * Returns TRUE if something, FALSE otherwise.
 */

The macros expand out to "\c true", "\c false" and "\c nullptr" for
the c++ dox, and ``True``, ``False`` and ``None`` for Python
docstrings and the Python API docs. Basically, they apply the correct
formatting for literal values and ensure that the language-correct
values are used in the corresponding docs (Python users should never
have to care what a nullptr is!).

I've bulk updated all existing dox, but please stick to the new
strings when writing new dox.

Finally, we should consistently use "returns NULLPTR"/"set to NULLPTR"
instead of "returns a NULLPTR"/"set to a NULLPTR" (no "a"), because
otherwise the Python dox expand to the awkward phrasing: "returns a
None"/"set to a None".

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] Algorithms help files not available for translation

[Jürgen E . Fischer]

Hi Harrissou,

On Tue, 26. Feb 2019 at 16:45:17 +0100, DelazJ wrote:
> Me again. Nobody knows?

https://github.com/qgis/QGIS/commit/2f431bc1f36f45b9bf6639691106e9975687817d


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Nordenhttps://www.norbit.de


signature.asc
Description: PGP signature
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/83/
___
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] 3.6 changelog

[Andreas Neumann]

Hi,

There is also the spreadsheet with the bug fixes done during the paid 
bug fixing effort:


https://docs.google.com/spreadsheets/d/1F6v4g8Ayb3wIt73rxFKD8h4B95MaTwt-eDit8YvReB0/edit#gid=145548804

I remember that in older Visual changelog we included them as well.

Can we do that again? It would give the effort some visibility.

Can I include that myself and if yes - how?

Thanks,
Andreas

Am 26.02.19 um 20:06 schrieb Tim Sutton:

I fixed the SLD not appearing issue:

http://changelog.qgis.org/en/qgis/version/3.6.0/#sld-export-for-raster-styles

Regards

Tim

On 26 Feb 2019, at 20:58, Richard Duivenvoorde > wrote:


On 26/02/2019 19.56, Etienne Trimaille wrote:
Le mar. 26 févr. 2019 à 14:52, Richard Duivenvoorde 
mailto:rdmaili...@duif.net>

> a écrit :


   It is a django app, if you create a login (and sent me your 
username),

   we can give you enough rights to edit yourself:


Did the rule change recently?
Before, anyone with a login could add an entry.


Yes, it should but that always has been buggy: people could add an
entry, but after that could not see/edit it anymore. What we did earlier
was make people (we knew) provide admin rights or so.

But maybe first try and see

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


—







*Tim Sutton*

*Co-founder:*Kartoza
*Ex Project chair:*QGIS.org 

Visit http://kartoza.com  to find out about open 
source:


Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

*Skype*: timlinux
*IRC:*timlinux on #qgis at freenode.net 


___
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] WMTS/XYZ on high DPI screens

[Martin Dobias]

Hi Matthias

Thanks for your thoughts...

On Tue, Feb 26, 2019 at 5:49 PM Matthias Kuhn  wrote:

> If I understand you correctly, the scaling that you see on OSM is only
> done on client side (in javascript)?
>
Yes this is handled by the client map library. In Javascript there's
window.devicePixelRatio property that gives you ratio between physical
pixels and CSS pixels (i.e. 1 for 96 dpi, 2 for 192 dpi). And if you have
high dpi tiles, then e.g. in OpenLayers you can set WMTS layer's
option tilePixelRatio to 2:
https://openlayers.org/en/latest/examples/wmts-hidpi.html


> This solution could also work nicely with services that provide
> high-res tiles (using 512x512 for each tile instead of 256x256) -
> right now QGIS thinks they are 256x256 so instead of a magnifying
> glass one needs a microscope - you can try it [1]. Setting explicitly
> DPI of high-res tiles to 192 DPI should also fix also that issue.
>
> That sounds like a promising path.
>
> Alternatively, I was wondering if this could be done on layer/renderer
> level instead of provider level, with no provider changes involved, as a
> "magnification factor" on the layer. The advantage would be that it could
> be applied to any raster format (WMS or even local tif files generated
> using the "Convert map to raster" processing algorithm).
>
I was playing with this idea of magnification too. But with plain
magnification the problem is that the projects would not be portable - if I
have high-res screen and give my project to someone else with low-res
screen, the magnification factor would make tiles too large for them. So
rather than magnification factor it would need to be again something more
like reference DPI for a layer.

And I still think we need to have the DPI information in raster providers
so that they can pick the correct resolution. For example with a WMS layer
I would prefer if WMS server gives me the image for 192 DPI rather than it
would request it for 96 DPI and then just scale it - and for this to be
possible I think the DPI information needs to be propagated with raster
block requests into providers.


> Just an idea, I didn't look into if/how this is doable code-wise.
>
> My only worry is if this setting is not going to be too difficult to
> use for ordinary users... But maybe a combo box would make the choice
> easier: "Normal resolution (96 DPI)" / "High resolution (192 DPI)" /
> "Custom resolution" (with a spin box).
>
> I wouldn't worry too much about that and rather have a clean and powerful
> API.
>
> - anything can be hidden in an advanced box in the beginning
>
> - Configuring those is advanced magic anyway, QMS and whatever comes along
> to ease the configuration can ship those parameters pre-filled so the user
> does not need to care about it
>
Yeah prepared configs from QMS can indeed make things easier.

The current state of varying DPI support in common protocols seems to be
quite poor:
- WMS 1.3 / WMTS 1.0 protocols simply assume that pixel size is 0.28
millimeters wide (that is ~90 DPI)
- there are custom extensions to WMS protocol to pass DPI to it (MapServer,
GeoServer, QGIS server all use different syntax)
- XYZ has no standardization either. I think some people use convention
http://example/layer/z/x/y.png for normal tiles and
http://example/layer@2x/z/x/y.png for high-dpi tiles (device pixel ratio
2), but this is far from being standard
- ArcGIS REST map service seems to report DPI for tilesets ("tileInfo" ->
"dpi")

In terms of support in QGIS API and implementation:
- QgsRasterDataProvider has setDpi() method which is used in raster layer
rendering. This approach is quite coarse as it sets DPI for the whole data
provider, while the DPI should be ideally set per raster block request
- the value from setDpi() is only used by WMS provider
- DPI information reported by ArcGIS REST service is not used in QGIS

Cheers
Martin
___
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] pylupdate5 Error

[Jorge Almerio]

Hi devs,

 

How to use 'pylupdate5' as described in the documentation

https://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/plugins.html?#ts-file

?

 

It's not recognized on my OSGeo Shell terminal. Only pylupdate4 is working

 

___
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] 3.6 changelog

[Tim Sutton]

I fixed the SLD not appearing issue:

http://changelog.qgis.org/en/qgis/version/3.6.0/#sld-export-for-raster-styles

Regards

Tim

> On 26 Feb 2019, at 20:58, Richard Duivenvoorde  wrote:
> 
> On 26/02/2019 19.56, Etienne Trimaille wrote:
>> Le mar. 26 févr. 2019 à 14:52, Richard Duivenvoorde > > a écrit :
>> 
>> 
>>It is a django app, if you create a login (and sent me your username),
>>we can give you enough rights to edit yourself:
>> 
>> 
>> Did the rule change recently?
>> Before, anyone with a login could add an entry.
> 
> Yes, it should but that always has been buggy: people could add an
> entry, but after that could not see/edit it anymore. What we did earlier
> was make people (we knew) provide admin rights or so.
> 
> But maybe first try and see
> 
> Richard
> ___
> 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

—








Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

Visit http://kartoza.com  to find out about open source:

Desktop GIS programming services
Geospatial web development
GIS Training
Consulting Services

Skype: timlinux 
IRC: timlinux on #qgis at freenode.net

___
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] 3.6 changelog

[Richard Duivenvoorde]

On 26/02/2019 19.56, Etienne Trimaille wrote:
> Le mar. 26 févr. 2019 à 14:52, Richard Duivenvoorde  > a écrit :
> 
> 
> It is a django app, if you create a login (and sent me your username),
> we can give you enough rights to edit yourself:
> 
> 
> Did the rule change recently?
> Before, anyone with a login could add an entry.

Yes, it should but that always has been buggy: people could add an
entry, but after that could not see/edit it anymore. What we did earlier
was make people (we knew) provide admin rights or so.

But maybe first try and see

Richard
___
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] 3.6 changelog

[Etienne Trimaille]

Le mar. 26 févr. 2019 à 14:52, Richard Duivenvoorde  a
écrit :

>
> It is a django app, if you create a login (and sent me your username),
> we can give you enough rights to edit yourself:
>

Did the rule change recently?
Before, anyone with a login could add an entry.
___
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] 3.6 changelog

[Richard Duivenvoorde]

On 26/02/2019 08.31, Andrea Aime wrote:
> Hi Nyall,
> looking at the changelog I don't see the raster SLD export.
> We have a guide and screenshots here:
> https://docs.geoserver.org/latest/en/user/styling/qgis/index.html#exporting-raster-symbology
> 
> I'm also happy to contribute bits to the document directly, if I have
> enough access to do so... 
> could I do a PR somewhere for example?

Hi Andrea,

It is a django app, if you create a login (and sent me your username),
we can give you enough rights to edit yourself:

http://changelog.qgis.org/en/accounts/signup/

I just added a a simple line and item now. Let me know if you want it to
be changed (added GeoSolutions as funder, could be developer too)

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] WMTS/XYZ on high DPI screens

[Matthias Kuhn]

Hi Martin

Interesting topic.

On 2/26/19 5:23 PM, Martin Dobias wrote:
> Hi all
>
> Whenever I use a background map like OpenStreetMap on my high-res
> laptop screen (192 DPI) in QGIS, the labels are tiny. That is
> "natural" because tiles are made for screens with ~96 DPI where the
> size of labels is just fine. When I look at OSM tiles in the browser,
> I can see that the browser displays the tiles scaled ... so even
> though the tiles do not look super crisp, at least I do not need a
> magnifying glass to read labels.
>
> A similar problem I have encountered before is when using tiles from
> WMTS/XYZ in print/PDF output: with higher resolution of print the
> rendering engine picks very detailed tiles which again may contain
> very tiny labels.

If I understand you correctly, the scaling that you see on OSM is only
done on client side (in javascript)?


> I would like to fix this in QGIS but I am wondering what would be the
> correct approach.
>
> One simple (and wrong?) solution would be to just scale tiles of all
> tile layers, but I guess if the service displays some raw imagery it
> would be wasteful to scale them as this unnecessarily would remove
> details which could be still shown on high res display.
Agreed!
>
> Other solution would be to introduce a new flag for WMTS/XYZ layers
> where users could set native DPI. By default this flag would be
> disabled, but for services like OSM one could explicitly set their DPI
> to 96 and get the tiles scaled accordingly. This would need an update
> of raster block request API as well where we would also need to
> specify output DPI in addition to output width/height (but that should
> not be a big deal).
>
> This solution could also work nicely with services that provide
> high-res tiles (using 512x512 for each tile instead of 256x256) -
> right now QGIS thinks they are 256x256 so instead of a magnifying
> glass one needs a microscope - you can try it [1]. Setting explicitly
> DPI of high-res tiles to 192 DPI should also fix also that issue.
That sounds like a promising path.

Alternatively, I was wondering if this could be done on layer/renderer
level instead of provider level, with no provider changes involved, as a
"magnification factor" on the layer. The advantage would be that it
could be applied to any raster format (WMS or even local tif files
generated using the "Convert map to raster" processing algorithm).

Just an idea, I didn't look into if/how this is doable code-wise.

> My only worry is if this setting is not going to be too difficult to
> use for ordinary users... But maybe a combo box would make the choice
> easier: "Normal resolution (96 DPI)" / "High resolution (192 DPI)" /
> "Custom resolution" (with a spin box).

I wouldn't worry too much about that and rather have a clean and
powerful API.

- anything can be hidden in an advanced box in the beginning

- Configuring those is advanced magic anyway, QMS and whatever comes
along to ease the configuration can ship those parameters pre-filled so
the user does not need to care about it

Best regards

Matthias

>
> Are there any opinions / ideas how to deal with that?
>
> Cheers
> Martin
>
> [1] https://tile.osmand.net/hd/{z}/{x}/{y}.png
> ___
> 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
>
-- 
Matthias Kuhn
matth...@opengis.ch 
+41 (0)76 435 67 63 
OPENGIS.ch Logo 
___
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] WMTS/XYZ on high DPI screens

[Martin Dobias]

Hi all

Whenever I use a background map like OpenStreetMap on my high-res
laptop screen (192 DPI) in QGIS, the labels are tiny. That is
"natural" because tiles are made for screens with ~96 DPI where the
size of labels is just fine. When I look at OSM tiles in the browser,
I can see that the browser displays the tiles scaled ... so even
though the tiles do not look super crisp, at least I do not need a
magnifying glass to read labels.

A similar problem I have encountered before is when using tiles from
WMTS/XYZ in print/PDF output: with higher resolution of print the
rendering engine picks very detailed tiles which again may contain
very tiny labels.

I would like to fix this in QGIS but I am wondering what would be the
correct approach.

One simple (and wrong?) solution would be to just scale tiles of all
tile layers, but I guess if the service displays some raw imagery it
would be wasteful to scale them as this unnecessarily would remove
details which could be still shown on high res display.

Other solution would be to introduce a new flag for WMTS/XYZ layers
where users could set native DPI. By default this flag would be
disabled, but for services like OSM one could explicitly set their DPI
to 96 and get the tiles scaled accordingly. This would need an update
of raster block request API as well where we would also need to
specify output DPI in addition to output width/height (but that should
not be a big deal).

This solution could also work nicely with services that provide
high-res tiles (using 512x512 for each tile instead of 256x256) -
right now QGIS thinks they are 256x256 so instead of a magnifying
glass one needs a microscope - you can try it [1]. Setting explicitly
DPI of high-res tiles to 192 DPI should also fix also that issue.

My only worry is if this setting is not going to be too difficult to
use for ordinary users... But maybe a combo box would make the choice
easier: "Normal resolution (96 DPI)" / "High resolution (192 DPI)" /
"Custom resolution" (with a spin box).

Are there any opinions / ideas how to deal with that?

Cheers
Martin

[1] https://tile.osmand.net/hd/{z}/{x}/{y}.png
___
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 server deployment

[Eric Lemoine]

> Hi all,
> 
> I'm not a sysadmin but for our customers I'd like find the better way
> for deploy QGIS-server 3.
> 
> I try at least 3 ways:
> 
> 1) Apache2 + libapache2-mod-fcgid


There is Apache2 + mod_proxy_fcgi that you could use as well. As
opposed to mod_fcgid, mod_proxy_fcgi requires that you use your own
method for starting the FastCGI process(es) (QGIS Server here). In this
regard mod_proxy_fcgi is very similar to NGINX-based setups.


> 2) Nginx + fcgiwrap

I recently added a note to the QGIS Server docs [0] that recommends
against fcgiwrap. fcgiwrap is very slow, because it creates a new QGIS
Server process on each request!

[0]


> 
> 3) Nginx + QGIS-Server working by socket/service (systemd)


I like this one a lot, because it doesn't require anything else than
systemd, which has become very very common on Linux distros. I even
wrote a blog post about it :-) See [1].

[1]



> 
> By delveloper side, what do you think is the best?


As already said I like the systemd-only method because it doesn't
require more than systemd, which you probably already have and use on
your Linux system.

spawn-fcgi works great as well, but you will need to use something like
supervisord, or write a systemd system unit for it.


> 
> I'd like to much 3) solution, but I found some problems, in
> particular, how many sockects I've to create watching at my server?
> (Number of processors )


I'd recommend using one QGIS Server process per processor, or even a
few more for more parallelism during I/O operations. For example with 4
processors I think you can use 6-8 QGIS Server processes.


> For 1) and 2) have you experiences on performance and tuning?

Don't use 2 :-) I don't have much experience with 1 so I won't comment.
But Patrick's suggestions sound very good to me :)

One final note: at Oslandia we either use NGINX + systemd, or NGINX +
spawn-fcgi when running QGIS Server in Docker container. If you want
to use Docker I'd recommend taking a look at [2], which explains how we
build and run QGIS Server using Docker.

[2] 

Good luck!

-- 
Éric Lemoine
Oslandia
+33 1 86 95 95 55


pgpLGpuheJdzp.pgp
Description: OpenPGP digital signature
___
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] Algorithms help files not available for translation

[DelazJ]

Hi,

Me again. Nobody knows?

Harrissou

Le lun. 25 févr. 2019 à 06:04, DelazJ  a écrit :

> Hi devs,
>
> A user who wanted to translate some strings in QGIS 3.4 contacted me
> because he could not find them. Giving it a look, it looks like no text
> from the
> https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/help/qgis.yaml
> is available for translation (I couldn't find them neither in transifex nor
> in the ts file), condemning us to feed our users with only English help
> texts, for their first contact with algs. Not nice imho.
>
> Is that a bug or some kind of limitations? Otherwise any chance to get
> this fixed in master and backported, please?
> Thanks,
>
> Harrissou
>
___
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] Plugin [354] OSM place search approval notification.

[noreply]

Plugin OSM place search approval by pcav.
The plugin version "[354] OSM place search 1.2.6 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/nominatim/
___
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] Python script to count the number of feature for each unique values

[kimaidou]

Thanks a lot Nyall, setting the NoGeometry flags and subset of fields does
improve the speed by factor 3 for my test layer ( 300k features and 80 (!)
fields )

Regards
Michaël

Le lun. 25 févr. 2019 à 23:48, Nyall Dawson  a
écrit :

> On Tue, 26 Feb 2019 at 03:31, kimaidou  wrote:
> >
> > Hi all,
> >
> > I needed to gather basic stats for a layer containing multiple fields. I
> created the following gist to compute the number of features per each
> unique value for a list of given fields
> > https://gist.github.com/mdouchin/a234efb7e67ebd8dae3a04cb26cf5e72
>
> Checkout trap #3 from
> http://nyalldawson.net/2016/10/speeding-up-your-pyqgis-scripts/.
> Specifically, since you aren’t doing anything with the geometry, and
> are only using a single attribute from the layer, by calling setFlags(
> QgsFeatureRequest.NoGeometry ) and setSubsetOfAttributes() you can
> tell QGIS that you don’t need the geometry, and only require a single
> attribute’s value in the feature request. This will give a huge speed
> boost to the feature fetching.
>
> > I know I could use PostgreSQL to do it (see
> https://twitter.com/kimaidou/status/1100053546978983936 conversation),
> wich is much faster, but I needed a quick way to do it with Python.
> > I tested virtual layers too, but my source layer has many fields (with
> some heavy data) and the copy/pasting into spatialite was not efficient
> here.
> >
> > The method uniqueValues(fieldIndex) of QgsVectorLayer is pretty fast
> compared to my iteration through the layer features. Any hint how to
> improve the speed of my calculation ?
>
> Potentially this could be a new method in QgsVectorDataProvider which
> sends a native query to be executed on the backend (like uniqueValues
> does -- that's why it's so fast). But that would require an addition
> to the c++ QgsVectorDataProvider class, and implementations in the
> popular vector data providers.
>
> Nyall
>
> >
> > Regards,
> > Michaël
> > ___
> > 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] OSGeo4W, sip update 4.19.14

[Matthias Kuhn]

On 25.02.19 21:35, Jürgen E. Fischer wrote:


Hi Matthias,

On Mon, 25. Feb 2019 at 09:25:22 +0100, Matthias Kuhn wrote:

Would it be possible to upgrade sip to the latest version on OSGeo4W
(and any other builds where we ship sip ourselves)? If I can do
something to help, please let me know!

Done.


Thanks a lot also :)

Matthias




Jürgen


___
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] 2.18 API Docs Broken

[Matthias Kuhn]

On 25.02.19 20:20, Jürgen E. Fischer wrote:


Hi Matthias,

On Mon, 25. Feb 2019 at 17:14:17 +0100, Matthias Kuhn wrote:

https://qgis.org/api/2.18

becomes

https://qgis.org/api/2.18/index.html/index.html/index.html/index.html/index.html/index.html/index.html/index.html/[...]

Check again please.


Thanks a lot, Jürgen!

Matthias




Jürgen


___
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] QGIS server deployment

[Walter Lorenzetti]

Ciao Daniele,

Il 25/02/19 14:43, Daniele Viganò ha scritto:

Ciao Walter,

we use 5) Nginx + spawn-fcgi (a lighttpd project) in multiple Docker 
containers [0]. As a thumb rule I use one process per Docker with 
number of QGIS threads equal to the available CPU 'cores' and a number 
of Docker containers also equal to the number of CPUs. It depends 
anyway much on the workload (i.e. long running requests vs quick ones).



This is clear :)

When not using containers I would go for 3) nginx + systemd.


In example if you have 4 cores you create 4 qgis-server socks file and 
put every soscks in a nginx upstream:


upstream qgis_mapserv_backend {
    server unix:/run/qgis-server1.sock;
    server unix:/run/qgis-server2.sock;
    server unix:/run/qgis-server3.sock;
    server unix:/run/qgis-server4.sock;
}

In this way?

Grazie

W



Cheers,
Daniele

[0] https://github.com/gem/oq-qgis-server#qgis-3-server-via-docker

On Mon, Feb 25, 2019 at 11:15 AM Walter Lorenzetti 
mailto:lorenze...@gis3w.it>> wrote:


Hi all,

I'm not a sysadmin but for our customers I'd like find the better
way for deploy QGIS-server 3.

I try at least 3 ways:

1) Apache2 + libapache2-mod-fcgid

2) Nginx + fcgiwrap

3) Nginx + QGIS-Server working by socket/service (systemd)

By delveloper side, what do you think is the best?

I'd like to much 3) solution, but I found some problems, in
particular, how many sockects I've to create watching at my
server? (Number of processors )

For 1) and 2) have you experiences on performance and tuning?

Thanks in advance and thanks for work!

W

-- 


Walter Lorenzetti phD
email: lorenze...@gis3w.it 
skype: aiki74
twitter:w_lorenzetti 
g+:aiki74 
Tel/Cell: (+39) 347-6597931
Viale Verdi 24 - 51016 Montecatini Terme (PT)
Nuovi corsi QGIS e GFOSS


___
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



--
*Daniele Viganò*
http://daniele.vigano.me

--

Walter Lorenzetti phD
email: lorenze...@gis3w.it
skype: aiki74
twitter:w_lorenzetti 
g+:aiki74 
Tel/Cell: (+39) 347-6597931
Viale Verdi 24 - 51016 Montecatini Terme (PT)
Nuovi corsi QGIS e GFOSS 



___
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 server deployment

[Walter Lorenzetti]

Hi René,

thank you for reply, I used only one time supervisord for a project. The 
4th way it'd be very nice :). Thanks.


W

Il 25/02/19 11:28, René-Luc Dhont ha scritto:

Hi Walter,

We, at 3Liz, use the 3) with supervisord and the number of process is 
based on the number of preocessors.


But we also used for QGIS3 a 4th way, a python server based on 
tronado: https://github.com/3liz/py-qgis-server


Regards,

René-Luc
https://github.com/rldhont

Le 25/02/2019 à 11:08, Walter Lorenzetti a écrit :


Hi all,

I'm not a sysadmin but for our customers I'd like find the better way 
for deploy QGIS-server 3.


I try at least 3 ways:

1) Apache2 + libapache2-mod-fcgid

2) Nginx + fcgiwrap

3) Nginx + QGIS-Server working by socket/service (systemd)

By delveloper side, what do you think is the best?

I'd like to much 3) solution, but I found some problems, in 
particular, how many sockects I've to create watching at my server? 
(Number of processors )


For 1) and 2) have you experiences on performance and tuning?

Thanks in advance and thanks for work!

W

--

Walter Lorenzetti phD
email: lorenze...@gis3w.it
skype: aiki74
twitter:w_lorenzetti 
g+:aiki74 
Tel/Cell: (+39) 347-6597931
Viale Verdi 24 - 51016 Montecatini Terme (PT)
Nuovi corsi QGIS e GFOSS 




___
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

--

Walter Lorenzetti phD
email: lorenze...@gis3w.it
skype: aiki74
twitter:w_lorenzetti 
g+:aiki74 
Tel/Cell: (+39) 347-6597931
Viale Verdi 24 - 51016 Montecatini Terme (PT)
Nuovi corsi QGIS e GFOSS 



___
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 server deployment

[Walter Lorenzetti]

Hi Patrick,

thanks for FcgidMaxRequestsPerProcess indication, so for processes you 
set FcgidMaxProcesses or FcgidMaxProcessesPerClass?


In example FcgidMaxProcesses 4 if cores are 4?

Do you have docker file for qgis-server image that you post here?

Thanks

W

Il 25/02/19 11:54, Patrick Valsecchi ha scritto:
On the camptocamp side, we use 1) within a docker image: 
https://cloud.docker.com/u/camptocamp/repository/docker/camptocamp/qgis-server


What I strongly recommend is to add a FcgidMaxRequestsPerProcess with 
a value of 1000 (work around some potential  memory leaks in QGIS). 
I'd say to set the number of processes to the number of CPU cores.


On Mon, Feb 25, 2019 at 11:29 AM René-Luc Dhont > wrote:


Hi Walter,

We, at 3Liz, use the 3) with supervisord and the number of process
is based on the number of preocessors.

But we also used for QGIS3 a 4th way, a python server based on
tronado: https://github.com/3liz/py-qgis-server

Regards,

René-Luc
https://github.com/rldhont

Le 25/02/2019 à 11:08, Walter Lorenzetti a écrit :


Hi all,

I'm not a sysadmin but for our customers I'd like find the better
way for deploy QGIS-server 3.

I try at least 3 ways:

1) Apache2 + libapache2-mod-fcgid

2) Nginx + fcgiwrap

3) Nginx + QGIS-Server working by socket/service (systemd)

By delveloper side, what do you think is the best?

I'd like to much 3) solution, but I found some problems, in
particular, how many sockects I've to create watching at my
server? (Number of processors )

For 1) and 2) have you experiences on performance and tuning?

Thanks in advance and thanks for work!

W

-- 


Walter Lorenzetti phD
email: lorenze...@gis3w.it 
skype: aiki74
twitter:w_lorenzetti 
g+:aiki74 
Tel/Cell: (+39) 347-6597931
Viale Verdi 24 - 51016 Montecatini Terme (PT)
Nuovi corsi QGIS e GFOSS



___
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


___
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

--

Walter Lorenzetti phD
email: lorenze...@gis3w.it
skype: aiki74
twitter:w_lorenzetti 
g+:aiki74 
Tel/Cell: (+39) 347-6597931
Viale Verdi 24 - 51016 Montecatini Terme (PT)
Nuovi corsi QGIS e GFOSS 



___
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] Programmaticaly open the Log Panel

[Tejas L]

Hi Richard,

That worked perfectly, thanks!

When developing plugins I always find myself opening the Log window and the 
Python console, after I start up QGIS. It would be nice to have a way to save 
the panel layout. At the moment though, your code snippet is sufficient for my 
needs.

Regards,
Tej


From: Richard Duivenvoorde 
Sent: Tuesday, February 26, 2019 3:19 AM
To: qgis-developer@lists.osgeo.org
Cc: tej...@live.com
Subject: Re: [QGIS-Developer] Programmaticaly open the Log Panel

On 25/02/2019 09.57, Tejas L wrote:
> Hello team,
>
> I would like to automatically open the Log Panel whenever Qgis starts.
> Is there a way to do this?

Hi,

For what I know there is no api call for it directly, but you can search
for child widgets in the main panel, something like this:

for widget in iface.mainWindow().children():
if widget.objectName() == 'MessageLog':
widget.show()

Or shorter (but trickier):

iface.mainWindow().findChild(QDockWidget, 'MessageLog').show()

With me this pops up the Messagelog Panel (though then you do not have
your tab yet, but that is a child of that one probably...)

Regards,

Richard Duivenvoorde

Ps what do you want to use it for, because more people see the use of it
maybe we can just add it (or ask to be added?)?
___
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