Hi Nyall,
Thank you for sharing this interesting document.
I have questions and remarks:
1. One fundamental difference between FME and QGIS modeler, as far as I
understand it, is the fact that FME data sources are much more tightly
coupled with the model than in QGIS modeler. This has the advantage,
that the data readers, transformers and writers always know what
geometry types and attributes they have. The disadvantage is that it is
harder to exchange data sources with sources that have other attributes.
In my experience the FME approach is what most users prefer. They like
the fact that they can always see at each transformer what attributes
are available at this stage. Would you see an improvement - perhaps
another modeler mode - where also QGIS modeler would be more tightly
coupled with the data sources and that the model and algorithms would
always know at any step what attributes are available at this stage? Or
is this a fundamental difference between the two approaches that
couldn't be bridged?
2. One aspect where FME shines is the ability to graphically debug
models. One can at every step in the model get the view (map and table)
of the intermediate step. One can also see at each branch in the model
how many features take this route and how many the other route. I know
this doesn't have anything to do with the transformer list you shared,
but this an aspect that I think, many users like about FME.
I agree that there would a lot of "low hanging" fruits and I'm looking
forward to more feature parity between the two. And to the discussion
around it.
Greetings,
Andreas
Am 07.04.20 um 03:27 schrieb Nyall Dawson:
Hi list,
Just wanted to give a heads up on a document I've recently completed,
which maps existing FME functionality across to the equivalent QGIS
Processing or Expression equivalent:
https://github.com/nyalldawson/qgis-processing-hitlist/blob/master/fme.md
Since FME transformers are both algorithm-like and expression-like
functionality, the document splits the QGIS equivalents into columns
for both algorithms and expressions. Wherever the transformer
functionality doesn't apply, a "N/A" is entered in the corresponding
column (e.g. the "StringCaseChanger" transformer doesn't make sense
the implement as a QGIS Processing algorithm -- it's equivalent is
instead the expression functions "lower", "upper" and "title". And
conversely the "DuplicateFilter" transformer maps to the Processing
algorithms "Delete Duplicate Geometries" and "Delete duplicates by
attribute", but doesn't make sense to have an expression function
equivalent!)
There's also Transformers in FME which really don't need an equivalent
in QGIS -- e.g. those relating to styling features.
Overall we have a good level of coverage of the most important
functionality. There's a LOT of low-hanging fruit which could easily
be addressed in small PRs (e.g. things like the
"CharacterCodeExtractor" transformer would be a trivial task to
implement as a new QGIS expression function ... a GREAT task for
someone getting started with QGIS development!).
(and just for completeness - QGIS offers hundreds of processing
algorithms and expression functionality which **doesn't** have
equivalents in FME. I suspect the reverse document would have just as
many "missing" cells!)
Feedback welcome! At some stage I think it would be nice to move this
document across to the QGIS repo, and possibly pull into the QGIS
documentation itself (along with similar documents for Arc/...
functionality!)
Nyall
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________
QGIS-Developer mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
