Re: [QGIS-Developer] QGIS WebSocket

[Nathan Woodrow via QGIS-Developer]

Hi,

You can use the QWebSocket (https://doc.qt.io/qt-6/qwebsocket.html) object
to do this.  Ships with Qt and QGIS.  I did some R with it a while ago
and it worked well.

- Nathan

On Sat, 13 May 2023 at 19:48, Nzikou, Michel via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi dev folks,
>
> I am working on creating a connection between my exp plugin and server via
> a WebSocket connection for data transferring. So my question is about
> whether QGIS has a WebSocket feature/ connect algorithm.
>
> Thanks
>
>
> *Michel Nzikou, Ph.D.*
> ASEG WA - President
> *-*
> ___
> QGIS-Developer mailing list
> 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] Slow downloads for LTR MSI

[Nathan Woodrow via QGIS-Developer]

Hey,

Well I am downloading from Australia but not sure what mirror it is using
as I'm just grabbing the LTR off the site, even the osgeo4w installer is
very slow.  But everytime I do the download speeds are very very poor.  At
times it is down to 14kb/s.  I don't remember having this issue in the past
but others have said it has been bad for a long while now.

I thought we had a CDN in front of this in order to help distribution?

It seems to be quite a problem here.  We have had multi people report it as
a issue and it doesn't look good.

I'm happy to have a look at whatever we need to do in order fo speed it
up.   If we need a CDN I can talk to work about using our AWS setup with
CloudFront to get much better speeds and see if we will cover it.

I don't know how much out going data it would be but CloudFront is cheap if
we put the downloads into S3 and serve it from there.

Regards
Nathan

On Wed, 20 Jul 2022, 6:19 pm Jürgen E. Fischer via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hi,
>
> On Wed, 20. Jul 2022 at 09:44:26 +1000, Nathan Woodrow via QGIS-Developer
> wrote:
> > I seem to be getting really slow downloads of the MSI packages (haven't
> > tested any other packages at the moment) from the main download page.
>
> It's redirected to several hosts - independant of the origin address.  So
> you
> might get better results just by retrying.  Where did you actually download
> from?  US (download.osgeo.org, ftp.osuosl.org; Oregon State, US) or Europe
> (qgis.org, norbit.de; both at Hetzner in Germany)?
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden
> https://www.norbit.de
> QGIS release manager (PSC)  Germany IRC: jef on Libera|OFTC
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Slow downloads for LTR MSI

[Nathan Woodrow via QGIS-Developer]

Hey all,

Been a while :)

I seem to be getting really slow downloads of the MSI packages (haven't
tested any other packages at the moment) from the main download page.

Slow as in 40+ mins for 1GB, and the download speed fluctuates quite a
lot.  This isn't a local internet issue for me as I have confirmed with
others on different connections that it's the same and we are all on
100mbps+.

I recall this used to be cached on a CDN to make it quicker is that not the
case anymore?

Regards,
Nathan
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] URGENT AS CAN BE: QGIS 3.16.12 and sip 6?

[Nathan Woodrow]

My download of 3.16.12 is using SIP 5.4.0 it says:

[image: image.png]

On Wed, Nov 3, 2021 at 10:35 AM Nyall Dawson  wrote:

> Hi all,
>
> Question: was QGIS 3.16.12 for Windows released using a sip version 5
> or 6? If so, we need to pull this release ASAP and put out a public
> retraction notice -- it will have completely broken Processing and
> result in risk of deadlocks when running any Python based processing
> algorithm.
>
> See description in
> https://github.com/qgis/QGIS/pull/45128#issuecomment-958529173
>
> I CANNOT OVERSTATE HOW DAMAGING THIS REGRESSION IS (if indeed it has
> slipped into the LTR Windows release builds)
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS Roadmap

[Nathan Woodrow]

It's done. Finally done! Good work team. When do we get rich?

On Fri, 11 Dec 2020, 6:45 pm Matthias Kuhn,  wrote:

> Hi
>
> I just checked the roadmap page (
> https://qgis.org/en/site/getinvolved/development/roadmap.html) and it
> seems we are approaching the end of days of QGIS in February with the
> release 3.18.0.
> Do I interpret this correctly that QGIS is now officially feature complete
> and does not require any more releases?
>
> Thanks :-)
> Matthias
> ___
> QGIS-Developer mailing list
> 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] sudden performance issues with my QGIS installation

[Nathan Woodrow]

I think it would better spent looking into why and fixing that and not just
bidding it and removing quite good feature we want people to use if we
can.  The browser is quite powerful and bidding it by default would be a
bit of a shame.

Suspect we might just have to get creative with how to handle the file
loading, they should already be done in background threads but maybe
something more is needed

On Tue, 1 Dec 2020, 10:59 pm Jeff McKenna, 
wrote:

> Hi Andreas,
>
> As a user, I wonder (out loud) if the Browser Panel should be hidden by
> default, in future QGIS versions.  This would avoid this common issue of
> slowing down QGIS for new users, and give the new user a guaranteed
> positive QIGS first-use experience.  Has there been any discussion on
> this possibility?  I was surprised to read here that it is the opposite
> case, where devs are promoting use of the browser panel more and more.
>
> I just thought that I'd share my longtime-user opinion, and hopefully
> not sound too negative.  I just feel disabling the browser panel by
> default would prevent so many issues for new users (and the advanced
> users can turn it on for their use when they need it).  So, benefit the
> new users, and cause the devs an extra button click to enable :)
>
> Related: when I give QGIS training, it is the first thing I instruct, to
> close the browser panel as it causes network issues often.
>
> thanks,
>
> -jeff
>
>
>
> --
> Jeff McKenna
> MapServer Consulting and Training Services
> co-founder of FOSS4G
> http://gatewaygeo.com/
>
>
>
>
>
> On 2020-12-01 7:22 a.m., Andreas Neumann wrote:
> > Hi Dimitris,
> >
> > Interesting, thanks for confirming.
> >
> > It is not the first time I hear that the Browser Panel is slowing down
> > QGIS too much (even bringing it to a halt almost).
> >
> > Now it would be interesting to find out, what, in the browser in your
> > situation is the culprit. Is it network drives, databases, services? My
> > first guess would be the network drives.
> >
> > This is kind of problematic, as the QGIS devs are more and more
> > promoting usage of the browser panel (and it is quite useful and
> > comfortable), but if it is a potential source of slow down ... I don't
> > know if it is so wise to promote the browser so much. Or at least we
> > should be more conservative on scanning folders by default.
> >
> > Andreas
> >
> > On 2020-12-01 12:09, Dimitris Kar wrote:
> >
> >> Hello Andrea,
> >> You were right! Amazing. This fixed the performance issues!
> >>
> >> On Mon, Nov 30, 2020 at 2:08 PM Andreas Neumann  >> > wrote:
> >>
> >> Hi Dimitris,
> >>
> >> Just a shot in the dark: does it help if you close the "Browser"
> >> panel. Sometimes the browser (esp. with network drives) can slow
> >> down QGIS considerably.
> >>
> >> Maybe worth a try.
> >>
> >> Andreas
> >>
> >> Am 30.11.20 um 12:07 schrieb Dimitris Kar:
> >>> Hello all,
> >>> I am facing some performance issues lately with QGIS. I have been
> >>> using QGIS3.14 since the last six months (Windows 10) without any
> >>> problems. It was always very fast in any type of analysis.
> >>> Suddenly it stopped responding. Sometimes it lags for a minute or
> >>> more while performing simply tasks (load layer, save layer as
> >>> geojson etc.).
> >>> I have tried to uninstall, delete the registry and the plugins
> >>> and reinstall it but the issues perform. I have tried the newer
> >>> version (3.16) and the older one (3.10) but I still get the same
> >>> performance issues. I have also trired to run it with a new
> >>> profile and without any plugins. When running it with no plugins
> >>> it launches faster but then I get the same lag issues when
> >>> loading layers or running simply analysis (buffer)
> >>> Do you have any idea what could be causing this? I was wondering
> >>> if some other software that I have installed recently could have
> >>> created an issue.
> >>> Thanks
> >>> Dimitris
> >>>
> >>> ___
> >>> QGIS-Developer mailing list
> >>> QGIS-Developer@lists.osgeo.org   QGIS-Developer@lists.osgeo.org>
> >>> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 
> >>> Unsubscribe:
> https://lists.osgeo.org/mailman/listinfo/qgis-developer  <
> https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org  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] Online Q plus discussion session - QEP 179 (Turning Plugin Management into Actual Package Management)

[Nathan Woodrow]

I will try and join this as well if I can.   Haven't had a chance to finish
reading the QEP but will catch up on it before the meeting.

On Wed, Jun 3, 2020 at 8:13 AM Nyall Dawson  wrote:

> On Wed, 3 Jun 2020 at 02:23, Sebastian M. Ernst 
> wrote:
> >
> > Hi all,
> >
> > there is a bit of a consensus building towards tomorrow, Wednesday, June
> > 3rd, 14:00 CEST.
> >
> > @Nyall: You also participated in the discussion on GitHub and I do not
> > want to exclude you. This should be 22:00 AEST on the same day. If you
> > want to join: Does this work for you?
>
> Thanks for the consideration, it's much appreciated! I'll try to
> attend, but don't delay starting the meeting if I not present (it'll
> depend on family commitments which I can't confirm in advance,
> sorry...)
>
> Nyall
>
>
> >
> > I am going to try to send an open invitation via this mailing list.
> >
> > Best regards,
> > Sebastian
> >
> >
> > Am 02.06.20 um 10:48 schrieb Sebastian M. Ernst:
> > > Hi all,
> > >
> > > this is a friendly reminder: I am trying to organize an online
> > > discussion session on QEP 179. If you are interested in joining, please
> > > let me know what times fit best.
> > >
> > > https://terminplaner4.dfn.de/wulb19ehAr8rSv9W
> > >
> > > Best regards,
> > > Sebastian
> > >
> > >
> ___
> QGIS-Developer mailing list
> 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] Getting changelog ready for 3.14

[Nathan Woodrow]

Hey Tim,

Myself and Andrew from Chartis Technology have some work time this week we
can spend on helping a bit. Not sure what day yet but will fit a few hours
in between other tasks.

- Nathan

On Sun, 24 May 2020, 7:40 am Tim Sutton,  wrote:

> Hi
>
>
> On 23 May 2020, at 13:52, Richard Duivenvoorde 
> wrote:
>
> On 5/22/20 5:03 PM, Tim Sutton wrote:
>
> Hi
>
> Toto: I re-ingested the Changelog entries now.
>
> Richard: For the entry images that are linked to GitHub embedded images
> we either need to import them over or just link out to them in the
> generated RST. If you tell me which you prefer I will ask Anita Hapsari
> to help make that happen before the release.
>
>
> Hi Tim,
>
> I think I prefer these images IN the export. Then at least the 'old' way
> will just work.
>
> If that is in place I can have a further look at using for example
>
> https://github.com/sphinx-contrib/images
>
> Or if that fails (as it does now with me), then I can have a look at
> generating thumbnails myself and add some ::target to them to the real
> image or so
>
> I also tested current export, and besides the usual little hick-ups
> (because of content of the items) there are some new bigger ones, of
> which I created issues:
>
> https://github.com/kartoza/prj.app/issues/1186
> https://github.com/kartoza/prj.app/issues/1187
> https://github.com/kartoza/prj.app/issues/1188
> https://github.com/kartoza/prj.app/issues/1189
>
> It would be great if Anita could find some time before the release to
> have a look into these.
>
>
>
> Ah great, thanks for filing those. @anita can you take a look through
> those?
>
> @Frank last release you were wanting to help out with the changelog - will
> be great if you are available to pitch in.
>
> @Richard for now I think I will manually just move the images into the
> entries which should fix the issues with embedded images.
>
> Regards
>
> Tim
>
>
> TIA & regards,
>
> Richard Duivenvoorde
>
>
>
> —
>
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> 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
>
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
>
> ___
> QGIS-Developer mailing list
> 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] Profiler?

[Nathan Woodrow]

Correct. QgsRuntimeProfiler is the tool that can do it.

https://qgis.org/api/classQgsRuntimeProfiler.html

In Python you can access it using this:

 QgsApplication.instance().profiler()

An example:

   QgsApplication.instance().profiler().start("my_thing")
# long expensive stuff
 QgsApplication.instance().profiler().end()



On Sat, May 23, 2020 at 9:38 PM Richard Duivenvoorde 
wrote:

> On 5/23/20 11:42 AM, Sebastian M. Ernst wrote:
>
> > @Richard How does your Citrix setup / architecture look like
> > (approximately)?
>
> I'll ask around for more details, as I'm there just as a user of that
> setup.
>
> But I did try a lot of things: and exactly what you tell: their virus
> scanner was pushing some hash version of all python files to some online
> service. So I disabled it...
> But still... And off course they are working with some network shares,
> so I will try out some of your other idea's
>
> > @Nathan & @Nyall Where in QGIS' source can I find the profiling tool? I
> > just searched and could not locate it ... Would you consider adding
> > support for a Python profiler to it, e.g. [1], [2] or [3]? The relevant
> > code could (conditionally) be injected somewhere around here [4] or here
> > [5]. I have played with this idea a while ago. It works in principle,
> > but a proper integration into your GUI would be great ...
>
> In my debug build, using
> export QGIS_DEBUG=5
>
> I see:
>
> ../src/core/symbology/qgssymbollayerutils.cpp:3936 :
> (svgSymbolNameToPath) [0ms] Svg found in alternative path
> ../src/core/qgsruntimeprofiler.cpp:80 : (end) [0ms] PROFILE: Load
> default style database/Load symbols/topo camp - 0.001
> ../src/core/qgsruntimeprofiler.cpp:80 : (end) [0ms] PROFILE: Load
> default style database/Load symbols/topo foot - 0
> ../src/core/qgsruntimeprofiler.cpp:80 : (end) [0ms] PROFILE: Load
> default style database/Load symbols/topo forest - 0
>
> So:
> https://github.com/qgis/QGIS/blob/master/src/core/qgsruntimeprofiler.cpp
> :-)
>
> Regards,
>
> Richard Duivenvoorde
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Exe size mismatch

[Nathan Woodrow]

The same thing just depends on the build options.  For the windows nightly
builds, you will end up with stuff like qgis-dev-bin.exe  and qgis-bin.exe
depending on what versions you have installed.  I started the work Jurgen
finished it off for me.

Like Andreas said the size difference is simply the different build
options, one thing different and it's going to be different.

The Could not load qgis_app.dll normally means it can't find something that
qgis_app.dll is needing to load, could be Qt, could be GDAL or anything
that is loaded really.  It's a tricky one to debug and I have never run the
package scripts for QGIS on Windows so can't help there sorry.

- Nathan

On Mon, May 4, 2020 at 10:23 PM Régis Haubourg 
wrote:

>
> Hi,
> qgis.exe and qgis-bin.exe are not the same beasts. Qgis.exe is a wrapper
> for the real exe file, passing additional .var values to the exe.
> IIRC it was done by Nathan to allow QGIS to be pinned in Windows taskbar
> correctly.
>
> Please correct me if I am wrong
>
> Le lun. 4 mai 2020 à 14:12, Sachin Kumar  a écrit :
>
>> I have compiled on MSVC 2015, Windows 10. Till compile and install as in
>> C:/OSGeo4w/apps/qgis-test and run successful from cmd prompt.
>>
>> When I tried to package it using perl creatensis.pl, it gives error
>> qgis_app.dll
>>
>> Error loading QGIS
>> Oops, looks like an error loading QGIS
>> Details:
>> Could not load qgis_app.dll
>> Windows Error: The specified module could not be found.
>> Help:
>> Check C:\Program Files\QGIS 3.12\bin\qgis-bin.env for correct environment
>> paths
>>
>> What could be wrong?
>>
>> Regards
>> Sachin
>>
>> On Mon 4 May, 2020, 3:21 PM Andreas Neumann,  wrote:
>>
>>> Hi Sachin,
>>>
>>> You probably used different compile options and then it would be logical
>>> to me that the size of the exe is slightly different.
>>>
>>> Why do you worry?
>>>
>>> Andreas
>>> Am 04.05.20 um 11:48 schrieb Sachin Kumar:
>>>
>>> Hi, I am compiling QGIS 3.12 successfully. It is notice that my qgis.exe
>>> size 196KB where as when I installed QGIS 3.12 x64, its qgis-bin.exe size
>>> is 111KB.
>>>
>>> Any reason?
>>>
>>> Regards
>>> Sachin
>>>
>>> ___
>>> 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
>>
>> ___
>> QGIS-Developer mailing list
>> 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] [RoadMap] Dates Versions Release Calendar

[Nathan Woodrow]

Yes, please! That would be super handy.

I have also though about a display like this
[image: image.png]



On Mon, Apr 27, 2020 at 1:41 PM Nyall Dawson  wrote:

> On Sun, 26 Apr 2020 at 06:27, João Gaspar 
> wrote:
> >
> > Hi devs,
> > it is possible or integrate the roadmap of releases in a shared calendar?
> >
> > The idea is to receive in the Calendar the releases dates through
> calendar notifications to easily manager test and deploy QGIS releases
> >
> > I don't know if this make sense please let me know if I need to clarify
> more this subject.
>
> This would be GREAT!
>
> Nyall
>
> >
> > Best regards,
> > João Gaspar
> > ___
> > QGIS-Developer mailing list
> > 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] libprotobuf-lite.dll dependency QGIS-dev osgeo4w?

[Nathan Woodrow]

Thanks for the fixes :)

On Sat, 11 Apr 2020, 8:34 am Jürgen E. Fischer,  wrote:

> Hi Richard,
>
> On Thu, 09. Apr 2020 at 16:30:00 +0200, Richard Duivenvoorde wrote:
> > Is this a missing dependency maybe?
>
> Was. ;)
>
> > Or is it an artifact because of the manual updates?
>
> No.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden
> https://www.norbit.de
> QGIS release manager (PSC)  GermanyIRC: jef on FreeNode
> ___
> QGIS-Developer mailing list
> 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] Geopackage FID columns: i HATE them!!!!

[Nathan Woodrow]

I agree.

If there is an ID that is used internally as a unique primary key it should
never be shown to the user. It should not be expected to be edited outside
of the provider's control or be stable between edits.

If you need a stable ID for reference you should make your own {{insert
rant about people wanting to use increating ints as a reference ID}}

On Thu, Mar 19, 2020 at 4:04 PM Nyall Dawson  wrote:

> Hi list,
>
> Just wondering what everyone's thoughts are about geopackage FID
> columns. Personally, I find them an absolute nightmare to deal with,
> resulting in annoying (and dangerous) issues when trying to save
> geopackage edits, such as
> - field type issues: converting certain formats to geopackage fails,
> because existing fields with name "fid" are of an incompatible type
> with geopackage. Solution: manually uncheck the "fid" field from the
> "save as" dialog.
> - unique constraint violations: we've mostly fixed this in processing,
> but it's still unfortunately really common to get failures when saving
> edits to geopackage because some operation has resulted in duplicate
> fids. This can be a nightmare to fix, if it's even possible to do so.
>
> I personally HATE HATE HATE these columns, and would rather I never
> saw them ever again. Does anyone else feel the same? If so, could we
> potentially just permanently hide these columns from QGIS and avoid
> all these dangerous issues for users?
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Reporting security related issues ?

[Nathan Woodrow]

Could I get added to that one please Richard. Thanks.

Nathan.

On Wed., 12 Feb. 2020, 10:19 pm Richard Duivenvoorde, 
wrote:

