fio-l3-vienna-geofabrik-highways

Rerun

Let me break down this task:

1. Download Austria OSM PBF from Geofabrik
2. Find all highway ways whose name ends with 'Gürtel' (Vienna's Gürtel corridor)
3. Create a 500m buffer around those ways
4. Extract all highway ways that intersect that buffer
5. Extract all public-transport route relations (bus, tram, subway, train, trolleybus, light_rail) that cross the buffer
6. Save both layers to vienna_network.gpkg
7. Highways as LineString, PT routes as MultiLineString
8. In Austria's standard projected coordinate system (EPSG:31287 or EPSG:31256 - Austria Lambert? Let me think... Austria's standard projected coordinate system is EPSG:31287 (MGI / Austria Lambert) or EPSG:31256 (MGI / GK M31). Actually, let me check. The standard projected CRS for Austria is EPSG:31287 (MGI / Austria Lambert) or EPSG:31258 (MGI / GK M28), etc. I think EPSG:31287 (Austria Lambert) is the standard one used nowadays.)

Wait, let me think about this more carefully. For Vienna, the standard projected coordinate system might be EPSG:31256 (MGI / GK M31) which covers Vienna. Or EPSG:31287 (MGI / Austria Lambert) which is the national projection. I'll use EPSG:31287 as it's the national standard.

Actually, let me use EPSG:31287 (MGI / Austria Lambert) which is the standard projected CRS for all of Austria.

Let me start by downloading the file and working with it.

I'll use osmnx or osmium or geopandas with osmium/pyosmium, or I can use duckdb with spatial extension... Actually, let me think about the best approach.

I think using osmnx would be the easiest. But osmnx works with OSMnx graphs and API, not directly with PBF files. Let me use osmium (pyosmium) or better yet, use osmnx with the PBF file.

Actually, osmnx can read from PBF files using `osmnx.graph_from_xml` or through `osmnx.geometries_from_polygon` using a local file? No, osmnx primarily uses the Overpass API.

Let me use a different approach. I'll use `pyosmium` to parse the PBF file and process it, or use `osmnx` functions.

Actually, the simplest approach might be:
1. Use `osmnx.settings.all_one_way = True` and `osmnx.graph_from_place` but that downloads from Overpass.

Let me think about using pyosmium to directly process the PBF file. This is the most efficient approach for a large PBF file.

Let me write a comprehensive script that:
1. Downloads the PBF file (or checks if it exists)
2. Uses pyosmium to read it
3. Finds Gürtel ways
4. Creates buffers
5. Finds intersecting highways
6. Finds PT route relations
7. Writes to GeoPackage

Actually, a more practical approach: use `osmnx` which can load from a local PBF file via `graph_from_xml`? No, that needs XML.

Let me try using `pyosmium` to parse the data. But pyosmium is quite low-level. Let me think of alternatives.

I could use `osmnx` with the `overpass` URL, but that might be slow for a whole country. 

Another approach: use `geopandas` with `pyogrio` which can read PBF files. Actually, Fiona/GDAL can read OSM PBF files using the `OSM` driver. Let me check if that's available.

Let me try a practical approach:

```python
import geopandas as gpd
import shapely
```

GDAL has an OSM driver that can read PBF files. But it needs to know what layers to read (points, lines, multipolygons, etc.).

Actually, let me try the approach with osmnx first, since it's simpler:

1. Download the PBF
2. Use osmium to extract the relevant data
3. Process with geopandas

Let me write a script that downloads the PBF and processes it.

Actually, let me think about this more carefully. The PBF file is ~800MB. Downloading might take a while. But it's necessary.

Let me write a Python script that:

1. Downloads the PBF
2. Uses pyosmium to read it and find Gürtel ways
3. Creates a buffer
4. Filters all highways that intersect the buffer
5. Finds PT route relations that cross the buffer
6. Writes to GeoPackage

Actually, using pyosmium might be complex. Let me try using the geopandas + pyogrio approach with the OSM GDAL driver.

With GDAL's OSM driver, I can read layers like 'lines' (ways) and 'multilinestrings' (for relations). But filtering for specific attributes might be tricky.

Let me think about a better workflow:

1. Download PBF file
2. Use `osmium` command-line tool (or pyosmium) to extract just the Vienna area or Gürtel area
3. Use pyosmium or GDAL to read the filtered data

Actually, let me just use a combination of tools. Let me check what's available.

Let me start by writing a script and see what's available.

I'll write a Python script that uses:
- `osmnx` if available, to load the data
- Or `pyosmium` to parse the PBF
- `geopandas` for spatial operations
- `shapely` for geometry operations

Let me first check what's installed.

Let me plan the approach:

1. Download the Austria PBF
2. Use osmium or osmnx to extract highways whose name ends in 'Gürtel' within Vienna
3. Buffer those by 500m
4. Find all highways intersecting that buffer
5. Find all PT route relations (bus, tram, subway, train, trolleybus, light_rail) crossing the buffer
6. Write both layers to vienna_network.gpkg in EPSG:31287 (Austria Lambert Conformal Conic) or EPSG:31256 (MGI / Austria GK M31) - the standard projected CRS for Austria. Let me check what's standard.

Actually, the standard projected coordinate system for Austria is EPSG:31287 (MGI / Austria Lambert) or EPSG:31256 (MGI / Austria GK M31). EPSG:31287 is the Austria-wide Lambert conformal conic projection. Let me use that.

Let me first download the file and start working.

Let me use osmnx to get the Gürtel ways, buffer, then get highways and PT routes. But osmnx might be simpler. Let me think about the best approach using the tools available.

Actually, let me use a combination:
1. Download the PBF
2. Use osmium to query/filter
3. Use geopandas/shapely for the geometry operations

Let me start by downloading the file.

Good, the file is 765 MB. Now I need to:

1. Find all highway ways whose name ends with "Gürtel" in Vienna.
2. Create a 500 m buffer around those ways.
3. Find all highway ways that intersect that buffer.
4. Find all public-transport route relations (bus, tram, subway, train, trolleybus, light_rail) that cross the same buffer.
5. Write both layers to vienna_network.gpkg.

Let me think about the approach. Using osmium is ideal for working with PBF files. Let me use the `osmium` Python library (which is installed as `osmium` version 4.3.1) to parse the PBF.

Actually, let me think about this more carefully. The approach:

1. First, find all "Gürtel" highway ways. These are ways where the `name` tag ends with "Gürtel". We need to identify their IDs.

2. Get the geometries of these ways, create a 500m buffer.

3. Find all highway ways that intersect the buffer.

4. Find all PT route relations that cross the buffer.

Let me write a comprehensive Python script.

Actually, let me use osmnx which might be the easiest approach. But osmnx works with Overpass API, not local PBF files typically. However, since we have the PBF file locally and osmium is available, let me use osmium.

Wait, osmium Python bindings (version 4.3.1) - let me check what's available.

Let me think about a practical approach:

Step 1: Use osmium to filter ways with name ending in "Gürtel" from the PBF. We need to extract their geometries.

Step 2: Buffer them and find intersecting highways.

Step 3: Find PT route relations.

Let me start by writing a script that uses osmium to find the Gürtel ways.

Actually, I think the most efficient approach is:

1. Use osmium with a handler to find all ways with name ending in "Gürtel" - get their node references.
2. Get the geometries of these ways.
3. Buffer by 500m.
4. Use osmium again to find all highways intersecting that buffer.
5. Find PT route relations.

But this is complex. Let me think differently.

Actually, I can use the `osmium` command-line tool and Python module. Let me first check what's available.

Let me write a Python script step by step.

