Shape the future of FME with your ideas
Open ideas have been reviewed by our Product Management and are open for commenting and voting.
Update the VariableSetter/VariableRetriever to pass multiple values in one transformer.Like the AttributeCreator the VariableSetter could have one line per variable.Like the ParameterFetcher the VariableRetriever could retrieve one variable per line. Bonus would be if the existing variables in the workspace were available as a drop down list.
This has probably been mentioned before, but I think it would be nice if the PythonCaller does some simple syntax checking (indents, variable names, typos etc.). It's always annoying to find out there was an unnecessary error in my code which caused the translation to fail and now I have to copy-paste my (sometimes long) code to an IDE and back again...[I remember that in the past, you could write all your code in an external *.py file and refer to the classes and functions in the PythonCaller. If this could be reintroduced, that would also be helpful!]
I propose adding DuckDB as the underlying database engine in the Inline Querier transformer for the following reasons:1. Performance Benefits:Columnar Storage: DuckDB’s columnar storage model allows for much faster query execution, particularly on large datasets, as it optimises for analytical queries. This would result in quicker workflows, especially for FME users dealing with substantial data volumes. Vectorised Execution: DuckDB uses a vectorised execution model that can process chunks of data more efficiently than the row-wise approach used in SQLite. This would significantly enhance performance in complex querying scenarios.2. Better Handling of Analytical Workloads:DuckDB is designed with analytical workloads in mind, making it more suitable for data processing tasks typically performed in FME. This switch would provide users with more efficient query processing when handling large geospatial datasets.3. Increased Flexibility with Data Types:DuckDB offers more advanced data types and functions, which would extend the flexibility of the Inline Querier transformer. This would enable more sophisticated transformations and analytics directly within FME, reducing the need for external tools.4. Seamless Integration:SQL Syntax Compatibility: DuckDB supports standard SQL queries similar to SQLite, ensuring a relatively smooth transition with minimal changes to existing workflows. Users will benefit from enhanced performance without needing to extensively rework their SQL queries.5. Broader Ecosystem Support:DuckDB has strong integrations with modern data ecosystems (e.g., Python, R, Parquet), which can open doors for future FME integrations and expand the functionality of the Inline Querier.6. Open-Source, Actively Developed:Like SQLite, DuckDB is open-source but has a much more active development roadmap focused on big data analytics. This would future-proof the Inline Querier transformer by providing new features and optimisations more regularly.Finally the ability to create macros in duckdb sql and refer to these inline could be very useful indeed, also the native spatial support would really help!
If a user is assigned the fmeadmin role, whilst they have permission to access and create items, they cannot view items (repositories/schedules etc) created by other users unless explicitly set under those user/role permissions. Currently the only way to expose everything to the admin is to assign the fmesuperuser role.Instead I would like to be able to provide full permissions on a per item basis, for example if I have multiple administrators, I may not want them all to have fmesuperuser privileges but I would like to give full permissions to certain components. E.g. As an Admin I can see all scheduled jobs in the Job History no matter the user that owns them, so I would like to see all Schedules on the Schedules page as soon as they created by other admins without having to go in and modify my own security settings to get full access to these.
Hello,I would like the Revit Reader to be able to expose different part (material) layers, for example in: Walls, slabs, roofs.Right now (FME 2020.0), we get a single surface:The use case:Doing basic quantity takeoffs. I was showing FME to some project managers and they were kind of speechless. I managed to automate basic cost estimation, in one afternoon.The only puzzle piece missing were different material layers (structure, insulation, etc). Those are separate cost classes (makes sense).So, I know this is kind of hard...As a workaround:Being able to read Revit schedules for material takeoffs would get the job done as well.That would be AMAZING!As a side note: We would only care about the information (layer name, material, position and quantities), not geometry.
How about an easy "one click" redock all windows option under the view tab?
Right now we can only control permissions at a repository level. It would be great if we could control permissions at a workspace level.
For now the Oracle Writer isn't capable of controlling the width between bytes and characters for varchar fields. The writer forwards the entered width to the database and the database uses the NLS_LENGTH_SEMANTICS settings to create a field either in byte or char length. A writer parameter to "control" the width (NLS_LENGTH_SEMANTICS) would be a great improvement and if it's not a big deal this settings could be integrated into the Writer feature type. Oracle it self recommends to set the NLS_LENGTH_SEMANTICS parameter to byte (see https://docs.oracle.com/cd/E24693_01/server.11203/e24448/initparams149.htm). If the user wants to use char he has to use a workaround with "SQL To Run Before Write" and "SQL To Run After Write".
I need to create a schema in geodatabase format and would love to use FME for this. To avoid writing null or junk features to the tables it would be good to be able to write out a schema without features. I know this defeats the very name of FME if there is no feature, but it would be useful.On this occasion I'll play with the idea of writing out one feature per table then truncating them all, to achieve the same outcome.
conditional visibility…, it would be great to be able to choose more than one value… in this case i would like for this parameter to be hidden if I select one of two from the four choices. but you can only selct one :-(
Allow generation of tokens via a REST endpoint by supplying username/password/expiry as parameters. This is similar to the now deprecated fme token service. When trying to automate some workflows that include FME Server jobs through scripting (e.g. using Powershell), currently the only recommended way to generate a token for REST API calls is to manually create an API token via the web interface. This doesn't fit well with automation and also involves storing/using a long-lived token, which is potentially insecure. The only other documented way to generate a token is to first use Basic Authentication, before creating a token, which is definitely insecure as user/password are sent in plain text. If there was a "generateToken" endpoint with user/password/expiry parameters that supported HTTPS and POST only (similar to the ArcGIS Server approach) this would be a secure way of generating a short-lived token for subsequent API calls.
(1) Show the assumed date and time of the NEXT run (I know it may be delayed because of lack of free engines) ; (2) show if the job has not started at defined time (because of engine unavailability); (3) if possible, show the running time of latest job run. All these would greatly improve the usability of the scheduler when using FME Servers as an ETL machine. Thank you !
Currently, it is only possible to cleanup job history based on an age. It would be great if additional filtering could be applied. For example, we have jobs that run daily, weekly and monthly. We would like our daily jobs to be cleaned up after they're 1 week old but our weekly jobs once they're 1 month old and our monthly jobs once they 1 year old.Being able to perform history cleanup based on a job name, job repository or job submitter, in addition to age, would be a big help.
There is currently a Zoom limit in the Geometry Parameter which prevents users from zooming in further than a specific level like (z21 in Google). A default limit for Google Maps is reasonable but when using own custom WMTS layers users should be able to set this limit. This “feature” of the Leaflet source code behind this function is currently quite “limiting”. So either the default zoom limit should be adjusted further in Leaflet for custom WMTS layers or users should be given the capability to do so.
In addition to the option Length of Shorter Side and Length of Longer Side attributes I would like to see an optional attribute for storing the angle of the oriented bounding box (angle of longer side)
Can we have an ability where an FME Automation running on a schedule can automatically change that schedule based on the number of features being read.For example I am thinking about flooding and flood warnings, if i have an automation to go and fetch all the flood warnings in the middle of summer i will probably get back zero features and this could be ran once per day, however as the year moves on and the storm season approaches the number of features returned would increase. In this case, it would be good to increase the frequency for the next run of the automation to every hour, and then as the number of features increases again, to have the automation run every 15 mins
It would be useful to have a list of dependencies for objects within FME Server. The example below focuses on workspace relationships and finds all the Repositories, Automations, and Schedules that are associated with a workspace and displays the report in the dashboards. This workspace works on all versions 2019.2.1.0 (19813) and higher and uses the REST API calls to query FME Server.What dependencies would you like to see? How do you want them displayed?How to use:1) Update the FME Server Web Connection parameter to use a connection to your server.2) Publish to FME Server3) Choose if you want a report on a specific workspace, or if you want all the workspace run with the parameter value "All"4) Run workspace5) View report from Dashboards
When experimenting with spatial data and comparing the effects of various processes we often end up with numerous (say 5 plus) Views in the Data Inspector. This is because we want to see the difference in geometries and attributes associated with the processes and analyse the results.Viewing the results at full extent is not always acceptable and there is a need to zoom into the same extent in each View to carry out the comparisons.An improvement within the Data Inspector would be the ability to nominate one View as the 'lead View' and have all other Views automatically adjust to the same spatial extent. Obviously with the ability to turn this function on and off.
In FME 2024, I can’t find TclCaller.TclCaller is very useful in some cases, I cannot understand why it has been deprecated.I strongly hope it will be restored.
I noticed that the explanation at the 'Info buttons’ at the 'Filter Settings’ of 'System Cleanup Tasks’ only mentions the cleanup of files in a specific folderIt seems to me that also folders and nested files/folders are removed. I think it would be nice if the explanation in these info buttons’ can be updated/altered, to be a bit more explicit on this.Ps. This idea is a follow up on ‘item 3’ of my question on the FME Community: How to periodically Cleanup the FME Flow Temp Resource (i.e. '$(FME_SHAREDRESOURCE_TEMP)') | Community (safe.com)
***Note from Migration:*** Original Title was: Backup and restore all workspace versions to FME Server database after installation or upgrade Currently it is only possible to reconnect to a remote repository for restoring workspace versions. This is not a solution if the FME Server built-in system (database) is used for version control. Please provide functionality to backup these workspace versions in addition to the configuration backup functionality already present and restore this backup after e.g. an upgrade of FME Server (application or database).Also related to this post: https://knowledge.safe.com/questions/111456/backup-all-fme-server-workspace-versions.html
Hi!I just updated my FME 2018 to FME2024 and I’m surprise to see that in AttributeManager, the OutputAttribute column don’t became blank when the Action is put to “Remove”. Is it normal? I find that more complex to read when there are a lot of attributes. Maybe the previous display could come back? Or use striped or italic text?Have a nice day !
Whilst working with the Text Writer I noticed a large memory performance difference between having dataset fanout on or off. With fanout peak memory usage was 563332 kB, without it was only 154180 kB. I'm assuming FME only starts to write the first fanout file and keeps the other features in memory until the end, just like with multiple Writers only the first Writer will start immediately.In my case the data was grouped by fanout value, meaning that it could be written sequentially only having a single file open at a time and opening each file only once. I think it would be good to have an option 'Input is ordered by fanout' on the Writer, similar in functionality to 'Input is ordered by group' on the Aggregator. This would remove the need to keep all features other than those from the first fanout group in memory.
In FME 2023, we do not have the ability to integrate Password parameters/encrypted parameters into conditional visibility. If, for example, you have a public facing web app, which might have additional functionality for a developer who has a certain admin password, there is no way to build in conditional visibility to access the admin parameters with a encrypted password. There is a unsecure workaround which I have attached as an example, which uses an unencrypted text field to achieve the same result, however this feels like it would be quite dangerous to rely upon. It would be amazing if encrypted values/passwords could be integrated into the conditional visibility parameter functionality to allow us to create more secure web apps. This idea was developed whilst creating a webinar on Conditional Visibility Parameters for 1Spatial UK.
When loading ArcGIS Pro Annotation Feature using ESRI GDB Writer with geodb_pro_annotation type, it is not supported to write leading lines.
In-depth courses for all FME skill levels.
Explore our extensive collection of how-to guides and tutorials.
Log an issue with us. Our support team is ready to help.
