When the result of a translation is a lzw compressed TIFF, the zip compression is useless, it only takes a long time to complete if the file is big and the resulting file has the same size as the original.
Currently this is not possible. It is an interesting request though and I have filed an enhancement request to evaluate adding this feature to the product.
On Monday, May 7, 2012 12:38:54 PM UTC-7, Mats H wrote:
> Hi,
> When the result of a translation is a lzw compressed TIFF, the zip > compression is useless, it only takes a long time to complete if the file > is big and the resulting file has the same size as the original.
On Monday, May 7, 2012 12:38:54 PM UTC-7, Mats H wrote:
> Hi,
> When the result of a translation is a lzw compressed TIFF, the zip > compression is useless, it only takes a long time to complete if the file > is big and the resulting file has the same size as the original.
Could you expand that request to include the ability to turn off the
zipping on specific data download jobs (maybe by using a service
parameter or such).
I have a many requirements to be able to allow a download of
single file translation results, like TXT, PDF, TIF, etc.
The authors/users would have to understand that with zipping
switched off on a translation that results in multi-files, somethings
going to blow up.
We have a 2011 server that we can’t upgrade because we will
lose that download feature, that I was able to incorporate using
a customized POST_COMMAND in the fmeEngineConfig file.
Couldn't you just use the Data Streaming service? That streams back individual files and if the workspace result contains more than one file the service will automatically zip the results for you.
The POST_COMMAND was omitted in error. It will be back again in FME Server SP3 which is out soon.
On Tuesday, May 8, 2012 1:59:27 PM UTC-7, Mike B wrote:
> Hi Stewart, (sorry to butt in Mats)
> Could you expand that request to include the ability to turn off the > zipping on specific data download jobs (maybe by using a service > parameter or such).
> I have a many requirements to be able to allow a download of > single file translation results, like TXT, PDF, TIF, etc. > The authors/users would have to understand that with zipping > switched off on a translation that results in multi-files, somethings > going to blow up.
> We have a 2011 server that we can’t upgrade because we will > lose that download feature, that I was able to incorporate using > a customized POST_COMMAND in the fmeEngineConfig file.
I'd second the request to be able to turn off the zip process for specific requests. The data streaming service doesn't provide the same features as the data download service. I'm using the data download via a custom front end web application and need to be able to handle the various error conditions that may arise and provide a reasonable response back to the end user. The data streaming service does not seem to provide any mechanism to do this - it just returns an HTTP error if the request fails for any reason and there's no way of getting at the FME log file or error status. If the data download service could be made to return an unzipped result it would be simple to code the front end to include a link to that result, as well as providing meaningfull feedback to the user on the status of the request. Nic
On Monday, 7 May 2012 13:38:54 UTC-6, Mats H wrote: > Hi,
> When the result of a translation is a lzw compressed TIFF, the zip > compression is useless, it only takes a long time to complete if the file > is big and the resulting file has the same size as the original.
I see where you are coming from now. The lack of an intelligent HTTP response for the data streaming service could be annoying. I have filed an enhancement request (PR38456) and pulled you into the ticketing system.
On Wednesday, May 23, 2012 9:22:06 AM UTC-7, nicr wrote:
> I'd second the request to be able to turn off the zip process for specific > requests. The data streaming service doesn't provide the same features as > the data download service. I'm using the data download via a custom front > end web application and need to be able to handle the various error > conditions that may arise and provide a reasonable response back to the end > user. The data streaming service does not seem to provide any mechanism to > do this - it just returns an HTTP error if the request fails for any reason > and there's no way of getting at the FME log file or error status. If the > data download service could be made to return an unzipped result it would > be simple to code the front end to include a link to that result, as well > as providing meaningfull feedback to the user on the status of the request. > Nic
> On Monday, 7 May 2012 13:38:54 UTC-6, Mats H wrote:
>> Hi,
>> When the result of a translation is a lzw compressed TIFF, the zip >> compression is useless, it only takes a long time to complete if the file >> is big and the resulting file has the same size as the original.
