Re: [Qgis-developer] A common set of functions for QGIS plugins

[Victor Olaya]

Nathan, that sounds like a great idea.

Having it under the QGIS organzation in github will avoid people
thinking it is an unofficial and probably unreliable project (as
someone mentioned before), and will help giving it more visibility,
even if we dont put it into core yet

Anyone with permission to do it (Gary, Tim?) can create that repo?
Which name do we use for it?



2015-11-05 8:56 GMT+01:00 Nathan Woodrow :
> Hey Victor and Gray,
>
> I have added you both to my project, however if you want maybe we can start
> an official QGIS repo for it and give it a new name. Keep it away from core
> but still part of the main project.
>
> Thoughts?
>
> On Thu, Nov 5, 2015 at 5:45 PM, Victor Olaya  wrote:
>>
>> Thanks Gary!
>>
>> I had a similar function to that one (actually coming from the
>> Processing code...), so it's good to see that we had the same idea.
>> That means other people out there might have something like that as
>> well, so the library definitely makes sense
>>
>> I am seeing also that the problem might not be in the lack of such
>> code itself, but in the lack of documentation. For instance, I
>> recently found out about the QgsMapLayerComboBox and QgsFieldComboBox
>> widgets. I am pretty sure most people ignore those widgets and dont
>> use them in plugins. I myself wrote classes to do exactly that in this
>> library...before I discovered that they existed already in the core of
>> QGIS.
>>
>> Improving the documentation will clearly help to avoid this redundancies.
>>
>> Cheers!
>>
>> 2015-11-04 18:10 GMT+01:00 Gary Sherman :
>> > On 11/2/15 4:29 AM, Nathan Woodrow wrote:
>> >>
>> >> Hey Victor,
>> >>
>> >> Working on the same kind of thing over here:
>> >> https://github.com/NathanW2/parfait
>> >>
>> > Hi,
>> >
>> > I wrote a few wrappers for the PyQGIS Programmer's guide that you might
>> > take
>> > a look at: http://locatepress.com/ppg/data_code
>> >
>> > Includes a generic add layer function that takes determines whether it
>> > is a
>> > vector or raster and calls the appropriate supporting function.
>> >
>> > Nothing earth-shattering; was meant as an example to get folks thinking
>> > in
>> > that direction.
>> >
>> > I'm definitely interested in this project...
>> >
>> > -gary
>> >
>> >> IMO I would rather see a new module and not put it in qgis.utils.
>> >> Something like qgis.py or qgis.wrappers or something like that that.
>> >>
>> >> - Nathan
>> >>
>> >> On Mon, Nov 2, 2015 at 11:20 PM, Victor Olaya > >> > wrote:
>> >>
>> >> >
>> >> > I'm in two minds as to whether it would be a good thing to have
>> >> an
>> >> > 'official' one. While I can see the use, surely if these things
>> >> are
>> >> useful
>> >> > then they should be included in the mainline API with proper API
>> >> guarantees?
>> >> > I'm not sure I'd want to rely on a library that doesn't have an
>> >> API
>> >> > guarantee, and if you're making the guarantee then why not in
>> >> core?
>> >> If they
>> >> > are *required* for a plugin to be accepted, then they must be in
>> >> core and
>> >> > have an API guarantee.
>> >> >
>> >>
>> >> My ideas is definitely to put this into core (that's what I wrote
>> >> in
>> >> my email when i detailed the plans that i have for this), but I
>> >> have
>> >> started it as a separate repo to make it easier to collaborate and
>> >> to
>> >> start moving ASAP.
>> >>
>> >> I could write a QEP with this idea, get it approved, throw a bunch
>> >> of
>> >> empty py modules in qgis.utils and then start working, but I like
>> >> to
>> >> first do some work, get people into it, and then do the bureucracy
>> >> to
>> >> pass this to core (I am sure no one will say no to this once a nice
>> >> collection of functions is ready)
>> >>
>> >> I will wait for other people to voice their opinion, and if most
>> >> people agree on going taht other way, I have nothing against it
>> >> ___
>> >> Qgis-developer mailing list
>> >> Qgis-developer@lists.osgeo.org
>> >> 
>> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>
>> >>
>> >>
>> >>
>> >> ___
>> >> Qgis-developer mailing list
>> >> Qgis-developer@lists.osgeo.org
>> >> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> >>
>> >
>> > --
>> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> > Gary Sherman
>> >
>> > Founder, QGIS Project
>> > Consulting: geoapt.com
>> > Publishing: locatepress.com
>> >
>> > We work virtually anywhere
>> > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] A common set of functions for QGIS plugins

