[QGIS-Developer] FlagDontResolveLayers in 3.34

[Alexandre Neto via QGIS-Developer]

I have a plugin that was working fine on 3.28, but not it no longer is working 
as expected.

The plugin loads a template project using FlagDontResolveLayers (for faster 
loading), then replaces the source of each of the vector layers, reload them, 
and then save the project as new project.

Now, in 3.34, to make it work, I had to remove the FlagDontResolveLayers, 
otherwise, although the layers sources seem to have been changed, when saving 
the project, none of the layers sources get changed and the final project still 
point to the template data.

Is this a bug? Or something intended, related to the fact that 3.34 projects 
now are much faster to load in the first place?

Thanks!

Alex Neto

Sent with Shortwave 
___
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] [Qgis-psc] Theoretical discussion: A QGIS paid plugin marketplace? (was: sponsored plugin)

[Alexandre Neto via QGIS-Developer]

I would say, why not?

Many other open source projects have opted by having "market places" and
paid plugins (e.g. Blender, Wordpress). This did not stopped many
developers to keep publishing free plugins, while allowed others to have an
easy way to sell their work.

Our plugin repository has now lots of plugins that are no longer working or
with bugs because the developer no longer have the time or will to maintain
it. Maybe if some of these developers could receive a compensation for
their time this could change.

Besides, QGIS is now very robust and offers so many functionality already.
Opposed to the past where some "core" functionality was depending of free
third party plugins.

Notice that there are already paid plugins. Some need api keys to work. And
other are being kept "secret" outside our plugin repository and they could
be useful for many more people.

All the best,

Alex



A sexta, 2/02/2024, 16:38, Régis Haubourg via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hi all,
> I have been sleeping over this thread a bit.
>
> We already have a lot of paid plugins and in the psc we try to contact
> vendors to have them aware of the GPL licence obligations. This is a lot of
> manual work, and this does not scale up obviously.
> Offering a marketplace in our plugin management system can be really
> interesting, since this would give us a way to explain GPL obligations to
> authors and offer them a place to advertise their products a lot better
> than letting them deal with their own systems.
>
> That said, the same question for QGIS.org general funding and
> sustainability also applies.
> We have been having a better fundings this year thanks to marketing
> efforts of Marco and Andreas, which allows us to consolidate some tasks,
> but we still live on a very low budget compared to the size of the project.
>
> Ideas have been thrown about using existing marketplaces (Windows store
> for instance) to collect regular incomes via notarized QGIS installers, but
> this is not an easy move given that we don't have permanent staff to handle
> with the administrative work this gives.
> Developing our own marketplace for plugins could indeed be a way to let
> users do a voluntary contribution to the project when buying a plugin, or
> even trade a very small percentage on sales to maintain the platform. Most
> payment associative tools I know always offer this possibility, I wouldn't
> be shocked personaly.
>
> If we keep a mandatory link to a repository in plugin metadata,  where
> source code is available, I think we preserve users that can't afford to
> pay. We might write down market place terms of use where we ask plugin
> authors for fair uses (no ads, no illegal use, security rules etc, no fake
> repository that would not really allow users to get the real source code..)
>
> And I agree with Alessandro here, having public sources availables will
> still let a large audience to the payment system. QGIS' audience is so
> large.
>
> All in all, this kind of system requires more efforts to maintain
> everything in place, and I would be in favor of growing up the budgets to
> have dedicated persons able to handle this, just like we already manage to
> do with documentation and infrastructure management (Thanks Kartozo, Lova
> and Selma, you do a great job)
>
> In short, I would be in favor of going this way, but we need to handle
> this as it is: grow up QGIS.org core to be able to handle those tasks. And
> growing the budget is the first thing missing maybe.
>
> Best regards
> Régis
>
>
> Le ven. 2 févr. 2024 à 02:01, Emma Hain via QGIS-PSC <
> qgis-...@lists.osgeo.org> a écrit :
>
>> Hi All
>> The economics of this is very interesting.
>>
>> As a community, we want to give something to our fellow members that they
>> need. It allows for our creativity in scratching an itch, and sharing that
>> solution. However, we can break the mold and work out a novel way to
>> deliver. The open-source pledge North Road uses goes some way to doing
>> this. Whilst there a lot of tools are within the licensed (paid) version,
>> those tools are available for release once production costs are met. This
>> enables the plugin to continue to deliver to those who cannot pay for the
>> licensed version, whilst funding further work as technology organically
>> develops or additional needs pop-up. Also note that the remuneration funds
>> our support for the FOSS4G community, whether via sponsorship or applying
>> resources on the committee. So the funding for the plugin gets recycled in
>> the community, as well as going someway to providing a living wage.
>>
>> Shutting out people from the use of desired services should not be what
>> we are about - there has to be another way.
>>
>> In regards to taking over a plugin, this is how FOSS continues, if
>> someone is passionate about it, they can ask the creator to take it over.
>> As part of the marketplace, the community should also have this as a
>> service, a page 

Re: [QGIS-Developer] [postgis-users] QGIS freezes when saving table with AFTER INSERT or UPDATE

[Alexandre Neto via QGIS-Developer]

Uhmm... Thanks.

So there's no way to avoid hanging QGIS while the trigger function(s) is 
running. I am guessing that if I have another trigger function in a table that 
is automatically populated by the first trigger, it will also be executed in 
the QGIS transaction, right?

Thanks Again,

Alexandre Neto

Sent with Shortwave 


On Thu Jan 4, 2024, 11:45 AM GMT, Nicolas Ribot 
 wrote:
> Hello,
>
> A trigger is executed in a single transaction: "The execution of an AFTER 
> trigger can be deferred to the end of the transaction, rather than the end of 
> the statement, if it was defined as a constraint trigger. In all cases, a 
> trigger is executed as part of the same transaction as the statement that 
> triggered it, so if either the statement or the trigger causes an error, the 
> effects of both will be rolled back." 
> (https://www.postgresql.org/docs/16/trigger-definition.html 
> )
>
> So QGIS has to wait for it to finish.
>
> Nicolas
>
> On Thu, 4 Jan 2024 at 11:16, Alexandre Neto via postgis-users 
> mailto:postgis-us...@lists.osgeo.org>> wrote:
>> Sorry for the cross posting.
>>
>> I have a table with the following trigger
>>
>> CREATE TRIGGER tr_base_cont_trocos_ai AFTER
>> INSERT OR UPDATE ON base.cont_troco
>> FOR EACH STATEMENT
>> EXECUTE FUNCTION tr_gerar_outputs();
>>
>> Now, the tr_gerar_outputs() takes some time to process, as it generates new 
>> tables and updates a few materialized views.
>>
>> In QGIS, when I add or update one or more features and press save, I would 
>> expect it to be immediate, but it seems that QGIS hangs waiting for the 
>> function to finish before considering the save operation complete. If the 
>> function fails, it even prevent the feature to be commit.
>>
>> Is this expected for a AFTER INSERT OR UPDATE trigger? Shouldn't PostgreSQL 
>> commit the changes, inform QGIS that the operation was successful and only 
>> then execute the trigger?
>>
>> Thanks,
>>
>> Alexandre Neto
>>
>> Sent with Shortwave 
>> 
>> ___
>> postgis-users mailing list
>> postgis-us...@lists.osgeo.org 
>> https://lists.osgeo.org/mailman/listinfo/postgis-users 
>> ___
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] QGIS freezes when saving table with AFTER INSERT or UPDATE

[Alexandre Neto via QGIS-Developer]

Sorry for the cross posting.

I have a table with the following trigger

CREATE TRIGGER tr_base_cont_trocos_ai AFTER
INSERT OR UPDATE ON base.cont_troco
FOR EACH STATEMENT
EXECUTE FUNCTION tr_gerar_outputs();

Now, the tr_gerar_outputs() takes some time to process, as it generates new 
tables and updates a few materialized views.

In QGIS, when I add or update one or more features and press save, I would 
expect it to be immediate, but it seems that QGIS hangs waiting for the 
function to finish before considering the save operation complete. If the 
function fails, it even prevent the feature to be commit.

Is this expected for a AFTER INSERT OR UPDATE trigger? Shouldn't PostgreSQL 
commit the changes, inform QGIS that the operation was successful and only then 
execute the trigger?

Thanks,

Alexandre Neto

Sent with Shortwave 
___
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] loadNamedStyle() is loading default style instead of QML file

[Alexandre Neto via QGIS-Developer]

I am trying to load a style from a QML file into a vector layer.

When I use a memory layer, loading the style works fine with the following code:

layer = iface.activeLayer()
layer.loadNamedStyle(path_to_style)

If the layer is a postgreSQL layer with a default style, the above code will 
return:

('Loaded from provider', True)

and the style from the QML won't be loaded. The way to force it was add a True 
parameter in the end of the method call:

layer = iface.activeLayer()
layer.loadNamedStyle(path_to_style, True)

Not sure if this is the correct behavior, but it does not match with the 
documentation:

https://api.qgis.org/api/classQgsMapLayer.html#a8b271b8bf3074e84808cff26f722b26f
 


Thanks,

Alexandre Neto___
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] Please unsubscribe me

[Alexandre Neto via QGIS-Developer]

There's an unsubscribe link at the bottom of this message. Only you can do
it.

