Open Looky1173 opened 1 year ago
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.
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?
Property | Value |
---|---|
Posted by | CeeJay (chrisj2110) |
Date posted | Wed, 17 Aug 2016 17:00:12 GMT |
ITs been an annoying Issue for ages!
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.
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
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
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.
Imported from https://bugs.launchpad.net/bugs/1393111
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.