[QGIS-Developer] What GDAL and PROJ versions with 3.10.2?

[pergler]

I know there's been a lot of inter-project cooperation to fix
projection-related bugs lately, and that the point release was delayed to
coordinate QGIS, GDAL, and PROJ patches.

 

What GDAL and PROJ versions *should* one have with the normal-stream 3.10.2
release (i.e. not 3.4.X LTR nor weekly 3.11 build)?

 

I installed 3.10.2 (OSGeo4W installer) over the weekend, and I'm running
into a bunch of issues (zoom crashes -
https://github.com/qgis/QGIS/issues/33902; corrupted output from
georeferencer, custom CRS that has lost its USER:x label). Before I try
to pick them off one by one, is it possible the right dependencies didn't
make it into the install?

 

My About. screen says I have GDAL 3.0.2 and PROJ "6.2.1 dated Nov 1", which
makes me suspicious.

 

Thanks, Martin

 

---

Martin Pergler

 <mailto:m...@pergler.org> m...@pergler.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

Re: [QGIS-Developer] Not all QGIS 3.10.2 downloads did contain the upgraded GDAL and PROJ versions (Re: What GDAL and PROJ versions with 3.10.2?)

[pergler]

Thank you for the follow-up, Raphael.

I'm now up to date and all works for me.

 

My original message was just before the mad scramble to re-release 3.10.x
with 3.0.3 and 6.3.0 (and in fact may together with the associated bug
reports have prompted it). 

 

My appreciation to the developers for the quick followup (doubtless
displacing whatever Nyall et al meant to be doing last week..), and for
doing their best to maintain a complex and very capable geospatial software
ecosystem. Not easy, in the open-source or commercial software environments.

 

I think there are lessons to be learnt about what should trigger (and, on
the flip side, be allowed in) _._._-x, _._.x, and _.x releases. In
particular, given the criticality I suspect it would have been better to
withdraw 3.10.2 and issue the fix as 3.10.3. And (earlier) to not try to
backport the Proj4->Proj6 shift into QGIS 3.4.x at all. (And maybe to not
change custom projection functionality as much between 3.10.1 and 3.10.2,
waiting until 3.12.) But I realize we were scrambling to fix the darn thing
rather than splitting hairs on versioning, and I think we can wait for the
devs' PTSD symptoms to abate somewhat before conclusive postmortems!

 

Thanks again,

Martin

 

 

 

From: Raphael Das Gupta  
Sent: January 28, 2020 07:16
To: qgis-developer@lists.osgeo.org
Cc: perg...@gmail.com
Subject: Not all QGIS 3.10.2 downloads did contain the upgraded GDAL and
PROJ versions (Re: [QGIS-Developer] What GDAL and PROJ versions with
3.10.2?)

 

Hi again

On 20.01.20 11:45, perg...@gmail.com   wrote:

I installed 3.10.2 (OSGeo4W installer) over the weekend, and I'm running
into a bunch of issues (zoom crashes -
https://github.com/qgis/QGIS/issues/33902; corrupted output from
georeferencer, custom CRS that has lost its USER:x label). Before I try
to pick them off one by one, is it possible the right dependencies didn't
make it into the install?

 

My About. screen says I have GDAL 3.0.2 and PROJ "6.2.1 dated Nov 1", which
makes me suspicious.

Apparently, the first Windows builds of release 3.10.2 still included older
versions of GDAL/OGR and PROJ. See this thread
  on this list.
https://lists.osgeo.org/pipermail/qgis-developer/2020-January/060001.html
seems to indicate that 3.10.2 was re-released some time before 2020-01-23
16:16 PST (2020-01-24 00:16 UTC). So if you downloaded QGIS 3.10.2 before
that, you should re-download it to not suffer from the bugs of the old
library versions.

I don't know why the 3.10.2 was re-released instead of releasing 3.10.3 with
the upgraded library versions as suggested in that mailing list thread (here

and here

). Releasing it as 3.10.3 would have made it more clear to users, which
version they actually downloaded and would have been more in line with
semantic versioning concepts. (I dunno whether QGIS aims to follow semantic
versioning conventions.)

Kind regards,
Raphael

___
QGIS-Developer mailing list
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] Heads up: no osgeo4w qgis-dev nightly since Nov 20

[pergler]

