How Crossrail was affected by the curvature of the Earth (2018) | Hacker News Reader

How Crossrail was affected by the curvature of the Earth (2018)

ianvisits.co.uk

139 pointszeristor54 comments

The article is kind of a tease, but doesn't really explain very well what's going on in these various coordinate systems that caused the need for the London area specific survey and model, and causes different coordinate systems to put the Greenwich "zero" point all over the map. Hard to tell whether the point of the article is that precise mapping is a hard problem with various solutions optimized for global applicability giving different lattitude/longitude results in specific locales (where it kinda leaves the impression some sort of error is involved, which is not the problem; the Greenwich zero point is not 102m East in GCS84 because of error, but because it approximates the shape of the earth globally differently than standard spherical coordinates), or, as the headline says, that the curvature of the earth figures into projects that cover city-scale distances (which is hardly a surprise to anyone who thinks ten seconds about it; you can see curvature effects on a calm sea at a distance of only a few miles).

> you can see curvature effects on a calm sea at a distance of only a few miles

Open sea is rarely calm. But lakes are sometimes calm. I've sometimes thought it would be fun to set up some kind of permanent markers, something like giant clapper boards along a straight line at the same height above the water, so that people walking around a lake could easily observe the curvature of the Earth. Has this been done anywhere?

Dan Olsen published a video [0], last year, outlining his experiment on Minnewanka Curve and the ideology driving people who deny his, and similar results, demonstrating the curvature of the earth. While there is no artificial structure, he observes that trees on the opposite side of the lake are obscured by the water surface. He also published raw footage of the multiple recordings he took as a separate 28 minute video.

[0] https://www.youtube.com/watch?v=JTfhYyTuT44 90 minutes

Great video by itself

Conveniently done already in Louisiana, where mankind has placed a line of concrete pillars twenty three miles across a lake. :)

https://en.wikipedia.org/wiki/Lake_Pontchartrain_Causeway#/m...

I've driven on that one, and the bridges across the Chesapeake Bay, they're fantastic experiences, personally.

I don't understand how that image (And this simulation[1]) is caused by curvature.

23 miles is ~0.001 of the Earth's circumference. How can that cause a visible difference in tower height? Even more so, the visible difference is in the last few miles, even smaller fraction.

    cos(0.001*2pi) = 0.999980

[1] http://walter.bislins.ch/bloge/index.asp?page=Finding+the+Cu...

>23 miles is ~0.001 of the Earth's circumference. How can that cause a visible difference in tower height?

It seems fairly intuitive that a tiny amount of an insane amount can still be a lot no?

I don't want to get too deep in the math right now since it's morning where i live nor am I good at it.... but if we'd just assume the earth was a nice sphere and a quick google was correct about a 12742 diameter then every degree down from the northpole to the equater would be on average a 70.79km difference in "height". Take a thousand of that and you're still dealing with an easily perceptible >7 meter difference.

Now all of this is shoddy quick thinking since the earth is not a nice sphere, this heigh difference is better not measured perpendicular to the equator but to the ground or center of the earth, etc but you get the idea i hope.

If GCS84 has the zero point 102m east, what are they using as a reference from which to determine that? How do they choose the position of their zero line? I’d have thought the zero line would be the reference from with other points would be determined. Unless they used the international date line as the reference perhaps.

As I recall, the WGS84 meridian is registered to the center of the Earth from space, whereas the classic Greenwich meridian is essentially registered to the local direction of gravity at a point on the surface. If the local direction of gravity passed through the center of the Earth then the meridians would be the same. However, the Earth's gravity is non-uniform which causes the local direction to be slightly deflected away from a path that would pass through the center of the Earth as is the case in Greenwich.

The WGS84 prime meridian is parallel to the Greenwich meridian but slightly shifted so that it actually passes through the center of the Earth. Because WGS84 meridian is not registered to a point on the surface (for good reason), it was always going to drift away from the Greenwich meridian over time regardless.

The actual explanation is very involved, but it boils down to the fact that due to gravitational anomalies in the area around Greenwich, the "straight up" vertical that was used to establish the Greenwich meridian as the origin for universal time does not pass through the center of mass of the earth. The coordinate system used by GPS (WGS84) has the center of mass of the earth as it's origin. The plane that defines the reference meridian (the 0th meridian that is) in that system has to be parallel to the one used to establish universal time, in order to maintain UT consistency. So, when you extend the plane of the WGS84 coordinate system from the center of mass of the earth, parallel to the vertical used at Greenwich, which, again, does not point exactly at the center of the earth, the plane cuts the earth's surface 102 meters East of the original 0th meridian.

This is why I love HN, thanks (and jandrewrogers).

Funny, I was just reminiscing about this very problem this afternoon.