For the buffer, Austria's standard projected coordinate system is EPSG:31287 (MGI / Austria Lambert) or EPSG:31256 (MGI / Austria GK M31) or EPSG:3416? Let me check... The standard for Vienna is often EPSG:31256 (MGI / Austria GK M31 - for Vienna area), or EPSG:31287 (Austria Lambert). Actually, the most common "standard projected coordinate system" for Austria is EPSG:31287 (MGI / Austria Lambert).

Let me just use EPSG:31287 (MGI / Austria Lambert) which is the standard for all of Austria.

Wait, let me check: EPSG:31287 is "MGI / Austria Lambert". EPSG:31256 is "MGI / Austria GK M31" covering the Vienna area. EPSG:31255 is "MGI / Austria GK M28" covering western Austria.

For Vienna specifically, EPSG:31256 (MGI / Austria GK M31) would be the local projection. But "Austria's standard projected coordinate system" likely refers to EPSG:31287 (MGI / Austria Lambert).

Let me just use EPSG:31287.

Now let me write the script. I'll use the osmium Python module.

Actually, looking at this more carefully, the osmium Python module (v4.3.1) - let me check how to use it.

The `osmium` Python module provides bindings to libosmium. I can use `osmium.SimpleHandler` to process the PBF file.

Let me write a comprehensive script.

Actually, let me first test what osmium provides:

```python
import osmium
```

Let me check the API.

Actually, let me just write a script that uses osmium to find the Gürtel ways, then uses shapely to create buffers, then filters again with osmium for intersecting highways and PT routes.

Let me plan the script:

