[Qgis-developer] Improving ftools geoprocessing tools
giovanni.manghi at gmail.com
Thu Oct 22 05:38:47 PDT 2015
the issues are the following:
there is whole universe of very basic users that need to do classic
geoprocessing operations (clips, unions, etc.) sometimes also with
large/dense geometries, possibly with geometry errors. This users are
usually not able to handle (or willingly to) the possible problems of
using a toolbox based on other software. For them the qgis
geoprocessing tools would be enough (now, as a separet menu as now or
only in processing this is not an issue).
problem is that when using large/dense inputs this qgis tools are
usually very slow, especially when compared to the proprietary
software many are trying to leave. In other worst cases the results
are wrong, but not in a way that is openly wrong, making the usability
of such tools even more difficult.
so said that I understand perfectly what João says, and I would say
that is time to the action, especially considering that there is an
offer on the table.
-- g --
> * Why is the processing toolbox not an option for your users? (Do you
> require shortcuts (menu entries) to the tools? Is it the parameter
> interface which is more fine-tuned? Missing functionality?)
> * Are the processing toolbox tools enough performant for your needs? If
> not, which ones require attention? It would be good to have a list.
> If the first one is a problem, I think it would be an approach to let
> system administrators define "favorite algorithms" (or similar) which
> would then be offered as a shortcut in the menu.
> If the second one applies, then we already have proven the point that
> maintaining the same algorithm twice is silly and the effort should
> rather be put into unifying these tools instead of rewriting duplicate
> code. I will probably soon be working on a test suite for processing
> which should ensure long-term quality assurance for the algorithms
> there. Another advantage of consolidating the two code bases.
> I hope that it's possible for your company to consider different
> approaches for this problem to get to a long-term enhancement.
> Best regards,
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151022/5fca27aa/attachment-0001.sig>
> Message: 5
> Date: Thu, 22 Oct 2015 12:30:26 +0000
> From: Alexandre Neto <senhor.neto at gmail.com>
> To: Lauri Kajan <lauri.kajan at gmail.com>, qgis-developer
> <qgis-developer at lists.osgeo.org>
> Subject: Re: [Qgis-developer] encoding in custom python functions
> <CA+H0G_FD09CD9h1vNbUbP=svU4KqRr6QyEnGhdMvC8JVMPUr2Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
> Ah... I think I now understand what you are saying. You are saying that
> expression files are always saved in your system default encoding system.
> Sorry for the noise.
> Lauri Kajan <lauri.kajan at gmail.com> escreveu no dia qui, 22/10/2015 às
>> Hi Alexandre,
>> The u'ä' works if I tell the file encoding using your snippet
>> # -*- coding: utf-8 -*-
>> But this works only in qgis and is not a correct way.
>> I cannot then debug my function in any IDE cause the file is encoded
>> differently than it says.
>> On Thu, Oct 22, 2015 at 1:37 PM, Alexandre Neto <senhor.neto at gmail.com>
>>> Have you tried to put the following line in the top of the file?
>>> # -*- coding: utf-8 -*-
>>> Lauri Kajan <lauri.kajan at gmail.com> escreveu no dia qui, 22/10/2015 às
>>>> Hi all,
>>>> I'm trying to figure out some encoding problems when using custom python
>>>> expression functions.
>>>> I'm using python functions for defining some label texts. I need use
>>>> some special characters like ä and ö.
>>>> When a new file is created in function editor the file is encoded in my
>>>> system encoding cp1252. At least the ä is coded to 0xe4 if I check that
>>>> with hex-editor.
>>>> Let the custom function just be
>>>> @qgsfunction(args='auto', group='Custom')
>>>> def encodingtest(feature, parent):
>>>> return 'ä'
>>>> This displays on a map like 'Ã¤'
>>>> It seems that the file is converted to utf-8 before execution and the ä
>>>> is then coded to 0xc3 0xa4. Now QGIS still tries to interpret this as
>>>> cp1252 and then displays this as 'Ã¤'.
>>>> It doesn't help to define the ä as unicode like u'ä' because QGIS still
>>>> sees the ä as 0xc3 0xa4 and think that it is in cp1252.
>>>> The only way to resolve this in the code at least that I have found is
>>>> to use
>>>> return 'ä'.decode('utf-8')
>>>> This works on QGIS but the file can't be executed elsewhere (IDE) since
>>>> the file is truly in cp1252 and 0xe4 can't be decoded using utf-8.
>>>> Does anyone else confirm this and have I understood right the problem?
>>>> Should I file a bug report?
>>>> Qgis-developer mailing list
>>>> Qgis-developer at lists.osgeo.org
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20151022/af0b1804/attachment.html>
> Subject: Digest Footer
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> End of Qgis-developer Digest, Vol 120, Issue 96
giovanni.manghi at naturalgis.pt
* WebGIS development
* QGIS/PostGIS Training
* QGIS Support and Consulting
* QGIS development
Google+/Hangouts: giovanni.manghi at gmail.com
Giovanni is QGIS main tester and active member of its development team
More information about the Qgis-developer