Přístup iniciativ RailTopoModel a railML 3 k datovému popisu železniční infrastruktury – díl II.

4 POŽADAVKY NA RAILTOPOMODEL A ÚROVEŇ JEJICH NAPLNĚNÍ

4.1 Logická reprezentace topologie sítě na různých rozlišovacích úrovních

Jedním z požadavků kladených na RailTopoModel, definovaných ve studii proveditelnosti, [1] je, aby podporoval logickou reprezentaci topologie sítě formou grafu (tj. prostřednictvím uzlů a hran nezávisle na fyzických vlastnostech a technickém vybavení). V rámci tímto způsobem popsané sítě by měly být definovatelné trasy (např. pro jízdu vlaků). Pro různé účely je však třeba topologii železniční sítě vyjádřit na různých rozlišovacích úrovních (srov. např. podrobnější úroveň jednotlivých výhybek propojených kolejemi a obecnější pojetí dopraven propojených traťovými úseky).

Odpovídající úroveň, na níž je účelné data reprezentovat, může také záviset na dostupnosti a přesnosti dat, která se může napříč jednotlivými správami lišit. Proto je žádoucí nabídnout uživateli, aby si zvolil rozlišovací úroveň, kterou bude pro popis sítě využívat, resp. ze které bude vycházet. Pro popis sítě jsou v současnosti zavedeny tři základní úrovně (micro, meso a macro), z nichž alespoň jedna by měla být uplatněna při konkrétní aplikaci modelu. Tyto úrovně je však možné libovolně doplňovat o další rozlišovací úrovně (např. nano) a uživatelsky specifické pohledy. V rámci modelu přitom měla být zajištěna jejich vzájemná vertikální propojenost, realizovaná na základě principů agregace a disagregace [1] [2].

Problematiku popisu logické reprezentace topologie sítě řeší Rail-TopoModel zavedením tzv. síťových prvků (net elements). Ty přestavují jednotlivé komponenty infrastruktury (koleje, dopravny, traťové úseky a další), které vystupují v kontextu určité rozlišovací úrovně a jsou reprezentovány prostřednictvím uzlů grafu (lhostejno zda se jedná o prvky neliniové nebo liniové) ve smyslu matematického konstruktu. Hrany grafu potom reprezentují vzájemnou provázanost těchto síťových prvků – síťové vazby (net relations).

Vzhledem k tomu, že uvedený popis topologie je zcela obecný a aplikovatelný ne nutně jen na železniční infrastrukturu, nýbrž na libovolnou síť, bylo potřeba jej pro účely železnice obohatit o určité specifické aspekty. Zejména bylo třeba dokázat vyjádřit možnost plynulého přechodu z jednoho síťového prvku na druhý (a zpět). Tento parametr vazby mezi síťovými prvky (již je navíc třeba vztáhnout buď k začátku, nebo ke konci obou ze zúčastněných prvků) je vyjádřen prostřednictvím atributu navigability. Tento parametr udává, zda je možný přechod mezi prvky A a B a pokud ano, tak zda je realizovatelný v obou směrech nebo jenom v jednom určitém směru [2] [3]. Tímto způsobem je možné např. funkčně modelovat výhybky (viz obrázek 1 – Příklad vyjádření topologie části železniční sítě na micro úrovni), ale také železniční uzly.

4.2 Souřadné systémy

Také na souřadné systémy byl kladen požadavek, aby bylo možné ukotvit je vůči definované topologii, avšak samotná topologie byla na nich nezávislá (např. na rozdíl od přístupu využívaného v rail-ML 2). Model by měl podporovat několik druhů souřadných systémů zároveň [1]. Na tento požadavek zareagoval RailTopoModel zavedením modulu souřadných systémů, zahrnujícího např. třídy reprezentující liniové souřadné systémy (využitelné např. pro zavedení systémů staničení jednotlivých tratí nebo kolejových tras) a geometrické souřadné systémy (jak různé geografické souřadné systémy využitelné např. pro účely GIS, tak systémy obrazovkových souřadnic pro vizualizaci popisované skutečnosti na monitoru). Vedle liniových a geometrických souřadnic, vázaných na tyto souřadné systémy, je možné prostřednictvím interní souřadnice na relativní škále od 0 do 1 vyjádřit pozici v rámci tzv. interního souřadného systému, přiřazeného konkrétnímu síťovému prvku [2] [3].

4.3 Matematický popis geometrických objektů

