Re: [QGIS-Developer] WMTS/XYZ on high DPI screens

2019-02-27 Thread Martin Dobias
Hi Nyall

On Wed, Feb 27, 2019 at 4:40 AM Nyall Dawson  wrote:
>
> 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?

Yes, that's correct - print output would be affected too. That means
that tiles from a regular XYZ service would be scaled up. Now this is
something I am not 100% sure about how this should work. On one hand
scaling tiles up is useful with tile layers containing labels (they
will have the same size as on the screen), on the other hand for some
tiles this may not be desired (scaling them up would just reduce their
resolution).

I am wondering if we should have three options for tile resolutions:
- standard (96 DPI) ... autoscaled, for 256x256 tiles for XYZ tiles
- high res (192 DPI) ... autoscaled, for 512x512 tiles for XYZ tiles
- undefined ... not scaled

This should hopefully handle all the cases. I am not sure though which
option should be the default. For compatibility reasons (not to break
existing behavior of QGIS) probably it would be good to have
"undefined" as the default with no scaling of tiles on screen nor for
print. Only when deliberately switched to standard / high res
resolution we would apply scaling.


> 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

Thanks for the pointer to those commits! There seems to be a mix of
behaviors with somewhat arbitrary threshold of 225 DPI (I guess
assuming screens are < 225 while printing uses > 225). If I read the
code correctly, for screens it would not apply any scaling, but for
print it would scale tiles up. Not sure why the logic is designed this
way...

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

Re: [QGIS-Developer] WMTS/XYZ on high DPI screens

2019-02-27 Thread Martin Dobias
Hi Richard

On Wed, Feb 27, 2019 at 10:47 AM Richard Duivenvoorde
 wrote:
>
> not sure if this is helpfull, but Matthijs of the OpenGeoGroep.nl
> created a hidpi tilecache for mac users not so long ago for an Dutch,
> osm based base map. I asked him what he did.  He says (translated):
>
> "Yes we serve two versions, eg"
>
> http://www.openbasiskaart.nl/mapcache/wmts/?SERVICE=WMTS=GetTile=1.0.0=osm-nb=default=rd=5=16=15=image%2Fpng
>
> http://www.openbasiskaart.nl/mapcache/wmts/?SERVICE=WMTS=GetTile=1.0.0=osm-nb-hq=default=rd-hq=5=16=15=image%2Fpng

Thanks for this - good to have also a WMTS service for testing. HQ
tiles look nice and crisp compared to the standard version :-)


> "Only the tileing protocol metadata is not really prepeared for HQ
> tiles. I now set it up i a way that for HiDPI tiles you have use the
> same TILEMATRIX, TILEROW en TILEROW, but you receive either a 256x256
> tile or a 512x512 tile depending on the TILEMATRIXSET. But you have to
> fool the tile server a little, so if you use current URL
> (http://www.openbasiskaart.nl/mapcache and layer with HQ in QGIS) you
> get big labels."

Yeah if I am not wrong that's the limitation of WMTS protocol - it
does not tell you the true DPI (you _should_ assume 90 DPI according
to the standard). For a WMTS offering mixed bag of tile resolutions I
am not sure what would be the best solution - a single DPI setting for
the whole connection won't work well - you would need two
connections... one for normal-res tiles, the other for high-res tiles.
Another solution could be per tileset configuration of true DPI, but
that would be even more complicated...

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] Plugin [1163] Plugin Load Times approval notification.

2019-02-27 Thread noreply

Plugin Plugin Load Times approval by pcav.
The plugin version "[1163] Plugin Load Times 3.0.0" is now approved
Link: http://plugins.qgis.org/plugins/PluginLoadTimes/
___
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 [1642] QCopycanvas approval notification.

2019-02-27 Thread noreply

Plugin QCopycanvas approval by pcav.
The plugin version "[1642] QCopycanvas 0.1" is now approved
Link: http://plugins.qgis.org/plugins/QCopycanvas/
___
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] Plugin site down

2019-02-27 Thread Alessandro Pasotti
I wonder if spinning up an AWS for the heavy duty tasks (and switch it off
when done) would be the right thing to do here.


On Wed, Feb 27, 2019 at 4:32 PM Richard Duivenvoorde 
wrote:

> On 27/02/2019 15.25, Paolo Cavallini wrote:
> > 504 Gateway Time-out
> >
> > is it my impression, or this is happening rather often recently?
> > any way to fix it more permanently?
>
> We use the qgis2 server for several purposes. So IF a lot of people are
> viewing/using plugins or qgis site, and we are building
> docs/website/packages it get's crowded.
>
> To fix this we could rent another server, or move the plugins dir to
> another existing server (like the issue tracker (qgis3) or test server
> (qgis4)) Another server is another 600 dollar per year
>
> 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



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

[QGIS-Developer] Plugin [1642] QCopycanvas approval notification.

2019-02-27 Thread noreply

Plugin QCopycanvas approval by pcav.
The plugin version "[1642] QCopycanvas 0.2" is now approved
Link: http://plugins.qgis.org/plugins/QCopycanvas/
___
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] Plugin site down

2019-02-27 Thread Richard Duivenvoorde
On 27/02/2019 15.25, Paolo Cavallini wrote:
> 504 Gateway Time-out
> 
> is it my impression, or this is happening rather often recently?
> any way to fix it more permanently?

We use the qgis2 server for several purposes. So IF a lot of people are
viewing/using plugins or qgis site, and we are building
docs/website/packages it get's crowded.

To fix this we could rent another server, or move the plugins dir to
another existing server (like the issue tracker (qgis3) or test server
(qgis4)) Another server is another 600 dollar per year

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] Plugin site down

2019-02-27 Thread Paolo Cavallini
Thanks Richard for the explanation. I would expect the load will only
increase over time.
The investment seems reasonable to me. Are there alternatives, like
moving some of the heavy load to a public, free-as-beer service?
All the best.

On 27/02/19 16:32, Richard Duivenvoorde wrote:
> On 27/02/2019 15.25, Paolo Cavallini wrote:
>> 504 Gateway Time-out
>>
>> is it my impression, or this is happening rather often recently?
>> any way to fix it more permanently?
> 
> We use the qgis2 server for several purposes. So IF a lot of people are
> viewing/using plugins or qgis site, and we are building
> docs/website/packages it get's crowded.
> 
> To fix this we could rent another server, or move the plugins dir to
> another existing server (like the issue tracker (qgis3) or test server
> (qgis4)) Another server is another 600 dollar per year
-- 
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] Plugin [1660] Pelias Geocoding approval notification.

2019-02-27 Thread noreply

Plugin Pelias Geocoding approval by pcav.
The plugin version "[1660] Pelias Geocoding 0.1" is now approved
Link: http://plugins.qgis.org/plugins/PeliasGeocoding/
___
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 [1659] ORS Tools approval notification.

2019-02-27 Thread noreply

Plugin ORS Tools approval by pcav.
The plugin version "[1659] ORS Tools 1.0.0" 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] Plugin site down

2019-02-27 Thread Paolo Cavallini
504 Gateway Time-out

is it my impression, or this is happening rather often recently?
any way to fix it more permanently?
Thanks.
-- 
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] WFS DescribeFeatureType Compliance question

2019-02-27 Thread Andreas Neumann
Hi Even, 

We tried to add the qgs namespace as a prefix: 

qgs:alias 

in the DescribeFeatureType response. 


Unfortunately it didn't make Geomedia happy. But as you said - that
depends how it is coded. 


I also asked them what we should do with the alias attribute. Let's see
what they respond. 

Thanks, 

Andreas 


On 2019-02-27 10:59, Even Rouault wrote:

On mercredi 27 février 2019 10:39:02 CET Andreas Neumann wrote: 


Hi,

We are trying to connect Geomedia Desktop 2018 to our QGIS 3.6 WFS
Server - but fail.

Geomedia complains about the extra "alias" attributes in the
DescribeFeatureType response:

See also our temporary URL:

http://linnode3.geo.zg.ch:8080/ows/Gewaessernetz?SERVICE=WFS=Describ
eFeatureType

Questions:

* Is the "alias" element valid or invalid according to the WFS spec?


It is invalid. The schema returned by the above requst doesn't validate 
against the XML schema of XML schema :-) from

https://www.w3.org/2009/XMLSchema/XMLSchema.xsd


* If yes, could we move the alias attribute to our own qgs namespace?


