Product decisions

Where you can see how I think

Three decisions that shape the database, each with the price it cost.

A source per entry

Every value has an origin: manufacturer figure, field report, my own measurement. That costs maintenance, but without an origin a number in this field is worthless, because the entire point of the database is being more reliable than the lab values.

Values I cannot evidence stay null, not estimated

Where I have no solid value, the entry is null, not an estimate. That is uncomfortable, because an estimated number would look more complete. But an estimated number that looks like a measured one is exactly the kind of quiet dishonesty the database was built against in the first place. Better a gap you can see than a number you cannot trust.

Three generic trucks for the easy way in

The guided mode of the calculator cannot carry a choice between 28 models, that overwhelms anyone who has not dealt with the topic yet. So I derived three generic trucks from the 28 real ones, covering the typical classes. Anyone who wants to go deeper reaches for the full database, anyone who just wants a feel starts with the three. The same data, two resolutions, depending on how far along the user is.

The data

Every value with an origin

The schema sits in the same file as the data, so field descriptions and content cannot drift apart.

Interface and field descriptions shown in German.

The JSON file of the e-truck database with field definitions and records
Fourteen fields per entry, source included. Note mcs_kw, ac_kw and range_km_oem sitting at null: there is no evidenced value for them. No estimate dressed up as a measurement.
In use

The database inside the fleet calculator

The actual point: instead of abstract kilowatt-hours you pick a vehicle you already know.

Vehicle selection in the fleet calculator, grouped by manufacturer
Grouped by manufacturer, with battery capacity per model. The generic fallback sits at the top for anyone who does not have a specific vehicle in mind yet.