[Qgis-developer] Questions/Suggestion on virtual layers

Thu Mar 3 03:16:56 PST 2016

Hi Andreas and all,

sorry to hijack your thread but my question is related as I am also 
trying to evaluate the new feature virtual layer.

My first tests resulted in QGIS freezing upon clicking "Test" or "OK" 
(2.14.0 on Ubuntu 14.04 64 bit). It finally turned up it was the layer's 
names containing dots (e.g. "schema.table" as they come from PostGIS). 
Double quoting any layer and field names containing dots solved this 
issue. However I had joins containing field names with dots, too because 
of the prefix I used ("table.") which could not be resolved but at least 
threw an error on testing. So I would propose to at least add a notice 
in the tooltip that if one runs into problems, double quoting layers' 
and fields' names might solve issues. Better would be to already have 
them double quoted if inserted from the pop-up list.
Should I open a ticket?

Very cool feature, though!

Bernhard

Am 02.03.2016 um 17:48 schrieb Neumann, Andreas:
> Hi Hugo,
>
> On 2016-03-02 17:17, Hugo Mercier wrote:
>
>> Hi Andreas,
>>
>> On 02/03/2016 16:27, Neumann, Andreas wrote:
>>
>>> Hi,
>>>
>>> I am experimenting with the virtual layers. They are quite cool!
>>>
>>> I have some suggesions/questions:
>>>
>>> 1. It would be nice to have a preview of my query results. Currently it
>>> is either it works - or not. If it works, but the results are wrong
>>> you have to start from scratch. I would suggest that when you press
>>> on the test button you would not only display "No error" or the
>>> error message, but maybe the first 10 rows of the result.
>>
>> True.
>> Note that you can also create a virtual layer using the DB Manager where
>> it can display the first rows of a query, as it is the case for other
>> databases.
>> I am not sure to love having these two very close but slightly different
>> dialogs. If anyone has a better idea in terms of usability, do not
>> hesitate to propose :)
>
> Can one create new virtual layers in the DB manager? I know that I can
> do queries on existing layers and load it as a new layer - but is this
> the same thing like a virtual layer?
>
>>> 2. Updating the virtual layer: it would be really nice if I could
>>> edit/improve on my virtual layers without having to start completely
>>> from scratch. --> Oh - now I found out that if you select an
>>> existing virtual layer and then use "Layer" --> "Add Layer" --> "Add
>>> Virtual Layer", that you can refresh an existing virtual layer. This
>>> is really not obvious. I think this is more a usability issue.
>>
>> Yes ... I am more used to click on the addition icon, which makes it
>> more direct, but you are right, this is not perfect.
>
> ah ok - the button works as "edit" if you have the layer selected. Maybe
> then we should rename the tooltip from "Add Virtual Layer" to "Add or
> Edit Virtual Layer"
>
>> An entry in the right-click menu ?
>
> Yes - that was my first idea - to look for an entry in the layer context
> menu. Of course this entry should only be there if it is a virtual
> layer.
>
>> Edit - you can also use the drop down menu of the creation dialog to
>> switch between different virtual layer definitions, as mentioned by Yves
>
> yes - now I found it - thanks!
>
>> 3. it is not very obvious how you can reuse an already existing
>> geometry column. I discovered it by accident, that you can use
>> layer.geometry (regardless of the original name of the geometry
>> column), but I think that it is not obvious. A better hint in the
>> the tooltip would probably help.
>> Indeed it appears to be not documented.
>
> This would just require an additional sentence in  the tooltip of the
> Query panel, after the sentence "Any functions from SQLite or Spatialite
> can then be used in the query.:
>
> To add or access existing geometries of a table, you can use
> "tablename.geometry", regardless of original geometry column's name.
>
>> 4. Unique identifier column: If you join several tables, you often have
>> the issue that you need to create an artificial primary key. Could
>> we offer a preconfigured builtin pkey - something like a rowid  for
>> such cases?
>> Good point. An autoincremented id is already generated on the feature.
>> That may not be a problem to add a "rowid" column in that case.
>
> That would be cool to have.
>
>> 5. What is the exact purpose of the "Embedded Layers" where you can
>> add/import/remove layers? I noticed that existing layers of the
>> project work anyway without adding/importing them first. Is the idea
>> that you can work on layers that aren't in the project?
>> Yes it is.
>> You can for example embed layers from the project, save the virtual
>> layer to a QLR and reload it in a new project, the referenced layers
>> would not need to be already loaded.
>> There may be some documentation needed as well here.
>
> Maybe we could add another tooltip here, explaining that one can add
> layers that are not in the project - and that you need to "embed
> existing layers", if you want to save to a qlr and load it in a
> different project.
>
>> Should I open feature request tickets for these or are there already
>> plans to address one or the other of the above issues?
>> Unfortunately, no plan yet.
>> Thanks for your tests and feedback !
>
> Ok - I will open feature requests for the above, where useful.
>
> Thanks,
> Andreas
>
>
> __________ Information from ESET Mail Security, version of virus signature database 13116 (20160302) __________
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>
>
> Hi Hugo,
>
> On 2016-03-02 17:17, Hugo Mercier wrote:
>
>> Hi Andreas,
>>
>> On 02/03/2016 16:27, Neumann, Andreas wrote:
>>> Hi,
>>>
>>> I am experimenting with the virtual layers. They are quite cool!
>>>
>>> I have some suggesions/questions:
>>>
>>>
>>>
>>>  1. It would be nice to have a preview of my query results. Currently it
>>>     is either it works - or not. If it works, but the results are wrong
>>>     you have to start from scratch. I would suggest that when you press
>>>     on the test button you would not only display "No error" or the
>>>     error message, but maybe the first 10 rows of the result.
>>
>> True.
>> Note that you can also create a virtual layer using the DB Manager where
>> it can display the first rows of a query, as it is the case for other
>> databases.
>> I am not sure to love having these two very close but slightly different
>> dialogs. If anyone has a better idea in terms of usability, do not
>> hesitate to propose :)
> Can one create new virtual layers in the DB manager? I know that I can
> do queries on existing layers and load it as a new layer - but is this
> the same thing like a virtual layer?
>>
>>
>>>  2. Updating the virtual layer: it would be really nice if I could
>>>     edit/improve on my virtual layers without having to start completely
>>>     from scratch. --> Oh - now I found out that if you select an
>>>     existing virtual layer and then use "Layer" --> "Add Layer" --> "Add
>>>     Virtual Layer", that you can refresh an existing virtual layer. This
>>>     is really not obvious. I think this is more a usability issue.
>>
>> Yes ... I am more used to click on the addition icon, which makes it
>> more direct, but you are right, this is not perfect.
> ah ok - the button works as "edit" if you have the layer selected. Maybe
> then we should rename the tooltip from "Add Virtual Layer" to "Add or
> Edit Virtual Layer"
>>
>> An entry in the right-click menu ?
> Yes - that was my first idea - to look for an entry in the layer context
> menu. Of course this entry should only be there if it is a virtual layer.
>>
>>
>> Edit - you can also use the drop down menu of the creation dialog to
>> switch between different virtual layer definitions, as mentioned by Yves
> yes - now I found it - thanks!
>>
>>
>>  3. it is not very obvious how you can reuse an already existing
>>     geometry column. I discovered it by accident, that you can use
>>     layer.geometry (regardless of the original name of the geometry
>>     column), but I think that it is not obvious. A better hint in the
>>     the tooltip would probably help.
>> Indeed it appears to be not documented.
> This would just require an additional sentence in  the tooltip of the
> Query panel, after the sentence "Any functions from SQLite or Spatialite
> can then be used in the query.:
> To add or access existing geometries of a table, you can use
> "tablename.geometry", regardless of original geometry column's name.
>>
>>
>>  4. Unique identifier column: If you join several tables, you often have
>>     the issue that you need to create an artificial primary key. Could
>>     we offer a preconfigured builtin pkey - something like a rowid  for
>>     such cases?
>> Good point. An autoincremented id is already generated on the feature.
>> That may not be a problem to add a "rowid" column in that case.
> That would be cool to have.
>>
>>
>>  5. What is the exact purpose of the "Embedded Layers" where you can
>>     add/import/remove layers? I noticed that existing layers of the
>>     project work anyway without adding/importing them first. Is the idea
>>     that you can work on layers that aren't in the project?
>> Yes it is.
>> You can for example embed layers from the project, save the virtual
>> layer to a QLR and reload it in a new project, the referenced layers
>> would not need to be already loaded.
>> There may be some documentation needed as well here.
>>
> Maybe we could add another tooltip here, explaining that one can add
> layers that are not in the project - and that you need to "embed
> existing layers", if you want to save to a qlr and load it in a
> different project.
>>
>> Should I open feature request tickets for these or are there already
>> plans to address one or the other of the above issues?
>> Unfortunately, no plan yet.
>> Thanks for your tests and feedback !
>>
> Ok - I will open feature requests for the above, where useful.
> Thanks,
> Andreas
>
>
> __________ Information from ESET Mail Security, version of virus
> signature database 13116 (20160302) __________
>
> The message was checked by ESET Mail Security.
> http://www.eset.com
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>

__________ Information from ESET Mail Security, version of virus signature database 13120 (20160303) __________

The message was checked by ESET Mail Security.
http://www.eset.com