[Paolo Cavallini]

Hi all,

Il 05/11/2015 09:08, Victor Olaya ha scritto:
> Having it under the QGIS organzation in github will avoid people
> thinking it is an unofficial and probably unreliable project (as
> someone mentioned before), and will help giving it more visibility,
> even if we dont put it into core yet

why exactly do you want to keep it out of core?
All the best, and thanks.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] A common set of functions for QGIS plugins

[Nathan Woodrow]

Mainly just for more rapid dev and so that it doesn't have to be stable API
yet or fit in with release plans.

Just for now. Consider it a sandbox until stable

On Thu, 5 Nov 2015 6:15 pm Paolo Cavallini  wrote:

> Hi all,
>
> Il 05/11/2015 09:08, Victor Olaya ha scritto:
> > Having it under the QGIS organzation in github will avoid people
> > thinking it is an unofficial and probably unreliable project (as
> > someone mentioned before), and will help giving it more visibility,
> > even if we dont put it into core yet
>
> why exactly do you want to keep it out of core?
> All the best, and thanks.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] A common set of functions for QGIS plugins

[Victor Olaya]

>
> why exactly do you want to keep it out of core?

Maybe to have more freedom to experiment in there...? I also think
that it will be easier to get people to collaborate in it, seeing it
as a smaller project, instead of having to do PRs agains the whole
QGIS project, which can feel more intimidating for a casual plugin
developer.
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] A common set of functions for QGIS plugins

[Neumann, Andreas]

 

Perhaps we can have it separate first - try it out - improve things and
then integrate it in core? 

If it is in core, it has to be stabilized - which I understand may not
be the case in the beginning. 

Andreas 

On 2015-11-05 09:14, Paolo Cavallini wrote: 

> Hi all,
> 
> Il 05/11/2015 09:08, Victor Olaya ha scritto: 
> 
>> Having it under the QGIS organzation in github will avoid people
>> thinking it is an unofficial and probably unreliable project (as
>> someone mentioned before), and will help giving it more visibility,
>> even if we dont put it into core yet
> 
> why exactly do you want to keep it out of core?
> All the best, and thanks.

  ___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] A common set of functions for QGIS plugins

[Nathan Woodrow]

Yep that is the plan.

On Thu, 5 Nov 2015 6:21 pm Neumann, Andreas  wrote:

> Perhaps we can have it separate first - try it out - improve things and
> then integrate it in core?
>
> If it is in core, it has to be stabilized - which I understand may not be
> the case in the beginning.
>
> Andreas
>
> On 2015-11-05 09:14, Paolo Cavallini wrote:
>
> Hi all,
>
> Il 05/11/2015 09:08, Victor Olaya ha scritto:
>
> Having it under the QGIS organzation in github will avoid people
> thinking it is an unofficial and probably unreliable project (as
> someone mentioned before), and will help giving it more visibility,
> even if we dont put it into core yet
>
>
> why exactly do you want to keep it out of core?
> All the best, and thanks.
>
>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin Dependencies

[Richard Duivenvoorde]

On 05-11-15 04:56, Tim Sutton wrote:
>> Some random thoughts:
>>
>> Quite powerful... but ... the current plugin packaging has very
>> limited requirements: it's just a zipped folder with a couple of
>> mandatory metadata and a class interface, building a simple plugin is
>> definitely an easy task.
>>
>> I'm afraid that by using a much more complicate system (such as
>> setuptools), would solve some problem for the (few) complex plugins
>> and create a lot of problems and increase the barrier for the vast
>> majority of simpler plugin authors.

I agree with Tim, unless we come up with a very simple way, this will
not solve the problem: "non tech savvy users cannot setup their python
environment for some complex plugi".

The different module versions problem I do not see as a practical
problem, most times python can work with higher versions. Let's keep it
the responsibility of the plugin builders to keep up with versions of
their modules.
I still think just copy the modules into the plugin is easiest (although
redundant).
And if you cannot package the lib with your plugin because of OS
problems: documentation is the answer...

