NL Vehicle Fuel & Emission — by Powertrain

Turn the Netherlands' vehicle fuel/emission register into clean, per-record powertrain benchmarks — one row per (fuel, emission code, exhaust level, combined CO2) profile with a registered-vehicle count, ready to compare powertrains without ever touching a licence plate or owner.

Each source row becomes one clean, flat record with numeric fields coerced to real numbers, a stable source-native record_id, and provenance stamped on every row: source, resource id, the licence notice, the required attribution, a UTC retrieval timestamp and an interpretation caveat.

What one record represents

The source is 8ys7-d773 — Open Data RDW: Gekentekende_voertuigen_brandstof on the RDW open-data portal (opendata.rdw.nl). Each record is one powertrain-emission profile: a distinct combination of fuel type, emission code, exhaust-emission level and combined CO2 figure, together with registered_count — the number of registered vehicles that share it. The count is the only computed value; the plate (kenteken) and any owner field are never read, grouped, or delivered.

For each record you get a composite record_id built from the source-native key, the analytic columns listed below (reproduced verbatim, numbers as numbers), and the provenance block. The group columns are brandstof_omschrijving (fuel type), emissiecode_omschrijving (emission code), uitlaatemissieniveau (exhaust emission level, e.g. EURO 6) and co2_uitstoot_gecombineerd (combined CO2, g/km), plus registered_count.

Coverage and volume

Grouped to this powertrain-emission shape, the RDW fuel register yields a precise set of distinct profiles spanning every fuel type, emission standard and CO2 level in the Dutch fleet.

Live count: 20,667 grouped powertrain-emission records (pinned live via a SODA group-count); the Wave-3 index stated only '>=2,500', so this is the exact figure. The capacity line is the grouped-row count.

The Actor pages the source with keyless SODA $query requests ordered by the source-native key for a stable total order, and stops as soon as your Maximum records cap is met. The Actor groups server-side with a SODA $query and never selects the plate or any owner field.

Licence and attribution

RDW open vehicle data is published as public-domain / CC0 open government data. The full notice travels on every record:

RDW (Netherlands Vehicle Authority) open fuel/emission data - CC0 / public domain. Aggregated vehicle counts only; the licence plate (kenteken) and any owner/holder field are never read, grouped, or delivered.

The required attribution — RDW - Netherlands Vehicle Authority (Dienst Wegverkeer) — travels on every record.

Interpretation caveat

registered_count is the number of registered vehicles sharing the (fuel, emission code, exhaust level, combined CO2) profile. Blank CO2 groups vehicles with no reported combined CO2 figure. This is the emission/fuel register, distinct from the general vehicle register.

Values are reproduced verbatim: the Actor never rescales, re-derives or editorialises a number.

Person-data policy

By construction this Actor reads only aggregate powertrain keys and a count. The licence plate (kenteken) and any owner/holder field are never in the query and never in a record — a structural guard rejects any source row that even contains a plate/owner field.

Data quality and freshness

Numeric fields are coerced from the source's string encoding into real numbers (integers where whole, floats otherwise); genuinely missing cells are delivered as null, never as zero. Text is passed through verbatim. Every run re-reads the live source, so the data is as fresh as the portal itself, and each record's observed_at stamp records exactly when the row was retrieved. Delivery order is fixed by the source-native key, so a capped sample and a later full pull agree on their overlap and a repeated run returns rows in the same order. The RUN_RECEIPT reports source rows scanned and records delivered and charged for a per-run reconciliation.

Provenance, licensing and compliance

Every run begins with a live source-preflight: the Actor reads the exact host's robots.txt at runtime and refuses to proceed if the crawl policy disallows the data path. The gate result — URL, HTTP status, byte length and a SHA-256 of the policy — is written to the run's RUN_RECEIPT, so each run carries its own audit trail. The Actor identifies itself with a transparent, non-impersonating User-Agent and never bypasses a block, solves a challenge, or fetches through a cache or mirror. When the door is genuinely unavailable the run fails loudly and bills nothing.

Inputs

• Maximum records (maxRecords) — hard cap on records delivered and billed. Raise it to pull the full set; lower it to sample cheaply. Records arrive in a stable, source-native order.

