Re: [Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?

[Tim Sutton]

Hi

I don't think there has been a strong enough argument to keep the extra 
bloat.and the potential goodies you hint at coming if they are removed have 
a broader benefit to all users over some hidden features that nobody 
understands.

Tim Sutton 
Co-founder of Kartoza 
Ex-QGIS project chairman 

> On 6 Aug 2019, at 07:59, Luigi Pirelli  wrote:
> 
> Hi Nyall
> 
> "Ok, we've hit a stalemate then. I was hoping to drop the additional 
> algorithms..." please remove. Try and error without a good statistic or 
> collection of maps where these options can do the difference IMHO is not 
> strong enough respect cleaning code and void bug fixing.
> 
> Luigi Pirelli
> 
> **
> * LinkedIn: https://www.linkedin.com/in/luigipirelli
> * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
> * GitHub: https://github.com/luipir
> * Book: Mastering QGIS3 - 3rd Edition
> * Hire a team: http://www.qcooperative.net
> **
> 
> 
>> On Tue, 6 Aug 2019 at 06:03, Nyall Dawson  wrote:
>> On Mon, 29 Jul 2019 at 17:33, Carlo A. Bertelli (Charta s.r.l.)
>>  wrote:
>> >
>> > Yes, if you consider trial and error a mindful method, I "use" label 
>> > placement algorithms when preparing a cartographic layout for printing.
>> > I mainly work on geographic data and web output, so it's not frequent and 
>> > I follow the easy and dumb way: I swap algorithms, hoping for a result 
>> > that solves cluttering in the worst spots, until it fits – usually it fits 
>> > here and it's out of order elsewhere...
>> > I generally criticise this approach, but when looking for a good 
>> > appearance, it seems bearable. Yes, I would need some more information to 
>> > do a better work. As already said, I think this is a cartographic issue 
>> > that can get more benefits by a better GIS approach. Label positioning is 
>> > not "substantial" but can exploit proper data. Say population for a 
>> > populated place. Using these algorithms on top of geometric-only data 
>> > gives little more than casual results.
>> > I had the opportunity to weight the theory behind these methods starting 
>> > from the obituary of Mitchell Jay Feigenbaum by Maurizio Codogno on 
>> > ilPost.it that referenced the New York Times: 
>> > https://www.nytimes.com/2019/07/18/science/mitchell-feigenbaum-dead.html. 
>> > Looking to further developments, I think there is not a "best" algorithm, 
>> > but that it's useful to keep alternatives. I doubt the algorithms could 
>> > really work well without an interface that can reach useful data, but
>> 
>> Ok, we've hit a stalemate then. I was hoping to drop the additional
>> algorithms to allow some desirable new features like avoiding
>> duplicate text labels within xxx mm of others (e.g. avoiding too many
>> labels for dual-carriage highways), and use that some logic to start
>> implementing things like automatically abbreviated label text when the
>> full text cannot be placed. But, if we keep all the existing
>> algorithms, it basically means this logic has to be written multiple
>> times. Ouch!
>> 
>> > I also think that keeping them available without any special interface 
>> > could keep them in a place that is not really influenced by the frequent 
>> > enhancements of QGIS.
>> 
>> Sounds great in theory, but the labeling code structure and logic
>> doesn't work that allow that.
>> 
>> Nyall
>> 
>> 
>> 
>> > c
>> >
>> >
>> > On Mon, Jul 29, 2019 at 8:31 AM Nyall Dawson  
>> > wrote:
>> >>
>> >> On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.)
>> >>  wrote:
>> >> >
>> >> > Label placement took a lot of time and efforts in the past and this is 
>> >> > the outcome.
>> >> > It's true, there is no real need for it while on screen, but it could 
>> >> > be very useful in Layout. The problem is similar to generalisation, you 
>> >> > need proper data to support label placement. Losing the relationship 
>> >> > with real geographic objects, when exporting the layout in SVG or 
>> >> > postscript, label placement takes time and needs cartographic expertise 
>> >> > while changing the algorithm in Layout mode can help a lot.
>> >>
>> >> So - just to confirm -- you are actively changing that setting, and
>> >> seeing useful results from different methods? If so, which do you use?
>> >> Which give the best results? What's the trade off between them?
>> >>
>> >> Nyall
>> >>
>> >>
>> >> > Keeping several algorithms in Layout could ease code maintenance while 
>> >> > keeping all the advantages.
>> >> > On the other hand, this needs some efforts on documentation and Anita's 
>> >> > touch is really welcome here. Algorithms need reference but also a 
>> >> > plain explanation in something that resembles a book. Someone developed 
>> >> > a publishing business out of a GIS program... maybe this is too much 
>> >> > and 

