Transit app developers see iOS 6 Maps as a chance to shine

As iOS 6 users, developers are frustrated. But as app makers, they're excited.

Buster 3 on the left, Embark NYC on the right. Both plug into iOS 6's new Maps app to offer transit directions.

The public reaction to Apple's new iOS 6 Maps application has been visceral thus far. There have been numerous complaints about Maps taking people to the wrong locations, directing them to businesses that have long been closed, and visually displaying less local and contextual data than Google Maps. Indeed, these are all turning out to be common frustrations among iOS 6 upgraders—I mentioned many of them in our review of iOS 6—prompting Apple to swear the app will be improved over time.

But one major omission from the Maps app that isn't likely to make a reappearance (at least from Apple) is transit directions. Apple stated that it ignored this feature in Maps in an attempt to open things up for third-party developers. The company line is that the best transit apps are ones that are tailored to each city. This may be true to some degree, but as I wrote in my iOS 6 review, I think this is a wildly user unfriendly move regardless of the motivation.

Apple appears to be sticking to its guns and is unlikely to reverse course anytime soon on the decision to put the transit responsibility on developers. Developers, on the other hand, appear to be cautiously optimistic about the move. Indeed, they appear excited about the possibilities, with many asserting a belief that the user experience will end up being better overall—once the early kinks are worked out.

How do transit apps plug into Maps anyway?

When a user enters a start and end point into the default Maps app and selects the transit button (instead of say, driving or walking), Maps automatically searches for any transit apps that might already be installed on the device. If there aren't any, it searches the App Store for apps based on geolocation—if you're in Chicago, it will bring up transit apps that are made for Chicago. If you're in London, it'll bring up ones for London, and so on. Users can still search for transit apps for all cities manually, but Maps aims to bring up only results for the city you're in—presumably to help weed out the cruft when all you want to do is get to your hotel.

Existing transit apps can't automatically plug into Maps, though. Developers have to tell Apple that they're making a transit app and provide a boundary for the area they're serving in order for it to function with Maps. When they do this, it allows their apps to function both as a standalone app and as a plugin to Maps.

Developers appear excited about this even if it involves significantly more work. Cieslak and his partner Jacob Van Order (who has his own app called QuickTrain) told me they teamed up in part because they needed to come up with their own way to actually route the user between point A and point B. When Maps calls their new app (Buster 3, to be released next week) with a beginning and end point, Buster will hand the data to a server using Open Trip Planner. OTP returns a "huge JSON file," which Buster 3 then uses in combination with Apple's MapKit to plot out the lines and provide an itinerary.

All this allows developers to offer a wider variety of transit options than what was available previously under Google's Maps app (which was largely limited to trains and busses in most cities). And because of the added transportation options, developers have the ability to provide users with even more customized routing options. TripGo developer Adrian Schoenig told Ars that his company's app can offer combinations of options—such as taking your car to the train station, taking the train into the city, and taking a cab to your final destination.

Such flexibility does sound appealing from a user's point of view. Cieslak and his partner Van Order added that Buster 3 will be able to "favorite" entire routes instead of individual stops thanks to the changes they're making. So if you're always taking a series of trains and buses to get to work, you can keep that route bookmarked for future use. And their app will also send push notifications to get off or transfer at certain locations, too, so you don't forget in case you're reading a book or engaging in a heated Twitter argument.

Opportunity is knocking

Indeed, the most common message I received from developers about this change was that they were hesitant to add significant new features before due to the limited audience. But now that Apple has unceremoniously shoved responsibility for transit into their hands, they've been motivated to step up and create some truly useful apps that they might not have done before.

"Developers have a lot of new opportunities because now transit apps are in high demand," developer Tim Desir told Ars. "Also, Apple is giving out free advertisement by including developers apps in a system app that everyone will see."

Schoenig agreed. "It's better for us developers and better for Apple. Users will feel short-term pain due to the lacking quality of Apple's maps and possibly lack of high-quality transit apps for where they are. In the medium- and long-term it will be an overall gain. It's better for innovation," Schoenig said.

"Now we have a chance to do something better than the Maps in iOS 5 and actually have an audience for it," Van Order said.

And it's important to remember that while Google's version of Maps worked reasonably well when it came to transit, it was still limited in many ways. Arrival and departure times were often wildly inaccurate. And Google was unable to take into account service changes, train or bus line shutdowns, and other details that would affect a user's route. To be sure, any regular transit user had their frustrations with the iOS 5 version of Maps as well, which is why some developers believe this change has the potential for good.

Embark developer David Hodge was quick to point this out. "Google, in its efforts to cover every single city, provides mediocre results in key big cities like NYC and SF. These big cities require a level of attention to detail that is difficult to achieve at scale. Apple instead chose to empower its app developers to make public transit apps," Hodge told Ars. "This is why we go in to cities like New York and figure out details like walking speeds and transfer times because that makes all the difference in providing accurate transit results.

"We think this is a great move for the space. Just like the early days of the App Store, Apple has opened up a large opportunity for developers to further innovate and improve public transit apps. Going into the iOS 6 launch, we were planning about 4 million mass transit trips per month for our users. Based on what we've seen with iOS 6 in the last 24 hours, that rate should be increasing by an order of magnitude shortly. So we've benefited thus far."

Still a user-unfriendly move

The developers are generally optimistic about their prospects, but they're still just "regular" users in their everyday lives. And from that perspective, they're more than willing to acknowledge that the situation is less-than-ideal—at least for now.

"I was really disappointed that transit was removed at first. I wasn't buying the 'developers make the best transit apps,'" Desir told Ars. "I really think that it's good for developers who want to make something better, but bad for the 'average user' and people who heavily rely on public transportation and don't know much about other apps on the App Store. It was a risky decision to do this."

Indeed, despite their optimism, almost all the developers I spoke to acknowledged that things won't be easy for users. "I personally used the transit directions in the Maps app almost every day, and haven't found a full-featured replacement that I like yet, so I find it pretty frustrating," developer Peter Stuart told Ars. "Right now things are definitely worse, but I think that eventually third-party apps will offer the same features and potentially be even better."

Some echoed my comments from the iOS 6 review, pointing out that users will have to learn something new in order to achieve the same level of functionality. That, combined with the inconsistent transit experience between cities, will undoubtedly provide challenges to the iOS 6 userbase.

"The only difficult part is the learning curve users will have to go through," Desir added. "All the transit apps will do the same thing, but will present it differently. It just sucks that some people will have to re-learn how to do what they've been doing for the past couple years."

Not all developers were as optimistic about the long-term possibilities for their apps, though. "The 3D maps are amazing, but they are meaningless if the core features of getting you from point A to point B aren't working," developer Greg Raiz told Ars. "I believe there may be a short-term opportunity for regional app developers, but long-term I see this being an area that's incorporated into the OS. I suspect the sheer number of issues prevented Apple from tackling transit directions; I expect this will be back. "

Promoted Comments

I think an article on how you can take map data from various sources (Tom Tom and others) and end up with this level of problems would be good. I admit that I don't have a good idea of how all that backend programming works, so I would be interested to learn more.

I can explain a little bit, I hope. I have done some navigation and GIS related programming before, although I think the problem is more to do with geodetics and conflicting data than any programming issue.

There are a number of potential sources of error, especially when you start involving multiple data sets. The first issue is presentation: The Earth is 3D, and we need to represent it in 2D. Worse, the Earth is a sphere. Imagine if you will trying to get a piece of paper wrapped smoothly around a ball, perfectly adhering to the surface of the ball. The paper always has gaps and bits of it don't quite touch the ball. If you imagine the paper to be film, and shine a light from the inside of the ball, it will project an image of the surface onto the paper. If the paper was perfect, it'd be a perfect representation, but it's not because we can't wrap it so it touches the surface in all places equally. This means the resultant image has some distortions, and it's not a 100% accurate representation. The process of taking a curved surface and making it flat will introduce distortions. In this case, the paper is your map and the ball is the Earth. These are called projections. Distortions can be one source of error.

But there's another problem. When we refer to points on the surface of the Earth, we use latitude and longitude. Latitude is nice; One degree of latitude is always the same distance. With longitude, it gets sticky. The distance between a degree of longitude at the equator isn't the same as the distance between a degree of longitude at the arctic circle. As we go towards the poles the lines of longitude converge, changing the distance on a scale depending on how far north/south you are. This isn't very desirable, because it makes measuring distances a real pain. We'd like to define a neat 2D grid in feet/meters, so we can figure out distances with simple subtraction and some Pythagoras rather than a mess of trig and calculus.

Before we can get down to a nice neat 2D Cartesian grid, we have an intermediate step. We want to get away from lat/long, because x/y is much easier to work with. So we go down to what's called a datum. Globally we use one called WGS84, but before the advent of satellites, everyone used their own regional datum. In the US this was called NAD27 (for 1927, when it was made), Europe had ED50, I believe Britain had their own, etc. In addition, each one used a certain reference ellipsoid, a mathematical modeling approximating the shape of the Earth (WGS84 refers to both the ellipsoid and datum). I'm sure you can already see this becoming a whole can of worms. What these served to do was specify a horizontal grid for a certain region, with the origin at a fixed point. NAD27 used Meades Ranch, WGS84 uses the center of the Earth. The problem with this is, counties in, say, California don't really want to map everything in their state in relation to some guys ranch in Kansas. Enter the State Planes system.

In the United States we use what's called the State Plane Coordinate System (SPCS). It's a set of small projections for every state broken up into zones. It's highly accurate within the zone, but the accuracy degrades rapidly outside of it. It's used extensively, and many states have scads of maps in their state plane coordinate system. They use it for road maps and other surveys. The problem with this is that when you cross the boundary between two planes, the coordinates all change to something completely different. A road located at x=1000 on one system may be x=1000000 when it travels to another zone.

You can see when mapping off of data provided by this, you need to accomodate for these shifts, by translating to the datum and then translating back to the new one. To make matters worse, some maps may be old or not using the standard WGS84 datum, so you then have to convert to the older datum, which doesn't line up correctly in the first place, and then convert back to the SPCS. There are even different formulas used to convert between datums, which can produce different results! Usually if there's an error, it's not a big one. Anecdotally, when offshore we used a different formula to position a boat precisely than the one the surveyors had used in planning our position. We were off by about 18 feet, not big, but maybe enough to put you next door.

Back to projections, the problem is your coordinates are a nice square grid, but your flat pictures grid is actually skewed, because it's a projection off a sphere. We need to distort the picture so that the pictures grid matches the nice square coordinates we have. When you're trying to align a picture of the earth's surface to a map of the earth's surface, you have to pin various known points of that picture to the positions on the map. eg If you know on the picture that this is the junction between I-10 and I-610, you say "Ok map, give me your coordinates for this junction, and this particular pixel of the image is anchored here." You go around and do that a few dozen/hundred times, and then the computer works out the rest. The problem is, you can't go around and pin down each and every single point to it's exact coordinate, because that's way too labor intensive. It would take years, and by the time you finished, the world probably would've trashed the coordinate system you used and moved on! So we do a handful of reference points and let the software do the rest for us. This can lead to slight inaccuracies, like the "house located in the river" incident. The map coordinates may be correct, but the image alignment is off slightly.

That was a bit long-winded, and I'm certain I got some things wrong (chime in if you spot something!), but you can see that it's definitely not a straightforward problem. There are a lot of steps along the way where it can go wrong.

I don't care about transit directions, but the new Maps has beta written all over it. It's not as bad as the press is making it out to be (at least in my experience, especially the people harping on the 3D cause Google Earth has flukes in it too).

I like the new look, but searching for things is very different. It'll get better over time though. I think it was a good attempt overall

*edit* especially compared to what Google offered to iOS before. It was only better at finding businesses and the like. What the new maps does pull up though is faaar more informative

Oh my god, Apple wasn't able to perfectly map the world in its first outing. I realize there are mistakes, but at a certain level you have to realize the cons are more stacked against Apple because that's more interesting news.

I use Maps. I've played with it a lot. Of course there are some mistakes like that. At the same time, they will probably be fixed within a few days. They need help from people to point out what's wrong

I'm using an app called Transit which Maps recommended (I'm in Vancouver B.C.). While there is a change I'd like to see (I already sent it to them... to have a list of 'steps' in the trip rather than arrows for next/previous 'step'), I'm already liking this solution FAR BETTER than using Safari and Google's Maps on iOS 5.

I wish people would stop saying Google Maps... iOS never really had Google Maps... They had Apple Maps with Google data... Google Maps is on the web and on android (maybe soon iOS)... But it was never Google's Baby. The reason iOS did not have turn by turn is because Google's APIs do not allow this.. And I bet Apple would not allow Google to create a 1st party App (one pre-loaded on the system) that also does all the fancy Google data gathering and reporting, etc...

Bottom line iOS 5 is not Google Maps... Its Apple Maps with a Google Back-end.. iOS 6 is well.... Apple Maps with what looks like data from a couple of places, including yelp, OSM, etc...

1. Sure it might have been Google, but considering they're an information services company I really doubt it was Google that wanted less people using their services. It certainly seems more likely that the company that wants to go thermonuclear on Android would dump Android's progenitor, but point taken, it is simply deduced reasonably at this point that it was Apple that wanted rid of Google, and not empirical fact.

Actually, empirical fact is that Google's terms of service for the Maps API precluded Apple's iOS 5 maps app (written by Apple, using Google data and back-end services) from adding desperately needed competitive features like turn-by-turn navigation. (§10.2 (c)) Given that constraint - and it's not specific to Apple; it's a general term of using Google Maps API - it was inevitable that Apple would source its mapping data elsewhere. The genesis of the iOS 6 Maps.app is probably not acrimonious at all.

TheWerewolf wrote:

In the end, no matter how you paint up this pig - it's still a pig. Apple's decision to turf Google Maps isn't based on making things better for the customer...

Actually, as sourced above, it is. You can set your "rivals at war" conspiracy theories aside, for once.

Honestly not noticed anything wrong with the maps app that better data won't fix. The app itself is very nice.

And PLEASE, Google maps on both Android and iOS has walked me to closed businesses before.

Any mapping software can do this... The main issue is even where I live (saint louis, MO) there are actual road and street issue... I mean we are talking some seriously OLD map data...

The power Google has is they are a data warehouse, so they collect the data, and clean it up and then place it on a map. Apple appears to be taking Yelp data and smacking it on a map without doing any sanity checks at all... Tons of locations except starbucks are in the wrong spots, a block off.. or just not even close.... But for some reason ALL the Starbucks locations are spot on...

1. Sure it might have been Google, but considering they're an information services company I really doubt it was Google that wanted less people using their services. It certainly seems more likely that the company that wants to go thermonuclear on Android would dump Android's progenitor, but point taken, it is simply deduced reasonably at this point that it was Apple that wanted rid of Google, and not empirical fact.

Actually, empirical fact is that Google's terms of service for the Maps API precluded Apple's iOS 5 maps app (written by Apple, using Google data and back-end services) from adding desperately needed competitive features like turn-by-turn navigation. (§10.2 (c)) Given that constraint - and it's not specific to Apple; it's a general term of using Google Maps API - it was inevitable that Apple would source its mapping data elsewhere. The genesis of the iOS 6 Maps.app is probably not acrimonious at all.

TheWerewolf wrote:

In the end, no matter how you paint up this pig - it's still a pig. Apple's decision to turf Google Maps isn't based on making things better for the customer...

Actually, as sourced above, it is. You can set your "rivals at war" conspiracy theories aside, for once.

Okay, so you're saying that you think I'm right, and Apple did dump Google?

I use Maps. I've played with it a lot. Of course there are some mistakes like that. At the same time, they will probably be fixed within a few days. They need help from people to point out what's wrong

Yes, they're called software testers, and they need to hire them. Its gotten annoying that in the age of 'always on' Internet connections companies feel they can push out unfinished products banking on the fact that they'll be able to push an update 'in a few days'. This isn't a complaint specific to Apple for the record...companies need to stop chasing deadlines and delay products if necessary.

Honestly not noticed anything wrong with the maps app that better data won't fix. The app itself is very nice.

And PLEASE, Google maps on both Android and iOS has walked me to closed businesses before.

Any mapping software can do this... The main issue is even where I live (saint louis, MO) there are actual road and street issue... I mean we are talking some seriously OLD map data...

The power Google has is they are a data warehouse, so they collect the data, and clean it up and then place it on a map. Apple appears to be taking Yelp data and smacking it on a map without doing any sanity checks at all... Tons of locations except starbucks are in the wrong spots, a block off.. or just not even close.... But for some reason ALL the Starbucks locations are spot on...

Oh don't misunderstand me, I agree. While I think the app is nice and the data bad, the data is REALLY bad and ultimately only Apple is to blame for that.

I think an article on how you can take map data from various sources (Tom Tom and others) and end up with this level of problems would be good. I admit that I don't have a good idea of how all that backend programming works, so I would be interested to learn more.

I can explain a little bit, I hope. I have done some navigation and GIS related programming before, although I think the problem is more to do with geodetics and conflicting data than any programming issue.

There are a number of potential sources of error, especially when you start involving multiple data sets. The first issue is presentation: The Earth is 3D, and we need to represent it in 2D. Worse, the Earth is a sphere. Imagine if you will trying to get a piece of paper wrapped smoothly around a ball, perfectly adhering to the surface of the ball. The paper always has gaps and bits of it don't quite touch the ball. If you imagine the paper to be film, and shine a light from the inside of the ball, it will project an image of the surface onto the paper. If the paper was perfect, it'd be a perfect representation, but it's not because we can't wrap it so it touches the surface in all places equally. This means the resultant image has some distortions, and it's not a 100% accurate representation. The process of taking a curved surface and making it flat will introduce distortions. In this case, the paper is your map and the ball is the Earth. These are called projections. Distortions can be one source of error.

