Re: [QGIS-Developer] New version notifications

[Richard Duivenvoorde]

On 04/06/2019 07.11, Etienne Trimaille wrote:
> In QGIS Settings -> "General", you can disable "Check QGIS version".
> 
> If you are deploying QGIS with an INI file, you can do it
> programmatically. You can hide this checkbox because QGIS version is
> managed by the system administrator.
> https://docs.qgis.org/3.4/en/docs/user_manual/introduction/qgis_configuration.html#deploying-qgis-within-an-organization
> 
> Le mar. 4 juin 2019 à 06:55, Bernhard Ströbl  > a écrit :
> 
> On that occasion:
> 
> how can I deactivate the new version information? I get frequent calls
> from my users asking if they need to do something. It's kind of
> annoying
> because we use LTS.

In my view, this should be DISabled by default, and being asked (at
startup?) if the user wants this.

It is actually a 'phone home' mechanisme, which I personally dislike
(even if developers developed it as 'service for users').

Quickmapservices plugin does the same (and stalls QGIS till timeout if
you network/proxy issues).

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

Re: [QGIS-Developer] New version notifications

[Bernhard Ströbl]

Hi Etienne,

thank you, pretty obvious :-)

Bernhard

Am 04.06.2019 um 07:11 schrieb Etienne Trimaille:

In QGIS Settings -> "General", you can disable "Check QGIS version".

If you are deploying QGIS with an INI file, you can do it 
programmatically. You can hide this checkbox because QGIS version is 
managed by the system administrator.

https://docs.qgis.org/3.4/en/docs/user_manual/introduction/qgis_configuration.html#deploying-qgis-within-an-organization

Le mar. 4 juin 2019 à 06:55, Bernhard Ströbl <mailto:bernhard.stro...@jena.de>> a écrit :


On that occasion:

how can I deactivate the new version information? I get frequent calls
from my users asking if they need to do something. It's kind of
annoying
because we use LTS.

Bernhard

Am 03.06.2019 um 18:11 schrieb Tim Sutton:
 > It takes the version status from QGIS.org <http://QGIS.org> not
from the
 > repositories. When the actual package arrives depends on your
package
 > repo etc.
 >
 > Regards
 >
 > Tim
 >
 >> On 3 Jun 2019, at 00:16, Cory Albrecht mailto:m...@hanfastolfe.com>
 >> <mailto:m...@hanfastolfe.com <mailto:m...@hanfastolfe.com>>> wrote:
 >>
 >> Why does QGIS alert about newer versions before the version is even
 >> available in something like the Debian/Ubuntu repos at
 >> http://qgis.org/ubuntu-nightly-release ?
 >> ___
 >> QGIS-Developer mailing list
 >> QGIS-Developer@lists.osgeo.org
