[QGIS-Developer] $scale vs @map_scale - QGIS v2 vs v3

Nyall Dawson nyall.dawson at gmail.com
Mon Jan 21 23:03:51 PST 2019


On Tue, 22 Jan 2019 at 16:56, Andreas Neumann <a.neumann at carto.net> wrote:
>
> Hi Nyall,
>
> Thanks. It is not about myself - I can live with it - but I fear many others who migrate might run into the same issue.
>
> Ideally the old code could still work through the alias, but the $scale wouldn't be listed anymore in the expression editor - so it wouldn't be advertised anymore. Is this the idea?

That's exactly what the PR does. So new projects will be guided to the
@map_scale approach, but older ones will still work.

Nyall

>
> Anyway - thanks a lot for adding this alias!
>
> I found projects in our organization where $scale was used >500 times within the project - used in lots of CASE WHEN END statements for defining stroke-widths and font-sizes depending on scale ranges in various layer configuration.
>
> Andreas
>
> On 2019-01-21 23:53, Nyall Dawson wrote:
>
> On Mon, 21 Jan 2019 at 22:52, Andreas Neumann <a.neumann at carto.net> wrote:
>
>
> Hi,
>
> When migrating our version 2 to version 3 projects, most of our symbology needs revision, because our data-defined properties used a lot the "$scale" variable.
>
> What is the exact reason that $scale fails in version 3 and had been replaced by @map_scale?
>
> Is there really no upgrade path for this? We have many, many projects, and almost all of them need to be upgraded in version 3 to use "@map_scale" instead of "$scale".
>
>
> There is a technical reason behind this, but there's also no technical
> reason we couldn't make $scale silently "alias" to @map_scale. My
> original thinking was that I wanted to strip out some of these older
> expression formats, and 3.0 was a good opportunity to do this. But I'm
> happy to reverse this decision.
>
> PR incoming.
>
> Nyall
>
>


More information about the QGIS-Developer mailing list