Somebody with this insights, maybe can write a chapter about python path
magics and how QGIS works with that?

Regards,

Richard

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] communication during hackfest on gitter

[Richard Duivenvoorde]

Hi Devs/Users,

we just started the Las Palmas Hackfest on Canary Islands \o/

during the hackfest it is good I think if we concentrate communications
in one channel.

I propose to use Gitter for that now, as (I think) it is easier for not
IRC users to set up:

Go to:

https://gitter.im/qgis/QGIS

and login via your Github (or other?) account.

There is also a gitter/IRC bridge:
https://github.com/gitterHQ/irc-bridge
not working 2-way though

Regards and see you (virtually) there,

Richard Duivenvoorde

ps for smaller groups you can off course setup whatever tech you like better
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] Oracle-qgis testing during hackfest

[Richard Duivenvoorde]

I know I'm cursing in FOSS-church here :-)

But during the hackfest I have an extra laptop with me, running an
Oracle database, with a nice big dataset on it. Happy to give everybody
here connect details to fix some stuff which is currently not working
very well, OR just test if your stuff is working with the oracle
provider too.

It is a temp database, so load whatever you want on it.

Some things that need fixing:
- QGIS browser + oracle
- layertree + oracle
- connection/layer dialog + oracle

Regards,

Richard Duivenvoorde
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin Dependencies

[Vincent Picavet (ml)]

Hello,

On 05/11/2015 09:50, Richard Duivenvoorde wrote:
> On 05-11-15 04:56, Tim Sutton wrote:
>[...]
>>> I'm afraid that by using a much more complicate system (such as
>>> setuptools), would solve some problem for the (few) complex plugins
>>> and create a lot of problems and increase the barrier for the vast
>>> majority of simpler plugin authors.
> 
> I agree with Tim, unless we come up with a very simple way, this will
> not solve the problem: "non tech savvy users cannot setup their python
> environment for some complex plugi".

You are right, but this should be taken the other way round : how do we
add sugar onto a powerful system, to make it accessible for
non-that-tech people.
This is clearly doable and would be an ideal solution.
The proposals from Victor and all to create a set of functions to help
writing plugins is already a good start in that direction for the code part.
We should be able to do the same for the development environment part.

I think there are much more end-users which are annoyed by dependency
problems than new plugin writers not willing to setup en environment.
Dependency problems are hard whatever we do, and we should definitely
rely on the experience of others for this.



> The different module versions problem I do not see as a practical
> problem, most times python can work with higher versions. Let's keep it
> the responsibility of the plugin builders to keep up with versions of
> their modules.

Yes the plugin versions dependencies should be left to the plugin
writer. Dealing with one application using various versions of a module
for various plugins will just lead to "DLL Hell", multiple duplication
of modules and behaviour inconsistencies for the end user.

I think we should build on top of well-defined and bullet-proof tools
the Python world has to offer, and focus on adding simple ways for a
newcomer to start with development. It is not a question of overhead, it
is a question of interface.

Vincent

> I still think just copy the modules into the plugin is easiest (although
> redundant).
> And if you cannot package the lib with your plugin because of OS
> problems: documentation is the answer...
> 
> Somebody with this insights, maybe can write a chapter about python path
> magics and how QGIS works with that?
> 
> Regards,
> 
> Richard
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] [processing] Get canvas CRS from Processing script

[Spencer Gardner]

I'm creating a Processing plugin for which one of the inputs for one of the
tools is a CRS. I'd like to use the CRS from the map canvas as the default
for this parameter but I can't figure out whether this is possible.

My main problem seems to be that the ParameterCrs object is created when
the plugin is first loaded (when QGIS is initialized), so if I parse the
authid() of the map canvas when the plugin loads, it automatically sets to
4326. I can't figure out whether there's a way to re-initialize this
parameter with a different CRS when I actually click on the tool.

Is this technically impossible within the current framework? How can I
accomplish this?

Thanks,
Spencer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Qgis-developer] HF meetings

[Hugo Mercier]

Hi,

We will be discussing project quality tomorrow morning at 10am (local
Gran Canaria time)

And we will talk about plugins (common framework / to pip or not to pip)
at 11am.

If remote people want to join, we will try to include them via Skype or
Hangouts.
Stay tuned on the gitter channel.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] A common set of functions for QGIS plugins

[Paolo Cavallini]