Yes, using qgsextension:alias would validate XMLSchema.xsd as it has a 
provision for extra attributes in another namespaces.
That doesn't mean that Geomedia would be ready for it though. Depends on how 
it is coded...


Even___
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] WFS DescribeFeatureType Compliance question

2019-02-27 Thread Andreas Neumann
Hi, 


We are trying to connect Geomedia Desktop 2018 to our QGIS 3.6 WFS
Server - but fail. 


Geomedia complains about the extra "alias" attributes in the
DescribeFeatureType response: 

See also our temporary URL: 


http://linnode3.geo.zg.ch:8080/ows/Gewaessernetz?SERVICE=WFS=DescribeFeatureType


Questions: 


* Is the "alias" element valid or invalid according to the WFS spec?
* If yes, could we move the alias attribute to our own qgs namespace?
* What side-effects would such a change have? Which clients are using
the "alias" information?

Thanks, 


Andreas___
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

2019-02-27 Thread Matthias Kuhn
HI Martin

On 2/27/19 11:23 AM, Martin Dobias wrote:
> Hi Nyall
>
> On Wed, Feb 27, 2019 at 4:40 AM Nyall Dawson  wrote:
>> 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?
> Yes, that's correct - print output would be affected too. That means
> that tiles from a regular XYZ service would be scaled up. Now this is
> something I am not 100% sure about how this should work. On one hand
> scaling tiles up is useful with tile layers containing labels (they
> will have the same size as on the screen), on the other hand for some
> tiles this may not be desired (scaling them up would just reduce their
> resolution).
>
> I am wondering if we should have three options for tile resolutions:
> - standard (96 DPI) ... autoscaled, for 256x256 tiles for XYZ tiles
> - high res (192 DPI) ... autoscaled, for 512x512 tiles for XYZ tiles
> - undefined ... not scaled

Sounds reasonable.

I can see the following options for what a data provider can offer:

  * A predefined set of available DPI from the server (e.g. XYZ)

  * Manually specify DPI (e.g. as WMS parameter "DPI=300")

  * No scaling available

Some dataproviders might know what they can offer (WMS might include
that in the GetCapabilities, AFS maybe?), others might need
configuration on layer / data provider properties (XYZ, preconfigured
through QMS or ,qml/.qlr files).


I assume that it's also not always desired to get the maximum resolution.

E.g. in HighRes atlas printing a WMS via a network connection with
"DPI=3000" parameter could be very slow, so the API should be prepared
to specify

 * "data source DPI", i.e. what's requested from the provider

 * and output device DPI, i.e. what it's scaled to for screen/paper

> This should hopefully handle all the cases. I am not sure though which
> option should be the default. For compatibility reasons (not to break
> existing behavior of QGIS) probably it would be good to have
> "undefined" as the default with no scaling of tiles on screen nor for
> print. Only when deliberately switched to standard / high res
> resolution we would apply scaling.

Yes, that sounds like the safest approach.

Matthias

___
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] Meteo in QGIS

2019-02-27 Thread Paolo Cavallini
Hi all,

On 16/02/19 12:06, Paolo Cavallini wrote:
> Hi all,
> I think adding to QGIS the possibility of a direct download of meteo
> (GRIB) data would be a big improvement, opening many new opportunities.
> As you probably know, now GRIB files are fully supported natively by
> QGIS, thanks to the work of Martin Dobias, Saber, and Lutra. What is
> missing is a relatively simple downloader.
> The good news is that there is already a free C++ downloader, from which
> we can take inspiration if not directly code:
> https://github.com/opengribs/XyGrib/blob/master/src/FileLoaderGRIB.cpp
> https://github.com/opengribs/XyGrib/blob/master/src/DialogLoadGRIB.cpp
> The port to PyQGIS/Processing seems relatively straightforward; the main
> issue is probably replicating the many options available in the download
> dialog, plus some specific meteo visualization options (e.g. wind
> indicators).
> I would be interested in starting a crowdfunding campaign about this -
> anyone interested?
> More info here:
> https://github.com/opengribs/XyGrib/issues/180
> Thanks.

Just a follow up: several developers are interested, we are discussing
about details and we'll come out with a proposal. Please add your
comments if interested.
Thanks.
-- 
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] WMTS/XYZ on high DPI screens

