The TimeSlice is central to AIXM temporality concept. Each aeronautical feature is composed of multiple TimeSlices, where each TimeSlice describes the state of the feature during a specific period of validity. This allows to plan and distribute future updates to the dataset.
AIXM (Aeronautical Information Exchange Model) is an internationally standardized information model used to represent aeronautical data in a structured, digital, and interoperable way. It supports the exchange of static and dynamic aeronautical information between systems while ensuring consistency, traceability, and semantic clarity.
The AIRAC cycle is a global aviation information synchronisation that defines special dates on which information, procedures, schedules, etc. can be changed. These changes are then displayed on the AIP for that country.
I'm seeking to generalise my AIP processing setup and to port it to asyncio. Thus I took a short look around.
DE: single pages as PNG; AIXM data.
NL: page collections as PDF; no AIXM data.
DK: all pages in one PDF; no AIXM data.
So I'll design my server's AIP arch around the apparent lowest common denominator: one PDF per page, referenced by the page designator (eg GEN-1.1) as URI.
Each country gets its own AIP #Python3 module; AIXM support is optional.
Slowly making progress:
✅ collect German AIP pages, OCR-ed
✅ allow search on German AIP (using grep on the transcripts; parsing ANSI colour codes to get structured results)
✅ download German electronic AIP (AIXM 5.1) and build SQLite DB
next on: integrate these parts so that they work robustly in my local server, providing feedback of what is going on.
Now I have German airspace data in a database.
Ho. Ho. Ho.
#AIXM uses a #GML subset to define surfaces and curves. Arbitrary sets of primitives don't go well with relational databases, imo. Thus I converted the GML structures to semicolon-separated command strings (arc, circle, geodesic, line, curve).
Work in progress: declaring #AIXM objects in my #Python class structure. Most AIXM features (like aixm:AirportHeliport) of the datasets at https://aip.dfs.de/datasets are already defined.
Added a global linker set as class variable to the abstract object class, so that all links (like aixm:onRunway) can be collected and stored in one #sqlite3 helper table.
Success! Completed a #Python #AIXM parser, based on xml.parsers.expat and a hierarchy of custom classes.
AIXM features and objects are declared as dictionairies, mapping tag names to AIXM value classes.
While expat traverses the document, features and objects are collected, and values are converted and attached.
In the end all features and objects generate their own SQL commands for creation and inserts.
It even got wait&space capacity for features I currently don't need.
💪
Work in progress: porting my AIXM XSLT back to Python's xml.etree.ElementTree.
Functional programming approach ftw! parseNode() calling parseNode(), doing tag-dependend things.
Downside: xml.etree's namespace handling and XPath parsing is rudimentary at its best. 😐
Finally! My #Javascript planning module can access data from the German electronic AIP.
🙂 💪
Behind the scenes it downloads the current metadata from aip.dfs.de, updates the local AIXM files if necessary, and uses XSLT stylesheets to translate the original XML into JSON-compatible text.
*sigh*
XSLT 1.0 is rather... awkward... unwieldy. And JSON is not forgiving when it comes to control chars and dangling commas. Had to develop JSON building block templates.
delorean-aixm
Frank Abelbeck