Open ideas have been reviewed by our Product Management and are open for commenting and voting.
It would be really useful to be able to check how long an FME Cloud instance has been running since it was last started up from the paused state. Could a call be added to the FME Cloud API to either get the time the instance was started up or how long it has been running since it started?
I would really want to have Georeferencing possibilities in the FME AR app/FME AR Writer to be able to view planned and current objects in real life at 1:1 scale through mobile devices. That could range from existing plumbing to planned buildings. We have tried the FME AR app out and found we lack this functionality to find the app useful to us.
I have observed that data present in seed file of dgn file is not considered while writing the dgn file. Instead FME is extracting the file settings like units and writing the destination file.It is better to retain the data (i.e. lines, tags, so on) as it is. It will be like updating the dgn file with the data just like UPDATE CELLS option to Excel
Currently, when the page content is set to table, the user needs to manually choose all column's content and name. Really hope there is an import button to auto-import all upstream columns or import from CSV to speed up the process.
To be able to encode text strings into metaphone and soundex representations would be a useful addition to FME's capabilities, and would perhaps fits within the existing TextEncoder transformer.My use case is with regard to place names, specifically to aid checking that candidate new names do not clash phonetically with existing names.Thanks!
AGOL & ArcGIS Portal right now do not support .esrijson files as an item type. To share small/modest/moderate size static data Esri JSON is easily convertible to features, emailed, shared to a platform that doesn't speak Esri and so on. Reply with your user story here and we can get it coming!
Using the new compare and merge tool, it would be great if we select and "ignore" elements from the reference workspace, if we do not want to merge them. It would help to go through all steps of the merging process.
When right clicking an object on the workspace canvas, you could publish disable/enable as a parameter. Then you could control the flow of the workspace and Readers/Writers straight with published parameters, and I wouldn't need to use filter transformers.
As someone who uses the FME chat feature, it would be nice to be able to drag and drop pics and possibly files instead of the current attachment button. I understand you want to have control over what gets uploaded, but as a Google Chat user, this feature would greatly speed up communication.
FME Server currently supports Active Directory on premises. Is there a need to support Azure Active Directory as another user security solution?
I am hoping that you could start putting the version of FME that a function or transformer was first available in your documentation, tutorials and knowledge base articles on every page. Or a statement of "applies to version yyyy.x" to clarify.I'm often disappointed that the golden nugget of information that I have found isn't available to me due to our current version of FME Server. So, my idea is to put in brackets the FME version that the functionality first existed with perhaps a dash followed by the FME version this particular item applies to. In a perfect world we would all be using the most recent version of FME possible, but that isn't the reality, especially for us. We are currently on FME Server 2019. All, I'm really looking for is the version of when the ability was first available. For example, I was looking for information on SFTP and found documentation on SFTP Directory. I had to navigate all the way to the top of the documentation to find out that I was looking at 2022 documentation. But that still doesn't tell me when that was first available and whether that is available to me in 2019.
When having a big workspace running, for the most of the the workspace components I wouldn't need detailed logging, just errors and warnings. But for some transformers, readers or writers I'd need very detailed logging (not just errors but all possible information for debugging).At the moment there's no separate logging settings for individual components of a workspace.
To be able to sort and/or filter by individual columns in the log viewer in desktop.Use case, identifying long running elements of a workbench
(Note: Not to be confused with the previously suggested idea “GeoBuf” - this is “FlatGeobuf”!)https://gdal.org/drivers/vector/flatgeobuf.htmlhttps://github.com/bjornharrtell/flatgeobuf/blob/master/README.mdExample: https://observablehq.com/@bjornharrtell/streaming-flatgeobuf
As we can zoom on a transformer by clicking on the log, it would be great to access the first call to the transformer in the log by clicking on the transformer (like the preview updates when you click on the lens ). It would save some time scrolling or searching.
There had been several suggestions to make design of FME Server automation workflows more graphical, and provide a higher level overview: https://knowledge.safe.com/idea/42491/system-architecture-design-view.html https://knowledge.safe.com/idea/18987/automation-workflows.html https://knowledge.safe.com/idea/19014/better-workflow-control-of-multi-step-workspace-jo.html I think a good addition to these ideas is the ability to display the status of each workflow step on this graphical framework, which makes this a visual monitoring / debugging interface, as well.
For a use case of this idea, please refer to this forum post.In summary, currently you can only access a single item in a list when using the adjacent features functionality. We should have the ability to access an entire list attribute, regardless of size/count, in order to copy it over to another existing or new list attribute. It would also be nice if perhaps the adjacent feature functionality is made available in other transformers such as the ListCopier, so we can copy an adjacent feature list attribute for each feature. Thanks.
Just like in some video games, having a list of all the available badges and how to get them could enhance the "gamification" of the platform. I know in my case I tend to give an extra nudge on someting if I know I'm close to get a badge or sticker :)
In short: Readers and Writers have and option to change a named database connection into an embedded one.This is our standard way of making sure that workspaces published to FME Server don’t overwrite other users' connections.And it is easy to do in FME Desktop:However, this not possible for FeatureReader, FeatureWriter, SQLCreator or SQLExecutor ! How many of your workspaces contain one or many of these transformers ? More than 50% ? 80% ? Yeah, I thought so …Consider the time savings, when in development you can add your transformers with named connections, and when publishing to FME Server you don’t have to embed the connection parameters by hand in every flaming transformer.In fact, it should be made possible in the ”Database Connections” section of Navigator - so that all transformers using that same connection would get embedded with one click !!!Read on for a case (almost) from real life ..Consider this scenario:your organization has several eager FME users, some of them fairly new, and you decide to let them publish their workspaces to FME Server. The users have learned enough FME to use saved ”Database Connections” in Desktop (because you teached them – or they learned it from an FME Webinar!).You yourself have made and deployed some critical scheduled workspaces using your own ”standardized” Database Connections like ”REPORTING”, ”CRM”, etc.After awhile you get emails from business users complaining that they haven’t received their critical reports for after sales marketing or contact lists of potential new customers.You start investigating and find out that your workspaces have crashed when trying to connect to the ”REPORTING” database. So what on earth has happened ?You finally find out that someone has actually over-written your database connection in FME Server. Someone has used the same database connection name ”REPORTING”, clicked ”Yes” when asked by FME whether existing connection with the same name should be replaced, and done the damage.But you remember that you told your FME users to replace their named database connections with embeded connection parameters in Readers and Writers when publishing their workspaces, and everyone says they have done so!So now you look at the Database Connections definition of ”REPORTING” in FME Server and find out that it connects to a completely different data warehouse (the one called HR_REPORTING). You then call the HR guy who made the latest deployment and ask him why he didn’t embed the connection parameters.He claims he did, only that he added one FeatureReader, tested with his named database connection ”REPORTING”, but could find the command to embed the connection parameters in the transformer. So he thought FME would somehow automagically take care of it, as it does for many things, and published his workspace anyway ...
A Geocoder for FME Server Apps would be a useful tool for locating users 'areas of interest' over a large area.This could be an addition to the geometry picker tool (new in 2020)orA stand alone map that can be added to FME server appsThis idea comes from feedback from users in the month of April 2020.The useful part of FME Server Apps is the speed you can deploy a workspace to server and make it available to users, this automates users for self-serve.based on a questionhttps://knowledge.safe.com/questions/112959/fme-server-app-geocoder.html
When one makes an error in the attribute manager it could be useful to have an undo button or support for CTRL+Z to undo. Asking for a friend.
No account yet? Create an account
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.