> FYI: I've just created an email(group) address for this:
>
> secur...@qgis.org
>
> Emails to that address will be forwarded to PSC members and members of
> admin-group.
>
> If individuals/core-members want to be added, please let me know so I
> can add you to that group.
>
> Regards,
>
> Richard Duivenvoorde
>
> On 12/02/2020 09.00, Paolo Cavallini wrote:
> > Hi,
> > generally here. If you think it is a grave vulnerability you can send it
> > privately to any PSC member or major QGIS developer (you can check on
> > GitHub for recent activity).
> > Thanks!
> >
> > Il 11/02/20 19:56, security minded ha scritto:
> >> Hello,
> >>
> >> What is the best way to report security issues affecting QGIS ?
> >>
> >> Thanks
> >>
> >> OSSSecurityMinded
> >>
> >> ___
> >> QGIS-Developer mailing list
> >> 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] Compliments

[Nathan Woodrow]

Hey Patrick,

Thanks for the kind words.  Great to see you are able to use it make
something worthwhile for yourself and others to enjoy.Do you have a
link to the maps so we can share them out?

I'm not sure what conflicts you refer to but I am assuming it was with good
intentions and maybe out of some frustration which we can all run up again
at times.

Regards,
Nathan

On Mon, Feb 10, 2020 at 10:44 PM Patrick Dunford 
wrote:

> Good day to all
>
> I wish to record my overwhelming gratitude to this software project as I
> have been a user of this software QGIS over the past 8 years since
> version 1.8. During that period I have been working on developing
> historical hobby maps covering a large part of the country of New
> Zealand and making extensive use of freely downloadable map resources
> which are available there.
>
> I have just completed the first volume of a series, containing just over
> 1000 individual maps which are published online for free access. Each of
> those maps has to be individually generated and checked from the layout
> composer. There are still another 11 volumes of a similar size to be
> produced in the series which should take roughly 11 months (for the rest
> of this year).
>
> None of this could have been achieved without the use of the Qgis
> software and I must especially record my appreciation that it is free
> software as this project could not have happened at all a few years ago
> considering the large volume of resources involved and the expense all
> round that would have been incurred given the commercial value of all
> the resources (my personal income at present being less than NZ$20,000 pa).
>
> It has been of considerable personal regret to me that a certain level
> of conflict did arise during the period that I was using the 2.99
> development edition of the software and I hope it will be possible for
> developers to accept this apology for those situations. Unfortunately I
> do not have the time these days to run the development edition for
> testing and have yet to master the new bug reporting system so you have
> not heard from me in a while anyways.
>
>
> ___
> QGIS-Developer mailing list
> 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] Fwd: Urgent: Remove windows 3.10.2 installer from site

[Nathan Woodrow]

Very much agree. Thanks for taking it on

On Tue., 21 Jan. 2020, 12:57 pm Mathieu Pellerin, 
wrote:

> Sure, I can draft something by the end of the day.
>
> On Tue, Jan 21, 2020 at 9:56 AM Paolo Cavallini 
> wrote:
>
>> Fully agreed. Mathieu, would you like to write it?
>> Thanks.
>>
>> On 21 January 2020 06:39:08 GMT+04:00, Mathieu Pellerin <
>> nirvn.a...@gmail.com> wrote:
>>>
>>> +100 on all that's been said here.
>>>
>>> Also, once 3.10.2 is updated to include the updated packages &
>>> above-referred fix, I'd suggest writing a QGIS.org blog post to inform
>>> users of the worthiness of updating to 3.10.2(.2) *ASAP*, and expand a bit
>>> on why 3.10.0/.1 were such rough releases. We can finish the post by
>>> thanking users that have reported bugs (an inevitable nightmare to go
>>> through as QGIS was exposing brand new GDAL3/PROJ6 versions to the masses).
>>> IMHO, we should not skip this communication to our users.
>>>
>>> On Tue, Jan 21, 2020 at 7:27 AM Nyall Dawson 
>>> wrote:
>>>
 Also, we better wait for a fix for
 https://github.com/qgis/QGIS/issues/33902 (incoming)...

 Gosh, will the nightmare ever end... Let's agree never to change
 anything in gdal or proj or qgis ever again ;)

 Nyall


 -- Forwarded message -
 From: Nyall Dawson 
 Date: Tue, 21 Jan 2020 at 06:28
 Subject: Urgent: Remove windows 3.10.2 installer from site
 To: qgis-developer 


 Can we please remove the 3.10.2 installer from the website as a matter
 of urgency? This installer was released using the older gdal 3.0.2 and
 proj 6.2 versions, which directly lead to crashes and reprojection
 failures in QGIS.

 QGIS SHOULD NEVER EVER*** be
 used with gdal >= 3 and gdal < 3.0.3 or proj >6 and proj < 6.3.0.

 This combination is a world of hurt for users :(

 Tickets filed at https://trac.osgeo.org/osgeo4w/ticket/618, and
 https://trac.osgeo.org/osgeo4w/ticket/617, and later today I'm going
 to commit cmake blocks which will completely prevent compilation under
 the affected gdal/proj versions.

 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
>>>
>>>
>> --
>> Please excuse my brevity.
>>
> ___
> QGIS-Developer mailing list
> 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] osgeo4w's qgis-dev package broken, proj_7_0.dll missing

[Nathan Woodrow]

Great work!  Thanks for all your hard work Jürgen it's really appreciated.

On Fri, Dec 6, 2019 at 9:06 AM Nyall Dawson  wrote:

> On Fri, 6 Dec 2019 at 07:54, Jürgen E. Fischer  wrote:
> >
> > Hi,
> >
> > On Thu, 05. Dec 2019 at 11:22:35 +, Pedro Venâncio wrote:
> > > But I believe that should be fixed in the next build.
> >
> > Yes, the rebuild has picked the new proj up.
> >
> > Rhere also a new qgis-ltr now - and new standalones for 3.4.13.
> >
> > As that also required updates to the build scripts in the release branch
> -
> > tomorrows 3.4.14 should be almost the same - except for some
> translations…
>
> Testing 3.4.13, it looks like you've successfully found a solution to
> use gdal < 3 and proj < 6 for the 3.4 build?
>
> Great work!!
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Nathan Woodrow]

Just have to make sure we communicate this via the blog and why.

On Thu, Nov 28, 2019 at 10:38 AM Mathieu Pellerin 
wrote:

> +1 to end 3.4 cycle a few months early too.
>
> On Thu, Nov 28, 2019, 05:57 Nathan Woodrow  wrote:
>
>> +1 on dropping support early as the risk is large on breaking the users
>> experience with a LTR
>>
>> On Thu., 28 Nov. 2019, 8:55 am Even Rouault, 
>> wrote:
>>
>>> > I think the issues are deeper then the crashes/projection failures
>>> > fixed by the GDAL/proj cherry-picked commits.
>>>
>>> Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because
>>> it
>>> uses the old pj_transform() API with doesn't trigger that code path at
>>> all.
>>> But it *is* affected by exportToProj4() no longer returning +datum or
>>> +towgs84
>>> in cases where it used to be, which basically makes working with
>>> anything !=
>>> WGS 84 fundamentaly broken. The only "fix" would be to backport the
>>> fully
>>> fledged PROJ 6 support of 3.10 which is obviously unreasonable to do in
>>> 3.4
>>>
>>> > think we SHOULD drop
>>> > Windows LTR support early rather than releasing a 3.4 build based on
>>> > proj6/gdal3.
>>>
>>> +1
>>>
>>> --
>>> 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
>
>
___
QGIS-Developer mailing list
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] LTR management [was Re: Delaying 3.10.1?]

[Nathan Woodrow]

+1 on dropping support early as the risk is large on breaking the users
experience with a LTR

On Thu., 28 Nov. 2019, 8:55 am Even Rouault, 
wrote:

> > I think the issues are deeper then the crashes/projection failures
> > fixed by the GDAL/proj cherry-picked commits.
>
> Yes, actually QGIS 3.4 should not be affected by the PROJ fix, because it
> uses the old pj_transform() API with doesn't trigger that code path at
> all.
> But it *is* affected by exportToProj4() no longer returning +datum or
> +towgs84
> in cases where it used to be, which basically makes working with anything
> !=
> WGS 84 fundamentaly broken. The only "fix" would be to backport the fully
> fledged PROJ 6 support of 3.10 which is obviously unreasonable to do in 3.4
>
> > think we SHOULD drop
> > Windows LTR support early rather than releasing a 3.4 build based on
> > proj6/gdal3.
>
> +1
>
> --
> 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

Re: [QGIS-Developer] Log file? - QGIS not starting

[Nathan Woodrow]

Hi,

Are the dlls inside C:\OSGeo4W\apps\qgis\bin?  Main issue with this error
is generally means "we tried to load qgis_app.dll, or another dll that it
needs and we couldn't find it so here is a poor error dialog"  It's a
tricky one to debug at times. Check that folder first for the dlls and we
can go from there if they are.

There are some other tools you can use to track down what file it might be
missing.

Also, do you have a virus scanner that might be taking one of the files
that QGIS needs to load and moving it away.  We have seen that happen
before with some dlls getting moved or blocked from installing due to a
virus scanner.

Regards,
Nathan

On Wed, Nov 27, 2019 at 1:34 AM magerlin  wrote:

> Having problems installing QGIS on a colleagues brand new Win 10 PC.
> I have recently installed without problems on my own identical PC.
>
> We have tried 3.4 and 3.10 both as Standalone and from OSGeo4W.
>
> But situation is the same:
>
> QGIS 3.4:
> 
> C:\Program Files\QGIS 3.4\apps\qgis-ltr\bin\Qgis_app.dll
> does exist on PC but the .env file does not
>
>
>
> QGIS 3.10:
> 
>
> Here the .env file exists and contains this:
>
>
> PATH=C:\OSGEO4~1\apps\qgis\bin;C:\OSGEO4~1\apps\grass\grass78\lib;C:\OSGEO4~1\apps\grass\grass78\bin;C:\OSGEO4~1\apps\Python37;C:\OSGEO4~1\apps\Python37\Scripts;C:\OSGEO4~1\apps\qt5\bin;C:\OSGEO4~1\apps\Python37;C:\OSGEO4~1\apps\Python37\Scripts;C:\OSGEO4~1\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\WBem
> GDAL_DATA=C:\OSGEO4~1\share\gdal
> GDAL_DRIVER_PATH=C:\OSGEO4~1\bin\gdalplugins
> GDAL_FILENAME_IS_UTF8=YES
> GEOTIFF_CSV=C:\OSGEO4~1\share\epsg_csv
> GISBASE=C:\OSGEO4~1\apps\grass\grass78
> GRASS_PROJSHARE=C:\OSGEO4~1\share\proj
> GRASS_PYTHON=C:\OSGEO4~1\bin\python3.exe
> JPEGMEM=100
> OSGEO4W_ROOT=C:\OSGEO4~1
> PROJ_LIB=C:\OSGEO4~1\share\proj
> PYTHONHOME=C:\OSGEO4~1\apps\Python37
> QGIS_PREFIX_PATH=C:/OSGEO4~1/apps/qgis
> QT_PLUGIN_PATH=C:\OSGEO4~1\apps\qgis\qtplugins;C:\OSGEO4~1\apps\qt5\plugins
> VSI_CACHE=TRUE
> VSI_CACHE_SIZE=100
> O4W_QT_PREFIX=C:/OSGEO4~1/apps/Qt5
> O4W_QT_BINARIES=C:/OSGEO4~1/apps/Qt5/bin
> O4W_QT_PLUGINS=C:/OSGEO4~1/apps/Qt5/plugins
> O4W_QT_LIBRARIES=C:/OSGEO4~1/apps/Qt5/lib
> O4W_QT_TRANSLATIONS=C:/OSGEO4~1/apps/Qt5/translations
> O4W_QT_HEADERS=C:/OSGEO4~1/apps/Qt5/include
>
>
>
>
>
>
> -
> Regards Morten
>
> Currently using Qgis 3.10.0
> Windows 10, 64bit
> --
> 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

Re: [QGIS-Developer] Temporary folders for processing

[Nathan Woodrow]

Hey,

They should be going into whatever %TEMP% is set as: In my case that
is C:/Users/Nathan/AppData/Local/Temp/
and running one of the GDAL commands outputs this:

C:/Users/Nathan/AppData/Local/Temp/processing_95803a9cdde54b1f8e28633e7fc16ccb/2834f0fd8fc4455485a212fb405c38c8/OUTPUT.gpkg


Regards,

Nathan

On Mon, Nov 25, 2019 at 7:53 PM Andreas Neumann  wrote:

> Hi,
>
> I would like to know where the temporary files of QGIS processing are
> stored? I know that there is a setting for default output files (defaults
> on Windows
> to 
> C:\Users\username\AppData\Roaming\QGIS\QGIS3\profiles\profilename\processing\outputs
> - but is this really the same location where also temporary files that are
> needed during the processing are stored?
>
> Our issues is that several users share Windows servers and the C partition
> is only 80GB in size. If 5-10 users are sharing one Windows server, we fear
> that our C drive is filled really quickly.
>
> Can we set another temporary drive/folder than
> "C:\Users\username\AppData\Roaming\QGIS\QGIS3\profiles\profilename\processing\outputs"
> ? If yes, where do I find this setting?
>
> Thank you for your help,
>
> Andreas
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR management [was Re: Delaying 3.10.1?]

[Nathan Woodrow]

Hey,

I know it has been said before, but changing the GDAL/Proj version of the
LTR versions is really a no go. It's a breaking change in terms of possible
breakages and just increases risks on a version we need to stay stable.

We are communicating to users they should use the LTR because it's stable
but changing the major dependencies under the hood with new versions breaks
this trust and message.  It would be like changing the Qt version inside an
LTR point release, we just can't do it because it's a full major change
with massive impacts.   The risk of the LTR running on older stacks is seen
as a net positive not a negative when it comes to stability for users.
 The moment we break this trust we lose all the work past work we have put
in to communicate this message, trust is hard to gain and easy to lose.

I'm not sure what the solution here is because I know OSGeo4w doesn't
really support that kind of separation yet but if we have a way to fund
this kind of work I would really like us to consider it (unsure the state
of the budget but this one is critical IMO).  It's going to be an ongoing
issue and something that will always have to be resolved with each LTR as
it moves away from the nightlies with the  dependencies  changing.   I wish
I had the skills and time to help fix this but at the moment all I can
offer is my concern.

Regards,
Nathan

On Sat, Nov 23, 2019 at 10:26 PM Tim Sutton  wrote:

> Hi
>
> We also have situations like this [1] where we are breaking the LTR with.
> Big bumps in GDAL/PROJ version.
>
> Could we either a) invest QGIS bug fixing money into resolving these or b)
> adopt a more conservative approach to adopting new versions of libraries?
>
> [1]https://github.com/qgis/QGIS/issues/32953
>
> Regards
>
> Tim
>
> On 23 Nov 2019, at 11:23, Paolo Cavallini  wrote:
>
> Hi Tim,
>
> Il 23/11/19 11:22, Tim Sutton ha scritto:
>
>
> For windows at least we could ‘freeze’ 3.4.x by pointing them to use the
> standalone installers but then we have an LTR that is not getting bug
> fixes. As I read Jürgen’s roadmap [1] we still have 4 more bug fix
> releases of 3.4 before 3.10 becomes LTR, which is quite a long time to
> have our ’stable’ version out there with no bug fixes.
>
>
> yes, that's what I meant. It's a kind of bad hack, so as Bas also
> pointed out the proper solution is just to go ahead and fix the bugs.
> I feel bad about people wasting their time to fix this compatibility bug
> that will be useful just for a relatively short period, however.
> 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
>
>
> —
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> 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
>
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
>
> ___
> QGIS-Developer mailing list
> 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] Copyright in a plugin?or idea?

[Nathan Woodrow]

Hey,

Ideas are a tricky one.  There is no need to give someone else credit for
an idea if you don't want to, even if you feel you had it first. It's a
nice thing to do but not required by any means.  You can copyright your
code but that doesn't stop someone reimplementing your idea in a different
way, it's why we have 100 different browsers these days.  This is just how
the software world works generally.   We take ideas from others and
evolve them and you can draw inspiration from many places.  If you want to
keep an idea for you own you need a patent but good luck :)

For an example, I added and worked on the style dock (also for free ;) )
along with others for a very long time, one of my largest QGIS projects in
core, however at the time I wasn't aware the same thing was in ArcGIS Pro
before me, I simply didn't know.  I took inspiration from other tools like
CartoDB and Mapbox at the time. Same with ideas I have had while using
Excel etc (although I did give credit to them in my post about that feature)

>> but the original idea is mine

I would be careful going down this route IMO.   Mainly because I did it
back in 1.6 or so but never open-sourced it because my code sucked back
then. Customizing the QGIS UI has always been on my, and others, minds on
the project, and we work together to make it better.  Sure some people have
ideas and we get to take credit they are ours but in the end, we don't work
in a vacuum and we contribute to each other and the project in different
ways.   Just because someone writes the code doesn't mean they own the idea
and no one else can do it. I have let many other devs, mainly Nyall when I
bug him enough, implement ideas I have had and don't ask for credit, most
of the time he does other times not.   I'm not in this for fame.

So yes generally you should credit if you can because it's nice thing to do
but just be careful of cashing the "I did this for free and this idea was
mine first how dare you"  because, in the end, it will end in frustration.
A lot of us work for free on QGIS, many many hours, many many late nights.
The best thing you can do is reach out and try and join forces if you can,
which it seems they are keen on.

For context: I made Roam a tablet version of QGIS for Windows (the first
from what I know), and now there is QField, and Input both using the same
kind of ideas (using the QGIS libs in a standalone project).  Making a
tablet version of QGIS wasn't my idea I was just the first to make a
installable standalone version and pushed it out.  Like a lot of things in
life, it's about the advertisement around the things you make if you want
people to see you as the main go for the idea.

- Nathan

On Wed, Oct 2, 2019 at 9:57 PM Fran Raga  wrote:

> Hi, all
>
>
> Recently I found out about this plugin
> https://github.com/qgist/toolbargenerator, which was presented in the
> FOSS4G 2019 Bucharest. What surprised me is that this plugin has EXACTLY
> the same functionality as mine, implemented for QGIS 3
> https://github.com/All4Gis/CustomToolBar , which I developed without any
> funding.
>
> Not only it does the same but also it has the same limitations as mine
> (like i18n problems).
>
>
> The main difference lies on the fact that it stores the tools depending on
> the user profile (which in my plugin implies modifying 2 -and only 2-
> lines).
>
>
> I don’t mind if the code is better written or not, but the original idea
> is mine (moreover, it is completely functional in QGIS3) and I developed it
> four years ago.
>
>
> Four years ago I experienced the same situation with “QGIS themes”, which
> I developed and then, a core developer (Nathan) implemented a plugin and
> integrated it in the QGIS core. I wrote to him and he changed his entry
> indicating that this idea already existed (
> https://nathanw.net/2015/08/13/qgis-ui-themes-plugin/). I found it
> satisfactory, because this functionality had been already developed by
> another developer.
>
>
> I think that who had the original idea should be taken into account. We
> are in an Open Source world, where I sometimes have the impression that
> “anything goes”. However, if an idea already exists, the original author
> should be taken into account or at least, the original author should be
> cited in a visible place.
>
>
> Here you can find my discussion with the other author:
> https://github.com/qgist/toolbargenerator/issues/7
>
>
> I think that these situations discourage people to collaborate in QGIS and
> in the open source, in general, if the original idea and the developer work
> are not valued.
>
>
> regards
>
> *Francisco Raga** | *Full-Stack Open Source GIS Developer
>
> Móvil: (+34) 654275432* | *e-Mail: franka1...@gmail.com *| *skype:
> francisco_raga
> Github: https://goo.gl/ydNTjY *| *Linkedin: https://goo.gl/TCfj8S *| *Site:
> https://goo.gl/qiypDj
>
> "La vida real no tiene ningún mapa.."  Ivy Compton Burnett
> ___
> QGIS-Developer mailing list
> 

Re: [QGIS-Developer] 3.4 backports

[Nathan Woodrow]

Is it easy to disable the auto backport and have it just create the pull
request and tag someone?  That way it can still be semi-automatic but with
some human checks

On Tue, Sep 17, 2019 at 9:06 AM Nyall Dawson  wrote:

> Hi all,
>
> Just a quick plea that during this freeze period please think
> carefully about the suitability of backporting fixes to 3.4. At this
> stage in its lifecycle 3.4 should only receive absolutely mission
> critical fixes (such as crash fixes or data corruption issues).
>
> The consequence of regressions in 3.4 caused by backporting minor bug
> fixes much outweighs the benefits of fixing these bugs. While the
> backport label makes 3.4 backports easy to do, it does not guarantee
> their safety or suitability.
>
> Thanks!
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Topical discussions for the QGIS Contributor Meeting in Bucharest

[Nathan Woodrow]

>  (looking at you Australia :-) )

