[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 
<https://www.shortwave.com?utm_medium=email_content=signature_source=c2VuaG9yLm5ldG9AZ21haWwuY29t>

On Thu Jan 4, 2024, 11:45 AM GMT, Nicolas Ribot 
<mailto:nicolas.ri...@gmail.com> 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 
> <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 
>> <https://www.shortwave.com?utm_medium=email_content=signature_source=c2VuaG9yLm5ldG9AZ21haWwuY29t>
>> ___
>> postgis-users mailing list
>> postgis-us...@lists.osgeo.org <mailto:postgis-us...@lists.osgeo.org>
>> https://lists.osgeo.org/mailman/listinfo/postgis-users 
>> <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 
<https://www.shortwave.com?utm_medium=email_content=signature_source=c2VuaG9yLm5ldG9AZ21haWwuY29t>___
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://www.linkedin.com/in/rosamaguilar/?locale=en_US>
>
> 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 <mailto:del...@gmail.com> 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 
> <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
>> >&

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

Re: [QGIS-Developer] Merge tool always creating a new feature id instead of preserving the existing one

[Alexandre Neto]

I would consider that a bug then, but I can't remember if I ever used merge
tool on PostGIS tables directly. I believe NaturalGIS has some processing
tools that work in PostGIS backend, but can't remember if merge is
available.

Alexandre

A terça, 1/03/2022, 09:24, Andreas Neumann  escreveu:

> Hi Alex,
>
> Thank you for your reply.
>
> In my case, the data resides in Postgis, not in Geopackage.
>
> But if I understand you correctly, then Geopackage imposes it's limit on
> QGIS in general, aka other providers as well - right?
>
> Thanks,
> Andreas
>
> On 2022-03-01 10:16, Alexandre Neto wrote:
>
> I believe that comes from the geopackage fid limitations. For that reason,
> I never use the fid field as an actual id. That's my workaround.
>
> Alexandre Neto
>
> A terça, 1/03/2022, 08:44, Andreas Neumann  escreveu:
>
> Hi,
>
> We have a problem with the merge tool.
>
> We have a relatively complex data model with lots of relations. We want to
> use the merge tool with this data.
>
> The merge tool allows to carefully choose which attributes should end up
> in the merged feature. This works fine, except for the feature ID.
>
> QGIS stubbornly insists on having to create a new feature ID after the
> merge - and is not reusing the feature ID of the original feature we
> selected as the "master" feature in the merge tool.
>
> This is a huge problem - because after the merge we loose all relations,
> because the feature ID has changed.
>
> Do you know any work around? Would we be able to fix this behaviour in a
> future QGIS release?
>
> Thanks for the discussion,
>
> Andreas
> ___
> 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] Merge tool always creating a new feature id instead of preserving the existing one

[Alexandre Neto]

I believe that comes from the geopackage fid limitations. For that reason,
I never use the fid field as an actual id. That's my workaround.

Alexandre Neto

A terça, 1/03/2022, 08:44, Andreas Neumann  escreveu:

> Hi,
>
> We have a problem with the merge tool.
>
> We have a relatively complex data model with lots of relations. We want to
> use the merge tool with this data.
>
> The merge tool allows to carefully choose which attributes should end up
> in the merged feature. This works fine, except for the feature ID.
>
> QGIS stubbornly insists on having to create a new feature ID after the
> merge - and is not reusing the feature ID of the original feature we
> selected as the "master" feature in the merge tool.
>
> This is a huge problem - because after the merge we loose all relations,
> because the feature ID has changed.
>
> Do you know any work around? Would we be able to fix this behaviour in a
> future QGIS release?
>
> Thanks for the discussion,
>
> Andreas
> ___
> 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] Pip install not working within QGIS with OSGeo4W v2?

[Alexandre Neto]

Use one of the qgis-full metapackages.

A terça, 18/01/2022, 21:06, Axel Hörteborn 
escreveu:

> Thanks for checking as well Jürgen,
>
> Interesting that it worked for you, I just tried and deleted my osgeo4w
> folder and got a fresh copy of qgis3.22.3 (during the installation I only
> installed "qgis: QGIS Desktop" and "python3-pip") and the same result could
> it be that I need to install some more stuff to get it to work?
>
> Best regards
> Axel
>
> On Tue, 18 Jan 2022 at 15:52, Jürgen E. Fischer  wrote:
>
>> Hi,
>>
>> On Tue, 18. Jan 2022 at 14:40:50 +0100, Axel Hörteborn wrote:
>> > Is there anyone else that can share some light on this issue?
>> >
>> > I've tried to make several changes to my qgis.bat and some other bat
>> files
>> > but I have no proposal how to fix it. Is this an intentional or
>> accidental
>> > change between OSGeo4w (v1) and OSGeo4w (v2)? (Shall I rewrite my
>> plugins
>> > or can I hope for a fix?)
>>
>> Works for me both in a fresh osgeo4w v2 install and QGIS 3.22.3
>> standalone (for
>> reportlab - matplotlib and psycopg2 are already included anyway).
>>
>>
>> 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 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] (no subject)

[Alexandre Neto]

Eheh I am not really a developer ^^ I just try to keep a LTR branch on
conda-forge, but most of the time real maintainers solve the problems.

But, yes. Starting on QGIS 3.20.x it's needed a more recent version of Qt5
than the one that is provided by conda-forge. There are not many hands to
work on the Qt builds and it's quite complex, therefore the work is going
quite slowly.

There's already a Qt5.15 build but now we are missing another components,
we need to be patient... As Alexander said, it's all based on volunteers
work.

Once that is solved, we should be back to regular releases not much time
after the Oficial QGIS releases.

Best regards,

Alexandre Neto

A quinta, 6/01/2022, 09:07, Benjamin Jakimow <
benjamin.jaki...@geo.hu-berlin.de> escreveu:

> Hi Eric,
> Alexandre Neto is one of the conda feedstock developers. Two days ago he
> wroted in another discussion:
>
> > QGIS on conda is not at is best shape right now, as we are stuck with
> the lack of a full featured Qt 5.15. The current package is lacking
> webengine that was split. The good news is it's already built on OSX arm64
> which may be useful in the future.
>
> Before this Qt issue, conda QGIS releases usually followed official QGIS
> releases with a small delay of  ~0-2 weeks.
>
> /Benjamin
>
> Am 05/01/2022 um 21:14 schrieb Eric Younkin - NOAA Federal:
>
> Hello,
>
> Sorry for the repeat, I've also posted this on the user list.
>
> Quick question, is there a conda release schedule?  I see that 3.18.3 is
> the latest release that is currently in Conda.  Is there some timeline laid
> out for when new releases hit Conda Forge?
>
> Thanks,
> Eric
>
> --
> Eric Younkin
> Physical Scientist
> NOAA OCS, Hydrographic Systems and Technology Branch
> 1315 East-West Highway
> N/CS11, Room 6604
> Silver Spring, MD 20910
> Office: 240-847-8208
> Cell: 828-331-8197
>
> ___
> QGIS-Developer mailing listqgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> --
> Benjamin Jakimow, Doctoral Researcher
> Earth Observation Lab | Geography Department | Humboldt-Universität zu Berlin
>
> e-mail: benjamin.jaki...@geo.hu-berlin.de
>
> phone:  +49 (0) 30 2093 6846
> mobile: +49 (0) 157 5656 8477
> fax:+49 (0) 30 2093 6848
> mail:   Unter den Linden 6 | 10099 Berlin | Germany
> room: 2'211
> web:https://hu-berlin.de/eo-lab
>
> ___
> 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] Leveraging Conda-Forge to create QGIS installers ?

[Alexandre Neto]

Alessandro,

Thank you for raising the subject.

QGIS on conda is not at is best shape right now, as we are stuck with the
lack of a full featured Qt 5.15. The current package is lacking webengine
that was split. The good news is it's already built on OSX arm64 which may
be useful in the future.

Alexandre Neto

A terça, 4/01/2022, 16:47, Alessandro Pasotti  escreveu:

> Hi,
>
> Just a quick followup on this: we briefly discussed this topic within the
> PSC and the conclusion was that this is not a PSC matter.
>
> Kind regards.
>
>
>
> On Wed, Nov 10, 2021 at 12:16 AM Nyall Dawson 
> wrote:
>
>> On Wed, 10 Nov 2021 at 00:42, Alexandre Neto 
>> wrote:
>> >
>> > No comments?l
>> >
>> > I was expecting at least a bit of discussion about this.
>>
>> Honestly, I see it as a bit of a non-starter. Conda is still stuck to
>> such an old Qt version that you can't build anything past QGIS 3.18.
>>
>> To me that's reflective of a larger issue with the ecosystem, not an
>> isolated example. These mega-packaging-everything projects just seem
>> to consistently get bogged down by the sheer number of dependent
>> packages they try to satisfy, resulting in an overall worse experience
>> all round.
>>
>> But that's just my 2c ;)
>>
>> Nyall
>>
>>
>> >
>> > :-)
>> >
>> > Alexandre Neto
>> >
>> > A sábado, 6/11/2021, 20:46, Even Rouault 
>> escreveu:
>> >>
>> >> Hi,
>> >>
>> >> Probably a topic that can raise passions and on which I'm moderately
>> >> legitimate to speak, but shouldn't we seriously consider leveraging the
>> >> Conda / Conda-Forge (https://conda-forge.org/) ecosystem for QGIS
>> >> packaging, especially on the Windows and Mac platforms ? QGIS depends
>> on
>> >> a lot of external dependencies, and building them and updating them is
>> >> really about maintaining a packaging system, and QGIS has two such
>> >> separate and bespoke systems for Windows (OSGeo4W) and Mac
>> >> (QGIS-Mac-Packager).  The ideal vision would be that the QGIS project
>> >> mostly maintains the bits specific to QGIS, but not be the sole
>> >> maintainer of its dependencies such as QT, GDAL (and its many
>> >> dependencies), PDAL, GRASS etc, as it is today. Conda-Forge provides a
>> >> truly collaborative environment and active community that already
>> >> bundles a number of those dependencies, and QGIS is already there (not
>> >> full capabilities yet, due to some dependencies missing. That would be
>> >> one of the points to address). The Conda-Forge community is really
>> >> vibrant (if you look at
>> >>
>> https://github.com/conda-forge/staged-recipes/pulls?q=is%3Apr+is%3Aclosed
>> ,
>> >> you can see that 20 packages were added in the last 24 hours!). It is
>> >> also a NumFocus sponsored project. It has support from a number of
>> >> institutions. It is unlikely to disappear anytime soon.
>> >>
>> >> There would certainly work needed to build installers from them. I
>> found
>> >> https://github.com/conda/constructor project where you can build
>> >> standalone installers from Conda packages, but was told it is perhaps
>> >> not super mature.  Even if QGIS needs require a dedicated installer
>> with
>> >> custom bits, leveraging already packaged dependencies would probably be
>> >> a big enough win compared to the current situation where the whole
>> stack
>> >> needs to be built and rebuilt from scratch by only a few knowledgeable
>> >> people, on non-shared infrastructure.
>> >>
>> >> There would be the possibility to pin dependencies at certain known
>> good
>> >> points, for example to base LTR builds on top of them.
>> >>
>> >> I guess also that Conda based installers could help for plugins that
>> >> require installing native or Python dependencies, but that'd be already
>> >> more a secondary advantage.
>> >>
>> >> Another proof that Conda is to be taken seriously:
>> >> https://developers.arcgis.com/python/guide/understanding-conda/
>> >>
>> >> I'm not saying this is a magical solution: there would clearly be a
>> >> significant amount of work and technical hurdles to solve to reach the
>> >> same degree of maturity as our current installers, but it is probably
>> an
>> >> invest

Re: [QGIS-Developer] py3_env bat file on osgeo4w install?

[Alexandre Neto]

Nyall, you are right. that is no longer needed.

Moreover, I was wrongly expecting that that py3_env.bat also set up
PYTHONPATH to include the %OSGEO_ROOT%apps/qgis/python folder, which never
was the case even in osgeo4w v1

Thanks,

Alexandre

On Wed, Dec 1, 2021 at 12:33 AM Nyall Dawson  wrote:

> On Wed, 1 Dec 2021 at 10:30, Alexandre Neto  wrote:
> >
> > Hi,
> >
> > For windows users, there used to be a bat file called py3_env.bat that
> would set up the necessary path variables so that python scripts can find
> QGIS packages.
> >
> > With the OSGeo V2 V2 installer, I can't seem to find it.
> >
> > Am I missing something?
>
>
> I believe it's no longer required, because osgeo v2 ONLY has python 3
> (no python 2).
>
> Nyall
>
> >
> >
> > 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] py3_env bat file on osgeo4w install?