When you are working to specific locations at each end it is a really tricky problem, but local grids like the ones described here help. I've worked on rail projects for mines in remote areas that need a few hundred kms of new track and span across "zones". The problem is exacerbated (at least then, early 00s) by the way you represent these in various CAD products, especially when sharing data between them. There are two main 3D modeling kernels that most popular professional CAD products rely on, both from the 70's 80's with minor updates neither 64bit native. Why is this an issue? Well, you see, the standard for civil design is to model in "real world" coordinates. That means you could be dealing with a file at the resolutions of mm for engineering purposes, but thousands of kms away from the origin. Now we enter the world off floating point calculation errors and subsequent kernel issues.

There are ways around it. Essentially offsets that move the origin of the file temporarily with a note to itself that everything must also account for the offset before displaying in the UI. But it can get confusing, fast, every product does it its own way and may not recognise this trickery. Working digitally with sparse real world reference data of varying qualities can be a big risk. I remember being in a large workshop with two surveying companies, our client and some civil engineers. I was horrified that I knew more about the various grids and their issues than any one else. I did one unit of surveying at uni, not long before and had to do a lot of research to get my head around the issues. These people were meant to be the experts.

The good thing about linear projects is that on those scales you can usually get somewhere where you can "work it out" on site (i.e. fudge it to make it fit). But It potentially affects everything, like, how many meters of track are we ordering? What contingency do we need? What are our expected mass haul volumes and estimated fuel costs? How big should we make our margin of error? It'll all work itself out, it'll just cost.

What happens when we start building beyond the planet and need to accomodate for curvatures in space time? Even ones that are brought about by the very thing you are building?

Back in the mid 2000's I tried to point out to the people writing the UK BIM standards why it was a bad idea to have all buildings drawn relative to the OS grid datum which is somewhere southwest of the Scilly Isles for exactly this reason. I even tried to explain that computers can't do accurate floating point calculations and they didn't believe me! And then CAD consultants are surprised when automatic 2D drawing generation from 3D models randomly fails to work properly (usually at 10pm the night before a big deadline) and then everyone wonders why architects are backwards and don't want to adopt 3D processes...

I used CAD software back in the late 90's called Spirit. The floating point calcs were infuriating. You could draw a bunch of lines with exact length and offset them by exact distances and trim them and they'd all end up x.01mm etc. when you measured or dimmed them.

Hah, people used to say. We've always used drawing boards, that kind of accuarcy isn't important.

But I'd argue that it was. For my own sanity. Sadly, a standard UK brick is 215 x 102.5 x 65mm. Are bricks manufactured to a tolerance of 0.5mm? Can a builder measure to 0.5mm? No.

But when you're digital, and you have a large building, small errors start to accumulate. Next thing is you have the builder on the phone saying the overall length of your building on opposite sides don't match, which one is correct?

This is why I can’t fathom why fractional inches didn’t become the dominant system once engineers switched to CAD. Or not necessarily inches, but at least a fractional representation.

Interesting. For infrastructure projects like roads and railways the standard I'm familiar with is still to just draw them directly based on the national coordinate system, but then again we're also still mostly outputting 2D drawings.

Thankfully it seems that at least with 2D drawings and AutoCAD the worst side effect these days is that under certain circumstances hardware acceleration causes curves/curve segments to be displayed slightly offset. Strangely (but also luckily) enough it never happens when using just AutoCAD, but only when our road/railway design add-in is active (which displays all its output inside the AutoCAD drawing itself) [1], and it doesn't affect points picked via object snapping, i.e. it's really only the display that's affected.

Our friends in structural engineering or architecture on the other hand do indeed use local coordinate systems for their 3D models, though I can't say whether that practice is absolutely universal

[1] Edit: And also in the layout view, but thankfully definitively not in regular model space, where you'd be actually editing things.

--What happens when we start building beyond the planet and need to accommodate for curvatures in space time?

By the looks of things, Star Trek fixes this issue by eliminating money.

In Avatar, there's a whole other interesting world of economic star travel where the mineral unobtanium is valued at 20 million per kg. Interstellar travel with back and forth trips to another world actually works out to be profitable for a company and that's set in 2154. With inflation at current rates 20 million ain't going to be much, so it seems like this problem get's solved. Or the company in that film has worse margins than air travel.

This is one of many reasons why floating-point should never be used for coordinates. It's also a bit frustrating because 64-bit integer support is easier to implement in hardware than double-precision (or even single-precision) floating point, but the latter was widely available long before the former.

There are coordinate systems that can represent any point on earth to the precision of a micron that use 64 bit integers.

One of my favorite curvature-of-the-earth/engineering details is that the tops of the towers of the Verrazon Narrows Bridge are 1 5/8 inches farther apart at their tops than at their bases due to the curvature of the earth.

