+14HI,
For test purposes I'm reading from two ESRI FileGDB with a FFS writer (no further transformations).
Now I recognized that the FFS writer wrote an additional .fts file. It's binary and larger than the.ffs (e.g. 5MB vs 11kb).
What is the meaning of .fts files?
thanks, Klaus
(FME Server 2017.1)
Best answer by fmelizard
".fts" is the "FME Feature Table" store. This is a more compact, faster way we deal with data that is known to share a schema across rows. The File Geodatabase (API) reader was an early convert to this new method of handling data. So I'm not surprised you saw what you're seeing. And the .fts does carry by far the bulk of the data, so that is why there is the size difference.
Right now CSV and MapInfo Extended are the other two readers that work in this way and would result in .fts files when written to FFS. An increasing # of transformers are being changed to either work upon or output data using this new technique, but all any user should notice is that things just work faster.
+14Â
Â
+21".fts" is the "FME Feature Table" store. This is a more compact, faster way we deal with data that is known to share a schema across rows. The File Geodatabase (API) reader was an early convert to this new method of handling data. So I'm not surprised you saw what you're seeing. And the .fts does carry by far the bulk of the data, so that is why there is the size difference.
Right now CSV and MapInfo Extended are the other two readers that work in this way and would result in .fts files when written to FFS. An increasing # of transformers are being changed to either work upon or output data using this new technique, but all any user should notice is that things just work faster.
+52".fts" is the "FME Feature Table" store. This is a more compact, faster way we deal with data that is known to share a schema across rows. The File Geodatabase (API) reader was an early convert to this new method of handling data. So I'm not surprised you saw what you're seeing. And the .fts does carry by far the bulk of the data, so that is why there is the size difference.
Right now CSV and MapInfo Extended are the other two readers that work in this way and would result in .fts files when written to FFS. An increasing # of transformers are being changed to either work upon or output data using this new technique, but all any user should notice is that things just work faster.
Â
Â
+14Thanks for explanation. Do I understand correctly that the Geodatabase API reader detects the different "flavours" of File GDBs automatically and writes . ffs if the GDB does not share a schema across rows and .ffs plus .fts if the GDB shares a schema across rows?
This would explain why some of my GDBs result in ffs and others in ffs/fts.
+6".fts" is the "FME Feature Table" store. This is a more compact, faster way we deal with data that is known to share a schema across rows. The File Geodatabase (API) reader was an early convert to this new method of handling data. So I'm not surprised you saw what you're seeing. And the .fts does carry by far the bulk of the data, so that is why there is the size difference.
Right now CSV and MapInfo Extended are the other two readers that work in this way and would result in .fts files when written to FFS. An increasing # of transformers are being changed to either work upon or output data using this new technique, but all any user should notice is that things just work faster.
Hi @daleatsafe,
I noted that more and more writers are producing mentioned .fts files.
Do we have some kind of option setting where we can choose to continue producing old .ffs format or readers are moving to .fts automatically?
+59Hi @daleatsafe,
I noted that more and more writers are producing mentioned .fts files.
Do we have some kind of option setting where we can choose to continue producing old .ffs format or readers are moving to .fts automatically?
I don't think other writers should be producing fts files, only the FFS writer. But more and more writers are supporting feature tables (aka bulk mode) and that technique is here to stay.
There is no way to force the FFS writer to write older versions. The version of FFS changes all the time and it would be very hard for us to implement that. However, if the problem is having multiple files, can I suggest you write to a zip file instead? For example, if I write to mydataset.zip, then it will contain both mydataset.ffs and mydataset.fts (and other FFS files, of which there are a few, such as frs for raster).
+6I don't think other writers should be producing fts files, only the FFS writer. But more and more writers are supporting feature tables (aka bulk mode) and that technique is here to stay.
There is no way to force the FFS writer to write older versions. The version of FFS changes all the time and it would be very hard for us to implement that. However, if the problem is having multiple files, can I suggest you write to a zip file instead? For example, if I write to mydataset.zip, then it will contain both mydataset.ffs and mydataset.fts (and other FFS files, of which there are a few, such as frs for raster).
Hi @mark2atsafe,
yes, indeed it is FFS writer. I didn't understood that fts files are result of new bulk mode approach, but now it's clear. Having multiple files is no issues. I am ready to sacrifice everything for best performance :)
