Vehicle capacity fields use units that don't fit every propulsion type (`battery_capacity` mAh, `fuel_capacity` liters)
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 65/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- api, documentation
Hướng nghiên cứu
Review the data-types.md file to understand the current Vehicle schema and the existing capacity fields. Look at the history of the spec to see how fields have been added or deprecated. The change involves updating the specification document and possibly the JSON schema definitions. Check for any existing tests or validation scripts that might need updating. 'Done' means the spec document clearly defines the new optional fields and deprecation note, and the changes are ready for review.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Is your feature request related to a problem? Please describe.
Both Vehicle capacity fields in MDS 2.x (data-types.md) have the same root problem. Each is tied to a single unit of measurement that doesn't work for every vehicle type the spec supports.
1. battery_capacity (mAh): the main problem
battery_capacity is defined as "Capacity of battery expressed as milliamp hours (mAh)".
mAh measures charge, not energy. What a battery can store (and so what range and work it can deliver) is energy: Wh = mAh × V / 1000. Without the pack's nominal voltage, an mAh value can't be compared across vehicles, and MDS has no field for voltage.
Two e-scooter packs show the problem:
| Nominal voltage | Charge | Energy | |
|---|---|---|---|
| Pack A | 36 V | 15 000 mAh | 540 Wh |
| Pack B | 48 V | 15 000 mAh | 720 Wh |
The mAh values are equal, but Pack B stores a third more energy. The reverse also happens. A 400 V car pack of 200 Ah and an 800 V pack of 100 Ah both hold 80 kWh, yet by mAh the first looks twice as big.
Operators also struggle to supply the value at all. We've seen this with carshare providers: fleet and vehicle data usually give battery size in kWh. That is how vehicle makers, type-approval documents and consumer information present EV batteries (e-bike makers do the same in Wh). Converting kWh to mAh needs each model's nominal system voltage. Operators often don't have that value.
2. fuel_capacity (liters): the same problem, not yet hit in practice
fuel_capacity is defined as "Capacity of fuel tank (liquid, solid, gaseous) expressed in liters". Liters suit liquid fuels, but the spec's own propulsion types include hydrogen_fuel_cell, and combustion also covers compressed-gas fuels such as CNG. Tanks for these fuels are normally specified by mass. A hydrogen car holds about 5–6 kg, and its volume in liters depends on storage pressure. Because the field is an integer, a value in kilograms wouldn't be precise enough anyway.
We haven't received data for such vehicles yet. But MDS explicitly supports them, so the gap will appear once they're deployed in shared fleets.
Describe the solution you'd like
Two complementary, non-breaking additions, following the same pattern: a new optional field in the unit that suits the vehicle, alongside the existing one.
In the next 2.x minor release (non-breaking):
| Field | Type | Required/Optional | Description |
|---|---|---|---|
battery_energy_capacity (new) |
Integer | Required if Available | Energy capacity of the battery at nominal voltage, expressed in watt-hours (Wh) |
fuel_capacity_mass (new) |
Integer | Required if Available | Capacity of fuel tank for fuels measured by mass (e.g. hydrogen, CNG), expressed in grams (g) |
battery_capacity |
Integer | Required if Available | Deprecated in favor of battery_energy_capacity |
fuel_capacity |
Integer | Required if Available | Unchanged, clarified as: Capacity of fuel tank for liquid fuels, expressed in liters |
In 3.0 (breaking):
- Remove
battery_capacity(mAh). fuel_capacitystays for liquid fuels.
Integer Wh keeps enough precision for small micromobility packs (e.g. 540) and has room for car packs (e.g. 77000). Integer grams stores hydrogen tank sizes accurately (e.g. 5600).
Is this a breaking change
- No, not breaking for the 2.x part: it adds two optional fields, deprecates one, and clarifies wording.
- Removing
battery_capacityin 3.0 is breaking, and belongs in that major release.
Impacted Spec
For which spec is this feature being requested?
agencyprovider
Describe alternatives you've considered
- Change the unit of
battery_capacityto Wh in place. This is simpler, but it changes the meaning of an existing field. It could only happen in 3.0, and until then data from different providers would be ambiguous. - Add an optional
battery_voltagefield (nominal V) so consumers can derive Wh from mAh. This asks providers for a value that is harder to get than Wh, and it still leaves the useful quantity to be derived. - Add a unit field (e.g.
fuel_capacity_unit:liters|kg, defaultliters). It's non-breaking in the schema, but clients are expected to ignore fields they don't recognize. An existing consumer would therefore silently read a hydrogen car'sfuel_capacityin kg as liters, which is the same ambiguity described above. It also doesn't fix the integer precision problem for kilograms. - Keep the current units and clarify the text. This doesn't fix comparability and doesn't help providers who only have kWh.
Additional context
- Both capacity fields first appeared in 2.0.0 with the multi-modal expansion. We couldn't find any earlier discussion of the choice of units.
- #643 (trip energy consumption) already treated battery capacity in Wh as the natural input for energy calculations.
I will be happy to open a PR against dev or any other branch once there's agreement on the direction.
- Ngôn ngữ chính
- Không có dữ liệu ngôn ngữ
- Star
- 753
- Fork
- 255
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của openmobilityfoundation/mobility-data-specification
-
documentation
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 85/100
openmobilityfoundation/mobility-data-specification#994 · 4 reaction ·
-
Policy
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 18/100
openmobilityfoundation/mobility-data-specification#996 · 1 reaction ·
-
Move Provider/Agency List out of MDS repoCó thể làm lại được @schnuerle đã nhận 37 ngày trước và không có pull request nào đang mở. Đang mởidentifier change
openmobilityfoundation/mobility-data-specification#995 · 1 người được giao ·
-
Pedestrian-proximity behaviour of delivery robots: proposed incident types and permit fieldsĐang mởAgency Delivery Policy Provider
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
-
discussion enhancement question
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
openmobilityfoundation/mobility-data-specification#925 · 1 bình luận ·
Tất cả issue của openmobilityfoundation/mobility-data-specification
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
OHDSI/Data2Evidence#3693 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Project-N-E-K-O/N.E.K.O#3725 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[Bug] Sending a Telegram message chain twice duplicates mentionsCó thể đã có người làm @123XieC đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
AstrBotDevs/AstrBot#11125 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
backend bug priority: high
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
nooriegarg/ContribIQ#73 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
backend enhancement
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 70/100
damodharg6/payledger#16 ·