Hacker News Reader

Comment by Terretta | Hacker News Reader

This app has some interesting ideas, but fails at the core task of navigating to a destination when it tries to be too clever about the address.

Say I'm in SW Connecticut, trying to go to our datacenter in NYC, at 111 8th Ave.

For all variations on 111 8th Ave, New York, NY, 111 Eighth Ave, Manhattan, NY (and all combinations thereof), this app suggests bizarre alternatives in Brooklyn, San Francisco, or what look like misspellings from Foursquare like "8th Ave Parkimg Garage" (sic).

Unless one can enter an address and go to it, no other feature or UI element matters.

View on HN

I agree this needs to be improved. The problem is with Apple's geocoder, which seems to be really dumb at finding addresses. We would like to use Google Geocoding Service instead, but they don't allow it if we don't display the results on a Google Map (and starting with iOS 6, the map tiles are now provided by Apple).

Apple's geocoder gets "111 8th Ave, Manhattan" and "111 8th Ave, Manhattan, NY" right.

In New York, Apple and others often show streets off of Manhattan island unless you call the island locations Manhattan. That's because for the other addresses, they have to accept users looking for them using New York as the city too.

Navigon, Tom Tom, Garmin, Google Maps, and Apple all exhibit that issue. But doesn't seem to be the issue here. Issue here seems to be results from Foursquare instead of an address lookup, with no valid address ("what I typed") option to select to continue.

Thanks for the technical precisions re: address geocoding in NYC.

Right now, tapping the return key will try finding an exact match of what you entered on Foursquare. If it fails, it will fall back to the geocoder and then proceed immediately with the routing request. This will be improved in 1.2.1 as the return key will now be labeled "Search" instead of "Route" and will no longer trigger the direction request.

Indeed the foursquare suggestions make address lookup confusing, as the Foursquare suggestions sometimes make no sense with what the user entered. I thought of maybe leaving them out when the search text starts with a number, but then that would leave out venues that start with numbers as well.

I'm genuinely curious as to why you're using Foursquare first and geocoding as a fallback.

What geocoder do you use? The one from Maps SDK or directly Google's?

Have you looked into Yahoo PlaceFinder? My understanding is that they don't have a similar restriction on use, although I don't know if they're better than Apple's geocoder.

It looks like this app is using Foursquare's geocoder.

Using Foursquare makes no sense to me. It should use Google's geocoder instead.

It only uses foursquare for suggestions. Read up my comment above that explains how it works.

isn't it possible for someone to write a mapkit alternative thats backed by google's tiles and geocoder?

I'm sure it is. In fact, I've wondered if Google might try something like that (e.g. if/when they release an iOS app, expose some custom URL schemes for third-party developers to use if they want).

That being said, there is another problem. I can't see Apple looking kindly on developers deliberately routing around a system API to use a competitor's. Perhaps, given the current PR issues, they'd be forgiving in the app approval process for the moment, but I certainly wouldn't count on such forbearance.

I don't know... I'd think that as long as you're not using private api's its all good! :)

As a workaround, you can drop a pin anywhere on the map with a long tap.

Completely off-topic... SW CT, woot!

Reply on news.ycombinator.com