Building a Coverage Map for Mobile Operators in India
http://towermapify.herokuapp.com/
What towermapify does ?
Towermapify is a coverage map. The objective is to map the coverage strength of all of the operators in India, whether they provide 3G, 4G, or HSIA (high speed internet connectivity) in a particular region.
If a user needs to know whether 3G/4G/HSIA is available in a region or how good the coverage strength of a particular operator is, the information can be found using Towermapify.
1 internship month = 1 prototype throwaway + 1 Production version
Growing requirements
Once I got a prototype working, the requirements at komparify.com started growing. We badly required many features, but Fusion tables were not enough because they had limitations. For example, you can‘t do a "OR" in the SQL query you send, and your table should be publicly available.
Thrown far far away
So many days and days of work were thrown away and we finally settled down to define a development stack. We decided to use our own servers and make RESTful APIs for data.
Towermapify — Built on
- Ruby on Rails
- Google Maps API V3
- KML/JSON
- HTML+CSS+JS
- Rails Cells integration
- MySQL
OverQuery algorithm
Problem (A)
We have a huge amount of data containing latitude and longitude information for places all over India. If we drop markers for all of the places, it will do a catastropic amount of damage to the performance and browser. Because it uses a huge amount of memory, it's not a good idea.
Work around (A)
So, to decide which markers to drop, we got the bounding edges south, west, and northeast of the map. With that, the query is for only the places that reside inside the bounding box and then we will query again when the user does panning inside the map with the new bounding box.
Problem (B)
The way we find the new bounding box after the user pans is by listening to the map-events. However, the problem is that map-events fire for every small pan or zoom, making navigation inside maps terrible. If the mouse is just shaken inside the map, it does a query for the new bounding box and drops the markers again, giving a terrible user experience. Also, the server-client IO will be high.
Work around (B)
This is the place where we went back to the drawing board and started writing rules that minimize the number of requests to the server and gives a good user experience.
Overquery
Whenever a query for the bounding box (let's call it box original) to get latitude/longitude for the markers is made, we have to add a delta value to that bounding box(let's call it box modified) so the results from the server includes the results of a bigger bounding box.
box original < box modified
When the user pans within the box modified, there is no need for querying since we already have the results fetched during the previous query. Only when the user pans outside the box modified do we need to query again, which follows the same procedure as above. Now, when the user pan around the map, the panning will be smooth and that's how Problem(b) was solved
Performance Boost
We were very close to putting this into production and then we started looking under the hood. The latency was not really high, but it was notable. The reason behind this is the data-exchange format we had — it was KML (keyhole markup language). We used this because there was a pretty KML parser( 
) available so it is was easy for us to handle data.
We switched from KML to JSON, and this gave us a solid decrease in the latency. Of course, a few big parts of the app had to be rewritten and I did that too. I wrote the full stack(client+server) so it was not hard for me.
Finally we shipped
The app exists in rails-cells integration inside komparify.com.
http://towermapify.herokuapp.com/
This post is originally published by the author here. This version has been edited for clarity and may appear different from the original post
