[QGIS-Developer] Plugin [390] HTP Geoprocessor approval notification.

[noreply]

Plugin HTP Geoprocessor approval by pcav.
The plugin version "[390] HTP Geoprocessor 1.2" is now approved
Link: http://plugins.qgis.org/plugins/htpgeoprocessor/
___
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 [1048] Another DXF Importer / DXF2Shape Converter approval notification.

[noreply]

Plugin Another DXF Importer / DXF2Shape Converter approval by pcav.
The plugin version "[1048] Another DXF Importer / DXF2Shape Converter 1.0.2" is 
now approved
Link: http://plugins.qgis.org/plugins/AnotherDXF2Shape/
___
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] Scale/Magnifier/Units per pixel

[Idan Miara]

Hi Denis,

Thanks for your reply!
I think I was expecting the behaviour that you described.

As far as I understand, in OSM there are scale dependent features, for
instance smaller streets, more labels, that won't show up in larger scale
for the same extent. That's why I was expecting that when I use the
'magnifying glass'  there won't be any new features showing up at the same
extent, i.e. smaller streets or more labels. But there are, same as if I've
changed the scale.

Kind regards,
Idan

On 1 Mar 2018 19:00, "Denis Rouzaud"  wrote:

Hi Idan,

I'll reply for the part I'm aware of.

Le jeu. 1 mars 2018 à 06:05, Idan Miara  a écrit :

> Hi,
>
> I was examining the Scale/Magnifier widget in QGIS3.
>
> I couldn't find any difference in the output picture between the following
> combinations (example):
> Scale 1:1,000 and magnifier 1000%
> Scale 1:10,000 and magnifier 100%
> Scale 1:100,000 and magnifier 10%
> Is this by design ?
>

Yes this expected. The idea of the magnifier is for having a "magnifier
glass" to do scale-dependent editing. In my scenario, that was useful for
fine-placement of labels.
But if you don't have scale-dependent rendering (mainly labels I guess) or
using map units instead of points for symology, it won't (shouldn't) change
anything.

>
> I was expecting a different results, for instance, if I load OSM, and I
> change the magnifier while the scale is fixed I was expecting to see the
> same rendered image, just smaller/larger (i.e. same map features, no new
> labels/roads etc.)
>

well, if you magnify with a fixed scale that will change the extent, you
can't see as much features in the map.


>
> Also, is there an option to set the resolution in Map Units per pixel,
> i.e.:
> Meters Per Pixels (when the units are meters, as in UTM) or
> Degrees/Seconds per pixel (when the units are Degrees, as in Geographic) ?
>
> I guess it makes more sense for most people to use Scale, but when I want
> to examine specific pixels of a raster usually it's easier for me to think
> in Meters Per Pixels in respect to the Map Units, for instance, when I know
> that my map is in 10 Meters per pixel, then if I set the Map canvas
> resolution to the same value of 10 Meters per pixel I expect to see the
> pixels in 1:1 as one pixel on the raster is one pixel on the map canvas.
>
> Regards,
> Idan.
>
>
Best wishes,
Denis
___
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] $geometry does not consider changes in the edit uffer

[Denis Rouzaud]

Hi all,

If I set a virtual field with the vertex count (i.e. num_points(  $geometry
) ), it does not consider changes in the edit buffer.
In other words, I have to commit the changes so the expression is correct.

Is this an expected behavior?
I would have expect to be updated directly.

Cheers,

Denis
___
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] Scale/Magnifier/Units per pixel

[Denis Rouzaud]

Hi Idan,

I'll reply for the part I'm aware of.

Le jeu. 1 mars 2018 à 06:05, Idan Miara  a écrit :

> Hi,
>
> I was examining the Scale/Magnifier widget in QGIS3.
>
> I couldn't find any difference in the output picture between the following
> combinations (example):
> Scale 1:1,000 and magnifier 1000%
> Scale 1:10,000 and magnifier 100%
> Scale 1:100,000 and magnifier 10%
> Is this by design ?
>

Yes this expected. The idea of the magnifier is for having a "magnifier
glass" to do scale-dependent editing. In my scenario, that was useful for
fine-placement of labels.
But if you don't have scale-dependent rendering (mainly labels I guess) or
using map units instead of points for symology, it won't (shouldn't) change
anything.

>
> I was expecting a different results, for instance, if I load OSM, and I
> change the magnifier while the scale is fixed I was expecting to see the
> same rendered image, just smaller/larger (i.e. same map features, no new
> labels/roads etc.)
>

well, if you magnify with a fixed scale that will change the extent, you
can't see as much features in the map.


>
> Also, is there an option to set the resolution in Map Units per pixel,
> i.e.:
> Meters Per Pixels (when the units are meters, as in UTM) or
> Degrees/Seconds per pixel (when the units are Degrees, as in Geographic) ?
>
> I guess it makes more sense for most people to use Scale, but when I want
> to examine specific pixels of a raster usually it's easier for me to think
> in Meters Per Pixels in respect to the Map Units, for instance, when I know
> that my map is in 10 Meters per pixel, then if I set the Map canvas
> resolution to the same value of 10 Meters per pixel I expect to see the
> pixels in 1:1 as one pixel on the raster is one pixel on the map canvas.
>
> Regards,
> Idan.
>
>
Best wishes,
Denis
___
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 [51] Hotlink approval notification.

[noreply]

Plugin Hotlink approval by pcav.
The plugin version "[51] Hotlink 0.8.2" is now approved
Link: http://plugins.qgis.org/plugins/Hotlink/
___
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.2 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] issues in QGIS Server 2,18

[René-Luc Dhont]

Hi Giovanni,


Le 01/03/2018 à 12:52, Giovanni Manghi a écrit :

