[Goku]

Because more and more users decide to create new routes using TSRE, alternative projection for better experience with OSM map layers becomes very important.

So, I couldn't wait much longer for OR team decision (how many years is it?) about new projection and I made it myself.

Now it is possible to use more than one projection in TSRE.

By default TSRE uses MSTS IGH projection.
But, if this line is found in .trk file:

TsreGeoProjection ( 48.8485 2.29143 -12340224 30290944 )

TSRE will use new TSRE projection.
This line describes center point in the world. From this LatLon average distance in meters per degree is calculated, and TSRE use it for the whole route.
Last two numbers is center point in the internal coordinates, so it is possible to define center point at custom world tile location.
Any ideas of better definition in .trk file are welcome.

This projection presrves angles and right shapes.

https://i.imgur.com/dqjJsWT.jpg

[Goku]

Of course this projection isn't perfect, in London - 350 km north from center point the distortion becomes visible too:
https://i.imgur.com/IENLPzi.jpg
I'm sorry. By mistake I used MSTS projection instead of TSRE projection xDDD

In TSRE is looks much better even 350 km away:
https://i.imgur.com/6o19gcE.png

--
At 250 km radius there is almost no distortion:

https://i.imgur.com/bWk4pDE.jpg

[Genma Saotome]

Many concerns, most are probably not really an issue but are just matters of trying to figure out what this all means and where it is going:

• What, if any, effect occurs in OR calculation of distance and train speed due to not using the Goode-Homosoline projection?
  
• Was any of this proposal discussed w/ the OR team?
  
• Is TSRE the going to be the only tool that can project terrain or can the methods be used by other people in other programs?
  
• What does this mean for images obtained from any non-OSM source?
  
• Will you be adding geotif (.tif) and .img file formats for DEM data? Those of us who have lots of DEM data collected over the years do not have .hgt files.
  
• Any change to tile size?
  
• Any change to file formats used to hold projected terrain data?
  
• Will the TSRE projection of terrain data process n tiles as part of the same processing transaction? Most routes have a bit less than 2000 tiles anbd so we'll want to process as many tiles as possible in one transaction
  
• Must the DEM source data conform to a specific boundary (e.g., 0.5 degree, square) or area (n square kilometers) in order to processed with this new code?

[Goku]

Quote

What, if any, effect occurs in OR calculation of distance and train speed due to not using the Goode-Homosoline projection?

OR doesn't use lat/log for almost anything.

Quote

Was any of this proposal discussed w/ the OR team?

No, see beginning of my first post.

Quote

Is TSRE the going to be the only tool that can project terrain or can the methods be used by other people in other programs?

The code is 100x simpler than IGH code, so if someone managed to use IGH projection, this one will be much easier for him.

Quote

What does this mean for images obtained from any non-OSM source?

You see it above, first post.

Quote

Will you be adding geotif (.tif) and .img file formats for DEM data? Those of us who have lots of DEM data collected over the years do not have .hgt files.

No one provided me source with geotiff to work with.

Quote

Any change to tile size?
Any change to file formats used to hold projected terrain data?
Will the TSRE projection of terrain data process n tiles as part of the same processing transaction? Most routes have a bit less than 2000 tiles anbd so we'll want to process as many tiles as possible in one transaction
Must the DEM source data conform to a specific boundary (e.g., 0.5 degree, square) or area (n square kilometers) in order to processed with this new code?

There is no change in TSRE route editing code at all. Nothing changes in the route data. It is just different function to transform "Tile XY xyz" coordinates to "LatLon" and "LatLon" to "Tile XY xyz".

[Goku]

No one interested with this topic?

[cjakeman]

Goku, on 22 December 2017 - 02:16 PM, said:

OR doesn't use lat/log for almost anything.

There is no change in TSRE route editing code at all. Nothing changes in the route data. It is just different function to transform "Tile XY xyz" coordinates to "LatLon".

So I expect Open Rails will continue to work just fine, but we need details of that function so we can report the correct Lat/Lon for TRK files containing TsreGeoProjection().

[Goku]

I think implementation in OR will be easy.
But I'm still thinking if make the projection better or leave it simple.

In next version of TSRE it is also possible to measure real world distances:

Example with MSTS projection and Japan - clearly IGH is useless for this part of the world.
https://i.imgur.com/baL8kTd.png

[James Ross]

Goku, on 22 December 2017 - 01:24 PM, said:

So, I couldn't wait much longer for OR team decision (how many years is it?) about new projection and I made it myself.

I believe the best option suggested so far is ellipsoidal transverse Mercator, so I highly recommend you implement that.

[Goku]

It is terrible for India, south America .. I think global projection isn't good choice here.

[James Ross]

Goku, on 23 December 2017 - 10:37 AM, said:

It is terrible for India, south America .. I think global projection isn't good choice here.

It's not a global projection, the central meridian is chosen and must be provided with the data. Note this line in the Wikipedia page with my emphasis added:

Quote

Near the central meridian (Greenwich in the above example) the projection has low distortion and the shapes of Africa, western Europe, the British Isles, Greenland, and Antarctica compare favourably with a globe.