Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It only takes a minute to sign up.
Sign up to join this community
I'm building a location based android application with following requirements:
All the processing will be done on the server side. The android application will communicate with the server through web services. What tools and packages do I require to achieve these requirements? I'm new to GIS. My preferences are java and free software.
Very simple answer is: Somekind way to read GPS data. Convert it to Point(' longitude lattitude) format, tool to send it to server side and store it in PostGIS ( you need to add from user, now() to it. Do PostGIS search for mentioned Point 'SELECT users, st_distance(the_geom, point) from somwtable where ST_distance(the_geom, point) < "some sane value". Return users, distance rows to back android and display them ).
So all you need is PostGIS database.
You'd develop an Android app using tools such as Eclipse and the Android SDK and request location updates to your app via the Location API's LocationManager.requestLocationUpdates() method. GPSTest open-source app on Google Play is a good example of how this is done. Android source code is here. If you don't need fine-detailed resolution for location data, for battery life reasons I'd strongly suggest listening to the NETWORK_PROVIDER (i.e., combination of cellular and Wi-Fi location) instead of GPS for battery life reasons. Even more efficient is the PASSIVE_PROVIDER, but using this you will only get location updates when they are requested by another app, not at a fixed interval. If you're collecting data ongoing in the background, you'll need to execute this code in a Service, instead of an Activity. See this page on the Android Developers site for details and tutorials on getting location on Android.
There are two options to send data to the server:
For #1, I would suggest creating a REST-ful API that is hosted in a web server and uploading the data encoded in JSON over HTTP.
For #2, I would strongly suggest sending data to the server using a compact format (e.g., proprietary) and an efficient protocol such as UDP. (See bottom paragraph for details why).
For #1 and #2, you need to be very careful on how often you refresh the location (e.g., Network or GPS data), and for #2 you need to be very careful on how often you send data to the server. Both GPS and wireless data transmissions have huge impact on mobile device battery life, and wireless transmissions quickly eat up the data allowances for users with tiered data plans (i.e., not unlimited). Again, use the NETWORK or PASSIVE provider if possible to avoid the heavy energy cost of GPS. Additionally, for wireless data transmissions, if they are happening frequently you really want to use an efficient protocol like UDP instead of TCP or HTTP, since UDP is much friendlier to battery life. Also, for #1, use compact formats such as JSON (or Google's Protocol Buffers) instead of XML, again for battery life and data allowance issues.
I wrapped up my dissertation on intelligent location-aware mobile platforms earlier this year, and it has a lot of field tests showing the impact of both GPS and wireless transmissions (including UDP vs. TCP, and SOAP vs. REST) on battery life and data allowances, and also has some strategies to mitigate this. Short version published in IEEE Pervasive Computing is here.
For either #1 or #2, we've hosted web apps receiving this data using the open-source Glassfish project, and have had good experiences with it. I'd recommend Netbeans for this type of server-side web application development, although you can accomplish the same in Eclipse.
You'll need to set up your Glassfish server to connect to PostGIS via JDBC drivers. Once the location data arrives at the Glassfish server, you can insert it into a PostGIS database and/or execute a spatial query to discover the items you've listed (see simplexio's answer for details). Once you have this information in your Java webapp, you can then perform any action you want from this software that you can do in a normal Java application.
Doesn't foursquare do this already?
Because of our pretty insane growth, we’ve designed our entire software stack to be as flexible and scalable as possible. It’s allowed us to go from a few thousand users to over fifteen million, and also to easily add more amazing engineers and get them contributing right away.
Foursquare is currently hosted within Amazon's EC2 service, using hundreds of servers running a bare bones version of CentOS Linux. We use NGINX to route requests and serve static content, and HAProxy to load balance web and API requests across many machines.
Then we get to the fun part. Moving up the stack, the live site data is stored in MongoDB (though we use Memcache to cache a small set of expensive calculations). For offline data analysis we regularly snapshot our live data and import it into a Hadoop cluster. We have some custom MapReduce jobs, but mostly rely on Hive's simple query syntax and a custom built job scheduler for regular calculations. We use Solr and Elasticsearch for powering venues, tips, users, and events search. Our search geo-indexing uses Google's s2 library to store cellids within our search index. We use PostGIS and the wonderful geonames.org dataset to reverse geocode addresses into coordinates, which allows us to place venues on a map and make them available for location-based search. Kestrel is our queue for asynchronous tasks that we wish to perform out of band of users' requests. User generated photos are stored on Amazon S3 with content delivery through Akamai. There is a bit more complexity if you dig deeper, but that’s the heart of it.
Almost all of the code for the web site, API, and batch processing is written in Scala. The web and API are built on top of the Lift web framework. We also use a good bit of Python and Bash scripting for automating build, deployment, and operations tasks. Finally, the dynamic content on the web site is written in javascript with a mix of jQuery, Backbone.js for object models, and Soy for templating.
We use beautiful maps by MapBox created using data provided by the wonderful © OpenStreetMap(and) contributors, CC-BY-SA. The interactive maps are generated using the open-source library Leaflet.
And we’re constantly pushing the limits and trying new things. Want to come join us? We’re looking for world-class engineers who want to do amazing things.
You can learn more about the technology we use on our engineering blog and on our github
.
you can check out Bump API 3.0 for Android and Scringo for your needs.
Scringo is a cross-platform SDK for iOS and Android. Scringo is the easiest way to let your users chat with each other, discover who else is running your app, and invite their friends through Facebook and Twitter. All within your app.
Scringo Radar lets your users find each other. The map and the list views display who else is running your app nearby, who's online and ready to talk, and what they like to do with your app. Scringo Radar also allows your users to view only their friends, prevent interactions with unwanted users, and more.
i hope it helps you...
