Unable to use altitude for our use case (NYC MTA)

We’re building a new subway/bus app at the MTA. Our system includes roughly 300 underground stations, around 150 elevated stations (i.e., above street level), and about 5 at-grade stations (i.e., at street level). We serve roughly 5 million riders a day.

We’re diving deep into Core Location on iOS and have found that the altitude values returned from two fields we’re testing aren’t accurate enough for our use case:

  1. CLLocation.altitude
  2. CMAbsoluteAltitudeData.altitude

We need to reliably distinguish whether a user is:

  1. At street level
  2. On an elevated platform (see attached picture)
  3. On any platform in an underground station — most have a single platform level, but some, like 59 St (see attached), have multiple platforms at different elevations.

These levels typically differ by at least 15 feet, which should in theory be well within the precision range of a properly calibrated barometric pressure sensor.

However, the absolute altitude values we’re seeing from these APIs are often inaccurate and inconsistent — not only compared to ground truth, but also across devices. For example, holding two phones side-by-side frequently yields altitude readings that differ by more than 15 feet. That level of variation makes the data unreliable for our needs.

Please see the below photos for more context.

That's an intrinsic limite of GPS localisation (not iPhone): vertical precision is less than horizontal.

You have probably noticed in your car. Sometimes, at the same point on a road, it says 295m, another day 305. 30 ft difference.

See details here and may be some hints to a workaround: https://stackoverflow.com/questions/8282169/cllocation-elevation-accuracy

Ot to get info on vertical accuracy: https://developer.apple.com/documentation/corelocation/cllocation/verticalaccuracy

These levels typically differ by at least 15 feet, which should in theory be well within the precision range of a properly calibrated barometric pressure sensor.

Yes, but…

However, the absolute altitude values we’re seeing from these APIs are often inaccurate and inconsistent

… Apple have ”improved“ them for you.

If I were you, I’d look at the raw(?) barometric pressure that should be in CMAltitudeData.pressure. See if this is consistent between devices, and has the resolution that you need to determine station levels.

If it does, you just need to know current local sea level pressure. You can probably assume that is constant across your area of interest. Have your app get that from your servers every hour, or whatever.

(Out of interest, are the barometric pressures in underground stations affected by the piston effect of the moving trains enough to perturb this analysis?)

While @Claude31 and @endecotp gave you some pointers about improving your altitude measurements and pointed out possible inefficiencies in obtaining barometric/elevation data in a subway station, we would like to understand your issues as it relates to specific use cases more, and look at some diagnostic logs to see if we can help resolve the issues better.

We already have some data about the MTA network from your previous inquiries, but more from a horizontal point of view.

On vertical, we could have some input into the issue, but a lot depends on the use cases.

For barometric data to be useful to determine absolute elevation, it would need to be calibrated to the outside data continually. For location based data, there would need to be accurate location, which is difficult indoors.

For example, if the users are walking from outdoor to underground platforms, then CMAltimeter would be more accurate.

If user is riding a train between stations, that's a scenario we would be very interested in understanding.

So, we would like to know as much detail as you can share about the use cases you are trying to cover.

To that end, the best would be to create a Feedback Report for our internal teams to work on, and collect more data and details (which you may not be able to share publicly otherwise)

We would like to start by looking at the two side by side devices showing more than 15 ft. of altitude difference. Alongside of diagnostic logs, we would also want to know the conditions that brought them together at the platform. Did they arrive from the outside together, different carrying methods, their exposure to the piston effect before or during the test, etc.

For diagnostic logs, It would be very helpful if you could please go to https://developer.apple.com/bug-reporting/profiles-and-logs/ and follow the instructions for Location Services for iOS to install a logging profile on your devices. Then reproduce the issue, and follow the instructions at the above link to create a sysdiagnose for both devices. And attach that to the Feedback report as well.

To file a Feedback Report, you can use the Feedback Assistant.

Once you have done so, please share the Feedback ID on this thread so I can make sure the team is aware of it.


Argun Tekant /  DTS Engineer / Core Technologies

Perfect, sounds good and will file a report within a couple weeks. Need to gather some data.

Please @tag me when you do, if it is going to be a couple weeks.

Or open a support request when you're ready at https://developer.apple.com/contact/request/code-level-support/ and reference this forum thread in the "Did someone from Apple ask you to submit ..." section so we don't miss the update.

Unable to use altitude for our use case (NYC MTA)
 
 
Q