On Tue, 22 Jan 2019 at 16:56, Andreas Neumann <[email protected]> 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 <[email protected]> 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 > > _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
