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 <lui...@gmail.com> 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 <nyall.daw...@gmail.com> wrote: >> 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 > _______________________________________________ > 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
_______________________________________________ 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