A segunda, 24/07/2023, 17:56, MATTHEWS, David via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hi folks,
>
>
>
> If possible, please could you unsubscribe me from the QGIS-Developers
> email list? I’ve managed to get myself included onto the QGIS Developers
> email group when I was looking for some help to develop the Georeferencer.
>
>
>
> Thank you,
>
>
>
> *David Matthews* – GIS, ICT Shared Service
>
> Tel: 01244 973158
>
> *e-mail: **david.matth...@cheshireeast.gov.uk
> *
>
>
>
>
>
> 
> Confidentiality: This email and its contents and any attachments are
> intended only for the above named. As the email may contain confidential or
> legally privileged information, if you are not the above named person or
> responsible for delivery to the above named, or suspect that you are not an
> intended recipient please delete or destroy the email and any attachments
> immediately.
>
> Security and Viruses: This note confirms that this email message has been
> swept for the presence of computer viruses. We cannot accept any
> responsibility for any damage or loss caused by software viruses.
>
> Monitoring: The Council undertakes monitoring of both incoming and
> outgoing emails. You should therefore be aware that if you send an email to
> a person within the Council it may be subject to any monitoring deemed
> necessary by the organisation from time to time. The views of the author
> may not necessarily reflect those of the Council.
>
> Access as a public body: The Council may be required to disclose this
> email (or any response to it) under the Freedom of Information Act, 2000,
> unless the information in it is covered by one of the exemptions in the Act.
>
> Legal documents: The Council does not accept service of legal documents by
> email.
> 
> To find out how we use your information see our privacy notice.
>
>
> https://www.cheshireeast.gov.uk/council_and_democracy/council_information/website_information/privacy-notices/privacy-notice.aspx
> 
>
>
> OFFICIAL
> ___
> 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] pyqt5-sip version for building QGIS

[Alexandre Neto via QGIS-Developer]

Hello all,

Can anyone tell me what's the version of PyQt5-sip are we building QGIS?

At conda-forge we are facing a strange bug with QGIS builds in several 
plataforms that is not affecting OSGeo builds:

https://github.com/conda-forge/qgis-feedstock/issues/346 


We think it might be related to the old version of PyQt5-sip being used 
(12.11.0) during the builds compared with the SIP version used in run time. Can 
anyone confirm what version of pyqt5-sip is being used in OSGeo4w builds?

Thanks,

Alexandre Neto___
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] QGIS Documentation Writer - Introduction

[Alexandre Neto via QGIS-Developer]

Welcome Selma,

I am really glad to have a dedicated person to work on our documentation.
Fell free to reach out in case you need help.

Alexandre Neto

A sexta, 21/07/2023, 15:11, Aguilar Bolivar, Rosa (UT-ITC) via
QGIS-Developer  escreveu:

> Glad to hear about you!
>
>
>
> We missed you in the fantastic session on writing documentation during the
> onboarding day (last contributor meeting – ‘s-Hertogenbosch).
>
> Hopefully you will be organizing some more 
>
>
>
> All the best!
>
>
>
> Rosa
>
>
>
> -
>
> Dr. Rosa Aguilar
>
> University of Twente
>
> Faculty of Geoinformation Science and Earth Observation
>
> Connect with me on LinkedIn
> 
>
> https://rosaguilar.github.io
>
> -
>
> The essential is invisible to the eye. Saint-Exupéry
>
>
>
> *From:* QGIS-Developer  *On
> Behalf Of *Selma Vidimlic via QGIS-Developer
> *Sent:* Friday, July 21, 2023 2:15 PM
> *To:* qgis-developer@lists.osgeo.org
> *Subject:* [QGIS-Developer] QGIS Documentation Writer - Introduction
>
>
>
> Hello to everyone.
>
>
> My name is Selma, and I'd like to introduce myself as a QGIS funded
> Documentation Writer. I have a background in geography and GIS, and I've
> been using QGIS for a while, so I'm excited to contribute to this project
> and community.
> My intention is to send you a report every Friday to let you know about
> the most recent contribution I made. I hope you all agree with me; if not,
> please let me know, and if you have any suggestions, please send them to me.
>
>
>
> For now I have set up my environment and I will start with User Manual and
> Training Manual and hopefully next Friday I will send you a report with all
> changes and updates that I made for the week.
>
>
> I think QGIS to be a really essential and truly fantastic project, and I'm
> thrilled to be a part of it.
>
>
>
> Kind regards,
>
> Selma.
>
>
>
> --
>
> Selma Vidimlic Husic
>
> QGIS Documentation Writer
>
> Visit http://kartoza.com to find out about open source:
> * Desktop GIS programming services
> * Geospatial web development
>
> * GIS Training
>
> * Consulting Services
>
> Phone: +387 61 933 651
> ___
> 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] Measuring Map Rendering Time using PyQGIS

[Alexandre Neto via QGIS-Developer]

Hi,

I am looking for a way to audit a QGIS projects in terms of layer rendering
time.

I was able to measuring the rendering every time I refresh the the map
canvas, change layers or change extent, using the following code (inspired
by Anita code):

from datetime import datetime

def get_time():
t1 = datetime.now()
print('Rendering time:',t1-t0, 'seconds')

def reset_time():
global t0
t0 = datetime.now()

canvas = iface.mapCanvas()
canvas.mapCanvasRefreshed.connect(get_time)
canvas.extentsChanged.connect(reset_time)
canvas.layersChanged.connect(reset_time)

Now, I wanted to programmatically zoom in, zoom out, enable and disable
layers, etc... but If I give two or more of these commands together, each
command won't wait for the other to finish rendering, therefore I am unable
to measure the time.

For example:
iface.actionZoomFullExtent()
canvas.zoomByFactor(0.5)

Only returns the time for the last zoom to render.

I have tried using time.wait() but that stops the rendering all together.

Thanks,

Alexandre Neto
___
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] QGIS builds source for qtwebkit?

[Alexandre Neto via QGIS-Developer]

One more question,

Are there any plans to use the new sources? There's only a pre-release by now, 
but at least it's active.

Thanks,

On Mon Jun 19, 2023, 07:51 AM GMT, Alexandre Neto 
<mailto:senhor.n...@gmail.com> wrote:
> Hi Jürgen!
>
> Thanks you very much.
>
> Alex
>
> A domingo, 18/06/2023, 21:09, Jürgen E. Fischer via QGIS-Developer 
> mailto:qgis-developer@lists.osgeo.org>> 
> escreveu:
>> Hi Alex,
>>
>> On Fri, 16. Jun 2023 at 13:39:26 +, Alexandre Neto via QGIS-Developer 
>> wrote:
>> > Are we (actually Jürgen) building qtwebkit from source? what is the source 
>> > that is being used. At conda-forge we were using the link below, which was 
>> > removed from qt.io <http://qt.io> <http://qt.io <http://qt.io>> site.
>> >
>> > http://download.qt.io/snapshots/ci/qtwebkit/5.212/1600955993/src/submodules/qtwebkit-opensource-src-5.212.tar.xz
>> >  
>> > <http://download.qt.io/snapshots/ci/qtwebkit/5.212/1600955993/src/submodules/qtwebkit-opensource-src-5.212.tar.xz>
>> >  
>> > <http://download.qt.io/snapshots/ci/qtwebkit/5.212/1600955993/src/submodules/qtwebkit-opensource-src-5.212.tar.xz
>> >  
>> > <http://download.qt.io/snapshots/ci/qtwebkit/5.212/1600955993/src/submodules/qtwebkit-opensource-src-5.212.tar.xz>>
>>
>> The recipe is at
>>
>> https://github.com/jef-n/OSGeo4W/blob/master/src/qtwebkit/osgeo4w/package.sh 
>> <https://github.com/jef-n/OSGeo4W/blob/master/src/qtwebkit/osgeo4w/package.sh>
>>
>> so the package was built with:
>>
>> https://github.com/qtwebkit/qtwebkit/releases/download/qtwebkit-5.212.0-alpha4/qtwebkit-5.212.0-alpha4.tar.xz
>>  
>> <https://github.com/qtwebkit/qtwebkit/releases/download/qtwebkit-5.212.0-alpha4/qtwebkit-5.212.0-alpha4.tar.xz>
>>
>>
>>
>> Jürgen
>>
>> --
>> Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
>> Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
>> Software Engineer D-26506 Norden https://www.norbit.de 
>> <https://www.norbit.de>
>> QGIS release manager (PSC) Germany IRC: jef on Libera|OFTC
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <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] QGIS builds source for qtwebkit?

[Alexandre Neto via QGIS-Developer]

Hi Jürgen!

Thanks you very much.

Alex

A domingo, 18/06/2023, 21:09, Jürgen E. Fischer via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hi Alex,
>
> On Fri, 16. Jun 2023 at 13:39:26 +0000, Alexandre Neto via QGIS-Developer
> wrote:
> > Are we (actually Jürgen) building qtwebkit from source? what is the
> source that is being used. At conda-forge we were using the link below,
> which was removed from qt.io <http://qt.io> site.
> >
> >
> http://download.qt.io/snapshots/ci/qtwebkit/5.212/1600955993/src/submodules/qtwebkit-opensource-src-5.212.tar.xz
> <
> http://download.qt.io/snapshots/ci/qtwebkit/5.212/1600955993/src/submodules/qtwebkit-opensource-src-5.212.tar.xz
> >
>
> The recipe is at
>
>
> https://github.com/jef-n/OSGeo4W/blob/master/src/qtwebkit/osgeo4w/package.sh
>
> so the package was built with:
>
>
> https://github.com/qtwebkit/qtwebkit/releases/download/qtwebkit-5.212.0-alpha4/qtwebkit-5.212.0-alpha4.tar.xz
>
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden
> https://www.norbit.de
> QGIS release manager (PSC)  Germany IRC: jef on Libera|OFTC
> ___
> 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] QGIS builds source for qtwebkit?

[Alexandre Neto via QGIS-Developer]

Are we (actually Jürgen) building qtwebkit from source? what is the source that 
is being used. At conda-forge we were using the link below, which was removed 
from qt.io  site.

http://download.qt.io/snapshots/ci/qtwebkit/5.212/1600955993/src/submodules/qtwebkit-opensource-src-5.212.tar.xz
 


We found this:

https://github.com/movableink/webkit/releases 


But I wanted to confirm if the official builds use the source from other place.

thanks!

