Re: [QGIS-Developer] issues with 1:n relations

[Matthias Kuhn]

On 04/17/2018 10:28 PM, Nyall Dawson wrote:
> On 18 April 2018 at 02:39, Matthias Kuhn  wrote:
>> Hi Giovanni
>>
>> On 04/17/2018 06:23 PM, Giovanni Manghi wrote:
>>
>> Hi all,
>>
>> I have recently had to test some scenario with 1:n relations in QGIS and I 
>> have found a few issues and would like to know if someone has them in its 
>> pipeline/todo list, eventually to share the effort for the fixes.
>>
>> Anyway I'm also interested on your feedback on the matter.
>>
>> 1) 1:n relations in QGIS3. They seems unusable at the moment. When opening a 
>> parent layer feature form, the area/space where the child records should 
>> show does not show/cannot be expanded.
>>
>> Interesting, I cannot reproduce this here on Linux nor did I hear of this 
>> from our clients using Windows.
> You need to be using autogenerated forms (not drag and drop). Report is here:
>
> https://issues.qgis.org/issues/17525
>
> I've confirmed it personally - Windows & Linux.

Thanks Nyall, now I see it also.

Actually vice versa:
it works with drag and drop (the projectgenerator which I've mainly been
testing creates those) and fails with autogenerate.

Matthias

>
> Nyall

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

Re: [QGIS-Developer] issues in QGIS Server 2,18

[Lorenzo Moretti]

Hi

In addition to the problem described in GetPrint I have a problem related to 
the legend in QGIS 2.18.
If the "Show Feature Count" function is enabled my QGIS Server crashes and part 
of the qgs file is also compromised. The legend is no longer displayed. Even if 
disabled "Show Feature Count" the qgs file is damaged. I've seen that this code 
in the qgs file crashes it:
  

  
This is also the case in GetPrint with dynamic texts in the legend (object 
counting). I have to remove all references in the qgs file but not always 
enough to avoid the crash. Sometimes I have to recreate the file from the 
beginning without this option and without the same option in the print.
QGIS server is installed on an OS Desktop (Mac OS X). X11 is not enabled and 
therefore I cannot use the fake-server.
The other options in QGIS Server work well.
All this in version 2.14 did not happen.

Thanks

cheers

Lorenzo

> 
> 
> *) 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.
> 


___
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] Error with GRASS in Processing

[Nyall Dawson]

On 18 April 2018 at 04:38, Giovanni Manghi  wrote:
> Hi Nyall
>
>> It may not be right for the GRASS provider (it isn't - this is a bug),
>> but for other providers it is, as this allows you to take advantage of
>> Processing 3.0's new transparent reprojection.
>
> right, I forgot about that. But then why not having the coordinates
> show in one field, and the value of the crs in a separate one?

I agree that the point parameter widget isn't ideal. I'd love to see a
PR improving this!

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] Error with GRASS in Processing

[Nyall Dawson]

On 17 April 2018 at 18:23, matteo  wrote:
> Hi devs,
>
> testing GRASS within Processing I noticed a small bug in all the
> algorithms where you can add a map point coordinates with a click on the
> map, like r.viewshed, r.drain
>
> If the users choose to click on the map to fill the box with the
> coordinates of the point, the box is filled with both coordinates AND
> the additional EPSG information, like:
>
> 348403.62350233766,4903994.026987238 [EPSG:32632]
>
> and this makes GRASS unhappy.
>
> Should I fill a ticket?

I can't confirm this - for me it works fine with r.drain and the param
values including the CRS.

Can you post more steps to reproduce? The processing log would help.

Nyall

>
> 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
___
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 with 1:n relations

[Nyall Dawson]

On 18 April 2018 at 02:39, Matthias Kuhn  wrote:
>
> Hi Giovanni
>
> On 04/17/2018 06:23 PM, Giovanni Manghi wrote:
>
> Hi all,
>
> I have recently had to test some scenario with 1:n relations in QGIS and I 
> have found a few issues and would like to know if someone has them in its 
> pipeline/todo list, eventually to share the effort for the fixes.
>
> Anyway I'm also interested on your feedback on the matter.
>
> 1) 1:n relations in QGIS3. They seems unusable at the moment. When opening a 
> parent layer feature form, the area/space where the child records should show 
> does not show/cannot be expanded.
>
> Interesting, I cannot reproduce this here on Linux nor did I hear of this 
> from our clients using Windows.

You need to be using autogenerated forms (not drag and drop). Report is here:

https://issues.qgis.org/issues/17525

I've confirmed it personally - Windows & Linux.

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] Error with GRASS in Processing

