Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

[Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer]

I don't think so. I think the python console has its specific function by
now. I think an SQL interface should provide different functions and
integrations, maybe based on GDAL that seems less and less important and
may play a stronger role as Spatialite.
At the same time, I understand that having two consoles may be confusing
for some of us.
Maybe it's just a boomers' approach, I would love even getting a bash
interface, a lua and a node one because they serve different approaches...
;.)

On Thu, Sep 8, 2022 at 11:34 PM Alexandre Neto 
wrote:

> 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?

[Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer]

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 
>> 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] Inserting provider filter just before PostGIS layer is loaded?

[Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer]

I think this could find an interesting framework in the proposal of a new
database interface. One of the proposals pertains to the process interface.
Maybe it could become a more generic interface to data sources. More and
more data infrastructures are intrinsically no-SQL and it could be
interesting to mix them at the source level and not afterwards when it
becomes heavy and very application specific.
Disclaimer: I had a love affair with MapInfo MapBasic and I miss its
command interface. It would be wonderful to have a SQL-like interface for
it – and the Spatialite interface that comes with GDAL would be a good
opportunity for it.
BTW: maybe a virtual GDAL interface would help in getting what you need for
OsGeo services.


On Mon, Aug 22, 2022 at 12:11 PM Jacky Volpes via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi,
>
> I don't know any way to do this, except for using a workaround.
> But it will depend on your use-case.
> Maybe using query layers, such as
>
> QgsVectorLayer("table='(select * from . )'
> service='' key=''", "", "postgres")
>
> can help ?
>
> Regards,
> Jacky
>
>
>
> Le 09/08/2022 à 11:15, Johannes Kröger (WhereGroup) via QGIS-Developer a
> écrit :
>
> Howdy!
>
> I'd like to force a provider filter when a user adds a PostGIS layer and
> have it applied *before* any data is loaded. Setting it after the layer
> (and some of its big data) is loaded initially is not an option.
>
> Is there a way to sneak in between "user clicked something in the GUI to
> load a table/query and QGIS will construct a QgsVectorLayer now" and "QGIS
> now talks to the PostGIS database to get the data for the new layer", maybe
> with a signal?
>
> Something like a "layerAboutToBeLoaded" (like the opposite
> layerWillBeRemoved on https://qgis.org/pyqgis/master/core/QgsProject.html)
> basically. :o)
>
> Cheers, Hannes
>
>
> ___
> 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
>
>
> --
> Jacky Volpes
>
> Ingénieur SIG - Oslandia
>
> ___
> 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?

[Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer]

I think José has a good suggestion, maybe a fully integrated SQL console
could be the other way around the browser panel.
Having a "Database" Menu without any database management tool could be
funny and deceiving for new users. The idea of having SQL as another
language to manage geographic DBMSs (and not only PostGIS) seems
interesting albeit not new (who remembers MapBasic in MapInfo?). For some
time it seemed that the integration with Spatialite could become so strong
that I was becoming the way to handle all the features of QGIS in a
data-centric way.
Then the affirmation of geopackage seems to have changed the outlook for
QGIS.
c

On Sun, Jul 10, 2022 at 3:06 PM José de Paula Rodrigues via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi, all,
>
> I must say I agree with Alexandre; one of the most precious feature of
> QGIS for me and the folks that work with me is the ability to very quickly
> and easily interact with PostGIS, making experiments, testing a query,
> adjusting, tailoring, comparing with other kinds of data sets, right there
> on the QGIS interface. I also agree that QGIS is not a database
> "manager"/"workshop"/"weaver" tool, so tasks such as creating database
> models, adding or removing columns, creating or droping
> tables/schemas/databases/roles might be out of scope for QGIS.
>
> If the leaders really think the DB Manager plugin should go away, perhaps
> the current functionality of the SQL Window from DB Manager (with the
> ability to create a layer right from the query) could be moved to something
> akin to the current Python console.
>
> One of the greatest strengths of QGIS, compared to the proprietary
> industry leader, is the ease and immediacy of working with all kinds of
> different dataset types, and I feel that if the DB manager goes away
> without some sort of replacement for its query window, this QGIS advantage
> will shrink a little.
>
> Thank you all.
>
> On Sun, Jul 10, 2022 at 8:51 AM Alexandre Neto via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> 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: 

Re: [QGIS-Developer] Problems with MAC and OneDrive

[Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer]

>
> Is there versioning control built into OneDrive?

Yes, as you can see here:
https://support.microsoft.com/en-us/office/restore-a-previous-version-of-a-file-stored-in-onedrive-159cad6d-d76e-4981-88ef-de6e96c93893
you can restore a previous version of a file stored in OneDrive. To what
means, I don't know, but sharing a SQLite, Spatialite or GPKG on cloud
storage is really a stress test for the concept of file sharing,
especially if it's shared (and if you are the same user on two platforms,
you have to be very very lucky.

On Tue, Apr 5, 2022 at 12:07 AM Patrick Dunford via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> I'll endorse that plus in noting that I have seen tables wiped clean
> with geopackage where there may be multiple users. Even if there is only
> one actual user, there is a risk with multiple clients on a file based
> system because there is no inherent mechanism with the file based layers
> to handle transactions the way there would be with a DBMS server. SQLite
> is not recommend over a network for multiple clients.
>
> That is separate from the other point which is that any one local client
> can overwrite the cloud version which is risky. Is there versioning
> control built into OneDrive?
>
> On 5/04/22 03:33, Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer
> wrote:
> > Could you please provide some more info about the format of the data?
> > I think your question does not imply using a DBMS server which I could
> > suggest in this case. Sharing a file that can be updated on a remote
> > file system involves some (risky) reaction, but cloud storage is
> > different, it involves syncronisation and I think it requires some
> > planning and careful evaluation of the consequences of the choices of
> > every participant in the workgroup. If you synchronise the empty file
> > towards a non-empty version... you get an empty file.
> > Maybe you can recover the work looking to all the revisions of the
> > same file on Onedrive. Good luck.
> > c
> >
> >
> ___
> 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] Problems with MAC and OneDrive

[Carlo A. Bertelli (Charta s.r.l.) via QGIS-Developer]

Could you please provide some more info about the format of the data? I
think your question does not imply using a DBMS server which I could
suggest in this case. Sharing a file that can be updated on a remote file
system involves some (risky) reaction, but cloud storage is different, it
involves syncronisation and I think it requires some planning and careful
evaluation of the consequences of the choices of every participant in the
workgroup. If you synchronise the empty file towards a non-empty version...
you get an empty file.
Maybe you can recover the work looking to all the revisions of the same
file on Onedrive. Good luck.
c

On Mon, Apr 4, 2022 at 1:57 PM Halle Allen I Lech-Consulting via
QGIS-Developer  wrote:

> Dear Developers,
>
>
>
> we have a Client that uses your QGis on MAC and two surfaces. The central
> data Storage is OneDrive.
>
>
>
> That means that that Client works on the Surface when he is externally
> working comes into the „office“ and works on the MAC.
>
>
>
> While being external he cleanly sync the data into the OneDrive Cloud and
> then opens the synced Data with MAC. After a few day the data und the
> databases are completely clean like they were never used.
>
>
>
> Could you help me out?
>
>
>
> Greetings from Germany.
>
>
>
> Schöne Grüße
>
>
>
> Allen Halle
>
> *Fachinformatiker für Systemintegration*
>
>
>
> Tel:  +49 8231 / 95 888 - 99
>
> Fax: +49 8231 / 95 888 - 98
>
> Mail: allen.ha...@lech-consulting.de
>
> Web: http://www.lech-consulting.de/
>
>
>
> [image: cid:image001.jpg@01D64F95.9C34B670]
>
>
>
> *Schneider & Schwandtner GbR*
>
> - Lech Consulting -
>
> Guldenstraße 33
>
> 86343 Königsbrunn
>
>
>
> Geschäftsführung: Michael Schneider, Roland Schwandtner
>
> Firmensitz: Königsbrunn
>
> Gerichtsstand: Augsburg
>
> USt-IdNr: DE297850929
>
>
>
> *Damit Ihre IT flüssig läuft !*
>
>
>
> Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte
> Informationen und Anlagen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten haben, informieren Sie bitte sofort den Absender und vernichten
> Sie diese E-Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind
> nicht gestattet.
>
> This e-mail may contain confidential and/ or privileged information. If
> you are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail.
> Any unauthorized copying, disclosure or distribution of the material in
> this e-mail is strictly forbidden.
>
>
>
> Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte
> Informationen und Anlagen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten haben, informieren Sie bitte sofort den Absender und vernichten
> Sie diese E-Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind
> nicht gestattet.
>
> This e-mail may contain confidential and/ or privileged information. If
> you are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail.
> Any unauthorized copying, disclosure or distribution of the material in
> this e-mail is strictly forbidde
> Diese E-Mail enthält vertrauliche und/ oder rechtlich geschützte
> Informationen und Anlagen.
> Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich
> erhalten haben, informieren Sie bitte sofort den Absender und vernichten
> Sie diese E-Mail.
> Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind
> nicht gestattet.
>
> This e-mail may contain confidential and/ or privileged information. If
> you are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail.
> Any unauthorized copying, disclosure or distribution of the material in
> this e-mail is strictly forbidden.
> ___
> 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] WFS3 API POST PUT Methods

[Carlo A. Bertelli (Charta s.r.l.)]

The GeoJSON Specification (RFC 7946) mandates the use of WGS84:

The coordinate reference system for all GeoJSON coordinates is a
> geographic coordinate reference system, using the World Geodetic
> System 1984 (WGS 84) [WGS84
> ] datum, with
> longitude and latitude units
> of decimal degrees.

(chapter 4)

OAPIF can use GeoJSON (very often) and in this case using another reference
system is not allowed, but it can also use GML level 0 or level 2 and in
these cases there is no limit to what CRS you can use.


On Wed, Mar 2, 2022 at 6:09 PM Alessandro Pasotti 
wrote:

>
> Enrico,
>
> We only accept 4326 currently.
>
> I think we could be more tolerant if the OAPIF extensions allows it, we
> currently allow GET with other CRSs but POST/PUT/PATCH are not implemented
> to handle different CRSs.
>
> Kind Regards
>
>
> On Wed, Mar 2, 2022 at 1:53 PM Enrico Ferreguti 
> wrote:
>
>> Hi QGIS devs,
>> I'm testing the API REST interface for updating a WFS3 and I verified
>> that the new/modified feature had to be expressed in geojson format in
>> EPSG:4326 coordinates regardless of the SRID of the served layer. I
>> verified the behaviour with QGIS server 3.16 LTR and latest 3.22
>>
>> Is this an issue or a feature due to compliance to OGC or RFC7946
>> standards?
>>
>> Anyway I found this behaviour very uncomfortable because it obliges to
>> perform preliminarly unaccurate reprojections from javascript/python
>> clients.
>>
>> Best regards.
>> Enrico Ferreguti.
>> ___
>> 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] WFS-T, postgis and triggers

