On Mon, 29 Jul 2019 at 17:33, Carlo A. Bertelli (Charta s.r.l.) <carlo.berte...@gmail.com> 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 <nyall.daw...@gmail.com> wrote: >> >> On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.) >> <carlo.berte...@gmail.com> 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 <nyall.daw...@gmail.com> >> > wrote: >> >> >> >> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson <nyall.daw...@gmail.com> 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-Developer@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 >> > -------------------------------------------------------------------------- >> > >> > >> > > > > > -- > -------------------------------------------------------------------------- > 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-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
