[Siebren]

For the Open Rail - Web Interface I've added a Map entry. It shows an OpenRailway map with a locomotive icon on the current position of the train. Of course only useful for simulation of real railways. Example:

I use an extra monitor for displaying this map.

I've tested this for the Bernina Pass, the BNSF Scenic SUB and the Edingburgh - Glasgow route. When zooming in the position of the train is not always 100% accurate, but at least it gives you a nice idea where you are and heading for in the real world. The idea is from Flightgear, an open source flight simulator.

Until now this is a private change, but would it be an enhancement for the standard? This would be my first contribution to Open Rails.

regards, Siebren.

[Weter]

Hello and welcome!
Very nice idea, as too often we have to look at map - for understanding, what is around the place, where our train currently is, and what can be watched else, riding along the route.
Must be i-net connection present for doing this, or it would be offline tool?

[Siebren]

You would need an internet connection for the openrailway map.

And by the way if not yet known, you can have a look the openrailway map by using this link https://www.openrailwaymap.org/.

[Weter]

Thanks, I didn't knew that. so Thank You.
Try to PM with Chris Jakeman for discussing technical details.
In parallel, sign-up on GitHub for uploading Your future ORTS contributions.

[joe_star]

Would there be some compensation for the different projections used in OR/MSTS vs openrailwaymap? I can't recall if lat/long are similarly impacted....

[Siebren]

I have not much knowledge about these different projections. I used the latitude/longitude as shown in the compass view:



The conversion to this latitude/longitude is done in Source\Orts.Simulation\Common\WorldLatLon.cs. In https://bugs.launchp...or/+bug/1393111 from 2016 I found a description of a bug in this code. However it was never solved. If I use the numbers:

        int ul_x = -20013965; // -180 deg in Goode projection
        int ul_y = 8674008; // +90 deg lat in Goode projection

found in this bug description results are much better. Still not 100%. For instance: you cannot see in a station with more tracks which track the train is on. But as I already said, it gives you an idea. And it might be the original MSTS coordinates are not 100% correct anyway.

This conversion code is quite complicated. Comment found in the top of it:

    * Contains equations that convert the camera (viewer) position on the current tile
    * to coordinates of world (as in planet earth) latitude and longitude.
    * MSTS uses the so-called "interrupted Goode homolosine projection" format 
    * to define world (i.e. planet earth) latitude and longitude coordinates.
    * This class is used to convert the current location of the viewer
    * to world coordinates of latitude and longitude.
    * Adapted from code written by Jim "deanville" Jendro, which in turn was
    * adapted from code written by Dan Steinwand.
*/
// Principal Author:
//    Rick Grout

[Weter]

Anyway, much better, than nothing, while studying new routes.

[cjakeman]

Weter, on 16 November 2022 - 08:41 AM, said:

Try to PM with Chris Jakeman for discussing technical details.

Good suggestions; I have sent Siebren a PM.

[Siebren]

This enhancement is now available in the unstable build.

To test just open a webpage http://localhost:2150/ in your browser. Or replace localhost if you are not browsing and running OR on the same computer. A webpage with the title Open Rails - Web Interface appears. Which contains an option Map.

[Weter]

Congrats with the first result.

[cjakeman]

Siebren, on 16 November 2022 - 07:35 AM, said:

Until now this is a private change, but would it be an enhancement for the standard? This would be my first contribution to Open Rails.

This map is now available in the Unstable Version.



Would it be useful to have an arrow indicating the direction the train is facing?

Please let us know what you think.

[Weter]

Might be.

[Aldarion]

Seams a great addition, but now that i tested it...

I've recently started laying my portuguese route once again - version 2. Why? because I started laying v1 twelve years ago -> only the first track is placed in the precise coordinates and not in a very precise direction. At the time I already had the experience to undertand that the longer the route, the greater would be the distorciont and hence, the route would be longer thatn in RL if i followed the coordinates. So I ignored coordinates and just followed the track scheme and data that i had with correct lenghts, curve radius etc.

During the pandemic I came across a great post telling how to ger rid of distortion with the use of TSRE's projection and TsreGeoProjection.

Now on testing this new feature... I find that my new Route is not up to it... and I have already layed 200km of it.

