Workbench automapper takes strange detour through Cataloger Agent

[FedorSteeman]

In some cases, that can be hard to predict, the Workbench Automapper maps to a field in a related table, like collecting event, through the cataloger (and sometimes other) agent.

These strange detours will then have to be unmapped and the more straightforward mapping to collectingevent attributes done instead. Could this be mitigated?

[maxpatiiuk]

what does the label for your collecting event attribute fields you want to map to looks like? automapper tries to match the dataset column name both against the localized field name, as well as database field name. also, it's not smart enough at the moment to handle camelCase header names properly. @FedorSteeman is that common in the production data sets?

it's possible that automapper fails to map to those, and in search of mapping as many fields as it can it settles for the best it can find.

[FedorSteeman]

Why the detour through the Cataloger agent, though? Why not directly to Collecting Event?

[maxpatiiuk]

Ah, thanks for the clarification.

Few possible reasons:

• For best automapper results, database header has to match field label. In your case, the data set uses depth, but field label uses elevation.
• Does automapper map any other column to collecting event -> locality -> min elevation? if that path is already taken, it will search for a different one
• Also, we have a hardcoded rule in the automapper that if a data set header contains the word depth, then map it to minElevation. Thus a workaround is to put the startDepth field before the depth verbatim field

A proper fix would be to make automapper smarter:

• treat min as synonym of start (but only in some contexts?)
• treat elevation, elev, elev. el. and all the variations as synonym of depth

and yet, there is only so much you can achieve with hardcoded rules or string comparison algorithms. some sort of light ML network would be best - something small enough that can be run on the client.