https://en.wikipedia.org/wiki/Verrazzano-Narrows_Bridge

I was thinking about this too from the perspective of potentially being easier to observe than ships at sea.

On the other hand, the earth's curvature is imperfectly correlated to gravitational vector. Given a stable gravitational anomaly, would two towers such as that bridge be oriented to gravity or curvature? My guess the former, meaning that the change in distance between the base and top of two tall towers wouldn't add to understanding curvature.

a number of years ago when I traveled frequently for work I was very focused on optimizing my airline miles and points.

At some point as part of a computer system cutover, United Airlines suddenly started shorting people miles on airport to airport differences. Not a lot, but a few here and there. A group of folks on flyertalk slowly realized that the change was perfectly explained by the difference between treating the globe as a perfect sphere and treating it as an oblate spheroid.

The previous model had been technically correct and precise. Whoever built the new model had simplified the code for some reason. After much kvetching United fixed it.

I propose that to simplify geographic calculations, we should all pack up and move to venus.

I'd sooner breathe sulpheric acid than...something something oblate spheroids?

Or the Earth could be shrinking.

This is the truth no one wants to admit. In ten years we'll be orbiting the moon!

The first time I drove across the US, I wondered why the two lane roads we were driving on in the midwest (scenic route) did a quick dogleg every so often.

https://kottke.org/18/01/us-road-grid-corrections-because-of...

Ok, the title "US road grid corrections because of the Earth’s curvature" is slightly misleading. The doglegs are not there because of the curvature of the earth, but because of the "Jefferson Grid", which divided a large portion of the US into plots which were each a square mile. But, due to the curvature of the earth, the north-south boundaries between these plots couldn't be exactly straight, and that led to these "misalignments".

> Ok, the title "US road grid corrections because of the Earth’s curvature" is slightly misleading

OK, but "US road grid corrections because of the north-south boundaries between Jefferson Grid plots that aren't straight due to the Earth's curvature" doesn't roll off the tongue quite as well.

I always figured it was to give drivers something to do to keep them awake.

I had heard of that idea in relation to the design of the US interstate highway system. I looked into it[0] and found that it may be a consideration, but not a requirement as I thought I remembered.

https://www.fhwa.dot.gov/interstate/faq.cfm#question31a

Though not the intended purpose, it probably also helps serve as a ground level windbreak.

Also Kansai airport [0] had to cope with this issue, complicated by the fact that it's built on reclaimed land and the whole thing is (or was) on software controlled hydraulic jacks which control differential settlement.

[0] http://www.rpbw.com/project/kansai-international-airport-ter...

[1] http://engineering-timelines.com/scripts/engineeringItem.asp...

Extremely interesting and an amazing feat of engineering.

"The terminal was completed in less than 36 months." Blows me away the most I think.

What the article mentions in passing was called "threading the needle" where an earth pressure balance tunnel-boring machine mined the section of tunnel directly above the operational Northern line platform tunnels at Tottenham Court Road, directly below the London Underground station structures, with less than 800mm clearance to each. Read more at https://www.theengineer.co.uk/content/in-depth/your-question...

Wait what? There are three tunnels under London separated by a two feet of earth?!

I doubt we even need a Bond villain to break through that !

I am not sure I trust engineering that much?

They posted an engineer (and a film crew[1]) to stand on the relevant platform at Tottenham Court Road while the TBM was boring through, to watch for anything going wrong. That's trust :)

1. For this documentary. The title hasn't aged well... : https://www.bbc.co.uk/programmes/b08ry6fy

I wonder if the Bond villain is responsible for the late opening of the eponymous Station?

It's more, is that going to hold for a hundred years? I mean it's just ... clay under London.

Then again what do I know. I look up at Jumbo Jets flying past and think, "no way can that stay up there"

If we turn out to live in the Matrix and heavier than air flight is done with a continuous loop in a Perl script, I will not be surprised.

make the project engineers who signed the plans stand there.

Not quite sure what your problem is, the tunneling was dicey but once it's done, it essentially becomes a concrete pipe.

It’s not as impressive if you know that we can use ultrasound to know how far away we are from the tunnels in the first place

> ...in three different coordinate systems (OSGB36, WGS84 and ED50)

> Crossrail made use of a *customised projection* with a meridian that runs through central London

https://xkcd.com/927/

"... so I decided to use regex. Now I have two problems."

A good chunk of this problem is because they don't just use the global WGS-84 standard, and instead decide to try to use locally-flat custom coordinate systems. It's like trying to design your own car from scratch to travel somewhere rather than just using one from Ford. Lots of extra effort with little gain.