Alexandre Neto___
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] Slow Joins on Virtual Layers

[Alexandre Neto via QGIS-Developer]

Uhmm... That's good to know.

In this case both layers are non-spatial. I will try saving them in shp and 
geopackage to test their performance. If the performance is worst with postgis 
tables, It might be worth opening a ticket.

Alexandre Neto

On Sat May 20, 2023, 07:19 PM GMT, Gabriel De Luca 
<mailto:pablogabrieldel...@gmail.com> wrote:
> Hi,
>
> What I have noticed is that the virtual layer performance drop occurs only 
> joining spatial tables in PostGIS. If the original tables do not contain 
> geometry, or if they are stored in another format (I tried spatialite and 
> shapefile) the performance is normal (a few seconds for an attributes join, 
> output of 10,000 rows without geometry).
>
> It also depends on the number of vertices of the source geometries (one 
> second or less for an attributes join of PostGIS spatial tables, if the 
> source geometries has only ten vertices). I have not yet tried trimming the 
> decimal places of the vertex coordinates of the original geometries.
>
> Despite the fact that the selection does not include the geometry of the 
> original tables, a minute or more of high network traffic with the server and 
> cpu usage is observed, as if the geometries resulting from the join of the 
> features were fully scanned.
>
> Regards,
> Gabriel
>
> El vie, 19 may 2023 a la(s) 11:45, Alexandre Neto via QGIS-Developer 
> (qgis-developer@lists.osgeo.org <mailto:qgis-developer@lists.osgeo.org>) 
> escribió:
>> Hi,
>>
>> I am trying to create a virtual layer that involves an attributes join 
>> between two layers.
>> something like this:
>>
>> SELECT
>> l.seg_via_rodov_id,
>> l.via_rodov_id,
>> vr.nome
>> FROM lig_segviarodov_viarodov as l,
>> "Via rodoviária" as vr
>> where vr.identificador = l.via_rodov_id;
>>
>> These two layer are saved in postgreSQL \ PostGIS and have and there's 
>> actually a foreign key constraint on .via_rodov_id referencing the 
>> vr.identificador.
>>
>> As a virtual layer, this is painfully slow. Slow to the point of waiting 1 
>> or 2 minutes to get the answer, while the same query on postgresql takes 
>> less than one second.
>>
>> Not sure if this is expected or not or if it's a bug.
>>
>> The reason I want to make this query as a virtual layer, instead of loading 
>> it as a postgresql query directly, is because I want to use this relation 
>> information in labels, and I wanted those labels to get updated before I 
>> save the data in the database (to help the editor to understand if a certain 
>> object is already updated or not)
>>
>> I wonder if there's some workaround to help me with this.
>>
>> Thanks
>>
>> Alexandre Neto
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <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] Slow Joins on Virtual Layers

[Alexandre Neto via QGIS-Developer]

Hi,

I am trying to create a virtual layer that involves an attributes join
between two layers.
something like this:

SELECT
  l.seg_via_rodov_id,
  l.via_rodov_id,
  vr.nome
FROM lig_segviarodov_viarodov as l,
  "Via rodoviária" as vr
where vr.identificador = l.via_rodov_id;

These two layer are saved in postgreSQL \ PostGIS and have and there's
actually a foreign key constraint on .via_rodov_id referencing the
vr.identificador.

As a virtual layer, this is painfully slow. Slow to the point of waiting 1
or 2 minutes to get the answer, while the same query on postgresql takes
less than one second.

Not sure if this is expected or not or if it's a bug.

The reason I want to make this query as a virtual layer, instead of loading
it as a postgresql query directly, is because I want to use this relation
information in labels, and I wanted those labels to get updated before I
save the data in the database (to help the editor to understand if a
certain object is already updated or not)

I wonder if there's some workaround to help me with this.

Thanks

Alexandre Neto
___
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] PyQGIS read project from postgresql database

[Alexandre Neto via QGIS-Developer]

Hi,

Actually, after I turned off the computer, I saw the fileName() method in 
documentation.

I tried it and I realised that both my password and project name needed percent 
encoding some characters.

So I have parsed my uri string with urllob.parse.quote to make it work 
correctly.

Not sure if there's a more convenient way to do it.

Thanks for the help German.

Alex Neto

On Sat May 13, 2023, 02:23 AM GMT, Germán Carrillo 
<mailto:carrillo.ger...@gmail.com> wrote:
> Hi,
>
> what do you get if you run the following line on your QGIS Python console in 
> a QGIS session where your project (the one stored in PG) is loaded?
>
> QgsProject.instance().fileName()
>
> Regards,
>
> Germán
>
>
> El vie, 12 may 2023 a las 19:22, Alexandre Neto via QGIS-Developer 
> (mailto:qgis-developer@lists.osgeo.org>>) 
> escribió:
>> Hi,
>>
>> I am trying to read a project that is stored in a postgreSQL/PostGIS 
>> database, but I am struggling with getting it correctly. I am using the 
>> following code
>>
>> project = QgsProject.instance()
>> uri = 
>> 'postgresql://my_user:my_pass@localhost:5432?sslmode=disable=my_database=my_schema=my_project_name'
>> project.read(uri)
>>
>> The last command always return false, and no project is loaded
>>
>> The documentation of QgsProject.read() only mentions filenames, not uri, but 
>> this answer seems to propose this uri format that would work:
>>
>> https://gis.stackexchange.com/a/354615/6191 
>> <https://gis.stackexchange.com/a/354615/6191>
>>
>> Any suggestions on how to solve or debug this? I get no error messages from 
>> the read method.
>>
>> Thanks,
>>
>> Aleandre Neto
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
>> <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
>
>
> --
> ---
> |\__
> (:>__)(
> |/
> Soluciones Geoinformáticas Libres
> http://geotux.tuxfamily.org/ <http://geotux.tuxfamily.org/>
> https://twitter.com/GeoTux2 <http://twitter.com/GeoTux2>
>
>
[image] <http://gis.stackexchange.com/users/4972/germ%c3%a1n-carrillo>___
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] PyQGIS read project from postgresql database

[Alexandre Neto via QGIS-Developer]

Hi,

I am trying to read a project that is stored in a postgreSQL/PostGIS
database, but I am struggling with getting it correctly. I am using the
following code

project = QgsProject.instance()
uri = 'postgresql://my_user:my_pass@localhost
:5432?sslmode=disable=my_database=my_schema=my_project_name'
project.read(uri)

The last command always return false, and no project is loaded

The documentation of QgsProject.read() only mentions filenames, not uri,
but this answer seems to propose this uri format that would work:

https://gis.stackexchange.com/a/354615/6191

Any suggestions on how to solve or debug this? I get no error messages from
the read method.

Thanks,

Aleandre Neto
___
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] [Qgis-community-team] QGIS webserver size vs publishing old docs

[Alexandre Neto via QGIS-Developer]

I would say keeping 3 LTRs documentations would be more than enough, if needed 
we can leave just keep the PDFs for historic.

Alexandre Neto

On Mon Mar 20, 2023, 11:21 AM GMT, DelazJ  wrote:
> Hi all (and sorry for the cross-post)
>
> Richard has raised the issue a couple of times with no specific 
> feedback/decision but I think now we NEED to go forward : there is not enough 
> space on our servers to store everything we want to share.
> Yesterday, I updated the docs infrastructure to serve translated versions of 
> the 3.28 documentation but they are not published this morning, probably 
> because of lack of space to get them pasted.
>
> # du -hs *
> 255M doc-test
> 579M QGIS-Documentation
> 7.2G QGIS-Documentation-2.14
> 6.3G QGIS-Documentation-2.18
> 7.7G QGIS-Documentation-2.8
> 12G QGIS-Documentation-3.10
> 11G QGIS-Documentation-3.16
> 9.4G QGIS-Documentation-3.22
> 579M QGIS-Documentation-3.28
> 8.0G QGIS-Documentation-3.4
> 31G QGIS-tests
> 16G QGIS-Website
>
> An option could be to rent a bigger webserver but a few questions/suggestions 
> so far (I'm only speaking for the docs as I don't know what is behind other 
> folders):
> - Do we need to serve all these versions? FYI we recently silently removed 
> and redirected <2.8 docs (and nobody complained) so we could probably be more 
> "aggressive"
> - It could be nice to define some strategy on this area: e.g. we keep 
> publishing master, current LTR, previous LTR and any older URL is redirected 
> to current LTR --> meaning that today we would be serving only testing in 
> English, 3.28 and 3.22 in English + translations. OR one more older LTR (ie 
> 3.16)?
>
> PS: this issue somehow also affects the PyQGIS documentation repo [0], due to 
> github-pages size limits
>
> Regards,
> Harrissou
>
> [0] https://github.com/qgis/pyqgis/issues/104#issuecomment-1354338491 
> ___
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] Offering QGIS installers through Windows store

[Alexandre Neto via QGIS-Developer]

Regarding conda-forge,

Qt update wait was quite unfortunate, but other than that the community is
generally quite responsive.

Currently QGIS stable and LTR versions are being built for Windows, Mac OS
and Linux with Python 3.8, 3.9, 3.10 and 3.11.

Alexandre Neto

