Shape the future of FME with your ideas
Open ideas have been reviewed by our Product Management and are open for commenting and voting.
I would want to be able to retrieve information about automation schedule.I see several similar requests in Ideas, and it looks like it was possible to do with FME Flow v3 API using schedules endpoint. I’ve tried <FME_URL>/fmeapiv4/schedules?limit=100&offset=0&includeAutomations=trueThe API call didn’t fail, however it returned only schedules and no scheduled automations. The v4 API documentation doesn’t have includeAutomations param, so I am rather surprised the call didn’t fail.The automations endpoint has nothing about triggers or schedules either.In general, it would be helpful to be able to retrieve information about automation trigger and, if the trigger is a schedule, information about the schedule. One of the use cases for this would be administration of an FME Flow hosting multiple projects and used by many users/teams. Somehow, midnight seems to be the most popular choice when scheduling automations. As a result, there is a long list of automations triggered at midnight, and if one of them gets stalled… there is a surprisingly long queue with time sensitive jobs in it in the morning. If I was able to retrieve schedule info, I would create a dashboard to monitor scheduled triggers distribution
As a follow-on from my question and the response from @zoe.forbes after we upgraded to 2026.1 and I found the info icon and blue banner in workspace apps have been removed for message-type user parameters. The icon and banner were useful and I think important aspects of the message parameter and outlining information in workspace apps. I haven’t found any requests to remove them and I think it is well worth restoring them.
I’m downloading bulk CSV data from an open data site, each download is gigabytes, I would like to set the output filename to a .zip file, to save space.
Hi,some formats (such as the Text File reader) have fixed schemas that will never change. In the case of the Text File reader the only attribute in the schema is the text_line_data attribute.For these fixed-schema formats, I would like to request an enhancement to the FeatureReader to have the schema automatically exposed, even when the Generic output port is configured. Currently, the schema attributes are only exposed for named output ports.For context, I refer to the following Community question: And to my own support question (to which James Cheng provided a very comprehensive reply):https://support.safe.com/hc/en-us/requests/64419I have reproduced James’ reply below, as it so clearly explains the situation:Thank you for raising this. I understand the frustration as I share the same thoughts and can see why you'd expect the text_line_data attribute to just be available when reading a Text File through the FeatureReader. The behavior you're seeing comes down to how the FeatureReader's generic output port works. This port is a catch-all that merges everything into a single stream, designed to handle any format and feature types with varying schemas. Because of this, it doesn't commit to any schema at authoring time, it doesn't make assumptions about which feature types or attributes will be present, so all attributes come through unexposed by default, even for predictable formats. By contrast, when you use a named output port (or a standalone Text File Reader), the schema is known at authoring time, so the attributes like text_line_data are automatically exposed. In essence, by using the Generic port, the trade-off is flexibility over schema awareness, it can handle anything but at the cost of not pre-committing to any specific attributes. However, as you've rightly pointed out though, the Text File Reader always produces a predictable fixed schema with a single attribute, text_line_data, no matter which files/feature types are being read. So there's a reasonable argument that the FeatureReader could recognize this and auto-expose it on the Generic Port since there's no ambiguity what the output will be. Currently, the Generic port doesn't differentiate between fixed schema and variable schema formats as it applies the same "unexposed by default" behavior uniformly across the board. That said, I think this is a genuinely good candidate for a product enhancement for the generic port. I'd encourage you to post this as an Idea on the FME Community, specifically requesting that the FeatureReader auto expose known attributes for fixed schema formats like Text Files on the Generic port and describing your use case. Community support helps the development team gauge interest and prioritize ideas for future releases, and we can link this ticket to the Idea to keep it on their radar. In the meantime, it's worth noting for this specific format, the feature types are all fixed to text_line, so using the default One per Feature Type output port setting will also route all text file features through a single text_line named port, similarly to the Generic Port, which will expose the text_line_data attribute automatically. If your workflow requires the Generic port, then the only available options are manually setting the Attributes to Expose parameter on the FeatureReader or placing an AttributeExposer downstream. regards,Nic
This idea is a specific use case of the more general:This idea exists simply to assist people searching specifically for information regarding exposing the text_line_data attribute on the Generic port of a FeatureReader when reading Text File data.
In the Autodesk AutoCAD DWG/DXF-writer (and in the other DWG writers too) it would be good if you could choose an attribute for Layer Description, Default Linetype, Default Color and the states: On, Frozen, Hidden, Locked, Plottable. It's not so usable right now when you need to hard code these values which makes all layers look the same.
The current customization options for FME Flow Apps is quite poor. FME Flow Apps have the potential to be a centralised focal point/application for organisational/enterprise level ETL; however, they currently allow for minimal flexibility and design when it comes to styling.The lack of flexibility and options for design improvements mean that even with greatest graphics/design eye in the world, FME Flow Apps are often left looking nothing more than a data dropzone, workspace runner or ‘Click to Download’ link.Expanding the options for image customization and editing, greater flexibility in text design, or incorporating HTML would greatly enhance the visual appeal of FME Flow Apps. This would increase visibility and improve perceptions to none FME users who are given access to a Flow App.Documentation could also be created in the form of a technical article on ‘Designing and Styling an FME Flow App for your Organization’ to support this process.
White Box Tools is an open source geoprocessing package made by the University of Guelph.Its key benefit is its extreme speed, being able to process tools between 5 and 50 times faster than ArcGIS Pro. It would extremely beneficial if FME included an WBT transformer which could allow users to pass FME data to WBT and allow the user to select which WBT to run (there are hundreds). This would greatly expand the raster capabilities of FME, and include some functionality which is currently lacking in FME (viewshed)Whitebox Geospatial
On FME Flow you can filter failed jobs. It would be great to be able to filter by error message. This way if you’re trying to troubleshoot an error that is occurring you can easily see which scripts have been impacted.
This idea has come up in the 2016 thread (now released) about adding any output ports to FeatureWriter but the use case for Rejected features remains - e.g. some web-based format has a transient HTTP error, the failed features need to be retried after a wee delay, or a field overflows and can’t be written. @markatsafe @rylanatsafe you guys were on that thread. FeatureReader has a Rejected port, very handy for retry logic in a looping custom transformer, lets see it for FeatureWriter!There might need to be a Rejected port for each output port if you're going to loop it, or filter on feature type before looping to an input.
Enhance Extruder transformer to have the option to extrude geometry along a complex path similar to the way AutoCAD does to create 3D lines, surfaces, and solids.
Is there a way to have feature writer (PNG format), to generate .pgw instead of .wld file?For feature writer (JPEG format) it has option to change .wld to .jgw Just wondering if it would be possible to do that with PNG as well? Currently I change the .wld to .pgw manually. I know there’s a way to use SystemCaller to make it change the file extension. But it would be helpful if we can just skip that entirely because it may not work as expected when we Publish workspace in FME Flow. JPEG Format PNG format
It would great and highly beneficial to see the exact processing time for each individual transformer directly on the transformer. This feature would allow users to easily identify bottlenecks and optimize workspace efficiency without manual benchmarking in the log.
When you add a "file" manual key to an automation which get run by an automation app, the option is to choose a file already in the resources of FME Flow. It would be nice to have an option for a user to upload a file like what's already available in workspace apps. For a User Parameter "File" the user is able to upload a file which gets used by the workspace the workspace app runs. The same would be ideal for automation apps.
***Note from Migration:*** Original Title was: Add Support for Aggregate Geometry Type (Esri ArcGIS Online (AGOL) Feature Service Writer) Add support for writing Aggregate features with the Esri ArcGIS Online (AGOL) Feature Service Writer.Currently this is not supported: https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/arcgisonlinefeatures/quick_facts_arcgisonlinefeatures.htmExample of community discussion of this feature: https://community.safe.com/s/question/0D54Q000080hRcE/cannot-write-to-esri-after-using-aggregator-mutipart-geometry?t=1619549337262
Would be great to have a Search Filter In the dialog which is handy when there are several workspaces in the same repo.
Idea: cancelling a job will rollback the whole transaction of all features for Snowflake WriterObserved behavior: cancelling a job in FME Flow will stop additional features from being written, but features that have already been written to Snowflake are already committed without any rollback of the transaction. There is inconsistency between “Features Written’ as recorded in the job log and actual features written according to Snowflake logs. The job log records zero features written while there have been many features written to Snowflake despite job being cancelled.Desired behavior: cancelling a job in FME Flow will stop additional features from being written and rollback any partial changes the job has just done. Outcome: improved management of jobs.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
OKSorry, our virus scanner detected that this file isn't safe to download.
OK