[Giovanni Manghi]

Hi Nyall

> It may not be right for the GRASS provider (it isn't - this is a bug),
> but for other providers it is, as this allows you to take advantage of
> Processing 3.0's new transparent reprojection.

right, I forgot about that. But then why not having the coordinates
show in one field, and the value of the crs in a separate one?

cheers!

-- G --
___
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 with 1:n relations

[DelazJ]

Hi,

2018-04-17 19:25 GMT+02:00 Raymond Nijssen :

> Hi Giovanni,
>
> Not sure what you exactly did, I wasn't even aware of QGIS being able
> doing any 1:n relations.
>
> Raymond,
https://docs.qgis.org/2.18/en/docs/user_manual/working_with_vector/attribute_table.html#creating-one-or-many-to-many-relations

Regards,
Harrissou


> But a few months ago I had to do a more complex 1:n relation, including
> adding some fields. I solved it by using a virtual layer. The description
> is here:
>
> http://www.qgis.nl/2018/02/16/english-diagrams-for-features/?lang=en
>
> Maybe it could help you. Or maybe you know an easier way for doing this?
> Btw, I would normally do this using PostGIS but this was a question from a
> customer.
>
> Ciao,
> Raymond
>
>
>
> On 17-04-18 18:23, Giovanni Manghi wrote:
>
>> Hi all,
>>
>> I have recently had to test some scenario with 1:n relations in QGIS and
>> I have found a few issues and would like to know if someone has them in its
>> pipeline/todo list, eventually to share the effort for the fixes.
>>
>> Anyway I'm also interested on your feedback on the matter.
>>
>> 1) 1:n relations in QGIS3. They seems unusable at the moment. When
>> opening a parent layer feature form, the area/space where the child records
>> should show does not show/cannot be expanded.
>>
>>
>> 2) 1:n relations in QGIS 2.18.
>>
>> I have tried a scenario (that to me seems not unusual at all) where both
>> the parent and the child are layers/tables with a geometry.
>>
>> The case where the child has its own geometries does not seems well
>> implemented (if implemented at all) in the context of the relation feature
>> form and this causes the following:
>>
>> a) from within the parent feature form, if I edit the child and try add a
>> new record there is no tool to allow also add/digitize the proper geometry.
>> The user can still enter only the attributes and when saving I have seen
>> two things happen *) In a test project using GPKGs this led effectively to
>> a record orphaned of its geometry *) In a test project using PostGIS layers
>> the edits are *silently* discarded, no warning, no error, not even in QGIS
>> logs.
>>
>> b) from within the parent feature form, when toggling editing for the
>> child, this is effectively put it in edit state also in the layers panel.
>> So a user can "move away" the parent feature form (that it is on first
>> plane) and use the standard editing tools to add a geometry to the child
>> layer. When finished the attributes form pop-up and can be used to fill the
>> data, with the important issue/limitation that the "referencing field" is
>> *not* automatically filled as it is done when working within the relation
>> form. Once saved the new record will also show in the relation form. This
>> seems a partial workaround because as said the referencing field is not
>> automatically filled.
>>
>> Am I missing something?
>>
>> thanks in advance for your 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
>>
>>
> --
> Terglobo
> Fahrenheitstraat 1
> 5223 BJ 's-Hertogenbosch
> 06 25 31 49 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

Re: [QGIS-Developer] issues with 1:n relations

[Raymond Nijssen]

Hi Giovanni,

Not sure what you exactly did, I wasn't even aware of QGIS being able 
doing any 1:n relations.


But a few months ago I had to do a more complex 1:n relation, including 
adding some fields. I solved it by using a virtual layer. The 
description is here:


http://www.qgis.nl/2018/02/16/english-diagrams-for-features/?lang=en

Maybe it could help you. Or maybe you know an easier way for doing this? 
Btw, I would normally do this using PostGIS but this was a question from 
a customer.


Ciao,
Raymond


On 17-04-18 18:23, Giovanni Manghi wrote:

Hi all,

I have recently had to test some scenario with 1:n relations in QGIS and 
I have found a few issues and would like to know if someone has them in 
its pipeline/todo list, eventually to share the effort for the fixes.


Anyway I'm also interested on your feedback on the matter.

1) 1:n relations in QGIS3. They seems unusable at the moment. When 
opening a parent layer feature form, the area/space where the child 
records should show does not show/cannot be expanded.



2) 1:n relations in QGIS 2.18.

I have tried a scenario (that to me seems not unusual at all) where both 
the parent and the child are layers/tables with a geometry.