A terça, 20/12/2022, 10:02, Matthias Kuhn via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hi all,
>
> I have had quite good experience with vcpkg for packaging qfield [1] (and
> remember waiting for months for qt updates on conda), we are also
> considering this for building mac packages.
> Furthermore, there are many dependencies already prepared for UWP as first
> class citizen.
>
> If a change of the build system is something to be discussed, I think a
> review of available systems would be good.
>
> Matthias
>
> [1]
> https://www.opengis.ch/2022/09/20/how-we-build-qfield-for-many-platforms-a-look-behind-the-curtain/
>
> On Sat, Dec 17, 2022 at 11:23 PM Even Rouault via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Hi,
>>
>> I've said it a few times, but I'll repeat myself one more time as it
>> can't hurt :-) I'd strongly advise for QGIS Windows installer to rely on
>> the massive Conda-Forge packaging effort. OSGeo4W is a bit of a
>> masochist effort when one sees that it packages everything from scratch,
>> a bit like if QGIS would take the responsibility of creating a Linux
>> distro from scratch, whereas leveraging Conda-Forge would enable QGIS to
>> benefit from > 90% of its dependencies already packages by a much bigger
>> community. The QGIS community could then concentrate on the QGIS build
>> recipee, and probably a few other packages specific to QGIS. Then the
>> QGIS installer itself would mostly bundle a subset of Conda-Forge
>> dependencies pinned at the wished versions.
>>
>> Even
>>
>> Le 16/12/2022 à 16:59, Julien Moura via QGIS-Developer a écrit :
>> > Hello,
>> >
>> > I'm working on the packaging purpose at Oslandia.
>> >
>> > Because we are committed to pushing QGIS in the most industrial
>> > information systems, at Oslandia we have been very interested in QGIS
>> > deployment for a few years now.
>> >
>> > We have reused and actively contributed to many projects: OSGeo4W v1
>> > mirror, NSIS and PowerShell recipes, presentations at FOSS4Gs (or at
>> > QGIS conferences), etc.
>> >
>> > Since this year, we are making efforts to de-correlate software
>> > deployment and end-user configurations (profiles): the QGIS Deployment
>> > Toolbelt (https://guts.github.io/qgis-deployment-cli/) has been
>> > created with this goal. It is still a young project and also it is one
>> > project among many others.
>> >
>> > We are obviously very interested in this project of packaging QGIS on
>> > Windows Store, a topic that we already discussed internally last year
>> > and that I discussed namely with Régis Haubourg in Florence. We
>> > obviously have some question marks and discussion points to make sure
>> > that all the process is in line with community and open-source
>> > governance. Still, it will be quite a challenge and we think it is a
>> > good direction to follow.
>> >
>> > As noted by others, this seems a huge undertaking though, and
>> > uncertainty paves the road and make this goal a distant future.
>> >
>> > We could start with gathering and referencing all resources dedicated
>> > to packaging, which would sum up as a website ( packaging.qgis.org ?)
>> > with all documentation regarding OSGeo4W recipes ( beyond the aging
>> > OSGeo trac ), and other packaging methods, like customized .deb
>> > packaging.
>> >
>> > The goal is to structure and promote knowledge on this topic to
>> > attract packager in addition to developers.
>> >
>> > And then we would also create packaging process documentation for
>> > Windows Store.
>> >
>> > Regards,
>> > Julien M
>> >
>> > Le 23/11/2022 à 10:41, Even Rouault via QGIS-Developer a écrit :
>> >>>
>> >>> - There is a requirement for every library in the package to be "UWP
>> >>> compatible".
>> >>>   At that time, libpq (postgresql) didn't have that, so I stopped.
>> >>> It's hard to say how many other packages will also need special
>> >>> attention. [1]
>> >>
>> >> Interesting. I know that people have contributed in the past fixes to
>> >> make PROJ *compilable* with UWP, but as we don't have a CI target for
>> >> that, it is unknown how it behaves at runtime.
>> >>
>> >> GDAL likely fails to build with UWP according to
>> >> https://github.com/OSGeo/gdal/issues/1201
>> >>
>> >> Without a CI target that can be hooked into github action (maybe that
>> >> exists. didn't check), UWP compatibility on the long term is going to
>> >> be hard to achieve.
>> >>
>> >
>> > ___
>> > 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] QGIS Plugin crash

[Alexandre Neto via QGIS-Developer]

Hello Jose,

Your English sounded quite good to me :)

This is the repository where you should report these bugs to the plugin
authors:

https://github.com/geomatico/qgis-sigpac/issues

Best regards,

Alexandre Neto

Jose Antonio Fernandez Martin via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu no dia quarta, 23/11/2022 à(s)
11:52:

> Hello everyone,
>
> my name is Jose and I have just suscribed to this mailing list. Apologies
> if my English is not very accurate, as I don't practice it very often here
> in Spain :-)
>
> My organization is having problems when using QGIS 3.14.15 with the
> "SIGPAC downloader" plugin. And I haven't found any bug tracker for that
> specific plugin so according to the QGIS Plugin page I should report the
> problem on this list. Upgrading to QGIS 3.22 doesn't solve the problem.
>
> The first issue comes when the plugin is installed. An error says "The
> plugin 'sigpac_downloader' could not be loaded because an error ocurred
> when calling the classFactory method" (translated from my spanish version
> of QGIS)
>
> The full error trace is provided in the attached document
> "SIGPACDownloader_install.txt"
>
> However there is apparently one workaround to that issue, you just have to
> select "reinstall" plugin and it finishes ok. After re-entering QGIS, the
> plugin is loaded and the menu entry appears in the "plugins" menu entry.
>
> But the real problem comes when trying to use the plugin: The SIGPAC
> Downloader window opens and says you have to accept the Terms Of Use. When
> clicking on the proper button, a new window opens with blank content
> (nothing is loaded) and after a few seconds the QGIS "Unexpected Error"
> window appears suggesting to report the crash and quit the program. The
> crash report is enclosed in this email as "stack.txt"
>
> Some relevant information about our QGIS settings: An HTTP Proxy is used
> for web connections, so the server, port, username and password are set in
> order to access the plugin repository.
>
> Looking forward to read from you.
>
> Kid regards,
>
> Jose.
> ___
> 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] Question about proj data files in the QGIS application folder

[Alexandre Neto via QGIS-Developer]

Hello Luca,

Yes, QGIS uses it for do precise coordinate system translations. Your users
may not use all of them, but I would avoid removing it.

You say you don't use MSI, but why don't you use the OsGeo4w installer?
It's much more convenient for larger organizations. You can do a download
only installation to get all packages into a network drive folder, then
reuse that folder for all installations in the users machines.

Also, to update QGIS, all you need is to run the installer again and it
will only download the updated packages instead of all packages. Again,
first installation will fetch any needed packages, the following machines
will just reuse it.

Alexandre Neto
User Support
www.qcooperative.net

A terça, 8/11/2022, 08:34, Luca Manganelli via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hello,
>
> I am preparing the QGIS Windows package file (it's a zip file) for
> distribution in our organization (we don't use MSI).
>
> I noticed that the folder /share/proj contains TIF files and it weighs 584
> MB, are they necessary for the working of the QGIS?
>
> Thank you and have a nice day
> Luca
>
>
> --
>
> Comune di Trento
>
> via Belenzani, 19 - 38122 Trento | C.F e P. IVA: 00355870221
>
> tel. +39 0461.884111 | www.comune.trento.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 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] Revolt Chat Community Server

[Alexandre Neto via QGIS-Developer]

Hi Regis,

Thanks for your well though email.

Despite local/platform specific communities can arise without any notice, I
agree that the QGIS project should choose one official mean of
communication. It used to be these mailing lists, but lately it's very
quite, which suggests that discussions and decisions are probably being
taken somewhere else.

So I do believe the project could/should discuss this situation. Something
that could still leverage email and that allows archiving and browsing of
old messages would be great.

Best Regards,

Alex Neto


A quarta, 2/11/2022, 20:37, Régis Haubourg via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hi Ethan,
>
> thanks for the work with Revolt. I tried it during the developer meeting
> in Firenze, but I did not persist in using it. Let me explain why and
> please excuse me in advance, this is a pretty long mail!
>
> First, before jumping to a tool, I would like that we discuss globally the
> communication challenges that all those new tools bring for all online
> communities - QGIS included.
>
> I experienced the very same situation with mailing list and a spontaneus
> Discord server ( at my paragliding club) and I learned a few things, both
> positive and negative.
>
> # Where are we now ?
>
> - mailing lists are dying. Younger won't jump in. Being at ease suppose a
> good email client and filter rules. And this is a pain. What is really
> unique is that they are indexed by search engine and accessible via public
> archives. We built a knowledge base each time we post a mail. Osgeo also
> offers a central hub where one can't explore existing mailing lists, and
> this was a really nice to me.  Now that Nabble is dead, there is no more
> forum-like web access. And let's not forget that some people just don't
> want to use apps, and would like to stick to mail forever.  So we can't
> stay without decision here.
>
> - Chats are fun, but messy, and they break our community in sub parts.
> Telegram / IRC / Element -Matrix / Gitter / Signal / WhatsApp etc...
> Furthermore, there are multiple channels that you can't be aware if you're
> not invited into. This is a serious regression, because transparency and
> public discussion is a key principle of Free software.
>
> - Chats aren't efficient and generate too much traffic. I personnaly just
> don't have enough bandwidth to follow 10% of the channels I should follow.
> And I am pretty involved. Furthermore, each country seems to have its
> preferences on which too to use. I ended up in having 6 apps on my phone
> only for those channels. This is far from ideal. Let's not forget that some
> people will never leave IRC too :) (and some have older phones not
> supporting so many apps).
>
> - Discord / Revolt are organized chats, with topics. They have nice apps.
> They are still it is some kind of private place if this can't be found via
> a search engine. Maybe Revolt can be indexed?  At one point, I think they
> also start to be messy and require so clear rules for category / topics
> management, and archiving discussions. The Revolt instance has too much
> categories IMO.
>
> - we also have issues, Pull requests and potential GitHub discussions to
> not forget here :)
>
> - adding a new communication channel without stating officially which is
> the main channel just breaks the single source of truth principle we had
> with mailing lists. I have seen recently two feedback from community users
> thinking that there was no debate on major topics, just because the
> discussion on the mailing list topics stalled. But those discussions in
> fact did occur, but spread across those new channels, and we didn't have
> enough bandwidth to summarize the decision on the mailing list (and we also
> forgot). This is the most annoying issue.
>
> - Side note, I didn't have a good user experience with Revolt, the app
> seems still a bit young. But I am pretty sure it will get more mature.
>
> - Last but not least, after discussing this issue in the French OSGeo
> local chapter and with open data groups, I discovered (yet) another option,
> which is Discourse.
>
> Discourse is a modern forum, that can act as a chat if you are inline, or
> a mailing list, and let users tune their notifications levels pretty
> nicely.  Just have a look to the main page, stating the principles of this
> tool [0]
>
> There are tools to migrate mailman history archives to Discourse. Gnome
> project just chose this path recently. [1] (thanks Marco for your pointers
> here)
>
> S, we are all now facing the "too much choice" situation and user's
> confusion.
>
> # How to adress this situation ?
>
> So I would like to propose the following approach, which is basically the
> Gnome's project strategy.
>
>  - Discourse as one organized and persistent place, including the osgeo
> history discussions. This would be the main communication channel. I will
> contact OSGEO to see if the system administration committee want to go this
> way for all the 