[Alexandre Neto]

Hi,

For windows users, there used to be a bat file called py3_env.bat that
would set up the necessary path variables so that python scripts can find
QGIS packages.

With the OSGeo V2 V2 installer, I can't seem to find it.

Am I missing something?

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-psc] QGIS LTR releases -- is it time to pull the plug?

[Alexandre Neto]

Hello all,

On Mon, Nov 15, 2021 at 9:09 PM Andreas Neumann  wrote:

> - strictly separate the build systems and libraries of LTR and regular
> releases. Parts of the problem stem from the fact that during the lifetime
> of an LTR underlying libraries are updated. Ideally, the libraries of the
> LT releases only receive bug fixes, but no new features
> - put more resources into manual testing
> - put more resources into packaging in general
> - let every release be checked manually by a couple of dedicates power
> users (at least the LTR ones) before it goes out to the public
>
> I know - all of these need personal/financial resources.
>
> Andreas
>

Since resources are limited, another thing we may consider is to reduce the
number of releases per year.
If on top of that, we could add a packaging freeze period, it would be
possible to run installers' manual tests before they are released to the
general public.

Here are some test plans we prepared for QEP 180:

https://qgis.tenant.kiwitcms.org/plan/search/

These are only examples, we can think about more tests, especially things
that can't be caught by CI.

Best regards,

Alexandre Neto



> On Mon, 15 Nov 2021 at 20:57, Nyall Dawson  wrote:
>
>> Hi lists,
>>
>> I'd like to start some conversation about the dire condition of the
>> QGIS LTR release and what we can do to remedy/avoid this in future.
>>
>> If you've missed the conversation, our QGIS 3.16 windows releases have
>> been completely broken for nearly a month now. 3.16.12 had a critical
>> issue which caused lockups in Python code, and now 3.16.13 has
>> completely broken projection handling (resulting in loss of CRS,
>> hangups when opening projects, etc).
>>
>> So what do we do? I can think of a few responses we could make:
>>
>> - Kill 3.16.13 with fire. It needs to be removed from the website and
>> all traces of the internet ASAP. Rollback to only offering 3.16.11,
>> which is the last good Windows 3.16 release.
>>
>> - Put out a massive apology (and ask users to step up their funding to
>> better maintain QGIS releases in future ;)
>>
>> - Mark 3.16 as an early EOL. (I can't see anyone interested in
>> resolving the actual issue, so we've no way forward here in releasing
>> a "good" 3.16 release again.)
>>
>> - Write the LTR releases off as a failed concept. (i.e. if we don't
>> have the resources to maintain them properly, we shouldn't be offering
>> them at all and should resort back to the single maintained release at
>> any one time situation.)
>>
>> - Lower the supported period of a LTR release to 6 months?
>>
>> - Offer "theoretical" LTR releases ONLY as source code, but leave it
>> to users to compile themselves and accept responsibility for their own
>> packaging of this release.
>>
>> - Go on a funding drive so that QGIS can **pay** a developer and
>> packager so that we actually CAN say we have stable LTR releases
>> again?
>>
>> - ...something else...?
>>
>> Suffice to say, these are big issues, with big responses. But we're
>> also under extreme time pressure here -- 3.16 is broken beyond belief,
>> and we DO need to make some public responses asap (i.e. TODAY)
>>
>> Nyall
>> ___
>> Qgis-psc mailing list
>> qgis-...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>
>
> --
>
> --
> Andreas Neumann
> QGIS.ORG board member (treasurer)
> ___
> Qgis-psc mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
___
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] Leveraging Conda-Forge to create QGIS installers ?

[Alexandre Neto]

No comments?l

I was expecting at least a bit of discussion about this.

:-)

Alexandre Neto

A sábado, 6/11/2021, 20:46, Even Rouault 
escreveu:

> Hi,
>
> Probably a topic that can raise passions and on which I'm moderately
> legitimate to speak, but shouldn't we seriously consider leveraging the
> Conda / Conda-Forge (https://conda-forge.org/) ecosystem for QGIS
> packaging, especially on the Windows and Mac platforms ? QGIS depends on
> a lot of external dependencies, and building them and updating them is
> really about maintaining a packaging system, and QGIS has two such
> separate and bespoke systems for Windows (OSGeo4W) and Mac
> (QGIS-Mac-Packager).  The ideal vision would be that the QGIS project
> mostly maintains the bits specific to QGIS, but not be the sole
> maintainer of its dependencies such as QT, GDAL (and its many
> dependencies), PDAL, GRASS etc, as it is today. Conda-Forge provides a
> truly collaborative environment and active community that already
> bundles a number of those dependencies, and QGIS is already there (not
> full capabilities yet, due to some dependencies missing. That would be
> one of the points to address). The Conda-Forge community is really
> vibrant (if you look at
> https://github.com/conda-forge/staged-recipes/pulls?q=is%3Apr+is%3Aclosed,
>
> you can see that 20 packages were added in the last 24 hours!). It is
> also a NumFocus sponsored project. It has support from a number of
> institutions. It is unlikely to disappear anytime soon.
>
> There would certainly work needed to build installers from them. I found
> https://github.com/conda/constructor project where you can build
> standalone installers from Conda packages, but was told it is perhaps
> not super mature.  Even if QGIS needs require a dedicated installer with
> custom bits, leveraging already packaged dependencies would probably be
> a big enough win compared to the current situation where the whole stack
> needs to be built and rebuilt from scratch by only a few knowledgeable
> people, on non-shared infrastructure.
>
> There would be the possibility to pin dependencies at certain known good
> points, for example to base LTR builds on top of them.
>
> I guess also that Conda based installers could help for plugins that
> require installing native or Python dependencies, but that'd be already
> more a secondary advantage.
>
> Another proof that Conda is to be taken seriously:
> https://developers.arcgis.com/python/guide/understanding-conda/
>
> I'm not saying this is a magical solution: there would clearly be a
> significant amount of work and technical hurdles to solve to reach the
> same degree of maturity as our current installers, but it is probably an
> investment worth considering for the long term.
>
> Even
>
> --
> 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 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] URGENT AS CAN BE: QGIS 3.16.12 and sip 6?

[Alexandre Neto]

Hi Bo,

Here:

https://blog.qgis.org/2021/11/06/psa-update-to-3-16-13/

Alexandre Neto


A sábado, 6/11/2021, 10:48, Bo Victor Thomsen 
escreveu:

> When will  users and GIS/IT administrators be notified of this mishap ?
>
> There must a lot of user affected by this..
>
> Med venlig hilsen / Kind regards
>
> Bo Victor Thomsen
>
> Den 04-11-2021 kl. 01:11 skrev Nyall Dawson:
> > On Thu, 4 Nov 2021 at 08:12, Jürgen E. Fischer  wrote:
> >> Hi,
> >>
> >> Sandro's fixes from #45829[0] have been applied to the qgis-ltr (3.16)
> and qgis
> >> (3.22) packages in OSGeo4W v2 and the MSIs have been updated.
> >>
> >> qgis-ltr-dev and qgis-rel-dev will be updated in the next round of
> nightlies.
> > Thanks!
> >
> > Can we still go ahead and push a new 3.16.13 release? (Even if it's
> > identical to 3.16.12 for all non-windows platforms?) I think its
> > important so that users are notified that there's a update they NEED
> > to install for windows (and also so that we can advise all the tickets
> > which flow on for 3.16.12 users that 3.16.12 is a dud release and that
> > they need to update)
> >
> > We also then need to push out a news feed item advising that 3.16.12
> > has critical issues and that all users should update to 3.16.13.
> >
> > Nyall
> >
> >
> >>
> >> Jürgen
> >>
> >>
> >> [0] https://github.com/qgis/QGIS/pull/45829
> >>
> >> --
> >> 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 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] QGIS 3.22.0 - ISSUE REPORT

[Alexandre Neto]

Try creating a new profile.

Alexandre Neto

A quinta, 4/11/2021, 15:59, Aggeliki B.  escreveu:

> Hello,
>
> I would like to report an issue that occured after downloading the latest
> version QGIS 3.22.0. At first everything worked fine and today I cannot
> open any project that was created or opened with the latest version 3.22.0
> as it crashes instantly. I removed this version from my computer and
> continued with version 3.16.3 but still I cannot open any project that was
> created or opened by the latest version 3.22.0. Unfortunately, my whole
> work has been lost.
>
> If this is an issue that has already been reported by other users too
> and that was probably not provoked by something I did, I would kindly ask
> you to fix it.
>
> Best regards.
> Aggeliki Bokari
> ___
> 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] Boundless (docs) & Central provisioning of QGIS plugins...

[Alexandre Neto]

Hi,

Yes, I have tested also and the plugins on that folder be one magically
installed on all profiles. Didn't test on a network folder, but should work.

A segunda, 4/10/2021, 18:19, Bourdon, Jean-François (DIF) <
jean-francois.bour...@mffp.gouv.qc.ca> escreveu:

>
> It seems that if there is any duplicated plugin (same name) in the default
> profile location and in the directory specified by QGIS_PLUGINPATH, only
> the latter will be loaded. It don't think it's bad, but I think this
> behaviour should be noted.
>

