[Lindsayts]

Goku, on 30 June 2016 - 01:09 PM, said:

In most places in the world, map layer in GH projection has acceptable angles. Thats the purpose of GH projection - to have acceptable angle, distance and area values.

Depends on what one calls exceptable, OpenRails in Victoria Australia has an error in distance of around minus 1.5%. As far as i am concerned such an error in a supposedly accurate train sim is not acceptable, particularly when much better accuracy can be acheived.

Lindsay

[Genma Saotome]

Goku, on 30 June 2016 - 01:09 PM, said:

In most places in the world, map layer in GH projection has acceptable angles. Thats the purpose of GH projection - to have acceptable angle, distance and area values.

Bull. In most places in the world the GH projection skews all right angled street intersections. Here are two examples for the US (and this occurs everywhere in the US) (and is far, far worse in Japan):
 ge01.jpg (119.7K)
Number of downloads: 71
 ge02.jpg (142.8K)
Number of downloads: 63

In addition to ruining every right angled intersection the distances within the skew are off: Measuring from the bottom corner across to the opposite top corner you get different distances. Not much on these city blocks but for any route whose start to end track journey follows that corner to corner direction it really adds up... 5% to 10% longer or shorter per 100 km (or miles) is not uncommon.

About the only place in the world where this is not a problem is in Congo.

[Rohit]

Please help...

I have created a small activity after creating two stations to check the route...But the following figures shows the issues:-
Capture:- Shows signals are not working...

Capture1:- Shows irregular traction lines...multiple branched instead of single...

Capture2:- Shows a dynamic track section created by mistake...It is not seen in RE...Hence I cannot delete this..Also see the traction lines...

Capture3:- Another view of capture 2.

Also the route is not opening in MSTS...

Attached File(s)

•  Capture.JPG (123.63K)
  Number of downloads: 35
•  Capture1.JPG (145.98K)
  Number of downloads: 37
•  Capture2.JPG (120.43K)
  Number of downloads: 40
•  Capture3.JPG (102.64K)
  Number of downloads: 37

[longiron]

Goku,

When you get a chance - the math for elevation of track has the decimal point in the wrong place - reads 11.3167, when it should be 1.13167. The one in xx, does calculate correctly.

http://www.elvastower.com/forums/uploads/monthly_07_2016/post-859-0-42675800-1467567752_thumb.jpg

And a suggestion, MSTS RE changes the cursor image depending on what task you are doing. A big "x" for object placement, a "circle" for terrain manipulation, etc. It's a excellent visual clue what function is currently live. Please give some consideration to something like that. If it's too difficult, then I'd love to have the weight of the line in the cursor image a little thicker to help distinguish it from the track lines - as both are yellow.

Thanks

chris

[Lindsayts]

Genma Saotome, on 30 June 2016 - 06:03 PM, said:

Bull. In most places in the world the GH projection skews all right angled street intersections. Here are two examples for the US (and this occurs everywhere in the US) (and is far, far worse in Japan):

In addition to ruining every right angled intersection the distances within the skew are off: Measuring from the bottom corner across to the opposite top corner you get different distances. Not much on these city blocks but for any route whose start to end track journey follows that corner to corner direction it really adds up... 5% to 10% longer or shorter per 100 km (or miles) is not uncommon.

About the only place in the world where this is not a problem is in Congo.

Just a comment, this skewing is actually correct for Goode Homosline projection it NOT being a Conformal projection (Note 1), its main claim to fame appears apparently to be its mathematics are quite simple.

Note 1: a Conformal projection as a projection that preserves local angles, as the world is complex 3 dimensional object this means conformal projections will always be over a relatively small area.

Lindsay

[Genma Saotome]

Lindsayts, on 06 July 2016 - 12:05 AM, said:

Just a comment, this skewing is actually correct for Goode Homosline projection it NOT being a Conformal projection (Note 1), its main claim to fame appears apparently to be its mathematics are quite simple.

Note 1: a Conformal projection as a projection that preserves local angles, as the world is complex 3 dimensional object this means conformal projections will always be over a relatively small area.

Lindsay

That may be all true but the domain we're operating in when building a route is not the entire globe, it's a rather small portion and within that portion the elegance of the G-H projection gets in the way of using any other source material. That's the problem. Until such time that all of our GIS data exists as a 3d model conforming to the planet were stuck w/ using what's commonly available and there isn't any GIS data in G-H projection that's remotely usable for track and road paths.

You know that, I know that, the OR team knows that, as do most route builders.

