jonas, on 20 April 2021 - 10:32 AM, said:
Wrong. If files are readable (i.e. not binary), there will always be users who will edit the file directly, whether there is an editor or not.
Users are now editing .con files, .w files and even the .tdb if necessary, even though these are (or can) be created through editors.
There are always two groups of people - those with no or limited knowledge of the data structure who therefor are happy to use the editor. And those who have that knowledge and just find editors cumbersome or too restricted, especially when things go wrong. That's how it always has been, that's how it always will be.
Quote
Well, even if there is such an aim (which I doubt), given the sparce development capacity it's just never going to happen. There will never be editors for all types of data files presently used in OR, and as long as new data is added without its own editor (like, in fact, turntables and clock) that problem is only growing.
Quote
With that, you have just landed JSON as file format for OR onto the dustheap. Definitely. Forever.
For the next person to come along with new data can, of course, use this same argument. And the next. And the next. And ..... (ad infinitum).
In fact, the clock data is an ideal candidate for conversion to JSON, for the following reasons :
- It is a relatively small and simple file.
- It has not yet been spread in any large numbers.
- It is not aimed at actual users but at route builders, which is only a small subset of the total number of users.
- There is already a conversion available so it will take not much work to introduce it as JSON.
The decision to set JSON as standard for new data has been made some time ago. Of course there is no 100% consensus among all users or even developers for that decision, which such a varied group there never can be. But the decision has been made and ignoring it is not going to help to improve the overall OR data structure.
You started this thread by pointing out the hotch potch of data used in OR. There is no magic wand to change that overnight. Improving the data consistency can only be done in small steps. The first of those steps was the decision to set JSON as standard. The second step was the introduction of the first JSON data - the wheather files. You can make that very important third step. By insisting on your arguments to stick to STF you provide loads of ammunition to other developers to keep on using their own preferenced data formats, thus not only maintaining that hotch potch but even making it worse.
Or, you can accept the conversion to JSON and with that take away that ammunition. For then we have two files in JSON, so when other new data is introduced, we can say : "look, all new data has now been introduced as JSON so please follow suit."
So, you are actually holding the key for improving the OR data structure. The choice is yours.
Regards,
Rob Roeterdink