Possible Feature: A global strecken-rapository

[Josbert Lonnee [NL]]

What about creating a global (public) rapository containing a zusi-representation of a part of the wordt or just Germany. Or does such a thing already exist? It could be given the following functional properties:

- If a user wants to drive for example from Ottobergen to Altenbeken, these 2 stations (with some surroundings) and the strecke between those stations are 'cut out' dynamically;

- A user can also load such a 'cut' into an editor, modify and/or extend it (like modifying / adding scenery) and send his/her new version back to Zusi, who commits the modifications / additions to the rapository after doing checks for correctness;

I think the many advantages of such a rapository are obvious. Some are:
- It brings order in the many Zusi files scattered around the internet;
- The date for the users are always as up to date as possible;
- The data of Bahnhofen is also centralized and need not any more to get copied from file to file any more;


There are of course also some disadvantages:
- A centralized server, with (especially for the future) a high capacity should be needed;
- The serverside funtionality won't be simple. Also some clientside functionality will be needed, but not much. This could probably just be added to a new version of Zusi?

- The positioning of all Strecken in relation to each other wil be difficult. A solution could be to first correctly add many/all main Strecken without any scenery or signals to the repository before someone could build his/her own version of it.

[Christoph Blümer]

There is an "official" institution, the "Zusi-Prüfamt Erlbach" (ZPA), created by the user Stefan Hums. Any add-on is passing his (and his co-workers') institution before becoming "official". Every addon you can find at the http://www.zusi.de webpage is compatible with the programme structure and should be free of serious errors.

Regards,
Christoph

[j]

Thanks for the hint Christoph. That seems indeed to be what I ment.

Maybe the name 'Add-Ons' is somewhat misleading?

Anyway ... So someone came with this idea before me. Still I see many possibilities to make things more dynamic than just a list of files it seems to be now. (Correct me if I'm wrong.)

Such a rapository could be set up like a (giant) database, where a 'cut' (as I described before) could be implemented with a system generating a typical Zusi file online.

For example: If someone once added a Strecke from A to B and someone else once adds e Strecke from B to C, the Strecke from A to C could be generated dynamically.

Regards,
Josbert

[Christoph Blümer]

Every "Strecke" and car can be seen as an add-on in the sense of Zusi, because it ist additional to the simulator...

What you want to create is already existing:
1.) The "ZPA" for official stuff
2.) The "Zusi Exchange" database created by Max Senft for experimental stuff which may be possibly not compatible with the official data structure.

A dynamic generation of Strecken is not possible with the simulator because you need a schedule to run trains that cannot be created automatically!
It is generally possible to combine different parts, but they must have the same altitude level and you need a lot of computing power.

Regards,
Christoph

[Thomas Gabler]

It is generally possible to combine different parts, but they must have the same altitude level

Definitely not.

Tom

[Max Senft]

Hi,

I think Josbert just wants to cut out a part of a landscape and its track. Maybe a square or so. This would be, indeed, very cool, because you won't have to load the entire data. If there's a file created containing the informations where you cut out your part, it should be no problem to put it back in again. I'm not sure if something like that is really doable, but I don't say it's impossible.

The other thing Josbert means is - IMHO - something like CVS. Oliver Lamm created a tutorial for creating something like that for your own track, but not for _every_ track existing 'till now. It's also hard for people not knowing the places of the "strecke" to change something there so it's still realistic. Sure, we could create CVS for non-realistic "strecken" but I don't think it would be used quite often. The most people building a "strecke" are having a homepage putting up screenshots of the current status, so, I don't think this is really needed.

I hope, this post is understandable.

Bye
Max Senft
PS: It's "repository", not "rapository"

[Oliver Lamm]

The main problem might be the connection and the resolving of dependencies between those parts. A zusi route is a very complex item which can not be cut into parts that easy - at least not in the moment.

Oli

[Gast]

Ok, so 'rapository' to 'repository' and 'strecke' to 'track'.

Some answers:

I still think its all technically possible, but it wouldn't be eazy.

What I mean does indeed look a bit like CVS.

If a file-generator generates a Zus file, it must be able to generate functional correctness. This can be done for example by generating a permanenet red signal at the end of each cut-off track.

Yes, a problem with adding new input to the system will be finetuning the height. And this finetuning should also be applied to the other 2 dimentions and possibly the rotation around the vertical axis.

I now think it's best to let the system remember what parts of the repository belong to a railway station / junction point and what belong to piece of track between two of this kind of points. (Note that it's not needed to fill in this 'belong-data' manually.)
The generating (or cutting out) of a track file now involves the data of the two endpoints (stations / junction points), the points in between and all tracks between all those points.

A train schedule can also be generated dynamically. This can, for example, be implemented as follows:
The system should be given a list of kind of trains which usually drive between 2 points. When a track is cut out, the generator can just fill in the track-time space with random trains out of this list.
To create such a generator whould possibly not be simple, but it's just a one-time effort, which can save many work in the future.

I learned it's hard to tell things are impossible in the computerworld.

[j]

Ok, so 'rapository' to 'repository'

Oops. Last message was mine by the way.