Just a heads up that the osgeo4w nightly qgis-dev build hasn't been updated
since Nov 20. 

No worries, but it does mean recent commits to master are getting less than
the usual dev-channel userbase testing, at least under Windows. 

 

A ticket has been filed: https://trac.osgeo.org/osgeo4w/ticket/707

 

---

Martin Pergler

 

___
QGIS-Developer mailing list
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] Handling NULL differs in concat vs || in expressions: let's remove ||

[Martin Pergler]

Matthias Kuhn 🌍 wrote
> For what it's worth, I agree with Richard that it's often not what's 
> expected. And the worst is that on first sight it looks as if it's 
> working as expected.
> [...]
> The functionality of `||` on the other hand should be left untouched. 
> (it's useful to have e.g. `prefix || filename` produce NULL if filename 
> is NULL)
> 
> Matthias

Full +1 with Matthias (and others).
Partial +1 with Richard; you're right that it's unexpected at first. We
should make sure it's explained in help, and if space permits some clue in
the tooltip wouldn't hurt.

But I think for better or worse lots of users (those that use expressions,
that is...) will have developed code in their projects that harnesses the
nuances of ||, concat, and coalesce around NULL in specific ways. I'd be
very careful about changing or getting rid of || since it will break stuff.

No opinion on the buttons.



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

Re: [QGIS-Developer] 3.12.1/3.10.4 releases?

[Martin Pergler]

Nyall, don't know the backstory (if any), but 3.12.1 has appeared sometime in
the past 6-7 hours or so, at least through the OSGeo4W installer, which
calls it 3.12.1-2 I believe. Uses proj 6.3.1.

Hurrah!

(You may well already know this, but replying since no answer visible here
yet.)

QGIS version
3.12.1-București
QGIS code revision
121cc00ff0
Compiled against Qt
5.11.2
Running against Qt
5.11.2
Compiled against GDAL/OGR
3.0.4
Running against GDAL/OGR
3.0.4
Compiled against GEOS
3.8.1-CAPI-1.13.3
Running against GEOS
3.8.1-CAPI-1.13.3
Compiled against SQLite
3.29.0
Running against SQLite
3.29.0
PostgreSQL Client Version
11.5
SpatiaLite Version
4.3.0
QWT Version
6.1.3
QScintilla2 Version
2.10.8
Compiled against PROJ
6.3.1
Running against PROJ
Rel. 6.3.1, February 10th, 2020
OS Version
Windows 10 (10.0)




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

Re: [QGIS-Developer] Issue with QGIS 3.16.2 standalone and GRASS 7.8.4

[Martin Pergler]

Andrea Giudiceandrea wrote
> yes, I can confirm that both 3.16.2-2 and 3.10.13-2 standalone installers
> ship QGIS with GRASS 7.8.5 and the issue is now fixed for both thanks to
> Jürgen E. Fischer.

However, as far as I can tell, the OSGeo4W component installer seems to only
know about 3.16.2*-1* and 3.10.13*-1*, though it does also install GRASS
7.8.5.  

Therefore a seemingly up-to-date OSGeo4W install of QGIS + GRASS continues
to fail to load GRASS.



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

Re: [QGIS-Developer] Issue with QGIS 3.16.2 standalone and GRASS 7.8.4

[Martin Pergler]

Myriam63 wrote
> Hi all
> 
> I installed the version of QGIS with
> QGIS-OSGeo4W-3.16.2-2-Setup-x86_64.exe,
> but the versions that were installed are 3.16.2-1 (not 3.16.2-2) for QGIS
> and 7.8.5-1 for GRASS, checked with OSGeo4W Setup.
> When i use QGIS with "QGIS Desktop 3.16.2 with GRASS 7.8.4" link, i get
> the
> following error message:
> 2020-12-24T14:15:50 WARNINGGRASS init error : Problem in GRASS
> initialization, GRASS provider and plugin will not work : Module built
> against version d8fbd49af but trying to use version 2b6ab2893. You need to
> rebuild GRASS GIS or untangle multiple installations.
> and I cannot use GRASS7 extension.
> 
> Someone can help me ?
> Thank you so much.
> 
> 
> 
> --
> Sent from:
> http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
> ___
> QGIS-Developer mailing list

> QGIS-Developer@.osgeo

> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