Output

Records land in the Actor's default dataset and export as JSON, CSV, Excel or via the Apify API. A tabular overview view surfaces the most useful columns for quick inspection while the full record retains every selected field and provenance stamp.

Fields in detail

The record leads with record_id — a stable composite key drawn from the source's own grain — followed by the analytic columns described above and closed by a provenance block: source, source_dataset (the Socrata resource id), licence, attribution, caveat and observed_at. Every one of those provenance fields is present on every record, so a single row is self-describing: hand it to a colleague or a downstream system and it carries its own origin, licence and retrieval time without reference back to this page. Because delivery is ordered by the source-native key, the same record always carries the same record_id across runs, which makes the dataset safe to diff, deduplicate, or upsert into a warehouse. Nothing in the record is computed or inferred beyond the explicit count where one is stated — every other value is the source's own, reproduced byte-for-byte.

Sibling Actors

This Actor draws on RDW's fuel/emission table (8ys7-d773), distinct from the fleet's two general-register RDW cells — nl-vehicle-registration-cohort-records (make/model/admission cohorts) and nl-vehicle-type-approval-records (type-approval variants) — which group the vehicle table (m9d7-ebf2). It is also distinct from eu-vehicle-co2-records, which carries EEA new-car CO2 monitoring values rather than fleet counts. This Actor also shares its engineering — the runtime robots gate, push-then-charge billing and verbatim-value discipline — with the fleet's other public-data records Actors.

Sample output

Real rows from a live run of this actor (first 5 rows, selected columns).

One full record from the same run, exactly as delivered:

{
  "record_id": "Alcohol:0:EURO 0:382",
  "brandstof_omschrijving": "Alcohol",
  "emissiecode_omschrijving": "0",
  "uitlaatemissieniveau": "EURO 0",
  "co2_uitstoot_gecombineerd": "382",
  "registered_count": 1,
  "source": "RDW (Netherlands Vehicle Authority) open data",
  "source_dataset": "8ys7-d773",
  "licence": "RDW (Netherlands Vehicle Authority) open fuel/emission data - CC0 / public domain. Aggregated vehicle counts only; the licence plate (kenteken) and any owner/holder field are never read, grouped, or delivered.",
  "attribution": "RDW - Netherlands Vehicle Authority (Dienst Wegverkeer)",
  "caveat": "registered_count is the number of registered vehicles sharing the (fuel, emission code, exhaust-emission level, combined CO2) profile. It is the only computed value; no plate or owner data is read. Blank CO2 groups vehicles with no reported combined CO2 figure.",
  "observed_at": "2026-09-25T17:24:10Z"
}

Pricing

This Actor uses Apify's pay-per-event model: a flat $0.05 per record actually delivered to the dataset, and nothing else — no monthly rental, no per-run base fee, no compute charge. Deliver 40 records and you pay $2.00; deliver 10,000 and you pay $500.00. Billing is wired after delivery — each record is pushed first and only then does the per-record event fire — so a mid-run failure can only ever under-charge you, never over-charge. Use Maximum records to cap spend precisely.

Scaling and limits

Set Maximum records low to sample the leading slice cheaply, or high to pull the full set. The Actor paginates server-side and delivers incrementally, so memory stays flat regardless of how many records you request, and you are billed only for what is actually delivered. Because the source is a live public API, extremely deep pagination is ultimately bounded by the source's own paging behaviour; for the vast majority of uses — sampling, a full refresh, or a scheduled top-up — the default paging is more than sufficient. Schedule the Actor on Apify to keep a downstream table current: each run re-reads the live source and re-stamps observed_at, so a nightly or weekly run gives you a dated, reproducible snapshot.

Typical uses

Compare powertrains by fuel, emission standard and CO2 band; size how much of the fleet meets a EURO standard; track electrification by counting electric-fuel profiles; or feed a fleet-planning, compliance or residual-value model with clean powertrain counts — without any owner or plate data.

What this Actor does not do

It does not forecast or model, does not merge multiple source tables into one record, and it never reads or delivers a licence plate or owner field. It gives you faithful, analysis-ready records — with a provenance trail you can audit on every run.