I believe there's a reason for this. The QGIS_PLUGINPATH main idea is for
developer automatically load plugins under development, so if you are
developing a already installed plugin, the dev one would take precedence.

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] Boundless (docs) & Central provisioning of QGIS plugins...

[Alexandre Neto]

Regarding this subject,

I have found this on PyQGIS Cookbook:

Note

By setting QGIS_PLUGINPATH to an existing directory path, you can add this
path to the list of paths that are searched for plugins.


So, I am guessing that one could set a folder with plugins in a network
location and then setup this environment variable in each machine to have
all the plugins available on all machines.

Just guessing, I didn't have the time to test it out.


Alexandre Neto

On Wed, Sep 15, 2021 at 6:55 PM Alexandre Neto 
wrote:

> Hi Richard,
>
> Several core commiters were working at BoundlessGeo back in those days,
> some are still there, in Planet Federal.
>
> I was there too, and I was responsible for the documentation. Moving part
> of this documentation to QGIS Docs has been in my to do list for a while,
> but it never reached the top :-(
>
> Sometime ago, I asked Alessandro Pasoti if those two settings were still
> valid, and he said that "AFAIK they were valid", but I abandoned the task
> before even trying it.
>
> I still have the original rst files. In case anyone wants to jump on that
> task and try it out, I can share it.
>
> Best regards,
>
> Alexandre Neto
>
> A quarta, 15/09/2021, 16:39, Andrea Aime 
> escreveu:
>
>> On Wed, Sep 15, 2021 at 5:21 PM David Strip 
>> wrote:
>>
>>> according to Crunchbase
>>> <https://www.crunchbase.com/acquisition/planet-labs-acquires-boundlessgeo--320fb5e0>,
>>> Boundless Spatial was acquired by Planet in 2018. Planet
>>> <https://www.planet.com/>still exists - I think it used to be called
>>> Planet Labs. It operates a constellation of small earth imaging satellites.
>>> I would guess that Boundless Spatial was absorbed into the mapping team
>>> <https://www.planet.com/markets/mapping/>.  But that's in
>>> information-free guess.
>>>
>>
>> It actually became a new division, "Planet Federal":
>> https://www.planet.com/pulse/planet-to-acquire-boundless/
>>
>> Cheers
>> Andrea
>> ___
>> 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] Fail compiing WITH_3D on ubuntu 20.04 - Qt53DExtras config files missing

[Alexandre Neto]

It worked!

Thanks Denis

On Mon, Oct 4, 2021 at 1:09 PM Denis Rouzaud 
wrote:

> I believe you have to set this on 20.04
>
> -DQT5_3DEXTRA_LIBRARY=/usr/lib/x86_64-linux-gnu/libQt53DExtras.so
> -DQT5_3DEXTRA_INCLUDE_DIR=/root/QGIS/external/qt3dextra-headers
> -DCMAKE_PREFIX_PATH=/root/QGIS/external/qt3dextra-headers/cmake
> -DQt53DExtras_DIR=/root/QGIS/external/qt3dextra-headers/cmake/Qt53DExtras
>
>
> https://github.com/qgis/QGIS/blob/master/.docker/docker-qgis-build.sh#L48-L51
>
> for reference
> https://qgis-developer.osgeo.narkive.com/xMSz0lbQ/building-master-with-3d-on-debian-testing-buster
>
> Ciao,
> Denis
>
> Le lun. 4 oct. 2021 à 14:00, Alexandre Neto  a
> écrit :
>
>> Hi,
>>
>> I have been having problems compiling QGIS with 3D support on Kubuntu
>> 20.04. This is the CCMAKE configuration error:
>>
>> CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake:28
>> (find_package):
>>   Could not find a package configuration file provided by "Qt53DExtras"
>> with
>>   any of the following names:
>>
>> Qt53DExtrasConfig.cmake
>> qt53dextras-config.cmake
>>
>>   Add the installation prefix of "Qt53DExtras" to CMAKE_PREFIX_PATH or
>> set
>>   "Qt53DExtras_DIR" to a directory containing one of the above files.  If
>>   "Qt53DExtras" provides a separate development package or SDK, be sure
>> it
>>   has been installed.
>> Call Stack (most recent call first):
>>   CMakeLists.txt:455 (find_package)
>>
>> I have libQt53DExtras installed, but there are no configuration files
>> like for other QT5 libraries. I tried to follow the suggestion and add the
>> installation prefix to CMAKE_PREFIX_PATH as suggested, but either it does
>> not work, or I am doing it wrong:
>>
>> ccmake -G Ninja .. -DMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/
>>
>> Anyone is facing similar problems? any hint?
>>
>> 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] Fail compiing WITH_3D on ubuntu 20.04 - Qt53DExtras config files missing

[Alexandre Neto]

Hi,

I have been having problems compiling QGIS with 3D support on Kubuntu
20.04. This is the CCMAKE configuration error:

CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt5/Qt5Config.cmake:28
(find_package):
  Could not find a package configuration file provided by "Qt53DExtras"
with
  any of the following names:

Qt53DExtrasConfig.cmake
qt53dextras-config.cmake

  Add the installation prefix of "Qt53DExtras" to CMAKE_PREFIX_PATH or set
  "Qt53DExtras_DIR" to a directory containing one of the above files.  If
  "Qt53DExtras" provides a separate development package or SDK, be sure it
  has been installed.
Call Stack (most recent call first):
  CMakeLists.txt:455 (find_package)

I have libQt53DExtras installed, but there are no configuration files like
for other QT5 libraries. I tried to follow the suggestion and add the
installation prefix to CMAKE_PREFIX_PATH as suggested, but either it does
not work, or I am doing it wrong:

ccmake -G Ninja .. -DMAKE_PREFIX_PATH=/usr/lib/x86_64-linux-gnu/

Anyone is facing similar problems? any hint?

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] Boundless (docs) & Central provisioning of QGIS plugins...

[Alexandre Neto]

Hi Richard,

Several core commiters were working at BoundlessGeo back in those days,
some are still there, in Planet Federal.

I was there too, and I was responsible for the documentation. Moving part
of this documentation to QGIS Docs has been in my to do list for a while,
but it never reached the top :-(

Sometime ago, I asked Alessandro Pasoti if those two settings were still
valid, and he said that "AFAIK they were valid", but I abandoned the task
before even trying it.

I still have the original rst files. In case anyone wants to jump on that
task and try it out, I can share it.

Best regards,

Alexandre Neto

A quarta, 15/09/2021, 16:39, Andrea Aime 
escreveu:

> On Wed, Sep 15, 2021 at 5:21 PM David Strip 
> wrote:
>
>> according to Crunchbase
>> <https://www.crunchbase.com/acquisition/planet-labs-acquires-boundlessgeo--320fb5e0>,
>> Boundless Spatial was acquired by Planet in 2018. Planet
>> <https://www.planet.com/>still exists - I think it used to be called
>> Planet Labs. It operates a constellation of small earth imaging satellites.
>> I would guess that Boundless Spatial was absorbed into the mapping team
>> <https://www.planet.com/markets/mapping/>.  But that's in
>> information-free guess.
>>
>
> It actually became a new division, "Planet Federal":
> https://www.planet.com/pulse/planet-to-acquire-boundless/
>
> Cheers
> Andrea
> ___
> 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] Using qgis_process with a specific profile

[Alexandre Neto]

Hello Jean-François,

I am afraid not, yet. qgis_process will always use the default profile.

Best regards,

Alexandre Neto
User Support
www.Qcooperative.net

A quinta, 19/08/2021, 20:40, Bourdon, Jean-François (DIF) <
jean-francois.bour...@mffp.gouv.qc.ca> escreveu:

> [image: Intranet logo]
>
> Hi all,
>
>
>
> Is it possible to specify to *qgis_process* which profile to use in a
> similar way we can start QGIS with parameters *--profiles-path* and
> *--profile* ? Thoses commands are not recognized by qgis_process (at
> least in 3.20.0).
>
>
>
> Thanks
>
>
>
> *Jean-François Bourdon, ing.f.*
>
> *Analyste en télédétection*
> *Direction des inventaires forestiers*
> *Ministère des Forêts, de la Faune et des Parcs*
> 5700, 4e Avenue Ouest, local A-108
> Québec (Québec) G1H 6R1
> Téléphone : 418 627-8669, poste 704304
> *jean-francois.bour...@mffp.gouv.qc.ca
> *
> *mffp.gouv.qc.ca* <http://www.mffp.gouv.qc.ca/accueil.jsp>
>
>
> ___
> 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] Trigger atlas on another layer

[Alexandre Neto]

What do you mean by trigger atlas?

A quinta, 5/08/2021, 10:55, Andreas Neumann  escreveu:

> Hi,
>
> I have two layers:
>
>- layer 1 for editing
>- layer 2 with joins, aggregates, etc. as a Postgis view prepared to
>be used for an Atlas
>
> Both layers share the same primary keys.
>
> Question: could I trigger the atlas (of a selected single feature) from
> layer 2 from the form/table of layer 1?  With an action and some Python
> code? Are there Python code examples around on how I could achieve that?
>
> Reasoning: layer 2 is only a helper construct. The GIS operator is
> supposed to work with layer 1 and ideally the atlas could be triggered from
> layer 1, even though it is defined on layer 2.
>
> Thank you for any ideas,
>
> Andreas
> ___
> 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] Algorithm and Code

[Alexandre Neto]

Hell Milos,

QGIS is open source, so all the code is available, in this case om github.
You can find the code for most processing tools in this folder of the
source code:

https://github.com/qgis/QGIS/tree/master/src%2Fanalysis%2Fprocessing

Search for qgsalgorithmpoligonize and qgsalgorithmpolygonstolines.

Best regards,

Alexandre Neto
User Support
www.qcooperative.net

A quinta, 22/07/2021, 07:12, Miloš Panteliċ 
escreveu:

> Hello everyone!
>
> Maybe I am referring to wrong address, but I hope that you will be able to
> redirect me at least. I am interested in finding source code or at least
> algorithms for tools from processing toolbox, specifically *Polygonizer *and
> *PolygonstoLines* tools. Is that even possible?
> Thanks in advance.
>
> Best of luck!
> Miloš Pantelić
> ___
> 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] Using environment variables in QGIS.ini

[Alexandre Neto]

Hi Thomas,

I will check with others and let you know.

Best regards,

Alexandre Neto

A terça, 13/07/2021, 07:08, Thomas B  escreveu:

> Hi Alexandre,
>
> >>This is some old stuff we wrote at Boundless, I believe it still
> applies for QGIS today.
> >>
> https://boundless-desktop.readthedocs.io/en/latest/system_admins/index.html#for-system-administrators
> >>Both initialisation scripts and global setting file can help you
> with what you want to achieve.
>
> The initialisation scripts could be useful. But they don't seem to be
> merged into the QGIS repository yet.
>
> regards,
> Thomas
>
>
> Am Mo., 12. Juli 2021 um 10:54 Uhr schrieb Alexandre Neto <
> senhor.n...@gmail.com>:
>
>> Hi Bo,
>>
>> This is some old stuff we wrote at Boundless, I believe it still applies
>> for QGIS today.
>>
>>
>> https://boundless-desktop.readthedocs.io/en/latest/system_admins/index.html#for-system-administrators
>>
>> Both initialisation scripts and global setting file can help you with
>> what you want to achieve.
>>
>> (I should make sure this information is available on docs.qgis.org, but
>> I never find the time to do it...)
>>
>> Best regards,
>>
>> Alexandre Neto
>> User Support
>> www.qcooperative.net
>>
>> A segunda, 12/07/2021, 08:34, Bo Victor Thomsen <
>> bo.victor.thom...@gmail.com> escreveu:
>>
>>> Hi Thomas -
>>>
>>> Your suggestion is actually pretty close to the solution I made -
>>>
>>>- Standard installation of QGIS with *standard* .msi package.
>>>- After the QGIS installation and before QGIS is started the user do
>>>a one-time run a Python script from et central network drive -  using the
>>>Python interpreter installed together with QGIS  which:
>>>- Unzip a complete profile  with specific plugins and customized
>>>   parameters from a central network based repository. This profile 
>>> replaces
>>>   the standard "default" profile.
>>>   - Search/replace a couple of "tokenized" values in QGIS.ini with
>>>   actual values based on username
>>>
>>> The profile and tokenized QGIS.ini is prepared by the GIS administrator
>>>
>>> The Python script is packaged in a .cmd file which is started by the
>>> user.
>>>
>>> Not a perfect solution, but doable:
>>>
>>>- The It department is happy: No work doing specialized installations
>>>- The GIS administrator is happy. It's a one-time piece of work for
>>>each QGIS version to  prepare the profile and tokenize the QGIS.ini
>>>- The user is - somewhat - happy. To finish the installation is
>>>simply to double-click once on a file placed in a "highly visible" 
>>> location.
>>>- Any subsequent mistakes made by the user (Installation of dodgy
>>>plugins, strange changes in setups ) is easily repaired by running 
>>> the
>>>Python script again.
>>>
>>>
>>> Med venlig hilsen / Kind regards
>>>
>>> Bo Victor Thomsen
>>>
>>> Den 12-07-2021 kl. 03:14 skrev Thomas Gratier:
>>>
>>> Hi,
>>>
>>> I'm not aware QSettings provided by Qt can do it. Your %APPDATA% is not
>>> portable as would only work on Windows
>>>
>>> You can always try generate the QGIS.ini file using a templating system
>>>
>>> File QGIS.ini.j2 with following content
>>>
>>>
>>> Configuration\MODELS_FOLDER={{APPDATA}}\\QGIS\\QGIS3\\profiles\\default\\processing\\models
>>>
>>> Configuration\SCRIPTS_FOLDERS={{APPDATA}}\\QGIS\\QGIS3\\profiles\\default\\processing\\scripts
>>>
>>>
>>> File generate_ini.py with following content
>>>
>>> import os
>>> import jinja2
>>>
>>> templateLoader = jinja2.FileSystemLoader(searchpath="./")
>>> templateEnv = jinja2.Environment(loader=templateLoader)
>>> TEMPLATE_FILE = "QGIS.ini.j2"
>>> template = templateEnv.get_template(TEMPLATE_FILE)
>>> mydict = {
>>> "APPDATA": os.environ.get("APPDATA")
>>> }
>>> outputText = template.render(**mydict)
>>> with open('QGIS.ini', 'w') as outputfile:
>>> outputfile.write(outputText)
>>>
>>> Then, to write your QGIS.ini file, do
>>>
>>>
>>> python3 generate_ini.py
>>>
>>>

Re: [QGIS-Developer] Using environment variables in QGIS.ini

[Alexandre Neto]

Hi Bo,

This is some old stuff we wrote at Boundless, I believe it still applies
for QGIS today.

https://boundless-desktop.readthedocs.io/en/latest/system_admins/index.html#for-system-administrators

Both initialisation scripts and global setting file can help you with what
you want to achieve.

(I should make sure this information is available on docs.qgis.org, but I
never find the time to do it...)

Best regards,

Alexandre Neto
User Support
www.qcooperative.net

A segunda, 12/07/2021, 08:34, Bo Victor Thomsen 
escreveu:

> Hi Thomas -
>
> Your suggestion is actually pretty close to the solution I made -
>
>- Standard installation of QGIS with *standard* .msi package.
>- After the QGIS installation and before QGIS is started the user do a
>one-time run a Python script from et central network drive -  using the
>Python interpreter installed together with QGIS  which:
>- Unzip a complete profile  with specific plugins and customized
>   parameters from a central network based repository. This profile 
> replaces
>   the standard "default" profile.
>   - Search/replace a couple of "tokenized" values in QGIS.ini with
>   actual values based on username
>
> The profile and tokenized QGIS.ini is prepared by the GIS administrator
>
> The Python script is packaged in a .cmd file which is started by the user.
>
> Not a perfect solution, but doable:
>
>- The It department is happy: No work doing specialized installations
>- The GIS administrator is happy. It's a one-time piece of work for
>each QGIS version to  prepare the profile and tokenize the QGIS.ini
>- The user is - somewhat - happy. To finish the installation is simply
>to double-click once on a file placed in a "highly visible" location.
>- Any subsequent mistakes made by the user (Installation of dodgy
>plugins, strange changes in setups ) is easily repaired by running the
>Python script again.
>
>
> Med venlig hilsen / Kind regards
>
> Bo Victor Thomsen
>
> Den 12-07-2021 kl. 03:14 skrev Thomas Gratier:
>
> Hi,
>
> I'm not aware QSettings provided by Qt can do it. Your %APPDATA% is not
> portable as would only work on Windows
>
> You can always try generate the QGIS.ini file using a templating system
>
> File QGIS.ini.j2 with following content
>
>
> Configuration\MODELS_FOLDER={{APPDATA}}\\QGIS\\QGIS3\\profiles\\default\\processing\\models
>
> Configuration\SCRIPTS_FOLDERS={{APPDATA}}\\QGIS\\QGIS3\\profiles\\default\\processing\\scripts
>
>
> File generate_ini.py with following content
>
> import os
> import jinja2
>
> templateLoader = jinja2.FileSystemLoader(searchpath="./")
> templateEnv = jinja2.Environment(loader=templateLoader)
> TEMPLATE_FILE = "QGIS.ini.j2"
> template = templateEnv.get_template(TEMPLATE_FILE)
> mydict = {
> "APPDATA": os.environ.get("APPDATA")
> }
> outputText = template.render(**mydict)
> with open('QGIS.ini', 'w') as outputfile:
> outputfile.write(outputText)
>
> Then, to write your QGIS.ini file, do
>
>
> python3 generate_ini.py
>
>
> The possible deal breakers with this approach are:
> - you depend from jinja2, a third party Python library,
> - you can't later reuse the mechanism if for instance QGIS changes the
> QGIS.ini file later on
>
>
> Regards
>
> Thomas
>
>
> Le mar. 6 juil. 2021 à 09:18, Bo Victor Thomsen <
> bo.victor.thom...@gmail.com> a écrit :
>
>> To the list -
>>
>> Is there a method to use OS (Linux, Windows...) environment variables in
>> the QGIS.ini setup file ?
>>
>> I had a number of customers asking for a method to "generalize" QGIS.ini,
>> so it doesn't contain any "user" specific file and directory references, i.e
>>
>> (From qgis.ini)
>>
>> Configuration\MODELS_FOLDER=*C:\\Users\\Bo Victor
>> Thomsen\\AppData\\Roaming*
>> \\QGIS\\QGIS3\\profiles\\default\\processing\\models
>> Configuration\SCRIPTS_FOLDERS=*C:\\Users\\Bo Victor
>> Thomsen\\AppData\\Roaming*
>> \\QGIS\\QGIS3\\profiles\\default\\processing\\scripts
>>
>> could be:
>>
>> Configuration\MODELS_FOLDER=*%APPDATA%*
>> \\QGIS\\QGIS3\\profiles\\default\\processing\\models
>> Configuration\SCRIPTS_FOLDERS=*%APPDATA%*
>> \\QGIS\\QGIS3\\profiles\\default\\processing\\scripts
>>
>> or likewise.
>>
>> The ultimate reason is to have a method to distribute a "standard" setup
>> for QGIS, complete with plugins and specialized setup parameters. This can
>> be done by making a standard QGIS installation (which the IT departme

[QGIS-Developer] GDAL-warp and gdal-translate strange behaviour regarding output NODATA vaue

[Alexandre Neto]

Hi,

I was quite surprised with the behavior of gdal_translate (in clip raster
by extent) and gdal_warp (reproject) when the user sets up an output nodata
value different from the original nodata value of the input files.

My intuition was telling me that by using that option, all the old nodata
pixel values would be transferred to the new nodata values. So, if I have a
raster with nodata = -3.40282e+38 and I use as output nodata value -, I
would expect that all -3.40282e+38 pixels would be converted to - and
considered to be NODATA. But I was wrong. By doing this, I ended up with
rasters containing pixels with actual -3.40282e+38 value, no longer
considered as nodata.

Is it just me that finds this unexpected?

On the other hand, if you use the same similar option in the DGAL raster
calculator it works as (I) expected.

Best regards,

Alexandre Neto
User Support
www.cooperative.net
___
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 on @atlas_featureid

[Alexandre Neto]

As far as I remember @atlas_featureid has always returned the same as the
$id in the attributes table, which is kind of the internal row number.

Alex

A quinta, 8/07/2021, 10:35, Andreas Neumann  escreveu:

> HI Jürgen,
>
> Yes - I provided the primary key column
>
> Here is my data source string:
>
> service='edit' authcfg=sogis00 key='t_id' srid=2056 type=Polygon
> checkPrimaryKeyUnicity='1'
> table="alw_strukturverbesserungen"."projekt_aggregiert_v"
> (geometrie_convex_hull) sql=geometrie_bbox IS NOT NULL
>
> @atlas_featureid returns something like an internal "row number" or
> similar, but not the column "t_id" as defined in the data source string.
>
> Andreas
>
> On Thu, 8 Jul 2021 at 10:42, Jürgen E. Fischer  wrote:
>
>> Hi Andreas,
>>
>> On Thu, 08. Jul 2021 at 10:30:08 +0200, Andreas Neumann wrote:
>> > attribute(@atlas_feature,'pkey_name'), but it is a little more
>> complicated
>> > than @atlas_featureid - and I'm pretty sure that @atlas_featureid was
>> using
>> > the pkey column in th past?
>> >
>> > My data source for the atlas coverage layer is a Postgis View.
>>
>> It's probably not using the column you expect for the feature id.  Did you
>> specify the key column when adding the view?
>>
>>
>> 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
>>
>
>
> --
>
> --
> Andreas Neumann
> QGIS.ORG board member (treasurer)
> ___
> 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] PyQGIS Cookbook License

