<div dir="ltr">Hi Nyall<div><br></div><div>"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.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br></div><div>Luigi Pirelli<br><br>**************************************************************************************************<br>* LinkedIn: <a href="https://www.linkedin.com/in/luigipirelli" target="_blank">https://www.linkedin.com/in/luigipirelli</a><br>* Stackexchange: <a href="http://gis.stackexchange.com/users/19667/luigi-pirelli" target="_blank">http://gis.stackexchange.com/users/19667/luigi-pirelli</a><br>* GitHub: <a href="https://github.com/luipir" target="_blank">https://github.com/luipir</a><br>* Book: <a href="https://www.packtpub.com/eu/application-development/mastering-geospatial-development-qgis-3x-third-edition" target="_blank">Mastering QGIS3 - 3rd Edition</a></div><div>* Hire a team: <a href="http://www.qcooperative.net" target="_blank">http://www.qcooperative.net</a><br>**************************************************************************************************</div></div></div></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 6 Aug 2019 at 06:03, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 29 Jul 2019 at 17:33, Carlo A. Bertelli (Charta s.r.l.)<br>
<<a href="mailto:carlo.bertelli@gmail.com" target="_blank">carlo.bertelli@gmail.com</a>> wrote:<br>
><br>
> Yes, if you consider trial and error a mindful method, I "use" label placement algorithms when preparing a cartographic layout for printing.<br>
> 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...<br>
> 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.<br>
> 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: <a href="https://www.nytimes.com/2019/07/18/science/mitchell-feigenbaum-dead.html" rel="noreferrer" target="_blank">https://www.nytimes.com/2019/07/18/science/mitchell-feigenbaum-dead.html</a>. 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<br>
<br>
Ok, we've hit a stalemate then. I was hoping to drop the additional<br>
algorithms to allow some desirable new features like avoiding<br>
duplicate text labels within xxx mm of others (e.g. avoiding too many<br>
labels for dual-carriage highways), and use that some logic to start<br>
implementing things like automatically abbreviated label text when the<br>
full text cannot be placed. But, if we keep all the existing<br>
algorithms, it basically means this logic has to be written multiple<br>
times. Ouch!<br>
<br>
> 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.<br>
<br>
Sounds great in theory, but the labeling code structure and logic<br>
doesn't work that allow that.<br>
<br>
Nyall<br>
<br>
<br>
<br>
> c<br>
><br>
><br>
> On Mon, Jul 29, 2019 at 8:31 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.)<br>
>> <<a href="mailto:carlo.bertelli@gmail.com" target="_blank">carlo.bertelli@gmail.com</a>> wrote:<br>
>> ><br>
>> > Label placement took a lot of time and efforts in the past and this is the outcome.<br>
>> > 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.<br>
>><br>
>> So - just to confirm -- you are actively changing that setting, and<br>
>> seeing useful results from different methods? If so, which do you use?<br>
>> Which give the best results? What's the trade off between them?<br>
>><br>
>> Nyall<br>
>><br>
>><br>
>> > Keeping several algorithms in Layout could ease code maintenance while keeping all the advantages.<br>
>> > 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...<br>
>> > My two eurocents.<br>
>> > c<br>
>> ><br>
>> > On Mon, Jul 29, 2019 at 2:00 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com" target="_blank">nyall.dawson@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> > Hey lists<br>
>> >> ><br>
>> >> > This was first discussed back in 2016 (see<br>
>> >> > <a href="http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html" rel="noreferrer" target="_blank">http://osgeo-org.1560.x6.nabble.com/Removal-of-labeling-search-methods-td5262743.html</a>),<br>
>> >> > but would anyone object if the different labeling solution algorithms<br>
>> >> > eg "chain" / "pop music" / "falp" / etc were dropped, and we just<br>
>> >> > leave the existing default (chain)?<br>
>> >> ><br>
>> >> > I don't think ANYONE knows what these mean, and it's a heck of a lot<br>
>> >> > of code (which needs fixes) to cart around for no compelling reason<br>
>> >> > that I can see.<br>
>> >> ><br>
>> >> > I have no particular preference to any of the methods, so would<br>
>> >> > happily accept a different default if anyone out there can point to<br>
>> >> > which method is best!<br>
>> >> ><br>
>> >> > Googling pop music / tabu / chain only gives a handful of results<br>
>> >> > relating to QGIS labeling engine. And googling for "falp" sounds like<br>
>> >> > something that would get you flagged on your company's firewall.<br>
>> >> ><br>
>> >> > Does ANYONE understand or change this setting? Or would object to its<br>
>> >> > complete removal?<br>
>> >><br>
>> >> PR at <a href="https://github.com/qgis/QGIS/pull/30960" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS/pull/30960</a><br>
>> >><br>
>> >> Last chance to save this setting!<br>
>> >><br>
>> >> Nyall<br>
>> >> _______________________________________________<br>
>> >> QGIS-Developer mailing list<br>
>> >> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
>> >> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> >> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > --------------------------------------------------------------------------<br>
>> > Carlo A. Bertelli<br>
>> > Charta servizi e sistemi per il territorio e la storia ambientale srl<br>
>> > Dipendenze del palazzo Doria,<br>
>> > vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy)<br>
>> > tel./fax +39(0)10 2475439 +39 0108566195 mobile:+39 393 1590711<br>
>> > e-mail: <a href="mailto:bertelli@chartasrl.eu" target="_blank">bertelli@chartasrl.eu</a> <a href="http://www.chartasrl.eu" rel="noreferrer" target="_blank">http://www.chartasrl.eu</a><br>
>> > --------------------------------------------------------------------------<br>
>> ><br>
>> ><br>
>> ><br>
><br>
><br>
><br>
> --<br>
> --------------------------------------------------------------------------<br>
> Carlo A. Bertelli<br>
> Charta servizi e sistemi per il territorio e la storia ambientale srl<br>
> Dipendenze del palazzo Doria,<br>
> vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy)<br>
> tel./fax +39(0)10 2475439 +39 0108566195 mobile:+39 393 1590711<br>
> e-mail: <a href="mailto:bertelli@chartasrl.eu" target="_blank">bertelli@chartasrl.eu</a> <a href="http://www.chartasrl.eu" rel="noreferrer" target="_blank">http://www.chartasrl.eu</a><br>
> --------------------------------------------------------------------------<br>
><br>
><br>
><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>