[Carlo A. Bertelli (Charta s.r.l.)]

I suppose we could benefit from the help of another Alessandro, the father
of Spatialite. I think he is already working on WFS3. Maybe this could lead
to an enhancement of libspatialite to make XML/JSON sources a more
interactive part of Spatialite itself or a virtualwms data provider for
Spatialite (like virtualpg).
c

On Sun, Nov 1, 2020 at 9:58 AM Régis Haubourg 
wrote:

> Hi,
> +1 with Denis, this is a quite common scenario, but the caching issue,
> combined with the good old WFS-T implementation spatialite provider issues
> looked like a big challenge.
>
> I think the future transactional version of WFS3 - OGC APIF should speed
> up and simplify a lot the protocol part. On my side, I was just waiting fo
> it to happen to raise the topic again.
>
> Concerning the client side caching, I'm not up to date with the potential
> spatialite provider enhancement.
>
> Having a reliable and efficient way to edit WFS-T would be really nice.
> But as Alessandro points out, our application with a lot of database
> intelligence will trigger a lot of data refresh in any case and we will
> have then some lags.
>
> Best
> Régis
>
>
>
>
>
>
> Le jeu. 29 oct. 2020 à 15:11, Denis Rouzaud  a
> écrit :
>
>>
>>
>> Le jeu. 29 oct. 2020 à 15:07, Alessandro Pasotti  a
>> écrit :
>>
>>> On Thu, Oct 29, 2020 at 2:59 PM Denis Rouzaud 
>>> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > I have a WFS-T layer with a Postgis DB behind it.
>>> > On my table, I have an insert trigger (before insert) which sets a
>>> field.
>>> > When I create a feature on this layer in QGIS, I don't get back the
>>> value of this field (I have to refresh the data, by re-opening QGIS for
>>> instance).
>>> >
>>> > Is this expected?
>>>
>>> Yes. The features are locally cached in a SQLite layer and a newly
>>> created feature will be stored locally and not retrieve from the
>>> server.
>>>
>>> > Is there anything we can fix?
>>>
>>> Of course yes but it would require re-fetching the feature(s) after an
>>> insert or an update, I think it will slow things down.
>>>
>>
>> This could be done asynchronously?
>> It sounds like a quite common scenario (or not if nobody complained...).
>>
>> Thanks for the answer anyway.
>>
>>
>>> Besides that there is no perfect solution to server-side changes: if
>>> some other user will trigger a data change on the DB we will of course
>>> miss it anyway.
>>>
>>>
>>> > Am I doing something wrong?
>>>
>>> No.
>>>
>>> Cheers
>>>
>>>
>>> --
>>> 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] What about AsincPg?

[Carlo A. Bertelli (Charta s.r.l.)]

Sorry for the noise!
c

On Mon, Aug 31, 2020 at 9:35 AM Tim Sutton  wrote:

> Hi Carlo
>
> In what context are you proposing this? We do not use python for the
> Postgres provider, but rather C++. If you are experiencing slowness using
> QGIS to connect to postgres it may well be your local configuration rather
> than postgresql. You would need to share a bit more detail before someone
> can help you resolve it though.
>
> Regards
>
> Tim
>
>
> On Fri, Aug 28, 2020 at 8:33 AM Carlo A. Bertelli (Charta s.r.l.) <
> carlo.berte...@gmail.com> wrote:
>
>> Maybe AsyncPg (https://github.com/MagicStack/asyncpg) could be the
>> answer for the slow pace of psycopg.
>> What do you think?
>> Using database introspection that was introduced since version 9.2,
>> AsincPg is not compatible with version 8.4 that is still widely used, but
>> declared speed gains seem worth trying.
>> c
>>
>> --
>> --
>> Carlo A. Bertelli
>>Charta servizi e sistemi per il territorio e la storia ambientale srl
>>   Dipendenze del palazzo Doria,
>>   vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
>>   tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393
>> 1590711
>>e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
>> --
>>
>>
>>
>> ___
>> 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
>
>
>
> --
>
> --
>
> Tim Sutton
> Visit http://kartoza.com to find out about open source:
>  * Desktop GIS programming services
>  * Geospatial web development
> * GIS Training
> * Consulting Services
> Skype: timlinux Irc: timlinux on #qgis at freenode.net
> Tim is a member of the QGIS Project Steering Committee
>
> ---
> Kartoza is a merger between Linfiniti and Afrispatial
>
___
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] What about AsincPg?

[Carlo A. Bertelli (Charta s.r.l.)]

Maybe AsyncPg (https://github.com/MagicStack/asyncpg) could be the answer
for the slow pace of psycopg.
What do you think?
Using database introspection that was introduced since version 9.2, AsincPg
is not compatible with version 8.4 that is still widely used, but declared
speed gains seem worth trying.
c

-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Popular plugins

[Carlo A. Bertelli (Charta s.r.l.)]

What Paolo said seems a suggestion to modify the existing query. Beside
popularity (downloads), the query should filter out the plugins that
provide functionality already in core (by version). This means having a
stronger control of the plugins and features to decide what is in and what
is out for any version. The funny thing is that the new features for any
version are (loosely) tied to the most requested plugin features.

On Thu, Nov 14, 2019 at 3:36 PM C Hamilton  wrote:

> It appears to me that popularity should be what is currently popular. If
> you are only keeping track of the total downloads and not when they are
> downloaded, then I am not sure that category has that much meaning. Adding
> in the ratings probably adds a little, but as I have looked at some of the
> star rankings of some plugins, tested their usefulness, how well they
> perform, and how may downloads they have vs stars, I wonder whether some of
> the rankings have been artificially inflated. The net result is that I
> don't believe some of them. I'm not sure there is a good solution to the
> popularity question. My suggestion is to make it dependent on only the past
> year's downloads and not the total if you have those stats and then somehow
> add in the star rankings from the past year as well.
>
> On Thu, Nov 14, 2019 at 9:01 AM Alessandro Pasotti 
> wrote:
>
>>
>>
>> Can't remember exactly why that formula, but it was carefully discussed
>> at the time (7 years ago):
>>
>>
>> https://github.com/qgis/QGIS-Django/blob/master/qgis-app/plugins/models.py#L113
>>
>>
>>
>>
>> On Thu, Nov 14, 2019 at 2:58 PM C Hamilton 
>> wrote:
>>
>>> What kind of stats are kept for the plugins? Popular plugins could be
>>> those with the most downloads during the past year, but I don't know if you
>>> keep track of when the downloads occurred.
>>>
>>> Calvin
>>>
>>> On Wed, Nov 13, 2019 at 11:50 PM Paolo Cavallini 
>>> wrote:
>>>
 Hi all,
 I noticed that the Popular plugins sections on our plugin web app is
 somewhat misleading, listing mostly plugin with a high number of
 downloads and good ratings in the past, not necessarily still very
 useful, often replaced by better alternatives in core.
 I'd suggest either finding a better query (not easy to design, I
 remember Alessandro and me spending some time on this years ago) or drop
 it altogether.
 Opinions?
 Cheers.
 --
 Paolo Cavallini - www.faunalia.eu
 QGIS.ORG Chair:
 http://planet.qgis.org/planet/user/28/tag/qgis%20board/
 ___

>>>
>> --
>> Alessandro Pasotti
>> w3:   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



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Dropping the extra label placement algorithms?

[Carlo A. Bertelli (Charta s.r.l.)]

Yes, if you consider trial and error a mindful method, I "use" label
placement algorithms when preparing a cartographic layout for printing.
I mainly work on geographic data and web output, so it's not frequent and I
follow the easy and dumb way: I swap algorithms, hoping for a result that
solves cluttering in the worst spots, until it fits – usually it fits here
and it's out of order elsewhere...
I generally criticise this approach, but when looking for a good
appearance, it seems bearable. Yes, I would need some more information to
do a better work. As already said, I think this is a cartographic issue
that can get more benefits by a better GIS approach. Label positioning is
not "substantial" but can exploit proper data. Say population for a
populated place. Using these algorithms on top of geometric-only data gives
little more than casual results.
I had the opportunity to weight the theory behind these methods starting
from the obituary of Mitchell Jay Feigenbaum by Maurizio Codogno on
ilPost.it that referenced the New York Times:
https://www.nytimes.com/2019/07/18/science/mitchell-feigenbaum-dead.html.
Looking to further developments, I think there is not a "best" algorithm,
but that it's useful to keep alternatives. I doubt the algorithms could
really work well without an interface that can reach useful data, but I
also think that keeping them available without any special interface could
keep them in a place that is not really influenced by the frequent
enhancements of QGIS.
c


On Mon, Jul 29, 2019 at 8:31 AM Nyall Dawson  wrote:

> On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.)
>  wrote:
> >
> > Label placement took a lot of time and efforts in the past and this is
> the outcome.
> > It's true, there is no real need for it while on screen, but it could be
> very useful in Layout. The problem is similar to generalisation, you need
> proper data to support label placement. Losing the relationship with real
> geographic objects, when exporting the layout in SVG or postscript, label
> placement takes time and needs cartographic expertise while changing the
> algorithm in Layout mode can help a lot.
>
> So - just to confirm -- you are actively changing that setting, and
> seeing useful results from different methods? If so, which do you use?
> Which give the best results? What's the trade off between them?
>
> Nyall
>
>
> > Keeping several algorithms in Layout could ease code maintenance while
> keeping all the advantages.
> > On the other hand, this needs some efforts on documentation and Anita's
> touch is really welcome here. Algorithms need reference but also a plain
> explanation in something that resembles a book. Someone developed a
> publishing business out of a GIS program... maybe this is too much and has
> already been done, but...
> > My two eurocents.
> > c
> >
> > On Mon, Jul 29, 2019 at 2:00 AM Nyall Dawson 
> wrote:
> >>
> >> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson 
> wrote:
> >> >
> >> > Hey lists
> >> >
> >> > This was first discussed back in 2016 (see
> >> >
> http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html
> ),
> >> > but would anyone object if the different labeling solution algorithms
> >> > eg "chain" / "pop music" / "falp" / etc were dropped, and we just
> >> > leave the existing default (chain)?
> >> >
> >> > I don't think ANYONE knows what these mean, and it's a heck of a lot
> >> > of code (which needs fixes) to cart around for no compelling reason
> >> > that I can see.
> >> >
> >> > I have no particular preference to any of the methods, so would
> >> > happily accept a different default if anyone out there can point to
> >> > which method is best!
> >> >
> >> > Googling pop music / tabu / chain only gives a handful of results
> >> > relating to QGIS labeling engine. And googling for "falp" sounds like
> >> > something that would get you flagged on your company's firewall.
> >> >
> >> > Does ANYONE understand or change this setting? Or would object to its
> >> > complete removal?
> >>
> >> PR at https://github.com/qgis/QGIS/pull/30960
> >>
> >> Last chance to save this setting!
> >>
> >> Nyall
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org
> >> List info: https://lists

