latitude/longitude fix for bug 1393111

[sweiland-openrails]

See https://bugs.launchpad.net/or/+bug/1393111

Don't know if this fix is 100% correct. However conversion is better with this values.

[cjakeman]

Hi Siebren,

I've checked to find that these 2 values have not been changed since at least 29-Jan-2013.

There is a reference on Elvas Tower to author Rick Grout and also James Ross at (http://www.elvastower.com/forums/index.php?/topic/21976-does-or-convert-lon-lat-to-tile-coordinates)

I cannot find any complaint on Elvas Tower that OR LatLon is inaccurate and I guess that's because noone has tried to match OR with a map as closely as you have.

If we adopt this change (and we will, of course, try it first in the Unstable Version), I assume it will affect positions all around the world. (I'm not a model builder, so I might be assuming too much.) So I wonder where in the world was the largest discrepancy that you found and how many metres was it? With your new values, are there still discrepancies elswhere in the world and how large might they be?

Chris

[sweiland-openrails]

hi Chris,

this bug 1393111 is filed in 2014. Comments are from 2016 and 2019. This was all I could find about this issue. So I guess not many people are using this latitude/longitude values. And I was glad the two changed values solved my problem to some degree. I'm not sure this conversion is used elsewhere in the OR code.

And it's not that the discrepancy is stable during one route. Along the route it differs. Otherwise I could have done something with some correction values in a file. I had coded the file with corrections already, but no luck.

I'm not a model builder either. I just found the latitude/longitude values in the compass window and from there worked my way into the OR code till I found this conversion.

regards, Siebren.

[cjakeman]

Hi Siebren,

I've tried this bug-fix along with the map enhancement on the Demo Model 1 at Edinburgh. Before the bug-fix the discrepancy was 3.2 km and after it was less - 1.2 km, which is better but not ideal.

Next Saturday I am meeting on-line with James Ross (twpol) who is our technical lead and had a personal input into these calculations. I expect he will have some useful thoughts about it.

Of course, Open Rails is here trying to provide the inverse to the Microsoft function which converts LatLon to a location on a tile and we don't have access to that function. Any errors in Microsoft's implementation also show themselves as displacements on your map.

There is also the issue of Goku's TSRE Route Editor (for which we have the source code). It could be that routes built using TSRE are more correct than ones built using Microsoft's Route Editor. In which case, your correction could make the displacement worse on a TSRE-built route.

Best wishes,

Chris

[sweiland-openrails]

Chris,

Is there a route available created with the TSRE editor? So that we could check? And do you have any idea how this TSRE route editor matches their railway lines with the ones in the real world?

Anyway it's also good to wait for the comments of James Ross.

regards, Siebren.

[cjakeman]

Hi Siebren,

Thanks for raising this issue.

I discussed it with James. It turns out that he came up with the original constants and these have been adopted by TSRE. I have posted on your thread in some detail and I'm hoping that we can be confident that these new constants give better results in some parts of the world and don't give worse results anywhere else.

Best wishes,

Chris

[cjakeman]

As reported on the forum, measurements show improved accuracy for:
Australia, Scotland, Germany, Portugal, Chicago and Seattle (near Vancouver).

We are still awaiting results for:
Japan, Moscow, South Africa

[cjakeman]

Change is included in PR 749, so this PR is no longer needed.