Developer Reference Route Checking

1. Home
2. Developer Reference
3. Route Checking

ENCX is now capable of examining a route to check for navigational warnings and dangers.

By far the easiest way to get started with this is to explore this capability is to look at the RouteChecker sample application included with ENCX. This article provides extra documentation that should be used in conjunction with the sample.

The sample code creates a very simple, but inadvisable, route.

The user can clear the route by clicking the Clear button.

New waypoints can be added simply by double-clicking.

The route checking area types can be filtered by checking them on or off in the list on right had side.

The safety contour can be adjusted in the edit box.

Route checking can be computationally intensive, therefore in the sample we do the checking on a separate thread. This allows the user to still interact with the application without waiting for the route check to complete.

The method that provides route checking is simply Check on the RouteCheck class. This method requires the following parameters:

• Waypoints - the ENCX collection class GeoPoints representing the route's waypoints.
• LineType - the line type between the waypoints (rhumb or great circle).
• SafetyContour - the depth in metres, of the safety contour. Usually you'll want to use the same value as DisplaySettings.
• SafetyDistance - the distance, in metres, to allow either side of the route leg.
• S57Manager - the SENC to check against.

Check returns an XML string containing the results in the following form:

<RouteCheck>
    <RouteLegs>
        <RouteLeg>
            <Index>n</Index> <!-- where n is 0-based index of route leg -->
            <Areas>
                <Area>
                    <AreaType>EcdisAreaType</AreaType> <!-- see below for values of EcdisAreaType -->
                    <Runs>
                        <Run>
                            <Features> <!-- no features when there's no data -->
                                <Feature>
                                    <ID></ID> <!-- the ID of the feature causing the warning -->
                                    <Depth></Depth> <!-- for depth sounding features only -->
                                </Feature>
                            </Features>
                            <Start></Start>
                            <End></End>
                        </Run>
                    </Runs>
                </Area>
            </Areas>
        </RouteLeg>
    </RouteLegs>
</RouteCheck>

The route leg is identified by the 0-based integer returned in the Index element. So if a route with 3 waypoints is passed into the method, you can expect to find a RouteLeg with an Index element of 0 for the leg between the first and second waypoints and a RouteLeg with an Index element of 1 for the leg between the second and third waypoints.

For each route leg, the XML identifies the EcdisAreaType causing the "collision" warning, the features involved and start and end points for the collision along the leg.

EcdisAreaType represents the type of objects found that cause the warning. It can be any one of:

• InsideSafetyContour
• NoData
• NavigationalHazard
• TrafficSeparationZone
• RestrictedArea
• CautionArea
• OffshoreProductionArea
• AreasToBeAvoided
• MilitaryPracticeArea
• SeaPlaneLandingArea
• SubmarineTransitLane
• AnchorageArea
• MarineFarm
• PSSA

The feature ID is a string that identifies the particular intersecting feature. Note that in the sample, the identifier is used with S57Draw.HighlightFeature (or HighlightSounding) to indicate which feature in the chart view.

The Start and End elements are the points along the route where the intersection with the features occurs. If it's a single point then start and end will be the same value.