Požadavek na podporu matematického popisu geometrie v rámci RailTopoModelu by měla výhledově naplnit dimenze geometrie, která je počátkem roku 2018 v rozpracované fázi. Popsat geometrické aspekty koleje prostředky RailTopoModelu je zatím možné v omezené míře díky síťovým entitám. Např. v railML 3 je možné geometrickou polohu koleje (směrové a sklonové poměry a převýšení) zjednodušeně vyjádřit s využitím geometrických entit, které jsou (vedle entit funkční infrastruktury zavedených v railML 3) odvozené od síťových entit definovaných RailTopoModelem. Např. přechodnice je zatím v railML 3 možné popsat jejich typem, avšak nikoliv již jako matematické křivky [3] [4].

Síťové entity (net entities) obecně představují v pojetí RailTopoModelu a railML 3 taková zařízení a různé popisné charakteristiky železniční dopravní cesty, které mohou být lokalizovány vůči topologii (síťovým prvkům) a zavedeným souřadným systémům (podrobněji viz oddíl 5.2 Lokalizace síťových entit). K vyjádření bodové, liniové nebo agregované lokace využívá railML 3.1 elementů reprezentujících body a liniové úseky s atributy vyjadřujícími pozici. [3] Pro tento účel je možné také využít geometrických datových typů reprezentujících body a linie GML (Geography Markup Language), které railML přejímá do vlastního schématu GML pro railML. Polygony GML, které by umožnily vyjádření externích ploch, ale zapracovány nejsou, i když RailTopoModel již třídy pro bodovou, liniovou i plošnou lokalizaci zavádí.

Model jako takový by měl i v souladu se studií proveditelnosti podporovat vyjádření jak nuladimenzionálních, tak jednodimenzionálních a dvoudimenzionálních objektů. Struktury těchto typů by měly být implementovatelné do výměnného formátu i v podobě rozšíření (což raiML 3 do jisté míry naplňuje, avšak výhledově by mělo být integrováno originální xsd schéma pro GML namísto vlastního schématu) [1] [3] [5].

4.4 Přístup k identifikaci, referencování a k popisu datových objektů prostřednictvím metadat

Formát kompatibilní s RailTopoModelem by měl dále umožnit, aby byly jednotlivé objekty jednoznačně referencovány, a to i zvnějšku, s využitím umělého klíče. Tento požadavek je naplněn tím, že pro ID objektů modelu má být datového typu UUID (univerzálně jedinečný identifikátor). Pro účely snadné adaptace stávajících systémů se nicméně připouští také využití jiných jedinečných identifikátorů [1] [2] [3]. Identita jednotlivých položek by měla být zachována po celou dobu životnosti modelu.

Model by měl také zahrnovat mechanismy pro rozdělení a opětovné sjednocení částí v celek, umožnit definovat hranice, rozhraní a identifikátory. Na hranicích, kde je třeba rozdělovat a slučovat národní modely, by mělo být možné definovat umělé uzly. Z hlediska struktury by měl být model dále otevřený rozšířením o uživatelské moduly se schopností se odkazovat na jádro modelu (avšak nikoliv naopak). Měla by být zároveň zajištěna nezávislost na IT dodavatelích a národně specifických odlišnostech (která by vedla v rozředění standardu v lokální dialekty), avšak s možností podpory tvorby nových konvencí ve smyslu pojmenovávání a definic objektů. Aplikace by přitom měly být schopné číst právě ty vrstvy, pro jejichž zpracování byly navrženy, a to bez ohledu na další data [1]. To např. právě struktura railML, jakožto výměnného datového souboru založeného na XML, umožňuje.

Souvisejícími požadavky jsou pak normalizace a jednoznačnost popisu sítě a zajištění zpětné i dopředné kompatibility modelu a formátu (výhledově potenciálně v žurnálovém provedení zachycujícím informace a minulých a budoucích změnách). Z hlediska metadat by pak model měl též podporovat vyjádření validity objektů ve smyslu kdy je objekt v provozu, aktivní, či využitelný (to je již na úrovni definovaných atributů zapracováno) a dále variant a verzí, čili alternativních stavů modelu ve stejném časovém horizontu, resp. vyvíjejících se v průběhu času. Tyto požadavky jsou podrobně řešeny zejména v rámci dimenze časovosti a projektů, na jejímž vývoji se na úrovni RailTopoModelu pracuje [1] [4].

