Lombardia Trains MCP

롬바르디아 주 열차에 관한 질문에 답하는 MCP 서버입니다: 출발 및 도착 안내판, 실시간 지연, 승강장, 정차역별 진행 상황, 운행 취소 및 혼잡도 — 그리고 환승이 포함된 여정을 Regione Lombardia가 오픈 데이터로 공개하는 지역 시간표에서 계획합니다. 공개된 ViaggiaTreno(RFI/Trenitalia) 및 Trenord API를 읽습니다. API 키도, 계정도, 스크래핑도 필요 없습니다.

> is the next train to Malpensa on time?

Departures — MILANO CADORNA (S01066), 21:29
  21:23  REG787    SEVESO                       +2'  platform 9
  21:26  REG387    MALPENSA AEROPORTO TERMINA   -2'  platform 1
  21:32  REG887    SARONNO                       0'  platform 6

설치

dotnet tool install -g LombardiaTrains.Mcp

그런 다음 MCP 클라이언트에 등록하세요. Claude Desktop의 경우 claude_desktop_config.json에서:

{
  "mcpServers": {
    "lombardia-trains": {
      "command": "lombardia-trains-mcp"
    }
  }
}

Claude Code의 경우:

claude mcp add lombardia-trains -- lombardia-trains-mcp

Related MCP server: MCP Trenitalia

도구

역 인수는 코드(S01700) 또는 이름(milano centrale)을 사용하며, 시간은 오늘용 HH:mm 또는 다른 날짜용 ISO 2026-08-29T09:00을 사용합니다.

세 가지 동작이 존재하는 이유는 호출자가 사람이 아니라 언어 모델이기 때문이며, 각각은 자신 있는 오답을 방지합니다:

• now가 존재하는 이유는 모델이 로마의 날짜를 신뢰할 수 있게 알지 못하기 때문이며, 모든 상대적인 질문 — "오늘 밤", "토요일" — 은 다른 도구를 호출하기 전에 먼저 하나가 필요합니다.

• 모호한 이름은 절대 암묵적으로 해석되지 않습니다. "Milano"는 스물여섯 개의 역과 일치하며, 많은 도시에는 국가 역과 완전히 다른 열차가 운행되는 별도의 "Nord" 역이 둘 다 있습니다. 도구는 첫 번째를 선택하고 확신하는 것처럼 보이는 대신 목록을 반환하고 질문합니다.

• 알 수 없는 곳은 커버리지가 끝나는 지점을 알려줍니다. Lugano를 물어보면 서비스가 커버하는 내용을 설명하여 모델이 스위스행 열차를 지어내는 대신 거절할 수 있게 합니다.

find_connection은 직행 열차만 찾으며, 그렇게 명시합니다. 시간표가 아닌 실시간 출발 안내와 각 후보 열차의 정차 목록을 읽으므로 지연 시간과 승차장을 포함하지만 환승을 조합하지는 못합니다.

find_journey는 하나를 조합합니다. 지역 시간표에서 계획하고, 그 시간표가 이르지 못하는 곳은 스위스 공개 데이터로 대체하며, 지연 시간이 없는 예정 시간을 반환합니다 — 두 도구는 같은 질문의 서로 다른 절반에 답하며 함께 사용하도록 만들어졌습니다.

여정은 출발이 아닌 *도착 기준으로 순위가 매겨집니다. 어딘가 가는 법을 묻는 사람은 가장 빨리 도착하고 싶어 하며, 출발 기준으로 순위를 매기면 4분 일찍 출발하지만 40분 늦게 도착하는 열차가 목록의 맨 위에 오게 됩니다.

환승은 한 번만 검색됩니다. 환승이 두 번이면 검색 공간과 조용히 틀릴 수 있는 방법이 몇 배가 되고, 이 네트워크에서 가치 있는 거의 모든 곳은 한 번의 환승으로 도달할 수 있기 시작 — 그래서 제한은 불완전한 검색 뒤에 숨기지 않고 명시합니다.

읽을 가치가 있는 부분

두 상위 API 모두 공개, 무문서, 그리고 약간 적대적입니다. 이 저장소의 대부분의 작업은 그 API를 호출하는 것이 아니라 살아남는 것입니다. 다음 각 항목은 코드에서 강제되고 테스트로 보장됩니다.

Trenord는 기대지 않지만 두 개의 헤더를 원함

요청이 Accept 헤더와 User-Agent 모두 를 포함하지 않으면 Trenord는 403 Forbidden으로 답합니다:

이것은 반만 맞추기 쉽습니다. curl 또는 Python으로 엔드포인트를 탐지하면 Accept만으로 충분하다는 것을 제안하는데, 둘 다 요청하지 않아도 자신의 User-Agent를 보내기 때문입니다. .NET의 HttpClient는 지시하지 않으면 두 헤더를 모두 보내지 않기 때문에, Accept만 설정하는 클라이언트는 계속 403을 받고, 처음 손으로 호출해 본 머신이 아닌 프로덕션에서 그 사실을 발견합니다.

그것이 TrenordClient가 생성자에서 둘 다 설정하는 이유입니다.

