Re: [QGIS-Developer] Temporal controller issues
I'm going to respond to your project-level criticism first, and then following that I'll give a technical response: On Thu, 7 Jan 2021 at 12:33, Cory Albrecht wrote: > > > and that using it for data analysis has been a secondary goal > > > I'm not doing any data analysis. In fact, I doubt that I use even 10% of > QGIS's capability. By analysis I mean: "anything that's not just viewing data". > > 1. The temporal framework was in discussion and consultation phases > > for years prior to implementation. > > > Then how did something as simple as the selection tool selecting stuff that > is not there get past this? Did nobody say "Hey, we need to make sure that > when the NTC is turned on that other parts of the application work as > expected"? Bingo. You're the first to bring up the issue with the selection and map tip tools. Guess that shows that we need more people like you involved with the discussion, testing, and review process. > > > 2. QGIS already has some of the most stringent and rigorous code review > > processes around, and the pull requests implementing the temporal framework > > were subject to all these processes and peer review. > > > Then how did this problem get past that review? Did nobody take the feature > branch, compile it, then run QGIS and do some common, simple tasks regarding > data entry with the NTC turned on to see that those tools are working on the > “root” layer data and not the filtered data one sees on the map canvas? (Or > an automated GUI test harness that does the same thing?) Or was it only > tested by loading a project with temporal layers and changing the viewing > time frame and seeing that only matching features were drawn on the map > canvas? Of course they did. But no-one anticipated your use case and tested that. (Hint: YOU could have been this person. There's nothing special about anyone that qualifies them to be part of a mystical "qgis beta testing" group. No-one is paid to do that. No-one is elected to do it. All it takes is downloading the nightlies prior to release and running them through YOUR workflows. So I reflect this criticism right back on you -- why didn't YOU beta test QGIS and ensure that it worked for your workflow? Are YOU going to get involved and ensure this doesn't happen again? If your answer is "no" then I suggest you take some time away from this community and come back when you've had a chance to meditate and reflect on how open-source works.) > > > > 3. If you're asking for the pace of feature development to be slowed > > then that problem was addressed years ago when the LTR releases were > > introduced. > > > No, not at all. That was purely a semantics comment about not using standard > terminology, which makes things confusing. > > > > The QGIS website is quite clear in advertising the LTR as the officially > > recommended version for stability and for mission critical work, while the > > non-LTR releases are clearly branded as "bleeding edge". > > > I would disagree about that clarity. When you go to the main page, for > example, there's just a download button with text underneath saying "Version > 3.16.2 Version 3.10.13 LTR". On the download page it just says "riches on > features" and "most stable". And the user manual for 3.16 itself says "We > recommend that you use this version over previous releases." > > > I couldn't find anything with the qgis.org search feature that says what you > say here. > > > > I'd make the case that in the situation you've described you should never > > have been using the non-LTR release > > > Unfortunately I've been somewhat forced into using master because other bugs > I have reported about how QGIS handles array fields in PostGIS layers. > Without those fixes I sometimes couldn't even work on my maps because I > couldn't save features without data corruption, or sometimes not even save at > all. Those fixes, when they finally got done (and some still aren't), took a > while to end up in the LTR. > > > > So I ask again, in the full spirit of reconciliation and moving forward: > > what concrete, practical changes do YOU think the project should make? > > > Testing, like I mentioned above. Better testing. Great, thanks for volunteering to do this! Like I said above, we need more beta testers, and I'm looking forward to your testing and feedback. (yes, that was semi-sarcastic. But this whole thing only works when everyone gets involved). Now the technical part: > For example, one can add all sorts of SQL-like filters to a layer datasource > (which was how the TimeManager plugin worked, if I understand correctly) and > the selection tool, vertex tool, and so on are not broken by that. When > somebody turns on the NTC, it is reasonable for them to expect that the > filtering it does would act in a similar manner to those SQL-like filters > added manually to a layer, yes? Time manager indeed piggy backed onto the layer sql filter functionality to implement
Re: [QGIS-Developer] Temporal controller issues
> and that using it for data analysis has been a secondary goal I'm not doing any data analysis. In fact, I doubt that I use even 10% of QGIS's capability. I draw a feature that is the Kingdom of France and set the start_date and end_date attributes appropriately (with -mm-dd resolution) and set a few other features (colour, default name, government type, etc...). Then I copy that feature, move the time frame to the day after end_date, paste, and edit the attributes of that new feature as the Second French Republic. Then again as the Second French Empire, then the Third Republic, and so on. If I make an error, like somehow I didn't get the border with Belgium quite right I will use either the Vertex Tool (from the Digitizing Toolbar) or the Reshape Features Tool (from the Advanced Digitizing Toolbar), depending on the scale of the edit. If that feature that I am pasting has its borders change (like when the Second French Empire lost Alsace to the German Empire), I will use the Split Features Tool to carve off a chunk to merge with that other feature. That's like 90% of my QGIS workflow right there, the drawing and simple editing of features. The rest is creating print layouts for exporting to SVG to work on artistic renderings. Nothing fancy and no data analysis. It's a simple data entry workflow. > 1. The temporal framework was in discussion and consultation phases for years prior to implementation. Then how did something as simple as the selection tool selecting stuff that is not there get past this? Did nobody say "Hey, we need to make sure that when the NTC is turned on that other parts of the application work as expected"? For example, one can add all sorts of SQL-like filters to a layer datasource (which was how the TimeManager plugin worked, if I understand correctly) and the selection tool, vertex tool, and so on are not broken by that. When somebody turns on the NTC, it is reasonable for them to expect that the filtering it does would act in a similar manner to those SQL-like filters added manually to a layer, yes? This is why in my initial email I asked about the pipeline from retrieval of features in the layer's data provider to drawing them on the canvas. Prior to the NTC, did tools like selection, vertex, identify, and so on work off of the same "root" list of features that the map canvas drawer worked from? Because these bugs suggest an implementation that either creates a second, filtered list of features and the canvas draws gets passed that list instead of the "root" list while the tools still work off of the "root" list, or that the canvas drawing code was modified to to do the temporal filtering itself and draw only a subset of the "root" list passed to it. You’ve said that you had to fix the bugs I reported separately, but why? To my mind, the NTC should be filtering that "root" list of features, and then nothing else needs to be modified. Not the code that calls the canvas drawer method, not the code for the selection tool. Not the code of the identify feature tool. Don’t change the tools to be time-aware individually, keep them time-agnostic and change the dataset that gets passed to them, and implement that in a centralized location. Then later when somebody with that rare use case of needing to select even the filtered-out features asks for it, you can modify that centralized location to return the full dataset, not the temporally filtered one if certain conditions are met, like an app setting or using the Alt key when clicking on the canvas, or whatever, and it will work for all tools, not just one. (I’m willing to bet you a $100 donation that usage cases that need the selection tool to work on all the features including those filtered out by the NTC and not drawn is tiny to nonexistent, compared to the one where the tool is expected to work in a WYSIWYG manner only on the visible features. If I am wrong, I'll double that donation.) However, since I do not know the codebase, I asked for that help in understanding how the NTC was implemented and why that way, due to other considerations of which I would be unaware that prevented that. It was also why I phrased my final line of criticism as “I feel” rather than as a statement of fact. > 2. QGIS already has some of the most stringent and rigorous code review processes around, and the pull requests implementing the temporal framework were subject to all these processes and peer review. Then how did this problem get past that review? Did nobody take the feature branch, compile it, then run QGIS and do some common, simple tasks regarding data entry with the NTC turned on to see that those tools are working on the “root” layer data and not the filtered data one sees on the map canvas? (Or an automated GUI test harness that does the same thing?) Or was it only tested by loading a project with temporal layers and changing the viewing time frame and seeing that only matching features were drawn on the map
[QGIS-Developer] Stale bot and older requests/issues - possible enhancement
Hi list, I've a small request to consider for stale bot and issues/feature requests. I think that if a ticket remains open for say > 90 days since the last comment, it would be nice if stale bot added a comment like: "Unfortunately this bug/feature request has not seen any solution in the recent QGIS release. If this fix/feature is important to you or your organisation, you can help to fast-track its development by sponsoring this work. To do so, contact one of the QGIS commercial support providers listed at ... to discuss how you could fund this functionality". I think it's a non-threatening, non-begging way to advise bug reporters on the alternative ways they can fast track development in QGIS. Thoughts? 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] Issue with QGIS 3.16.2 standalone and GRASS 7.8.4
Hi Andrea, This seems fixed in 3.16.2-2 released yesterday: https://qgis.org/downloads/QGIS-OSGeo4W-3.16.2-2-Setup-x86_64.exe I believe 3.10.13-2 also fixes this issue. Do you confirm? Best regards, Pedro Andrea Giudiceandrea escreveu no dia quarta, 30/12/2020 à(s) 23:47: > Pedro Venâncio-2 wrote > > Hi Andrea, > > > > I believe this report is yours, right? > > https://trac.osgeo.org/osgeo4w/ticket/655 > > Yes. > > QGIS 3.16.2 and QGIS 3.10.13 installers contain GRASS 7.8.4 which needs > gdal300.dll and proj_6_2.dll, but both the dlls are missing. > > On the contrary, GRASS 7.8.5 doesn't seem to need them. > > Regards. > > Andrea > > > > -- > Sent from: > http://osgeo-org.1560.x6.nabble.com/QGIS-Developer-f4099106.html > ___ > 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