4.5 Zajištění syntaktické a sémantické korektnosti

Výměnný formát by měl podporovat syntaktickou a sémantickou korektnost. Jako formát odvozený od XML umožňuje railML 3 snadné ověření syntaktické korektnosti. Právě pro tyto účely je navržen např. zmiňovaný software RailVIVID. [6] Sémantickou korektnost by v co nejvyšší možné míře podporovat již samotný návrh modelu (např. využíváním výčtů hodnot, resp. stávajících knihoven, namísto neomezených textových řetězců u kontextových informací, zavedením sad alternativních kombinací atributů namísto široké škály nezávisle volitelných atributů, eliminací redundance) [1]. 

Stávající dokumentace RailTopoModelu zatím z tohoto hlediska žádné podrobné specifikace neposkytuje, [2] ovšem např. prozatímní verze railML 3 vyžívají výčtů hodnot poměrně hojně. Na rozdíl od rail-ML 2, u kterého byl příznak volitelnosti u jednotlivých elementů a atributů platný obecně bez ohledu na konkrétní případ užití, railML 3 volí cestu specifických profilů, které jejich volitelnost (v základní podobě poněkud benevolentněji pojatou než u railML 2) dále omezují v závislosti na konkrétním případu užití, jehož aplikace se u konkrétního datového rozhraní uplatňuje [5]. Tím je jazyk railML 3 poplatný požadavku studie proveditelnosti na závislost kompletnosti formátu na případu užití. Na jednu stranu se tím jazyk stává flexibilnějším a šířeji využitelným, na stranu druhou může částečně utrpět jeho univerzální použitelnost tohoto formátu coby standardizovaného rozhraní.

Kvalita implementace standardu má být dále podporována díky certifikačnímu procesu [7] a prostřednictvím dostupnosti a srozumitelnosti průvodní dokumentace a podpůrných nástrojů. Je tudíž třeba, aby popis topologického modelu byl pro člověka čitelný. Na výměnný formát sloužící pro komunikaci mezi počítači tento požadavek za
předpokladu zajištění vizualizačních nástrojů kladen není, avšak navzdory tomu nabízí railML 3 ve stávající podobě zápis, který do značné míry člověku srozumitelný je. Je to sice za cenu poněkud větších přenášených datových souborů, tento ústupek nicméně (společně s možnou nižší výpočetní efektivitou) studie proveditelnosti připouští.

Vlastní integritu dat je však třeba zajistit prostřednictvím externích mechanismů (např. s využitím šifrování) mimo model a formát, které tuto funkcionalitu samy o sobě nepodporují [1].

5 ZMĚNY FORMÁTU RAILML V REAKCI NA RAILTOPOMODEL

5.1 Změna v přístupu k pojetí topologie

Jestliže starší verze výměnného formátu railML byly z hlediska způsobu popisu železniční infrastruktury poplatné zejména potřebám jízdního řádu, s implementací principů RailTopoModelu dochází v railML 3 k postupnému přibližování se prostorovému popisu umožňujícího širší využití tohoto jazyka. V railML 2 je základní jednotkou popisující železniční síť kolej, reprezentovaná XML elementem track, který ve své substruktuře obsahuje jak topologickou informaci (provázanost s ostatními kolejemi pomocí konektorů). Veškeré objekty, zařízení a vlastnosti, které dané koleji přísluší, jsou tak lokalizované na základě parametru udávajícího jejich vzdálenost od jejího začátku (s využitím atributu pos).

Oproti tomu railML 3 v reakci na strukturu RailTopoModelu pojímá topologii sítě jako samostatný modul vystupující vedle souřadných systémů, geometrie, funkční infrastruktury a výhledově např. hmotného majetku (viz oddíl 2.3 v I. díle tohoto článku). Topologie je jediným povinným z těchto modulů. Je koncipována jako abstraktní a bezrozměrná a železniční síť popisuje nezávisle na její fyzické reprezentaci. Vystupuje v roli logické kostry železniční infrastruktury, kterou RailTopoModel umožňuje vyjádřit na různých rozlišovacích úrovních. Vůči takto pojaté topologii, vyjádřené pomocí síťových prvků a vazeb, je možné (např. s využitím modulu souřadných systémů) lokalizovat jednotlivá zařízení, která se na železnici vyskytují, včetně parametrů, jimiž je možné železniční dopravní cestu popsat [3] [4].

5.2 Lokalizace síťových entit