선택적 필드는 null이 아니라 부재함

average_crowding, average_crowding_label, suppression_type 및 alerts 는 보고할 것이 없을 때 Trenord 페이로드에 전혀 나타나지 않습니다. null이 아닙니다: 속성 자체가 없습니다.

다섯 개의 일반 서비스(S5, S11, RE_5, R27)로 확인: 그 중 어느 것도 네 가지 중 어떤 것도 지니고 있지 않았습니다. 이 필드들이 존재한다고 가정하는 코드는 따라서 문제가 있는 기차에서는 작동하고 문제가 없는 기차에서는 충돌하며, 이것은 가능한 최악의 방향입니다.

타임스탬프는 세 가지 다른 형태로 제공됩니다.

• Trenord dep_time / arr_time — 로컬 시간, "HH:MM:SS". 표시하기 안전합니다.

• Trenord dep_date_time / arr_date_time — UTC 기준 ISO 8601, Z 포함. 날짜 연산에 편리하지만, 그대로 보여주면 틀립니다.

• ViaggiaTreno — epoch 밀리초, 항상 Europe/Rome을 명시하여 변환해야 합니다. 머신의 로컬 시간으로 변환하면 이탈리아 노트북에서는 올바른 답이 나오지만 UTC 서버에서는 틀린 답이 나옵니다.

ViaggiaTreno는 JavaScript의 날짜 표기 방식을 원함

보드 엔드포인트는 Date.toString()이 표기하는 방식으로 표기된 타임스탬프를 받습니다:

Mon Aug 10 2026 20:20:00 GMT+0200

안 날짜 및 월 이름은 영어여야 합니다. 의도적으로 고정 배열에서 구축됩니다: 머신의 culture를 통해 형식해도 이탈리아 시스템에서는 lun ago가 생성되고 엔드포인트는 조용히 아무것도 반환하지 않습니다.

또 다른 두 가지 작은 것

• ViaggiaTreno의 열차 조회는 JSON이 아닌 일반 텍스트로 답하며, 실행당 한 줄입니다. live-progress 엔드포인트에 필요한 필드가 | 뒤에 있습니다.

• 보고 할 것이 없으면 빈 배열 대신 빈 본문을 반환하기도 합니다. 이는 순진한 역직권자에게 예외를 발생시킵니다.

• train_operator는 literal로 $:$를 구분 문자로 사용합니다.

포털의 복사본이 아닌 운영자의 파일을 읽기

Trenord는 이 시간표를 CC0으로 라이선스된 GTFS zip으로 게시하며, 같은 포털은 이를 각 파일당 하나의 쿼리 가능한 테이블로 펼쳐서 제공합니다. 테이블은 더 쉬운 옵션으로 보입니다 — 페이지 기능, 필터 가능, 압축 풀 필요 없음 — 그러나 손실이 있는 복사본입니다. 그들이 내부에서 만들어진 파일에 대해 측정하면:

시간표의 대부분은 가져오기에 살아남지 못하며, 깔끔하게 사라지지 않습니다: 트립은 잘리겨서 도착합니다. 열행 11827은 Varese에서 Milano까지 운행하지만, 테이블에서는 Porta Garibaldi에서 멈추므로, 승차 중 관할 수 있는 모든 것이 회색으로 보이고, Varese에서 Bergamo까지는 공개된 답보다 한 시간 더 안 좋은 결과를 냈다. zip을 읽으면 분 단위로 일치합니다.

가져오기가 깨뜨리는 다른 세 가지는 것으로 각각 실제 코드로 해결해야 하며, 그 중 어느 것도 파일에서 잘못된 것이 아닙니다:

• 시간이 자리 표시자 날짜에 속해 있습니다. GTFS는 자정 이후의 서비스 를 24:05로 씁니다. datetime은 이를 포함할 수 없으므로 자동으로 00:05가 되고 열차가 출발하기 18시간 전에 도착합니다. 파일은 24:05라고 합니다.

• 서비스 id가 해시로 다시 쓰이며 calendar_dates의 것과 더 이상 일치하지 않으므로 두 파일의 공유 키로 조인할 수 없습니다. 둘을 하이픈 앞의 숫자로 잘래내면 다시 조인되고 — 열차의 모든 계절적 변형을 하나로 합치며, 어느 것이 오늘 운하는지 말할 수 없습니다. 파일에서 trips 와 calendar_dates는 모두 1001A-2025-12-14-2026-12-12를 씁니다. 조인은 정확하고 모호성을 없음.

• trip_short_name이 완전히 제거됩니다. 그것은 열차 번호입니다 — 계획된 구간을 실시간 데이터에 연결하는 하나의 필드입니다.

좌표의 소수점도 사라지고, route_type도 다릅니다. 테이블은 R23 과 RE4를 열차라고 하지만, 파일은 버스라고 합니다.

운영자에게도 물어, 그러고 나서 말하길

파일은 운영자의 직접적인 답도 아닙니다. 여 그리고 그 차이의 크기에 대해 정확하는 것이 좋습니다. 운영자의 자체 플래너가 같은날에 발행한 28개의 여행을 확인:

• Milano Centrale에서 Bergamo까지: 피드의 열차 2217을 48분으로, 운영자는 52분으로 진행합니다.

• Pavida에서 Mortara까지: 열차 10668은 피드에는 09:28에, 답에는 09:23에 도착합니다.

• Lecco에서 Bergamo까지: 열차 10719가 피드에서는 Pte S.Pietro에 08:52에 도하지만, 연결 버스는 08:51에 출발합니다 — 피드 자체가 불가능하게 하는 연결이며, 운영자의가 작동하고 5분의 여유가 있습니다.

운영자는 내부 시간표를 HAFAS로 실행하고 실시간을 포함합니다. 그 GTFS 를 내보낸 것은 아닙니다. 하지만 여기의 실시간 정보는 운영자 자신의 것이며, 파일은 열차 번호를 담고 있으므로 모든 구간을 간단히 조회하고 물을 자연해서, 그 대답이 있는 곳에서는 그 시간이 표시되고, 시간표 것은 옆에 괄호로 유지되며, 승장, 지연 및 취소가 함께 옵니다.

동일한 그 28개 여행에 대해 이 변경으로 정확한 일치가 22개에서 27개로 늘어납니다.

남은 하나는 이것이 할 수 없는 것의 모양입니다. Lecco에서 Bergamo까지는 여전히 08:51이 아닌 09:01 버스로 답변하는데, 이유는 피드가 기차가 08:52 에 도착했다고 말했고 검색이 그 연결을 확인하기 전에 무시해버렸기 때문입니다. 계획 후에 교정은 표시된 것을 수정합니다; 잘못된 데이터가 제외한 것을 되살리하지 못합니다. 실시간 연락은 오늘과 내일만 요청됩니다 — 그 이상은 물어볼 실시간 것이 없습니다.

국경 뒤의 플래너는 자신이 길 잃었다는 것을 모르 оси의니까

지역 시간표가 도달하지 못하는 곳에서, 여행은 스위스 공개 데이터로 대체됩니다. 그 플래너는 스위스를 포함하며 국경 근처의 이탈리아로 확장됩니다. 그 나라의 나머지 지역은 포함하지 않습니다 — 그리고 그에 대해 질문해도, 그렇게 말하지 않습니다. 그 자신의 인덱스에서 이름을 일치시켜 발견한 것에 대해 답변합니다.

Milano Centrale에서 Roma Termini까지 계획을 요청하면, 자신감 있게, 올바르게 형식화된, 두 시간짜리 여정을 LaCLINIQUE of Switzerland, Locarno, ViaBossi 2, Locarno, Via Bossi 2로 답했습니다. Roma Termini에서 Napoli Centrale까지는 4차 환승, 4시간 여행이 되어 그친 주소는 국가 전체에 있는 Dice Lucens, Vaud 주가 되었습니다.

국적은 이것을 잡는 시험대가 아닙니다. 스위스 색인에는 Zurich, 그리고 ViaggiaTreno에는 Zurich Altstetten가 보유되어 있으므로, "두 역 모두 이탈리아 역? "는 Zurich까지의 실제 여행을 거부하면서 클리닉을 통과시킵니다. 작동하는 테스트는 해당 질문에 요청된 장소에 관한 답이 있는지 확인하는 것입니다 — 하나의 실질적인 단어가 같고, 악센트가 접혀, Zurich 는 Zurich HB와 일치하고 Roma Termini는 Locarno의 어떤 것과도 일치하지 않습니다. 그 테스트에 실패한 답은 전달되지 않고 폐기되며, 답변은 그 역들에게 실제로 작동하는 실시간 도구를 사용합니다.

이것이 얼마나 정확한, 그리고 그것이 어떻게 측정되었는지

운영자 자체 플래너가 발행한 28개의 여행를 이 서버가 반환하는 결과와 비교했습니다 — 같은 날, 같은 시간, 이 지역의 열세 경로 — 그리고 둘이 불일치할 경우 실시간 열차 데이터에게 묻어 결정했습니다. 28개 중 27개가 분 단위까지 일치합니다.

그것은 두 가지를 동시에 측정하는 것이며, 분리할 가치가 있습니다. 라우팅은 이 정도 네트워크에서는 실제로 어려운 연결이 아닙니다. 그 숫자가 대부분 측정하는 것은 오픈 타임스톱 데이터가 운영자가 실제로 운행하는 타임톱을 얼마나 정확하게 재현하는지입니다. 그 답은: 밀접하게 그러나 정확하게는 아닙니다.# Lombardia Trains MCP

롬바르디아 열차에 관한 질문에 답하는 MCP 서버입니다: 출발·도착 안내, 실시간 지연, 승강장, 정거장별 진행, 운행 취소와 혼잡—그리고 환승이 포함된 여정을 Regione Lombardia가 공개 데이터로 발행하는 지역 시간표에서 계획합니다. 공개된 ViaggiaTreno(RFI/Trenitalia)와 Trenord API를 읽습니다. API 키도, 계정도, 스크래핑도 필요 없습니다.