Re: [Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?

[Luigi Pirelli]

Hi Nyall

"Ok, we've hit a stalemate then. I was hoping to drop the additional
algorithms..." please remove. Try and error without a good statistic or
collection of maps where these options can do the difference IMHO is not
strong enough respect cleaning code and void bug fixing.

Luigi Pirelli

**
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Book: Mastering QGIS3 - 3rd Edition

* Hire a team: http://www.qcooperative.net
**


On Tue, 6 Aug 2019 at 06:03, Nyall Dawson  wrote:

> On Mon, 29 Jul 2019 at 17:33, Carlo A. Bertelli (Charta s.r.l.)
>  wrote:
> >
> > Yes, if you consider trial and error a mindful method, I "use" label
> placement algorithms when preparing a cartographic layout for printing.
> > I mainly work on geographic data and web output, so it's not frequent
> and I follow the easy and dumb way: I swap algorithms, hoping for a result
> that solves cluttering in the worst spots, until it fits – usually it fits
> here and it's out of order elsewhere...
> > I generally criticise this approach, but when looking for a good
> appearance, it seems bearable. Yes, I would need some more information to
> do a better work. As already said, I think this is a cartographic issue
> that can get more benefits by a better GIS approach. Label positioning is
> not "substantial" but can exploit proper data. Say population for a
> populated place. Using these algorithms on top of geometric-only data gives
> little more than casual results.
> > I had the opportunity to weight the theory behind these methods starting
> from the obituary of Mitchell Jay Feigenbaum by Maurizio Codogno on
> ilPost.it that referenced the New York Times:
> https://www.nytimes.com/2019/07/18/science/mitchell-feigenbaum-dead.html.
> Looking to further developments, I think there is not a "best" algorithm,
> but that it's useful to keep alternatives. I doubt the algorithms could
> really work well without an interface that can reach useful data, but
>
> Ok, we've hit a stalemate then. I was hoping to drop the additional
> algorithms to allow some desirable new features like avoiding
> duplicate text labels within xxx mm of others (e.g. avoiding too many
> labels for dual-carriage highways), and use that some logic to start
> implementing things like automatically abbreviated label text when the
> full text cannot be placed. But, if we keep all the existing
> algorithms, it basically means this logic has to be written multiple
> times. Ouch!
>
> > I also think that keeping them available without any special interface
> could keep them in a place that is not really influenced by the frequent
> enhancements of QGIS.
>
> Sounds great in theory, but the labeling code structure and logic
> doesn't work that allow that.
>
> Nyall
>
>
>
> > c
> >
> >
> > On Mon, Jul 29, 2019 at 8:31 AM Nyall Dawson 
> wrote:
> >>
> >> On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.)
> >>  wrote:
> >> >
> >> > Label placement took a lot of time and efforts in the past and this
> is the outcome.
> >> > It's true, there is no real need for it while on screen, but it could
> be very useful in Layout. The problem is similar to generalisation, you
> need proper data to support label placement. Losing the relationship with
> real geographic objects, when exporting the layout in SVG or postscript,
> label placement takes time and needs cartographic expertise while changing
> the algorithm in Layout mode can help a lot.
> >>
> >> So - just to confirm -- you are actively changing that setting, and
> >> seeing useful results from different methods? If so, which do you use?
> >> Which give the best results? What's the trade off between them?
> >>
> >> Nyall
> >>
> >>
> >> > Keeping several algorithms in Layout could ease code maintenance
> while keeping all the advantages.
> >> > On the other hand, this needs some efforts on documentation and
> Anita's touch is really welcome here. Algorithms need reference but also a
> plain explanation in something that resembles a book. Someone developed a
> publishing business out of a GIS program... maybe this is too much and has
> already been done, but...
> >> > My two eurocents.
> >> > c
> >> >
> >> > On Mon, Jul 29, 2019 at 2:00 AM Nyall Dawson 
> wrote:
> >> >>
> >> >> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson 
> wrote:
> >> >> >
> >> >> > Hey lists
> >> >> >
> >> >> > This was first discussed back in 2016 (see
> >> >> >
> http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html
> ),
> >> >> > but would anyone object if the different labeling solution
> algorithms
> >> >> > eg 

