[Jovet]

I actually thought that "setting in Africa" is a good idea. MSTS can "know" it's Africa, and under the hood OR can too. But each route can have lat. and lon. offset values which shift the logical position of the world when exposed to the user.

[SetiRich]

I just happened across this discussion, but I understand the 'issue' of the earth not being a perfect sphere...instead a unevenly squashed roundish object. I do not have a good understanding of projection math.My assumption is, even though it is not even, for the most part the unevenness is relatively constant...that is...its more or less fixed, unlike some giant bean bag that changes shape continuously. Is this constancy of distension a factoid? Or am I just living in a flatland world?

My question is around lat long itself. Do the coordinates themselves consider the planet as it is? Or a perfect sphere? In other words, how does my GPS seem to know where I am without any projection issues?

??? Rich ???

[James Ross]

SetiRich, on 21 January 2017 - 12:39 PM, said:

I just happened across this discussion, but I understand the 'issue' of the earth not being a perfect sphere...instead a unevenly squashed roundish object. I do not have a good understanding of projection math.My assumption is, even though it is not even, for the most part the unevenness is relatively constant...that is...its more or less fixed, unlike some giant bean bag that changes shape continuously. Is this constancy of distension a factoid? Or am I just living in a flatland world?

I'm pretty sure the deviations from a perfect sphere are constant, at least relative to the size of the Earth, tectonic planes and their shenanigans notwithstanding. :)

SetiRich, on 21 January 2017 - 12:39 PM, said:

My question is around lat long itself. Do the coordinates themselves consider the planet as it is? Or a perfect sphere? In other words, how does my GPS seem to know where I am without any projection issues?

The short answer is yes, latitude and longitude can and usually do take into account the non-spheroid nature of the Earth. Interesting side fact: a single location on Earth can have different a latitude and longitude depending on which geoid (model of the non-spherical shape) is being used to calculate it. GPS uses the WGS84 geoid, but you can use others, including a sphere if you're feeling naughty.

The reason there are no projection issues with GPS is because latitude and longitude are angular measurements, not 2D grid coordinates. Think about your typical desk globe - to work out your longitude, start with the 0 location (nominally London, UK) under the arm holding the globe in place, and simply see how far you need to rotate the globe for the arm to be on top of the target - the amount of rotation is the longitude. Latitude works similarly, but I don't think any desk globes are mounted that way around. :)

It's when you try and turn the spheroid into a flat 2D version that all the projection issues really attack. Take a segment of an orange, or satsuma, etc., and see how the middle is much fatter than the ends - a given distance in longitude has exactly this problem. A 1° longitude change is a completely different physical distance at the equator than somewhere far north or south.

So if you simply try and turn the latitude and longitude into a 2D grid system, you end up massively distorting the size the further from the equator you get, and because the squares of constant latitude and longitude aren't remotely squares away from the equator (they're mostly rectangular) you also end up distorting angles! This is the equirectangular projection and it is not generally useful.

Using some trig, you can solve the angles problem by vertically stretching the places further from the equator, at the expense of distorting area even more and being unable to include the poles at all. This is the Mercator projection and it is far too common for its own good.

You can do all kinds of other things though, including the entertaining interrupted Goode homolosine projection, which MSTS used and is a combination of two other projections, which has no area distortion but absolutely screws up angles in a variety of locations, including Japan, where two of MSTS's original routes were set!

You can find more entertaining projections in Wikipedia's list of projections, where each is labelled as equal-area (no area distortion, like the interrupted Goode homolosine projection) or conformal (no angle distortion, like the Mercator projection) and others.

That was slightly off-topic but it's fascinating stuff to read about. :)

[cjakeman]

James Ross, on 24 January 2017 - 02:03 PM, said:

I'm pretty sure the deviations from a perfect sphere are constant, at least relative to the size of the Earth, tectonic plates and their shenanigans notwithstanding.

Yes, I heard recently that the location of Australia is being updated soon because it's moved a little bit since last time.

[Lindsayts]

James Ross, on 24 January 2017 - 02:03 PM, said:

I'm pretty sure the deviations from a perfect sphere are constant, at least relative to the size of the Earth, tectonic planes and their shenanigans notwithstanding. :)


