Skip to main content
  • EN

This may be due to my inexperience but I have an FME script I have been modifying for a client, no new nodes added, and it throws up an error when the client tries to run it. The script runs with no issue on my own dev environment but when the client runs it using their environment it seems to fail. The error log message is rather confusing to me so I hoped someone here might be able to help point me in the right direction. Unfortunately, I can't access the client's environment so I'm stuck with remote debugging.

The error in question that stops the script is as follows:

2016-09-12 14:55:16| 1.5| 0.0|ERROR |Labeller_TDUCT_start(LabelFactory): The clause 'MINIMUM_LENGTH 0 REJECT_INVALID_GEOM YES' within 'FACTORY_DEF * LabelFactory FACTORY_NAME Labeller_TDUCT_start INPUT FEATURE_TYPE AttributeRounder_OUTPUT PLACEMENT UPPER_RIGHT LABEL_ENDS yes PLACEMENT_DISTANCE 0.0000001 PLACEMENT_SPACING 0 MINIMUM_LENGTH 0 REJECT_INVALID_GEOM YES OUTPUT POINT FEATURE_TYPE Labeller_TDUCT_start_LABEL @GeometryType(fme_text,@EvaluateExpression(FDIV,STRING_ENCODED,<at>Value<openparen>length<closeparen>,Labeller_TDUCT_start),0.000015,@Value(LabelRotation),ENCODED) @RenameAttributes(_label_rotation,LabelRotation) @RenameAttributes(_parallel_rotation,ParallelRotation)' is incorrect. The parameter to MINIMUM_LENGTH must be a constant value, a value-of (&) attribute, or an FME function call
2016-09-12 14:55:16| 1.5| 0.0|ERROR |The clause 'MINIMUM_LENGTH 0 REJECT_INVALID_GEOM YES' within 'FACTORY_DEF * LabelFactory FACTORY_NAME Labeller_TDUCT_start INPUT FEATURE_TYPE AttributeRounder_OUTPUT PLACEMENT UPPER_RIGHT LABEL_ENDS yes PLACEMENT_DISTANCE 0.0000001 PLACEMENT_SPACING 0 MINIMUM_LENGTH 0 REJECT_INVALID_GEOM YES OUTPUT POINT FEATURE_TYPE Labeller_TDUCT_start_LABEL @GeometryType(fme_text,@EvaluateExpression(FDIV,STRING_ENCODED,<at>Value<openparen>length<closeparen>,Labeller_TDUCT_start),0.000015,@Value(LabelRotation),ENCODED) @RenameAttributes(_label_rotation,LabelRotation) @RenameAttributes(_parallel_rotation,ParallelRotation)' is incorrect. The parameter to MINIMUM_LENGTH must be a constant value, a value-of (&) attribute, or an FME function call

looks to me like a minimal requirement is not met (minimum lenght)

looks to me like a minimal requirement is not met (minimum lenght)

I had thought the same thing from the error message, yet the node that is referred to in that message has the following properties when I sent the FME script:

 

 

As far as I can tell they haven't edited anything. This is why I felt the need to ask since the error message doesn't make sense to me.
I had thought the same thing from the error message, yet the node that is referred to in that message has the following properties when I sent the FME script:

 

 

As far as I can tell they haven't edited anything. This is why I felt the need to ask since the error message doesn't make sense to me.
Strange indeed!, I would gather a 0 value to be a constant.....sounds like a support case to me...

 

 

Can you confirm that you and your client are both using the same FME version? Can you specify the build numbers? That way if there is a difference I can check to see if something changed between those two builds. For example, I can see there was a change made in FME build 16422.

 

 

Also, what are the two platforms? Both 32 or 64 bit? If you can paste the headers of each log file it would answer both this and the version questions.

 

Strange indeed!, I would gather a 0 value to be a constant.....sounds like a support case to me...

 

 

If I copy/paste a Labeller into a text editor I see: MINIMUM_LENGTH "0"

 

I'm thinking that without those quotes FME might try to parse the whole thing as "MINIMUM_LENGTH 0 REJECT_INVALID_GEOM" being the name of a single directive. So I'm thinking a quoting error.

 

 

Oh, also, is the workspace being run in the same build it was created in? Or was it created in 2015 but is now being run in 2016? That could be a source of a problem.

 

 

Oh, also, is the workspace being run in the same build it was created in? Or was it created in 2015 but is now being run in 2016? That could be a source of a problem.

 

 

Clients version header:

 

2016-09-12 11:15:04| 0.6| 0.6|INFORM|FME 2016.0.1.2 (20160318 - Build 16178 - WIN32)

 

2016-09-12 11:15:04| 0.6| 0.0|INFORM|FME_HOME is 'C:\\apps\\FME\\'

 

