[Qgis-user] [QGIS-Developer] Dropping the extra label placement algorithms?
Luigi Pirelli
luipir at gmail.com
Mon Aug 5 23:59:51 PDT 2019
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
<https://www.packtpub.com/eu/application-development/mastering-geospatial-development-qgis-3x-third-edition>
* Hire a team: http://www.qcooperative.net
**************************************************************************************************
On Tue, 6 Aug 2019 at 06:03, Nyall Dawson <nyall.dawson at gmail.com> wrote:
> On Mon, 29 Jul 2019 at 17:33, Carlo A. Bertelli (Charta s.r.l.)
> <carlo.bertelli at 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.dawson at gmail.com>
> wrote:
> >>
> >> On Mon, 29 Jul 2019 at 16:28, Carlo A. Bertelli (Charta s.r.l.)
> >> <carlo.bertelli at 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.dawson at gmail.com>
> wrote:
> >> >>
> >> >> On Fri, 26 Jul 2019 at 12:40, Nyall Dawson <nyall.dawson at 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 at 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: bertelli at 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: bertelli at chartasrl.eu http://www.chartasrl.eu
> >
> --------------------------------------------------------------------------
> >
> >
> >
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20190806/e9553f47/attachment.html>
More information about the Qgis-user
mailing list