2019-02-27 Thread Richard Duivenvoorde
On 26/02/2019 17.23, 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.
> 
> 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?

Hi Martin,

not sure if this is helpfull, but Matthijs of the OpenGeoGroep.nl
created a hidpi tilecache for mac users not so long ago for an Dutch,
osm based base map. I asked him what he did.  He says (translated):

"Yes we serve two versions, eg"

http://www.openbasiskaart.nl/mapcache/wmts/?SERVICE=WMTS=GetTile=1.0.0=osm-nb=default=rd=5=16=15=image%2Fpng

http://www.openbasiskaart.nl/mapcache/wmts/?SERVICE=WMTS=GetTile=1.0.0=osm-nb-hq=default=rd-hq=5=16=15=image%2Fpng

"Only the tileing protocol metadata is not really prepeared for HQ
tiles. I now set it up i a way that for HiDPI tiles you have use the
same TILEMATRIX, TILEROW en TILEROW, but you receive either a 256x256
tile or a 512x512 tile depending on the TILEMATRIXSET. But you have to
fool the tile server a little, so if you use current URL
(http://www.openbasiskaart.nl/mapcache and layer with HQ in QGIS) you
get big labels."

Maybe you can use the service to check/test?
(note hq is only in EPSG:28992)

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] WFS DescribeFeatureType Compliance question

2019-02-27 Thread Even Rouault
On mercredi 27 février 2019 10:39:02 CET Andreas Neumann wrote:
> Hi,
> 
> We are trying to connect Geomedia Desktop 2018 to our QGIS 3.6 WFS
> Server - but fail.
> 
> Geomedia complains about the extra "alias" attributes in the
> DescribeFeatureType response:
> 
> See also our temporary URL:
> 
> http://linnode3.geo.zg.ch:8080/ows/Gewaessernetz?SERVICE=WFS=Describ
> eFeatureType
> 
> 
> Questions:
> 
>   * Is the "alias" element valid or invalid according to the WFS spec?

It is invalid. The schema returned by the above requst doesn't validate 
against the XML schema of XML schema :-) from
https://www.w3.org/2009/XMLSchema/XMLSchema.xsd

>   * If yes, could we move the alias attribute to our own qgs namespace?

Yes, using qgsextension:alias would validate XMLSchema.xsd as it has a 
provision for extra attributes in another namespaces.
That doesn't mean that Geomedia would be ready for it though. Depends on how 
it is coded...

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
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] Plugin site down

2019-02-27 Thread Alex M
On 2/27/19 07:39, Paolo Cavallini wrote:
> Thanks Richard for the explanation. I would expect the load will only
> increase over time.
> The investment seems reasonable to me. Are there alternatives, like
> moving some of the heavy load to a public, free-as-beer service?
> All the best.
> 
> On 27/02/19 16:32, Richard Duivenvoorde wrote:
>> On 27/02/2019 15.25, Paolo Cavallini wrote:
>>> 504 Gateway Time-out
>>>
>>> is it my impression, or this is happening rather often recently?
>>> any way to fix it more permanently?
>>
>> We use the qgis2 server for several purposes. So IF a lot of people are
>> viewing/using plugins or qgis site, and we are building
>> docs/website/packages it get's crowded.
>>
>> To fix this we could rent another server, or move the plugins dir to
>> another existing server (like the issue tracker (qgis3) or test server
>> (qgis4)) Another server is another 600 dollar per year

The new osgeo server (osgeo7) is container compatible if QGIS would like
to deploy something there. The main osgeo download site will be moving
there shortly with significantly increased disk space.

Also a good time to review caching implementations.

As far as build loads, there are plenty of services to consider for
offloading some of that work, starting at free or possibly incurring
some cost, but probably less than renting a whole server.

Enjoy,
Alex
___
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] Plugin site down

2019-02-27 Thread Paolo Cavallini
Hi all,

On 27/02/19 17:35, Alex M wrote:

> The new osgeo server (osgeo7) is container compatible if QGIS would like
> to deploy something there. The main osgeo download site will be moving
> there shortly with significantly increased disk space.
> 
> Also a good time to review caching implementations.
> 
> As far as build loads, there are plenty of services to consider for
> offloading some of that work, starting at free or possibly incurring
> some cost, but probably less than renting a whole server.