2016-09-12 11:15:04| 0.6| 0.0|INFORM|FME MS SQL Server Edition (node locked-crc)

 

2016-09-12 11:15:04| 0.6| 0.0|INFORM|Serial Number:

 

2016-09-12 11:15:04| 0.6| 0.0|INFORM|Permanent License.2016-09-12 11:15:04| 0.6| 0.0|INFORM|Machine host name is: WVVMWKS26

 

 

My version header:

 

2016-09-12 02:58:33| 0.5| 0.5|INFORM|FME 2016.1.1.0 (20160722 - Build 16609 - WIN32)

 

2016-09-12 02:58:33| 0.5| 0.0|INFORM|FME_HOME is 'C:\\apps\\FME\\'

 

2016-09-12 02:58:33| 0.5| 0.0|INFORM|FME Database Edition (node locked-crc)

 

2016-09-12 02:58:33| 0.5| 0.0|INFORM|Serial Number:

 

2016-09-12 02:58:33| 0.5| 0.0|INFORM|Temporary License: 11 days left.

 

2016-09-12 02:58:33| 0.5| 0.0|INFORM|Machine host name is: WIN-JM8060T7H42

 

 

So it looks like build 16422 is smack in the middle of the two versions. I believe it was created in 2015, I've been modifying it in 2016 and the client has tried it on their copy of 2015 and 2016.

 

 

I will also check if adding quotes allows the script to run on my dev environment.

 

OK, from the log file above I strongly suspect that something was changed for 2016.1.1 and your client's version (2016.0.1) is incompatible.

I can think of a few fixes...

1) The obvious: have your client upgrade to 2016.1.1

2) Almost as obvious: downgrade to 2016.0.1 and recreate the workspace

3) Maybe not obvious: have your client replace that transformer in 2016.0.1.

4) Try the quotes thing, but I'm really not hopeful.

If everything else works then just replacing that transformer in 2016.0.1 should get around that issue. The problem is, how do you know that everything else works?!

I'll check with our developers about compatibility. For example, I understand that anything 2016 is obviously not guaranteed to work in 2015. But should 2016.1.1 workspaces work in 2016.0.1? Which digit of 201a.b.c.d is the point at which we assume compatibility is not guaranteed? I'll try and find out.

But generally, don't create (or edit) a workspace in a newer version and then run it in an older one. It's not good practice and it can cause problems of this type.

OK, from the log file above I strongly suspect that something was changed for 2016.1.1 and your client's version (2016.0.1) is incompatible.

I can think of a few fixes...

1) The obvious: have your client upgrade to 2016.1.1

2) Almost as obvious: downgrade to 2016.0.1 and recreate the workspace

3) Maybe not obvious: have your client replace that transformer in 2016.0.1.

4) Try the quotes thing, but I'm really not hopeful.

If everything else works then just replacing that transformer in 2016.0.1 should get around that issue. The problem is, how do you know that everything else works?!

I'll check with our developers about compatibility. For example, I understand that anything 2016 is obviously not guaranteed to work in 2015. But should 2016.1.1 workspaces work in 2016.0.1? Which digit of 201a.b.c.d is the point at which we assume compatibility is not guaranteed? I'll try and find out.

But generally, don't create (or edit) a workspace in a newer version and then run it in an older one. It's not good practice and it can cause problems of this type.

The consensus of our "build and release" team is that the second digit is a "major" version change (eg 2016.0 to 2016.1) and that is definitely not guaranteed in the same way as 2015 to 2016 wouldn't be.

 

The middle digit is a scheduled release but should only be fixes, so you should be able to switch between versions with a differing digit, provided you aren't using the functionality that needed to be fixed.

 

The final digit is usually only for emergency hotfixes, so it's unlikely to be an issue unless you happen to be unlucky and are using the particular function that needed a hotfix (but if you did it likely wouldn't work at all in the older build anyway).

 

The consensus of our "build and release" team is that the second digit is a "major" version change (eg 2016.0 to 2016.1) and that is definitely not guaranteed in the same way as 2015 to 2016 wouldn't be.

 

The middle digit is a scheduled release but should only be fixes, so you should be able to switch between versions with a differing digit, provided you aren't using the functionality that needed to be fixed.

 

The final digit is usually only for emergency hotfixes, so it's unlikely to be an issue unless you happen to be unlucky and are using the particular function that needed a hotfix (but if you did it likely wouldn't work at all in the older build anyway).

 

 

Thanks Mark, I'll mark this as answered as irrespective of the final resolution I think the version incompatibility is the source of my issue. Good to know that in the a.b.c.d version numbering any change in "a" and "b" will likely cause issues.

Reply


Community Stats

30,123
Posts
114,333
Replies
37,752
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.