fix(sdk): createPedestrian emitted a shape type no consumer recognises - #100
Merged
Conversation
`createPedestrian` returned `type: 'pedestrian'`, but nothing in the SDK or
the editor handles that type:
- the editor has only ever stored placed participants as `vehicle`
(pedestrians are a `templateId`, not a shape type)
- `exporter/openscenario.ts` iterates `shape.type !== 'vehicle' && continue`
and picks `<Pedestrian>` vs `<Vehicle>` from PEDESTRIAN_PATTERNS
So scenes built with `createPedestrian` silently lost every pedestrian:
`exportToOpenScenario` emitted 0 ScenarioObjects for them, with no warning.
`createVehicle` and `createPedestrian` differ only in the default templateId
('filled'), which already matches the exporter's pedestrian patterns.
Return `type: 'vehicle'` so the factory agrees with its own consumers, and
document why, since the naming otherwise invites the same mistake again.
Verified with plain Node: a lane + createVehicle + createPedestrian scene now
emits 2 entities named Vehicle_0 / Pedestrian_1, with
`<Pedestrian pedestrianCategory="pedestrian">`.
Adds __tests__/helpersFactoryContract.test.ts. It runs factory output through
the exporter rather than asserting the shape type, because the type alone would
not have caught the consequence. No existing test referenced createPedestrian,
which is why this went unnoticed. Confirmed both cases fail when the old type
is restored.
kosuke55
added a commit
that referenced
this pull request
Aug 10, 2026
The README documented only the extension (iframe) workflow, while the factories and exporters also work from plain Node.js since the ESM fix (#99) and the factory fixes (#100, #101). Add a copy-paste runnable example that builds a lane + driving path + vehicle and exports OpenDRIVE / OpenSCENARIO / Lanelet2, notes the 0.17.0 requirement, and points scenario logic (triggers, speed profiles) to the editor.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Scenes built with
createPedestriansilently lose every pedestrian:Cause
createPedestrianreturnedtype: 'pedestrian', but nothing in the SDK or the editor handles that shape type:vehicle— pedestrians are atemplateId, not a shape typeexporter/openscenario.tsskips anything that is notvehicle, then picks<Pedestrian>vs<Vehicle>fromPEDESTRIAN_PATTERNSSo the factory disagreed with its own consumers.
createVehicleandcreatePedestriandiffer only in the defaulttemplateId('filled'), which already matches the exporter's pedestrian patterns — the shape type was the only thing wrong.Fix
Return
type: 'vehicle', and document why in a doc comment: the namecreatePedestriannaturally invitestype: 'pedestrian', so without an explanation the same change is likely to be reintroduced.Verification
With plain Node against the built
dist/:Existing suite: 325 passed, 4 skipped.
Test
Added
__tests__/helpersFactoryContract.test.ts.It runs factory output through the exporter instead of asserting the shape type. Asserting
shape.type === 'vehicle'would pass while telling us nothing about whether a pedestrian actually survives export — and the consequence is the part that was broken.No existing test referenced
createPedestrianat all, which is why this went unnoticed. I confirmed both new cases fail when the old type is restored.