Lokalizaci těchto entit je možné provést jak relativně ve vztahu k jednotlivým prvkům, z nichž se síť skládá, tak pomocí souřadnic (liniových nebo geometrických) ve vztahu k zavedeným souřadným systémům, a vyjádřit tak jejich topologickou resp. geometrickou pozici. Liniových a geometrických souřadných systémů může pro tyto účely uživatel definovat libovolné množství, ať již ve smyslu různých os staničení, interních liniových souřadných systémů, geografických souřadných systémů, nebo např. pro účely schématické vizualizace infrastruktury na obrazovce. Jednotlivé entity lze lokalizovat (určit jejich pozici relativně vůči síťovým prvkům i prostřednictvím souřadnic definovaných souřadných systémů) v railML 3 několikanásobně. To formát railML 2 neumožňuje, neboť každý objekt umisťovaný na železniční síť je v této starší verzi třeba přiřadit právě k jedné konkrétní koleji (XML element příslušný objekt reprezentující utváří substrukturu elementu track). Oproti tomu v jazyce railML 3 jsou jednotlivé entity popsány samostatně a k topologii nebo souřadným systémům jsou přiřazeny až právě s využitím lokalizace.

Aktuální verze railML 3.1 nabízí možnost lokalizovat síťové entity bodově, liniově nebo agregovaně. Bodová lokalizace umožňuje entitu lokalizovat do určitého bodu nebo několika bodů infrastruktury. Tento způsob je vhodný např. pro umístění návěstidla. V případě skupinového návěstidla lze přitom zvolit jeho pozici vzhledem ke všem síťovým prvkům, reprezentujícím koleje, pro které platí. Liniovou lokalizací se rozumí vymezení úseku, na kterém se daný objekt nachází, nebo po který daná skutečnost platí, a to počátečním a koncovým bodem. Je tak možné lokalizovat např. most, a to i na vícekolejné trati s využitím více úseků (viz obrázek 2 – Lokalizace mostu na dvoukolejné trati metodikou railML 2 a railML 3). V railML 2 je přitom nutné využít několika instancí umisťované entity, což je však nevhodné např. z pohledu evidence a identifikace příslušných objektů. Na různých rozlišovacích úrovních je možné lokalizovat tytéž entity různě. Např. zmiňovaný most lze na podrobné úrovni kolejí (např. micro) lokalizovat liniově a na méně podrobné úrovni tratí (např. macro) již pouze bodově. Na jiné úrovni nemusí být z hlediska datového popisu daný objekt lokalizován vůbec. Pro takové případy, kdy je nutné lokaci vyjádřit prostřednictvím minimálně jednoho bodu a minimálně jednoho úseku, se používá agregovaná lokalizace.

V průběhu vývoje railML 3 (různé fáze vývojové alpha verze 3.0) došlo stejně jako ve většině ostatních dílčích oblastí schématu infrastruktura k řadě dílčích změn týkajících se problematiky lokalizace síťových entit. Mezi nimi je možné jmenovat zavedení síťové lokalizace, umožňující přiřadit globální parametry celé popisované síti. Tímto způsobem reagovali tvůrci formátu na připomínku komunity uživatelů raiML týkající se modulu parametrů infrastruktury, který figuroval ve vývojové verzi 3.0.is4 a na rozdíl od síťových entit umožňoval tyto parametry přiřadit pouze k síťovým prvkům jako k celku (to by např. znemožňovalo vyjádření změnu elektrizace v rámci koleje reprezentované jedním síťovým prvkem). Následně byly parametry infrastruktury přesunuty do skupiny zařízení později přejmenované na funkční infrastrukturu, a staly se tak síťovými entitami. Obdobně skupina atributů kolejového lože, pomocí nichž měla být původně popisována entita výhybka nebo kolej jako celek, byla (i díky iniciativě pracoviště Dopravního sálu při Fakultě dopravní ČVUT v Praze) přesunuta do modulu funkční infrastruktury, což umožňuje jejich flexibilnější lokalizaci [3].

Ačkoliv některé entity je na základě jejich povahy vhodné ve vztahu k určité rozlišovací úrovni lokalizovat některým konkrétním z uvedených způsobů, obecně je volba tohoto způsobu na uživateli (resp. na konkrétním případu užití), neboť pro všechny síťové entity platí v tomto ohledu stejná pravidla. I zde lze spatřovat odlišnost oproti railML 2, který způsob lokalizace stanovuje zvlášť pro každý typ elementu vyjadřujícího určité zařízení nebo vlastnost lokalizovanou vůči koleji. Velice často se u railML 2 jedná o lokalizace bodů změn (např. rychlosti nebo poloměru směrového oblouku), kterýžto ne příliš vhodný přístup již railML 3 nevyužívá [3].

