Latitude and longitude don't match MSTS (and are wrong generally)

Following up with message indicating that this is known issue.

Edward K.

All right, fine. But that doesn't really help the situation, does it? Over a year and a half since filing the bug and all we get is "known issue?" We know it's a "known issue!" Do you have any intent to solve the problem?

ITs been an annoying Issue for ages!

Edward, I apologize for unloading on you. You are not the target. Just pure frustration in working with existing and new routes when you have to enter lat long then hunt for what your looking for. What I'm usually reduced to is figuring out, in OR, how many telegraph poles the problem is from Mile Post "X", then opening MSTS Tools, open AE, bring up "new activity, "find the MSTS coordinates for MP "X" and then close AE, open RE, Home key and enter the coordinates, find the MP and then work back the number of poles to get to the spot.

It shouldn't be this hard. The only other alternative is using the x y coordinates in the Debug screen but that isn't any closer than the lat/long.

Again, Edward, I'm sorry for being harsh. It isn't you but rather the frustration. Please forgive me.

Seems to be a problem with the default corners in the WorldLatLon.cs file - the projections better match up if the corners are set to -

ul_x = -20013965
ul_y = 8674008

Sooo .. I now see why its a difficult one to solve, you're literally working with a fast moving target. It seems the offsets vary depending on the world tile in scope of the current view.

I ported WorldLatLon.cs to golang to play with it easily on the command line.

 Using the Coals to Newcastle Route, I parked the camera under a known bridge in Taree - correct coords are -31.899305, 152.467734. WorldLatLon calculated it at -31.907621846997195, 152.44948874630478. So to try and line it up correctly, I changed the World Tile EW/NS offsets to double, and used precision to try and bump it closer to where it should be.

Incorrect:

ew_offset = -16385
ns_offset = 16385

go run main.go -ew=1564 -ns=10417 -x=-70.77898 -y=13.19096 -z=-548.0775
Goode World Tile X 17949
Goode World Tile Y 5968
Location on tile: -70.77898 -548.0775
Location on tile (cast): -70 -548
X coords 16742433
Y coords -3547964
GX / GY 1.6742433e+07 -3.547964e+06
Region 9
Radian - Latitude / Longitude -0.5568930577113754 2.660745521605061
Degrees - Latitude / Longitude -31.907621846997195 152.44948874630478

vs

Close to correct:

ew_offset = -16385.8929888
ns_offset = 16384.54879

go run main.go -ew=1564 -ns=10417 -x=-70.77898 -y=13.19096 -z=-548.0775
Goode World Tile X 17949.8929888
Goode World Tile Y 5967.548790000001
Location on tile: -70.77898 -548.0775
Location on tile (cast): -70 -548
X coords 16744262
Y coords -3547039
GX / GY 1.6744262e+07 -3.547039e+06
Region 9
Radian - Latitude / Longitude -0.5567478685047254 2.661064033661856
Degrees - Latitude / Longitude -31.899303118225294 152.46773814288318

hi,

long time ago this bug was entered. Looks like the values mentioned by Dean:

ul_x = -20013965
ul_y = 8674008

are more valid then the current ones.

I would need this fix for an enhancement I'm planning: an openrail map in the browser.

Can I create a pull request for this? It might not be 100% correct, but at least it looks much better.

regards, Siebren.