Shape the future of FME with your ideas
Open ideas have been reviewed by our Product Management and are open for commenting and voting.
When working with a big shared Revit project the use of Worksets is essential for being able to collaborate in the same file. Every object in the Revit file is assigned to a Workset and when the user wants to work in the Revit file he/she checks out a Workset.It would be useful to be able to use these Worksets in FME when reading a Revit file. Sometimes the need is just to read the objects inside a certain Workset and then this parameter could filter out what the user need.So this idea is for creating the same possibility to choose Worksets as to choose Views in the Revit reader.
***Note from Migration:*** Original Title was: Create a igds_info feature with Drawing System Variables like autocad_info but for Microstation V8 DGN-reader The parameter Read Drawing System Variable in the AutoCAD DWG-readers are much used to retrieve information about a DWG-file. Currently there's no equivalent when reading Microstation DGN-files. This idea is for creating a new parameter in the DGN V8-reader: Read Drawing System Variable which creates an igds_info feature which holds information like DGN-version, units, current level an so on.
It would be useful to be able to configure the CouchDB reader to read from a view using a startkey and endkey to limit the returned documents. Since we have views in the database for other uses, it would be convenient to be able to query the views directly from FME instead of having to return all documents from the database and filter them.For example, a database with a view where the keys are built from a retailer name and unix timestamp. The view design document looks something like this:function (doc) { // code for only returning the subset of documents this view is for. // E.g. maybe this view is only for returning sale records if (doc.type != 'sale'){ return; } // output the view keys and values emit([doc.retailer, (new Date(doc.createddate)).getTime()], doc); }I am getting around this currently using the CouchDB http API and an HTTPCaller with the request URL directed to the view and parsing the returned JSON. As shown below, I am getting the records for "retailer1" in the month of February 2020.
What I'd like to see is an option that shows, if you click a transformer, transformer port, feature type or connection, all the places where features upstream or downstream are.I can't seem to attach images right now but here's a mockup I made:exampleImagine you clicked the SpatialFilter's Passed port. The red line shows all features/streams on the input side affecting that port, the green line shows all features/streams where results from this port can end up.I think this could be very helpful in trying to debug complex workspaces, it would make it easier to understand the flow of data. In addition to that it could be very useful for novice users to gain that understanding of FME.
Universally in transformers, readers and writers that have the ability for the user to select a coordinate reference system, the pick list presented to the user can really easily be broken and can force an error. For old-FME-timers like me that's just a well trodden peril. But for new users, just starting out it's awkward to tell them that this is just the way things are.So, in the Reprojector if a user searches for 4326 and finds "EPSG:4326" but doesn't have the foresight to pick it from the list of presented CRS', and instead just clicks the focus away (which is really easy to do)... the user ends up with this getting filled into the dialog "4326". When the process runs that CRS is found not to exist and the process errors at worst and does nothing at best.Please can this CRS pick list become an uneditable and fixed picklist that allows you to select something from the list or nothing at all. A very simple change but will remove a lot of very frustrating and difficult to debug workspace failures.
I've been meaning to post this for a long time, because it's a frustrating issue but by nature of where it appears it's usually just when I'm getting into something so I've never prioritised posting this.The 'generate workspace' dialog has a memory within the same session of the last workplace that you built. This IS very handy when you make a mistake adding readers and writers as you can go back and make the small change to a parameter without completely updating the whole dialog box. But, if you start a new workspace and have to update each parameter and perhaps are not thinking about reprojection for example, you might accidentally end up filling in a projection if you reprojected in the previous process!Simple fix, please just provide us with a 'clear all' button on this dialog!
At the moment in the Workbench settings under Tools > FME Options it IS possible to reset the settings on one page, for example on the 'Translation' tab. But if you want to reset all settings back to factory default you have to do every page, one at a time.Please can we have a 'Reset All' button that will clear back all system settings. Or force you to a selection dialog box where you can tick off which settings to revert.This would be especially useful for test deployments, training machines and debugging.It is the opposite of being able to export all settings and share them with a colleague or another machine, but no less important than @takashi's suggestion here https://knowledge.safe.com/content/idea/84078/backuprestore-fme-options-configuration.html .
If you need a polygon,line or a point as input for a workspace then it would be nice if the user interface provides a map component to draw the object so you can use it.For now I use a custom form with some javascript: WicketBut it would be nice to have it implemented into the standard web interface of FME server.
Derived from: Where are the fme_dataset and fme_basename attributes when reading with the FeatureReader?In most formats, you can read "fme_basename" and "fme_dataset" with a FeatureReader by selecting them through the Additional Attributes to Expose parameter in the reader parameters.It's good but then the schema feature output from the Schema port of the FeatureReader would contain those attributes in the schema definition (attribute{} list), as in:It's just annoying when configuring dynamic schema writer feature type using the schema feature as the schema source. You will have to remove them through the Attributes to Remove parameter in the writer feature type if you don't want to write them into the destination dataset, and I think you don't want to write them usually.In my observation, not only "fme_basename" and "fme_dataset" but also other format attributes will be added to the attribute{} list in the schema feature if you expose them via the Additional Attributes to Expose parameter.I think it would be better if the FeatureReader would never add any format attributes to the attribute{} list in the schema feature.
The ability to add colour to a connection line, so it is easier to distinct between different feature routes
Currently when I use the Directory Watch trigger (or any other watcher) to watch for modified files FME Server will watch on file size only. This means that even if my file has been updated, if the file size remains the same my Automation/Notification will not be triggered. I'd like the watchers to watch the timestamp on files when available.
I was curious if there was some way to set FME Server up so that if a job from a workspace that was already running, the new job would either be cancelled or sent to the queue/held until the current job got done running. This would be useful especially for jobs automatically submitted through schedules or automations when writing out so you don't write double records.I think I'm basically asking for this, but productized so we don't have to implement it in each workspace that's in a schedule. Additionally, it might be something that I could see added into the automation functionality on FME server.
Give the option to provide the capability to enforce password renewal for users in FME Server.
Today I was investigating the use of a PUSH subscription (HTTP POST) to notify some other application about the results of their job.This application (SAS) needs a quite specifically formatted XML-body to understand my message. I was unable to parse this from a XMLTemplater and textwriter in the workspace, through a notification, to the body the PUSH subscription sends to the provided URL.The alternative was a more text-like body, I could easily get to the subscription, Only that needed to be presented as an application/x-www-form-urlencoded contend type. A content type the push subscription does not support.I ended up making a workspace subscription and a small workspace with a HTTPCaller converting the subscriber_content to the desired body format. This is a bit like building the PUSH Subscription service I would like to see.Would it be an idea to upgrade the PUSH subscription, give it some more content-type methods (perhaps even more REST methods) and a template for the body and perhaps for the URL? Like a mini-HTTPCaller / XMLTemplater / JSONTemplater combination?Kind regards,Martin
The same as the (2D) Generalizer, there should be a 3D Generalizer. I've created a custom transformer by myself that is doing the trick.
There isn't a truly easy way to generate a file (excel, CSV, etc) and then email the file after it is finished being created. I run into the issue on large workflows that the emailer tries to email before the separate sheets have all been written to an excel workbook, and sometimes the emailer tries to run before the workbook is even created. Why does the workflow end when I'm writing to a file?
Hello,When reading metadata features from file geodatabase Reader or SDE reader, the attribute geodb_feature_dataset is not being populated (missing). it would be useful to have access to that information in many cases (selection, filtering, modify/update metadata, etc).Bug reported with case C142892 with Safe Support
When using Feature Caching, currently "Run to this" will load all Feature Types of the Reader, which is very time consuming on large datasets. It would be much nicer if it only imported the Feature Type from the Reader that the current "Run to this" is actually in need of.
PATH Reader: Add where clause "like" functionality to only read certain filesCurrently, this reader forces the user to read all the files (w/ properties) into memory and THEN filter them in the workspace for size, date, etc.I contest that I can get these properties much much faster via DOS DIR command written to .txt -- why can't the reader do this upfront?
***Note from Migration:*** Original Title was: GeoPackage-writer registers the proper geometry type in GPKG_GEOMETRY_COLUMNS for tables with features of a single geometry-type Feature tables in GeoPackage are registered in the GPKG_GEOMETRY_COLUMNS table with their geometry column, SRS and geometry type. Right now FME registers all tables with the common geometry type GEOMETRY. For tables that contains features with only one single geometry type FME should register this geometry type in the GPKG_GEOMETRY_COLUMNS table as defined in the GeoPackage-specification. For example, a table with only point features (geopackage_type: wkb_point) should be registered as a POINT geometry type instead of the GEOMETRY geometry type. This will help other applications (like QGIS, for example) to better understand the contents of the GeoPackage table.
Even though I've been using FME for some years for some reason I've only just discovered the Workspace Runner when I was researching the ability to set the paths for readers and writers using attributes.The current version of Workspace Runner appears to mostly fulfil this in that it identifies the paths for the primary input and output and I can use an attribute to define common base folder paths (which I can then pass to multiple workspaces). The problem I'm having is with workspaces that have not only a primary input and output but also a feature writer embedded within the flow. The Workspace Runner is not identifying the output path for this feature writer as a parameter which means if this changes I need to go in and set it manually which largely negates the reason I was using a Workspace Runner in the first place.Would it be possible for the Workspace Runner to be developed so that it would also identify the folder paths for feature writers (and most probably feature readers).Many thanks
In the Esri ArcGIS Online (AGOL) Feature Service Reader, allow connecting to a feature service via entering the AGOL Item ID as a value. This could be a seperate parameter field or maybe this could be an option via the text editor for the Feature Service parameter field?Currently FME populates a list of feature services retrieved from AGOL, however you cannot find a feature service via its AGOL Item ID.While the pre-populated list is great, the list can be very long both to generate and to sift through. Often to be certain I'm selecting the correct Item, I have to hunt the feature service down in AGOL to figure out which folder it is in. It would be helpful to have the option of simply pasting the Items unique global ID as a value.The screen capture below clarifies how the current lookup functions, as an example I am selecting a feature service titled "RC_TPW_StreetLight_Replace_pnts_Public"Screen capture below clarifies the AGOL Item ID I am referring to. In this case, viewing the item titled "RC_TPW_StreetLight_Replace_pnts_Public" in AGOL exposes the ID as 4707e815a61c47cfbf8438e528db5aa0Thank you for considering this idea!Edited for clarity
Would it be possible to add more flexibility to the building of action parameters? For now the text editor only offers to concatenate elements (event or automation attributes) and write free text. It would be nice if we could directly generate a parameter with more text editing options or even Jqueries. This could also be through an action dedicated to create keys if it is too complex to add it to the text editor. It would save us from generating dedicated workspaces for simple text operations.
In case the SQL statement in a SQL Executor transformer returns more than one record, it would be very beneficial to have an option to add those records as a list to the original feature.At this moment the feature is causing an error and will be rejected.
Please can you add a new FME Feature Function which calculates the current date and timestamp?You have a Timestamp() function but that requires an input string and you have a Timestamper transformer but I think it makes sense to have a Now (or Today) function similar to applications like Excel.This means you can then test a date/time attribute against the current date/time in a Tester transformer without needing an additional transformer or use of Python.
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.
