Question

Writing to a GDB using a UUID or Timestamp

S
Badge +1

I would like to create a folder for output that is named by either a UUID or Timestamp. Within that folder I want to output multiple feature classes within one geodatabase, plus add other items such as layer files loose into that folder.

So for example it might look this this:

UUIDFolder/ (containing loose lyr files etc.)

PLUS

UUIDFolder/export.gdb (containing multiple features classes)

The problems I'm facing are as follows:

- I can create a parameter for UUID/Timestamp, using @UUID() for example, then link my writer to that parameter, but whenever it tries to write out it creates a brand new stamp.

- I can create an attribute from the parameter and use a fanout expression with the attribute value but this always fails to write. And it seems impossible to populate a new parameter from the attribute.

I'm trying to do this all in one workbench rather that export attributes as parameters using JSON to a second workbench.

It is failing in both Desktop and Server.

Any ideas?

3 replies

takashi
Rank
Userlevel 2
Badge +17

Hi @soothsayers, UUID should be unique within the spatiotemporal space. Naturally different ID will be generated whenever you generate an UUID value with the @UUID function.

If you want to create and use just a single UUID value per a translation, consider using a Creator (Number to Create: 1) and a VariableSetter to save a UUID as a global variable at first. You can then retrieve the UUID anywhere the workflow with a VariableRetriever, like this.

Note the Creator should be run at first. By default (Create At End: No), the Creator will outputs a feature before every reader starts outputting features. However, if your workspace contains other Creators or similar kick-starter transformers such as SQLCreator, PythonCreator, etc., you will have to modify their runtime order appropriately (Right-click on a Creator > Set Creator Runtime Order).
S
Badge +1

Thanks @takashi. I eventually got this working using a fanout dataset, and forcing my writing to accept values with my new favourite transformer - the Unconditional Feature Merger!

takashi
Rank
Userlevel 2
Badge +17

Thanks @takashi. I eventually got this working using a fanout dataset, and forcing my writing to accept values with my new favourite transformer - the Unconditional Feature Merger!

Good to hear.

 

FYI, in modern FME, you can use the regular FeatureMerger to perform unconditional merging, by setting an identical constant value (e.g. 1) to the Join On parameter for both Requestor and Supplier.

 

Reply


Community Stats

28,707
Posts
109,479
Replies
36,553
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.