Skip to main content
  • EN

We have a dynamic, schema independent workflow. In order to write our output properly to shapefiles, I need to make sure that the fields which are dates, are formatted in ISO Date (%Y-%m-%d) format.

The attached workspace uses a list searcher to find the first date attribute (I plan to turn it into a custom transformer to be able to loop so I can find all date attributes, but that's for later). With the listSearcher index I get the attribute name which is a date. The corresponding attribute name retrieved using a small piece of python, storing the name in an attribute named _dateAttribute.

This name is passed on onto another custom transformer. The custom transformer has a parameter which is using this name. This parameter is used by the DateFormatter to specify which attribute is a date field and thus which field it should format.

In stead of the attribute name however, the DateFormatter is trying to convert a field name @Value(_dateAttribute). Parallel to the dateformatter, I added an attributeCreator, which creates an arbitrary attribute with the value of the parameter. There, it shows the proper name of the attribute.

In conclusion: it seems like the DateFormatter is not reading the parameter properly, but I don't know why.

Hoi @bzwemmer (Bart), your sample data does not contain any date values (just the schema), so how do you expect to format it?

I would use the demote found list attribute option in the ListSearcher and not any python for standard functionality

Have a look at the ListElementFilter from the FME Hub, it can save you some time....

Hai @itay I must have included the wrong file. Please find a subset of the data attached. data.zip

 

The list is created much earlier in the main workspace, hence the listSearcher. For further development, I can also use it to pass a list of attributes to the DateFormatter, in stead of doing it one by one.

 

Even with your approach, the behaviour of the DateFormatter with the parameter strikes me as odd., but maybe I am missing something.

Hai @itay I must have included the wrong file. Please find a subset of the data attached. data.zip

 

The list is created much earlier in the main workspace, hence the listSearcher. For further development, I can also use it to pass a list of attributes to the DateFormatter, in stead of doing it one by one.

 

Even with your approach, the behaviour of the DateFormatter with the parameter strikes me as odd., but maybe I am missing something.

Hoi Bart, already did see the FFS data (its included in the fmewt) and what you just delivered is still without any attributes and only the schema list.

 

 

You can better send a sample from the D:\\Bart\\TESTDATA\\Conversie\\707\\19537_export.gdb

 

 

 

Now with the datadata.zip

 

Hoi @bzwemmer do you intent to write the data into a date data type in the shape files? if so that can be an issue, since the shape file format doesn't allow the ISO annotation.

Naturally writitng it as a string is possible.

Hoi @bzwemmer do you intent to write the data into a date data type in the shape files? if so that can be an issue, since the shape file format doesn't allow the ISO annotation.

Naturally writitng it as a string is possible.

@itay this workspace is part of a data conversion. The input data is formatted as date (at least some columns), so we try to keep it like that when converting.

 

 

Our local Safe support where I asked the same question suggested to convert to ISO date. In essence, in both cases the writer should recognize the data as a date-type, since that is what is specified in the schema.

 

@itay this workspace is part of a data conversion. The input data is formatted as date (at least some columns), so we try to keep it like that when converting.

 

 

Our local Safe support where I asked the same question suggested to convert to ISO date. In essence, in both cases the writer should recognize the data as a date-type, since that is what is specified in the schema.

 

Since you are using a dynamic translation, I wonder that why its not actually detecting the data type (date) for you.

 

 

@itay this workspace is part of a data conversion. The input data is formatted as date (at least some columns), so we try to keep it like that when converting.

 

 

Our local Safe support where I asked the same question suggested to convert to ISO date. In essence, in both cases the writer should recognize the data as a date-type, since that is what is specified in the schema.

 

Since the Date Formatter accepts a user parameter, I would first define the date attributes in a pre-processing step and then provide it to the DateFormatter as a parameter in the processing step.

 

 

something like this

ffs2esrishape.fmw

Reply


Community Stats

30,126
Posts
114,354
Replies
37,760
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.