<mailto:QGIS-Developer@lists.osgeo.org>
<mailto:QGIS-Developer@lists.osgeo.org
<mailto: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 <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 <http://freenode.net>
<http://freenode.net>
 >
 > I'd love to connect. Here's my calendar link
 > <https://calendly.com/timlinux> to make finding time easy.
 >
 >
 >
 > __ Information from ESET Mail Security, version of virus
 > signature database 19461 (20190603) __
 >
 > The message was checked by ESET Mail Security.
 > http://www.eset.com
 >
 >  '�z�Zr �r ^�)�j[p��Z��'~��zJ&�W�� ��{^� �iק
 >



__ Information from ESET Mail Security, version of virus
signature database 19465 (20190604) __

The message was checked by ESET Mail Security.
http://www.eset.com


___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer





__ Information from ESET Mail Security, version of virus signature 
database 19465 (20190604) __

The message was checked by ESET Mail Security.
http://www.eset.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

Re: [QGIS-Developer] New version notifications

[Etienne Trimaille]

In QGIS Settings -> "General", you can disable "Check QGIS version".

If you are deploying QGIS with an INI file, you can do it programmatically.
You can hide this checkbox because QGIS version is managed by the system
administrator.
https://docs.qgis.org/3.4/en/docs/user_manual/introduction/qgis_configuration.html#deploying-qgis-within-an-organization

Le mar. 4 juin 2019 à 06:55, Bernhard Ströbl  a
écrit :

> On that occasion:
>
> how can I deactivate the new version information? I get frequent calls
> from my users asking if they need to do something. It's kind of annoying
> because we use LTS.
>
> Bernhard
>
> Am 03.06.2019 um 18:11 schrieb Tim Sutton:
> > It takes the version status from QGIS.org <http://QGIS.org> not from
> the
> > repositories. When the actual package arrives depends on your package
> > repo etc.
> >
> > Regards
> >
> > Tim
> >
> >> On 3 Jun 2019, at 00:16, Cory Albrecht  >> <mailto:m...@hanfastolfe.com>> wrote:
> >>
> >> Why does QGIS alert about newer versions before the version is even
> >> available in something like the Debian/Ubuntu repos at
> >> http://qgis.org/ubuntu-nightly-release ?
> >> ___
> >> QGIS-Developer mailing list
> >> QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> 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 <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 <http://freenode.net>
> >
> > I'd love to connect. Here's my calendar link
> > <https://calendly.com/timlinux> to make finding time easy.
> >
> >
> >
> > __ Information from ESET Mail Security, version of virus
> > signature database 19461 (20190603) __
> >
> > The message was checked by ESET Mail Security.
> > http://www.eset.com
> >
> >  '�z�Zr �r ^�)�j[p��Z��'~��zJ&�W�� ��{^� �iק
> >
>
>
>
> __ Information from ESET Mail Security, version of virus signature
> database 19465 (20190604) __
>
> The message was checked by ESET Mail Security.
> http://www.eset.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] New version notifications

[Bernhard Ströbl]

On that occasion:

how can I deactivate the new version information? I get frequent calls 
from my users asking if they need to do something. It's kind of annoying 
because we use LTS.


Bernhard

Am 03.06.2019 um 18:11 schrieb Tim Sutton:
It takes the version status from QGIS.org <http://QGIS.org> not from the 
repositories. When the actual package arrives depends on your package 
repo etc.


Regards

Tim

On 3 Jun 2019, at 00:16, Cory Albrecht <mailto:m...@hanfastolfe.com>> wrote:


Why does QGIS alert about newer versions before the version is even 
available in something like the Debian/Ubuntu repos at 
http://qgis.org/ubuntu-nightly-release ?

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
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 <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 <http://freenode.net>

I'd love to connect. Here's my calendar link 
<https://calendly.com/timlinux> to make finding time easy.




__ Information from ESET Mail Security, version of virus 
signature database 19461 (20190603) __


The message was checked by ESET Mail Security.
http://www.eset.com

'�z�Zr�r^�)�j[p��Z��'~��zJ&�W����{^��iק





__ Information from ESET Mail Security, version of virus signature 
database 19465 (20190604) __

The message was checked by ESET Mail Security.
http://www.eset.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

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] QGIS and Proj 6

[Paolo Cavallini]

Thanks Nyall. You Australians should be proud of this forward thinking (as well 
as giving birth to Nyall, of course ;) ).
Cheers.

Il 3 giugno 2019 09:28:34 CEST, Nyall Dawson  ha 
scritto:
>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

-- 
Sorry for being short___
QGIS-Developer mailing list
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] Plugin [840] INSPIRE Nederland plugin voor QGIS approval notification.

[noreply]

Plugin INSPIRE Nederland plugin voor QGIS approval by pcav.
The plugin version "[840] INSPIRE Nederland plugin voor QGIS 2.6" is now 
approved
Link: http://plugins.qgis.org/plugins/inspireNL/
___
QGIS-Developer mailing list
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 and Proj 6

[Nyall Dawson]

On Mon, 3 Jun 2019 at 23:53, Régis Haubourg  wrote:
>
> Let me strongly second Calvin here.
> I followed your work on the PROJ mailing lists and it's a big hat off for you 
> Nyall. Understanding the geodesic issues and making it available into QGIS so 
> soon is brilliant.
> I'd also like to thank your funder whoever it is, because he allowed a huge 
> step forward. Not so many funders are able to invest into such low level 
> stuff.

This was thanks to sponsorship from ICSM (https://www.icsm.gov.au/),
an Australian committee responsible for introducing a new system of
projections to Australia (GDA2020). They are also behind the
(scary/exciting) new world of 4d coordinate transformations, where a
future Australian reference system will be dynamic and have a temporal
component modelling the tectonic movements of the Australian
continent. When this lands it'll be time for a lot of us to hit the
textbooks again ;) We (Australians, that is) are extremely fortunate
to have such a forward thinking team behind this -- not only are they
tackling some fundamental changes in how projections are handled, they
also had the foresight to recognise the need for strong support for
this in open source software and invest their funds into seeing it
happen.