[QGIS-Developer] QGIS and Python 3.8

[Alexandre Neto via QGIS-Developer]

Hi,

In the download page there is a message saying that QGIS needs at least
windows 8 because it uses Python 3.9 or above.

At conda-forge we are building QGIS 3.22 and 3.26 with python 3.8, 3.9 and
3.10. Should we drop 3.8? What are the current implications?

Thanks,

Alexandre Neto
___
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] Import DWG\DXF use curves option

[Alexandre Neto via QGIS-Developer]

Yes, I believe so.

My linestrings are also simple, now rounded corners, but it still promotes
it to compoundcurves, which is them harder to import to PostGIS.

I have ended up using ogr2ogr with the option

-nlt CONVERT_TO_LINEAR

A segunda, 10/10/2022, 16:29, Richard Duivenvoorde 
escreveu:

> On 10/10/22 17:11, Alexandre Neto via QGIS-Developer wrote:
> > Hi,
> >
> > Not sure of a feature or a bug, but shouldn't disabling the "use curves"
> in the Import DWG\DXF tool output non-compound curve geometries?
> >
> > I am getting curves even with the option turned of.
>
> Mmm, seeing this message... could the following be maybe related?
>
> Recently I created a Polygon with a hole, and copied one feature (WKT
> output), and also was presented with a 'CompoundCurve' part in it (while
> all was square)...
>
> MultiPolygon (((6.13102839454553816 52.75093214925507823,
> 6.130964672425808 52.74717640996099277, 6.14539911649133597
> 52.7466899769035038, 6.14536915982601872 52.75123707754761426,
> 6.13102839454553816 52.75093214925507823), CompoundCurve
> ((6.13427151349723498 52.75005518140639538, 6.13467440942566444
> 52.7482075319318966, 6.14346286447305268 52.7477566482503093,
> 6.14241109067726665 52.74974024139419271, 6.13427151349723498
> 52.75005518140639538
>
> For reference: I created a quick MultiPolygon type Memory layer, as 2
> rectangles(!)
>
> This is above feature as GeoJson:
>
>
> {"features":[{"bbox":[6.130965,52.74669,6.145399,52.751237],"geometry":{"coordinates":6.131028,52.750932],[6.130965,52.747176],[6.145399,52.74669],[6.145369,52.751237],[6.131028,52.750932]],[[6.134272,52.750055],[6.134674,52.748208],[6.143463,52.747757],[6.142411,52.74974],[6.134272,52.750055,"type":"MultiPolygon"},"id":-9,"properties":null,"type":"Feature"}],"type":"FeatureCollection"}
>
> Could this be related?
>
> Regards,
>
> Richard Duivenvoorde
>
___
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] Import DWG\DXF use curves option

[Alexandre Neto via QGIS-Developer]

Hi,

Not sure of a feature or a bug, but shouldn't disabling the "use curves" in
the Import DWG\DXF tool output non-compound curve geometries?

I am getting curves even with the option turned of.

Should I open a ticket?

Thanks,

Alexandre Neto
___
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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

It's probably out of the scope of this migration, but following your idea,
I wonder if the python console/editor and underlying code could be used
also to run SQL?

A quinta, 8/09/2022, 22:13, Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com> escreveu:

> This decision makes sense to me, but I still miss an SQL interface – I
> mean an SQL-oriented interface for data as GDAL does even for unnecessary
> cases. QGIS has a python-first approach but I don't think this should be
> the only or the mandatory way to approach GIS data.
>
> Alexandre Neto says:
>
>> I am big QGIS/PostGIS user and DB manager in QGIS allows me to do
>> something that you can't do elsewhere, run long spatial analysis using SQL.
>
> while Richard Duivenvoorde replies:
>
>> My de facto client is DBeaver, a cross platform FOSS general Database
>> client (written in Java).
>> It even has a simple spatial viewer (as: show geometries on OSM, both for
>> Postgis and Geopackages) in the data tabs.
>
>
>  DBeaver is a great tool if you have to move data from one DBMS to another
> and has even a simple geometry viewer, but what I think QGIS should provide
> is a data-oriented interface, something that could mix procedural tools
> that work on the client with dbms resident functions. In reality, if you
> deal with data and resort to views based on native Postgis functions, it's
> much better to have a good SQL interface in QGIS than simply visualising
> geometries in DBeaver. Let alone, as Paolo Cavallini says, using topology.
> Nothing against the idea of a better integration that implies an optional
> role of the plug-in, but the outcome is an implicit choice for a
> traditional client-server approach vs a well-balanced orientation we
> enjoyed. I would appreciate a move in the opposite direction, but it's only
> a personal preference.
>
> On Thu, Sep 8, 2022 at 4:33 PM Alexandre Neto via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Yes, ti seems to. thanks!
>>
>> Nyall Dawson  escreveu no dia quinta, 8/09/2022
>> à(s) 10:16:
>>
>>> On Thu, 8 Sept 2022 at 19:08, Alexandre Neto via QGIS-Developer
>>>  wrote:
>>> >
>>> > Hi,
>>> >
>>> > In the end, Richard ended up closing the project. But I was able to
>>> create a new one. Can someone with QGIS organization owner privileges
>>> please make it public?
>>>
>>> Done, I think ...
>>>
>>> Nyall
>>>
>>> >
>>> > https://github.com/orgs/qgis/projects/3/settings
>>> >
>>> > Thanks
>>> >
>>> > Alexandre Neto
>>> >
>>> >
>>> > Richard Duivenvoorde via QGIS-Developer <
>>> qgis-developer@lists.osgeo.org> escreveu no dia quarta, 7/09/2022 à(s)
>>> 16:02:
>>> >>
>>> >> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
>>> >> > Hi
>>> >> >
>>> >> > Can anyone please create a github project for dbmanager migration?
>>> I don't have enough permissions for it.
>>> >>
>>> >> I had never heard of 'projects'... but Alexandre helpt me to create:
>>> >>
>>> >> https://github.com/orgs/qgis/projects/1
>>> >>
>>> >> Please let me know if it works...
>>> >>
>>> >> Regards,
>>> >>
>>> >> Richard Duivenvoorde
>>> >>
>>> >> ___
>>> >> 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
>>
>
___
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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Yes, ti seems to. thanks!

Nyall Dawson  escreveu no dia quinta, 8/09/2022
à(s) 10:16:

> On Thu, 8 Sept 2022 at 19:08, Alexandre Neto via QGIS-Developer
>  wrote:
> >
> > Hi,
> >
> > In the end, Richard ended up closing the project. But I was able to
> create a new one. Can someone with QGIS organization owner privileges
> please make it public?
>
> Done, I think ...
>
> Nyall
>
> >
> > https://github.com/orgs/qgis/projects/3/settings
> >
> > Thanks
> >
> > Alexandre Neto
> >
> >
> > Richard Duivenvoorde via QGIS-Developer 
> escreveu no dia quarta, 7/09/2022 à(s) 16:02:
> >>
> >> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
> >> > Hi
> >> >
> >> > Can anyone please create a github project for dbmanager migration? I
> don't have enough permissions for it.
> >>
> >> I had never heard of 'projects'... but Alexandre helpt me to create:
> >>
> >> https://github.com/orgs/qgis/projects/1
> >>
> >> Please let me know if it works...
> >>
> >> Regards,
> >>
> >> Richard Duivenvoorde
> >>
> >> ___
> >> 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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Hi,

In the end, Richard ended up closing the project. But I was able to create
a new one. Can someone with QGIS organization owner privileges please make
it public?

https://github.com/orgs/qgis/projects/3/settings

Thanks

Alexandre Neto


Richard Duivenvoorde via QGIS-Developer 
escreveu no dia quarta, 7/09/2022 à(s) 16:02:

> On 9/7/22 14:52, Alexandre Neto via QGIS-Developer wrote:
> > Hi
> >
> > Can anyone please create a github project for dbmanager migration? I
> don't have enough permissions for it.
>
> I had never heard of 'projects'... but Alexandre helpt me to create:
>
> https://github.com/orgs/qgis/projects/1
>
> Please let me know if it works...
>
> Regards,
>
> Richard Duivenvoorde
>
> ___
> 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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Sandro, thanks for the clarification.

Sandro Santilli via QGIS-Developer 
escreveu no dia quarta, 7/09/2022 à(s) 22:28:

> On Tue, Sep 06, 2022 at 06:15:46PM +0200, Paolo Cavallini via
> QGIS-Developer wrote:
> > I believe it is the only way to visualize topogeoms from
>
> Just a clarification: the DBManager TopoViewer does not visualize
> "TopoGeometry" objects (which is what I usually refer to by
> "topogeoms") but simple features being the primitives of topologies.
>
> Visualizing TopoGeometry objects (topology layers) is supported by core
> QGIS (PostgreSQL provider) since version 2.0.0 (2012)
>
> --strk;
> ___
> 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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Hi

Can anyone please create a github project for dbmanager migration? I don't
have enough permissions for it.

Alexandre Neto

Paolo Cavallini via QGIS-Developer 
escreveu no dia terça, 6/09/2022 à(s) 17:16:

> Hi all,
>
> Il 06/09/22 17:41, Julien Cabieces via QGIS-Developer ha scritto:
> >
> > Hi!
> >
> > I added recently one comment in your table regarding TopoViewer because
> I met
> > somebody at Foss4G who was using it. From what I understand, it
> > generates several vector layers to visualise topology when extension is
> > enabled in PostgreSQL.
> >
> > I don't know if it is widely used, if the feature is stable/maintained
>
> I confirm
>
> > or if there is other QGIS plugin able to provide such visalization.
>
> IMNSHO not. I believe it is the only way to visualize topogeoms from
> PostGIS.
>
> Thanks!
> --
> Paolo Cavallini
> www.faunalia.eu - QGIS.org
> training, support, development on QGIS, PostGIS and more
> ___
> 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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Hi!

I didn't receive much input in this table, so I will go ahead and create a
few feature requests as Nyall asked for those functionalities not yet
covered by a viable workaround.
I will be up to the project to decide which are crucial, nice to have or
simply won't fix/implement.

Alexandre Neto

Alexandre Neto  escreveu no dia segunda, 8/08/2022
à(s) 11:52:

> The link...
>
>
>
> https://docs.google.com/spreadsheets/d/1VyC_kYJU3qmWrzXzjeZuHGBjwE6O2lPov_c0LnO-AUA/edit?usp=sharing
>
> Alexandre Neto
>
> A sábado, 6/08/2022, 21:08, Alexandre Neto 
> escreveu:
>
>> Hi,
>>
>> Sorry for the long waiting. I have made a functionality matrix for db
>> manager and possible alternatives. I am not sure if all is correct so
>> please feel free to edit or comment.
>>
>> After your edits I will create the migragion feature requests.
>>
>> Best regards,
>>
>> Alexandre Neto
>>
>> A segunda, 11/07/2022, 08:11, Alexandre Neto 
>> escreveu:
>>
>>> Hi Nyall,
>>>
>>> A segunda, 11/07/2022, 00:47, Nyall Dawson 
>>> escreveu:
>>>

 I wonder if you'd be willing to lead an effort to document the missing
 functionality from dbmanager, and file QGIS tickets for these and
 assign them to a new project in the QGIS github for "deprecating db
 manager"?
>>>
>>>
>>> Sure I will! I am on vacations, but next week I will start working on it.
>>>
>>> Thanks!
>>>
>>> Alexandre
>>>
>>
___
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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

The link...


https://docs.google.com/spreadsheets/d/1VyC_kYJU3qmWrzXzjeZuHGBjwE6O2lPov_c0LnO-AUA/edit?usp=sharing

Alexandre Neto

A sábado, 6/08/2022, 21:08, Alexandre Neto  escreveu:

> Hi,
>
> Sorry for the long waiting. I have made a functionality matrix for db
> manager and possible alternatives. I am not sure if all is correct so
> please feel free to edit or comment.
>
> After your edits I will create the migragion feature requests.
>
> Best regards,
>
> Alexandre Neto
>
> A segunda, 11/07/2022, 08:11, Alexandre Neto 
> escreveu:
>
>> Hi Nyall,
>>
>> A segunda, 11/07/2022, 00:47, Nyall Dawson 
>> escreveu:
>>
>>>
>>> I wonder if you'd be willing to lead an effort to document the missing
>>> functionality from dbmanager, and file QGIS tickets for these and
>>> assign them to a new project in the QGIS github for "deprecating db
>>> manager"?
>>
>>
>> Sure I will! I am on vacations, but next week I will start working on it.
>>
>> Thanks!
>>
>> Alexandre
>>
>
___
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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Hi,

Sorry for the long waiting. I have made a functionality matrix for db
manager and possible alternatives. I am not sure if all is correct so
please feel free to edit or comment.

After your edits I will create the migragion feature requests.

Best regards,

Alexandre Neto

A segunda, 11/07/2022, 08:11, Alexandre Neto 
escreveu:

> Hi Nyall,
>
> A segunda, 11/07/2022, 00:47, Nyall Dawson 
> escreveu:
>
>>
>> I wonder if you'd be willing to lead an effort to document the missing
>> functionality from dbmanager, and file QGIS tickets for these and
>> assign them to a new project in the QGIS github for "deprecating db
>> manager"?
>
>
> Sure I will! I am on vacations, but next week I will start working on it.
>
> Thanks!
>
> Alexandre
>
___
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] Digitize shapes in advanced digitizing toolbar concerns/suggestions

[Alexandre Neto via QGIS-Developer]

Hi,

I came across the "recent" change that integrates the options to select to
digitize with segments, curves, shapes, or streaming into a combobox
button. I love it. It makes sense. Thanks, Denis for it.

Nevertheless, the shapes option is dependent on another toolbar (Shape
Digitizing Toolbar), which had led to some bugs [0] but also to some
frustration to some users, not understanding why a strange message appear
when they just want to draw a polygon.

I opened a PR to change the wording of the message that informs the user
that if he decided to digitize using shapes, then he also needs to select
the shape he wants to use [1], but he might not even remember that the last
time he used it, he selected to digitize using shapes.

My suggestions:

1. On QGIS reload, always rollback to "digitize with segment" as default
2. On selecting shapes, automatically enable the Shape Digitizing Toolbar
3. On selecting shapes, automatically enable one of the options in the
shape digiting toolbar, to solve [0], even if the user never used it before.

I can open a feature request if more people agree.

Best regards,

Alexandre Neto
[0] - https://github.com/qgis/QGIS/issues/47648
[1] - https://github.com/qgis/QGIS/pull/49425
___
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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Hi Nyall,

A segunda, 11/07/2022, 00:47, Nyall Dawson 
escreveu:

>
> I wonder if you'd be willing to lead an effort to document the missing
> functionality from dbmanager, and file QGIS tickets for these and
> assign them to a new project in the QGIS github for "deprecating db
> manager"?


Sure I will! I am on vacations, but next week I will start working on it.

Thanks!

Alexandre
___
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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Hi Richard

A domingo, 10/07/2022, 08:56, Richard Duivenvoorde via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> On 7/10/22 03:02, Alexandre Neto via QGIS-Developer wrote:
>
> > This db manager functionality is unique, and is (in my opinion) one of
> the reasons why QGIS is PostGIS de facto client.
>
> Hi Alexandre,
>
> My de facto client is DBeaver, a cross platform FOSS general Database
> client (written in Java).
>

I know dbeaver and like it alot and I use it too, but IMHO sending people
to another software is not a solution.

It even has a simple spatial viewer (as: show geometries on OSM, both for
> Postgis and Geopackages) in the data tabs.
> (in my setup I have Mysql(spatial), Postgis, Geopackages and Oracle
> connections in one set)
>
> Changing constraints/permissions/edits in data etc etc is really 'simple'
> (as in via gui).
>

This is what I use dbeaver for, and as I said before that is not my main
concern.


> So running a spatial analysis to me is:
> - run a query in a .sql file, create a view or temporary table
> for it
> - load it in QGIS
> (- saving all queries including comments in that sql file)
>

Now this is where I think the workflow is incomparable. In QGIS you can
overlap and see several results at the same time. something that it's not
possible to do in dbeaver (or pgadmin). You can easily change your query
and reload again in a very easy and fast way. Creating views or temporary
tables in dbeaver to go and open it in QGIS, then if something went off go
back to dveaver do it again... Nah... :-p


> Would that be a work around for you?
>
> It is like: A DB client like DBeaver should not try to be a (Q)GIS and
> vice versa ;-)
>

I agree! My worries are not power users like you and me, we can use several
software at the same time without crossing the wires, But it's damn hard to
make common GIS folks transition to spatial databases and spatial SQL.
Although Alessandro brilliant work will help this transition, the SQL
editor from dbmanager was by far the best tool for spatial SQL.

This being said, I understand that db manager will eventually die anyway
for lack of maintenance if nothing is done otherwise. I just ask for some
time so we have a plan for making sure that important functionality is not
delegated to third party plugins.

Maybe I should lead a QEP followed by a crowd funding? If that is the issue.

"We" added lots of new functionality to QGIS, some of which I probably
won't ever use, I am ok with it, but it's hard to see functionality I use
everyday go away.

Thanks,

Alexandre


> Regards,
>
> Richard Duivenvoorde
> ___
> 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] Time for db manager to become an "opt-in" plugin?

