曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
notification for the natural key of the <Ahp> feature has already been sent, then the <Changed> notification
for the <Rwy> feature shall contain the new natural key in the <AhpUid> element.
The same rule applies for withdrawn features. If a RWY ceases to exist at the aerodrome, then the
<Withdrawn> notification for the <Rwy> feature shall contain the new natural key of the <Ahp> feature,
as it is included in the natural key of the <Rwy>.
5.1.7.2. Limited Geographical Areas
Users might be interested to receive from an AIXM data source messages covering only a limited geographical
area, such as an FIR. This is possible with AIXM. However, there are two aspects that need
to be mentioned.
• Certain types of feature do not have a geographical aspect and so cannot be collated in that way. For
example, if an AIXM source is to provide downloads based on a geographical area, certain elements
- such as Org_Auth - cannot be readily included. A choice must be made between including all nonrelated
features or only directly referenced ones.
• Another potential issue can arise with update messages for limited geographical areas. An update
can generate "change" messages for designated points that are unknown to the receiving system.
This is because it is possible for the points to have "moved" into the area of interest (e.g. an FIR).
Instead of a "changed" message, the receiving system expects a "new" message. This can also apply
to children of the unknown feature, for example in the case of "changed" messages to an route segment
usage <Rsu>, which is the child of an unknown route segment. Potential problems such as this one
could be handled by implementing special procedures in the client application. For example, to resolve
the above scenario, the system could treat the unknown feature in the "changed" message as if it
were in a "new" message, and thus create the object locally.
5.1.7.3. Cascaded Updates
The AIXM does not compel applications to cascade the effects of changes or deletions to the database.
For example, if a VOR is deleted, one could argue that all route segments etc. that use that VOR should
also be deleted. The precise behaviour in circumstances such as this is left entirely as an applicationlevel
decision.
5.1.7.4. Related Features
The AIXM does not require referred features to be present in a message - this again is an applicationlevel
decision. For example, if an application did not want to store VORs, but just DMEs, its upload
Edition Number: 4.5 21
AIXM PRIMER
software should simply ignore all references towards VORs. The related VORs would not have to be
present in the parameter set or the AIXM download file.
5.2. AIXM-Snapshot
AIXM-Snapshot XML messages could be regarded as a kind of database reports, containing data about
versions of aeronautical features which are valid at a specific moment (date and time). The root element
is <AIXM-Snapshot>. It has attributes indicating the origin of the message, the date and time when it
was issued and the date and time used as selection criteria (effective time). It contains elements such as
<Vor>, <Dme>, <Rsg>, etc., as defined in the AIXM-Features.xsd sub-schema. Each such feature element
contains data about the version of a feature. The values of all feature attributes correspond to the date
and time specified in the 'effective' attribute of the <AIXM-Snapshot> element.
An extract from an AIXM snapshot message is given below:
<AIXM-Snapshot
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="AIXM-Snapshot.xsd"
version="1.1"
origin="EAD"
created="2002-05-27T15:25:34"
effective="2002-05-26T01:00:00">
<Dme>
<DmeUid mid='137456733'>
<codeId>BXL</codeId>
<geoLat>514327.45N</geoLat>
<geoLong>0032346.21E</geoLong>
</DmeUid>
<OrgUid mid='178692030'>
<txtName>BELGIUM</txtName>
</OrgUid>
<VorUid mid='187652432'>
<codeId>BXL</codeId>
<geoLat>514326.67N</geoLat>
<geoLong>0032345.37E</geoLong>
</VorUid>
<codeChannel>15X</codeChannel>
<codeDatum>WGE</codeDatum>
<valElev>350</valElev>
<uomDistVer>FT</uomDistVer>
<Dtt>
<codeWorkHr>H24</codeWorkHr>
</Dtt>
</Dme>
…
</AIXM-Snapshot>
As mentioned in 3.4, feature relationships are encoded by including the natural key of the related feature.
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
AIXM_Primer_4.5(12)