> And I don't forget the PROJ team, we all rely on the shoulders of giants, 
> truly.

Totally. This team is amazing!

Nyall

> Big up, you rock!
> Régis
>
> Le lun. 3 juin 2019 à 15:02, C Hamilton  a écrit :
>>
>> Nyall,
>>
>> I just wanted to thank you for doing this. QGIS is already awesome, but this 
>> makes it even more awesome.
>>
>> Calvin
>>
>> On Mon, Jun 3, 2019 at 3:28 AM 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 

Re: [QGIS-Developer] QGIS and Proj 6

[Nyall Dawson]

On Tue, 4 Jun 2019 at 05:44, Richard Duivenvoorde  wrote:
>
> On 03/06/2019 09.28, 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])
>
> Ubercool Nyall! Thanks!
>
> I've build QGIS with GDAL3 and proj6.1 here.
>
> Both with an my (old) profile or with a crisp fresh one, I get a lot of
> debug output with 'failed' in it... See below

This is "just" noise, it's not actually indicating anything is wrong.
I'll see what I can do to reduce this, because it annoys me too!

Nyall

>
> Wondering if my build is wrong or it is just 'normal' output
> (QGIS_DEBUG=5...)
>
> But: thanks for all this. Though, let's be honest, I only understand
> half of it :-)   Nobody with such knowledge willing to write a thorough
> "QGIS with proj magic" intro in our docs?
>
> Regards,
> Richard Duivenvoorde
>
> src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
> [27ms] Projection is not found in databases.
> src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [16ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat
> +a=529800 +no_defs' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [1ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat
> +a=529800 +no_defs' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [56ms]
> failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
> +proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=529800 %' AND '
> '||parameters||' ' LIKE '% +no_defs %' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [1ms]
> failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
> +proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=529800 %' AND '
> '||parameters||' ' LIKE '% +no_defs %' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
> [12ms] Projection is not found in databases.
> src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [11ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat
> +a=2575000 +no_defs' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [2ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat
> +a=2575000 +no_defs' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
> [35ms] Projection is not found in databases.
> src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [11ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat
> +a=25559000 +rf=43.616040955631398 +no_defs' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [1ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat
> +a=25559000 +rf=43.616040955631398 +no_defs' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [32ms]
> failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
> +proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=25559000 %' AND '
> '||parameters||' ' LIKE '% +rf=43.616040955631398 %' AND '
> '||parameters||' ' LIKE '% +no_defs %' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [1ms]
> failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
> +proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=25559000 %' AND '
> '||parameters||' ' LIKE '% +rf=43.616040955631398 %' AND '
> '||parameters||' ' LIKE '% +no_defs %' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
> [17ms] Projection is not found in databases.
> src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [25ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat
> +a=578900 +no_defs' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [7ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat
> +a=578900 +no_defs' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [41ms]
> failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
> +proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=578900 %' AND '
> '||parameters||' ' LIKE '% +no_defs %' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [2ms]
> failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
> +proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=578900 %' AND '
> '||parameters||' ' LIKE '% +no_defs %' order by deprecated
> src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
> [10ms] Projection is not found in databases.
> src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [10ms]
> failed :  select * from tbl_srs where parameters='+proj=longlat +a=33000
> +no_defs' order by 

Re: [QGIS-Developer] QGIS and Proj 6

[Richard Duivenvoorde]

On 03/06/2019 09.28, 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])

Ubercool Nyall! Thanks!

I've build QGIS with GDAL3 and proj6.1 here.

Both with an my (old) profile or with a crisp fresh one, I get a lot of
debug output with 'failed' in it... See below

Wondering if my build is wrong or it is just 'normal' output
(QGIS_DEBUG=5...)

But: thanks for all this. Though, let's be honest, I only understand
half of it :-)   Nobody with such knowledge willing to write a thorough
"QGIS with proj magic" intro in our docs?

Regards,
Richard Duivenvoorde

src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
[27ms] Projection is not found in databases.
src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [16ms]
failed :  select * from tbl_srs where parameters='+proj=longlat
+a=529800 +no_defs' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [1ms]
failed :  select * from tbl_srs where parameters='+proj=longlat
+a=529800 +no_defs' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [56ms]
failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
+proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=529800 %' AND '
'||parameters||' ' LIKE '% +no_defs %' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [1ms]
failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
+proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=529800 %' AND '
'||parameters||' ' LIKE '% +no_defs %' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
[12ms] Projection is not found in databases.
src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [11ms]
failed :  select * from tbl_srs where parameters='+proj=longlat
+a=2575000 +no_defs' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [2ms]
failed :  select * from tbl_srs where parameters='+proj=longlat
+a=2575000 +no_defs' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
[35ms] Projection is not found in databases.
src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [11ms]
failed :  select * from tbl_srs where parameters='+proj=longlat
+a=25559000 +rf=43.616040955631398 +no_defs' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [1ms]
failed :  select * from tbl_srs where parameters='+proj=longlat
+a=25559000 +rf=43.616040955631398 +no_defs' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [32ms]
failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
+proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=25559000 %' AND '
'||parameters||' ' LIKE '% +rf=43.616040955631398 %' AND '
'||parameters||' ' LIKE '% +no_defs %' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [1ms]
failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
+proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=25559000 %' AND '
'||parameters||' ' LIKE '% +rf=43.616040955631398 %' AND '
'||parameters||' ' LIKE '% +no_defs %' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
[17ms] Projection is not found in databases.
src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [25ms]
failed :  select * from tbl_srs where parameters='+proj=longlat
+a=578900 +no_defs' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [7ms]
failed :  select * from tbl_srs where parameters='+proj=longlat
+a=578900 +no_defs' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [41ms]
failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
+proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=578900 %' AND '
'||parameters||' ' LIKE '% +no_defs %' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1161 : (getRecord) [2ms]
failed :  SELECT * FROM tbl_srs WHERE ' '||parameters||' ' LIKE '%
+proj=longlat %' AND ' '||parameters||' ' LIKE '% +a=578900 %' AND '
'||parameters||' ' LIKE '% +no_defs %' order by deprecated
src/core/qgscoordinatereferencesystem.cpp:1057 : (createFromProj4)
[10ms] Projection is not found in databases.
src/core/qgscoordinatereferencesystem.cpp:1119 : (getRecord) [10ms]
failed :  select * from tbl_srs where parameters='+proj=longlat +a=33000
+no_defs' order by deprecated

___
QGIS-Developer mailing list
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] Plugin [1412] GeoDataFarm approval notification.