Hi all,
now that 2.18 is LTR I guess that many have also updated their QGIS
Server installation to this release. Problem is that I see a few
issues in 2.18 and would like to have gsome feedback from others.

*) slower: it seems this version is slower compared to 2.14, at least
for some specific request like WFS GetFeatures. See for example:

https://issues.qgis.org/issues/18249#note-1

where in the same condition (same server, same postgis datasource of
around ~25000 polygons) 2.18 is about 30 seconds slower than 2.14.


This issue is simply due to the transformation of the geometry from the 
layer CRS to the GeoJSON CRS standard: EPSG:4326




*) At some point in 2.18 development -in the print composer,
properties of a legend- the "none" value for the "map" option was
removed. This option (together with "auto update" unchecked) allowed
to do GetPrint requests where a legend always shown the same fixed
entries regardless of the layers being requested. Moreover now the
layers legend (from a GetPrint) frequently shows "?" instead of the
correct legend. Not sure if the two things are related.


It will be great to have the possibility to allow nullptr in the map 
combobox.
Nyall, do you have an idea how to enhance QgsComposerItemComboBox 
introdiuced by 
https://github.com/qgis/QGIS/commit/1b4bd47076103e931e642c9c2b6a363f14b20a45?

Issue already exists: https://issues.qgis.org/issues/16899



*) Crashes on GetPrint: adding some type of elements in print
composers (like html text boxes) caused QGIS Server to crash when
doing a GetPrint *if* the *headless* server didn't had a fake xserver
installed. Now in 2.18 this happens even if QGIS Server is installed
on a Desktop OS, unless installing the fake x server. Not sure is
related but this now affects also Windows machines where a GetPrint
requests (of a layout with one of this problematic elements) make
always QGIS Server crash. This was not the case for 2.14.


The solution is probably to update the environment variable 
QT_GRAPHICSSYSTEM to 'raster' has explain 
https://issues.qgis.org/issues/15440 and in a lot of other project:

https://stackoverflow.com/questions/6168570/qgraphicsview-slow-scale-performance-under-linux
https://forum.kde.org/viewtopic.php?t=90821

I'll test this solution.

Regards,
René-Luc
___
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 [995] dzetsaka : Classification tool approval notification.

[noreply]

Plugin dzetsaka : Classification tool approval by pcav.
The plugin version "[995] dzetsaka : Classification tool 3.0.2" is now approved
Link: http://plugins.qgis.org/plugins/dzetsaka/
___
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] issues in QGIS Server 2,18

[Giovanni Manghi]

Hi all,
now that 2.18 is LTR I guess that many have also updated their QGIS
Server installation to this release. Problem is that I see a few
issues in 2.18 and would like to have gsome feedback from others.

*) slower: it seems this version is slower compared to 2.14, at least
for some specific request like WFS GetFeatures. See for example:

https://issues.qgis.org/issues/18249#note-1

where in the same condition (same server, same postgis datasource of
around ~25000 polygons) 2.18 is about 30 seconds slower than 2.14.


*) At some point in 2.18 development -in the print composer,
properties of a legend- the "none" value for the "map" option was
removed. This option (together with "auto update" unchecked) allowed
to do GetPrint requests where a legend always shown the same fixed
entries regardless of the layers being requested. Moreover now the
layers legend (from a GetPrint) frequently shows "?" instead of the
correct legend. Not sure if the two things are related.


*) Crashes on GetPrint: adding some type of elements in print
composers (like html text boxes) caused QGIS Server to crash when
doing a GetPrint *if* the *headless* server didn't had a fake xserver
installed. Now in 2.18 this happens even if QGIS Server is installed
on a Desktop OS, unless installing the fake x server. Not sure is
related but this now affects also Windows machines where a GetPrint
requests (of a layout with one of this problematic elements) make
always QGIS Server crash. This was not the case for 2.14.


thanks in advance for the feedback

cheers

-- Giovanni --
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 2.18.17 LTR: Changelog?

[Etienne Trimaille]

You can find the list of commits between 2.18.16 and 2.18.17 with this
link:
https://github.com/qgis/QGIS/compare/final-2_18_16...final-2_18_17

2018-03-01 13:43 GMT+03:00 Luca Manganelli :

> Hello,
>
> where can I find the changelog (list of bugs fixed) for QGIS 2.18.17?
>
> Thank you
> Luca
> ___
> 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] QGIS 2.18.17 LTR: Changelog?

[Luca Manganelli]

Hello,

where can I find the changelog (list of bugs fixed) for QGIS 2.18.17?

Thank you
Luca
___
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] Scale/Magnifier/Units per pixel

[Idan Miara]

Hi,

I was examining the Scale/Magnifier widget in QGIS3.

I couldn't find any difference in the output picture between the following
combinations (example):
Scale 1:1,000 and magnifier 1000%
Scale 1:10,000 and magnifier 100%
Scale 1:100,000 and magnifier 10%
Is this by design ?

I was expecting a different results, for instance, if I load OSM, and I
change the magnifier while the scale is fixed I was expecting to see the
same rendered image, just smaller/larger (i.e. same map features, no new
labels/roads etc.)

Also, is there an option to set the resolution in Map Units per pixel, i.e.:
Meters Per Pixels (when the units are meters, as in UTM) or
Degrees/Seconds per pixel (when the units are Degrees, as in Geographic) ?

I guess it makes more sense for most people to use Scale, but when I want
to examine specific pixels of a raster usually it's easier for me to think
in Meters Per Pixels in respect to the Map Units, for instance, when I know
that my map is in 10 Meters per pixel, then if I set the Map canvas
resolution to the same value of 10 Meters per pixel I expect to see the
pixels in 1:1 as one pixel on the raster is one pixel on the map canvas.

Regards,
Idan.
___
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