thanks, added as a topic for the upcoming HF:
https://github.com/qgis/QGIS/wiki/22nd-Developer-Meeting-in-A-Coru%C3%B1a,-Spain#topics

Regards.
-- 
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] Changes to @atlas_feature?

2019-02-27 Thread Spencer Gardner
I'm still seeing issues. From what I can tell, the Expression generator
appears to be correctly reading the @atlas_feature variable now, and in
fact most references in the Reports are working correctly. However, my
attribute tables are still empty on the Reports page. I'll file a bug
report to see if we can get to the bottom of it.

On Mon, Feb 11, 2019 at 8:47 PM Nyall Dawson  wrote:

> On Tue, 12 Feb 2019 at 09:59, Spencer Gardner 
> wrote:
> >
> > I have a map document set up with a report that filters an attribute
> table based on an attribute in the layers used for filtering (i.e. the
> "atlas" layer for lack of a better Reports-oriented term). In 3.4.2 I could
> use the @atlas_feature variable to grab the attribute I needed, but I've
> discovered this doesn't work in 3.4.4. Was there a change to the handling
> of @atlas_feature between the two versions? If so, I'll file a bug report.
> Otherwise, I'm at a loss as to what's going on.
> >
>
> That's an unfortunate bug in 3.4.4 - it's fixed for next weeks 3.4.5
> release.
>
> Nyall
>
>
> > Thanks!
> > Spencer
> > ___
> > 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

2019-02-27 Thread Martin Dobias
On Wed, Feb 27, 2019 at 1:03 PM Matthias Kuhn  wrote:
> >
> > I am wondering if we should have three options for tile resolutions:
> > - standard (96 DPI) ... autoscaled, for 256x256 tiles for XYZ tiles
> > - high res (192 DPI) ... autoscaled, for 512x512 tiles for XYZ tiles
> > - undefined ... not scaled
>
> Sounds reasonable.
>
> I can see the following options for what a data provider can offer:
>
>   * A predefined set of available DPI from the server (e.g. XYZ)
>
>   * Manually specify DPI (e.g. as WMS parameter "DPI=300")
>
>   * No scaling available

Right.


> Some dataproviders might know what they can offer (WMS might include
> that in the GetCapabilities, AFS maybe?), others might need
> configuration on layer / data provider properties (XYZ, preconfigured
> through QMS or ,qml/.qlr files).

As mentioned in my earlier email, WMS, WMTS, XYZ have no way to tell
the true DPI of tiles (as far as I know). AMS does but QGIS does not
take it into account.


> I assume that it's also not always desired to get the maximum resolution.
>
> E.g. in HighRes atlas printing a WMS via a network connection with
> "DPI=3000" parameter could be very slow, so the API should be prepared
> to specify
>
>  * "data source DPI", i.e. what's requested from the provider
>
>  * and output device DPI, i.e. what it's scaled to for screen/paper

To specify output device DPI there's already
QgsRasterDataProvider::setDpi() call which is also used when drawing
raster layers.

I am not sure how do you mean it with specification of "data source
DPI" ... if I have a tileset with 96 DPI, do you mean that option
should allow overriding of the source DPI?

In any case, here's my take on fixing three problems in one go:
- correct rendering of XYZ tiles on high res screen (and in print output)
- correct rendering of high resolution XYZ tiles (on any screen)
https://github.com/qgis/QGIS/pull/9296

The PR does not address scaling issues with WMTS layers. Compared to
XYZ layers where one connection = one tile layer, with WMTS there may
be multiple tile layers within one connection, each with different DPI
- and as mentioned above, WMTS does not provide information about DPI.

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

Re: [QGIS-Developer] Plugin site down

2019-02-27 Thread Tim Sutton
Hi

> On 27 Feb 2019, at 17:32, Richard Duivenvoorde  wrote:
> 
> On 27/02/2019 15.25, Paolo Cavallini wrote:
>> 504 Gateway Time-out
>> 
>> is it my impression, or this is happening rather often recently?
>> any way to fix it more permanently?
> 
> We use the qgis2 server for several purposes. So IF a lot of people are
> viewing/using plugins or qgis site, and we are building
> docs/website/packages it get's crowded.
> 
> To fix this we could rent another server, or move the plugins dir to
> another existing server (like the issue tracker (qgis3) or test server
> (qgis4)) Another server is another 600 dollar per year

