What happens
Import streets from OpenStreetMap, then import RTC's network into the same
system. The agency's routes mint their own rough geometry over the streets
that are already there instead of binding to them. You end up with two
networks on one map that never join.
Why
conflatePatternOntoExisting in apps/web/src/editor/store.ts takes an
optional ontoWayIds set restricting what a pattern may be absorbed into.
Drawing by hand passes undefined, so a finished line adopts anything
compatible nearby, including imported streets.
reconcileImportedSystem passes established, which starts empty and only
collects ways minted by patterns processed earlier in the same import. Since
the candidate filter drops every way outside the set, everything already on
the map is excluded along with everything else.
The restriction is doing real work. Patterns are handled longest first, so a
boulevard carrying a dozen routes gets one set of ways rather than a dozen
stacked copies. The exclusion of pre-existing ways is a side effect of that,
not its purpose.
Why dropping the argument is not the fix
Bus tolerance is road width. Matching a whole feed freely against a whole
city of imported streets will sometimes fuse a route onto the frontage road
beside the one it really runs on, and it does that across every route at once
with nobody watching. Whatever replaces the restriction needs to be at least
as careful — candidate ways scoped per pattern, a tighter tolerance for the
automatic case, or a confirmation step.
Notes
Documented in
Where imported data comes from
and listed in the architecture risk table.
Related: #59, which would add OSM transit route relations. Those name their
member ways by OSM id, so they would attach without any geometric matching —
a different and easier join than this one.
What happens
Import streets from OpenStreetMap, then import RTC's network into the same
system. The agency's routes mint their own rough geometry over the streets
that are already there instead of binding to them. You end up with two
networks on one map that never join.
Why
conflatePatternOntoExistinginapps/web/src/editor/store.tstakes anoptional
ontoWayIdsset restricting what a pattern may be absorbed into.Drawing by hand passes
undefined, so a finished line adopts anythingcompatible nearby, including imported streets.
reconcileImportedSystempassesestablished, which starts empty and onlycollects ways minted by patterns processed earlier in the same import. Since
the candidate filter drops every way outside the set, everything already on
the map is excluded along with everything else.
The restriction is doing real work. Patterns are handled longest first, so a
boulevard carrying a dozen routes gets one set of ways rather than a dozen
stacked copies. The exclusion of pre-existing ways is a side effect of that,
not its purpose.
Why dropping the argument is not the fix
Bus tolerance is road width. Matching a whole feed freely against a whole
city of imported streets will sometimes fuse a route onto the frontage road
beside the one it really runs on, and it does that across every route at once
with nobody watching. Whatever replaces the restriction needs to be at least
as careful — candidate ways scoped per pattern, a tighter tolerance for the
automatic case, or a confirmation step.
Notes
Documented in
Where imported data comes from
and listed in the architecture risk table.
Related: #59, which would add OSM transit route relations. Those name their
member ways by OSM id, so they would attach without any geometric matching —
a different and easier join than this one.