Re: [QGIS-Developer] Dropping the extra label placement algorithms?

[Carlo A. Bertelli (Charta s.r.l.)]

Label placement took a lot of time and efforts in the past and this is the
outcome.
It's true, there is no real need for it while on screen, but it could be
very useful in Layout. The problem is similar to generalisation, you need
proper data to support label placement. Losing the relationship with real
geographic objects, when exporting the layout in SVG or postscript, label
placement takes time and needs cartographic expertise while changing the
algorithm in Layout mode can help a lot.
Keeping several algorithms in Layout could ease code maintenance while
keeping all the advantages.
On the other hand, this needs some efforts on documentation and Anita's
touch is really welcome here. Algorithms need reference but also a plain
explanation in something that resembles a book. Someone developed a
publishing business out of a GIS program... maybe this is too much and has
already been done, but...
My two eurocents.
c

On Mon, Jul 29, 2019 at 2:00 AM Nyall Dawson  wrote:

> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson  wrote:
> >
> > Hey lists
> >
> > This was first discussed back in 2016 (see
> >
> http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html
> ),
> > but would anyone object if the different labeling solution algorithms
> > eg "chain" / "pop music" / "falp" / etc were dropped, and we just
> > leave the existing default (chain)?
> >
> > I don't think ANYONE knows what these mean, and it's a heck of a lot
> > of code (which needs fixes) to cart around for no compelling reason
> > that I can see.
> >
> > I have no particular preference to any of the methods, so would
> > happily accept a different default if anyone out there can point to
> > which method is best!
> >
> > Googling pop music / tabu / chain only gives a handful of results
> > relating to QGIS labeling engine. And googling for "falp" sounds like
> > something that would get you flagged on your company's firewall.
> >
> > Does ANYONE understand or change this setting? Or would object to its
> > complete removal?
>
> PR at https://github.com/qgis/QGIS/pull/30960
>
> Last chance to save this setting!
>
> 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



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Get rid of 'Manage Layers Toolbar', or not?

[Carlo A. Bertelli (Charta s.r.l.)]

This is an old debate, GIS programs usually show a very cluttered
interface. It's matter of muscles: more icons, more tools, more power.
Uncluttering the interface would help noviced and power users. I think that
actions that are performed "per feature" (frequently) may benefit from
getting an icon (and a keyboard shortcut) for one-click actions, but
actions that are performed "per map" (relatively unfrequently) should not
get an icon. I'm very fond of the superposition of Layer and Browser panel
because they are mutually exclusive. You may add a layer than switch to the
layer level and manage it – two clicks, but very useful and not in the
front stage. How many times you add a layer to a map?
One thing that should be assured is the complete alignment of Layer -> Add
Layer menu and Browser panel.
I know showing a new icon helps advertising new features, but... let's find
another way, say adding a button to the splash screen...
My two boring cents (sorry!)
c

On Sun, Mar 17, 2019 at 1:24 PM Richard Duivenvoorde 
wrote:

> On 17/03/2019 13.19, Mathieu Pellerin wrote:
> > For the record, this toolbar is already hidden by default.
> >
> > Some people like the one-button unified dialog, some prefer the
> > individual provider buttons. I don't see why we'd want / what we'd gain
> > to remove this hidden-by-default toolbar.
>
> We'd gain the need to support it: as said, it is missing th 'Add Mesh
> Layer' button currently. So I'd be in favour of removing instead of
> investing time keeping (even hidden) toolbars up to date with new
> functionality.
>
> I'm also aware that adding it is 10 minutes of work, but I think we keep
> too much 'history' in all kind of places in the project: we should not
> be afraid to do some cleanup once and every while?
>
> 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

Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin

[Carlo A. Bertelli (Charta s.r.l.)]

This long and fruitful exchange about usage of Windows-only executables
inside QGIS suggests the availability of some "bridge" made using wine (
winehq.org). This could be an infrastructure made available to Processing
that could ease accessing some valuable tool.
c

On Mon, Feb 11, 2019 at 8:25 AM Paolo Cavallini 
wrote:

> Hi Christina,
> thanks for this. I believe implementing this in QGIS should not be hard.
> In any case, R has the most reliable and complete set of kriging
> methods, and can be used within Processing.
> Al the best.
>
> On 11/02/19 00:56, christina.ratcl...@csiro.au wrote:
> > Hi Paulo,
> >
> > VESPER provides local block kriging. It has also been adopted as the
> method and tool of choice by the Precision Agriculture industry here in
> Australia.
> >
> > Further information on VESPER can be found at
> https://sydney.edu.au/agriculture/pal/software/vesper.shtml.
> >
> > Christina
> >
> > -Original Message-
> > From: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] On
> Behalf Of Paolo Cavallini
> > Sent: Friday, 8 February 2019 6:10 PM
> > To: qgis-developer@lists.osgeo.org
> > Subject: Re: [QGIS-Developer] Windows only version of a QGIS 2.18x plugin
> >
> > Hi all,
> >
> > On 07/02/19 08:46, Alessandro Pasotti wrote:
> >
> >> That makes me think that perhaps the best win-win solution would have
> >> been to fix/improve QGIS's Kriging implementation instead of relying
> >> on a windows-only binary.
> >
> > Christina, what is missing fro our core kriging module?
> > Thanks.
> >
> > --
> > Paolo Cavallini - www.faunalia.eu
> > QGIS.ORG Chair:
> > http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> > ___
> > 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
> >
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Plugin [1462] Repair Lines Connections approval notification.

[Carlo A. Bertelli (Charta s.r.l.)]

Hello,
the page of this plugin:
http://plugins.qgis.org/plugins/RepairLinesConncetions/
heads to the repository for another plugin developed by Carlos Eduardo
Cagna.
The right link should be:
https://github.com/CarlosCagna/RepairLinesConncetions
It would be event better to fix the spelling of Connections on Github
before changing the page of the plugins, but...
Thanks in advance. Sobretudo for the plugin which is a true blessing when
working on hiking trails ;.).
c

On Mon, Feb 4, 2019 at 6:34 PM  wrote:

>
> Plugin Repair Lines Connections approval by pcav.
> The plugin version "[1462] Repair Lines Connections 1.0" is now approved
> Link: http://plugins.qgis.org/plugins/RepairLinesConncetions/
> ___
> 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] Find unmaintained plugins

[Carlo A. Bertelli (Charta s.r.l.)]

Hi Paolo,
if I understand well, your reply implicitely highlights several topics.

Plugins are plug-ins, they are supposed to serve as an integration of
specialised functions that are too specific to become part of the main
program. This in theory; sometimes they are a temporary solution for a more
general audience, sometimes they propose an alternative solution for
something that is already in QGIS.
I think this should be clear to users, what category the plugin belongs to,
and one of the most important enhancements to the present situation is
adding this information to the list. Then it should be clear since what
version the functionality provided by a plugin has been added to the QGIS,
so the plugin should not be installed unless the user is so fond of the
provided workaround to prefer the plugin to the solution adopted by QGIS
(it happens!).