Yay go Australia *checks notes* ok maybe not



On Fri, Aug 23, 2019 at 8:20 PM Tim Sutton  wrote:

> Hi all
>
> So we are settling in nicely at the great hackfest venue in Bucharest and
> I wanted to confirm the remote sessions for the meet up. Could I ask
>
> 1) Take a look at
> https://github.com/qgis/QGIS/wiki/23rd-Contributors-Meeting-in-Bucharest#making-your-first-pull-request-to-qgis
> and the subsequent sections and...
> 2)  Those who have their names next to a session as the presenter confirm
> if you are able and willing to present on this topic again, then write me
> an email with your proposed day and time if you are available, or let me
> know if you are not.
> 3) If you are participating in-person or remotely and would like to have a
> discussion about a specific topic, add it to the wiki page using the
> existing template and then also pop me a note so that I can find a session
> presenter for your chosen topic if possible.
> 4) if you are participating remotely and really want to join a discussion
> but are constrained e.g. by living on the wrong side of the world (looking
> at you Australia :-) ) pop me a note so that I can try to schedule it at a
> time that will work for you.
>
> Have a great hackfest all!
>
> Regards
>
> Tim
> —
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> 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
>
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
>
> ___
> QGIS-Developer mailing list
> 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] On github, gitlab, and imperialist nations screwing us all over...

[Nathan Woodrow]

Hey Nyall,

>From my understanding, it is only private repos (which we have none) and
nothing open source and the public which means it really shouldn't affect
us in any way.

Providing a mirror isn't a bad thing anyway, but I don't think this move
affects us really here.  A lot of places have networks blocking access to
stuff like GitHub anyway so might not be bad to have a mirror to help those
people.

- Nathan



On Thu, Aug 1, 2019 at 2:26 PM Nyall Dawson  wrote:

> Hi list,
>
> Well, I've got to say upfront that we WERE warned about the dangers of
> this happening by members of our community, and now the worst IS
> happening and Github has started blocking access to projects from
> certain regions.
>
> See https://www.linuxinsider.com/story/86154.html, but long story
> short, GitHub is now blocking users in Crimea, Cuba, Iran, North Korea
> and Syria from accessing its services to comply with U.S. trade
> control laws. I'm unsure if we're directly affected yet by this, but
> the wording on Github's notice is very vague: " GitHub MAY allow users
> in or ordinarily resident in countries and territories subject to U.S.
> sanctions to access CERTAIN free GitHub.com services for PERSONAL
> COMMUNICATIONS " (emphasis added by me).
>
> What can/should we do in response to this?
>
> Note that it ALSO applies to gitlab.com, who are also subject to the
> same trade laws, so moving to gitlab ISN'T a possible solution (unless
> we self-host).
>
> I think at the least we could/should endorse an official, read-only
> repo mirror which isn't affected by the trade laws, e.g.
> https://git.osgeo.org/gitea/qgis/QGIS would be a great candidate
> (unless osgeo is also affected by the same ruling, which they could
> easily be, given that they are US based too) . An official mirror
> would at least ensure that users in these regions can access the
> existing source.
>
> Does this development concern anyone else?
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Crashes on exit

[Nathan Woodrow]

Hmm pretty sure if is wrong. Without debug symbols it doesn't know what
code is running and just has a good guess. A stack trace with symbols will
show a completely different stack

On Fri., 19 Jul. 2019, 9:26 am Nyall Dawson,  wrote:

> On Thu, 18 Jul 2019 at 16:52, Nathan Woodrow  wrote:
> >
> > Yeah, in this case, the stack trace is wrong because of the lack of
> symbols.  The symbols could be installed with QGIS at the increase of
> package size but maybe we can do that for a while until we catch this issue.
>
> I don't think the trace *is* wrong here. The recurring source of these
> issues is that long-lived objects which have QgsCoordinateTransform
> members are being cleaned up AFTER QgsApplication::exitQgis, where the
> proj library handling is gracefully cleaned up. After
> QgsApplication::exitQgis NOTHING should be accessing coordinate
> transforms.
>
> Actually I just had an idea for a potential workaround... let me see
> if this works...
>
> Nyall
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Crashes on exit

[Nathan Woodrow]

Thanks Jürgen,

Yeah I know it was a bit much to have them included.  I will see what I can
do with my install and hopefully get a good stack trace.

Regards,
Nathan

On Thu, Jul 18, 2019 at 5:07 PM Jürgen E. Fischer  wrote:

> Hi Nathan,
>
> On Thu, 18. Jul 2019 at 16:51:44 +1000, Nathan Woodrow wrote:
> > Jurgen, would we be able to include the debug symbols for the build on
> the
> > normal installers for once release cycle while this is still an issue?
> That
> > would be super handy to catch this and other issues that come up.
>
> You can already install the qgis-pdb package using the normal installer.
> The
> normal installer is also shipped with the standalone, so you could also use
> that to install pdbs afterwards.  They cannot be included in the
> standalone as
> we're already near to NSIS' 2GB limit (maybe once the GRASS package is
> ported
> to python3, so we can drop all python2 - but I gues not as the pdbs are
> huge)
>
> We also have a symbol server - but given the nightlies it's huge and needs
> to
> be aged out quickly (a week I think) so the release symbols probably don't
> last
> long.  Running nightlies for this kind of thing should help.
>
>
> Jürgen
>
> --
> Jürgen E. Fischer norBIT GmbH   Tel. +49-4931-918175-31
> Dipl.-Inf. (FH)   Rheinstraße 13Fax. +49-4931-918175-50
> Software Engineer D-26506 Norden
> https://www.norbit.de
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Crashes on exit

[Nathan Woodrow]

Yeah, in this case, the stack trace is wrong because of the lack of
symbols.  The symbols could be installed with QGIS at the increase of
package size but maybe we can do that for a while until we catch this issue.

At the moment installing the symbols for the normal installer versions of
QGIS is a bit hard for most users.

Jurgen, would we be able to include the debug symbols for the build on the
normal installers for once release cycle while this is still an issue? That
would be super handy to catch this and other issues that come up.

On Thu, Jul 18, 2019 at 4:44 PM Mathieu Pellerin 
wrote:

> While discussing this further with Nathan, disabling the crash reporter
> might not be the right solution as it'd most likely bring the OS crash
> dialog anyways.
>
> We'd need for the crash reporter to detect specific traces and silently
> fail when it detects a useless / harmless trace.
>
> There's also the problem of ppl pasting wrong traces due to not having
> installed the debug package, we could improve the notification in this
> scenario to suggest installing package.
>
> On Thu, Jul 18, 2019, 13:35 Andreas Neumann  wrote:
>
>> Hi Nyall,
>>
>> Thanks for the reply. I also experienced quite a lot of these crashes.
>> Something that often shows up in the stack trace is
>>
>> proj_lpz_dist :
>> proj_lpz_dist :
>> QgsCoordinateTransform::transformPolygon :
>> QgsCoordinateTransform::transformPolygon :
>> QgsCoordinateTransform::QgsCoordinateTransform :
>> QHashData::free_helper :
>> QgsCoordinateTransform::addToCache :
>> QgsCoordinateTransform::invalidateCache :
>> QgsApplication::exitQgis :
>> QgisApp::~QgisApp :
>> CPLStringList::operator char * __ptr64 * __ptr64 :
>> main :
>> BaseThreadInitThunk :
>> RtlUserThreadStart :
>>
>> Like in https://github.com/qgis/QGIS/issues/30753
>>
>> But I am sure you also came across these.
>>
>> Really annoying. Perhaps disabling the crash reporter on QGIS exit on the
>> release versions would help? Can we enable them just on the master?
>>
>> Andreas
>>
>> On 2019-07-18 08:19, Nyall Dawson wrote:
>>
>> On Thu, 18 Jul 2019 at 16:05, Andreas Neumann 
>> wrote:
>>
>>
>> Hi QGIS core devs,
>>
>> Currently on the Github issues I have the (subjective) feeling that every
>> third report is about QGIS crashing on closing the program. It seems to be
>> a really wide-spread issue that a majority of our users have. It would be
>> great for QGIS' reputation if we could fix this/these issue(s). Or has this
>> already been fixed and people don't use the newest versions?
>>
>>
>> These are VERY frustrating. It's actually a bunch of different
>> underlying issues causing this. We've probably squashed a dozen or so,
>> but they keep resurfacing (or being re-introduced), and none of the
>> existing bug reports have clues on remaining causes.
>>
>> Fortunately they are harmless. Mathieu has previously suggested we
>> just shut down the crash reporter on QGIS exit to avoid this -- I
>> think that would be a worthwhile change.
>>
>> Nyall
>>
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Save Log messages as pdf

[Nathan Woodrow]

Sorry that should have been Qt libs.  Phone auto correct doesn't understand
"Qt".

Here is a good example for you that should work out of the box.  This is
C++ but it's the same logic for PyQt:
https://wiki.qt.io/Exporting_a_document_to_PDF

- Nathan

On Fri, Jul 12, 2019 at 11:14 PM Roberta Fagandini 
wrote:

> Thank you Nathan,
> I found some documentation about QPainter but I'm not able to find
> something interesting about At lib..do you have any specific link?
>
> Using the solution that you suggested, is it possible to set graphic
> effects? for instance bold or italic characters, font size, text spacing
> and justification, ecc.
>
> Thank you!
>
> Roberta
>
> Il giorno ven 12 lug 2019 alle ore 14:50 Nathan Woodrow <
> madman...@gmail.com> ha scritto:
>
>> Sure. You would be able to do this with a QPainter. Have a search for
>> print pdf using At and you should get something. We use the built on At
>> libs to render layout prints.
>>
>> On Fri., 12 Jul. 2019, 10:44 pm Roberta Fagandini, <
>> robifagand...@gmail.com> wrote:
>>
>>> Hi all,
>>> I'm working on a plugin that prints a report at the end of the process
>>> in a log text area of the GUI. I'd like to add an option (maybe a checkbox)
>>> to save the content of the log and the image of the map area as a single
>>> multipage pdf file.
>>>
>>> Is it possible with the standard libraries or it requires external
>>> dependencies? Do you have any documentation to suggest?
>>>
>>> Thanks in advance
>>>
>>> Roberta
>>> ___
>>> QGIS-Developer mailing list
>>> 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] Save Log messages as pdf

[Nathan Woodrow]

Sure. You would be able to do this with a QPainter. Have a search for print
pdf using At and you should get something. We use the built on At libs to
render layout prints.

On Fri., 12 Jul. 2019, 10:44 pm Roberta Fagandini, 
wrote:

> Hi all,
> I'm working on a plugin that prints a report at the end of the process in
> a log text area of the GUI. I'd like to add an option (maybe a checkbox) to
> save the content of the log and the image of the map area as a single
> multipage pdf file.
>
> Is it possible with the standard libraries or it requires external
> dependencies? Do you have any documentation to suggest?
>
> Thanks in advance
>
> Roberta
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] QGIS shortcuts on windows. With and without grass

[Nathan Woodrow]

Hey all,

Just wondering if there is a reason that we have 3 shortcuts to QGIS when
you install on Windows.

- QGIS
- QGIS with Grass
- QGIS with Grass 7.6

Could there be a single exe and always set the grass path?  Given we ship
grass and saga seems odd to run without it given it's only setting the
environment variable at the start from what I can see (haven't looked at
the code).

Has been raised a few times when I have been training people as a source of
confusion.

Regards,
Nathan
___
QGIS-Developer mailing list
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] Where did the gdal / ogr provider logic go?

[Nathan Woodrow]

We dropped support for ogr in a effort to finally kill off shapefiles :p

- Nathan

On Mon., 8 Jul. 2019, 11:39 pm Tim Sutton,  wrote:

> Hi All
>
> Can someone point me to where the logic that used to be in
> src/providers/ogr went?
>
> Thanks!
>
> Regards
>
> Tim
> —
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> 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
>
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 3.8 Transformations dialog

[Nathan Woodrow]

NIce work! Pretty handy having that map in there.

On Mon, Jul 8, 2019 at 10:13 AM Nyall Dawson  wrote:

> On Mon, 1 Jul 2019 at 11:11, Nyall Dawson  wrote:
> >
> > On Fri, 28 Jun 2019 at 17:29, Nyall Dawson 
> wrote:
> > >
> > > On Fri, 28 Jun 2019 at 17:11, Richard Duivenvoorde <
> rdmaili...@duif.net> wrote:
> > > >
> > > > On 28/06/2019 01.28, Nyall Dawson wrote:
> > > > >> That one shows 'just' 2 options (added to the qgis.nl post)
> > > > >> IF the green line is just the first one, but we are not sure if
> it is
> > > > >> the right one... should we make it green anyway?
> > > >
> > > > > Ah, on proj 6 builds, we ARE sure that the first/green one is the
> most
> > > > > recommended one :) That's because proj gives us an ordered list of
> > > > > possible operations in order of preference (calculated using all
> > > > > proj's internal smarts and knowledge about the accuracy of
> different
> > > > > transform operations).
> > > >
> > > > Mmm, then my last question, after this I'll move to proj ;-)
> > > >
> > > > See:
> > > >
> > > >
> http://www.qgis.nl/media/2019/06/Screenshot-20190627104509-716x467.png
> > > >
> > > > This is QGIS with proj6: As you see there are 2 options. The first
> one
> > > > being green 'numbered' (3). But the bottom one having a higher number
> > > > between brackets having a (4) between brackets?
> > > >
> > > > Now /me wondering what these numbers are: because given your answer
> > > > above, the green one being 'THE one' :-) I wonder what this other
> > > > numbers are (I was wondering ordered by date/relevance or so)??
> > >
> > > These are how proj identifies the coordinate operation -- I'm not
> > > entirely sure what they represent, but I assume they are just indexes.
> >
> > Just for followers of this thread - conversation moved to the proj
> > mailing list, and looks like it will result in improved descriptive
> > strings coming as a result...
>
> Following all this discussion, here's a quick comparison of before vs
> current:
> Before:
> http://www.qgis.nl/media/2019/06/Screenshot-20190627104509-716x467.png
> Now:
> https://user-images.githubusercontent.com/1829991/60775333-f4f4db80-a164-11e9-8076-225ba2322aba.png
>
> Iterative design at its finest ;)
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS 4.0 - let's start some early discussions!

[Nathan Woodrow]

Personally, I'm a bit uncomfortable with any kind of API break if we can
avoid it which means we don't need to call it 4.0 as that marks a major API
break when bumping that version number?  Any reason we need to make it 4.0
and not just continue down the 3.x stream until we are forced to break APIS?

We should be able to migrate away from any API breaks in theory right? We
couldn't for 3.0 because of all the SIP and Python 3 stuff but that
shouldn't be the case in Qt 6 hopefully.

That is just my take.  We need to maintain a stable API for as long as
possible if we can which I know you know I'm just double voicing it.

- Nathan

On Tue, Jun 25, 2019 at 7:42 PM Nyall Dawson  wrote:

> Hi all,
>
> Following conversation from https://github.com/qgis/QGIS/pull/30234, I
> think it would be beneficial if we start the conversation happening
> about QGIS 4.0, and to throw some thoughts about timelines out there.
>
> **Before anyone panics -- I'm expecting multi-year time frames here!
> But I think we should START this discussion, and have at least some
> idea of the time frames we're all aiming toward for a future 4.0
> release.**
>
> For reference: Qt upstream has previously hinted at November 2020 for
> Qt 6, at which stage support for 5.x will be dropped. Discussions so
> far are moving toward Qt 6 being a "gentle" cleaning, so there's
> likely (hopefully?) not a lot we'll be forced to do to adapt to this.
>
> I think we should aim for a similar goal -- a "gentle" API break, as
> opposed to the huge-clean-and-break-everything-we-possibly-can
> approach we took for 3.x (with good reason!).
>
> Thoughts?
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] saving a layer with the world_map.shp

[Nathan Woodrow]

Hey Tim,

Yes I yanked that file from Natural Earth and I think it might have
simplified it a little bit to reduce the file size but it's the same file.

Regards,
Nathan

On Fri, Jun 7, 2019 at 7:25 PM Tim Sutton  wrote:

> Hi
>
> If I am not mistaken, the world map comes from Nathan Woodrow (he added it
> for the projection selector widget):
>
> [timlinux@sandstone ~/dev/cpp/QGIS/resources/data (master)]$ git log
> world_map.shp
> commit cf241f51ae2ae4ae225c9af65690aa2a5524df04
> Author: Nathan Woodrow 
> Date:   Mon Oct 16 10:40:05 2017 +1000
>
> [FEATURE][needs-docs] Show projection bounds in projection widget
> (#5356)
>
>
> - Script to pull bounds from EPSG.org Postgres dump
> - Add resources/data/world_map.shp for reference
> - Show canvas bounds for reference
>
> I’m guessing it comes from Natural Earth, but he would need to confirm.
> Nathan can you add a license for that file?
>
> Regards
>
> Tim
>
> On 7 Jun 2019, at 09:53, Áron Gergely  wrote:
>
> Hi Tim,
>
> With Raymond we are planning on using your great ester egg data in the
> overview box within map layouts.
> I am looking for the license of the data,  do you perhaps know it / know
> where to find it?
> Or does it fall under QGIS' license?
>
> Thanks,
>
> Best Regards,
> Aron Gergely
>
> I am also a fan of the ester egg, learned it from Raymond.
>
> On 28/05/2019 10:50, Tim Sutton wrote:
>
> Hi
>
> I don’t have any immediate fix for your issue, but I am glad you are
> enjoying my Easter egg :-) I also use it ALL THE TIME and it is really
> great in training courses etc. to get people quickly started with panning
> and zooming or putting their data in context. One day maybe we can elevate
> it’s status to have a button on the file toolbar that adds it to the canvas
> without the need for bunnies and chocolate :-)
>
> PS for those that don’t know about the Easter egg, type ‘world’ into the
> coordinate box in the status bar as shown below, then press ENTER.
>
> 
> Regards
>
> Tim
>
> On 27 May 2019, at 14:58, Raymond Nijssen  wrote:
>
> I know it was introduced as an easter egg, but I'm very happy with the
> built in world map in qgis. I'm using it in a plugin to automatically add a
> layer for the overview map in my layout. This layer points to a shapefile
> in my qgis install directory:
>
> /home/raymond/programs/qgis-master/share/qgis/resources/data/world_map.shp
>
> Now, when saving my project and somebody else opening it, the layer is
> invalid (of course). Is there a way to make the project point to the right
> file, using some kind of variable pointing to the qgis installation path?
>
> like this:
> {QGIS_RESOURCE_PATH}/data/world_map.shp
>
> or I could copy the world.shp into my plugin and do this:
>
> {QGIS_PLUGIN_PATH}/my-plugin/data/world_map.shp
>
> These paths should then be saved including the variable in the project
> file.
>
>
>
> Another option would be to save the shp-file in the .qgz somehow but I'm
> not too sure if that is the way to go..
>
>
>
> This is the way I create the path now:
>
> worldShp = os.path.join(QgsApplication.pkgDataPath(), 'resources', 'data',
> 'world_map.shp')
>
>
>
> To make the question more general, is it possible to add resources to a
> plugin in a way that projects point to these resources and make that work
> for other users too?
>
>
> Hope anyone can help!
>
> Kind regards,
> Raymond
>
>
> ___
> QGIS-Developer mailing list
> 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*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org <http://qgis.org/>
>
> 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
>
> I'd love to connect. Here's my calendar link
> <https://calendly.com/timlinux> to make finding time easy.
>
>
> ___
> 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
>
>
>
> —
>
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> Visit http://kartoza.com to find out abo

