Skip to content

Changes

Page history
Updated Associations (markdown) authored by Sven Schwyn's avatar Sven Schwyn
Show whitespace changes
Inline Side-by-side
Associations.md
View page @ 275d0d8d
...@@ -5,7 +5,7 @@ A VOR-DME is a good example. This [[navigational aid]] is a combination of a VOR ...@@ -5,7 +5,7 @@ A VOR-DME is a good example. This [[navigational aid]] is a combination of a VOR
```xml ```xml
<Vor> <Vor>
<VorUid> <VorUid mid="1">
<codeId>AGN</codeId> <codeId>AGN</codeId>
<geoLat>435316.90N</geoLat> <geoLat>435316.90N</geoLat>
<geoLong>0005222.30E</geoLong> <geoLong>0005222.30E</geoLong>
...@@ -13,12 +13,12 @@ A VOR-DME is a good example. This [[navigational aid]] is a combination of a VOR ...@@ -13,12 +13,12 @@ A VOR-DME is a good example. This [[navigational aid]] is a combination of a VOR
(...) (...)
</Vor> </Vor>
<Dme> <Dme>
<DmeUid> <DmeUid mid="1">
<codeId>AGN</codeId> <codeId>AGN</codeId>
<geoLat>435316.90N</geoLat> <geoLat>435316.90N</geoLat>
<geoLong>0005222.30E</geoLong> <geoLong>0005222.30E</geoLong>
</DmeUid> </DmeUid>
<VorUid> <VorUid mid="1">
<codeId>AGN</codeId> <codeId>AGN</codeId>
<geoLat>435316.90N</geoLat> <geoLat>435316.90N</geoLat>
<geoLong>0005222.30E</geoLong> <geoLong>0005222.30E</geoLong>
...@@ -36,14 +36,14 @@ The association may be nested inside another `*Uid` tag such as [[airports|airpo ...@@ -36,14 +36,14 @@ The association may be nested inside another `*Uid` tag such as [[airports|airpo
```xml ```xml
<Ahp> <Ahp>
<AhpUid> <AhpUid mid="1">
<codeId>LFNT</codeId> <codeId>LFNT</codeId>
</AhpUid> </AhpUid>
(...) (...)
</Ahp> </Ahp>
<Rwy> <Rwy>
<RwyUid> <RwyUid mid="1">
<AhpUid> <AhpUid mid="1">
<codeId>LFNT</codeId> <codeId>LFNT</codeId>
</AhpUid> </AhpUid>
<txtDesig>16R/34L</txtDesig> <txtDesig>16R/34L</txtDesig>
...@@ -58,26 +58,12 @@ The bonding between the two features is **strong**: Say, if the `codeId` of the ...@@ -58,26 +58,12 @@ The bonding between the two features is **strong**: Say, if the `codeId` of the
## mid ## mid
Since a `*Uid` tag may contain quite a number of key properties, the recognition of identical `*Uid` tags in order to associate features is a cumbersome task sometimes. Since a `*Uid` tag may contain quite a number of key properties, therefore the recognition of identical `*Uid` tags in order to associate features is a cumbersome task sometimes.
To facilitate this matching, you can add an `mid` attribute to the `*Uid` tag: To facilitate this matching, you must add an `mid` attribute to every `*Uid` tag.
```xml The `mid` must be unique to the `*Uid` tag. In other words, the same `mid` is allowed e.g. for one `AhpUid` and one `RwyUid`, but not for two different `AhpUid`.
<Ahp>
<AhpUid mid="15826583"> The `mid` does not replace the key properties wrapped by the `*Uid` tag. Think of it as a shortcut digest of the key properties. Even as a `mid` attribute is present, the key properties must never be omitted!
<codeId>LFNT</codeId>
</AhpUid>
(...)
</Ahp>
<Rwy>
<RwyUid>
<AhpUid mid="15826583">
<codeId>LFNT</codeId>
</AhpUid>
<txtDesig>16R/34L</txtDesig>
</RwyUid>
(...)
</Rwy>
```
:warning: The `mid` does not replace the key properties wrapped by the `*Uid` tag. Think of it as a shortcut digest of the key properties. Even if a `mid` attribute is present, the key properties must not be omitted! :bomb: Unlike AIXM, the `mid` may contain only dots `.` as well as numbers from `0` to `9`.
\ No newline at end of file