The second item is about categorisation of plugins. They are many more than
anyone would expect when the plugins were introduced. Alphabetical order is
not anymore a solution when you have several hundred plugins (there should
be a psycological rule written about this somewhere, please fill in if you
know ;.)), we should find out categories and attribute plugins to these
categories. When a developer wants to do something about any issue which is
already tackled by one of more plugins (it's frequent, I see), he should
also provide information about what plugins become obsolete. It's not a
good idea to "vote for obsolescence".

The third item is about automation. Github has some experience about how to
evaluate source code, I think we should bring the data that Zoltan shows
for the plugin he evaluated in the list, adding how many bugs were found,
closed or stay open since when, suggesting that some plugins should be
subject to further investigation. This is the area for human intervention.
Some warning can be automated, but it would be better to provide a
responsible feedback. Some developer feel more responsible for certain
subject, I think that categorising plugins helps developers to keep an eye
on plugins that are relevant for everyone's area of experience.

Over all, I think that the work you do about administrative and technical
approval (thank you very much for your attention and even for your
occasional failures) could be balanced by Anita Graser who has frequently
focused on some interesting plugins. This is another important issue about
documentation. There should be a comprehensive description of what plugins
do. Having a simple list, even a categorised list, is not enough. Some
plugins – DbManager comes immediately to my mind – are even more important
for me and for others than many features of the main program.

Sorry for being so verbose, but all the work done on plugins so far
deserves great attention.
c

On Sun, Feb 3, 2019 at 1:45 PM Paolo Cavallini 
wrote:

> Hi Siki,
>
> On 03/02/19 10:54, Siki Zoltan wrote:
> > Hi All,
> >
> > there should be some mechanism to overtake a plugin.
> > For example the qgsaffine plugin [1], the last commit was in 2015 on
> > github and there is a pull request [2] (more than one month old) which
> > upgrades plugin to qgis 3.4.
> > Deadlock...
> >
> > Zoltan
> >
> > [1] https://github.com/eriktim/qgsAffine
> > [2] https://github.com/eriktim/qgsAffine/pulls
>
> the plugin manager can change the author email and name. of course it
> would be good to have the original author's assent, but I realize that
> this is not always possible.
> Perhaps this should only be made more clear and visible to power users.
> What do you suggest?
> Cheers.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Why is .qgz the default format?

[Carlo A. Bertelli (Charta s.r.l.)]

My first reaction is "please KISS", the XML project is already complicated,
so I would stick to option 1.
About usability, I really don't mind it. Having a zipped file is convenient
when... I make a mess, editing the project file.
There is already an enhancement proposal to optionally save the project to
the database, it could be a good start for option 2, but the project is
stored as raw content to accomodate future changes in any direction.
Here are my two cents: don't try to automate everything, sometimes a touch
of vi saves your day, and above all don't make it overly complicated for
automation sake.
c

On Mon, Jan 21, 2019 at 2:41 PM Hugo Mercier 
wrote:

> Hi,
>
> On 21/01/2019 14:19, Régis Haubourg wrote:
> > Hi all,
> >
> > The initial plan - discussed some years ago on the lists - was to have a
> > container so that we can embed resources along the project file, and
> > open the door to a lot of nice features for sharing qgis projects.
> > The auxiliary data work was the opportunity to add this optional format
> > and checks the associated issues.
> > Then the idea was to switch to qgz by default and add features to save
> > resources (svg, fonts, datasets, etc...) into the project file.
> >
> > Unfortunately, the expected funding was discontinued and we are stuck
> > now with this default QGZ format, only storing the qgs and the qgd
> > files.  (I think one should not hire a QGIS funder and expect fundings
> > keep coming afterwards :) )
> >
> > The timing was bad also, because we only start since a few weeks to have
> > user feedback on this, like this issue
> https://issues.qgis.org/issues/20828
> >
> > We also have feeback that QGZ makes things more complicated for qgs
> > maintenance tasks.
> >
> > I really don't know what to do:
> >
> > - switch back to classical qgs and let qgz get maturity. (But I'm afraid
> > we'll have very few real feedback then, just like during 3.0-3.2 period)
> > - give up qgz and bet on another option to offer a container (geopackage
> )
> > - totally switch to qgz and offer a python lib for easing maintenance
> > tasks ?
>
> I would vote for your 3rd proposition: replace xml hacking by something
> that looks like calls to an API.
> And adding an option for those who want to switch back to .qgs +
> separated aux files, keeping the default to .qgz.
>
> ___
> 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



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Redmine stats

[Carlo A. Bertelli (Charta s.r.l.)]

Hello,
maybe I don't catch the right meaning of proposals, but I think we could
put in better use GitHub by using its API (
https://developer.github.com/v3/repos/statistics/).
Sorry for misunderstanding if it happens.
c


Il giorno mar 15 gen 2019, 09:03 Paolo Cavallini  ha
scritto:

> Hi Richard,
>
> On 15/01/19 07:53, Richard Duivenvoorde wrote:
> > I had a look at that page, it is 4 years old, and updates the database
> > schema? Anybody experience with this or anybody wants to fix the
> > database if anything goes wrong ;-)
> > (Maybe try at the hackfest after a db backup, not we run Redmine 2.5.2)
>
> thanks for your reply (and glad also Nyall is intersted - I really think
> this should make part of our quality control strategy).
> The plugin I mentioned was just an example. I see there are many, e.g.:
> https://duckduckgo.com/?q=redmine+statistics=ffab=images
> Selecting the most appropriate is an important part of the job.
> Unfortunately, many are not free, but I do not think we need very fancy
> stuff- the rate of opening and closing tickets over time is probably the
> most important thing. Any Redmine expert around?
> All the best.
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
> ___
> 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] IFC data in QGIS?

[Carlo A. Bertelli (Charta s.r.l.)]

About GDAL and IFC, there is something useful here:
https://3d.bk.tudelft.nl/ken/en/thesis/implementation.html
c

On Wed, Dec 12, 2018 at 2:53 PM Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com> wrote:

> Is ifcopenshell.org any use in getting data into QGIS? May GDAL may use
> it to convert to XML and than resort to the infrastructure used for GML
> (which is unfortunately not so similar, looking to namespaces)?
>
> Il giorno mer 12 dic 2018, 14:04 Loïc Bartoletti <
> lbartole...@tuxfamily.org> ha scritto:
>
>> Hi,
>>
>> IFC is the exchange format for BIMs. At this time, GDAL/OGR cannot read
>> this format. Some may wonder about the need to read this format in a
>> GIS, personally, I think it is an evolution of our tools for BIM/GIS
>> convergence.
>> However, to answer the question, unless I am mistaken, it is not
>> possible to read an IFC file in QGIS. However, one solution may be to
>> use FreeCAD with its Arch module to open this file and export it in a
>> format that can be read by QGIS, including Qgis 3D.
>>
>> Loïc Bartoletti
>>
>> Le 12/12/2018 à 12:36, johnrobot a écrit :
>> > Hi
>> > Are there any plans on adding support for reading IFC data
>> > (https://en.wikipedia.org/wiki/Industry_Foundation_Classes) in QGIS?
>> That
>> > would help bridge the gap between the GIS/BIM/CAD worlds.
>> >
>> > I originally posted this on the user list, but I realized that this list
>> > might be a better match.
>> >
>> > Regards,
>> >
>> > Magnus
>> >
>> >
>> >
>> > --
>> > 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
>> ___
>> 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] IFC data in QGIS?

[Carlo A. Bertelli (Charta s.r.l.)]

Is ifcopenshell.org any use in getting data into QGIS? May GDAL may use it
to convert to XML and than resort to the infrastructure used for GML (which
is unfortunately not so similar, looking to namespaces)?

Il giorno mer 12 dic 2018, 14:04 Loïc Bartoletti 
ha scritto:

> Hi,
>
> IFC is the exchange format for BIMs. At this time, GDAL/OGR cannot read
> this format. Some may wonder about the need to read this format in a
> GIS, personally, I think it is an evolution of our tools for BIM/GIS
> convergence.
> However, to answer the question, unless I am mistaken, it is not
> possible to read an IFC file in QGIS. However, one solution may be to
> use FreeCAD with its Arch module to open this file and export it in a
> format that can be read by QGIS, including Qgis 3D.
>
> Loïc Bartoletti
>
> Le 12/12/2018 à 12:36, johnrobot a écrit :
> > Hi
> > Are there any plans on adding support for reading IFC data
> > (https://en.wikipedia.org/wiki/Industry_Foundation_Classes) in QGIS?
> That
> > would help bridge the gap between the GIS/BIM/CAD worlds.
> >
> > I originally posted this on the user list, but I realized that this list
> > might be a better match.
> >
> > Regards,
> >
> > Magnus
> >
> >
> >
> > --
> > 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
> ___
> 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 Server WFS 2.18 unreliable?

[Carlo A. Bertelli (Charta s.r.l.)]

Just my two cents:
* try to understand if there are issues with charsets, sometimes you focus
on geometries and don't remember to check for lesser things;
* try to use ogr2ogr to try the conversion. What happens converting your
datasource directly to GML3?
c

On Wed, Nov 14, 2018 at 2:37 PM Andreas Neumann  wrote:

> Hi René and David,
>
> Thank you for your replies. Interesting to see that GeoJSON works, but
> GMLv3 fails.
>
> In my Apache webserver log I find the following error:
>
> [Wed Nov 14 14:32:54.580958 2018] [fcgid:error] [pid 13453] mod_fcgid:
> process /var/www/cgi-bin/qgis_mapserv.fcgi(22829) exit(communication
> error), get unexpected signal 11
>
> I also checked the geometries of the concenred table in Postgis for
> validity. All geometries seem to be valid.
>
> Do you have any idea what I could do? Or do you think the issue will be
> solved in QGIS 3.x master?
>
> Thanks,
>
> Andreas
>
> On 2018-11-13 22:37, René-Luc Dhont wrote:
>
> Hi Andreas,
>
> QGIS Server segfaults when it try to build the GML for a Feature
>
> The request works for GeoJSON format
> https://services.geo.zg.ch/ows/Gewaessernetz?SERVICE=WFS=GetFeature=1.0.0=zg.gewaessernetz=EPSG:2056=GeoJSON
> René-Luc
>
> Le 13/11/2018 à 14:32, Andreas Neumann a écrit :
>
> Hi,
>
> I am trying to publish a WFS Service through QGIS Server 2.18.
>
> However, the result I get back from GetFeature errors out.
>
> The XML stream starts correctly and after a while there is an HTML error
> snipped and as a result a non-wellformed XML response.
>
> this is my URL:
>
>
> https://services.geo.zg.ch/ows/Gewaessernetz?SERVICE=WFS=GetFeature=1.0.0=zg.gewaessernetz=EPSG:2056=GML3
>
> Sometimes it works, but most of the time it fails.
>
> Any ideas of what might be wrong?
>
> Is QGIS Server 3.x more reliable regarding serving WFS?
>
> Thanks,
>
> Andreas
>
>
-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Editing topology data

[Carlo A. Bertelli (Charta s.r.l.)]

QGIS is based on simple features and handles topological data (e. g. GRASS
layers) as such.
Recently I had to deal with a dataset made with Topobase (now Autodesk) on
Oracle Spatial (topology). I proposed to migrate it to PostgreSQL/PostGIS
as a topological dataset, withoud degrading it to simple features.
Handling it using Sandro Santilli's PostGIS Topology Editor could be a
possibility, but it was not upgraded for a long time and it does not seem
to be a long term solution.
What is the future of topology in QGIS? Handling topological vectors has
been substantially enhanced, but what about the data? How to deal with the
problems that the plugin (partially) tackles? I see a wide area for
enhancement proposals, but they are maybe off topic, maybe GRASS is the way
to go, without bothering QGIS.
What do you think?
c
___
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] Appending text data to a geopackage

[Carlo A. Bertelli (Charta s.r.l.)]

What about working on a geometric view with properly configured rules while
on PostgresSQL or with a trigger on other DBMSs (SQLite too)? It seems the
easiest way to avoid the shell. Maybe there could even be a way with a
virtual file based on internal SQLite... Just a thought...
c

On Wed, Oct 10, 2018 at 8:39 AM Paolo Cavallini 
wrote:

> Hi all,
>
> I have a simple problem for which I cannot find a simple solution: I
> have a table in a gpkg, and I have to add often data coming from text.
> Ideally I'd like to paste the text as a new record, having it parsed
> automatically. Currently this only seems possible from an SQL shell.
> Anything I'm overlooking?
>
> All the best, and thanks.
>
> --
> Paolo Cavallini - www.faunalia.eu
> QGIS.ORG Chair:
> http://planet.qgis.org/planet/user/28/tag/qgis%20board/
>
>
> ___
> 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



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] QgsProcessing vector types combobox

[Carlo A. Bertelli (Charta s.r.l.)]

May I support this request by Matteo?
When processing geometries, undesired multi-geometries are a frequent
outcome. It may even be useful to show the users that that the procedure
has a multi-geometry output. This usually means there are uplanned outcomes
and that the algorithm is not properly configured and/or is a wrong
solution for your problem.
Anyway, being able to precede a process with a multi-to-single algorithm
would be really convenient.
Thanks for pointing this out.
c