My real question here is... ( and maybe other Route developers may have the same question) How will this all work with my route? if it will work at all...
How does this impact the routes already beeing developed. And what has to be done in the future (as far as route developers are concerned) so that new routes work well with this? Something that does not compromise the precions of route building has far as track lenght is concerned (that being my priority concern).

[joe_star]

Aldarion, on 25 November 2022 - 12:48 AM, said:

Seams a great addition, but now that i tested it...

I've recently started laying my portuguese route once again - version 2. Why? because I started laying v1 twelve years ago -> only the first track is placed in the precise coordinates and not in a very precise direction. At the time I already had the experience to undertand that the longer the route, the greater would be the distorciont and hence, the route would be longer thatn in RL if i followed the coordinates. So I ignored coordinates and just followed the track scheme and data that i had with correct lenghts, curve radius etc.

During the pandemic I came across a great post telling how to ger rid of distortion with the use of TSRE's projection and TsreGeoProjection.

Now on testing this new feature... I find that my new Route is not up to it... and I have already layed 200km of it.

My real question here is... ( and maybe other Route developers may have the same question) How will this all work with my route? if it will work at all...
How does this impact the routes already beeing developed. And what has to be done in the future (as far as route developers are concerned) so that new routes work well with this? Something that does not compromise the precions of route building has far as track lenght is concerned (that being my priority concern).

I noted the same on my routes, of which I have found multiple reasons for seeing shifts:

a. Differences between information sources. Google earth/maps vs Open Railway Map. I created most of my marker sets from kml exported out of google earth.
b. Differences between the DEM/satelite view layer vs Map layer, I suspect this becomes more prominent at higher elevations or in mountainous terrain
c. Actual inaccuracies while track laying. I am well aware I had at times not followed prototypical curve radius or at times shifted the track left or right by some meters to better align with DEM & satelite view

What I am not certain on is whether the different projection schemes are also having an influence. In my case, the differences are within 20m-30m, except where there is significant deviation in the OpenRailwayMap vs the sources I had originally used. Regardless, overall I am happy with the results especially when viewed from a reasonably zoomed out view.

[cjakeman]

Siebren, on 18 November 2022 - 07:21 AM, said:

I have not much knowledge about these different projections.

The conversion to this latitude/longitude is done in Source\Orts.Simulation\Common\WorldLatLon.cs. In https://bugs.launchp...or/+bug/1393111 from 2016 I found a description of a bug in this code. However it was never solved. If I use the numbers:

        int ul_x = -20013965; // -180 deg in Goode projection
        int ul_y = 8674008; // +90 deg lat in Goode projection

found in this bug description results are much better. Still not 100%.

Yes, this change which you have now submitted in PR 748 was not applied back in 2016.

To check accuracy, the easiest method is to find a station or known location and use the Open Rails compass (Key 0) to find the values given by Open Rails. Of course, it's possible that route creators have introduced errors in positioning their assets, so a better alternative is to open the route in the MS Route Editor and add a marker at a given lat-lon corodinate. Then use Open Rails to travel to that marker and read its coordinates with the compass.

The 2 constants that Open Rails uses are an attempt to match MSTS as closely as possible. This would be easier if MSTS used the constants in the official documentation for the Goode Homosoline projection. Sadly it doesn't, so we have an error.


Goku's TSRE uses exactly the same constants as Open Rails (James compared the sources), so the Open Rails compass should return the exact lat-lon for a route built using TSRE. Would anyone with such a route like to confirm this, please? (Again, assuming the route was built with no errors in positioning assets.)

Siebren is proposing that we adopt the constants first suggested in 2016. These are available to you in the Unstable Version so that will give different results from the Testing and Stable Versions which have not changed. The proposal would take Open Rails closer to MS Route Editor but open up a difference with Goku's TSRE.

This is a worldwide change so, before we can adopt this proposal, I think we ought to check that it does not have a bad effect in other parts of the world.




Looking at the Goode Homolosine projection above that MSTS and Open Rails use, I would expect the maximum errors to be found away from the Equator and in regions where the lines of longitude deviate more from the vertical.


I would welcome feedback comparing Testing and Unstable Versions for known locations in

• Australia
• South Africa
• Japan
• Moscow
• Scotland
• New York
• Vancouver
• and (for a location where the projection has negligible distortion)
• Texas