We're revisiting the SchemaMapper over here, to see how we might be able to shave down it's long tooth. In digging into this transformer, it's evident there are a lot of questions about what exactly a new-n-improved SchemaMapper looks like. We're beginning to look at supporting simple functions and conditionals but still need to investigate/verify the following:
Which functions and conditionals would be used? What would be helpful?
Would these statements be specified in the external lookup table, the configuration fields, or apply to the incoming feature values themselves?
What kind of UI help would the author expect for writing these statements?
Any and all feedback welcomed on these above points, if you would be game to share! I would greatly appreciate it!
My use case involves the conversion of one complex dataset to the another complex dataset. The way our workbench is structured now, we have a series of SchemaMappers that defines the feature type and attribute values. This works well for features that map directly or have one-to-one mapping relationships. For example, FeatureType 'A' will always map to FeatureType '1', and the attributes from FeatureType 'A' have a direct equivalent on FeatureType '1'. These are easily handled by the SchemaMapper.
The situations where it isn't useful is when the attribute mapping is conditional on the input attributes. Some of our conversion rules say "If attribute 'B' contains 'house', make attribute '3' = 'residential'". Or it could be something along the lines of "If the value in attribute 'B' is in the range 0-180, set FeatureType to 'beacon'". For these situations, we are currently mapping these with other processes after the SchemaMappers, which significantly add to the complexity of the workbench (nearing 30mb).
Honestly, I could likely use all the operators we currently have available within transformers like AttributeManager in the SchemaMapper. From my perspective, the best place to specify the Operator would be in the Filter dialog box where the 'Attribute Name Field', 'Attribute Value Field', and 'Blank Attribute Value' options are now. Having Operators read from the external lookup table seems prone to error. What if the user accidentally enters 'contans' instead 'Contains'. Although if you can sort that out somehow, it does add quite a bit of flexibility to read from the lookup table since any particular Filter wouldn't be tied to any one Operator.
If you need someone for beta testing, I would be more than willing to volunteer, as this will be a significant improvement for our workflows.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.