Question

Empty attribute after GDB conversion to Postgis

V
Badge

HI,

I'm converting geodatabase GDB files to PostGIS. The table conversion works well but some of the attributes are empty after the conversion (only 5 attributes over 200 in 7 differents tables).

The five attributes don't have the same types.

Does anyone knows where it could come from?

20 replies

redgeographics
Rank
Userlevel 5
Badge +25
Could you elaborate a bit more please? Are the attribute names exactly the same in the geodatabase and PostGIS (attribute names are case sensitive in FME)

 

 

V
Badge
Yes they are, I'm not changing their names. And if it was because of their names, all the attributes would be empty after the transfer.

 

 

For example, in this table, all the attribute except SUBART are converted well

 

 

redgeographics
Rank
Userlevel 5
Badge +25
Yes they are, I'm not changing their names. And if it was because of their names, all the attributes would be empty after the transfer.

 

 

For example, in this table, all the attribute except SUBART are converted well

 

 

Okay, that's odd. I assume you used the Generate Workspace option to set this up, in that case FME will do its best to set the data types correctly as well, but could you doublecheck that to be sure?

 

 

ngoorman
Badge +2

Are you sure that these attributes actually have values in your input data? If they do, could it be that they are too long to fit the output field, and are left out as a result?

takashi
Rank
Userlevel 2
Badge +17
I'd like to know what kind of values the 'SUBART' attribute of the source GDB table contains.

 

V
Badge

Indeed, I used the "generate workspace" option.

The source attribute 'SUBART' is of type text and the output of type Varchar. What is strange is that the attribute 'ART' has the same source and output type and is transfering without problem.

No the attribute does have values! And yes sometimes they were too long so I used the transformer AttributeValueMapper and it worked!

david_r
Rank
Userlevel 4

The first thing to do would be to fine comb the log for any warnings. Ctrl-F on "SUBART" might be a good idea.

V
Badge

Hi David,

I just did but didn't find anything about subart in the log

And I have 0 warnings

 

david_r
Rank
Userlevel 4

Hi David,

I just did but didn't find anything about subart in the log

And I have 0 warnings

 

I'm a bit surprised that SUBART is type text, according to my knowledge of Geonis it should be a long integer ;-) Can you post a print screen here of the feature class field definitions, as well as some of the contents of the feature class?
V
Badge
I'm a bit surprised that SUBART is type text, according to my knowledge of Geonis it should be a long integer ;-) Can you post a print screen here of the feature class field definitions, as well as some of the contents of the feature class?

You are right, in Geonis it is a 'Long Integer' but FME takes it with the type 'text', that could be the problem?

 

 

Here one of feature:

 

 

 

 

 

 

 

V
Badge

You are right, in Geonis it is a 'Long Integer' but FME takes it with the type 'text', that could be the problem?

 

 

Here one of feature:

 

 

 

 

 

 

 

And the feature type in Geonis

 

 

david_r
Rank
Userlevel 4
And the feature type in Geonis

 

 

This could be related to something with subtypes and domains.

 

If I'm not mistaken ART is a subtype, but I'm not sure if SUBART has been defined with a domain.

 

Try inserting a breakpoint just before the writer and see what the value for SUBART is really like when it hits the writer.

 

 

 

V
Badge
And the feature type in Geonis

 

 

I just did and it has no values, it is already null. So the problem could come from the writer?

 

 

No subart hasn't been defined with a domain.

 

 

V
Badge
I just did and it has no values, it is already null. So the problem could come from the writer?

 

 

No subart hasn't been defined with a domain.

 

 

Sorry I said wrong, SUBART does have a domain

 

 

david_r
Rank
Userlevel 4

I recommend you re-create the reader. In my opinion the SUBART attribute should be of type integer. This is what is looks like when I try to recreate:

Make sure you don't check "Resolve domains" when you create the reader:

V
Badge

I recommend you re-create the reader. In my opinion the SUBART attribute should be of type integer. This is what is looks like when I try to recreate:

Make sure you don't check "Resolve domains" when you create the reader:

But how do you create a reader that way? I don't have the same interface when I create an ESRI reader (maybe I have an older version of FME?)

 

david_r
Rank
Userlevel 4
But how do you create a reader that way? I don't have the same interface when I create an ESRI reader (maybe I have an older version of FME?)

 

Click on Parameters when you add the reader:

 

 

 

V
Badge
But how do you create a reader that way? I don't have the same interface when I create an ESRI reader (maybe I have an older version of FME?)

 

Ok I see it now, I was using the reader format "File Geodatabase API" instead of "File Geodatabase ArcObjects".

 

 

So now it is working!! Thanks a lot David

 

 

david_r
Rank
Userlevel 4
Ok I see it now, I was using the reader format "File Geodatabase API" instead of "File Geodatabase ArcObjects".

 

 

So now it is working!! Thanks a lot David

 

 

I suspect the API reader isn't a very good choice for Geonis databases, they usually have a lot of functionality in them necessitates the ArcObjects reader.

 

 

Great to hear that it works!

 

tim_wood
Rank
Badge +7

If you tick the "Resolve Domains" option, you might think that you don't need to expose the original field in the Reader. But you do! If you un-tick the original field (e.g. un-tick "MyField" and leave only "MyField_resolved" ticked), then you will encounter problems when you try to work with the resolved field. I presume there is some sort of relationship between the two versions of the field that gets broken if both are not exposed.

Reply


Community Stats

28,711
Posts
109,487
Replies
36,559
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.