[noreply]

Plugin GeoDataFarm approval by zimbogisgeek.
The plugin version "[1412] GeoDataFarm 2.5.2" is now approved
Link: http://plugins.qgis.org/plugins/geodatafarm/
___
QGIS-Developer mailing list
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] Plugin [1670] XYZ Hub Connector approval notification.

[noreply]

Plugin XYZ Hub Connector approval by zimbogisgeek.
The plugin version "[1670] XYZ Hub Connector 1.6.2" is now approved
Link: http://plugins.qgis.org/plugins/XYZHubConnector/
___
QGIS-Developer mailing list
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] Using encrypted authentication credentials in QGIS Server

[Tim Sutton]

Hi All

As explained by the subject line, I would like to reply a QGIS 3.x server based 
site where the project uses the QGIS authentication framework to store user 
names and password for the database connection in an encrypted manner.

I have used the authentication manager before on my desktop, but what do I need 
to do to set things up in a server environment?

Also the list of supported services in ’Settings->Authentication->Installed 
Plugins’ does not currently include Oracle. Did anyone use  the authentication 
manager against an Oracle database before?

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

Re: [QGIS-Developer] New version notifications

[Tim Sutton]

It takes the version status from QGIS.org not from the repositories. When the 
actual package arrives depends on your package repo etc.

Regards

Tim

> On 3 Jun 2019, at 00:16, Cory Albrecht  wrote:
> 
> Why does QGIS alert about newer versions before the version is even available 
> in something like the Debian/Ubuntu repos at 
> http://qgis.org/ubuntu-nightly-release 
>  ?
> ___
> QGIS-Developer mailing list
> 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

Re: [QGIS-Developer] QGIS and Proj 6

[Régis Haubourg]

Let me strongly second Calvin here.
I followed your work on the PROJ mailing lists and it's a big hat off for
you Nyall. Understanding the geodesic issues and making it available into
QGIS so soon is brilliant.
I'd also like to thank your funder whoever it is, because he allowed a huge
step forward. Not so many funders are able to invest into such low level
stuff.
And I don't forget the PROJ team, we all rely on the shoulders of giants,
truly.
Big up, you rock!
Régis