The case where the child has its own geometries does not seems well 
implemented (if implemented at all) in the context of the relation 
feature form and this causes the following:


a) from within the parent feature form, if I edit the child and try add 
a new record there is no tool to allow also add/digitize the proper 
geometry. The user can still enter only the attributes and when saving I 
have seen two things happen *) In a test project using GPKGs this led 
effectively to a record orphaned of its geometry *) In a test project 
using PostGIS layers the edits are *silently* discarded, no warning, no 
error, not even in QGIS logs.


b) from within the parent feature form, when toggling editing for the 
child, this is effectively put it in edit state also in the layers 
panel. So a user can "move away" the parent feature form (that it is on 
first plane) and use the standard editing tools to add a geometry to the 
child layer. When finished the attributes form pop-up and can be used to 
fill the data, with the important issue/limitation that the "referencing 
field" is *not* automatically filled as it is done when working within 
the relation form. Once saved the new record will also show in the 
relation form. This seems a partial workaround because as said the 
referencing field is not automatically filled.


Am I missing something?

thanks in advance for your 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



--
Terglobo
Fahrenheitstraat 1
5223 BJ 's-Hertogenbosch
06 25 31 49 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] issues with 1:n relations

[Matthias Kuhn]

Hi Giovanni

On 04/17/2018 06:23 PM, Giovanni Manghi wrote:
> Hi all,
>
> I have recently had to test some scenario with 1:n relations in QGIS
> and I have found a few issues and would like to know if someone has
> them in its pipeline/todo list, eventually to share the effort for the
> fixes.
>
> Anyway I'm also interested on your feedback on the matter.
>
> 1) 1:n relations in QGIS3. They seems unusable at the moment. When
> opening a parent layer feature form, the area/space where the child
> records should show does not show/cannot be expanded.
>
Interesting, I cannot reproduce this here on Linux nor did I hear of
this from our clients using Windows.

>
> 2) 1:n relations in QGIS 2.18.
>
> I have tried a scenario (that to me seems not unusual at all) where
> both the parent and the child are layers/tables with a geometry.
>
> The case where the child has its own geometries does not seems well
> implemented (if implemented at all) in the context of the relation
> feature form and this causes the following:
>
> a) from within the parent feature form, if I edit the child and try
> add a new record there is no tool to allow also add/digitize the
> proper geometry. The user can still enter only the attributes and when
> saving I have seen two things happen *) In a test project using GPKGs
> this led effectively to a record orphaned of its geometry *) In a test
> project using PostGIS layers the edits are *silently* discarded, no
> warning, no error, not even in QGIS logs.

>From what I can remember, yes, there is still an issue here that the
geometry cannot be digitized right at this time. As a workaround one can
go to the attribute table and select this feature and use the add part
tool. In some project we implemented a python based feature action that
implements this use case. (Hint hint, if there's a customer request for
this, I'll be happy to estimate the required amount of work ;) ).

>
> b) from within the parent feature form, when toggling editing for the
> child, this is effectively put it in edit state also in the layers
> panel. So a user can "move away" the parent feature form (that it is
> on first plane) and use the standard editing tools to add a geometry
> to the child layer. When finished the attributes form pop-up and can
> be used to fill the data, with the important issue/limitation that the
> "referencing field" is *not* automatically filled as it is done when
> working within the relation form. Once saved the new record will also
> show in the relation form. This seems a partial workaround because as
> said the referencing field is not automatically filled.

Are you referring to the case here, when the parent is added (and not
edited)
for this case you preferably
 * enable transaction mode
 * server side evaluation of default values (so the id of the parent is
known already at form time before the parent is committed to the layer)
 * deferred foreign key constraints (so the database only checks if the
foreign key points to a valid parent at transaction commit time)

I hope this helps at least a bit
Matthias

>
> Am I missing something?
>
> thanks in advance for your 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

-- 
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] issues with 1:n relations

[Giovanni Manghi]

Hi all,

I have recently had to test some scenario with 1:n relations in QGIS and I
have found a few issues and would like to know if someone has them in its
pipeline/todo list, eventually to share the effort for the fixes.

Anyway I'm also interested on your feedback on the matter.

1) 1:n relations in QGIS3. They seems unusable at the moment. When opening
a parent layer feature form, the area/space where the child records should
show does not show/cannot be expanded.


2) 1:n relations in QGIS 2.18.

I have tried a scenario (that to me seems not unusual at all) where both
the parent and the child are layers/tables with a geometry.

The case where the child has its own geometries does not seems well
implemented (if implemented at all) in the context of the relation feature
form and this causes the following:

a) from within the parent feature form, if I edit the child and try add a
new record there is no tool to allow also add/digitize the proper geometry.
The user can still enter only the attributes and when saving I have seen
two things happen *) In a test project using GPKGs this led effectively to
a record orphaned of its geometry *) In a test project using PostGIS layers
the edits are *silently* discarded, no warning, no error, not even in QGIS
logs.

b) from within the parent feature form, when toggling editing for the
child, this is effectively put it in edit state also in the layers panel.
So a user can "move away" the parent feature form (that it is on first
plane) and use the standard editing tools to add a geometry to the child
layer. When finished the attributes form pop-up and can be used to fill the
data, with the important issue/limitation that the "referencing field" is
*not* automatically filled as it is done when working within the relation
form. Once saved the new record will also show in the relation form. This
seems a partial workaround because as said the referencing field is not
automatically filled.

Am I missing something?

thanks in advance for your 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] Error with GRASS in Processing

[matteo]

Hi Nyall,


> It may not be right for the GRASS provider (it isn't - this is a bug),
> but for other providers it is, as this allows you to take advantage of
> Processing 3.0's new transparent reprojection.
> 
> E.g.:
> 
> - canvas in 3857
> - layers in 4326
> - run the shortest path point-to-point alg, and pick a start/end
> coordinate off the map. These will be in 3857 (respecting the canvas
> crs), but when the alg runs it will reproject it to the required crs
> (4326) without hassling the user and making them hate QGIS :)

definitely yes. I'm loving this new CRS handling by Processing

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] Error with GRASS in Processing

[matteo]

Hi Giovanni,

thanks for the answer. I was not sure if this error was reported somewhere.

BTW, done: https://issues.qgis.org/issues/18737

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] Error with GRASS in Processing

[Nyall Dawson]

On 17 April 2018 at 21:26, Giovanni Manghi  wrote:
> Hi Matteo,
>
>> Should I fill a ticket?
>
> of course you should (for this case as for any other regression/bug as this)
> this is not right, and if fact it wasn't ever the case (to have also
> the CRS info when using the pick coordinate tool).

It may not be right for the GRASS provider (it isn't - this is a bug),
but for other providers it is, as this allows you to take advantage of
Processing 3.0's new transparent reprojection.

E.g.:

- canvas in 3857
- layers in 4326
- run the shortest path point-to-point alg, and pick a start/end
coordinate off the map. These will be in 3857 (respecting the canvas
crs), but when the alg runs it will reproject it to the required crs
(4326) without hassling the user and making them hate QGIS :)

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] Error with GRASS in Processing

[Giovanni Manghi]

Hi Matteo,

> Should I fill a ticket?

of course you should (for this case as for any other regression/bug as this)
this is not right, and if fact it wasn't ever the case (to have also
the CRS info when using the pick coordinate tool).

thanks!

-- G --
___
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] Drill-down (cascading) forms in QGIS Value Relation Widgets crowdfunding

[Matthias Kuhn]

Hi Alessandro,

Thanks a lot for these detailed insights!

On 04/17/2018 12:44 PM, Alessandro Pasotti wrote:
> Hi,
>
> I'll try to address all concerns in a single mail (what a challenge!)
>
> First I would like to say that everybody has access to a different set
> of "average/typical users" and I cannot claim any statistical
> relevance to the group of users I've been in touch with.
>
> But the user's feedback that I've got so far is that the
> Value-Relation widget (V-RW) is easier to use and to understand: its
> scope it's limited to how data are entered and viewed and does not
> depend on a model-project-level constraint (the Relation-Reference
> R-RW does).
>
> Those (statistically insignificant) users were quite emotional and
> ready to fight to keep V-RW live and healthy :)

May they be statistically significant or not, the opinion counts and is
important to be considered. I assume, the main requirement here is an
easy setup (i.e. directly in the widget, no roundtrip via project
properties). As long as this is not implemented, the value relation
widget will stay alive.

Let's focus on what other requirements are potential show-stoppers and
then decide if it's worth moving on.

> Code-wise I totally agree that the two widgets could share more logic
> and options, but given the intricacies of the attr-table and
> widgets-forms logic this is not trivial at all, and it's not in scope
> with this QEP 116 enhancement.
>
> Coming to the new functionalities introduced by QEP 116, the way they
> will be implemented will make them easily reusable in the context of
> the R-RW:
>
> - form scope context with geometry and attributes
> - form scope available in both the form and the attribute table

And that's what I really like about it!

>
> Of course existing bugs and glitches in the V-RW workflow will be
> fixed on the way when they not imply rewriting the whole QGIS core ;)
>
> What could be considered here, is to add a second goal to the campaign
> for making the new features available to the R-RW too, what do you think?

