Ask YC: Want to learn about GPS/Location Based Programming. Where to start? | Hacker News Reader

Ask YC: Want to learn about GPS/Location Based Programming. Where to start?

23 pointsshafqat19 comments

Hi all - I'm fascinated by the notion of GPS/Location Based programming and generally programming mobile apps that are location aware. I've read some primers and have a tech background, so wondering if the community had links or background to share to learn more?

I guess the fundamental questions are:

1) How much can a programmer do without striking deals with the big telecoms (i.e. can you now get around it with the new location aware phones). 2) What kind of APIs already exist? 3) At the end of the day, the challenge is to get the location (longitude/latititude) of a phone user. The rest is up to the idea/execution of the app. I need to know what to read/learn to enable me to hack an app to get that location.

I know this is HUGELY simplified, but hope you get the gist.

View on HN

I can give you a teeny tiny head start. Here is the logic for determining the distance (in miles) between two points.

    sqrt((power(69.1 * (latitude1 - latitude2),2) + power(69.1 * (longitude1 - longitude2) * cos(latitude1 / 57.3), 2)))

This is coming from SQL server... it took a little fidgeting to get the actual distances right because of the weird curvature of the earth issue; but it should get you close for reasonable distances.

The Yahoo! geocoding API is pretty nice for getting lats and longs for addresses in the US:

http://developer.yahoo.com/maps/rest/V1/geocode.html

Wow, cool. This is the kind of stuff I'm looking for. Tips and tricks to help me start coding and experiment. Thanks!

> it took a little fidgeting to get the actual distances right because of the weird curvature of the earth issue; but it should get you close for reasonable distances.

Probably can't tell you how we solve it at work, but the very much publicly-available book Computational Geometry: Algorithms and Applications, Third Edition by de Berg, Cheong, et al., mentions something about the robustness of geometric algorithms using inexact (floating point) vs. exact arithmetic. :-)

I can never tell the appropriate way to say thank you to a poster here. Should I upvote? Should I leave a comment? In this case, I'll do both.

Thanks for the recommendation, most of the maths work I do these days is financial, so geometry is a nice diversion. I hadn't seen this text before so I've got it bookmarked for some reading now.

As an aside, is this something I would have gotten some exposure to if I'd been a college grad? Any time I see things like this, I worry there are large swaths of text I've missed in self-study.

> As an aside, is this something I would have gotten some exposure to if I'd been a college grad?

You might have had some exposure to the subject, but probably as part of other problems, i.e. not under the name Computational Geometry. For me, the most valuable thing was learning that this was an actual field with a name, which gave me a starting point for self-study.

Also check out Computational Geometry in C, Second Ed., by O'Rourke. It goes into more low-level implementation details (the first book I mentioned is a good high-level introduction to reasoning about geometric algorithms, so you should read that first).

Having spent many years working on this problem in the US market, here's my two cents ...

There are tens of millions of mainstream handsets on the market that contain GPS, including virtually all phones sold by Sprint and Verizon in the past few years and most new AT&T phones going forward. However, location is typically locked down and requires a relationship with the carrier to access the handset location APIs. For location privacy and business reasons, making a deal with a carrier for a location-enabled application is often a multi-year process.

The other possibility is to target smart phones such as the Nokia N95, iPhone, Blackberry, Windows Mobile, or Android that provide more open access to location. This is a good audience of early adopters with high data usage, but it's a very small percentage of total phones on the market.

Handsets using carrier-assisted GPS will typically have better performance than smartphones. The 'autonomous GPS' in most smart phones takes a long time to get an initial fix and is less accurate than carrier assisted, or aGPS handsets, which utilize cell towers on the network to enhance performance. Note: The new iPhone will combine GPS, Wi-fi, and cell tower location and so should be fairly fast and accurate.

One means by which developers can gain access to location across multiple carriers is through WHERE http://developer.where.com (caveat: i work there).

I'm working on a white paper covering all of this in more detail. If you're interested in getting a preview copy, let me know.

I also work at a startup in the location space. If you're just looking to play around and have fun, I'd definitely recommend avoiding the "feature phones" (J2ME and BREW) and focusing instead in Symbian and Blackberry.

