Feature Representation
LandXML is an XML-based format, so all features have both XML specific format attributes, as well as LandXML-specific format attributes.
This table lists the LandXML-specific format attributes.
Attribute Name |
Contents |
landxml_landxml_type |
The LandXML element type that this feature belongs to. |
landxml_retwall_offset_ |
On a Surface Feature, determines how to interpret the vertical offset on the geometry. |
landxml_retwall_offset_ |
On a Surface Feature, determines how to interpret the horizontal offset on the geometry. |
landxml_element_id |
An attribute which identifies this feature. It is used to track the hierarchy of elements within a LandXML document. |
landxml_parent_id |
An attribute which identifies the parent of this feature. It is used to track the hierarchy of elements within a LandXML document. |
landxml_children_id |
A comma-separated value attribute which identifies the children of this feature (by landxml_element_id value). It is used to track the hierarchy of elements within a LandXML document. |
landxml_equipment_type |
This attribute identifies the type of the equipment used for a survey. Only found on Survey feature types. Current possible values are "equipment_laser_details”,"equipment_instrument_details","equipment_gps_reciever_details","equipment_gps_antenna_details”. |
In particular, landxml_element_id, landxml_parent_id, and landxml_children_id all work together to provide information on the hierarchy of elements within the original LandXML document. These attributes are bookkeeping attributes, in that they store information on the placement of elements within the original LandXML document, but are not properties of the elements themselves. That is, there is no element or attribute that corresponds to the landxml_parent_id attribute, but rather the placement of the element itself is recorded in these format attributes.
As an example of these attributes in action, consider the following LandXML fragment
<Parcels name="AirPorts"> <Parcel name="AirPort_01"> <Parcels name="Runways_01"/> </Parcel> <Parcel name="AirPort_02"> <Parcels name="Runways_02"> <Parcel name="Runway_02_01"/> </Parcels> </Parcel> </Parcels>
Here we see a Parcels feature, which contains two Parcel features, each of which in turn contains a single Parcels feature, and one of those embedded Parcels contains a single Parcel feature. The following features would be produced (with geometry and irrelevant attributes omitted for clarity).
Parcels name : Airports landxml_element_id : 1 landxml_children : 2,4 Parcel name : AirPort_01 landxml_element_id : 2 landxml_parent_id : 1 landxml_children : 3 Parcels name : Runways_01 landxml_element_id : 3 landxml_parent_id : 2 Parcel name : AirPort_02 landxml_element_id : 4 landxml_parent_id : 1 landxml_children : 5 Parcels name : Runways_02 landxml_element_id : 5 landxml_parent_id : 3 landxml_children : 6 Parcel name : Runway_02_01 landxml_element_id : 6 landxml_parent_id : 5
So within FME, these IDs can be used to reconstruct the original structure of the document.Within a reader, the landxml_element_id will be unique to each feature
Note that while it is possible to create cyclic containment hierarchies (i.e. with a Parcels feature referencing a Parcel feature as its parent, which in turn references that Parcels feature as its parent). These will cause the translation to fail with a warning that a cyclic relationship was detected. Self loops (in which a feature refers to itself as its parent) will be detected and the parent reference changed to the default parent in the document.
Of the feature types currently read, only Parcel/Parcels and CgPoints elements can create a cycle. A Parcels element is a container for Parcel elements, and a Parcel element can contain a Parcels element. In the case of CgPoints, A CgPoints element can contain other CgPoints elements.