Re: [QGIS-Developer] QGIS and Proj 6

[Nathan Woodrow]

Great work! I know that has been a massive project and I'm sure it's well
worth it (except for the grey hairs now).

Thanks, heaps to ICSM for the funding to make this happen.

On Mon, Jun 3, 2019 at 5:28 PM Nyall Dawson  wrote:

> Hi all,
>
> Following the merge of https://github.com/qgis/QGIS/pull/30040 , I now
> consider QGIS' port to the Proj 6 API complete. Here's a bit of a
> summary of what's been done here (on builds based on proj 6.1 and
> later only, more on that later[1])
>
> - The Proj CRS database is now used to populate QGIS' internal CRS
> database. We no longer use the combination of GDAL CSV files and
> manual QGIS overrides we've used till now. This means that ALL
> responsibility for CRS definitions and updating these sit were they
> belong, upstream in the proj library. It also means we'll be an exact
> match wrt projections as other tools which have completed the port,
> such as GDAL 3.0. (All this goodness is thanks to the GDAL barn
> raising effort). We still HAVE an internal projection database, in
> order not to break existing 3.x API, so we'll need to revisit that at
> 4.0 and see if it can be safely removed then.
>
> - We rely entirely on Proj 6's wonderful logic for generating the best
> coordinate operation to transform between CRS pairs now. This means
> (amongst other stuff), we correctly support complex things like
> operations which require a "pivot datum", e.g. transformation to and
> from GDA2020 coordinate systems. Again, this is thanks to the GDAL
> barn raising effort... if it wasn't for that, we'd be... YEARS away
> from even dreaming about supporting these correctly. Seriously, hats
> off to the proj/GDAL teams here, they've done a brilliant effort, and
> have been tirelessly answering tons of questions on their mailing
> lists.
>
> - Instead of the older approach QGIS used for datum transformations
> (carrying around our own table of when grid shift files can be used),
> we now use proj to determine these. This considerably changes the user
> interface shown when a user has opted into selecting manually a
> transform to use when multiple transforms exist, and we now show a
> simplified list of available (and non-available) pathways.
>
> - We also use proj's database to populate lists of available
> ellipsoids for use in distance and area calculations. This has cleaned
> up the ellipsoid choices considerably, and added many additional
> ellipsoid definitions as a result. (woohoo... no more duplicate
> "WGS84"/"WGS 84" entries!)
>
> - The UX for notifying users about issues in coordinate transforms is
> greatly improved, e.g. users are now alerted when a more accurate
> transform is possible, but not usable on their system (e.g. due to
> missing .gsb grid shift files). Wherever possible, we present users
> with direct download links to obtain these required/desired grid shift
> files. The intention here is to ensure users are informed when
> transforms can be improved, instead of silently falling back to less
> accurate options.
>
> - Users also now have the option of placing grid shift files in "proj"
> folder off their user profile. This means users can install grid shift
> files and make them available in QGIS without requiring administrative
> rights (possibly in future we could make QGIS fire up a background
> task which automatically downloads and installs grids on demand...)
>
> - We've also completed a project which began back in the lead-up to
> 3.0, which ensures that project-specific transformation pathway
> settings are correctly respected EVERYWHERE a coordinate transform is
> performed. This also means we're ready for the next stage in handling
> 4d coordinate transforms (when these start to land in 2020 and beyond)
>
> As noted above, a lot of this is only possible thanks to improvements
> in the proj and gdal libraries, which landed as a result of the GDAL
> barn raising effort. On the QGIS side, it was ONLY possible thanks to
> funding from the Australian ICSM. It's been a HUGE undertaking, so I'm
> extremely grateful that the ICSM has had the foresight to invest into
> QGIS and open source software development in this way.
>
> Nyall
>
> [1] Note that building 3.8 using the Proj 6 library requires a minimum
> of Proj 6.1 -- it's not possible to build using Proj 6.0. There was an
> API call added in 6.1 which we require, and I couldn't work around.
> Sorry for any inconveniences this causes!
> ___
> QGIS-Developer mailing list
> 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] Crashes on closing QGIS

[Nathan Woodrow]

Nyall has hopefully fixed that bug already.  The one with proj_lpz_dist in
the stack trace.  That isn't the real crash as that stack trace has no
symbols so it's giving you the wrong info.  I got a stack trace the other
day with correct symbols loaded and hopefully, it will be fixed now.

- Nathan

On Thu, Apr 11, 2019 at 5:06 PM Jürgen E. Fischer  wrote:

> Hi Thomas,
>
> On Wed, 10. Apr 2019 at 23:04:50 +0200, Thomas Baumann wrote:
> > proj_lpz_dist :
> > QgsCoordinateTransform::transformPolygon :
>
> > Does someone know what "proj_lpz_dist" stands for?
>
> It's a function from PROJ:
>
>
> https://proj4.org/development/reference/functions.html?highlight=deg#c.proj_lpz_dist
>
>
> Jürgen
>
> --
> Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
> Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
> Software Engineer   D-26506 Norden
> https://www.norbit.de
> ___
> QGIS-Developer mailing list
> 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] Improvement to the plugin manager's upgradeable plugins details

[Nathan Woodrow]

I think we should add some new metadata with a standard format for each
version. Something like this


[changelog]

1.0.6=something something dark side even more
  some other things
  and other things
1.0.5=something something dark side
1.0=First version of the dark side really

That can be taken and turned into the full changelog or parsed into a
version based one.

The other option is to use some kind of naming convention in the already
there changelog tag but might be hard for multiline notes.

On Mon, Mar 11, 2019 at 7:43 PM Paolo Cavallini 
wrote:

> Agreed, this is undefined, and people use it in different ways, leading
> to uncertainties both on the developer and the user sides.
> Any suggestion for the best option?
> Thanks.
>
> On 11/03/19 10:12, Tom Chadwin wrote:
> > Might this lead to some guidance on plugin changelogs? Mine has the whole
> > changelog history, so should I instead only include current version
> changes
> > in metadata.txt?
> >
> > 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
> >
>
> --
> 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] Improvement to the plugin manager's upgradeable plugins details

[Nathan Woodrow]

Ohh yes please.  That is really needed!

On Sat, Mar 9, 2019 at 8:39 PM Mathieu Pellerin 
wrote:

> Greetings,
>
> While applying a couple of commits to QGIS' plugin manager, I would like
> to fix a long-standing UX issue with it, namely that plugins that show a
> newer version available do _not_ show the latest changelog but rather the
> changelog of the currently installed plugin version.
>
> It'd much nicer, and exciting for users, to show what's new _prior to_
> hitting the [ update plugin ] button.
>
> For that to happen, we'd need either: a/ add the changelog information in
> the repository XML file fetched (i.e.
> https://plugins.qgis.org/plugins/plugins.xml?qgis=3.6), or b/ add a
> method to fetch changelog strings from the repository site (for e.g.,
> https://plugins.qgis.org/plugins/changelog.xml?names=plugin1,plugin2,plugin3
> ).
>
> Unless adding the short changelog to the repository XML adds too many MBs,
> I'd vote for option A.
>
> Thoughts?
>
> Mathieu
> ___
> QGIS-Developer mailing list
> 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] Vagrant file for QGIS-Django

[Nathan Woodrow]

haha yes I know but for some reason I can't get docker to run well on
Windows at the moment for me, so I will just run it inside a vagrant box
because it's turtles all the way down.

Richard,  could I get some details on how to set this up?

On Fri, Mar 8, 2019 at 9:59 PM Tim Sutton  wrote:

> Hi
>
>
> Vagrant is so 2000s :-p Everything runs in docker. We have it in a a
> private docker hub repo as image contains a working db snapshot too..
>
> Richard is the gate keeper for getting access to the hub repo after which
> you should be able to do:
>
>
> docker login
> docker run -ti -p 8099:80 \
> -d --restart=unless-stopped \
> --name="plugins" \
> -v ${PWD}/static:/home/plugins/QGIS-Django/qgis-app/static \
> -v ${PWD}/backups:/backups \
> -v ${PWD}/tmp:/tmp \
> -v ${PWD}/logs:/var/log/nginx \
> qgis/plugins:latest \
> supervisord -n
>
> The volume mounts are not strictly necessary - we store teh actual plugin
> packages in a host directory instead of the container.
>
> Regards
>
> Tim
>
> On 08 Mar 2019, at 13:41, Nathan Woodrow  wrote:
>
> Hey,
>
> Is there any premade vagrant file I can use for the QGIS-Django project
> that already has everything set up?
>
> If not I can make one as I run Windows most of the time and I would like
> to have something set up I can just run up and shutdown nicely to match
> what we have running on https://plugins.qgis.org without having to
> install anything local on my windows machine.
>
> Keen to see if others with more experience have done work in this area
> before so I don't have to reinvent it, but happy to do it if other haven't.
>
> Regards,
> Nathan
> ___
> QGIS-Developer mailing list
> 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*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> 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
>
>
___
QGIS-Developer mailing list
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] Vagrant file for QGIS-Django

[Nathan Woodrow]

Hey,

Is there any premade vagrant file I can use for the QGIS-Django project
that already has everything set up?

If not I can make one as I run Windows most of the time and I would like to
have something set up I can just run up and shutdown nicely to match what
we have running on https://plugins.qgis.org without having to install
anything local on my windows machine.

Keen to see if others with more experience have done work in this area
before so I don't have to reinvent it, but happy to do it if other haven't.

Regards,
Nathan
___
QGIS-Developer mailing list
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

[Nathan Woodrow]

Hey  Christina,

Yeah, it's a bit odd it's not showing up at all in the XML output.  I
wonder if it was the HTML in the changelog as I can't see anything else
that is different.  I have edit the changelog and removed the HTML to see
if that picks it up.

Edited the changelog on this version for now to test that theory:
https://plugins.qgis.org/plugins/pat/version/0.1.0/

On Fri, Mar 8, 2019 at 11:11 AM  wrote:

> Hi QGIS Developers,
>
>
>
> I’m  following up on this issue which I posted last month. While it
> triggered  a lot of discussion I never received a firm answer as to whether
> my PAT plugin could be hosted and made discoverable as a QGIS plugin on the
> official plugins site.
>
>
>
> About a week ago I uploaded a new version of PAT for some bug fixes, and
> it remains unapproved. Is this likely to get approved so users can find and
> install it via the plugin manager?
>
>
>
> I was interested to see that PAT v0.1.0 has now had 131 downloads directly
> from the QGIS repository so there is definitely an interest.  Currently
> version 0.1.0 is showing on the website as being approved, but when I
> search for it in using the QGIS plugin manager, I can’t find it, even with
> the experimental option ticked on. Is there a reason for this?
>
> Kind Regards,
>
>
>
> Christina
>
>
> PLEASE NOTE: The information contained in this email may be confidential
> or privileged. Any unauthorised use or disclosure is prohibited. If you
> have received this email in error, please delete it immediately and
> notify the sender by return email. Thank you. To the extent permitted by
> law, CSIRO does not represent, warrant and/or guarantee that the integrity
> of this communication has been maintained or that the communication is free
> of errors, virus, interception or interference.
>
>
> ___
> QGIS-Developer mailing list
> 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] Branch protection enabled for 3.4

[Nathan Woodrow]

Nice. Thanks for the heads up.

On Sat., 23 Feb. 2019, 11:32 am Mathieu Pellerin, 
wrote:

> Thanks for the reminder Nyall, I'd totally forgotten about this.
>
> On Sat, Feb 23, 2019, 8:24 AM Nyall Dawson  wrote:
>
>> Hi all,
>>
>> Just a heads up: now that 3.4 is officially the LTR, I've enabled
>> github branch protection on the branch. This means all commits to the
>> branch must now:
>> 1. Go through a PR
>> 2. Pass all Travis tests
>> 3. Be approved by at least 1 other core committer
>>
>> (same rules as were in place for 2.18)
>>
>> Nyall
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Nathan Woodrow]

Hi,

Personally I don't see any reason to not allow it in official repo and
there is support for that here as IMO there is nothing bad here and nothing
should force people to work 100% on all platforms all the time because that
is a hell of a lot of work that is hard even for skilled developers.

I appreciate everyone trying to work out a method to allow this to run
cross-platform and a avoid a Windows-only solution, and in a perfect world
that is what we all want, but in this case, it won't work out and I think
having it in the official repo is better than not in this case as it allows
for better user experience for the target users..  If we can get it running
cross-platform by adding stuff to QGIS in future so be it  and we
can reevaluate at that point but I think we need to support this plugin in
this case as it's not how it is.

Regards,
Nathan

On Tue, Feb 12, 2019 at 11:27 AM  wrote:

> Hi All,
>
>
>
> Thank you all for your suggestions and  ideas for resolving this issue.
>
>
>
> The use of VESPER is currently not negotiable, and as I’ve previously pointed 
> out, VESPER is a tool of choice for kriging in the Precision Agriculture 
> industry in Australia. We will continue using VESPER as it is currently 
> implemented in the PAT plugin. If hosting PAT on the official QGIS plugin 
> repository cannot be approved, we will host it on our own repository. This 
> would be disappointing as we believe the official plugin repository would 
> provide the greatest visibility to the broader global  precision agriculture 
> community.
>
>
>
> Regards,
>
> *Christina Ratcliff*
>
> ___
> QGIS-Developer mailing list
> 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] Windows only version of a QGIS 2.18x plugin

[Nathan Woodrow]

QGIS is for the users in the end, if this opens a new world of users, and
note this is government funded, I don't think we should avoid allowing
these kinds of things in.  This isn't a core feature of QGIS and more of an
exception than a rule.  I don't see most plugins going this route but the
few that do because of X reasons they have no control over should still be
part of the community I think.

I really don't see the harm here as it's not something that most people
will know or care about in the end.  Getting plugins to work cross-platform
is a lot of work and I don't really like pushing people away because they
can't do it for whatever reason.  If this was going to be a core feature I
would be on your side for it but the plugins are for the users.

I would also note we have some features of QGIS that only work on some
platforms and not others and we are fine with that because it makes it
better for those users, so this is the same here IMO.  Pushing them out to
a self-hosted plugin repo just adds extra overhead and limits user base
and visibility of well-funded work that we should embrace.

- Nathan

On Wed, Feb 6, 2019 at 9:04 PM Paolo Cavallini 
wrote:

> Hi all,
>
> On 06/02/19 09:42, Richard Duivenvoorde wrote:
>
> > If you prefer to put it in QGIS repo: just add a big note in the
> > metadata.txt description that this plugin is only usable with vesper and
> > windows. And maybe do an OS check in the __init__ for illiterate users
> ;-)
>
> I respectfully disagree with that: at the very core of the QGIS project
> it stands the idea of letting everybody use the best possible GIS,
> without discrimination. This kind of approach would in fact favour
> Windows users. I have no issue if someone wants to create their own
> repo, as suggested by Richard, but the official one IMHO should remain
> platform-independent. I'm now dealing with CUDA, thanks Nyall for
> letting me know. Please let me know if you know of other plugins in the
> same situation.
> I would appreciate avoiding plugin approval until the discussion has
> come to a shared conclusion.
> 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

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

[Nathan Woodrow]

Hey,

Hmm, I'm not sure we should reject something if it only works on Windows
because of a 3rd party tool.  Given the limited user base, limited in the
sense that it's not a general tool for all users of QGIS and not targeted
as one, I think it would be fine if it was just listed in the comments that
this currently only works on Windows due to X reasons.   In the ideal world
it would be great if everything was cross platform but it's not life so
this is a +1 from me because it opens QGIS to more users who really will
never worry about linux or OS X.

If it was a core bit of QGIS function that would be a different question as
we try and make sure it runs the same on all platforms but personally I see
no reason we can't allow a 3rd party plugin.with those limits.

Also speaking personally as a core dev and plugin author I do all my work
on Windows and if something doesn't run on Linux or OS X others will have
to get me a fix because I can't work on those environments.

Regards,
Nathan

On Wed, Feb 6, 2019 at 4:29 PM  wrote:

> Hi QGIS dev list,
>
> I have just uploaded a new QGIS 2.18.x plugin called PAT - Precision
> Agriculture Tools.  It relies on VESPER,  a Windows only bit of software so
> therefore I went ahead writing a Windows only plugin using QGIS 2.18.x and
> the non-QGIS Python dependencies of rasterio, Fiona, geopandas and our
> pyprecag package.
>
> The majority of our users are Windows users and are the likes of Farmers
> and Ag consultants with no programming experience and very little QGIS
> experience which also led to the decision of making PAT a Windows only
> plugin. I have developed a series of dependency checks based on the Windows
> environment and create a Windows batchfile that the user can launch to
> install the Python dependencies correctly for use with QGIS.
>
> On uploading to the QGIS repository I have been advised by @pcav (see
> https://github.com/CSIRO-Precision-Agriculture/PAT_QGIS_Plugin/issues/7 )
> that PAT must support Linux and OSX operating environments. I have had a
> look on https://plugins.qgis.org/ and I cannot find where this is listed
> in bullet points under *how to add your plugin to this repository* as a
> requirement for the approval of plugins. @pcav advised that I email this
> list regarding this issue.
>
> Is it acceptable to add a line in the metadata.txt file clearly pointing
> out that this plugin is to be used in Windows only and will it still be
> approved for the QGIS plugin repository?
>
> If not what are my options?
> Are there any guides on how to best setup and test QGIS plugins for Linux
> and OSX environments? I only have access to Windows at the moment and I am
> a novice at Python programming in these other environments.
>
> Any help or direction would be greatly appreciated.
>
> Kind Regards,
>
> Christina Ratcliff
>
> PLEASE NOTE
> The information contained in this email may be confidential or privileged.
> Any unauthorised use or disclosure is prohibited. If you have received this
> email in error, please delete it immediately and notify the sender by
> return email. Thank you. To the extent permitted by law, CSIRO does not
> represent, warrant and/or guarantee that the integrity of this
> communication has been maintained or that the communication is free of
> errors, virus, interception or interference.
>
>
> ___
> QGIS-Developer mailing list
> 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] QEP: Decorators to make processing scripts easier

[Nathan Woodrow]

Hey all,

I have put up a new QEP related to making processing scripts a lot easier
to write.  This is a result of running a workshop at foss4g in Australia
last week with Nyall and the feeling that it was just a little too hard for
what should be an easier process.  We had a brainstorming after the session
and have come up with some ideas to make this process a lot easier on
Python devs.

Would really love any feedback anyone has.

https://github.com/qgis/QGIS-Enhancement-Proposals/issues/134

Regards,
Nathan
___
QGIS-Developer mailing list
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] Error with hdf5.dll on Windows build.

[Nathan Woodrow]

Thanks Jurgen.  That has fixed it.

On Thu, Oct 11, 2018 at 10:09 PM Jürgen E. Fischer  wrote:

> Hi Nathan,
>
> On Mon, 01. Oct 2018 at 20:23:42 +1000, Nathan Woodrow wrote:
> > This is on 32bit but really I should setup a 64bit build and that might
> fix
> > the issue, plus I really should do that anyway.
>
> > For now I will just override the path in cmake like Martin said just so I
> > can finish this task off while I setup my 64bit build.
>
> I've just hit this on an old vm that still had CMake 3.7.1 - upgrading to
> 3.12
> fixed this (but I guess 3.8 would also have been new enough).
>
>
> 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-Developer mailing list
> 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] For info: Travis now has supports Windows

[Nathan Woodrow]

Oh so OSGeo4w stuff is already in chocolaty?

On Thu, Oct 18, 2018 at 1:23 AM Peter Petrik <
peter.pet...@lutraconsulting.co.uk> wrote:

> Hello,
>
> we managed to add Travis Windows build for MDAL
> . If you are interested, best is
> to look at .travis.yml
>  and
> scripts/travis/windows
> .
> The libraries (GDAL, NetCDF, HDF5, ...) are taken from OSGeo4W which is
> already included in https://chocolatey.org.
>
> Peter
>
> On Mon, Oct 15, 2018 at 5:35 PM Denis Rouzaud 
> wrote:
>
>> That's great news, thanks for the info!
>>
>> Le ven. 12 oct. 2018 à 09:47, Tom Chadwin  a
>> écrit :
>>
>>> Run your single test suite on all major platforms (early release):
>>>
>>>
>>> https://blog.travis-ci.com/2018-10-11-windows-early-release?utm_source=twitter_medium=web_campaign=windows_early_release
>>>
>>> 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
>>
>> --
>>
>> 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
___
QGIS-Developer mailing list
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] Error with hdf5.dll on Windows build.

[Nathan Woodrow]

Hey,

This is on 32bit but really I should setup a 64bit build and that might fix
the issue, plus I really should do that anyway.

For now I will just override the path in cmake like Martin said just so I
can finish this task off while I setup my 64bit build.

- Nathan

On Mon, Oct 1, 2018 at 7:42 PM Jürgen E. Fischer  wrote:

> Hi Nathan,
>
> On Mon, 01. Oct 2018 at 12:13:21 +1000, Nathan Woodrow wrote:
> > Do you have this issue with the nightly builds?  Maybe something missing
> > local here?
>
> No, sorry.  And it doesn't ring a bell.
>
>
> > > C:\OSGeo4W\bin\hdf5.dll : fatal error LNK1107: invalid or corrupt file:
> > > cannot read at 0x2B0
>
> Is that 32 or 64 bit?   Did you perhaps install 64bit to C:\OSGeo4W?
> Looks like c:/OSGeo4W64/share/cmake/hdf5/hdf5-targets-release.cmake has
> OSGeo4W64 in it.
>
> 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-Developer mailing list
> 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] Error with hdf5.dll on Windows build.

[Nathan Woodrow]

Jurgen,

Do you have this issue with the nightly builds?  Maybe something missing
local here?

Regards,
Nathan

On Sat, Sep 29, 2018 at 2:54 PM Nathan Woodrow  wrote:

> Hi,
>
> Trying to build on Windows for master I'm getting the following:
>
> C:\OSGeo4W\bin\hdf5.dll : fatal error LNK1107: invalid or corrupt file:
> cannot read at 0x2B0
>
> It looks like cmake is trying to use that in the scripts and not the lib
> file but I can't see why it wants to do that.
>
> Any thoughts?
>
>
>
> - Nathan
>
___
QGIS-Developer mailing list
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] Error with hdf5.dll on Windows build.

[Nathan Woodrow]

Hi,

Trying to build on Windows for master I'm getting the following:

C:\OSGeo4W\bin\hdf5.dll : fatal error LNK1107: invalid or corrupt file:
cannot read at 0x2B0

It looks like cmake is trying to use that in the scripts and not the lib
file but I can't see why it wants to do that.

Any thoughts?



- Nathan
___
QGIS-Developer mailing list
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] Gentle request: please be careful with 2.18 backports

[Nathan Woodrow]

+1. Stable LTR is super important

On Mon, Jul 16, 2018 at 7:04 PM Nyall Dawson  wrote:

> On Mon, 16 Jul 2018 at 14:52, Paolo Cavallini 
> wrote:
> >
> > Hi all,
> >
> > Il 16/07/2018 00:20, Nyall Dawson ha scritto:
> >
> > > (Possibly we should consider switching on github branch protection
> > > here, blocking direct commits and requiring a minimum of 2 or 3
> > > 'acceptable' reviews from core devs on PRs?)
> >
> > this proposal makes sense to me - do you think it is realistically
> > feasible with our forces?
>
> I think so. There's enough core developers who are active on a near
> daily basis to mean that this should not be a major inconvenience. And
> I for one am willing to trade some minor inconvenience for a stabler
> LTR.
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] 32 by 3.2?

[Nathan Woodrow]

ohh that reminds me I have 100 new things coming so I might just open a PR
for all of those right now...

:P

On Tue, May 8, 2018 at 4:16 PM, Nyall Dawson  wrote:

> On 8 May 2018 at 09:15, Nyall Dawson  wrote:
> > Hi all,
> >
> > It's no surprise to anyone familiar with the QGIS project that we've
> > got an issue with the Pull Request queue. It's been slowly growing
> > over time, recently hitting over 150 open requests!
>
> Progress report - we're down to 83, thanks to some fantastic efforts today!
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Sentry support for QGIS crashes / minidumps

[Nathan Woodrow]

Hey Tim,

I added a crash handler in 3.0 for Windows at least and it lead to a few
good fixes.  I will checkout the stuff you posted to see if we can
intergrate it into what I already have there.

Nathan

On Thu, 3 May 2018, 4:43 pm Tim Sutton,  wrote:

> Hi All
>
>
> For many years we have used sentry (http://sentry.io) in our python
> projects to systematically collect, review and prioritise issues raised in
> our python projects. Sentry.io is open source (plus they offer a
> commercially hosted service). At Kartoza we run our own instance under
> docker / rancher.
>
> In the last Nødebo hackfest, we discussed the possibility of using
> something like Sentry for QGIS so that we could better understand where our
> users encounter crashes and proactively fix them. I subsequently went and
> researched whether Sentry.io has support for mini dumps / c++ crash
> handling and at the time it did not have so I parked thinking about it
> there.
>
> Yesterday I got a sentry updates newsletter and noticed that they have now
> added C++  support (currently in beta):
>
> https://blog.sentry.io/2018/04/17/introducing-minidump-support
>
> I know I am not alone when I run training courses offering this advice:
> “Save your project regularly, QGIS will probably crash at some point”. I
> really hate saying that but we have never had a systematic way of seeing
> where QGIS is crashing for our users and fixing this crash points. As we
> lead up to 3.4 LTR later this year, having good crash metrics and fixing
> the most common crash points will allow us to have a release that we can be
> confident works well for our users with out crashing during trivial
> operations.
>
> Perhaps one of our fine developers might like to pitch this as a QGIS
> Grant proposal (submission period closes 13 May 2018)?
>
>
> http://blog.qgis.org/2018/04/15/qgis-grants-3-call-for-grant-proposals-2018/
>
> I’d be happy to help set up our own sentry.io instance on QGIS
> infrastructure. We could also use that instance to receive tracebacks from
> the python bits of our code….
>
> Regards
>
> Tim
>
> —
>
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org
>
> 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
>
> ___
> QGIS-Developer mailing list
> 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] QEP: Projects in PostgreSQL

[Nathan Woodrow]

>
> this is always a huge issue with us since we work a lot in areas with very
> poor or no internet connection thus projects have to be loaded on our
> personal computers or external hardrives.
> also when you give a session to a client you always have to go into the
> project file and change the directory names.


Hey Syd,

QGIS has the option (on by default) to save as everything as relative paths
which is better to make projects portable

- Nathan.

On Tue, Mar 20, 2018 at 10:17 PM, Syd Visser  wrote:

> Martin
>
> a general comment on
>
> “All references to files will be saved as absolute paths “
>
>
> why does things have to be absolute path especially if you eventually will
> design for Geopackage that is suppose to simplify portability
>
> can the Path not be divided into two separate names
>
> 1) one that is easily changed like a computer home directory which changes
> depending on computer used
>
> 2) project and all of its sub-directories that should not change
>
> this is always a huge issue with us since we work a lot in areas with very
> poor or no internet connection thus projects have to be loaded on our
> personal computers or external hardrives.
>
> also when you give a session to a client you always have to go into the
> project file and change the directory names.
>
> QGIS is not the only program that has this issue and i never quite
> understood why it was done this way maybe there is a explanation besides
> its simpler for programers.
>
> thanks
>
> Syd
>
>
> *Syd (Sipke) Visser, P.Geo.*
> President, Snr. Geophysicist/Geologist
>
> Tel: 1 (604) 582-1100
> Cell: 1 (604) 813-1440
> s...@sjgeophysics.com
> www.sjgeophysics.com
>
>
> 
> On 2018-03-19 07:09 AM, Martin Dobias wrote:
>
> Hi everyone
>
> Here is a new proposal to add support for storage of QGIS projects
> inside PostgreSQL (and possibly in other backends in the future):
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/118
>
> Any comments would be highly appreciated!
>
> Cheers
> Martin
> ___
> 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
>
___
QGIS-Developer mailing list
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 qgd files

[Nathan Woodrow]

Haha. I was going to start prototyping this idea next week.  I will start a
QEP at some stage this week to collect ideas.

- Nathan

On Tue, Mar 6, 2018 at 6:31 PM, Paolo Cavallini 
wrote:

> Il 06/03/2018 09:29, Alessandro Pasotti ha scritto:
> > Maybe out of scope but I'd like to see an abstraction on top of
> > QgsProject to be able to load the project from different sources, for
> > instance a REST API, or a gpkg.
>
> right - or a PostgeSQL, as well.
> all the best.
>
> --
> Paolo Cavallini - 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
>
___
QGIS-Developer mailing list
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)

[Nathan Woodrow]

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  wrote:
>
>> Hi
>>
>> On 03 Mar 2018, at 20:43, Jürgen E. Fischer  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
>
___
QGIS-Developer mailing list
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)

[Nathan Woodrow]

Hey Carlo,

Right I guess the first one is a package issue for unix type installs. On
Windows this is fine as we can run different versions all the time but is a
good point for Linux, etc.

Regarding .qgis2 and .qgis3 This is already isolated in QGIS 3 as the
settings and plugins are now all stored in the appdata folder for the user
along with a folder for each project.  Use Settings -> User Profile  to see
what I mean.  This means you can run QGIS 2 and 3 and they don't mess each
others settings etc up.

Regards,
Nathan

On Sun, Mar 4, 2018 at 12:41 AM, Carlo A. Bertelli (Charta s.r.l.) <
carlo.berte...@gmail.com> wrote:

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

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

[Nathan Woodrow]

Hi,

I'm not sure what you mean. Could you explain with an example.

Regards,
Nathan

On 3 Mar. 2018 9:43 pm, "Carlo A. Bertelli (Charta s.r.l.)" <
carlo.berte...@gmail.com> 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?
> 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
>
___
QGIS-Developer mailing list
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] Changelog for 3.2 now active

[Nathan Woodrow]

Hey all,

The changelog page for 3.2 is now active.  Would be good if we can start
adding entries as we make changes so we don't have to wait until right at
the end like 3 :)


http://changelog.qgis.org/en/qgis/version/3.2.0/

Regards,
Nathan
___
QGIS-Developer mailing list
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] Sign in options for readmine

[Nathan Woodrow]

Hey,

If we don't move off Redmine in the near future (although I do a see a
GitLab/Github move inevitable) what sign in options do we have that we can
implement for our sites?  If we can't move off Redmine it would be nice if
we could make the sign in process for issues.qgis.org and plugins.qgis.org
a more pleasant one.

Is it possible to wire in Gtihub, Facebook, Google, and all those kinds of
providers into the site? If so what kind of work is required for that to
happen.

Forcing users to jump through too many hoops before even getting a login
does a disservice to those we want to keep happy and puts off a lot of new
users.  Looking at our contribution jump for the project is proof that
barrier to entry being low is a good thing.

Regards,
Nathan
___
QGIS-Developer mailing list
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] Building sip bindings on Windows 64 bit

[Nathan Woodrow]

Hey,

Anyone else seen this error before trying to build bindings on a 64 bit
build.

c:\osgeo4w64\apps\python36\include\pyconfig.h(403): note: see previous
definition of 'HAVE_DIRECT_H'

C:\Users\Nathan\dev\build\python\core\sip_corepart0.cpp(168592): fatal
error C1001: An internal error has occurred in the compiler.

(compiler file 'msc1.cpp', line 1468)

To work around this problem, try simplifying or changing the program near
the locations listed above.

Please choose the Technical Support command on the Visual C++

I don't seem to get it on 32 bit build but always on a 64 bit build.

Thoughts?

- Nathan
___
QGIS-Developer mailing list
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] Last call for switching to github issue tracker

[Nathan Woodrow]

Hey,

You can include me on the +1.

On Wed, Jan 17, 2018 at 11:34 PM, Denis Rouzaud 
wrote:

> Hi all,
>
> I'd like to move on a bit the discussion.
>
> I'll try to summarize (and to be fair and honest):
>
> * The desire to switch to Github is strong
> 1 against: Sandro
> 5 neutral (or did not pronounce): Jürgen, Andreas, Richard, Paolo, Nyall
> 9 for: Borys, Matthias, Tom, Jorge, Régis, Bernard (says Redmine sucks),
> Loic, Tisharm and myself
>
> * But among those who spoke. I was hoping for a broader response.
>
> * I think we shouldn't mix switching to github (for technical reason) with
> switching to gitlab or so (for ethical reason). My original call was mainly
> for technical reasons and I believe, the end-users should decide on this.
>
> * As stated, ethical reason should rely on the PSC. Feel free to call for
> it.
>
> * I believe that we should first decide on what to do and next find the
> technical (and financial) solutions. And not the other way around.
>
> * Jorge volunteered to work on the topic.
>
> Additional **personal** notes:
>
> * I would be against moving all issues to github. That doesn't mean losing
> our history: let's just keep redmine online but locked. This has to be
> discussed and decided after deciding to move to github.
>
> * Another upcoming issue we HAVE to take care of: soon the PR number in GH
> will catch up with the issue number in Redmineso bugfix commits will
> link to an unrelated PR... Keeping things untouched by fear of losing
> history is a suicide!
>
>
> Can we make a decision, and in this order:
> 1. decide to move (but to be applied if following questions are made
> possible)
> 2. what/when to move (empty list or everything or open issues, before the
> release, etc.)
> 3. how to move (volunteer, grant proposal, etc)
>
> And if we realize the decision is not feasible: we start again the
> procedure by stating we cannot do it.
> It would be useless to spend hours on trying to migrate the issues if we
> decide to start with an empty list -- just to illustrate.
>
> What is next?
> A loomio vote for this?
>
> Cheers,
>
> Denis
>
> Le ven. 12 janv. 2018 à 09:52, Denis Rouzaud  a
> écrit :
>
>> Hi all,
>>
>> I'ld like to raise a last call to switch to github issue tracker before
>> the release.
>> I'd like to summarize briefly why.
>>
>> Pros (to me):
>> - integration with code and mainly with PR
>> - avoid multiplication of platforms
>> - so much more powerful (attachment, text formatting, referecing
>> issue/PR, pinging people, fitlering/searching/tagging, possibility to
>> plugin external issue management such as zenhub or others)
>> - so much more responsive, mobile friendy and easy to use
>> - lower infrstructure management on QGIS team (would be available for
>> other stuff)
>> - opportunity to clean the list
>>
>> A proof that current situation is sub-optimal:
>> - people are pointing to code issues directly in comments of commits on
>> github rather than creating an issue (high chance of getting lost)
>> - people send mail to the mailing saying they have created an issue (sic)
>> - people creates new gitub repo for creating issue lists (sic again): see
>> qgis 3 API or UX changes
>> - mantra thing is a nightmare for new comers
>>
>> Why I don't agree on the raised issues to not to move to github:
>> - migration of existing issues: we have migrated a to a new redmine which
>> should make migration easier [0].
>> - Github has a close-source: there is an API and existing tools to
>> migrate to other issue tracker [1]. I guess it leads down to pragmatic vs
>> ethical matters.
>>
>> I would be in favor of using a semi-automatic migration:
>> - move all open tickets
>> - propose a tool to migrate others on demand: like a one-click process to
>> move the features.
>> But this can be decided afterwards.
>>
>> I know PSC is (was?) against it, but I feel the majority of devs (and new
>> issue posters) are for it.
>> Sorry to hassle on the topic. Let me know if I shall shut-up forever. Or
>> raise your hand :)
>>
>> Or can we setup a loomio vote directly???
>>
>> Best wishes,
>> Denis
>>
>> [0] https://github.com/gmontard/issue-sync-redmine-github
>> [1] Github importer for Gitlab: https://docs.gitlab.com/ee/
>> user/project/import/github.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

Re: [QGIS-Developer] Fresh QGIS3 misses all kind of 'default' options on first start

[Nathan Woodrow]

I will have a look at what options we have next Monday hopefully.

On Wed., 10 Jan. 2018, 10:40 pm Jorge Gustavo Rocha, 
wrote:

> Hi Richard,
>
> Good point!
>
> We have in QGIS3 a new qgis_global_settings.ini file where we can put
> global default settings. These global settings can be override later by
> the users.
>
> I think we need to start populating this file with reasonable settings.
>
> You might suggest some of those settings to start with.
>
> Regards,
>
> Jorge Gustavo
>
> On 10-01-2018 11:53, Richard Duivenvoorde wrote:
> >
> > Hi Devs,
> >
> > Currently if you start QGIS3 for the first time, all kind of default
> > options (from the Options Dialog) are not yet 'saved' to QgsSettings().
> >
> > To test:
> > - remove ~/.share/local/QGIS
> > - start QGIS
> > - choose 'I want a clean start. Don't import my QGIS 2 settings.'
> >
> > Now in Python console type:
> >
> > QgsSettings().value( "help/helpSearchPath" )
> > which will return an emtpy list (of search paths)
> >
> > Open Settings/Options/System properties and see there is:
> > https://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/
> > in Documentation paths there.
> >
> > NOW click OK and
> >
>  QgsSettings().value( "help/helpSearchPath" )
> > ['
> https://docs.qgis.org/$qgis_short_version/$qgis_locale/docs/user_manual/']
> >
> > So Question: is there a way to 'silently' save all those options for a
> > fresh user? I'm not so familiar with how those dialogs are constructed,
> > so can we 'submit' all tabs in one? Or should we submit them one by one?
> >
> > Ah, it appears that clicking OK once from whatever tab will 'save' (at
> > least this path) to QgsSettings()...
> >
> > Otherwise, current situation will be that a new user upon clicking
> > any(!) help button will always be shown with the daft "Oops! QGIS help
> > is currently not available. This is likely because: ... " message.
> >
> > See also:
> >
> > https://issues.qgis.org/issues/17670
> >
> > https://issues.qgis.org/issues/17598
> >
> > 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
> >
>
> J. Gustavo
> --
> Jorge Gustavo Rocha
> Departamento de Informática
> Universidade do Minho
> 4710-057 Braga
> Tel: +351 253604480
> Fax: +351 253604471
> Móvel: +351 910333888
> skype: nabocudnosor
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Rename Style manager to Symbol manager in 3.0?

[Nathan Woodrow]

+1.  That has always bugged me.

- Nathan

On Wed, Jan 3, 2018 at 11:15 AM, Alexandre Neto 
wrote:

> While writing some tutorials, I have noticed some possible nomenclature
> confusion between Symbols (as compounds of stacked markers, lines, fills
> outlines and color ramps) and Styles (a vector layer symbols and labels
> settings).
>
> We currently have to places we call "Style manager":
> 1. The symbols library that we open by going to Options > Style Manager;
> 2. The Style manager tab in the Layer Styling panel.
>
> I think that the first one should be renamed to "Symbols manager", since
> it exclusively allows to create, edit, group, import and export symbols,
> and not styles.
>
> On the other hand, the Style manager in the Layer Styling panel allows to
> create, manage, load, save as default the layers' styles (unfortunatly it
> does not allow to save styles as we can do in properties).
>
> Any strong opinions about this?
>
> Thanks.
>
> Alexandre Neto
>
>
> --
> Alexandre Neto
> -
> @AlexNetoGeo
> http://sigsemgrilhetas.wordpress.com
> http://gisunchained.wordpress.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

