Re: [QGIS-Developer] Vertex tool and cache invalidation
Hi Hugo Are the issues you mentioned solved now by your PR https://github.com/qgis/QGIS/pull/8724 or that was some other separate issue? For your open question with "click first" behavior of vertex tool as an option - I don't know. There has been some interest to address some ergonomic issues in the new implementation, but I am not sure yet what we would end up doing... Cheers Martin On Tue, Dec 18, 2018 at 9:30 AM Hugo Mercier wrote: > > Hi, > > I am facing some issues with the vertex tool of 3.x. > > In 2.18 the "node tool" was working by clicking first on a geometry to > select it or its vertices and then displace them. With the new "vertex > tool", there is no more first click involved and geometries are > "selected" when the mouse position is close enough. > > This behaviour and ergonomic change (which I like !) implied an > implementation that needs, for descent performances, to build a cache of > geometries and maintain it. > > Problems arise when a modification on a layer may trigger modifications > on others. For example when two layers have triggers in database (to > maintain a correct network topology in database for instance), or even > when the same layer is opened twice. > > QGIS has no way to know that the modification of a layer can modify > another layer. So it easily leads to problems where "phantom" geometries > are still selectable but actual (modified by side effect) geometries are > not. > > I introduced in a previous version a way to express "data dependencies" > between layers, with this issue in mind. For PostgreSQL databases, there > is probably also a way to circumvent this by using the LISTEN/NOTIFY > mechanism and some lines of Python. > However I find these solutions very obscure and unfriendly. > > Open question: what about re-introducing the old "click first" behaviour > of the vertex tool (and probably other tools) in a next version ? Not as > a replacement, but as a possible alternative. > ___ > 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
Re: [QGIS-Developer] Vertex tool and cache invalidation
Hi Martin, On 07/01/2019 10:22, Martin Dobias wrote: > Hi Hugo > > Are the issues you mentioned solved now by your PR > https://github.com/qgis/QGIS/pull/8724 or that was some other separate > issue? Unfortunately, this only solves a very small part of the problem. The overall issue of wrong cache synchronization is still there. > > For your open question with "click first" behavior of vertex tool as > an option - I don't know. There has been some interest to address some > ergonomic issues in the new implementation, but I am not sure yet what > we would end up doing... I understand. I am still looking for a solution here. So instead of resurrecting the old vertex tool, would it be possible to make it work without index/cache ? I understand a cache has been introduced to allow for edition when lots of geometries are displayed on the current extent. But usually geometry editions are made at a high level of details, when a few geometry features are visible. Is a cache still needed if we somehow enforce the edition to be allowed only at small scale ? > > Cheers > Martin > > On Tue, Dec 18, 2018 at 9:30 AM Hugo Mercier > wrote: >> >> Hi, >> >> I am facing some issues with the vertex tool of 3.x. >> >> In 2.18 the "node tool" was working by clicking first on a geometry to >> select it or its vertices and then displace them. With the new "vertex >> tool", there is no more first click involved and geometries are >> "selected" when the mouse position is close enough. >> >> This behaviour and ergonomic change (which I like !) implied an >> implementation that needs, for descent performances, to build a cache of >> geometries and maintain it. >> >> Problems arise when a modification on a layer may trigger modifications >> on others. For example when two layers have triggers in database (to >> maintain a correct network topology in database for instance), or even >> when the same layer is opened twice. >> >> QGIS has no way to know that the modification of a layer can modify >> another layer. So it easily leads to problems where "phantom" geometries >> are still selectable but actual (modified by side effect) geometries are >> not. >> >> I introduced in a previous version a way to express "data dependencies" >> between layers, with this issue in mind. For PostgreSQL databases, there >> is probably also a way to circumvent this by using the LISTEN/NOTIFY >> mechanism and some lines of Python. >> However I find these solutions very obscure and unfriendly. >> >> Open question: what about re-introducing the old "click first" behaviour >> of the vertex tool (and probably other tools) in a next version ? Not as >> a replacement, but as a possible alternative. >> ___ >> 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
Re: [QGIS-Developer] Vertex tool and cache invalidation
Hi Hugo (finally coming back to the earlier thread now) On Mon, Jan 7, 2019 at 4:14 PM Hugo Mercier wrote: > > > > Are the issues you mentioned solved now by your PR > > https://github.com/qgis/QGIS/pull/8724 or that was some other separate > > issue? > > Unfortunately, this only solves a very small part of the problem. The > overall issue of wrong cache synchronization is still there. So what are the missing pieces of the puzzle? With data dependencies defined in QGIS, I would expect that edit of a geometry in a layer should trigger dataChanged() signal, so any piece of QGIS that caches any data is notified that caches should be invalidated... isn't this the case? > > For your open question with "click first" behavior of vertex tool as > > an option - I don't know. There has been some interest to address some > > ergonomic issues in the new implementation, but I am not sure yet what > > we would end up doing... > > I understand. I am still looking for a solution here. > > So instead of resurrecting the old vertex tool, would it be possible to > make it work without index/cache ? > I understand a cache has been introduced to allow for edition when lots > of geometries are displayed on the current extent. But usually geometry > editions are made at a high level of details, when a few geometry > features are visible. Is a cache still needed if we somehow enforce the > edition to be allowed only at small scale ? I am not sure I understand what is the problem with cache... attribute table has its cache, vector joins have caches, snapping has its cache, so vertex tool has its cache too to make things faster. As long as we can detect that the cache needs to be invalidated, there should not be a problem. Could you please shed some light where is the source of the troubles you are having? Cheers Martin ___ 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] Vertex tool and cache invalidation
Hi Martin, On 23/01/2019 23:02, Martin Dobias wrote: > Hi Hugo > > (finally coming back to the earlier thread now) > > On Mon, Jan 7, 2019 at 4:14 PM Hugo Mercier wrote: >>> >>> Are the issues you mentioned solved now by your PR >>> https://github.com/qgis/QGIS/pull/8724 or that was some other separate >>> issue? >> >> Unfortunately, this only solves a very small part of the problem. The >> overall issue of wrong cache synchronization is still there. > > So what are the missing pieces of the puzzle? With data dependencies > defined in QGIS, I would expect that edit of a geometry in a layer > should trigger dataChanged() signal, so any piece of QGIS that caches > any data is notified that caches should be invalidated... isn't this > the case? It is, but snapping invalidation of indexes for a whole layer can take a lot of time to rebuild, depending on the indexing strategy. So the initial benefit of building an index once and querying it with good performances afterwards is partly lost. As discussed in a PR (https://github.com/qgis/QGIS/pull/8862), we have to find a way to speed up this index rebuilt to have an acceptable solution. Moreover, it requires the user to declare dependencies between layers. > > >>> For your open question with "click first" behavior of vertex tool as >>> an option - I don't know. There has been some interest to address some >>> ergonomic issues in the new implementation, but I am not sure yet what >>> we would end up doing... >> >> I understand. I am still looking for a solution here. >> >> So instead of resurrecting the old vertex tool, would it be possible to >> make it work without index/cache ? >> I understand a cache has been introduced to allow for edition when lots >> of geometries are displayed on the current extent. But usually geometry >> editions are made at a high level of details, when a few geometry >> features are visible. Is a cache still needed if we somehow enforce the >> edition to be allowed only at small scale ? > > I am not sure I understand what is the problem with cache... attribute > table has its cache, vector joins have caches, snapping has its cache, > so vertex tool has its cache too to make things faster. As long as we > can detect that the cache needs to be invalidated, there should not be > a problem. Could you please shed some light where is the source of the > troubles you are having? I am sure you know the quote "There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors." :-) Caches are very nice until we find a situation where it gets complicated to know what and when to invalidate. So there are 3 general approaches I can see for the problem I have: - avoid cache : the less intrusive one for the user, provided we maintain good performances - invalidate the whole layer at each edition: see above - invalidate precisely at the level of each feature: should be signaled by the data provider but seems (on first thought) hard to auto-detect, so would require a lot of work by the user Hugo ___ 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
