Feature Code

Purpose

This note defines the Feature Code as the primary identity token inside a Point_Code.

A Feature Code is the alphabetical identifier that categorises the surveyed feature and determines its baseline processing behaviour.

Examples include:

Feature Code	Feature Name	Typical Feature Type
`KX`	Kerb Bottom	`LINEAR`
`KC`	Kerb Bottom curve indicator variant	`LINEAR`
`CP`	Catch Pit	`POLYGON` / sizing-capable symbol route
`FB`	Flower Bed	`POLYGON`
`TE`	Tree	`1POINT`
`STN`	Control Station	`1POINT` with survey-control handling

The Point Code begins with a Feature Code. Optional suffixes may then modify behaviour:

KX01G
│ │└─ Supplementary Suffix
│ └── Clustering Number
└──── Feature Code with Segment Type Indicator

The Feature_Catalogue uses FeatureCode as the primary key for looking up:

Feature Code resolution must happen before drafting routing.
Unknown or unsupported Feature Codes should not be silently guessed.
Drafting properties should be queried from the Feature_Catalogue rather than hard-coded in script logic.
Feature Code and Feature_Type are related but not identical; the code is identity, while the type is routing behaviour.

Preferred planned functions:

If a code has straight and curve variants, the parser should preserve both:

Parsed Field	Example
`FeatureCode`	`KX`
`IsCurveSegment`	`False`
`FeatureCode`	`KC` or resolved base `KX`, depending on implementation policy
`IsCurveSegment`	`True`

The exact resolution policy for curve variants should be explicit and consistent across the engine.

Confirm whether PythonNet3 should store curve variants as their raw Feature Code (KC) or resolve them to a base Feature Code (KX) plus IsCurveSegment = True.