[Alexandre Neto via QGIS-Developer]

Hello all,

-1 for me

I am big QGIS/PostGIS user and DB manager in QGIS allows me to do something
that you can't do elsewhere, run long spatial analysis using SQL.

I understand the development reasons for removing db manager from the
official release and I really enjoy all the effort that Alessandro put to
bring most functionality to the browser. Nevertheless, I don't think it
fully replaces db manager querying functionality, and I really don't think
it will ever do.

The execute SQL dialog is great and amazingly fast, but it doesn't replace
the db manager editor. The QGIS SQL Editor (db manager or not) needs to be
an independent window that one can keep open for as long as needed to
develop and run queries step by step, see the results, load them in the
project, re-run etc... Also, it is almost mandatory that the user, while
having the SQL script open, can check tables details, like column names,
preview their values, etc... to help write the queries. We need an
independent window or in the limit a panel to allow that together with the
browser panel.

This db manager functionality is unique, and is (in my opinion) one of the
reasons why QGIS is PostGIS de facto client.

There are other minor functionality that is still not present, but can be
added later, like being able to create and manage constraints. Or easily
create a view from a query.

I understand that for now the functionality I miss would be available as an
external plugin, but, not being in core, soon it will just stop working,
and no one will care. QGIS was born as PostGIS query and visualiser client,
in my humble opinion, by removing db manager at these stage we are
downgrading QGIS functionality.

