[QGIS-Developer] Plugin [1412] GeoDataFarm approval notification.

[noreply]

Plugin GeoDataFarm approval by pcav.
The plugin version "[1412] GeoDataFarm 2.3.3" is now approved
Link: http://plugins.qgis.org/plugins/geodatafarm/
___
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] GetFeatureInfo: sensitivity on rendered geometry vs original geometry.

[Régis Haubourg]

I think Paul and Eric have been working on that issue. I'm adding them in
the loop here.
Regards
Régis

Le ven. 12 avr. 2019 à 16:46, René-Luc Dhont  a écrit :

> Hi
>
> Le 12/04/2019 à 16:05, Andreas Neumann a écrit :
>
> On 2019-04-12 15:53, René-Luc Dhont wrote:
>
> Hi Andreas,
>
> I think QGIS Server has to use the rendered geometries to identify Feature.
>
> yes
>
>
> Is it possible to get the  point layer to polygon rendred layer ?
>
> Like Alessandro, I also don't understand this statement. Do you say that I
> should convert my point layer to a polygon layer representing the rendered
> bounding box? This would be quite difficult for our users.
>
> Andreas
>
>
>
> The idea is how QGIS can convert point layer to polygon layer
> corresponding to bbox symbol to get feature information.
>
> In QGIS Server, GetFeatureInfo is a simple GetFeature based on Extent. Is
> it possible to do the same but based on rendering ?
>
> 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 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] GetFeatureInfo: sensitivity on rendered geometry vs original geometry.

[René-Luc Dhont]

Hi

Le 12/04/2019 à 16:05, Andreas Neumann a écrit :


On 2019-04-12 15:53, René-Luc Dhont wrote:


Hi Andreas,

I think QGIS Server has to use the rendered geometries to identify 
Feature.


yes



Is it possible to get the  point layer to polygon rendred layer ?


Like Alessandro, I also don't understand this statement. Do you say 
that I should convert my point layer to a polygon layer representing 
the rendered bounding box? This would be quite difficult for our users.


Andreas




The idea is how QGIS can convert point layer to polygon layer 
corresponding to bbox symbol to get feature information.


In QGIS Server, GetFeatureInfo is a simple GetFeature based on Extent. 
Is it possible to do the same but based on rendering ?


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

Re: [QGIS-Developer] GetFeatureInfo: sensitivity on rendered geometry vs original geometry.

[Andreas Neumann]

On 2019-04-12 15:53, René-Luc Dhont wrote:


Hi Andreas,

I think QGIS Server has to use the rendered geometries to identify Feature.


yes


Is it possible to get the  point layer to polygon rendred layer ?


Like Alessandro, I also don't understand this statement. Do you say that
I should convert my point layer to a polygon layer representing the
rendered bounding box? This would be quite difficult for our users. 

Andreas 


Regards,
René-Luc

Le 12/04/2019 à 15:43, Andreas Neumann a écrit : 

Hi, 

I'd like to discuss an issue with GetFeatureInfo that we have with point symbols. 

(Point) symbols can have different sizes (sometimes rather large), different anchor points and sometimes even with offset away from the original feature geometry. Often, the rendering of the point symbol differs substantially from the original point geometry. 

Now, our issue is that GetFeatureInfo often fails miserably in such cases. People try to click on the visible symbol, which doesn't correspond to the original geometry. 

One such example WMS: 

https://services.geo.zg.ch/ows/Abfallsammelstellen 

The symbols are rather large, but the anchor point is at the bottom of the symbol. Users now think that they can click anywhere on the symbol, but in fact they can only click on the original geometry at the very bottom of the symbol, taking into account the FI_POINT_TOLERANCE parameter. 

Things get even worse when one wants to identify points that are displayed using the point displacement renderer. There, GetFeatureInfo is only sensitive on the center point, and not at all at the rendered points at a completely different position. 

Now my question: could we improve QGIS server that GetFeatureInfo responds to the bounding boxes of the rendered geometries (as opposed to the raw geometries), taking into account sizes, offsets, etc. 

Would this be technically possible?  

Would others also think that this is useful to have? 

Or would this even contradict OGC standards? 

Do other WMS servers implement such behaviors (Geoserver, UMN)? 

Thanks for the discussion, 

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


___
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] GetFeatureInfo: sensitivity on rendered geometry vs original geometry.

[Alessandro Pasotti]

On Fri, Apr 12, 2019 at 3:53 PM René-Luc Dhont  wrote:

> Hi Andreas,
>
> I think QGIS Server has to use the rendered geometries to identify Feature.
>

Hi René,

Yeah, I also though that's the only solution, what scares me is the
performances cost, because we would need to render and check each layer
individually.



> Is it possible to get the  point layer to polygon rendred layer ?
>

I don't follow you, can you explain what's in your mind?



