You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An issue when importing EATSML from an EATSML export from another system is that the eats_id values are likely to be incorrect, requiring manual merging of the correct ids from the new system into the EATSML. For infrastructural elements, at least, it would be better if the EATSML used subject identifiers and used those to find existing elements in a new system.
Obviously this only works if the two systems have such identifiers in common, but this is at least data that can be managed, where database IDs cannot.
Implementing this change in the EATSML importer and exporter depends on implementing an interface for adding subject identifiers to infrastructure elements (#1).
It might be that in the use case of wanting to merge data from two or more different EATS systems, it is better to just use XTM, if available (#2).
The text was updated successfully, but these errors were encountered:
An issue when importing EATSML from an EATSML export from another system is that the eats_id values are likely to be incorrect, requiring manual merging of the correct ids from the new system into the EATSML. For infrastructural elements, at least, it would be better if the EATSML used subject identifiers and used those to find existing elements in a new system.
Obviously this only works if the two systems have such identifiers in common, but this is at least data that can be managed, where database IDs cannot.
Implementing this change in the EATSML importer and exporter depends on implementing an interface for adding subject identifiers to infrastructure elements (#1).
It might be that in the use case of wanting to merge data from two or more different EATS systems, it is better to just use XTM, if available (#2).
The text was updated successfully, but these errors were encountered: