Building a geospatial querying REST api

I am trying to build an iOS app that takes the location of the user and then queries the backend for other users near him/her through a REST api.I have done some googling and my choices (given my experience) seem to be .

• Django - piston with geodjango.Hosting on webfaction probably.
• Google App Engine.

I am more inclined to the first choice since Google App Engine seems to be not so open and has a steep learning curve in the beginning.

Now doing location queries on a mysq开发者_StackOverflow社区l database seems kinnof intimidating.My gut feeling is that there has to be something better.Afterall I dont want to reinvent the wheel!!

Can anyone please throw some light on

• how exactly I am going to location queries?..bounding recangles or something better?
• what database should i use?...non-relational or relational?
• If relational...should the databases be indexed by location?
• Should the location data be stored in a seperate table or the same table as other user data?
• Should I use timestamps to invalidate old location updates or is there any better method for doing that?(for example the database could itself peridically delete location updates).

I have been primarily an iOS developer so far and have minimal experience in building web apps.Any suggestion would be greatly appreciated.

If a similar question has been asked before feel free to point it out.

Thanks in advance. - samyzee!

---

I'm afraid you're asking too many and general questions to get a useful answer. I'll try:

If you want to do very simple geo-spatial stuff, try to stick to working with bounding boxes. the simplest technology that fits the problem is well worth exploring. However, you'll probably find out soon you need more...

If you want to use geodjango, use a PostGIS database and forget the non-relational ones. You will be developing a back-end and it has a steep learning curve for a non-webapp programmer. Start with the geodjango tutorials, and gradually develop a technology stack you're comfortable with (REST services will be easy enough with geodjango).

The reason for choosing a non-relational database is either very use case specific (you want to store documents, a graph, or you don't want a predefined schema) or required for scaling purposes (concurrently read and write a lot lot of data, and therefore use multiple nodes, etc). If you're a non-web app programmer, hire one with experience (who can do some 'software architecting') to help you on this path.

• Should the location data be stored in a seperate table or the same table as other user data?
• Should I use timestamps to invalidate old location updates or is there any better method for doing that?(for example the database could itself peridically delete location updates).

Ask someone who did any database design to help you. With the problem description so far, you could work with two tables: a User(id, name) table, and a UserLocation(id, timestamp, user_id, xCoordinate, yCoordinate) table. Than add a UserLocation row for every sample you get for a user. You can later design (and change) rules on interpreting the UserLocation table, like:

• The latest UserLocation is the one which is valid
• If the timestamp is older than 4 hours, it's unusable
• etc

From your line of questioning, it feels you're a bit out of your league. However, if you can stick to simple technology and work pragmatically, you can get your service working. Why not start with mysql+php and bounding queries? And swap it for something else once you have everything else working?