Definition of "track" not complete

[gdschut]

Track (https://era-web.linkeddata.es/doc/index-en.html#Track) has a definition, but it contains the word "track" making it a reference to itself. Also it is not clear where a track starts and ends, and whether it is meant to be

• a topological (functional) edge of the micro network,
• a physical track (making the connection between for example two switches),
• the logical (capacity management) view on the railroad, addressing the place where an RU or IM can do something with a train (halting, connecting splitting, cleaning, waiting, etc) Working towrds micro topology it is essential to know the full meaning of "track" to make sure it can be positioned correctly in the model. Also compare the old RSM/RTM/RailML discussion with Track and Trail.

[gatemezing]

Dear @gdschut, thank you for the point raised. My 2 cents below:

• Regarding the definition, if you have any legal source / trusted source from the sector with a clearly definition, please share it with us. We'll be happy to integrate it.
• In the model (sorry if you don't see all the links), a era:Track era:isPartOf era:SectionOfLine, from which you can have an era:opStart or era:opEnd.
• See this example in PROD for the Section of Line in Amsterdam, where we'll preserve the link between SoL and Track, and from there you'll still reach the topology with a different property.
• I put the two elements from the documentation - the class era:Track and the propertyera:track

[gdschut]

The challenge is nog finding the legal definition, because as far as I know it does not exist. We live in Europe consisting of a lot of different countries, where even more IM's operate, all with their own definitions and models. The challenge for ERA is to find a generic model where alle IM's can put there data in, not to adapt one of the models of 1 IM. For track specific it took us about 3 years of conversations and resulting in an explaining document of several pages with a lot of drawings to explain the wording and definition we wanted to use. That is only for track. We are working with a team of about 10 during the last 10 years on our model and exchange format, and we only have to discuss with Dutch stakeholders. These things really takes a lot of time and effort.

The links you pointed to are all good, but not making complete definitions. Take for example both a design drawing and aerial photo, and ask yourself these questions when describing the tracks on it:

• where does it start?
• where does it end?
• how is the track described in data?
• how is it identified for systems? and for users?
• how is the lifecycle of a track in the data? (design, change, (partly) removed)
• how relates the track to other elements (like the network, navigability, switches, SOL, OP, PLC, levelcrossing, tunnels)
• how is a track described in GIS? What are the possibilities for different ways to describe it in more or less detail?
• How is the functional track related to the physical track? (where functional exists from start of design, and physical is what is outside)
• etc etc

The same sort of questions can be asked for OP. The current definition of OP leaves a lot of space for IM to choose what is an OP for THEM. Resulting in a mess if you gather al the OP of EU. That is the reason it is almost impossible to make the link to PLC (which is a little more narrowed down with its definition) But even when the result of the TWG OP-PLC is implemented it does not result in a better list of OP. IT simply leaves too much space. Resulting in a hard to work with dataset for RU's. Because what is the worth of all those data if OP in one country can be a switch or a signal, and in another country it can be a couple of stations together?

The proof of the pudding is in the eating: If the data of RINF can be put in the new RINF model, resulting in a dataset, on which RU's can make their RCC and Routebook, and PLC's can be used as well other usecases supported, it is a good enough model.