Citymaps was built by a small team with a big idea: to create a real-time, personal map of places. Based in New York City, our startup was founded on the belief that maps could be more. More fun. More personal. More inspiring. And in order to do more, we had to build a new map platform from the ground up.
We wanted a map that would do two things really well: quickly show you the relevant places around you, and help you make better decisions on where to go.
We believe that a single recommendation from a friend is more meaningful than many recommendations from people you don’t know. When you Follow someone on Citymaps, your map becomes personal because it surfaces the tips they leave on places. Simply pan the map and see your friends’ tips pop-up over places. This is especially useful when you are discovering new areas or remembering old ones.
We designed Search to give you more relevance. With Citymaps you can quickly Search Your Places and Friends’ Places with 1-tap. If you Search for a specific restaurant or cuisine, Search will automatically show you if your friends have left a tip or liked it. With Social Search you spend less time figuring out if a place is good, and more time enjoying yourself out in the world.
There are a lot of places out there.
Citymaps brings them all together on your own personal map.
At Citymaps, we have designed our technology stack to balance speed and scalability with flexibility. We are pushing the boundaries of mapping technology, and moving to a future where we will serve up unique, personalized maps for every user.
The core of our technology efforts fall into three areas: our cross-platform vector map engine and its related mobile client applications, our business API services, and our location data processing technologies.
At the core of our client applications is our proprietary vector map engine. Developed in C++, the map engine is platform-agnostic and runs on the iOS, Android, and Windows operating systems. It is responsible for taking binary-encoded vector map tile data from our OSM-based map servers and rapidly rendering map tiles on the mobile client (faster than 60fps on some devices). It is has been designed to take full advantage of multiprocessor architectures, and includes adjustable memory and file caching to allow for short and long term storage.
Some of our map engine components include: a label renderer and collision detection algorithm that intelligently displays labels for streets, POIs, neighborhoods, and cities; a POI display system that surfaces locations based on popularity and/or personal relevance to the user, and a marker system that supports arbitrary images, extends simple markers into more complex ones, and associates arbitrary labels with markers.
Our map tiles are delivered in a custom binary data format optimized to minimize size. They are generated by our map tile server, written in Scala and Java, and served up by Amazon’s CloudFront edge-caching service for high scalability and responsiveness.
Our map engine powers our applications on iOS, Android, and a Windows-based mobile display platform that runs in 7,000 NYC taxis. We are also currently developing a WebGL port of our engine.
The map engine is currently available as an SDK. This SDK allows developers to create complex maps in a few short steps. The SDK hides the complexities of our engine, exposing only those functions the developer needs to build their map. Our development partners can use our Style Editor to customize the look of our map.
We use geo data provided by the awesome members of the © OpenStreetMap project.
A map is only as good as the data it provides, and we provide lots of great data via our business API services. These services provide data on venues, users, and user maps, and personalize the results to each person’s specific needs and tastes. Our API services consist of our core service (data about our venues, users, and user maps), our search service, our notifications service (manages push and email notifications) and our on-boarding service (asynchronously loading data from partner sites so you can use our applications without waiting).
Our map services are written in Scala, and served up by the Play application servers proxied by an Nginx load-balancer. Search services are provided by Elasticsearch, and the data is stored in a Postgres database cluster.
Application and user images are stored on our Riak cluster, and also fronted by Cloudfront. Our business objects are “lazy-loaded” and stored on an in-memory Redis cluster running on Amazon’s Elasticache service.
All these services require lots of communication to coordinate efforts properly, so we use a messaging bus (RabbitMQ) to allow the API services to talk to each other.
Our IE is responsible for taking data from our business partners (via SSH, API request, or flat file), processing it for use within our system, then sending the data to our VPS via RabbitMQ messages.
The VPS is responsible for taking locations and deals discovered by our IE, grouping and de-duping them, and using our proprietary business rules to decide which to publish. Each time a business is updated by one of our business partners, the DPS runs the full suite of publishing tools, sends it to our web service to be published, and sends a RabbitMQ message to the API services to invalidate any cached copies…all within a couple seconds or less. It does this for hundreds of thousands of businesses each day.
We’re pushing the boundaries on what is possible with mapping technologies. The technical challenges are unending, which keeps us motivated and excited. Want to join us? Email us at email@example.com.