As written in my previous email, please do !!

>
> But even without this additional goal, I still think that this QEP
> (which is not a complete refactoring of the whole form/attr-table *-R
> widgets) is a step forward and in the direction of a future better
> integration of the existing *-R-widgets.
>
>
> That's why I'm joining Nyall's call to contribute and make this a reality.
>
>
> Also note that some of Règis requirements, like a geographical dynamic
> filter will be possible with an expression like:
>
> ... AND contains(buffer( $current_form_geometry, 10), $geometry)

... and even better with the R-R widget where it will be possible to
dynamically adjust the range from the form (thinking of advanced search
functionality in a popup or so), its new infrastructure allows for some
very cool additions which I hope to be able to implement soon ;)

Please keep up the good work and let us know what's required to bring
this to relation reference too!

Best regards
Matthias

> note that this expression is the one used to filter the values in the
> related layer, and it will have access to the geometry of the feature
> currently being edited/added in the form (or table row) as well as to
> the form (row) values, so:
>
> - $current_form_geometry = the geometry of the feature currently being
> edited in the form
> - $geometry = the geometry of the related layer that is being filtered
> to get the list of values for the combo/search/etc...
>
> Also note that the V-RW is already used in the identify results panel
> (and form of course).
>
>
> Cheers
>
> -- 
> 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

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

Re: [QGIS-Developer] Drill-down (cascading) forms in QGIS Value Relation Widgets crowdfunding

[Alessandro Pasotti]

Hi,

I'll try to address all concerns in a single mail (what a challenge!)

First I would like to say that everybody has access to a different set of
"average/typical users" and I cannot claim any statistical relevance to the
group of users I've been in touch with.

But the user's feedback that I've got so far is that the Value-Relation
widget (V-RW) is easier to use and to understand: its scope it's limited to
how data are entered and viewed and does not depend on a
model-project-level constraint (the Relation-Reference R-RW does).

Those (statistically insignificant) users were quite emotional and ready to
fight to keep V-RW live and healthy :)

Code-wise I totally agree that the two widgets could share more logic and
options, but given the intricacies of the attr-table and widgets-forms
logic this is not trivial at all, and it's not in scope with this QEP 116
enhancement.

Coming to the new functionalities introduced by QEP 116, the way they will
be implemented will make them easily reusable in the context of the R-RW:

- form scope context with geometry and attributes
- form scope available in both the form and the attribute table

Of course existing bugs and glitches in the V-RW workflow will be fixed on
the way when they not imply rewriting the whole QGIS core ;)


What could be considered here, is to add a second goal to the campaign for
making the new features available to the R-RW too, what do you think?

But even without this additional goal, I still think that this QEP (which
is not a complete refactoring of the whole form/attr-table *-R widgets) is
a step forward and in the direction of a future better integration of the
existing *-R-widgets.


That's why I'm joining Nyall's call to contribute and make this a reality.


Also note that some of Règis requirements, like a geographical dynamic
filter will be possible with an expression like:

... AND contains(buffer( $current_form_geometry, 10), $geometry)

note that this expression is the one used to filter the values in the
related layer, and it will have access to the geometry of the feature
currently being edited/added in the form (or table row) as well as to the
form (row) values, so:

- $current_form_geometry = the geometry of the feature currently being
edited in the form
- $geometry = the geometry of the related layer that is being filtered to
get the list of values for the combo/search/etc...

Also note that the V-RW is already used in the identify results panel (and
form of course).


Cheers

-- 
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] Error with GRASS in Processing

[matteo]

Hi devs,

testing GRASS within Processing I noticed a small bug in all the
algorithms where you can add a map point coordinates with a click on the
map, like r.viewshed, r.drain

If the users choose to click on the map to fill the box with the
coordinates of the point, the box is filled with both coordinates AND
the additional EPSG information, like:

348403.62350233766,4903994.026987238 [EPSG:32632]

and this makes GRASS unhappy.

Should I fill a ticket?

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

[QGIS-Developer] Plugin [947] ImportEpanetInpFiles approval notification.

[noreply]

Plugin ImportEpanetInpFiles approval by zimbogisgeek.
The plugin version "[947] ImportEpanetInpFiles 1.3" is now approved
Link: http://plugins.qgis.org/plugins/ImportEpanetInpFiles/
___
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 [1444] Geodyn gemeente approval notification.

[noreply]

Plugin Geodyn gemeente approval by zimbogisgeek.
The plugin version "[1444] Geodyn gemeente 0.4 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/GeodynGem/
___
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