Skip to main content
  • EN

I am attempting to build schema features, with coded value domains, from a schema specification in Excel and to write them out to geodatabase with a dynamic writer. I am almost there, but I am missing something, and I do not understand the structure and requirements for schema features quite deeply enough to solve the problem. I have read through the set of Dynamic Workflow tutorials and other pages, like Deriving Destination Schema from Schema Feature, but none of them quiiite go far enough to address my situation.

 

As I am building and writing out coded value domains, I am specifying the fme_format_short_name (= GEODATABASE_FILE) attribute on the schema features and including the attribute{}.native_data_type on all attributes in the list, with the value in the required "coded_domain( ... )" in the case of attributes with a domain. I also want to include the attribute alias in the attribute{} list. Finally, I have set fme_geometry{0} accordingly for each schema feature. So, for a schema feature for the AirfieldLight point feature class in the the Airfield feature dataset, I have the following feature type-level attributes:

imageIn the attribute{} list, an attribute without a domain looks like this:

image... and an attribute with a coded domain looks like this:

imageIn the feature type-level attributes, I set fme_type, but letting it keep its internal value of fme_no_geometry doesn't seem to make a difference. The final result is that I am getting no feature classes or domains written out to the geodatabase. If I do not specify fme_schema_handling=schema_only, I do get one (of 13) feature class created correctly, but the schema feature for that feature class then gets added as a feature. The geodatabase write chokes, though, on the second schema feature (though two of its domains are created correctly.) I am just very confused at this point and not having a clue how to proceed. Any help is greatly appreciated.

I also run into the problem with the fme_schema_handling=schema_only using multiple features (with an error that tell you nothing), so I now do that differently in my processes. Yes, irritating but not enough for me to raise it as a case.

 