5.3 Use cases pro další rozvoj railML 3

Vzhledem k tomu, že je snahou tvůrců přizpůsobit formát reálným uživatelským potřebám, byli členové komunity, kteří mají záměr datově komunikovat prostřednictvím railML 3, a to zejména s využitím schématu infrastruktura, vyzváni ke zpracování svého případu užití (use case), [8] reflektujícího jejich specifické požadavky. Součástí dokumentu je popis aplikace daného případu užití a souvisejících dat, datových toků a rozhraní a případné souvislosti s ostatními schématy railML. Potenciální uživatel může blíže charakterizovat data z hlediska předpokládané četnosti aktualizací, rozsahu přenášených datových souborů z hlediska popisované lokality, konkrétního zaměření a bližšího obsahu (elementy, datové typy, přípustné hodnoty, volitelnost). Na základě těchto podkladů a dalších impulsů a připomínek poskytovaných tvůrcům railML uživateli (např. prostřednictvím k tomu určeného diskusního fóra railML) budou stávající specifikace rail-ML 3 (testovací beta verze 3.1 z podzimu 2017 a následně veřejné vydání verze 3.1 z počátku roku 2018) postupně doplňovány a aktualizovány ve snaze přizpůsobit je konkrétnímu případu užití. Jednotlivé případy užití jsou ohodnoceny příznakem priority, podle které budou požadavky z nich vyplývající do specifikací zapracovávány.

První veřejné vydání railML 3.1 zapracovává případy užití s nejvyšší prioritou, a sice use case Prohlášení o dráze pro účely správce infrastruktury, na jehož tvorbě se podílejí provozovatelé drah v Norsku, Nizozemsku a České republice (BaneNOR, ProRail a SŽDC) a Schematický plán kolejí pro norské společnosti JBV a Bane NOR. Následuje Poskytování dat do sytému RINF iniciované francouzským správcem infrastruktury SNCF Réseau a Geometrická poloha koleje ve vysoké podrobnosti (např. pro účely podbíjecích prací) v režii rakouských ÖBB. Ostatní případy užití jsou zatím ve fázi návrhu a budou zapracovávány průběžně během následujících let. Ovlivní zpětně podobu formátu railML 3 a zřejmě také přispějí v rozvoji vlastního RailTopoModelu. [5] [8] [9] Ačkoliv specifikace stávající verze railML 3.1 obsahují pouze omezené množství typů elementů reprezentujících síťové entity a zejména jejich atributového popisu, lze v závislosti na uživatelských potřebách očekávat (ale zejména také podnítit) jejich podstatné rozšíření.

Zároveň se tedy jedná o výzvu pro potenciální uživatele mající zájem o datovou komunikaci v oblasti železniční dopravy k tomu, aby vypracovali a rozvíjeli vlastní use case railML 3 schématu infrastruktura (a v případě zájmu také dalších schémat) a podíleli se tak na dalším vývoji výměnného formátu railML 3. I na jejich iniciativě závisí, jaká data bude výhledově možné prostřednictvím railML přenášet a nakolik bude formát využitelný pro jejich konkrétní potřeby i pro globální potřeby railML komunity (viz schéma na obrázku 3 – Význam uživatelských use cases pro vývoj railML 3).

6 ZÁVĚREČNÉ SHRNUTÍ

Značkovací železniční jazyk railML je de facto standardem na poli datové výměny v oblasti železniční dopravy, jehož specifikace jsou rozčleněny do základních dílčích schémat jízdního řádu, vozidel a infrastruktury a nově též zabezpečovacího zařízení. V souvislosti se spuštěním iniciativy UIC RailTopoModel, která zavádí principy jednotného datového modelování železniční infrastruktury, začala být vyvíjena třetí verze tohoto výměnného datového formátu, který by měl být na rozdíl od předcházejících verzí s RailTopoModelem kompatibilní. V souvislosti s uvedeným záměrem formát railML 3 doznává oproti předcházejícím verzím podstatných změn (zejména ve struktuře schématu infrastruktura). Nové pojetí umožňuje železniční infrastrukturu popisovat efektivnějším způsobem. Jak railML 3 (toho času v testovací verzi), tak RailTopoModel jsou stále ve vývoji. Postupně jsou zapracovávány požadavky definované v studii proveditelnosti RailTopoModelu zpracované spolu se zahájením iniciativy v roce 2013. Neméně důležitá je zpětná vazba od výhledových uživatelů. Na základě jejich podnětů a případů užití, pro které chtějí railML 3 využívat, dochází k rozšiřování a zkvalitňování schématu infrastruktury railML, a tím i ke vzniku uživatelské nadstavby nad vlastním jádrem dokumentu IRS 30100 a obecným návrhem RailTopoModelu.