>From Andrea's reponse to my email upstream on this, my hypothesis is that
the Windows QGIS standalone installer on the QGIS website installs 3.16.2-2,
and works with GRASS. 

However, the OSGeo4W component installer (whatever it is properly called,
where you choose which OSGeo packages are to be installed and can update
previous installations), *still* installs 3.16.2-1, and therefore GRASS does
not work under QGIS.

However, I have not had time to test this since Andrea's email, and so I may
be wrong. But your (Myriam's) experience in addition to mine would support
it.



--
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] Map canvas displays at wrong scale (logical vs physical dpi)

[Martin Pergler]

I posted this as a bug at https://github.com/qgis/QGIS/issues/41248 and
Giovanni Manghi suggested I bring it here.

For a lot of users, QGIS currently shows the main map canvas at the wrong
scale, whenever their systemwide "display scaling"(=logical dpi) doesn't
match their screen's physical dpi. It's disconcerting side-by-side with a
printed map, and just incorrect. We can do better, since Qt exposes both
logical and physical dpi. But fixing it would change on-screen behaviour
users are accustomed to.

I think the right solution is to continue using logical DPI for QGIS UI
elements, but initialize mapCanvas().mapSettings().outputDPI() from
iface.mainWindow().physicalDpiX() rather than .logicalDpiX(). And to make
this change opt-in via a setting in Options / Canvas & Legend called
something like "Render canvas at", with a choice of"System DPI" (=logical
DPI), "Physical screen DPI", or a user-defined DPI (since I'm sure some
external monitors will have physical DPI wrong). 

More details at https://github.com/qgis/QGIS/issues/41248
Comments welcome here or there; I know this will be a bit controversial
since we've all gotten used to the "wrong" way on our screens!



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

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

[Martin Pergler]

Happy to take this on (next week, this week is a bit crazy).
I like all 3 examples given: key thing being leading off much more with an
easy-to-understand, illustrated list of main functionality and use cases.

By way of introduction, 30 years ago I was a software developer, back when
Pascal and C (++ was cutting edge!) were mainstream and Prolog was sexy (at
least for geeks, that is). I then became a mathematician for a while, before
going into business consulting. I've done a fair amount of technical writing
and ran an editorial board for a while. My day job is now risk consulting,
including probabilistic modeling, Excel/VBA, and R. On the side I help
manage and preserve a decent chunk of Canadian wilderness, through which in
the past couple of years I've become more and more involved in GIS. First,
just making a map of the darned thing, but more recently vegetation and
land-use analysis, indexing of research notes and wildlife photos,
automation so others can use it, and even more recently UAV 2.5D mapping.
I'm also a frequent contributor (Q and A) at gis.stackexchange.com

Happy also to work on this 4 (or more) hands if anyone else wants to help
out. Otherwise, I'll sit back this week and accept with gratitude any
additional suggestions of what to cover or how. I'll then come back with a
1st (but doubtlessly incomplete) draft next week.

Martin Pergler




--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

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

[Martin Pergler]

As per the thread last week, with the help of Jorge Gustavo Rocha (regarding
server) and Ben Hur Pintor, I've taken a first crack at revising the Github
landing page to be more exciting, up-to-date, and visual.

The current draft is at
https://github.com/Houska1/QGIS/blob/README-md-update/README.md; all
comments welcome (here, there, or by email to perg...@gmail.com).

At this stage, I'd love to get buy in on the overall structure, and the
choice of the 5 high-level points under Features. We can then hunt for
better illustrations for each -- right now, I grabbed something from the
user manual or qgis.org gallery for each one, but we can probably do better.
Might even make sense to make something custom at a better image
size/resolution (but only once we're collectively happy we have the right
points to illustrate...).

Cheers,
Martin



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

Re: [QGIS-Developer] [Qgis-psc] Unscheduled 3.18.1 release?

[Martin Pergler]

+1 on the idea.

How far away is the OSGeo4W "reboot" from moving from testing to release? If
similar timing, would it make sense to coordinate with this 3.18.1?  At the
risk of being annoyingly Windows-centric, I suspect for a lot of our Windows
userbase, the distinction between "point release of QGIS" and "availability
of (new/improved/streamlined) Windows build" is murky at best.



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

Re: [QGIS-Developer] QGIS compiled agains GDAL 3.3.0 crash opening a project

[Martin Pergler]