Re: [Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?

[Régis Haubourg]

+1 for the removal too. Never could explain the difference. Playing with
number of candidates is a lot more useful than changing the algorithm.
Best regards
Régis

Le mar. 6 août 2019 à 08:14, Anita Graser  a écrit :

> On Fri, Jul 26, 2019 at 4:40 AM Nyall Dawson 
> wrote:
>
>> Does ANYONE understand or change this setting? Or would object to its
>> complete removal?
>>
>
> I'd be +1 for removal. I know about the setting, don't understand the
> algorithmic differences, have tried them in the past, didn't see meaningful
> differences in the results.
>
> Regards,
> Anita
>
>
> ___
> QGIS-Developer mailing list
> qgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?

[Anita Graser]

On Fri, Jul 26, 2019 at 4:40 AM Nyall Dawson  wrote:

> Does ANYONE understand or change this setting? Or would object to its
> complete removal?
>

I'd be +1 for removal. I know about the setting, don't understand the
algorithmic differences, have tried them in the past, didn't see meaningful
differences in the results.

Regards,
Anita
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?

[Nyall Dawson]

On Mon, 29 Jul 2019 at 17:33, Carlo A. Bertelli (Charta s.r.l.)
 wrote:
>
> Yes, if you consider trial and error a mindful method, I "use" label 
> placement algorithms when preparing a cartographic layout for printing.
> I mainly work on geographic data and web output, so it's not frequent and I 
> follow the easy and dumb way: I swap algorithms, hoping for a result that 
> solves cluttering in the worst spots, until it fits – usually it fits here 
> and it's out of order elsewhere...
> I generally criticise this approach, but when looking for a good appearance, 
> it seems bearable. Yes, I would need some more information to do a better 
> work. As already said, I think this is a cartographic issue that can get more 
> benefits by a better GIS approach. Label positioning is not "substantial" but 
> can exploit proper data. Say population for a populated place. Using these 
> algorithms on top of geometric-only data gives little more than casual 
> results.
> I had the opportunity to weight the theory behind these methods starting from 
> the obituary of Mitchell Jay Feigenbaum by Maurizio Codogno on ilPost.it that 
> referenced the New York Times: 
> https://www.nytimes.com/2019/07/18/science/mitchell-feigenbaum-dead.html. 
> Looking to further developments, I think there is not a "best" algorithm, but 
> that it's useful to keep alternatives. I doubt the algorithms could really 
> work well without an interface that can reach useful data, but

Ok, we've hit a stalemate then. I was hoping to drop the additional
algorithms to allow some desirable new features like avoiding
duplicate text labels within xxx mm of others (e.g. avoiding too many
labels for dual-carriage highways), and use that some logic to start
implementing things like automatically abbreviated label text when the
full text cannot be placed. But, if we keep all the existing
algorithms, it basically means this logic has to be written multiple
times. Ouch!

> I also think that keeping them available without any special interface could 
> keep them in a place that is not really influenced by the frequent 
> enhancements of QGIS.

Sounds great in theory, but the labeling code structure and logic
doesn't work that allow that.

Nyall



> c
>
>
> On Mon, Jul 29, 2019 at 8:31 AM Nyall Dawson  wrote:
>>
>> On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.)
>>  wrote:
>> >
>> > Label placement took a lot of time and efforts in the past and this is the 
>> > outcome.
>> > It's true, there is no real need for it while on screen, but it could be 
>> > very useful in Layout. The problem is similar to generalisation, you need 
>> > proper data to support label placement. Losing the relationship with real 
>> > geographic objects, when exporting the layout in SVG or postscript, label 
>> > placement takes time and needs cartographic expertise while changing the 
>> > algorithm in Layout mode can help a lot.
>>
>> So - just to confirm -- you are actively changing that setting, and
>> seeing useful results from different methods? If so, which do you use?
>> Which give the best results? What's the trade off between them?
>>
>> Nyall
>>
>>
>> > Keeping several algorithms in Layout could ease code maintenance while 
>> > keeping all the advantages.
>> > On the other hand, this needs some efforts on documentation and Anita's 
>> > touch is really welcome here. Algorithms need reference but also a plain 
>> > explanation in something that resembles a book. Someone developed a 
>> > publishing business out of a GIS program... maybe this is too much and has 
>> > already been done, but...
>> > My two eurocents.
>> > c
>> >
>> > On Mon, Jul 29, 2019 at 2:00 AM Nyall Dawson  
>> > wrote:
>> >>
>> >> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson  wrote:
>> >> >
>> >> > Hey lists
>> >> >
>> >> > This was first discussed back in 2016 (see
>> >> > http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html),
>> >> > but would anyone object if the different labeling solution algorithms
>> >> > eg "chain" / "pop music" / "falp" / etc were dropped, and we just
>> >> > leave the existing default (chain)?
>> >> >
>> >> > I don't think ANYONE knows what these mean, and it's a heck of a lot
>> >> > of code (which needs fixes) to cart around for no compelling reason
>> >> > that I can see.
>> >> >
>> >> > I have no particular preference to any of the methods, so would
>> >> > happily accept a different default if anyone out there can point to
>> >> > which method is best!
>> >> >
>> >> > Googling pop music / tabu / chain only gives a handful of results
>> >> > relating to QGIS labeling engine. And googling for "falp" sounds like
>> >> > something that would get you flagged on your company's firewall.
>> >> >
>> >> > Does ANYONE understand or change this setting? Or would object to its
>> >> > complete removal?
>> >>
>> >> PR at https://github.com/qgis/QGIS/pull/30960
>> >>
>> >> Last chance to save this setting!
>> >>
>> >> Nyall
>> >> 