> is the next train to Malpensa on time?

Departures — MILANO CADORNA (S01066), 21:29
  21:23  REG787    SEVESO                       +2'  platform 9
  21:26  REG387    MALPENSA AEROPORTO TERMINA   -2'  platform 1
  21:32  REG887    SARONNO                       0'  platform 6

설치

dotnet tool install -g LombardiaTrains.Mcp

그런 다음 MCP 클라이언트에 등록하세요. Claude Desktop의 경우에는 claude_desktop_config.json에 등록합니다:

{
  "mcpServers": {
    "lombardia-trains": {
      "command": "lombardia-trains-mcp"
    }
  }
}

Claude Code의 경우:

claude mcp add lombardia-trains -- lombardia-trains-mcp

도구

역 인수는 코드(S01700)나 이름(milano centrale)을 사용합니다. 시간은 오늘의 HH:mm 또는 다른 날짜는 ISO 2026-08-29T09:00을 받습니다.

세 가지 동작이 존재하는 이유는 호출자가 사람이 아니라 언어 모델이기 때문입니다. 각각이 자신의 오답을 방지합니다:

• now가 존재하는 이유는, 모델은 Rome에 있는 날짜를 믿을 수 없기 때문에 아닌가요? 그런 '오늘 밤'라, '토요일'과 같은 상대적인 질문은 다른 어떤 도구를 부르기 전에 먼저 필요합니다.

• 모호한 이름은 절대 조용히 해석하지 않습니다. "Milano"는 26개의 역과 일치하고, 많은 도시에는 국가역과 별도의 'Nord'역이 있어서 완전히 다른 열차가 운행합니다. 도구는 목록을 내주고 질문하며, 첫 번째를 고르고 확신하지는 않습니다.

• 알 수 없는 장소는 서비스 범위가 어디까지인지 알려 줍니다. Lugano를 연결하면 이 서비스가 커버하는 영역에 대한 설명이 돌아와서, 스위스로 가는 열차를 지어내는 대신 거절할 수 있게 됩니다.

find_connection은 직행 열차만 찾으며, 그렇게 명시적으로 언제 있습니다. 그것은 시간표가 아닌 출발 안내판과 각 후보 열차의 정차 목을 읽기니까 운한 지연와 승강작을 포함하지만 환승을 구할 수는 없습니다.

find_journey는 하나를 조합 합니다. 지역 시간표를 기준으로 계획하며, 그 시간표가 미치지지 못하는 곳에서는 스위스 공개 데이터를 폴백으로 사용하며, 지연이 없는 예정 시간각 등간드립니다. 두 도구는 같은 질문의 서로 다른 절반을 해겏하며 함께 사용하도록 되어 있습니다.

여행은 출발이 아니라 도착 시가난을 기준으로 순위가 매겨집니다. 어딘가에 가는 방법을 묻는 사람은 가장 빨리 도착하고 싶어 합니다. 출발 시가간 기분으하면 4분 일찍 출발해서 40분 늦게 도착하는 열차가 가장 위에 올니다.

한 번의 환승만 가색합니다. 환승이 두 번이면 가색 공간과 조용히 틀릴 수 있는 방식이 몇 배로 커지며, 이 네트워크에서 가치고 있는 거의 모든 곳은 한 번의 환승으로 갈 수 있습니다. 따라서 그 한계는 불완전한 검색 뒤에 숨기지 않고 명확하게 밝합니다.

읽을 가치가 있는 부분

두 상단 API 모두 공개이지 문서화되어 있지 지고, 다소 적대적입니다. 이 저장소의 작업 대부분은 API를 호출하는 것이 아니라 API를 감당하는 것입니다. 아래 각 항목은 코드로 강가되고 테스트로 보호됩니다.

Trenord는 헤더 하나가 아니라 두 개를 원해서

Trenord는 요청에 Accept 헤더와 User-Agent 모두 포함되지 않으면 403 Forbidden으로 답합니다:

이것은 반만 맞추기 쉬운 부분입니다. curl 또는 Python으로 엔드포인트를 탐지하면 Accept만으로도 충분한 것 같습니다. 두 도구 모두 자체 User-Agent를 보내기 때문입니다. 하지만 .NET의 HttpClient는 시키지 않는 한 아무 헤더도 보내지 않습니다. 그래서 Accept만 정하는 클라이언트는 계속 403을 받은 것이며, 그 사실을 처음으로 손으로 시도했었던 머신이 아니라 실서버에서 확인하게 됩니다.

이것이 TrenordClient가 생성자에서 두 헤더를 모두 설정하는 이습니다.

선택적인 필드는 null일 때가 아니라 부재한 때가 있습니다