Seems GDAL 3.3.0 is miscompiled. In my case, I'm not getting crashes, just
QGIS unable to open any LERC-compressed TIFF files with an uninformative
error message from QGIS. However, can be tracked down to GDAL likely
compiled without internal libtiff and so gdalinfo gives:

Warning 1: GS0327-dem_cliplerc.tif: GS0327-dem_cliplerc.tif:LERC compression
support is not configured
ERROR 1: GS0327-dem_cliplerc.tif: Cannot open TIFF file due to missing
codec.

Bug report submitted (for the LERC problem, not your crash):
https://trac.osgeo.org/osgeo4w/ticket/679



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

Re: [QGIS-Developer] Agree to requirements for new contributors

[Martin Pergler]

Welcome Miguel!

Since in recent months I've made a few contributions around the edges, I
hereby catch up on the formalities and also agree to the requirements for
contributors as listed at
https://qgis.org/en/site/getinvolved/development/contributor_requirements.html

Martin Pergler



--
Sent from: http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Accessing clipboard from PyQGis

[Martin Pergler]

Can one access the internal QGIS clipboard (as defined in
qgsclipboard.h/cpp) in a python script or plugin within QGis desktop?

I've tried QgsApplication.clipboard() and QApplication.clipboard, both of
which return a PyQt5 QClipboard object rather than a QgsClipboard.

In a plugin I'm developing, I'd love to make use of features copied to the
clipboard in native format (e.g. via the copyOf() method of QgsClipboard).
However, if I get a QClipboard I only have access to a text()
representation, the WKT or geoJson format of the features depending
on Settings -> Options -> Data sources -> Copy features as... The same
is also accessible as -- apparently -- the only MIME type via
.mimeData().formats().

I'm running QGis version 3.6.3 on Win10. (Note this is dup of
https://gis.stackexchange.com/questions/322878/accessing-internal-qgis-clipboard-in-python
that
I asked a week ago).

Thanks!

-- 
Martin Pergler
m...@pergler.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

Re: [QGIS-Developer] Blocking of SAGA & GRASS batch files by Windows AppLocker

[Martin Pergler via QGIS-Developer]

Dirk - and others:

 

I'm not a core developer, but I have some experience with AppLocker. 

 

I believe your IT staff or perhaps even yourself ought to be able to code an
"Allow" permission exception in AppLocker, based for instance on the
guidance at
https://www.tenforums.com/tutorials/124016-use-applocker-allow-block-script-
files-windows-10-a.html

You will have to allow scripts in directory
%userprofile%\AppData\QGIS\QGIS3\PROFILES\DEFAULT\PROCESSING

Or something like that, I don't have AppLocker active to test it out; it's
wherever the offending batch files get placed.

 

With all respect to innocent users like you caught in the middle, I do feel
that an application, like QGIS, that does processing can very reasonably be
expected to need to write and execute dynamic script files to communicate
with other programs. This is, in fact, arguably exactly why script files
were invented many years ago. Blanket forbidding their execution is a
simplified but overzealous security policy measure, and your IT department
should be willing to work with you to create an exception for your use case.
In fact, the running of scripts in a user-writable directory, whether they
are dynamically generated by trusted software like QGIS, or written manually
by you, is a pretty standard tool in running replicable geospatial analysis
of any sort. So I think the appropriate analog you should use in discussing
with your IT dept is that it would be equally unreasonable to preclude you
from running any new program (executable) files on your computer if you were
a developer who was compiling code!

 

On Fri Jun 17 05:06:18 PDT 2022, Dirk.Pispers at STADT-KOELN.DE wrote via
qgis-developer:

> Hi list,

> refering to the post "Blocking of SAGA & GRASS batch files by MS
AppLocker<https://www.mail-archive.com/qgis-developer@lists.osgeo.org/msg514
08.html>" 

> in Aug 2020 I would like to reopen the discussion about the
SAGA/GRASS/AppLocker problem.

> I my organisation AppLocker has recently been activated und the generated
batch files from SAGA and GRASS processings are blocked now.

> Since switchting to a different file location is not a valid solution as
Nyall Dawson postet in 2020, is it possible to submit the command directly
in QGIS instead of writing it into a batch file und call this file?

 

---

Martin Pergler

 <mailto:m...@pergler.org> m...@pergler.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