>
> Regards,
> René-Luc
>
> Le 12/04/2019 à 15:43, Andreas Neumann a écrit :
>
> Hi,
>
> I'd like to discuss an issue with GetFeatureInfo that we have with point
> symbols.
>
> (Point) symbols can have different sizes (sometimes rather large),
> different anchor points and sometimes even with offset away from the
> original feature geometry. Often, the rendering of the point symbol differs
> substantially from the original point geometry.
>
> Now, our issue is that GetFeatureInfo often fails miserably in such cases.
> People try to click on the visible symbol, which doesn't correspond to the
> original geometry.
>
> One such example WMS:
>
> https://services.geo.zg.ch/ows/Abfallsammelstellen
>
> The symbols are rather large, but the anchor point is at the bottom of the
> symbol. Users now think that they can click anywhere on the symbol, but in
> fact they can only click on the original geometry at the very bottom of the
> symbol, taking into account the FI_POINT_TOLERANCE parameter.
>
> Things get even worse when one wants to identify points that are displayed
> using the point displacement renderer. There, GetFeatureInfo is only
> sensitive on the center point, and not at all at the rendered points at a
> completely different position.
>
> Now my question: could we improve QGIS server that GetFeatureInfo responds
> to the bounding boxes of the rendered geometries (as opposed to the raw
> geometries), taking into account sizes, offsets, etc.
>
> Would this be technically possible?
>
> Would others also think that this is useful to have?
>
> Or would this even contradict OGC standards?
>
> Do other WMS servers implement such behaviors (Geoserver, UMN)?
>
> Thanks for the discussion,
>
> Andreas
>
> ___
> QGIS-Developer mailing listqgis-develo...@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



-- 
Alessandro Pasotti
w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] GetFeatureInfo: sensitivity on rendered geometry vs original geometry.

[René-Luc Dhont]

Hi Andreas,

I think QGIS Server has to use the rendered geometries to identify Feature.
Is it possible to get the  point layer to polygon rendred layer ?

Regards,
René-Luc

Le 12/04/2019 à 15:43, Andreas Neumann a écrit :


Hi,

I'd like to discuss an issue with GetFeatureInfo that we have with 
point symbols.


(Point) symbols can have different sizes (sometimes rather large), 
different anchor points and sometimes even with offset away from the 
original feature geometry. Often, the rendering of the point symbol 
differs substantially from the original point geometry.


Now, our issue is that GetFeatureInfo often fails miserably in such 
cases. People try to click on the visible symbol, which doesn't 
correspond to the original geometry.


One such example WMS:

https://services.geo.zg.ch/ows/Abfallsammelstellen

The symbols are rather large, but the anchor point is at the bottom of 
the symbol. Users now think that they can click anywhere on the 
symbol, but in fact they can only click on the original geometry at 
the very bottom of the symbol, taking into account 
the FI_POINT_TOLERANCE parameter.


Things get even worse when one wants to identify points that are 
displayed using the point displacement renderer. There, GetFeatureInfo 
is only sensitive on the center point, and not at all at the rendered 
points at a completely different position.


Now my question: could we improve QGIS server that GetFeatureInfo 
responds to the bounding boxes of the rendered geometries (as opposed 
to the raw geometries), taking into account sizes, offsets, etc.


Would this be technically possible?

Would others also think that this is useful to have?

Or would this even contradict OGC standards?

Do other WMS servers implement such behaviors (Geoserver, UMN)?

Thanks for the discussion,

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


___
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] GetFeatureInfo: sensitivity on rendered geometry vs original geometry.

[Andreas Neumann]

Hi, 


I'd like to discuss an issue with GetFeatureInfo that we have with point
symbols. 


(Point) symbols can have different sizes (sometimes rather large),
different anchor points and sometimes even with offset away from the
original feature geometry. Often, the rendering of the point symbol
differs substantially from the original point geometry. 


Now, our issue is that GetFeatureInfo often fails miserably in such
cases. People try to click on the visible symbol, which doesn't
correspond to the original geometry. 

One such example WMS: 

https://services.geo.zg.ch/ows/Abfallsammelstellen 


The symbols are rather large, but the anchor point is at the bottom of
the symbol. Users now think that they can click anywhere on the symbol,
but in fact they can only click on the original geometry at the very
bottom of the symbol, taking into account the FI_POINT_TOLERANCE
parameter. 


Things get even worse when one wants to identify points that are
displayed using the point displacement renderer. There, GetFeatureInfo
is only sensitive on the center point, and not at all at the rendered
points at a completely different position. 


Now my question: could we improve QGIS server that GetFeatureInfo
responds to the bounding boxes of the rendered geometries (as opposed to
the raw geometries), taking into account sizes, offsets, etc. 

Would this be technically possible?  

Would others also think that this is useful to have? 

Or would this even contradict OGC standards? 

Do other WMS servers implement such behaviors (Geoserver, UMN)? 

Thanks for the discussion, 


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

[QGIS-Developer] Plugin [915] Spatial Design Network Analysis approval notification.

[noreply]