Le lun. 3 juin 2019 à 15:02, C Hamilton  a écrit :

> Nyall,
>
> I just wanted to thank you for doing this. QGIS is already awesome, but
> this makes it even more awesome.
>
> Calvin
>
> On Mon, Jun 3, 2019 at 3:28 AM 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!
>> 

Re: [QGIS-Developer] Issues in Feedback state & auto-closing issues

[DelazJ]

Hi,

Le lun. 3 juin 2019 à 15:45, Alessandro Pasotti  a
écrit :

>
> Looks good!
>
> Do we have web page with more information where we can point the users to?
>
> Afaict, no! Nothing on our official web site. And this would address, if I
correctly understand what's being said,
https://github.com/qgis/QGIS-Website/issues/611

Regards,
Harrissou

>
> --
> 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] Security Question - Is location included in file when save an image file?

[Ert Four]

Thank you, that's super helpful. I will post your answer to the original thread 
on the qgis-user list.

I wonder how much effort would be involved (just a very quick ballpark guess) 
in adding an option to turn off georeferencing or coordinates when saving image 
files. Granted, I assume it's not something most users would need, but not sure 
how small or big it would be. It sounds like it might be bigger than I'd 
originally imagined in case it requires making adjustments for each file type.

> On June 3, 2019 at 3:44 AM Nyall Dawson  wrote:
> 
> 
> On Sun, 2 Jun 2019 at 17:50, Ert Four <4...@mailbox.org> wrote:
> >
> > I'm a little out of my league here, I'm not a developer, but was pointed 
> > here from the QGIS-user list.
> >
> > My question is: Does any coordinate or location data get embedded in the 
> > image file if I use Project > Save as Image or Composer > Export as 
> > Image/PDF/SVG (other than what is literally seen in the image)?
> >
> > My question is primarily for 2.14.3 now, but later will have the same 
> > concern for the 3.x series when we upgrade.
> >
> > (I know about the option to check "World file on" and create a separate 
> > world file. What I need is to make sure there is no identifying info 
> > whatsoever from the project file in the image file itself.)
> 
> yes - regardless of that setting, the outputs are georeferenced and
> have coordinates baked in*
> 
> (* depending on format support. SVG doesn't, certain raster formats
> may not -- check with GDAL whether embedded georeferencing of these is
> possible. It is for all the common ones at least).
> 
> Nyall
> 
> 
> >
> > Eg, say I have a basemap like OpenStreetMap open for a country and I load 
> > points in another layer that are inside that country. Then I zoom in on a 
> > group of points from my data layer, I turn off the basemap layer, and make 
> > a map with just my data points. I want to preserve the relative spatial 
> > relationships between my points but not reveal where in the world the map 
> > came from. If I publish this image file, might the metadata or anything 
> > else embedded in the file reveal the location?
> >
> > So far, the QGIS-user members who've responded and I have found no 
> > indications that this type of data is included, but I'm posting here in 
> > case anyone who is familiar with that code could confirm that. Sorry I'm 
> > not able to read the code myself.
> >
> > For the work we do, it's critically important we don't unknowingly publish 
> > specific locations. For now I'm taking screenshots to be sure nothing is 
> > transmitted, but that's a limiting workaround.
> >
> > Thank you, as I said in my first post to the QGIS-user list, I very much 
> > appreciate QGIS and its community!
> >
> > Fwiw, thread on the user list starts here: 
> > https://lists.osgeo.org/pipermail/qgis-user/2019-May/043218.html
> > Continues here in June archive: 
> > https://lists.osgeo.org/pipermail/qgis-user/2019-June/043224.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] Issues in Feedback state & auto-closing issues

[Alessandro Pasotti]

On Mon, Jun 3, 2019 at 3:36 PM Martin Dobias  wrote:

> Hi Nyall
>
> On Mon, Jun 3, 2019 at 4:28 AM Nyall Dawson 
> wrote:
> >
> > Well, I figure it's an accurate reflection of the situation. A feature
> > request older than this will likely NEVER get implemented without
> > funding. If we don't go for a specific label, I'd suggest we make the
> > bot message say something like:
> >
> > "Hey, your feature request hasn't been implemented in the 2 months
> > since you suggested it. That doesn't mean it's not a great idea! (more
> > likely, our developers are just busy with other priorities). The good
> > news is that YOU can still see this feature become a reality! Some
> > possible suggestions are:
> > - Dive into the QGIS code, and implement it yourself. If you've got
> > coding experience, QGIS is a fantastic, friendly open-source community
> > to contribute to.
> > - Pay one of the QGIS core developers to implement it for you.
> > Developers aren't necessarily volunteers, and often require payment to
> > justify the time they invest into the QGIS project. Our developers
> > LOVE working on QGIS, but they also like to eat and pay their rents!
> > - Run your own crowd funding or co-funding campaign and raise funds to
> > see the feature sponsored.
> > If you've any questions regarding how to approach any of these
> > suggestions, just ask below, and one of our team members will assist."
>
> That's nice and positive wording - definitely worth a try :-)
>
> Cheers
> Martin
>
>

Looks good!

Do we have web page with more information where we can point the users to?


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

Re: [QGIS-Developer] Issues in Feedback state & auto-closing issues

[Martin Dobias]

Hi Nyall

On Mon, Jun 3, 2019 at 4:28 AM Nyall Dawson  wrote:
>
> Well, I figure it's an accurate reflection of the situation. A feature
> request older than this will likely NEVER get implemented without
> funding. If we don't go for a specific label, I'd suggest we make the
> bot message say something like:
>
> "Hey, your feature request hasn't been implemented in the 2 months
> since you suggested it. That doesn't mean it's not a great idea! (more
> likely, our developers are just busy with other priorities). The good
> news is that YOU can still see this feature become a reality! Some
> possible suggestions are:
> - Dive into the QGIS code, and implement it yourself. If you've got
> coding experience, QGIS is a fantastic, friendly open-source community
> to contribute to.
> - Pay one of the QGIS core developers to implement it for you.
> Developers aren't necessarily volunteers, and often require payment to
> justify the time they invest into the QGIS project. Our developers
> LOVE working on QGIS, but they also like to eat and pay their rents!
> - Run your own crowd funding or co-funding campaign and raise funds to
> see the feature sponsored.
> If you've any questions regarding how to approach any of these
> suggestions, just ask below, and one of our team members will assist."

That's nice and positive wording - definitely worth a try :-)

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

Re: [QGIS-Developer] QGIS and Proj 6

[C Hamilton]

Nyall,

I just wanted to thank you for doing this. QGIS is already awesome, but
this makes it even more awesome.

Calvin

On Mon, Jun 3, 2019 at 3:28 AM 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

[QGIS-Developer] Plugin [1456] EO Time Series Viewer approval notification.

[noreply]

Plugin EO Time Series Viewer approval by zimbogisgeek.
The plugin version "[1456] EO Time Series Viewer 1.2.20190603T1435.master" is 
now approved
Link: http://plugins.qgis.org/plugins/timeseriesviewerplugin/
___
QGIS-Developer mailing list
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 and Proj 6

[Nyall Dawson]

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

Re: [QGIS-Developer] QGIS Print Layouts Graphs and Charts – campaign deadline extended!

[Nyall Dawson]

On Wed, 1 May 2019 at 20:53, Nyall Dawson  wrote:
>
> Hi lists!
>
> I'm sure most members of this list will already be familiar with the QGIS 
> Print Layouts Graphs and Charts crowd funding which North Road are currently 
> running in partnership with Faunalia.
>
> Unfortunately the required funds for this campaign weren’t raised within our 
> original April 30 deadline. But, because both North Road and Faunalia very 
> much want to see this work progress, we’ve decided to extend this campaign by 
> an additional 30 days in the hopes that the users and organisations from the 
> wider QGIS community will jump onboard and pledge the remaining required 
> funds.
>
> This missing feature is a large gap in QGIS printing capabilities, so we’re 
> counting on everyone to show their support and spread the word to the local 
> user groups, QGIS users, and any other organisations you know of who rely on 
> QGIS and would love to see its inbuilt reporting capabilities levelled up!
>
> More details about the campaign and the planned functionality are available 
> at https://north-road.com/qgis-data-plotly-campaign/

Great news -- thanks to the extended deadline, and dozens of fantastic
sponsors, this campaign hit its target and the work will proceed as
planned!

More details at
https://north-road.com/2019/04/30/qgis-print-layouts-graphs-and-charts-campaign-deadline-extended/

Many thanks to everyone involved, all the sponsors, and everyone who
helped spread the word about this campaign.

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