InfoWorks ICM to TUFLOW: Difference between revisions
Content deleted Content added
Tuflowduncan (talk | contribs) |
Tuflowduncan (talk | contribs) |
||
Line 28:
[[File:ODEC Conduit TUFLOW.png|400px]]
Once the mappings have been set up, they can be saved as a Config file by using the ‘Save Config…’ option. Once a copy has been saved, the config file can be re-used to apply the same field mappings to subsequent exports. It should be noted that not all TUFLOW fields have an equivalent InfoWorks field and vice versa, therefore in some situations there will be some modeller input required to ensure the data is imported in the correct manner.
*'Constant'-Allows the user to specify a constant value, for example, specify a constant value of '1' for the 'Code' field when exporting 2D Zones. It is also used when exporting a null value.
* 'Field'-This is used to directly map an InfoWorks ICM field to a TUFLOW/Estry field. For example, copying the 'conduit_length' field to the 'Len_or_ANA' field for conduits.
*'SQL'-This allows a simple structured query language (SQL) script to export a combination of fields. For example, the ID is set to US_node_ID + link_suffix.
* 'Script'-This allows the user to utilise a ruby script to filter out exported items or to convert fields. For example, for conduits, conduits with an InfoWorks shape type of 'CIRC' can be exported to TUFLOW link types 'C', shape types 'RECT' to 'R' and all others to 'I'.
It is also possible to export all InfoWorks fields at the end of the shape file and then use GIS to post-process this for conversions and other simple translations. Please contact support@tuflow.com for an example config file which contains mappings for nodes, pipes, 2D components and 1D structures. The config file is a work in progress but provides a good starting point for the conversion and further mapping of fields between InfoWorks and TUFLOW. Note, that currently the config file is set up to export geometry tables only and will not export tables containing cross-sections, head-discharge curves and similar.
This approach can be used to export on a table by table approach although it is possible to save to the same config file. This allows one config file to set up all the mappings for each of the table exports. The downside of this approach is the time-consuming nature of exporting each table individually.
| |||