[QGIS-Developer] Plugin [1775] Magic Wand approval notification.
Plugin Magic Wand approval by zimbogisgeek. The plugin version "[1775] Magic Wand 1.0" is now approved Link: http://plugins.qgis.org/plugins/MagicWand-master/ ___ 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
Re: [QGIS-Developer] Dropping the extra label placement algorithms?
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 > 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 wrote: >> >> 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 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 >> > wrote: >> >> >> >> 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" / "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 >> >>
Re: [QGIS-Developer] Some thought on LTR
Hiii all, On 05/08/19 11:10, Matthias Kuhn wrote: > On 8/5/19 1:00 AM, Nyall Dawson wrote: >> On Fri, 2 Aug 2019 at 18:13, Matthias Kuhn wrote: >> >>> d) Stop shipping bugfixes (hint: joke, that makes the LTR concept >>> pointless and anyone can do that today already by sticking to the .0 >>> patch release ;) ) >> Actually - jokes aside - this does raise a good question. >> >> We've never (as far as i know) formally defined about what the goal of >> the LTR is. Is it: >> 1. a version of QGIS with every bug fix possible backported >> or >> 2. a version of QGIS with only absolutely critical bugfixes >> backported, such as security risks or data corruption bugs > > That's a very good question. thanks, very important indeed. I assumed we decide for 1. In fact, experience showed that it is preferable to be more conservative, and only include fixes with very low chances of regressions. I don't see a way to decide other than relying on the developer's assessment. The only (costly) improvement I'd see is having another independent core dev to check any bugfix before accepting it. Cheers. -- Paolo Cavallini - www.faunalia.eu QGIS.ORG Chair: http://planet.qgis.org/planet/user/28/tag/qgis%20board/ ___ 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
Re: [QGIS-Developer] Some thought on LTR
On 8/5/19 1:00 AM, Nyall Dawson wrote: On Fri, 2 Aug 2019 at 18:13, Matthias Kuhn wrote: d) Stop shipping bugfixes (hint: joke, that makes the LTR concept pointless and anyone can do that today already by sticking to the .0 patch release ;) ) Actually - jokes aside - this does raise a good question. We've never (as far as i know) formally defined about what the goal of the LTR is. Is it: 1. a version of QGIS with every bug fix possible backported or 2. a version of QGIS with only absolutely critical bugfixes backported, such as security risks or data corruption bugs That's a very good question. While there's no binary crystal clear categorization possible anyway, I realize that we tend toward 1. if it's a fixes affecting (experienced/sponsored/implemented by) ourselves and 2. for any other fix. Which introduces a bias that can cause tension. So I agree that: IF the concerns with the current (1.) approach are too high, the decision for 2. is better taken as a community and made official so it can be communicated easier to our clients and users. (And then even with the decision taken, the situation will be tricky. At the time a client reports a bug and funding is available, it almost always looks like a trivial fix and it's easy to promise a backport "what could potentially go wrong?". Whereas the question about the categorization of a bugfix mostly appears in retrospective when it turns out something has gone wrong and the situation is already difficult.) Matthias (or somewhere between the two) Currently, it's very much 1. We see everything backported from crash fixes to string updates to performance optimisations to backported API. Maybe this is the problem. Maybe we should only be accepting absolutely mission critical bug fixes, and the expectation is to see only 1 or 2 commits between LTR patch release versions. Reality is that every bug fix, regardless of how trivial it seems, brings with it the increased chances of regressions into the stable LTR release... Possibly this is a question we need to raise with our voting panel or user communities, in order to work out exactly what people's desires from the LTR are. 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
Re: [QGIS-Developer] [GRASS-dev] Bump to proj 6/gdal 3
Hi, so if I understand correctly, we need to hold it until GRASS is compatible with PROJ6 or should we switch to proj6 nevertheless for mac packages? Thanks, Peter On Tue, Jul 23, 2019 at 6:40 PM Markus Metz wrote: > > > On Tue, Jul 23, 2019 at 10:24 AM Jürgen E. Fischer wrote: > > > > Hi, > > > > On Tue, 23. Jul 2019 at 10:11:59 +1000, Nyall Dawson wrote: > > > Discussion welcome :) > > > > What's the state of GRASS with PROJ 6? > > GRASS compiles with PROJ 6, but does not work properly with PROJ 6 because > PROJ 6 behaves differently compared to PROJ 5. PROJ 6 isupport in GRASS is > WIP. > > Markus M > > > > > > Jürgen > > > > -- > > Jürgen E. Fischer norBIT GmbH Tel. > +49-4931-918175-31 > > Dipl.-Inf. (FH) Rheinstraße 13 Fax. > +49-4931-918175-50 > > Software Engineer D-26506 Norden > https://www.norbit.de > > QGIS release manager (PSC) GermanyIRC: jef on > FreeNode > > ___ > > grass-dev mailing list > > grass-...@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/grass-dev > ___ > grass-dev mailing list > grass-...@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ 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