Or  we can just deploy on a smaller dedicated server - should cost any where 
near so much and we can isolate the services better.

Regards

Tim


> 
> 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] Pyrcc5 is not installed , pyuic4 is not in the path and other errors trying to build a plugin framework

2019-02-27 Thread J L
Hi All,
I've installed QGis desktop 3.6.0 from the OSGeo4w web installer on my
windows 10 machine. This most recent time with a default express-install. I
tried various things before on a different win7 machine and I thought maybe
a completely fresh install on a newer computer would work better, so this
was all the first time install on this machine.

Once I install and run the plugin "Plugin Builder3" , fill out the dialogs
then press "generate" to get a basic plugin framework made for me, I get
the error: "The resource compiler pyrcc5 was not found in your path. You'll
have to manually compile the resources.qrc file with pyrcc5 before
installing your plugin."

I saw a stackexchange question that seems to solve this problem,
https://gis.stackexchange.com/questions/273552/pyrcc5-is-not-recognized-as-an-internal-or-external-command
Run some bat files to get the right directories added to the path. That
seems to allow me to build the resource as a one off.

I believe the next step is to deploy using pb_tool. I don't have that, so I
installed pb_tool from the OSGeo4w shell with, "pip install pb_tool"
but then I get errors when running "pb_tool deploy" in my plugin directory,
"pyuic4 is not in your path---unable to compile your ui files pyrcc4 is not
in your path---unable to compile your resource file(s)"

Seems like a path issue again, so I run the bat files from the
stackexchange answer to add them again in my osgeo4w shell, then I get this:
C:\MyFiles\Medina\Generated_Plugin_Code\topology_edit>pb_tool deploy File
"C:\OSGEO4~1\apps\Python37\lib\site.py", line 177 file=sys.stderr)

which seems very odd to me. I don't think I should try to solve syntax
errors in teh python scripts. I feel like I must be doing something wrong
here, or there is a bug in the install that doesn't include these things
automatically, I assume the idea would be to have all the tools needed
installed by default.

I can get the plugin deployed by manually building the resources with the
stackexchange  bat file advice, then manually copy it to the plugin
directory, but I thought I would report my experience in case there was an
easy way that allows me to use pb_tool and automate that.
Cheers,
-Jeff
___
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] Changes to @atlas_feature?

2019-02-27 Thread Spencer Gardner
Looking deeper, I realized even unfiltered attribute tables aren't showing
up for me. I can show column names, but no rows are displayed. Can anyone
else confirm?

On Wed, Feb 27, 2019 at 1:17 PM Spencer Gardner 
wrote:

> I'm still seeing issues. From what I can tell, the Expression generator
> appears to be correctly reading the @atlas_feature variable now, and in
> fact most references in the Reports are working correctly. However, my
> attribute tables are still empty on the Reports page. I'll file a bug
> report to see if we can get to the bottom of it.
>
> On Mon, Feb 11, 2019 at 8:47 PM Nyall Dawson 
> wrote:
>
>> On Tue, 12 Feb 2019 at 09:59, Spencer Gardner 
>> wrote:
>> >
>> > I have a map document set up with a report that filters an attribute
>> table based on an attribute in the layers used for filtering (i.e. the
>> "atlas" layer for lack of a better Reports-oriented term). In 3.4.2 I could
>> use the @atlas_feature variable to grab the attribute I needed, but I've
>> discovered this doesn't work in 3.4.4. Was there a change to the handling
>> of @atlas_feature between the two versions? If so, I'll file a bug report.
>> Otherwise, I'm at a loss as to what's going on.
>> >
>>
>> That's an unfortunate bug in 3.4.4 - it's fixed for next weeks 3.4.5
>> release.
>>
>> Nyall
>>
>>
>> > Thanks!
>> > Spencer
>> > ___
>> > 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] Algorithms help files not available for translation

2019-02-27 Thread DelazJ
Hi

Thank you very much, Jürgen. I can already see the strings in Transifex.
Nice!
Could that be backported to 3.4 LTR, please? We'd like to translate them,
easier for QGIS promotion in some administrations.

Thanks again,
Harrissou

Le mar. 26 févr. 2019 à 23:09, Jürgen E. Fischer  a écrit :