Plugin Spatial Design Network Analysis approval by pcav.
The plugin version "[915] Spatial Design Network Analysis 4.0.0" is now approved
Link: http://plugins.qgis.org/plugins/sdna/
___
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] Project files translation

[Matteo Ghetta]

> Correct. The main open question there is if the side car files should be
> inside the qgz or next to it. Both have advantages and disadvantages and
> therefore it was left out of the first implementation for a follow up
> step with a clearer path.

ok
>> * when using a field within an algorithm (e.g. a buffer with variable
>> distance) the name displayed are the original and not the translated
> What exactly are you referring too here?
> In general: everything that is translatable needs to be added one by one
> (see https://github.com/qgis/QGIS-Enhancement-Proposals/issues/90) and
> will also need to be added incrementally as things appear in the future.
> Especially expressions are hard to do.
> The focus of the initial project was mainly on forms and legend.

I imagined that the main focus was related to legend and forms. What I
mean is that if you run a Processing algorithm and you want to use a
field of the source layer (e.g. a variable distance buffer where the
distance should be taken from a layer field), the list of the field
shown in the alg UI is not the translated one, but the source one

> There is no work going on right now.

got it, thanks!

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

Re: [QGIS-Developer] Can I backport bugfix with UI updates and fixing QGIS Server regression

[Paolo Cavallini]

Hi René,

On 12/04/19 12:05, René-Luc Dhont wrote:

> I would like to know if I can backport all the commits made by Nyall to
> fix issue 19500 even if it updates the User Interface ?

+1 from my side, but obviously Nyall has the final word on this.
Thanks.

-- 
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] Can I backport bugfix with UI updates and fixing QGIS Server regression

[René-Luc Dhont]

Hi Dev,

I have worked on fixing a regression in QGIS Server. 
https://github.com/qgis/QGIS/pull/9692


This regression exists in QGIS 3.4 but has been fixed by Nyall in QGIS 
3.6 by fixing an other issue.
The issue fixed by Nyall was *Layout export - raster divided into tiles, 
edges evident in pdf/svg* https://issues.qgis.org/issues/19500
The issue has been found in QGIS 3.2. It has been fixed in QGIS 3.6 but 
the fix has not been backported to QGIS 3.4.
I suppose that the backport has not been done because the fix updates 
the User Interface. https://github.com/qgis/QGIS/pull/9016


I would like to know if I can backport all the commits made by Nyall to 
fix issue 19500 even if it updates the User Interface ?


I think that this backport has to be done in QGIS 3.4 to fix a desktop 
issue and a server regression because it is the LTR version, but I need 
to know if it's the right thing to do.


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

Re: [QGIS-Developer] Project files translation

[Matthias Kuhn]

Hi Matteo

On 4/12/19 11:49 AM, Matteo Ghetta wrote:
> Hi all,
>
> playing with the i18n translation of projects I discovered some
> (unwanted?) things:
>
> * works only for qgs and not qgz, right? Is this a bug or a feature request?
Correct. The main open question there is if the side car files should be
inside the qgz or next to it. Both have advantages and disadvantages and
therefore it was left out of the first implementation for a follow up
step with a clearer path.

> * when using a field within an algorithm (e.g. a buffer with variable
> distance) the name displayed are the original and not the translated
What exactly are you referring too here?
In general: everything that is translatable needs to be added one by one
(see https://github.com/qgis/QGIS-Enhancement-Proposals/issues/90) and
will also need to be added incrementally as things appear in the future.
Especially expressions are hard to do.
The focus of the initial project was mainly on forms and legend.

>
> Is this still a work in progress or should I file a bug/feature request?
There is no work going on right now.

Bests
Matthias
>
> Thanks
>
> Matteo
>
-- 
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] Project files translation

[Matteo Ghetta]

Hi all,

playing with the i18n translation of projects I discovered some
(unwanted?) things:

* works only for qgs and not qgz, right? Is this a bug or a feature request?
* when using a field within an algorithm (e.g. a buffer with variable
distance) the name displayed are the original and not the translated

Is this still a work in progress or should I file a bug/feature request?

Thanks

Matteo

-- 
Matteo Ghetta - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis
___
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 [862] Geosearch DK approval notification.

[noreply]

Plugin Geosearch DK approval by pcav.
The plugin version "[862] Geosearch DK 1.1.0" is now approved
Link: http://plugins.qgis.org/plugins/geosearch_dk/
___
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 [1329] FREEWAT approval notification.

[noreply]

Plugin FREEWAT approval by pcav.
The plugin version "[1329] FREEWAT 1.1.2.1" is now approved
Link: http://plugins.qgis.org/plugins/freewat/
___
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 [1696] FUSION for Processing approval notification.

[noreply]

Plugin FUSION for Processing approval by pcav.
The plugin version "[1696] FUSION for Processing 0.1.0 Experimental" is now 
approved
Link: http://plugins.qgis.org/plugins/processing_fusion/
___
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