Open ideas have been reviewed by our Product Management and are open for commenting and voting.
Ability to write to the Autodesk Revit format *.rvt (as opposed to *.ifc)This may involve having to read in an existing revit file to pick up the schema (fieldnames) of geometry. Geometry / fieldnames could then be mapped from the existing format being read into FME to the revit output format.If native reading of RVT files is of interest, vote for this idea too.
I think a right click context option to switch a transformer between an AttributeKeeper and an AttributeRemover would be neat.
It could be useful to have a "replace with..." option in the transformer right-click menu, or have the Quick Add do that when using it while a transformer is selected. This could save some effort when replacing one transformer with another.
There are different transformers with the same functionality. When it is about to change such a transformer to a more generic one, It would be really handy to be able do it automatically than create the more generic transformer and copy over the parameters. Eg:AttributeCreator, AttributeRemover or AttributeCopier to AttributeManager, Tester (or even AttributeFilter) to TestFilter
If I had two AttributeCreators with 10 attributes with 10 conditional values in each I would like a quick way to merge the two to a single AttributeCreator/Manager as it is both time consuming and risky to to this manually.
***Note from Migration:*** Original Title was: Adding a right-click "Replace by AttributeManager" on transformers when revelant I would like a "Replace by AttributeManager" option when I right-click on an AttributeKeeper or an AttributeRemover or a StringConcatenator, etc.And the cherry on the cake, be able to replace a selection of multiple connected revelant transformers by one AttributeManager (like a "Replace all selected Transformers by AttributeManager" option).
Would be nice to be able to expose and use fme feature attributes directly in the inspector, rather than adding an attribute exposer.
BulkAttributeExposer: Expose all possible attributes, especially for JSON and XML when you don't know what's in your dataset.Merged Ideas:Expose Attributes from Feature Cache by denniswilhelm on October 20, 2019I think it would be very handy if you could expose attributes from the feature cache. The main idea is that you would run a workspace once to build up your cache and use these features to get a list of possible attributes to be used in the AttributeExposer.Especially when using a PythonCaller or a HTTPCaller that retrieves an arbitrary JSON structure, this would allow you to easily identify all required attributes.What do you think?
I think it would be very handy if you could expose attributes from the feature cache. The main idea is that you would run a workspace once to build up your cache and use these features to get a list of possible attributes to be used in the AttributeExposer.Especially when using a PythonCaller or a HTTPCaller that retrieves an arbitrary JSON structure, this would allow you to easily identify all required attributes.What do you think?
It would be nice with a small pop-up/notification in the system tray of windows / mac / linux when a workspace completes. With the following information for instance:"Workspace myworkspace.fmw Completed Successfully - 1 hour 32 min - 8 files written - go to outputcatalogue here: link or open workspace here: link"Then you can easily go to the outputcatalogue and you can easily navigate to that workspace.
String attribute values should be represented in a monospaced font rather than a variable width (serif or sans serif) font. Otherwise, it's too easy to miss subtle details like duplicated characters that happen to be narrow and look like one in variable width fonts. This is a standard in software development environments; FME should be no different."Setting text in a monospace font makes it easier to identify characters by themselves. Because of this, tasks that rely on the easy identification of specific characters, such as programming, benefit from the use of a monospace font." - https://www.techwalla.com/articles/proportional-vs-monospace-fonts
Sometimes it can be hard to identify data quality issues in the data inspector table view with whatever the default font is. It would be helpful if I could select an alternative font (like a mono-spaced font with ligatures) so that certain characters (especially the letter "O" and "I" and numbers "0" and "1") are more easily distinguished.
Users with some older mobile data collection software packages need an ability to directly read the Microsoft SQL Compact database file (*.SDF). Would like to handle these files directly without having to use SystemCaller, VB programs, or other methods to wrestle with the data. This would allow us to build models that would sync this mobile data with more current enterprise database systems.
would like to see a .SDF reader for wincan vx (pipe survey CCTV) data base files, have tried the SDF readers within FME but nothing works. Believe this maybe a SQL compact database.
The Reprojector Transformer has been around for a while now but the CsmapReprojector clearly has the same capabilities with the added capabilities of transformation and vertical handling. There doesn't appear to me to be much point in retaining both, so perhaps it's time to alias the name of one in favour of the other for the sake of simplicity.
Merge these 8 transformers into just 4 to simplify.
My main work uses network drives for both workspaces and data. For convinience most of these are mapped by drive letters.But if a workspace is attempted to be run with different credentials than my normal login, these may fail. The only work-around is to always manually enter the UNC paths instead of the drive letters.My suggestion is to add an option to Workbench to have it automatically replace all non-local drive references to their UNC eqivalents when saving the workspace.Cheers.
When you save an FME script that has UNC references to readers or writers, FME often replaces that UNC path with $(FME_MF_DIR). However, this causes problems in FME Server, which uploads the FMW script to the FME Server folder and can't find the reader or writer using $(FME_MF_DIR). I would like an option in the FME Options dialog so that you could turn this behaviour off. When I use a UNC path there is no need to convert it to $(FME_MF_DIR). The path will always be the same whether FME is reading it on the server or on a desktop
It would be very useful if this was an automatic process when you publish to server. FME knows the mapped drives so it should know the full UNC path.
Be able to use UNC paths with other credentials. If multiple users have different functional IDs to UNC paths, they should be able to enter those and when the workspace is sent to server, those are used as well.
I've just come across an issue where a back-end system has migrated from one server to another and as part of the process the server name changed, for example; from server01 to server02. The problem I had was that whilst I could easily go into Database Connections and update the connection details in there I also had a number of workspaces that pulled MapInfo TAB files from various locations on that server. I had to go and update the UNC paths to the file locations for each of these.In a similar vein to the Database Connections and Web Connections options would it be possible to have a new option for defining commonly used UNC paths which you could then assign aliases to, for example; \\server01applicationmaps could have an alias of app_maps which could then be used in readers and writers. The advantage of this would be that if a server name changed or path moved then this could be updated in a single place which would take effect immediately across multiple workspaces.
Hi, would it be possible to make the clipper coordinate system aware? Like data inspection which displays data in different coordinate systems on the right position with respect to the background. Currently, the clipper just treads geometries as coordinate lists and if two feature have different coordinate systemen (for example the first has a projected cs and the second a geocentric cs) the results are unpredictable, since projected cs usually have large coordinate values and geocentric cs usually have angular values in general smaller than 360 degrees. There is allready an idea to have the Clipper flag a message if coordinate systems are different, however, not every one studies log files thoroughly. See Clipper: Add a note in the log when coordinate systems are different
When clipping with two datasets, I don't realize they are in different coordinate systems. FME is completely silent about this and succeeds. It would be nice if there was some indication that my desired result won't happen.Maybe log that that coordinate systems are different between the features?I suppose this warning could be given for all spatial overlay transformers.
I would like the option to disable all other bookmarks.
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.