Il 05/11/2015 09:24, Nathan Woodrow ha scritto:
> Yep that is the plan.

I see you already done it, so now it's probably pointless, but: why not
using git submodules?
All the best.

-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 2.5D rendering crowdfunding

[Hugo Mercier]

On 04/11/2015 11:25, Matthias Kuhn wrote:
> Hi
> 
> Good to be aware of this. Let's see that we don't do work twice.
> 
> On 11/04/2015 11:17 AM, Hugo Mercier wrote:
>> On 04/11/2015 10:19, Régis Haubourg wrote:
>>> Matthias Kuhn-2 wrote
  * on-the-fly transformation of geometries while rendering (or with some
 small additions also to create geometries based on attributes)
>>> Hi, this is quite inline with QEP 46 {0]  about handling geometries to draw
>>> label paths. Storing geometries in data or having on-the fly smoothing
>>> expressions for geometries seems to have the same prerequisites for 2.5 D
>>> and that QEP. Hugo  any opinion on that ? 
>>> Cheers
>>> Régis
>>>  [0] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/46
>> Hi,
>>
>> Exact. The concepts seem very close. Except that in one case it is
>> before painting and in another case, before drawing labels.
>>
>> Matthias, is this possible with your proposition to have different parts
>> of the buildings coming from different geometry columns ?
>> Currently for a PostGIS table with two geometry columns (or Spatialite I
>> guess), the second is extracted as a WKT string. I am not sure yet of
>> what changes would be needed to have them extracted as QgsGeometry. That
>> would ease (and speed up) such functionalities (2.5D or label paths)
> 
> 
> Theoretically, yes. It's just the result of an expression that is going
> to be painted. So the expression can be based on several columns. But
> the symbology will always be configured for the main geometry type of
> the layer (making it configurable will be an easy followup).

Ok, cool.

> 
> But as you noted, it will be required to have access to the additional
> columns as geometry (instead of WKT). One task will probably be to make
> the CRS of the additional columns available (IIRC that's not possible
> yet). And the other task to conver WKT to a geometry (already possible?)
> or even better, never ever handle them as WKT.

Correct.
A first step where the additional geometry columns are considered to be
expressed in the same CRS as the main geometry column would already be
interesting.
And yes, that would be better if additional geometries could be accessed
directly as QgsGeometry, and converted to WKT only when needed
(attribute table ?). It's probably only modifications provider-side.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] Plugin Dependencies

[Tim Sutton]

Hi

> On 05 Nov 2015, at 10:50, Richard Duivenvoorde  wrote:
> 
> On 05-11-15 04:56, Tim Sutton wrote:
>>> Some random thoughts:
>>> 
>>> Quite powerful... but ... the current plugin packaging has very
>>> limited requirements: it's just a zipped folder with a couple of
>>> mandatory metadata and a class interface, building a simple plugin is
>>> definitely an easy task.
>>> 
>>> I'm afraid that by using a much more complicate system (such as
>>> setuptools), would solve some problem for the (few) complex plugins
>>> and create a lot of problems and increase the barrier for the vast
>>> majority of simpler plugin authors.
> 




> I agree with Tim, unless we come up with a very simple way, this will
> not solve the problem: "non tech savvy users cannot setup their python
> environment for some complex plug”.


Just a note that the comments above are from Ale, not from me…

Regards

Tim
> 
> The different module versions problem I do not see as a practical
> problem, most times python can work with higher versions. Let's keep it
> the responsibility of the plugin builders to keep up with versions of
> their modules.
> I still think just copy the modules into the plugin is easiest (although
> redundant).
> And if you cannot package the lib with your plugin because of OS
> problems: documentation is the answer...
> 
> Somebody with this insights, maybe can write a chapter about python path
> magics and how QGIS works with that?
> 
> Regards,
> 
> Richard
> 
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

—





Tim Sutton

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
Tim is a member of the QGIS Project Steering Committee

Kartoza is a merger between Linfiniti and Afrispatial



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 2.5D rendering crowdfunding

[Matthias Kuhn]

On 11/05/2015 05:07 PM, Hugo Mercier wrote:
> On 04/11/2015 11:25, Matthias Kuhn wrote:
>> Hi
>>
>> Good to be aware of this. Let's see that we don't do work twice.
>>
>> On 11/04/2015 11:17 AM, Hugo Mercier wrote:
>>> On 04/11/2015 10:19, Régis Haubourg wrote:
 Matthias Kuhn-2 wrote