Jak model, tak výměnný formát by měly být otevřeným standardem sdíleným a rozvíjeným v rámci uživatelské komunity, která je bude využívat k výměně zkušeností a osvědčených postupů [1]. Využitelnost těchto nástrojů v praxi se tím pádem odvíjí od aktivity zúčastněných partnerů z řad železničních společností, IT firem a poradenských a akademických institucí, které jsou součástí konsorcia. V zájmu co možná nejširší využitelnosti formátu railML a metodiky datového modelování systému železnice RailTopoModel i v národně specifických podmínkách a pro účely ať již mezinárodní nebo vnitropodnikové datové komunikace je tudíž žádoucí tyto úzce propojené mezinárodní iniciativy podpořit. Kromě uplatnění principů RailTopoModelu v railML 3 a dalších jeho aplikací může tento koncept posloužit jako řešení železnicím, které doposud nemají vlastní datový model železniční infrastruktury, nebo si přejí zdokonalit model stávající.

POUŽITÉ ZDROJE:
[1] UIC. Feasibility study UIC RailTopoModel and Data Exchange Format [soubor pdf]. 2013. Dostupné také z: http://www.railtopomodel.org/files/download/RailTopoModel/270913_trafIT_Final-ReportFeasibilityStudyRailTopoModel.pdf 
[2] UIC. UIC International Railway Standard IRS 30100 RailTopoModel [soubor pdf]. 2016.
[3] railML.org. railML 3 Schema – Alpha Versions [online]. 2017 [cit. 2017-11-10]. Dostupné po přihlášení z: https://svn.railml.org/railML3/trunk/xsd/ 
[4] KOLMORGEN, V. P; RAHMIG, C. a kol. 7th RailTopoModel and 30th railML Conference. Paris: UIC, railML.org, 2. 11. 2016
[5] KOLMORGEN, V. P; RAHMIG, C. a kol. railML/RTM Explanation Session. Praha: SŽDC, 9. 3. 2017–10. 3. 2017
[6] railML.org. railVIVID: The railML Viewer & Validator – powered by UIC [online]. ©2002–2017 [cit. 2017-04-14]. Dostupné z: https://www.railml.org/en/user/railvivid.html 
[7] railML.org. Certification of your railML® interface [online]. ©2002–2017 [cit. 2017-04-14]. Dostupné z: https://www.railml.org/en/user/certification.html 
[8] railML.org. Use Cases [online]. ©2002–2017 [cit. 2017-04-14]. Dostupné z: https://www.railml.org/en/user/use-cases.html 
[9] KOLMORGEN, V. P. a kol. 8th RailTopoModel Conference. Paris: UIC, 4. 5. 2017

The Attitude of the RailTopoModel and railML 3 initiativesTowards the Data Description of the Railway Infrastructure – Part II.
At present, the requirements for efficient data storage and sharing are growing together with development of software applications across various sectors including transport, as well as with increasing tendencies to apply intelligent transport systems in practice. In the railway sector, besides the timetable and rolling stocks related data, the description of infrastructure plays an essential role. As regards the data modelling of railway infrastructure, the UIC RailTopoModel initiative was introduced in 2013. A feasibility study defining requirements on uniform model of railway infrastructure description was processed on this occasion. Development of this generic model in turn influences also the form of the railML exchange format, which has been being developed as an open specification for rail data sharing since 2001. The infrastructure schema content, as regards the upcoming railML 3 version, based on the RailTopoModel principles, especially depends on specific needs of potential users. In order to achieve broadly usable structure of railML 3, it is appropriate to support these initiatives. The second part of the article evaluates current fulfilment of the RailTopoModel requirements stated in the feasibility study and describes the railML development focusing on the aspects being introduced or changed with railML 3.

Autor

• Ing. Hlubuček Adam