<div dir="ltr">Hi all,<div><br></div><div>We are currently evaluating work to improve QGIS processing to a closer experience to FME.</div><div>There is already some information here from Nyall.</div><div>Our memories are a bit loose, is there any other work done on requirements or a wishlist? </div><div><br></div><div>Is there any work already started so we don't hijack?</div><div><br></div><div>Thanks a lot,</div><div>Denis</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mar. 7 avr. 2020 à 12:22, Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 7 Apr 2020 at 17:35, Andreas Neumann <<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>> wrote:<br>
><br>
> Hi Nyall,<br>
><br>
> Thank you for sharing this interesting document.<br>
><br>
> I have questions and remarks:<br>
><br>
> 1. One fundamental difference between FME and QGIS modeler, as far as I<br>
> understand it, is the fact that FME data sources are much more tightly<br>
> coupled with the model than in QGIS modeler. This has the advantage,<br>
> that the data readers, transformers and writers always know what<br>
> geometry types and attributes they have. The disadvantage is that it is<br>
> harder to exchange data sources with sources that have other attributes.<br>
> In my experience the FME approach is what most users prefer. They like<br>
> the fact that they can always see at each transformer what attributes<br>
> are available at this stage. Would you see an improvement - perhaps<br>
> another modeler mode - where also QGIS modeler would be more tightly<br>
> coupled with the data sources and that the model and algorithms would<br>
> always know at any step what attributes are available at this stage? Or<br>
> is this a fundamental difference between the two approaches that<br>
> couldn't be bridged?<br>
<br>
I think it's totally possible -- we just need to know how each<br>
algorithm transforms its inputs into an output data set in advance<br>
(i.e. the crs, wkb type, and fields).  API which permits this was<br>
recently added, but it's not yet hooked into the modeler.  There's<br>
still considerable work to do for that, but it's far from impossible!<br>
<br>
> 2. One aspect where FME shines is the ability to graphically debug<br>
> models. One can at every step in the model get the view (map and table)<br>
> of the intermediate step. One can also see at each branch in the model<br>
> how many features take this route and how many the other route. I know<br>
> this doesn't have anything to do with the transformer list you shared,<br>
> but this an aspect that I think, many users like about FME.<br>
<br>
A recent improvement is that after running a model in the designer,<br>
you can now see the actual values of inputs and outputs which were<br>
used for each child algorithm in the model. It's a partial step<br>
towards the FME approach. To get the rest of the way we'd need:<br>
1. to ensure that every algorithm has numeric outputs for the number<br>
of features processed<br>
2. ideally to allow the model to run on a background thread inside the<br>
designer, so that you'd see these input/output values populate<br>
instantly as the model runs (would also allow us to color-code child<br>
algorithms by state, e.g. completed/running/pending/skipped).<br>
<br>
1. is pretty straightforward, just a lot of grunt work. 2. is more<br>
complex (and I suspect only achievable in builds based on qt 5.10+<br>
(since we'd need to invoke the child algorithm prepare steps on the<br>
main thread)... but its probably time to bump the minimum anyway).<br>
<br>
Anyway, definitely achievable in the near future.<br>
<br>
> I agree that there would a lot of "low hanging" fruits and I'm looking<br>
> forward to more feature parity between the two. And to the discussion<br>
> around it.<br>
<br>
Me too! When 3.14 is released the model capabilities in QGIS will be<br>
much much improved vs previous releases. Just the fact that **every**<br>
parameter for child algorithms (including input and output layers) can<br>
now be defined using qgis expressions opens up a WHOLE new world of<br>
possibilities alone...<br>
<br>
Nyall<br>
<br>
<br>
<br>
><br>
> Greetings,<br>
><br>
> Andreas<br>
><br>
> Am 07.04.20 um 03:27 schrieb Nyall Dawson:<br>
> > Hi list,<br>
> ><br>
> > Just wanted to give a heads up on a document I've recently completed,<br>
> > which maps existing FME functionality across to the equivalent QGIS<br>
> > Processing or Expression equivalent:<br>
> ><br>
> > <a href="https://github.com/nyalldawson/qgis-processing-hitlist/blob/master/fme.md" rel="noreferrer" target="_blank">https://github.com/nyalldawson/qgis-processing-hitlist/blob/master/fme.md</a><br>
> ><br>
> > Since FME transformers are both algorithm-like and expression-like<br>
> > functionality, the document splits the QGIS equivalents into columns<br>
> > for both algorithms and expressions. Wherever the transformer<br>
> > functionality doesn't apply, a "N/A" is entered in the corresponding<br>
> > column (e.g. the "StringCaseChanger" transformer doesn't make sense<br>
> > the implement as a QGIS Processing algorithm -- it's equivalent is<br>
> > instead the expression functions "lower", "upper" and "title". And<br>
> > conversely the "DuplicateFilter" transformer maps to the Processing<br>
> > algorithms "Delete Duplicate Geometries" and "Delete duplicates by<br>
> > attribute", but doesn't make sense to have an expression function<br>
> > equivalent!)<br>
> ><br>
> > There's also Transformers in FME which really don't need an equivalent<br>
> > in QGIS -- e.g. those relating to styling features.<br>
> ><br>
> > Overall we have a good level of coverage of the most important<br>
> > functionality. There's a LOT of low-hanging fruit which could easily<br>
> > be addressed in small PRs (e.g. things like the<br>
> > "CharacterCodeExtractor" transformer would be a trivial task to<br>
> > implement as a new QGIS expression function ... a GREAT task for<br>
> > someone getting started with QGIS development!).<br>
> ><br>
> > (and just for completeness - QGIS offers hundreds of processing<br>
> > algorithms and expression functionality which **doesn't** have<br>
> > equivalents in FME. I suspect the reverse document would have just as<br>
> > many "missing" cells!)<br>
> ><br>
> > Feedback welcome! At some stage I think it would be nice to move this<br>
> > document across to the QGIS repo, and possibly pull into the QGIS<br>
> > documentation itself (along with similar documents for Arc/...<br>
> > functionality!)<br>
> ><br>
> > Nyall<br>
> > _______________________________________________<br>
> > QGIS-Developer mailing list<br>
> > <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
> > List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> > Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> _______________________________________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>