Most Windows Mobile devices in the US don't allow access to GPS or have it deliberatly crippled (The Sprint Mogul and AT&T Tilt are the only two I know of with user accessible GPS).

iPhone is still an unknown, as I doubt Apple will open up its app store to every developer and every app. Right now it's probably best to wait and see.

Android is, well, not out yet. Wait for a device to make it to market.

WHERE is also a fast easy way to get one shot fixes and rapidly deploy an application to the millions of "feature phones" out there already, but it won't give you background updates or complete control over the user experience.

Here are my delicious location links:

http://del.icio.us/jmatt.peterson/location

There are a lot of APIs if you are going from address, city, zip. All sorts of variations - free, commercial, metadata, super accurate, international, US only, shipping, etc.

There are fewer and they are less reliable if you have a latitude / longitude and want address, major intersection, city, etc.

Initially I'd code for phones that provide basic location information like lat/long/precision. Personally I've written code for the iphone and android. I'd avoid any of the older phones that don't provide some sort of API. Your initial users presumably will be techies with newer phones. If you have some initial success you can add support for older phones that don't have a friendly API.

Thanks this is fantastic. Going from address is fairly straightforward as you say.

However, I am looking to use the GPS or tower triangulation built into newer phones. I'm assuming this is available through the ipHone and android APAs?

Is any of your code open-source by any chance? Just looking for some tips as to how to get started - even the basics.

There's plenty of code on the Nokia wiki, including a complete compass application: http://wiki.forum.nokia.com/index.php/GPS_Compass

(See also, the location category index http://wiki.forum.nokia.com/index.php/Symbian_C%2B%2B_Locati... )

Try postgis, it's really cool with postgres. You can add a column which makes evaluating distance between points really easy. If you want to find out what points are near a given lat,long.

DISCLAIMER: I work for the Yahoo Developer Network

Yahoo recently released an updated version of the Where On Earth (WOE) API for Where 2.0 (more info at http://developer.yahoo.com/geo/).

It's pretty cool, I especially like the way that WOE deals with hierarchy in places. So a street address is normally part of neighbourhood or area of a city, which is part of a state, etc.

One of my other favourite projects at Y! at the moment is also about LBS. Fireagle is one of the Brickhouse projects, so those guys are actually based in San Francisco. http://fireeagle.yahoo.net is still invite only, but that's mostly to hide it from consumers until it's ready to go. Fireeagle acts as middlewear, allowing users to update their location in lots of ways through an API (Text string, GPS units, Cell phone via services like Navizon, etc) and then share is with apps of their choice. This means that the user only has to update Fireeagle to update all their apps.

It also means app developers don't need to provide lots of ways to specify location. They can just use Fireeagle and forget about the rest.

I have some invites so if you have a good idea let me know and I'll hook you up.

I've looked into it a little bit and FireEagle(http://fireeagle.yahoo.net/) seem's ok, but it works with Navizon (http://www.navizon.com/) which I think would be a better solution if it provided api access to the free users of it's product.

What about Google Gears/Android and the iPhone API? If you build an application that uses those two APIs, won't that cover most of the future mobile market? If so, is there any need to dig under the covers - just make the simple API calls??

Check this out: http://del.icio.us/popular/gis and http://developer.yahoo.com/geo/

This site is a bit more hardware orientated but you may find some of it useful:

http://www.hackaday.com/search/?q=gps

A bunch of APIs, data, and examples here:

http://del.icio.us/pskomoroch/gis

The GPS chip/unit embeded in cell phones is incredibly minimal (at least when I reviewed the topic a couple years ago). The phone itself does not calculate lat/lon. The phone captures the bare timebase GPS signal, uplinks the raw sat numbers to a server which calculates the actual coords and transmits that back to the phone.

But privacy issues are probably the biggest reason lat/lon is not more available for app usage.

That's nonsense. I know of no phone or device that does this, it's not like the calculations needed are exactly challenging even for your typical phone with a 200Mhz arm chip.

Reply on news.ycombinator.com