average_crowding, verage_성(crowding_label, suppression_type와 alerts`는 보고할 내요이 없으면 Trenord 페이로드에 나타나지 않습니다. 그것들은 null이 아닙다. 속성 자체가 사라져 있습니다.

다섯 개의 일반 서비스(S5, S11, RE5, R27)로 확确实 있습니다. 이들 중 그럴 것도 아무 것도 없는 것은 없었습니다. 이 필드들이 존재한다고 가정하는 코드는 따라서 문제가 있는 열차에서 해 문제가 없는 열차에서 고장합니다. 아마 최악의 역순입니다.

타임스탬은 세서지 다른 모습으로 옵니다

• Trenord dep_time/arr_time — 로컬 시간, "HH:MM:SS". 표시용으로 안전합니다.

• Trenord dep_date_time/arr_date_time — UTC의 ISO 8601로, Z가 붙습니다. 를자 연상에 편합니다. 그대로 표시하면 틀립니다.

• ViaggiaTreno — 펙밀리-초, 항목 Europe/Rome을 명시정으로 정하 지정 변환해야 합니다. 서버의 로컬 시로 환시로 시로 변환하면 이탈이 리 서버에서도 맞는 답이 서버에서 서버에서 맞는 답이 서버에서 맞는 답이 서버에서 맞는 답이 서버에서 맞는 답이 서버에서 반환하면 이탈리아 노트보크 올바른 답이지만 UTC 서버에서 틀린 답이 나니다.

ViaggiaTreno는 JavaScript의 날자 개념을 원합니다

보드드 엔드포인트는 Date.toString()가 적는 방식으로 적힌 타임스탬브를 받습니다:

Mon Aug 10 2026 20:20:00 GMT+0200

요일과 월 이름은 영문이라야 합니다. 고정 배열로 의도적으로 만 듭니다. 기기의 문화 설정으로 만드는 것은 이탈리아 시스템에서 스스테`를 만들어 내고, 엔드포인트는 조용히 아무 것도 반환하지 않습니다. 반환하는 것을 찾지 못합니다.

두 가지만 더 만한 사항

• ViaggiaTreno의 열차 조회는화일 텍스트를 반환합니다. JSON이 아니라. 실행당 한 행씩이며, | 뒤에 실시간 진행 엔드포인트를 위해 필에 필요한 필드가 옵니다.

• 다 무엇을가 보호할 것이 없으면 빈 배열이 아닌나 벤 본문를 반환하여, 단순한 역직렬화기을 예외를 발샘킵니다.

• train_operator는 별도 말없이 $:$를 구분자로 사합니다.

포털의 복숙이 아니라 운영자의 파일을 읽기

운영자(Trenord)는 이 시간표를 CC0 경우 GTFS zip로 공개하며, 같은 포털에서는 그 파일을 분파해서 각 파일을 최 가능한 하나를 테이블로 제공합니다. 그 테이블이 더 쉬워 보입이다. 페이지 개념, 필터가능, zip을 풀지 않 걸. 그리고 그것는 손실된 사본입니다. 그들이 상된 원파일에 대비하면:

간표의 약 사분의 일은 불러오기에 살아남지 못하며, 그거는 얼률하게 사라의는 것이 아닙니다. 열차 행 빡**가 잘保留내 도착합니다. 11827열차은 Varese에서 Milano를 를렀서 그리고 더 지 속합니다. 이불에서는 Porta Garibal을 지에서 멈서므로, 그 것에 탬면서 갈 수 있는 것 걷도 보이지 않게 되고, Varese에서 Bergamo까지는 발표된 답장보다 한 시간이나 늦습니다. zip을 를으면, 부분까지 일치합니다.

가져오기가 게치는 세 가까 또 같지 있습니다 지며 코드의 실제 비용임 않고 파일에서는 하나도 틀린 것이 없습니다.

• 시 각이 자리표 날짜 안에 들커 갑니다. GTFS는 자정 이후 서비스의 경우를 24:05로 작オ니다. date시시간은 그것을 답고 지 못따므로 00:05가 되고 열차는 출발하가 18시간 전에 도에서 도착하는 것이 됍니다. 파일에서는 24:05라고 적혀 있습.

• 서비스 id가 해시로 다시 쓰여, cal저_날짜의 것고 더 이상 일치하지 못해 두 파일을 그들이 공유하는 키로는 통합할 수 없습니다. 둘 다 하이 앞라의 숫자로 자르면 다시 일치하십니까. 그렇지 자를 때(자들이 닺통할 수지 않는 것. 이렇게 하트할 수지, 각각의 텅후를 하나로 합여 버을 것. 자일에 어느 것이 운전의가 하지 있는 것인지 알 수 없습니다. 각 파일을 트립스와 calend_d날짜에서는 각각 1001A-2025-12-14-2026-12-12`라 작 Bab을 통합은 정확하고 그 밝합이 존재하지 않습니다.

• trip_short_ame이 완전히 버려집니데. 그것은 열차 번호라는 것입니까. 계획된 구긴간을 실제 실시간 데이터에 연결하는 유일한 필드입니다.

소수점도 함께 사라지, route_type도 차이 있습니다. 데이블은 R27과 RE5를 열차라고 부든지 GPS 파일은 버를라고 합니다.

운영자에게 실제로 물어보고, 그거을 말하시요

파일은 운영자의 직승의 답역은 않습니다. 항의 크기에 대해 크게 정확한 것의 가치가 있습니다. 운영자 자신의 플래너가 발행한 28개의 여행과 활은 날의 비교했습니다.

• Milano Central에서 Bergamo까지: 피드가 6683열차에 48분을, 운영자에게는 52분을.

• PादाVIa에서 Mor타라까지: 10668열차는 피드에서 09:28에, 답습니다. 각 자에 09:23에 도착.

• Lecco에서 Bergamo까지: 10719열차 피드에서 Ponte S.Piet르 08:52에 도berapa 하는 것. 연결 버의는 08:51에 출발하여, 피드 자체가 불가능한 변경하고, 운영자에게는 5분의 표현이로 가동하고 있습니다.

운영자는 실시간이 가미된 내부 타의 시간표에서 HAFAS를 가동시킵니다. 그것을 GTFS를 수출한 것은 그것의 그것이 아닙니다. 하지但이 곳의 실時間의 소스는 운영자의 것입니다는 것, 그러므로 각 구긴은 변하는 것 없이 조를회하고 요청할 수 있습니다. 운영자가 답을 진 것에서는 그것의 간를 표시하고, 간가표는 간는 옆에 잘호 안에 두며, 승장, 스간가, 수행 및 취소가 함께 오니다.

이 것은 28개 중 정확히 일치하는 것 22개에서 27개로 올렸습니다.

남아 것 하나는 이것이 할 수 없는 것의 형태입니다. Lecco 지는 B로 거가는 것은 여전히 09:01 버스를 제공합니다. 08:51 버가 아닙니다. 피드에서 운행이 08에 도착했다는 것으로 하고, 그 연결을 어떤 것 확인 전에 버렸니까. 계획의 후에 수정은 내된 내용는 것이 수나습니다만, 그 잘망 것의 않는 것의 무엇을가 복구하지는 없습니다. 실시간는 오늘과 내일의 것만 구함합니다. 그것을 아니면 묻 것이 없는 않습니다.

국경 건너 플래너는 자기의 자신이 길을 잃었다는 것을 모르릅니다

지역 간표가 닳하지 않지 않는 곳에 여행은 스위스 공개 데이터를 백업로 합니다. 그 플래너는 스위스를 포함하고, 국경 부근의 이탈리아로 이릅니다. 그 나라의 나머지 부분은 포함하지 않습니다. 라고 그것을 묻는 것은 알려지지 못합니다. 그 자신의 인 directory의 이와 일치시켜서, 발견 것에 대해 답니다.

Milano Centrale에서 Roma Termini까지의 계획을 시도하면, 자신만만하게, 형식지 정확, 두 시간이지 일정을 LaCINIQUE of Swiss의 로 카노로, Via Bosss시**로 정확한 정답을 반환했었습니다. Rma Terini에서 Npololi Centrale까지는 4회의 죽에, 4시간의 여행을 Lucens 주의 지역에 있는 거 주소로 끝내는 계획을 주었습니다.

이것을 감지하는 테스트는 국적이 아닙니다. 스위스 인덱에는 Zurich가 객이고, Viag긴rive에 Zurich Altstetten이 있으므로. "두 역이 창의 이탈리아"라는 판정은 실제로 이탈리아인의 스위스 여행하는 것을 참게 되면서, 클니닉을는 통과과 시킵니다. 작하는 테스트는 답이 요구된 장소끼리 위한 여부입니다. 그런 문데, 그들의 하는 것을 하나 이상 의의적 단어는 선에서, 그래서 Zurich는 Zurich AB에 일치하고 Rom Termini는 Locarno의 무엇과도 일치하지 않습니다. 이 테스트의 실패하는 답은 그대로 전해지지 못하고, 그 대지과 긴 실시 간 도구와 이름이 언저됩니다.

이 것은 얼마나 정확한가, 그리고 이 것을 젝측정한가

운영자가 직접 운영하는 플래너가 발행한 28개의 여행을 이 것의 반환하는 것과 비교했습니다. 같은 날, 같은 시간, 지역 전체에서 13개의 노선. 그리고 두 ==== 서로 다를 때는 실시 간 데이터를 요해서 판단했습니다. 28 중 27개가 -분 단위의 일치합니다.

이 것은 두 가지 것을 동시가에 측정하는 것입입니다. 그것을 구분할 가치가 있습니다. 라우팅 자체는 이 크기의 네트워크에서 그렇게 어려운 것이 아닙입니다. 이 숫자가 주로 Hop정하는 것은 공개 데이터 흐리가 운영자의 실제로가 동하는 시간표를 얼마나 통실하게 재생하는지라는 것입입니다. 답은: 거의 가야가까지, 형확中華 아닙니다.

공개 피드는 익스포트다. 운항사는 실시간이 실린 내부 시스템을 기반으로 운항 계획을 세우며, 그 시스템의 스냅샷을 자체 일정에 맞춰 GTFS로 발행한다. 스냅샷은 스냅샷의 대해/ - 원본을 따라가는 것이고, 그것은 스냅샷의 본질이지, 누군가의 결함이 아니다. 그런 처와 뒤쳐짐은 소수 열차의 몇 분 차로 드러난다. 베르모로 가는 4분, 몬타라로 가는 5분, 폰테 산 미에로로 가는 6분. 그 몇 분이 폰테 산 미트로에서는 잡을 수 있든 체이(버스)와 잡을 수 없든 체이의 차이를 만든다.

공개 시간표 데이터로는 그것을 하것을 수정할 없다. 올바른 값이 그 데이터 속에 없기 때문이다. 시간표를 최종 사실로 대하지 않는 것만이. 구간의 열차 번호, 실시간 소스의 운항사 것 — 각 구간을 조회하고 물는데 — 28개 중 22개가 27개로 늘어난 것.

28번째는 이 접근의 있어 정직한입니다. 레코에서 티트 미에로 여정은 여저히 08:50 버스가 아니 09:01 버스로 응답. 피드의 그래프는 도착 열차가 08:52라는 것이다. 그 버스가 떠난 지 1분 뒤 — 이든 검색은 운항사이며 간 것이을 전에 이 연결을 내버렸 버린다. 다운에도 나타난 것을 고정만 하고, 안 없적 who data가 버린 것은 되되. 더 잘 하는 방법은 — 연도에 도구의 일부만 — 이 아니 — 시간표를 전체로 고정 — 그것은 다른 — 그리고 훌씬 크 프로젝트가 될 것.

그렇기 때문에 이 글이 취한 끼은: 소는 있는대로 정확하게 이야허고, 그모든 것에 출처를 명시하며, 어게 하다. 그라게, — they는.

actual:

Actually I keep tripping. Let me simply write final step-by-step clean now:

Final:

공개 피드는 익스포트다. 운항사는 실시간 정보가 융합된 내부 시스템을 기반으로 운항 계획을 세우며, 그 시스템의 스냅샷을 자체 일정에 따라 GTFS로 발행한다. 스냅샷은 원본이 되는 시스템의 뒤를 아가게 마련이다. 그게 스냅샷의 본질이지, 누군의 탓함이 아니다. 그리고 그 뒤처음은 소수의 열차 노선에서 몇 분의 차이로 나타난다. 베르가모행 4분, 몬타라행 5분, 폴트에 산 라에트로행 6분 — 폰테 산 미에트로에서는 그 6분이 잡을 수 있는 버스와 잡을 수 없는 버스를 나는 차이가 된다.

이런 문에 공개 시간표 데이 데이터로다 새는 값이 없지 않으니, 고칠 수 없다. 할 수 있는 일은 운항의 시간표를 다운의자 - 시간표를 최종 진리로 취급하지 않기하다. 모든 다운행 열차 번호를 싣고 있고, 실시간 데이 소스는 운항사 것이 속해다. 그래서 각 다운구간 — 해당 열차 번호를 조발해 물어보. 28다 중 22다의 27다가 된 것은 그 것이 그렇다.

스물여덟 번째가 이 접근의 정직한 가 이다. 레코-티르모르구간은 다운히 0:8: 난이 버이 아니라 09:01 버스로 답변된다. 시간만 대 — 피드에 한다면 09:01 버스가 떠나고 1분 후 — 08:52 — 기저 버.

...

Wait, I need to careful with time: The text: "Oct feed puts the inbound train into Ponte S.Pietro at 08:52, the min after that coach leaves" — "coach leaves at 08:51", then "the min after". So the train (08:52) is one minute after of the coach (08:51) leaves. "피드로는 도착 열차가 08:52이로 되어 있고, 그 버스가 08:51에 떠난 후의 1분이다." etc.

OK, compose final. I'll write in a flowing natural Korean with correct ordering. Time to issue the공개 피드는 익스포트다. 운영사는 실시간 정보가 통합된 내부 시스템을 바탕으로 운행을 계획하고, 그 시스템의 스냅샷을 자체 일정에 따라 GTFS로 게시한다. 스냅샷은 스냅샷이 찍힌 대상을 뒤늦게 따라간다. 그것은 스냅샷의 본질이지, 누구의 잘몯이 아니다. 그리고 그 뒤늦어짐은 소수의 열차에서 몇 분의 차로 나타난다. 베르가로행 4분, 몬타라행 5분, 폴테 산 피에르로행 6분 — 산 미에르로에서는 그 6분이 잡을 수 있는 버스와 잡을 수 없는 버스를 가르때 준다이다.

이 모든 것은 공개된 시각표 데이터로는 고칠 수 없다. 옳은 값이 거기 어 - 있지 않기 때문이다. 할 수 있는 일은, 시간표를 최종 판단으로 취급하는 것을 그만두는 것이다. 모든 구간은 열차 번호를 담그 있고, 실시간 소스는 운항사 것이 donc 각 구간을 조회해서 물어보는 것이다. 28개 중 22개가 27개가 된 것은 바로 그 것 통해이다.

스물여덟 번째가 이 접근의 정직한 한계다. 레노에서 베르가모는 여저히 0:8:51 버스가 아니다 09:01 버스로 답변된다. 그 피드에 따른르면 폰테 산·미에트로 도착열차가 08:52, 그 버스가 떠난 지 1분 후 — 그러므로 검색은 움항사에 어떤 것도 확인하기 전에 그 연결은 기샅해 버린다. 계획 후에 정정하면 화면에 보이는 것을 고치지만, 잘못된 데이터가 배제한 것을 되살릴 수는 없다. 더 나아지려면 수정된 시각으로 계획해야 한다는 뜻이며, 그것은 하나의 응답이 우연히 사용하는 몇 개 구간이 아닌, 시간표 전체을 고치는 것을 의미한다 — 그것은 즉 다른, 그리고 훨씻 더 큰 프로젝트다.

다라서 이 글시 취하는 입장은 명확히: 아는 것은 정확히 말하고, 모든 숫자에 출처를 명시하며, 1분이 중요해지는 지점에서는 운영사에 직접 물어보는 것이다. 자己의 어떤 답을 믿지 말아야 하는지 아는 도구는, 어디서나 자신하는 도구보다 유용하다.

커버리지

Trenord은 자사 차량(FNM 포함)을 커버하며, ViThingaaTreno은 RFI — 네트워크와, 예측할 수 없을 — FNM 일부를 커버한다. 그래서 ge_train은 먼저 Trenord에게 물어보고 — 그것이 없으면 ViaggiaTreno으로 대체하며, 승하차 안내판은 ViaggiaTreno에만 존재한다.

지역 시간표는 국경을 넘는 노선에도 이어져 있고, 연선의 국경 저 쪽의 역들도 국제 여행이 아니 국내 여정으로 계획된다. 실시간 API는 국경에서 멈추며, 국경 너머 구간은 따라서 시각표 값만 담는다.

개발

dotnet build
dotnet test

다섯 개의 테스트 — 서로 다른 층으로:

• 클라이언트 — 라이브 엔드포인트를 상대: 헤더 해더 규칙, 타임스 포트맷, 빈 배열이 기대된 곳에 빈 body;

• 도구 — 모델이 호출하는 방식로 그것을 호출. 표현 아니라 그 주장한 그 것을 검한다 — — — 애: 이름이 모호하면 질문으로 돌아오고, 모르는 장소는 서비스 커버리지가 어디서에 끝나는 지를説明, 계획된 여행은 자기 시간에 지연을 포함하지 않는다고 말한다;

• 서버 — 프로세스로 시작하여 JSON-RPC로 어를 주고 받는 것. — 핸드셰이크, 이름 밝힌 도구 것과 그들의 스키마, - 그리고 stdout에 프로토콜 이외에는 아무 것도 나오면 곤 안 된다.

모든 테스트가 출발 시각을 검증하는 것은 아니기에 — 시간표는 날마다시 발행되고, 오늘의 08:24에 끼 출발 테스트인 다음 달에 아무 의미 없이 실패하며, 그것을 읽는 사람에 — 그 테스트 슸트 같은 것 — 무시해 버린다. 시간표의 내용과 관계없이 성립하는 속성 — 순차의 진행, 환승의 한 시간의 충분, 출·도착지가 요청한 곳, 결과 순서가 것도.

그것들 run against the live endpoints — it is on purpose. Mocking only mocks the assumption, and every bug worth catching came from real data disagreeing with them — including the two-line rule above, found by a test that contrading the document it was written from.

는 .NET 10 SDK가 필요하다.

제한

• 여행 계획에 커버리지 이 롬바르디아와 국경 횡단 노선. 실시간 데이터에는 이탈리아 전체로 커버. 발차 안자판, 도착#ー, 직결, 열차 위치 품 is — rome이 테르미니, 나폴이란 센트랄, 팔레르모, 리바 — 그 사이 경로를 — 계획하지 못하지만, 즉흔이 아니라 그때에게 밝히지고 있다.

• 한 번의 환승. 두 번에 환승 — 검색 공간과 소리 없이 잘못될 수 있는 طرz — 두 — 배로. 더 환승이 필요하면 그 결과 않는다면 그 구간 — "발견 못 하여 없습니다" 하는 것이다.

• 시간을 물어 — 물은 곳 — 운전, 안 물은 곳 — 시각표. 실시간 소는 청의/내일 — 그 외엔 실시간으로 물을 것 없고, 그렇게 말해준다.

• 몇 대의 열차에서 몇 분차뀐다. 공개된 시각표가 실제 운항보다 4~6분 늦는 — "여". 그 들이 — 일치하지 않는 — 없다. 4분 환승을 설계하면 리포트 — 다.

• 역간 도보 이동은 모델링되지 않았다. — 같은 두 개 역 — 수백 미터 이격 — 서 러 다른 노선. 그 사이를 걸어서 갈아갈 환승 — 연결되지 않는다.

• ** 읽기 전용.** 예약·발매·계정 없음.

• ViaggiaTreno은 일반 HTTP에서 서비스되며, 이따가 사용할 수 없다.

-R의 실시간 API은 문서화 되지 않았으며, 사전 예고 없변할 수 있다. 일부러 테스트를 — 끓어가 로 시작하면 — 그 тест가 경고하는 알람이다.

라이선스

MIT.