Skip to main content
Question

output folder name from input file using python scripted paramter

arthy
Contributor
Forum|alt.badge.img+8
  • arthyContributor
  • Contributor

Hi,

I would like to create an output folder based on the input file.

I created a user variable <output_folder> and I'm trying to determine the value  using a python script.

Below is the error that I'm getting using this workspace 

INCLUDE -- failed to evaluate Python script `def ParamFunc():

  import fmeobject

  def output_folder(feature):

  feature = FME_MacroValues['featuretypes']

  string='C:\Users\Administrateur\Documents\oracle_spatial\tmp'

  if feature[10:]=='roads'

     output_folder=string+'\shape'

  else

     output_folder=string+'\mapinfo'

  return str(output_folder)

value = ParamFunc()

macroName = 'output_folder'

if value == None:

  return { macroName : '' }

else:

  return { macroName : str(value) }

'

Program Terminating




Translation FAILED.




  File "<string>", line 5

    feature = FME_MacroValues['featuretypes']

          ^

IndentationError: expected an indented block

Thanks

11 replies

itay
Supporter
Forum|alt.badge.img+17
  • itaySupporter
  • Supporter
  • October 28, 2016

Have you tried using the parameter value in a writer fan out?

takashi
Influencer
  • takashiInfluencer
  • October 28, 2016

The error message IndentationError: expected an indented block indicates that a code block (the definition of a function called output_folder in this script) doesn't have appropriate indentations. In Python scripts, indentations have to be inserted with strictly conforming to Python syntax specifications.

That is the direct reason for the error, but it doesn't seem to be necessary to define the function in this case. What do you intend to perform with this line?

def output_folder(feature):
david_r
Evangelist
  • david_rEvangelist
  • October 28, 2016

Agree with Takashi, try removing line 5:

def output_folder(feature):
arthy
Contributor
Forum|alt.badge.img+8
  • arthyContributor
  • Author
  • Contributor
  • October 28, 2016

I remove the line "def output_folder" as suggested by @takashi and @david_r but it did not fixed the issue.

 

 

The problem is that featuretype is a list of tables read from another oracle table. I was first thinking of creating another column in the table MYTABLESLISTV that will contain the output folder for each oracle spatial object processed. Because I wasn't able do to that, I tried to write the above script.

 

 

Any thoughts?
takashi
Influencer
  • takashiInfluencer
  • October 29, 2016
arthy wrote:

I remove the line "def output_folder" as suggested by @takashi and @david_r but it did not fixed the issue.

 

 

The problem is that featuretype is a list of tables read from another oracle table. I was first thinking of creating another column in the table MYTABLESLISTV that will contain the output folder for each oracle spatial object processed. Because I wasn't able do to that, I tried to write the above script.

 

 

Any thoughts?
I noticed that the first line "import fmeobject" also could cause a syntax error, since the module name fmeobject is wrong. If you needed to use FME Objects Python API in a script, the module name should be fmeobjects, but you can remove the import statement in this case, because you don't use any API method.

 

That aside, from the script you have posted, it is supposed that you are going to perform this processing.

 

  1. Retrieve the value (a character string) of a user parameter called "featuretypes" which is defined before this scripted parameter, and save it as a Python variable called "feature".
  2. If the substring (starting at the position of index 10 and ending at the last) of "feature" is equal to "road", assign string+'\\shape' to "outptut_feature". Otherwise assign string+'\\mapinfo' to "output_feature".
  3. Return the value of "output_feature" as the parameter value.
Is it the processing that you actually want to achieve? If not, what do you want to achieve?

 

arthy
Contributor
Forum|alt.badge.img+8
  • arthyContributor
  • Author
  • Contributor
  • October 29, 2016
takashi wrote:
I noticed that the first line "import fmeobject" also could cause a syntax error, since the module name fmeobject is wrong. If you needed to use FME Objects Python API in a script, the module name should be fmeobjects, but you can remove the import statement in this case, because you don't use any API method.

 

That aside, from the script you have posted, it is supposed that you are going to perform this processing.

 

  1. Retrieve the value (a character string) of a user parameter called "featuretypes" which is defined before this scripted parameter, and save it as a Python variable called "feature".
  2. If the substring (starting at the position of index 10 and ending at the last) of "feature" is equal to "road", assign string+'\\shape' to "outptut_feature". Otherwise assign string+'\\mapinfo' to "output_feature".
  3. Return the value of "output_feature" as the parameter value.
Is it the processing that you actually want to achieve? If not, what do you want to achieve?

 

@takashi

 

Yes this what I want to do, and you are rigth There was a typo on the spelling of "fmeobject".

 

What you are saying will work is featuretype was constituted by only a table but in my case it has several tables.

 

Please could you have a look on the workspace that I uploaded, edit it and return it to me so I can see eactly what I'm doing wrong?
takashi
Influencer
  • takashiInfluencer
  • October 30, 2016
arthy wrote:

I remove the line "def output_folder" as suggested by @takashi and @david_r but it did not fixed the issue.

 

 

The problem is that featuretype is a list of tables read from another oracle table. I was first thinking of creating another column in the table MYTABLESLISTV that will contain the output folder for each oracle spatial object processed. Because I wasn't able do to that, I tried to write the above script.

 

 

Any thoughts?
1. You cannot access the user parameter named "featuretypes" now through the FME_MacroValues dictionary, since the "featuretypes" is not defined before this parameter now. At run-time, FME configures user parameters in the order that you defined in the Navigator of Workbench, so if you want to access "featuretypes" in the script for "output_folder", you should move the "output_folder" to lower position than the "featuretypes", like this screenshot.

 

 

2. I looked at the "featuretypes" script too, and guess that you intended to create a string consisting of one or more table names separated by spaces through the "featuretypes" scripted parameter. e.g. "table1 table2 table3". On the other hand, the "output_folder" script just determines if the substring of "feature" is equal to "road". If the result was unexpected, there is a logical bug even if there was no syntax error. What value should the script return if "feature" consists of two or more table names?
takashi
Influencer
  • takashiInfluencer
  • October 30, 2016
arthy wrote:

I remove the line "def output_folder" as suggested by @takashi and @david_r but it did not fixed the issue.

 

 

The problem is that featuretype is a list of tables read from another oracle table. I was first thinking of creating another column in the table MYTABLESLISTV that will contain the output folder for each oracle spatial object processed. Because I wasn't able do to that, I tried to write the above script.

 

 

Any thoughts?
Perhaps do you need to determine the output folder for each feature according to the source table name? If so, the Fanout Dataset option might help you, rather than scripted parameters. e.g. with this setting, the features from tables whose name ends with "roads" will be written into "shape" folder and others will be written into "mapinfo" folder.

 

 

arthy
Contributor
Forum|alt.badge.img+8
  • arthyContributor
  • Author
  • Contributor
  • October 30, 2016
takashi wrote:
1. You cannot access the user parameter named "featuretypes" now through the FME_MacroValues dictionary, since the "featuretypes" is not defined before this parameter now. At run-time, FME configures user parameters in the order that you defined in the Navigator of Workbench, so if you want to access "featuretypes" in the script for "output_folder", you should move the "output_folder" to lower position than the "featuretypes", like this screenshot.

 

 

2. I looked at the "featuretypes" script too, and guess that you intended to create a string consisting of one or more table names separated by spaces through the "featuretypes" scripted parameter. e.g. "table1 table2 table3". On the other hand, the "output_folder" script just determines if the substring of "feature" is equal to "road". If the result was unexpected, there is a logical bug even if there was no syntax error. What value should the script return if "feature" consists of two or more table names?
@takashi ,

 

 

Thank you very much for all your answers.

 

However, I was thinking of using the solution provided by a script instead of fanout.

 

As you mentioned, the scripted parameter feature returned the list of all the tables as a string but what I really wanted is that based on the name of each feature, I would like to have other constraints like a "where clause" and an output folder.

 

 

The fanout option - that you propose below - solves the issue of having an output folder for each feature. How can I solve the issue of the where_clause?

 

 

Keeping in mind that each feature is an oracle spatial object, let's assume that the feature that end with roads has a column entitled 'state' with the values 'paved' or 'unpaved' and I would like to extract only the road which a status equal to 'paved,.

 

 

Thanks

 

takashi
Influencer
  • takashiInfluencer
  • October 31, 2016

As an easy solution, I think you can use a Tester transformer to filter out unnecessary features - i.e. "unpaved" road features. Since the road features have "state" attribute storing "paved" or "unpaved", the condition for required features would be: the source table name does not end with "roads" OR the value of "state" is equal to "paved".

Alternatively, as a little bit advanced solution, the SQLCreator/Executor transformer might be helpful.
  1. SQLCreator: Retrieve the table names from the [TableName] table.
  2. Tester: Branch the data flow into two streams according to whether the table name ends with "roads". Send the Passed features to a SQLExecutor (1), send the Failed features to another SQLExecutor (2).
  3. SQLExecutor (1) -> writer feature type [shape]: Execute a SQL statement containing the where clause (state='paved') to read road features from "***roads" tables, and then write them into "shape" folder.
  4. SQLExecutor (2) -> writer feature type [mapinfo]: Execute a SQL statement to read non-road features from other tables, and then write them into "mapinfo" folder.

SQLExecutor Parameters

  • Combine Attributes: Keep Initiator Attributes if Conflict
  • Combine Geometry: Result Geometry Only

In this case, you can add an Oracle Spatial reader as a Workspace Resource in order to derive the destination schema from the existing database. And source table name - which will be used as the schema definition name and the destination feature type name in the dynamic writer feature types, can be propagated from the initiator feature for each SQLExecutor to the result features.

Regarding Workspace Resources, see these articles to learn more.

takashi
Influencer
  • takashiInfluencer
  • October 31, 2016
takashi wrote:

As an easy solution, I think you can use a Tester transformer to filter out unnecessary features - i.e. "unpaved" road features. Since the road features have "state" attribute storing "paved" or "unpaved", the condition for required features would be: the source table name does not end with "roads" OR the value of "state" is equal to "paved".

Alternatively, as a little bit advanced solution, the SQLCreator/Executor transformer might be helpful.
  1. SQLCreator: Retrieve the table names from the [TableName] table.
  2. Tester: Branch the data flow into two streams according to whether the table name ends with "roads". Send the Passed features to a SQLExecutor (1), send the Failed features to another SQLExecutor (2).
  3. SQLExecutor (1) -> writer feature type [shape]: Execute a SQL statement containing the where clause (state='paved') to read road features from "***roads" tables, and then write them into "shape" folder.
  4. SQLExecutor (2) -> writer feature type [mapinfo]: Execute a SQL statement to read non-road features from other tables, and then write them into "mapinfo" folder.

SQLExecutor Parameters

  • Combine Attributes: Keep Initiator Attributes if Conflict
  • Combine Geometry: Result Geometry Only

In this case, you can add an Oracle Spatial reader as a Workspace Resource in order to derive the destination schema from the existing database. And source table name - which will be used as the schema definition name and the destination feature type name in the dynamic writer feature types, can be propagated from the initiator feature for each SQLExecutor to the result features.

Regarding Workspace Resources, see these articles to learn more.

The FeatureReader could also be effective and easier. e.g.

 

 

or

 

 

If you use the FeatureReader, it's not necessary to add the Workspace Resource (Oracle Spatial reader) to the workspace, since the destination schema can be derived from the schema feature read by the FeatureReader.

 

Anyway, in my personal view, use of scripted parameters does not seem to be the best practice in your case.

 

Reply


Helpful Members This Week

Community Stats

31,134
Posts
118,036
Replies
38,876
Members

Latest FME

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie 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.