Repository navigation
RULE Suggestion: Verify used Ids (esp. vehicle_ids) across a GBFS-Feed #217
Description
I am a Product Owner at MOBIDROM - a company owned by the German state North-Rhine-Westphalia with the mission to bundle mobility data related operations in NRW and support both data owners and data users.
I'd like to suggest an addition to the RULEs for the gbfs-validator:
Test if vehicle_ids used for pricing_plan, station_information, station_status and geofencing_zones are actually defined in vehicle_types.json
During the development of our central data platform this issue popped up when using the feeds from our platform for route calculations (we try to use data dogfooding wherever possible) when a geofencing zone was not properly applied and no routes could be calculated. We pinned that down to the fact that we added prefixes to the vehicle_ids while importing the feed but didn't prefix the same ids in geofencing_zones.json).
I think the GBFS-validator should at least raise a warning about "non matching ids" across a feed even though the feed is syntactically valid.
Activity
richfab commentedon Sep 4, 2026
Hello Lars Röglin @PartTimeDataScientist,
Thank you for contributing to the GBFS validator!
Sorry for the delayed response.
I agree with you that validating object dependency relationships is a good idea. And actually an issue already exists for it: #153.
In my opinion, if we add object dependency relationships validation, we should do it for all objects.
I will check internally with MobilityData IT team how we can help with this. Please note that this Javascript validator will progressively be replaced by this one in Java: https://github.com/MobilityData/gbfs-validator-java.
Best regards,
Fabien (MobilityData)
cc @davidgamez @emmambd
richfab commentedon Sep 7, 2026
Hello Lars Röglin @PartTimeDataScientist,
Unfortunately our team does not have the bandwidth to make improvements to the JavaScript validator. Our team can help review and approve PRs from external contributors, but this will also take time.
Please note that we want to refrain from approving PRs with partial fixes, since we won't have time to follow up and complete them.
Feel free to add your use case in the existing issue #153. This will help inform the roadmap to improve the Java validator.
For now, I will close this issue, the conversation continues in #153.
Please don't hesitate if you have any questions.
Thank you!
Fabien (MobilityData)
PartTimeDataScientist commentedon Sep 7, 2026
Hi Fabien @richfab,
thanks for looking into this and your feedback! I mainly wanted to document this problem as we used the GBFS validator during the development process and missed the described problem. Somehow I missed #153 before opening this issue, otherwise I would have commented there. As far as I understand our case is covered by the
primary keysandforeign keysdescribed in #153 - so I'll follow that ticket to watch future developments.And just as a remark: please note that the author of #218 is not affiliated with me or MOBIDROM in any way but someone external who picked up that issue and tried to fix (parts) of it.