[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

[Weter]

We all know two japanese routes, one scottish and many australian.
There are two routes, known to me: on in Moscow itself, and another is 125 km to the North.
But it's unknown to me, how precise authors followed coordinates of the real-word trackwork there.

My personal route-builder's observations about distortion are reported in topic about training project.

[Siebren]

I've tested some routes and took a look at the maps. My findings:

* Chicago - Seattle: lat-lon fix make it definitely better. Placing in Everett is in the station, without fix in the city itself

* Bernina: same, much better, quite usable

* Edinburgh - Glasgow: better, but not as much as the above two

* Chiltern (London): unusable with/without correction

* OR_CPV (Portugal Algarve): unusable with/without correction

* Ruebelandbahn (Germany): usage good with correction

Don't know with which editor these routes are created. I don't see any relation between the location of the routes and the usability. When I started coding I used the Bernina bahn in Zwitserland - Italië for testing. And by then I was quite surprised with the usability. It also depends on the complexity of the railplans. The Bernina bahn is more or less one long stretch. London is much more complicated. For flightgear, where I found this map, this usability is not an issue. As the route between two airfields is not hard coded like with rail tracks. As long as the airfields are on the correct location everything is fine.

Can anyone tell me the name of a TSRE created route?

And I'll have a look if an idea I have can be implemented. Dragging the locomotive icon or double clicking on the map where the actual location is. And store the correction calculated that way somewhere related to the route. But technically that would mean feeding back data into the OR webserver. Done that before but not for Open Rails. Seen some API forum messages where that was happening, feeding data from the webpage back into OR.

[cjakeman]

Siebren, on 04 December 2022 - 03:06 AM, said:

* Chiltern (London): unusable with/without correction

* OR_CPV (Portugal Algarve): unusable with/without correction

And I'll have a look if an idea I have can be implemented. Dragging the locomotive icon or double clicking on the map where the actual location is. And store the correction calculated that way somewhere related to the route. But technically that would mean feeding back data into the OR webserver.

I'm guessing that "unusable with/without correction" means that the Lat-Lon is so far away that your animated map is useless.

Can you also tell us whether the error is larger with your proposal or smaller in these two cases?

Working with Edinburgh, I tried using your proposed constants and also adding an offset to the Lat-Lon to position the train in the right platform at Waverley. I guess this is equivalent to your idea of dragging the loco icon to where the actual location is. Then, when the train travels westward, it very quickly deviates from the track on the map.

That was disappointing, and I assume it is because Scotland has some distortion as shown by the grid on the Goode projection above. Instead of offsetting the Lat-Lon, perhaps we should be adjusting the constants to achieve the right Lat-Lon but I haven't tried that yet.


I am coming to the view that each region of the globe should have its own constants and perhaps these can be provided as part of the route.

[Weter]

Some authors turn their "maps" of real-based routes 90⁰ due to unknown for me reason.

[BillC]

cjakeman, on 04 December 2022 - 11:41 AM, said:

I'm guessing that "unusable with/without correction" means that the Lat-Lon is so far away that your animated map is useless.

Can you also tell us whether the error is larger with your proposal or smaller in these two cases?

Working with Edinburgh, I tried using your proposed constants and also adding an offset to the Lat-Lon to position the train in the right platform at Waverley. I guess this is equivalent to your idea of dragging the loco icon to where the actual location is. Then, when the train travels westward, it very quickly deviates from the track on the map.

That was disappointing, and I assume it is because Scotland has some distortion as shown by the grid on the Goode projection above. Instead of offsetting the Lat-Lon, perhaps we should be adjusting the constants to achieve the right Lat-Lon but I haven't tried that yet.


I am coming to the view that each region of the globe should have its own constants and perhaps these can be provided as part of the route.

Hi Chris
I am not going into the horros of the GH projection, this has been discussed in many prior posts. The poblem discussed above has to do re-projecting GH on Web Meracator projection from GPS coordinates used with Open Street Maps, from which OpenRaiway map is a derivitive.

For back ground look at some of the folloing web links:

GISsurfer Map with Military Grid Reference Sysytem (MGRS) Coordinates Learn MGRS with color-coded coordinates

In the reference pdf GISsurfer USNG and MGRS Coordinates section 3. 911 dispatching and responding discusses problems using GPS coordinages from there phones, UTM coordinates, and an address.

A Guide to Coordinate Systems in Great Britain goes into highly technical detail. However, section 1.2 A few myths about coordiante systems, is worth a read.

This document MAP.ARMY discusses MGRS system in detail.

IMHO I agree with your conclusion that each route has to be tuned to it's own constants, taking there "poetic license" in account.

Bill