1. Parse the PBF to find all ways with `name` tag ending with "Gürtel" (case-insensitive? Probably case-sensitive since it's a proper name).
2. For each such way, collect its node references, then get the node coordinates to build a LineString geometry.
3. Create a 500m buffer around these ways (union them).
4. Find all highway ways that intersect this buffer.
5. Find all PT route relations (type=route, route=bus|tram|subway|train|trolleybus|light_rail) that have geometry intersecting the buffer.
6. Write to GeoPackage.

For route relations, I need to get the route geometry as a single MultiLineString. A route relation has members (ways). I need to get the geometry of all member ways, merge them into a single geometry.

This is quite complex. Let me write a step-by-step Python script.

Actually, let me use a more practical approach. I'll use osmium to:
1. First pass: find Gürtel ways and their node coordinates.
2. Second pass: find all highways intersecting the buffer.
3. Third pass: find all PT route relations and their member ways.

Let me start coding.

Actually, a simpler approach might be:

1. Use osmium to extract all nodes, then all ways with name ending in "Gürtel" to get their geometries.
2. Buffer and find intersection.
3. Extract all highways intersecting buffer.
4. Extract all PT routes intersecting buffer.

Let me write this step by step.

Let me write a Python script:

```python
import osmium
import geopandas as gpd
import shapely.geometry as geom
import pyproj
import json
from collections import defaultdict

# First, let's find all Gürtel ways
class GuertelHandler(osmium.SimpleHandler):
    def __init__(self):
        super().__init__()
        self.nodes = {}
        self.guertel_ways = []
        
    def way(self, w):
        if 'name' in w.tags and w.tags['name'].endswith('Gürtel') or w.tags['name'].endswith('Guertel'):
            # Store way info
            way_nodes = [n.ref for n in w.nodes]
            self.guertel_ways.append({
                'id': w.id,
                'nodes': way_nodes,
                'tags': dict(w.tags)
            })
    
    def node(self, n):
        if n.id in self.all_needed_nodes:
            self.nodes[n.id] = (n.location.lon, n.location.lat)
```

Hmm, the issue is that we don't know which nodes are needed before processing ways. Let me do it in two passes: first collect all way node refs, then read those nodes.

Or better, use osmium's index to handle node locations.

Actually, let me use a simpler approach. Let me use `osmium` with the `NodeLocationsForWays` handler:

```python
import osmium

class GuertelHandler(osmium.SimpleHandler):
    def __init__(self):
        super().__init__()
        self.ways = []
    
    def way(self, w):
        if 'name' in w.tags and 'Gürtel' in w.tags['name'] and w.tags['name'].endswith('Gürtel'):
            # Build geometry from nodes
            coords = []
            for n in w.nodes:
                if n.location.valid():
                    coords.append((n.location.lon, n.location.lat))
            if len(coords) >= 2:
                self.ways.append({
                    'id': w.id,
                    'geometry': geom.LineString(coords),
                    'tags': dict(w.tags)
                })

# Apply NodeLocationsForWays
handler = GuertelHandler()
with osmium.io.Reader('austria-latest.osm.pbf', osmium.osm.osm_entity_bits.NODE | osmium.osm.osm_entity_bits.WAY) as reader:
    # We need node locations for way geometries
    loc_handler = osmium.make_node_locations_handler(handler)
    osmium.apply(reader, loc_handler)
```

Let me check the osmium API more carefully. The `osmium` Python module's API...

Actually, I recall that `osmium.SimpleHandler` with `NodeLocationsForWays` is the right approach. Let me write the full script.

Let me also think about the route relations. For PT routes, we need to:
1. Find relations where type=route and route is one of bus, tram, subway, train, trolleybus, light_rail.
2. For each such relation, find all member ways (with role "" or similar).
3. Build geometry from those ways.
4. Check if the geometry intersects the buffer.
5. Keep as a single MultiLineString feature.

Let me write the full script now.

Actually, osmium Python module: I need to check the exact API. Let me test some basics first.

Good. I have osmium available. Let me first get the Gürtel ways. The approach:

1. First pass: Find all highway ways where name ends with 'Gürtel' and get their geometries to build the buffer.
2. Second pass: Get all highways intersecting the buffer.
3. Third pass: Get all PT route relations that cross the buffer.

But osmium is a single-pass handler. Let me think about this more carefully.

Actually, I can use osmnx which is available. Let me check if osmnx can work with local PBF files.

Actually, osmnx works with OSMnx's graph_from_place or similar functions that download from OSM. But I have a local PBF file. Let me think of a better approach.

Approach:
1. Use osmium to scan the PBF file and find all ways with `name` ending in 'Gürtel' and `highway` tag. Collect their way IDs.
2. Then use osmium again with NodeLocationsForWays to get the geometries of those ways.
3. Compute the buffer around those geometries.
4. Then find all highways intersecting the buffer.
5. Find all PT route relations crossing the buffer.

This is complex but doable with osmium. Let me write a comprehensive Python script.

Actually, let me think about a simpler approach using OSMnx or just using osmium to process the file in multiple passes.

Let me use osmium with NodeLocationsForWays to get geometries.

First, let me find the Gürtel ways (highway ways with name ending in 'Gürtel').

Let me write a script step by step.

Actually, I think the most efficient approach is:

1. First pass: use osmium to find all ways with highway tag and name ending in Gürtel. Collect their node IDs.
2. Second pass: with NodeLocationsForWays, get the full geometry of those ways, build a buffer.
3. Third pass: with NodeLocationsForWays, find all highway ways intersecting that buffer.
4. Fourth pass: find all route relations (type=route, route=bus/tram/subway/train/trolleybus/light_rail) that intersect the buffer.

Actually, for relations, I need the geometry of the relation, which is the union of its member ways. That's more complex.

Let me write a comprehensive script that does:
1. First pass: identify Gürtel ways, collect their node coordinates (with NodeLocationsForWays), build buffer.
2. Second pass: identify all highway ways intersecting buffer, collect their attributes and geometries.
3. Third pass: identify route relations, find their member ways, check if they intersect buffer, collect geometries.

This is going to be quite complex. Let me write it step by step.

Actually, let me think about using osmnx. osmnx 2.1.0 might be able to work with local files or we can use it to search.

Hmm, but osmnx typically uses Overpass API, not local PBF. However, I could use osmnx's `graph_from_polygon` approach if I can extract the buffer polygon first.

Let me try a different approach. Let me use osmium to extract the data I need.

Let me write the full script.

Let me figure out the approach. I'll use osmium to:

1. First pass: scan all ways with highway tag, find those whose name ends with 'Gürtel', collect their nodes, build their geometries.
2. First pass also: collect all public transport route relations.
3. Find all ways that intersect a 500m buffer around the Gürtel ways.
4. Find all PT route relations that cross that buffer.

Actually, let me think about this more carefully.

The task:
1. Find highway ways whose name ends in 'Gürtel' - these define the Gürtel corridor in Vienna.
2. Buffer those by 500m.
3. Get ALL highways that intersect that buffer.
4. Get public-transport route relations (bus, tram, subway, train, trolleybus, light_rail) that cross that buffer.
5. Each route relation as a single feature (MultiLineString).
6. Write to vienna_network.gpkg with EPSG code for Austria (MGI / Austria Lambert = EPSG:31287? Actually Austria's standard is EPSG:31287 (MGI Austria Lambert) or EPSG:31285 (MGI / Austria GK East). Let me check.)

Actually, the standard projected coordinate system for Austria is EPSG:31287 (MGI / Austria Lambert) for nationwide mapping, or EPSG:31255-31259 for GK zones. But "Austria's standard projected coordinate system" is likely EPSG:31287 (MGI / Austria Lambert) which covers all of Austria. Let me verify.

Let me write a comprehensive Python script using osmium to extract the data.

My approach:
- Use osmium to scan the PBF file
- First find all Gürtel ways (name endswith 'Gürtel')
- Build their geometries (as LineStrings)
- Compute their union and buffer by 500m (using shapely)
- Then find all highway ways that intersect that buffer
- Also find all PT route relations that cross that buffer

Actually, processing a 765MB PBF with osmium in multiple passes is feasible. Let me write a script that does it in stages.

Stage 1: Scan all ways to find Gürtel ways (name ends with 'Gürtel') and collect their node references.
Stage 2: Resolve node locations for those way nodes to build geometries.
Stage 3: Build the buffer.
Stage 4: Scan all ways again to find highways intersecting buffer.
Stage 5: Scan relations to find PT routes.
Stage 6: Build geometries and write to GeoPackage.

Actually, osmium can do this more elegantly. Let me use a handler-based approach.

Let me write the full script.

Actually, a simpler approach: use osmnx to download the data directly? But the Geofabrik PBF is already downloaded. Let me think...

osmnx might be easier for this! Let me check if osmnx can work with local PBF files.

Actually, osmnx uses the Overpass API typically. But it can work with local data too if we use OSMnx's graph_from_xml or similar. Hmm, but a PBF is not XML.

Let me just use osmium with Python. I'll write a comprehensive script.

Plan:
1. Use `osmium.SimpleHandler` to iterate through the PBF.
2. First pass: collect all ways where `name` ends with 'Gürtel'. Store their node IDs.
3. Second pass with `NodeLocationsForWays` handler to get node coordinates for those ways.
4. Build geometries of Gürtel ways using shapely.
5. Compute buffer (500m).
6. Third pass: iterate all ways again, find those with highway tag that intersect the buffer.
7. Fourth pass: iterate all relations, find PT route relations that intersect the buffer.
8. Write to GeoPackage.

Let me code this step by step.

Actually, let me think about a more efficient way. Since we need to do multiple passes, I can use the `FileProcessor` approach or just multiple handler passes.

Let me write a single Python script that does everything.

Let me think about the approach:

1. First, I need to find the Gürtel ways (highways whose name ends with 'Gürtel' in Vienna).
2. Then compute a 500m buffer around them.
3. Find all highways that intersect that buffer.
4. Find all PT route relations (bus, tram, subway, train, trolleybus, light_rail) that intersect the buffer.
5. Write both layers to a GeoPackage.

The PBF is 765MB, so reading it all with osmium is fine. Let me use a multi-pass approach:

**Pass 1**: Find all ways whose `name` tag ends with "Gürtel" and are highways. Get their coordinates (need node locations) and compute the buffer.

**Pass 2**: 
- For highways: Find all ways that intersect the buffer.
- For PT routes: Find all relations with `type=route` and `route` in (bus, tram, subway, train, trolleybus, light_rail), collect their member ways, and check if they intersect the buffer.

Let me think about this more carefully.

Actually, the simplest approach might be to use osmnx which has convenient functions for this. But with 765MB PBF, let me think...

Actually, osmnx uses Overpass API typically, not local PBF files. But osmium can read PBF files directly.

Let me use osmium with a handler approach:

**Step 1**: Read the PBF to find all Gürtel ways.
- Parse all ways, look for `highway` tag and `name` ending in "Gürtel"
- Store their node references

**Step 2**: Read the PBF again to get node locations for the Gürtel way nodes, build the linestrings.

**Step 3**: Compute the 500m buffer (in a projected CRS for accurate distances).

**Step 4**: Read the PBF again:
- For all ways with `highway` tag, check if they intersect the buffer
- For all relations with `type=route` and `route` in PT types, check if they intersect the buffer

This is a lot of passes. Let me think of a better approach.

Actually, with osmium I can:
1. First pass: extract all Gürtel way node IDs
2. Second pass: get all node coordinates for those IDs
3. Build the buffer geometry
4. Third pass: extract all highways and PT route relations intersecting the buffer

Let me write this step by step.

Actually, osmium has `NodeLocationsForWays` handler that can store node locations in memory. Let me use that approach.

Let me write the full script:

```python
import osmium
import geopandas as gpd
import pandas as pd
from shapely import wkb, wkt
from shapely.geometry import LineString, MultiLineString, box, Point
from shapely.ops import unary_union
import pyproj
import sys
import json

# --- Configuration ---
PBF_PATH = "/work/austria-latest.osm.pbf"
GPKG_PATH = "/work/vienna_network.gpkg"
BUFFER_METERS = 500
# Austria projected CRS (MGI / Austria Lambert - EPSG:31287)
PROJECTED_CRS = "EPSG:31287"
WGS84_CRS = "EPSG:4326"

project = pyproj.Transformer.from_crs(WGS84_CRS, PROJECTED_CRS, always_xy=True).transform
project_back = pyproj.Transformer.from_crs(PROJECTED_CRS, WGS84_CRS, always_xy=True).transform

# --- STEP 1: Find all Gürtel ways ---
class GuertelWayFinder(osmium.SimpleHandler):
    def __init__(self):
        super().__init__()
        self.guertel_ways = {}  # way_id -> {tags, nodes list}
    
    def way(self, w):
        if 'highway' in w.tags and 'name' in w.tags:
            name = w.tags.get('name')
            if name and name.endswith('Gürtel'):
                tags = {}
                for k, v in w.tags:
                    tags[k] = v
                self.guertel_ways[w.id] = {
                    'tags': tags,
                    'nodes': [n.ref for n in w.nodes]
                }

finder = GuertelWayFinder()
finder.apply_file(PBF_PATH)

print(f"Found {len(finder.guertel_ways)} Gürtel ways")

# Collect all node IDs from Gürtel ways
guertel_node_ids = set()
for way_data in finder.guertel_ways.values():
    guertel_node_ids.update(way_data['nodes'])

print(f"Total Gürtel way nodes: {len(guertel_node_ids)}")

# --- STEP 2: Get node locations ---
class NodeLocationHandler(osmium.SimpleHandler):
    def __init__(self, desired_nodes):
        super().__init__()
        self.desired_nodes = desired_nodes
        self.locations = {}  # node_id -> (lon, lat)
    
    def node(self, n):
        if n.id in self.desired_nodes:
            self.locations[n.id] = (n.location.lon, n.location.lat)

node_handler = NodeLocationHandler(guertel_node_ids)
node_handler.apply_file(PBF_PATH)

print(f"Retrieved {len(node_handler.locations)} node locations")

# --- STEP 3: Build Gürtel geometry in projected CRS ---
from shapely.geometry import shape, mapping
import shapely

def build_line_from_nodes(way_data, node_locs):
    coords = []
    for node_id in way_data['nodes']:
        if node_id in node_locs:
            coords.append(node_locs[node_id])
    if len(coords) < 2:
        return None
    return LineString(coords)

guertel_lines = []
for wid, wd in finder.guertel_ways.items():
    line = build_line_from_nodes(wd, node_handler.locations)
    if line:
        guertel_lines.append(line)

print(f"Built {len(guertel_lines)} Gürtel linestrings")

# Combine all Gürtel lines and project
guertel_union = unary_union(guertel_lines)
# Project to projected CRS
guertel_projected = shapely.ops.transform(project, guertel_union)
# Buffer in projected units (meters)
guertel_buf_projected = guertel_projected.buffer(BUFFER_METERS)
# Convert back to WGS84
guertel_buf = shapely.ops.transform(project_back, guertel_buf_projected)

print("Buffer computed")

# --- STEP 4: Find all highways intersecting buffer ---
class HighwayFinder(osmium.SimpleHandler):
    def __init__(self, buffer_geom):
        super().__init__()
        self.buffer = buffer_geom
        self.highways = []  # list of (linestring, tags)
        self.node_locs = {}
        self.collecting_nodes = set()
        self.interesting_way_ids = set()
    
    def way(self, w):
        if 'highway' in w.tags:
            tags = dict(w.tags)
            self.interesting_way_ids.add(w.id)
            # We'll build geometry later, for now just store tags
            self.highways.append((w.id, [n.ref for n in w.nodes], tags))
            self.collecting_nodes.update(n.ref for n in w.nodes)
    
    def node(self, n):
        if n.id in self.collecting_nodes:
            self.node_locs[n.id] = (n.location.lon, n.location.lat)

# Hmm, this approach needs all node locations for all highways... that's a lot.
# Better approach: do it in two sub-passes.
```

Actually, let me think about this differently. The PBF is 765MB, so reading it multiple times is okay but slow. Let me be more efficient.

Better approach:
1. Pass 1: Find Gürtel ways, get their node IDs
2. Pass 2: Get node locations for Gürtel ways, compute buffer
3. Pass 3: Find highways (store way IDs and node refs), AND find all nodes for those ways
4. Pass 4: Get node locations for all highway nodes, then build geometries and check intersection

Actually, reading the PBF 4 times might be slow. Let me try a different approach.

Alternative:
1. First, use osmium to get Gürtel ways and their nodes
2. Use osmium with NodeLocationsForWays to build all way geometries in one pass, and check intersections

Actually, `NodeLocationsForWays` is a handler that resolves node locations for ways. Let me check how to use it.

Let me think more carefully. I'll write a comprehensive script that does:

1. First scan for Gürtel ways + collect their node IDs
2. Second scan for Gürtel node coordinates  
3. Build buffer
4. Third scan: use NodeLocationsForWays handler to build way geometries, filter by buffer intersection, and also collect relations

Actually, with `osmium.NodeLocationsForWays`, I can use it as a location handler that's applied after reading nodes. Let me look at how to use it.

Actually, I think the best approach is:

1. Use `osmium.SimpleHandler` with `NodeLocationsForWays` as a filter chain to get all ways with their full geometries in one pass. But we need to know the buffer first...

Let me just write a multi-pass approach but combine some steps.

Plan:
- Pass 1: Find Gürtel way IDs and their node IDs
- Pass 2: Get node locations for Gürtel nodes
- Compute buffer
- Pass 3: Find all highway way IDs and their node IDs that might intersect (just collect all highway ways' nodes)
- Pass 4: Get node locations for those nodes, build geometries, check intersection

Actually, for highways there could be hundreds of thousands. Let me think about this more efficiently.

Alternative approach using osmnx + overpass: but we're using a local PBF.

Another approach: use `osmium` tags-filter to extract a smaller file first, then process that.

Let me try a more streamlined approach using the osmium tag-filter and geospatial filtering.

Actually, let me just go ahead and write the multi-pass approach. The PBF is 765MB, reading it 4 times will take a few minutes but should work.

Wait, actually, let me think about whether I can do this in fewer passes.

Pass 1: Find Gürtel ways + their node IDs
Pass 2: Get node locations for those nodes, build buffer

Then for highways:
Pass 3: For ALL ways with highway tag, collect node IDs (store way_id -> node_ids)
Pass 4: Get node locations for those highway nodes, build geometries, check buffer intersection

For PT routes:
I could do this in Pass 3/4 as well - store relation info and member way IDs.

Actually, let me rethink. Let me write a script that does everything in 3 passes:

Pass 1: Find Gürtel ways and their node IDs
Pass 2: Get node locations for Gürtel nodes, build buffer

Pass 3: Use a handler that:
  - For ways with highway tag, store way_id -> node_refs, tags
  - For relations with type=route and route in PT types, store relation info and member way IDs
  - For nodes, store locations if they belong to any way we care about

Then build geometries from the stored data.

Actually, the issue is that for Pass 3, we need to know which node IDs to collect BEFORE we read the nodes. But osmium processes nodes first, then ways, then relations. So we'd need to collect way node IDs first (from ways), then... but by then nodes have already been processed.

Hmm, this is tricky. The standard approach is:

Option A: Use `osmium.NodeLocationsForWays` which stores all node locations and resolves them for ways. But this stores ALL node locations in memory which for a 765MB PBF could be huge.

Option B: Two passes - first collect all needed node IDs from ways, then get their locations.

Let me go with Option B, but optimize:

Pass 3a: Read PBF, collect all highway way IDs and their node refs, collect all PT route relation details and their member way IDs
Pass 3b: From the collected node refs, get their locations
Pass 4: Build geometries and check intersection

Actually, let me see if `NodeLocationsForWays` can handle 765MB PBF. Let me check available RAM.

Let me just write the script and run it. I'll use a 3-pass approach.

Wait, actually I realize there's a cleaner approach using `osmium.FileProcessor` + filters + handlers. Let me try to write a clean solution.

Let me write the full script now.

Here's my plan for the script:

```python
import osmium
import geopandas as gpd
import pandas as pd
from shapely import geometry
from shapely.ops import transform, unary_union
import pyproj
import sys

PBF = "/work/austria-latest.osm.pbf"
OUT = "/work/vienna_network.gpkg"
BUFF_M = 500
CRS_PROJ = "EPSG:31287"

# --- PASS 1: Find Gürtel ways ---
class GuertelFinder(osmium.SimpleHandler):
    def __init__(self):
        super().__init__()
        self.ways = {}
        self.node_ids = set()
    def way(self, w):
        if 'highway' in w.tags and 'name' in w.tags:
            name = w.tags['name']
            if name.endswith('Gürtel'):
                tags = dict((k,v) for k,v in w.tags)
                nodes = [n.ref for n in w.nodes]
                self.ways[w.id] = {'tags': tags, 'nodes': nodes}
                self.node_ids.update(nodes)

gf = GuertelFinder()
gf.apply_file(PBF)

# --- PASS 2: Get Gürtel node locations ---
class NodeGetter(osmium.SimpleHandler):
    def __init__(self, wanted):
        super().__init__()
        self.wanted = wanted
        self.locs = {}
    def node(self, n):
        if n.id in self.wanted:
            self.locs[n.id] = (n.location.lon, n.location.lat)

ng = NodeGetter(gf.node_ids)
ng.apply_file(PBF)

# Build Gürtel linestrings
wgs84 = pyproj.CRS("EPSG:4326")
proj = pyproj.CRS(CRS_PROJ)
trans = pyproj.Transformer.from_crs(wgs84, proj, always_xy=True).transform
trans_back = pyproj.Transformer.from_crs(proj, wgs84, always_xy=True).transform

def build_line(node_ids, locs):
    pts = [locs[n] for n in node_ids if n in locs]
    if len(pts) < 2: return None
    return geometry.LineString(pts)

lines = [build_line(wd['nodes'], ng.locs) for wd in gf.ways.values()]
lines = [l for l in lines if l]
guertel_union = unary_union(lines)
# Project, buffer, project back
guertel_proj = transform(trans, guertel_union)
buf_proj = guertel_proj.buffer(BUFF_M)
buf_wgs84 = transform(trans_back, buf_proj)

# --- PASS 3: Collect highways and PT route info ---
class Collector(osmium.SimpleHandler):
    def __init__(self, buffer):
        super().__init__()
        self.buffer = buffer
        self.highway_ways = {}  # way_id -> {node_ids, tags}
        self.all_highway_node_ids = set()
        self.route_relations = []  # [{tags, member_way_ids}]
        self.route_way_ids = set()
        # store which way IDs are part of which PT route relations
        self.way_to_route = {}  # way_id -> list of relation indices
    
    def way(self, w):
        if 'highway' in w.tags:
            nodes = [n.ref for n in w.nodes]
            tags = dict((k,v) for k,v in w.tags)
            self.highway_ways[w.id] = {'nodes': nodes, 'tags': tags}
            self.all_highway_node_ids.update(nodes)
    
    def relation(self, r):
        if 'type' in r.tags and r.tags['type'] == 'route':
            route = r.tags.get('route')
            if route in ('bus', 'tram', 'subway', 'train', 'trolleybus', 'light_rail', 'railway'):
                tags = dict((k,v) for k,v in r.tags)
                member_ways = [m.ref for m in r.members if m.type == 'w']
                idx = len(self.route_relations)
                self.route_relations.append({'tags': tags, 'member_ways': member_ways})
                self.route_way_ids.update(member_ways)
                for wid in member_ways:
                    if wid not in self.way_to_route:
                        self.way_to_route[wid] = []
                    self.way_to_route[wid].append(idx)

coll = Collector(buf_wgs84)
coll.apply_file(PBF)

# We need node locations for all highway ways AND all route member ways
all_needed_nodes = coll.all_highway_node_ids | coll.route_way_ids
# Actually we need node locations for route member ways too
# But route member ways are a subset of highway ways? Not necessarily.
# PT routes can include ways that are not tagged with highway.
# So let's get node locations for all route member ways separately.

# Hmm, we need to re-read the PBF to get node locations for route member ways
# Actually, we also need to re-read to get the actual geometries of the route member ways
# because some route member ways might not be highway ways and won't be in highway_ways dict.

# Let me redo: I need to collect ALL ways that are either:
# a) tagged as highway, OR
# b) members of a PT route relation
# Then get their node IDs and locations.

# Let me redo pass 3 more carefully...
```

OK this is getting complex. Let me just write the complete script carefully.

Actually, let me simplify by reading the PBF multiple times. The PBF is 765MB, reading it maybe 4-5 times should take 5-10 minutes total, which should be acceptable.

Let me write a cleaner script:

Pass 1: Find Gürtel ways + their node IDs
Pass 2: Get Gürtel node locations
Pass 3: Find all highway ways + all PT route-related ways, collect their node IDs
Pass 4: Get all those node locations
Pass 5: Build geometries and intersect

Let me combine passes 3 and 4 differently. Actually, let me use `NodeLocationsForWays` which can handle large files if I give it enough memory.

Actually, let me just go ahead and write the script. I'll be pragmatic about it.

The script timed out after 600 seconds. The PBF file is 765 MB and we're doing multiple passes. The main issue is likely that we're doing full-file passes which each take a long time. Let me think about optimizations.

Actually, osmium applies to files by reading them sequentially. Each pass reads the entire 765 MB PBF. We're doing:
- Pass 1: Find Gürtel ways (full scan)
- Pass 2: Get Gürtel node coordinates (full scan)
- Pass 3: Collect highway ways + PT route relations + PT member ways (full scan)
- Pass 3b: Extra PT ways collection (full scan)
- Pass 4: All needed node coordinates (full scan)

That's 5 full scans of a 765 MB file. This is very slow.

We can optimize significantly. Let me think about the approach:

1. Instead of multiple passes, we can combine some. But the issue is that we need node locations - osmium processes nodes first before ways, but the callback order is: nodes, ways, relations (depending on how they are stored in the PBF).

Actually, in osmium, `apply_file` processes elements in file order. In PBF files, nodes are typically first, then ways, then relations. So if we try to find Gürtel ways in the first pass and then need their node coordinates, we can't get them in the same pass because nodes come before ways in the file.

Wait, actually in OSM PBF files, nodes, ways, and relations are typically stored in that order but not guaranteed. However, osmium's SimpleHandler will call the callbacks in the order the elements appear in the file.

Let me think about a better approach:

Option 1: Use `osmium.NodeLocationsForWays` which can build node locations on-the-fly. This is a handler that stores node locations and makes them available to subsequent way processing.

Option 2: Use osmnx which might handle all this more efficiently.

Option 3: Use a more efficient approach with fewer passes.

Let me try using `osmium.NodeLocationsForWays` which can handle the node-to-location resolution automatically. This would let us get way geometries in a single pass.

Actually, looking at osmium docs more carefully:

`osmium.NodeLocationsForWays` is a handler that stores node locations and makes them available as way nodes have their location set automatically when passed to the handler. So we can chain handlers.

But the issue is we need to:
1. Find Gürtel ways first (to know which ways to focus on)
2. Then filter highways and PT routes

Let me think about using osmnx instead. osmnx can download data from OSM and work with it directly. But we have the local PBF file - osmnx can't directly work with PBF files.

Alternative: Use `osmium` with a two-pass approach but optimize:

Pass 1: Find all ways (highway ways and PT route member ways) that we might need, along with their node IDs. Also collect PT route relations.
Pass 2: Get node coordinates for all needed node IDs.

This is essentially what I'm doing but the issue is the 5 full scans. Let me see if I can reduce to 2 scans.

Actually, looking at my code more carefully:
- Pass 1: Find Gürtel ways - needs to scan all ways
- Pass 2: Get Gürtel node coords - scans all nodes
- Pass 3: Collect highway ways + PT routes + PT member ways - scans all ways and relations
- Pass 3b: Extra PT ways - scans all ways again
- Pass 4: All needed node coords - scans all nodes

We can combine Pass 3 and 3b into a single pass. But the main issue is we have 5 full scans.

Let me redesign:

Pass 1: Scan ways to find Gürtel ways (those ending in 'Gürtel' with highway tag).
   Also scan relations to find PT route relations.
   Also scan ways to find all highway ways (tagged with highway).
   We can do this in a single pass since osmium calls way() and relation() callbacks.

But wait, to find which ways are relevant, we need to know the Gürtel geometry first (to build the buffer). So we need at least:
- Pass 1: Find Gürtel ways and their node refs
- Pass 2: Get Gürtel node coords, build buffer
- Pass 3: Scan all ways again, check which intersect the buffer, and also collect PT route relation info and their member ways
- Pass 4: Get node coords for all needed ways

That's 4 passes minimum. But we can try to speed up the file reading.

Actually, osmium can process files in chunks with `osmium.FileProcessor` or we can use `osmium.apply` with multiple handlers. Let me think about using `osmium.NodeLocationsForWays` handler.

Actually, the simplest optimization is to use `osmium.NodeLocationsForWays` handler and process everything in 2 passes:

Pass 1: Find Gürtel ways + get their node locations using NodeLocationsForWays
   - Actually NodeLocationsForWays only works if nodes come before ways in the file
   - In PBF, nodes typically come before ways
   - So a handler chain of [NodeLocationsForWays, GuertelWayFinder] should work

Pass 2: Find all highway ways intersecting buffer + PT routes + their member ways
   - Use NodeLocationsForWays + a handler that checks buffer intersection
   - Build geometries on the fly

Let me try this approach.

Actually, let me just try to speed things up by combining passes and using a more efficient approach. Let me look at what took so long.

The file is 765 MB. Reading it sequentially at ~100 MB/s would take about 7-8 seconds per pass. With 5 passes, about 40 seconds of I/O time. But Python overhead and the handler processing might slow things down significantly.

The timeout was 600 seconds (10 minutes) which is a lot. Something must be very slow.

Let me check: in Pass 3, I'm collecting ALL highway ways and ALL PT route relations from the entire PBF of Austria. Austria has a LOT of highway ways. Let me see if the issue is memory or processing speed.

Actually, the Collector2 handler processes ALL ways in Austria looking for highway tags. That could be millions of ways. Each way callback creates a dict of tags and a list of nodes. For all 2M+ ways in Austria, this consumes a lot of memory and time.

Let me think about a smarter approach:

1. Find Gürtel ways first (small subset)
2. Build the buffer
3. In the second pass, only scan ways and check if they intersect the buffer roughly

But we can't easily check intersection without knowing the way's geometry, which requires node coords...

Let me try using osmnx instead. osmnx can:
- Download from OSM within a bounding box/polygon
- Or work with OSM data directly

But we need to use the local PBF file. osmnx can't read PBF directly.

Another approach: Use `osmium` with a handler that uses `NodeLocationsForWays` and processes in a single pass.

Let me think again about the two-pass approach:

**Pass 1**: Find Gürtel ways (ways with highway tag and name ending 'Gürtel')
- We scan all ways. For each way with highway tag and name ending Gürtel, we record its node IDs.
- Then we scan all nodes (or have a second pass) to get those node locations.
- Build the buffer.

**Pass 2**: Find highways and PT routes intersecting buffer
- Use NodeLocationsForWays to get way geometries
- For each way (with highway tag), check if it intersects the buffer. If yes, collect.
- For each relation (with route tag in our list), record it and its member way IDs.
- Since NodeLocationsForWays resolves nodes for ways, we can get way geometries.

But in Pass 2, we need to know which member ways of PT routes are relevant. We could:
- Collect all PT routes (there aren't that many)
- For each PT route, check its member ways' geometries (which we now have from NodeLocationsForWays)
- Check if any member way intersects the buffer

So the approach would be:

Pass 1: Find Gürtel ways (simple, no need for node coords yet), extract their node IDs, then scan again for those node coords. Build buffer.

Actually, let me try a completely different approach. Use `osmium` to extract just the Vienna area first using a bounding box, then work with that smaller dataset.

Vienna is roughly at lat=48.2, lon=16.37. The Gürtel is a ring road around the inner districts. Let me extract a bounding box around Vienna first.

Or better yet, let me use `osmium` with a filtered approach. The `osmium` tool (not Python library) has command-line tools that can filter by bounding box. Let me check if `osmium` is installed.

Actually let me check what's available:

The script timed out after 600s. The PBF is 765MB and we're scanning it multiple times. Let me think about how to optimize this.

The main issues:
1. We're scanning the 765MB PBF multiple times (Pass 1, Pass 2, Pass 3, Pass 3b, Pass 4 = up to 5 passes!)
2. The buffer computation might be slow

Let me optimize by:
1. Using a single pass to collect everything needed (Gürtel ways, highway ways, PT routes)
2. Using a second pass for node locations
3. Maybe using `osmium` tool command line utilities for faster processing

Or I could use OSMnx which is already installed and might be faster for this use case.

Actually, let me think about this differently. OSMnx can easily:
1. Get the Gürtel streets by querying name
2. Get the surrounding network within a buffer
3. Get the PT routes

But OSMnx works with Overpass API, not local files. Let me check if we can use the local PBF with OSMnx or if we need to use osmium/pyosmium differently.

Actually, let me try a more efficient approach: use osmium to do it in fewer passes, and use the osmium Python bindings more efficiently.

Let me rewrite to:
1. First pass: Find Gürtel ways (way IDs, node IDs, tags)
2. Second pass: Get Gürtel node coordinates
3. Build buffer
4. Third pass: In ONE pass, collect highway ways that intersect the buffer (or store all ways and filter later) AND PT route relations AND their member ways' node refs
5. Fourth pass: Get all needed node coordinates
6. Build geometries

The issue was probably that Pass 3 stores ALL highway ways (which could be millions) or that the file reading is slow.

Let me think about osmium more carefully. The `osmium` tool (command line tool) might not be installed, but the Python `osmium` module is installed.

Actually, the timeout at 600s (10 min) is probably due to iterating over the whole 765MB PBF multiple times. Let me try a smarter approach:

1. First, let me just use `osmium` command-line tools to filter, since they're much faster than Python.
2. Or, I can use OSMnx with the local file via a custom approach.

Wait, let me check if osmnx can work with local files.

Actually, looking at the osmium Python module more carefully, I should use `osmium.FileProcessor` which is faster. Also, the issue might be that `apply()` on the full file just takes a long time in Python.

Let me try a different approach: use the `osmium` command-line tool (if available) to extract just Vienna, then work with that smaller dataset.

Let me check what's available.

The osmium Python package is installed but the osmium command-line tool isn't. The Python-based approach is very slow for a 765MB PBF because it reads the file 4 times. Let me think about a more efficient approach.

Actually, the issue is that reading the entire PBF multiple times from Python is slow. I could:

1. Use `osmium` command-line tool if available, but it's not.
2. Use `osmnx` which can filter by bounding box, but we need to define the buffer first.
3. Use a more efficient approach: maybe read the PBF once with all the filtering logic in one handler.

Let me rethink. The slowest part is probably reading the PBF 4 times. Let me try to combine passes.

Actually, the timeout could also be because the script is just too slow due to Python overhead. Let me think about alternatives.

Option 1: Use osmnx to download the data directly from Overpass API. But the user specifically asked to use the Geofabrik PBF.

Option 2: Use osmium to filter to just Vienna area, then process.

Option 3: Use a single pass through the PBF with the handler doing everything.

Let me try using osmnx's graph_from_place or similar, or use a spatial filter with osmium.

Actually, osmium's SimpleHandler.apply_file can be slow. But maybe we can use pyosmium (the lower-level C++ bindings) more efficiently, or use a separate tool.

Let me think about this differently. The Python osmium bindings read the PBF in one pass, so we can combine all our handlers into one. Let me rewrite:

Pass 1 (one read): 
- Find Gürtel ways, collect their node IDs
- After the pass, build Gürtel geometry and buffer
- Can't do this because we need to know the buffer before filtering other features

Alternative: Two passes:
1. First pass: Find Gürtel ways, get their node locations, build buffer
2. Second pass: Filter all highways and PT relations by the buffer

That's 2 reads instead of 4. Let me try that.

But even 2 reads of a 765MB file might be slow with Python. Let me check if there are faster alternatives.

Actually, maybe I can use osmnx's `graph_from_point` or `graph_from_address` to get the Gürtel network, but the user specifically wants the Geofabrik file.

Another option: Use osmium's `NodeLocationsForWays` handler which caches node locations, so in a single pass we can:
1. Collect Gürtel way node refs
2. After the pass, reconstruct the Gürtel geometry, buffer it
3. But we'd need to pass through the file again to collect intersecting features

Hmm. Let me try a different approach: use the pyosmium with NodeLocationsForWays to store node locations, and do everything in two passes.

Actually, let me try with a smaller test first to see if the script logic works, then optimize.

Wait, actually maybe the issue is that the first pass (finding Gürtel ways) took forever because the Python PBF reader is slow when iterating over the entire file. Let me check if we can use the command-line osmium tool.

Let me install osmium-tool.

The osmium Python library is iterating over the full PBF which is huge. Each pass touches every object in the file. Let me check sizes. The PBF is 765M. Each pass through the whole file could be slow.

But 600 seconds should be enough... Let me check if the process is still running or what happened. Actually it timed out. Let me look at what's happening differently.

Maybe I can use a more targeted approach. Let me use `osmium` command-line tool instead, or use a filter to only extract relevant data. But I don't have the CLI tool installed...

Let me try using OSMnx instead which might be more efficient for this specific query? Or I could use pyosmium with more efficient filtering.

Actually, maybe the issue is that the Python osmium library's `apply_file` is very slow with large files when using SimpleHandler. Each pass reads the entire file.

Let me try a more efficient approach: use one pass only, collecting everything at once.

Actually wait - the issue might be that the first pass takes too long. Let me check if there's a simpler way. Let me try using OSMnx first to get the Gürtel buffer and then use osmium filtering.

Actually, let me think about this differently. The osmium Python library applies_file with SimpleHandler. For a 765MB PBF, reading it once should take maybe 30-60 seconds. But I'm doing 4 passes over the file! That's 4x 60s = 240s minimum, and probably more.

Let me combine the passes:
- Pass 1: Find Gürtel ways, get their nodes -> Done in one pass
- Pass 2: Get Gürtel node coords -> One pass
- Pass 3: Collect highway ways + PT route relations + their nodes -> One pass
- Pass 4: Get all needed node coords -> One pass

That's 4 passes. Can I reduce this?

Actually, I can do:
1. Find Gürtel ways and their nodes (pass 1)
2. Get Gürtel node coords (pass 2)  
3. Collect highways, PT routes, their member ways, and get all their node coords in ONE pass

Wait, but I can't get node coords in the same pass as ways and relations because ways and relations reference nodes, but the nodes might come after the ways in the file.

Actually, the osmium library uses `NodeLocationsForWays` handler which can store node locations and use them when processing ways. So I can do it in 2 passes:
1. Find Gürtel ways and their node coords
2. Collect highways + PT routes, using node locations to build geometries and test intersection

Let me restructure. But first, let me check if the first pass even completes.

Actually, the issue is the timeout of 600s. Let me check if the process was killed or what happened. Exit code -1 means timeout.

Let me try running just the first pass to see how long it takes.

The file is 765MB and reading it with osmium is taking extremely long. This is a huge file. Let me check if I can use a faster approach - maybe using osmnx which can download just Vienna, or use osmosis/osmium-tool command line which might be faster. Or I could try to approach this differently.

Let me think about this differently. The Geofabrik PBF for all of Austria is huge. Instead of reading the whole file with Python, I could:

1. Use osmium tool (command line) to filter just the Vienna area first, then work with a smaller file
2. Or use osmnx to get Vienna data directly from the API

Actually, osmnx can download from the OSM API directly. Let me try that approach - it'll be much faster for a city-scale extraction.

Let me think about what we need:
1. Find Gürtel ways - ways whose name ends with "Gürtel" in Vienna
2. Buffer them by 500m
3. Get all highways that intersect that buffer
4. Get all PT route relations that cross that buffer

osmnx can:
- Get streets by name
- Get the graph within a bounding box
- etc.

But for PT routes, osmnx might not be ideal. Let me think about a hybrid approach.

Actually, let me try using osmnx to get the Gürtel geometry first, then use that to filter.

Or even better - use osmium-tool (the C++ command-line tool) to filter the PBF to just Vienna, then process the smaller subset.

Let me see if osmium-tool is available or can be installed via pip.

The Python osmium library is very slow for the full Austria PBF (765MB). Let me try a different approach using `osmnx` (which uses OSMnx to download and filter) or using `osm2pgsql` or something. 

Actually, let me think about this more carefully. The issue is that `osmium` in Python reads the entire PBF, and the full Austria file is huge. The problem is that in the first pass, we're reading all nodes/ways/relations which takes too long.

Let me try a different approach:
1. Use `osmnx` to get the Gürtel ways and the buffer area
2. Use `osmnx` to get highways in that area
3. For PT routes, use a more efficient approach

Actually, osmnx uses the Overpass API which requires internet connectivity. Let's check if that's available.

Wait, actually the timeout was 600 seconds (10 minutes) - that should be enough. But maybe the Python osmium library is just very slow for reading 765MB of data. Let me try with a much more optimized approach.

Actually, let me try a completely different strategy. Let me use `osmnx` to query Vienna directly, since osmnx can filter by custom filters and fetch from Overpass.

Let me think about what's more practical:
1. OSMnx can fetch by polygon/bbox and custom tags
2. The Overpass API will be faster for this kind of targeted query

Let me try osmnx first.

The osmium Python library is very slow for full-file reading. Let me try a different approach. Maybe use `osmium` command-line tool or use `geopandas` with `pyogrio` to read the PBF, or use `osmnx` with a smaller bounding box approach.

Actually, let me check if there's a way to use osmnx or direct reading with geopandas/pyogrio more efficiently.

The PBF is 765 MB which is big but should be manageable. Let me try using pyogrio to read the file directly, or use duckdb's spatial extension.

Actually let me try a different approach - use osmnx with a bounding box query for Vienna, or use duckdb to filter the data.

Let me check what tools are actually fast enough for this.

Interesting! Pyogrio can read OSM PBF directly as layers! That's much faster. Let me use that approach instead of iterating through the PBF with osmium.

Let me think about the approach:

1. Use pyogrio to read the `lines` layer, filter for `highway` ways with `name` ending in 'Gürtel'
2. Buffer those by 500m
3. Read all lines that intersect the buffer (highway ways)
4. Read relations to find PT route relations, then get their member ways

But pyogrio might not handle relations well. Let me check what pyogrio can do with the PBF.

Actually, pyogrio uses GDAL/OGR's OSM driver which has limitations:
- The `lines` layer contains all ways as linestrings (already built geometries!)
- The `multilinestrings` layer contains relations that form multilinestrings
- The `other_relations` layer has route relations etc.

So I can:
1. Read the `lines` layer with pyogrio, query for highway ways with name like '%Gürtel'
2. Buffer those
3. Read all lines intersecting buffer (filter by highway)
4. For PT routes, read `other_relations` and find route relations, then use their member ways

Let me check what attributes are available.

Great! pyogrio can read directly from the OSM PBF and supports SQL WHERE clauses. Let me try a much faster approach using pyogrio (which internally uses GDAL/OGR's OSM driver).

Actually, pyogrio can read from OSM PBF files using GDAL's OSM driver. Let me check if the SQL syntax works for filtering by name LIKE '%Gürtel' and highway.

Let me design a much more efficient approach:

1. Read all lines with name ending in 'Gürtel' to find the Gürtel ways
2. Compute their buffer
3. Read lines intersecting the buffer (for highways)
4. Read relations (PT routes) and their member ways

Actually, pyogrio can read lines, but the question is about relations. Let me check what the other_relations layer contains.

Let me also try using DuckDB with spatial extension which can read PBF files directly.

Hmm, the OSM PBF layer "other_relations" has `other_tags` as a string column. The route relations might be there. Let me check the "multilinestrings" layer too which might have route relations.

Actually, the standard OGR OSM driver reading of a PBF has layers: points, lines, multilinestrings, multipolygons, other_relations.

Route relations could be in "multilinestrings" or "other_relations". Let me check.

Also, I need to find the Gürtel ways first. Let me query them.

The query is working. But it's finding Gürtel ways all over Austria (Graz has a Gürtel too - Weblinger Gürtel, Waltendorfer Gürtel, etc.). I need to focus on Vienna's Gürtel. Let me check what Gürtel ways are in Vienna.

Actually, the user says "Vienna's Gürtel" which is specifically the ring road around the inner city districts. The ones in Vienna are: Währinger Gürtel, Döblinger Gürtel, Hernalser Gürtel, Lerchenfelder Gürtel, Mariahilfer Gürtel, Gumpendorfer Gürtel, Sechshauser Gürtel, Gaudenzdorfer Gürtel, Wiedner Gürtel, Landstraßer Gürtel. The ones in Graz (Weblinger Gürtel, Waltendorfer Gürtel, Eggenberger Gürtel, etc.) are clearly not in Vienna.

So I should filter by the bounding box of Vienna or by the actual location. Let me use a different approach: first get the Gürtel ways that are in/near Vienna by doing a spatial filter, or just find all that end with 'Gürtel' and then filter by those whose geometry is within Vienna's general area.

Actually, let me think about this more carefully. The user says "Vienna's Gürtel, defined as the highway ways whose name ends in 'Gürtel'". So they want ALL highways whose name ends in Gürtel, and then buffer around them. But many Gürtel ways are in Graz, not Vienna. 

The user says "Vienna's Gürtel" - so they're referring to the specific ring road in Vienna. Let me filter by a bounding box around Vienna first.

Let me use osmnx to get the Vienna boundary, or just use a bounding box.

Actually, I think the simplest approach: get all Gürtel ways from the PBF, filter those whose centroids fall within a bounding box around Vienna, then proceed.

The approach using pyogrio with multilinestrings might work for PT routes, but the multilinestrings layer may not contain all route relations properly. Let me think about this more carefully.

In OSM PBF files read by OGR/GDAL (pyogrio):
- `lines`: ways that are simple linestrings (most highways, etc.)
- `multilinestrings`: ways that are multilinestrings (generally not common)
- `other_relations`: relations of type other than boundary, multipolygon, etc. These include route relations
- `multipolygons`: multipolygon relations

For PT routes (route relations), the `other_relations` layer has them. But they have `GeometryCollection` geometries. Each relation has member ways, and OGR creates a geometry collection from the member way geometries.

Wait, actually OGR for OSM does create geometry for route relations from their member ways. Let me check if the other_relations layer already has proper geometries for route relations.

Let me test this.

The multilinestrings layer contains PT routes with their geometries already built. This is great! Now I need to:

1. Find all Gürtel ways (highway, name ends with Gürtel) in Vienna
2. Compute 500m buffer
3. Read highway lines intersecting buffer
4. Read PT route multilinestrings intersecting buffer

Let me rewrite the script properly.

Wait, the multilinestrings layer's `name` column might be the route name already. Let me check the column names more carefully. The issue is that when we read the multilinestrings layer, it has `osm_id, name, type, other_tags, geometry`. The `name` column is the OSM name tag (which could be the route name). The parsed `rname` from `other_tags` would be `name` from other_tags, but that might be redundant. Let me check what `name` in the multilinestrings layer actually is.

Also, I need to be careful: the `name` column in the output should be the route name from the OSM name tag. And the `ref` should be from the ref tag (which is in other_tags).

Let me run the script and check.

The output looks good. Let me also check:

1. That the `name` column in pt_routes is from OSM (which comes from the OSM 'name' tag), not from the parsed other_tags. Actually looking at the output, the `name` column shows None for most routes - that's because the OSM `name` field in the multilinestrings layer is the OSM name tag. For routes, the name tag often isn't set directly but rather in other_tags. Let me check what's happening with the name column.

Looking at the code, I used `gdf_pt[out_cols]` where `out_cols` includes 'name'. The `name` column in the multilinestrings layer is the OSM `name` tag. For route relations, the name is often stored in the `name` tag (OSM column) or in `other_tags`. Let me verify.

Actually, looking at the sample output, the routes have `name=None`. But some might have names. Let me check if the 'name' column in the original OSM multilinestrings layer is actually the OSM `name` tag or something else.

From the earlier test, multilinestrings has columns: ['osm_id', 'name', 'type', 'other_tags', 'geometry']. The 'name' column is the OSM `name` tag. For route relations, the `name` tag is often not set - it's the `ref` tag that's more commonly used.

But wait - the user asked for `name` attribute on PT routes. The OSM name tag for routes might be empty. Let me see if we should use the name from other_tags instead.

Actually, looking at the code more carefully: I have both 'name' (from OSM multilinestrings) and 'rname' (parsed from other_tags). But in the output I used 'name' not 'rname'. Let me fix this to use the parsed name if the OSM name is None.

Actually wait - looking at the code output for `pt_routes`, the `name` column is present but shows empty for most routes. The column I wanted was the OSM `name` tag. But actually for route relations, the `name` tag might be in either place. Let me check what we have.

Let me also double-check the buffer is reasonable - 218 Gürtel ways in Vienna area seems plausible. And 9230 highway features in the buffer seems reasonable.

Actually, I notice there's a potential issue: the user asked for the highway ways from Vienna's Gürtel specifically (ways whose name ends in 'Gürtel'), and then EVERY highway intersecting a 500m buffer around those Gürtel ways. That's what we did.

Let me also verify the PT routes have the correct name column. Let me check what names exist.

The output looks good. Let me check if the 'name' column in PT routes actually has the route names (not just the ref). Looking at the sample, the `name` column is populated for all 383 routes, but I notice in the output the names aren't showing - probably because they're long and the display truncates. Let me check more carefully.

Actually, looking at the code again, the `name` column in the output is from the OSM `name` tag of the relation, not the `rname` I parsed from other_tags. Let me check if the OSM `name` field in the multilinestrings layer actually has meaningful route names.

Let me also verify that the highways have their attributes properly (not all None).

The output looks good. The PT routes have names and refs. Let me check that the highways also have proper data and verify the file size.

Let me also double-check that the 'name' column in PT routes is populated (it looks like it is - "name" column from the OSM multilinestrings layer is being used, which has nice descriptions like "U3: Ottakring => Simmering"). 

Let me also check that the highways layer is indeed LineString (not MultiLineString) and the PT routes are MultiLineString.

The script worked well. Let me verify the output file size and do a quick sanity check.

The output looks great. Let me clean up the debug buffer layer that was added earlier.

Actually, looking at the code, I wrote a `_debug_buffer` layer in the first version but the script was rewritten. Let me check if there's a stray layer.

Actually, looking at my first script, I wrote `buf_gdf.to_file(OUT, layer='_debug_buffer', driver='GPKG')` in the first attempt, but then I rewrote the script. However, since the file was overwritten by the new script's `to_file` calls, the old buffer layer shouldn't be there. The layers listed show only `highways` and `pt_routes`. So it's clean.

Let me also remove the downloaded PBF to save space if needed.