Shape the future of FME with your ideas
New and Open ideas are awaiting review or have been reviewed by our Product Management team, and are open for commenting and voting.
Support readers/writers for Bentley's Open Roads, as many transportation agencies are using them.
A question was asked about this in the MCP and FME training, and it was suggested that an idea post be made for it. I didn’t find one yet, so I’m posting what I was thinking when the question came up:So say I have an automation app that runs a couple of workspaces as needed by my manager, and emails results to an employee they choose. I think it would be cool to set it up to where my manager could tell an AI chat “email [automation app name] results to Lauren” and it would work with the parameters like it would with a workspace as an MCP tool. Or something like that - I’m still fairly new to MCP, and really FME Flow, but hopefully that makes sense!
Add the "EWKT" Geometry Encoding definition to GeometryReplacer and GeometryExtractor.EWKT is a simple extension to WKT that allows to include the coordinate system with the geometry, for instance: "SRID=4326;POINT(-44.3 60.1)" instead of "POINT(-44.3 60.1)"https://en.wikipedia.org/wiki/Well-known_text_representation_of_geometryEWKT is supported by Postgis and can be found in many open datasets.
Currently the translation log window starts with a messageCommand-line to run this workspace: "C:Program FilesFME2016.1.1fme.exe" someWorkspace.fmw --Param1 "Value1" --Param2 "Value2"but this information is not reflected in the log file itself, and unless you have a ParameterFetcher+Logger, you cannot easily recreate the settings of a workspace with just the log file.I would like an option in the Translation Log Settings to write the (published) parameter settings to the log file. Perhaps as part of the FME Configuration Inform messages?
Within FME Flow I am using several Deployment Parameters in a multitude of workspaces. When managing those, I would like to be able to see which workspaces and automations are referencing a specific deployment parameter, similar to how you can see within a workspace which transformers are using this deployment parameter.The reason why? I want to be able to see my impact whenUpdating/altering a deployment parameter → which workspaces and automations do I need to test Deleting a deployment parameter → can I delete this deployment parameter or is it still being used?Currently the only way to see this is to open every single workspace and check which deployment parameters are being used. Or managing a separate list with an overview of all deployment parameters and workspaces + automations.
It would be helpful if the text editor supported more advanced formatting options to create a more professional-looking output, including line breaks, text styling, and font customization.
IssueThe Migrating From REST API V3 section currently documents new, moved, and removed endpoints, including V3-to-V4 endpoint mappings.However, it does not document changes to the attributes within each endpoint’s request and response.Customers must therefore compare the V3 and V4 Swagger definitions side by side to identify:Added, removed, or renamed attributes Changes to required and optional fields Changes to object nesting and response structure Changes to parametersThis makes migrations time-consuming and increases the risk of missed changes, integration failures, delayed upgrades, and support cases.Proposed solutionFor each endpoint mapping, include a concise table showing attribute changes. If no attributes changed, state: “No request or response schema changes”This should become a standard part of future major-version migration documentation, including V4-to-V5. BenefitsReduces migration time and manual comparison Prevents customers from overlooking breaking changes Makes upgrade effort easier to estimate Reduces testing, troubleshooting, and support cases Creates a consistent process for future API migrations
Hello,We are currently expanding the use of Apache Kafka across our organization, and more and more departments are requesting access to published topics.Unfortunately, I cannot use the Apache Kafka Connector in FME to publish data because our Schema Registry is protected by authentication. When the connector tries to access the Schema Registry, it fails with an "Unauthorized" error.As a workaround, I developed a custom Python script that publishes the data directly to Kafka. While this solution works, it is far from ideal. One of the main advantages of FME is that non-developers can build and maintain integrations without writing code. Not everyone in our department is comfortable with Python, so relying on custom scripts creates an additional maintenance burden.It would be great if the Apache Kafka Connector supported authenticated Schema Registries, allowing users to publish messages directly through the native connector without requiring custom Python implementations.Best regards,Felix 😊
Could you please add a simple “Copy FMW Full Path” feature in Workbench.I’m referring to: It’s a simple request but a valuable one as it will save me a lot of time. (i.e. resolving service desk calls / documentation / ...)
Hello everyone,in FME Flow, it is currently possible to create multiple Automations with exactly the same name.From a user perspective, this can become confusing quite quickly, especially because Automations are displayed in a flat list and there is no structure comparable to repositories. If several Automations have the same name, it becomes harder to identify the correct one, especially in larger environments with many users and many Automations.I understand that the internal identifier is an ID and not the Automation name, which is technically the right approach. I also understand that there may be valid scenarios where different users, with different permissions, create Automations with the same name and cannot see each other’s items.Still, it would be helpful to improve the user experience here. Possible options could be: warn the user when creating an Automation with a name that already exists and is visible to them prevent duplicate names within the same visible scope provide folders or a repository-like structure for Automations improve filtering or tagging options to make larger Automation lists easier to manage This would help avoid confusion and reduce the risk of users editing, starting, or referencing the wrong Automation.Would it be possible to consider this as a future improvement for FME Flow?
In the current situation + Finland & Sweden joining NATO there is more demand to support Nato Vector Graphics (NVG) -format. Just read a RFP where it’s a must and waiting for more similar RFP’s to come. It’s not just the military people who ask for it, it’s also e.g. border control and who ever is providing services for them.
Hi Safe team,I’d just like to suggest that it may be helpful if published text parameters in FME Flow Apps could support placeholder text inside the input box.Example: For an email parameter, the field could show name@company.com as hint text without submitting it as a real value.Right now the workaround is to put the example in the prompt or in the app description, but placeholder text would be cleaner and easier for users.This would help for email fields, IDs, dates, and other inputs where a format example is useful.Thanks for considering!I’ve added example images below to show the current behavior and the suggested improvement.Current:Place holder text example:
I’ve been using the CESIUM 3D Tiles transformer, and my experience has been somewhat tricky because of (I hope) the version that FME writes (1.0). I wonder if future versions of FME will support the 1.1 version to help resolve some issues I’ve encountered, such as the structure of the .json output or to be able to select the type of geometry compression, like Draco, Meshopt, or Quantization.
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.
Add .ods reader and writer (LibreOffice OR OpenOffice) !
Level up to the parquet format (updates and snapshot)
When using a FME Server App which fails for some reason there is no built in way to return an error message to the user. It is always an unknown problem.It would be great if there was a way to return a few more details to the user. This is particularly important when an invalid dataset is uploaded. Without a workaround there is currently no way to let the user know their data needs to be fixed.
re-proposing the past idea:
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.