Hi Nyall,
> 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
> implemen
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 chairm
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
**
+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 underst
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
diff
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
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 c
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 generalis
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
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
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 de
11 matches
Mail list logo