Thanks,

Alexandre Neto





A sexta, 8/07/2022, 18:12, Paolo Cavallini via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hi all,
> are we going to implement this? Apparently nobody objects.
> I'd add to the list the Topology sub plugin by strk. Probably not widely
> used, but an unique feature.
> I confirm that in the meantime the table historicization has been
> broken, one more reason for not shipping DB Manager in the current state.
> Cheers.
>
> Il 22/06/22 07:55, Nyall Dawson ha scritto:
>
> > - Saving/re-running previously saved SQL queries
>
> very useful to me. also loading the result of a query as a new layer
>
> > - Switching to the simplified "SQL builder" dialog for creating a SQL
> query
> > - Truncating a table (this is available through a Processing
> > algorithm, just not via browser)
> > - Attribute index creation (this is available through a Processing
> > algorithm, just not via browser)
>
> handy but not crucial
>
> > - !! Support for editing an existing column (changing name/type). This
> > is the biggest functionality gap -- changing existing column types is
> > not available elsewhere in QGIS
> > - Listing database triggers
>
> I'd add storicization of a table - I couldn't find anything easier for
> this.
>
> Cheers.
> --
> Paolo Cavallini
> www.faunalia.eu - QGIS.org
> training, support, development on QGIS, PostGIS and more
> ___
> 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] gdal2xyz.bat not accepting -b any band number

[Alexandre Neto via QGIS-Developer]

Done

https://github.com/OSGeo/gdal/issues/5984

A sexta, 24/06/2022, 01:40, Even Rouault 
escreveu:

>
> Le 24/06/2022 à 02:29, Alexandre Neto via QGIS-Developer a écrit :
> > I am testing the GDAL tools on QGIS 3.22.8 on Windows. When running
> > gdal2xyz with a single band raster I am getting the following error:
> >
> > C:\Users\testing_user>gdal2xyz.bat -b 1
> > C:/Users/testing_user/Desktop/gdal_commands_test/mdt_clipped.tif
> > OUTPUT.csv
> > usage: gdal2xyz.py [-h] [-skip] [-srcwin xoff yoff xsize ysize] [-b
> > band [band ...]] [-allbands] [-csv] [-skipnodata]
> >[-srcnodata [SRC_NODATA ...]] [-dstnodata
> > [DST_NODATA ...]]
> >src_dataset dst_dataset
> > gdal2xyz.py: error: argument -b/-band/--band: invalid int value:
> > 'C:/Users/testing_user/Desktop/gdal_commands_test/mdt_clipped.tif'
> >
> > If I remove the -b option it works.
> >
> > Windows Is now on GDAL 3.5.0. On my linux machine that still uses GDAL
> > 3.0.4 it works fine.
> >
> > Bug report? In here or in GDAL?
> to GDAL. It looks like the -b option is a bit too greedy in consuming
> arguments. A workaround is to put the -b 1 option at the end of the
> command line.
> >
> > Alexandre Neto
> >
> > ___
> > 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
>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
___
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] gdal2xyz.bat not accepting -b any band number

[Alexandre Neto via QGIS-Developer]

I am testing the GDAL tools on QGIS 3.22.8 on Windows. When running
gdal2xyz with a single band raster I am getting the following error:

C:\Users\testing_user>gdal2xyz.bat -b 1
C:/Users/testing_user/Desktop/gdal_commands_test/mdt_clipped.tif OUTPUT.csv
usage: gdal2xyz.py [-h] [-skip] [-srcwin xoff yoff xsize ysize] [-b band
[band ...]] [-allbands] [-csv] [-skipnodata]
   [-srcnodata [SRC_NODATA ...]] [-dstnodata [DST_NODATA
...]]
   src_dataset dst_dataset
gdal2xyz.py: error: argument -b/-band/--band: invalid int value:
'C:/Users/testing_user/Desktop/gdal_commands_test/mdt_clipped.tif'

If I remove the -b option it works.

Windows Is now on GDAL 3.5.0. On my linux machine that still uses GDAL
3.0.4 it works fine.

Bug report? In here or in GDAL?

Alexandre Neto
___
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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Great,

Thanks Harrissou,

Alex

On Tue Apr 5, 2022, 09:53 AM GMT, DelazJ  wrote:

Hi,

Le jeu. 31 mars 2022 à 11:58, Alexandre Neto via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi Jurgen,
>
> Can I delete the 3-16 and 3-20 translation resources from transifex? they
> won't be used anymore and that way we avoid people translating it in vain.
>
> FYI, Transifex removed these resources from the Desktop project.

Regards,
Harrissou

> Alexandre Neto
>
> On Thu Mar 24, 2022, 10:13 PM GMT, Jürgen E. Fischer 
> wrote:
>
> Hi Alexandre,
>
> On Thu, 24. Mar 2022 at 18:43:24 +, Alexandre Neto wrote:
>
> I only have the PT_pt translation experience, but I am pretty sure the same
> should happen in other languages too.
>
>
> I doubt that. I wonder why the quality is so bad. I would expect that most
> of
> the translations are ok and only some are poor. Review can help with those,
> but should not be necessary to get usable translations at all.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
> Software Engineer D-26506 Norden https://www.norbit.de
> QGIS release manager (PSC) Germany IRC: jef on Libera|OFTC
> norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
> Rheinstrasse 13, 26506 Norden
> GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
> Datenschutzerklaerung: https://www.norbit.de/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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Great.

Thanks Jürgen and Harrissou.

Alexandre

On Thu Mar 31, 2022, 10:19 AM GMT, DelazJ  wrote:

Hi,
I've been chatting with Transifex guys for the docs and indeed, they made
me confirm that we want to 3.16 and 3.20 desktop resources. And as they
told you, Jürgen, they were supposed to do it and let us know.
Anyway, I asked them again last night about this. So let's give them few
days (again).

Regards,
harrissou

Le jeu. 31 mars 2022 à 12:11, Jürgen E. Fischer via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :

> Hi Alexandre,
>
> On Thu, 31. Mar 2022 at 02:58:45 -0700, Alexandre Neto wrote:
> > Can I delete the 3-16 and 3-20 translation resources from transifex? they
> > won't be used anymore and that way we avoid people translating it in
> vain.
>
> No, their webinterface will just ignore you if you try.  It has been that
> way
> for several releases.
>
> I asked transifex' support to delete shortly after the release of 3.22.5.
> They
> promised to get back to me, once they do.  But I think it takes longer than
> usual this time.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
> Software Engineer D-26506 Norden
> https://www.norbit.de
> ___
> 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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Hi Jurgen,

Can I delete the 3-16 and 3-20 translation resources from transifex? they
won't be used anymore and that way we avoid people translating it in vain.

Alexandre Neto

On Thu Mar 24, 2022, 10:13 PM GMT, Jürgen E. Fischer  wrote:

Hi Alexandre,

On Thu, 24. Mar 2022 at 18:43:24 +, Alexandre Neto wrote:

I only have the PT_pt translation experience, but I am pretty sure the same
should happen in other languages too.


I doubt that. I wonder why the quality is so bad. I would expect that most
of
the translations are ok and only some are poor. Review can help with those,
but should not be necessary to get usable translations at all.


Jürgen

-- 
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden https://www.norbit.de
QGIS release manager (PSC) Germany IRC: jef on Libera|OFTC
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Juergen Fischer, Nils Kutscher HR: Amtsgericht Aurich HRB 100827
Datenschutzerklaerung: https://www.norbit.de/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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Hi Jurgen,

I only have the PT_pt translation experience, but I am pretty sure the same
should happen in other languages too.

We do try to fix the portuguese language, but we don't seem to have enough
man power to fix and review all the strings. Even if we slowly review as
much as we can, next time the resources are updated, all the reviewed
strings get unreviewed, and we lost control again.

