Maps with turn-by-turn navigation (long overdue) and transit APIs sound very promising. Having portable maps is one of the key strengths of a smartphone and this kind of lower-level integration now kicks it up a notch. He mentioned "biking and hiking" for the transit apps: that's exciting!
Also, turn-by-turn navigation has this "overview" mode--tap it and you exit the forced-point-of-view navigation and get to pan around the map in 2D mode. This is critical for being able to inspect the area for improvised routes. In the past, this has not been easy to do on all my old-school GPS navigation devices, including a Tom Tom hardware unit of a year ago. Cannot compare to Google Navigation or Tom Tom on the iPhone, so it would be great if anyone familiar with those can chime in.
Fully vector maps (no more f'king double tap to get that shit at pixel-perfect view) and much more legible traffic marking (such that it doesn't kill the name of the street) are two minor changes that will have a major impact for me personally.
Sort of FYI, Google's original effort at providing their own database for map information was that Navtec would not license them the right to use map data for turn-by-turn navigation. It was really quite amazing to see all of the constraints that were put on map data (it was so much easier for Trimble, the original company, to exploit their map database than to try to compete in the gadget space).
I don't doubt that Apple has been working on their own database to use for turn by turn and it wasn't until now that they had it ready to go. Stuff you need that isn't "normally" in a GIS database are driving restrictions, road quality metrics, etc. There are also 'quirks' exceptions for this data like "In theory you can get from A->B->C in Portland on this route but you really want to go A->D->C." some of the "roads" in SE Portland would challenge dune buggies :-)
In my former life in US-GEO (MapPoint, Streets & Trips, 1997 or 1998) at Microsoft, one of the tools I worked on normalized data sets from disparate vendors. One of the largest jobs we had was figuring out mappings from the "north" of one vendor and the "north" of another, as the vendors for high-quality data sets varied from locale to locale.
Frequently, you would need to rotate and transform the data to get it close enough that the geometry could be snapped together. This usually required some manual intervention; nothing like the human eye for detecting an array of streets suddenly had a 1 degree kink where it crossed some stitching line.
Our licensing for the data sets was very strict, and deformed the products in interesting ways, as you might imagine.
My fondest memory of working with that group was inserting POIs - we all got a POI, provided it wasn't obscene or something. I named a feature close to where I grew up; sadly, the POIs were culled every edition.
Sort of FYI, Google's original effort at providing their own database for map information was that Navtec would not license them the right to use map data for turn-by-turn navigation.
Of course Navteq would allow them to use map data for turn-by-turn navigation, but Google didn't want to pay the price they were asking for license fees.
Earlier Navteq and Tele Atlas had a duopoli in worldwide map data - no-one else had as good coverage as they had. And they used tiered licensing structure. On lower tiers, you were allowed to display maps, but you couldn't use them for turn-by-turn navigation or for example dynamically show locations of your friends.
Actually in that particular case, according to what the employees were told at one of the TGIF events, previous deals Navtec had made with navigation device vendors precluded them from licensing Google the turn by turn rights at any price.
Now that may have been a misstatement, but it was presented as a large part of the rationale for the whole project which encompassed getting rights to satellites, driving data, broadcast source locations, etc etc. Things like "we bought Keyhole and got great satellite imagery but we're forbidden from image processing that imagery into a map, so we bought a satellite and took our own damn pictures." It played well with the whole 'think bigger than that' mantra that Larry Page embodied.
Good quality of results is difficult to get even on paved roads without "boots on the ground". Consider driving down a street with stop signs at every intersection (NW Northrup St) or one with speed bumps every block (SE 41st Ave).
Yes, when people asked me why Google was spending millions on driving around taking a picture of every street I explained they were actually taking pictures of the signs on every street :-) That you can see your front door is just a bonus on top of the intelligence that is gained by being able to image process miles and miles of streets for data about how they are used (or not).
Or both...yesterday google maps on my iPhone took me to Taylor Ave in Sunnyvale. Those are stop signs and gutters deep enough for cars to scrape the ground! Either street north or south would have been better.
Maps in iOS6 look great, but will moving away from Google break legacy apps for <5.1? I'm sure main stuff will integrate pretty seamlessly, but what about the little stuff? (e.g. in a UIWebView, if I make a link to google maps, when the user clicks it, they are taken to the Map app). In the long run, it's the right decision, I'm just eager to test some of our MapKit apps on iOS6, to see what breaks
FWIW, my small app which uses MKMapView just to show a location - works fine on iOS6 as is. Of course. I'd guess that API (is and) will be backward compatible.
I'll chime in here as I'm currently working on an app that uses MapKit extensively. MKMapViews work in pretty much the same way as they did in iOS 5, no breaking changes.
The one thing that did break in my case was the feature of my app that opened up a walking route in the old Maps app. On iOS 5 this is done by redirecting any maps.google.com URL requests to the Maps app but of course this doesn't work with the new method. Thankfully they've replaced this with a generic API that allows you to programmatically create a routing request (no more string concatenation!) and pass it to any app which implements the required protocol for handling it, right now that's just the Maps app but I'm sure that selection will expand once iOS 6 is out.
It really bothered me that Google Maps on Android got vector maps and the iOS Google Maps didn't. I guess that won't be a problem for me later this year.
Also, turn-by-turn navigation has this "overview" mode--tap it and you exit the forced-point-of-view navigation and get to pan around the map in 2D mode. This is critical for being able to inspect the area for improvised routes. In the past, this has not been easy to do on all my old-school GPS navigation devices, including a Tom Tom hardware unit of a year ago. Cannot compare to Google Navigation or Tom Tom on the iPhone, so it would be great if anyone familiar with those can chime in.
Fully vector maps (no more f'king double tap to get that shit at pixel-perfect view) and much more legible traffic marking (such that it doesn't kill the name of the street) are two minor changes that will have a major impact for me personally.