[Alexandre Neto]

Hi,

Although I think you can safely use and replicate any part of the
documentation, including code snippets, I think you spotted an important
issue.

I do believe we should add a licence to all our documentation. Maybe a
creative commons license.

I have included the PSC mailing list in this reply, maybe they already have
a position about this subject.

Alexandre Neto


A sexta, 2/07/2021, 18:30, Malte Ziebarth 
escreveu:

> Dear all,
>
> first off, thank you all for all the great work that went into QGIS!
>
> I am currently writing a Python plugin that I intend to make publicly
> available in the plugin repository. I started developing the plugin by
> adapting the examples from the PyQGIS Cookbook, specifically this page:
>
>
> https://docs.qgis.org/3.16/en/docs/pyqgis_developer_cookbook/plugins/plugins.html#writing-a-plugin
>
> Now the problem that I encountered with that is the license of the skeleton
> code (i.e. __init__.py and mainPlugin.py). The code does not actually
> contain
> a license header and the documentation page itself contains only the
> very general copyright information
>
> "© Copyright 2002-now, QGIS project. Last updated on Jul 02, 2021 09:02."
>
> with no further licensing information.
>
> I guess that the intention of this part of documentation is for people to
> have an easy start developing plugins which can then be contributed back
> to the community under GPL license. This is just what I am planning to
> do. However, trying to put this into a correct license header is currently
> giving me a bit of a headache.
>
> Maybe someone here in this mailing list has some advice about this issue,
> and maybe even the person/people who wrote this piece of code can clarify?
> Any help would be greatly appreciated!
>
> Kind regards
> Malte Ziebarth
>
> --
> Malte J. Ziebarth
> Section 2.6
> Tel.: +49 (0)331/288-28634
> E-Mail: zieba...@gfz-potsdam.de
> ___
>
> Helmholtz-Zentrum Potsdam
> Deutsches GeoForschungsZentrum GFZ
> Stiftung des öff. Rechts Land Brandenburg
> Telegrafenberg, 14473 Potsdam
>
> ___
> 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] Install grid ui

[Alexandre Neto]

Hi Richard,

I agree that it's not completely clear what the expected steps are, so I
agree with you text changes.

Best regards,

Alex Neto

A segunda, 14/06/2021, 20:25, Richard Duivenvoorde 
escreveu:

> Hi All,
>
> Today QGIS presented me the following nice service:
>
> https://duif.net/installgrid.png
>
> Super service, both from QGIS and opendata advocates/packagers!
>
> Did others also FIRST clicked the 'install' button before downloading the
> tiff first :-)
> If not: no problem
> If so: what about rephrasing it to:
>
> "This grid is available for download from ..."
> "Please download it yourself and save it to an arbitrary folder"
> "Then install it via this button":   [ install button ]
>
> Or is that too much text?
>
> Regards,
>
> Richard Duivenvoorde
>
> PS, I can do a PR for this, but not sure how to make the dialog show again
> :-)
> ___
> 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] SIP generated PEP 484 type hints stub files are removed on installation

[Alexandre Neto]

Hi,

On linux, after compiling QGIS, the python file has some *.pyi files
generated by SIP. They are PEP 484 type stub files, and it seems that they
are useful for code completion for python bindings (at least on visual code
studio using pylance).

Nevertheless, they don't seem to be copied in the installation step. Any
idea why? Is there a place where one can control which files are copied
over during the installation and which files are ignored?

I would like to propose to keep the pyi file as they are not that big.

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] QGIS installation using conda on downloads page

[Alexandre Neto]

Hi,

QGIS installation using conda seems to be quite stable for some time. We
provide the stable branch and the LTR that works on Windows, Linux and Mac
OS.

I have documented how to install QGIS using conda on my personal blog, but
I think it would be better to have it on QGIS Website.

This being said, is there any objections for adding the information in
https://www.qgis.org/en/site/forusers/download.html ?

Obviously, I should add something saying that this is an non-oficial way to
install QGIS and that any related bugs should be reported elsewhere.

Best regards,

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] Disable/commenting provider filter?

[Alexandre Neto]

Bad workaround then :-p

A terça, 11/05/2021, 21:10, Matthias Kuhn  escreveu:

> Unfortunately, that won't work, filters are not part of the style.
>
> On Tue, May 11, 2021 at 9:24 PM Alexandre Neto 
> wrote:
>
>> As an workaround, can't you just create a new style and remove the
>> filter? Then go back to the default style?
>>
>> Obviously a checkbox would be much more user friendly.
>>
>> Alexandre Neto
>>
>> A terça, 11/05/2021, 09:52, Andreas Neumann  escreveu:
>>
>>> Hi Richard,
>>>
>>> Yes - I think this would be very useful. I would prefer the checkbox for
>>> enabling/disabling without losing the filter string.
>>>
>>> Thanks,
>>> Andreas
>>>
>>> On Mon, 10 May 2021 at 16:41, Richard Duivenvoorde 
>>> wrote:
>>>
>>>> Hi List,
>>>>
>>>> When I add a filter to a layer, I often want to temporarily disable
>>>> that
>>>> filter (just to see what the full view is).
>>>>
>>>> Working a lot with sql scripts recently, in which you comment out (a
>>>> part) of a sql query by putting '--' in front of it, I tried that also
>>>> in the Query builder, and though it looks like I'm commenting out my
>>>> query (the query is greyed-out), it's not working, I get a parsing
>>>> error.
>>>>
>>>> So usability question:
>>>> - would other people be interested in temporarily disabling the layer
>>>> filter query, or am I the only one :-)
>>>>
>>>> If yes:
>>>>
>>>> - should it be implemented by 'commenting' out part of the query?
>>>> - or should there be some 'temporarily disable' checkbox in the query
>>>> builder)
>>>> - should it be a context menu (either the layer, or the little filter
>>>> overlay icon in the layermanager)
>>>>
>>>> Tech question:
>>>> - any forseeing issues with such thing?
>>>>
>>>> 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
>>>>
>>>
>>>
>>> --
>>>
>>> --
>>> Andreas Neumann
>>> QGIS.ORG board member (treasurer)
>>> ___
>>> 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] Disable/commenting provider filter?

[Alexandre Neto]

As an workaround, can't you just create a new style and remove the filter?
Then go back to the default style?

Obviously a checkbox would be much more user friendly.

Alexandre Neto

A terça, 11/05/2021, 09:52, Andreas Neumann  escreveu:

> Hi Richard,
>
> Yes - I think this would be very useful. I would prefer the checkbox for
> enabling/disabling without losing the filter string.
>
> Thanks,
> Andreas
>
> On Mon, 10 May 2021 at 16:41, Richard Duivenvoorde 
> wrote:
>
>> Hi List,
>>
>> When I add a filter to a layer, I often want to temporarily disable that
>> filter (just to see what the full view is).
>>
>> Working a lot with sql scripts recently, in which you comment out (a
>> part) of a sql query by putting '--' in front of it, I tried that also
>> in the Query builder, and though it looks like I'm commenting out my
>> query (the query is greyed-out), it's not working, I get a parsing
>> error.
>>
>> So usability question:
>> - would other people be interested in temporarily disabling the layer
>> filter query, or am I the only one :-)
>>
>> If yes:
>>
>> - should it be implemented by 'commenting' out part of the query?
>> - or should there be some 'temporarily disable' checkbox in the query
>> builder)
>> - should it be a context menu (either the layer, or the little filter
>> overlay icon in the layermanager)
>>
>> Tech question:
>> - any forseeing issues with such thing?
>>
>> 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
>>
>
>
> --
>
> --
> Andreas Neumann
> QGIS.ORG board member (treasurer)
> ___
> 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] QGIS Docs: ReStructureText flavour?

[Alexandre Neto]

Hi,

As far as I remember, sphinx is based/expands "normal" RST introducing new
directives, so it should be normal that some seems to be missing when you
try to parse them using a rst parser.

Alexandre Neto

A quarta, 31/03/2021, 14:11, DelazJ  escreveu:

> Hi Jonathan,
>
> I can't answer whether there's any particular RST flavour behind. What I
> know is that we rely on Sphinx [0] and most of the rules/syntaxes we use
> are picked from them. The docs guidelines [1] also provide some explanation
> on the choice made.
> So, in the Sphinx docs, you can find :ref: [2] and .. only:: [3]
>
> [0] https://www.sphinx-doc.org/en/master/
> [1] https://docs.qgis.org/3.16/en/docs/documentation_guidelines/index.html
> [2]
> https://www.sphinx-doc.org/en/master/usage/restructuredtext/roles.html#cross-referencing-arbitrary-locations
> [3]
> https://www.sphinx-doc.org/en/master/usage/restructuredtext/directives.html#directive-only
>
> Hope that clarifies,
> Harrissou
>
> Le mer. 31 mars 2021 à 14:21, Jonathan Moules <
> jonathan-li...@lightpear.com> a écrit :
>
>> Hi List,
>>
>> What flavour is the RST behind the QGIS docs? There are quite a few
>> things in here that are syntax erroring all the parsers I'm trying and
>> aren't in the basic RST spec either
>> (https://docutils.sourceforge.io/docs/user/rst/cheatsheet.txt).
>>
>> For example using ":ref:" for internal hyperlinks when the spec says
>> they should be done like this:
>>
>> https://docutils.sourceforge.io/docs/user/rst/quickref.html#internal-hyperlink-targets
>> (there is no "ref" in the specs). Or the `.. only:: html` that starts
>> some files.
>>
>> I tried looking at the QGIS Docs page but I couldn't see anything about
>> what RST standard the docs should be written to. Where can I find the
>> spec?
>>
>> Cheers,
>>
>> Jonathan
>>
>> ___
>> 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] WITH_PDAL and WITH_EPT doubt

[Alexandre Neto]

Sorry for the basic questions, I was about to say. I am lagging a bit on
all this point cloud business, but I wanted to make it available on
conda-forge.

Thanks,

Alexandre Neto


A sábado, 6/03/2021, 09:53, Alexandre Neto  escreveu:

> Hi Sylvain,
>
> Thank you for you answer. Yes, the build in conda is building untwine for
> sure. I know because the windows build is failing there. So that's a result
> of with_ept=true?
>
>  entwine or untwine serve the same purpose? Is there a prefered one?
>
> If I build using WITH_EPT = true, does it make sense to install entwine
> (from packaging system) anyway? Or, in that case, I should use WITH_EPT =
> FALSE?
>
> Sorry for
>
> A sábado, 6/03/2021, 09:28, Sylvain POULAIN 
> escreveu:
>
>> Hi Alexandre,
>>
>> When you build qgis with cmake, it will build untwine (not entwine) in
>> qgis structure.
>> I guess it could be the same with conda but not tested.
>>
>> Regards,
>>
>> *Sylvain*
>>
>>
>> Le mer. 3 mars 2021 à 12:46, Alexandre Neto  a
>> écrit :
>>
>>> Hello again,
>>>
>>> Does this mean that, if entwine isn't present in the system, the
>>> compilation won't fail or complaint, but some functionality will be missing?
>>>
>>> Should I include entwine as a dependency for 3.18.0 on conda-forge?
>>>
>>> Thanks,
>>> Alexandre
>>>
>>> A quarta, 3/03/2021, 03:40, Alexandre Neto 
>>> escreveu:
>>>
>>>> Great, thanks!
>>>>
>>>> A quarta, 3/03/2021, 02:03, Nyall Dawson 
>>>> escreveu:
>>>>
>>>>> On Wed, 3 Mar 2021 at 11:59, Alexandre Neto 
>>>>> wrote:
>>>>> >
>>>>> > Hi,
>>>>> >
>>>>> > I am trying to add point cloud support to QGIS on conda-forge [0],
>>>>> but I am unsure if I need to use
>>>>> > WITH_PDAL=TRUE
>>>>>
>>>>> yes, you'll need to add this even if you have pdal library available.
>>>>> it defaults to false to avoid breaking the compilation if pdal isn't
>>>>> available (and we want explicit breaks here rather than silently
>>>>> compiling without pdal provider if the library isn't found).
>>>>>
>>>>> > and WITH_EPT=TRUE
>>>>>
>>>>> That defaults to true anyway, so you can omit it if you want.
>>>>>
>>>>> Nyall
>>>>>
>>>> ___
>>> QGIS-Developer mailing list
>>> QGIS-Developer@lists.osgeo.org
>>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>>
>>
___
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] WITH_PDAL and WITH_EPT doubt

[Alexandre Neto]

Hello again,

Does this mean that, if entwine isn't present in the system, the
compilation won't fail or complaint, but some functionality will be missing?

Should I include entwine as a dependency for 3.18.0 on conda-forge?

Thanks,
Alexandre

A quarta, 3/03/2021, 03:40, Alexandre Neto  escreveu:

> Great, thanks!
>
> A quarta, 3/03/2021, 02:03, Nyall Dawson 
> escreveu:
>
>> On Wed, 3 Mar 2021 at 11:59, Alexandre Neto 
>> wrote:
>> >
>> > Hi,
>> >
>> > I am trying to add point cloud support to QGIS on conda-forge [0], but
>> I am unsure if I need to use
>> > WITH_PDAL=TRUE
>>
>> yes, you'll need to add this even if you have pdal library available.
>> it defaults to false to avoid breaking the compilation if pdal isn't
>> available (and we want explicit breaks here rather than silently
>> compiling without pdal provider if the library isn't found).
>>
>> > and WITH_EPT=TRUE
>>
>> That defaults to true anyway, so you can omit it if you want.
>>
>> Nyall
>>
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] WITH_PDAL and WITH_EPT doubt

[Alexandre Neto]

Great, thanks!

A quarta, 3/03/2021, 02:03, Nyall Dawson  escreveu:

> On Wed, 3 Mar 2021 at 11:59, Alexandre Neto  wrote:
> >
> > Hi,
> >
> > I am trying to add point cloud support to QGIS on conda-forge [0], but I
> am unsure if I need to use
> > WITH_PDAL=TRUE
>
> yes, you'll need to add this even if you have pdal library available.
> it defaults to false to avoid breaking the compilation if pdal isn't
> available (and we want explicit breaks here rather than silently
> compiling without pdal provider if the library isn't found).
>
> > and WITH_EPT=TRUE
>
> That defaults to true anyway, so you can omit it if you want.
>
> Nyall
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] WITH_PDAL and WITH_EPT doubt

[Alexandre Neto]

Hi,

I am trying to add point cloud support to QGIS on conda-forge [0]
<https://github.com/conda-forge/qgis-feedstock/pull/174>, but I am unsure
if I need to use
WITH_PDAL=TRUE and WITH_EPT=TRUE or just make sure PDAL is available from
the packaging repositories.

Will anything be missing if I skip these two during the compilation?

Thanks,

Alexandre Neto

[0] - https://github.com/conda-forge/qgis-feedstock/pull/174
___
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] Voronoi tool missing from processing, what could be wrong?

[Alexandre Neto]

Might seem obvious, but have you tried using a brand new profile?

A terça, 2/03/2021, 08:34, Hernán De Angelis 
escreveu:

> Hi,
>
> I wrote about this a few days ago in the user list but I still have the
> problem and can find neither a cause nor a solution. I thus post it in
> this list in the hope that some developer may have a hint on what is
> going wrong here.
>
> In my installation the Voronoi Polygon tool is missing from the
> Processing menu, both from the bar (vector geometry dialog) and the
> processing panel. It is also not listed in the Python console (see below
> whole listing).
>
> But, the code seems to be present in the /usr/local/share... folder,
> where other plugins live as well:
>
> localhost:/usr/local # find ./share -name *oronoi*
>
> ./share/qgis/python/plugins/processing/algs/grass7/description/v.voronoi.skeleton.txt
>
> ./share/qgis/python/plugins/processing/algs/grass7/description/v.voronoi.txt
> ./share/qgis/python/plugins/processing/algs/grass7/ext/v_voronoi.py
> ./share/qgis/python/plugins/processing/algs/qgis/VoronoiPolygons.py
> ./share/qgis/python/plugins/processing/algs/qgis/voronoi.py
>
> I compile QGIS from source, things have gone smoothly every time and I
> cannot see any obvious particular problem. I have tested with master a
> couple of weeks ago, then 3.18.0 a couple of days ago, and moments ago
> with 3.16.4 (after wiping all traces of previous installations) but the
> problem persists.
>
> Anyone has seen this? What could possibly be wrong here?
>
> Thanks in advance,
>
> Hernán
>
>
> - - - - -
>
> from qgis import processing
> for alg in QgsApplication.processingRegistry().algorithms():
>  print(alg.id(), "->", alg.displayName())
>
> native:addautoincrementalfield -> Add autoincremental field
> native:addfieldtoattributestable -> Add field to attributes table
> native:adduniquevalueindexfield -> Add unique value index field
> native:addxyfields -> Add X/Y fields to layer
> native:affinetransform -> Affine transform
> native:aggregate -> Aggregate
> native:angletonearest -> Align points to features
> native:antimeridiansplit -> Geodesic line split at antimeridian
> native:arrayoffsetlines -> Array of offset (parallel) lines
> native:arraytranslatedfeatures -> Array of translated features
> native:aspect -> Aspect
> native:assignprojection -> Assign projection
> native:atlaslayouttoimage -> Export atlas layout as image
> native:atlaslayouttopdf -> Export atlas layout as PDF
> native:bookmarkstolayer -> Convert spatial bookmarks to layer
> native:boundary -> Boundary
> native:boundingboxes -> Bounding boxes
> native:buffer -> Buffer
> native:bufferbym -> Variable width buffer (by M value)
> native:calculatevectoroverlaps -> Overlap analysis
> native:categorizeusingstyle -> Create categorized renderer from styles
> native:cellstatistics -> Cell statistics
> native:centroids -> Centroids
> native:clip -> Clip
> native:collect -> Collect geometries
> native:combinestyles -> Combine style databases
> native:condition -> Conditional branch
> native:converttocurves -> Convert to curved geometries
> native:convexhull -> Convex hull
> native:countpointsinpolygon -> Count points in polygon
> native:createattributeindex -> Create attribute index
> native:createconstantrasterlayer -> Create constant raster layer
> native:createdirectory -> Create directory
> native:creategrid -> Create grid
> native:createpointslayerfromtable -> Create points layer from table
> native:createrandombinomialrasterlayer -> Create random raster layer
> (binomial distribution)
> native:createrandomexponentialrasterlayer -> Create random raster layer
> (exponential distribution)
> native:createrandomgammarasterlayer -> Create random raster layer (gamma
> distribution)
> native:createrandomgeometricrasterlayer -> Create random raster layer
> (geometric distribution)
> native:createrandomnegativebinomialrasterlayer -> Create random raster
> layer (negative binomial distribution)
> native:createrandomnormalrasterlayer -> Create random raster layer
> (normal distribution)
> native:createrandompoissonrasterlayer -> Create random raster layer
> (poisson distribution)
> native:createrandomuniformrasterlayer -> Create random raster layer
> (uniform distribution)
> native:createspatialindex -> Create spatial index
> native:dbscanclustering -> DBSCAN clustering
> native:deleteduplicategeometries -> Delete duplicate geometries
> native:deleteholes -> Delete holes
> native:densifygeometries -> Densify by count
> native:densifygeometriesgivenaninterval -> Densify by interval
> native:detectvectorchanges -> Detect dataset changes
> native:difference -> Difference
> native:dissolve -> Dissolve
> native:dropgeometries -> Drop geometries
> native:dropmzvalues -> Drop M/Z values
> native:equaltofrequency -> Equal to frequency
> native:explodehstorefield -> Explode HStore Field
> native:explodelines -> Explode lines
> native:extendlines -> Extend lines
> native:extenttolayer -> Create layer from extent
> 

Re: [QGIS-Developer] [Qgis-user] A nice task for a community member: revamping the QGIS github landing page

[Alexandre Neto]

There should be already some description on the QGIS Server documentation:

https://docs.qgis.org/3.16/en/docs/server_manual/introduction.html

Alexandre Neto



A terça, 16/02/2021, 09:11, Jorge Gustavo Rocha  escreveu:

> Hi,
>
> Thanks for stepping up, Martin.
>
> I would like to add a single suggestion: to make a clear distinction
> between QGIS and QGIS Server. If necessary, I can help/review QGIS
> Server description.
>
> Regards,
>
> Jorge Gustavo
>
>
> Às 01:15 de 16/02/21, Martin Pergler escreveu:
> > Happy to take this on (next week, this week is a bit crazy).
> > I like all 3 examples given: key thing being leading off much more with
> an
> > easy-to-understand, illustrated list of main functionality and use cases.
> >
> > By way of introduction, 30 years ago I was a software developer, back
> when
> > Pascal and C (++ was cutting edge!) were mainstream and Prolog was sexy
> (at
> > least for geeks, that is). I then became a mathematician for a while,
> before
> > going into business consulting. I've done a fair amount of technical
> writing
> > and ran an editorial board for a while. My day job is now risk
> consulting,
> > including probabilistic modeling, Excel/VBA, and R. On the side I help
> > manage and preserve a decent chunk of Canadian wilderness, through which
> in
> > the past couple of years I've become more and more involved in GIS.
> First,
> > just making a map of the darned thing, but more recently vegetation and
> > land-use analysis, indexing of research notes and wildlife photos,
> > automation so others can use it, and even more recently UAV 2.5D mapping.
> > I'm also a frequent contributor (Q and A) at gis.stackexchange.com
> >
> > Happy also to work on this 4 (or more) hands if anyone else wants to help
> > out. Otherwise, I'll sit back this week and accept with gratitude any
> > additional suggestions of what to cover or how. I'll then come back with
> a
> > 1st (but doubtlessly incomplete) draft next week.
> >
> > Martin Pergler
> >
> >
> >
> >
> > --
> > Sent from:
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> > ___
> > 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
> >
>
> J. Gustavo
> --
> Jorge Gustavo Rocha
> Departamento de Informática
> Universidade do Minho
> 4710-057 Braga
> Gabinete 3.29 (Piso 3)
> Tel: +351 253604480
> Fax: +351 253604471
> Móvel: +351 910333888
> skype: nabocudnosor
> ___
> 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] [ui] blue != blue

[Alexandre Neto]

Richard, can you create an issue and assign it to me? I will give it a look.

Thanks,

Alex

A quarta, 3/02/2021, 15:00, Charles Dixon-Paver 
escreveu:

> From what I can see, the SAP HANA icon is "close enough" in colour scheme
> to the existing ones, as I checked the colours for the hana icon against
> the postgres one in inkscape and got these results:
>
> Postgis
> Fill: #6e97c4ff
> Stroke: #476280ff
>
> Hana:
> Fill: #6e97c4ff
> Stroke: #425a75ff
>
> The design isn't too off-putting, but I feel like there are issues with it:
>
> 1) The "bits" around the central chip are not visible against a dark
> background, so it's not a "good" design.
> 2) The generic computer component doesn't seem ideal. It's differentiated
> enough from existing providers to be useful, but it's generic enough that
> it should be used for some other button or component, not tied to a
> "branded" database.
>
> I would personally like to see it using the "SAP" logo, to make a "DB2"
> looking replacement, but it might not be ok with their corporate branding
> terms. I can't think of a great replacement off the top of my head though.
>
> The point cloud one I feel is pretty jarring and way off. I've attached an
> svg of what I think it should look like.
>
> On Wed, 3 Feb 2021 at 16:02, Richard Duivenvoorde 
> wrote:
>
>> On 2/3/21 2:54 PM, Richard Duivenvoorde wrote:
>> > Hi,
>> >
>> > Am I the only one, getting blind (not really, just finding it not so
>> nice) of the different use of blue for Point Cloud in the Datasource button
>> bars (like in the Data Source Manager).
>>
>> I do not have a really good feeling for colors, but recently also the
>> Hana icons were added:
>>
>>
>> https://github.com/qgis/QGIS/blob/master/images/themes/default/mActionAddHanaLayer.svg
>>
>> https://github.com/qgis/QGIS/blob/master/images/themes/default/mIconHana.svg
>>
>> does that 'fit' in the 'color scheme'? (asking to peeps with
>> designer/cartography backgrounds)
>>
>> (not sure who did the earlier cleanup of our icon theme)
>>
>> Richard
>> ___
>> 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] Bug fix campaign and QA regression tests

[Alexandre Neto]

Hi,

With the work from QEP-180[0][1] funded by a QGIS Grant, we have the
quality assurance infrastructure in place and we are now ready to test the
methodology.

One of the workflows [2] aims to help to test the implemented fixes.

This being said, If any developer working on bug squashing feels that a
particular fix would benefit from some extra testing on several platforms,
let's talk and prepare it.

We are setting things up to test Windows 10, Ubuntu 20.04, Mac OS Big Sur
as prioritary platforms, and ubuntu 18.04 and Mac OS Catalina as
secondary platforms.

Best Regards,

Alexandre Neto

[0] - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/180
[1] - https://github.com/qcooperative/qgis-testing/blob/main/README.md
[2] -
https://github.com/qcooperative/qgis-testing/blob/main/README.md#regression-tests
___
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] Nightly LTR for 3.16.4 Release Candidate

[Alexandre Neto]

Hi,

Carrying on the work of QEP-180[1], we are now "metatesting" the testing
infraestructure and metodology[2] by running the set of designated test
cases  (manual tests) for the next releases 3.18.0 and 3.16.4LTR.

For the later, we would need to have the nigthly-ltr builds pointing to the
release 3.16 branch.

Question: Normally, when does the switch from the old LTR moves to the next
one happens? I was hoping that it would happen before the release itself.

[1] - https://github.com/qgis/QGIS-Enhancement-Proposals/issues/180

[2] - https://github.com/qcooperative/qgis-testing

Best regards,

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] Stale bot and older requests/issues - possible enhancement

[Alexandre Neto]

On Thu, Jan 7, 2021 at 11:44 PM Nyall Dawson  wrote:

>
>
> What I'm trying to convey here is that there's a chance the ticket
> will be addressed without sponsorship, but if they DO sponsor it will
> get addressed immediately. So "fast track" here means something a
> little like "short cut".  Is there better wording you think may convey
> this same meaning?
>
> Nyall
>
>
>
Maybe "Speed up" or "accelerate"

But maybe it's just my limited vocabulary.

Alexandre


> >
> > Other than that +1
> >
> > Alexandre Neto
> >
> > A quinta, 7/01/2021, 08:33, Matthias Kuhn 
> escreveu:
> >>
> >> Hi Nyall,
> >>
> >> I would also appreciate a hint like this.
> >> Maybe it could be done even more subtle by shortening this text and
> adding a link to a page "learn how to make things progress"?
> >>
> >> I'd also very much appreciate the voices of users on this topic (that's
> a classical "we don't only want to hear the dev side" topic).
> >>
> >> Matthias
> >>
> >> On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
> wrote:
> >>>
> >>> Hi list,
> >>>
> >>> I've a small request to consider for stale bot and issues/feature
> >>> requests. I think that if a ticket remains open for say > 90 days
> >>> since the last comment, it would be nice if stale bot added a comment
> >>> like:
> >>>
> >>> "Unfortunately this bug/feature request has not seen any solution in
> >>> the recent QGIS release. If this fix/feature is important to you or
> >>> your organisation, you can help to fast-track its development by
> >>> sponsoring this work. To do so, contact one of the QGIS commercial
> >>> support providers listed at ... to discuss how you could fund this
> >>> functionality".
> >>>
> >>> I think it's a non-threatening, non-begging way to advise bug
> >>> reporters on the alternative ways they can fast track development in
> >>> QGIS.
> >>>
> >>> Thoughts?
> >>>
> >>> Nyall
> >>> ___
> >>> QGIS-Developer mailing list
> >>> QGIS-Developer@lists.osgeo.org
> >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >>
> >> ___
> >> 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] Stale bot and older requests/issues - possible enhancement

[Alexandre Neto]

As an user and member of a user group, the message does not offend at all.
This is something we struggle to explain to users and it's a good
opportunity to send the message.

 I prefer a long version instead of just a link (many won't click on it)

I am not a native english speaker, but I think using something like
"consider sponsoring" instead of "you can sponsor".

Also the term "fast track" for me is not very clear for me, again as
non-native english speaker.

Other than that +1

Alexandre Neto

A quinta, 7/01/2021, 08:33, Matthias Kuhn  escreveu:

> Hi Nyall,
>
> I would also appreciate a hint like this.
> Maybe it could be done even more subtle by shortening this text and adding
> a link to a page "learn how to make things progress"?
>
> I'd also very much appreciate the voices of users on this topic (that's a
> classical "we don't only want to hear the dev side" topic).
>
> Matthias
>
> On Thu, Jan 7, 2021 at 1:42 AM Nyall Dawson 
> wrote:
>
>> Hi list,
>>
>> I've a small request to consider for stale bot and issues/feature
>> requests. I think that if a ticket remains open for say > 90 days
>> since the last comment, it would be nice if stale bot added a comment
>> like:
>>
>> "Unfortunately this bug/feature request has not seen any solution in
>> the recent QGIS release. If this fix/feature is important to you or
>> your organisation, you can help to fast-track its development by
>> sponsoring this work. To do so, contact one of the QGIS commercial
>> support providers listed at ... to discuss how you could fund this
>> functionality".
>>
>> I think it's a non-threatening, non-begging way to advise bug
>> reporters on the alternative ways they can fast track development in
>> QGIS.
>>
>> Thoughts?
>>
>> Nyall
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> ___
> 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] [Qgis-psc] call for nominations for new QGIS community voting members

[Alexandre Neto]

Hi again,

Is there a updated place where we can see who got elected in 2019 and 2020?

Thanks,

Alexandre Neto



A sexta, 18/12/2020, 17:36, Alexandre Neto  escreveu:

> Hello Marco,
>
> Can you please clarify if after the nomination period there will be a
> voting period, or it's a one step process (nomination/voting)
>
> Thanks,
>
> Alexandre Neto
>
> A quarta, 16/12/2020, 20:56, Marco Bernasocchi  escreveu:
>
>> Dear QGIS Community
>>
>> This is a call for nominations for new QGIS community voting members.
>> Please read the instructions carefully and establish your eligibility to
>> vote which I repeat here for your convenience:
>>
>> "Only community members with commit rights to an official QGIS git
>> repository or with write access in transifex are eligible to make
>> nominations.”
>>
>> The nomination form is here.
>>
>> https://forms.gle/RycZ6aycRppa8qYD9
>>
>>
>> Incoming community voting members will be selected based on the number of
>> nominations they receive. The above form will close on 31 December 2020.
>>
>> If you play an organisational role (e.g. documentation lead, translation
>> lead), please forward this email to your committers.
>>
>> A larger version of the diagram included in the form is also available
>> here:
>>
>>
>> https://drive.google.com/file/d/12qPHUjvPv5CMpZKSWHwr65DG-YOZsub1/view?usp=sharing
>>
>>
>> If you have any questions about the process please do not hesitate to
>> contact me.
>>
>> Thank you,
>>
>> Regards Marco
>>
>>
>> --
>> Marco Bernasocchi
>>
>> QGIS.org Chair
>> OPENGIS.ch CEO
>> http://berna.io
>> ___
>> Qgis-psc mailing list
>> qgis-...@lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>
>
___
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] call for nominations for new QGIS community voting members

[Alexandre Neto]

Hello Marco,

Can you please clarify if after the nomination period there will be a
voting period, or it's a one step process (nomination/voting)

Thanks,

Alexandre Neto

A quarta, 16/12/2020, 20:56, Marco Bernasocchi  escreveu:

> Dear QGIS Community
>
> This is a call for nominations for new QGIS community voting members.
> Please read the instructions carefully and establish your eligibility to
> vote which I repeat here for your convenience:
>
> "Only community members with commit rights to an official QGIS git
> repository or with write access in transifex are eligible to make
> nominations.”
>
> The nomination form is here.
>
> https://forms.gle/RycZ6aycRppa8qYD9
>
>
> Incoming community voting members will be selected based on the number of
> nominations they receive. The above form will close on 31 December 2020.
>
> If you play an organisational role (e.g. documentation lead, translation
> lead), please forward this email to your committers.
>
> A larger version of the diagram included in the form is also available
> here:
>
>
> https://drive.google.com/file/d/12qPHUjvPv5CMpZKSWHwr65DG-YOZsub1/view?usp=sharing
>
>
> If you have any questions about the process please do not hesitate to
> contact me.
>
> Thank you,
>
> Regards Marco
>
>
> --
> Marco Bernasocchi
>
> QGIS.org Chair
> OPENGIS.ch CEO
> http://berna.io
> ___
> Qgis-psc mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
___
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] In Identify Results: hiding (Derived) and (Actions) in treeview?

