Open ideas have been reviewed by our Product Management and are open for commenting and voting.
The idea is to have an FME function that crawls database connections to extract the schema of the data.For example, when you create a database connection there would be an option to create a crawler. When chosen we crawl the database (or specified parts of it) at intervals and store the table list and schemas locally. That way, when a user adds a reader and requests a list of tables, the response can be instantaneous and FME doesn't need to fetch that info from the database.The crawler could be set to run at specified intervals, or on demand. The information it returns would include any schema information such as table names, field names, indexing, etc. The information would be held in a form of catalog that FME readers/writers/transformers can access. Maybe it could even be held in a format (like sqlite?) that users could read from it too?
As an FME Flow Admin I would like to have the ability to set an expiration date for FME Flow profiles. This would likely be an optional parameter that could be set on a user or role level. Some of our project managers have requested this, particularly when we have external users(sub-contractors) accessing our infrastructure. This would help tremendously to manage access automatically as opposed to manually having to remove access or profiles after a projects period of performance.This is just a conversation starter. Removing a user from a role would remove access from an app--for example--but it does not prevent access to FME Flow depending on the users profile settings. Thanks for all you do
I have a large amount (3000+) of structured e57 files that I would like to convert to Leica/Hexagons proprietary format which is LGS/LGSx. e57's, while great due to being non-propritary, are large. Leica's LGS and even great LGSx files can store the same structured point cloud data but into half or a third the space. My 20TB of point cloud data could be as low as 7-10TBs, this is a great savings in storage costs. The only workflow I know is to import e57s into Leica's Cyclone or Cyclone Register 360 platforms and export LGS/LGSx. Doing this 3000+ times might kill me lol. Being able to set this up on my FME Server means I could do it hands off 24/7. Please Safe/FME I know I would not be the only one to benefit from such a transformer.
In a standard reader you have the option to clip to extents if setting a search envelope. Similar functionality in the FeatureReader would be useful when a spatial filter is being used to give the option to clip to the filter feature
Hi,I tend to build very long horizontal scripts due to my company guidelines regarding FME Form. It would be a convenient feature to be able to scroll horizontally using the shift key + mouse wheel. Best regards,Jacques de Flon
Just thought it would be potentially useful to have a writer feature type's icon vary depending on whether it is creating, truncating or dropping/creating the table. At present you have to view each feature type's parameters and it would be a bit quicker if you could instead see at a glance what it was doing. Obviously there's a big difference between the operations with at times significant connotations to using the wrong one, so whilst there's the onus on the author to check things this might well help.
IFC writing at the moment does not support IFC Types and IFC Material layers. Can this please be added?
Support for exposing IfcPresentationLayerAssignment entity from IFC file to attributes. Building IFC models often have autocad layer values assigned to IfcPresentationLayerAssignment entity. By being able to expose IfcPresentationLayerAssignment entity, it would be easier to parse different elements from IFC models automatically.Related question: https://community.safe.com/s/question/0D54Q00008ufsxOSAQ/how-do-i-expose-ifcpresentationlayerassignment-entity-from-ifc-file
First of all, I agree that IFC is used in many ways, not all IFC's fits together, and not all IFC's are completely "after the book".One way is to give an address and lat / long in IfcSite. But this is only an approximate location, linked to the address point. It has nothing to do with the coordinate system used. By using this, one probably ends up on the right plot, but not with any particular accuracy.Example from a sample file good building-case-project:IFCSite with Address Verification:# 111 = IFCSITE ('01uPthe3Uixx0TRWar3Vt8', # 26, 'Helland', 'Test plot in B X2 00F8 X0 ', $, # 108, $, $,. ELEMENT., (59,24,47,484830 ), (9,3,30,811790), 75000., '3817-55 / 40/0/0', # 99);# 99 = IFCPOSTALADDRESS ($, $, $, $, ('Kyrkjevegen 6'), $, $, 'B X2 00F8 X0 i Telemark', '3800', 'Norge');But what needs to be taken into account are:# 80 = IFCGEOMETRICREPRESENTATIONCONTEXT ($, 'Model', 3.0.01, # 77, # 78);# 84 = IFCPROJECT ('0LgUPU8IoJzfI479rEc5t9', # 26, 'DiBK Office Build', 'DiBK Standard Office Model', $, $, 'Building Case BIM', (# 80), # 67);# 95 = IFCMAPCONVERSION (# 80, # 96,503000000., 6586000000., 0., 1., 0., 1.); (NB! This is the origin of the local IFC coordinate system)# 96 = IFCPROJECTEDCRS ('EPSG: 25832', 'EPSG EU89 UTM33', 'EU89', 'NN2000', 'EU89 UTM33', '33', $);It does not look like the FME can do this atm, how about a transformer that can handle this?
Some context on IFC Rail here from BuildingSmart https://www.buildingsmart.org/wp-content/uploads/2019/10/RWR-IFC_Rail-Context-Approach_1.1.pdf Let us know what your use case is and how this might be helpful in your workflows!
Set units and Coordinate System into the IFC settings. Even selecting a coordinate system in the IFC writer, the location is lost as you open it into another 3D tool/viewer
It would be beneficial for FME to support IFC4x3 (reader, schema, documentation and writer) in a better way, as it has officially received the ISO 16739-1:2024 certification. since many of the projects now require IFC4x3 for data delivery.
Part of the "BuildingSmart IFC for Infrastructure Project" the IFC Alignment extension includes Road Rail and Bridges. http://www.buildingsmart-tech.org/infrastructure/projects/alignment The Idea is to extend the FME IFC reader/writer to support this IFC extension.
Create the ability to do in-place upgrades for FME Flow (Server). This would save considerable time and effort. At least the ability to apply patch releases without a complete new installation would be very helpful. As it is now, upgrades take a huge amount of time to install, configure, test, and migrate from existing installations. If this capability existed, many hours would be saved, and make regular upgrades smoother and faster.
It would be good to get the option to “Load Preset” in addition to “Load template” when using the Email Action so I don’t have re-type all the configuration values each time.For example, I cannot use “Load Template” as O365 would have different parameters set for our organisation. We also use different mail servers for 0365 hence the request.
Short lived tokens to SASS providers like ESRI AGOL require reauthorization after establishing the initial connection. I would like a way to create a workspace that could update the tokens on a set schedule instead of doing a manual process.
Should FME have an AutoDesk Forge API connector transformer to provide a more generic way of connecting to AutoDesk applications? Currently FME has an AutodeskA360Connector but users have mentioned the need to connect to Autodesk BIM 360 Docs (see idea) and other parts of the Forge API such as the Data Management and Model Derivative end points. Would these needs be better solved simply by adding a new Web Service Connection type to FME?Please comment below on any workflows or specific requirements relating to the AutoDesk Forge API.
The reader would return all the metadata descriptions of the layers defined in a .mxd file, and the writer would take this information and create a .mxd file. ArcObjects would have to be available for this to work. Would provide for bulk operations on .mxd files, as well as creation of .mxd files in the same process as geodatabases or shape files were being created.
It would be great if we had the option to embed a warning in the default output value of transformers like the Attribute Value Mapper. It would work in a similar war to the “@Abort()” function, but instead of stopping the translation, it would return a custom warning in the log. This can be really useful in tools that are designed to be run by people who don’t know much FME and/or tools that are designed to run automatically.As a side note, yes, I understand that you can just write a custom default value there and use it to identify the bad values downstream. This idea would essentially be an alternate way of doing that, and would be simpler/more direct.
There are a number of operations that are made much easier and/or more efficient by simply having data be passed around a file on disk instead of as FME features. When dealing with large amounts of features going into a PythonCaller, for instance, it can be preferable to dump them all into a Parquet or Arrow file and decode that file with Pandas or some other dataframe library, rather than extracting attribute data feature by feature in Python. Some other use-cases, like Emailer, also often make use of temporary files.The issue is that having FeatureWriter recieve both a path from TempPathnameCreator and the features it needs to actually write doesn’t work, that path needs to be joined on each feature in any of various clumsy methods. Given most uses of TempPathnameCreator are intended to feed into FeatureWriter, I would suggest that “Temporary local file” be a valid dataset option for FeatureWriter, which would simply generate a temporary path in FME_TEMP, write all features to it and allow the file name to be retrieved as the _dataset attribute under the Summary tag, as is already the case. It would otherwise work in exactly the same way as the combination of TempPathnameCreator and FeatureWriter, but simpler to setup.Any scenario where it is more practical to pass features between transformers as single files rather than large collections of features might benefit from this.
The suggestion I have is to allow for the GoogleDriveConnector Delete action to work with “Move to Trash” HTTP call request to Google API V2, instead of using the Delete HTTP call. The reason for this is due to the difference between the “Content Manager” and “Manager” access levels. A “Content Manager” is allowed to move files to the trash, but not allowed to “permanently delete” files.Only “Manager” access level is allow to “permanently delete” files.As it stands right now the GoogleDriveConnector is sending a request to “permanently delete” files, which in Google Shared Drives would only work for users with “Manager” access level and not the “Content Manager” access level that is generally assigned to team members in an organization.
It would be great to have an Tolerence-Parameter and Automatic Mode for the transformers Matcher and ChangeDetector, similiar to the LineOnLineOverlayer for example.Espacially when you work with geographic coordinate systems (latlong) and data from different systems/formats is it hard to find a proper value for the vector tolerance. An Automatic Mode would help a lot.bestThomas
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.