[Driver]

I think I may have narrowed down why SRT does not generate GE textures in the OR route editor. I looked at the tiles folder for my route. I am developing same route in both editors. The MSTS eeditor creates tiles with an e.raw, n.raw and y.raw for each and every single route tile. While the OR RE only creates the y.raw for each tile, with no creation of the e.raw, and n.raw. I guess that SRT was programmed to read all three raw files for each tile in order for it to create GE images within the route terrain. Not sure if this is something GOKU can address, but just something I noticed while trying to figure out why STR works great with MSTS RE but is inoperable with the OR RE. SRT has created some great looking routes. My route with the wagon wheel gap looks great coming through the canyon. EOLESON has been working between Tucson and phoenix on a route, and his SRT screens look excellent. And then you have Bernina Bahn, which is an amazing looking route thanks to SRT. It would be great if we could get this feature working with the OR RE. Not demanding, just hopeful of the possibility. And thanks to Goku for the excellent effort you have put into this RE. It already surpassed MSTS RE by leaps and bounds.

[Lindsayts]

Genma Saotome, on 06 July 2016 - 08:00 AM, said:

That may be all true but the domain we're operating in when building a route is not the entire globe, it's a rather small portion and within that portion the elegance of the G-H projection gets in the way of using any other source material. That's the problem. Until such time that all of our GIS data exists as a 3d model conforming to the planet were stuck w/ using what's commonly available and there isn't any GIS data in G-H projection that's remotely usable for track and road paths.

You know that, I know that, the OR team knows that, as do most route builders.

I do not understand what you are getting at here, data used as a basis for a world model such as the well known 3DEM SRTM data is not released in ANY projection. deformation of the world model is a natural result if one uses ANY projection. As you say all routes are effectively local, even long routes such as the "Adelaide hills and SE" route. My one tests with Transverse Mercator indicates this is quite suitable for a train sim though, ie a route is VERY unlikely to be long enough for Transverse Mercators inaccuracies to be any kind of an issue no matter where in the world you are.

Lindsay

[Genma Saotome]

Lindsayts, on 24 July 2016 - 03:14 PM, said:

I do not understand what you are getting at here....

Lindsay

Essentially I was appending my comments to your line of thinking and not trying to rebut you. I should not have quoted you. Sorry about that.

What I was attempting to accomplish is to make a point about why the G-H projection is no good for train simming. You do understand why it is no good but not everyone does. For example, Goku asked what's wrong G-H?

Let me also mention that the SRTM data is obsolete here in the US, it's long since been replaced by data w/ better resolution. My first route was started in 2002 and much of it was built using 30m data, not 90m SRTM. In 2003! Why are we even messing with 90m resolution today when 10m -- or smaller -- is available?

[Lindsayts]

Genma Saotome, on 24 July 2016 - 04:28 PM, said:

Essentially I was appending my comments to your line of thinking and not trying to rebut you. I should not have quoted you. Sorry about that.

No problems

Quote

What I was attempting to accomplish is to make a point about why the G-H projection is no good for train simming. You do understand why it is no good but not everyone does. For example, Goku asked what's wrong G-H?

The problem with Goode Homosline projection is that it is not a conformal projection, that is it does not show all areas in there true shapes, in fact only a fraction of the earth is produce at its correct shape. This is not a problem for Transverse Mercator, if it is restricted to around plus or minus 5 degrees from its reference meridian.

Quote

Let me also mention that the SRTM data is obsolete here in the US, it's long since been replaced by data w/ better resolution. My first route was started in 2002 and much of it was built using 30m data, not 90m SRTM. In 2003! Why are we even messing with 90m resolution today when 10m -- or smaller -- is available?

There is still a lot of areas around the world where high res terrain info is still not availible, so theres a few of us that have to struggle on with such low res data as 3 second SRTM. While 1 second data (30 metres) is availible in Australia. its not availible in a form thats is in any easy to use for MSTS, it being supplied in the proprietry ARCinfo format. Also if one requests say a 4 degree square of data, its supplied in one enormouse file. For my own use I break these down into 1 degree squares and save them in Geotiff format. My terrain modelling program using this file format directly.

Post Script. In fact the whole of Australia is availible at 1 sec resolution, unfortunately for me (i am on dialup intenet access) is only readily downloadable in a gi-normouse 25 gigabyte zipped ARCinfo file (one can make special request just for a specifc area). Just unzipping files this size takes ages even on a fast system.

Lindsay