As for the other things: Your coded_domain syntax appears incorrect. You show as coded_domain(CodeLightingCategory:text

 

but it should be:

coded_domain(CodeLightingCategory:char

 

And also your alias syntax should be (unless they have included it like that in 2022). It is not included in the attribute{} list, so appears as a normal attribute.

<fieldname>_alias

 

e.g lightingCategory_alias = Lighting Category

 

 

 

Cheers,

Todd

 

N.B. If you need an example, send me an email and I can send you an example.

I also run into the problem with the fme_schema_handling=schema_only using multiple features (with an error that tell you nothing), so I now do that differently in my processes. Yes, irritating but not enough for me to raise it as a case.

 

As for the other things: Your coded_domain syntax appears incorrect. You show as coded_domain(CodeLightingCategory:text

 

but it should be:

coded_domain(CodeLightingCategory:char

 

And also your alias syntax should be (unless they have included it like that in 2022). It is not included in the attribute{} list, so appears as a normal attribute.

<fieldname>_alias

 

e.g lightingCategory_alias = Lighting Category

 

 

 

Cheers,

Todd

 

N.B. If you need an example, send me an email and I can send you an example.

Also, personally I don't use the domain creation in FME because I seem to have domains that are constantly being added to, description changed etc which I do not believe FME can alter. If that is likely to be something you face, I would say you are better to build a workspace that incorporates ArcPy into it and can handle any domain situation. We have, and it is great.

 

I also run into the problem with the fme_schema_handling=schema_only using multiple features (with an error that tell you nothing), so I now do that differently in my processes. Yes, irritating but not enough for me to raise it as a case.

 

As for the other things: Your coded_domain syntax appears incorrect. You show as coded_domain(CodeLightingCategory:text

 

but it should be:

coded_domain(CodeLightingCategory:char

 

And also your alias syntax should be (unless they have included it like that in 2022). It is not included in the attribute{} list, so appears as a normal attribute.

<fieldname>_alias

 

e.g lightingCategory_alias = Lighting Category

 

 

 

Cheers,

Todd

 

N.B. If you need an example, send me an email and I can send you an example.

@Todd Davis​ -- Yes, the fme_schema_handling attribute does seems to be a problem. Did you ever find a workaround in FME for the error you were getting?

I also run into the problem with the fme_schema_handling=schema_only using multiple features (with an error that tell you nothing), so I now do that differently in my processes. Yes, irritating but not enough for me to raise it as a case.

 

As for the other things: Your coded_domain syntax appears incorrect. You show as coded_domain(CodeLightingCategory:text

 

but it should be:

coded_domain(CodeLightingCategory:char

 

And also your alias syntax should be (unless they have included it like that in 2022). It is not included in the attribute{} list, so appears as a normal attribute.

<fieldname>_alias

 

e.g lightingCategory_alias = Lighting Category

 

 

 

Cheers,

Todd

 

N.B. If you need an example, send me an email and I can send you an example.

@Todd Davis​ -- Understood about data type and alias attribute name errors I am making. Thank you. The data type issue brings up a question, though: Is there any specific Safe documentation of the Esri "native data types" that FME is expecting? Everywhere I look in Esri documentation has the data type for characters/strings as "text."

Re: Workaround for schema handling. In our main process we pull in arcpy to do a couple of Esri things, so I just use a deletefeatures at that point, but if I was not doing that I would do this...Insert feature and create the schema, and then run a delete operation of the layer by:

 

1) before writing schema layer add an attributecreator and create fme_db_operation = INSERT

2) then create another branch with another attributecreator and create fme_db_operation = DELETE (if you do that in that order the runtime order will be correct otherwise you need to correct in "Set Runtime Connection Order" to make sure the insert works before the delete)

3) Set up feature Operation in the writer to consume fme_db_operation and where clause to be 1=1

4) Maintain the rest of your schema writing setup

 

Below is 1-3 (excluding schema writing setup)

image

As for what FME data types it is expecting, I just have found the domain values from Safe's writeup(s) but I have not found a defined values in the documentation. For standard native_data_type schema stuff, I have just learnt by reading in a layers that already has it using a featurereader and then looking at the schema outputs. But again, like lots of things, the more you do it, the more your own knowledge grows.

As for what FME data types it is expecting, I just have found the domain values from Safe's writeup(s) but I have not found a defined values in the documentation. For standard native_data_type schema stuff, I have just learnt by reading in a layers that already has it using a featurereader and then looking at the schema outputs. But again, like lots of things, the more you do it, the more your own knowledge grows.

@Todd Davis​ -- Thanks for this. You are, of course, correct about gleaning info from a FeatureReader and about learning in general just by doing. I did inspect the schema from a FeatureReader, and I implemented your FME-based workaround above, using the fme_db_operation attribute. Makes perfect sense and should work, but, alas, my workspace is still choking. I will pound on this for a bit more, but I think the continued problems are just screaming for a straightforward arcpy/fmeobjects solution, which I always think of first anyway and am far more experienced with and better at than the minimal-Esri or pure FME solutions my organization normally seeks. I will likely be arguing for some flexibility in this case. Thanks again for all your patience and help.

@Todd Davis​ -- Thanks for this. You are, of course, correct about gleaning info from a FeatureReader and about learning in general just by doing. I did inspect the schema from a FeatureReader, and I implemented your FME-based workaround above, using the fme_db_operation attribute. Makes perfect sense and should work, but, alas, my workspace is still choking. I will pound on this for a bit more, but I think the continued problems are just screaming for a straightforward arcpy/fmeobjects solution, which I always think of first anyway and am far more experienced with and better at than the minimal-Esri or pure FME solutions my organization normally seeks. I will likely be arguing for some flexibility in this case. Thanks again for all your patience and help.

If you want, you could send me the FFS of the feature that sets the schema of a table you are trying to create. I can then have a look and see if I can spot anything that may be causing an issue. You should be able to find my contact details quickly via the internet.

Reply


Community Stats

30,166
Posts
114,516
Replies
37,821
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.