[QGIS-Developer] Temporal controller issues

Tue Jan 5 01:59:59 PST 2021

On Tue, 5 Jan 2021 at 05:42, Cory Albrecht <maps at hanfastolfe.com> wrote:
>
> > Please be very wary of your language in future -- every piece of feedback worded like this directly equates to a developer losing interest in volunteering their time on QGIS, to the harm of all.
>
> I hear what you're saying, Nyall, I apologise if it sounded harsh, but what do you want me to say after I find out that the latest of several bugs has compromised my data and now I have to hunt down an unknown number of duplicates silently created over the last few months of work? If you empathise, do you understand how all these bugs and my data being compromised might make me feel that this feature was not done very well and that there was a lack of adequate testing?
>
> > As background, I implemented time handling for vector layers as a VOLUNTEER (completely unpaid). Would you have preferred I didn't do this, and we had no time support for vectors at all?
>
> As to what I would have preferred, well, I've reverted back to 3.10 to use the old TimeManager plugin to avoid using the NTC. I would have preferred that the feature branch you used to implement the NTC had not gotten merged and the feature included in release versions until it had been checked to work with and not break basic features like the selection tool. So now I have to work under some Damoclean time limit for a couple of months until 3.16 replaces 3.10 and I will have no choice but to move to a version with the NTC and these bugs.

Full disclosure: I don't even really consider these issues as bugs.
Functionality gaps, yes, but it's important to keep in mind that the
new temporal framework was designed primarily around visualisation of
time based data, and that using it for data analysis has been a
secondary goal which has been slowly chipped away at since the initial
implementation. The selection tool was NEVER broken, it was just never
upgraded to be time aware. There's plenty of features in  QGIS which
don't completely work alongside each other, and these are not always
bugs but often are feature requests.

I'd rather shelve that part of the discussion now, because I suspect
we'll just keep going around in circles here at increasing levels of
emotion, and I don't think that's healthy. I realise there's hurt
here, but I DO think you are a valuable member of this community and
I've much appreciated your previous diligence with submitting quality
tickets. I'd rather move forward and find a way that we can move past
this.

Which leads me to a question: what exactly do you think should have
been done differently here? The way I see it:

1. The temporal framework was in discussion and consultation phases
for years prior to implementation. There were public calls for
comments on the related QEPs, and consultation with all relevant
stakeholders, including representatives from Kartoza (WMS-T), Lutra
(mesh temporal handling), and the Time Manager plugin maintainers.  It
was a group effort which pulled in ALL the expertise and experience of
the QGIS project community.

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. There's plenty of developers who would attest to how difficult
it is to get code merged into QGIS, due to the very strict coding
guidelines and processes which govern the codebase. I fail to see
anyway we could realistically further tighten these code review
requirements without completely strangling the development of QGIS.

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. 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'd make the case that in the situation you've
described you should never have been using the non-LTR release for
this work without doing your full diligence to determine that it
worked correctly in your workflow. And guess what? Most of the bugs
are now fixed in time for 3.16.4, when 3.16 officially becomes the
next LTR release! Again, I can't see how the project can do anything
differently here. In fact, the next LTR (3.16) will even be supported
for a massive 2 year period to ensure even more stable releases are
available for mission critical work.

So I ask again, in the full spirit of reconciliation and moving
forward: what concrete, practical changes do YOU think the project
should make?

Nyall

>
> On Sun, Jan 3, 2021 at 9:32 PM Nyall Dawson <nyall.dawson at gmail.com> wrote:
>>
>> On Sat, 2 Jan 2021 at 10:23, Cory Albrecht <maps at hanfastolfe.com> wrote:
>> >
>> > Can somebody help me under the basics of how things work inside QGIS starting from when it loads all the features for a layer through the steps, and then finally drawing them on the map canvas, specifically with respect to the new temporal controller (NTC)?
>> >
>> > The issues caused by the NTC have been very frustrating for me as I make mostly (historical) timeline maps and I relied heavily on the old TimeManager (OTM) plugin by Antia Graser and group. So many tasks are now much more laborious or difficult because so many tools are just not time-aware.
>> >
>> > Was it not possible to add the NTC in such a way that would have still let all the other features work as before with the filtered feature set before being made time-aware, rather than confusingly operating on the unfiltered set? Or perhaps it shouldn't have been turned on until the infrastructure was there for the tools to be time-aware right away?
>> >
>> > Because I've just submitted yet another bug about the NTC, this time for the selection tool, and it has me more than a little annoyed. As a result of this bug I now have an unknown number of duplicate objects in multiple layers across multiple databases/projects that I unknowingly pasted into them over the past several months since the NTC was added to QGIS.
>> >
>> > I feel that the NTC was both poorly thought out and badly implemented as all these bugs would indicate.
>>
>> I can empathise with your frustration, but this is a very complex discussion!
>>
>> As background, I implemented time handling for vector layers as a
>> VOLUNTEER (completely unpaid). Would you have preferred I didn't do
>> this, and we had no time support for vectors at all? Please be very
>> wary of your language in future -- every piece of feedback worded like
>> this directly equates to a developer losing interest in volunteering
>> their time on QGIS, to the harm of all.
>>
>> I've fixed two of your issues here
>> https://github.com/qgis/QGIS/pull/40834, as an UNPAID VOLUNTEER.
>> Without funding I'm just not interested in fixing the snapping related
>> issues. I don't personally have any need for these, and the QGIS
>> snapping code isn't something I'm motivated in getting involved with
>> at all. Perhaps there's another developer interested in looking at
>> this, or perhaps a developer will take a look at this during the 3.18
>> bug sprint. Or maybe someone will pay for this fix and financial gain
>> will be the motivation.
>>
>> I like making the world a better place through volunteering my time on
>> making a first-class desktop mapping application, but I'm far from
>> being a slave to this, and my family, garden, and drum kit want my
>> time too!
>>
>> 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