What causes "front path has 0 length" in a-b-street/abstreet?

Skip the lot (the caller does this) or fix the OSM polygon so the lot doesn't reach the sidewalk.

front path has 0 length

Error message

front path has 0 length

What it means

When snapping a parking lot driveway, the library draws a line from the lot's center to the nearest sidewalk point and trims it against the lot's polygon. If Line::new fails, the center is effectively on the sidewalk (zero-length front path), so no driveway geometry can be built and the lot is skipped.

Solutions

Skip the lot (the caller does this) or fix the OSM polygon so the lot doesn't reach the sidewalk.
Adjust the snapped sidewalk point threshold in map generation so the center-to-sidewalk line has positive length.
Edit the parking lot polygon in the input data to pull its boundary back from the sidewalk.

Defensive patterns

Strategy: try-catch

Validate before calling

let d = center.to_pt2d().distance(sidewalk_pos.pt(map));
if d <= Distance::ZERO || trim_path(polygon, line).is_err() { skip_lot = true; }

Try / catch

match snap_driveway(&lot, ...) {
    Ok(driveway) => ..., 
    Err(e) if e.to_string().contains("front path has 0 length") => {
        warn!("skipping lot {:?}: no driveway possible", lot.id);
    }
    Err(e) => return Err(e),
}

Prevention

Sanity-check OSM parking lot polygons for overlap with sidewalks before import
Treat per-lot driveway failures as skippable warnings in import tooling
Review degenerate/small polygons flagged during map generation

When it happens

Trigger: fix_parking_lot_driveways / make_all_parking_lots calling snap_driveway where the parking lot polygon extends all the way to the snapped sidewalk point, making center-to-sidewalk distance ~0 and Line::new reject a degenerate line.

Common situations: Importing OSM parking lot polygons that touch or overlap the sidewalk; small/oddly-shaped lots whose centroid lies near the sidewalk; maps generated in dense urban areas with lots abutting sidewalks.

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

AI-assisted analysis of a-b-street/abstreet@0964f29315 (2026-09-13). Data as JSON: /api/errors/e0c50f289b451baa. Report an issue: GitHub.

Appendix: source

Thrown at map_model/src/make/parking_lots.rs:147

    results
}

/// Returns (driveway_line, driving_pos, sidewalk_line, sidewalk_pos)
pub fn snap_driveway(
    center: HashablePt2D,
    polygon: &Polygon,
    sidewalk_pts: &HashMap<HashablePt2D, Position>,
    map: &Map,
) -> Result<(PolyLine, Position, Line, Position)> {
    let driveway_buffer = Distance::meters(7.0);

    let sidewalk_pos = sidewalk_pts
        .get(&center)
        .ok_or_else(|| anyhow!("parking lot center didn't snap to a sidewalk"))?;
    let sidewalk_line = match Line::new(center.to_pt2d(), sidewalk_pos.pt(map)) {
        Ok(l) => trim_path(polygon, l),
        Err(_) => {
            bail!("front path has 0 length");
        }
    };

    // Can this lot have a driveway? If it's not next to a driving lane, then no.
    let mut driveway: Option<(PolyLine, Position)> = None;
    let sidewalk_lane = sidewalk_pos.lane();
    if let Some(driving_pos) = map
        .get_parent(sidewalk_lane)
        .find_closest_lane(sidewalk_lane, |l| PathConstraints::Car.can_use(l, map))
        .and_then(|l| {
            sidewalk_pos
                .equiv_pos(l, map)
                .buffer_dist(driveway_buffer, map)
        })
    {
        if let Ok(pl) = PolyLine::new(vec![
            sidewalk_line.pt1(),
            sidewalk_line.pt2(),

View on GitHub (pinned to 0964f29315)