But there's another problem. When we refer to points on the surface of the Earth, we use latitude and longitude. Latitude is nice; One degree of latitude is always the same distance. With longitude, it gets sticky. The distance between a degree of longitude at the equator isn't the same as the distance between a degree of longitude at the arctic circle. As we go towards the poles the lines of longitude converge, changing the distance on a scale depending on how far north/south you are. This isn't very desirable, because it makes measuring distances a real pain. We'd like to define a neat 2D grid in feet/meters, so we can figure out distances with simple subtraction and some Pythagoras rather than a mess of trig and calculus.

Before we can get down to a nice neat 2D Cartesian grid, we have an intermediate step. We want to get away from lat/long, because x/y is much easier to work with. So we go down to what's called a datum. Globally we use one called WGS84, but before the advent of satellites, everyone used their own regional datum. In the US this was called NAD27 (for 1927, when it was made), Europe had ED50, I believe Britain had their own, etc. In addition, each one used a certain reference ellipsoid, a mathematical modeling approximating the shape of the Earth (WGS84 refers to both the ellipsoid and datum). I'm sure you can already see this becoming a whole can of worms. What these served to do was specify a horizontal grid for a certain region, with the origin at a fixed point. NAD27 used Meades Ranch, WGS84 uses the center of the Earth. The problem with this is, counties in, say, California don't really want to map everything in their state in relation to some guys ranch in Kansas. Enter the State Planes system.

In the United States we use what's called the State Plane Coordinate System (SPCS). It's a set of small projections for every state broken up into zones. It's highly accurate within the zone, but the accuracy degrades rapidly outside of it. It's used extensively, and many states have scads of maps in their state plane coordinate system. They use it for road maps and other surveys. The problem with this is that when you cross the boundary between two planes, the coordinates all change to something completely different. A road located at x=1000 on one system may be x=1000000 when it travels to another zone.

You can see when mapping off of data provided by this, you need to accomodate for these shifts, by translating to the datum and then translating back to the new one. To make matters worse, some maps may be old or not using the standard WGS84 datum, so you then have to convert to the older datum, which doesn't line up correctly in the first place, and then convert back to the SPCS. There are even different formulas used to convert between datums, which can produce different results! Usually if there's an error, it's not a big one. Anecdotally, when offshore we used a different formula to position a boat precisely than the one the surveyors had used in planning our position. We were off by about 18 feet, not big, but maybe enough to put you next door.

Back to projections, the problem is your coordinates are a nice square grid, but your flat pictures grid is actually skewed, because it's a projection off a sphere. We need to distort the picture so that the pictures grid matches the nice square coordinates we have. When you're trying to align a picture of the earth's surface to a map of the earth's surface, you have to pin various known points of that picture to the positions on the map. eg If you know on the picture that this is the junction between I-10 and I-610, you say "Ok map, give me your coordinates for this junction, and this particular pixel of the image is anchored here." You go around and do that a few dozen/hundred times, and then the computer works out the rest. The problem is, you can't go around and pin down each and every single point to it's exact coordinate, because that's way too labor intensive. It would take years, and by the time you finished, the world probably would've trashed the coordinate system you used and moved on! So we do a handful of reference points and let the software do the rest for us. This can lead to slight inaccuracies, like the "house located in the river" incident. The map coordinates may be correct, but the image alignment is off slightly.

That was a bit long-winded, and I'm certain I got some things wrong (chime in if you spot something!), but you can see that it's definitely not a straightforward problem. There are a lot of steps along the way where it can go wrong.

Okay, so you're saying that you think I'm right, and Apple did dump Google?

I'm saying that "dumped" is a dumb pejorative, employed solely to incite. Apple's Maps API license expired, and it elected not to renew because of the constraints using it placed on competitive features it could add to its product.

I think an article on how you can take map data from various sources (Tom Tom and others) and end up with this level of problems would be good. I admit that I don't have a good idea of how all that backend programming works, so I would be interested to learn more.

I can explain a little bit, I hope. I have done some navigation and GIS related programming before, although I think the problem is more to do with geodetics and conflicting data than any programming issue.

There are a number of potential sources of error, especially when you start involving multiple data sets. The first issue is presentation: The Earth is 3D, and we need to represent it in 2D. Worse, the Earth is a sphere. Imagine if you will trying to get a piece of paper wrapped smoothly around a ball, perfectly adhering to the surface of the ball. The paper always has gaps and bits of it don't quite touch the ball. If you imagine the paper to be film, and shine a light from the inside of the ball, it will project an image of the surface onto the paper. If the paper was perfect, it'd be a perfect representation, but it's not because we can't wrap it so it touches the surface in all places equally. This means the resultant image has some distortions, and it's not a 100% accurate representation. The process of taking a curved surface and making it flat will introduce distortions. In this case, the paper is your map and the ball is the Earth. These are called projections. Distortions can be one source of error.

But there's another problem. When we refer to points on the surface of the Earth, we use latitude and longitude. Latitude is nice; One degree of latitude is always the same distance. With longitude, it gets sticky. The distance between a degree of longitude at the equator isn't the same as the distance between a degree of longitude at the arctic circle. As we go towards the poles the lines of longitude converge, changing the distance on a scale depending on how far north/south you are. This isn't very desirable, because it makes measuring distances a real pain. We'd like to define a neat 2D grid in feet/meters, so we can figure out distances with simple subtraction and some Pythagoras rather than a mess of trig and calculus.

Before we can get down to a nice neat 2D Cartesian grid, we have an intermediate step. We want to get away from lat/long, because x/y is much easier to work with. So we go down to what's called a datum. Globally we use one called WGS84, but before the advent of satellites, everyone used their own regional datum. In the US this was called NAD27 (for 1927, when it was made), Europe had ED50, I believe Britain had their own, etc. In addition, each one used a certain reference ellipsoid, a mathematical modeling approximating the shape of the Earth (WGS84 refers to both the ellipsoid and datum). I'm sure you can already see this becoming a whole can of worms. What these served to do was specify a horizontal grid for a certain region, with the origin at a fixed point. NAD27 used Meades Ranch, WGS84 uses the center of the Earth. The problem with this is, counties in, say, California don't really want to map everything in their state in relation to some guys ranch in Kansas. Enter the State Planes system.