> 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 Norden
> https://www.norbit.de
> 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
___
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 [1493] Layer Group Filter approval notification.

2019-02-27 Thread noreply

Plugin Layer Group Filter approval by pcav.
The plugin version "[1493] Layer Group Filter 0.2" is now approved
Link: http://plugins.qgis.org/plugins/layerGroupFilter/
___
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

2019-02-27 Thread Andreas Neumann
Hi Richard, 

Sorry for causing trouble with the tables. 


I think we can point directly to Projecta for the bug fixes. There is no
point in translating bug titles (noone would do it anyway). 


Thanks,
Andreas 


On 2019-02-27 09:15, Richard Duivenvoorde wrote:

On 27/02/2019 09.04, Andreas Neumann wrote: 


Ok - I had a look at past entries and saw that it should be added to the
Category "Notable Fixes".

I am copy/pasting the Google Spreadsheet with the bug fixes of the devs
to the respective categories with some Help of Regexp replace and markdown.

See 
http://changelog.qgis.org/en/qgis/version/3.6.0/#bug-fixes-by-alessandro-pasotti
 as
an example.


Please keep in mind that to move the changelog to (clean/translatable)
rst these tables are hard to handle and a lot to translate.

I understand it is nice to show what people did, but if it affects the
easy building/maintaining of the website, I'd leave it.

I'll do a test now, to see if it works (export to rst, move into website
etc). If it works, cool.

Another options is to NOT move the changelog rst to the website anymore
but keep pointing to the projecta site (and not translate the changelog
anymore).

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

2019-02-27 Thread Andreas Neumann
Hi Richard, 

When is the deadline with the copying of the changelog? 


Have to do some "real work" for my employer now, but will continue
tonight. Still good or too late? 

Andreas 


On 2019-02-27 09:24, Andreas Neumann wrote:

Hi Richard, 

Sorry for causing trouble with the tables. 

I think we can point directly to Projecta for the bug fixes. There is no point in translating bug titles (noone would do it anyway). 


Thanks,
Andreas 

On 2019-02-27 09:15, Richard Duivenvoorde wrote: 
On 27/02/2019 09.04, Andreas Neumann wrote: Ok - I had a look at past entries and saw that it should be added to the

Category "Notable Fixes".

I am copy/pasting the Google Spreadsheet with the bug fixes of the devs
to the respective categories with some Help of Regexp replace and markdown.

See 
http://changelog.qgis.org/en/qgis/version/3.6.0/#bug-fixes-by-alessandro-pasotti
 as
an example. 
Please keep in mind that to move the changelog to (clean/translatable)

rst these tables are hard to handle and a lot to translate.

I understand it is nice to show what people did, but if it affects the
easy building/maintaining of the website, I'd leave it.

I'll do a test now, to see if it works (export to rst, move into website
etc). If it works, cool.

Another options is to NOT move the changelog rst to the website anymore
but keep pointing to the projecta site (and not translate the changelog
anymore).

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


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

2019-02-27 Thread Andreas Neumann

Ok - I had a look at past entries and saw that it should be added to the
Category "Notable Fixes". 


I am copy/pasting the Google Spreadsheet with the bug fixes of the devs
to the respective categories with some Help of Regexp replace and
markdown. 


See
http://changelog.qgis.org/en/qgis/version/3.6.0/#bug-fixes-by-alessandro-pasotti
as an example. 

Andreas 


On 2019-02-27 08:47, Paolo Cavallini wrote:


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?___
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 [1656] Map Library approval notification.

2019-02-27 Thread noreply

Plugin Map Library approval by pcav.
The plugin version "[1656] Map Library 0.6" is now approved
Link: http://plugins.qgis.org/plugins/maplibrary/
___
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 [1656] Map Library approval notification.

2019-02-27 Thread noreply

Plugin Map Library approval by pcav.
The plugin version "[1656] Map Library 0.5" is now approved
Link: http://plugins.qgis.org/plugins/maplibrary/
___
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] QEP 140: QGIS Processing standalone executable

2019-02-27 Thread David Marteau
Hi Nyall

You may be interested in some work already done for running qgis processing 
algorithms at server side with no gui and direct calls to "createAlgorithms":

https://github.com/3liz/py-qgis-wps 

Development of embedding the processing machinery has raised some interesting 
questions about using processing in stand alone programs. 

