Skip to main content
  • EN

Hi all,

 

We have a FGDB that contains domain values and we are using the FGDB Open API Reader to read in the data.

We have examples where a field has a modeled domain but a value is not a valid coded value. In this situation we are seeing that the value is being read into FME as an empty text string. I am guessing that FME has trying to get the description of the value, and because it does not exist it is returning an empty text string.

I'm just checking to see whether anyone else has seen this and whether this is expected behavior?

We are using FME to validate these values but by bring in a blank it does not really help. We tested using FME 2018.1 and 2020.0.

If we use the arc-object FGDB reader we can resolve the domain and see the bad value. Unfortunately using this reader is not an option due to licensing.

 

Cheers

Adie

I see the same behaviour in FME(R) 2019.2.3.2 (20200320 - Build 19825 - WIN32) but I think it's what i would expect as the FGDB Open API Reader resolves the domains

If a field with a coded domain is coming through as blank then by definition the value is invalid, is it important to know the value if it is wrong?

It's important as well to be able to distinguish between cases where a field contains the value rather than the code

e.g. ArcView v Data

I'd be wary of using the FGDB Open API Reader for any critical validation

Hi @adieporter,

You are correct. The File Geodatabase Open API reader will resolve the domain values, this means that the descriptions are used and not the coded values. You can see more details about domains for this format in the documentation here by expanding the section "The Esri Geodatabase (File Geodb Open API) reader/writer also provide the following capabilities"

Given that the description is used to resolve domains with the Open API format, an invalid domain producing an empty text string makes sense as it does not exist in the domain table.

If you are wanting to extract the coded value to see the bad value, you would need to use the GEODATABASE_FILE format.

There is also this idea that you can vote on to add a resolve domains option to the FGDB Open API format: https://knowledge.safe.com/idea/94707/add-resolve-domains-option-to-file-geodatabase-fgd.html?

 

FME is actually the number one culprit of getting incorrect values into coded domains in my experience, you should have to pass a test before you're allowed to set this parameter to No :-)

Thanks All

That backups what we've found.

I agree with you Liz, especially as in our case we have some fields with domains on them that can be isnullable=true. So distinguishing between valid/invalid is coming down is <empty text string>/<null>.

Andrea may be useful to add to usage notes for format.

Unfortunately we cant use the GEODATABASE_FILE due to licensing restrictions.

Cheers Adrian

On a related note

 

I've noticed that we have some fields with time values stored. When the FGDB Open API Reader reads this data it appends the date 1899-12-30 to the time of, making it a timestamp. When reading the data using GEODATABASE_FILE we just get the time value.

 

Handy to know.

Adie

Thanks All

That backups what we've found.

I agree with you Liz, especially as in our case we have some fields with domains on them that can be isnullable=true. So distinguishing between valid/invalid is coming down is <empty text string>/<null>.

Andrea may be useful to add to usage notes for format.

Unfortunately we cant use the GEODATABASE_FILE due to licensing restrictions.

Cheers Adrian

It's really fun when people have put the text string <Null> in a field alongside genuine null values

Reply


Community Stats

30,351
Posts
115,341
Replies
38,081
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.