[Alexandre Neto]

I find "derived" quite useful. You can immediately see things like area and
perimeter of the feature, even if there's no field with that information.

Yet, a option to disable it is ok for me.

Best regards,

Alexandre Neto

A quarta, 14/10/2020, 14:42, Richard Duivenvoorde 
escreveu:

> Hi,
>
> Whenever I click on a (vector) feature from a table with say 6 columns,
> QGIS presents me a treview in the 'Identify Results' panel which shows me
> (for every feature) these blocks 'Derived' and 'Actions'.
>
> When I click in a 'crowded place' in which a lot of features are returned,
> I can open all leaves in the tree(view) but then my sight is pretty
> polluted by all this (to me very not interesting) facts about where I
> clicked and to see that I have one (View feature form) Action (I never use).
>
> Are others 'seeing' this also as an usability issue?
> Or am I missing a setting somewhere?
>
> Would it be an idea (feature request) to maybe add an option (like the
> checkbox in the little tool-button menu there), with an option "Hide
> Derived and Actions"?
>
> Or am I the only one which does never used this xtra info?
>
> 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] Offline Editing plugin

[Alexandre Neto]

Maybe you can have a better idea about that, if you ask in the users
mailing list.

Alex

A quarta, 7/10/2020, 14:57, matteo  escreveu:

> Hi Tim,
>
> thanks for the feedback.
>
> > Yes I have experienced similar issues - often getting corrupted projects
> > when I try to round trip data. IMHO we should remove that plugin and
> > point people to QFieldSync or Mergin as better options for syncing to a
> > device.
>
> I'm also +1 to remove the plugin. I'm also curious: how many people are
> actually using the OfflineEditing plugin?
>
> Cheers and thanks
>
> Matteo
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Is the spellcheck too greedy?

[Alexandre Neto]

Hi Alessandro,

FYI, there's some json files that provide expressions functions help.
Therefore, if a white list is created, those should not be included.

Cheers,
Alexandre Neto

A segunda, 28/09/2020, 16:48, Alessandro Pasotti 
escreveu:

> On Mon, Sep 28, 2020 at 5:41 PM Jürgen E. Fischer  wrote:
> >
> > Hi Alessandro,
> >
> > On Mon, 28. Sep 2020 at 17:10:56 +0200, Alessandro Pasotti wrote:
> > > I think that we should skip the spell check on a  a list of file
> > > formats under the testdata directory:
> > >
> > > - xml
> > > - sql
> > > - json
> > > - html
> > >
> > > note that these are all under "tests/testdata" and they are not actual
> > > released or source code this means that there will be no consequences
> > > on the quality of our releases.
> >
> > Remember ef1497faaa0dac55b1511c9aa06738c02b24884c ? ;)
>
>
> No, I've been bitten so many times by the spell check (and most of
> them for a reason) that I can't remember :)
>
> Anyway that commit does not exclude all SQL files, it actually
> excludes all files under the postgres raster testdata folder (which
> are all sql files btw).
>
>
>
> >
> >
> >
> > 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)  GermanyIRC: jef on
> FreeNode
>
>
>
> --
> 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] SQL in graphic modeller - Reg

[Alexandre Neto]

Hello,

Have you tried to use the PostgreSQL execute and load algorithm from the
Processing toolbox?

https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/database.html#postgresql-execute-and-load-sql

Another alternative is to use the Refactor fields tool, where you can
select the columns you want to keep and in which order.

https://docs.qgis.org/testing/en/docs/user_manual/processing_algs/qgis/vectortable.html#refactor-fields

Best regards,

Alexandre Neto
QGIS Support
www.qcooperative.net

A sexta, 14/08/2020, 12:23, Karthikeyan M  escreveu:

> Hi ,
>
> I'm learning graphic modeller in QGis3. Earlier I used to select only 3
> columns ( from 73 coloumn) of attributes by using sql query in DB manager.
> I want to create a  model for that. Is there anyway I can use that sql
> query to extract particular coloumn from shape files using Graphic modeller
> ?
>
> Expecting your reply
>
> Regards,
> Karthikeyan M
>
>
> ___
> 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] using conda for development

[Alexandre Neto]

Hello Ari,

A segunda, 3/08/2020, 06:51, Ari Meyer  escreveu:

>
> I guess from Matthias' comments, though, your multi-platform build
> requirements are beyond the scope of what conda can deliver?
> Ari
>
>>
I think that what Mathias said is that what we have now, without depending
on others, just works. Moving to anything else, conda or not, would involve
a huge amount of work. Besides, there will always be cross platform
dependencies divergences anyway, whatever the system is used.

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] using conda for development

[Alexandre Neto]

Hi,

Following the discussion on QGIS dependencies on conda-forge, I had a chat
with one of conda-forge most active maintainers.

It seems that the conda-forge community is aware of the dangers of building
only bleeding edge versions of the packages. There's a CFEP (same as our
QEP) to improve the situation.

https://hackmd.io/N1hoJGJBSqGTFd83pxCyYA

Nevertheless, regarding the QGIS packages, and because they are not
dependencies of any other packages, I was told that it would be ok to
create local pinning configuration files for both our stable and LTR
branches. This means we could have the control of the most important
dependencies. I will try to mimic osgeo4w for 3.16 onwards, and make sure
the pinning is not changed during the LTR life cycle.

This does not fix the issue with no one maintaining the QtWebKit package,
but I don't think no one really worked actively on it.

My intentions are not to replace our packaging system (poor me), that, like
Mathias said, works fine for now. I will just try to keep QGIS available on
conda, as it seems useful for some folks, and it doesn't really take me too
much time.

Thanks,

Alexandre Neto

A domingo, 2/08/2020, 10:04, Matthias Kuhn  escreveu:

> Hi Ari, all
>
> I can follow your reasoning. Various discussions have taken place about
> this already.
>
> Currently it's also a question of feasibility. Windows and macOS have
> completely different dependency build chains / repositories. Synchronizing
> those within their current completely separate frameworks will be hard to
> achieve. (other OS'es come with their own set of dependencies already, so
> we only can ignore them - or could build complete packages including all
> deps in the future if we do have a standard set).
>
> I had a look at conda-forge in the past months to evaluate if it could be
> considered fit for a reference build system. One precaution I had from the
> start was the rolling release dependency hell we had experienced with
> homebrew. It still needs to be proven if we get away with pinning. The
> major roadblock I hit was already updating Qt. I tried to lift it to the
> latest version with no success (and nobody else succeeded either despite
> constant efforts in the last 4 months since that -- because of CI
> limitations / build issues). If we would have a proposal how to continue
> here (custom hosted CI with a responsible person taking care of it?), I am
> open to explore this further.
>
> In summary, the current process we have works good enough, with the
> occasional troubles of varying dependency versions you mention. Changing it
> would be risky but possible and it is a major effort for which we currently
> lack a widely accepted plan, resources and/or (long-term committed)
> volunteers to do so.
>
> For your particular case here, since there are no standard versions of
> dependencies, conda might be as good as any other guess. Or you go for the
> installer of your main target platform instead.
>
> Best regards
>
> Matthias
>
>
> On 8/2/20 8:49 AM, Ari Meyer wrote:
>
> Obrigado, Alexandre, for all the details. :-)  I guess I'm still baffled
> by, "Conda-forge community always tries to use the most recent version of
> all dependencies."  It just seems like a "recipe" for disaster -- just
> built on assumptions.  Maybe you get lucky and everything just happens to
> work.  Or maybe you get slightly less lucky and encounter breakages
> immediately, forcing you to fiddle with the build until you find some
> combination that seems to work, if you can't pin the versions.  Or maybe
> you get unlucky and everything builds and *seems* to work based on the
> extent of your testing, but your testing may have important gaps.
>
> In my previous contract I was using PyViz, which was rebranded as
> HoloViz.  As that set of libraries was immature and constantly in flux, and
> we wanted to take advantage of new features/fixes, our policy was to go
> with the latest releases.  I wasn't comfortable with this, esp. after
> enduring many problems, but we just dealt with bugs and regressions as they
> came up.  QGIS, though, is much more mature, after more than a decade since
> 1.0 was released (2009 according to Wiki).  I assumed, therefore, that they
> wouldn't trust such a hit-or-miss strategy with dependencies.  But maybe
> I'm just being a worry wart. ;-)  In any case, I'm going to be hard-pressed
> to sell conda to my team if the dependencies are out of sync with those of
> the installers.
>
> On Fri, Jul 31, 2020 at 8:49 AM Alexandre Neto 
> wrote:
>
>> Hi,
>>
>> I will take this opportunity to give a brief explanation of how conda /
>> conda-forge works. At least what I was able to understand so far.
>>
>> Full disclaimer: I know very little about build

Re: [QGIS-Developer] using conda for development

[Alexandre Neto]

of conda-forge recipes, and upload the result to a dedicated
channel, probably even outside anaconda cloud.
- We could use dependencies available on conda-forge or other channels, but
we would need to be ready to maintain abandoned packages that greatly
impact QGIS, like QtWebkit;
- Recreate the installers (at least Windows and Mac) to use conda tools for
downloading, installing, and updating packages.

Last bit, when I was working for Boundless, Larry Shaffer was trying to do
all this mentioned above, but then the company was bought by Planet... Not
sure what is the status of this work now.

https://github.com/osgeo-forge

Thanks, Sorry for the long post.

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] Implementarion version in Function help JSON Files

[Alexandre Neto]

Hi,

I think we are talking about the same thing. We want to have a way to
inform the users of QGIS release version where the function was introduced.

Alexandre Neto



A quinta, 23/07/2020, 14:03, matteo  escreveu:

> HI Alexandre,
>
> that's a great improvement, thanks!
>
> Having a key to catch the QGIS release related to the expression would
> be also super useful. Anybody willingly to help on this?
>
> Cheers and thanks again
>
> Matteo
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Implementarion version in Function help JSON Files

[Alexandre Neto]

Hi,

Sorry for the cross-posting.

Because we only release documentation for the LTR versions (3.10 now) and
testing (which represents master), in the past, we have been adding the
version of QGIS where each function was added. That way, someone looking at
the testing documentation, would know that some functions were only
available, for example, after QGIS 3.12. Once the new Documentation release
for 3.16 is out, all these tags are removed and only used again for 3.18
functions.

Meanwhile, at the QGIS-Documentation, we are now fetching the Expressions
Function list (and its description, arguments and other
information) directly from QGIS Code using a python script, more precisely
from the JSON help files available in this folder:

https://github.com/qgis/QGIS/tree/master/resources/function_help/json

Would it be ok for us to add a new key with the "implementation version" in
the JSON files for some of the functions?

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