David 

> Le 27 févr. 2019 à 04:36, Nyall Dawson  a écrit :
> 
> 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 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

2019-02-27 Thread Richard Duivenvoorde
On 27/02/2019 09.04, Andreas Neumann wrote:
> Ok - I had a look at past entries and saw that it should be added to the
> Category "Notable Fixes".
> 
> I am copy/pasting the Google Spreadsheet with the bug fixes of the devs
> to the respective categories with some Help of Regexp replace and markdown.
> 
> See 
> http://changelog.qgis.org/en/qgis/version/3.6.0/#bug-fixes-by-alessandro-pasotti
>  as
> an example.

Please keep in mind that to move the changelog to (clean/translatable)
rst these tables are hard to handle and a lot to translate.

I understand it is nice to show what people did, but if it affects the
easy building/maintaining of the website, I'd leave it.

I'll do a test now, to see if it works (export to rst, move into website
etc). If it works, cool.

Another options is to NOT move the changelog rst to the website anymore
but keep pointing to the projecta site (and not translate the changelog
anymore).

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

2019-02-27 Thread Jürgen E . Fischer
Hi Andreas,

On Tue, 26. Feb 2019 at 22:06:19 +0100, Andreas Neumann wrote:
> 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

Thanks for the friendly reminder - updated ;)


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

2019-02-27 Thread Luigi Pirelli
Tnx tim :)

On Tuesday, 26 February 2019, Tim Sutton  wrote:

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

-- 
Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS 2nd Edition:
*
https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition
* Hire me: http://goo.gl/BYRQKg
**
___
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] Changes to @atlas_feature?

2019-02-27 Thread Marco Hugentobler
Seems this bugfix has not been backported to 3.4.x yet (see pull request 
https://github.com/qgis/QGIS/pull/9306).


Regards,

Marco

Am 27.02.19 um 22:21 schrieb Spencer Gardner:
Looking deeper, I realized even unfiltered attribute tables aren't 
showing up for me. I can show column names, but no rows are displayed. 
Can anyone else confirm?


On Wed, Feb 27, 2019 at 1:17 PM Spencer Gardner 
mailto:spencergard...@gmail.com>> wrote:


I'm still seeing issues. From what I can tell, the Expression
generator appears to be correctly reading the @atlas_feature
variable now, and in fact most references in the Reports are
working correctly. However, my attribute tables are still empty on
the Reports page. I'll file a bug report to see if we can get to
the bottom of it.

On Mon, Feb 11, 2019 at 8:47 PM Nyall Dawson
mailto:nyall.daw...@gmail.com>> wrote:

On Tue, 12 Feb 2019 at 09:59, Spencer Gardner
mailto:spencergard...@gmail.com>>
wrote:
>
> I have a map document set up with a report that filters an
attribute table based on an attribute in the layers used for
filtering (i.e. the "atlas" layer for lack of a better
Reports-oriented term). In 3.4.2 I could use the
@atlas_feature variable to grab the attribute I needed, but
I've discovered this doesn't work in 3.4.4. Was there a change
to the handling of @atlas_feature between the two versions? If
so, I'll file a bug report. Otherwise, I'm at a loss as to
what's going on.
>

That's an unfortunate bug in 3.4.4 - it's fixed for next weeks
3.4.5 release.

Nyall


> Thanks!
> Spencer
> ___
> 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


--
Dr. Marco Hugentobler
Sourcepole -  Linux & Open Source Solutions
Weberstrasse 5, CH-8004 Zürich, Switzerland
marco.hugentob...@sourcepole.ch http://www.sourcepole.ch

___
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 [1232] OSM Tools approval notification.

2019-02-27 Thread noreply

Plugin OSM Tools approval by pcav.
The plugin version "[1232] OSM Tools 3.3.0" is now approved
Link: http://plugins.qgis.org/plugins/OSMtools/
___
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] Plugin site down

2019-02-27 Thread Paolo Cavallini
Hi Tim,

On 27/02/19 22:20, Tim Sutton wrote:

> Or  we can just deploy on a smaller dedicated server - should cost any
> where near so much and we can isolate the services better.
this is also a possibility, although this means administering another
machine.
Better have a general discussion about infrastructure in Coruña.
Regards.
-- 
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