Skip to main content
  • EN
  • Home
  • Forums
  • FME Form
  • General
  • Esri Mobile Geodatabase Writer Feature Type Definition 'main.BridgeAnno' was requested, but not defined. What is going on?

I ran into this same error when building this dynamic workspace a year ago and writing to existing, unpopulated geodatabase (GDB) in File GDB format. The solution was to add my template File GDBs to the workspace as resources in the Schema Sources control in the FeatureWriter parameters. I have now modified the workspace to write optionally to Mobile GDB format through an additional FeatureWriter set for Mobile GDB format. I have the FeatureWriter set up identically to the File GDB version (which works fine), but I am getting that "Feature Type Definition 'ftype_name' was requested, but not defined" error. The following screenshot shows the parameter setup for the Mobile GDB FeatureWriter (FeatureWriter_8), and the Feature Information for the first feature to be written as it comes out of AttributeCreator_38. I am baffled. The Schema Sources items are correct; the fme_feature_type, fme_feature_type_name, and geodb_feature_dataset format attribute values are correct. The _out_dataset attribute value, which points to the target GDB for the feature, is also correct. I have checked it. The schema in the target GDB is correct, and the schema in the template GDBs (which provide the schema source) are correct. As I said, the File GDB FeatureWriter works fine, and the the new Mobile GDB FeatureWriter doesn't. I just can't see the problem. any help is appreciated greatly.

imageADDITIONAL INFO (10/3/2023): Just found that the BridgeAnno feature class (file GDB) being translated (to mobile GDB) has a 1:3654 anno ref scale, while the destination has a 1:500 anno ref scale. Might the anno ref scale actually be taken into account as part of the feature type schema definition that is being retrieved from the template GDB in the Workspace Resources? (Again, writing to File GDB works, though, so I don't know why the annotation would be treated differently when writing to mobile GDB.)

ADDITIONAL INFO #2 (10/3/2023): I just tested the anno ref scale idea above by just recalculating geodb_text_ref_scale to 500 and then writing out to the mobile GDB: no effect, same error.

ADDITIONAL INFO #3 (10/4/2023): I tried a classic Writer instead of a FeatureWriter and got the same error; however, the logged messages are slightly different. The below screenshot appears to indicate that the reader in the workspace resources is extracting the schema from the incorrect source. The reader is seeing feature classes like "UtilityTunnel" and "UtilityPoint," which are clearly NOT mobile geodatabase feature classes but file geodatabase feature classes. I did try removing the worksapce resources and re-adding them but got the same error.

image

@tcrossman​ Hi there, it sounds like this issue will require some in depth troubleshooting. We will likely need to see full translation logs, your workspace, and possibly some other system details in order to get a fuller picture of the error. Would you be able to submit a support request to us?

@tcrossman​ Hi there, it sounds like this issue will require some in depth troubleshooting. We will likely need to see full translation logs, your workspace, and possibly some other system details in order to get a fuller picture of the error. Would you be able to submit a support request to us?

Thank you, @natalieatsafe​. I do so wish that I could send workspaces, logs, and data to you for troubleshooting, but my company considers that information proprietary. The policy is that we cannot share this information. Unfortunately, that means that I will have to completely rethink our strategy for translating these data, as Mobile GDBs are central to it. Punting ...

I just ran into a similar problem with FME 2023 and different behaviour of dynamic FileGeoDB writing vs. dynamic MobileGeoDB writing. In my case I have attribute names which are longer than 64 char. In both cases I use the same fme schema definition csv.

In FGDB writing the log contains 1 line which says xxxx attributes were truncated, which means their names were shortened and everything was written fine.

In MobileGDB writing it gives me errors for each shortened attribute in the sense that no correct definition was found for the attribute.

I will fix this by shortening the attributes myself and my understanding is, that the FileGDB writer recieved more effort from the developer, so it can handle shortened attributes even if the schema-definition needs to be shortened too.

In MobileGDB case the attributes are shortened without fixing the related schemadefinition.

EDIT: Additionally FME 2023 does the shortening of attributes to 64char which is OK for FGDB but too long for MobileGDB. MobileGeoDB has an attributename limit of 31 chars.

Reply


Community Stats

30,159
Posts
114,480
Replies
37,806
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.