Charging & Electricity-Price App Built on AFIR/DATEX II Data

The European regulation on the deployment of alternative fuels infrastructure (AFIR) requires that static and dynamic data on charging points — location, connector type, power output, availability, ad-hoc price — be published through official access points. What is served there is not a convenient REST API but DATEX II publications: a model-driven European standard built on deeply nested XML, with a very large number of optional fields and noticeable differences between publishers and between versions of the standard. Anyone who wants to surface this data in an app has to master the format first — the frontend is the easy part.

The second issue is volume and cadence. Inventory data typically arrives as complete snapshots at fixed intervals, while dynamic status information is published far more frequently. Handled naively, that means rewriting the entire dataset on every run without knowing what actually changed. Processing large volumes of data in a backend is less a question of more compute than of recognizing what is new and leaving everything else untouched.

Then there is the semantics. A charging site is a hierarchy of location, station, charge point and connector; identifiers have to stay stable across updates, otherwise points jump around on the map or show up twice. Prices are rarely a single number — they are assembled from energy, time and fixed session components. And with third-party data, "real time" is only ever as real as the publication cadence of the source. That belongs in the data model and in the UI rather than being rounded away.

The architecture keeps three jobs cleanly separated: ingestion, a normalized core, and delivery. The ingestion layer pulls the DATEX II publications from the official sources, reads them as a stream rather than loading whole documents into memory, validates them against the schema, and translates them into a lean domain model of its own. The standard therefore stops at the system boundary — everything behind it works with clear, self-defined concepts.

The data backbone is a scalable .NET backend. The choice follows the nature of the work: schema-driven XML processed continuously. Static typing maps a model-driven format directly, the XML tooling supports streaming reads of large snapshots at a flat memory profile, and long-running background services with scheduled runs are first-class citizens. Ingestion and the delivery API scale independently, because their load profiles have nothing in common: ingestion runs in bursts dictated by the sources, the API follows user behavior.

Continuous market price updates run on their own cadence alongside the inventory data. Each run is compared against the last known state, so only genuine changes trigger downstream work — writes, cache invalidation, refreshing the map layer. Every record carries its origin and a timestamp with it. That is not cosmetic: it is the only way to show honestly in the app how current a value is, and to trace a complaint back to a specific source and point in time instead of searching the whole system.

On the client side, iOS and Android do not speak DATEX II — they speak a deliberately narrow API. Map queries are viewport-based, backed by a spatial index, and aggregated according to zoom level, so the amount of data transferred is tied to what is visible rather than to the size of the overall dataset. Real-time data in a mobile app therefore does not mean pushing everything to the device; it means serving exactly what each view needs, from prepared read models that still answer when an upstream source happens to be unreachable.

• Real-time market prices
• Continuous updates
• Charging points on the map
• Official AFIR/DATEX-II data basis
• Scalable .NET backend

Built for a client in the e-mobility space; the .NET backend runs continuously on a standards-compliant DATEX-II basis. Client-specific metrics remain confidential – what matters is the reliable, scalable data processing behind the scenes.

In projects built on official data standards, the effort almost never sits where the proposal assumes it does. The UI is the manageable part; the real work is in parsing, normalization, stable identity and change detection. The sensible move is to start working with actual publications very early rather than with the specification alone — divergence between the documented model and what is really delivered is the norm with standardized sources, not the exception.

The second transferable point concerns the word real time. With third-party data it effectively always means "as current as the source" — establishing that early saves you from architectural decisions that try to outsmart that limit. A system that carries the origin and as-of time of every value is considerably calmer to operate: reports of supposedly wrong data can be traced back to one source and one point in time instead of turning into a hunt across the whole system.