On Wed, Oct 10, 2018 at 9:27 AM Matteo Ghetta 
wrote:

> Hi devs,
>
> if I'm not wrong Processing script input combobox can filter some vector
> types [0] but does not distinguish between single and multi geometries.
>
> I think this could be useful to add. I faced a problem where an
> algorithm could not run with multipoint geometries, but I had to filter
> them after the RUN button was clicked
>
> Some opinions?
>
> Cheers
>
> Matteo
>
>
>
> [0] https://qgis.org/pyqgis/master/core/Processing/QgsProcessing.html
>
> --
> Matteo Ghetta - www.faunalia.eu
> QGIS & PostGIS courses: http://www.faunalia.eu/training.html
> https://www.google.com/trends/explore?date=all=IT=qgis,arcgis
> ___
> 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



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Discussing default snapping and node editing settings

[Carlo A. Bertelli (Charta s.r.l.)]

If the most frequent case is snapping to the same or to one or two other
layers, is not a good idea to ask the user to resort to advanced settings.
The proposed idea to put the choice of  layers in the basic snapping
options seems a reasonable solution IMHO.
About WFS - but this is true for remote geodatabases with slow connections
- indexing should happen on the current canvas with a clear limit on zoom
level: snapping to at little scale is dangerous, you will never understand
if you snapped to the right now or to something that is hidden behind a
simplification artefact.
A possible solution is viewing an enlarged area about three or four times
the confidence circle and indexing inside it in real time.
c

Il mer 12 set 2018, 19:26 Denis Rouzaud  ha
scritto:

> Hi Aurelio,
>
> That's what the advanced digitizing mode is made for, you can define per
> layer settings.
>
> Denis
>
> Le mer. 12 sept. 2018 à 13:13, Aurelio Pires  a
> écrit :
>
>> Hi,
>>
>> Editing the active layer is appropriate, but you may need to snap to
>> another layer even if it is for reference.
>> The best would be for the user to be able to tell which layers to use as
>> a snap.
>>
>> APires
>>
>>
>> On 2018-09-12 15:57, Andreas Neumann wrote:
>>
>> Hi,
>>
>> I noticed that by default QGIS is set to edit ALL layers and also snaps
>> to ALL layer by default. I do think that this is a bad default setting,
>> esp. with larger projects.
>>
>> We had issues because users had WFS layers in their project (read only,
>> as reference) and QGIS tries to index these WFS layers and to get their
>> vertices in order to snap to them. Then QGIS hangs and freezes and there
>> are network time outs. Apparently one has to kill QGIS using the task
>> manager.
>>
>> I think the better default is to edit and snap only in the active layer
>> by default.
>>
>> Opinions?
>>
>> Andreas
>>
>>
>> ___
>> 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
>>
>>
>> ___
>> 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
>
> --
>
> Denis Rouzaud
> de...@opengis.ch  
> +41 76 370 21 22
>
>
> ___
> 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] What to do about WFS test failures?

[Carlo A. Bertelli (Charta s.r.l.)]

What about starting with/focusing on WFS 3? The new version is really
cleaner and seems much more efficient.
The current WFS implementation in QGIS is much better than previous
versions, even if sometimes making a virtual OGR file il the only way to
use some services. There are really bad server implementations out there,
additionally an automated solution struggles against misleading and lazy
XML informations. This is a broken idea or at least one that asks for close
cooperation between server and client.
Just my remaining cent.
c


On Mon, Sep 3, 2018 at 10:01 PM, Jeremy Palmer  wrote:

> Can I also add that the refactoring that was funded in 2.16 added tests,
> paging support, filter query builder and dynamic caching. There is now a
> lot of complexity in the driver due to the complexity of WFS server
> implementations and the standard, plus the multi-threading code. If a
> refactor is proposed I would be against anything that doesn't deal current
> use cases and edge cases which have already been implemented. Maybe some
> analysis of the failed tests is the first place to start. WFS-T is a side
> issue to that.
>
> Cheers,
> Jeremy
>
>
> On Tue, Sep 4, 2018 at 7:51 AM Régis Haubourg 
> wrote:
>
>> Hi Even, thanks for pointing that, I missed that history.
>> I'll ask the dev's for the detailed improvements planned, I dont' have
>> any detail currently (sorry for that)
>> Régis
>>
>> Le lun. 3 sept. 2018 à 21:29, Even Rouault 
>> a écrit :
>>
>>> Régis,
>>>
>>> Not that I'm against improvements, all the contrary, but just wanted to
>>> underline that the provider was seriously refactored already in 2.16.
>>> Clearly
>>> the lack of WFS-T support for 1.1 and 2.0 in the scope of those
>>> enhancements
>>> can be a source of confusion currently for users. What do you have in
>>> mind as
>>> refactoring exactly ?
>>>
>>> Even
>>>
>>> > Hi all,
>>> > I very much think that the WFS client is an really bad state, and is
>>> not
>>> > really reliable, especially in WFS-T context.
>>> > The good news is that we just have been funded to refactor it !
>>> > The work should start in september and land in 3.6. I will let our
>>> dev's
>>> > come here with more technical details about the goals. I hope we will
>>> also
>>> > be able to take benefit of this to this the OGC compliancy of the
>>> client
>>> > here.
>>> > Best regards,
>>> > Régis
>>> >
>>> > Le lun. 3 sept. 2018 à 11:36, Tom Chadwin  a
>>> >
>>> > écrit :
>>> > > I can't offer any helpful suggestions, but just to let you know I
>>> finally
>>> > > had
>>> > > to disable all my plugin WFS tests. I used to cope, by rerunning
>>> failed
>>> > > Travis runs, but by about three months ago, it seemed no longer
>>> usable -
>>> > > failure after failure.
>>> > >
>>> > > I was using a third-party WFS, and perhaps I could have got round
>>> this by
>>> > > adding a WFS provider to the test docker image, but in this plugin's
>>> case,
>>> > > I
>>> > > didn't think it worth the significant effort to do so. The WM(T)S
>>> tests
>>> > > also
>>> > > use third-party sources and seem stable, so perhaps this wasn't the
>>> > > underlying issue anyway.
>>> > >
>>> > > If an improvement or solution could be found, it would be great to
>>> > > reinstate
>>> > > these tests.
>>> > >
>>> > > Thanks
>>> > >
>>> > > Tom
>>> > >
>>> > >
>>> > >
>>> > > -
>>> > > Buy Pie Spy: Adventures in British pastry 2010-11 on Amazon
>>> > > --
>>> > > 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
>>>
>>>
>>> --
>>> Spatialys - Geospatial professional services
>>> http://www.spatialys.com
>>>
>> ___
>> 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
>



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
QGIS-Developer mailing list

Re: [QGIS-Developer] epel packages gdal and spatialite

[Carlo A. Bertelli (Charta s.r.l.)]

I should add that there are already other sites providing RPM packages for
GIS. One of them, very good and coordinate with EPEL (when possible, that's
the case about GDAL), is Postgresql's one (originally provided by Devrim
Gündüz who is still in the team).
See for example:
https://yum.postgresql.org/10/redhat/rhel-7-x86_64/repoview/
with all the provided packages (A..W).
It may be a good idea not to replicate this effort, but to supplement it
with missing packages.
Ciao
c

On Wed, Aug 29, 2018 at 11:03 AM, Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com> wrote:

> Thank you, it's a very good idea. The Enterprise Linux Gis project (ELGIS
> - https://wiki.osgeo.org/wiki/Enterprise_Linux_GIS) says:
>>
>> The ELGIS repository is not maintained any more, use EPEL.
>
>
> I don't think there is a strong need for QGIS (Desktop), Centos and RH are
> mainly used as servers, but everything that can enable a FOSS GIS
> environment is beneficial to QGIS and is very well done. Obviously
> RH/Centos is an excellent home for QGIS Server & friends.
>
> If I may add something about this, I suggest to target an SDI
> infrastructure, including GeoNode or something of the like, oriented
> towards a geographic topic not only to show single choropletic layers.
>
> Regards.
> c
>
>
> On Wed, Aug 29, 2018 at 10:36 AM, Richard Duivenvoorde <
> rdmaili...@duif.net> wrote:
>
>> On 08/29/2018 09:47 AM, Sebastiaan Couwenberg wrote:
>> > On 8/29/18 9:24 AM, Richard Duivenvoorde wrote:
>> >> Anybody aware if there is (other then nobody did it) a reason epel does
>> >> not contain 2.x ?
>> >
>> > ABI breaking changes are should be avoided, see:
>> >
>> >  https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_
>> major_version_update
>>
>> Hi Bas,
>>
>> Brrr.. I more or less understand, but RHEL7 released in 2015 (Centos 7.5
>> released in latest april), this means that 'we' are stuck with GDAL 1.x
>> for years...
>>
>> While my idea of epel was that it not only provided some extra packages,
>> but also some more up to date packages... (like we do with
>> https://qgis.org/debian)
>>
>> My reason for mocking about this is that I see RHEL and CentOS at a lot
>> of municipalities/governmental agencies etc.
>> And if we want for example QGIS-server to be installed in such places,
>> it should really be easier to install.
>>
>> I do not think a separate repo would be a solution? EPEL is a
>> well/better established and trusted one.
>>
>> I'm able to compile/install gdal myself, but am thinking here for the
>> more general public.
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>> ps and yes, I know Docker :-)
>> ___
>> 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
>>
>
-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] epel packages gdal and spatialite

[Carlo A. Bertelli (Charta s.r.l.)]

Thank you, it's a very good idea. The Enterprise Linux Gis project (ELGIS -
https://wiki.osgeo.org/wiki/Enterprise_Linux_GIS) says:
>
> The ELGIS repository is not maintained any more, use EPEL.


I don't think there is a strong need for QGIS (Desktop), Centos and RH are
mainly used as servers, but everything that can enable a FOSS GIS
environment is beneficial to QGIS and is very well done. Obviously
RH/Centos is an excellent home for QGIS Server & friends.

If I may add something about this, I suggest to target an SDI
infrastructure, including GeoNode or something of the like, oriented
towards a geographic topic not only to show single choropletic layers.

Regards.
c


On Wed, Aug 29, 2018 at 10:36 AM, Richard Duivenvoorde 
wrote:

> On 08/29/2018 09:47 AM, Sebastiaan Couwenberg wrote:
> > On 8/29/18 9:24 AM, Richard Duivenvoorde wrote:
> >> Anybody aware if there is (other then nobody did it) a reason epel does
> >> not contain 2.x ?
> >
> > ABI breaking changes are should be avoided, see:
> >
> >  https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#A_major_
> version_update
>
> Hi Bas,
>
> Brrr.. I more or less understand, but RHEL7 released in 2015 (Centos 7.5
> released in latest april), this means that 'we' are stuck with GDAL 1.x
> for years...
>
> While my idea of epel was that it not only provided some extra packages,
> but also some more up to date packages... (like we do with
> https://qgis.org/debian)
>
> My reason for mocking about this is that I see RHEL and CentOS at a lot
> of municipalities/governmental agencies etc.
> And if we want for example QGIS-server to be installed in such places,
> it should really be easier to install.
>
> I do not think a separate repo would be a solution? EPEL is a
> well/better established and trusted one.
>
> I'm able to compile/install gdal myself, but am thinking here for the
> more general public.
>
> Regards,
>
> Richard Duivenvoorde
>
> ps and yes, I know Docker :-)
> ___
> 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
>

-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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: Mixed Polygon/MultiPolygon shapefile

[Carlo A. Bertelli (Charta s.r.l.)]

