...
| Table of Contents | ||||
|---|---|---|---|---|
|
...
Export Hierarchy
There are a number of things to consider that all affect the results that are output from WinCan VX during the export process, and they are almost all handled automatically in the background during the data exchange routine without any user options available to the user.
...
At the end of this export process, every asset has an inspection record exported into the data regardless of whether it was inspected by the contractor during this package of work or not.
...
Creating HADDMS Exports
The files that are produced by the HADDMS export routine are described in the next section, but are essentially only the files required by HADDMS for upload and a .dxf file. The important part about this is that any other deliverables that your client may like to receive have to be created separately from the export routine.
...
When the process has finished, you maybe presented with some warnings, but provided the final message says that the ‘Process has been finished’, then you are good to go, and clicking on the folder icon to the right will take you straight to the export file folder ([Project Folder] → Misc → Exchange → [Project Name]_Date_Time and the folder containing the export files will be named [Project Name]_DDMS_CD535. Inside here, you will find the export files as described:
...
Export final stage.
...
Auto Nodes
A common question after export is ‘Why has my data now got Auto ghost nodes in it after export?’
There are 2 drivers of auto created nodes inside the data after the export routine has been executed. The first is clearly visible in the WinCan project after export, and the second is only visible in the shapefiles with no change in the project, although the trigger for the change will be clear.
Auto_GN_nnnn
After export of the data to the HADDMS shapefiles, you may see some additional nodes in your WinCan project named Auto_GN_nnnn where nnnn is a numeric counter.
These have been created automatically by the export routine to satisfy one of the ‘golden rules' of HADDMS data for a successful upload. This rule is that every continuous item must have a point item at each end that is in the same catchment scheme.
So, if you have a section that is in catchment 1 and it has a node at each end where one node is also in catchment 1, but the other node is in catchment 2, then a Auto_GN node will be created in catchment 1 and linked to the section to satisfy this golden rule. The new Auto node will be a Ghost Node at the same coordinates as the original node, so now you have 2 nodes on top of each other in the same place, but only one of them is valid.
This feature is somewhat complicated by the fact that only inspections are linked to catchments, not assets. So, on investigation, you might have:
A section with multiple inspections - you must check that all of the inspections of the section are in the correct catchment and make amendments if necessary.
Nodes connected to the section which might also have multiple inspections - you must check that all of the inspections of the nodes connected to the section are in the same catchment as the section.
There is a tool available in WinCan VX 10.0 and higher which helps to resolve these issues before export:
...
The Job Checker tool.
When launched:
The application checks that all section inspections are in the same catchment as the original imported catchment from the very beginning of the process.
If they are not, then it automatically assigns the original read-only catchment to all inspections of the section.
It then goes on to do the same thing for all the inspections of the 2 nodes that are attached to the section, so the catchment information is auto-fixed in this scenario.
If the section is a newly added section that did not exist in the original data, then it checks that all inspections of the section are in the same catchment.
If they are not, then the user is prompted to select a catchment from the available list for the section.
Then, the inspections of the nodes connected to the section are moved to this same catchment also.
| Warning |
|---|
Warning - at the time of writing this (Prod v10.1), there is a bug in the pop up window that appears after launching the tool. The list is showing the nodes that are in the wrong catchments, and not the sections. However, it does indicate where corrections need to be made in the data, but as a rule-of-thumb, the user must align all the node catchments with the section catchments. This bug will be fixed in due course. |
A common user error when checking the cohesion of section catchment IDs against its node catchment IDs is to not consider multiple inspections - it is crucially important to align the catchment ID of all inspections of the section first with the original catchment ID of the read-only inspection (if it exists), or with a user selected catchment if it is new data, then align all of node inspections of both nodes to the same catchment ID as the section.
Auto_SC/DC/LC/MC_nnnn
During the export process, there can be occasions when the the exported shapefiles have unexpected point items and extra continuous items that are not visible inside the WinCan VX project.
The reason that this happens is because section 2.26 of the CD535 documentation states:
2.26 Continuous assets shall be split into two separately recorded assets where a significant change in the asset occurs, such as a watershed, significant change in dimensions, materials or lining, or where there is an intermediate flow control device.
NOTE Where there is no physical asset at the location of a significant change, a ghost node is recorded, and is the upstream or downstream asset as appropriate of the two continuous assets.
What this means is that wherever there is a change of significant attribute in the inspection data, we must split the continuous item and create a ghost node connected to both items.
Significant changes of attribute are:
Shape change - triggered by any SCx observation code (not SC code). At this point, an auto ghost node will be created and named Auto_SC_nnnn indicating that this auto node has been created at a Shape Change in the asset.
Size change - triggered by the SC observation code. At this point, an auto ghost node will be created and named Auto_DC_nnnn indicating that this auto node has been created at a Dimension Change in the asset, and this will only be triggered when the change in the primary dimension is greater or equal to 75mm (i.e. one nominal pipe size in most cases).
Material change - triggered by any MCxxx observation code. At this point, an auto ghost node will be created and named Auto_MC_nnnn indicating that this auto node has been created at a Material Change in the asset.
Lining material change - triggered by any LCxxx observation code. At this point, an auto ghost node will be created and named Auto_LC_nnnn indicating that this auto node has been created at a Lining Change in the asset.
At the point of creating a new ghost node with this naming convention, the inspection data and continuous attribute data will also be split accordingly, so now there will be 2 continuous items where before there was only 1.
Also, the assets that have been split will be re-scored. This is the underlying driver behind this feature, because for some observation codes (consider the deformed code), the scoring is different for flexible and rigid materials, so if the material changes from say concrete to plastic and there is deformation in the pipe, we must split the pipe into 2 to get the correct grades for each part of the pipe.
| Info |
|---|
Notes: When these ‘hidden’ auto nodes are created, they are only created in the shapefile exports and there is no change to the data in the WinCan VX project. The reason for this is that there was only ever one video inspection of this pipe, and the operator simply created an inspection with some codes, as is good an proper. We only create one report in the pdf file for this inspection, there is only one video and there is only one record of the inspection in the project database, and this has to stay this way for our sanity inside the database. Hence, these are the hidden auto nodes that are only in the exported shapefiles. But, if you need to know where they have been created, then use the filtering options to find observation codes SC% MC% and LC% in the inspections in the project. These are the places where the these auto nodes will be created. Furthermore, if you are struggling to diagnose a HADDMS upload error based on these point items and the continuous items that are created as a result of this process, then there is little point in searching through the WinCan VX project to find these nodes, because they simply will not be there. They are only in the shapefiles. You should open the shapefiles directly in WinCan Map without WinCan VX, and start your investigations from there, which then may lead you into the WinCan VX project to fix the problems. Remember - whenever you run the export routine for the final deliverables, a backup is made of the current database inside [Project Folder] → Misc → Backup. We do this because we are modifying the data during the export process and you have no control over this process, so if you are not happy with the results after export, you can roll back your project to the place where it was at when you started the export process if you wish, make some fixes and run the export again. |
...
Understanding the Outputs
The HADDMS export routine creates two files for each catchment in the project and this is exactly the reason why it is essential to keep a solid grip on the job data within the WinCan project at all times during data processing and site analysis:
A zipped folder containing all of the HADDMS data files for upload including the inspection photos, shapefiles and observation .dbf file. You can try to upload this file to HADDMS and if the data is good, then it will be approved.
A .dxf file containing the shape geometry of the project including attribute data, but without any significant layer styling. This is not a HADDMS deliverable which is why it is saved outside of the .zip file, but it creates a geometrically correct representation of the data that is being uploaded in a generic layered CAD file from where the user can style and design their own CAD files for delivery to the area client.
...
Uploading to HADDMS
The upload process to HADDMS is not for any real description here, because that is a HADDMS process using their systems and website, but it is worth just noting a few minor points that are maybe a little unclear with their system:
...