Question

Unable to convert value taken from Z_ORIGIN keyword to a float data type

  • 14 January 2020
  • 9 replies
  • 21 views

Hello,

I am writing to ESRI geodatabase that uses MS SQL. Every time I get "Unable to convert value taken from Z_ORIGIN keyword to a float data type".

 

So far i have:

  • Used a 2dforcer,
  • changed the "z scale and z origin" to 0 or 0.00000
  • under table creation parameters set "Contains Z Values" to No (also set to yes, and blank on other trys)
  • Recreated the writers
  • Set the writer geometry to table, not a point file.

Nothing has worked. I am under the assumption that the writer is passing a "Null" value to the writer which in turn says that "null" cant be a float value.

Finally I have looked at the other posts on this and nothing has helped. Any suggestions?

 

Just to update, I used a vertex creator to make new geometry, and still didn't work, but i can insert all of this into a file geodatabase and then import that to my enterprise database. If anyone has any help please post it, this issue doesn't have a good answer on the forms yet.


9 replies

Badge +2

Hi @freegnome,

Sorry to hear that you are running into issues. It looks like this has been reported and filed as an issue (FMEENGINE-61075). Are you using File Geodatabase or an SDE?

Aside from what you have tried above, another possible workaround is to try the following if you are using SDE is to set the z scale and z origin in the writer parameters rather than in the writer feature type:

  • Set the Contains Z Values parameter to auto detect, Z origin to 0, and Z Scales to 100 in the Writer parameters (via the Navigator window).

Hope that helps while we look into this issue.

Hi @chrisatsafe,

Thanks for the follow up. I am using a SDE database, I just mentioned the file geodatabase because it is odd that it worked and for the moment I can write to that then export/import to the SDE. I will let you know if changing writer parameters resolves the issue.

Badge +11

Hi @freegnome,

Sorry to hear that you are running into issues. It looks like this has been reported and filed as an issue (FMEENGINE-61075). Are you using File Geodatabase or an SDE?

Aside from what you have tried above, another possible workaround is to try the following if you are using SDE is to set the z scale and z origin in the writer parameters rather than in the writer feature type:

  • Set the Contains Z Values parameter to auto detect, Z origin to 0, and Z Scales to 100 in the Writer parameters (via the Navigator window).

Hope that helps while we look into this issue.

I was notified by another user that this resolved their issue. However, I only know of 2 reports of this. If you are seeing this issue, please let us know so we can get it fixed and into the product.

@freegnome Did @chrisatsafe suggest help you as well?

Badge

I was notified by another user that this resolved their issue. However, I only know of 2 reports of this. If you are seeing this issue, please let us know so we can get it fixed and into the product.

@freegnome Did @chrisatsafe suggest help you as well?

Thank you both for this - between this answer and setting the Python version we were able to get things working. The errors that were presented did not indicate the Python issue, and it was difficult to track this work-around down.

@chrisatsafe @steveatsafe

I had this error - it was driving me nuts.

I had my workbench working just fine to write to a file geodatabase, but when I tried to write the same feature class to SDE, the Z_ORIGIN problems appeared, no amount of fiddling with settings, or adding 2D-Forcer could get round the issue. Eventually I managed to get it to go away by adding a new Writer and writing the SDE feature class to a differently-named dataset.

So for me at least the issue seems to be when you have 2 feature classes with the same name - one being written to a file geodatabase and one to a SDE database. Add a new writer to a different name for the feature class seemed to fix it. Happy to share my workbench if it is any help to you.

Badge +1

Hi @freegnome,

Sorry to hear that you are running into issues. It looks like this has been reported and filed as an issue (FMEENGINE-61075). Are you using File Geodatabase or an SDE?

Aside from what you have tried above, another possible workaround is to try the following if you are using SDE is to set the z scale and z origin in the writer parameters rather than in the writer feature type:

  • Set the Contains Z Values parameter to auto detect, Z origin to 0, and Z Scales to 100 in the Writer parameters (via the Navigator window).

Hope that helps while we look into this issue.

We just had this issue using Geodatabase writer in FME(R) 2020.0.0.1 (20200316 - Build 20202 - WIN64). I'm not sure why it isn't happening in more of our Geodatabase writers but glad to have temp fix for it.

Badge

I was notified by another user that this resolved their issue. However, I only know of 2 reports of this. If you are seeing this issue, please let us know so we can get it fixed and into the product.

@freegnome Did @chrisatsafe suggest help you as well?

I too now am having this issue with writing to SDE with this error message in one of my workspaces.

What is curious is in my instance I am attempting to add records to an existing a SDE table (no geometry), so Z_ORIGIN shouldn't even be an issue. This is happening in FME 2018, 2019.

I have deleted the writer and re-imported the feature type...

After deleting the writer and again adding a new writer and manually created a new feature type and replicated the attributes...

All the while in each case, making sure the table parameters are set as in the screenshot in the answer and still no luck.

I cannot rename the table as it participates in several relationship classes and has been published out to feature services actively in place on several web maps and web applications.

There was mention of some settings for python, but I did not see details in the post for how that was resolved. @steveatsafe or @phoeffler- Could those details be shared?

Badge

I too now am having this issue with writing to SDE with this error message in one of my workspaces.

What is curious is in my instance I am attempting to add records to an existing a SDE table (no geometry), so Z_ORIGIN shouldn't even be an issue. This is happening in FME 2018, 2019.

I have deleted the writer and re-imported the feature type...

After deleting the writer and again adding a new writer and manually created a new feature type and replicated the attributes...

All the while in each case, making sure the table parameters are set as in the screenshot in the answer and still no luck.

I cannot rename the table as it participates in several relationship classes and has been published out to feature services actively in place on several web maps and web applications.

There was mention of some settings for python, but I did not see details in the post for how that was resolved. @steveatsafe or @phoeffler- Could those details be shared?

@neilmyoung, the first thing we needed to do was set the Python Interpreter in the workspace - the default can also be set in FME Desktop/Workbench if it turns out that it's not what you need it to be, and that can save some trouble in the future. It's described a bit at https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_Workbench/Workbench/Startup_and_Shutdown_Python_Scripts.htm under Dependencies, with a couple links, and likely elsewhere. In my case it was initially set to use a version of Python that was newer than the one that was packaged with the version of ArcGIS Pro that I had installed at the time. In another case I tried a few of these options until my workspace worked as expected.

With the issue I was having that parameter was set correctly and then I needed to adjust the writer parameters for Z values as described above. Hope you get it working soon, or I find that the live chat on these pages is generally very helpful and resposnive!

I had this issue today and customer support solved it for me by changing the SDE Writer Table Parameters from "Contains Z Values = No" to "auto-detect" then z origin=0 and z scale=100 (even though the data has no z values).

Reply