>  * on-the-fly transformation of geometries while rendering (or with some
> small additions also to create geometries based on attributes)
 Hi, this is quite inline with QEP 46 {0]  about handling geometries to draw
 label paths. Storing geometries in data or having on-the fly smoothing
 expressions for geometries seems to have the same prerequisites for 2.5 D
 and that QEP. Hugo  any opinion on that ? 
 Cheers
 Régis
  [0] https://github.com/qgis/QGIS-Enhancement-Proposals/issues/46
>>> Hi,
>>>
>>> Exact. The concepts seem very close. Except that in one case it is
>>> before painting and in another case, before drawing labels.
>>>
>>> Matthias, is this possible with your proposition to have different parts
>>> of the buildings coming from different geometry columns ?
>>> Currently for a PostGIS table with two geometry columns (or Spatialite I
>>> guess), the second is extracted as a WKT string. I am not sure yet of
>>> what changes would be needed to have them extracted as QgsGeometry. That
>>> would ease (and speed up) such functionalities (2.5D or label paths)
>>
>> Theoretically, yes. It's just the result of an expression that is going
>> to be painted. So the expression can be based on several columns. But
>> the symbology will always be configured for the main geometry type of
>> the layer (making it configurable will be an easy followup).
> Ok, cool.
>
>> But as you noted, it will be required to have access to the additional
>> columns as geometry (instead of WKT). One task will probably be to make
>> the CRS of the additional columns available (IIRC that's not possible
>> yet). And the other task to conver WKT to a geometry (already possible?)
>> or even better, never ever handle them as WKT.
> Correct.
> A first step where the additional geometry columns are considered to be
> expressed in the same CRS as the main geometry column would already be
> interesting.
> And yes, that would be better if additional geometries could be accessed
> directly as QgsGeometry, and converted to WKT only when needed
> (attribute table ?). It's probably only modifications provider-side.
The conversion provider side are probably straightforward (just use the
code that is used to create the main geometry of the feature).
But I don't know if it can be considered an API break. If you have a
plugin that currently makes use of the WKT format, that may be broken by
this change. Maybe implementing QgsGeometry.__str__() is already fine?

>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
Help to improve QGIS rendering possibilities before Nov 30, 2015
http://www.opengis.ch/2015/11/02/qgis-crowdfunding-2-5d-rendering




signature.asc
Description: OpenPGP digital signature
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 2.5D rendering crowdfunding

[Hugo Mercier]

On 05/11/2015 19:10, Matthias Kuhn wrote:
> 
> 
> On 11/05/2015 05:07 PM, Hugo Mercier wrote:

>> Correct.
>> A first step where the additional geometry columns are considered to be
>> expressed in the same CRS as the main geometry column would already be
>> interesting.
>> And yes, that would be better if additional geometries could be accessed
>> directly as QgsGeometry, and converted to WKT only when needed
>> (attribute table ?). It's probably only modifications provider-side.
> The conversion provider side are probably straightforward (just use the
> code that is used to create the main geometry of the feature).
> But I don't know if it can be considered an API break. If you have a
> plugin that currently makes use of the WKT format, that may be broken by
> this change. Maybe implementing QgsGeometry.__str__() is already fine?
> 

Yes good point. And __str__() is a good idea.

___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [Qgis-developer] 2.5D rendering crowdfunding

[Nyall Dawson]

On 6 Nov 2015 06:16, "Hugo Mercier"  wrote:
>
> On 05/11/2015 19:10, Matthias Kuhn wrote:
> >
> >
> > On 11/05/2015 05:07 PM, Hugo Mercier wrote:
>
> >> Correct.
> >> A first step where the additional geometry columns are considered to be
> >> expressed in the same CRS as the main geometry column would already be
> >> interesting.
> >> And yes, that would be better if additional geometries could be
accessed
> >> directly as QgsGeometry, and converted to WKT only when needed
> >> (attribute table ?). It's probably only modifications provider-side.
> > The conversion provider side are probably straightforward (just use the
> > code that is used to create the main geometry of the feature).

I've got a partial implementation of this I tried a while back. I'll dig it
up and see if it's of any use.

Nyall

>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer