[Simon E]

Goku, on 23 December 2017 - 03:34 PM, said:

I think IGH is best compromise for whole world? Maybe it was choosen for Flight Simulator?

James Ross - this projection looks soo difficult. But if you have any example code to work with I can try.

What? IGH in a Flight Simulator? you gotta be kidding Goku!

And to Ross, I think UTM is a MUCH Better Projection. Thats why Trainz, And Train Simulator (Railworks) 2018 uses it.

Also put a radio button somewhere to choose the old MSTS Projection and UTM.

and TSRE writes ORTSGeoProjection(MSTS) or ORTSGeoProjection(UTM) in the .trk file. So some innocent novice, doesn't go fiddling with switches in the options dialog in OR.

[Simon E]

I also wish, that you could come up with a way to Move And or rotate an entire Route to its correct co-ordinates..

[Simon E]

James Ross, on 23 December 2017 - 01:05 PM, said:

They appear in the compass window and HUD in MSTS IIRC.

These GIS Programs (Both open Source) Maybe useful to you.

http://mapwindow4.codeplex.com/

And this is in c#
http://dotspatial.codeplex.com/

It will have code to screw around with this kind of stuff. (I have used these for real world railway based project, and I remember thinking of OpenRails and MSTS, while looking at code...) S I think it has exactly what you want.

ALSO ALMOST PROBABLY USEFUL TO YOU TOO GOKU..

[James Ross]

Goku, on 23 December 2017 - 03:34 PM, said:

James Ross - this projection looks soo difficult. But if you have any example code to work with I can try.
I'd like to give something for users as fast as possible.

That is not a good strategy. You should at least consider some of the options; there have been plenty of discussions here about projections and the options seem to always come back to Transverse Mercator (TM ) although, having looked at it today, Universal Transverse Mercator (UTM) seems like a better option (see below).

Simon E, on 23 December 2017 - 03:38 PM, said:

And to Ross, I think UTM is a MUCH Better Projection. Thats why Trainz, And Train Simulator (Railworks) 2018 uses it.

When making claims of "better" you really ought to include reasoning, even if it's just a link to a respectable source.

UTM and TM are strongly related as their names imply; TM is a projection down a single longitudinal line with good accuracy near to this line (a few degrees to either side), where as UTM is a collection of 60 of these TM "strips" stitched together to create a worldwide version.

Therefore, it seems that the only significant difference between UTM and TM is that UTM provides a global map, where as TM only provides it within a single longitudinal strip. Both provide similar properties (e.g. conformal) and accuracy AFAICT. I would say that UTM is the better choice simply because it is worldwide.

Simon E, on 23 December 2017 - 03:38 PM, said:

and TSRE writes ORTSGeoProjection(MSTS) or ORTSGeoProjection(UTM) in the .trk file. So some innocent novice, doesn't go fiddling with switches in the options dialog in OR.

Nobody has suggested this is a user option in OR AFAICS; this is an option for the route creator only and whatever is selected will be included in the route data somewhere, most likely the track data file (.trk).

[Simon E]

James Ross, on 26 December 2017 - 03:33 AM, said:

That is not a good strategy. You should at least consider some of the options; there have been plenty of discussions here about projections and the options seem to always come back to Transverse Mercator (TM ) although, having looked at it today, Universal Transverse Mercator (UTM) seems like a better option (see below).


When making claims of "better" you really ought to include reasoning, even if it's just a link to a respectable source.

UTM and TM are strongly related as their names imply; TM is a projection down a single longitudinal line with good accuracy near to this line (a few degrees to either side), where as UTM is a collection of 60 of these TM "strips" stitched together to create a worldwide version.

Therefore, it seems that the only significant difference between UTM and TM is that UTM provides a global map, where as TM only provides it within a single longitudinal strip. Both provide similar properties (e.g. conformal) and accuracy AFAICT. I would say that UTM is the better choice simply because it is worldwide.


Nobody has suggested this is a user option in OR AFAICS; this is an option for the route creator only and whatever is selected will be included in the route data somewhere, most likely the track data file (.trk).

I should have explained in more detail. You have already done as much, so thats out of the way. And it is why i suggested UTM.

And yeah, I do propose, That Option is set by a route builder, and once its set, it shouldn't be fiddled with. Otherwise you will end up with a pretty strange looking route.

[Simon E]

Im quite surprised by the lack of interest about this subject.... Anyway, If its any consolation, Guys, I am VERY Interested in this subject.

[ebnertra000]

I am quite interested in this, as well. I have given some consideration to modelling in a place like Japan, where the current projection is complete rubbish. Unless, of course, OR doesn't bother with MSTS's projection of the World

[Simon E]

ebnertra000, on 09 January 2018 - 09:14 PM, said:

I am quite interested in this, as well. I have given some consideration to modelling in a place like Japan, where the current projection is complete rubbish. Unless, of course, OR doesn't bother with MSTS's projection of the World

See what I mean? The MSTS projection is totally useless for Japan. And other places too. I wish that was not the case. Fixing the Map projection, would get rid of this problem. We are going to make 1067mm tracks, But what use are they, when the Map is distorted!

If this problem was not there in the first place, There would be tons of Japanese routes and Trains. (I would like to see these myself)

[Genma Saotome]

James Ross, on 26 December 2017 - 03:33 AM, said:

That is not a good strategy. You should at least consider some of the options; there have been plenty of discussions here about projections and the options seem to always come back to Transverse Mercator (TM ) although, having looked at it today, Universal Transverse Mercator (UTM) seems like a better option (see below).


UTM and TM are strongly related as their names imply; TM is a projection down a single longitudinal line with good accuracy near to this line (a few degrees to either side), where as UTM is a collection of 60 of these TM "strips" stitched together to create a worldwide version.

Therefore, it seems that the only significant difference between UTM and TM is that UTM provides a global map, where as TM only provides it within a single longitudinal strip. Both provide similar properties (e.g. conformal) and accuracy AFAICT. I would say that UTM is the better choice simply because it is worldwide.

I don't think that is correct James. Please review this post by Lindsay. He says with UTM there is not a clean match from any one of the strips to one adjacent. If that indeed is the case then I'd say that would be a fatal flaw.

[James Ross]

 Genma Saotome, on 10 January 2018 - 12:17 AM, said:

I don't think that is correct James. Please review this post by Lindsay. He says with UTM there is not a clean match from any one of the strips to one adjacent. If that indeed is the case then I'd say that would be a fatal flaw.

It's very hard to get a straight answer from the information I have over what the problem with UTM is, but it might be angles. E.g. a straight line around the globe would have a slight kink on each UTM boundary. It's even harder to know what the degree of error would be.

There's also the possibility of projecting it as a 3D world in-game, which would be a complex change, but I believe would avoid issues like the UTM zone boundaries.

This will require some more thought, unfortunately.

[Simon E]

 James Ross, on 10 January 2018 - 12:43 PM, said:

It's very hard to get a straight answer from the information I have over what the problem with UTM is, but it might be angles. E.g. a straight line around the globe would have a slight kink on each UTM boundary. It's even harder to know what the degree of error would be.

There's also the possibility of projecting it as a 3D world in-game, which would be a complex change, but I believe would avoid issues like the UTM zone boundaries.

This will require some more thought, unfortunately.

They Project UTM Tiles in 3D Space in Trainz, So it is possible. I dont know how hard it is to do. Its done with 3rd Party Software, Not in Trainz Itself. It might be a good thing to Implement. I have this software. I probably could make something like it, but for Open Rails.

And yeah, It does need well thought out. Not like the mess Kuju/MS Created!

[BillC]

 Simon E, on 11 January 2018 - 12:14 AM, said:

They Project UTM Tiles in 3D Space in Trainz, So it is possible. I dont know how hard it is to do. Its done with 3rd Party Software, Not in Trainz Itself. It might be a good thing to Implement. I have this software. I probably could make something like it, but for Open Rails.

And yeah, It does need well thought out. Not like the mess Kuju/MS Created!

The third party software that you mentioned is TransDem. This software has been discussed in the private OR development forum. A member WaltN in the past has corresponded with Dr. Ziegler the author.

You may be interested in these threads in the TrainZ fourm, Why to avoidLat/Long-Reader with TransDM routes andLOD again (test build 78095) #5. In addition Converting UTM to Trainz World Coordinates on Dr. Ziegler’s forum. Geophil is Dr. Ziegler’s handle on the forum.

In general TansDem takes a given DEM source, converts it to UTM. Then translates those to TWC coordinates.

[Simon E]

 BillC, on 11 January 2018 - 09:50 AM, said:

The third party software that you mentioned is TransDem. This software has been discussed in the private OR development forum. A member WaltN in the past has corresponded with Dr. Ziegler the author.

You may be interested in these threads in the TrainZ fourm, Why to avoidLat/Long-Reader with TransDM routes andLOD again (test build 78095) #5. In addition Converting UTM to Trainz World Coordinates on Dr. Ziegler’s forum. Geophil is Dr. Ziegler’s handle on the forum.

In general TansDem takes a given DEM source, converts it to UTM. Then translates those to TWC coordinates.

Yes. Thats the one. TransDem. We could probably do something like it.

[Genma Saotome]

 Simon E, on 11 January 2018 - 12:57 PM, said:

Yes. Thats the one. TransDem. We could probably do something like it.

No need to do much of anything. Look at qGIS: Open Source, free, is still being enhanced, does conversions to over 2000 different projections. There are hundreds of TM and UTM projection "targets" to choose from and AFAIK qGIS can read data from an equal number of projections. So if you start with US NED and wish to finish with TM South Dakota you can. Did I say FREE? OPEN SOURCE? Yup.

The initial task would be to gain some understanding of which projections to use when. After that it becomes a decision point to leave the whole matter up the route developer to obtain and export his DEM data in the chosen type (e.g., TM or UTM) and leave it up to him to chose which of the many targets are suitable... or whether some enterprising soul takes on task of integrating the open source functions into something more closely tied tot he software we use. Either way should work.

qGIS works with DEM data, ortho-photographs, gobs of different map data. I am unaware of its ability to use OSM files but that could be a task to do.

Like all GIS tools there is a huge amount of functionality present that would probably never be relevant to our interests. What appealed to me in selecting qGIS for my own work was the user interface was the easiest for me to decipher -- every thing I needed was on one tab. I can take USGS DEM data (in .img format) and convert that to geotiff for DEMEX with a minimal amount of effort put in to understand how to use the software to accomplish that, slice up that dem data into subset images and merge multiple DEM files (or geotiff files) into larger images. All very, very easy to do and do so w/ no need to explore >90% of what the other tabs can do. Sweet... simple to learn.

[BillC]

 Genma Saotome, on 11 January 2018 - 04:09 PM, said:

No need to do much of anything. Look at qGIS: Open Source, free, is still being enhanced, does conversions to over 2000 different projections. There are hundreds of TM and UTM projection "targets" to choose from and AFAIK qGIS can read data from an equal number of projections. So if you start with US NED and wish to finish with TM South Dakota you can. Did I say FREE? OPEN SOURCE? Yup.

The initial task would be to gain some understanding of which projections to use when. After that it becomes a decision point to leave the whole matter up the route developer to obtain and export his DEM data in the chosen type (e.g., TM or UTM) and leave it up to him to chose which of the many targets are suitable... or whether some enterprising soul takes on task of integrating the open source functions into something more closely tied tot he software we use. Either way should work.

qGIS works with DEM data, ortho-photographs, gobs of different map data. I am unaware of its ability to use OSM files but that could be a task to do.

Like all GIS tools there is a huge amount of functionality present that would probably never be relevant to our interests. What appealed to me in selecting qGIS for my own work was the user interface was the easiest for me to decipher -- every thing I needed was on one tab. I can take USGS DEM data (in .img format) and convert that to geotiff for DEMEX with a minimal amount of effort put in to understand how to use the software to accomplish that, slice up that dem data into subset images and merge multiple DEM files (or geotiff files) into larger images. All very, very easy to do and do so w/ no need to explore >90% of what the other tabs can do. Sweet... simple to learn.

Dave,
FWIW here are some of my observations on QGIS

QGIS does the functions as you mentioned in the 1st paragraph. Namely a given projection to UTM like TransDem. UTM is based on WGS84 so would be a suitable world CRS, as would also TM. However ESRI recommends limiting 12-15 deg. on each side of the central meridian. The distortion would be too great beyond that distance. Since QGIS Lisboa there is a proj4 conversion for IGH. Since we don't know the exact datum that that MSTS used for their projection, doubt that this would be useful for a target or source. OSM is WGS Web Mercator like Google and Bing maps without the license restrictions.

For open source the QGIS infrastructure use's C++, and Qt as the interace (same as Goku). Possibly a better approach would be to customize using Python plugins which it supports. As mentioned 90% of QGIS is not used. For a "DEMEX" tool from selection to tile output would still be a large task, IMHO not worth doiing for IGH. For a conformal projection (equal angles) if OR changes to rectangular grid may be worth doing.