Re: [Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?

[Carlo A. Bertelli (Charta s.r.l.)]

Yes, if you consider trial and error a mindful method, I "use" label
placement algorithms when preparing a cartographic layout for printing.
I mainly work on geographic data and web output, so it's not frequent and I
follow the easy and dumb way: I swap algorithms, hoping for a result that
solves cluttering in the worst spots, until it fits – usually it fits here
and it's out of order elsewhere...
I generally criticise this approach, but when looking for a good
appearance, it seems bearable. Yes, I would need some more information to
do a better work. As already said, I think this is a cartographic issue
that can get more benefits by a better GIS approach. Label positioning is
not "substantial" but can exploit proper data. Say population for a
populated place. Using these algorithms on top of geometric-only data gives
little more than casual results.
I had the opportunity to weight the theory behind these methods starting
from the obituary of Mitchell Jay Feigenbaum by Maurizio Codogno on
ilPost.it that referenced the New York Times:
https://www.nytimes.com/2019/07/18/science/mitchell-feigenbaum-dead.html.
Looking to further developments, I think there is not a "best" algorithm,
but that it's useful to keep alternatives. I doubt the algorithms could
really work well without an interface that can reach useful data, but I
also think that keeping them available without any special interface could
keep them in a place that is not really influenced by the frequent
enhancements of QGIS.
c


On Mon, Jul 29, 2019 at 8:31 AM Nyall Dawson  wrote:

> On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.)
>  wrote:
> >
> > Label placement took a lot of time and efforts in the past and this is
> the outcome.
> > It's true, there is no real need for it while on screen, but it could be
> very useful in Layout. The problem is similar to generalisation, you need
> proper data to support label placement. Losing the relationship with real
> geographic objects, when exporting the layout in SVG or postscript, label
> placement takes time and needs cartographic expertise while changing the
> algorithm in Layout mode can help a lot.
>
> So - just to confirm -- you are actively changing that setting, and
> seeing useful results from different methods? If so, which do you use?
> Which give the best results? What's the trade off between them?
>
> Nyall
>
>
> > Keeping several algorithms in Layout could ease code maintenance while
> keeping all the advantages.
> > On the other hand, this needs some efforts on documentation and Anita's
> touch is really welcome here. Algorithms need reference but also a plain
> explanation in something that resembles a book. Someone developed a
> publishing business out of a GIS program... maybe this is too much and has
> already been done, but...
> > My two eurocents.
> > c
> >
> > On Mon, Jul 29, 2019 at 2:00 AM Nyall Dawson 
> wrote:
> >>
> >> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson 
> wrote:
> >> >
> >> > Hey lists
> >> >
> >> > This was first discussed back in 2016 (see
> >> >
> http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html
> ),
> >> > but would anyone object if the different labeling solution algorithms
> >> > eg "chain" / "pop music" / "falp" / etc were dropped, and we just
> >> > leave the existing default (chain)?
> >> >
> >> > I don't think ANYONE knows what these mean, and it's a heck of a lot
> >> > of code (which needs fixes) to cart around for no compelling reason
> >> > that I can see.
> >> >
> >> > I have no particular preference to any of the methods, so would
> >> > happily accept a different default if anyone out there can point to
> >> > which method is best!
> >> >
> >> > Googling pop music / tabu / chain only gives a handful of results
> >> > relating to QGIS labeling engine. And googling for "falp" sounds like
> >> > something that would get you flagged on your company's firewall.
> >> >
> >> > Does ANYONE understand or change this setting? Or would object to its
> >> > complete removal?
> >>
> >> PR at https://github.com/qgis/QGIS/pull/30960
> >>
> >> Last chance to save this setting!
> >>
> >> Nyall
> >> ___
> >> QGIS-Developer mailing list
> >> qgis-develo...@lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> >
> >
> >
> > --
> >
> --
> > 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  mobile:+39 393
> 1590711
> >e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
> >
> --
> >
> >
> >
>