Re: [QGIS-Developer] QGIS 3.0 Soft Feature Freeze

[Nathan Woodrow]

I think we really need some more bug fixing time.  I noticed all the
layouts stuff from Nyall is now there but given the large amount of work
more time would be good IMO.

- Nathan

On Tue, Jan 2, 2018 at 7:45 PM, Tim Sutton  wrote:

> Hi
>
> For my part I think we can go ahead and set a date for the freeze (e.g.
> Friday) - Etienne still needs to commit the last metadata serialisation
> stuff but he has kindly come back from leave for a day to finish that.
> Stephané wanted to merge the OGC filters stuff which is fine for me.
>
> Do we want  have some additional bug fix only time before we make the
> actual release - perhaps targeting the release for the end of Jan? I
> haven't looked in detail what blocking issues there are but from Mac point
> of view the GRASS processing tools still don’t work which is a bit of a
> blocker IMHO.
>
> Regards
>
> Tim
>
>
> On 02 Jan 2018, at 11:31, Paolo Cavallini  wrote:
>
> Hi all,
> for the first time, a good part of developers are uncertain about the
> need to postpone the freeze. IMHO it is better to discuss about his in
> the list. From my point of view, we should postpone it only if there is
> a real, strong necessity, which does not seem the case now.
> Opinions?
> All the best.
> --
> Paolo Cavallini - 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
>
>
> —
>
>
>
>
>
>
> *Tim Sutton*
>
> *Co-founder:* Kartoza
> *Project chair:* QGIS.org
>
> 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
>
>
> ___
> QGIS-Developer mailing list
> 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] The left hand doesn't know what the right hand is doing

[Nathan Woodrow]

Hey,

What OS are you running your testing on? If you are on Windows grab the
qgis-dev-pdb package so the crash will give you more info and we can get it
fixed.

Regards,
Nathan

On Mon, Dec 18, 2017 at 4:38 PM, Patrick Dunford 
wrote:

> Sorry. I have appreciated since writing this email that you guys could not
> have foreseen how the project properties dialog box crashes because no one
> else reported that as a bug.
>
> There's a paradox (or tension) here: to get the best testing you have to
> be using this software every day to do as many things as possible. That
> creates issues when something breaks in a project file, if it's hard to fix
> easily.
>
> Every time the CRS changed I changed it back but now it crashes when I try
> to do that. The changes in layer styles that don't migrate was small
> compared to being unable to set the correct CRS on a project because the
> CRS gui crashes.
>
>
>
> On 18/12/17 18:47, Nyall Dawson wrote:
>
>> On 16 December 2017 at 22:32, Patrick Dunford 
>> wrote:
>>
>>> With a recent change in masters the project file format has been broken
>>> yet
>>> again (it seems) and now instead of recognising EPSG:3857 on project
>>> files
>>> that are not very old, it comes up as USER:100029
>>>
>>> Now ordinarily this wouldn't be an issue, just open project properties
>>> and
>>> change the CRS. Except there is a well documented bug that makes the
>>> software crash when you try to do this.
>>>
>>> As it's not possible in any way for me to fix this latest inability to
>>> recognise the CRS from the previous project file from a slightly earlier
>>> version of master, maybe it would be helpful to document how we could
>>> actually insert the CRS into the project file by hand so it is correct.
>>>
>>> Patrick,
>>
>> Your bug testing is very much appreciated - the way you word your
>> email subjects, not so.
>>
>> Nyall
>>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] New API - Easier restore of dialog positions.

[Nathan Woodrow]

Hey all,

Just thought I would make everyone aware of a quick time saver for
restoring dialog/widget positions added in master.  This is mainly to
remove the pain of having to do restoreGeometry()/saveGeometry() in every
widget and remembering the naming we use for settings keys.  It's also
about fixing consistency inside the application so every dialog remembers
their state correctly.

The new API is:

  QgsGui::instance()->enableAutoGeometryRestore( this );

This should go just after   setupUi( this );

Here is an example:


https://github.com/qgis/QGIS/blob/master/src/gui/qgsexpressionbuilderdialog.cpp#L26

You can then remove any calls to restoreGeometry() and saveGeometry() in
your widget. Diff of an example:


https://github.com/qgis/QGIS/commit/57dc9deb06a8f4474429b2956008188292588a1b#diff-b4d61d74d8a5b5319106d746b54d378bL21

Unless there is a good reason not, all new widgets should be using this
code when you write them. I would like to ask if people can start to port
existing widgets if they are already editing that code.  I will be doing a
bulk update when I can but I suspect I will miss some and group effort is
better in case I run out of time.

Regards,
Nathan
___
QGIS-Developer mailing list
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] Improving usability of "Project Home" in browser?

[Nathan Woodrow]

.. listen to layers loaded on the project, pull the source from the layer,
resolve folder...

Maybe I'm missing something here

On Thu, Dec 14, 2017 at 10:41 AM, Nyall Dawson <nyall.daw...@gmail.com>
wrote:

> On 14 December 2017 at 10:38, Nathan Woodrow <madman...@gmail.com> wrote:
> >> I'm guessing you mean "scan all folders used in the project file". If
> >> so, good idea! Unfortunately non-trivial... but something we
> >> could/should do as a future enhancement to the Project Home item.
> >
> >
> > Isn't project home only set after the project is loaded?  So we will know
> > the folders used as the project loads...
> >
>
> How so? Am I missing something obvious?
>
> Nyall
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Improving usability of "Project Home" in browser?

[Nathan Woodrow]

>
> I'm guessing you mean "scan all folders used in the project file". If
> so, good idea! Unfortunately non-trivial... but something we
> could/should do as a future enhancement to the Project Home item.


Isn't project home only set after the project is loaded?  So we will know
the folders used as the project loads...

On Thu, Dec 14, 2017 at 10:34 AM, Nyall Dawson <nyall.daw...@gmail.com>
wrote:

> On 14 December 2017 at 10:26, Nathan Woodrow <madman...@gmail.com> wrote:
> > One option might be to scan all folders used in the profile file and add
> > each one to the project home folder so you have quick access to all
> folders
> > that are currently used.
> >
>
> I'm guessing you mean "scan all folders used in the project file". If
> so, good idea! Unfortunately non-trivial... but something we
> could/should do as a future enhancement to the Project Home item.
>
> I also don't think it fully addresses my use case, since it would only
> show utilised folders. So e.g. if I get new data and place it in a new
> folder under "incoming", it won't be shown there.
>
> Nyall
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Improving usability of "Project Home" in browser?

[Nathan Woodrow]

One option might be to scan all folders used in the profile file and add
each one to the project home folder so you have quick access to all folders
that are currently used.

- Nathan

On Thu, Dec 14, 2017 at 10:22 AM, Nyall Dawson 
wrote:

> Hey all,
>
> I'm seeking ideas on how we can improve the usefulness of the "Project
> Home" item in the browser panel.
>
> Currently, this item is shown after opening a project, and consists of
> a directory item showing the contents of the same folder in which the
> .qgs project file is stored.
>
> I really like the idea of this Project Home item, but I can't make use
> of it because at none of my current workplaces are the .qgs project
> files stored in the root directory of a project. A more common
> structure is something like:
>
> project_001\
> project_001\incoming_data\
> project_001\reports
> project_001\outgoing
> project_001\data
> project_001\projects\my_qgis_file.qgs
>
> In this case the shortcut to the .qgs folder doesn't help - because
> none of the interesting stuff is located there. I suspect this isn't
> an uncommon scenario, and that a lot of workplaces don't store .qgs
> files in the root directory of projects.
>
> Has anyone got any ideas of how we could improve the Project Home item
> to meet this scenario? Best I can come up with is to add a new setting
> (booo) in Project Properties to manually set the project home
> folder...
>
> (Note - In an ideal world, ALL file open/save dialogs would have a
> shortcut to this project home folder available too. It's possible in
> Windows (see e.g.
> http://www.pbjzone.com/images/VS2010_open_dialog.png) - but not
> exposed via Qt (yet) )
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Settings migration from QGIS 2 to 3

[Nathan Woodrow]

Hey,

Yes, a dialog is on the todo list just need some time to finish it.
Hopefully next monday.

On Fri, Dec 8, 2017 at 11:22 AM, Olivier Dalang <olivier.dal...@gmail.com>
wrote:

> Hi !
>
> I think the migration should be optional (eg. by displaying a message on
> first start if there's a QGIS2 conf). I'd say this is what most programs do
> for major updates. This would allow users who are a bit messy (like me) to
> take advantage of QGIS3 to make a clean start.
>
> Also, you'd be able to easily reset to factory settings by wiping the
> whole QGIS3 directory (actually it's by trying to do that and not
> understanding why the browser kept my providers that I learned that config
> was migrated).
>
> What do you think ? Should I open a feature request ?
>
> Still the feature will definitely be very useful for most users ! Thank
> you very much for developing it :)
>
> Olivier
>
>
> On Wed, Nov 1, 2017 at 9:50 PM, Stefan Blumentrath <
> stefan.blumentr...@nina.no> wrote:
>
>> Thanks so much Alessandro!
>>
>>
>>
>> Having read some documentation:
>>
>> https://connect.boundlessgeo.com/docs/desktop/1.1.0/system_a
>> dmins/globalsettings.html
>>
>> I am sure that this will be a cool new feature in QGIS 3 that will be
>> very much appreciated by organisations!!!
>>
>>
>>
>> Thanks again for the hint!
>>
>>
>>
>> Cheers
>>
>> Stefan
>>
>>
>>
>> *From:* Alessandro Pasotti [mailto:apaso...@gmail.com]
>> *Sent:* onsdag 1. november 2017 09.30
>> *To:* Stefan Blumentrath <stefan.blumentr...@nina.no>
>> *Cc:* Nathan Woodrow <madman...@gmail.com>; Borys Jurgiel <
>> li...@borysjurgiel.pl>; Richard Duivenvoorde <rich...@duif.net>;
>> qgis-developer@lists.osgeo.org
>>
>> *Subject:* Re: [QGIS-Developer] Settings migration from QGIS 2 to 3
>>
>>
>>
>>
>> Stefan, you may try to use global settings for shared user settings, you
>> can specify the global settings file path in several ways (and it could
>> even be a shared network folder).
>>
>> See:
>> https://github.com/qgis/QGIS/blob/master/src/app/main.cpp#L131
>>
>> and:
>> https://github.com/qgis/QGIS/blob/master/src/app/main.cpp#L831
>>
>> the global settings format is exactly the same of the user settings file:
>> INI.
>>
>> Hope this helps.
>>
>>
>>
>>
>>
>> On Tue, Oct 31, 2017 at 11:19 PM, Stefan Blumentrath <
>> stefan.blumentr...@nina.no> wrote:
>>
>> Dear all,
>>
>>
>>
>> I am really looking forward to seeing all QGIS configuration in ini-files
>> and that registry will be abandoned on Windows in QGIS 3!
>>
>> That will be a great improvement, esp. from a sys-admin perspective!
>>
>>
>>
>> In this consolidation context I was wondering I would be possible to
>> prepare for:
>>
>> -  Use of relative path (https://issues.qgis.org/issues/12623)
>>
>> -  Usage of variables in the ini file
>>
>>
>>
>> I have been earlier thinking about “versioning” of ini files, so that
>> updates (e.g. changes in OWS URLs) can be passed to all users as a sort of
>> “diff/merge” without damaging individual adjustments they might have made.
>>
>> Background is that the Norwegian mapping authority provides a “Service
>> feed” (https://register.geonorge.no/register/tjenestevarsler) where all
>> OWS changes are announced… I would love to be able to just apply those
>> changes to all our users…
>>
>>
>>
>> No idea if such a thing could be fostered by the way settings are stored
>> in the ini files?
>>
>>
>>
>> Cheers
>>
>> Stefan
>>
>>
>>
>> *From:* QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org] *On
>> Behalf Of *Nathan Woodrow
>> *Sent:* mandag 30. oktober 2017 15.27
>> *To:* Borys Jurgiel <li...@borysjurgiel.pl>
>> *Cc:* Richard Duivenvoorde <rich...@duif.net>;
>> qgis-developer@lists.osgeo.org
>> *Subject:* Re: [QGIS-Developer] Settings migration from QGIS 2 to 3
>>
>>
>>
>> Ah right.  I'm happy with whatever there.
>>
>>
>>
>> On Tue, Oct 31, 2017 at 12:25 AM, Borys Jurgiel <li...@borysjurgiel.pl>
>> wrote:
>>
>> Dnia wtorek, 31 października 2017 00:19:49 Nathan Woodrow pisze:
>> > Hey,
>> >
>> > > There are over 100 keys there, are we going to migrate them all from
>> >
>> > Window

Re: [QGIS-Developer] QGIS 2.99 nightly: profiles folder location

[Nathan Woodrow]

>
> Hey,
>



> I get this debug message for a simple PyQGIS script:
> ../../src/core/qgscoordinatereferencesystem.cpp: 924: (getRecord) [6ms]
> user qgis.db not found
> Not being familiar with the QGIS codebase it seems to me that there are
> two competing settings:
> - qgisSettingsDirPath() gives me '/home/user/.local/share/profi
> les/default'
> - but https://qgis.org/api/qgsapplication_8cpp_source.html#l00127 checks
> for the environment variable (which is empty on my system) and falls back
> to which is accorrding to http://doc.qt.io/qt-5/qstandardpaths.html
>  "~/.local/share/", "/usr/local/share/",
> "/usr/share/"
> Indeed I have a qgis.db in  
> /home/user/.local/share/QGIS/QGIS3/profiles/default
> and if I create via the GUI "Settings > Profile > New profile" another one
> it shows up in /home/user/.local/share/QGIS/QGIS3/profiles/ .
> This is is clearly different from what qgisSettingsDirPath() returns.


Yes this looks like a bug to me.  I will take a look.

Regards,
Nathan

On Sat, Dec 2, 2017 at 9:06 PM, Christian Prior-Mamulyan <
cprior+q...@gmail.com> wrote:

> Hello,
>
> first post of mine, am a software support engineer without much QGIS
> knowhow but "figure-it-out" drive. Here I have:
>
>
> 1) some kind of a bug report
> 2) request for guidance
>
>
> ad 1)
>
> I have installed (and updated) the nightly build on a clean Ubuntu 16.04
> (container with systemd-nspawn) with these apt sources:
> $  cat /etc/apt/sources.list.d/qgis.list
> deb http://qgis.org/ubuntugis-nightly xenial main
> deb-src http://qgis.org/ubuntugis-nightly xenial main
> deb http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable/ubuntu xenial
> main
>
>
> I get this debug message for a simple PyQGIS script:
> ../../src/core/qgscoordinatereferencesystem.cpp: 924: (getRecord) [6ms]
> user qgis.db not found
>
> Not being familiar with the QGIS codebase it seems to me that there are
> two competing settings:
>
> - qgisSettingsDirPath() gives me '/home/user/.local/share/profi
> les/default'
> - but https://qgis.org/api/qgsapplication_8cpp_source.html#l00127 checks
> for the environment variable (which is empty on my system) and falls back
> to which is accorrding to http://doc.qt.io/qt-5/qstandardpaths.html
>  "~/.local/share/", "/usr/local/share/",
> "/usr/share/"
>
> Indeed I have a qgis.db in  
> /home/user/.local/share/QGIS/QGIS3/profiles/default
> and if I create via the GUI "Settings > Profile > New profile" another one
> it shows up in /home/user/.local/share/QGIS/QGIS3/profiles/ .
>
> This is is clearly different from what qgisSettingsDirPath() returns.
>
>
> PyQGIS code to reproduce the debug message "user qgis.db not found":
> In [1]: from qgis.core import *
> In [2]: crs = QgsCoordinateReferenceSystem()
> In [3]: crs.createFromProj4("+proj=ortho +lat_0=20 +lon_0=20 +x_0=0
> +y_0=0 +a=6370997 +b=6370997 +units=m +no_defs")
> ../../src/core/qgscoordinatereferencesystem.cpp: 883: (getRecord) [0ms]
> failed : /resources/srs.db does not exist!
> ../../src/core/qgscoordinatereferencesystem.cpp: 883: (getRecord) [0ms]
> failed : /resources/srs.db does not exist!
> Out[3]: True
>
>
>
> ad 2)
> Not sure if the above warrants a bug report, or if it is a package problem
> of the xenial ubuntugis-nightly packages. So:
>
> I am looking for guidance in my quest to contribute to the PyQGIS docs.
> Being new to QGIS (I need maps for a mobile app of mine) I would
> appreciate if someone experienced could guide me.
>
> Right now I am
> a) learning PyQGIS
> b) documenting working examples as Python unittest modules in
> https://github.com/cprior/sunlightmap/tree/master/applica
> tion/physical/GIS/qgis3-tests
> (whole repo under MIT, so no effort would be "lost")
>
> Started to poke around on https://gis.stackexchange.com/users/87254/cprior but
> I would be glad to have a speedier onboarding process than looking at
> "badges earned"... ;)
>
> I am willing to spend an hour each weekday for 4-6 weeks and think I could
> contribute something helpful to the PyQGIS docs.
>
>
> BR,
> Christian Prior-Mamulyan
>
> ___
> QGIS-Developer mailing list
> 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] all profile removed, still OWS connections, where stored?

[Nathan Woodrow]

There are no v2 files kept. If it's named the same it's just not updated in
the code. Settings are auto migrated from 2 to 3 into the new settings
files.

There will hopefully be a first run screen if I get time to implement it
before release.

@Richard for now make a new profile and run with that as the main one.  The
default profile is always migrated to give users a nicer first-run
experience of 3 because losing all the settings sucks.

- Nathan

On Wed, Nov 29, 2017 at 11:33 PM, Régis Haubourg 
wrote:

> Huh,
> what is the rationale behind keeping a V2 file in QGIS3? Migrating fromr
> QGIS2 shouldn't mean using the same files.
> Régis
>
> 2017-11-29 14:20 GMT+01:00 Richard Duivenvoorde :
>
>> On 29-11-17 13:51, Régis Haubourg wrote:
>> > Hi,
>> > we just realized that QGISCUSTOMIZATION2.conf is still used, it is not
>> > creating a QGISCUSTOMIZATION3.conf.
>> > I suppose it's a bug? Anyone confirms?
>> >
>> > Régis
>>
>> Régis,
>>
>> Are you sure it is actually used or is it 'migrated'.
>>
>> What I found was that if I not remove:
>> ~/.local/share/QGIS
>> and from qgis2.18:
>> ~/.qgis2
>> ~/.config/QGIS  <= this is in registry in Windows
>> then I do not startup with a clean 3.0 sheet.
>>
>> You will also end up with svg-paths to 2.18 qgis paths.
>>
>> @nathan? would it not be nicer to ask a user if he wants to bring the
>> qsettings from 2.x over to 3 or not? Only the first time this migration
>> is done isn't it?
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] all profile removed, still OWS connections, where stored?

[Nathan Woodrow]

Hey,

All profiles or just the default one? Because settings migration will be
bringing it over from 2 for the default.