In the United States we use what's called the State Plane Coordinate System (SPCS). It's a set of small projections for every state broken up into zones. It's highly accurate within the zone, but the accuracy degrades rapidly outside of it. It's used extensively, and many states have scads of maps in their state plane coordinate system. They use it for road maps and other surveys. The problem with this is that when you cross the boundary between two planes, the coordinates all change to something completely different. A road located at x=1000 on one system may be x=1000000 when it travels to another zone.

You can see when mapping off of data provided by this, you need to accomodate for these shifts, by translating to the datum and then translating back to the new one. To make matters worse, some maps may be old or not using the standard WGS84 datum, so you then have to convert to the older datum, which doesn't line up correctly in the first place, and then convert back to the SPCS. There are even different formulas used to convert between datums, which can produce different results! Usually if there's an error, it's not a big one. Anecdotally, when offshore we used a different formula to position a boat precisely than the one the surveyors had used in planning our position. We were off by about 18 feet, not big, but maybe enough to put you next door.

Back to projections, the problem is your coordinates are a nice square grid, but your flat pictures grid is actually skewed, because it's a projection off a sphere. We need to distort the picture so that the pictures grid matches the nice square coordinates we have. When you're trying to align a picture of the earth's surface to a map of the earth's surface, you have to pin various known points of that picture to the positions on the map. eg If you know on the picture that this is the junction between I-10 and I-610, you say "Ok map, give me your coordinates for this junction, and this particular pixel of the image is anchored here." You go around and do that a few dozen/hundred times, and then the computer works out the rest. The problem is, you can't go around and pin down each and every single point to it's exact coordinate, because that's way too labor intensive. It would take years, and by the time you finished, the world probably would've trashed the coordinate system you used and moved on! So we do a handful of reference points and let the software do the rest for us. This can lead to slight inaccuracies, like the "house located in the river" incident. The map coordinates may be correct, but the image alignment is off slightly.

That was a bit long-winded, and I'm certain I got some things wrong (chime in if you spot something!), but you can see that it's definitely not a straightforward problem. There are a lot of steps along the way where it can go wrong.

This is on the lines I was talking about it seems Apple has taken different data sources without much thought into getting them correctly placed on the map. Google has thousands of engineers working on maps making this happen... Using many points of data to verify a place really is where it says it is and more importantly is represented properly on a flat map.. and a round one at that (3d maps). And corrections happen REALLY fast, most modifications I have made in Google Maps are realized within a couple of hours - there are some really cool videos about how they do this... People think the street view is just for fun, but it plays a MAJOR role in this. Because the street view data is not just for taking pictures and driving on roads, but it also is looking at street signs, storefronts, addresses, etc... And it is then used by the engineers to validate map corrections. Now this data is not super current, but it is constantly being updated - I see Google Cars in my city at least 2-3 times a month driving around - and no those pictures are not being uploaded immediately to Maps, but I guarantee they are being used to source additional data...

I think this really misses the mark in a few ways. The beauty of Google Transit directions, especially in the UK is that it compared and combined multiple transit modes and operators for you.

For example, it'd let you know that getting the train (which is run by a different operator in the UK) was a lot quicker than the bus, even if it did mean a few minutes walk on either side. It could even do train+bus combinations, even though the two companies running these services are completely different.

You could even do really clever stuff like a street address from, say, Birmingham to one in London. It'd tell you which local buses to get to the train station, then which tube to get in London, followed by the best bus.

In iOS6 maps, you'd have to consult a lot of different apps for this. There are a few which do pool data like Google does, but they are nowhere near as comprehensive or accurate.

The reason for this is probably that Google is an information services broker, it's in their interest to get you the best and most complete results for anything you ask, period.

Apple, on the other hand, is an old guard hardware vendor whose specialty is UI and marketing.

The lowered usefulness of Apple's map software caused by dumping Google will probably never be recovered from as Google will probably always be ahead of them in this game, but it also probably won't really change the perception or sales for Apple, as the people that buy their products generally already seem to be ignoring significant feature deficits in the iOS ecosystem, one more is barely a blip on the radar.

I think you've nailed it. While this may be bad short term, and they may never catch Google, iOS users will remain iOS users because they need the hipster credentials even if it means using an 'obscure' route to get to their destination