Hello Javier,
just force the multipolygon behaviour.
As you say it's a GDAL refinement, just use a Layer Creation Option (-lco).
As per the docs (http://www.gdal.org/drv_shapefile.html):

   - *SHPT=type*: Override the type of shapefile created. Can be one of
   NULL for a simple .dbf file with no .shp file, POINT, ARC, POLYGON or
   MULTIPOINT for 2D; POINTZ, ARCZ, POLYGONZ, MULTIPOINTZ or MULTIPATCH for
   3D; POINTM, ARCM, POLYGONM or MULTIPOINTM for measured geometries; and
   POINTZM, ARCZM, POLYGONZM or MULTIPOINTZM for 3D measured geometries. The
   measure support was added in GDAL 2.1. MULTIPATCH files are supported since
   GDAL 2.2.

I think there are consequences, it will be necessary to know if there are
multipolygons in cadastral parcels. This is almost always the case if you
have an entire map, but it could be necessary to scan data or at least to
issue a GDAL_SQL query to detect it.

c

On Tue, May 29, 2018 at 3:39 PM, Javier Sánchez Portero <
javiers...@gmail.com> wrote:

> Hello
>
> My name is Javier Sanchez and I'm the developer of a QGIS based standalone
> application to convert Spanish Cadastre data to OpenStreetMap format [1].
> I'm trying to port this app from QGIS 2 to 3 and I would like this to work
> also with the previous version.
>
> In QGIS 2.x, I was able to write a shapefile with a mixed set of polygons
> and multipolygons geometries. Now in QGIS 3.x I can't. Maybe this is a GDAL
> issue. Probably the last behaviour is the correct one. But is there any way
> in QGIS 3 to create a shapefile mixing polygons with multipolygons?
>
> Here is an example code to illustrate what I meant:
>
> crs = QgsCoordinateReferenceSystem(32628)
> fn = 'xxx.shp'
> w = PolygonLayer.create_shp(fn, crs)
> p = [[QgsPoint(0,0), QgsPoint(1,0), QgsPoint(1,1), QgsPoint(0,0)]]
> mp = [[[QgsPoint(2,0), QgsPoint(3,0), QgsPoint(3,1),
> QgsPoint(2,0)]],
>   [[QgsPoint(4,0), QgsPoint(5,0), QgsPoint(5,1),
> QgsPoint(4,0)]]]
> f1 = QgsFeature(QgsFields())
> g1 = QgsGeometry().fromPolygon(p)
> f1.setGeometry(g1)
> w.addFeature(f1)
> f2 = QgsFeature(QgsFields())
> g2 = QgsGeometry().fromMultiPolygon(mp)
> f2.setGeometry(g2)
> w.addFeature(f2)
> del(w)
> l = QgsVectorLayer(fn, 'test', 'ogr')
> for f in l.getFeatures():
> g = f.geometry()
> print(g.isMultipart())
>
> When I run this in QGIS 2, the output is:
>
> False
> True
>
> When I run the same example in QGIS 3.x (replacing fromPolygon with
> fromPolygonXY and fromMultiPolygon with fromMultiPolygonXY), the output
> instead is:
>
> True
> True
>
> The writer converts g1 from polygon to multipolygon and every geometry in
> the resulting shapefile have the same type while before I had a bunch of
> multipart and singlepart geometries.
>
> Regards, Javier
>
> [1] https://github.com/OSM-es/CatAtom2Osm
>
>
> ___
> 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
>



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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 Print Composer - Page Properties

[Carlo A. Bertelli (Charta s.r.l.)]

I suggest to provide the same interface as version 2 calling this "default
page size" and explaining that every page could get a different size,
right-clicking on the page. Most users make one-page maps and they would
never need this otherwise vital feature.
c

On Mon, Apr 2, 2018 at 10:01 PM, Alessandro Pasotti 
wrote:

> The reason for this change is that your can now have different settings
> for each page.
>
> The page size is not a property of the layout anymore but it's a property
> of the page.
>
> But I agree that the page properties might be better exposed.
>
>
> On Mon, Apr 2, 2018, 21:56 C Hamilton  wrote:
>
>> I was just going to ask what happened to the "Page Size" properties in
>> the QGIS 3 print composer, but I stumbled upon it accidentally by
>> right-mouse clicking on the page and selecting "Page Properties." This was
>> not easily found. In the QGIS 2 print compose it is a part of the layout.
>> In QGIS 3 I just lucked out.
>>
>> Could the page properties be more obvious to find? At lease add them to
>> the Layout or Edit menus or put them back under the layout settings.
>>
>> Thanks,
>>
>> Calvin
>>
>
-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Microstation DGN v8

[Carlo A. Bertelli (Charta s.r.l.)]

We have been members of OpenDWG then Open Design Alliance for years. Teigha
is not open source, but we never paid any fee to use the converter/viewer,
I don't know if there is any limitation to use the (binary) libraries
included. I don't think so, but I may be wrong.
Licensing the source is unfortunately not free (as in free beer) and open
is "members only" which is a real pity.
Anyway, GDAL has a new driver based on the free (as in free speech as well
as in free beer) Libopencad (https://github.com/sandyre/libopencad), it's
called OpenCAD: http://www.gdal.org/drv_cad.html.
Unfortunately it does not cover DGN v8. I think Alexandr Borzykh could
extend his library to cover it as it is similar to DWG (it has no relation
to previous "true" DGN format).
c


On Tue, Mar 13, 2018 at 2:50 PM, Jürgen E. Fischer  wrote:

> Hi Erik,
>
> On Tue, 13. Mar 2018 at 13:59:48 +0100, Erik Leemreijze wrote:
> > I went looking for a solution and according to this website
> > (http://www.gdal.org/drv_dgnv8.html) it should actually be possible to
> load
> > the file format DGN v8 in QGis 2.18 and 3.0. However, it still does not
> > work. Does anyone know a solution for this problem?
>
> "This driver requires to be built against the (non open source) Open Design
> Alliance Teiga library."
>
> And that library is proprietary and only available for a fee (see
> https://www.opendesign.com/join).
>
>
> 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
> http://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
>
> ___
> 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
>



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Simple QGIS KML/KMZ Import

[Carlo A. Bertelli (Charta s.r.l.)]

XML and JSON formats do not adhere to the simple feature model of GDAL/OGR
that is reminiscent of a flat file or a relational table. And GDAL is one
of the base pillars for QGIS.
These are more similar to other storage models, say hierarchical or graphs,
so they enable a complex data structure that requires a pre-flight and asks
for some decisions to correctly represent their structure as a simple
feature or exceed it, delivering a complex relational system (if you can
guess some) or something other.
Maybe that's the new frontier for GDAL more than an opportunity for a
plugin. The same challenge is available for other formats like GPX,
geo/topoJSON, etc.
QGIS may implement much thoroughly the relevant options, but I think this
is work for GDAL.
c

On Fri, Mar 9, 2018 at 6:01 PM, C Hamilton  wrote:

> The challenge with KML imports is that its free form nature makes it
> difficult to conform to a table. I have large KMLs with nested folder
> structures. I find that these large KMLs crash QGIS if I try to import the
> entire thing and then each point gets rendered as a separate layer.
>
> It wouldn't be hard to write a script that just pulls out all the
> placemarks and writes them to a point layer, lines to a line layer, and
> polygons to a polygon layer. What I would loose is the folder structure and
> styling, but I could easily process large KMLs. I could consider a field in
> the layers that would be a string of the nested folders that each point,
> line, polygon were in.
>
> Would this be of interest as a plugin? Is anyone doing this already? There
> doesn't appear to be anything in the plugin repository.
>
> Thanks,
>
> Calvin
>
> ___
> 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
>



-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Issues building from source on Mac - No module named PyQt5

[Carlo A. Bertelli (Charta s.r.l.)]

This discussion is going a bit off-topic, but I think the problem could be
in your Homebrew installation. If someone changes the reference to qt from
qt4 to qt5 may cause some issue (I call it a mess, but I am biased, I had a
very bad time with these issue – thanks to Larry did fix them). Maybe you
will have to uninstall all qt related formulas and reinstall qt 4 and 5.
I see Remi Desgrange made a formula for the released QGIS 3 here:
https://github.com/RemiDesgrange/homebrew-qgisrelease
Are you using it?
c


On Fri, Mar 9, 2018 at 5:22 PM, Timur Girgin <girgin.ti...@gmail.com> wrote:

> Hello Carlo,
>
> Would you advice building Qt5 from source then, rather than using brew?
>
> Thanks
>
> On Fri, Mar 9, 2018 at 11:13 AM, Carlo A. Bertelli (Charta s.r.l.) <
> carlo.berte...@gmail.com> wrote:
>
>> Hello,
>> I suggest to remind that using Homebrew carries in another issue. The
>> maintainers decided to force everyone to use Qt5 as Qt4 is deprecated by Qt
>> developers. Everything that was called qt5-something should become
>> qt-something, so everyone who uses Qt4 had to make formulas called
>> qt4-something for every Qt4 dependency.
>> This was the case even for OsGeo4Mac (https://github.com/OsGeo/home
>> brew-osgeo4mac/) and Larry Shaffer had to recreate all the needed
>> dependencies inside this tap. If you have old Qt dependencies inside your
>> Homebrew, it may happen that qt-something is still qt4-something even if
>> brew thinks it's qt5... Feeling bewildered? So am I.
>> c
>>
>> On Thu, Mar 8, 2018 at 4:10 PM, Timur Girgin <girgin.ti...@gmail.com>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> I am having trouble building the QGIS release-3_0 branch on my Mac. I
>>> finally got it to cmake, however I am getting an error during the make
>>> process in which it seems that spatialite is using the system's Python(@2)
>>> executable to find PyQT5 when in reality it should be looking for it in the
>>> Python@3 executable that has been given during CMAKE. I am guessing
>>> this is what is causing the issue.
>>>
>>> Please find the error at the bottom of this email. If anyone knows what
>>> I am doing wrong, would you please let me know?
>>>
>>> Thank you very much!
>>> Tim
>>>
>>> Here is my CMAKE:
>>>
>>> cmake -D CMAKE_INSTALL_PREFIX=~/Downloads/QGIS-build \
>>>   -D CMAKE_BUILD_TYPE=MINSIZEREL -D ENABLE_TESTS=FALSE \
>>>   -D 
>>> SPATIALINDEX_LIBRARY=/usr/local/Cellar/spatialindex/1.8.5/lib/libspatialindex.4.dylib
>>> \
>>>   -D SPATIALINDEX_INCLUDE_DIR=/usr/local/Cellar/spatialindex/1.8.
>>> 5/include/spatialindex/\
>>>   -D QWT_LIBRARY=/usr/local/qwt-6.1.3/lib/libqwt.dylib \
>>>   -D QWT_INCLUDE_DIR=/usr/local/qwt-6.1.3/include \
>>>   -D BISON_EXECUTABLE=/usr/local/Cellar/bison/3.0.4_1/bin/bison \
>>>   -D GEOS_LIBRARY=/usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib \
>>>   -D GEOS_INCLUDE_DIR=/usr/local/Cellar/geos/3.6.2/include \
>>>   -D LIBZIP_LIBRARY=/usr/local/Cellar/libzip/1.4.0/lib/libzip.5.0.dylib
>>> \
>>>   -D LIBZIP_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>>>   -D LIBZIP_CONF_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>>>   -D EXPAT_LIBRARY=/usr/local/Cellar/expat/2.2.5/lib/libexpat.1.6.7.dylib
>>> \
>>>   -D EXPAT_INCLUDE_DIR=/usr/local/Cellar/expat/2.2.5/include \
>>>   -D Qt5Core_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Core \
>>>   -D Qt5Gui_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Gui \
>>>   -D Qt5Test_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Test \
>>>   -D Qt5Widgets_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Widgets \
>>>   -D Qt5Concurrent_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Concurrent
>>> \
>>>   -D Qt5OpenGL_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5OpenGL \
>>>   -D Qt5Xml_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Xml \
>>>   -D Qt5Svg_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Svg \
>>>   -D Qt5Network_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Network \
>>>   -D 
>>> Qt5PrintSupport_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5PrintSupport
>>> \
>>>   -D Qt5Positioning_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Positioning
>>> \
>>>   -D Qt5XmlPatterns_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5XmlPatterns
>>> \
>>>   -D Qt5WebKit_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5WebView \
>>>   -D Qt5UiTools_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5UiTools \
>>>   -D Qt5Sql_DIR=/usr/local

Re: [QGIS-Developer] Issues building from source on Mac - No module named PyQt5

[Carlo A. Bertelli (Charta s.r.l.)]

Hello,
I suggest to remind that using Homebrew carries in another issue. The
maintainers decided to force everyone to use Qt5 as Qt4 is deprecated by Qt
developers. Everything that was called qt5-something should become
qt-something, so everyone who uses Qt4 had to make formulas called
qt4-something for every Qt4 dependency.
This was the case even for OsGeo4Mac (
https://github.com/OsGeo/homebrew-osgeo4mac/) and Larry Shaffer had to
recreate all the needed dependencies inside this tap. If you have old Qt
dependencies inside your Homebrew, it may happen that qt-something is still
qt4-something even if brew thinks it's qt5... Feeling bewildered? So am I.
c

On Thu, Mar 8, 2018 at 4:10 PM, Timur Girgin  wrote:

> Hello everyone,
>
> I am having trouble building the QGIS release-3_0 branch on my Mac. I
> finally got it to cmake, however I am getting an error during the make
> process in which it seems that spatialite is using the system's Python(@2)
> executable to find PyQT5 when in reality it should be looking for it in the
> Python@3 executable that has been given during CMAKE. I am guessing this
> is what is causing the issue.
>
> Please find the error at the bottom of this email. If anyone knows what I
> am doing wrong, would you please let me know?
>
> Thank you very much!
> Tim
>
> Here is my CMAKE:
>
> cmake -D CMAKE_INSTALL_PREFIX=~/Downloads/QGIS-build \
>   -D CMAKE_BUILD_TYPE=MINSIZEREL -D ENABLE_TESTS=FALSE \
>   -D 
> SPATIALINDEX_LIBRARY=/usr/local/Cellar/spatialindex/1.8.5/lib/libspatialindex.4.dylib
> \
>   -D SPATIALINDEX_INCLUDE_DIR=/usr/local/Cellar/spatialindex/1.8.
> 5/include/spatialindex/\
>   -D QWT_LIBRARY=/usr/local/qwt-6.1.3/lib/libqwt.dylib \
>   -D QWT_INCLUDE_DIR=/usr/local/qwt-6.1.3/include \
>   -D BISON_EXECUTABLE=/usr/local/Cellar/bison/3.0.4_1/bin/bison \
>   -D GEOS_LIBRARY=/usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib \
>   -D GEOS_INCLUDE_DIR=/usr/local/Cellar/geos/3.6.2/include \
>   -D LIBZIP_LIBRARY=/usr/local/Cellar/libzip/1.4.0/lib/libzip.5.0.dylib \
>   -D LIBZIP_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>   -D LIBZIP_CONF_INCLUDE_DIR=/usr/local/Cellar/libzip/1.4.0/include \
>   -D EXPAT_LIBRARY=/usr/local/Cellar/expat/2.2.5/lib/libexpat.1.6.7.dylib
> \
>   -D EXPAT_INCLUDE_DIR=/usr/local/Cellar/expat/2.2.5/include \
>   -D Qt5Core_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Core \
>   -D Qt5Gui_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Gui \
>   -D Qt5Test_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Test \
>   -D Qt5Widgets_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Widgets \
>   -D Qt5Concurrent_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Concurrent
> \
>   -D Qt5OpenGL_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5OpenGL \
>   -D Qt5Xml_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Xml \
>   -D Qt5Svg_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Svg \
>   -D Qt5Network_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Network \
>   -D Qt5PrintSupport_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5PrintSupport
> \
>   -D Qt5Positioning_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Positioning
> \
>   -D Qt5XmlPatterns_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5XmlPatterns
> \
>   -D Qt5WebKit_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5WebView \
>   -D Qt5UiTools_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5UiTools \
>   -D Qt5Sql_DIR=/usr/local/Cellar/qt/5.10.1/lib/cmake/Qt5Sql \
>   -D QCA_INCLUDE_DIR=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.
> framework/Versions/2.1.3/Headers \
>   -D QCA_LIBRARY=/usr/local/Cellar/qt/5.10.1/lib/qca-qt5.
> framework/Versions/2.1.3/qca-qt5 \
>   -D LIBTASN1_LIBRARY=/usr/local/Cellar/libtasn1/4.13/lib/libtasn1.6.dylib
> \
>   -D LIBTASN1_INCLUDE_DIR=/usr/local/Cellar/libtasn1/4.13/include \
>   -D QSCINTILLA_INCLUDE_DIR=/usr/local/Cellar/qscintilla2/2.10.2_1/include
> \
>   -D QSCINTILLA_LIBRARY=/usr/local/Cellar/qscintilla2/2.10.2_1/
> lib/libqscintilla2_qt5.13.1.0.dylib \
>   -D QTKEYCHAIN_INCLUDE_DIR=/usr/local/Cellar/qtkeychain/0.8.0/include \
>   -D 
> QTKEYCHAIN_LIBRARY=/usr/local/Cellar/qtkeychain/0.8.0/lib/libqt5keychain.0.8.0.dylib
> \
>   -D 
> SPATIALITE_LIBRARY=/usr/local/Cellar/libspatialite/4.3.0a_6/lib/mod_spatialite.7.dylib
> \
>   -D SPATIALITE_INCLUDE_DIR=/usr/local/Cellar/libspatialite/4.3.0a_6/include
> \
>   -D SQLITE3_LIBRARY=/usr/local/Cellar/sqlite/3.22.0/lib/libsqlite3.0.dylib
> \
>   -D PYTHON_EXECUTABLE=/usr/local/bin/python3 \
>   -D 
> PYTHON_INCLUDE_PATH=/usr/local/Frameworks/Python.framework/Versions/3.6/Headers
> \
>   -D PYTHON_LIBRARY=/usr/local/Frameworks/Python.framework/Versions/3.6/Python
> \
>   -D WITH_QTWEBKIT=FALSE \
>   ..
>
> Which outputs:
>
> -- QGIS version: 3.0.0 Girona (3)
> -- Could not find GRASS 7
> -- Found Proj: /Library/Frameworks/PROJ.framework
> -- Found GEOS: /usr/local/Cellar/geos/3.6.2/lib/libgeos.dylib (3.6.2)
> -- Found GDAL: /usr/local/Cellar/gdal2/2.2.3/lib/libgdal.dylib (2.2.3)
> -- Found Expat: 

Re: [QGIS-Developer] Separate namespaces for QGIS-LTR and QGIS (3)

[Carlo A. Bertelli (Charta s.r.l.)]

Sorry for rewinding the thread to where it started.
Provided that users can benefit from keeping the last stable release and an
LTR both installed, do you think that this is up to the specific platform
to handle this (OsGeo4W does it already) or a more general solution can be
provided?
The LTR will be on version 2 for several months, so I suggest the libraries
could use a different namespace. Is this an acceptable solution? Are there
alternatives.
c


On Sun, Mar 4, 2018 at 12:13 PM, Nathan Woodrow <madman...@gmail.com> wrote:

> Hey Carlo,
>
> I guess we are a bit confused at the moment because the goal of QGIS has
> never really been that at all, at least not post v1.  We have always aimed
> to make it the best it can be for a lot of different workflows.
>
> I'm not sure I would consider anything in QGIS a step backwords at all,
> There has been a crazy, and I mean crazy, amount of dev work to create a
> better product for end users.
>
> - Nathan
>
> On Sun, Mar 4, 2018 at 6:21 PM, Carlo A. Bertelli (Charta s.r.l.) <
> carlo.berte...@gmail.com> wrote:
>
>> No pun intended, when you announced what you were going to do, I used
>> MapInfo as my main GIS and Thuban as a viewer and I hoped very much you
>> were starting something that was went further.
>> Since version 0.11 I was using QGIS as my "main" GIS. What I was saying
>> is that the continuous improvement made all users rely on a dependable
>> QGIS. Departing from a cautious approach to a very fast development pace
>> means users can keep an LTR for day to day working (no advanced needs) and
>> an "evolution" approach for the advanced features. I didn't think that
>> saying "viewer" I diminished the huge effort of these years. The "viewer"
>> approach is still a plus of QGIS and it's not something easy to accomplish
>> if I see the work on Processing and what has been done for GRASS. I think
>> being a "viewer" for GDAL means getting all of the benefits of an evolving
>> project. This has its drawbacks, some processing that is needed at the
>> feature level was available only on layers as a whole. I meant that, the
>> last major version is a further step that asks for more dependability.
>> My apologies for all the developers who felt injured by my words.
>> c
>>
>> On Sun, Mar 4, 2018 at 12:04 AM, Tim Sutton <t...@kartoza.com> wrote:
>>
>>> Hi
>>>
>>> On 03 Mar 2018, at 20:43, Jürgen E. Fischer <j...@norbit.de> wrote:
>>>
>>> Hi,
>>>
>>> On Sat, 03. Mar 2018 at 12:43:00 +0100, Carlo A. Bertelli (Charta
>>> s.r.l.) wrote:
>>>
>>> but also abandoned the idea of QGIS as a simple viewer that acquires
>>> editing
>>> abilities by plugins.
>>>
>>>
>>> Was that ever a goal?  If so, I didn't know - but I have been around
>>> only for a
>>> bit more than 10 years ;)
>>>
>>>
>>> Yeah I think the idea of being a full fledged GIS rather than a simple
>>> viewer has been with us for many years already….glad to see it is really
>>> taking hold with 3.0 though :-) Great to have your inputs Carlo.
>>>
>>> Regards
>>>
>>> Tim
>>>
>>>
>>>
>>> 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
>>> http://www.norbit.de
>>> QGIS release manager (PSC)  GermanyIRC: jef on
>>> FreeNode
>>> ___
>>> 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
>>>
>>>
>>>
>>>
>>> ---
>>>
>>> *Tim Sutton*
>>> QGIS Project Steering Committee Chair
>>> t...@qgis.org
>>>
>>
>> --
>> 
>> --
>> Carlo A. Bertelli
>>Charta servizi e sistemi per il territorio e la storia ambientale srl
>>   Dipendenze del palazzo Doria,
>>   vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
>>   tel./fax +39(0)10 2475439  +39 0108566195 <010%20856%206195>
>> mobile:+39 393 1590711 <393%20159%200711>
>>  

Re: [QGIS-Developer] Discussing qgd files

[Carlo A. Bertelli (Charta s.r.l.)]

A disruptive "moreover approach" suggests some reflection about the file
 database approach.

I see several places where handling metadata in the database could provide
a better but possibly conflicting solution.
This happens for instance with styles stored on the database that may
easily be overwritten by opening a modified project (if you work alone it's
wonderful, but cooperating is a nightmare), but may happen also with any
other "intelligent" provision that uses XML and/or persistent storage.

I think this should not prevent a good solution about metadata. A map is
not made of several layers overlaid with their styles only, it's something
more and it's not completely satisfactory to reduce this to a project file
that helps a single user to keep working on it or store the printing styles
(sorry, I simplify too much, I know). Maybe QGD files are a starting point
to design a better solution because we are embracing a three level storage
system: files, light database (SQLite/Spatialite), DBMS (mainly
PostgreSQL/PostGIS, but even others). This solution could lead us to a
careful choice or to more flexibility (complexity?).

Maybe this further flexibility is needed. I raise a very peculiar case: we
work with historical maps and sometimes I georeference maps without being
certain about my sources, sometimes the source itself is made of parts that
ask two set of conflicting reference points for the same file. I'm forced
to make a symlink on the filesystem to have the same file georeferenced in
two ways. Why the different point sets cannot be stored on database? The
reference points are points on earth and frequently I need to reuse them
(what about adjacent tables? Maybe snapping on them could help), why not
storing them in the database?

QGIS Server is an amazing tool, but why using monolithic and completely
proprietary XML file while several other applications could benefit from
more generic metadata stored in the database? That is already done for
styles which store SLD values besides the Qt ones, but it could be extended
to other areas.

It's reasonable to blame my "moreover approach", but take what you think
QGIS could benefit of.
c

-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Separate namespaces for QGIS-LTR and QGIS (3)

[Carlo A. Bertelli (Charta s.r.l.)]

No pun intended, when you announced what you were going to do, I used
MapInfo as my main GIS and Thuban as a viewer and I hoped very much you
were starting something that was went further.
Since version 0.11 I was using QGIS as my "main" GIS. What I was saying is
that the continuous improvement made all users rely on a dependable QGIS.
Departing from a cautious approach to a very fast development pace means
users can keep an LTR for day to day working (no advanced needs) and an
"evolution" approach for the advanced features. I didn't think that saying
"viewer" I diminished the huge effort of these years. The "viewer" approach
is still a plus of QGIS and it's not something easy to accomplish if I see
the work on Processing and what has been done for GRASS. I think being a
"viewer" for GDAL means getting all of the benefits of an evolving project.
This has its drawbacks, some processing that is needed at the feature level
was available only on layers as a whole. I meant that, the last major
version is a further step that asks for more dependability.
My apologies for all the developers who felt injured by my words.
c

On Sun, Mar 4, 2018 at 12:04 AM, Tim Sutton <t...@kartoza.com> wrote:

> Hi
>
> On 03 Mar 2018, at 20:43, Jürgen E. Fischer <j...@norbit.de> wrote:
>
> Hi,
>
> On Sat, 03. Mar 2018 at 12:43:00 +0100, Carlo A. Bertelli (Charta s.r.l.)
> wrote:
>
> but also abandoned the idea of QGIS as a simple viewer that acquires
> editing
> abilities by plugins.
>
>
> Was that ever a goal?  If so, I didn't know - but I have been around only
> for a
> bit more than 10 years ;)
>
>
> Yeah I think the idea of being a full fledged GIS rather than a simple
> viewer has been with us for many years already….glad to see it is really
> taking hold with 3.0 though :-) Great to have your inputs Carlo.
>
> Regards
>
> Tim
>
>
>
> 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 http://www.norbit.
> de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> ___
> 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
>
>
>
>
> ---
>
> *Tim Sutton*
> QGIS Project Steering Committee Chair
> t...@qgis.org
>

-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195 <010%20856%206195>
mobile:+39 393 1590711 <393%20159%200711>
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Separate namespaces for QGIS-LTR and QGIS (3)

[Carlo A. Bertelli (Charta s.r.l.)]

@Nathan: Yes, to be precise, I mean calling using a different name, say
qgis2 or qgis_ltr and using /usr/lib/libqgis2* instead
of /usr/lib/libqgis*, /usr/lib/qgis2 or /usr/lib/qgis-ltr,
/usr/share/qgis2, /usr/include/qgis2 instead of /usr/include/qgis,

@Richard: That's very good, I overlooked this feature. Anyway, I think the
casual user will never know and while working perfectly on the repository,
it needs two separate directory, say .qgis2 and .qgis3. Not difficult but
it should be easier for users to deal with these issues.

Anyway, thanks for considering this suggestion.
c

On Sat, Mar 3, 2018 at 1:16 PM, Richard Duivenvoorde <rdmaili...@duif.net>
wrote:

> On 03-03-18 12:43, Carlo A. Bertelli (Charta s.r.l.) wrote:
> > From a user's point of view, having a tried and dependable LTR is an
> > important feature.
> > The new main version has finally addressed the needed upgrade of python
> > (2->3) and Qt (4->5) but also abandoned the idea of QGIS as a simple
> > viewer that acquires editing abilities by plugins. Plugins are not
> > anymore needed for several tasks and require sometimes a major upgrade,
> > because of the transition to python 3.
> > As the road map shows that the LTR version will rely on version 2 for a
> > fairly long time, what about letting it live in a separate namespace as
> > to let the two versions coexist, keeping the needed version 2 plugins
> > for the LTR?
>
> Not sure if you would call it a 'namespace', but by using the right
> values for
> *qgisMinimumVersion*
> and
> *qgisMaximumVersion*
> the plugins.qgis.org site can host both plugin versions at the same time.
>
> Personally I host one of my plugins separate for the 2.x branch and 3.x
> branch.
>
> If you use
> qgisMinimumVersion=3.0
> qgisMaximumVersion=3.99
> your plugin will only be visible in 3.x
>
> qgisMinimumVersion=2.0
> qgisMaximumVersion=2.99
> makes it only visible in 2.x
>
> both versions can coexist on plugins.qgis.org
>
> Regards,
>
> Richard Duivenvoorde
>
>
On Sat, Mar 3, 2018 at 12:45 PM, Nathan Woodrow <madman...@gmail.com> wrote:

> Hi,
>
> I'm not sure what you mean. Could you explain with an example.
>
> Regards,
> Nathan
>
>
-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195 <010%20856%206195>
mobile:+39 393 1590711 <393%20159%200711>
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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] Separate namespaces for QGIS-LTR and QGIS (3)

[Carlo A. Bertelli (Charta s.r.l.)]

>From a user's point of view, having a tried and dependable LTR is an
important feature.
The new main version has finally addressed the needed upgrade of python
(2->3) and Qt (4->5) but also abandoned the idea of QGIS as a simple viewer
that acquires editing abilities by plugins. Plugins are not anymore needed
for several tasks and require sometimes a major upgrade, because of the
transition to python 3.
As the road map shows that the LTR version will rely on version 2 for a
fairly long time, what about letting it live in a separate namespace as to
let the two versions coexist, keeping the needed version 2 plugins for the
LTR?
c

-- 
--
Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
  Dipendenze del palazzo Doria,
  vc. alla Chiesa della Maddalena 9/2 16124  Genova (Italy)
  tel./fax +39(0)10 2475439  +39 0108566195 <010%20856%206195>
mobile:+39 393 1590711 <393%20159%200711>
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
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