On Sun., 26 Nov. 2017, 1:11 am Richard Duivenvoorde, 
wrote:

> Hi Devs,
>
> in my understanding all(!) settings and configuration is now moved to
> the profiles? So in my case:
>
> /home/richard/.local/share/QGIS
>
> isn't it?
>
> BUT if I remove that folder (= all profiles isn't it?), then I still
> have the connections I had in earlier work in my Data Browser widgets?
>
> (at the moment in my system the 'Open Profile folder' isn't working so I
> cannot check the profile folder settings...)
>
> Regards,
>
> Richard Duivenvoorde
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS-Server on Windows with IIS - missing methods in dlls

[Nathan Woodrow]

Stefan,

I think you are looking at the wrong thread. cgywin is just for running
shell scripts etc in Dev builds scripts.  We build with VS 2015

On Fri., 17 Nov. 2017, 19:22 Stefan Steiger, 
wrote:

> Why not cygwin ? Because it doesn't produce Windows native executables ...
>
>
> https://stackoverflow.com/questions/27678988/run-cygwin-built-exe-in-windows-without-cygwins-environment
>
> Use MinGW + msys instead.
>
> Strange that this still needs to be said in 2017.
>
> This explains why qgis-server didn't run on my machine...
>
>
>
>
>
> -Ursprüngliche Nachricht-
>
> Von: QGIS-Developer [mailto:qgis-developer-boun...@lists.osgeo.org
> ] Im Auftrag von Jürgen E. Fischer
>
> Gesendet: Mittwoch, 15. November 2017 10:02
>
> An: qgis-developer@lists.osgeo.org
>
> Betreff: Re: [QGIS-Developer] Merging raster-save dialog change and
> Windows workflow
>
>
>
> Hi,
>
>
>
> On Wed, 15. Nov 2017 at 01:02:48 +, Tisham Dhar wrote:
>
> > 1)  Checkout as standard on windows with git-bash (line endings are
> an
>
> > issue). Will have to try a fresh clone in WLS to see what
> difference
>
> > it makes
>
>
>
> Why not cygwin?  That's what I use and recommend.   WLS means WSL?
>
>
>
>
>
> 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-Developer mailing list
> 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] Processing Split with lines algorithm broken

[Nathan Woodrow]

IMO go with the principle of least astonishment.  I think the expected
outcome is single part features as it's not clear that you need to run
another step.

- Nathan

On Wed, Nov 15, 2017 at 2:48 PM, Nyall Dawson 
wrote:

> On 15 November 2017 at 00:33, matteo  wrote:
> > Hi devs,
> >
> > the algorithm Split with lines seems not working. No output error but
> > both lines or polygons in output are not split. The same algorithm with
> > the same data works in QGIS 2.18
>
> I suspect it's working OK, but you're hitting a change in 3.0 where
> the output of this algorithm is a multi-line, with the individual
> split parts still forming a single feature. You need to run multiparts
> to singleparts on it afterward.
>
> However
>
> This was a change I requested in
> https://github.com/qgis/QGIS/pull/3798, since it seemed like a logical
> move. Having used this algorithm extensively since (and also been
> confused in thinking that the algorithm was broken!) I'm not convinced
> this was the right move anymore, and think that we should probably
> always output single-part features from this algorithm.
>
> What's everyone's thoughts?
>
> Nyall
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS custom widgets badly placed in Osgeo4W install

[Nathan Woodrow]

Hey Denis,

We can't really put it in C:\OSGeo4W\apps\Python27\Lib\site-packages\PyQt4\uic
as it will conflict with different versions.  It would have to be in the
installed folder for each version and then set with a custom path which is
should already be doing.

- Nathan

On Tue, Nov 14, 2017 at 11:30 PM, Denis Rouzaud 
wrote:

> Hi all, mainly Jürgen I guess ;)
>
> During a course, I just realized qgis_customwidgets.py is badly placed
> preventing using QGIS custom widgets within uic.loadUiType.
>
> It is placed in
> C:\OSGeo4W\apps\qgis\python\PyQt4\uic
> while it should be in
> C:\OSGeo4W\apps\Python27\Lib\site-packages\PyQt4\uic
>
> Thanks a lot for fixing this :)
>
> Cheers,
> Denis
>
> ___
> QGIS-Developer mailing list
> 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] discuss: What's our development gameplan for 3.0 and above?

[Nathan Woodrow]

Hey,

Personally, I like using the database wrapper that Qt provide and I don't
really see much risk in using it, to be honest.
We might get better speeds going to std route which is something to
consider but I prefer an easier API over raw speed unless it's massive
speed up.

Ideally, we really need to have our own database wrapper which can sit on
top of whatever implementation we choose.  This would also allow us to add
logging of all SQL commands that are run etc.

Regards,
Nathan



On Fri, Nov 10, 2017 at 8:27 AM, Tom Chadwin 
wrote:

> Having suffered at the hands of the QtWebkit thing, I would strongly agree,
> though I guess one airways needs to evaluate the health of any dependency -
> perhaps the are instances where a Qt class is better maintained than the
> alternatives.
>
> 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
>
___
QGIS-Developer mailing list
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] Soft freeze for QGIS 3.0

[Nathan Woodrow]

Hey Tim,

If I can get the first run Welcome Screen to intro QGIS 3 ready soon do you
think I can sneak that one in.  No API changes mainly just a bit of nice UX
for first run when we release.

Not a major issue if no.

Regards,
Nathan

On Tue, Nov 7, 2017 at 8:32 AM, Tim Sutton  wrote:

> Hi All
>
> As discussed earlier, we raised the issue of when and how to freeze at the
> PSC meeting. We tried to take on board your various comments and came out
> with this recommendation:
>
> • The current master branch will be in ‘soft freeze’ with a list of
> allowed PR’s / Future PR’s related to these features:
> • Datum transform handling (https://github.com/qgis/QGIS/pull/5535)
> • SAGA Support (https://github.com/qgis/QGIS/pull/5155)
> • GRASS Support (https://github.com/qgis/QGIS/pull/5426)
> • Metadata write support to file system (https://github.com/qgis/QGIS/
> pull/5379)
> • UI Widgets for drag forms (https://github.com/qgis/QGIS/pull/5467)
> * Composer refactor ( https://github.com/qgis/QGIS/pull/5486 to drop
> bindings and new PR to come for composer refactor).
>
> Please let us know if there were other ‘must merge’ features that were
> discussed but that I missed in the list above.
>
> • We will hold a rolling vote put to core developer (on loomio.org) every
> two weeks (starting two weeks from now) with a simple question “shall we
> freeze”? Once we have quorum on that vote, we go ahead and freeze and
> Jürgen can pretty much ignore 3.x in his release planning until that vote
> passes.
> • The paid bug fixing should commence now already regardless of when the
> freeze will actually happen.
>
>
> To address specifically Mathieu’s concerns about an unspecified date in
> the future, we do not anticipate an endless feature frenzy - the ‘soft
> freeze’ should keep the timelines reasonable while still giving us a chance
> to make sure that they API changes get a chance to land.
>
>
> I hope that woks for the majority of you. If you want o make the release
> come faster, help by reviewing code in PR’s, testing new features and
> generally pointing the QGIS car towards the finish line!
>
> Regards
>
> Tim
>
>
>
>
>
>
>
> ---
>
> Tim Sutton
> QGIS Project Steering Committee Chair
> t...@qgis.org
>
>
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-psc] PROPOSAL: change how we manage the 3.0 release process

[Nathan Woodrow]

I agree.  I very much like the fixed schedule normally just with 3.0 being
such a major rework of core stuff maybe just tweaking it for this release
is the best plan.  The fixed schedule has been great for clients to know
when they are going to get a new release and what will be in it.

- Nathan

On Mon, Nov 6, 2017 at 8:10 PM, Alessandro Pasotti 
wrote:

> I agree with Matthias, having a fixed/predictable schedule is very
> important for planning, but for QGIS3 we invested so much time and efforts
> in fixing the API that it would be a pity if we miss the occasion.
>
> I would be in favor of grant some more flexibility to this 3.0 release
> while keeping the fixed release cycles.
>
> Of course we should try harder to meet the deadlines in he future major
> releases.
>
>
>
> On Mon, Nov 6, 2017 at 11:03 AM, Régis Haubourg 
> wrote:
>
>> Hi Tim,
>>
>>  I agree QGIS 3.0 is sort of an exception, we have a lot a major
>> refactoring that need to land in it.
>>
>> However, I think we should keep fixed date releases within major version
>> lifecycle, and in the same time improve our feature roadmap planning. Let
>> me explain why.
>>
>>  - Release when ready would imply that we all can announce in advance
>> what feature we will bring in each version. By now, we are not structured
>> for that I think.
>>  - Fixed date releases are very good for users, developpers and funders
>> to plan work and anticipate. It also allows to avoid those huge delays we
>> have currently in QGIS3, with too much untested nex features. Release often
>> is the key for real user testing.
>>
>> So my vote would be to allow unfixed schedule for major releases, but
>> with a better project management of critical features and API break we need
>> in it, and keep fixed date minor releases.
>>
>> My two cents,
>> Regards
>> Régis
>>
>> 2017-11-06 10:43 GMT+01:00 Tim Sutton :
>>
>>> Hi All
>>>
>>> We have our PSC meeting tonight and I have added an agenda item about
>>> feature freeze exceptions. I will respond immediately after the meeting
>>> with any decision that has been reached, or if we are not able to reach a
>>> consensus I will put it to a general members vote.
>>>
>>> As Jürgen is release manager, I would prefer that we have his agreement
>>> and buy-in (he has already stated a contrary opinion to lifting the freeze
>>> - http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-Feature
>>> -freeze-Paid-developer-activities-for-QGIS-3-0-tp5340245p5340300.html).
>>>
>>> Probably more accurately I should state that Jürgen already agreed in
>>> Girona to go to a fixed release schedule in preference to a  ‘when it is
>>> ready’ schedule as was originally planned.
>>>
>>> At the risk of severely irritating Jürgen (sorry!), why don’t we move
>>> back to a ‘release when ready’ approach which might also have the happy
>>> by-product of being less work for him since he only needs to deal with the
>>> process once when the release is deemed ready.
>>>
>>> One simple mechanism we could do is have a rolling voting member’s vote
>>> (e.g. at then end of each month) with a simple question “shall we freeze”?
>>> Once we have quorum on that vote, we go ahead and freeze and Jürgen can
>>> pretty much ignore 3.x in his release planning until that vote passes. We
>>> also have the by-product that we cannot tell our users / customers / fans
>>> when the release will be ready but by-and-large I think the outcome will be
>>> better since we all will be dancing to the same tune and we can make sure
>>> 3.0 has everything in it that we think it should have without compromises.
>>>
>>> I also propose that the paid bug fixing should commence now already
>>> regardless of when the freeze will actually happen.
>>>
>>>
>>> Our PSC meeting is at 8pm CET (sorry thats an awful time for you Nyall)
>>> and anybody is always welcome to sit in the call if you wish you raise your
>>> concerns in person (or send me any notes for things that you would like
>>> raised on your behalf).
>>>
>>>
>>> Regards
>>>
>>> Tim
>>>
>>> —
>>>
>>>
>>>
>>>
>>>
>>> *Tim Sutton*
>>>
>>> *Co-founder:* Kartoza
>>> *Project chair:* QGIS.org
>>>
>>> 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
>>>
>>> Kartoza is a merger between Linfiniti and Afrispatial
>>>
>>>
>>> ___
>>> Qgis-psc mailing list
>>> qgis-...@lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>>>
>>
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it
>
> 

Re: [QGIS-Developer] Settings migration from QGIS 2 to 3

[Nathan Woodrow]

Ah right.  I'm happy with whatever there.

On Tue, Oct 31, 2017 at 12:25 AM, Borys Jurgiel <li...@borysjurgiel.pl>
wrote:

> Dnia wtorek, 31 października 2017 00:19:49 Nathan Woodrow pisze:
> > Hey,
> >
> > > There are over 100 keys there, are we going to migrate them all from
> >
> > Windows
> > to windows, like we did with Qgis -> qgis?
> >
> > No I don't think we need to do anything for those subgroups, dropping the
> > Windows placement between version isn't a big deal.  The main core things
> > to migrate is stuff that is a pain to setup again.
>
> Sorry I was unclear. I didn't mean migrating the values, just changing the
> section for all these keys.
>
> Regards,
> Borys
>
___
QGIS-Developer mailing list
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] Settings migration from QGIS 2 to 3

[Nathan Woodrow]

> the bottom line is that you cannot rely on capitalization because of
differences in the platforms, even if by using the "ini" file like we are
doing now after Nathan's profile implementation will probably overcome this
issue (reason: The Windows registry and INI files use case-insensitive
keys).

All the platforms should now be case-insensitive I suspect given we are
using ini for everything.

On Mon, Oct 30, 2017 at 11:57 PM, Alessandro Pasotti 
wrote:

> On Mon, Oct 30, 2017 at 2:15 PM, Borys Jurgiel 
> wrote:
>
>> By the way, do we have a standard for the section naming? Now I don't
>> mean the
>> enumeration, just other top-level sections, like [PluginInstaller].
>> Should I
>> drop the camel case?
>>
>> Sorry for such detailed question, sometimes I'm too pedantic ;)
>>
>
> On the contrary: thank you for  raising this point!
>
> This is what I suggest (but no strong opinions so feel free to suggest a
> better/alternative approach):
>
> ideally the main Sections should be kept to minimum, that's why I added
> just a few of them, we can always create all the sub-sections we want
> instead of overcrowding the sections enum.
>
> For anything related to application that is not purely Gui, I would just
> use the "App" section.
>
>
>
>> Regards,
>> Borys
>>
>> Dnia poniedziałek, 30 października 2017 14:08:01 Borys Jurgiel pisze:
>> > Hi,
>> >
>> > I was updating and migrating plugin installer's settings when Alessandro
>> > suggested to create a new QgsSettings::Section::Windows enum value for
>> all
>> > the window geometries, currently placed in the [Windows] section
>> > (capitalized) [1]
>> >
>> > There are over 100 keys there, are we going to migrate them all from
>> Windows
>> > to windows, like we did with Qgis -> qgis?
>>
>
>
> Here, I would follow the Qt recommendations about naming of the setting:
> the bottom line is that you cannot rely on capitalization because of
> differences in the platforms, even if by using the "ini" file like we are
> doing now after Nathan's profile implementation will probably overcome this
> issue (reason: The Windows registry and INI files use case-insensitive
> keys).
>
> So, I'd vote for sticking to an all-lowercase underscore-separated syntax
> but as I said there is not anymore a technical reason for doing so.
>
> see: http://doc.qt.io/qt-5/qsettings.html#section-and-key-syntax
>
>
>
>
>> >
>> > If so, I'll create the new enum value and port a few keys there, but I
>> don't
>> > want to mess if other keys are going to stay in the capitalized
>> [Windows].
>> >
>> > Regards,
>> > Borys
>> >
>> > [1] https://github.com/qgis/QGIS/pull/5494#discussion_r147628437
>> > ___
>> > QGIS-Developer mailing list
>> > 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
>>
>
>
>
> --
> 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
>
___
QGIS-Developer mailing list
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] Settings migration from QGIS 2 to 3

[Nathan Woodrow]

Hey,

> There are over 100 keys there, are we going to migrate them all from
Windows
to windows, like we did with Qgis -> qgis?

No I don't think we need to do anything for those subgroups, dropping the
Windows placement between version isn't a big deal.  The main core things
to migrate is stuff that is a pain to setup again.

- Natha

On Mon, Oct 30, 2017 at 11:08 PM, Borys Jurgiel 
wrote:

> Hi,
>
> I was updating and migrating plugin installer's settings when Alessandro
> suggested to create a new QgsSettings::Section::Windows enum value for all
> the
> window geometries, currently placed in the [Windows] section (capitalized)
> [1]
>
> There are over 100 keys there, are we going to migrate them all from
> Windows
> to windows, like we did with Qgis -> qgis?
>
> If so, I'll create the new enum value and port a few keys there, but I
> don't
> want to mess if other keys are going to stay in the capitalized [Windows].
>
> Regards,
> Borys
>
> [1] https://github.com/qgis/QGIS/pull/5494#discussion_r147628437
>
___
QGIS-Developer mailing list
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] Speed up building time after git checkout

[Nathan Woodrow]

Using ccache? That normally cuts down build times.

On Sun., 29 Oct. 2017, 3:12 am ,  wrote:

> Hi,
>
> I wrote almost the same message few days ago and forgot to send it. I'm
> really interested in the answer of this, fed up with waiting so long
> anytime i checkout a new branch, regardless the diff.
> I didn't know the ˋninja qgisˋ command (used to ˋninja -j8ˋ as stated in
> the install doc). Will give it a try.
> Thanks to anyone who would help us... Le 28 oct. 2017 5:12 PM,
> Pierre_Loicq  a écrit :
> >
> > Hello,
> >
> > Does anyone know how to speed up my building time after a checkout ? It
> > takes me 30 sec when I change just a file, with "ninja qgis"
> > (https://nathanw.net/2016/05/26/speeding-up-qgis-build-times-with-ninja/
> )
> > but when I checkout it takes like more than 1 hour, with my 2 cores  at
> > 100%.
> >
> > Thank you
> > Pierre
> >
> > --
> > 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] Settings migration from QGIS 2 to 3

[Nathan Woodrow]

Hey Richard,

Leave it with me I will take a look.  I don't mind what we go with but we
should have a standard used over the whole app.

Your PR is fine if /qgis/connections-wms s used in QGIS 3 and
Qgis/connections-wms was
in 2.x the translation framework will pick it up ok.

Regards,
Nathan

On Sat, Oct 28, 2017 at 1:13 AM, Richard Duivenvoorde <rdmaili...@duif.net>
wrote:

> On 27-10-17 16:15, Nathan Woodrow wrote:
> > Sorry I'm not sure I follow what you mean?
>
> This pull fixed some WCS related changes, please see comments in the PR:
>
> https://github.com/qgis/QGIS/pull/4586
>
> I also grepped (at that time) some other key's which contained Qgis with
> a capital Q (again see PR):
>
> python/pyplugin_installer/installer_data.py:reposGroup =
> "/Qgis/plugin-repos"
> python/pyplugin_installer/installer_data.py:settingsGroup =
> "/Qgis/plugin-installer"
> python/pyplugin_installer/installer_data.py:seenPluginGroup =
> "/Qgis/plugin-seen"
> python/pyplugin_installer/installer_data.py:("Barry Rowlingson's
> Repository",
> "http://www.maths.lancs.ac.uk/~rowlings/Qgis/Plugins/plugins.xml;),
> python/pyplugin_installer/installer.py:lastDirectory =
> settings.value('/Qgis/plugin-installer/lastZipDirectory', '.')
> python/pyplugin_installer/installer.py:
> settings.setValue('/Qgis/plugin-installer/lastZipDirectory',
> python/qsci_apis/PyQGIS-2.0.api:qgis.gui.QgsNewHttpConnection?1(QWidget
> parent=None, QString baseKey="/Qgis/connections-wms/", QString
> connName=QString.null, Qt.WindowFlags fl=QgisGui.ModalDialogFlags)
> python/qsci_apis/PyQGIS-2.0.api:qgis.gui.QgsNewHttpConnection.__init__?
> 1(self,
> QWidget parent=None, QString baseKey="/Qgis/connections-wms/", QString
> connName=QString.null, Qt.WindowFlags fl=QgisGui.ModalDialogFlags)
> python/qsci_apis/PyQGIS-2.2.api:qgis.gui.QgsNewHttpConnection?1(QWidget
> parent=None, QString baseKey="/Qgis/connections-wms/", QString
> connName=QString.null, Qt.WindowFlags fl=QgisGui.ModalDialogFlags)
> python/qsci_apis/PyQGIS-2.2.api:qgis.gui.QgsNewHttpConnection.__init__?
> 1(self,
> QWidget parent=None, QString baseKey="/Qgis/connections-wms/", QString
> connName=QString.null, Qt.WindowFlags fl=QgisGui.ModalDialogFlags)
> python/gui/qgsnewhttpconnection.sip:QgsNewHttpConnection( QWidget
> *parent /TransferThis/ = 0, const QString  =
> "/Qgis/connections-wms/", const QString  = QString::null, const
> Qt::WindowFlags  = QgsGuiUtils::ModalDialogFlags );
> python/plugins/MetaSearch/dialogs/maindialog.py:# stype = human
> name,/Qgis/connections-%s,providername
> python/plugins/MetaSearch/dialogs/maindialog.py:
> self.settings.beginGroup('/Qgis/connections-%s' % stype[2])
> python/plugins/MetaSearch/dialogs/maindialog.py:
> self.settings.beginGroup('/Qgis/connections-%s' % stype[1])
> python/plugins/MetaSearch/dialogs/maindialog.py:
> self.settings.beginGroup('/Qgis/connections-%s' % stype[2])
> python/plugins/MetaSearch/dialogs/maindialog.py:
> self.settings.beginGroup('/Qgis/connections-%s' % stype[1])
>
> But I understand now that yours is just about settings object/file, NOT
> so much about the code that creates that settings?
>
> 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] Settings migration from QGIS 2 to 3

[Nathan Woodrow]

Sorry I'm not sure I follow what you mean?

On Sat., 28 Oct. 2017, 12:13 am Richard Duivenvoorde, <rdmaili...@duif.net>
wrote:

> On 27-10-17 12:49, Nathan Woodrow wrote:
>
> > If you want to add stuff to and have troubles let me know.   I would
> > like to see if we can get all the important stuff to come over before
> > release, connection strings, etc.  Anything that is a pain to setup for
> > users.
>
> Hi Nathan,
>
> I fixed some code already related to that, see:
>
> https://github.com/qgis/QGIS/pull/4586
>
> 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] Settings migration from QGIS 2 to 3

[Nathan Woodrow]

Hi all,

Just a heads up that I just merged something to migrate settings and styles
from 2 .qgis2 and config locations into QGIS 3 settings.  It will currently
only take a selection of things that I know we can port over but I would
like some help to grow that list before release.

Notes on how it works:

Edit the following file:
https://github.com/qgis/QGIS/blob/90857b2b18b69ac195d152db269f18a23c0ab95f/resources/2to3migration.txt

Syntax is:

oldkey;newkey

* means match key and /* means copy everything under this group:

Qgis/connections-xyz/*;qgis/connections-xyz/*

Will copy and Qgis/connections-xyz/ to gis/connections-xyz/ and everything
under it.

browser/favourites;*

Will copy the full key browser/favourites to the same key in QGIS 3.

If you change the file you must change # version=1 at the top to be a
higher number
or else the migration won't run again, however, we can leave it at 1 for
now until release
and just bump it at the end just before release once all the keys are
added.

If you want to add stuff to and have troubles let me know.   I would like
to see if we can get all the important stuff to come over before release,
connection strings, etc.  Anything that is a pain to setup for users.

If you don't want to lose any settings you are currently using in QGIS 3
dev I would make a new profile (Settings -> User Profile) and run with that
one while default takes everything from the migration steps.  Pro tip: Just
copy the default copy in the profiles\ folder to have a copy.

Regards,
Nathan
___
QGIS-Developer mailing list
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] MSSQL Spatial vector features not showing up in QGIS 2.18 up

[Nathan Woodrow]

You need to have a unique int based column QGIS can use as a row id at the
moment.  That might be why.

On Thu, Oct 26, 2017 at 9:40 PM, Diego Sartori  wrote:

> I'm importing a MSSQL 2008 Spatial layer in QGIS. In version 2.14 it works
> OK, I can see the vector features and interact with the associated
> attribute tables. But in versions 2.18 and 2.99, though the connection is
> OK (I can see the attribute tables), the features are not showing up in the
> map canvas. I can even modify the data in the tables but I can't
> graphically select the features for editing.
> I'm using a Windows 10 PC. The 3 versions of QGIS are runnig in the same
> machine, at the same time, with the same configuration. I've tried with the
> standalone installer and with the OSGEO4W installer (32 bit).
> ¿Anything changed from version 2.14 to newer versions that I can't get the
> features drawn on the map in version 2.18.13 and 2.99.0?
> This is my first post here and I'd like to add some screen captures, ¿how
> should I poceed?
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] UI discussion?

[Nathan Woodrow]

Remove overview panel?

On Fri., 13 Oct. 2017, 6:55 pm Richard Duivenvoorde, 
wrote:

> Hi Dev's,
>
> Should/can we plan some ui discussion maybe before QGIS3 freeze?
>
> I know only discussion is not very helpfull, as it does not DO it, but I
> think we should use the big 3 release as a handle to cleanup/fix some ui
> too. As we add so much things, in my opinion you should not be afraid to
> also remove (non used/important) things.
>
> Some low hanging fruit I would like to do/discuss:
> - move 'Plugins/Install plugin from zip' to the dialog
> - remove overview panel (and menu actions)
> - remove Help toolbar (we have helpbuttons and a menu item)
> - move stuff (which I think clutter menu's but personally never use) to
> 'menu groups' (like all Save Map as.. and DXF import/export (and rename
> those)
> - merge Project New and New from Template to one 'menu group'-action
>
> (with menu group I mean a button/action with a little dropdown next to
> it, like you have for the select tools)
>
> Opinions? Anybody interested?
>
> Regards,
>
> Richard Duivenvoorde
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Future of OSM integration

[Nathan Woodrow]

Does quick OSM give us the same download as local dataset feature. I have
never looked.

On Thu., 12 Oct. 2017, 6:26 pm Tim Sutton,  wrote:

> Hi
>
> > On 12 Oct 2017, at 10:20, Martin Dobias  wrote:
> >
> > Hi
> >
> > What do people think about the OpenStreetMap integration in Vector >
> > OpenStreetMap menu?
> >
> > My original plan for it was to have a convenient way of downloading
> > and viewing of OSM data as background maps for project, however I have
> > a feeling that the implementation somehow stayed far behind my grand
> > plans :-)
> >
> > The GUI is quite clunky and weird to use (it is really just a thin
> > wrapper of underlying classes), there are some bugs, it does not
> > support the less verbose .pbf format of OSM data... Also there is more
> > than a dozen of other OSM-related plugins now and I have not really
> > done much to improve the existing code.
> >
> > So my question really is - shall we just get rid of it? Would anyone
> > miss it? :-)
>
> Sorry to say I wont miss it :-( There is quick-osm and InaSAFE also has a
> downloader and I think if we were going to have something in core, Quick
> OSM would be a better choice. So +1 from me to clean house. Let’s see if
> others have different ideas…
>
> Regards
>
> Tim
>
>
> >
> > Cheers
> > Martin
> > ___
> > QGIS-Developer mailing list
> > 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] project properties menu item: move it?

[Nathan Woodrow]

Please move it for every OS.  There is no reason this needs to be in the
settings menu for different systems.

On Thu, Sep 21, 2017 at 8:03 PM, Andreas Neumann 
wrote:

> Hi Alessandro,
>
> It depends on the OS.
>
> As to my knowledge, Linux with KDE is the only platform where the project
> properties are in the settings menu, whereas Windows, OSX and Linux with
> Gnome all have it in the project menu.
>
> When I teach QGIS I always have to say people that on my machine
> (Linux/KDE) the project properties are in the settings menu, while on 99%
> of the other machines it is in the project menu.
>
> It is indeeed VERY, VERY annoying, that KDE behaves different in this
> respect.
>
> Andreas
>
>
> On 2017-09-21 11:57, Alessandro Pasotti wrote:
>
>
> What do you think about moving the project properties menu item from the
> settings menu to the project menu?
>
>
>
> --
> 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
>
>
>
> ___
> QGIS-Developer mailing list
> 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] removing icons

[Nathan Woodrow]

Hey Donn,

FIrst, your post is in the right place.  Maybe qgis-user is a better place
but doesn't really matter for this.

Second, you sure can do what you need.  The first thing you need is
Settings -> Customization. Tick enable and you can disable and enable
anything you need.  You can also Save To File to get an ini file which you
can load QGIS with the following argument to start the UI with that
interface: qgis -z yourfile.ini.  Pretty handy if you need different UIs
for different use cases.

Next thing to do after that is look for the "Customize ToolBars" plugin.
That will let you make custom toolbars with what ever actions you need for
your users.

Regards,
Nathan


On Wed, Sep 20, 2017 at 11:24 PM, Donn Downey  wrote:

> Hello, I develop database solutions for a niche industry that also has
> significant GIS needs. I personally use QGIS and help others get going, but
> even QGIS can be tough to teach to non-savvy computer users. As such, I
> dream of a version of QGIS where we basically strip out 90% of the icons
> from the half dozen relevant toolbars, in order to further simplify the
> interface and make the necessary tasks more accessible.  I have no
> programming experience- we would hire someone to do this- I’m just trying
> to figure out options. Ultimately, we’d like to (freely) share a special
> stripped down version of QGIS.
>
> First, is it technically possible to hide or remove icons from toolbars,
> or develop a toolbar that is specific to our industry-specific purpose?
> Along these lines, are there developers on this list that contract to do
> work like this?
>
> I apologize if this isn’t an appropriate forum to post this topic- I’m new
> to this. Please let me know. Thanks!
>
> ___
> QGIS-Developer mailing list
> 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] FeatureIterator Python question

[Nathan Woodrow]

I think we could just implement out own next method to avoid that break
would be easy enough.

On Fri, Sep 15, 2017 at 11:48 PM, Andreas Neumann 
wrote:

> Hi Matteo and Matthias,
>
> Thanks - that works fine. I did not know that this changed in Python 3.
>
> All the poor QGIS book authors who need to rewrite their books ... about
> this Python changes.
>
> Helps a lot!
>
> Andreas
>
>
>
>
> On 15.09.2017 15:44, matteo wrote:
>
>> Hi Andreas,
>>
>> if I'm not wrong the next method is not been removed, it is a python 3
>> *fix*
>>
>> https://stackoverflow.com/questions/1073396/is-generator-
>> next-visible-in-python-3-0
>>
>> so instead of:
>>
>> it = layer.getFeatures()
>> it.next()
>>
>> just type
>>
>> it = layer.getFeatures()
>> next(it)
>>
>> Matteo
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
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] Reword "Trusted Plugin" --> "Trusted Plugin Author"?

[Nathan Woodrow]

+1 That makes sense to me.

On Fri, Sep 8, 2017 at 3:07 AM, Anita Graser  wrote:

> Hi Harrissou,
>
> On Thu, Sep 7, 2017 at 6:14 PM, DelazJ  wrote:
>
>> Hi,
>> I know there has been a lot of discussion about this subject and sorry
>> to revive it.
>> I'd like to propose to reword the "Trusted Plugin" text in the Plugin
>> Manager into "Trusted Author" or "Trusted Plugin Author".
>>
>
> ​Yeah, I think that would make sense.​
>
>
>> I know there have been literature on what trusted means, some blog
>> post (unfortunately now) hidden on the Internet
>>
>
> ​For reference:​
> ​http://blog.qgis.org/2016/08/26/what-are-trusted-plugins/
> ​
>
> ​Regards,
> Anita​
>
>
> ___
> QGIS-Developer mailing list
> 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] Slow downloads from download.osgeo.org

[Nathan Woodrow]

Hey all,

Just trying to do an update with osgeo4w but the downloads are super slow
tonight around 30 kbs.

Is there anything we can do to improve the speed of the server?  Maybe
setting up some mirrors like Cygwin has so we can host the files around the
world.

- Nathan
___
QGIS-Developer mailing list
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] Incremental drawing possible?

[Nathan Woodrow]

Hey John,

QGIS has had multithreaded rendering since 2.0 which allows the map to be
rendered as you pan around so you don't have to wait.  You can also set the
refresh rate in order to draw more features so you get feedback quicker.

Regards,
Nathan

On Tue, Jul 11, 2017 at 2:32 AM, John Abraham  wrote:

> Is incremental drawing possible, especially for web features in the
> background?
>
> I've been playing with some GPU based visualizers lately (in particular
> CityPhi from INRO https://www.inrosoftware.com/en/products/cityphi/ ) and
> switching back to QGIS and waiting for the maps to redraw on every single
> pan or zoom is extremely painful.
>
> GPU-drawn 3D visualizations at 30 frames per second is probably not a
> realistic short-term goal for QGIS. But, what about allowing the graphics
> system to draw the current status of the internal render, before it's
> complete?  For example, if WMS tiles are being downloaded, can the
> background map be updated as data comes in, while the foreground features
> stay on top?  Can layers be shown as they are drawn, instead of popping up
> the entire image after the final layer has been drawn?
>
>
> On Jul 10, 2017, at 9:44 AM, qgis-developer-requ...@lists.osgeo.org wrote:
>
> Send QGIS-Developer mailing list submissions to
> qgis-developer@lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.osgeo.org/mailman/listinfo/qgis-developer
> or, via email, send a message with subject or body 'help' to
> qgis-developer-requ...@lists.osgeo.org
>
> You can reach the person managing the list at
> qgis-developer-ow...@lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of QGIS-Developer digest..."
>
>
> Today's Topics:
>
>   1. Re: QGIS/OGR: FeatureIds reassigned on write to data
>  provider? (Even Rouault)
>   2. Re: Value entry using comma as decimal separator?
>  (Bernhard Ströbl)
>   3. Plugin [1246] go2mapillary approval notification.
>  (nore...@qgis.org)
>   4. Re: QGIS/OGR: FeatureIds reassigned on write to data
>  provider? (Régis Haubourg)
>   5. Re: QGIS/OGR: FeatureIds reassigned on write to data
>  provider? (Even Rouault)
>   6. qgis-bin.exe - Entry Point Not Found (Patrice)
>
>
> --
>
> Message: 1
> Date: Mon, 10 Jul 2017 13:58:57 +0200
> From: Even Rouault 
> To: qgis-developer@lists.osgeo.org
> Subject: Re: [QGIS-Developer] QGIS/OGR: FeatureIds reassigned on write
> to data provider?
> Message-ID: <2643131.9G3uCidT8S@even-i700>
> Content-Type: text/plain; charset="utf-8"
>
> I did some playing around and came up with some FeatureId mapping code
> which is pretty space efficient (basically requiring just
> 3*nDeletedFeatures entries), see below.
>
> The code however assumes that the gaps in the fid-sequence are filled by
> decreasing the fids after the gap, which may be pretty specific to the
> OGR/Shapefile behaviour.
>
>
> This should clearly be restricted to Shapefiles. Other drivers don't have
> this compaction logic
> and will let happily holes in the feature ids.
>
> Hence in my view such code should really belong
> into the OGR provider (or perhaps even ogr itself) and not in the
> plugin. Thoughts?
>
>
> Regarding putting that in OGR itself, there's no such API for that right
> now, and I'm not
> completely clear of the value to add one (specific use case, for a single
> driver)
>
> Perhaps the QGIS OGR provider would be a better place for now.
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> -- next part --
> An HTML attachment was scrubbed...
> URL:  attachments/20170710/138fa822/attachment-0001.html>
>
> --
>
> Message: 2
> Date: Mon, 10 Jul 2017 14:15:46 +0200
> From: Bernhard Ströbl 
> To: qgis-developer 
> Subject: Re: [QGIS-Developer] Value entry using comma as decimal
> separator?
> Message-ID: <2f5e52a4-ef66-5cb1-200d-80a1d8d9f...@jena.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi,
> just my two cents: My users are working in a German administration and
> they depend on QGIS having a German UI. They will be puzzled if they are
> supposed to use a point instead of the regular komma as decimal
> separator. On the other hand they won't expect "5.5" to be a regular
> entry into a decimal field either.
>
> Bernhard
>
> Am 08.07.2017 um 09:58 schrieb Richard Duivenvoorde:
>
> On 08-07-17 01:11, Nyall Dawson wrote:
>
> It's a trivial change to make to get the spin boxes to accept the
> local decimal separator, but this would prevent users entering "5.5"
> in those locales.
>
> Can someone from one of these affected regions let me know what the
> correct behavior should be? I don't want to make 

Re: [QGIS-Developer] dataset icons in Browser tree

[Nathan Woodrow]

Are you sure? It's never done that for me, it uses ogr to know what files
it can open.

On Wed, 5 Jul 2017, 7:00 PM McDonaldR <mcdona...@angus.gov.uk> wrote:

> Smashing!
>
>
>
> ArcCatalog also collapses down all the constituent parts and shows one
> file in the tree instead of all parts of the shapefile or tab file, for
> example.  However, it also only shows files it can open.   The info button
> in Browser lists all files in the folder regardless of whether QGIS can
> open them or not.  I guess we need to think about what the user wants to do
> with the info they can see in the panel.
>
>
>
> Ross
>
>
>
> *From:* Nathan Woodrow [mailto:madman...@gmail.com]
> *Sent:* 05 July 2017 09:29
> *To:* McDonaldR; qgis-developer@lists.osgeo.org
> *Subject:* Re: [QGIS-Developer] dataset icons in Browser tree
>
>
>
> Yep I'm down for that, would look pretty nice if we can I think. Bit like
> what VS Code, pycharm etc do for different file types.
>
> Would be still handy to see if it's line, point, etc so just need to
> consider that.
>
>
>
> On Wed, 5 Jul 2017, 6:26 PM McDonaldR <mcdona...@angus.gov.uk> wrote:
>
> Hi List,
>
>
>
> This might be on the hit list already.  Is it possible to have different
> icons for different file types within the QGIS Browser?  I know the
> standalone Browser is being discontinued but the panel will still be
> available in the core QGIS.  Different icons would be very useful.
>
>
>
> In the QGIS Browser (app and panel) file system based datasets are listed
> in alphabetical order and each file has either a small raster icon if it is
> an image format or a small polygon icon if it is not.  For database layers
> they have a small point, line or polygon icon.
>
>
>
> In my second choice GIS (well known!) there is also a browser-like
> application but it shows the files and datasets with different icons
> depending on file and data type.  You can see the icons in the screenshots
> on this page -
> http://desktop.arcgis.com/en/arcmap/10.3/manage-data/using-arccatalog/a-quick-tour-of-arccatalog.htm
>
>
>
> Ross
>
>
>
> *Ross McDonald | *GIS Data Coordinator | Angus Council, People, IT |
> Angus House, Orchardbank Business Park, Sylvie Way, Forfar DD8 1AT* | t:
> 01307 476419*
>
>
>
>
>
> This message is strictly confidential. If you have received this in error,
> please inform the sender and remove it from your system. If received in
> error you may not copy, print, forward or use it or any attachment in any
> way. This message is not capable of creating a legal contract or a binding
> representation and does not represent the views of Angus Council. Emails
> may be monitored for security and network management reasons. Messages
> containing inappropriate content may be intercepted. Angus Council does not
> accept any liability for any harm that may be caused to the recipient
> system or data on it by this message or any attachment.
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> This message is strictly confidential. If you have received this in error,
> please inform the sender and remove it from your system. If received in
> error you may not copy, print, forward or use it or any attachment in any
> way. This message is not capable of creating a legal contract or a binding
> representation and does not represent the views of Angus Council. Emails
> may be monitored for security and network management reasons. Messages
> containing inappropriate content may be intercepted. Angus Council does not
> accept any liability for any harm that may be caused to the recipient
> system or data on it by this message or any attachment.
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer