I am constructing a workspace that builds a file geodatabase from a schema specified in Excel. Each worksheet row defines an attribute and its feature class and feature dataset hierarchy (and domain, if any, but that will be for another day). The schema has feature classes mostly nested in feature datasets but some are root level. For testing, I have extracted a small sample of the schema, representing thirteen combinations of feature dataset and feature class with one feature class at root level. Now, after Excel file reading and subsequent processing, near the end of the workflow the attribute records go through an Aggregator transformer, which creates the attribute{} list attribute. The result is thirteen schema features. Schema features exiting from the Aggregator have no geometry, of course, and consequently have fme_type=fme_no_geom and fme_geometry=fme_undefined. I created and set the following attributes on each schema feature to hold the values that I want to specify as the geometry: _fme_geom_val and _fme_type_val. So, finally, my question: how exactly do I go about specifying the geometry of each schema feature? I have read many times through the Dynamic Workflow tutorials and read all sorts of questions and answers in the Community, but I am still quite confused. The most I have gathered is that I somehow have to create and use an fme_geometry{} list attribute to define the geometry. Descriptions of this attribute vary from source to source, and none actually demonstrates the construction and use of this list attribute. I have tried lots of things, but I cannot figure it out. Here is a screenshot of the Feature Information for one of my schema features:
I did, by the way, try the logical but very newbie solution of simply setting fme_type and fme_geometry format attributes to the values I want, but that didn't work. Any help with this sticky situation would be greatly appreciated. (I suspect also that simply setting geodb_feature_dataset to the proper value isn't going to work either, so any pointers on specifying feature dataset would also be appreciated.)
@tcrossman You do use the fme_geometry{}, for example:
fme_geometry{0} fme_point
A good way to see what you needon the schema feature is to use the FeatureReader to point at a Geodatabase and inspect the <Schema> output.
Before you go too far down this path, I don't think these dynamic schema workflows do not support the creation of domains or subtypes.
@tcrossman You do use the fme_geometry{}, for example:
fme_geometry{0} fme_point
A good way to see what you needon the schema feature is to use the FeatureReader to point at a Geodatabase and inspect the <Schema> output.
Before you go too far down this path, I don't think these dynamic schema workflows do not support the creation of domains or subtypes.
@markatsafe -- So, I did as you suggested and put a GDB through a FeatureReader and looked at the <Schema> port output. What I see is an fme_geometry{0} list attribute. What confuses me most is the the case of polygon feature classes, though. In that case, fme_geometry{0}=fme_area, which is normally an fme_type enumeration value, not an fme_geometry value. Further, there is no attribute with a value of fme_polygon, and fme_geometry=fme_undefined. If I write a schema feature like this to a GDB, how does the writer know that the geometry type should be polygon and not fme_donut or fme_aggregate? There are no data features involved here, only schema features.
@markatsafe -- So, I did as you suggested and put a GDB through a FeatureReader and looked at the <Schema> port output. What I see is an fme_geometry{0} list attribute. What confuses me most is the the case of polygon feature classes, though. In that case, fme_geometry{0}=fme_area, which is normally an fme_type enumeration value, not an fme_geometry value. Further, there is no attribute with a value of fme_polygon, and fme_geometry=fme_undefined. If I write a schema feature like this to a GDB, how does the writer know that the geometry type should be polygon and not fme_donut or fme_aggregate? There are no data features involved here, only schema features.
UPDATE: OK. Now I get it. The fme_geometry{} list attribute "stores all the supported geometries for the feature type defined in 'fme_feature_type_name' attribute" [https://docs.safe.com/fme/html/FME_Desktop_Documentation/FME_ReadersWriters/schema/Feature_Representation.htm?Highlight=fme_geometry]. Essentially, fme_geometry{0}=fme_area is code for "geometry could be any of fme_polygon, fme_donut, or fme_aggregate." A bit opaque but certainly slick.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.