If WGS-84 had been used throughout (and all old measurements converted), everything would have been far simpler and cheaper, both now and for future modifications.

I worked for a small British GIS company in the mid-nineties. Having an entire country on a single rectilinear coordinate system really makes life easier. The OS grid makes sense for mapping a country the shape, size and location of the UK. And on 16-bit windows machines, not having to deal with WGS-84 or UTM, was a reasonable call

But now all the complex math is hidden away behind abstractions, and the extra computation to do everything in WGS-84 space is insignificant. Yet the benefits are huge in that every engineer who works on the design won't need all this extra knowledge of many custom coordinate systems and the way conversions and interactions between them work. Not to mention the huge possible costs when someone messes up and uses the wrong coordinate system for something and a beam ends up only half the thickness it should have been because the top was constrained by something in one coordinate system and the bottom by something in another...

I think a close parallel is the complexity of UTF-8 is now worth it over encoding things using codepages.

> the extra computation to do everything in WGS-84 space is insignificant

There is still significant overhead involved in conversion - arbitrary trig functions, even optimised, are still really expensive compared to planar geometry. Remember these folks will be working at super high resolutions too.

Isn't another issue also that WGS-84 is fixed globally, which'd mean that due to continental drift, local coordinates would be constantly shifting? Whereas the current local grids are usually fixed with regards to the local continental plate, so coordinates remain relatively stable-ish because the whole local grid moves together with the continental plate.

I was thinking about mentioning that... yes! Construction on this project began 13 years ago so it needs to be taken into consideration. A similar project in Australia would've seen a drift of up to several metres in this time [0]. Europe has another angular CRS for this reason [1].

[0]: https://theconversation.com/australia-on-the-move-how-gps-ke...

[1]: https://www.killetsoft.de/t_1009_e.htm

> But now all the complex math is hidden away behind abstractions, and the extra computation to do everything in WGS-84 space is insignificant... UTF-8 is now worth it over encoding things using codepages.

There is a reason for having GIS professionals. WGS-84 is not nearly accurate enough for many purposes. Good enough to find your home, not good enough for precision surveys. In my country to get sub-metre (cm) precision using NZGT2000 is necessary.

WGS-84 also has no deformation component. The tectonic plates moves, in parts of my country movement is 5cm/year,and so a WGS-84 coordinate taken at one point in time won't precisely point to the save bit of dirt at a later time. Other geographic coordinate systems can take this into account.

Nobody would use UTF-8 if every 1000th character was lost.

With a dual band survey grade receiver, WGS84 coordinates can be derived to 2cm accuracy in the vertical [0] and even better in the horizontal.

WGS 84 is a time dependent datum - each addition to the ensemble is known as a realization. The software used to convert across time and reference frames is called HTDP [1]. This can also be done for the vertical using VDatum, which wraps HTDP.

The confusion around this issue usually has to do with how analysts actually handle coordinate information in software. For example ESRI, arguably the dominant GIS, does not have time dependent conversion capability. In the US there is also a false equivalence that NAD83 == WGS84. Looks like NZ has a similar issue [2].

Developers also have to deal with this issue, since web mercator and the tiling scheme were designed for convenience and not sub meter accuracy.

[0] https://www.ngs.noaa.gov/PUBS_LIB/NGS592008069FINAL2.pdf [1] https://www.ngs.noaa.gov/TOOLS/Htdp/Htdp.shtml [2] https://www.linz.govt.nz/data/geodetic-system/datums-project...

> With a dual band survey grade receiver, WGS84 coordinates can be derived to 2cm accuracy in the vertical [0] and even better in the horizontal.

Accuracy or precision? The issue is accuracy, not precision.

> Developers also have to deal with this issue, since web mercator and the tiling scheme were designed for convenience and not sub meter accuracy.

This is a projection problem. All projections are essentially wrong, and tradeoffs need to be made (eg. you can't flatten an orange on a desk without distorting some parts of it) . Unfortunately users don't understand this which is why people get excited when they discover America is smaller, and Africa larger, than they thought. Ideally when zooming into a country a more suitable projection would be used, but at the end of the day it doesn't matter much for consumers.

I think software developers don't give GIS developers enough credit. Software devs will endless debate and be critical of floating point issues, but also not consult with a GIS professional when doing spatial work. People don't know what they don't know.

WGS-84 has angular coordinates, you can't measure distances like they need for construction without projecting to Cartesian coords, hence the local CRS they developed.

For a U.S. analog, we use the State Plane system. The states have (multiple) custom projections to suit local accuracy needs. Like another commenter said, WGS 84 uses ellipsoidal coordinates that are not suitable for the Crossrail's construction. If it were really so easy, American states would "just use WGS 84" as well.

Reply on news.ycombinator.com