Having a dialog on the first launch (similar to the one had for converting
2.x configuration to 3.x would give the user a choice right way. With some
extra wording we can make very informative on how users can help improving,
and how they can select a different language later if they want.

Thanks,

Alexandre

A quinta, 24/03/2022, 16:49, Jürgen E. Fischer via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu:

> Hi Alexandre,
>
> On Thu, 24. Mar 2022 at 11:11:50 +0000, Alexandre Neto via QGIS-Developer
> wrote:
> > The European Portuguese translation is quite poor, with many errors and
> bad
> > translations.
>
> Are there more that poor translations above 35%?
>
> Otherwise I would suggest to fix the portuguese translation instead - if
> everything else fails by removing the bad ones and getting it below
> threshold.
> Or is resetting it the better choice?  That's will also get you C / en_US
> (or
> pt_BR in this case?).
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden
> https://www.norbit.de
> QGIS release manager (PSC)  Germany IRC: jef on Libera|OFTC
> ___
> 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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Hi marco,

I am aware of that. My main concern is the users that aren't even aware
that they can customize QGIS language without reinstalling it and get stuck
with a poor-quality translation.
If on top of that the translation changes too much from one version to
another, people can get very frustrated and lost and blame it on the QGIS
project. That's what I wanted to avoid.
If people understand where the translations came from, and that there is a
place where they can actually improve it, maybe they get involved...
maybe...

Alex

Marco Lechner - FOSSGIS e.V. via QGIS-Developer <
qgis-developer@lists.osgeo.org> escreveu no dia quinta, 24/03/2022 à(s)
15:37:

> Hi Alexandre,
>
> you easily could start QGIS with --lang option to force a specific
> language. E.g. $ qgis --lang en_US
> On Windows you have to add this to the qgis.bat file, as on Windows qgis
> is not startetd by executing a *.exe directly
>
> Best regards
> Marco
>
> Am 24.03.22 um 12:11 schrieb Alexandre Neto via QGIS-Developer:
> > Hi,
> >
> > I have raised this before, but I wanted to ask for it again.
> > Currently, QGIS default is not to Override System Locale and use the
> > system's locale for User interface.
> >
> > If the system locale language happens to have good and reliable
> > translations, this works well, but when the language is incomplete or
> > poorly translated, this IMHO poses a problem.
> >
> > The European Portuguese translation is quite poor, with many errors
> > and bad translations. In the end it is sometimes hard to work with the
> > GUI in PT_pt. To me the bad thing is it looks bad on the project
> > reputation and people (users) read it as a symptom of bad quality
> > software, which is not the case.
> >
> > So, I wanted to suggest if we could have American english as the
> > default for the GUI? Would this  be reasonable?
> >
> > Thanks,
> >
> > Alexandre Neto
> >
> > ___
> > 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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Hi Harrissou,

I agree that some folks will just go with the system locale anyway, but
here, many users prefer to use the GUI in English. Some are not even aware
that for changing to English from the system locale they don't need to
reinstall QGIS. So having an option on the first lauch, would be a great
improvement in my opinion.

All the best,

Alex

DelazJ  escreveu no dia quinta, 24/03/2022 à(s) 11:52:

> Hi,
> I'm sure I'm not a particular case: when I'm asked to select a language, I
> usually look after the one I'm the most comfortable with and select it. And
> in this case, I guess most of pt_PT people seeing their language in the
> list will still pick that language, ignoring there are issues with it.
>
> Mathieu there's already a value check: only languages with 35% are pulled
> into code base. The issue here is that pt_PT has issues with the quality of
> the translated strings.
>
> Regards,
> Harrissou
>
> Le jeu. 24 mars 2022 à 12:39, Mathieu Pellerin via QGIS-Developer <
> qgis-developer@lists.osgeo.org> a écrit :
>
>> Could we not have some means to attach a quality value to each language
>> (eg at the very least % translated), and only force English on poorly
>> translated languages? I feel forcing English by default would be a
>> disservice to the part of the community that spends hours to translate QGIS.
>>
>> On Thu, Mar 24, 2022, 18:32 Alexandre Neto via QGIS-Developer <
>> qgis-developer@lists.osgeo.org> wrote:
>>
>>> Hi Alessandro,
>>>
>>> Well, the option on first launch would be a much bettter solution. But
>>> probably more complicated. Any idea of how much man/hours would be needed
>>> to implement it?
>>>
>>> Thanks,
>>>
>>> Alex
>>>
>>> A quinta, 24/03/2022, 11:21, Alessandro Pasotti 
>>> escreveu:
>>>
>>>> Hi Alexandre,
>>>>
>>>> it seems reasonable to me but I'd suggest adding a first-time notice
>>>> and an option for the user to actually set the system locale, maybe only
>>>> for the first QGIS launch.
>>>>
>>>>
>>>> On Thu, Mar 24, 2022 at 12:12 PM Alexandre Neto via QGIS-Developer <
>>>> qgis-developer@lists.osgeo.org> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have raised this before, but I wanted to ask for it again.
>>>>> Currently, QGIS default is not to Override System Locale and use the
>>>>> system's locale for User interface.
>>>>>
>>>>> If the system locale language happens to have good and reliable
>>>>> translations, this works well, but when the language is incomplete or
>>>>> poorly translated, this IMHO poses a problem.
>>>>>
>>>>> The European Portuguese translation is quite poor, with many errors
>>>>> and bad translations. In the end it is sometimes hard to work with the GUI
>>>>> in PT_pt. To me the bad thing is it looks bad on the project reputation 
>>>>> and
>>>>> people (users) read it as a symptom of bad quality software, which is not
>>>>> the case.
>>>>>
>>>>> So, I wanted to suggest if we could have American english as the
>>>>> default for the GUI? Would this  be reasonable?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Alexandre Neto
>>>>> ___
>>>>> 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
>>>> QCooperative:  www.qcooperative.net
>>>> ItOpen:   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 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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Following Alessandro advice, we could have a choice menu on the first QGIS
launch, that would allow the user to select the GUI language. Maybe we
could keep the system locale as default, but inform that the translation
work may not be 100% accurate as it is done by volunteer work. We could add
a link to transifex so the user can see the translation stats and even
invite them to join the effort for better translations.

My main problem is not the translation percentage, but its quality. At
least in PT_pt, some folks just translate strings without caring about the
context of the string, which ends up in very strange and nonsense.

Thanks for your opinions

Alex

Mathieu Pellerin  escreveu no dia quinta, 24/03/2022
à(s) 11:39:

> Could we not have some means to attach a quality value to each language
> (eg at the very least % translated), and only force English on poorly
> translated languages? I feel forcing English by default would be a
> disservice to the part of the community that spends hours to translate QGIS.
>
> On Thu, Mar 24, 2022, 18:32 Alexandre Neto via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Hi Alessandro,
>>
>> Well, the option on first launch would be a much bettter solution. But
>> probably more complicated. Any idea of how much man/hours would be needed
>> to implement it?
>>
>> Thanks,
>>
>> Alex
>>
>> A quinta, 24/03/2022, 11:21, Alessandro Pasotti 
>> escreveu:
>>
>>> Hi Alexandre,
>>>
>>> it seems reasonable to me but I'd suggest adding a first-time notice and
>>> an option for the user to actually set the system locale, maybe only for
>>> the first QGIS launch.
>>>
>>>
>>> On Thu, Mar 24, 2022 at 12:12 PM Alexandre Neto via QGIS-Developer <
>>> qgis-developer@lists.osgeo.org> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have raised this before, but I wanted to ask for it again. Currently,
>>>> QGIS default is not to Override System Locale and use the system's locale
>>>> for User interface.
>>>>
>>>> If the system locale language happens to have good and reliable
>>>> translations, this works well, but when the language is incomplete or
>>>> poorly translated, this IMHO poses a problem.
>>>>
>>>> The European Portuguese translation is quite poor, with many errors and
>>>> bad translations. In the end it is sometimes hard to work with the GUI in
>>>> PT_pt. To me the bad thing is it looks bad on the project reputation and
>>>> people (users) read it as a symptom of bad quality software, which is not
>>>> the case.
>>>>
>>>> So, I wanted to suggest if we could have American english as the
>>>> default for the GUI? Would this  be reasonable?
>>>>
>>>> Thanks,
>>>>
>>>> Alexandre Neto
>>>> ___
>>>> 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
>>> QCooperative:  www.qcooperative.net
>>> ItOpen:   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 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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Hi Alessandro,

Well, the option on first launch would be a much bettter solution. But
probably more complicated. Any idea of how much man/hours would be needed
to implement it?

Thanks,

Alex

A quinta, 24/03/2022, 11:21, Alessandro Pasotti 
escreveu:

> Hi Alexandre,
>
> it seems reasonable to me but I'd suggest adding a first-time notice and
> an option for the user to actually set the system locale, maybe only for
> the first QGIS launch.
>
>
> On Thu, Mar 24, 2022 at 12:12 PM Alexandre Neto via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Hi,
>>
>> I have raised this before, but I wanted to ask for it again. Currently,
>> QGIS default is not to Override System Locale and use the system's locale
>> for User interface.
>>
>> If the system locale language happens to have good and reliable
>> translations, this works well, but when the language is incomplete or
>> poorly translated, this IMHO poses a problem.
>>
>> The European Portuguese translation is quite poor, with many errors and
>> bad translations. In the end it is sometimes hard to work with the GUI in
>> PT_pt. To me the bad thing is it looks bad on the project reputation and
>> people (users) read it as a symptom of bad quality software, which is not
>> the case.
>>
>> So, I wanted to suggest if we could have American english as the default
>> for the GUI? Would this  be reasonable?
>>
>> Thanks,
>>
>> Alexandre Neto
>> ___
>> 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
> QCooperative:  www.qcooperative.net
> ItOpen:   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] Override System Locale user interface with American English by Default?

[Alexandre Neto via QGIS-Developer]

Hi,

I have raised this before, but I wanted to ask for it again. Currently,
QGIS default is not to Override System Locale and use the system's locale
for User interface.

If the system locale language happens to have good and reliable
translations, this works well, but when the language is incomplete or
poorly translated, this IMHO poses a problem.

The European Portuguese translation is quite poor, with many errors and bad
translations. In the end it is sometimes hard to work with the GUI in
PT_pt. To me the bad thing is it looks bad on the project reputation and
people (users) read it as a symptom of bad quality software, which is not
the case.

So, I wanted to suggest if we could have American english as the default
for the GUI? Would this  be reasonable?

Thanks,

Alexandre Neto
___
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] [Qgis-user] QGIS freezes for minutes when updated SpatiaLite SQL Layer

[Alexandre Neto via QGIS-Developer]

It probably also has something to do with the query you are using.

Can you please create a ticket? Preferably with some sample data and
project and explaining the steps to reproduce the problem.

Thanks

Alexandre Neto

A terça, 22/03/2022, 09:24, SIGéal via Qgis-user 
escreveu:

> Hi list,
>
> QGIS 3.22/3.24 freezes with hourglass for about 2 minutes when I click
> on close button of Update SQL Layer dialog, even if I didn't modify the
> query.
> If I click on Execute button, I get this error : "an error occurred
> while opening GPKG dbname=..."
> This happens with a big database file (600 Mb), only with with query
> returning hundreds of rows.
>
> I don't have any problem at all with old behaviour on QGIS 3.16.16 : DB
> Manager opened when I click on Update SQL Layer.
> So this sounds clearly like a regression linked to the new "Update SQL
> Layer" dialog/behaviour.
>
> Thanks for any hint or work around,
>
> --
> Christophe Damour
>
> ___
> Qgis-user mailing list
> qgis-u...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
___
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