Countries and lines are both multi-select, and results are combined across everything you pick.
Lines are fetched once per country and cached — ticking a country again costs no further query. Because a line
identifier is unique only within a Member State, the picker keeps each line's country attached rather than
matching on the bare identifier, so two countries publishing the same number can never be picked by mistake.
Every table row, and both exports, carry the country and line they came from, and the D2 coverage view
aggregates across the whole selection.
Sections of line carry no name of their own, so this tool borrows one from the operational points at
each end. Every section of line is bounded by era:opStart and era:opEnd;
both resolve to an era:OperationalPoint, and its era:opName is what appears in the
Section column and on the network map — the same property the
RCC Parameters tool's map already draws chords between. A section missing either end
keeps its kilometre position only, shown as — where even that isn't published. That name is
era:opName verbatim, and for an unstaffed junction that is not always a place name — France's
SNCF Réseau names some junctions after the two lines that cross there (e.g. 001379-1/979000-1)
rather than giving them one of their own. Unusual next to Haussmann-St-Lazare, but exactly what
was published, not a labelling failure here.
The network map draws every selected line's sections geographically , over a plain
Esri basemap; the “Railway overlay” checkbox adds the OpenRailwayMap
“standard” layer for real track, station and line-number context, off by default so its own
colours never compete with each line's own legend colour. Sections now publish their own geometry almost
everywhere too, but each is still drawn as the straight chord between the two operational points it runs
between regardless — topology, not alignment. Each line gets its own colour from the legend; a thicker, brighter segment
carries at least one D2 element from this run, a thin grey one was resolved but has none here. It reuses the
operational-point names and geometry already fetched for the Section column, so drawing the map costs no
further query. “Open in new window” pops the same drawing out into its own browser window — no
further query either, just the current segments redrawn there — so it can be dragged to a second monitor or
given more room than the panel embedded here, the same as the RINF Parameter
Values map. Unlike the rest of this tool, the map is not offline and not third-party-free: it fetches tiles
from arcgisonline.com and, if you turn the Railway overlay on, openrailwaymap.org as you pan and zoom.
Appendix D2 numbers the route book; the ontology carries the numbers but not the headings.
ERA annotates each property with era:tsiOPEAppendixD2Index — the index of that term in
“Appendix D2: Elements the infrastructure manager has to provide to the railway undertaking for the Route
Book” — but publishes no title for each index. Elements are therefore named here by their ontology labels,
with the D2 number kept as the legal cross-reference. One D2 element is often several properties, and one
property often serves several D2 elements.
Five D2 elements cannot be filled by anyone today. 3.2.4, 3.2.6,
3.3.5 and 3.3.6 are carried only by era:SpecialArea, and
3.4.7 only by era:RadioBlockCenter; neither class has a single instance in the live
endpoint. The coverage view separates that case — not published by anyone — from an element that other
managers do publish but nothing in this selection does, because they mean very different things to a
route-book compiler.
D2 1.1 takes two registers, and the same URI opens both. Every section of line declares its
manager: era:infrastructureManager points at an era:OrganisationRole, which
era:roleOf resolves to the organisation. RINF knows which organisation but not its name —
all 660 era:Body resources in rinf-plus carry zero foaf:name. The name
comes from the Organisation
Codes Register , queried with the very same URIs RINF returned — no code column, no join key, no matching by
hand. That is what a shared identifier buys, and it is resolved once for every distinct code across the whole
selection, not once per line. The dataset a line is published in is reported alongside, as the separate fact it
is: German line 4000 appears in two of them.
Line identity. 9,543 of the 9,642 era:LinearPositioningSystem resources carry
era:lineId. The 99 that do not are Croatia's 55 and Norway's 32, which put the identifier in the
English rdfs:label instead — NationalRailwayLine_M604,
B03-Kongsvingerbanen. The line list takes era:lineId where it exists and the label
where it does not, and says which it used.Reaching operational points. Most managers position a point with a kilometric post on the
line's own LRS. Croatia's 582 points carry era:uopid and a net reference but nothing tying them
to an LRS, and no era:inCountry either — yet its sections name them with
era:opStart and era:opEnd. Both routes are queried, and the second excludes points
the first already found. It also improves complete networks: French line 830000-1 goes from 327
points to 603.Linear referencing at all. Croatia's net point references carry a geometry and no
era:hasLrsCoordinate, so its sections have no kilometre position. Position is therefore
optional: unpositioned places are reported with — and sorted after the positioned ones, rather
than excluded. Setting a kilometre range necessarily limits results to places that have one.The part-whole link. A place and its tracks are joined by era:isPartOf in
every dataset except Croatia's, which publishes only era:hasPart — 645 tracks that a query
written against the inverse alone never sees. Asking for both in the same query is correct and ruinous: it
takes a German line from 1.4 s to 57 s, because the optimiser can no longer push the property
join. The direction is therefore probed once per line — publishers differ, and with several
countries picked in one run a single global answer would silently be wrong for whichever of them did not
set it — and one form is emitted for that line.Organisation URIs. Names are joined to the Organisation Codes Register on
era:organisationCode, not on the body URI. The URI join works for 25 of the 27 — but Croatia
publishes its manager under both body/organisation/0078 and a bare …/0078_ORG, and
Norway uses …/organisations/0076 where the register has body/organisation/0076.
None of this is guesswork about what a manager meant: each branch queries a property the ontology defines, and
the page reports which branch produced what. The queries are
published alongside the page .
Superseded descriptions are dropped, place by place. The same validity rule as the RCC tool:
the newest window per stretch of line, and per era:uopid then per track at operational points.
Ten countries publish no dated validity at all, and a resource with no validity is always kept.
Retired (owl:deprecated) properties are excluded.
← Back to the ERA Graph Explorer · RDF Exporter ·
RINF Parameter Values · RCC Parameters ·
Ask the Graph · Eurostat Exporter