openrails / test-launchpad-bugs

TEST repository for Launchpad bug migration exploration
0 stars 0 forks source link

[BUG 1393111] Latitude and longitude don't match MSTS (and are wrong generally) #91

Open twpol opened 9 years ago

twpol commented 9 years ago

Imported from https://bugs.launchpad.net/bugs/1393111

Property Value
Reported by Herb Kelsey (hkelsey41)
Date reported Sun, 16 Nov 2014 01:14:47 GMT

Since we are stuck with using the MSTS Route Editor for fixing errors like trees in the middle of the roadway on account of overlapping forests and stuff of that ilk, it would be handy if the Latitude and Longitude of the problem location in Open Rails would be close enough to the Latitude and Longitude in MSTS so you could find the problem in the other software and fix it. The difference is a good half mile of distance from the problem and where Lat Long says it is. Checking coordinates for both MSTS and OR against latitude/longitude lookup sites it would appear that MSTS is spot on, so the problem exists in OR.ttttgffddfddfffff dont do this

twpol commented 8 years ago

Imported from https://bugs.launchpad.net/or/+bug/1393111/comments/1

Property Value
Posted by Edward Keenan (edwardk)
Date posted Tue, 16 Aug 2016 22:11:26 GMT

Following up with message indicating that this is known issue.

Edward K.

twpol commented 8 years ago

Imported from https://bugs.launchpad.net/or/+bug/1393111/comments/2

Property Value
Posted by Herb Kelsey (hkelsey41)
Date posted Wed, 17 Aug 2016 00:57:17 GMT

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?

twpol commented 8 years ago

Imported from https://bugs.launchpad.net/or/+bug/1393111/comments/3

Property Value
Posted by CeeJay (chrisj2110)
Date posted Wed, 17 Aug 2016 17:00:12 GMT

ITs been an annoying Issue for ages!

twpol commented 8 years ago

Imported from https://bugs.launchpad.net/or/+bug/1393111/comments/4

Property Value
Posted by Herb Kelsey (hkelsey41)
Date posted Wed, 17 Aug 2016 23:32:39 GMT

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.

twpol commented 5 years ago

Imported from https://bugs.launchpad.net/or/+bug/1393111/comments/5

Property Value
Posted by Dean Stalker (dean-stalker)
Date posted Sun, 16 Jun 2019 13:09:21 GMT

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

twpol commented 5 years ago

Imported from https://bugs.launchpad.net/or/+bug/1393111/comments/6

Property Value
Posted by Dean Stalker (dean-stalker)
Date posted Tue, 18 Jun 2019 12:19:01 GMT

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

twpol commented 1 year ago

Imported from https://bugs.launchpad.net/or/+bug/1393111/comments/7

Property Value
Posted by Siebren Weiland (sweiland-openrails)
Date posted Thu, 17 Nov 2022 16:02:12 GMT

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.