Perhaps it is a US thing but I have never been able to use Google maps for bus or bike routes in London and have always relied on 3rd party apps (or websites when at my desktop). It's just a fact of life that Google's offerings have always been sub-par for the UK, have always included incorrect information and put locations in the wrong place (e.g. my gf's workplace is still shown by Google to be in a completely different part of town to where it actually is located and has been for years now) and have always been poor for finding good places to eat and drink etc.

The new Maps on iOS6 just happen to be even worse in this first release, which is a tragedy. But the actual app itself and the way it presents the information is far superior to what we had before. Assuming the crowd sourcing works, and assuming that Apple and OSM are able to handle the data provided in a timely fashion it could end up being a huge boon for everyone (particularly those websites that are being stuffed by Google's exorbitant new fees).

Personally I think Apple could have taken a different approach that may have mitigated the hoopla: as well as pre-announcing the switch away from Google at the initial iOS6 preview, they should have also released an easy-to-use app for iOS5 that let people submit corrections to the OSM data. Given the fanaticism of many Apple users, many of the most blatant faults in the new mapping data would have been identified - and could have been fixed - before final release.

I think the negativity to Apple Maps is hugely over-blown. Google has sent me to closed restaurants hundreds of times over the years, but I never felt the urge to cry "Infamy!" all over the internet. Its a monstrously huge data set, people....

As for transit, I am very optimistic about the future for 3rd Party Development. Its strange that Apple is being decried for deferring to 3rd party innovation instead of offering their own rigid system for transit solutions in maps. Isn't Apple supposed to be the Evil Empire of Walled Gardens?

to the point at hand.

In Portland, OR we have a fantastic transit system and there has been a really terrific 3rd party app (PDX Bus) that offers amazing features. After reading this article, I logged on to App Store because I was curious if they had any info about when they were planning on integrating with Apple Maps. Lo and behold, it already does. I downloaded the update and its really terrific.

I realize not everyone has a great solution today, but as the article states and my experience demonstrates, good things are coming and there is very good reason to embrace the idea that 3rd party developers are going to do great things with Apple Maps.

The Google Maps app in iOS5 is really fantastic in Portland. I use it constantly and I've never had a problem with it. PDX Bus, from what I can tell, is pretty horrible. I just put in a destination that I go to all the time and takes 20 minutes with one bus route on google maps, and pdxbus was only giving me options with multiple transfers, at least 70 minutes for every options. Horrible.

I'm sure the options will get better, but I am certainly not upgrading my iPhone 3GS until a decent option comes along

PDX Bus uses Trimet's own API services so not sure how that might be. Do the same comparison on Trimet.org and see what happens. Curious if there is a new bug or something.

In my experience, Google transit info in Portland was based on hypothetical times, not on actual Trimet data which actively tracks bus locations, updates for closures and delays, etc.

I've used PDX Bus for 4 years and found its timetables to be exactly accurate so I'm curious to test it now and see if something has changed.

This is the singular upshot of living in a city of 6+ million whose mass transit policy is "five or six buses and one train." The loss of mass transit directions only matters if there was mass transit to begin with.

This is the singular upshot of living in a city of 6+ million whose mass transit policy is "five or six buses and one train." The loss of mass transit directions only matters if there was mass transit to begin with.

Let me guess: Houston?

Spot on. Though I'm not too familiar with it, Dallas probably would've also been acceptable.

The Google Maps application on Android is superior in every way maps on iOS 5. If you haven't use it than don't compare Apple's new maps to it. From what I'm reading Google has nothing to worry about

Most of these users have never seen an actual android phone...

Most of us have never used one that was an enjoyable experience, that's for sure. I keep trying them, I keep hating the lagginess of the UI when using them. We had a Samsung Galaxy Tab 10.1 and that was shockingly poor.

Allegedly this is fixed with Jelly Bean but I've never seen it in the wild (lack of updates being another thing I loathe about Android phones) and I am skeptical about those claims because it would need to be a massive improvement - and the same claims have been made with each release with no actual improvement noticeable when used.

Fwiw, I wasn't comparing to Android maps, I was writing of Google maps in general and its *data*, including on the web. It is the data that, at best, is mediocre here in the UK and it frequently gets things wrong. The notion that Google maps is the pinnacle of achievement is false - Google have a lot of work to do on their mapping too, just much, much less than Apple now do.

The huge improvement in the software I wrote of was between Maps in iOS5 and iOS6. Functionally it is far superior in 6 than 5 but now the data needs to catch up.

The iOS5 Maps app was awesome for transit info in Seattle/King County. I haven't found a replacement app and so am holding off on the upgrade to iOS6.

Being able to tell it to give me bus directions from one of my contacts (with a nebulous reference) in Redmond to an equally vaguely named location in Seattle, was awesome.

OneBusAway doesn't do anything even close to that, requiring that I already know all the routes I'd ever want to take.

Neither HotSpot nor Lumatic's City Map (the only other ones I've tried yet (they're free)) offer decent service because they depend on Yelp and FourSquare to populate their location lists which is great if I want to go to a business with an internet presence. It's worthless if I want to get directions to the VA hospital (which can't be found even when typing in the full, correct name).

I guess I have to hope things get better and just not get sick between now and then.

After getting burned over updating to iOS 4 on my iPhone 3G I vowed NEVER to update without reading reviews for at least a week after a new update hits. In this case I'm so VERY glad I decided to stick with this policy on my new 4S.

I depend upon the Google Maps feature in iOS 5 to get in and around the Southern portion of the Bay Area. The two other map apps, SJ Transit and SiliconValleyBus, are severely flawed and not very dependable compared to the built-in Google Maps app. Until the public transit issue is resolved, either by a better mapping program or Google releasing an updated Google Maps app, I'll be sticking with iOS 5 for the foreseeable future.

This is on the lines I was talking about it seems Apple has taken different data sources without much thought into getting them correctly placed on the map. Google has thousands of engineers working on maps making this happen... Using many points of data to verify a place really is where it says it is and more importantly is represented properly on a flat map.. and a round one at that (3d maps). And corrections happen REALLY fast, most modifications I have made in Google Maps are realized within a couple of hours - there are some really cool videos about how they do this... People think the street view is just for fun, but it plays a MAJOR role in this. Because the street view data is not just for taking pictures and driving on roads, but it also is looking at street signs, storefronts, addresses, etc... And it is then used by the engineers to validate map corrections. Now this data is not super current, but it is constantly being updated - I see Google Cars in my city at least 2-3 times a month driving around - and no those pictures are not being uploaded immediately to Maps, but I guarantee they are being used to source additional data...

I do this sort of thing for a living (not for Google though, but I do see data I've collected or paid to be collected for me show up on Google fast) and it's way more complex than most people know or understand. The only way to have good mapping data is to do it like Google is, constantly checking, refining, updating and fixing. You don't just buy a few terabytes of data and call it a day.

Google Maps wasn't perfect - but no one - not even Google - made any claim it was. It works well for most people in most cases. That's all anyone claimed.

Anyone does not = everyone. I knew that iOS Apple/Google Maps lacked the turn by turn GPS feature. My friends with Android phones repeatedly pointed this out. - So, no matter how good iOS Apple/Google Maps was, it could not have an important feature that was essential to compete with Android, again, turn by turn GPS.

TheWerewolf wrote:

So, if iOS 6' map app was about as good as Google Maps, it's already lowering the bar. Apple products are supposed to be easy to use, have great quality and offer a great experience. Google Maps is below that bar (most apps are). But in fact, iOS 6 Maps is *below* Google Maps in general quality. Arguing that Google Maps isn't that great is an irrelevent argument because *no one* defined Google Maps as a gold standard - it's just the most commonly used app.

Correct.

TheWerewolf wrote:

Most people expect (perhaps without just cause) that if Apple does something - it will inherently be BETTER than the competition, not the same and definitely not worse. That's the bar.

It's sometimes an unrealistic expectation. And the new iOS 6 Map App is one of those situations.

TheWerewolf wrote:

Either abandon this world view or apply it - but applying it ONLY when you can win and refusing to apply it when you know you'll lose is poor sportsmanship.

Too bad, you were doing pretty well up to this point. I don't care about "losing" or sportsmanship as if this is a tennis match. This should be a discussion of Map software on a tech website.

TheWerewolf wrote:

Will iOS 6 Maps get better? Assuming it's not abandoned at some point, then of course it will. Will it get better than Google Maps? VERY hard to say, but my gut says 'unlikely' simply because Google invests a lot on maps. Unless Apple is going to start sending out cars around the world doing street view, there's going to be areas Apple won't be willing to implement.

I agree that the Google Maps system on Android will remain superior to the alternative iOS 6 Maps.

TheWerewolf wrote:

In the end, no matter how you paint up this pig - it's still a pig. Apple's decision to turf Google Maps isn't based on making things better for the customer - it's all about punching Google in the face. Unfortunately, the customer got punched along with them.

Now you have gone off the deep end. Again, it's too bad that rationality has to devolve into name calling and ignoring of factual information about the matter.

* Fact is iOS Apple/Google Maps could never get the turn by turn feature that iOS customers wanted. And the reason imo that iOS customers are generally putting up with the flaws in iOS 6 Maps is because they want that feature to be standard..

That's it. There is no need to exaggerate about companies getting punched. It is just business.

Okay, so you're saying that you think I'm right, and Apple did dump Google?

I'm saying that "dumped" is a dumb pejorative, employed solely to incite. Apple's Maps API license expired, and it elected not to renew because of the constraints using it placed on competitive features it could add to its product.

Not everything has to be a move made to spite another party.

Actually, the reason they dumped Google is to stop them from data mining and pushing ads to IOS users. As for adding features, I'm sure they will build on it in the future in many useful ways, but honestly speaking, that will take time so we have to work around the basic problems in the short term.

Personally, I will delay upgrading my iP4S for that reason since I frequently travel to US and Europe and need reliable maps, but plan to buy an iP5 when it's available in China. However, for local use for transit I use ExploreMetro, an awesome app I linked in another comment.

Apple over-reached a bit to hype this feature, they would have done better to concentrate on basic mapping features first, but then, that's what the public demands: wiz-bang new features over boring competence.

clearly apple is just trying to spin this. they figured that nobody wanted transit information and got caught with their pants down so now it's all about how they did it intentionally to give third party developers opportunities. i had no idea apple was so benevolent. is anybody seriously buying this load of crap?

Okay, so you're saying that you think I'm right, and Apple did dump Google?

I'm saying that "dumped" is a dumb pejorative, employed solely to incite. Apple's Maps API license expired, and it elected not to renew because of the constraints using it placed on competitive features it could add to its product.

Not everything has to be a move made to spite another party.

which constraints and which features might those be?

btw, i don't understand, if the google maps app on iOS was made and distributed by google why would apple need a license for it?

apple prides itself on having the best user experience (debatable, but that's what they claim). reports coming from pretty much everywhere indicate that their maps application is substandard and i find it hard to believe that they weren't aware of that fact however they decided to push it anyways. given that, really the ONLY logical conclusion is that apple did this with complete disregard for their users and for whatever reason as an attack against google. there is no plausible reason that faced with being removed from iphones google wouldn't have been happy to provide a full featured maps application. this is why i seriously doubt there will ever be a native google maps app for iOS6 because apple will lock them out. i'm willing to bet that google will have to resort to the courts to be able to provide such an app.

I find it funny that Apple believes that 3rd party transit options are better than consumers. If it believed that, it wouldn't have released a half way house maps app. Basically they are saying, we can't hope to do this, please take it off our hands.

I'm saying that "dumped" is a dumb pejorative, employed solely to incite. Apple's Maps API license expired, and it elected not to renew because of the constraints using it placed on competitive features it could add to its product.

which constraints and which features might those be?

Turn-by-turn directions are the single most prominent. As stated earlier, Google Maps API terms of service prohibit adding such features even with independent data sources.

canned polar bear wrote:

btw, i don't understand, if the google maps app on iOS was made and distributed by google why would apple need a license for it?

The iOS 1 through iOS 5 maps app was made by Apple, with data licensed from Google.

canned polar bear wrote:

apple prides itself on having the best user experience (debatable, but that's what they claim). reports coming from pretty much everywhere indicate that their maps application is substandard and i find it hard to believe that they weren't aware of that fact however they decided to push it anyways. given that, really the ONLY logical conclusion is that apple did this with complete disregard for their users and for whatever reason as an attack against google.

LOL. No, it's not the "only logical conclusion." Sane people realize that some things are tradeoffs; foaming-at-the-mouth nerds and a click-baiting tech press want this to be a big deal so they can point fingers and claim conspiracy and other stupidity.

Newslfash: mapping is hard. Yes, Apple Maps are inferior to Google Maps, but at least now Apple can offer turn-by-turn directions and continue to enhance the product without needing Google's permission. Apple Maps will get better and eventually be acceptable in most markets, and this "controversy" will end up meaning nothing.

canned polar bear wrote:

there is no plausible reason that faced with being removed from iphones google wouldn't have been happy to provide a full featured maps application. this is why i seriously doubt there will ever be a native google maps app for iOS6 because apple will lock them out. i'm willing to bet that google will have to resort to the courts to be able to provide such an app.

Your entire argument is predicated on the iOS 5 maps app having been made by Google. It wasn't.

I'm saying that "dumped" is a dumb pejorative, employed solely to incite. Apple's Maps API license expired, and it elected not to renew because of the constraints using it placed on competitive features it could add to its product.

Not everything has to be a move made to spite another party.

Actually, the reason they dumped Google is to stop them from data mining and pushing ads to IOS users.

Data mining how? The maps app doesn't send any user data, just map queries - queries which might even be routed through Apple server so that Google can't even associate them with IP addresses or UDIDs.

canned polar bear wrote:

Apple over-reached a bit to hype this feature, they would have done better to concentrate on basic mapping features first, but then, that's what the public demands: wiz-bang new features over boring competence.

but it also probably won't really change the perception or sales for Apple, as the people that buy their products generally already seem to be ignoring significant feature deficits in the iOS ecosystem, one more is barely a blip on the radar.

Oh yea, we're all mindless idiots, while you folks on other platforms are intelligent consumers.

Many of us are well aware of the deficiencies on the Apple platform, as well as the other platforms, and we pick Apple. When it comes to individual features: a) it depends on how critical that feature that is to us, and b) a realization that often, the overall picture is more important than adding up a feature list.

I spent decades working in IS/IT, mostly with Windows machines, yet I used a Mac personally. I feel much the same way when I've used Android so far. It's crude and just too much work unless someone is paying me to use it. If I have to pay, I want to use something decent, even if I don't get a feature here or that, so long as it isn't critical to me. (ex: Say Kindle reader and access to Kindle books disappeared from iOS, I'd be FORCED to use something else, as that is a critical for what I do. I wouldn't like to move, but I'd have to.)

but it also probably won't really change the perception or sales for Apple, as the people that buy their products generally already seem to be ignoring significant feature deficits in the iOS ecosystem, one more is barely a blip on the radar.

Oh yea, we're all mindless idiots, while you folks on other platforms are intelligent consumers.

Many of us are well aware of the deficiencies on the Apple platform, as well as the other platforms, and we pick Apple. When it comes to individual features: a) it depends on how critical that feature that is to us, and b) a realization that often, the overall picture is more important than adding up a feature list.

I spent decades working in IS/IT, mostly with Windows machines, yet I used a Mac personally. I feel much the same way when I've used Android so far. It's crude and just too much work unless someone is paying me to use it. If I have to pay, I want to use something decent, even if I don't get a feature here or that, so long as it isn't critical to me. (ex: Say Kindle reader and access to Kindle books disappeared from iOS, I'd be FORCED to use something else, as that is a critical for what I do. I wouldn't like to move, but I'd have to.)

Is your position really so weak that you needed to pull out a straw man? I never said anyone was a mindless idiot, I said that people obviously don't buy iphones because of comparative features. Apple's been way behind Android from a feature standpoint for at least a year now (since ICS hit) and always been behind it from a customizability standpoint.

I didn't say you're an idiot for buying an iphone, I just said people obviously don't buy iphones because they have more features than android phones, because obviously they don't.

I didn't say you're an idiot for buying an iphone, I just said people obviously don't buy iphones because they have more features than android phones, because obviously they don't.

Part of good design is trimming unnecessary features in favor of making the features you do have better. This is Apple's approach, which I generally prefer to a laundry list of indifferent checkboxes. Although some people may really like shake-to-refresh.

I didn't say you're an idiot for buying an iphone, I just said people obviously don't buy iphones because they have more features than android phones, because obviously they don't.

Part of good design is trimming unnecessary features in favor of making the features you do have better. This is Apple's approach, which I generally prefer to a laundry list of indifferent checkboxes. Although some people may really like shake-to-refresh.

If Germans didn't find it too confusing to use 3rd party apps for transit, I'm quite sure, US Americans will quickly get used to 3rd party apps plugging into Maps.app for transit directions.

There's a problem with that. I have no doubt that people (myself included) will adjust to this, but a large group of users is being downgraded even though another large group's experience is remaining the same or somewhat enhanced. My preferred alternative is that we continue to have the level of convenience that the old Apple Maps app provided (using Google-data), and extending that integrated service to users such as yourself.

Postulator wrote:

I figured that Apple left out transit information because they decided their target class of buyer didn't use public transport.

I live in the San Francisco Bay area, which is Apple home territory (they're technically further south but there's lots of people who travel between areas). The area probably has the best public transportation system for a large region in California and I regularly see people using their iPhones and Androids to navigate their way around the system. I doubt the class of their users was on Apple's mind but let's be clear that I am not excusing them. If it was an issue I don't think they would have included these Maps APIs at all for public transit apps. Whatever the politics between Apple and Google, most users don't care but they care is that public transportation experience on iOS is now less convenient.

Eriden wrote:

jgk6 wrote:

Eriden wrote:

This is the singular upshot of living in a city of 6+ million whose mass transit policy is "five or six buses and one train." The loss of mass transit directions only matters if there was mass transit to begin with.

Let me guess: Houston?

Spot on. Though I'm not too familiar with it, Dallas probably would've also been acceptable.

This means that I can "brag" about Los Angeles' public transportation system, which has traditionally been the butt of jokes in California. To be fair I've heard they have improved in the 10 years since I left.

CapuchinSeven wrote:

Honestly not noticed anything wrong with the maps app that better data won't fix. The app itself is very nice.

And PLEASE, Google maps on both Android and iOS has walked me to closed businesses before.

I don't think the question was whether the new Maps app will improve. Of course it will. But how much problems should we tolerate in a first release and how long will we have to wait for significant improvements? We should all be more tolerant for 1.0 releases, but we also shouldn't be too lenient either. Will Apple somehow be able to improve the convenience of using 3rd-party apps for public transit? I think the idea is inherently less convenient than the integrated solution offered by the old Apple Maps using Google's data.

Whether a business is closed is besides the point. Businesses open and close all the time and I don't expect such data online to be reliable (I regularly call businesses I find online so I can confirm their hours before I visit). Transportation systems on the other hand, generally don't change much from day to day or even year to year, so they're far more stable.