
Ask YC: Want to learn about GPS/Location Based Programming. Where to start?  - shafqat
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?<p>I guess the fundamental questions are:<p>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.<p>I know this is HUGELY simplified, but hope you get the gist.
======
icey
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>

~~~
icky
> _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.
:-)

~~~
icey
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.

~~~
icky
> _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).

------
akuafo
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.

~~~
kogir
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.

------
jmatt
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.

~~~
shafqat
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.

~~~
jamess
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...](http://wiki.forum.nokia.com/index.php/Symbian_C%2B%2B_Location_Articles)
)

------
vikram
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.

------
sh1mmer
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.

------
auston
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.

------
shafqat
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??

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

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

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

------
pskomoroch
A bunch of APIs, data, and examples here:

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

------
sammyo
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.

~~~
jamess
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.