-- 

Re: [Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?

[Nyall Dawson]

On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.)
 wrote:
>
> Label placement took a lot of time and efforts in the past and this is the 
> outcome.
> It's true, there is no real need for it while on screen, but it could be very 
> useful in Layout. The problem is similar to generalisation, you need proper 
> data to support label placement. Losing the relationship with real geographic 
> objects, when exporting the layout in SVG or postscript, label placement 
> takes time and needs cartographic expertise while changing the algorithm in 
> Layout mode can help a lot.

So - just to confirm -- you are actively changing that setting, and
seeing useful results from different methods? If so, which do you use?
Which give the best results? What's the trade off between them?

Nyall


> Keeping several algorithms in Layout could ease code maintenance while 
> keeping all the advantages.
> On the other hand, this needs some efforts on documentation and Anita's touch 
> is really welcome here. Algorithms need reference but also a plain 
> explanation in something that resembles a book. Someone developed a 
> publishing business out of a GIS program... maybe this is too much and has 
> already been done, but...
> My two eurocents.
> c
>
> On Mon, Jul 29, 2019 at 2:00 AM Nyall Dawson  wrote:
>>
>> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson  wrote:
>> >
>> > Hey lists
>> >
>> > This was first discussed back in 2016 (see
>> > http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html),
>> > but would anyone object if the different labeling solution algorithms
>> > eg "chain" / "pop music" / "falp" / etc were dropped, and we just
>> > leave the existing default (chain)?
>> >
>> > I don't think ANYONE knows what these mean, and it's a heck of a lot
>> > of code (which needs fixes) to cart around for no compelling reason
>> > that I can see.
>> >
>> > I have no particular preference to any of the methods, so would
>> > happily accept a different default if anyone out there can point to
>> > which method is best!
>> >
>> > Googling pop music / tabu / chain only gives a handful of results
>> > relating to QGIS labeling engine. And googling for "falp" sounds like
>> > something that would get you flagged on your company's firewall.
>> >
>> > Does ANYONE understand or change this setting? Or would object to its
>> > complete removal?
>>
>> PR at https://github.com/qgis/QGIS/pull/30960
>>
>> Last chance to save this setting!
>>
>> Nyall
>> ___
>> QGIS-Developer mailing list
>> qgis-develo...@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> --
> 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  mobile:+39 393 1590711
>e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
> --
>
>
>
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user

Re: [Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?

[Carlo A. Bertelli (Charta s.r.l.)]

Label placement took a lot of time and efforts in the past and this is the
outcome.
It's true, there is no real need for it while on screen, but it could be
very useful in Layout. The problem is similar to generalisation, you need
proper data to support label placement. Losing the relationship with real
geographic objects, when exporting the layout in SVG or postscript, label
placement takes time and needs cartographic expertise while changing the
algorithm in Layout mode can help a lot.
Keeping several algorithms in Layout could ease code maintenance while
keeping all the advantages.
On the other hand, this needs some efforts on documentation and Anita's
touch is really welcome here. Algorithms need reference but also a plain
explanation in something that resembles a book. Someone developed a
publishing business out of a GIS program... maybe this is too much and has
already been done, but...
My two eurocents.
c

On Mon, Jul 29, 2019 at 2:00 AM Nyall Dawson  wrote:

> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson  wrote:
> >
> > Hey lists
> >
> > This was first discussed back in 2016 (see
> >
> http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html
> ),
> > but would anyone object if the different labeling solution algorithms
> > eg "chain" / "pop music" / "falp" / etc were dropped, and we just
> > leave the existing default (chain)?
> >
> > I don't think ANYONE knows what these mean, and it's a heck of a lot
> > of code (which needs fixes) to cart around for no compelling reason
> > that I can see.
> >
> > I have no particular preference to any of the methods, so would
> > happily accept a different default if anyone out there can point to
> > which method is best!
> >
> > Googling pop music / tabu / chain only gives a handful of results
> > relating to QGIS labeling engine. And googling for "falp" sounds like
> > something that would get you flagged on your company's firewall.
> >
> > Does ANYONE understand or change this setting? Or would object to its
> > complete removal?
>
> PR at https://github.com/qgis/QGIS/pull/30960
>
> Last chance to save this setting!
>
> Nyall
> ___
> QGIS-Developer mailing list
> qgis-develo...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer



-- 
--
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  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu  http://www.chartasrl.eu
--
___
Qgis-user mailing list
Qgis-user@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user