What I was wondering is the strange structure of track inside line,
which reminds me of the old railML infrastructure structure (1.x), but
doesn't make sense for the 2.x infrastructure model. Am I right? Does
anybody use this with railML 2.x? Or is it useful to adapt the structure
in the next railML release?

Hello Thomas,
I'm not over the moon with the present visualisation model either. I'm
however convinced that visualisation is important for two reasons:
1. a visual representation of the infrastructure helps both the modeller
and the user. This is highly useful for gaining acceptance of RailML.
RailML can go the GIS-way. Lack of visualisation makes for a very opaque
tool.
2. often, multiple plans, maps, schemas are linked with an infrastructure.
E.g. there's a track plan of a station for maintenance purpose and another
schema of the same station for dispatching. Both refer to the very same
infrastructure. It is helpful to associate more than one set of
coordinates with infrastructure. So, in my opinion, it is great if we can
link an object with several coordinates. This actually reduces the
probability there are multiple discordant plans floating around.

concluding - visualisation is important but the XSD needs some
improvement.

Yours,
Bob Janssen
Siemens NL

Thomas Albrecht wrote:> Dear colleagues,> I had a look at the infrastructure visualization implementation in > railML 2.2.> There is no real documentation in the wiki and no forum post about it.> The only thing I found was the thesis of Hengartner in the document > library dating back to 2003.>
( http://railml.org//index.php/bibliothek.html?file=tl_files/r ailML.org/documents/science/hengartner.thesis_da.pdf)> > <visualization id="infraVis">> <lineVis ref="">> <trackVis>> > </trackVis>> > <trackVis>> > </trackVis>> ...> </lineVis>> </visualization>> > What I was wondering is the strange structure of track inside line, > which reminds me of the old railML infrastructure structure (1.x), but > doesn't make sense for the 2.x infrastructure model. Am I right? Does > anybody use this with railML 2.x? Or is it useful to adapt the structure > in the next railML release?> > Best regards> Thomas Albrecht> TU Dresden> Chair for Traffic Control Systems and Process Automation> tu-dresden.de/vlp> > >

Hello Again Thomas,
the presentation by Eurocontrol made it clear that they use GML for
geographical object description. This may be a way forward as GML has wide
following and is supported by many tools.
Did you ever give thought to that idea ?
Yours, Bob

On 22.08.2013 15:09, at wrote:> Dear colleagues,> I had a look at the infrastructure visualization implementation in> railML 2.2.> There is no real documentation in the wiki and no forum post about it.> The only thing I found was the thesis of Hengartner in the document> library dating back to 2003.> ( http://railml.org//index.php/bibliothek.html?file=tl_files/r ailML.org/documents/science/hengartner.thesis_da.pdf)> > [...]> > What I was wondering is the strange structure of track inside line,> which reminds me of the old railML infrastructure structure (1.x), but> doesn't make sense for the 2.x infrastructure model. Am I right? Does> anybody use this with railML 2.x? Or is it useful to adapt the structure> in the next railML release?

You are right: the railML infrastructure visualisation branch looks
rather like a railML 1.x than the current schema structure of railML
2.2. The reason for this is that while the regular infrastructure schema
has been updated over the years following the documented user
requirements, there haven't been any requests for an update of the
visualisation schema. I guess, it has not been used in the meantime.

However, if there is a need for having this infrastructure visualisation
branch, then we should think about an adaptation of its structure with a
new release.

On 04.09.2013 16:40, Bob Janssen wrote:> Hello Thomas,> I'm not over the moon with the present visualisation model either. I'm> however convinced that visualisation is important for two reasons:> 1. a visual representation of the infrastructure helps both the modeller> and the user. This is highly useful for gaining acceptance of RailML.> RailML can go the GIS-way. Lack of visualisation makes for a very opaque> tool.> 2. often, multiple plans, maps, schemas are linked with an infrastructure.> E.g. there's a track plan of a station for maintenance purpose and another> schema of the same station for dispatching. Both refer to the very same> infrastructure. It is helpful to associate more than one set of> coordinates with infrastructure. So, in my opinion, it is great if we can> link an object with several coordinates. This actually reduces the> probability there are multiple discordant plans floating around.> > concluding - visualisation is important but the XSD needs some> improvement.

thank you very much for sharing your thoughts on the visualisation
model. Indeed, an infrastructure can be transferred in a number of
different graphical representations. Some of these representations are
easy to create directly from the infrastructure data e.g. by using the
geo-coordinates. There has been also an approach for generating
topological map representations from the railML topology data [1]. In
general, the question about which aspects of a graphical representation
have to be explicitly defined and which are implicitly given in the
data, is not easy to answer. In this case, we also rely on the feedback
and the requests of the users of the infrastructure visualisation branch.

On 23.09.2013 15:01, Bob Janssen wrote:> Hello Again Thomas,> the presentation by Eurocontrol made it clear that they use GML for> geographical object description. This may be a way forward as GML has wide> following and is supported by many tools.> Did you ever give thought to that idea ?> Yours, Bob>

PS: Yes, railML infrastructure schema does not use GML so far, but I
agree with you, that before re-inventing a schema for geo-data
representations, we can build on a GML approach.