The short answer is yes, latitude and longitude can and usually do take into account the non-spheroid nature of the Earth. Interesting side fact: a single location on Earth can have different a latitude and longitude depending on which geoid (model of the non-spherical shape) is being used to calculate it. GPS uses the WGS84 geoid, but you can use others, including a sphere if you're feeling naughty.

While the variations from a sphere of the earth are small they do present a problem, incedently the equator has an uneven radius , the greatest distance from the centre of the earth to anywhere on the earths surface is in northern South America The total variation in the earths radius being in the order of 70 or so Nautical miles.

Route length in a train sim will vary depending on if one uses the correct geoid, From my testing on a route in south eastern Australia the worst case was, the variation in distance between WGS84 and a true sphere was around 1.3%, using WGS84 brought the error back to less than 0.1%. This is actually quite difficult to test as indepentently measuring long distances on the earths surface is quite an undertaking.

Lindsay

[BillC]

James Ross, on 24 January 2017 - 02:03 PM, said:

I'm pretty sure the deviations from a perfect sphere are constant, at least relative to the size of the Earth, tectonic planes and their shenanigans notwithstanding. :)


The short answer is yes, latitude and longitude can and usually do take into account the non-spheroid nature of the Earth. Interesting side fact: a single location on Earth can have different a latitude and longitude depending on which geoid (model of the non-spherical shape) is being used to calculate it. GPS uses the WGS84 geoid, but you can use others, including a sphere if you're feeling naughty.


You can do all kinds of other things though, including the entertaining interrupted Goode homolosine projection, which MSTS used and is a combination of two other projections, which has no area distortion but absolutely screws up angles in a variety of locations, including Japan, where two of MSTS's original routes were set!

For Trainz users there has been a GIS mapping generator (TransDem) out for a number of years. At a modest cost of USD $28.00 the well written instruction manual, is almost a course of railroad GIS it self

Back in the past WaltN wrote to Dr. Ziegler about using his program with OR. His reply was detailed, but in summary supporting the IGH projection was too difficult and to use UTM. In addtition to train generation, it allows for spline generation, and tying into external CAD programs.

If OR was to update to a more sensible projection like UTM, maybe he could be persuaded to support OR.

[SP 0-6-0]

Bill, I have had the exact same thought about Transdem. It's a great program for Trainz users.

Robert

[cjakeman]

BillC, on 26 January 2017 - 05:03 PM, said:

If OR was to update to a more sensible projection like UTM, maybe he could be persuaded to support OR.

The way I see it, Open Rails doesn't make use of a specific projection internally except to orient the sky and compass and to calculate LatLong for the TrackViewer. It just assumes tiles which are 2048m square. The tiles could be generated by any convenient projection. And, yes, UTM would be a more useful projection, especially for importing elevation and path data.

[Goku]

UTM is bad choice. Maybe better than IGH but still bad. Only reasonable choice is Mercator projection used in all online maps and WMS image servers.

[Genma Saotome]

Goku, on 27 January 2017 - 12:31 PM, said:

UTM is bad choice. Maybe better than IGH but still bad. Only reasonable choice is Mercator projection used in all online maps and WMS image servers.

What in your opinion is wrong about UTM?

As for Mercator, I recall my grade school education explanation (from over 50 years ago) of Mercator as perfectly fine for east west and horrendous for north south anywhere other than near the equator. Needless to say that is still true today.

I'm no zealot on any specific method of projection other than not KUJU's choice of Goode-Homosoline on the one hand and on the other hand whatever has the least distortion. One requirement of whatever is picked should be other forms of mapping projections should be able to be converted to the chosen method.

I'll toss out another idea, certainly out of the box thinking: Use a hex grid instead of squares to hold the tile data. Hexes are much closer to the area of a circle which should mean far fewer things rendered just beyond view limits -- be thinking of the number of tiles at a 10km view distances, not the count at just 2km and what that difference means in rendering. You get a smooth run of tiles in 6 directions, which in contrast to squares does minimize the sawtoothed margins of any route that's not perfectly east/west or north/south. That makes it a bit easier for the developer to fill the margins properly. Once done there really isn't anything else that is fundamentally different... tiles are simply containers of data.